موضوعات SNS وبنية التوزيع المتعدد

إن Amazon Simple Notification Service (SNS) هي خدمة مراسلة بنمط النشر/الاشتراك مُدارة بالكامل. يرسل الناشرون الرسائل إلى موضوع في SNS، وتسلّم SNS هذه الرسائل فورًا إلى جميع المشتركين. وعلى خلاف SQS (القائمة على السحب)، تعتمد SNS على الدفع؛ إذ تسلّم الرسائل إلى المشتركين بمجرد نشرها. وهذا يجعل SNS مناسبةً بشكل مثالي لبث الأحداث إلى أنظمة متعددة لاحقة في الوقت نفسه.

مثل SQS، توفر SNS نوعين من الموضوعات: توفر موضوعات Standard ترتيبًا للرسائل على أساس أفضل جهد، وتسليمًا مرة واحدة على الأقل، ومعدل نقل يكاد يكون غير محدود؛ ويمكنها التسليم إلى SQS وLambda ونقاط نهاية HTTP والبريد الإلكتروني والرسائل النصية والدفع إلى الأجهزة المحمولة. تضمن موضوعات FIFO ترتيبًا صارمًا وتسليمًا مرة واحدة فقط، ولكن إلى مشتركي FIFO في SQS فقط. وتدعم موضوعات FIFO ما يصل إلى 3,000 رسالة في الثانية عند استخدام التجميع، وتُستخدم عندما يجب الحفاظ على ترتيب الأحداث عبر مشتركين متعددين.

تدعم SNS عدة أنواع من المشتركين المستندة إلى البروتوكولات:

• SQS: وضع الرسائل في قائمة انتظار متينة (وهو الاستخدام الأكثر شيوعًا للمعالجة غير المتزامنة)
• Lambda: استدعاء مباشر (متزامن من منظور SNS)
• HTTP/HTTPS: تسليم webhook إلى نقاط نهاية خارجية
• Email / Email-JSON: إرسال إشعارات إلى المستخدمين
• SMS: تسليم رسائل نصية
• Mobile Push: استخدام FCM وAPNs عبر تطبيقات المنصات
• Firehose: بث البيانات إلى S3 أو Redshift عبر Kinesis Data Firehose

يمثل التوزيع المتشعب النمط الأساسي في SNS: إذ تُنشر رسالة واحدة إلى موضوع، ثم تسلّمها SNS في الوقت نفسه إلى جميع المشتركين. على سبيل المثال، يمكن توزيع حدث طلب جديد متشعبًا إلى: قائمة انتظار SQS لتنفيذ الطلبات في المستودع، وقائمة انتظار SQS أخرى لتحديث المخزون، ووظيفة Lambda لاكتشاف الاحتيال، واشتراك بالبريد الإلكتروني لفريق العمليات. يعالج كل مشترك الحدث بشكل مستقل من دون اقتران بين المشتركين. وهذا أكثر قابلية للتوسع بكثير من مستهلك واحد يوجّه الرسائل إلى أنظمة متعددة.

يجمع النمط الموصى به بين SNS وSQS: إذ تُنشر الرسالة إلى SNS، التي توزعها بشكل متشعب إلى قوائم انتظار SQS متعددة. ويوفر ذلك ما يلي:

• المتانة: إذا كان أحد المستهلكين متوقفًا، تُخزّن الرسائل في قائمة انتظار SQS
• التوسع المستقل: يعالج كل مستهلك الرسائل بالسرعة التي تناسبه
• فك الاقتران: لا يحتاج المستهلكون الجدد إلا إلى الاشتراك في SNS من دون تغيير الناشر
• المرونة في إعادة المحاولة: توفر SQS مهلة الرؤية وقائمة انتظار الرسائل غير القابلة للتسليم

يفتقر المشتركون المباشرون في Lambda إلى التخزين المؤقت الذي توفره SQS، مما يجعل SNS→SQS→Lambda النمط ثلاثي الطبقات الأكثر مرونة.

عندما تفشل SNS في التسليم إلى أحد المشتركين (مثلما يعيد أحد نقاط نهاية HTTP الرمز 5xx، أو تُلقي Lambda استثناءً، أو تصبح SQS غير متاحة)، فإنها تعيد المحاولة باستخدام استراتيجية التراجع الأسي. وتختلف سياسات إعادة المحاولة حسب البروتوكول: تحصل نقاط نهاية HTTP على ما يصل إلى 4 محاولات فورية، تليها إعادة محاولات مع تراجع أسي على مدار 23 يومًا؛ بينما تتم إدارة محاولات Lambda وSQS بواسطة آليات إعادة المحاولة الخاصة بهما. اضبط قائمة DLQ لموضوع SNS لالتقاط الرسائل التي تستنفد جميع محاولات التسليم، مما يضمن عدم فقدان أي أحداث دون إشعار.

