التعافي من الكوارث وتعدد المناطق

أنماط التطبيقات متعددة المناطق

18 دقيقة الدرس 5 من 27

أنماط التطبيقات متعددة المناطق

تشغيل تطبيق في مناطق جغرافية متعددة ليس مجرد تفصيل في عملية النشر — بل قرار معماري يتشعب في كل طبقة من طبقات بنيتك التقنية: منطق التوجيه، ومخطط قاعدة البيانات، وتماسك الذاكرة المؤقتة، وإدارة الجلسات، ومستويات الخدمة التي يمكنك وعد العملاء بها بصدق. يتناول هذا الدرس الأبعاد الثلاثة التي يجب على المهندسين إتقانها قبل أن تبدأ أي منطقة ثانية في استقبال حركة البيانات: كيف تصل الطلبات إلى المنطقة الصحيحة، وأين تقطن البيانات ولماذا يهم ذلك، وكيف يتصرف النظام حين تكون منطقة ما متدهورة جزئياً أو متوقفة كلياً.

توجيه الحركة بين المناطق

على مستوى DNS، تهيمن ثلاث استراتيجيات توجيه على بيئات الإنتاج:

التوجيه المبني على زمن الاستجابة — تقيس كل من AWS Route 53 وGoogle Cloud DNS وCloudflare زمن رحلة الذهاب والإياب (RTT) من المُحلِّل إلى كل نقطة إقليمية وتوجّه الاستعلام إلى أقرب منطقة سليمة. هذا هو الاختيار الافتراضي للأحمال الموجهة للمستخدم. الفخ هنا هو عدم التطابق بين موقع المُحلِّل وموقع المستخدم — مُحلِّل DNS شركاتي في لندن يخدم مستخدماً على هاتفه في دبي سيوجّه بشكل خاطئ.
التوجيه الجغرافي — يوجّه بناءً على الأصل الجغرافي لاستعلام DNS لا بناءً على RTT المقاسة. مفيد لامتثال إقامة البيانات (يجب أن تظل بيانات الاتحاد الأوروبي داخله) ولتعيين مزودي خدمة إنترنت أو دول بعينها إلى طاقة استيعابية مخصصة.
التوجيه الوزني — يقسم الحركة بنسب مئوية. يُستخدم أثناء الطرح الجزئي لمنطقة جديدة (10% إلى المنطقة الجديدة) وأثناء إفراغ حركة منطقة فاشلة (تخفيض وزن us-east-1 من 100 إلى 0 على مدى 5 دقائق بدلاً من قطع مفاجئ).

TTL في DNS قيد صارم. عند TTL مدته 60 ثانية، يمكن لمنطقة فاشلة أن تستقبل حركة لمدة 60 ثانية بعد تحديث السجل. تضيف فحوصات صحة Route 53 بفاصل 10 ثوانٍ وحد 3 إخفاقات نحو 30 ثانية إضافية من وقت الكشف. صمم RTO الخاص بك حول هذا: الحد الأدنى المطلق للتحول القائم على DNS هو نحو 90 ثانية. إذا احتجت تحولاً أقل من 30 ثانية، فأنت بحاجة إلى طبقة anycast (Cloudflare أو AWS Global Accelerator أو GCP Premium Tier) تُعيد التوجيه على مستوى الشبكة متجاوزةً تماماً تخزين DNS.

Anycast مقابل توجيه DNS: يُسند AWS Global Accelerator عناوين IP ثابتة anycast تُوجِّه عبر شبكة AWS الداخلية إلى أقرب نقطة إقليمية سليمة. خلافاً لـDNS، يحدث هذا التوجيه في ميلي ثوانٍ — لا TTL تنتظر انتهاءه، ولا ذاكرات مُحلِّل تنتهي صلاحيتها. المقايضة هي التكلفة (~0.025 دولار/GB فوق تكلفة نقل البيانات) وحقيقة أنك توجّه كل حركة TCP عبر بنية AWS التحتية مما يُعقّد إنهاء mTLS وتسجيل عنوان IP المصدر.

# Route 53: توجيه مبني على زمن الاستجابة مع تحول تلقائي عند فشل الصحة
# Terraform — سجلان من نوع A، واحد لكل منطقة، سياسة زمن الاستجابة

resource "aws_route53_health_check" "us_east" {
  fqdn              = "us-east-1.api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
  request_interval  = 10
}

resource "aws_route53_record" "api_us_east" {
  zone_id         = var.hosted_zone_id
  name            = "api.example.com"
  type            = "A"
  set_identifier  = "us-east-1"
  health_check_id = aws_route53_health_check.us_east.id

  latency_routing_policy {
    region = "us-east-1"
  }

  alias {
    name                   = aws_lb.us_east.dns_name
    zone_id                = aws_lb.us_east.zone_id
    evaluate_target_health = true
  }
}

# نفس الكتلة لـeu-west-1 (set_identifier = "eu-west-1")

أسفل طبقة DNS، يتحكم موزع حمل عالمي أو service mesh في التوجيه لكل طلب. يدعم كل من Envoy وIstio موازنة الحمل المُدركة للموقع الجغرافي — تُفضّل حاوية في us-east-1a نقاط النهاية في نفس منطقة التوفر، ثم نفس المنطقة الجغرافية، ولا تنتقل إلى منطقة أخرى إلا حين تنفد الطاقة المحلية. هذا بالغ الأهمية للزمن والتكلفة: نقل البيانات عبر المناطق أبطأ ويُفوتَر بأسعار الخروج.

توطين البيانات

التوجيه هو الجزء السهل. البيانات هي المكان الذي يصعب فيه تعدد المناطق. كل قراءة/كتابة يجب أن تُجيب: على أي نسخة من البيانات أعمل، وهل هي متسقة مع الأخريات؟

أبرز الأنماط الإنتاجية:

الكتابة في المنطقة الأساسية وقراءة من النسخ — تذهب جميع الكتابات إلى منطقة واحدة (الأساسية)، تُنسخ منها بشكل غير متزامن إلى المناطق الثانوية. يمكن خدمة القراءات محلياً من أقرب نسخة. بسيط في التفكير؛ المقايضة هي أن تأخر النسخ (عادةً 10-200ms لنسخ Postgres المتدفقة المضبوطة جيداً، لكن يمكن أن يرتفع إلى ثوانٍ تحت كتابة كثيفة) يعني أن القراء قد يرون بيانات قديمة قليلاً.
نشط-نشط مع حل تعارضات — تقبل كل منطقة كتابات على مجموعة بيانات مشتركة. يتطلب إما قاعدة بيانات موزعة ذات اتساق عالمي (CockroachDB أو Spanner أو DynamoDB Global Tables) أو تقسيماً دقيقاً يضمن ألا تكتب منطقتان على نفس السجل. تستخدم DynamoDB Global Tables آخر كاتب يفوز مع vector clock؛ تستخدم Spanner نموذج TrueTime. كلاهما يفرض تأخراً في الكتابة يتناسب مع زمن الذهاب والإياب بين المناطق (50-150ms للمناطق المتجاورة).
توطين البيانات بالتقسيم الجغرافي للمستخدمين — تُقسَّم المستخدمون حسب الجغرافيا. بيانات المستخدمين الأوروبيين تقطن في منطقة الاتحاد الأوروبي؛ بيانات المستخدمين الأمريكيين في us-east-1. كل منطقة هي أساسية فعلياً لقطاعها. هذا هو النمط الذي تستخدمه Stripe وShopify وجل الشركات ذات التزامات GDPR الأوروبية.

فخ تماسك الذاكرة المؤقتة: يُشغّل الفرق كثيراً Redis بأساسي في منطقة وقارئات في أخرى، ثم يكتشفون أن ذاكرة تخزين قديمة في eu-west-1 تخدم مستخدماً بيانات حُذفت أو عُدِّلت في us-east-1. بالنسبة للبيانات المرتبطة بالمستخدم (الجلسات، الصلاحيات، الأرصدة)، القراءات القديمة هي خطأ في الصحة لا مجرد مشكلة أداء. إما اقبل الاتساق النهائي صراحةً في تصميم منتجك، أو وجّه الكتابات والقراءات لمستخدم معين إلى منطقة واحدة.

معمارية نشط-نشط

النشط-نشط يعني أن جميع المناطق تخدم حركة كتابة حية في آنٍ واحد دون أساسي واحد. هو المعيار الذهبي للتوفر لكنه النمط الأكثر تعقيداً في التشغيل.

نشط-نشط عبر ثلاث مناطق: كل منطقة تخدم كتابات حية؛ Kafka ينسخ الأحداث في كلا الاتجاهين؛ فحوصات صحة DNS تُؤتمت التحول عند انقطاع منطقة.

قواعد تصميم أساسية للنشط-نشط:

قسّم الكتابات بمفتاح ثابت. أأمن نمط نشط-نشط هو حين لا يُكتب على نفس السجل المنطقي من منطقتين في آنٍ واحد. استخدم consistent hashing على user_id أو tenant_id لتثبيت مستخدم في منطقة مرجعية. تلك المنطقة تمتلك كتاباته؛ المناطق الأخرى هي قارئات له. هذا يُقصي مشكلة التعارض كلياً.
اجعل العمليات idempotent. الأحداث المُنسوخة عبر المناطق قد تصل خارج الترتيب أو تُسلَّم أكثر من مرة. يجب أن تحمل كل عملية كتابة vector version أو UUID حتمي حتى لا يكون للتطبيق المكرر أي أثر.
تتبع تأخر النسخ كـSLI من الدرجة الأولى. ضع مقياس Prometheus لتأخر النسخ على قاعدة البيانات وطابور الرسائل. تنبيه عند 5 ثوانٍ، ونداء عند 30 ثانية. أثناء تدهور منطقة، يرتفع التأخر قبل انخفاض التوفر — هو إنذارك المبكر.

الثبات الساكن

الثبات الساكن مبدأ مفاده أن كل منطقة يجب أن تكون قادرة على العمل باستقلالية تامة — خدمة كل حركتها، وتوسيع حوسبتها، والتعافي من الأعطال — دون إجراء أي استدعاء API عبر المناطق. يبدو هذا بديهياً لكنه ينكسر باستمرار في الممارسة.

انتهاكات الثبات الساكن الشائعة:

خدمة مصادقة تتحقق من JWTs بالاستدعاء إلى نقطة استفسار عن الرمز في المنطقة الأساسية. حين تتدهور us-east-1، تفشل تسجيلات الدخول في eu-west-1.
أنظمة Kubernetes تسحب صور الحاويات من سجل ECR في منطقة واحدة. فشل منطقة يُعطّل النشر في كل مكان.
علامات الميزات تُجلب من مستوى تحكم مركزي مع كل طلب. إذا كان مستوى التحكم غير متاح، يكون الاحتياطي غير محدد وقد يُعيد "كل الميزات معطّلة."
الأسرار تُسترجع من Vault أو AWS Secrets Manager أحادي المنطقة عند بدء تشغيل الحاوية. تفشل الحاويات في البدء في مناطق سليمة أثناء حادثة في مستوى التحكم.

# الثبات الساكن: تخزين علامات الميزات محلياً في كل منطقة
# LaunchDarkly relay proxy (أو Flagsmith self-hosted) لكل منطقة
# كل تطبيق يقرأ من relay المحلي؛ relay يتدفق من المركزي

# مقتطف نشر Kubernetes (LaunchDarkly relay)
env:
  - name: LD_RELAY_CONFIG
    value: /etc/ld/relay.toml
# relay.toml
[relay]
  heartbeatIntervalMs = 10000
  # يعود إلى آخر حالة علامات معروفة إذا لم يتوفر المجرى الأعلى
  offlineCachePath = /var/cache/ld-relay

---
# الثبات الساكن: ذاكرة تمرير ECR متعددة المناطق
# كل منطقة لديها سجل ECR خاص بها؛ تُدفع الصور إلى الجميع عند البناء
# ArgoCD ImageUpdater يُبلّغ الأنظمة الإقليمية باستقلالية
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-image-updater-config
data:
  registries.conf: |
    registries:
      - name: ECR us-east-1
        prefix: 123456789.dkr.ecr.us-east-1.amazonaws.com
        api_url: https://123456789.dkr.ecr.us-east-1.amazonaws.com
        credentials: ext:/scripts/ecr-login.sh
        default: true
      - name: ECR eu-west-1
        prefix: 123456789.dkr.ecr.eu-west-1.amazonaws.com
        api_url: https://123456789.dkr.ecr.eu-west-1.amazonaws.com
        credentials: ext:/scripts/ecr-login.sh

الاختبار الحاسم للثبات الساكن هو يوم لعبة الفوضى حيث تحجب تماماً كل حركة الشبكة عبر المناطق (باستخدام قاعدة deny-all في security group أو تجربة شبكية فوضوية) وتتحقق أن كل منطقة تواصل خدمة 100% من حركتها المحلية لمدة 30 دقيقة على الأقل. الفرق التي لم تُشغّل هذا الاختبار تكتشف باطّراد تبعية عبر مناطق لم تعرف بوجودها.

صمّم للحالة الاعتيادية "split-brain". تقضي الأنظمة متعددة المناطق وقتاً أطول في وضع التدهور الجزئي (منطقة متأخرة، مستوى تحكم غير متاح) مقارنةً بحالة الانقطاع الكامل النظيف. يجب أن تتعامل runbooks والتنبيهات وكود التطبيق مع الحالات الوسطى: منطقة متاحة لكن تُعيد أخطاء مرتفعة، قاعدة بيانات نسخ متأخرة 45 ثانية، أو مخزن إعدادات يُعيد بيانات قديمة. هذه أصعب في الكشف وأصعب في التعافي من فشل منطقة نظيف.

اختيار النمط الصحيح

ليست كل حمولة عمل بحاجة إلى نشط-نشط. التكلفة — في تعقيد هندسي، وترخيص قاعدة بيانات، ورسوم خروج البيانات عبر المناطق، وعبء التشغيل — جوهرية. طابق النمط مع متطلب التوفر والزمن الفعلي:

نشط-سلبي مع احتياطي دافئ: RTO من 5 إلى 15 دقيقة، 30-50% من تكلفة النشط. كافٍ لمعظم B2B SaaS بـSLA 99.9%.
نشط-نشط مقسّم بالمستخدم: RTO أقل من 90 ثانية (TTL DNS)، لا تعارضات في الكتابة. الاختيار الصحيح للمنتجات الاستهلاكية ذات المستخدمين العالميين وSLA أعلى من 99.95%.
نشط-نشط موزع كلياً (Spanner/CockroachDB): RTO أقل من 30 ثانية، multi-master حقيقي. ضروري للسجلات المالية وأنظمة المخزون وأي حمولة يُعدّ فيها القراءة القذرة تحت التحول غير مقبول. التكلفة 3-10 أضعاف النشر أحادي المنطقة.

النمط الذي تختاره اليوم يحدد مسار الترحيل الذي ستواجهه إذا تغيرت متطلباتك. البدء بتصميم نشط-سلبي محكم الفصل — حدود خدمات نظيفة، وكتابات idempotent، ونسخ قائم — يُبقي الباب مفتوحاً للانتقال لاحقاً إلى نشط-نشط دون إعادة كتابة كاملة.