Membuat dan Mengkonsumsi Webhook Burung
Burung
27 Jan 2022
1 min read
Poin Penting
Webhook kejadian waktu nyata Bird memungkinkan pengirim menerima data kejadian secara instan—tanpa polling, tanpa pekerjaan cron, dan tanpa masalah batasan laju.
Webhook menghilangkan kompleksitas pengelolaan jendela waktu, mencegah kejadian yang terlewat dan menangani catatan duplikat.
Ideal untuk otomatisasi hulu: memperbarui daftar, memulai perjalanan, memperkaya dasbor, atau menyinkronkan sistem internal.
Tutorial ini memandu pengirim dalam membangun saluran masuk AWS penuh: penyimpanan S3, pemrosesan Lambda, dan penyeimbang beban aplikasi.
S3 berfungsi sebagai lapisan penyimpanan pusat untuk muatan webhook, dengan setiap batch ditulis sebagai file JSON datar.
Fungsi Lambda menangani baik pengambilan (menyimpan batch mentah) dan transformasi (mengonversi JSON ke CSV).
Batch kejadian Bird—setiap batch webhook mencakup
x-messagesystems-batch-idunik, memungkinkan pemeriksaan pemutaran dan deduplikasi.Lambda konsumen harus tetap efisien karena Bird mencoba ulang batch jika titik akhir tidak merespons dalam ~10 detik.
AWS ALB disarankan (dibandingkan API Gateway) untuk kesederhanaan, efektivitas biaya, dan penanganan langsung permintaan HTTP POST.
DNS (Route 53 atau penyedia eksternal) dikonfigurasi untuk memetakan nama host yang ramah ke titik akhir ALB.
Setelah pengaturan, Bird mengirimkan data kejadian secara langsung dan andal ke saluran AWS Anda untuk pemrosesan asinkron.
Panduan ini juga mencakup praktik terbaik: izin IAM dengan hak minimum, batasan penyimpanan sementara, menghindari pemicu rekursif, dan mengorganisir alur kerja multi-lambda.
Sorotan Tanya jawab
Apa tujuan utama dari webhook acara waktu nyata Bird?
Untuk mengirim data peristiwa langsung ke titik akhir pengirim secara real time, memungkinkan otomatisasi segera tanpa polling atau panggilan API yang dibatasi oleh laju.
Mengapa webhook lebih baik daripada menarik data melalui API untuk pengirim besar?
Sebab pengambilan API memerlukan manajemen jendela waktu, risiko data yang hilang atau duplikat, dan mungkin mencapai batas laju—webhook menghilangkan semua itu dengan mendorong data secara terus-menerus.
Layanan AWS apa yang digunakan dalam saluran penerimaan webhook yang direkomendasikan?
Amazon S3 (penyimpanan), AWS Lambda (pemrosesan), sebuah Application Load Balancer (pendengar HTTP), dan opsional Route 53 (DNS).
Bagaimana cara Bird mengelola data acara dalam kelompok?
Burung mengirim beberapa peristiwa bersama dalam sebuah payload, masing-masing diberi ID batch yang unik (x-messagesystems-batch-id) untuk pelacakan, pengulangan, dan deduplikasi.
Apa yang memicu fungsi Lambda konsumen?
ALB meneruskan permintaan POST webhook yang masuk langsung ke Lambda, yang mengekstrak payload dan menuliskannya ke S3.
Mengapa menyimpan batch webhook mentah di S3 sebelum memprosesnya?
Untuk memastikan ingest cepat (<10 detik) sehingga koneksi tidak timeout, dan untuk membebankan pemrosesan yang lebih berat ke pipeline async terpisah.
Apa yang dilakukan fungsi Lambda kedua?
Ini dipicu oleh objek S3 baru, memvalidasi JSON, mengonversinya ke CSV, dan menulis output yang diproses ke bucket S3 terpisah.
Mengapa menggunakan bucket S3 terpisah untuk file CSV yang diproses?
Untuk menghindari pemicu rekursif (menulis file yang sudah diproses kembali ke dalam bucket yang sama akan memicu Lambda tanpa henti).
Izin apa yang diperlukan oleh fungsi Lambda?
Konsumen Lambda membutuhkan izin S3 PutObject; Lambda pemrosesan membutuhkan GetObject untuk bucket sumber dan PutObject untuk bucket tujuan.
Mengapa AWS ALB disarankan dibandingkan API Gateway?
ALB lebih murah, lebih sederhana, dan ideal untuk penerusan HTTPS POST yang sederhana; API Gateway dapat mengubah format payload dan meningkatkan kompleksitas.
Bagaimana pengirim mengonfigurasi webhook di Bird?
Dengan menyediakan endpoint HTTPS (catatan DNS untuk ALB), memilih subakun, memilih acara, dan menyimpan konfigurasi webhook.
Apa opsi hilir yang ada untuk menyimpan atau menganalisis data yang telah diproses?
Muat ke dalam basis data (PostgreSQL, DynamoDB, RDS), masukkan ke dalam sistem ETL, atau kueri langsung dengan alat seperti Athena.
Webhook acara waktu nyata Bird adalah alat yang sangat berharga bagi pengirim untuk mendapatkan data yang secara otomatis dikirim ke sistem mereka. Ini dapat mendorong otomatisasi mendatang seperti memperbarui daftar email, memicu perjalanan email otomatis, atau mengisi dasbor internal. Sementara data acara yang sama dapat diakses melalui UI Bird menggunakan Pencarian Acara, atau secara programatis dengan memanfaatkan API Acara Bird, batasan yang dikenakan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batasan laju yang diterapkan pada titik akhir API dapat membuat kedua metode ini terbatas 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 menarik data. Ada juga pertukaran logistik ketika menarik data dibandingkan dengan mengizinkan data dikirimkan kepada Anda, seperti harus mengidentifikasi rentang waktu dan parameter yang akan digunakan untuk setiap permintaan API. Jika rentang waktu tidak disusun dengan sempurna, Anda berisiko kehilangan data, dan jika rentang waktu tumpang tindih, Anda perlu menangani catatan data duplikat. Dengan webhook waktu nyata, data acara langsung dikirim ke titik akhir Anda saat tersedia di dalam Bird.
Sementara manfaat menerima data acara secara real-time untuk mendorong proses otomatisasi downstream mungkin segera dipahami oleh banyak pengirim, proses nyata untuk menerapkan dan mengkonsumsi webhook mungkin menakutkan. Ini mungkin terutama berlaku jika Anda tidak akrab dengan komponen teknis untuk membuat titik akhir dan menangani data secara programatis. Terdapat layanan yang tersedia yang akan mengkonsumsi data webhook Bird dan ETL ke dalam database Anda secara otomatis - contohnya adalah StitchData, yang telah kami bahas di blog sebelumnya. Namun, jika Anda ingin lebih banyak kontrol atas proses tersebut, Anda dapat dengan mudah membangun komponen tersebut sendiri. Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengkonsumsi data menggunakan infrastruktur di dalam AWS.
Webhook acara waktu nyata Bird adalah alat yang sangat berharga bagi pengirim untuk mendapatkan data yang secara otomatis dikirim ke sistem mereka. Ini dapat mendorong otomatisasi mendatang seperti memperbarui daftar email, memicu perjalanan email otomatis, atau mengisi dasbor internal. Sementara data acara yang sama dapat diakses melalui UI Bird menggunakan Pencarian Acara, atau secara programatis dengan memanfaatkan API Acara Bird, batasan yang dikenakan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batasan laju yang diterapkan pada titik akhir API dapat membuat kedua metode ini terbatas 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 menarik data. Ada juga pertukaran logistik ketika menarik data dibandingkan dengan mengizinkan data dikirimkan kepada Anda, seperti harus mengidentifikasi rentang waktu dan parameter yang akan digunakan untuk setiap permintaan API. Jika rentang waktu tidak disusun dengan sempurna, Anda berisiko kehilangan data, dan jika rentang waktu tumpang tindih, Anda perlu menangani catatan data duplikat. Dengan webhook waktu nyata, data acara langsung dikirim ke titik akhir Anda saat tersedia di dalam Bird.
Sementara manfaat menerima data acara secara real-time untuk mendorong proses otomatisasi downstream mungkin segera dipahami oleh banyak pengirim, proses nyata untuk menerapkan dan mengkonsumsi webhook mungkin menakutkan. Ini mungkin terutama berlaku jika Anda tidak akrab dengan komponen teknis untuk membuat titik akhir dan menangani data secara programatis. Terdapat layanan yang tersedia yang akan mengkonsumsi data webhook Bird dan ETL ke dalam database Anda secara otomatis - contohnya adalah StitchData, yang telah kami bahas di blog sebelumnya. Namun, jika Anda ingin lebih banyak kontrol atas proses tersebut, Anda dapat dengan mudah membangun komponen tersebut sendiri. Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengkonsumsi data menggunakan infrastruktur di dalam AWS.
Webhook acara waktu nyata Bird adalah alat yang sangat berharga bagi pengirim untuk mendapatkan data yang secara otomatis dikirim ke sistem mereka. Ini dapat mendorong otomatisasi mendatang seperti memperbarui daftar email, memicu perjalanan email otomatis, atau mengisi dasbor internal. Sementara data acara yang sama dapat diakses melalui UI Bird menggunakan Pencarian Acara, atau secara programatis dengan memanfaatkan API Acara Bird, batasan yang dikenakan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batasan laju yang diterapkan pada titik akhir API dapat membuat kedua metode ini terbatas 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 menarik data. Ada juga pertukaran logistik ketika menarik data dibandingkan dengan mengizinkan data dikirimkan kepada Anda, seperti harus mengidentifikasi rentang waktu dan parameter yang akan digunakan untuk setiap permintaan API. Jika rentang waktu tidak disusun dengan sempurna, Anda berisiko kehilangan data, dan jika rentang waktu tumpang tindih, Anda perlu menangani catatan data duplikat. Dengan webhook waktu nyata, data acara langsung dikirim ke titik akhir Anda saat tersedia di dalam Bird.
Sementara manfaat menerima data acara secara real-time untuk mendorong proses otomatisasi downstream mungkin segera dipahami oleh banyak pengirim, proses nyata untuk menerapkan dan mengkonsumsi webhook mungkin menakutkan. Ini mungkin terutama berlaku jika Anda tidak akrab dengan komponen teknis untuk membuat titik akhir dan menangani data secara programatis. Terdapat layanan yang tersedia yang akan mengkonsumsi data webhook Bird dan ETL ke dalam database Anda secara otomatis - contohnya adalah StitchData, yang telah kami bahas di blog sebelumnya. Namun, jika Anda ingin lebih banyak kontrol atas proses tersebut, Anda dapat dengan mudah membangun komponen tersebut sendiri. Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengkonsumsi data menggunakan infrastruktur di dalam AWS.
Mengonfigurasi Endpoint Target Webhook
Ketika acara Bird dibuat, kami ingin data acara tersebut disiarkan secara real-time 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 di bucket S3. Diagram tingkat tinggi dari alur data yang dijelaskan dapat dilihat di bawah:
Komponen | Tanggung Jawab |
|---|---|
Webhook Bird | Emit batch acara real-time sebagai permintaan HTTP POST |
Application Load Balancer | Menerima lalu lintas webhook eksternal dan mengarahkan permintaan |
Lambda (Konsumen) | Menyimpan batch webhook mentah ke S3 dengan efisien |
Amazon S3 | Menyimpan payload acara yang dibundel sebagai file JSON datar |
Lambda (Pengolah) | Transformasi atau memuat data yang disimpan secara asinkron |
Untuk menerapkan alur kerja ini, mari kita benar-benar membangunnya dalam urutan terbalik dimulai dengan membuat bucket S3 tempat kami akan menyimpan data acara kami dan kemudian bekerja mundur – menambahkan setiap komponen yang terhubung dengan apa yang telah kami bangun.
Ketika acara Bird dibuat, kami ingin data acara tersebut disiarkan secara real-time 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 di bucket S3. Diagram tingkat tinggi dari alur data yang dijelaskan dapat dilihat di bawah:
Komponen | Tanggung Jawab |
|---|---|
Webhook Bird | Emit batch acara real-time sebagai permintaan HTTP POST |
Application Load Balancer | Menerima lalu lintas webhook eksternal dan mengarahkan permintaan |
Lambda (Konsumen) | Menyimpan batch webhook mentah ke S3 dengan efisien |
Amazon S3 | Menyimpan payload acara yang dibundel sebagai file JSON datar |
Lambda (Pengolah) | Transformasi atau memuat data yang disimpan secara asinkron |
Untuk menerapkan alur kerja ini, mari kita benar-benar membangunnya dalam urutan terbalik dimulai dengan membuat bucket S3 tempat kami akan menyimpan data acara kami dan kemudian bekerja mundur – menambahkan setiap komponen yang terhubung dengan apa yang telah kami bangun.
Ketika acara Bird dibuat, kami ingin data acara tersebut disiarkan secara real-time 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 di bucket S3. Diagram tingkat tinggi dari alur data yang dijelaskan dapat dilihat di bawah:
Komponen | Tanggung Jawab |
|---|---|
Webhook Bird | Emit batch acara real-time sebagai permintaan HTTP POST |
Application Load Balancer | Menerima lalu lintas webhook eksternal dan mengarahkan permintaan |
Lambda (Konsumen) | Menyimpan batch webhook mentah ke S3 dengan efisien |
Amazon S3 | Menyimpan payload acara yang dibundel sebagai file JSON datar |
Lambda (Pengolah) | Transformasi atau memuat data yang disimpan secara asinkron |
Untuk menerapkan alur kerja ini, mari kita benar-benar membangunnya dalam urutan terbalik dimulai dengan membuat bucket S3 tempat kami akan menyimpan data acara kami dan kemudian bekerja mundur – menambahkan setiap komponen yang terhubung dengan apa yang telah kami bangun.
Buat S3 Bucket 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 kami di mana data akan disimpan. Sementara S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan basis data PostgreSQL untuk pemrosesan acara harus menerapkan prosedur cadangan dan pemulihan yang tepat untuk melindungi data terstruktur mereka di samping strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 di dalam AWS dan tekan “Buat Bucket.” Anda akan diminta untuk memberikan nama pada bucket Anda dan mengatur region – pastikan untuk menggunakan region yang sama dengan ALB dan fungsi lambda Anda. Ketika bucket S3 Anda dibuat, itu akan kosong – jika Anda ingin mengatur data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file. Dalam contoh ini, kami menamai bucket S3 kami “bird-webhooks” dan membuat folder bernama “Data Acara B” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah.
Sebelum membuat penyeimbang beban kami untuk menerima data, atau fungsi lambda kami untuk menyimpan data, kami perlu terlebih dahulu membuat bucket S3 kami di mana data akan disimpan. Sementara S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan basis data PostgreSQL untuk pemrosesan acara harus menerapkan prosedur cadangan dan pemulihan yang tepat untuk melindungi data terstruktur mereka di samping strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 di dalam AWS dan tekan “Buat Bucket.” Anda akan diminta untuk memberikan nama pada bucket Anda dan mengatur region – pastikan untuk menggunakan region yang sama dengan ALB dan fungsi lambda Anda. Ketika bucket S3 Anda dibuat, itu akan kosong – jika Anda ingin mengatur data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file. Dalam contoh ini, kami menamai bucket S3 kami “bird-webhooks” dan membuat folder bernama “Data Acara B” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah.
Sebelum membuat penyeimbang beban kami untuk menerima data, atau fungsi lambda kami untuk menyimpan data, kami perlu terlebih dahulu membuat bucket S3 kami di mana data akan disimpan. Sementara S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan basis data PostgreSQL untuk pemrosesan acara harus menerapkan prosedur cadangan dan pemulihan yang tepat untuk melindungi data terstruktur mereka di samping strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 di dalam AWS dan tekan “Buat Bucket.” Anda akan diminta untuk memberikan nama pada bucket Anda dan mengatur region – pastikan untuk menggunakan region yang sama dengan ALB dan fungsi lambda Anda. Ketika bucket S3 Anda dibuat, itu akan kosong – jika Anda ingin mengatur data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file. Dalam contoh ini, kami menamai bucket S3 kami “bird-webhooks” dan membuat folder bernama “Data Acara B” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah.
Buat Fungsi Lambda untuk Mengkonsumsi Data
Proses dan penyimpanan data yang sebenarnya akan dilakukan oleh sebuah fungsi lambda yang dipanggil oleh penyeimbang beban aplikasi kami (ALB).
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda di dalam AWS dan mengklik “Buat Fungsi.” Anda akan diminta untuk memberikan nama untuk fungsi lambda Anda dan memilih bahasa pemrograman mana yang akan digunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kami perlu mengembangkan fungsi lambda kami. Untuk sejenak, mari kita anggap bahwa penyeimbang beban aplikasi kami telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kami – lambda akan menerima payload yang mencakup semua header dan body. Payload ini diteruskan ke fungsi lambda kami menggunakan objek “event” sebagai kamus. Anda dapat mengacu pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami 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 body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan otentikasi atau penanganan kesalahan, sesuai kebutuhan.
Saat menyimpan payload ke dalam flat-file 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 endpoint Anda habis waktu. Meskipun Anda dapat menyesuaikan pengaturan timeout koneksi di 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 sejauh mungkin – seperti mengonversi payload JSON yang dikelompokkan menjadi file CSV, atau memuat data peristiwa ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan perlu memiliki izin PutObject dan GetObject untuk S3. Merupakan praktik terbaik untuk memberlakukan prinsip hak akses terkecil, 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 peristiwa menjadi satu payload, di mana setiap batch dapat berisi 1 hingga 350 atau lebih catatan peristiwa. Batch akan diberikan ID batch unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan API Webhook Peristiwa atau di dalam akun Bird Anda dengan mengklik pada aliran webhook dan memilih “Status Batch.” Dalam hal payload webhook tidak dapat dikirim, seperti saat terjadi timeout koneksi, Bird akan secara otomatis mencoba kembali 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 guna mengurangi waktu eksekusi.
Untuk menangani semua aktivitas pemrosesan data, saya sarankan untuk membuat fungsi lambda terpisah yang dieksekusi setiap kali file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron dengan transmisi data, dan tidak ada risiko kehilangan data karena koneksi yang terputus. Saya akan membahas fungsi lambda pemrosesan di bagian selanjutnya.
Proses dan penyimpanan data yang sebenarnya akan dilakukan oleh sebuah fungsi lambda yang dipanggil oleh penyeimbang beban aplikasi kami (ALB).
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda di dalam AWS dan mengklik “Buat Fungsi.” Anda akan diminta untuk memberikan nama untuk fungsi lambda Anda dan memilih bahasa pemrograman mana yang akan digunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kami perlu mengembangkan fungsi lambda kami. Untuk sejenak, mari kita anggap bahwa penyeimbang beban aplikasi kami telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kami – lambda akan menerima payload yang mencakup semua header dan body. Payload ini diteruskan ke fungsi lambda kami menggunakan objek “event” sebagai kamus. Anda dapat mengacu pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami 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 body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan otentikasi atau penanganan kesalahan, sesuai kebutuhan.
Saat menyimpan payload ke dalam flat-file 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 endpoint Anda habis waktu. Meskipun Anda dapat menyesuaikan pengaturan timeout koneksi di 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 sejauh mungkin – seperti mengonversi payload JSON yang dikelompokkan menjadi file CSV, atau memuat data peristiwa ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan perlu memiliki izin PutObject dan GetObject untuk S3. Merupakan praktik terbaik untuk memberlakukan prinsip hak akses terkecil, 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 peristiwa menjadi satu payload, di mana setiap batch dapat berisi 1 hingga 350 atau lebih catatan peristiwa. Batch akan diberikan ID batch unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan API Webhook Peristiwa atau di dalam akun Bird Anda dengan mengklik pada aliran webhook dan memilih “Status Batch.” Dalam hal payload webhook tidak dapat dikirim, seperti saat terjadi timeout koneksi, Bird akan secara otomatis mencoba kembali 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 guna mengurangi waktu eksekusi.
Untuk menangani semua aktivitas pemrosesan data, saya sarankan untuk membuat fungsi lambda terpisah yang dieksekusi setiap kali file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron dengan transmisi data, dan tidak ada risiko kehilangan data karena koneksi yang terputus. Saya akan membahas fungsi lambda pemrosesan di bagian selanjutnya.
Proses dan penyimpanan data yang sebenarnya akan dilakukan oleh sebuah fungsi lambda yang dipanggil oleh penyeimbang beban aplikasi kami (ALB).
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda di dalam AWS dan mengklik “Buat Fungsi.” Anda akan diminta untuk memberikan nama untuk fungsi lambda Anda dan memilih bahasa pemrograman mana yang akan digunakan untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kami perlu mengembangkan fungsi lambda kami. Untuk sejenak, mari kita anggap bahwa penyeimbang beban aplikasi kami telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kami – lambda akan menerima payload yang mencakup semua header dan body. Payload ini diteruskan ke fungsi lambda kami menggunakan objek “event” sebagai kamus. Anda dapat mengacu pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami 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 body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan otentikasi atau penanganan kesalahan, sesuai kebutuhan.
Saat menyimpan payload ke dalam flat-file 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 endpoint Anda habis waktu. Meskipun Anda dapat menyesuaikan pengaturan timeout koneksi di 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 sejauh mungkin – seperti mengonversi payload JSON yang dikelompokkan menjadi file CSV, atau memuat data peristiwa ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan perlu memiliki izin PutObject dan GetObject untuk S3. Merupakan praktik terbaik untuk memberlakukan prinsip hak akses terkecil, 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 peristiwa menjadi satu payload, di mana setiap batch dapat berisi 1 hingga 350 atau lebih catatan peristiwa. Batch akan diberikan ID batch unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan API Webhook Peristiwa atau di dalam akun Bird Anda dengan mengklik pada aliran webhook dan memilih “Status Batch.” Dalam hal payload webhook tidak dapat dikirim, seperti saat terjadi timeout koneksi, Bird akan secara otomatis mencoba kembali 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 guna mengurangi waktu eksekusi.
Untuk menangani semua aktivitas pemrosesan data, saya sarankan untuk membuat fungsi lambda terpisah yang dieksekusi setiap kali file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron dengan transmisi data, dan tidak ada risiko kehilangan data karena koneksi yang terputus. Saya akan membahas fungsi lambda pemrosesan di bagian selanjutnya.
Buat Load Balancer Aplikasi
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukan ini dengan membuat load balancer aplikasi di dalam AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik "Buat Load Balancer". Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat load balancer aplikasi. Kita perlu menggunakan load balancer aplikasi (ALB) untuk membangun konsumen kita karena webhook event akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk merouting permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan lebih hemat biaya dibandingkan dengan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format event mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut dengan benar.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama pada ALB Anda dan mengonfigurasi skema serta pengaturan akses/keamanan – karena kita berencana menerima data event dari sumber eksternal (Bird), kita ingin ALB kita bersifat menghadapi internet. Di bawah "Pendengar dan routing," ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang mengarah ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda konsumsi yang kita buat di atas. Anda juga perlu memastikan bahwa grup keamanan memiliki izin untuk menerima lalu lintas melalui port 443.
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukan ini dengan membuat load balancer aplikasi di dalam AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik "Buat Load Balancer". Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat load balancer aplikasi. Kita perlu menggunakan load balancer aplikasi (ALB) untuk membangun konsumen kita karena webhook event akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk merouting permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan lebih hemat biaya dibandingkan dengan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format event mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut dengan benar.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama pada ALB Anda dan mengonfigurasi skema serta pengaturan akses/keamanan – karena kita berencana menerima data event dari sumber eksternal (Bird), kita ingin ALB kita bersifat menghadapi internet. Di bawah "Pendengar dan routing," ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang mengarah ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda konsumsi yang kita buat di atas. Anda juga perlu memastikan bahwa grup keamanan memiliki izin untuk menerima lalu lintas melalui port 443.
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukan ini dengan membuat load balancer aplikasi di dalam AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik "Buat Load Balancer". Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat load balancer aplikasi. Kita perlu menggunakan load balancer aplikasi (ALB) untuk membangun konsumen kita karena webhook event akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk merouting permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan lebih hemat biaya dibandingkan dengan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format event mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut dengan benar.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama pada ALB Anda dan mengonfigurasi skema serta pengaturan akses/keamanan – karena kita berencana menerima data event dari sumber eksternal (Bird), kita ingin ALB kita bersifat menghadapi internet. Di bawah "Pendengar dan routing," ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang mengarah ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda konsumsi yang kita buat di atas. Anda juga perlu memastikan bahwa grup keamanan memiliki izin untuk menerima lalu lintas melalui port 443.
Buat Catatan DNS untuk Penyeimbang Beban
Untuk memudahkan kami menggunakan ALB kami sebagai titik akhir, kami akan membuat catatan 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 catatan A untuk nama host yang ingin Anda gunakan untuk titik akhir Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, sadarilah bahwa ada batas DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi dengan volume tinggi, terutama yang menangani jumlah besar lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk mengarah ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk ke instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji apakah semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat melakukan permintaan POST ke titik akhir Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa kembali bahwa ALB Anda mendengarkan di port yang benar.
Untuk memudahkan kami menggunakan ALB kami sebagai titik akhir, kami akan membuat catatan 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 catatan A untuk nama host yang ingin Anda gunakan untuk titik akhir Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, sadarilah bahwa ada batas DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi dengan volume tinggi, terutama yang menangani jumlah besar lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk mengarah ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk ke instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji apakah semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat melakukan permintaan POST ke titik akhir Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa kembali bahwa ALB Anda mendengarkan di port yang benar.
Untuk memudahkan kami menggunakan ALB kami sebagai titik akhir, kami akan membuat catatan 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 catatan A untuk nama host yang ingin Anda gunakan untuk titik akhir Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, sadarilah bahwa ada batas DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi dengan volume tinggi, terutama yang menangani jumlah besar lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk mengarah ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk ke instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji apakah semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan webhook Bird Anda. Anda dapat melakukan permintaan POST ke titik akhir Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa kembali bahwa ALB Anda mendengarkan di port yang benar.
Buat Webhook Burung
Sekarang kami siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai endpoint target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik “Buat Webhook.” Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target – target tersebut harus merupakan hostname dari catatan A yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi subakun dan peristiwa yang benar telah dipilih, dan tekan “Buat Webhook” untuk menyimpan konfigurasi Anda. Data peristiwa untuk semua jenis peristiwa yang dipilih sekarang akan dialirkan ke URL target kami dan akan dikonsumsi oleh ALB kami untuk pemrosesan lebih lanjut.
Sekarang kami siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai endpoint target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik “Buat Webhook.” Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target – target tersebut harus merupakan hostname dari catatan A yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi subakun dan peristiwa yang benar telah dipilih, dan tekan “Buat Webhook” untuk menyimpan konfigurasi Anda. Data peristiwa untuk semua jenis peristiwa yang dipilih sekarang akan dialirkan ke URL target kami dan akan dikonsumsi oleh ALB kami untuk pemrosesan lebih lanjut.
Sekarang kami siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai endpoint target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik “Buat Webhook.” Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target – target tersebut harus merupakan hostname dari catatan A yang Anda buat sebelumnya. Perhatikan bahwa URL target mungkin memerlukan “HTTPS://” disertakan dalam URL.
Setelah selesai, verifikasi subakun dan peristiwa yang benar telah dipilih, dan tekan “Buat Webhook” untuk menyimpan konfigurasi Anda. Data peristiwa untuk semua jenis peristiwa yang dipilih sekarang akan dialirkan ke URL target kami dan akan dikonsumsi oleh ALB kami untuk pemrosesan lebih lanjut.
Memproses Data Acara Webhook
Menurut tujuan yang dimaksud untuk menyimpan data acara Bird, kebutuhan Anda mungkin dapat dipenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda juga mungkin sudah memiliki proses ETL yang ada yang mampu mengkonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh lambda pemrosesan kami yang kami buat di atas apa adanya.
Atau, Anda mungkin perlu mengubah data – seperti untuk mengonversi dari format JSON ke format CSV – atau memuat data langsung ke dalam database. 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 database.
Menurut tujuan yang dimaksud untuk menyimpan data acara Bird, kebutuhan Anda mungkin dapat dipenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda juga mungkin sudah memiliki proses ETL yang ada yang mampu mengkonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh lambda pemrosesan kami yang kami buat di atas apa adanya.
Atau, Anda mungkin perlu mengubah data – seperti untuk mengonversi dari format JSON ke format CSV – atau memuat data langsung ke dalam database. 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 database.
Menurut tujuan yang dimaksud untuk menyimpan data acara Bird, kebutuhan Anda mungkin dapat dipenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda juga mungkin sudah memiliki proses ETL yang ada yang mampu mengkonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh lambda pemrosesan kami yang kami buat di atas apa adanya.
Atau, Anda mungkin perlu mengubah data – seperti untuk mengonversi dari format JSON ke format CSV – atau memuat data langsung ke dalam database. 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 database.
Buat Lambda untuk Memproses Data
Seperti fungsi lambda untuk mengkonsumsi data webhook, kita perlu membuat fungsi lambda baru dengan menavigasi ke layanan Lambda di AWS dan menekan "Buat Fungsi." Fungsi lambda baru ini akan diaktifkan ketika file baru dibuat di bucket S3 kita – ia akan membaca data dan mengonversinya menjadi file csv baru.
Fungsi lambda menerima informasi file sebagai peristiwa. Dalam fungsi lambda contoh, Anda akan melihat bahwa kita pertama-tama memiliki serangkaian pemeriksaan validasi untuk memastikan bahwa data lengkap dan terformat seperti yang diharapkan. Selanjutnya, kita 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 kita membuat file csv sementara dan menamakannya dengan konvensi <batch_id>.csv. Alasan kita menggunakan batch_id di sini adalah untuk memastikan bahwa proses paralel yang berjalan sebagai hasil dari menerima banyak payload webhook tidak saling mengganggu, karena setiap batch webhook akan memiliki batch_id yang unik.
Setelah data sepenuhnya dikonversi menjadi CSV, kita 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, kita berisiko menciptakan loop rekursif yang dapat mengakibatkan peningkatan penggunaan lambda dan biaya yang meningkat. Kita perlu mengidentifikasi di bucket S3 mana dan lokasi mana kita ingin file CSV kita disimpan dalam fungsi lambda kita. Ikuti prosedur yang sama seperti di atas untuk membuat bucket S3 baru untuk menyimpan file CSV kita.
Perlu dicatat bahwa direktori tmp dibatasi hingga 512 MB ruang, jadi penting bahwa file sementara dihapus setelahnya untuk memastikan ruang yang cukup untuk eksekusi di masa mendatang. Alasan kita menggunakan file sementara, alih-alih menulis langsung ke S3, adalah untuk menyederhanakan koneksi ke S3 dengan memiliki satu permintaan.
Sama seperti fungsi lambda konsumsi, Anda mungkin perlu memperbarui izin untuk fungsi lambda proses Anda. Fungsi lambda ini memerlukan peran eksekusi untuk memiliki izin GetObject untuk bucket S3 input, dan baik PutObject maupun GetObject untuk bucket S3 output.
Contoh fungsi lambda pemrosesan kita dapat ditemukan di sini.
Seperti fungsi lambda untuk mengkonsumsi data webhook, kita perlu membuat fungsi lambda baru dengan menavigasi ke layanan Lambda di AWS dan menekan "Buat Fungsi." Fungsi lambda baru ini akan diaktifkan ketika file baru dibuat di bucket S3 kita – ia akan membaca data dan mengonversinya menjadi file csv baru.
Fungsi lambda menerima informasi file sebagai peristiwa. Dalam fungsi lambda contoh, Anda akan melihat bahwa kita pertama-tama memiliki serangkaian pemeriksaan validasi untuk memastikan bahwa data lengkap dan terformat seperti yang diharapkan. Selanjutnya, kita 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 kita membuat file csv sementara dan menamakannya dengan konvensi <batch_id>.csv. Alasan kita menggunakan batch_id di sini adalah untuk memastikan bahwa proses paralel yang berjalan sebagai hasil dari menerima banyak payload webhook tidak saling mengganggu, karena setiap batch webhook akan memiliki batch_id yang unik.
Setelah data sepenuhnya dikonversi menjadi CSV, kita 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, kita berisiko menciptakan loop rekursif yang dapat mengakibatkan peningkatan penggunaan lambda dan biaya yang meningkat. Kita perlu mengidentifikasi di bucket S3 mana dan lokasi mana kita ingin file CSV kita disimpan dalam fungsi lambda kita. Ikuti prosedur yang sama seperti di atas untuk membuat bucket S3 baru untuk menyimpan file CSV kita.
Perlu dicatat bahwa direktori tmp dibatasi hingga 512 MB ruang, jadi penting bahwa file sementara dihapus setelahnya untuk memastikan ruang yang cukup untuk eksekusi di masa mendatang. Alasan kita menggunakan file sementara, alih-alih menulis langsung ke S3, adalah untuk menyederhanakan koneksi ke S3 dengan memiliki satu permintaan.
Sama seperti fungsi lambda konsumsi, Anda mungkin perlu memperbarui izin untuk fungsi lambda proses Anda. Fungsi lambda ini memerlukan peran eksekusi untuk memiliki izin GetObject untuk bucket S3 input, dan baik PutObject maupun GetObject untuk bucket S3 output.
Contoh fungsi lambda pemrosesan kita dapat ditemukan di sini.
Seperti fungsi lambda untuk mengkonsumsi data webhook, kita perlu membuat fungsi lambda baru dengan menavigasi ke layanan Lambda di AWS dan menekan "Buat Fungsi." Fungsi lambda baru ini akan diaktifkan ketika file baru dibuat di bucket S3 kita – ia akan membaca data dan mengonversinya menjadi file csv baru.
Fungsi lambda menerima informasi file sebagai peristiwa. Dalam fungsi lambda contoh, Anda akan melihat bahwa kita pertama-tama memiliki serangkaian pemeriksaan validasi untuk memastikan bahwa data lengkap dan terformat seperti yang diharapkan. Selanjutnya, kita 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 kita membuat file csv sementara dan menamakannya dengan konvensi <batch_id>.csv. Alasan kita menggunakan batch_id di sini adalah untuk memastikan bahwa proses paralel yang berjalan sebagai hasil dari menerima banyak payload webhook tidak saling mengganggu, karena setiap batch webhook akan memiliki batch_id yang unik.
Setelah data sepenuhnya dikonversi menjadi CSV, kita 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, kita berisiko menciptakan loop rekursif yang dapat mengakibatkan peningkatan penggunaan lambda dan biaya yang meningkat. Kita perlu mengidentifikasi di bucket S3 mana dan lokasi mana kita ingin file CSV kita disimpan dalam fungsi lambda kita. Ikuti prosedur yang sama seperti di atas untuk membuat bucket S3 baru untuk menyimpan file CSV kita.
Perlu dicatat bahwa direktori tmp dibatasi hingga 512 MB ruang, jadi penting bahwa file sementara dihapus setelahnya untuk memastikan ruang yang cukup untuk eksekusi di masa mendatang. Alasan kita menggunakan file sementara, alih-alih menulis langsung ke S3, adalah untuk menyederhanakan koneksi ke S3 dengan memiliki satu permintaan.
Sama seperti fungsi lambda konsumsi, Anda mungkin perlu memperbarui izin untuk fungsi lambda proses Anda. Fungsi lambda ini memerlukan peran eksekusi untuk memiliki izin GetObject untuk bucket S3 input, dan baik PutObject maupun GetObject untuk bucket S3 output.
Contoh fungsi lambda pemrosesan kita dapat ditemukan di sini.
Konfigurasikan Lambda untuk Dijalankan Saat Data Baru Disimpan di S3
Sekarang setelah 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 menambah pemicu ke fungsi lambda kami dengan membuka fungsi lambda kami dan mengklik “Tambahkan Pemicu” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan dan/atau sufiks file untuk difilter. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Tambahkan” di bagian bawah halaman. Sekarang fungsi lambda pemrosesan Anda akan dijalankan setiap kali file baru ditambahkan ke bucket S3 Anda.
Sekarang setelah 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 menambah pemicu ke fungsi lambda kami dengan membuka fungsi lambda kami dan mengklik “Tambahkan Pemicu” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan dan/atau sufiks file untuk difilter. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Tambahkan” di bagian bawah halaman. Sekarang fungsi lambda pemrosesan Anda akan dijalankan setiap kali file baru ditambahkan ke bucket S3 Anda.
Sekarang setelah 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 menambah pemicu ke fungsi lambda kami dengan membuka fungsi lambda kami dan mengklik “Tambahkan Pemicu” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan dan/atau sufiks file untuk difilter. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Tambahkan” di bagian bawah halaman. Sekarang fungsi lambda pemrosesan Anda akan dijalankan setiap kali file baru ditambahkan ke bucket S3 Anda.
Memuat Data ke dalam Basis Data
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam basis data, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muatan data langsung ke dalam basis data Anda di dalam fungsi lambda pemrosesan Anda
Konsumsi file CSV Anda menggunakan proses ETL yang telah ditentukan
Apakah Anda menggunakan layanan basis data AWS, seperti RDS atau DynamoDB, atau Anda memiliki basis data PostgreSQL Anda sendiri (atau yang serupa), Anda dapat terhubung langsung ke layanan basis data Anda 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 langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya sarankan untuk merujuk pada dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik untuk melakukannya 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 ditentukan yang dapat Anda manfaatkan.
Kami harap Anda menemukan panduan ini bermanfaat – selamat mengirim!
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam basis data, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muatan data langsung ke dalam basis data Anda di dalam fungsi lambda pemrosesan Anda
Konsumsi file CSV Anda menggunakan proses ETL yang telah ditentukan
Apakah Anda menggunakan layanan basis data AWS, seperti RDS atau DynamoDB, atau Anda memiliki basis data PostgreSQL Anda sendiri (atau yang serupa), Anda dapat terhubung langsung ke layanan basis data Anda 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 langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya sarankan untuk merujuk pada dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik untuk melakukannya 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 ditentukan yang dapat Anda manfaatkan.
Kami harap Anda menemukan panduan ini bermanfaat – selamat mengirim!
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam basis data, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muatan data langsung ke dalam basis data Anda di dalam fungsi lambda pemrosesan Anda
Konsumsi file CSV Anda menggunakan proses ETL yang telah ditentukan
Apakah Anda menggunakan layanan basis data AWS, seperti RDS atau DynamoDB, atau Anda memiliki basis data PostgreSQL Anda sendiri (atau yang serupa), Anda dapat terhubung langsung ke layanan basis data Anda 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 langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya sarankan untuk merujuk pada dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik untuk melakukannya 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 ditentukan yang dapat Anda manfaatkan.
Kami harap Anda menemukan panduan ini bermanfaat – selamat mengirim!