يمكنكم النشر إلى SNS باستخدام AWS SDK أو CLI. ويمكن أن تتضمن كل رسالة Subject (للبريد الإلكتروني)، ونص Message (بحجم يصل إلى 256 كيلوبايت)، وMessage Attributes لأغراض التوجيه. وبالنسبة إلى أنواع المشتركين المختلفة (SQS مقابل البريد الإلكتروني مقابل الأجهزة المحمولة)، يمكنكم استخدام Message Structure لإرسال محتوى مختلف إلى كل بروتوكول؛ إذ تتيح مفاتيح JSON الخاصة بكل بروتوكول تخصيص الحمولة لكل نوع من المشتركين.

تتيح سياسات تصفية الاشتراك لكل مشترك تلقي الرسائل ذات الصلة به فقط، استنادًا إلى سمات الرسالة. ومن دون التصفية، يتلقى جميع المشتركين كل الرسائل المنشورة. أما مع سياسة التصفية، فيحدد المشترك قيم السمات التي يهتم بها. على سبيل المثال، يشترك طابور طلبات 'PREMIUM' باستخدام عامل التصفية {"orderType": ["PREMIUM"]}؛ بينما يصفّي طابور 'STANDARD' باستخدام ["STANDARD"]. وهكذا يعالج كل مشترك المجموعة الفرعية ذات الصلة به فقط، مما يقلل المعالجة غير الضرورية.

تدعم SNS إشعارات الدفع المباشر إلى الأجهزة المحمولة التي تعمل بنظام iOS (APNs) وAndroid (FCM/GCM). تسجلون رموز الأجهزة باعتبارها ARNs لنقاط نهاية المنصة، ثم تنشرون مباشرةً إلى نقطة نهاية أو إلى موضوع يضم مشتركين من تطبيقات المنصة. ولإرسال إشعارات مباشرة إلى الأجهزة على نطاق واسع (ملايين الأجهزة)، يمكنكم دمج SNS مع التوزيع المتشعب باستخدام SQS: إذ توجّه SNS حدث الإشعار إلى SQS، وتتولى خدمة عاملة حل رموز الأجهزة وتسليمها على نطاق واسع.

احموا رسائل SNS باستخدام التشفير من جانب الخادم عبر AWS KMS. ويعمل ذلك على تشفير الرسائل أثناء تخزينها داخل البنية التحتية لـ SNS. ويستخدم التحكم في الوصول كلاً من السياسات المستندة إلى الموارد (لتحديد من يمكنه النشر إلى الموضوع أو الاشتراك فيه) وسياسات IAM. وللسماح لحاوية S3 بنشر إشعارات إلى موضوع SNS، امنحوا sns:Publish إلى مسؤول خدمة S3 في سياسة موارد الموضوع. احرصوا دائمًا على تقييد النشر ليقتصر على المصادر المصرّح لها، لمنع حقن الأحداث غير المصرّح به.

تُعد SNS وSQS خدمتين متكاملتين وليستا بديلتين لبعضهما. تُستخدم SNS (الدفع) للبث الفوري إلى مستهلكين متعددين، وذلك عندما يتعين على أنظمة متعددة الاستجابة لحدث ما. أما SQS (السحب) فتُستخدم للمعالجة الموثوقة والمتينة بواسطة مستهلك واحد، مع إعادة المحاولة وقائمة DLQ، وذلك عندما يتعين على مستهلك واحد معالجة كل رسالة مرة واحدة فقط وبالسرعة التي تناسبه. ويوفر نمط التوزيع المتشعب SNS→SQS المزاياَ كلها: تسليم البث من SNS والمعالجة المتينة القابلة لإعادة المحاولة من SQS. ويظهر هذا الدمج كثيرًا في سيناريوهات اختبار SAA-C03.

اختبر مدى فهمكم لمفاهيم AWS Solutions Architect (SAA-C03) الواردة في هذا الدرس.

تعلّمتم في هذا الدرس ما يلي: توفر موضوعات SNS بثًا بنمط النشر/الاشتراك قائمًا على الدفع إلى المشتركين، بما في ذلك SQS وLambda وHTTP والرسائل النصية والبريد الإلكتروني في الوقت نفسه؛ وتستخدم بنية التوزيع المتشعب موضوع SNS واحدًا يغذي قوائم انتظار SQS متعددة لتحقيق معالجة متينة وقابلة للتوسع المستقل للأحداث بواسطة مستهلكين متعددين؛ كما تقلل سياسات تصفية الاشتراك المعالجة غير الضرورية عبر توجيه الأحداث ذات الصلة فقط إلى كل مشترك، استنادًا إلى سمات الرسالة. بعد ذلك، سنستكشف تصفية رسائل SQS وتكامل SNS + SQS بالتفصيل.