Panduan ini memberikan pemahaman dan gambaran keseluruhan tentang fitur keandalan Pub/Sub.
Mengapa Pub/Sub?
Sebagai paradigma pesan, publikasi-langganan dirancang untuk memisahkan produsen pesan dari konsumen pesan tersebut. Alih-alih produsen mengirimkan permintaan langsung ke konsumen dengan data, mereka 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 penerimaan data oleh konsumen, berdasarkan kapasitas mereka. 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 tersebut.
Isolasi
Secara default, Pub/Sub adalah layanan global: topik dan langganan tidak secara inheren 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 terhubung ke region terdekat dalam jaringan tempat Pub/Sub berjalan. Saat menggunakan
endpoint regional,
seperti pubsub.us-central1.rep.googleapis.com, atau
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 regional atau lokasi untuk memastikan pesan mengalir di antara region yang diharapkan secara konsisten.
Isolasi Regional
Untuk meminimalkan infrastruktur yang menjadi tempat bergantung operasi publikasi dan berlangganan di luar satu region dan untuk memastikan bahwa semua data tetap terisolasi di region tersebut, ikuti langkah-langkah berikut:
Buat topik per region.
Meskipun namespace Pub/Sub bersifat global dan Anda tidak dapat mengaitkan topik dan langganan ke region tertentu, metadata untuk semua resource direplikasi ke penyimpanan data lokal dalam region tersebut. Oleh karena itu, setelah Anda membuat resource, konfigurasinya akan tersedia bahkan jika terjadi masalah di region lain. Perhatikan bahwa update pada konfigurasi topik atau langganan mungkin tidak langsung diterapkan jika terjadi pemadaman layanan.
Hindari penggunaan endpoint global.
Sebagai gantinya, gunakan endpoint regional jika tersedia dan endpoint lokasi jika endpoint regional tidak tersedia. Endpoint regional menawarkan lebih banyak isolasi regional, tetapi belum tersedia di semua region.
Gunakan kebijakan penyimpanan pesan dan tetapkan
enforceInTransitkeTrue.Dengan Enforce in transit, data tidak akan pernah keluar dari region dan semua klien yang terhubung ke topik di region tertentu, menetapkan kebijakan penyimpanan pesan ke region tersebut.
Dengan topik yang dikonfigurasi seperti ini, Anda dapat memastikan bahwa semua operasi publikasi dan langganan menulis dan membaca data secara eksklusif dalam region tersebut. Jika terjadi kegagalan penayang, pelanggan, atau Pub/Sub di satu region, pengiriman pesan akan berhenti di region tersebut. Pengiriman pesan pada topik dan langganan untuk region lain tidak terpengaruh.
Jika Anda memerlukan operasi administratif dan namespace topik serta langganan Anda juga diisolasi secara regional, pertimbangkan untuk menggunakan Managed Service untuk 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 penayang dan pelanggan untuk mendukung berbagai jenis failover dan redundansi data.
Semantik failover default
Pertimbangkan kasus saat ada satu topik dan langganan. Penayang berada di wilayah Amerika Serikat dan Australia, dan pelanggan berada di wilayah Google Cloud Eropa dan Australia. Jika semua pelanggan memiliki kapasitas yang cukup untuk menerima pesan, alur pesan akan terlihat seperti ini:
P mewakili penayang, S mewakili pelanggan. Segi enam biru mewakili layanan Pub/Sub. Silinder mewakili tempat penyimpanan pesan (pesan selalu disimpan 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 jaringan terdekat 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 apa yang terjadi dalam berbagai skenario kegagalan.
Pelanggan 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 jika 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 topik hingga 31 hari. Jangan memilih durasi retensi pesan yang lebih singkat daripada pemadaman maksimum yang Anda perkirakan atau bersedia Anda toleransi.
Pub/Sub tidak tersedia di Eropa
Meskipun jarang terjadi, Anda mungkin juga ingin menangani kasus saat Pub/Sub sendiri tidak tersedia. Ketidaktersediaan Pub/Sub terlihat sebagai periode error yang tidak terduga yang berkepanjangan pada permintaan publikasi atau langganan, atau ketidakmampuan untuk mengirimkan pesan yang dipublikasikan kepada pelanggan. Misalnya, jika Pub/Sub tidak aktif di region di Eropa, skenarionya akan terlihat sama seperti saat pelanggan tidak aktif:
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 ketidaktersediaan. Masalah seperti ini dianggap sebagai pemadaman layanan besar. Namun, cakupan dampak pemadaman layanan dapat dibatasi pada region tempat pelanggan terhubung. Jika layanan mengizinkan mereka untuk melakukan failover ke region lain, pelanggan juga dapat menyebabkan ketidaktersediaan di sana, sehingga mengakibatkan kegagalan beruntun di seluruh layanan.
Penayang di Australia tidak tersedia
Jika penayang di satu region tidak tersedia, pesan yang sudah dipublikasikan akan tetap dikirim ke pelanggan terdekat:
Pada akhirnya, semua pesan digunakan dan dikonfirmasi 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 Pub/Sub tidak tersedia di region tempat penayang mengirim pesan, pesan di region tersebut mungkin tidak akan dikirimkan hingga layanan dipulihkan sepenuhnya:
Pesan pada akhirnya tetap dikirim (dengan asumsi periode retensi pesan belum berlalu), tertunda selama durasi pemadaman layanan. Perhatikan bahwa mirip dengan pelanggan, penayang di Amerika Serikat juga tidak melakukan failover ke region lain saat layanan gagal. Perilaku ini membantu mencegah kemungkinan kegagalan beruntun di seluruh region karena penayang atau pelanggan yang rusak.
Failover dan redundansi yang dikontrol pelanggan
Semantik failover default Pub/Sub mungkin tidak sepenuhnya menjamin bahwa pesan dapat selalu mengalir dari penayang ke pelanggan jika terjadi pemadaman layanan di mana pun di antaranya. Pemadaman layanan dapat terjadi di beberapa tempat berbeda, termasuk klien Anda, dalam layanan tempat penayang atau pelanggan Anda berjalan, dalam jaringan, atau bahkan jarang terjadi di Pub/Sub itu sendiri. Jika Anda memerlukan layanan yang tahan 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 masing-masing opsi.
Ketahanan zona
Pub/Sub memiliki replikasi lintas zona bawaan. Anda tidak perlu melakukan langkah khusus untuk menangani pemadaman layanan satu zona 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 aktif, klien di zona lain dapat mengambil traffic dan memproses pesan. Praktik terbaiknya adalah tidak memublikasikan perubahan pada klien ini secara bersamaan, sehingga jika terjadi bug, 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 menangani kemungkinan pemadaman layanan di klien tersebut atau dalam jaringan.
Jika Anda ingin tahan terhadap potensi kegagalan Pub/Sub di suatu region, Anda harus memiliki mekanisme failover yang siap menangani pemadaman layanan tersebut. Pendekatan yang mungkin dilakukan adalah kompromi antara latensi pengiriman pesan menyeluruh 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 region 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 region yang sesuai. Untuk setiap pesan, penayang memanggil publikasi di setiap klien. Dengan publikasi redundan, Anda tidak perlu mencoba ulang publikasi jika salah satunya gagal.
Demikian pula, setiap pelanggan membuat banyak klien pelanggan--satu untuk setiap region--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:
- Pemadaman layanan satu region tidak memengaruhi pemrosesan pesan yang telah dipublikasikan, maupun yang dipublikasikan selama pemadaman layanan. Karena pesan dipublikasikan ke beberapa region, pesan tersebut masih tersedia di region lain jika salah satu region tidak aktif. Selama pemadaman layanan, panggilan publikasi gagal di region yang terpengaruh, tetapi berhasil di region lain.
- Latensi pemrosesan pesan tidak terpengaruh selama salah satu region tempat pesan mengalir tersedia.
- Pemrosesan pesan harus bersifat idempoten. Karena setiap pesan akan dikirim beberapa kali, pemrosesan pesan harus tahan terhadap duplikat. Jika terjadi pemadaman layanan regional, beberapa duplikat tersebut mungkin muncul jauh lebih lambat daripada saat pesan pertama kali dikirim. Duplikat tersebut kemungkinan berasal dari region lain yang tidak mengalami pemadaman layanan.
Menjalankan dengan jenis redundansi ini memberikan ketahanan tertinggi terhadap segala jenis pemadaman layanan. Untuk layanan Google internal yang mengandalkan Pub/Sub dan memerlukan ketersediaan tertinggi, penyiapan ini lebih disarankan. Namun, penyiapan ini memiliki konsekuensi, yaitu mengalikan biaya pengiriman pesan dengan jumlah region 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 menjadi tujuan pengarahan penayang dan pelanggan melalui endpoint lokasi. Seperti sebelumnya, region ini tidak harus 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 ditentukan tidak aktif, penayang akan mulai memublikasikan ke region penggantian. Menentukan bahwa region tidak aktif dan melakukan failover dapat dilakukan dengan dua cara. Hal ini dapat dilakukan melalui proses manual, dan konfigurasinya 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 region penggantian. Dalam hal ini, pelanggan mempertahankan koneksi ke region utama dan region penggantian setiap saat. 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 gagal beralih.
- Mendeteksi dan mengalihkan pelanggan secara manual ke region penggantian melalui konfigurasi. Jika mendeteksi pemadaman layanan, Anda dapat melakukan failover ke region penggantian, lalu kembali ke region utama setelah pemadaman layanan mereda.
- Failover pada 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 kembali permintaan pull streaming secara internal pada error sementara, sehingga Anda mungkin tidak dapat mendeteksi bahwa ada periode error yang tidak terduga dalam waktu lama. Selain itu, rasio error streaming pull diperkirakan akan mencapai 100%, bahkan selama operasi normal.
- Gagal jika pelanggan mengalami waktu yang sangat lama tanpa menerima pesan. Dengan asumsi bahwa pesan dipublikasikan secara konsisten, pelanggan selalu dapat menerima pesan. Jika pelanggan tidak menerima pesan apa pun dalam jangka waktu yang lama, mungkin ada masalah di sisi pelanggan di Pub/Sub di region utama. Hal ini diperbaiki dengan melakukan failover ke region penggantian.
Dari keempat opsi, opsi pertama adalah yang 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 dapat 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 sekali. Namun, konsekuensinya adalah untuk jenis pemadaman layanan tertentu, pesan yang dipublikasikan sebelum pemadaman layanan dimulai mungkin tidak tersedia hingga pemadaman layanan diselesaikan. Pesan yang disimpan di region yang tidak tersedia mungkin tidak dapat dikirim ke pelanggan, di mana pun mereka terhubung. Pesan yang dipublikasikan selama pemadaman layanan ke region penggantian dapat tersedia. Selain itu, mungkin ada periode tidak tersedianya layanan 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 opsi ini dapat berinteraksi dengan fitur Pub/Sub. Pengiriman sesuai urutan dan pengiriman tepat satu kali menawarkan jaminannya dalam satu 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 pengganti sebelum pesan dipublikasikan ke region utama, meskipun pesan tersebut dipublikasikan ke region utama terlebih dahulu.
Penayang fine-tuning
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 beban tinggi. Pengelompokan pesan 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 disesuaikan demi keandalan, termasuk setelan percobaan ulang dan setelan kontrol alur.
Publikasi dapat gagal karena berbagai alasan, termasuk alasan sementara seperti jaringan yang tidak tersedia atau alasan yang memerlukan intervensi pengguna seperti perubahan izin. Library klien Pub/Sub mencoba ulang error sementara menggunakan parameter yang ditentukan dalam setelan percobaan ulang. 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 waktu tunggu total. Waktu tunggu RPC awal adalah durasi 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 total waktu tunggu terlampaui.
Waktu tunggu awal dapat disesuaikan jika penayang Anda memiliki keterbatasan jaringan atau berada 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 yang menggunakan jaringan secara intensif. Jika waktu tunggu ditetapkan terlalu singkat, RPC awal dapat gagal berulang kali, sehingga memerlukan lebih banyak upaya (dengan waktu tunggu yang lebih lama) agar berhasil dipublikasikan. Kebutuhan berulang untuk percobaan ulang 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 memberi RPC publikasi lebih banyak waktu untuk diselesaikan dengan berhasil. Jika RPC publikasi terus-menerus gagal dengan error batas waktu terlampaui, pertimbangkan untuk menyesuaikan nilai ini.
Error batas waktu terlampaui yang terus-menerus saat publikasi juga dapat mengindikasikan 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 besar dalam permintaan keluar 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 total waktu tunggu. Kontrol alur penayang membatasi jumlah pesan atau byte yang dapat beredar tanpa respons dari permintaan publikasi. Membatasi jumlah permintaan dengan cara ini akan menjaga pemakaian 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 pemanggil layanan dengan meminta kontrol alur menampilkan error saat kapasitas tercapai. Anda mengonfigurasi cara library klien penayang merespons dengan perilaku batas terlampaui.
Subscriber fine-tuning
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 pelanggan menggunakan streaming pull, di mana klien membuka streaming 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 diproses. Dengan adanya kontrol alur, jumlah pesan yang belum dikonfirmasi yang belum terselesaikan ke 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 beban memungkinkan pelanggan tetap berada di bawah batasan 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 akan berkurang. 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 seperti ini, Anda mungkin juga ingin menyetel penskalaan otomatis untuk meningkatkan jumlah pelanggan sebagai respons terhadap meningkatnya jumlah pesan yang belum dikonfirmasi. Cara menyiapkannya bergantung pada platform komputasi yang Anda gunakan untuk pelanggan. Misalnya, autoscaler 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. Pastikan Anda mengikuti Praktik terbaik untuk menggunakan metrik Pub/Sub sebagai sinyal penskalaan.
Menggunakan metrik backlog versi regional, bukan versi global
Saat Anda memantau backlog langganan, mengonfigurasi kebijakan pemberitahuan, atau
melakukan penskalaan otomatis pelanggan, Pub/Sub menawarkan dua versi untuk setiap
metrik backlog. Pastikan Anda menggunakan versi dengan akhiran by_region:
Jangan gunakan versi global metrik ini
(subscription/num_undelivered_messages
dan
subscription/oldest_unacked_message_age)
jika Anda ingin pemantauan, pemberitahuan, dan penskalaan otomatis Anda tahan terhadap
pemadaman layanan di satu region. Versi global metrik ini memerlukan penghitungan backlog di semua region yang diketahui memiliki pesan, yang berarti ketidaktersediaan di satu region akan menyebabkan kesenjangan data. Sebaliknya, versi by_region dari metrik menghitung dan melaporkan backlog per region. Jika backlog tidak dapat dihitung untuk satu region, metrik akan tetap melaporkan nilai untuk region lain.
Menggunakan snapshot dan pencarian untuk deployment yang aman
Kehilangan pesan biasanya merupakan peristiwa yang fatal. 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 mengirimkannya kembali. 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 seek, yang dapat membantu Anda 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 berdasarkan kasus penggunaan Anda. Satu-satunya cara untuk keluar dari alur langkah-langkah ini adalah saat pelanggan dianggap berfungsi, yang 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-produksi dan deployment bertahap ke produksi. Komponen ini memberikan tingkat perlindungan tambahan untuk memastikan pemrosesan data yang andal. Konsekuensinya adalah pencarian ke snapshot dapat mengakibatkan pengiriman duplikat pesan yang berhasil diproses oleh pelanggan Anda. Namun, mengingat bahwa Pub/Sub memiliki semantik pengiriman setidaknya sekali secara default, pelanggan Anda sudah tahan terhadap pengiriman ulang pesan.