Eventarc #

Dalam era transformasi digital modern, arsitektur berbasis peristiwa (event-driven architecture atau EDA) telah menjadi fondasi utama untuk membangun sistem yang responsif, berkinerja tinggi, dan terdistribusi secara longgar (loosely coupled). Pada sistem microservices tradisional, integrasi antar layanan sering kali dipaksa menggunakan panggilan HTTP sinkron yang kaku. Ketika sebuah file diunggah ke penyimpanan objek, kita harus menulis kode khusus di backend untuk mendeteksi unggahan tersebut, atau menyuruh frontend memicu webhook ke layanan lain secara berurutan. Pendekatan ini meningkatkan risiko kegagalan berantai dan menambah kerumitan kode.

Google Cloud Eventarc hadir untuk mengatasi kompleksitas tersebut sebagai layanan serverless event routing terkelola penuh (fully managed). Eventarc bertindak sebagai sistem perantara universal yang mampu menangkap peristiwa (events) dari berbagai sumber — baik dari layanan internal Google Cloud, log audit, aplikasi kustom kita sendiri, maupun platform SaaS pihak ketiga — memfilternya secara granular, menerjemahkannya ke dalam standar industri, dan menyalurkannya langsung ke target komputasi serverless seperti Cloud Run, Cloud Functions, atau Google Cloud Workflows. Dengan Eventarc, kita dapat membangun sistem reaktif berskala besar tanpa perlu menulis kode penghubung (glue code) dan tanpa perlu mengelola infrastruktur broker event satu pun.

Arsitektur Internal dan Teknologi di Balik Eventarc #

Untuk memahami keandalan Eventarc dalam menangkap dan mengantarkan jutaan event secara real-time, kita harus melihat bagaimana ia dibangun di atas fondasi infrastruktur GCP.

1. Pub/Sub sebagai Transport Engine di Latar Belakang #

Di bawah tenda, Eventarc memanfaatkan keandalan infrastruktur Google Cloud Pub/Sub untuk melakukan transmisi pesan. Setiap kali kita membuat sebuah Eventarc Trigger, Google secara otomatis memprovisikan sebuah Pub/Sub topic tersembunyi yang bertindak sebagai jalur transportasi event. Pengguna tidak perlu membayar sepeser pun untuk topic tersembunyi ini; seluruh biaya sudah dikonsolidasikan ke dalam tarif penggunaan Eventarc.

2. Standar Format CNCF CloudEvents v1.0 #

Salah satu tantangan terbesar dalam sistem event-driven adalah variasi format payload data dari berbagai sumber yang berbeda. Eventarc memecahkan masalah ini dengan mengadopsi standar CloudEvents v1.0 yang dikelola oleh Cloud Native Computing Foundation (CNCF). Semua event yang melewati Eventarc dikemas ke dalam struktur JSON standar yang seragam, yang berisi atribut metadata wajib seperti:

• specversion: Versi spesifikasi CloudEvents yang digunakan (selalu 1.0).
• type: Jenis peristiwa yang terjadi (misalnya google.cloud.storage.object.v1.finalized untuk unggahan file).
• source: URI yang mengidentifikasi asal usul peristiwa (misalnya nama bucket GCS).
• id: ID unik peristiwa untuk mempermudah deteksi duplikasi pesan di sisi konsumen.
• time: Waktu stempel (timestamp) kapan peristiwa tersebut pertama kali terjadi di sistem asal.
• datacontenttype: Format media dari payload data (biasanya application/json).
• subject: Detail spesifik tentang resource yang terdampak (misalnya jalur file /photos/avatar.png).
• data: Payload spesifik dari peristiwa asli yang berisi metadata detail objek.

Standardisasi ini memastikan bahwa target penerima (seperti layanan Cloud Run) dapat memproses event dari sumber mana pun menggunakan pustaka parser CloudEvents universal yang sama.

3. Cloud Audit Logs sebagai Universal Event Source #

Bagaimana jika kita ingin memicu fungsi ketika sebuah VM Compute Engine dimatikan, atau ketika sebuah dataset BigQuery dibuat? Sebagian besar layanan GCP tidak memiliki trigger event bawaan. Eventarc mengatasi ini dengan mengintegrasikan Cloud Audit Logs. Setiap kali terjadi aktivitas modifikasi di layanan GCP mana pun, log aktivitas akan ditulis to Cloud Audit Logs. Eventarc memantau log audit ini secara real-time. Jika mendeteksi pola aktivitas yang sesuai dengan filter trigger kita, Eventarc akan mengonversi entri log tersebut menjadi format CloudEvent dan mengirimkannya ke target tujuan. Melalui mekanisme cerdas ini, lebih dari 130 layanan GCP secara otomatis berubah menjadi sumber event potensial bagi aplikasi kita.

