Get a quote

النشر متعدد المناطق لمنتجات SaaS في AWS لمنطقة MENA

المنتجات اللبنانية الموجهة لأسواق الخليج تواجه مشكلة الزمن المضاف: سيرفر في أوروبا يضيف 100-200ms لمستخدمي الرياض ودبي. هذا دليل عملي للنشر متعدد المناطق على AWS لشركات SaaS في MENA.

مشكلة الزمن المضاف للمنتجات اللبنانية في الخليج

المنتجات اللبنانية الموجهة لأسواق الخليج تواجه مشكلة زمن الاستجابة: خادم في أوروبا (eu-west-1) يضيف 100-200 مللي ثانية لمستخدمي الرياض ودبي. لنظام POS للمطاعم مثل RTYLR يخدم مشغّلين في الخليج، هذا الزمن المضاف ملحوظ.

النشر متعدد المناطق ليس مجرد تحسين للزمن المضاف. إنه الفرق بين الشعور بأنك منتج محلي والشعور بأنك منتج دولي بطيء. مشغّلو الخليج لديهم بدائل محلية. الزمن المضاف مشكلة استبقاء.

هذا المقال يغطي البنية التي نستخدمها للنشر متعدد المناطق على AWS، شاملاً اختيار المنطقة، التوجيه، إعداد ECS Fargate، استراتيجية قاعدة البيانات، وتكاليف SaaS في مرحلته الأولى.

اختيار مناطق AWS لتغطية MENA

لدى AWS منطقتان مخصصتان لـ MENA:

  • me-south-1 (البحرين): تغطية جيدة للمملكة العربية السعودية والكويت والبحرين. أوسع دعماً للخدمات.
  • me-central-1 (الإمارات): مثالية إذا كان لديك حركة مرور كبيرة من الإمارات أو متطلبات إقامة بيانات إماراتية.
  • eu-west-1 (أيرلندا): منطقة الأصل، حيث يعيش نقطة الكتابة الأساسية لقاعدة البيانات.

لـ RTYLR، نستخدم me-south-1 وeu-west-1. هذا يقطع زمن الاستجابة في الخليج من ~150 مللي ثانية إلى ~25 مللي ثانية.

لاحظ أن ليس كل خدمات AWS متاحة في مناطق MENA. قبل الالتزام بمنطقة، تحقق من توفر الخدمات التي تحتاجها (ElastiCache، SES، وغيرها).

توجيه Route 53 المعتمد على الزمن المضاف

التوجيه المعتمد على الزمن المضاف في Route 53 هو أبسط طريقة لإرسال المستخدمين إلى أقرب منطقة. كل منطقة تحصل على سجل زمن استجابة يشير إلى ALB الإقليمي.

قرارات التكوين الرئيسية:

فحوصات الصحة: كل سجل زمن استجابة يجب أن يكون له فحص صحة Route 53. إذا كان ALB الإقليمي غير صحي، يتوقف Route 53 عن التوجيه إليه.

TTL: اضبط TTL على 60 ثانية. القيم الأقل تعني تجاوزاً أسرع للأعطال لكن استعلامات Route 53 أكثر.

الجمع بين الزمن المضاف والتجاوز: يمكنك الجمع بين التوجيه المعتمد على الزمن المضاف وتوجيه التجاوز. يمنحك هذا مزايا زمن الاستجابة الإقليمية مع احتياطي عالمي.

نشر ECS Fargate لكل منطقة

التطبيق يعمل على ECS Fargate. كل منطقة لها مجموعة ECS مستقلة بنفس تعريفات المهام. نفس صورة الحاوية تعمل في كلتا المنطقتين. لا يوجد كود خاص بمنطقة.

بنية Terraform تستخدم وحدة لكل منطقة. النشرات تحدّث كلتا المنطقتين. نستخدم استراتيجية نشر أزرق-أخضر على مستوى خدمة ECS، نحدّث eu-west-1 أولاً، نتحقق من الصحة، ثم نحدّث me-south-1.

قرارات رئيسية لـ ECS متعدد المناطق:

  • نفس ARN تعريف المهمة: تعريفات المهام عالمية في AWS. كلتا المنطقتين تشيران إلى نفس مراجعة تعريف المهمة.
  • ALBs منفصلة: كل منطقة لها Application Load Balancer خاص بها.
  • شبكات VPC منفصلة مع شبكات فرعية خاصة: المهام تعمل في شبكات فرعية خاصة.

