Pemrosesan Berbasis Kejadian untuk Komunikasi Asinkron

Pada posting pertama dalam seri ini tentang pola perpesanan (messaging pattern), kami memberikan tinjauan umum tentang olahpesan (messaging) serta manfaat dan tantangan komunikasi layanan sinkron dan asinkron. Dalam posting ini, kita akan melihat karakteristik umum yang perlu dipertimbangkan ketika mengevaluasi teknologi kanal olahpesan (messaging channel). Kami juga akan memperkenalkan Amazon EventBridge, sebuah serverless event bus dari AWS.

Apa Itu Kejadian (Event)?

Suatu kejadian (event) adalah terjadinya sebuah pesan yang tidak dapat berubah (immutable) yang menggambarkan sesuatu yang terjadi di masa lalu. Muatan (payload) data dari event biasanya berisi detail kejadian dan juga metadata terkait. Event dialihkan dari produsen ke konsumen potensial melalui kanal transportasi, sebagaimana dijelaskan dalam tulisan sebelumnya dalam seri ini. Event ini dapat dikirimkan ke nol, satu, atau banyak konsumen, tergantung pada jumlah konsumen yang berlangganan (subscribe) pada kanal transportasi tersebut, dan mungkin bisa jadi hanya terbatas pada konsumen yang berlangganan tapi mereka telah memfilter langganan mereka ke event-event tertentu saja.

Di bawah ini adalah contoh sebuah AWS event. Sebuah AWS event diterbitkan oleh layanan AWS, direpresentasikan sebagai objek JSON, berisi bagian-bagian yang merupakan metadata dan juga berisi muatan (payload) khusus dari sumber layanan AWS pada bagian “detail”-nya.

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2017-12-22T18:43:48Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:123456789012:instance/ i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": " i-1234567890abcdef0",
    "state": "terminated"
  }
}

Skema Event

Melihat contoh event di atas dan merujuk ke dokumentasi tentang AWS event, Anda akan melihat ada skema untuk bagian-bagian (fields) tingkat atas dari semua event dan skema terpisah untuk atribut khusus sumber di bagian “detail”. Ini karena beberapa layanan AWS menerbitkan event ke message bus bawaan dari Amazon EventBridge. Tidak seperti HTTP API, yang sering memiliki skema yang dipublikasikan dan adanya proses validasi request terhadap skema itu, pada kanal transportasi event biasanya memungkinkan event yang heterogen melewati kanal tersebut, seperti pada bus bawaan di EventBridge.

Untuk menyederhanakan pengalaman dalam mendefinisikan, menemukan, dan mengembangkan skema suatu event, Amazon EventBridge memiliki Schema Registry. Registry tersebut sudah diisi sebelumnya dengan skema OpenAPI untuk event-event dari layanan AWS dan memungkinkan Anda untuk menentukan skema Anda sendiri. Registry juga mendukung pengunduhan code bindings untuk bahasa pemrograman populer untuk suatu skema tertentu yang ada dalam registry.

Karakteristik kanal event

Saat mengevaluasi teknologi kanal event (event channel) terhadap kebutuhan bisnis dan teknis Anda, perhatikan karakteristik umum berikut. Daftar ini tidak lengkap, tetapi dapat menjadi titik awal yang berguna dalam mengarahkan Anda ke pemilihan teknologi yang tepat.

Urutan (ordering): Apakah event dijamin akan dikirimkan sesuai dengan urutan kedatangannya?
Duplikasi: Bisakah event yang sama (duplikat) diperbolehkan? Apakah duplikat event di kanal akan dihilangkan (de-duplication)?
Fanout: Dapatkah setiap event dikirim atau diproses oleh banyak konsumen?
Push versus pull: Apakah event dikirimkan ke konsumen atau apakah konsumen yang perlu mengambil event?
Pemfilteran: Dapatkah konsumen event memilih untuk menerima sebagian saja dengan penyaringan dari semua event yang melewati kanal?
Serverless: Apakah infrastruktur yang digunakan dapat dikelola dan disetel oleh pemilik kanal?

Amazon EventBridge

Amazon EventBridge adalah event bus yang serverless dan dikelola sepenuhnya oleh AWS. Produsen dapat berupa layanan AWS, Software as a Service (SaaS) dari mitra yang didukung, atau aplikasi Anda sendiri yang menulis pesan JSON ke event bus dari EventBridge. Pesan dikirimkan ke konsumen yang dikonfigurasi sebagai target pada suatu aturan event (event rule). Aturan event dapat memfilter pesan berdasarkan atribut dalam muatan JSON, dan sebuah aturan dapat merutekan event ke beberapa target. Aturan event akan mencoba lagi pengiriman event ke target yang telah dikonfigurasi dengan backoff eksponensial hingga maksimum 24 jam. EventBridge tidak menjamin urutan event akan tetap dipertahankan dan menjamin pengiriman event setidaknya sekali (as-least-once delivery), yang berarti dapat terjadi pesan duplikat. Pertimbangkan untuk menggunakan EventBridge pada kasus di mana Anda memerlukan pemfilteran event yang rumit, penyebaran (fanout) event ke puluhan konsumen, pengiriman atau konsumsi pesan lintas akun AWS, juga untuk mendapatkan event dari berbagai layanan AWS, atau untuk menerima pesan dari sistem mitra SaaS.

Kesimpulan

Dalam tulisan ini, kami menjelaskan definisi event dan menguraikan kriteria untuk mengevaluasi teknologi transportasi event. Kami kemudian secara singkat meninjau Amazon EventBridge dengan kriteria ini. Untuk diskusi lebih lanjut tentang eventing technology, saya sarankan Anda menonton rekaman sesi Moving to Event-Driven Architectures dari acara AWS re:Invent 2019, oleh Tim Bray, seorang AWS Distinguished Engineer. Untuk menyelami lebih dalam tentang Amazon EventBridge, silakan tonton AWS Tech Talk ini. Untuk contoh cara mengintegrasikan Amazon EventBridge dalam arsitektur serverless, silakan baca tulisan ini yang membahas sebuah contoh aplikasi.

Dalam seri tulisan tentang Olahpesan (Messaging) ini

Sekarang Anda memahami karakteristik umum untuk dipertimbangkan saat mengevaluasi teknologi kanal olahpesan, pastikan untuk membaca posting selanjutnya dalam seri ini:

Tulisan ini berasal dari artikel Event-Based Processing for Asynchronous Communication yang ditulis oleh Roberto Iturralde dan diterjemahkan oleh Eryan Ariobowo.

Blog AWS Indonesia