Jenis-Jenis Sumber Event (Event Sources) #

Eventarc mengelompokkan sumber peristiwa menjadi beberapa kategori utama untuk mempermudah konfigurasi otentikasi dan perutean:

1. Google Cloud Services (Direct Events) #

Event yang dipicu langsung dari layanan GCP pendukung tanpa melalui log audit. Contoh klasiknya adalah Google Cloud Storage (misalnya event pembuatan objek object.v1.finalized atau penghapusan objek object.v1.deleted) dan kueri real-time Firestore. Opsi direct event ini menawarkan latensi pengiriman yang sangat rendah karena tidak perlu menunggu log audit selesai ditulis ke disk.

• Evolusi Trigger GCS Gen 1 vs Gen 2: Pada Cloud Functions Gen 1 lama, trigger penyimpanan menggunakan notifikasi langsung berbasis Pub/Sub internal yang tersembunyi di dalam bucket. Pada Gen 2, Eventarc bertindak sebagai sistem perute tunggal. Ini menyederhanakan topologi jaringan karena kita tidak perlu lagi memprovisikan atau merawat korelasi Pub/Sub secara manual di tingkat bucket; semua dikelola secara deklaratif melalui satu API Eventarc.

2. Custom Application Events (Custom Channels) #

Kita dapat menggunakan Eventarc untuk mengirimkan event buatan aplikasi kita sendiri lintas project GCP atau ke tim developer lain. Kita mempublikasikan event kustom kita ke Eventarc Channel khusus menggunakan format standar CloudEvents. Eventarc kemudian akan menyalurkannya ke berbagai target yang berminat berdasarkan filter yang telah dikonfigurasikan.

3. SaaS Third-Party Partners #

Eventarc mendukung integrasi asli dengan penyedia SaaS eksternal ternama seperti Auth0, Datadog, PagerDuty, dan MongoDB Atlas. Menggunakan fitur Partner Channels, kita dapat menangkap event keamanan dari Auth0 (misalnya event user_signup atau failed_login) dan merutekannya langsung ke backend Cloud Run kita di GCP untuk memicu workflow investigasi atau pengiriman email selamat datang secara otomatis tanpa perlu membuka endpoint API publik kita ke internet.

• Mekanisme Kerja Partner Channel: Integrasi diawali ketika platform SaaS partner mempublikasikan event ke endpoint Google Partner Source yang diotorisasi oleh ID project GCP kita. Di dalam konsol Google Cloud, kita kemudian menyetujui pembuatan saluran asosiasi (partner channel). Setelah saluran tersebut aktif, kita dapat membuat trigger Eventarc dengan kriteria filter spesifik untuk langsung mengarahkan payload SaaS tersebut ke layanan internal privat kita tanpa menulis skrip penengah.

Diagram Transmisi Event (Eventarc Flowchart) #

Berikut adalah visualisasi bagaimana event mengalir dari berbagai kategori sumber, difilter oleh Eventarc routing engine, dan didistribusikan ke target serverless dengan penanganan kegagalan.

flowchart TD
    subgraph Event Sources
        GCS["Cloud Storage Bucket"]
        CAL["Cloud Audit Logs"]
        CustomApp["Custom Application (Pub/Sub)"]
        SaaS["SaaS Partner (e.g. Auth0)"]
    end
    
    subgraph Eventarc Routing Engine
        Trigger["Eventarc Trigger"]
        Router["Filter & Router (CloudEvents v1.0)"]
        Trigger --> Router
    end
    
    subgraph Target Destinations
        CR["Cloud Run Service"]
        GCF["Cloud Functions Gen 2"]
        Workflows["GCP Workflows"]
    end
    
    GCS --> Trigger
    CAL --> Trigger
    CustomApp --> Trigger
    SaaS --> Trigger
    
    Router -->|"HTTP POST"| CR
    Router -->|"HTTP POST"| GCF
    Router -->|"HTTP POST"| Workflows
    Router -->|"Failure after Max Retry"| DLQ["Pub/Sub Dead Letter Queue"]

    style Router stroke:#0288d1,stroke-width:2px

Kebijakan Pengiriman, Retry, dan Penanganan Kegagalan (DLQ) #

Menjamin keandalan pengantaran event di lingkungan cloud yang dinamis adalah hal krusial. Eventarc menerapkan sistem garansi pengiriman yang ketat untuk memastikan tidak ada event yang hilang di tengah jalan.

1. Jaminan Pengiriman At-Least-Once #

