اعتبارات هامّة عند ترحيل الأنظمة والتطبيقات بين مناطق AWS

توفر HAQM Web Services (AWS) منصة سحابية متكاملة تتميز بموثوقيتها العالية وقابليتها للتوسع وتكلفتها المنخفضة، وذلك عبر العديد من المناطق (Regions) حول العالم. صُممت هذه المناطق لتكون معزولة عن بعضها البعض، مما يمنح التطبيقات مستوىً عالياً من المرونة والقدرة على تحمل الأعطال. وتنقسم هذه المناطق إلى تقسيمات (Partitions) مثل aws وaws-gov وaws-cn وaws-iso، حيث تتميز هذه التقسيمات بمستوى أعلى من العزل من حيث الشبكة والأمان.

مع توسع AWS وافتتاح مناطق جديدة، يتزايد اهتمام العملاء بترحيل أنظمتهم وتطبيقاتهم (Workloads) من مناطقهم الحالية إلى مناطق أخرى، سواء لتحسين زمن الاستجابة (Latency) أو للامتثال لمتطلبات تنظيمية جديدة. ومن السيناريوهات الشائعة أيضاً رغبة مزوّدي البرامج المستقلين (ISVs) في توسيع نطاق خدماتهم عبر تقديم حلولهم في مناطق جديدة. تتطلّب هذه المبادرات اتباع مراحل الترحيل المعتادة، بدءاً من تقييم البيئة الحالية، مروراً بتجهيز الموارد، وانتهاءً بتنفيذ عملية الترحيل.

تتناول هذه المقالة أبرز النقاط التي ينبغي مراعاتها عند ترحيل الأنظمة والتطبيقات بين منطقتين داخل نفس التقسيم (Partition) في AWS. تجدر الإشارة إلى أن نقل البيانات عبر تقسيمات مختلفة يتطلب اعتبارات إضافية لا تغطيها هذه المقالة.

إعداد دراسة جدوى ومراعاة التكاليف

كما هو الحال في أي مشروع ترحيل، يُنصح بالبدء بمرحلة التقييم وإعداد دراسة جدوى شاملة.

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

عند تقييم التكاليف، ضع في اعتبارك العناصر التالية إلى جانب تكاليف المشروع المعتادة:

أسعار الخدمات: تتفاوت أسعار خدمات AWS بين المناطق المختلفة. لذا، من الضروري مراجعة أسعار الخدمات في المنطقة المستهدفة وتقدير التكلفة الإجمالية للتشغيل هناك.
الالتزامات المالية: راجع التزاماتك الحالية مثل حجوزات HAQM EC2 (Reserved Instances) وخطط التوفير (Savings Plans)، حيث أنها غالباً ما تكون مرتبطة بمنطقة محددة. يمكنك النظر في بيع الحجوزات الحالية في سوق AWS للحجوزات، أو شراء حجوزات جديدة في المنطقة المستهدفة.
تكاليف ترحيل البيانات : تُفرض رسوم على ترحيل البيانات من المنطقة الأصلية إلى المنطقة الجديدة، بينما لا توجد رسوم على استقبال البيانات. تختلف هذه الرسوم حسب وسيلة النقل المستخدمة (مثل الإنترنت، أو VPC Peering، أو Transit Gateway).

تحديد مكونات النظام المراد ترحيلها

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

فيما يلي أمثلة على المكونات التي يُمكن ترحيلها:

الإعدادات: وتشمل مجموعات الخيارات (Parameter groups) في HAQM RDS أو إعدادات المراقبة التفصيلية في HAQM EC2 و VPC Flow Logs.
حزم التعليمات البرمجية والبرمجيات: مثل حزم التعليمات البرمجية والبرمجيات المتوفرة في صور حاويات في HAQM ECR أو وظائف في AWS Lambda.
البيانات: وتتضمن البيانات التاريخية والحالية، حيث يعتمد قرار ترحيلها على متطلبات العمل. على سبيل المثال، يمكن الاحتفاظ بالبيانات التاريخية في HAQM S3 Glacier.
البيانات المساندة: وتشمل النسخ الاحتياطية واللقطات والسجلات، والتي قد لا تكون ضرورية للتشغيل المباشر للتطبيق، ويمكن الاحتفاظ بها في المنطقة الأصلية.

ضمان التوافق في المنطقة المستهدفة

قد تختلف مناطق AWS في خصائصها وإمكاناتها، وقد تكون هذه الاختلافات مؤقتة نظراً لتباين مواعيد إطلاق الخدمات والميزات في المناطق المختلفة. لذا، من الضروري التحقق من توافق الأنظمة والتطبيقات مع المنطقة المستهدفة قبل الشروع في عملية الترحيل. ويتم ذلك من خلال إجراء جرد شامل لمكونات بيئة العمل الحالية، بما في ذلك أنواع الخوادم الافتراضية، والخدمات المستخدمة، وإصدارات البرمجيات، والحصص المخصصة (Quotas)، ثم مقارنتها بما هو متاح في المنطقة الجديدة.

النقاط الرئيسية التي تتطلب المراجعة:

