Pub/Sub: Pengantar keandalan

Panduan ini memberikan pemahaman dan gambaran keseluruhan tentang fitur keandalan Pub/Sub. Topik yang dibahas dalam dokumen ini mencakup:

• Mengapa Pub/Sub?
• Failover
• Penyelaraskan penayang
• Menyesuaikan subscriber
• Menggunakan snapshot dan mencari deployment yang aman

Mengapa Pub/Sub?

Sebagai paradigma pengiriman pesan, publikasi-langganan dirancang untuk memisahkan produser pesan dari konsumen pesan tersebut. Produser tidak mengirimkan permintaan langsung ke konsumen dengan data, melainkan memublikasikan data tersebut ke layanan Pub/Sub seperti Pub/Sub. Layanan ini secara asinkron mengirimkan pesan tersebut kepada konsumen yang berminat dan telah berlangganan.

Hasilnya adalah layanan tersebut menyerap semua seluk-beluk menemukan konsumen yang tertarik dengan data. Layanan juga mengelola tingkat penerimaan data oleh konsumen, berdasarkan kapasitas mereka. Pemisahan ini memungkinkan pembuat data menulis pesan dalam skala tinggi dengan latensi rendah, terlepas dari perilaku konsumen.

Pub/Sub menawarkan pengiriman pesan yang sangat skalabel dan andal. Meskipun layanan menangani sebagian besar hal ini secara otomatis, Anda memiliki kontrol atas berbagai aspek penayang dan pelanggan yang dapat memengaruhi ketersediaan dan performa. Bagian selanjutnya dari panduan ini memberikan beberapa detail tentang aspek-aspek tersebut

Failover

Pub/Sub adalah layanan global: topik dan langganan tidak terkait dengan region tertentu, dan pesan mengalir dalam layanan Pub/Sub antar-region jika diperlukan. Saat menggunakan endpoint global, pubsub.googleapis.com, penayang dan pelanggan akan terhubung ke region terdekat dengan jaringan tempat Pub/Sub berjalan. Saat menggunakan endpoint lokasi, seperti us-central1-pubsub.googleapis.com, penerbit dan pelanggan terhubung ke Pub/Sub di region yang ditentukan. Saat menjalankan penayang atau pelanggan di luar Google Cloud, sebaiknya gunakan endpoint lokasi untuk memastikan pesan mengalir di antara region yang diharapkan secara konsisten. Bagian selanjutnya ini membahas cara membuat topik dan langganan. Selain itu, cara menempatkan penayang dan pelanggan untuk mendukung berbagai jenis failover dan redundansi data juga dibahas.

Semantik failover default

Pertimbangkan sebuah kasus ketika hanya ada satu topik dan langganan. Penayang berada di wilayah Amerika Serikat dan Australia, dan pelanggan berada di Google Cloud wilayah Eropa dan Australia. Jika semua pelanggan memiliki kapasitas yang cukup untuk menerima pesan, alur pesan akan terlihat seperti ini:

P mewakili penerbit, sedangkan S mewakili pelanggan. Heksagon biru mewakili layanan Pub/Sub. Silinder mewakili tempat pesan disimpan (pesan selalu disimpan ke beberapa zona di region tempat pesan dipublikasikan). Pub/Sub lebih memilih mengirim pesan dalam region yang sama tempat pesan dipublikasikan saat pelanggan tersedia. Jika tidak, klien akan mengirimkan pesan ke region terdekat dengan pelanggan yang memiliki kapasitas. Oleh karena itu, seperti ditunjukkan pada gambar sebelumnya, pesan yang dipublikasikan di Amerika Serikat akan dikirim kepada pelanggan di Eropa dan pesan yang dipublikasikan di Australia tetap berada di Australia.

Bagian berikut membahas hal yang terjadi dalam berbagai skenario kegagalan.

Subscriber di Eropa tidak tersedia

Asumsikan pelanggan di Eropa ditolak atau sering mengalami error, dan tidak dapat mempertahankan koneksi ke Pub/Sub. Jika hal ini terjadi, layanan akan mulai mengirimkan pesan kepada pelanggan di Australia:

