Google Pub/Sub

Mengapa Menggunakan Pub/Sub

Pub/Sub menangani messaging dan even ingestion pada level global. Namun sebelum membahas lebih jauh, mari kita bahas mengapa digunakan messaging middleware.

Dengan melihat diagram dibawah dapat dilihat, ketika Aplikasi yang dikembangkan terdistribusi dengan aliran data dapat masuk dari berbagai node, tanpa messaging service, arsitektur dibawah akan bermasalah ketika salah satu node bermasalah.

Hal diatas dapat dicegah dengan menggunakan messaging middleware. Dengan melihat arsitektur dibawah, ketika salah satu node bermasalah, sistem secara keseluruhan tetap berfungsi. Sistem akan kembali berjalan normal ketika node yang bermasalah kembali normal.

Dengan cara ini, keterikatan antar service rendah, membuat sistem lebih tahan.

Anda dapat bayangkan Pub/Sub sebagai shock absorber untuk sistem ketika ada node yang bermasalah. Pub/Sub bekerja baik untuk exchange messages pada distributed system dan juga dapat mentriger event dan melakukan suatu tindakan tertentu.

Pengenalan Google Cloud Pub/Sub

Google Cloud Pub/Sub adalah global messaging dan event ingestion service. Menggunakan Pub/Sub modl menangani messages/events secara konsisten diberbagai region secara serverless dan fully-managed service. Artinya Anda tidak perlu melakukan provision dan langsung menggunakan Pub/Sub API.

Sebagai bayangan kemampuan dari Google Cloud Pub/Sub, Google Internal Pub/Sub sendiri menangani messages dan events untuk berbagai service seperti Ads, Gmail dan lainnya sebanyak 500 juta message per second dan lebih dari 1 TB/s data.

Fitur dari Google Cloud Pub/Sub

  • Multiple publisher/subscriber pattern
  • Garansi at-least-once delivery, setiap message dikirim minimal satu kali untuk setiap topic subscription. Ada kemungkinan menerima message lebih dari sekali dalam sebuah subscription.
  • Message dapat diproses secara real-time atau batch.
  • Dapat di-integrasikan dengan Google Cloud DataFlow.
  • Message yang tidak terkirim akan dihapus setelah melewati masa retention. Secara default adalah 7 hari, dapat dikonfigurasi.
  • Message yang di publish sebelum subscription dibuat, message tersebut tidak akan dikirimkan pada subscription tersebut. Hal ini juga berlaku sebaliknya, jika mengirimkan message pada topic yang tidak ada subscription, message tidak akan terkirim.

Penggunaan Google Pub/Sub

  • Distributing workload.
  • Asynchronous Workflow.
  • Distributing event notifications.
  • Distributing logging.
  • Device data streaming.

Pub/Sub Patterns

  • One to One, terdapat 1 publisher, 1 topic dan 1 subscriber.
  • One to Many, terdapat 1 publishser, 1 topic dan lebih dari 1 subscriber.
  • Many to One, terdapat lebih dari 1 publisher, lebih dari 1 topic dan terdapat 1 subscriber.
  • Many to Many, terdapat lebih dari 1 publisher, lebih dari 1 topic dan lebih dari 1 subscriber.

Publishing Message

Publish message menggunakan Pub/Sub cukup mudah:

  • Membuat message berupa JSON base64 encoded, dengan ukuran kurang dari 10Mb.
  • Kemudian mengirim request ke Pub/Sub API. Spesifikan topic.

Menerima Message

Menerima message juga sangat mudah: cukup membuat subcription untuk sebuah topic.

Terdapat dua metoda delivery:

  • Pull (default), ketika message diterima, kita harus melakukan Acknowledge penerimaan data. Bila tidak message akan tetap dalam antrian.
  • Push, message akan otomatis dikirim ke endpoint. Endpoint harus menggunakan HTTPS dengan Valid SSL Certificate.

Integrasi Pub/Sub

  • Melakukan integrasi Pub/Sub cukup mudah karena mendukung bahasa yang umum, Java, Python, C#, Go, Java, Node, PHP dan Ruby.
  • Pub/Sub juga didukung penuh oleh Google Cloud Dataflow.
  • Menggunakan events untuk trigger Cloud Functions.
  • Menggunakan Cloud Run untuk menerima Subscriptions.
  • Dasar dari IoT core, menerima messages dan events dari devices.

Local Pub/Sub

Jika Anda memerlukan Pub/Sub service untuk local aplikasi namun tidak ingin menggunakan Google Cloud Pub/Sub service untuk menghemat biaya, Anda dapat gunakan Local Pub/Sub emulator. Untuk menjalankannya Anda memerlukan Google Cloud SDK dan Java Runtime Environment 7 keatas.

Subscription Lifecycle

  • Secara default subscriptions akan expire setelah 31 hari tanpa aktifitas. Anda bisa ubah.
  • Jika Anda membuat subscription dengan nama yang sama dengan subscription yang pernah dihapus, tidak ada relasinya dengan subscription tersebut.

Limitation Standard Model

  • ACK message tidak tersedia untuk subscribers. Message masih bisa diakses didalam topics.
  • Subscriber harus memproses setiap messages.

Ordering Messages

  • Tidak ada garansi messages ordering.
  • Jika membutuhkan ordering, tambahkan metadata time stamp pada message.
  • Pertimbangkan penggunaan alternatif transactional ordering, misalnya menyimpan order list berdasarkan timestamp untuk setiap message dalam Cloud Store atau Cloud SQL.

Resource Location

  • Message secara default disimpan di region terdekat.
  • Anda dapat menentukan message storage. Perhatikan bisa terjadi biaya egress tambahan.

Monitoring PubSub

Berikut beberapa metrik yang umum digunakan untuk memonitor kesehatan PubSub, list lengkap dapat dilihat disini.

pubsub.googleapis.com/topic/byte_costTotal utilization in bytes
pubsub.googleapis.com/subscription/byte_costSubscription utilization in bytes
subscription/num_undelivered_messagesMessages yang tidak terkirim dalam sebuah subscription.
subscription/oldest_unacked_message_ageMessages paling tua yang belum diretrieve.
subscription/num_outstanding_messagesPending delivery untuk push subscription.

Access Control

  • Seperti GCP service lainnya, Anda harus mengatur akses terhadap PubSub menggunakan Cloud IAM dan menggunakan custom service accounts.
  • Gunakan permission by topic atau subscription.
  • Gunakan limited access untuk publish atau consume messages.

Silakan lihat dokumentasi lebih lengkap untuk PubSub Access Control.

Sharing is caring: