التالي هو دليل بسيط لمساعدة المرسلين على الشعور بالراحة عند إنشاء webhook لأحداث Bird واستهلاك البيانات باستخدام البنية التحتية داخل AWS.
تعتبر إشعارات الويب للأحداث في الوقت الفعلي من Bird أداة قيمة للغاية للمستخدمين ليتم دفع البيانات تلقائيًا إلى أنظمتهم. يمكن أن يحفز هذا الأتمتة التالية مثل تحديث قوائم البريد، أو بدء رحلات البريد الإلكتروني التلقائية، أو تعبئة لوحات تحكم داخلية. بينما يمكن الوصول إلى نفس بيانات الحدث عبر واجهة Bird باستخدام البحث عن الأحداث، أو برمجيًا باستخدام Events API الخاصة بـBird، يمكن أن تكون الحدود المفروضة على عدد السجلات المسترجعة في طلب واحد أو حدود السرعة على واجهة API المقيدة للطرفين للمستخدمين الكبار والمتقدمين.
تُمكّن إشعارات الويب في الوقت الفعلي المُرسل من تكوين نقطة نهاية حيث تنقل Bird البيانات إليها، ويمكن استهلاك البيانات دون الحاجة لتحديد وظائف cron التي تسحب البيانات. هناك أيضًا مقايضات لوجستية عند سحب البيانات بدلاً من دفع البيانات إليك، مثل الحاجة إلى تحديد الفترة الزمنية والمعلمات للاستخدام لكل طلب API. إذا لم تتوافق الفترات الزمنية تمامًا فإنك تخاطر بفقدان البيانات، وإذا تداخلت الفترات الزمنية فإنك تحتاج إلى التعامل مع السجلات المكررة. مع إشعارات الويب في الوقت الفعلي، يتم دفع بيانات الأحداث ببساطة إلى نقطة النهاية الخاصة بك عند توفرها في Bird.
بينما قد يتم فهم فوائد تلقي بيانات الأحداث في الوقت الفعلي لتحفيز عمليات الأتمتة التالية بوضوح من قبل العديد من المستخدمين، قد تكون عملية تنفيذ واستهلاك إشعارات الويب مرهبة. قد يكون هذا صحيحًا بشكل خاص إذا لم تكن مألوفًا بالمكونات التقنية لإنشاء نقطة نهاية والتعامل مع البيانات برمجيًا. هناك خدمات متاحة ستستهلك بيانات إشعارات الويب من Bird وتنفذ ETL إلى قاعدة بياناتك تلقائيًا - مثال على ذلك هو StitchData، الذي تحدثنا عنه في مدونة في الماضي. ومع ذلك، إذا كنت ترغب في مزيد من التحكم في العملية يمكنك بناء المكونات بنفسك بسهولة. النص التالي هو دليل بسيط لمساعدة المستخدمين على الشعور بالراحة عند إنشاء إشعار الويب لفعاليات Bird واستهلاك البيانات باستخدام البنية التحتية في AWS.
تكوين وجهة نقطة نهاية Webhook
عندما يتم إنشاء حدث Bird، نريد أن يتم بث بيانات الحدث في الوقت الفعلي إلى نقطة نهاية في AWS حتى نتمكن من استهلاك واستخدام تلك البيانات برمجياً. ستُرسل البيانات من Bird إلى نقطة نهاية مستهدفة، والتي ستنقل الحمولة إلى دالة lambda التي ستعالج وتخزن البيانات في دلو S3. يمكن رؤية رسم بياني شاملي لتدفق البيانات الموصوف أدناه:
لتنفيذ هذا سير العمل، فلنبدأ ببناء المكونات بترتيب عكسي بدءًا من إنشاء دلو S3 حيث سنخزن بيانات الحدث لدينا ثم نعود للخلف – حيث نضيف كل مكون يُغذي في ما تم بناؤه بالفعل.
إنشاء دلو S3 لتخزين بيانات Webhook
قبل إنشاء محمل التحميل الخاص بنا لقبول البيانات أو دالة lambda الخاصة بنا لتخزين البيانات، نحتاج أولاً إلى إنشاء دلو S3 حيث ستُخزن البيانات. على الرغم من أن S3 يوفر تخزينًا ممتازًا لبيانات الويب هوك، يجب على المنظمات أيضًا التي تستخدم قواعد البيانات PostgreSQL لمعالجة الأحداث تنفيذ إجراءات النسخ الاحتياطي والاستعادة المناسبة لحماية بياناتهم المنظمة بجانب استراتيجية تخزين S3 الخاصة بهم. للقيام بذلك، انتقل إلى خدمة S3 داخل AWS واضغط على “إنشاء دلو.” ستُطلب تعيين اسم لدلوك وتحديد المنطقة – تأكد من استخدام نفس المنطقة مثل ALB ودالة lambda. عند إنشاء دلوك S3، سيكون فارغًا – إذا كنت ترغب في تنظيم البيانات داخل مجلد، يمكنك إما إنشاء الدليل المقصود الآن، أو سيتم إنشاء الدليل عندما تخزن دالة lambda الخاصة بك الملف. في هذا المثال، قمنا بتسمية دلوك S3 الخاص بنا “bird-webhooks” وخلقنا مجلدًا يسمى “B Event Data” لتخزين بيانات الحدث لدينا – سترى هذه الأسماء مذكورة في دالة lambda الخاصة بنا أدناه.
إنشاء دالة Lambda لاستهلاك البيانات
ستُنفذ المعالجة والتخزين الفعلي للبيانات بواسطة دالة lambda التي يتم استدعاؤها بواسطة موزع التحميل للتطبيق الخاص بنا (ALB).
الخطوة الأولى هي إنشاء دالة lambda عن طريق التنقل إلى خدمة Lambda داخل AWS والضغط على “إنشاء دالة.” ستُطلب منك تعيين اسم لدالة lambda وتحديد اللغة البرمجية التي تريد كتابة دالتك بها. في هذا المثال، نستخدم Python كلغة تنفيذ.
الآن نحتاج إلى تطوير دالة lambda الخاصة بنا. للحظة، دعونا نفترض أن موزع تحميل التطبيق الخاص بنا قد تم تكوينه ويقوم بإعادة توجيه الحمولة الواردة إلى دالة lambda الخاصة بنا – ستتلقى lambda حمولة تحتوي على كافة الرؤوس والجسم. يتم تمرير الحمولة إلى دالة lambda الخاصة بنا باستخدام الكائن “event” كقاموس. يمكنك الرجوع إلى الرؤوس والجسم للحمولة بشكل مستقل عن طريق الوصول إلى كائنات “headers” و“body” داخل الحمولة. في هذا المثال، سنقوم ببساطة بقراءة رأس “x-messagesystems-batch-id”، حيث يُنشأ معرف باتش فريد بواسطة Bird من أجل دفعة الويب هوك، ونستخدمه كاسم الملف عند تخزين الجسم كملف نصي في S3؛ ومع ذلك، قد ترغب في إضافة وظائف إضافية مثل فحوصات المصادقة أو التعامل مع الأخطاء، حسب الحاجة.
عند تخزين الحمولة كملف نصي في S3، سنحتاج إلى تحديد اسم دلو S3، الموقع، واسم الملف الذي ستُخزن فيه بيانات الحمولة. في دالة lambda الخاصة بنا، نقوم بذلك داخل وظيفة “store_batch”. في هذا المثال، سنقوم بتخزين كامل الباتش كملف واحد، مما يساعد على ضمان أن البيانات قد جُمعت وتخُزنت قبل أن تنتهي صلاحية الاتصال بين Bird ونقطة النهاية الخاصة بك. بينما يمكنك ضبط إعدادات مهلة الاتصال على موزع التحميل الخاص بك، لا توجد ضمانات بأن الاتصال لن ينتهي من جانب الإرسال (في هذه الحالة Bird) أو أن الاتصال لن يُقطع قبل انتهاء تنفيذ دالة lambda الخاصة بك. من الأفضل أن تبقى دالة المستهلك الخاصة بك فعالة قدر الإمكان وتحجز أنشطة معالجة البيانات للعمليات النهائية حيثما أمكن – مثل تحويل الحمولة المجمعة بصيغة JSON إلى ملف CSV، أو تحميل بيانات الحدث إلى قاعدة بيانات.
من المهم ملاحظة أنك قد تحتاج إلى تحديث الأذونات الخاصة بدالة lambda الخاصة بك. سيحتاج دور التنفيذ الخاص بك إلى قوانين PutObject وGetObject بالنسبة لـ S3. من الأفضل تنفيذ مبدأ الامتياز الأقل، لذلك أوصي بتعيين هذه الأذونات فقط لدلو S3 حيث ستُخزن حمولة الويب هوك.
عينة من دالة lambda الخاصة بمستهلكينا يمكن العثور عليها هنا.
ملحوظة سريعة حول معرف الباتش: سوف يقوم Bird بتجميع الأحداث في حمولة واحدة، حيث يمكن أن يحتوي كل باتش على 1 إلى 350 أو أكثر من سجلات الأحداث. سيُعطى الباتش معرف باتش فريد، والذي يمكن استخدامه لعرض حالة الباتش من خلال الاستفادة من API الخاص بحدث Webhooks أو داخل حساب Bird الخاص بك بالنقر على تدفق الويب هوك وتحديد “حالة الباتش.” في حالة عدم تسليم حمولة الويب هوك، مثل أثناء انتهاء مهلة الاتصال، سيقوم Bird تلقائيًا بإعادة المحاولة بالباتش باستخدام نفس معرف الباتش. يمكن أن يحدث هذا عندما تكون دالة lambda الخاصة بك تعمل بالقرب من الحد الأقصى لوقت الاستجابة البينية البالغة 10 ثواني وهو سبب لتحسين دالة المستهلك لتقليل وقت التنفيذ.
للتعامل مع جميع أنشطة معالجة البيانات، أوصي بإنشاء دالة lambda منفصلة يتم تنفيذها كلما تم إنشاء ملف جديد في دلو S3 – بهذه الطريقة، ستُنفذ معالجة البيانات بشكل غير متزامن مع إرسال البيانات، ولا يوجد خطر فقدان البيانات بسبب اتصال مقطوع. أناقش دالة معالجة lambda في قسم لاحق.
إنشاء محمل تحميل التطبيق
من أجل تلقي حمولة الويب هوك، نحتاج إلى توفير نقطة نهاية لإرسال حمولات الويب هوك إليها. نقوم بذلك عن طريق إنشاء محمل تحميل التطبيق داخل AWS بالتنقل إلى EC2 > محملات التحميل والضغط على “إنشاء محمل تحميل.” سيُطلب منك اختيار نوع محمل التحميل الذي تريد إنشاؤه – لهذا، نحن نريد إنشاء محمل تحميل التطبيق. نحتاج إلى استخدام محمل تحميل التطبيق (ALB) لبناء المستهلك الخاص بنا لأن أحداث الويب هوك ستُرسل كطلب HTTP، وتُستخدم ALBs لتوجيه طلبات HTTP داخل AWS. يمكننا تنفيذ بوابة HTTP كبديل؛ ومع ذلك، نستخدم ALB لهذا المشروع لأنه أخف تكلفة وأكثر اقتصادًا من بوابة HTTP. من المهم ملاحظة أنه إذا اخترت استخدام بوابة HTTP، فقد يكون تنسيق الحدث مختلفًا عن ALB، وبالتالي ستحتاج دالة lambda الخاصة بك إلى معالجة كائن الطلب وفقًا لذلك.
بمجرد إنشاء ALB الخاص بك، سيُطلب منك تعيين اسم لـ ALB الخاص بك وتكوين إعدادات المخطط والوصول/الأمان – نظرًا لأننا نخطط لاستلام بيانات الحدث من مصدر خارجي (Bird)، نريد أن يكون ALB الخاص بنا موجهاً للإنترنت. ضمن “المستمعين والتوجيه”، يجب أن يستمع ALB إلى HTTPS على المنفذ 443، ونريد إنشاء مجموعة مستهدفة تشير إلى دالة lambda الخاصة بنا بحيث يقوم ALB بإعادة توجيه الطلبات الواردة إلى الدالة المستهلكة لـ lambda التي أنشأناها أعلاه. تحتاج أيضًا إلى التأكد من أن المجموعة الأمنية لديها الإذن بقبول الحركة المرورية عبر المنفذ 443.
إنشاء سجل DNS لمحمل التحميل
لنجعلها أسهل لنا لاستخدام ALB كنقطة نهاية، سنقوم بإنشاء سجل A في DNS يشير إلى ALB الخاص بنا. لهذا، يمكننا استخدام خدمة AWS Route 53 (أو موفر DNS الحالي الخاص بك) وإنشاء سجل A للاسم المضيف الذي تريد استخدامه لنقطة النهاية الخاصة بك (مثل spevents.<your_domain>). عند العمل مع DNS على نطاق واسع على AWS، كن على دراية بأن هناك قيود DNS غير موثقة التي يمكن أن تؤثر على التطبيقات ذات الحركة المرورية العالية، خاصة تلك التي تتعامل مع كميات كبيرة من الحركة الصادرة مثل أنظمة تسليم البريد الإلكتروني. يجب تكوين سجل A للإشارةإلى ALB الذي أنشأناه. إذا كنت تستخدم Route 53 لإدارة سجلات DNS، يمكنك الرجوع إلى مثيل ALB مباشرة من خلال تمكين “Alias” وتحديد ALB؛ بخلاف ذلك، إذا كنت تستخدم موفر DNS خارجي، يجب عليك الإشارة إلى سجل A على عنوان IP العام لمثيل ALB.
أوصي باستخدام أداة مثل Postman لاختبار أن كل شيء تم تكوينه بشكل صحيح قبل تمكين الويب هوك لـ Bird. يمكنك إنشاء طلب POST إلى نقطة النهاية الخاصة بك وتأكيد استلام الرد. إذا لم يُرجع طلب POST الخاص بك ردًا، فقد تحتاج إلى التحقق مرة أخرى من أن ALB الخاصة بك تستمع للمنفذ الصحيح.
إنشاء Webhook لـ Bird
الآن نحن جاهزون لإنشاء الويب هوك في Bird واستخدام اسم المضيف الذي تم تحديده بواسطة A record أعلاه كنقطة النهاية المستهدفة لدينا. لإنشاء الويب هوك، انتقل إلى قسم الويب هوك داخل حساب Bird الخاص بك واضغط على “إنشاء ويب هوك.” سيُطلب منك تعيين اسم لويب هوك الخاص بك وتوفير URL الهدف – يجب أن يكون الهدف هو اسم المضيف لـ A record الذي قمت بإنشائه سابقًا. لاحظ أن URL الهدف قد يتطلب تضمين “HTTPS://” في URL.
بمجرد الانتهاء، تحقق من تحديد الحساب الفرعي الصحيح والأحداث، واضغط على “إنشاء ويب هوك” لحفظ الإعداد الخاص بك. الآن ستتدفق بيانات الأحداث لجميع أنواع الأحداث المحددة إلى URL هدفنا وسيتم استهلاكها بواسطة ALB لمعالجة العمليات النهائية.
