Pub/Sub adalah layanan pesan asinkron yang dirancang agar sangat andal dan skalabel. Layanan ini dibuat di atas komponen infrastruktur Google inti yang diandalkan oleh banyak produk Google selama lebih dari satu dekade. Produk Google termasuk Google Ads, Penelusuran, dan Gmail menggunakan infrastruktur ini untuk mengirim lebih dari 500 juta pesan per detik, dengan total lebih dari 1 TB/dtk data. Artikel ini menjelaskan fitur desain penting yang memungkinkan Pub/Sub menyediakan jenis skala ini dengan andal.
Menilai Performa Layanan Pesan
Layanan pesan seperti Pub/Sub dapat dinilai berdasarkan performanya dalam tiga aspek: skalabilitas, ketersediaan, dan latensi. Ketiga faktor ini sering kali bertentangan satu sama lain, sehingga salah satunya harus dikompromikan untuk memperbaiki aspek yang lain.
Istilah "skalabilitas", "ketersediaan", dan "latensi" dapat merujuk ke berbagai properti sistem, jadi bagian berikut menjelaskan definisinya di Pub/Sub.
Skalabilitas
Layanan skalabel harus dapat menangani peningkatan beban tanpa penurunan latensi atau ketersediaan yang kentara. "Beban" dapat merujuk ke berbagai dimensi penggunaan di Pub/Sub:
Jumlah topik
Jumlah penayang
Jumlah langganan
Jumlah subscriber
Jumlah pesan
Ukuran pesan
Tingkat pesan (throughput) yang dipublikasikan atau dipakai
Ukuran backlog pada langganan tertentu
Ketersediaan
Dalam sistem terdistribusi, jenis dan tingkat keparahan masalah bisa sangat bervariasi. Ketersediaan sistem diukur pada seberapa baik sistem menangani berbagai jenis masalah, mengalami kegagalan dengan cara yang tidak terlihat oleh pengguna akhir. Kegagalan dapat terjadi pada hardware (mis., drive disk tidak berfungsi atau masalah konektivitas jaringan), di software, dan karena beban. Kegagalan akibat beban dapat terjadi saat peningkatan traffic secara tiba-tiba dalam layanan (atau komponen software lainnya yang berjalan pada hardware yang sama atau dalam dependensi software) menyebabkan kelangkaan resource. Ketersediaan juga dapat menurun karena kesalahan manusia, yaitu ketika membuat kesalahan dalam membangun atau men-deploy software atau konfigurasi.
Latensi
Latensi adalah ukuran performa suatu sistem berdasarkan waktu. Sebuah layanan biasanya ingin meminimalkan latensi jika memungkinkan. Untuk Pub/Sub, dua metrik latensi yang paling penting adalah:
Jumlah waktu yang diperlukan untuk mengonfirmasi pesan yang dipublikasikan.
Jumlah waktu yang diperlukan untuk mengirim pesan yang dipublikasikan kepada pelanggan.
Arsitektur Dasar Pub/Sub
Bagian ini menjelaskan desain Pub/Sub untuk menunjukkan cara layanan mencapai skalabilitas dan latensi rendahnya dengan tetap mempertahankan ketersediaan. Sistem ini dirancang agar dapat diskalakan secara horizontal, dengan peningkatan jumlah topik, langganan, atau pesan dapat ditangani dengan meningkatkan jumlah instance server yang berjalan.
Server Pub/Sub berjalan di semua region Google Cloud di seluruh dunia. Hal ini memungkinkan layanan untuk menawarkan akses data global yang cepat, sekaligus memberi pengguna kontrol terhadap lokasi penyimpanan pesan. Cloud Pub/Sub menawarkan akses data global di klien penayang dan pelanggan tersebut, yang tidak mengetahui lokasi server yang terhubung dengan mereka atau cara layanan tersebut merutekan data.
Mekanisme load balancing Pub/Sub mengarahkan traffic penayang ke pusat data Google Cloud terdekat tempat penyimpanan data diizinkan, seperti yang dijelaskan di bagian Pembatasan Lokasi Resource pada konsol IAM & admin. Artinya, penayang di beberapa region dapat memublikasikan pesan ke satu topik dengan latensi rendah. Setiap pesan disimpan di satu region. Namun, topik mungkin memiliki pesan yang disimpan di banyak region. Saat klien pelanggan meminta pesan yang dipublikasikan ke topik ini, klien tersebut terhubung ke server terdekat yang menggabungkan data dari semua pesan yang dipublikasikan ke topik untuk dikirimkan ke klien.
Pub/Sub dibagi menjadi dua bagian utama: bidang data, yang menangani perpindahan pesan antara penerbit dan pelanggan, dan bidang kontrol, yang menangani penetapan penayang dan pelanggan ke server pada bidang data. Server di bidang data disebut penerusan, dan server di bidang kontrol disebut router. Saat penerbit dan pelanggan terhubung ke forwarder yang ditetapkan, mereka tidak memerlukan informasi apa pun dari router (selama penerusan tersebut tetap dapat diakses). Oleh karena itu, Anda dapat mengupgrade bidang kontrol Pub/Sub tanpa memengaruhi klien yang telah terhubung dan mengirim atau menerima pesan.
Bidang Kontrol
Bidang kontrol Pub/Sub mendistribusikan klien ke penerus dengan cara yang memberikan skalabilitas, ketersediaan, dan latensi rendah untuk semua klien. Setiap penerusan mampu melayani klien untuk topik atau langganan apa pun. Ketika klien terhubung ke Pub/Sub, router memutuskan pusat data yang harus terhubung dengan klien berdasarkan jarak jaringan terpendek, yaitu ukuran latensi pada koneksi antara dua titik. Dalam pusat data tertentu, router mencoba mendistribusikan beban keseluruhan ke seluruh kumpulan forwarder yang tersedia. Router harus menyeimbangkan dua tujuan yang berbeda saat melakukan penetapan ini: (a) keseragaman beban (yaitu, idealnya setiap forwarder memiliki muatan yang sama); dan (b) stabilitas penugasan (yaitu, idealnya perubahan beban atau perubahan dalam kumpulan forwarder yang tersedia mengubah jumlah terkecil dari tugas yang ada). Router menggunakan varian hashing konsisten yang dikembangkan oleh Tim Riset Google untuk mencapai keseimbangan yang tepat antara konsistensi dan keseragaman. {i>Router<i} memberi klien daftar urut penerusan yang dapat dipertimbangkan untuk disambungkan. Daftar yang diurutkan ini dapat berubah berdasarkan ketersediaan penerusan dan bentuk beban dari klien.
Klien mengambil daftar penerusan ini dan terhubung ke satu atau beberapa dari mereka. Klien lebih memilih untuk menghubungkan ke forwarder yang paling direkomendasikan oleh router, tetapi juga mempertimbangkan kegagalan yang terjadi, misalnya, klien mungkin memutuskan untuk mencoba forwarder di pusat data yang berbeda jika beberapa upaya untuk melakukan percobaan ke penerusan terdekat gagal. Untuk memisahkan klien Pub/Sub dari detail penerapan ini, ada proxy layanan antara klien dan penerusan yang melakukan pengoptimalan koneksi ini atas nama klien.
Pesawat Data - {i>The Life of a Message<i}
Bidang data menerima pesan dari penayang dan mengirimkannya ke klien. Mungkin cara terbaik untuk memahami bidang data Pub/Sub adalah dengan melihat aktivitas pesan, dari saat diterima oleh layanan hingga tidak ada lagi di layanan. Mari kita lihat langkah-langkah pemrosesan pesan. Untuk tujuan bagian ini, kami mengasumsikan bahwa topik yang memublikasikan pesan memiliki setidaknya satu langganan yang dilampirkan. Secara umum, pesan melalui langkah-langkah berikut:
Penayang mengirim pesan.
Pesan ditulis ke penyimpanan.
Pub/Sub mengirim konfirmasi kepada penerbit bahwa pesan telah diterima dan menjamin pengirimannya ke semua langganan yang terpasang.
Pada saat yang sama dengan menulis pesan ke penyimpanan, Pub/Sub mengirimkannya kepada pelanggan.
Pelanggan mengirimkan konfirmasi ke Pub/Sub bahwa mereka telah memproses pesan.
Setelah setidaknya satu pelanggan untuk setiap langganan mengonfirmasi pesannya, Pub/Sub akan menghapus pesan tersebut dari penyimpanan.
Pertama, penerbit mengirim pesan mengenai topik ke Pub/Sub. Pesan ini dienkripsi oleh lapisan proxy dan dikirim ke penerus publikasi, yang merupakan penerus yang terhubung dengan penerbit. Untuk memastikan pengiriman, pesan segera ditulis ke penyimpanan. Forwarder awalnya menulis pesan ke N cluster (N adalah angka ganjil) dan menganggap pesan dipertahankan ketika telah ditulis setidaknya ⌈N/2⌉. Setelah pesan dipertahankan, penerus publikasi mengonfirmasi penerimaan pesan kembali kepada penerbit, dan pada saat itu Pub/Sub menjamin bahwa pesan akan dikirim ke semua langganan yang terlampir. Proses latar belakang secara teratur menulis pesan apa pun yang tidak ada di semua cluster N ke cluster yang kehilangan pesan.
Dalam setiap cluster, pesan ditulis ke M independen disk (di mana M adalah angka ganjil), yang memerlukan data untuk berada pada disk ⌈M/2⌉ sebelum dianggap dipertahankan dalam cluster itu. Secara total, setiap pesan yang diterbitkan akan ditulis ke setidaknya ⌈ M/2 ⌉ disk independen dalam cluster ⌈ N/2 ⌉ sebelum dianggap dipertahankan dan akhirnya akan direplikasi ke disk N*M.
Penerusan publikasi memiliki daftar semua langganan yang terkait dengan suatu topik. Anda bertanggung jawab untuk mempertahankan pesan yang dipublikasikan dan metadata yang menjelaskan pesan mana yang telah dikonfirmasi oleh setiap langganan. Kumpulan pesan yang diterima dan disimpan oleh penerus publikasi untuk topik tertentu, beserta pelacakan pesan yang dikonfirmasi, disebut "sumber publikasi pesan". Bergantung pada persyaratan throughput untuk topik, satu penayang dapat mengirim pesannya ke beberapa penerusan publikasi dan menyimpan pesan di beberapa sumber pesan publikasi. Penayang lain untuk topik yang sama juga dapat mengirim pesan ke penerus publikasi yang berbeda. Setiap pesan hanya dikirim ke satu penerus publikasi. Pub/Sub secara dinamis menyesuaikan jumlah penerus publikasi yang menerima pesan untuk topik tertentu saat throughput berubah.
Pelanggan menerima pesan dengan terhubung ke penerusan yang berlangganan, yang meneruskan pesan yang diteruskan ke pelanggan dari penerbit. “Menghubungkan” dalam kasus pelanggan pull berarti mengeluarkan permintaan pull. “Menghubungkan” untuk pelanggan push berarti memiliki endpoint push yang terdaftar dengan Pub/Sub. Setelah langganan dibuat, dijamin bahwa setiap pesan yang dipublikasikan setelah periode tersebut akan dikirimkan ke langganan tersebut, yang kami sebut jaminan titik sinkronisasi.
Setiap penerusan langganan harus meminta pesan dari penerus penerusan yang telah memublikasikan sumber pesan untuk topik tersebut. Seperti penerbit, pelanggan dapat terhubung ke lebih dari satu penerusan langganan untuk menerima pesan. Dengan begitu, tidak semua penerus langganan perlu mengetahui atau menerima pesan dari setiap sumber pesan publikasi untuk suatu topik--properti penting bagi Pub/Sub agar dapat melakukan penskalaan secara horizontal. Berdasarkan throughput pesan yang dikirimkan ke pelanggan, Pub/Sub secara dinamis menyesuaikan jumlah penerusan langganan yang digunakan pelanggan untuk menerima pesan untuk topik tertentu saat throughput berubah.
Penerusan langganan membuat permintaan ke satu atau beberapa penerus publikasi yang telah memublikasikan sumber pesan untuk suatu topik guna meminta pesan yang dibutuhkan. Penerusan publikasi mengirim pesan yang tidak dikonfirmasi ke penerus langganan, yang kemudian merelai pesan tersebut ke pelanggan.
Setelah memproses pesan, pelanggan akan mengirimkan konfirmasi kembali kepada penerus langganan. Penerusan langganan menyampaikan konfirmasi ini ke penerus publikasi, yang menyimpan konfirmasi tersebut di sumber publikasi pesan. Setelah semua langganan pada suatu topik mengonfirmasi pesan, pesan tersebut akan dihapus secara asinkron dari sumber pesan publikasi dan dari penyimpanan.
Pesan yang berbeda-beda untuk satu topik dan langganan dapat mengalir melalui banyak penerbit, pelanggan, penerusan publikasi, dan penerusan langganan. Penerbit dapat memublikasikan ke beberapa penerus secara bersamaan dan pelanggan dapat terhubung ke beberapa penerusan langganan untuk menerima pesan. Oleh karena itu, aliran pesan melalui koneksi di antara penerbit, pelanggan, dan penerus dapat menjadi rumit. Diagram berikut menunjukkan bagaimana pesan dapat mengalir untuk satu topik dan langganan, dengan warna yang berbeda menunjukkan berbagai jalur yang dapat diambil oleh pesan dari penerbit ke pelanggan:
Menjaga Pub/Sub Tetap Aktif
Memastikan bahwa sistem terdistribusi seperti Pub/Sub dapat tetap aktif dan berjalan serta melayani semua pelanggan secara efektif memerlukan banyak visibilitas dan kontrol atas sistem tersebut. Mengelola layanan adalah tanggung jawab Site Reliability Engineer (SRE) kami. Untuk Pub/Sub, engineer ini berlokasi di beberapa lokasi di seluruh dunia untuk memberikan cakupan 24/7.
Lingkungan
Bagian pertama dari pemeliharaan sistem seperti Pub/Sub adalah memiliki kemampuan untuk menguji software sebelum digunakan oleh pelanggan. Untuk memungkinkan hal itu, ada tiga lingkungan Pub/Sub: pengujian, staging, dan produksi. Pengujian dan staging tidak berisi traffic pelanggan; pengujian tersebut hanya berisi pengujian dan pemantauan yang terus berjalan yang membantu menemukan masalah pada rilis. Lingkungan ini menerima rilis baru software sebelum lingkungan production. Perbedaan antara pengujian dan staging adalah yang kedua adalah replika yang tepat dari apa yang ada di (atau akan segera ada di) lingkungan produksi, termasuk versi software dan flag command line. Developer sebaiknya memiliki fitur yang masih dikerjakan dan direncanakan untuk dirilis oleh developer di masa mendatang.
Peluncuran
Prosedur untuk meluncurkan dan menguji Pub/Sub dirancang untuk meminimalkan potensi dampak. Mari kita lihat langkah-langkah umum untuk peluncuran Pub/Sub versi baru:
Pastikan semua pengujian unit dan pengujian integrasi lulus.
Buat versi baru dari semua server.
Deploy server baru ke lingkungan pengujian dan staging.
Jalankan server di lingkungan pengujian dan staging selama beberapa hari.
Jika tidak ada masalah umum, rilis server ke canary, subset lingkungan produksi yang memiliki sedikit traffic pelanggan.
Jika tidak ada masalah yang terdeteksi pada canary, secara bertahap luncurkan server ke lebih banyak produksi selama beberapa hari hingga server dirilis di mana saja.
Karena Pub/Sub dirancang agar tahan terhadap kegagalan, misalnya, melalui pemisahan bidang kontrol dan bidang data, peluncuran versi baru server berjalan lancar bagi pelanggan dan tidak akan berdampak pada performa yang mereka lihat.
Pemantauan
Kunci untuk menjaga Pub/Sub tetap aktif dan berjalan adalah dengan secara otomatis mendeteksi dan memitigasi masalah sebelum masalah tersebut terlihat oleh pengguna akhir. Untuk mencapai hal ini, diperlukan pemantauan sistem yang ekstensif. Tim Site Reliability Engineering (SRE) mengelola serangkaian indikator tingkat layanan (SLI), metrik yang didefinisikan dengan baik yang mendeskripsikan perilaku sistem. Metrik dapat mencakup "jumlah waktu yang diperlukan untuk menyelesaikan permintaan CreateSubscription" atau "tingkat error yang dihasilkan oleh permintaan Publikasi". Metrik ini diukur dengan berbagai cara. Beberapa dari mereka secara ketat internal untuk forwarder dan {i>router<i} kita. Misalnya, fitur ini mengukur berapa lama waktu yang diperlukan untuk menulis pesan ke disk.
Semua tindakan ini membantu menentukan tujuan tingkat layanan (SLO) internal, target spesifik untuk SLI. Misalnya, "permintaan CreateSubscription memerlukan waktu tidak lebih dari lima detik untuk diselesaikan". SRE akan diberi tahu jika ada pelanggaran SLO, dan harus menindaklanjuti pemberitahuan dalam waktu lima menit.
Perjanjian tingkat layanan (SLA) mencantumkan SLO yang menentukan jaminan performa kami kepada pengguna akhir dan konsekuensinya jika kami tidak memenuhinya. Anda dapat membaca SLA Pub/Sub.
Kami mengelola sekumpulan klien yang dapat memprediksi dan berlangganan. Hal ini disebut prober. {i>Prober<i} ada untuk bidang data dan bidang kontrol. Setiap klien kami melakukan tindakan tertentu seperti yang dilakukan pelanggan, dan mengukur berapa lama operasi berlangsung. Misalnya, kami memiliki staf yang membuat langganan baru, memublikasikan pesan, dan melihat waktu yang diperlukan untuk membuat langganan dan menerima pesan. Jika prober menentukan bahwa salah satu metrik yang diukur tidak seperti yang diharapkan, SRE akan diberi tahu.
Metrik untuk server dan akun pemeriksaan kami dirangkum di beberapa dasbor internal. Ini adalah tempat pertama yang harus dilihat SRE setiap kali mendiagnosis potensi masalah. Halaman ini memberikan akses cepat ke statistik dan grafik seluruh layanan. Mereka juga dapat dikelompokkan berdasarkan topik, pusat data, atau tugas individual.
Metrik yang paling menarik bagi pengguna layanan ditampilkan melalui Google Cloud Monitoring.
Kontrol
Kami memiliki beberapa kontrol untuk membantu menyesuaikan performa Pub/Sub. Beberapa kontrol ini didesain untuk membantu pusat data atau pemadaman mesin. Kita dapat menempatkan batasan perutean pada beberapa atau semua topik, yang merupakan aturan yang menentukan kumpulan klien yang dapat dan/atau tidak dapat terhubung ke kumpulan penerusan. Kami menggunakan kendala perutean untuk menguras traffic dari tugas penerusan individual atau keseluruhan pusat data yang tidak berfungsi seperti yang diharapkan.
Fitur lain yang dapat disesuaikan adalah kontrol alur. Fitur ini memungkinkan kami memaksimalkan throughput sekaligus mencegah kelebihan beban dalam layanan. Kontrol alur adalah bentuk pembentukan lalu lintas di mana lonjakan beban yang tidak terduga dapat dihaluskan seiring waktu untuk stabilitas layanan yang lebih baik. Kontrol alur beroperasi di seluruh sistem atau berbasis per topik atau per pelanggan untuk membatasi jumlah pesan atau jumlah byte yang ditransfer atau luar biasa. Dalam hal ini "outstanding" berarti diserahkan ke klien, tetapi belum diakui. Kontrol alur dan batasan perutean memungkinkan kami mengoptimalkan performa Pub/Sub tanpa mengharuskan pelanggan mengkhawatirkan detail tingkat rendah ini.
Ringkasan
Keuntungan dalam skalabilitas, ketersediaan, dan latensi layanan seperti Pub/Sub menentukan proposisi nilai bagi pelanggan yang mempertimbangkan untuk beralih ke layanan cloud terkelola. Setiap layanan pesan asinkron harus dibuat dari awal dengan mempertimbangkan fitur ini. Dengan pengalaman lebih dari satu dekade dalam mengirimkan banyak pesan dengan cepat dan andal, tim Pub/Sub telah membuat dan memelihara layanan yang dapat memenuhi permintaan produk yang paling mendasar di Google. Sekarang layanan yang sama tersedia untuk semua pelanggan eksternal yang ingin mengirim pesan mereka ke seluruh dunia tanpa harus khawatir apakah sistem pesan mereka dapat menangani 2x, 10x, atau 100x beban mereka saat ini.
Glosarium
| Masa Berlaku | Deskripsi |
|---|---|
| cluster | Pengelompokan logis mesin yang umumnya memiliki domain kegagalan yang sama (misalnya, jaringan lokal dan daya bersama). |
| bidang kontrol | Lapisan Pub/Sub yang menangani penetapan penayang dan pelanggan ke server di bidang data. |
| bidang data | Lapisan Pub/Sub yang menangani perpindahan pesan antara penerbit dan pelanggan. |
| penerus | Server di bidang data. |
| akses data global | Klien penayang dan pelanggan Pub/Sub tidak mengetahui lokasi data. Semua perutean dan penyimpanan dilakukan oleh layanan itu sendiri, sesuai dengan kebijakan Pembatasan Lokasi. |
| skalabel secara horizontal | Kemampuan layanan untuk menangani lebih banyak beban secara lancar dengan meningkatkan jumlah instance komponen layanan. |
| pesan | Data yang berpindah melalui Pub/Sub. |
| jarak jaringan | Ukuran latensi pada koneksi antara dua titik. |
| Prober | Tugas yang bertindak sebagai klien dan dapat diprediksi melakukan satu atau beberapa tindakan di server Pub/Sub. |
| publikasikan sumber pesan | Kumpulan pesan yang diterima dan disimpan oleh penerus publikasi dan kumpulan ID pesan yang dikonfirmasi oleh semua langganan terlampir. |
| layanan publikasi/langganan (Pub/Sub) | Layanan pesan yang memisahkan pengirim pesan dari penerima pesan |
| penayang | Klien Pub/Sub yang membuat pesan dan mengirimkannya (memublikasikan) pada topik tertentu. |
| router | Server di bidang kontrol. |
| batasan perutean | Daftar aturan yang menunjukkan penerusan mana yang boleh atau tidak boleh dikirim oleh router ke klien sebagai titik akhir yang dapat dihubungkan. |
| perjanjian tingkat layanan (SLA) | Daftar SLO yang menentukan jaminan performa sistem kepada pelanggan dan menguraikan konsekuensi jika tidak terpenuhi. |
| indikator tingkat layanan (SLI) | Metrik yang didefinisikan dengan baik yang menggambarkan perilaku sistem. |
| tujuan tingkat layanan (SLO) | Target spesifik untuk indikator tingkat layanan. |
| pelanggan | Klien Pub/Sub yang menerima pesan pada langganan tertentu. |
| langganan | Entity bernama yang mewakili minat untuk menerima semua pesan tentang topik tertentu. |
| jaminan titik sinkronisasi | Waktu pembuatan langganan, saat semua pesan berikutnya yang dipublikasikan akan dikirimkan kepada pelanggan. |
| topic | Entity bernama yang mewakili feed pesan. |