Panduan ini memberikan pemahaman dan gambaran keseluruhan tentang fitur keandalan Pub/Sub. Topik yang dibahas dalam dokumen ini mencakup:
- Mengapa Pub/Sub?
- Failover
- Menyesuaikan penayang
- Menyesuaikan subscriber
- Menggunakan snapshot dan mencari deployment yang aman
Mengapa Pub/Sub?
Sebagai paradigma pesan, publikasikan-langganan dirancang untuk memisahkan pembuat pesan dari konsumen pesan tersebut. Bukannya mengirim permintaan langsung kepada konsumen dengan data tersebut, produser 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, layanan ini menyerap semua seluk-beluk untuk menemukan konsumen yang tertarik dengan data tersebut. Layanan juga mengelola kecepatan penerimaan data 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 penerbit 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 terikat
dengan region tertentu, dan pesan mengalir dalam layanan Pub/Sub
antar-region saat diperlukan. Saat menggunakan endpoint global, pubsub.googleapis.com,
penayang dan pelanggan akan terhubung ke region terdekat jaringan tempat
Pub/Sub berjalan. Saat menggunakan endpoint lokasi, seperti us-central1-pubsub.googleapis.com, penayang dan pelanggan akan terhubung ke Pub/Sub di region yang ditentukan. Saat menjalankan penerbit atau pelanggan di luar Google Cloud, sebaiknya gunakan endpoint lokasi untuk memastikan pesan terkirim di antara region yang diharapkan secara konsisten. Bagian selanjutnya dari 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
Bayangkan jika ada satu topik dan langganan. Penerbit berada di wilayah Amerika Serikat dan Australia, serta 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 penerbit, S mewakili pelanggan. Heksagon biru mewakili layanan Pub/Sub. Tabung tersebut mewakili tempat pesan disimpan (pesan selalu disimpan ke beberapa zona di region tempat pesan dipublikasikan). Pub/Sub lebih suka mengirim pesan dalam region yang sama tempat pesan tersebut dipublikasikan, saat pelanggan tersedia. Jika tidak, server akan mengirimkan pesan ke region jaringan terdekat dengan pelanggan yang memiliki kapasitas. Oleh karena itu, seperti yang ditunjukkan pada gambar sebelumnya, pesan yang dipublikasikan di Amerika Serikat dikirimkan kepada pelanggan di Eropa dan pesan yang dipublikasikan di Australia tetap berada di Australia.
Bagian berikut membahas apa 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 ke 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 jika gangguan berlangsung lebih lama dari durasi retensi pesan yang dikonfigurasi. Secara default, retensi pesan langganan ditetapkan ke 7 hari. Anda juga dapat mengonfigurasi retensi pesan tentang suatu topik hingga 31 hari. Jangan memilih durasi retensi pesan yang lebih singkat dari pemadaman maksimum yang Anda harapkan atau yang ingin Anda toleransi.
Pub/Sub tidak tersedia di Eropa
Meskipun jarang terjadi, sebaiknya Anda juga menangani kasus ketika Pub/Sub tidak tersedia. Ketidaktersediaan Pub/Sub terwujud sebagai periode error tak terduga yang berkepanjangan pada permintaan publikasi atau berlangganan, atau ketidakmampuan mengirim pesan yang dipublikasikan kepada pelanggan. Misalnya, jika Pub/Sub berada di wilayah di Eropa, maka skenarionya akan terlihat sama seperti saat pelanggan menurun:
Perlu diperhatikan bahwa dalam kasus ini, pelanggan di Eropa tidak beralih ke region lain, meskipun menggunakan endpoint global. Pub/Sub sengaja tidak menggagalkan 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 mencakup region yang terhubung dengan pelanggan. Jika layanan tersebut mengizinkan mereka untuk berpindah ke region lain, pelanggan juga dapat menyebabkan ketidaktersediaan di sana, yang mengakibatkan kegagalan beruntun di seluruh layanan.
Penayang di Australia tidak tersedia
Jika penerbit di satu wilayah menjadi tidak tersedia, pesan yang sudah dipublikasikan akan tetap dikirimkan ke pelanggan terdekat:
Pada akhirnya, semua pesan dibaca dan diakui oleh pelanggan. Saat mengirim pesan, Pub/Sub mencoba meminimalkan jarak jaringan. Oleh karena itu, pelanggan di region 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 Cloud Pub/Sub menjadi tidak tersedia di region tempat penerbit mengirim pesan, pesan di region tersebut mungkin tidak akan dikirim hingga layanan dipulihkan sepenuhnya:
Pesan tetap terkirim (dengan asumsi periode retensi pesan belum berlalu), yang tertunda oleh durasi pemadaman layanan. Perlu diperhatikan bahwa seperti halnya pelanggan, penerbit di Amerika Serikat juga tidak beralih ke wilayah lain jika layanan gagal. Perilaku ini membantu mencegah kemungkinan kegagalan beruntun di seluruh region karena kesalahan penayang atau pelanggan.
Isolasi
Semantik failover default yang mendetail memengaruhi isolasi data dan pengaruh ketidaktersediaan penayang, pelanggan, atau Pub/Sub itu sendiri dapat memengaruhi alur pesan. Kasus penggunaan Anda mungkin memerlukan tingkat isolasi yang berbeda. Misalnya, Anda mungkin mewajibkan pengiriman semua pesan intra-region.
Jika Anda tidak menginginkan isolasi, semantik failover default yang dijelaskan 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 berada di wilayah tempat mereka terhubung, pengiriman akan gagal ke pelanggan di wilayah lain.
Untuk isolasi regional, ketika data dijamin tidak akan keluar dari suatu region, buat topik dan langganan untuk menangani pesan di setiap region. Temukan penerbit dan pelanggan di masing-masing wilayah tersebut, lalu minta mereka memublikasikan dan berlangganan topik regional dan langganan yang sesuai. Anda juga harus menggunakan endpoint regional untuk memastikan data hanya berpindah di dalam region tersebut. Jika terjadi kegagalan penerbit, pelanggan, atau Pub/Sub di satu region, pengiriman pesan akan dihentikan di region tersebut. Pengiriman pesan pada topik dan langganan untuk region lain tidak akan terpengaruh.
Terakhir, isolasi zona, ketika data dijamin tetap berada dalam satu zona, tidak mungkin dilakukan di Pub/Sub. Jika Anda mengharuskan zona individual 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 penerbit ke pelanggan jika terjadi pemadaman layanan di antaranya. Gangguan dapat terjadi di beberapa tempat, termasuk klien Anda, di layanan tempat penerbit atau pelanggan Anda dijalankan, di jaringan, atau bahkan jarang terjadi di Pub/Sub itu sendiri. Jika ingin layanan Anda tahan terhadap gangguan 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 akun.
Ketahanan zona
Pub/Sub memiliki replikasi lintas zona bawaan. Anda tidak perlu melakukan langkah khusus apa pun untuk menangani gangguan zona tunggal yang memengaruhi layanan itu sendiri. Namun, agar tahan 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, maka klien di zona lain dapat mengambil traffic dan memproses pesan. Praktik terbaiknya adalah tidak memublikasikan perubahan ke klien tersebut secara bersamaan sehingga jika bug muncul, zona lain yang tidak tersentuh dapat terus memproses pesan.
Ketahanan regional
Agar tahan terhadap kegagalan regional, siapkan redundansi tambahan pada penayang dan pelanggan Anda. Anda dapat menjalankan penayang dan pelanggan di beberapa region untuk menangani kemungkinan gangguan pada klien tersebut atau dalam jaringan.
Jika ingin tahan terhadap potensi kegagalan Pub/Sub di suatu region, Anda harus memiliki mekanisme failover yang siap untuk mengatasi pemadaman layanan tersebut. Pendekatan yang memungkinkan merupakan kompromi antara latensi pengiriman pesan menyeluruh dan biaya Anda.
Untuk meminimalkan latensi jika biaya tidak menjadi masalah, strategi terbaik adalah selalu memublikasikan dan berlangganan secara bersamaan di berbagai region. Pertama, pilih jumlah wilayah tempat Anda ingin redundansi. Berikutnya, meskipun tidak sepenuhnya diperlukan, Anda dapat menyiapkan topik dan langganan untuk setiap wilayah tersebut.
Setiap penayang membuat klien penayang sebanyak wilayah (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 redundan, Anda tidak perlu mencoba kembali publikasi jika ada satu publikasi yang gagal.
Demikian pula, setiap pelanggan membuat sejumlah klien pelanggan--satu untuk setiap region--dan menggunakan endpoint lokasi untuk terhubung ke region yang berbeda. Jika menggunakan langganan yang berbeda untuk setiap wilayah, setiap klien pelanggan harus menggunakan langganan yang sesuai. Perhatikan bahwa wilayah yang digunakan untuk penerbit 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, maupun pesan yang dipublikasikan selama penonaktifan. Karena pesan dipublikasikan ke beberapa region, pesan tersebut masih tersedia di region lain jika suatu region tidak aktif. Selama pemadaman layanan, panggilan publikasi gagal di region yang terpengaruh, tetapi berhasil di region lain.
- Latensi pemrosesan pesan tidak terpengaruh selama region tempat pesan mengalir tersedia.
- Pemrosesan pesan harus idempoten. Karena setiap pesan akan dikirimkan beberapa kali, pemrosesan pesan harus tahan terhadap duplikat. Jika terjadi pemadaman layanan regional, beberapa duplikat tersebut mungkin terjadi jauh lebih lambat daripada saat pertama kali pesan dikirimkan. Duplikat tersebut kemungkinan berasal dari wilayah lain yang tidak mengalami pemadaman.
Menjalankan dengan redundansi semacam ini memberikan ketahanan tertinggi terhadap segala jenis pemadaman. Untuk layanan Google internal yang mengandalkan Pub/Sub dan memerlukan ketersediaan tertinggi, penyiapan ini lebih disarankan. Namun, penyiapan ini memiliki konsekuensi dari perkalian biaya pengiriman pesan dengan jumlah wilayah yang digunakan. Ada juga biaya tambahan penggunaan jaringan antar-regional untuk pesan yang harus berpindah antar-region.
Pendekatan lain terhadap redundansi adalah hanya melakukan failover jika permintaan gagal atau pesan tidak mengalir dari penayang ke pelanggan seperti yang diharapkan. Dalam skenario ini, Anda memiliki wilayah utama tempat Anda mengarahkan penayang dan pelanggan melalui endpoint lokasi. Seperti sebelumnya, region ini tidak harus berada di region yang sama. Anda juga kemudian memiliki region penggantian untuk penayang dan pelanggan yang digunakan saat region utama tidak tersedia.
Penayang hanya memublikasikan ke region utama (melalui endpoint lokasi) jika permintaannya berhasil dikirim. Setiap kali region ditentukan sebagai tidak aktif, penayang akan mulai memublikasikan ke region penggantian. Menentukan bahwa region sedang tidak aktif dan gagal dapat dilakukan dengan dua cara. Tindakan ini dapat dilakukan dengan proses manual, dan konfigurasi diperbarui secara dinamis di penayang. Penayang juga dapat mengupdate konfigurasinya sendiri jika tingkat 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 region penggantian. Dalam hal ini, pelanggan mempertahankan koneksi ke region utama dan region penggantian setiap waktu. Region yang sama dapat digunakan untuk region utama dan penggantian untuk penayang dan pelanggan. Jika demikian, pelanggan hanya boleh menerima pesan melalui region pencadangan jika penayang gagal.
- Deteksi dan alihkan pelanggan secara manual ke region penggantian melalui konfigurasi. Jika mendeteksi pemadaman, Anda dapat beralih ke region penggantian, lalu kembali ke region utama saat penonaktifan telah mereda.
- Gagal mengatasi error subscriber. Jika permintaan pelanggan menampilkan error, Anda dapat menggunakannya sebagai indikasi bahwa Anda harus menggagalkan ke region penggantian. Perlu diperhatikan bahwa library klien Pub/Sub akan mencoba kembali streaming permintaan pull secara internal pada error sementara, sehingga Anda mungkin tidak dapat mendeteksi error yang tidak terduga dalam jangka panjang. Selain itu, rasio error pull streaming diperkirakan akan mencapai 100%, bahkan selama operasi normal.
- Melakukan failover jika pelanggan mengalami waktu yang lama tanpa menerima pesan. Dengan asumsi adanya publikasi pesan yang konsisten, pelanggan dapat selalu menerima pesan. Jika pengguna melewati jangka waktu yang lama tanpa menerima pesan apa pun, mungkin ada masalah sisi berlangganan di Pub/Sub di region utama. Hal ini diperbaiki dengan gagal ke region penggantian.
Dari keempat opsi tersebut, yang pertama ideal. Koneksi pelanggan tidak dikenai biaya jika tidak ada pesan yang mengalir di dalamnya. Satu-satunya biaya adalah di jejak instance tambahan library klien pelanggan, yang boleh diabaikan. Anda juga harus memperhatikan jumlah koneksi pull streaming yang terbuka per kuota region.
Keuntungan dari model kedua ini adalah bahwa tidak ada pengganda dalam biaya Pub/Sub karena pesan hanya dipublikasikan sekali. Namun, konsekuensinya adalah untuk jenis pemadaman tertentu, pesan yang dipublikasikan sebelum pemadaman dimulai mungkin tidak tersedia hingga setelah pemadaman diselesaikan. Pesan yang disimpan di region yang tidak tersedia mungkin tidak dapat dikirim ke pelanggan, di mana pun mereka terhubung. Pesan yang dipublikasikan selama gangguan di region penggantian 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 menggagalkan ke region penggantian.
Apa pun opsi yang Anda pilih, perhatikan bagaimana opsi ini dapat berinteraksi dengan fitur Pub/Sub. Pengiriman yang dipesan dan hanya setelah pengiriman menawarkan jaminan dalam suatu wilayah. Misalnya, jika Anda menggunakan teknik redundansi failover, pengiriman pesan hanya dijamin berfungsi 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 dipilih, ada beberapa langkah penyesuaian tambahan yang perlu Anda lakukan pada penayang. Menyesuaikan perilaku penayang akan memastikan performa yang optimal dalam beban tinggi. Pengelompokan pesan adalah cara untuk mengorbankan latensi demi mengurangi biaya, tetapi bukan merupakan masalah keandalan dan karenanya tidak dibahas di sini. Sebaliknya, 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 tidak tersedianya jaringan atau yang memerlukan intervensi pengguna seperti perubahan izin. Library klien Pub/Sub mencoba ulang error sementara menggunakan parameter yang ditentukan dalam setelan coba lagi. Setelan ini mengontrol perilaku backoff eksponensial saat percobaan ulang RPC publikasi yang gagal karena alasan sementara. Meskipun setelan default biasanya dapat berfungsi dengan baik dalam sebagian besar skenario, ada situasi yang mengharuskan Anda 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 waktu yang diberikan untuk menyelesaikan RPC publikasi pertama. Jika RPC gagal atau habis waktunya, RPC yang 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 yang menjalankan penayang, atau dapat disebabkan oleh layanan lain yang berjalan di mesin yang sama yang memproses banyak jaringan. Jika waktu tunggu ditetapkan terlalu singkat, RPC awal dapat gagal berulang kali, sehingga mengakibatkan lebih banyak upaya (dengan waktu tunggu yang lebih lama) yang diperlukan agar publikasi berhasil. Kebutuhan percobaan ulang yang berulang akan 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 memberi lebih banyak waktu bagi publikasi RPC agar berhasil. Jika publikasi RPC terus-menerus gagal dengan batas waktu error terlampaui, pertimbangkan untuk menyesuaikan nilai ini.
Batas waktu berkelanjutan melebihi error pada publikasi juga dapat mengindikasikan perlunya menyesuaikan kontrol alur penayang. Dengan setelan ini, Anda dapat memastikan bahwa penayang Anda tahan terhadap lonjakan traffic masuk yang menghasilkan lebih banyak pesan yang akan dikirim ke Pub/Sub. Peningkatan besar pada permintaan keluar dapat membebani CPU, memori, atau kapasitas jaringan penayang. Jika publikasi kelebihan beban, publikasi tidak dapat memproses permintaan atau respons publikasi sebelum waktu tunggunya habis. Hal ini mengakibatkan lebih banyak permintaan publikasi dan pada akhirnya, mencapai total waktu tunggu. Kontrol alur penayang membatasi jumlah pesan atau byte yang dapat diselesaikan 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 untuk menunggu kapasitas dengan mengizinkan publikasi untuk memblokir permintaan lebih lanjut. Atau, Anda dapat menolak pemanggil layanan dengan menggunakan kontrol alur untuk 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 penerbit, Anda dapat menyesuaikan setelan kontrol alur pelanggan untuk memastikan mereka tidak kewalahan. Library klien pelanggan menggunakan streaming pull, tempat klien membuka streaming persisten ke server dan server mengirim pesan saat tersedia. Jika jumlah pesan yang dipublikasikan sangat tinggi, pelanggan mungkin akan menerima lebih banyak pesan daripada yang dapat diproses. Dengan adanya kontrol alur, jumlah pesan yang tidak dikonfirmasi yang belum diterima 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 load out memungkinkan pelanggan untuk tetap berada di bawah batasan resource yang memengaruhi pemrosesan pesan, yang dapat mengakibatkan efek menurun yang berkembang menjadi ketidakmampuan untuk memproses pesan apa pun.
Kontrol alur saja sudah cukup jika Anda hanya mengharapkan lonjakan jumlah data yang pada akhirnya akan 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 dikirimkan sebelum durasi retensi pesan berlalu. Dalam kasus seperti itu, Anda juga dapat menyetel penskalaan otomatis untuk meningkatkan jumlah pelanggan sebagai respons terhadap bertambahnya jumlah pesan yang tidak dikonfirmasi. Cara menyiapkannya bergantung pada platform komputasi yang Anda gunakan untuk pelanggan. Misalnya, dengan penskalaan otomatis Compute Engine, Anda dapat melakukan penskalaan berdasarkan metrik seperti jumlah pesan yang tidak terkirim. Dengan penskalaan otomatis dan kontrol alur, Anda dapat memastikan pelanggan tahan terhadap lonjakan jangka pendek lainnya pada throughput pesan dan pertumbuhan jangka panjang yang memerlukan lebih banyak daya komputasi.
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 subscriber. 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 untuk mengonfirmasi pesan tanpa memprosesnya dengan benar dapat menyebabkan hilangnya pesan yang disebabkan oleh pelanggan. Pub/Sub menawarkan fitur snapshot and lookup, yang dapat membantu memastikan bahwa Anda memproses setiap pesan dengan benar, bahkan dalam menghadapi bug pelanggan.
Pola untuk setiap deployment pelanggan harus seperti berikut:
Lama waktu tunggu sebelum menentukan apakah pelanggan baru dapat berfungsi atau tidak, dapat bervariasi, tergantung kasus penggunaan Anda. Satu-satunya cara untuk keluar dari alur langkah adalah ketika pelanggan dianggap berfungsi, dan pada saat itu snapshot dapat dihapus.
Penggunaan snapshot dan pencarian tidak dimaksudkan untuk menggantikan praktik terbaik seputar menjalankan software pertama kali di lingkungan non-produksi dan deployment bertahap ke produksi. Lapisan data memberikan tingkat perlindungan tambahan untuk memastikan pemrosesan data yang andal. Konsekuensinya, mencari snapshot dapat menghasilkan duplikat pengiriman pesan yang berhasil diproses oleh pelanggan Anda. Namun, mengingat bahwa Pub/Sub memiliki semantik pengiriman setidaknya satu kali secara default, pelanggan Anda tidak akan terpengaruh oleh pengiriman ulang pesan.