Pelanggan di Eropa dan Australia tidak tersedia

Jika semua pelanggan tidak tersedia, Pub/Sub akan menyimpan pesan hingga durasi retensi pesan yang dikonfigurasi.

Setelah pelanggan terhubung kembali, pesan akan dikirim kecuali pemadaman layanan berlangsung lebih lama dari durasi retensi pesan yang dikonfigurasi. Secara default, retensi pesan langganan ditetapkan ke 7 hari. Anda juga dapat mengonfigurasi retensi pesan pada suatu topik hingga 31 hari. Jangan memilih durasi retensi pesan yang lebih pendek dari pemadaman layanan maksimum yang Anda harapkan atau dapat Anda toleransi.

Pub/Sub tidak tersedia di Eropa

Meskipun jarang terjadi, Anda mungkin juga ingin menangani kasus saat Pub/Sub tidak tersedia. Ketidaktersediaan Pub/Sub berwujud sebagai periode error tak terduga yang berkepanjangan pada permintaan publikasi atau berlangganan, atau ketidakmampuan untuk mengirimkan pesan yang dipublikasikan kepada pelanggan. Misalnya, jika Pub/Sub tidak aktif di region Eropa, skenarionya akan terlihat sama seperti saat pelanggan sedang tidak aktif:

Perlu diperhatikan bahwa dalam kasus ini, pelanggan di Eropa tidak gagal ke region lain meskipun menggunakan endpoint global. Pub/Sub sengaja tidak mengalami kegagalan secara otomatis. Bayangkan pelanggan itu sendiri yang menyebabkan masalah tidak terduga di Pub/Sub yang mengakibatkan ketidaktersediaan. Masalah tersebut dianggap sebagai pemadaman layanan besar. Namun, cakupan dampak pemadaman layanan dapat tercakup di region tempat pelanggan terhubung. Jika layanan memungkinkan mereka untuk beralih ke region lain, pelanggan juga dapat menyebabkan ketidaktersediaan di sana, mengakibatkan kegagalan beruntun di seluruh layanan.

Penayang di Australia tidak tersedia

Jika penayang di satu wilayah tidak tersedia, pesan yang sudah dipublikasikan akan tetap dikirimkan ke pelanggan terdekat:

Pada akhirnya, semua pesan akan digunakan dan dikonfirmasi oleh subscriber. Saat mengirim pesan, Pub/Sub mencoba meminimalkan jarak jaringan. Oleh karena itu, pelanggan di wilayah di Australia dapat berhenti menerima pesan jika pelanggan di Eropa memiliki kapasitas yang cukup untuk menangani semua pesan yang dipublikasikan di Amerika Serikat.

Pub/Sub tidak tersedia di Amerika Serikat

Pub/Sub menulis pesan secara sinkron ke beberapa zona dalam satu region. Oleh karena itu, pemadaman layanan zona tidak cukup untuk mencegah pengiriman pesan; seluruh region harus tidak tersedia. Jika Pub/Sub tidak tersedia di region tempat penayang mengirim pesan, pesan di region tersebut mungkin tidak akan dikirim hingga layanan dipulihkan sepenuhnya:

Pesan pada akhirnya tetap terkirim (dengan asumsi periode retensi pesan belum berlalu), tertunda selama durasi pemadaman. Perlu diketahui bahwa serupa dengan pelanggan, penayang di Amerika Serikat juga tidak gagal beralih ke wilayah lain jika layanan mengalami kegagalan. Perilaku ini membantu mencegah kemungkinan kegagalan beruntun di seluruh region karena penayang atau pelanggan yang salah.

Isolasi

Detail semantik failover default memengaruhi isolasi data dan pengaruh ketidaktersediaan penayang, pelanggan, atau Pub/Sub itu sendiri terhadap alur pesan. Kasus penggunaan Anda mungkin memerlukan tingkat isolasi yang berbeda. Misalnya, Anda mungkin memerlukan pengiriman semua pesan intra-region.