Eventarc menjamin bahwa setiap event akan dikirimkan setidaknya satu kali ke target. Karena target (seperti Cloud Run atau Cloud Functions) menerima event melalui request HTTP POST biasa, Eventarc menganggap pengiriman sukses jika target merespons dengan kode status HTTP sukses (2xx). Jika target merespons dengan kode error (non-2xx) atau koneksi mengalami timeout, Eventarc akan menjadwalkan pengiriman ulang. Konsekuensinya, kode aplikasi target kita wajib dirancang bersifat Idempotent untuk menghindari efek samping dari pemrosesan event duplikat.

2. Kebijakan Retry Eksponensial #

Untuk menangani masalah kelebihan beban sementara (temporary rate limit) pada target, Eventarc menerapkan kebijakan percobaan ulang otomatis (retry policy) dengan jeda waktu yang meningkat secara eksponensial (exponential backoff). Sistem akan terus mencoba mengirimkan event tersebut secara berkala hingga maksimum 24 jam sejak event pertama kali tercipta.

3. Integrasi Dead Letter Queue (DLQ) #

Jika setelah 24 jam percobaan ulang target tetap gagal merespons dengan sukses (misalnya karena bug permanen pada kode aplikasi target), Eventarc akan memindahkan event bermasalah tersebut ke Dead Letter Queue (DLQ) berbasis Pub/Sub topic yang telah kita konfigurasi sebelumnya. Dengan memindahkan event rusak ke DLQ, kita mencegah penumpukan antrean event lainnya dan dapat menganalisis penyebab error secara aman tanpa kehilangan data event asli.

4. Manajemen Beban dan Throttling #

Eventarc melindungi aplikasi hilir (downstream apps) kita dari kelebihan beban kerja (request flooding) saat terjadi badai event. Jika terjadi unggahan file secara massal sebanyak puluhan ribu sekaligus ke GCS, Eventarc akan memantau kecepatan respons target Cloud Run kita. Jika Cloud Run mulai mengembalikan status HTTP 429 atau mengalami kenaikan latensi, Eventarc akan menunda pengiriman event sementara di antrean Pub/Sub-nya (backpressure handling), mengalirkan event sesuai dengan kapasitas skalabilitas target tanpa meruntuhkan server backend kita.

Konfigurasi IaC: Trigger Eventarc via Terraform #

Mengelola konfigurasi Eventarc di tingkat produksi sangat direkomendasikan menggunakan tools Infrastructure as Code (IaC) seperti Terraform untuk menjamin reproduksibilitas antar environment. Di bawah ini adalah contoh kode Terraform untuk membuat Eventarc Trigger yang menangkap event pembuatan file baru di Cloud Storage dan mengirimkannya ke layanan Cloud Run.

# 1. Definisi Service Account khusus untuk Eventarc Trigger
resource "google_service_account" "eventarc_sa" {
  account_id   = "eventarc-trigger-sa"
  display_name = "Service Account khusus untuk Eventarc routing"
}

# 2. Memberikan izin agar Eventarc dapat memicu Cloud Run
resource "google_cloud_run_service_iam_member" "run_invoker" {
  service  = google_cloud_run_service.backend_service.name
  location = google_cloud_run_service.backend_service.location
  role     = "roles/run.invoker"
  member   = "serviceAccount:${google_service_account.eventarc_sa.email}"
}

# 3. Memberikan izin agar Eventarc dapat membaca log dari Cloud Storage
resource "google_project_iam_member" "eventarc_receiver" {
  project = var.project_id
  role    = "roles/eventarc.eventReceiver"
  member  = "serviceAccount:${google_service_account.eventarc_sa.email}"
}

# 4. Definisi Eventarc Trigger untuk mendeteksi file di Cloud Storage
resource "google_eventarc_trigger" "gcs_trigger" {
  name     = "gcs-upload-trigger"
  location = "asia-southeast2" # Region Jakarta

  # Menentukan target komputasi penerima event
  destination {
    cloud_run_service {
      service = google_cloud_run_service.backend_service.name
      region  = google_cloud_run_service.backend_service.location
      path    = "/events/gcs-upload" # Endpoint HTTP target
    }
  }

  # Menentukan filter event yang dicari
  matching_criteria {
    attribute = "type"
    value     = "google.cloud.storage.object.v1.finalized"
  }

  matching_criteria {
    attribute = "bucket"
    value     = google_storage_bucket.media_uploads.name
  }

  # Menghubungkan service account pengirim
  service_account = google_service_account.eventarc_sa.email

  # Dependensi eksplisit untuk menjamin urutan pembuatan resource
  depends_on = [
    google_cloud_run_service_iam_member.run_invoker,
    google_project_iam_member.eventarc_receiver
  ]
}

Perbandingan: Eventarc vs. Pub/Sub (Kapan Memilih yang Mana?) #

