Panduan ini memberikan pemahaman dan gambaran keseluruhan tentang fitur keandalan Pub/Sub. Topik yang dibahas dalam dokumen ini mencakup hal-hal berikut:
- Mengapa Pub/Sub?
- Failover
- Menyesuaikan penayang
- Menyesuaikan subscriber
- Menggunakan snapshot dan mencari deployment yang aman
Mengapa Pub/Sub?
Sebagai paradigma pesan, publish-subscribe dirancang untuk memisahkan produsen pesan dari konsumen pesan tersebut. Sebagai gantinya, produsen akan memublikasikan data tersebut ke layanan Pub/Sub seperti Pub/Sub, bukan mengirim permintaan langsung ke konsumen dengan data tersebut. Layanan ini secara asinkron mengirimkan pesan tersebut kepada konsumen yang tertarik dan telah berlangganan.
Hasilnya adalah layanan menyerap semua kerumitan dalam menemukan konsumen yang tertarik dengan data. Layanan ini juga mengelola kecepatan konsumen menerima data, berdasarkan kapasitasnya. Pemisahan ini memungkinkan produsen 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 ini
Failover
Pub/Sub adalah layanan global: topik dan langganan tidak secara inheren
terikat dengan region tertentu, dan pesan mengalir dalam layanan Pub/Sub di antara
region jika diperlukan. Saat menggunakan endpoint global, pubsub.googleapis.com,
penayang dan pelanggan terhubung ke region terdekat jaringan tempat
Pub/Sub berjalan. Saat menggunakan endpoint lokasi, seperti
us-central1-pubsub.googleapis.com, penayang 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 lainnya dalam bagian 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 kasus saat ada satu topik dan langganan. Penayang berada di wilayah Amerika Serikat dan Australia, dan pelanggan berada di region Google Cloud di Eropa dan Australia. Jika semua pelanggan memiliki kapasitas yang cukup untuk menerima pesan, alur pesan akan terlihat seperti ini:
P mewakili penayang, S mewakili subscriber. Heksagon biru mewakili layanan Pub/Sub. Silinder mewakili tempat penyimpanan pesan (pesan selalu dipertahankan ke beberapa zona di region tempat pesan dipublikasikan). Pub/Sub lebih memilih untuk mengirim pesan dalam region yang sama dengan tempat pesan dipublikasikan saat pelanggan tersedia. Jika tidak, pesan akan dikirim ke region terdekat jaringan dengan pelanggan yang memiliki kapasitas. Oleh karena itu, seperti yang ditunjukkan pada gambar sebelumnya, pesan yang dipublikasikan di Amerika Serikat dikirim ke 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
Anggap pelanggan di Eropa dinonaktifkan, 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:
Subscriber 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 jika penghentian 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 di topik hingga 31 hari. Jangan memilih durasi retensi pesan yang lebih singkat dari pemadaman layanan maksimum yang Anda perkirakan atau yang bersedia Anda tolerir.
Pub/Sub tidak tersedia di Eropa
Meskipun jarang terjadi, Anda mungkin juga ingin menangani kasus saat Pub/Sub sendiri tidak tersedia. Ketidaktersediaan Pub/Sub akan terlihat sebagai periode error yang tidak terduga dalam permintaan publikasi atau langganan yang berkepanjangan, atau ketidakmampuan untuk mengirimkan pesan yang dipublikasikan kepada pelanggan. Misalnya, jika Pub/Sub tidak berfungsi di wilayah Eropa, skenarionya akan terlihat sama seperti saat subscriber tidak berfungsi:
Perhatikan bahwa dalam hal ini, pelanggan di Eropa tidak dialihkan ke region lain, meskipun menggunakan endpoint global. Pub/Sub sengaja tidak melakukan pengalihan secara otomatis. Bayangkan pelanggan itu sendiri yang menyebabkan masalah tak terduga di Pub/Sub yang mengakibatkan ketersediaan tidak ada. Masalah tersebut diperlakukan sebagai pemadaman layanan besar. Namun, cakupan dampak pemadaman layanan dapat dibatasi ke wilayah tempat pelanggan terhubung. Jika layanan mengizinkan mereka untuk gagal beralih ke wilayah lain, pelanggan juga dapat menyebabkan ketidaktersediaan di sana, sehingga menyebabkan kegagalan berurutan di seluruh layanan.
Penayang di Australia tidak tersedia
Jika penayang di satu region tidak tersedia, pesan yang sudah dipublikasikan 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 wilayah harus tidak tersedia. Jika Cloud Pub/Sub tidak tersedia di region tempat penayang mengirim pesan, pesan di region tersebut mungkin tidak dikirim hingga layanan dipulihkan sepenuhnya:
Pesan pada akhirnya tetap dikirim (dengan asumsi periode retensi pesan belum berlalu), tertunda oleh durasi pemadaman. Perhatikan bahwa mirip dengan pelanggan, penayang di Amerika Serikat juga tidak dialihkan ke wilayah lain saat layanan gagal. Perilaku ini membantu mencegah kemungkinan kegagalan beruntun di seluruh wilayah karena penayang atau pelanggan yang rusak.
Isolasi
Semantik failover default yang dijelaskan memengaruhi isolasi data dan cara ketersediaan penayang, pelanggan, atau Pub/Sub itu sendiri dapat memengaruhi alur pesan. Kasus penggunaan Anda mungkin memerlukan tingkat isolasi yang berbeda. Misalnya, Anda mungkin memerlukan pengiriman intra-wilayah untuk semua pesan.
Jika Anda tidak menginginkan isolasi, semantik failover default yang dijelaskan sudah memadai. Anda harus membuat satu topik, satu langganan, dan menempatkan penayang dan pelanggan di semua region yang dipilih. Jika pelanggan tidak tersedia atau Pub/Sub tidak berfungsi di region tempat mereka terhubung, pengiriman akan gagal dan beralih ke pelanggan di region lain.
Untuk isolasi regional, tempat data dijamin tidak akan keluar dari region, buat topik dan langganan untuk menangani pesan di setiap region. Temukan penayang dan pelanggan di setiap wilayah tersebut, lalu minta mereka untuk memublikasikan dan berlangganan topik dan langganan regional yang sesuai. Anda juga harus menggunakan endpoint regional untuk memastikan data hanya dipindahkan dalam region. Jika terjadi kegagalan penayang, pelanggan, atau Pub/Sub di satu region, pengiriman pesan akan berhenti di region tersebut. Pengiriman pesan tentang topik dan langganan untuk wilayah lain tidak akan terpengaruh.
Terakhir, isolasi zona, yang menjamin data tetap berada dalam satu zona, tidak dapat dilakukan di Pub/Sub. Jika Anda mewajibkan 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 di mana saja di antara keduanya. Gangguan dapat terjadi di beberapa tempat, termasuk klien Anda, di layanan tempat penayang atau pelanggan Anda berjalan, di jaringan, atau bahkan jarang terjadi di Pub/Sub itu sendiri. Jika Anda ingin layanan Anda tahan terhadap pemadaman tersebut, Anda harus menerapkan redundansi Anda sendiri. Biasanya, redundansi ini mencakup penggunaan beberapa instance klien penayang dan pelanggan, dengan setiap instance menggunakan endpoint lokasi yang berbeda.
Anda mungkin menginginkan ketahanan terhadap dua cakupan dampak yang berbeda: zonal atau regional. Berikut adalah opsi penyiapan untuk masing-masing opsi.
Ketahanan zona
Pub/Sub memiliki replikasi lintas zona bawaan. Anda tidak perlu mengambil langkah khusus untuk menangani pemadaman layanan satu zona yang memengaruhi layanan itu sendiri. Namun, untuk memiliki ketahanan terhadap pemadaman layanan untuk klien atau jaringan Anda, sebaiknya jalankan penayang dan pelanggan dengan kapasitas yang memadai di beberapa zona dalam region. 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 bug muncul, zona lain yang tidak tersentuh dapat terus memproses pesan.
Ketahanan regional
Agar tidak terganggu oleh kegagalan regional, siapkan redundansi tambahan di penayang dan pelanggan Anda. Anda dapat menjalankan penayang dan pelanggan di beberapa region untuk mengatasi kemungkinan penghentian layanan di klien tersebut atau dalam jaringan.
Jika ingin tahan terhadap potensi kegagalan Pub/Sub di suatu region, Anda harus memiliki mekanisme failover yang siap menangani pemadaman layanan tersebut. Kemungkinan pendekatannya adalah kompromi antara latensi pengiriman pesan end-to-end dan biaya Anda.
Untuk meminimalkan latensi jika biaya tidak menjadi masalah, strategi terbaiknya adalah selalu memublikasikan dan berlangganan secara bersamaan di berbagai region. Pertama, pilih jumlah region tempat Anda menginginkan redundansi. Selanjutnya, meskipun tidak mutlak diperlukan, Anda dapat menyiapkan topik dan langganan untuk setiap wilayah tersebut.
Setiap penayang membuat klien penayang sebanyak jumlah region (satu untuk setiap region) dan menggunakan endpoint lokasi yang berbeda untuk memastikan pesan diarahkan ke region 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 yang redundan, Anda tidak perlu mencoba ulang publikasi jika salah satunya gagal.
Demikian pula, setiap pelanggan membuat banyak klien pelanggan tersebut--satu untuk setiap wilayah--dan menggunakan endpoint lokasi untuk terhubung ke wilayah yang berbeda. Jika menggunakan langganan yang berbeda untuk setiap wilayah, setiap klien pelanggan harus menggunakan langganan yang sesuai. Perhatikan bahwa wilayah 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:
- Pemadaman layanan satu region tidak memengaruhi pemrosesan pesan yang sudah dipublikasikan, atau yang dipublikasikan selama pemadaman layanan. Karena pesan dipublikasikan ke beberapa region, pesan tersebut masih tersedia di region lain jika satu region tidak berfungsi. Selama pemadaman layanan, panggilan publikasi gagal di region yang terpengaruh, tetapi berhasil di region lainnya.
- Latensi pemrosesan pesan tidak terpengaruh selama region tempat pesan mengalir tersedia.
- 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 akan datang jauh lebih lambat dari saat pertama kali pesan dikirim. Duplikat tersebut kemungkinan berasal dari region lain yang tidak mengalami pemadaman layanan.
Berjalan dengan jenis redundansi ini memberikan ketahanan tertinggi terhadap semua jenis penghentian. Untuk layanan Google internal yang mengandalkan Pub/Sub dan memerlukan ketersediaan tertinggi, penyiapan ini lebih disarankan. Namun, penyiapan ini memiliki konsekuensi berupa penggandaan biaya pengiriman pesan dengan jumlah region yang digunakan. Ada juga biaya tambahan penggunaan jaringan antar-regional untuk pesan yang harus berpindah antar-region.
Pendekatan lain untuk redundansi adalah hanya melakukan failover saat permintaan gagal atau pesan tidak mengalir dari penayang ke pelanggan seperti yang diharapkan. Dalam skenario ini, Anda memiliki region utama tempat Anda mengarahkan penayang dan pelanggan melalui endpoint lokasi. Seperti sebelumnya, region ini tidak harus sama. Anda juga akan 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 wilayah ditentukan tidak aktif, penayang akan mulai memublikasikan ke wilayah penggantian. Menentukan bahwa region tidak aktif dan gagal dapat dilakukan dengan dua cara. Hal ini dapat dilakukan dengan proses manual, dan konfigurasi diperbarui secara dinamis di penayang. Penayang juga dapat memperbarui konfigurasi sendiri jika rasio error dalam permintaan publikasi 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:
- Selalu berlangganan ke wilayah penggantian. Dalam hal ini, pelanggan selalu mempertahankan koneksi ke region utama dan region penggantian. Region yang sama dapat digunakan untuk region utama dan penggantian bagi penayang dan pelanggan. Jika demikian, pelanggan hanya boleh menerima pesan melalui region cadangan jika penayang mengalami kegagalan.
- Mendeteksi dan mengalihkan pelanggan ke region penggantian secara manual melalui konfigurasi. Jika mendeteksi pemadaman layanan, Anda dapat melakukan failover ke region penggantian, lalu kembali ke region utama saat pemadaman layanan mereda.
- Gagal saat terjadi error pelanggan. Jika permintaan pelanggan menampilkan error, Anda dapat menggunakannya sebagai indikasi bahwa Anda harus melakukan failover ke region penggantian. Perhatikan bahwa library klien Pub/Sub mencoba lagi streaming permintaan pull secara internal pada error sementara, sehingga Anda mungkin tidak dapat mendeteksi bahwa ada periode error tidak terduga yang lama. Selain itu, tingkat error pull streaming diperkirakan mencapai 100%, bahkan selama operasi normal.
- Gagal jika pelanggan mengalami waktu yang tidak terduga tanpa menerima pesan. Dengan asumsi bahwa ada publikasi pesan yang konsisten, pelanggan selalu dapat menerima pesan. Jika selama jangka waktu yang lama, pesan tidak diterima, mungkin ada masalah sisi langganan di Pub/Sub di region utama. Hal ini diperbaiki dengan melakukan failover ke region penggantian.
Dari keempat opsi tersebut, opsi pertama adalah yang paling ideal. Koneksi pelanggan tidak dikenai biaya apa pun jika tidak ada pesan yang mengalir di dalamnya. 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 model kedua ini adalah tidak ada pengganda dalam biaya Pub/Sub karena pesan hanya dipublikasikan satu kali. Namun, komprominya adalah untuk jenis pemadaman layanan tertentu, pesan yang dipublikasikan sebelum pemadaman layanan dimulai mungkin tidak tersedia hingga setelah pemadaman layanan diselesaikan. Pesan yang disimpan di wilayah yang tidak tersedia mungkin tidak dapat dikirimkan ke pelanggan, terlepas dari tempat mereka terhubung. Pesan yang dipublikasikan selama pemadaman layanan ke region penggantian dapat tersedia. Selain itu, mungkin ada periode tidak tersedia dengan peningkatan rasio error untuk penayang atau pelanggan. Hal ini bergantung pada metode yang digunakan untuk mendeteksi pemadaman layanan dan waktu untuk melakukan failover ke region penggantian.
Apa pun opsi yang Anda pilih, perhatikan bagaimana hal ini dapat berinteraksi dengan fitur Pub/Sub. Pengiriman terurut dan pengiriman tepat satu kali menawarkan jaminan dalam suatu wilayah. Misalnya, jika Anda menggunakan teknik redundansi failover, pengiriman pesan hanya dijamin untuk pesan yang dipublikasikan di region yang sama. Pelanggan dapat menerima pesan yang dipublikasikan ke region penggantian sebelum pesan dipublikasikan ke region utama, meskipun pesan dipublikasikan ke region utama terlebih dahulu.
Menyesuaikan penayang
Apa pun opsi failover yang Anda pilih, ada beberapa langkah penyesuaian tambahan yang ingin Anda lakukan di dalam penayang itu sendiri. Menyesuaikan perilaku penayang akan memastikan performa yang optimal dalam beban tinggi. Pemrosesan pesan secara massal adalah cara untuk mengorbankan latensi demi mengurangi biaya, tetapi tidak terlalu menjadi masalah keandalan, sehingga tidak dibahas di sini. Sebagai gantinya, fokuslah 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 tidak adanya jaringan atau alasan yang memerlukan intervensi pengguna seperti perubahan izin. Library klien Pub/Sub mencoba lagi error sementara menggunakan parameter yang ditentukan dalam setelan percobaan ulang. Setelan ini mengontrol perilaku backoff eksponensial saat mencoba ulang RPC publikasi yang gagal karena alasan sementara. Meskipun setelan default biasanya 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 waktu tunggu total. Waktu tunggu RPC awal adalah waktu yang diberikan untuk menyelesaikan RPC publikasi pertama. Jika RPC gagal atau waktu tunggu habis, RPC lain akan dicoba dengan waktu tunggu yang lebih lama hingga jumlah total permintaan atau waktu tunggu total 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 throughput mesin tempat penayang berjalan atau dapat disebabkan oleh layanan lain yang berjalan di mesin yang sama dan intensif jaringan. Dengan waktu tunggu yang ditetapkan 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 percobaan ulang akan meningkatkan latensi publikasi. Dalam situasi ini, meningkatkan waktu tunggu awal dapat menghasilkan publikasi yang lebih cepat.
Jika koneksi jaringan tidak dapat diandalkan, meningkatkan waktu tunggu total serta waktu tunggu awal dapat membantu. Peningkatan waktu tunggu total memberi RPC publikasi lebih banyak waktu untuk berhasil diselesaikan. Jika RPC publikasi terus gagal dengan error batas waktu terlampaui, pertimbangkan untuk menyesuaikan nilai ini.
Error batas waktu terlampaui berkelanjutan saat publikasi juga dapat menunjukkan perlunya menyesuaikan kontrol alur penayang. Setelan ini memungkinkan Anda memastikan bahwa penayang Anda tahan terhadap lonjakan traffic masuk yang menghasilkan lebih banyak pesan untuk dikirim ke Pub/Sub. Peningkatan permintaan keluar yang besar dapat membebani CPU, memori, atau kapasitas jaringan penayang. Jika kelebihan beban, publikasi tidak dapat memproses permintaan atau respons publikasi sebelum waktu tunggu habis. Hal ini menghasilkan lebih banyak permintaan publikasi dan pada akhirnya, mencapai waktu tunggu total. Kontrol alur penayang membatasi jumlah pesan atau byte yang dapat tertunda 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 kerja penayang, Anda dapat mengizinkan RPC publikasi berikutnya menunggu kapasitas dengan mengizinkan publikasi memblokir permintaan lebih lanjut. Atau, Anda dapat mendorong kembali 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 memastikannya beroperasi dengan andal. Serupa dengan penayang, Anda dapat menyesuaikan setelan kontrol alur pelanggan untuk memastikan mereka tidak kewalahan. Library klien subscriber menggunakan pull streaming, dengan klien membuka streaming persisten ke server dan server mengirim pesan saat pesan tersedia. Jika terjadi peningkatan pesan yang dipublikasikan secara besar-besaran, subscriber mungkin menerima lebih banyak pesan daripada yang dapat diproses. Dengan kontrol alur yang diterapkan, jumlah pesan yang belum dikonfirmasi yang tertunda untuk klien pada satu waktu akan dibatasi. Hal ini mengurangi jumlah pesan yang ditangani secara bersamaan dan memperluas pemrosesannya selama jangka waktu yang lebih lama. Dengan menyebarkan beban, pelanggan dapat tetap berada dalam batasan resource yang memengaruhi pemrosesan pesan, yang dapat menyebabkan efek kaskade yang berkembang menjadi ketidakmampuan untuk memproses pesan apa pun.
Kontrol alur saja sudah cukup jika Anda hanya mengharapkan lonjakan jumlah data yang akan diproses yang pada akhirnya akan mereda. Jika traffic umumnya meningkat seiring waktu karena lebih banyak penggunaan, kontrol alur akan melindungi pelanggan. Namun, hal ini dapat mengakibatkan backlog yang terus bertambah dan menyebabkan pesan tidak dapat dikirim sebelum durasi retensi pesan berakhir. Dalam kasus tersebut, Anda juga dapat menetapkan penskalaan otomatis untuk menampilkan lebih banyak subscriber sebagai respons terhadap meningkatnya jumlah pesan yang tidak dikonfirmasi. Cara menyiapkannya bergantung pada platform komputasi yang Anda gunakan untuk pelanggan. Misalnya, pengoptimal ukuran Compute Engine memungkinkan Anda menskalakan berdasarkan metrik seperti jumlah pesan yang tidak terkirim. Dengan menggunakan penskalaan otomatis dan kontrol alur, Anda dapat memastikan bahwa pelanggan Anda tahan terhadap lonjakan jangka pendek lainnya dalam throughput pesan dan pertumbuhan jangka panjang yang memerlukan lebih banyak daya komputasi.
Menggunakan snapshot dan mencari deployment yang aman
Kehilangan pesan biasanya merupakan peristiwa yang sangat buruk. Pub/Sub menawarkan pengiriman setidaknya satu kali untuk semua pesan yang dipublikasikan. Namun, pemrosesan pesan ini 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 yang mengonfirmasi pesan tanpa memprosesnya dengan benar dapat menyebabkan hilangnya pesan yang disebabkan oleh pelanggan. Pub/Sub menawarkan fitur snapshot dan seek, yang dapat membantu Anda memastikan bahwa Anda memproses setiap pesan dengan benar, bahkan saat menghadapi bug pelanggan.
Pola untuk setiap deployment subscriber harus sebagai berikut:
Jumlah waktu yang harus ditunggu sebelum menentukan apakah pelanggan baru berfungsi dapat bervariasi berdasarkan kasus penggunaan Anda. Satu-satunya cara untuk keluar dari alur langkah adalah saat subscriber dianggap berfungsi, pada saat itu snapshot dapat dihapus.
Penggunaan snapshot dan pencarian tidak dimaksudkan untuk menggantikan praktik terbaik seputar software yang pertama kali berjalan di lingkungan non-prod dan deployment bertahap ke produksi. Lapisan ini memberikan tingkat perlindungan tambahan untuk memastikan pemrosesan data yang andal. Namun, hal ini dapat menyebabkan pengiriman pesan duplikat yang berhasil diproses oleh pelanggan Anda. Namun, mengingat bahwa Pub/Sub memiliki semantik pengiriman setidaknya satu kali secara default, pelanggan Anda sudah tahan terhadap pengiriman ulang pesan.