Jika Anda tidak menginginkan isolasi, detail semantik failover default sudah cukup. Anda harus membuat satu topik, satu langganan, serta menempatkan penayang dan pelanggan di semua wilayah yang dipilih. Jika pelanggan tidak tersedia atau Pub/Sub tidak aktif di region tempat mereka terhubung, pengiriman akan gagal ke pelanggan di region lain.

Untuk isolasi regional, tempat data dijamin tidak keluar dari suatu region, buat topik dan langganan untuk menangani pesan di setiap region. Temukan penerbit dan pelanggan di setiap region tersebut dan minta mereka memublikasikan serta berlangganan topik dan langganan regional yang sesuai. Anda juga harus menggunakan endpoint regional untuk memastikan data hanya berpindah dalam region tersebut. Jika terjadi kegagalan penerbit, pelanggan, atau Pub/Sub di satu region, pengiriman pesan akan berhenti di region tersebut. Pengiriman pesan terkait topik dan langganan untuk wilayah lain tidak akan terpengaruh.

Terakhir, isolasi zona, tempat data dijamin tetap berada dalam satu zona, tidak dimungkinkan di Pub/Sub. Jika Anda mengharuskan setiap zona untuk bersifat independen, gunakan Pub/Sub Lite.

Failover dan redundansi yang dikontrol pelanggan

Semantik failover default Pub/Sub mungkin tidak sepenuhnya menjamin bahwa pesan selalu dapat mengalir dari penayang ke pelanggan jika terjadi pemadaman layanan di antaranya. Penghentian dapat terjadi di beberapa tempat, termasuk klien Anda, di layanan tempat penayang atau pelanggan Anda dijalankan, di jaringan, atau bahkan jarang terjadi di Pub/Sub itu sendiri. Jika ingin layanan Anda tangguh terhadap pemadaman layanan tersebut, Anda harus menerapkan redundansi Anda sendiri. Biasanya, redundansi ini mencakup penggunaan beberapa instance klien penayang dan pelanggan yang masing-masing menggunakan endpoint lokasi yang berbeda.

Anda mungkin menginginkan ketahanan terhadap dua cakupan dampak yang berbeda: zona atau regional. Berikut adalah opsi penyiapan untuk setiap opsi.

Ketahanan zona

Pub/Sub memiliki replikasi lintas zona bawaan. Anda tidak perlu melakukan langkah khusus apa pun untuk menangani pemadaman layanan satu zona yang memengaruhi layanan itu sendiri. Namun, agar klien atau jaringan Anda tahan terhadap pemadaman layanan, sebaiknya jalankan penayang dan pelanggan yang memiliki kapasitas yang memadai di beberapa zona dalam region tersebut. Jika satu zona tidak aktif, klien di zona lain dapat mengambil traffic dan memproses pesan. Praktik terbaiknya adalah tidak memublikasikan perubahan pada klien ini secara bersamaan sehingga jika muncul bug, zona lain yang tidak disentuh dapat terus memproses pesan.

Ketahanan regional

Agar tahan terhadap kegagalan regional, siapkan redundansi tambahan di penerbit dan pelanggan Anda. Anda dapat menjalankan penayang dan pelanggan di beberapa region untuk menangani kemungkinan pemadaman layanan pada klien tersebut atau di jaringan.

Jika Anda ingin melindungi dari potensi kegagalan Pub/Sub di suatu region, Anda harus memiliki mekanisme failover yang siap untuk mengatasi pemadaman layanan tersebut. Beberapa pendekatan yang mungkin digunakan adalah kompromi antara latensi pengiriman pesan menyeluruh dan biaya Anda.

Untuk meminimalkan latensi jika tidak mengkhawatirkan biaya, strategi terbaiknya adalah selalu memublikasikan dan berlangganan secara bersamaan di region yang berbeda. Pertama, pilih jumlah region tempat Anda ingin redundansi. Selanjutnya, meskipun tidak sepenuhnya diperlukan, Anda dapat menyiapkan topik dan langganan untuk setiap wilayah tersebut.

