Pub/Sub adalah layanan pesan asinkron yang dirancang agar sangat andal dan skalabel. Layanan ini dibuat berdasarkan komponen infrastruktur inti Google yang telah digunakan oleh banyak produk Google selama lebih dari satu dekade. Produk Google termasuk Iklan, Penelusuran, dan Gmail menggunakan infrastruktur ini untuk mengirim lebih dari 500 juta pesan per detik, dengan total data lebih dari 1 TB/detik. Artikel ini menjelaskan fitur desain yang 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 memerlukan kompromi pada salah satu faktor untuk meningkatkan dua faktor lainnya.
Istilah "skalabilitas", "ketersediaan", dan "latensi" dapat merujuk ke berbagai properti sistem, sehingga bagian berikut menjelaskan cara menentukannya di Pub/Sub.
Skalabilitas
Layanan yang skalabel harus dapat menangani peningkatan beban tanpa penurunan latensi atau ketersediaan yang signifikan. "Beban" dapat merujuk ke berbagai dimensi penggunaan di Pub/Sub:
Jumlah topik
Jumlah penayang
Jumlah langganan
Jumlah subscriber
Jumlah pesan
Ukuran pesan
Rasio pesan (throughput) yang dipublikasikan atau digunakan
Ukuran backlog pada langganan tertentu
Ketersediaan
Dalam sistem terdistribusi, jenis dan tingkat keparahan masalah dapat sangat bervariasi. Ketersediaan sistem diukur berdasarkan seberapa baik sistem tersebut menangani berbagai jenis masalah, dengan gagal secara halus dengan cara yang tidak terlihat oleh pengguna akhir. Kegagalan dapat terjadi pada hardware (misalnya, drive disk tidak berfungsi atau masalah konektivitas jaringan), pada software, dan karena beban. Kegagalan karena beban dapat terjadi saat peningkatan traffic secara tiba-tiba dalam layanan (atau dalam komponen software lain yang berjalan di hardware yang sama atau dalam dependensi software) menyebabkan kelangkaan resource. Ketersediaan juga dapat menurun karena kesalahan manusia, yaitu seseorang melakukan kesalahan dalam mem-build atau men-deploy software atau konfigurasi.
Latensi
Latensi adalah pengukuran performa sistem berdasarkan waktu. Layanan umumnya 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 mengirimkan pesan yang dipublikasikan kepada pelanggan.
Arsitektur Dasar Pub/Sub
Bagian ini menjelaskan desain Pub/Sub untuk menunjukkan cara layanan ini mencapai skalabilitas dan latensi rendah sekaligus 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 menawarkan akses data global yang cepat, sekaligus memberi pengguna kontrol atas tempat penyimpanan pesan. Cloud Pub/Sub menawarkan akses data global karena klien penayang dan pelanggan tidak mengetahui lokasi server yang terhubung 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 ditentukan di bagian Resource Location Restriction di IAM & admin console. Artinya, penayang di beberapa wilayah dapat memublikasikan pesan ke satu topik dengan latensi rendah. Setiap pesan disimpan di satu region. Namun, topik dapat memiliki pesan yang disimpan di banyak region. Saat klien pelanggan meminta pesan yang dipublikasikan ke topik ini, klien akan terhubung ke server terdekat yang menggabungkan data dari semua pesan yang dipublikasikan ke topik untuk dikirim ke klien.
Pub/Sub dibagi menjadi dua bagian utama: data plane, yang menangani pemindahan pesan antara penayang dan pelanggan, serta control plane, yang menangani penetapan penayang dan pelanggan ke server di data plane. Server di bidang data disebut forwarder, dan server di bidang kontrol disebut router. Saat penayang dan pelanggan terhubung ke penerusan 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 sudah terhubung dan mengirim atau menerima pesan.
Bidang Kontrol
Bidang kontrol Pub/Sub mendistribusikan klien ke penerusan dengan cara yang memberikan skalabilitas, ketersediaan, dan latensi rendah untuk semua klien. Setiap penerusan dapat melayani klien untuk topik atau langganan apa pun. Saat klien terhubung ke Pub/Sub, router akan menentukan pusat data yang harus dihubungkan klien berdasarkan jarak jaringan terpendek, yaitu ukuran latensi pada koneksi antara dua titik. Dalam pusat data tertentu, router mencoba mendistribusikan beban secara keseluruhan di seluruh kumpulan penerusan yang tersedia. Router harus menyeimbangkan dua sasaran yang berbeda saat melakukan penetapan ini: (a) keseragaman beban (yaitu, idealnya setiap forwarder dimuat secara merata); dan (b) stabilitas penetapan (yaitu, idealnya perubahan beban atau perubahan dalam kumpulan forwarder yang tersedia akan mengubah jumlah terkecil penetapan yang ada). Router menggunakan varian hashing konsisten yang dikembangkan oleh Riset Google untuk mencapai keseimbangan yang dapat disesuaikan antara konsistensi dan keseragaman. Router memberikan daftar forwarder yang diurutkan kepada klien yang dapat dipertimbangkan untuk dihubungkan. Daftar yang diurutkan ini dapat berubah berdasarkan ketersediaan forwarder dan bentuk beban dari klien.
Klien mengambil daftar penerusan ini dan terhubung ke satu atau beberapa penerusan. Klien lebih memilih untuk terhubung ke penerusan yang paling direkomendasikan oleh router, tetapi juga mempertimbangkan kegagalan yang telah terjadi, misalnya, klien dapat memutuskan untuk mencoba penerusan di pusat data lain jika beberapa upaya ke penerusan terdekat telah 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.
Bidang Data - Siklus Proses Pesan
Data plane menerima pesan dari penayang dan mengirimkannya ke klien. Mungkin cara terbaik untuk memahami bidang data Pub/Sub adalah dengan melihat masa aktif pesan, mulai dari saat pesan diterima oleh layanan hingga saat pesan tidak lagi ada di layanan. Mari kita lacak langkah-langkah pemrosesan pesan. Untuk tujuan bagian ini, kami mengasumsikan bahwa topik tempat pesan dipublikasikan memiliki setidaknya satu langganan yang terpasang. Secara umum, pesan akan melalui langkah-langkah berikut:
Penayang mengirim pesan.
Pesan ditulis ke penyimpanan.
Pub/Sub mengirimkan konfirmasi kepada penayang bahwa pesan telah diterima dan menjamin pengirimannya ke semua langganan yang terlampir.
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 pesan, Pub/Sub akan menghapus pesan dari penyimpanan.
Pertama, penayang mengirimkan pesan tentang suatu topik ke Pub/Sub. Data ini dienkripsi oleh lapisan proxy dan dikirim ke penerusan publikasi, yaitu penerusan yang terhubung ke penayang. Untuk memastikan pengiriman, pesan akan langsung ditulis ke penyimpanan. Pengirim awalnya menulis pesan ke cluster N (dengan N adalah bilangan ganjil) dan menganggap pesan dipertahankan jika telah ditulis ke setidaknya ⌈N/2⌉ cluster. Setelah pesan dipertahankan, penerusan publikasi akan mengonfirmasi penerimaan pesan kembali ke penayang, pada saat itu Pub/Sub menjamin bahwa pesan akan dikirim ke semua langganan yang terlampir.
Dalam setiap cluster, pesan ditulis ke M disk independen (dengan M adalah bilangan ganjil), yang mengharuskan data berada di disk ⌈M/2⌉ sebelum dianggap dipertahankan di cluster tersebut. Secara total, setiap pesan yang dipublikasikan akan ditulis ke setidaknya ⌈M/2⌉ disk independen di ⌈N/2⌉ cluster sebelum dianggap dipertahankan dan pada akhirnya akan direplikasi ke disk N*M.
Pengirim publikasi memiliki daftar semua langganan yang dilampirkan ke topik. Fungsi ini bertanggung jawab untuk mempertahankan pesan yang dipublikasikan dan metadata yang menjelaskan pesan mana yang telah diakui oleh setiap langganan. Kumpulan pesan yang diterima dan disimpan oleh penerusan publikasi untuk topik tertentu, beserta pelacakan pesan yang diakui ini, disebut "sumber pesan publikasi". Bergantung pada persyaratan throughput untuk topik, satu penayang dapat mengirim pesannya ke beberapa penerusan publikasi dan menyimpan pesan di beberapa sumber pesan publikasi. Penayang yang berbeda untuk topik yang sama juga dapat mengirim pesan ke penerusan publikasi yang berbeda. Setiap pesan hanya dikirim ke satu penerusan publikasi. Pub/Sub secara dinamis menyesuaikan jumlah penerusan publikasi yang menerima pesan untuk topik tertentu saat throughput berubah.
Pelanggan menerima pesan dengan terhubung ke penerusan berlangganan, penerusan yang digunakan untuk mengalirkan pesan ke pelanggan dari penayang. “Menghubungkan” dalam kasus pelanggan pull berarti mengeluarkan permintaan pull. “Menghubungkan” dalam kasus pelanggan push berarti memiliki endpoint push yang terdaftar dengan Pub/Sub. Setelah langganan dibuat, pesan apa pun yang dipublikasikan setelah titik tersebut akan dikirim ke langganan tersebut, yang kami sebut jaminan titik sinkronisasi.
Setiap penerusan langganan harus meminta pesan dari penerusan publikasi yang memiliki sumber pesan publikasi untuk topik tersebut. Seperti penayang, pelanggan dapat terhubung ke lebih dari satu pengirim berlangganan untuk menerima pesan. Dengan demikian, tidak setiap penerusan langganan perlu mengetahui atau menerima pesan dari setiap sumber pesan publikasi untuk suatu topik, yang merupakan properti penting agar Pub/Sub dapat diskalakan secara horizontal. Berdasarkan throughput pesan yang dikirim ke pelanggan, Pub/Sub secara dinamis menyesuaikan jumlah penerusan langganan yang digunakan pelanggan untuk menerima pesan untuk topik tertentu saat throughput berubah.
Pengirim berlangganan membuat permintaan ke satu atau beberapa pengirim publikasi yang telah memublikasikan sumber pesan untuk suatu topik guna meminta pesan yang diperlukan. Penerusan publikasi mengirim pesan yang tidak direspons ke penerusan langganan, yang kemudian meneruskan pesan ke pelanggan.
Setelah memproses pesan, pelanggan akan mengirimkan konfirmasi kembali ke pengirim yang berlangganan. Penerusan berlangganan meneruskan konfirmasi ini ke penerusan publikasi, yang menyimpan konfirmasi di sumber pesan publikasi. Setelah semua langganan di topik mengonfirmasi pesan, pesan akan dihapus secara asinkron dari sumber pesan publikasi dan dari penyimpanan.
Pesan yang berbeda untuk satu topik dan langganan dapat mengalir melalui banyak penayang, pelanggan, penerusan publikasi, dan penerusan langganan. Penayang dapat memublikasikan ke beberapa penerusan secara bersamaan dan pelanggan dapat terhubung ke beberapa penerusan berlangganan untuk menerima pesan. Oleh karena itu, alur pesan melalui koneksi di antara penayang, pelanggan, dan penerusan dapat menjadi rumit. Diagram berikut menunjukkan cara pesan dapat mengalir untuk satu topik dan langganan, dengan warna yang berbeda menunjukkan jalur yang berbeda yang dapat dilalui pesan dari penayang ke pelanggan:
Memastikan Pub/Sub Tetap Beroperasi
Memastikan sistem terdistribusi seperti Pub/Sub dapat tetap aktif dan berjalan serta melayani semua pelanggan secara efektif memerlukan visibilitas dan kontrol yang besar atas sistem tersebut. Site Reliability Engineer (SRE) kami bertanggung jawab untuk memelihara layanan ini. Untuk Pub/Sub, engineer ini berada di beberapa lokasi di seluruh dunia untuk memberikan cakupan 24/7.
Lingkungan
Bagian pertama dalam mengelola sistem seperti Pub/Sub adalah memiliki kemampuan untuk menguji software sebelum digunakan oleh pelanggan. Untuk memungkinkan hal tersebut, ada tiga lingkungan Pub/Sub: pengujian, staging, dan produksi. Pengujian dan staging tidak berisi traffic pelanggan; keduanya hanya berisi pengujian dan pemantauan yang terus berjalan yang membantu menemukan masalah pada rilis. Lingkungan ini menerima rilis baru software sebelum produksi. Perbedaan antara pengujian dan staging adalah staging adalah replika persis dari apa yang ada di (atau akan segera ada di) lingkungan produksi, termasuk versi software dan flag command line. Versi pertama mungkin mengaktifkan fitur yang sedang dikerjakan oleh developer dan direncanakan untuk dirilis pada masa mendatang.
Peluncuran
Prosedur untuk meluncurkan dan menguji Pub/Sub dirancang untuk meminimalkan potensi dampaknya. Mari kita lihat langkah-langkah standar untuk peluncuran versi baru Pub/Sub:
Pastikan semua pengujian unit dan pengujian integrasi berhasil.
Build 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 yang diketahui, rilis server ke canary, yaitu sebagian kecil lingkungan produksi yang memiliki sedikit traffic pelanggan.
Jika tidak ada masalah yang terdeteksi di canary, luncurkan server secara bertahap ke lebih banyak produksi selama beberapa hari hingga dirilis di mana-mana.
Karena Pub/Sub dirancang agar tahan terhadap kegagalan, misalnya, melalui pemisahan bidang kontrol dan bidang data, peluncuran server versi baru 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 otomatis mendeteksi dan mengurangi masalah sebelum terlihat oleh pengguna akhir. Untuk mencapai hal ini, pemantauan sistem yang ekstensif diperlukan. Tim Site Reliability Engineering (SRE) mengelola kumpulan indikator tingkat layanan (SLI), metrik yang ditentukan dengan baik yang mendeskripsikan perilaku sistem. Metrik dapat mencakup "jumlah waktu yang diperlukan untuk menyelesaikan permintaan CreateSubscription" atau "rasio error yang dihasilkan oleh permintaan Publish". Metrik ini diukur dengan berbagai cara. Beberapa di antaranya hanya bersifat internal untuk forwarder dan router kami. Misalnya, metrik ini mengukur 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 tidak boleh memerlukan waktu lebih dari lima detik untuk diselesaikan". SRE akan menerima pemberitahuan untuk pelanggaran SLO, dan harus menangani 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 diprediksi untuk memublikasikan dan berlangganan. Fungsi ini disebut prober. Prober ada untuk bidang data dan bidang kontrol. Setiap pemeriksa kami melakukan tindakan tertentu seperti yang dilakukan pelanggan dan mengukur berapa lama operasi berlangsung. Misalnya, kita memiliki penguji yang membuat langganan baru, memublikasikan pesan, dan melihat berapa lama waktu yang diperlukan untuk membuat langganan dan menerima pesan. Jika pemeriksa menentukan bahwa salah satu metrik yang diukur tidak seperti yang diharapkan, SRE akan diberi tahu.
Metrik untuk server dan penguji kami diringkas di beberapa dasbor internal, tempat pertama yang dilihat SRE setiap kali mendiagnosis potensi masalah. Halaman ini memberikan akses cepat ke statistik dan grafik seluruh layanan. Data ini juga dapat dikelompokkan menurut 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 dirancang untuk membantu mengatasi pemadaman pusat data atau mesin. Kita dapat menempatkan batasan pemilihan rute pada beberapa atau semua topik, yang merupakan aturan yang menentukan kumpulan klien yang dapat dan/atau tidak dapat terhubung ke kumpulan penerusan. Kami menggunakan batasan pemilihan rute untuk mengurangi traffic dari setiap tugas penerusan atau seluruh 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 di layanan. Kontrol alur adalah bentuk pembentukan traffic yang dapat meminimalkan lonjakan beban yang tiba-tiba dan tidak terduga dari waktu ke waktu untuk stabilitas layanan yang lebih baik. Kontrol alur beroperasi di seluruh sistem atau berdasarkan per topik atau per pelanggan untuk membatasi jumlah pesan atau jumlah byte yang ditransfer atau yang belum selesai. Dalam hal ini, "outstanding" berarti dikirim ke klien, tetapi belum direspons. Kontrol alur dan batasan pemilihan rute memungkinkan kami mengoptimalkan performa Pub/Sub tanpa pelanggan harus khawatir dengan detail tingkat rendah ini.
Ringkasan
Keunggulan 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-fitur ini. Dengan pengalaman lebih dari satu dekade dalam mengirimkan banyak pesan dengan cepat dan andal, tim Pub/Sub telah membuat dan mengelola layanan yang dapat memenuhi permintaan produk paling mendasar di Google. Sekarang layanan yang sama tersedia untuk semua pelanggan eksternal yang ingin mengirim pesan ke seluruh dunia tanpa harus khawatir apakah sistem pesan mereka dapat menangani beban 2x, 10x, atau 100x beban saat ini.
Glosarium
| Istilah | Deskripsi |
|---|---|
| cluster | Pengelompokan mesin yang secara logis memiliki domain kegagalan yang sama (misalnya, jaringan lokal bersama 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 pemindahan pesan antara penayang 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 dengan lancar dengan meningkatkan jumlah instance komponen layanan. |
| message | Data yang bergerak melalui Pub/Sub. |
| jarak jaringan | Ukuran latensi pada koneksi antara dua titik. |
| penguji | Tugas yang bertindak sebagai klien dan secara dapat diprediksi melakukan satu atau beberapa tindakan di server Pub/Sub. |
| memublikasikan sumber pesan | Kumpulan pesan yang diterima dan disimpan oleh penerusan publikasi dan kumpulan ID pesan yang diakui oleh semua langganan yang terlampir. |
| layanan publikasi/langganan (Pub/Sub) | Layanan pesan yang memisahkan pengirim pesan dari penerima pesan |
| penayang | Klien Pub/Sub yang membuat pesan dan mengirim (memublikasikan) pesan tersebut pada topik yang ditentukan. |
| router | Server di bidang kontrol. |
| batasan pemilihan rute | Daftar aturan yang menunjukkan forwarder mana yang harus atau tidak boleh dikirim oleh router ke klien sebagai kemungkinan endpoint untuk 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 ditentukan dengan baik yang menjelaskan perilaku sistem. |
| tujuan tingkat layanan (SLO) | Target spesifik untuk indikator tingkat layanan. |
| subscriber | Klien Pub/Sub yang menerima pesan pada langganan yang ditentukan. |
| langganan | Entitas bernama yang mewakili minat untuk menerima semua pesan tentang topik tertentu. |
| jaminan titik sinkronisasi | Waktu saat langganan dibuat, tempat semua pesan berikutnya yang dipublikasikan akan dikirimkan kepada pelanggan. |
| topic | Entitas bernama yang mewakili feed pesan. |