Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengonsumsi data menggunakan infrastruktur di AWS.
Bird’s real-time event webhooks adalah alat yang sangat berharga bagi pengirim untuk memiliki data secara otomatis didorong ke sistem mereka. Ini dapat mendorong otomatisasi hilir seperti memperbarui daftar surat, memicu perjalan surel otomatis, atau mengisi dasbor internal. Meskipun data peristiwa yang sama dapat diakses melalui antarmuka pengguna Bird menggunakan Event Search, atau secara terprogram dengan memanfaatkan Bird Events API, batasan yang ditempatkan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batas laju yang ditempatkan pada ujung API dapat membuat kedua metode ini dianggap terbatas untuk pengirim besar dan canggih.
Webhooks peristiwa real-time memungkinkan pengirim untuk mengkonfigurasi endpoint di mana Bird mengirimkan data, dan data dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang mengambil data. Ada juga pertukaran logistik saat menarik data dibandingkan dengan memiliki data yang didorong kepada Anda, seperti harus mengidentifikasi periode waktu dan parameter apa yang harus digunakan untuk setiap permintaan API. Jika periode waktu tidak teratur, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, Anda harus menangani catatan data duplikat. Dengan real-time webhooks, data peristiwa cukup didorong ke endpoint Anda saat tersedia di dalam Bird.
Meskipun manfaat menerima data peristiwa secara real-time untuk mendorong proses otomatisasi hilir mungkin segera dipahami oleh banyak pengirim, proses sebenarnya untuk mengimplementasikan dan mengonsumsi webhooks mungkin menakutkan. Ini bisa berlaku terutama jika Anda tidak terbiasa dengan komponen teknis dalam pembuatan endpoint dan penanganan data secara terprogram. Ada layanan yang tersedia yang akan mengonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – sebagai contoh adalah StitchData, yang telah kita blogkan di masa lalu. Namun, jika Anda ingin lebih mengontrol prosesnya, Anda dapat dengan mudah membangun komponen itu sendiri. Berikut ini adalah panduan sederhana untuk membantu pengirim merasa nyaman ketika membuat webhook peristiwa Bird dan mengonsumsi data menggunakan infrastruktur dalam AWS.
Mengonfigurasi Target Endpoint Webhook
Ketika sebuah acara Bird dibuat, kami ingin data acara itu dialirkan secara real-time ke sebuah endpoint di AWS sehingga kami dapat mengonsumsi dan menggunakan data tersebut secara programatis. Data tersebut akan dikirim dari Bird ke endpoint target, yang akan meneruskan payload ke fungsi lambda yang akan memproses dan menyimpan data di S3 bucket. Diagram tingkat tinggi alur data yang dijelaskan dapat dilihat di bawah:
Untuk menerapkan alur kerja ini, mari kita bangun dari arah terbalik dimulai dengan membuat S3 bucket tempat kita akan menyimpan data acara kita dan kemudian bekerja mundur – menambahkan setiap komponen yang memberi umpan ke dalam apa yang telah kita bangun.
Buat S3 Bucket untuk Menyimpan Data Webhook
Sebelum membuat load balancer kami untuk menerima data, atau fungsi lambda kami untuk menyimpan data, kita perlu terlebih dahulu membuat S3 bucket tempat data akan disimpan. Meskipun S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan basis data PostgreSQL untuk pemrosesan acara harus menerapkan prosedur pencadangan dan pemulihan yang tepat untuk melindungi data terstruktur mereka bersama strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Create Bucket.” Anda akan diminta untuk memberikan nama pada bucket Anda dan menetapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Setelah bucket S3 Anda dibuat, ia akan kosong – jika Anda ingin mengatur data di dalam folder, Anda dapat membuat direktori yang dimaksudkan sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file tersebut. Dalam contoh ini, kami menamakan bucket S3 kami “bird-webhooks” dan membuat folder bernama “B Event Data” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Buat Fungsi Lambda untuk Mengonsumsi Data
Pemrosesan dan penyimpanan data yang sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh application load balancer (ALB) kami.
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda dalam AWS dan mengklik “Create Function.” Anda akan diminta untuk memberikan nama pada fungsi lambda Anda dan memilih bahasa pemrograman yang akan Anda gunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Untuk sementara, mari kita asumsikan bahwa aplikasi load balancer kita telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kita – lambda akan menerima payload termasuk seureigh pos pesan lengkap dan tubuh. Payload diteruskan ke fungsi lambda kita menggunakan objek “event” sebagai dictionary. Anda dapat merujuk ke headers dan body payload secara independen dengan mengakses objek “headers” dan “body” di dalam payload. Dalam contoh ini kami hanya akan membaca header “x-messagesystems-batch-id”, di mana batch ID adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan body sebagai flat file di S3; namun, Anda mungkin ingin menambahkan fungsi tambahan seperti pemeriksaan otentikasi atau penanganan kesalahan sesuai kebutuhan.
Saat menyimpan payload ke flat-file di S3, kita perlu menentukan nama bucket S3, lokasi, dan nama file tempat data payload akan disimpan. Dalam fungsi lambda sampel kami, kami melakukan ini dalam fungsi “store_batch”. Dalam contoh ini, kita akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan endpoint Anda habis waktu. Meskipun Anda dapat menyesuaikan pengaturan timeout koneksi pada load balancer Anda, tidak ada jaminan bahwa koneksi tidak akan habis waktu di sisi transmisi (dalam hal ini Bird) atau bahwa koneksi tidak akan dihentikan sebelum fungsi lambda Anda selesai dieksekusi. Sebaiknya jaga agar fungsi konsumen Anda seefisien mungkin dan simpan kegiatan pemrosesan data untuk proses hilir bila memungkinkan – seperti mengonversi payload dalam format JSON menjadi file CSV, atau memuat data acara ke dalam basis data.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran pelaksanaan Anda akan memerlukan izin PutObject dan GetObject untuk S3. Sebaiknya terapkan prinsip hak istimewa paling sedikit, jadi saya merekomendasikan menetapkan izin ini hanya untuk S3 bucket tempat payload webhook akan disimpan.
Sampel fungsi lambda konsumen kami dapat ditemukan di sini.
Sebagai catatan singkat tentang batch ID: Bird akan membatching acara ke dalam satu payload, di mana setiap batch dapat berisi 1 hingga 350 atau lebih catatan acara. Batch akan diberikan batch ID unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan Event Webhooks API atau di dalam akun Bird Anda dengan mengklik webhook stream dan memilih “Batch Status.” Dalam hal payload webhook tidak dapat dikirimkan, seperti selama timeout koneksi, Bird akan secara otomatis mencoba ulang batch menggunakan batch ID yang sama. Ini dapat terjadi saat fungsi lambda Anda berjalan mendekati waktu perjalanan pulang maksimum 10 detik dan merupakan alasan untuk mengoptimalkan fungsi konsumen untuk mengurangi waktu eksekusi.
Untuk menangani semua kegiatan pemrosesan data, saya sarankan membuat fungsi lambda terpisah yang dijalankan setiap kali file baru dibuat di S3 bucket – dengan cara ini, pemrosesan data dilakukan secara asinkron terhadap transmisi nya data, dan tidak ada risiko kehilangan data karena koneksi terputus. Saya membahas fungsi lambda pemrosesan di bagian selanjutnya.
Buat Application Load Balancer
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload. Kami melakukan ini dengan membuat application load balancer di dalam AWS dengan navigasi ke EC2 > Load Balancers dan mengklik “Create Load Balancer.” Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kami ingin membuat application load balancer. Kami perlu menggunakan application load balancer (ALB) untuk membangun konsumen kami karena event webhooks akan dikirim sebagai HTTP request, dan ALB digunakan untuk routing HTTP request di dalam AWS. Kami dapat menerapkan HTTP Gateway sebagai alternatif; namun, kami menggunakan ALB untuk proyek ini karena lebih ringan dan hemat biaya dibandingkan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih menggunakan HTTP Gateway, format acara mungkin berbeda dari dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan sesuai.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama pada ALB Anda dan mengonfigurasi skema dan pengaturan akses/keamanan – karena kami berencana menerima data acara dari sumber eksternal (Bird), kami menginginkan ALB kami internet-facing. Di bawah “Listeners and routing,” ALB harus mendengarkan HTTPS pada port 443, dan kami ingin membuat Target group yang menunjuk ke fungsi lambda kami sehingga ALB kami akan meneruskan permintaan masuk ke fungsi lambda konsumsi yang kami buat di atas. Anda juga perlu memastikan bahwa security group memiliki izin untuk menerima lalu lintas melalui port 443.
Buat Catatan DNS untuk Load Balancer
Untuk mempermudah penggunaan ALB sebagai endpoint, kami akan membuat A record di DNS yang menunjuk ke ALB kami. Untuk ini, kita dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat A record untuk hostname yang ingin Anda gunakan untuk endpoint Anda (misalnya spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, waspadai bahwa ada batasan DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi dengan volume tinggi, terutama yang menangani lalu lintas keluar dalam jumlah besar seperti sistem pengiriman email. A record harus dikonfigurasi untuk menunjuk ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus menunjuk A record ke alamat IP publik dari instance ALB.
Saya sarankan menggunakan alat seperti Postman untuk menguji apakah semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat membuat POST request ke endpoint Anda dan mengonfirmasi bahwa sebuah response diterima. Jika POST request Anda tidak mengembalikan response, Anda mungkin perlu memeriksa kembali bahwa ALB Anda mendengarkan port yang benar.
Buat Bird Webhook
Sekarang kami siap membuat webhook di Bird dan menggunakan hostname yang didefinisikan oleh A record di atas sebagai target endpoint kami. Untuk membuat webhook, navigasi ke bagian Webhooks di dalam akun Bird Anda dan klik “Create Webhook.” Anda akan diminta untuk memberikan nama pada webhook Anda dan menyediakan URL target – target harus berupa hostname dari A record yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi bahwa subaccount yang tepat dan acara dipilih, dan tekan “Create Webhook” untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan dialirkan ke target URL kami dan dikonsumsi oleh ALB kami untuk pemrosesan hilir.