Setiap penayang membuat klien penayang sebanyak jumlah yang ada (satu untuk setiap wilayah) dan menggunakan endpoint lokasi yang berbeda untuk memastikan pesan diarahkan ke wilayah yang berbeda. Jika menggunakan topik terpisah, setiap klien penayang harus memublikasikan ke topik per wilayah yang sesuai. Untuk setiap pesan, penayang memanggil publikasi di setiap klien. Dengan publikasi redundan, Anda tidak perlu mencoba lagi publikasi jika ada yang gagal.

Demikian pula, setiap pelanggan membuat banyak klien pelanggan--satu untuk setiap wilayah--dan menggunakan endpoint lokasi untuk terhubung ke region yang berbeda. Jika menggunakan langganan yang berbeda untuk setiap region, setiap klien pelanggan harus menggunakan langganan yang sesuai. Perhatikan bahwa region yang digunakan untuk penayang dan pelanggan tidak harus sama. Pelanggan menerima pesan di ketiga langganan dan memprosesnya.

Penyiapan ini memiliki beberapa fitur dan persyaratan utama:

1. Gangguan satu region tidak memengaruhi pemrosesan pesan yang sudah dipublikasikan, maupun pesan yang dipublikasikan selama pemadaman. Karena pesan dipublikasikan ke beberapa region, pesan tersebut masih tersedia di region lain saat satu region tidak aktif. Selama pemadaman layanan, panggilan publikasi gagal di region yang terpengaruh, tetapi berhasil di region lain.
2. Latensi pemrosesan pesan tidak terpengaruh selama region mana pun tempat pesan mengalir tersedia.
3. Pemrosesan pesan harus idempoten. Karena setiap pesan akan dikirim beberapa kali, pemrosesan pesan harus tahan terhadap duplikat. Jika terjadi pemadaman layanan regional, beberapa duplikat tersebut mungkin muncul lebih lambat daripada saat pertama kali pesan dikirim. Duplikat tersebut kemungkinan berasal dari region lain yang tidak mengalami pemadaman layanan.

Menjalankan redundansi semacam ini akan memberikan ketahanan tertinggi terhadap segala jenis gangguan. Untuk layanan Google internal yang mengandalkan Pub/Sub dan memerlukan ketersediaan tertinggi, penyiapan ini lebih disarankan. Namun, penyiapan ini memiliki imbal balik di mana biaya pengiriman pesan harus dikalikan dengan jumlah region yang digunakan. Terdapat juga biaya tambahan penggunaan jaringan antar-regional untuk pesan yang harus dipindahkan lintas region.

Pendekatan lain terhadap redundansi adalah menggagalkan hanya ketika permintaan gagal atau pesan tidak mengalir dari penerbit ke pelanggan seperti yang diharapkan. Dalam skenario ini, Anda memiliki region utama tempat Anda mengarahkan penayang dan pelanggan melalui endpoint lokasi. Seperti sebelumnya, keduanya tidak harus berada di region yang sama. Anda juga memiliki region penggantian untuk penayang dan pelanggan yang digunakan saat region utama tidak tersedia.

Penayang hanya memublikasikan ke region utama (melalui endpoint lokasi) saat permintaannya berhasil dikirim. Setiap kali region ditetapkan sebagai nonaktif, penayang akan mulai memublikasikan ke region penggantian. Menentukan bahwa region sedang tidak aktif dan failover dapat dilakukan dengan dua cara. Hal ini dapat dilakukan secara manual, dan konfigurasi diperbarui secara dinamis di penayang. Penayang juga dapat memperbarui konfigurasi itu sendiri jika tingkat error dalam permintaan publikasi sudah cukup tinggi.

Pelanggan harus selalu terhubung ke region utama melalui endpoint lokasi. Anda dapat memutuskan bahwa pelanggan dapat menggunakan region penggantian dengan satu atau beberapa pemicu berikut:

