Webhook acara waktu nyata Bird adalah alat yang sangat berharga bagi pengirim untuk memiliki data yang secara otomatis didorong ke sistem mereka. Ini dapat memicu otomatisasi lebih lanjut seperti memperbarui daftar milis, memicu perjalanan email otomatis, atau mengisi dasbor internal. Sementara data acara yang sama dapat diakses melalui Antarmuka Pengguna Bird menggunakan Pencarian Acara, atau secara programatis dengan memanfaatkan Bird API Acara, batasan yang ditempatkan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batasan kecepatan yang ditempatkan pada titik akhir API dapat membuat kedua metode ini membatasi bagi pengirim yang besar dan canggih.
Webhook acara waktu nyata memungkinkan pengirim untuk mengonfigurasi titik akhir di mana Bird mengirimkan data, dan data dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang mengambil data tersebut. Ada juga trade-off logistik saat menarik data dibandingkan dengan memiliki data yang didorong kepada Anda, seperti harus mengidentifikasi periode waktu dan parameter yang digunakan untuk setiap permintaan API. Jika periode waktu tidak diselaraskan dengan sempurna, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, maka Anda perlu menangani catatan data duplikat. Dengan webhook waktu nyata, data acara cukup didorong ke titik akhir Anda saat tersedia dalam Bird.
Sementara manfaat menerima data acara dalam waktu nyata untuk memicu proses otomatisasi berikutnya mungkin langsung dipahami oleh banyak pengirim, proses nyata untuk mengimplementasikan dan mengonsumsi webhook mungkin menakutkan. Ini bisa sangat benar jika Anda tidak terbiasa dengan komponen teknis untuk membuat titik akhir dan menangani data secara programatis. Ada layanan yang tersedia yang akan mengkonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – contohnya adalah StitchData, yang telah kami bahas di blog kami sebelumnya. Namun, jika Anda ingin lebih mengontrol prosesnya, Anda dapat dengan mudah membangun komponen itu sendiri. Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengkonsumsi data menggunakan infrastruktur dalam AWS.
Mengonfigurasi Titik Akhir Target Webhook
Ketika sebuah acara Bird dibuat, kami ingin data acara tersebut disiarkan secara waktu nyata ke titik akhir di AWS sehingga kami dapat mengonsumsi dan menggunakan data tersebut secara programatis. Data akan dikirim dari Bird ke titik akhir target, yang akan meneruskan payload ke fungsi lambda yang akan memproses dan menyimpan data dalam bucket S3. Diagram tingkat tinggi dari alur data yang digambarkan dapat dilihat di bawah:
Untuk menerapkan alur kerja ini, mari kita benar-benar membangunnya dalam urutan terbalik dimulai dengan membuat bucket S3 di mana kami akan menyimpan data acara kami dan kemudian bekerja mundur – menambahkan setiap komponen yang diberi makan ke dalam apa yang telah kami bangun.
Membuat Bucket S3 untuk Menyimpan Data Webhook
Sebelum membuat penyeimbang beban kami untuk menerima data, atau fungsi lambda kami untuk menyimpan data, kami perlu terlebih dahulu membuat bucket S3 di mana data akan disimpan. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Buat Bucket.” Anda akan diminta untuk memberikan nama untuk bucket Anda dan menyiapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Ketika bucket S3 Anda dibuat, itu akan kosong – jika Anda ingin mengorganisir data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori tersebut akan dibuat saat fungsi lambda Anda menyimpan file. Dalam contoh ini, kami menamai bucket S3 kami “bird-webhooks” dan membuat folder bernama “B Data Acara” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Membuat Fungsi Lambda untuk Mengonsumsi Data
Proses dan penyimpanan data yang sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh penyeimbang beban aplikasi kami (ALB).
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda dalam AWS dan mengklik “Buat Fungsi.” Anda akan diminta untuk memberikan nama untuk fungsi lambda Anda dan memilih bahasa pemrograman yang digunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Sebentar, mari kita anggap bahwa penyeimbang beban aplikasi kami telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kami – lambda akan menerima payload yang menyertakan seluruh header dan tubuh. Payload diteruskan ke fungsi lambda kami menggunakan objek “event” sebagai kamus. Anda dapat merujuk header dan tubuh payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami hanya akan membaca header “x-messagesystems-batch-id,” di mana ID batch adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan tubuh sebagai file datar dalam S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan otentikasi atau penanganan kesalahan, sesuai kebutuhan.
Saat menyimpan payload ke file datar di S3, kami perlu mendefinisikan nama bucket S3, lokasi, dan nama file tempat data payload akan disimpan. Dalam contoh fungsi lambda kami, kami melakukan ini dalam fungsi “store_batch.” Dalam contoh ini, kami akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan titik akhir Anda habis waktu. Meskipun Anda bisa menyesuaikan pengaturan timeout koneksi pada penyeimbang beban 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. Merupakan praktik terbaik untuk menjaga fungsi konsumen Anda seefisien mungkin dan menyimpan kegiatan pemrosesan data untuk proses hilir jika memungkinkan – seperti mengonversi payload berformat JSON yang dikelompokkan menjadi file CSV, atau memuat data acara ke dalam basis data.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Role eksekusi Anda perlu memiliki izin PutObject dan GetObject untuk S3. Merupakan praktik terbaik untuk menerapkan prinsip hak akses minimal, jadi saya sarankan untuk mengatur izin ini hanya untuk bucket S3 tempat payload webhook akan disimpan.
Contoh fungsi konsumen lambda kami dapat ditemukan di sini.
Sebagai catatan cepat tentang ID batch: Bird akan mengelompokkan acara menjadi satu payload, di mana setiap batch dapat berisi 1 hingga 350 catatan acara atau lebih. Batch akan diberikan ID batch yang unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan API Webhook Acara atau dalam akun Bird Anda dengan mengklik stream webhook dan memilih “Status Batch.” Dalam kemungkinan bahwa payload webhook tidak dapat dikirim, seperti selama waktu tunggu koneksi, Bird akan secara otomatis mengulangi batch menggunakan ID batch yang sama. Ini dapat terjadi ketika fungsi lambda Anda berjalan mendekati waktu perjalanan 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 bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron terhadap transmisi data, dan tidak ada risiko kehilangan data akibat koneksi yang terputus. Saya membahas fungsi lambda pemrosesan dalam bagian selanjutnya.
Membuat Penyeimbang Beban Aplikasi
Untuk menerima payload webhook, kami perlu menyediakan titik akhir untuk mengirimkan payload. Kami melakukannya dengan membuat penyeimbang beban aplikasi dalam AWS dengan menavigasi ke EC2 > Penyeimbang Beban dan mengklik “Buat Penyeimbang Beban.” Anda akan diminta untuk memilih jenis penyeimbang beban yang ingin Anda buat – untuk ini, kami ingin membuat penyeimbang beban aplikasi. Kami perlu menggunakan penyeimbang beban aplikasi (ALB) untuk membangun konsumen kami karena webhook acara akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk merutekan permintaan HTTP dalam AWS. Kami bisa menerapkan HTTP Gateway sebagai alternatif; namun, kami menggunakan ALB untuk proyek ini karena lebih ringan dan lebih hemat biaya daripada HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format acara mungkin berbeda dibandingkan dengan ALB, dan karena itu fungsi lambda Anda perlu menangani objek permintaan sesuai dengan itu.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama untuk ALB Anda dan mengonfigurasi skema dan pengaturan akses/keamanan – karena kami berencana menerima data acara dari sumber eksternal (Bird), kami ingin ALB kami menjadi dapat diakses dari internet. Di bawah “Pendengar dan pengaturan,” ALB harus mendengarkan HTTPS di port 443, dan kami ingin membuat grup Target yang mengarah 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 grup keamanan memiliki izin untuk menerima lalu lintas melalui port 443.
Membuat Rekor DNS untuk Penyeimbang Beban
Untuk mempermudah kami menggunakan ALB kami sebagai titik akhir, kami akan membuat rekaman A di DNS yang mengarah ke ALB kami. Untuk ini, kami dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat rekaman A untuk hostname yang ingin Anda gunakan sebagai titik akhir Anda (misalnya, spevents.<your_domain>). Rekaman A harus dikonfigurasi untuk mengarah ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk langsung ke instance ALB dengan mengaktifkan “Alias” dan memilih ALB; sebaliknya, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan rekaman A ke alamat IP publik dari instance ALB.
Saya sarankan menggunakan alat seperti Postman untuk menguji bahwa semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat membuat permintaan POST ke titik akhir Anda dan mengonfirmasi bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa kembali bahwa ALB Anda mendengarkan ke port yang benar.
Membuat Webhook Bird
Sekarang kami siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh rekaman A di atas sebagai titik akhir target kami. Untuk membuat webhook, navigasikan ke bagian Webhook dalam akun Bird Anda dan klik “Buat Webhook.” Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target – target harus merupakan hostname dari rekaman A yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi bahwa subakun yang benar dan acara yang dipilih sudah benar, dan tekan “Buat Webhook” untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan disiarkan ke URL target kami dan dikonsumsi oleh ALB kami untuk pemrosesan hilir.
Memproses Data Acara Webhook
Terlepas dari tujuan yang dimaksudkan untuk menyimpan data acara Bird, kebutuhan Anda mungkin terpenuhi dengan hanya menyimpan payload JSON sebagai file datar. Anda mungkin juga sudah memiliki proses ETL hilir yang mampu mengkonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh fungsi lambda pemrosesan kami yang kami buat di atas apa adanya.
Atau, Anda mungkin perlu melakukan transformasi data – seperti mengonversi dari format JSON ke format CSV – atau memuat data langsung ke dalam basis data. Dalam contoh ini, kami akan membuat fungsi lambda sederhana yang akan mengonversi data webhook dari format JSON asli menjadi file CSV yang dapat dimuat ke dalam basis data.
Membuat Lambda untuk Memproses Data
Seperti halnya fungsi lambda untuk mengkonsumsi data webhook, kami perlu membuat fungsi lambda baru dengan menavigasi ke layanan Lambda dalam AWS dan menekan “Buat Fungsi.” Fungsi lambda baru ini akan dipicu ketika file baru dibuat di bucket S3 kami – itu akan membaca data dan mengonversinya menjadi file csv baru.
Fungsi lambda menerima informasi file sebagai peristiwa. Dalam contoh fungsi lambda, Anda akan melihat bahwa kami terlebih dahulu memiliki serangkaian pemeriksaan validasi untuk memastikan bahwa data lengkap dan diformat sesuai harapan. Selanjutnya, kami mengonversi payload JSON menjadi file CSV dengan menggunakan pustaka “csv” dan menulis ke file sementara. Fungsi lambda hanya dapat menulis file lokal ke direktori “/tmp,” jadi kami membuat file csv sementara dan menamakannya dengan konvensi <batch_id>.csv. Alasan kami menggunakan batch_id di sini hanyalah untuk memastikan bahwa pemrosesan paralel yang dijalankan sebagai akibat dari menerima beberapa payload webhook tidak akan saling mengganggu, karena setiap batch webhook akan memiliki batch_id yang unik.
Setelah data sepenuhnya dikonversi ke CSV, kami membaca data CSV sebagai aliran byte, menghapus file sementara, dan menyimpan data CSV sebagai file baru di S3. Penting untuk dicatat bahwa bucket S3 yang berbeda diperlukan untuk output, jika tidak, kami berisiko menciptakan loop rekursif yang dapat mengakibatkan peningkatan penggunaan lambda dan biaya yang meningkat. Kami perlu mengidentifikasi di bucket S3 mana dan lokasi kami ingin file CSV kami disimpan dalam fungsi lambda kami. Ikuti prosedur yang sama seperti di atas untuk membuat bucket S3 baru untuk menyimpan file CSV kami.
Perhatikan bahwa direktori tmp dibatasi hingga 512 MB ruang, jadi penting bahwa file sementara dihapus setelah itu untuk memastikan ruang yang cukup untuk eksekusi di masa mendatang. Alasan kami menggunakan file sementara, daripada menulis langsung ke S3, adalah untuk menyederhanakan sambungan ke S3 dengan memiliki satu permintaan.
Sama seperti dengan fungsi lambda konsumsi, Anda mungkin perlu memperbarui izin untuk fungsi lambda proses Anda. Fungsi lambda ini memerlukan role eksekusi untuk memiliki izin GetObject untuk bucket S3 input, dan PutObject serta GetObject untuk bucket S3 output.
Contoh fungsi lambda pemrosesan kami dapat ditemukan di sini.
Konfigurasi Lambda untuk Menjalankan Ketika Data Baru Disimpan di S3
Sekarang bahwa fungsi lambda kami untuk mengonversi file dari format JSON ke CSV telah dibuat, kami perlu mengonfigurasinya untuk memicu ketika file baru dibuat di bucket S3 kami. Untuk melakukan ini, kami perlu menambahkan pemicu ke fungsi lambda kami dengan membuka fungsi lambda kami dan mengklik “Tambah Pemicu” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 di mana payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan prefiks dan/atau akhiran file untuk difilter. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Tambah” di bagian bawah halaman. Sekarang fungsi lambda pemrosesan Anda akan dieksekusi setiap kali file baru ditambahkan ke bucket S3 Anda.
Memuat Data ke dalam Basis Data
Dalam contoh ini, saya tidak akan mencakup pemuatan data ke dalam basis data secara detail, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Memuat data langsung ke basis data Anda dalam fungsi lambda pemrosesan Anda
Mengkonsumsi file CSV Anda menggunakan proses ETL yang telah ditetapkan
Apakah Anda menggunakan layanan basis data AWS, seperti RDS atau DynamoDB, atau Anda memiliki basis data PostgreSQL sendiri (atau yang serupa), Anda dapat terhubung ke layanan basis data Anda langsung dari fungsi lambda proses Anda. Misalnya, dengan cara yang sama bahwa kami memanggil layanan S3 menggunakan “boto3” dalam fungsi lambda kami, Anda juga dapat menggunakan “boto3” untuk memanggil RDS atau DynamoDB. Layanan AWS Athena juga dapat digunakan untuk membaca file data secara langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya sarankan untuk merujuk ke dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik untuk mencapai ini dalam lingkungan Anda.
Demikian pula, ada banyak layanan yang tersedia yang dapat membantu mengkonsumsi file CSV dan memuat data ke dalam basis data. Anda mungkin sudah memiliki proses ETL yang telah ditetapkan yang dapat Anda manfaatkan.
Kami berharap Anda menemukan panduan ini bermanfaat – selamat mengirim!