Banyak pengembang bingung membedakan peran Eventarc dengan Pub/Sub karena keduanya sama-sama digunakan untuk pengiriman pesan asinkron. Tabel di bawah memperjelas batasan peran masing-masing teknologi.

Pemantauan, Diagnostik, dan Tracing Distributed #

Mengelola sistem berbasis event membutuhkan visibilitas tingkat tinggi agar kita dapat mengidentifikasi di mana pesan terhambat saat terjadi masalah.

• Integrasi Cloud Logging: Setiap kali Eventarc Trigger menerima event dari sumber dan mengirimkannya ke target, ia menulis log audit penyerahan ke Cloud Logging. Kita dapat menggunakan kueri log terperinci di Cloud Logging Console untuk mendiagnosis pengiriman event:

  resource.type="eventarc_trigger"
  severity>=WARNING
  

  Kueri ini akan menampilkan semua kegagalan transmisi, termasuk kode status HTTP 4xx/5xx yang dikembalikan oleh Cloud Run target, mempermudah debugging penolakan request.
• Distributed Tracing dengan Cloud Trace: Eventarc secara native meneruskan header pelacakan terdistribusi W3C (traceparent) dari event publisher ke target HTTP. Dengan mengaktifkan Cloud Trace SDK di aplikasi target Cloud Run kita, kita dapat melihat visualisasi grafis garis waktu terperinci (timeline span) yang menunjukkan perjalanan satu event mulai dari saat file diunggah ke GCS, diproses oleh Eventarc, hingga selesai diproses oleh kode server kita di satu dasbor terpadu.
• Alerting pada Kegagalan DLQ: Untuk menjamin keamanan data produksi, kita direkomendasikan untuk memasang dasbor pemantauan (Cloud Monitoring alerting policy) yang mengawasi metrik pubsub.googleapis.com/topic/send_message_operation_count pada topic DLQ. Jika ada pesan yang masuk ke topic tersebut, tim operational akan menerima notifikasi otomatis via Slack atau PagerDuty untuk segera melakukan investigasi dan mencegah kehilangan data transaksi pengguna.

Best Practice Desain Event-Driven dengan Eventarc #

Terapkan prinsip-prinsip arsitektur berikut untuk menjamin keandalan sistem berbasis event kita:

1. Wajib Terapkan Idempotensi di Sisi Target #

Karena jaminan pengiriman At-Least-Once, pengiriman ulang event yang sama akibat kendala jaringan sesaat di akhir transaksi adalah hal yang wajar.

• BENAR: Baca atribut id yang ada di dalam metadata CloudEvents. Gunakan ID unik ini sebagai kunci unik deduplikasi di penyimpanan database atau caching Redis Anda. Jika ID event tersebut sudah pernah sukses diproses, segera kembalikan status HTTP 200 tanpa mengeksekusi ulang logika bisnis.

2. Konfigurasikan Service Account Berprinsip Least Privilege #

Hindari menggunakan service account default dengan akses luas untuk mendeploy trigger Eventarc.

• BENAR: Buat service account terisolasi untuk setiap trigger. Hanya berikan role roles/run.invoker khusus pada kontainer Cloud Run target penerima, serta role roles/eventarc.eventReceiver untuk menerima data event terkait.

3. Pilih Region yang Sama untuk Sumber dan Target Event #

Mendeploy bucket Cloud Storage di region us-central1, mendeploy trigger Eventarc di europe-west3, dan mendeploy target Cloud Run di asia-southeast2 akan menyebabkan latensi jaringan antar benua yang tinggi serta pembengkakan biaya transfer data keluar (egress bandwidth).

• BENAR: Lokasikan bucket data, trigger Eventarc, dan komputasi Cloud Run target di dalam satu region geografi yang sama (misalnya semuanya di asia-southeast2 Jakarta) untuk performa transmisi data terbaik.

Ringkasan #

• Google Cloud Eventarc adalah perute event serverless yang menyederhanakan pembangunan arsitektur event-driven di GCP.
• Mengadopsi standar CloudEvents v1.0 dari CNCF untuk menyeragamkan format payload data dari semua jenis event source.
• Memanfaatkan Cloud Audit Logs untuk menyulap lebih dari 130 layanan GCP menjadi sumber event reaktif secara otomatis.
• Menyediakan integrasi SaaS Partner Channels untuk menangkap event eksternal dari Auth0, Datadog, atau PagerDuty ke target GCP.
• Menjamin pengantaran At-Least-Once dengan retry eksponensial otomatis selama 24 jam dan dukungan Dead Letter Queue (DLQ).
• Gunakan Terraform untuk mendefinisikan trigger secara deklaratif guna memastikan konsistensi antar lingkungan dev/staging/prod.

← Sebelumnya: AppEngine   Berikutnya: Terraform →