أنواع الخوادم الافتراضية : (Instance types) قد لا تتوفر بعض الأنواع في جميع المناطق.
منتجات الطرف الثالث: بعض صور AMI أو الحاويات أو التراخيص قد لا تكون متاحة في كل المناطق.
توفر الميزات: قد تكون بعض الخدمات متاحة جزئياً أو غير مدعومة ببعض الميزات في مناطق معينة.
الإصدارات: قد تختلف إصدارات البرمجيات المتاحة بين المناطق.
القيود: تتفاوت الحصص الافتراضية للخدمات بين المناطق، مع إمكانية طلب زيادتها لبعض الخدمات.
الامتثال: تحقق من تقارير AWS Artifact للتأكد من التوافق مع المعايير التنظيمية المطلوبة.

تأسيس البنية الأساسية في المنطقة الجديدة

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

تشمل المجالات الرئيسية للتأسيس:

البنية التحتية: تهيئة الشبكات مثل Direct Connect و Transit Gateway.
الأمان: تحديث السياسات الأمنية وإعداد IAM و KMS وغيرها من خدمات الحماية.
استمرارية الأعمال: تعزيز قدرة النظام على تحمل الأعطال وتحديد منطقة ثانوية للطوارئ.
العمليات: عداد أنظمة مراقبة الأداء، وفحص الصحة، وتحديث آليات التنبيه والمراقبة.
الجوانب المالية: تأسيس آليات لتتبع النفقات حسب المنطقة وتحسين إدارة التكاليف.
الامتثال والحوكمة: توسيع نطاق السياسات والإجراءات الرقابية لتشمل المنطقة الجديدة.

اختيار مسار الترحيل المناسب

على الرغم من أننا نركز هنا على إعادة الاستضافة في منطقة جديدة (Rehosting)، إلا أن هناك استراتيجيات متعددة للترحيل. نوصي بالبدء بتصنيف الخدمات حسب قابليتها للعمل عبر المناطق، ثم اختيار المسار الأنسب من المسارات التالية:

الخدمات العالمية

مثل HAQM Route 53 وHAQM CloudFront. يتم تعديل إعداداتها لتشمل المنطقة الجديدة في نطاق عملها.

الخدمات القابلة للتوسع عبر المناطق

تشمل خدمات مثل HAQM Aurora Global Database و HAQM DynamoDB وAWS KMS. تتطلب هذه الخدمات تعديلات في الإعدادات لتوسيع نطاق عملها ليشمل المنطقة المستهدفة. على سبيل المثال، في AWS KMS، يمكن إنشاء نسخ متماثلة من المفاتيح (Replica Keys) في المنطقة الجديدة عند استخدام مفاتيح يديرها العميل. كما تدعم قواعد بيانات Aurora Global إضافة مناطق ثانوية (Secondary Regions)، مما يعزز توافر وموثوقية قواعد البيانات عبر المناطق الجغرافية المختلفة.

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

الخدمات الإقليمية الأخرى

إعادة النشر (Redeploy): يمكنك إعادة إنشاء الخدمة من جديد في المنطقة المستهدفة لخدمات مثل HAQM ECR وAWS Lambda وHAQM Simple Queue Service (SQS)، بالإضافة إلى التطبيقات عديمة الحالة (Stateless) التي تعمل على HAQM EC2.
بالنسبة لبعض الخدمات مثل AWS DMS وAWS Elastic Disaster Recovery، فإن الخيار الوحيد المتاح هو إعادة إنشاء الخدمة وتهيئتها بالكامل في المنطقة الجديدة.

الاستعادة (Restore): يمكنك أخذ نسخ احتياطية أو لقطات (Snapshots) واستعادتها في المنطقة المستهدفة، وذلك لخدمات مثل HAQM EC2 وHAQM RDS. يُعد هذا الخيار مناسباً عندما تحتاج إلى ترحيل حالة النظام أو قاعدة البيانات كما هي، مع الحفاظ على إعداداتها وبياناتها.

النسخ (Replicate): يمكنك الاستفادة من أدوات النسخ المتماثل مثل AWS Application Migration Service لترحيل الخوادم، وAWS DataSync لخدمة HAQM FSx. كما توفر بعض البرمجيات مثل PostgreSQL وMySQL آليات نسخ مدمجة (Native Replication) يمكن استخدامها أيضاً في ترحيل الأنظمة والتطبيقات. عند استخدام أداة نسخ من AWS، تأكد من توفر الخدمة والميزات المطلوبة في كل من المنطقة المصدر والمنطقة المستهدفة قبل بدء عملية الترحيل.

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

الخلاصة

يُعد التخطيط الشامل وإجراء الاختبارات الدقيقة أمراً ضرورياً عند تنفيذ أي نوع من عمليات الترحيل، بما في ذلك الترحيل بين مناطق AWS المختلفة. ينبغي على العملاء مراعاة جميع جوانب عملية النقل، بما في ذلك وضع خطط للعودة (Failback) للتعامل مع أي سيناريوهات غير متوقعة.

تُسهّل AWS هذا النوع من العمليات من خلال توفير عدة مسارات للترحيل، وأدوات متقدمة، بالإضافة إلى إمكانية الاحتفاظ بالبنية التحتية الحالية حتى اكتمال عملية النقل بنجاح.

إذا كانت لديك أي استفسارات حول ترحيل الأنظمة والتطبيقات بين مناطق AWS، يمكنكم التواصل مع جهات الدعم في AWS المعتادة الخاصة بك.

المدوَّنة العربية