1. Selalu berlangganan region penggantian. Dalam hal ini, pelanggan dapat mempertahankan koneksi ke region utama dan region penggantian sepanjang waktu. Region yang sama dapat digunakan untuk utama dan fallback untuk penayang dan pelanggan. Jika hal ini terjadi, pelanggan hanya boleh menerima pesan melalui region cadangan jika penayang mengalami kegagalan.
2. Deteksi dan alihkan pelanggan ke region penggantian secara manual melalui konfigurasi. Jika mendeteksi pemadaman layanan, Anda dapat beralih ke region penggantian, lalu kembali ke region utama saat pemadaman layanan mereda.
3. Gagal memperbaiki error subscriber. Jika permintaan pelanggan menampilkan error, Anda dapat menggunakan hal ini sebagai indikasi bahwa Anda harus gagal ke region penggantian. Perlu diperhatikan bahwa library klien Pub/Sub mencoba kembali streaming permintaan pull secara internal jika terjadi error sementara, sehingga Anda mungkin tidak dapat mendeteksi adanya error tak terduga dalam jangka waktu yang lama. Selain itu, rasio error pull streaming diperkirakan 100%, bahkan selama operasi normal.
4. Failover jika pelanggan mengalami waktu yang sangat lama tanpa menerima pesan. Dengan asumsi ada penerbitan pesan yang konsisten, pelanggan dapat selalu menerima pesan. Jika pengguna melewati jangka waktu yang lebih lama tanpa menerima pesan apa pun, mungkin ada masalah sisi berlangganan di Pub/Sub di region utama. Hal ini diperbaiki dengan kegagalan ke region penggantian.

Dari keempat opsi tersebut, yang pertama sudah ideal. Koneksi pelanggan tidak dikenai biaya apa pun jika tidak ada pesan yang mengalir. Satu-satunya biaya adalah jejak instance tambahan library klien pelanggan, yang dapat diabaikan. Anda juga harus memperhatikan jumlah koneksi pull streaming terbuka per kuota region.

Keuntungan dari model kedua ini adalah tidak ada pengganda dalam biaya Pub/Sub karena pesan hanya dipublikasikan satu kali. Namun, konsekuensinya adalah untuk jenis pemadaman layanan tertentu, pesan yang dipublikasikan sebelum pemadaman dimulai mungkin tidak tersedia hingga pemadaman layanan diselesaikan. Pesan yang disimpan di wilayah yang tidak tersedia mungkin tidak dapat dikirim ke pelanggan, di mana pun mereka terhubung. Pesan yang dipublikasikan selama pemadaman ke region pengganti dapat tersedia. Selain itu, mungkin ada periode ketidaktersediaan dengan peningkatan tingkat error untuk penerbit atau pelanggan. Hal ini bergantung pada metode yang digunakan untuk mendeteksi pemadaman layanan dan waktu untuk beralih ke region penggantian.

Apa pun opsi yang Anda pilih, perhatikan bagaimana opsi ini dapat berinteraksi dengan fitur Pub/Sub. Pengiriman yang dipesan dan tepat satu kali pengiriman menawarkan jaminan dalam suatu wilayah. Misalnya, jika Anda menggunakan teknik redundansi failover, pengiriman pesan hanya dijamin agar pesan dipublikasikan di region yang sama. Pelanggan dapat menerima pesan yang dipublikasikan ke region penggantian sebelum pesan dipublikasikan ke region utama, meskipun pesan tersebut dipublikasikan ke region utama terlebih dahulu.

Penyelaraskan penayang

Apa pun opsi failover yang Anda pilih, ada beberapa langkah penyesuaian tambahan yang ingin Anda lakukan dalam penayang itu sendiri. Menyesuaikan perilaku penayang akan memastikan performa yang optimal dalam kondisi pemuatan tinggi. Pengelompokan pesan adalah cara untuk mengorbankan latensi dengan mendapatkan biaya yang lebih rendah. Namun, ini bukan masalah keandalan, sehingga tidak dibahas di sini. Sebagai gantinya, fokuskan pada beberapa parameter lain yang berguna untuk menyesuaikan keandalan termasuk setelan percobaan ulang dan setelan kontrol alur.