استراتيجية قاعدة البيانات

قاعدة البيانات هي الجزء الأصعب في التعدد الإقليمي. نستخدم Aurora PostgreSQL مع Aurora Global Database.

Aurora Global Database يمنحك:

  • مجموعة كتابة أساسية في منطقة واحدة (eu-west-1 بالنسبة لنا)
  • نسخ قراءة في مناطق أخرى (me-south-1)
  • تأخر النسخ عادةً أقل من ثانية
  • تجاوز تلقائي للأعطال

الاستعلامات كثيفة القراءة تذهب إلى نسخة القراءة الإقليمية. عمليات الكتابة تذهب إلى كاتب الأساسي في eu-west-1 بغض النظر عن المنطقة التي وصل منها الطلب.

زمن كتابة إضافي من me-south-1 إلى eu-west-1 يضيف ~130 مللي ثانية لكل عملية كتابة. لـ RTYLR، معظم الكتابات هي إنشاء الطلبات وتحديثات الحالة. الزمن الإضافي على الكتابات مقبول.

الأسرار والتكوين عبر المناطق

AWS SSM Parameter Store إقليمي. كل منطقة لها نسختها الخاصة من الأسرار والتكوين. هذا النهج الصحيح. لا تشارك مسار SSM واحداً عبر المناطق.

عند بدء التشغيل، يقرأ التطبيق تكوينه من SSM Parameter Store الإقليمي. الأسرار تُملأ في SSM كل منطقة كجزء من نشر Terraform.

لا تبنِ الأسرار في صورة الحاوية أبداً. لا تمرر الأسرار كمتغيرات بيئة في تعريف مهمة ECS. اسحب دائماً من SSM عند بدء التشغيل.

التكاليف التقريبية

تقدير شهري لإعداد منطقتين (eu-west-1 + me-south-1):

  • ECS Fargate (مهمتان × منطقتان): ~60 دولار
  • ALB × منطقتان: ~40 دولار
  • Aurora Global Database: ~180 دولار
  • NAT Gateway × منطقتان: ~70 دولار
  • Route 53: ~10 دولار
  • الإجمالي: ~360 دولار

للمنتجات ذات الحركة المعتدلة، البقاء تحت 400 دولار شهرياً لتغطية منطقتين أمر قابل للتحقيق.

المراقبة عبر المناطق

CloudWatch إقليمي. كل منطقة تنتج مقاييسها وسجلاتها وتنبيهاتها بشكل مستقل.

أنشئ لوحة CloudWatch في eu-west-1 مع أدوات عبر المناطق تسحب المقاييس من me-south-1. أعدّ تنبيهات متطابقة في كلتا المنطقتين. وجّه جميع التنبيهات إلى نفس موضوع SNS الذي يُعيّن إلى Slack أو PagerDuty.

المقياس الأكثر فائدة عبر المناطق للتتبع: تأخر النسخ على قارئ Aurora Global Database. إذا تجاوز 5 ثوانٍ، قراءات الخليج تقدم بيانات قديمة.

دروس من أول نشر متعدد المناطق

  • اختبر التجاوز قبل الحاجة إليه. اجبر المنطقة الأساسية على أن تكون غير صحية في بيئة التدريج وتحقق من صحة التوجيه.
  • نسخ القراءة تتأخر تحت انفجارات الكتابة. أثناء معالجة دُفعة كبيرة، يمكن أن يرتفع تأخر النسخ لعدة ثوانٍ. صمّم عمليات القراءة لتحمل بيانات قديمة قليلاً.
  • me-south-1 لديها خدمات أقل من eu-west-1. واجهنا هذا مع ElastiCache عند إعداد منطقة الخليج. تحقق من توفر الخدمة قبل أن تعتمد عليها معمارياً.
  • انشر كلتا المنطقتين بشكل ذري. نشر يحدّث eu-west-1 لكن ليس me-south-1 يترك منطقتيك تشغّلان إصدارات تطبيق مختلفة.

هل تحتاج إلى مساعدة في البداية؟

إذا كنت تطوّر منتج SaaS في MENA وتحتاج إلى بنية تحتية متعددة المناطق جاهزة للإنتاج وفعّالة من حيث التكلفة، يمكن لـ Voxire مساعدتك في تصميمها ونشرها. تواصل معنا على https://voxire.com/get-a-quote/

العودة إلى المدونة
Chat on WhatsApp