Panduan ini memberikan pemahaman dan gambaran umum tentang fitur keandalan Pub/Sub.
Mengapa Pub/Sub?
Sebagai paradigma pesan, publish-subscribe dirancang untuk memisahkan produsen pesan dari konsumen pesan tersebut. Daripada mengirim permintaan langsung ke konsumen dengan data, produsen memublikasikan data tersebut ke layanan Pub/Sub seperti Pub/Sub. Layanan ini secara asinkron mengirimkan pesan tersebut kepada konsumen yang tertarik dan telah berlangganan.
Hasilnya, layanan ini menyerap semua kerumitan dalam menemukan konsumen yang tertarik dengan data tersebut. Layanan ini juga mengelola kecepatan konsumen menerima data, berdasarkan kapasitasnya. Dengan pemisahan ini, produsen data dapat menulis pesan dalam skala besar dengan latensi rendah, terlepas dari perilaku konsumen.
Pub/Sub menawarkan pengiriman pesan yang sangat skalabel dan andal. Meskipun sebagian besar hal ini ditangani secara otomatis oleh layanan, 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 ini.
Isolasi
Secara default, Pub/Sub adalah layanan global: topik dan langganan tidak secara inheren terikat ke region tertentu, dan pesan mengalir dalam layanan Pub/Sub antar-region jika diperlukan. Saat menggunakan
endpoint global,
pubsub.googleapis.com, penerbit dan pelanggan terhubung ke
region terdekat jaringan tempat Pub/Sub berjalan. Saat menggunakan
endpoint regional,
seperti us-central1-pubsub.googleapis.com, atau
endpoint lokasi,
seperti pubsub.us-central1.rep.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 regional atau lokasi untuk memastikan pesan mengalir di antara
wilayah yang diharapkan secara konsisten.
Isolasi Regional
Untuk meminimalkan infrastruktur yang bergantung pada operasi publikasi dan langganan di luar satu region dan untuk memastikan bahwa semua data tetap terisolasi ke region tersebut, ikuti langkah-langkah berikut:
Buat topik per wilayah.
Meskipun namespace Pub/Sub bersifat global dan Anda tidak dapat mengikat topik dan langganan ke region tertentu, metadata untuk semua resource direplikasi ke penyimpanan data lokal dalam region. Oleh karena itu, setelah Anda membuat resource, konfigurasinya akan tersedia meskipun terjadi masalah di region lain. Perhatikan bahwa pembaruan pada konfigurasi topik atau langganan mungkin tidak langsung diterapkan jika terjadi gangguan.
Hindari penggunaan endpoint global.
Sebagai gantinya, gunakan endpoint regional jika tersedia dan endpoint lokasi jika endpoint regional tidak tersedia. Endpoint regional menawarkan isolasi regional yang lebih baik, tetapi belum tersedia di semua wilayah.
Gunakan kebijakan penyimpanan pesan dan tetapkan
enforceInTransitkeTrue.Jika Enforce in transit diaktifkan, data tidak akan pernah keluar dari region dan semua klien yang terhubung ke topik di region tertentu akan menyetel kebijakan penyimpanan pesan ke region tersebut.
Dengan topik yang dikonfigurasi dengan cara ini, Anda dapat memastikan bahwa semua operasi publikasi dan langganan menulis dan membaca data secara eksklusif dalam region. Jika terjadi kegagalan penayang, pelanggan, atau Pub/Sub di satu region, pengiriman pesan akan berhenti di region tersebut. Pengiriman pesan di topik dan langganan untuk wilayah lain tidak terpengaruh.
Jika Anda juga memerlukan operasi administratif dan namespace topik serta langganan Anda diisolasi secara regional, pertimbangkan untuk menggunakan Managed Service for Apache Kafka.
Failover
Jika tidak memerlukan isolasi regional, Anda dapat memanfaatkan kemampuan Pub/Sub untuk mengirimkan pesan secara efisien di beberapa region guna mencapai kemampuan failover multi-region. Bagian selanjutnya membahas cara membuat topik dan langganan serta menempatkan penerbit dan pelanggan untuk mendukung berbagai jenis failover dan redundansi data.
Semantik failover default
Pertimbangkan kasus saat ada satu topik dan langganan. Penerbit berada di wilayah Amerika Serikat dan Australia, dan pelanggan berada di wilayah Eropa dan Australia. Google Cloud Jika semua pelanggan memiliki kapasitas yang cukup untuk menerima pesan, alur pesan akan terlihat seperti ini:
P mewakili penayang, S mewakili subscriber. Segi enam biru mewakili layanan Pub/Sub. Silinder mewakili tempat pesan disimpan (pesan selalu dipertahankan ke beberapa zona di region tempat pesan dipublikasikan). Pub/Sub lebih memilih mengirim pesan dalam region yang sama tempat pesan tersebut dipublikasikan saat pelanggan tersedia. Jika tidak, pesan akan dikirim ke region 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 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 dikirimkan kecuali jika gangguan berlangsung lebih lama daripada durasi retensi pesan yang dikonfigurasi. Secara default, retensi pesan langganan ditetapkan ke 7 hari. Anda juga dapat mengonfigurasi retensi pesan pada topik hingga 31 hari. Jangan memilih durasi retensi pesan yang lebih pendek dari perkiraan pemadaman maksimum yang Anda harapkan atau bersedia Anda toleransi.
Pub/Sub tidak tersedia di Eropa
Meskipun jarang terjadi, Anda mungkin juga ingin menangani kasus saat Pub/Sub itu sendiri tidak tersedia. Pub/Sub tidak tersedia karena error yang tidak terduga dalam jangka waktu yang lama pada permintaan publikasikan atau berlangganan, atau tidak dapat mengirimkan pesan yang dipublikasikan ke pelanggan. Misalnya, jika Pub/Sub tidak berfungsi di region Eropa, maka skenarionya akan terlihat sama seperti saat pelanggan tidak berfungsi:
Perhatikan bahwa dalam kasus ini, pelanggan di Eropa tidak melakukan failover ke region lain, meskipun menggunakan endpoint global. Pub/Sub sengaja tidak melakukan failover secara otomatis. Bayangkan jika pelanggan itu sendiri yang menyebabkan masalah tak terduga di Pub/Sub yang mengakibatkan tidak tersedianya layanan. Masalah seperti ini dianggap sebagai gangguan berat. Namun, cakupan dampak pemadaman layanan dapat dibatasi pada region tempat pelanggan terhubung. Jika layanan mengizinkan failover ke region lain, pelanggan juga dapat menyebabkan ketidaktersediaan di sana, sehingga mengakibatkan kegagalan beruntun di seluruh layanan.
Penayang di Australia tidak tersedia
Jika penerbit di satu wilayah tidak tersedia, pesan yang sudah dipublikasikan akan tetap dikirimkan ke pelanggan terdekat:
Pada akhirnya, semua pesan akan digunakan dan dikonfirmasi oleh pelanggan. Saat mengirim pesan, Pub/Sub mencoba meminimalkan jarak jaringan. Oleh karena itu, pelanggan di wilayah 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 suatu region. Oleh karena itu, pemadaman zona tidak cukup untuk mencegah pengiriman pesan; seluruh region harus tidak tersedia. Jika Pub/Sub tidak tersedia di region tempat penerbit mengirim pesan, maka pesan di region tersebut mungkin tidak dikirim hingga layanan dipulihkan sepenuhnya:
Pesan pada akhirnya tetap dikirim (dengan asumsi periode retensi data pesan belum berakhir), yang tertunda selama durasi gangguan. Perhatikan bahwa seperti pelanggan, penayang di Amerika Serikat juga tidak melakukan failover ke wilayah lain saat layanan gagal. Perilaku ini membantu mencegah kemungkinan kegagalan beruntun di seluruh wilayah karena kesalahan penayang atau pelanggan.
Failover dan redundansi yang dikontrol pelanggan
Semantik failover default Pub/Sub mungkin tidak sepenuhnya menjamin bahwa pesan akan selalu mengalir dari penerbit ke pelanggan jika terjadi pemadaman di antara keduanya. Gangguan dapat terjadi di beberapa tempat yang berbeda, termasuk di 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 tetap berfungsi saat terjadi 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: zonal atau regional. Berikut opsi penyiapan untuk masing-masing opsi.
Ketahanan zona
Pub/Sub memiliki replikasi lintas zona bawaan. Anda tidak perlu melakukan langkah khusus untuk menangani gangguan zona tunggal yang memengaruhi layanan itu sendiri. Namun, agar 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 berfungsi, klien di zona lain dapat mengambil traffic dan memproses pesan. Sebaiknya jangan memublikasikan perubahan ke klien ini secara bersamaan agar jika ada bug, zona lain yang tidak tersentuh dapat terus memproses pesan.
Ketahanan regional
Agar tidak terpengaruh oleh kegagalan regional, siapkan redundansi tambahan di penayang dan pelanggan Anda. Anda dapat menjalankan penayang dan pelanggan di beberapa region untuk mengatasi kemungkinan gangguan pada klien atau jaringan tersebut.
Jika Anda ingin memiliki ketahanan terhadap potensi kegagalan Pub/Sub di suatu region, Anda harus menyiapkan mekanisme failover untuk mengatasi pemadaman tersebut. Kemungkinan pendekatan adalah kompromi antara latensi pengiriman pesan end-to-end dan biaya Anda.
Untuk meminimalkan latensi jika biaya tidak menjadi masalah, maka strategi terbaik 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, tidak perlu mencoba ulang publikasi jika salah satu publikasi gagal.
Demikian pula, setiap pelanggan membuat banyak klien pelanggan--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:
- Setiap pemadaman layanan satu region tidak memengaruhi pemrosesan pesan yang sudah dipublikasikan, maupun yang dipublikasikan selama pemadaman layanan. Karena pesan dipublikasikan ke beberapa wilayah, pesan tersebut masih tersedia di wilayah lain jika salah satu wilayah mengalami gangguan. Selama pemadaman layanan, panggilan publikasi gagal di region yang terpengaruh, tetapi berhasil di region lainnya.
- Latensi pemrosesan pesan tidak terpengaruh selama salah satu region yang dilalui pesan 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 tiba jauh lebih lambat daripada saat pesan pertama kali dikirim. Duplikat tersebut kemungkinan berasal dari region lain yang tidak mengalami gangguan.
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 kekurangan, yaitu biaya pengiriman pesan akan dikalikan dengan jumlah wilayah yang digunakan. Ada juga biaya tambahan penggunaan jaringan antar-region 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 yang mengarahkan penerbit dan pelanggan melalui endpoint lokasi. Seperti sebelumnya, region ini tidak harus sama. Anda juga akan memiliki region pengganti untuk penayang dan pelanggan yang digunakan saat region utama tidak tersedia.
Penayang hanya memublikasikan ke wilayah utama (melalui endpoint lokasi) saat permintaannya berhasil dikirim. Setiap kali wilayah ditentukan tidak berfungsi, penayang mulai memublikasikan ke wilayah penggantian. Penentuan bahwa region tidak berfungsi dan melakukan failover 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 mempertahankan koneksi ke region utama dan region penggantian setiap saat. Region yang sama dapat digunakan untuk primer dan penggantian bagi penayang dan pelanggan. Jika demikian, pelanggan hanya boleh menerima pesan melalui region cadangan jika penayang mengalami failover.
- Mendeteksi dan mengalihkan pelanggan secara manual ke region penggantian melalui konfigurasi. Jika mendeteksi pemadaman layanan, Anda dapat melakukan failover ke region penggantian dan kemudian kembali ke region utama saat pemadaman layanan telah mereda.
- Pengalihan saat terjadi error pada pelanggan. Jika permintaan pelanggan menampilkan error, Anda dapat menggunakan hal ini sebagai indikasi bahwa Anda harus melakukan failover ke region penggantian. Perhatikan bahwa library klien Pub/Sub mencoba kembali permintaan pull streaming secara internal saat terjadi error sementara, sehingga Anda mungkin tidak dapat mendeteksi bahwa ada error tak terduga dalam jangka waktu yang lama. Selain itu, tingkat error penarikan streaming diperkirakan 100%, bahkan selama operasi normal.
- Melakukan failover jika pelanggan tidak menerima pesan dalam waktu yang sangat lama dan tidak terduga. Dengan asumsi ada publikasi pesan yang konsisten, pelanggan dapat selalu menerima pesan. Jika tidak menerima pesan selama jangka waktu yang lama, mungkin ada masalah di sisi langganan di Pub/Sub di region utama. Hal ini diperbaiki dengan melakukan failover ke region pengganti.
Dari keempat opsi tersebut, opsi pertama adalah yang paling ideal. Koneksi pelanggan tidak dikenai biaya jika tidak ada pesan yang mengalir di dalamnya. Satu-satunya biaya adalah jejak instance tambahan library klien pelanggan, yang bisa diabaikan. Anda juga harus memperhatikan jumlah koneksi pull streaming terbuka per kuota region.
Keuntungan dari model kedua ini adalah tidak ada pengali dalam biaya Pub/Sub karena pesan hanya dipublikasikan satu kali. Namun, sebagai gantinya, untuk jenis pemadaman tertentu, pesan yang dipublikasikan sebelum pemadaman dimulai mungkin tidak tersedia hingga setelah pemadaman 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 wilayah penggantian dapat tersedia. Selain itu, mungkin ada periode tidak tersedia dengan peningkatan rasio error untuk penerbit atau pelanggan. Hal ini bergantung pada metode yang digunakan untuk mendeteksi gangguan dan waktu untuk melakukan failover ke region penggantian.
Apa pun opsi yang Anda pilih, perhatikan cara opsi ini dapat berinteraksi dengan fitur Pub/Sub. Baik pengiriman berurutan maupun pengiriman tepat satu kali menawarkan jaminan dalam suatu region. Misalnya, jika Anda menggunakan teknik redundansi failover, pengiriman pesan hanya dijamin berurutan untuk pesan yang dipublikasikan di region yang sama. Pelanggan dapat menerima pesan yang dipublikasikan ke region penggantian sebelum pesan yang 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 perlu Anda lakukan dalam penayang itu sendiri. Menyesuaikan perilaku penayang memastikan performa optimal saat beban tinggi. Mengelompokkan pesan adalah cara untuk menyeimbangkan latensi dengan biaya yang lebih rendah, tetapi tidak terlalu terkait dengan keandalan dan oleh karena itu 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 tersedianya 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 penundaan eksponensial pada percobaan 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 total waktu tunggu. Waktu tunggu RPC awal adalah durasi yang diberikan untuk menyelesaikan RPC publikasi pertama. Jika ada RPC yang gagal atau waktunya habis, RPC lain akan dicoba dengan waktu tunggu yang lebih lama hingga total jumlah permintaan atau total waktu tunggu terlampaui.
Waktu tunggu awal dapat disesuaikan jika penerbit 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 berupa hasil dari layanan lain yang berjalan di mesin yang sama yang menggunakan banyak jaringan. Jika waktu tunggu ditetapkan terlalu singkat, RPC awal dapat gagal berulang kali, sehingga diperlukan lebih banyak upaya (dengan waktu tunggu yang lebih lama) agar berhasil dipublikasikan. Kebutuhan untuk mencoba lagi yang berulang meningkatkan latensi publikasi. Dalam situasi ini, meningkatkan waktu tunggu awal dapat menghasilkan publikasi yang lebih cepat.
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 berhasil diselesaikan. Jika RPC publikasi terus gagal dengan error batas waktu terlampaui, pertimbangkan untuk menyesuaikan nilai ini.
Error batas waktu berkelanjutan yang terlampaui saat memublikasikan juga dapat menunjukkan perlunya menyesuaikan kontrol alur penayang. Setelan ini memungkinkan Anda memastikan bahwa penerbit Anda tahan terhadap lonjakan traffic masuk yang menghasilkan lebih banyak pesan untuk dikirim ke Pub/Sub. Peningkatan besar dalam permintaan keluar dapat membebani CPU, memori, atau kapasitas jaringan penayang. Jika publikasi 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 total waktu tunggu. Kontrol alur penayang membatasi jumlah pesan atau byte yang dapat tertunda tanpa respons dari permintaan publikasi. Membatasi jumlah permintaan dengan cara ini akan menjaga pemanfaatan 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 menolak panggilan ke 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 juga mungkin diperlukan untuk memastikan pelanggan beroperasi dengan andal. Serupa dengan penayang, Anda dapat menyesuaikan setelan kontrol alur pelanggan untuk memastikan mereka tidak kewalahan. Library klien subscriber menggunakan penarikan streaming, di mana klien membuka streaming persisten ke server dan server mengirim pesan saat pesan tersebut tersedia. Jika terjadi peningkatan besar pada pesan yang dipublikasikan, pelanggan mungkin menerima lebih banyak pesan daripada yang dapat diprosesnya. Dengan adanya kontrol alur, jumlah pesan yang belum dikonfirmasi yang belum diterima klien dalam satu waktu dibatasi. Hal ini mengurangi jumlah pesan yang ditangani secara bersamaan dan menyebarkan pemrosesannya selama jangka waktu yang lebih lama. Penyebaran beban memungkinkan pelanggan tetap berada di bawah batasan resource apa pun yang memengaruhi pemrosesan pesan, yang dapat mengakibatkan efek berjenjang 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 berkurang. Jika traffic umumnya meningkat seiring waktu karena lebih banyak penggunaan, kontrol alur melindungi pelanggan. Namun, hal ini dapat menyebabkan backlog yang terus menumpuk dan menyebabkan pesan tidak dapat dikirim sebelum durasi retensi pesan berakhir. Dalam kasus tersebut, Anda mungkin juga ingin menyetel penskalaan otomatis untuk meningkatkan jumlah pelanggan sebagai respons terhadap peningkatan jumlah pesan yang belum dikonfirmasi. Cara Anda menyiapkannya bergantung pada platform komputasi yang Anda gunakan untuk pelanggan. Misalnya, penskala otomatis 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 Anda tahan terhadap lonjakan throughput pesan jangka pendek lainnya 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 pencarian untuk deployment yang aman
Hilangnya pesan biasanya merupakan peristiwa yang sangat merugikan. Pub/Sub menawarkan pengiriman setidaknya sekali untuk semua pesan yang dipublikasikan. Namun, pemrosesan yang benar dari pesan ini bergantung pada perilaku pelanggan. Jika pesan berhasil dikonfirmasi, Pub/Sub tidak akan mengirim ulang pesan tersebut. Oleh karena itu, bug yang muncul dalam kode pelanggan baru yang Anda deploy yang mengonfirmasi pesan tanpa memprosesnya dengan benar dapat mengakibatkan hilangnya pesan yang disebabkan oleh pelanggan. Pub/Sub menawarkan fitur snapshot dan pencarian, yang dapat membantu Anda memastikan Anda memproses setiap pesan dengan benar, bahkan saat terjadi bug pelanggan.
Pola untuk setiap deployment pelanggan 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 pelanggan dianggap sedang bekerja, 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-prod dan deployment bertahap ke produksi. Komponen ini memberikan tingkat perlindungan tambahan untuk memastikan pemrosesan data yang andal. Sebagai gantinya, mencari snapshot dapat menyebabkan pengiriman pesan duplikat yang berhasil diproses oleh pelanggan Anda. Namun, mengingat Pub/Sub memiliki semantik pengiriman minimal satu kali secara default, pelanggan Anda sudah tahan terhadap pengiriman ulang pesan.