Publikasi dapat gagal karena berbagai alasan, termasuk alasan sementara seperti ketidaktersediaan jaringan atau yang memerlukan intervensi pengguna seperti perubahan izin. Library klien Pub/Sub mencoba kembali error sementara menggunakan parameter yang ditentukan dalam setelan coba lagi. Setelan ini mengontrol perilaku backoff eksponensial pada percobaan ulang RPC publikasi yang gagal karena alasan sementara. Meskipun setelan default biasanya dapat berfungsi dengan baik dalam sebagian besar skenario, ada situasi saat Anda mungkin ingin menyesuaikan nilai ini.

Dua properti yang kemungkinan besar ingin Anda sesuaikan adalah waktu tunggu RPC awal dan total waktu tunggu. Waktu tunggu RPC awal adalah durasi RPC publikasi pertama diberikan untuk diselesaikan. Jika ada RPC yang gagal atau waktu tunggunya habis, RPC lain akan dicoba dengan waktu tunggu yang lebih lama hingga jumlah total permintaan atau total waktu tunggu terlampaui.

Waktu tunggu awal dapat disesuaikan jika penayang Anda dibatasi jaringan atau jauh dari pusat data Google Cloud terdekat yang menjalankan Pub/Sub. Batasan jaringan dapat berupa batasan pada throughput mesin tempat penayang berjalan atau dapat disebabkan oleh layanan lain yang berjalan di mesin yang sama dengan penggunaan intensif jaringan. Jika waktu tunggu terlalu singkat, RPC awal dapat gagal berulang kali, sehingga diperlukan lebih banyak upaya (dengan waktu tunggu yang lebih lama) agar berhasil dipublikasikan. Kebutuhan berulang untuk melakukan percobaan ulang meningkatkan latensi publikasi. Dalam situasi ini, meningkatkan waktu tunggu awal dapat mempercepat publikasi.

Jika koneksi jaringan tidak dapat diandalkan, meningkatkan total waktu tunggu serta waktu tunggu awal dapat membantu. Total waktu tunggu yang lebih lama akan memberi RPC publikasi lebih banyak waktu untuk menyelesaikan dengan sukses. Jika RPC publikasi terus-menerus gagal dengan error batas waktu terlampaui, pertimbangkan untuk menyesuaikan nilai ini.

Error batas waktu yang terus-menerus terlampaui pada publikasi juga dapat mengindikasikan perlunya penyesuaian kontrol alur penayang. Dengan setelan ini, Anda dapat memastikan bahwa penayang tahan terhadap lonjakan traffic masuk yang menghasilkan lebih banyak pesan untuk dikirim ke Pub/Sub. Peningkatan besar pada permintaan keluar dapat membebani CPU, memori, atau kapasitas jaringan penayang. Jika kelebihan beban, publikasi tidak dapat memproses permintaan atau respons publikasi sebelum waktu tunggu. Hal ini menghasilkan lebih banyak permintaan publikasi dan pada akhirnya, mencapai waktu tunggu total. Kontrol alur penayang membatasi jumlah pesan atau byte yang dapat diproses tanpa respons dari permintaan publikasi. Membatasi jumlah permintaan dengan cara ini akan menjaga penggunaan resource pada tingkat yang dapat dikelola, bahkan selama lonjakan. Bergantung pada cara penayang beroperasi, Anda dapat mengizinkan RPC publikasi berikutnya menunggu kapasitas dengan mengizinkan publikasi untuk memblokir permintaan lebih lanjut. Atau, Anda dapat melakukan push back ke pemanggil layanan dengan membuat kontrol alur menampilkan error saat kapasitas tercapai. Anda mengonfigurasi cara library klien penayang merespons dengan perilaku batas terlampaui.

Menyesuaikan subscriber

Penyesuaian pelanggan mungkin juga diperlukan untuk memastikan keandalannya beroperasi. Serupa dengan penerbit, Anda dapat menyesuaikan setelan kontrol alur pelanggan untuk memastikan mereka tidak kewalahan. Library klien pelanggan menggunakan streaming pull, tempat klien membuka aliran persisten ke server dan server mengirim pesan saat tersedia. Jika terjadi peningkatan besar dalam pesan yang dipublikasikan, pelanggan mungkin menerima lebih banyak pesan daripada yang dapat diprosesnya. Dengan menerapkan kontrol alur, jumlah pesan tidak dikonfirmasi yang belum dikonfirmasi kepada klien pada satu waktu akan dibatasi. Hal ini mengurangi jumlah pesan yang ditangani secara bersamaan dan menyebarkan pemrosesannya dalam jangka waktu yang lebih lama. Menyebarkan pemuatan memungkinkan pelanggan tetap berada dalam pembatasan resource yang memengaruhi pemrosesan pesan, yang dapat mengakibatkan efek beruntun yang berkembang menjadi ketidakmampuan untuk memproses pesan apa pun.

Kontrol alur saja sudah cukup jika Anda hanya memperkirakan lonjakan jumlah data yang akan diproses yang pada akhirnya surut. Jika traffic umumnya meningkat seiring waktu karena penggunaan yang lebih banyak, kontrol alur akan melindungi pelanggan. Namun, hal ini dapat mengakibatkan backlog yang terus menumpuk dan menyebabkan pesan tidak dapat dikirim sebelum durasi retensi pesan berlalu. Dalam kasus tersebut, Anda juga mungkin ingin menetapkan penskalaan otomatis untuk meningkatkan jumlah pelanggan sebagai respons terhadap pesan yang tidak diakui yang terus bertambah. Cara menyiapkannya bergantung pada platform komputasi yang digunakan untuk pelanggan. Misalnya, autoscaler Compute Engine memungkinkan Anda melakukan penskalaan berdasarkan metrik seperti jumlah pesan yang tidak terkirim. Dengan menggunakan penskalaan otomatis dan kontrol alur, Anda dapat memastikan bahwa pelanggan tahan terhadap lonjakan jangka pendek lainnya dalam throughput pesan dan pertumbuhan jangka panjang yang memerlukan lebih banyak daya komputasi. Pastikan Anda mengikuti Praktik terbaik untuk menggunakan metrik Pub/Sub sebagai sinyal penskalaan.

Menggunakan snapshot dan mencari deployment yang aman

Kehilangan pesan biasanya merupakan peristiwa bencana. Pub/Sub menawarkan pengiriman minimal satu kali untuk semua pesan yang dipublikasikan. Namun, pemrosesan pesan yang benar bergantung pada perilaku pelanggan. Jika pesan berhasil dikonfirmasi, Pub/Sub tidak akan mengirim ulang pesan tersebut. Oleh karena itu, bug yang diperkenalkan dalam kode pelanggan baru yang Anda deploy dan menerima pesan tanpa memprosesnya dengan benar dapat menyebabkan hilangnya pesan yang disebabkan oleh pelanggan. Pub/Sub menawarkan fitur snapshot dan pencarian, yang dapat membantu memastikan bahwa Anda memproses setiap pesan dengan benar, bahkan saat menghadapi bug pelanggan.

Pola untuk setiap deployment pelanggan harus sebagai berikut:

Jumlah waktu tunggu sebelum menentukan apakah pelanggan baru berfungsi dapat bervariasi, bergantung pada kasus penggunaan Anda. Satu-satunya cara untuk keluar dari alur langkah adalah jika pelanggan dianggap berhasil, dan pada saat itu snapshot dapat dihapus.

Penggunaan snapshot dan pencarian tidak dimaksudkan untuk menggantikan praktik terbaik dalam menjalankan software untuk pertama kalinya di lingkungan non-produksi dan deployment bertahap ke produksi. Kunci keamanan memberikan tingkat perlindungan tambahan untuk memastikan pemrosesan data yang andal. Konsekuensinya, mencari snapshot dapat mengakibatkan duplikasi pengiriman pesan yang berhasil diproses oleh pelanggan Anda. Namun, mengingat Pub/Sub memiliki semantik pengiriman minimal satu kali secara default, pelanggan Anda sudah tidak tahan terhadap pengiriman ulang pesan.