في هذه الوحدة نتعمق في Cloud Architecting، ونفهم كيف وُلدت Amazon Web Services من رحم التحديات التي واجهتها أمازون في بداياتها عام 2000. سنتعرف على AWS Well-Architected Framework وإطاره المكون من ست ركائز، وعلى أفضل الممارسات لبناء الحلول على AWS، وعلى البنية التحتية العالمية من Regions وAvailability Zones وLocal Zones وPoPs. هذه الوحدة هي البوصلة التي توجّه قراراتك المعمارية في كل الوحدات التالية. تماماً كما يدرس الطبيب مبادئ التشريح قبل الجراحة، فإن هذه الوحدة تعلمك المبادئ قبل أن تبدأ في بناء أي بنية سحابية.
1️⃣ As a cloud architect
عندما تتخذ دور cloud architect لتصميم بنى على AWS، تحتاج أولاً إلى فهم ممارسة تطبيق أفضل ممارسات السحابة على الحلول. يجب أن تكون قادراً على تقييم أي بنية باستخدام AWS Well-Architected Framework، وتطبيق أفضل ممارسات بناء الحلول على السحابة. الأهم من ذلك كله أن cloud architect يعمل بتراجع من الاحتياجات التجارية لتصميم البنية المثلى. تخيل أنك تصمم مطعماً: لا تبدأ بعداد الطاولات، بل تبدأ بسؤال "من سيأكل هنا؟ ومتى؟ وكم يدفع؟"، ثم تصمم بناءً على ذلك.
2️⃣ Cloud computing and AWS
لفهم ماهية Cloud Architecting، يجب أن نعود إلى بدايات أمازون. في عام 2000، حاولت أمازون بناء خدمة تجارة إلكترونية للتجار الخارجيين، لكن البنية كانت معقدة جداً وصعبة التوسع. استغرق بناء قاعدة البيانات والحوسبة والتخزين ثلاثة أشهر من أصل مشروع كان مقرراً أن يستغرق نفس المدة. الحل كان في عام 2006 عندما أطلقت أمازون Amazon SQS، ثم Amazon S3، ثم Amazon EC2 كخدمات سحابية قابلة للتوسع. هذه الخدمات الثلاث هي البذرة التي نمت منها AWS الحالية التي تضم أكثر من 200 خدمة. تماماً كما تنمو شجرة من بذرة صغيرة، بدأت AWS من ثلاث خدمات بسيطة وأصبحت أكبر منصة سحابية في العالم.
3️⃣ Cloud architecture
Cloud architecture هي ممارسة تطبيق خصائص السحابة على حل يستخدم خدمات وميزات السحابة لتلبية احتياجات تقنية وتجارية. تشبه هذه الممارسة بناء مبنى حقيقي: لو كانت الأساسات ضعيفة، انهار المبنى بأكمله. في المبنى الحقيقي، يضع العميل متطلباته، ويصمم المعماري المخططات، ويبني فريق البناء المبنى. في السحابة، يحدد صاحب القرار الأهداف التجارية، ويصمم cloud architect الحل، وينفذه فريق التسليم. النتيجة في الحالتين واحدة: أنظمة متينة تحقق أهدافها. تماماً كما لا يبدأ بناء برج بدون رسومات هندسية، لا تبدأ بنية سحابية بدون تصميم معماري واضح.
4️⃣ Role of a cloud architect
دور cloud architect له ثلاث مراحل أساسية: التخطيط (Plan)، البحث (Research)، والبناء (Build). في مرحلة التخطيط، يضع الاستراتيجية التقنية السحابية مع قادة الأعمال، ويحلل الحلول لاحتياجات الشركة. في مرحلة البحث، يستقصي مواصفات خدمات السحابة، ويراجع بنى الأحمال الحالية، ويصمم نماذج أولية. في مرحلة البناء، يصمم خارطة طريق التحول بمعالم ومسارات عمل، ويدير التبني والهجرة. يتعامل cloud architect مع صانعي القرار لتحديد الأهداف، ويضمن التوافق بين المخرجات التقنية والأهداف التجارية. تماماً كما يقود المخرج الأوركسترا، فإن cloud architect ينسق بين الفرق المختلفة لتحقيق رؤية موحدة.
📖 قاموس مصطلحات المحور الأول
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Cloud architecture | المعمارية السحابية | ممارسة تطبيق خصائص السحابة على حل يلبي احتياجات تقنية وتجارية. |
| Cloud architect | معماري السحابة | خبير مسؤول عن تصميم البنية السحابية واختيار التقنيات لتحقيق الأهداف. |
| Amazon SQS | خدمة الطوابير البسيطة | خدمة لإدارة الرسائل بين الخدمات الموزعة، أول خدمات AWS التي أطلقت في 2006. |
| Amazon S3 | خدمة التخزين البسيطة | خدمة تخزين كائنات قابلة للتوسع، أطلقت في 2006 ولا تزال من أكثر الخدمات استخداماً. |
| Amazon EC2 | سحابة الحوسبة المرنة | خدمة حوسبة توفر آلات افتراضية قابلة للتعديل عبر السحابة. |
1️⃣ Pillars of the AWS Well-Architected Framework
AWS Well-Architected Framework هو دليل يوفر نهجاً متسقاً لتقييم البنى السحابية، ويقدم إرشادات لتنفيذ التصاميم. وُضع هذا الإطار بعد مراجعة آلاف البنى الخاصة بعملاء AWS. يصف الإطار أسئلة تأسيسية وأفضل ممارسات تساعدك على فهم ما إذا كانت بنية معينة متوافقة مع أفضل ممارسات السحابة. ينقسم الإطار إلى ست ركائز: Operational Excellence، Security، Reliability، Performance Efficiency، Cost Optimization، وSustainability. تتم مراجعة هذه الركائز في كل وحدة من وحدات الدورة. تماماً كما يحدد دستور البلاد المبادئ العليا للحكم، يحدد Well-Architected Framework المبادئ العليا لأي بنية سحابية ناجحة.
2️⃣ Operational Excellence pillar
ركيزة Operational Excellence تعالج القدرة على تشغيل الأنظمة والحصول على رؤى حول عملياتها لتقديم قيمة تجارية. كما تعالج القدرة على تحسين العمليات والإجراءات الداعمة باستمرار. عند تصميم حمل لعمليات التشغيل، يجب أن تكون واعياً بكيفية نشره وتحديثه وتشغيله. في AWS، يمكنك عرض كامل حملك (التطبيقات والبنية والسياسات والحوكمة والعمليات) ككود (infrastructure as code). هذا يتيح تطبيق نفس الانضباط الهندسي المستخدم في كود التطبيق على كل عنصر من عناصر بنيتك. ينصح بالاستثمار في تنفيذ أنشطة العمليات ككود لزيادة الإنتاجية وتقليل معدلات الخطأ. تماماً كما يحوّل الطاهي المحترف الوصفة إلى قائمة خطوات دقيقة، يحوّل Operational Excellence كل عملية إلى كود قابل للتكرار.
3️⃣ Security pillar
ركيزة Security تعالج القدرة على حماية المعلومات والأنظمة والأصول مع تقديم قيمة تجارية من خلال تقييم المخاطر واستراتيجيات التخفيف. تصبح بنية أمتك أقوى بكثير إذا طبقت أساس هوية قوي، وحافظت على قابلية التتبع، وطبقت الأمان على كل الطبقات، وأتمت أفضل ممارسات الأمان، وحميت البيانات أثناء النقل والتخزين. تنفيذ هذه المبادئ يساعدك على الاستعداد للأحداث الأمنية. تمتد الركيزة لتشمل سبعة مبادئ تصميم: أساس هوية قوي، حماية البيانات، الأمان متعدد الطبقات، إبعاد الأشخاص عن البيانات، قابلية التتبع، الاستعداد للأحداث، وأتمتة الأمان. تماماً كما لا تكتفي بباب أمامي لمنزلك بل تضع أقفالاً على النوافذ والكاميرات، فإن Security تتطلب دفاعاً متعدد الطبقات.
4️⃣ Reliability pillar
ركيزة Reliability تعالج قدرة النظام على التعافي من أعطال البنية أو الخدمة، واكتساب موارد حوسبة ديناميكياً لتلبية الطلب. كما تعالج قدرة النظام على التخفيف من الاضطرابات مثل سوء التهيئة أو مشاكل الشبكة المؤقتة. ضمان الموثوقية صعب في البيئات التقليدية بسبب نقاط الفشل الوحيدة، ونقص الأتمتة، ونقص المرونة. بتطبيق أفضل الممارسات في ركيزة Reliability، يمكنك منع معظم هذه المشاكل. تساعدك الركيزة على ضمان بنية مصممة بشكل صحيح من حيث التوافر العالي (high availability)، وتحمل الأخطاء (fault tolerance)، والتكرار (redundancy). تماماً كما يحتفظ المطعم الذكي بمكونات جاهزة لكل طبق، تحتفظ البنية الموثوقة بموارد بديلة جاهزة لتحل محل الفاشلة.
5️⃣ Performance Efficiency pillar
ركيزة Performance Efficiency تركز على تعظيم الأداء باستخدام موارد الحوسبة بكفاءة، والحفاظ على هذه الكفاءة مع تغير الطلب. من مبادئها الأساسية democratize advanced technologies: في المواقف التي يصعب فيها تنفيذ التكنولوجيا بنفسك، استخدم بائعاً متخصصاً. عندما يتولى البائع التعقيد والمعرفة، يتفرغ فريقك لعمل ذي قيمة أعلى. من المبادئ أيضاً mechanical sympathy: استخدام الأداة أو النظام بفهم لكيفية عمله الأمثل. على سبيل المثال، اختر نهج قاعدة البيانات بناءً على أنماط الوصول إلى البيانات. كما يجب اختيار الموارد الصحيحة ومراقبتها باستمرار. تماماً كما يختار السائق السيارة المناسبة لكل طريق، يختار المعماري الخدمة المناسبة لكل نمط استخدام.
6️⃣ Cost Optimization pillar
Cost Optimization هو مطلب مستمر لأي تصميم معماري جيد. هذه العملية تكرارية ويجب تنقيحها وتحسينها طوال عمر الإنتاج. فهم كفاءة بنيتك الحالية مقارنة بأهدافك يمكن أن يزيل النفقات غير الضرورية. اعتمد نموذج الاستهلاك المناسب لحالتك: نموذج تدفع فيه فقط مقابل الموارد التي تستخدمها. استخدم managed services لأنها تعمل بمقياس السحابة، ويمكنها تقديم تكلفة أقل لكل معاملة. من النصائح المهمة أيضاً: قياس الكفاءة، وإزالة النفقات غير المطلوبة، وتحليل النفقات بمرور الوقت. تماماً كما يراجع صاحب المنزل فواتير الكهرباء شهرياً بحثاً عن استهلاك غير مبرر، يجب أن يراجع cloud architect فواتير AWS بانتظام عبر AWS Cost Explorer.
7️⃣ Sustainability pillar
ركيزة Sustainability تعالج القدرة على بناء بنى تزيد الكفاءة وتقلل الهدر. يعالج انضباط الاستدامة التأثير البيئي والاقتصادي والمجتمعي طويل الأمد لأنشطة عملك. يجب أن تفهم تأثير أحمال عملك وتعمل على تقليل الأثر اللاحق. الاستدامة في السحابة جهد مستمر يركز أساساً على تقليل الطاقة وزيادة الكفاءة عبر جميع مكونات الحمل. يمكن أن يشمل هذا اختيار لغة برمجة فعالة، واعتماد خوارزميات حديثة، واستخدام تقنيات تخزين بيانات فعالة. كما يمكن أن يشمل النشر على بنية تحتية محسوبة الحجم، وتقليل متطلبات الأجهزة الطرفية عالية الطاقة. تماماً كما يختار المستهلك الواعي منتجات صديقة للبيئة، يختار cloud architect خدمات تقلل البصمة الكربونية.
8️⃣ Using the AWS WA Tool
AWS Well-Architected Tool (WA Tool) هي أداة خدمة ذاتية تتيح لك الوصول عند الطلب إلى أفضل ممارسات AWS الحالية. تساعدك على مراجعة حالة أحمال عملك ومقارنتها بأحدث أفضل الممارسات المعمارية. تمنحك وصولاً إلى المعرفة وأفضل الممارسات التي يستخدمها معماريو AWS عند الحاجة. الأداة متاحة في AWS Management Console، حيث تعرّف حملك وتجيب على سلسلة من الأسئلة في مجالات Operational Excellence، Security، Reliability، Performance Efficiency، Cost Optimization. ثم تقدم خطة عمل بإرشادات خطوة بخطوة. توفر الأداة عملية متسقة لمراجعة وقياس بنى السحابة. تماماً كما يستخدم مدرب اللياقة البدنية تقييماً دورياً لقياس تقدم العميل، تستخدم WA Tool لتقييم تقدم بنيتك.
📖 قاموس مصطلحات المحور الثاني
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Well-Architected Framework | إطار الهندسة المعمارية المتقنة | دليل AWS لتقييم البنى السحابية عبر ست ركائز تأسيسية. |
| Operational Excellence | التميز التشغيلي | ركيزة تركز على تشغيل الأنظمة وتحسين العمليات بشكل مستمر. |
| Reliability | الموثوقية | قدرة النظام على التعافي من الأعطال وتلبية الطلب ديناميكياً. |
| Sustainability | الاستدامة | بناء بنى تزيد الكفاءة وتقلل البصمة الكربونية للهدر البيئي. |
| AWS WA Tool | أداة Well-Architected | أداة ذاتية لتقييم أحمال العمل ومقارنتها بأفضل ممارسات AWS. |
| Infrastructure as Code | البنية التحتية ككود | ممارسة تعريف البنية التحتية بملفات كود قابلة للنسخ والتكرار. |
1️⃣ Design trade-offs
عند تصميم حل، فكر بعناية في trade-offs لتختار النهج الأمثل. من الأمثلة على trade-offs: التضحية بالاتساق (consistency)، والمتانة (durability)، والمساحة مقابل الوقت وزمن الاستجابة (latency) لتقديم أداء أعلى. في الميزات الجديدة، يمكن إعطاء الأولوية للسرعة في السوق على حساب التكلفة. يجب أن تستند قرارات التصميم على بيانات تجريبية. على سبيل المثال، قد تحتاج لإجراء load testing للتأكد من الحصول على فائدة قابلة للقياس في الأداء. كما قد تحتاج لإجراء benchmarking لتحقيق الحمل الأمثل من حيث التكلفة. تماماً كما يختار الطباخ بين نكهة غنية ووقت طبخ طويل، يختار cloud architect بين أداء أعلى وتكلفة أكبر.
2️⃣ Implementing scalability
عند تشغيل أحمال العمل على AWS Cloud، يمكنك توسيع بنيتك التحتية بسرعة وبشكل استباقي. تأكد من تنفيذ scalability على كل طبقة من بنيتك. بتنفيذ scalability، تحسّن تصميمك لتتنبأ بالحاجة إلى مزيد من السعة وتقدمها قبل فوات الأوان. على سبيل المثال، يمكنك استخدام حل مراقبة مثل Amazon CloudWatch لاكتشاف ما إذا كان الحمل الإجمالي عبر أسطول خوادمك قد وصل إلى عتبة محددة. يمكنك تعريف هذه العتبة كـ "بقاء استخدام المعالج فوق 60% لأكثر من 5 دقائق". مع CloudWatch، يمكنك أيضاً تصميم مقاييس مخصصة تستدعي توسيع الموارد المطلوب. عندما يتم إطلاق المنبه، يقوم Amazon EC2 Auto Scaling فوراً بتشغيل مثيل جديد. تماماً كما يضيف المطعم طاولات قبل ساعة الذروة، يضيف Auto Scaling موارد قبل ازدحام الخوادم.
3️⃣ Automating your environment
تقدم AWS أدوات مراقبة وأتمتة مدمجة في كل طبقة من بنيتك التحتية تقريباً. استفد من هذه الأدوات لضمان أن بنيتك التحتية يمكنها الاستجابة بسرعة للتغييرات. بدون هذه الأدوات، يجب عليك يدوياً اكتشاف أي فشل والاستجابة له. إذا تعطل خادم تطبيق، يجب اكتشافه وإخطار المسؤول يدوياً، ثم يقوم المسؤول يدوياً بتشغيل الخادم الجديد وتكوينه. أدوات مثل CloudWatch وAmazon EC2 Auto Scaling يمكنها اكتشاف الموارد غير الصحية وأتمتة تشغيل الموارد البديلة. يمكنك أيضاً أن يتم إخطارك عند تغيير تخصيصات الموارد. تماماً كما يستخدم مصنع السيارات روبوتات لطلاء كل سيارة بنفس الدقة، تستخدم AWS الأتمتة لتكوين كل خادم بنفس الدقة.
4️⃣ Using IaC
Infrastructure as Code (IaC) هي ممارسة استخدام الكود بدلاً من العمليات اليدوية لتوفير البنية التحتية للحاسوب. الاستخدام الأكثر شيوعاً لـ IaC في تطوير البرمجيات هو بناء واختبار ونشر التطبيقات. من فوائدها: نشر بيئات مكررة بسرعة. باستخدام قالب واحد، يمكن نشر بيئات متطابقة. كما تقلل أخطاء التهيئة الناتجة عن التكوين اليدوي. وأخيراً، تنشر التغييرات باستمرار على كل المكدسات. عند وجود أخطاء بسبب تحديثات كود IaC، يمكنك إصلاح الموقف بسرعة عبر rolling back قاعدة الكود إلى ملفات التكوين المستقرة الأخيرة. تماماً كما يستخدم الطاهي وصفة مكتوبة بدل الذاكرة، يستخدم cloud architect قوالب IaC بدلاً من الإعداد اليدوي.
5️⃣ Treating resources as disposable
أفضل ممارسة "اعتبر مواردك قابلة للاستبدال" تشير إلى فكرة التفكير في بنيتك التحتية كبرنامج بدلاً من عتاد صلب. مع العتاد الصلب، يمكنك شراء مكونات أكثر مما تحتاج للتحضير لارتفاع الاستخدام. لكن القيام بذلك مكلف وغير مرن، ومن الصعب الترقية بسبب التكلفة الغارقة. بدلاً من ذلك، عندما تعامل مواردك كقابلة للاستبدال، يصبح الانتقال بين المثيلات أو الموارد المنفصلة أمراً بسيطاً. يمكنك الاستجابة بسرعة للتغييرات في احتياجات السعة، وترقية التطبيقات، وإدارة البرمجيات الأساسية. من النصائح: أتمتة نشر موارد جديدة بتكوينات متطابقة، وإيقاف الموارد غير المستخدمة، واختبار التحديثات على موارد جديدة ثم استبدال القديمة. تماماً كما يستبدل سائق السباق الإطارات بسرعة، يستبدل cloud architect الخوادم بسرعة.
6️⃣ Using loosely coupled components
البنى التقليدية بها سلاسل من الخوادم المتكاملة بشكل محكم، كل منها لغرض محدد. المشكلة أنه عندما يفشل أحد هذه المكونات أو الطبقات، قد يكون الاضطراب للظام قاتلاً. كما يعيق ذلك التوسع: لو أضفت أو أزلت خوادم في طبقة، يجب أن تربط كل خادم في كل طبقة متصلة. مع loose coupling، تستخدم حلولاً مُدارة كوسطاء بين طبقات نظامك. يتولى الوسيط تلقائياً التعامل مع الفشل وتوسيع المكونات أو الطبقات. الحلان الأساسيان لفك الترابط هما load balancers وmessage queues. المثال على اليسار يوضح Elastic Load Balancing (ELB) الذي يوجه الطلبات بين خوادم الويب وخوادم التطبيق. تماماً كما يفصل ساعي البريد بين المخزن والمستلم، يفصل message queue بين المرسل والمستقبل.
7️⃣ Designing services, not servers
أفضل ممارسة التالية هي "صمم خدمات، لا خوادم". رغم أن Amazon EC2 يوفر مرونة هائلة في التصميم والإعداد، لا يجب أن يكون دائماً الحل الأول أو الوحيد لكل احتياج. أحياناً، قد تكون الحاويات أو حل بدون خوادم (serverless) أكثر ملاءمة. مع الحلول بدون خوادم والخدمات المُدارة في AWS، لا تحتاج لتوفير وتكوين وإدارة مثيل EC2 كامل. الحلول المُدارة ذات البصمة الأصغر والأداء الأفضل يمكن أن تحل محل الحلول القائمة على الخوادم بتكلفة أقل. من الأمثلة: AWS Lambda، Amazon SQS، Amazon DynamoDB، ELB، Amazon Simple Email Service (Amazon SES)، وAmazon Cognito. تماماً كما لا يحتاج المطعم لبناء فرنه الخاص به (يمكنه استخدام خدمات توصيل الطعام)، لا يحتاج المطور لبناء خدماته الخاصة (يمكنه استخدام AWS managed services).
8️⃣ Choosing the right database solution
من المهم اختيار حل قاعدة البيانات المناسب. في مراكز البيانات التقليدية وبيئات on-premises، تحد القيود على العتاد والتراخيص من اختيارك لحل تخزين البيانات. توصي AWS باختيار مخزن البيانات بناءً على احتياجات بيئة التطبيق لديك. من المعايير المهمة: احتياجات القراءة والكتابة، إجمالي متطلبات التخزين، الحجم النموذجي للكائن وطبيعة الوصول إليه، متطلبات المتانة (durability)، متطلبات زمن الاستجابة (latency)، الحد الأقصى للمستخدمين المتزامنين، طبيعة الاستعلامات، القوة المطلوبة لضوابط السلامة. تماماً كما يختار الطبيب الدواء المناسب لكل مرض، يختار cloud architect قاعدة البيانات المناسبة لكل نمط استخدام.
9️⃣ Avoiding single points of failure
حيثما أمكن، أزل single points of failure من بنيتك. هذا لا يعني تكرار كل مكون دائماً. بناءً على اتفاقيات مستوى الخدمة (SLAs) للتعطل، يمكنك استخدام حلول آلية تُشغل المكونات عند الحاجة فقط. يمكنك أيضاً استخدام خدمة مُدارة، فتستبدل AWS تلقائياً العتاد المعطّل. إذا كان خادما تطبيق متصلين بخادم قاعدة بيانات واحد، فإن خادم قاعدة البيانات يمثل single point of failure ويجب تجنبه. الطريقة الشائعة لتجنب single points of failure هي إنشاء خادم قاعدة بيانات ثانوي (standby) وتكرار البيانات. بهذه الطريقة، إذا توقف خادم قاعدة البيانات الرئيسي، يمكن للخادم الثانوي تحمل الحمل. تماماً كما يضمن المطار أن لديه مدراراً بديلاً لكل مدرج، تضمن البنية المرنة بديلاً لكل مكون حرج.
🔟 Optimizing for cost
مع الحوسبة السحابية، يمكنك تحويل المصروفات الثابتة إلى مصروفات متغيرة. المصروفات الثابتة هي أموال الشركة لاقتناء الأصول المادية وترقيتها وصيانتها. مع هذا النموذج، تدفع مقابل الخوادم في مركز البيانات سواء كانت نشطة أم لا. على النقيض، تستخدم خدمات AWS نموذج تكلفة المصروفات المتغيرة، مما يعني أنك تدفع فقط مقابل الخدمات الفردية التي تحتاجها طالما تستخدمها. في كل خدمة، يمكنك التحسين من أجل التكلفة. تقدم العديد من الخدمات مستويات تسعير أو نماذج أو تكوينات مختلفة. تذكر أنه قد يكون مكلفاً جداً تكرار إعداد مركز بيانات محلي يعمل 24/7 في السحابة. لذلك، أفضل طريقة لبناء بنية تحتية فعالة من حيث التكلفة هي توفير الموارد التي تحتاجها فقط وإيقاف الخدمات عندما لا تكون قيد الاستخدام. تماماً كما يطفئ صاحب المنزل الأنوار في الغرف الفارغة، يجب إيقاف خدمات AWS غير المستخدمة.
1️⃣1️⃣ Using caching
Caching هي تقنية لجعل الطلبات المستقبلية أسرع وتقليل إنتاجية الشبكة بتخزين البيانات مؤقتاً في موقع وسيط بين الطالب والتخزين الدائم. الهدف الأساسي من cache هو زيادة أداء استرجاع البيانات بتقليل الحاجة للوصول إلى طبقة التخزين الأبطأ الأساسية. تُخدم الطلبات المستقبلية للبيانات المخزنة مؤقتاً أسرع من الطلبات التي تصل إلى موقع التخزين الأساسي. مع caching، يمكنك إعادة استخدام البيانات المسترجعة أو المحسوبة سابقاً بكفاءة. في المثال، تستخدم البنية التحتية Amazon CloudFront أمام Amazon S3 لتوفير caching. الطلبات اللاحقة للملف تُسترجع من موقع الحافة الأقرب في CloudFront بدلاً من Amazon S3. الطلبات الثانية والثالثة وما بعدها تكون بزمن استجابة وتكلفة أقل. تماماً كما يحتفظ النادل بالأطباق الأكثر طلباً في متناول يده، يحتفظ cache بالبيانات الأكثر طلباً في متناول المستخدم.
1️⃣2️⃣ Securing your entire infrastructure
الأمان لا يتعلق فقط باختراق الحدود الخارجية لبنيتك التحتية. يتعلق أيضاً بضمان أن بيئاتك الفردية ومكوناتها مؤمنة من بعضها البعض. على سبيل المثال، في Amazon EC2، يمكنك إنشاء security groups لتحدد المنافذ على مثيلاتك التي يمكنها إرسال واستقبال الحركة. يمكن لـ security groups أيضاً تحديد مصدر الحركة أو وجهتها. يمكنك استخدام security groups لتقليل احتمال أن ينتشر تهديد أمني في مثيل واحد إلى كل مثيل آخر في بيئتك. من النصائح المهمة: استخدام الخدمات المُدارة، تسجيل الوصول للموارد، عزل أجزاء من بنيتك، تشفير البيانات أثناء النقل والتخزين، فرض التحكم في الوصول بدقة باستخدام مبدأ الامتياز الأقل، استخدام MFA، وأتمتة عمليات النشر للحفاظ على اتساق الأمان. تماماً كما لا يكتفي صاحب القلعة ببناء سور خارجي، بل يضع حراساً داخليين على كل باب، يجب تأمين كل طبقة من طبقات البنية.
📖 قاموس مصطلحات المحور الثالث
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Trade-offs | المقايضات | موازنات بين خصائص متناقضة في التصميم، مثل الأداء مقابل التكلفة. |
| Auto Scaling | التوسع التلقائي | خدمة تضيف أو تزيل موارد EC2 تلقائياً بناءً على الطلب. |
| Loose coupling | الترابط الفضفاض | تصميم معماري يفصل بين المكونات عبر وسطاء مثل قوائم الرسائل. |
| Serverless | بدون خوادم | نموذج تشغيل كود دون إدارة خوادم، مثل AWS Lambda. |
| Single point of failure | نقطة فشل وحيدة | مكون وحيد في النظام، فشله يؤدي لانهيار النظام بأكمله. |
| Caching | التخزين المؤقت | تقنية تخزين البيانات مؤقتاً في موقع وسيط لتسريع الاسترجاع. |
| MFA | المصادقة متعددة العوامل | طبقة أمان إضافية تتطلب أكثر من كلمة مرور لتسجيل الدخول. |
1️⃣ AWS infrastructure topics
AWS Global Cloud Infrastructure هي منصة سحابية آمنة وموسعة وموثوقة، تقدم أكثر من 200 خدمة مميزة من مراكز البيانات عالمياً. تمتد البنية التحتية لـ AWS Cloud على 102 Availability Zone في 32 منطقة جغرافية حول العالم. هذا يمنحك القدرة على إطلاق بنى عالية التوسع والمرونة والقرب من عملائك لخفض زمن الاستجابة وزيادة الأداء. عند تصميم وبناء البنى، تحتاج للنظر في أي منطقة تنشر فيها. AWS Region هي موقع جغرافي فعلي يحتوي على منطقتي توفر أو أكثر. Availability Zones تتكون بدورها من مركز بيانات واحد أو أكثر. يجب أن تستند قراراتك على متطلبات العمل واحتياجات الحمل. من المواضيع المهمة: Regions، Availability Zones، AWS Local Zones، AWS data centers، وAWS points of presence (PoPs). تماماً كما تختار الشركة موقع مكتبها الرئيسي بناءً على قرب العملاء، تختار منطقة AWS بناءً على نفس المعايير.
2️⃣ Selecting Regions
Region هي منطقة جغرافية فعلية تحتوي على منطقتي توفر أو أكثر. Availability Zones تتكون بدورها من مركز بيانات واحد أو أكثر. تتصل المناطق بعدة مزودي خدمة إنترنت (ISPs). كما تتصل بشبكة backbone عالمية خاصة، توفر تكلفة أقل وزمن استجابة أكثر اتساقاً عبر المناطق مقارنة بالإنترنت العام. المناطق التي أُطلقت قبل 20 مارس 2019 مفعّلة افتراضياً. أما المناطق التي أُطلقت بعد هذا التاريخ (مثل Asia Pacific (Hong Kong) وMiddle East (Bahrain)) فهي معطلة افتراضياً. يجب تفعيل هذه المناطق قبل استخدامها. بعض المناطق لها وصول مقيد، مثل AWS GovCloud (US) المصممة للوكالات الحكومية الأمريكية. الموارد في منطقة واحدة لا تُكرر تلقائياً إلى مناطق أخرى. تقع على عاتقك مسؤولية تكرار البيانات عبر المناطق إذا كانت احتياجات عملك تتطلب ذلك. تماماً كما تختار دولة إقامتك بناءً على الجنسية والضرائب والمناخ، تختار Region بناءً على الامتثال والقرب والتكلفة.
3️⃣ Selecting Availability Zones
تتكون كل Region من موقعين أو أكثر معزولين تسمى Availability Zones. تضم كل AZ مركز بيانات واحد أو أكثر، بعضها يصل إلى ستة مراكز بيانات. لكن لا يمكن أن يكون مركز البيانات جزءاً من منطقتي توفر. صُممت كل AZ كمنطقة فشل مستقلة. هذا يعني أن AZs مفصولة فعلياً في منطقة حضرية نموذجية. كما تقع في مناطق منخفضة المخاطر للفيضانات. تمتلك AZs إمداد طاقة مستقلاً غير قابل للانقطاع (UPS) ومرافق توليد احتياطية في الموقع. تتصل AZs ببعضها البعض عبر روابط خاصة عالية السرعة. AZ هو المستوى الأكثر دقة من التحديد الذي يمكنك تقديمه لخدمات معينة، مثل Amazon EC2. تقع على عاتقك مسؤولية اختيار AZs التي ستقيم فيها أنظمتك. تماماً كما تختار الطوابق المختلفة في المبنى لتوزيع المخاطر، تختار AZs المختلفة لتوزيع المخاطر التقنية.
4️⃣ Using Local Zones
Local Zones هي نوع من البنية التحتية لـ AWS يضع خدمات الحوسبة والتخزين وقواعد البيانات وغيرها من الخدمات المختارة أقرب إلى مراكز السكان والصناعة وتكنولوجيا المعلومات الكبيرة التي لا توجد فيها مناطق اليوم. مع Local Zones، يمكنك تشغيل أجزاء حساسة لزمن الاستجابة من التطبيقات أقرب إلى المستخدمين النهائيين والموارد في جغرافيا محددة. يمكنك استخدام Local Zones لتقديم زمن استجابة بأرقام أحادية (single-digit millisecond) لحالات استخدام مثل إنشاء محتوى الإعلام والترفيه، الألعاب في الوقت الفعلي، محاكاة الخزانات، أتمتة التصميم الإلكتروني، وتعلم الآلة. كل موقع Local Zone هو امتداد لـ Region. يمكنك تشغيل تطبيقات حساسة لزمن الاستجابة في Local Zone باستخدام خدمات AWS مثل Amazon EC2، Amazon Virtual Private Cloud (Amazon VPC)، Amazon Elastic Block Store (Amazon EBS)، Amazon FSx، وELB بالقرب الجغرافي من المستخدمين النهائيين. تماماً كما يفتتح متجر سلسلة فرعاً في حي بعيد عن المتجر الرئيسي لخدمة العملاء هناك، يفتتح AWS Local Zone في مدينة بعيدة عن Region لخدمة العملاء هناك.
5️⃣ Role of AWS data centers
الأساس للبنية التحتية لـ AWS هو data centers. لا تحدد مركز بيانات معين لنشر الموارد. ومع ذلك، مركز البيانات هو الموقع الذي توجد فيه البيانات الفعلية. تدير أمازون مراكز بيانات حديثة وعالية التوافر. رغم ندرة ذلك، يمكن أن تحدث أعطال تؤثر على توافر المثيلات في نفس الموقع. إذا استضفت كل مثيلاتك في موقع واحد يتأثر بهذا العطل، فلن يكون أي من مثيلاتك متاحاً. كل مراكز البيانات متصلة بالإنترنت وتخدم العملاء. في حالة العطل، تنقل العمليات الآلية حركة بيانات العملاء بعيداً عن المنطقة المتأثرة. يتم نشر التطبيقات الأساسية بتكوين N+1. تستخدم AWS معدات شبكات مخصصة مصدرها عدة ODMs (Original Device Manufacturers). تماماً كما يضع المطار معدات ملاحة متكررة من عدة شركات لتجنب الاعتماد على مورد واحد، تستخدم AWS معدات شبكية من عدة مصنعين.
6️⃣ AWS PoPs
لتقديم المحتوى للمستخدمين النهائيين بزمن استجابة أقل، تستخدم CloudFront شبكة عالمية تضم أكثر من 410 PoPs. تتكون PoPs من 400 edge location و13 regional mid-tier cache. هذه PoPs هي الوجهة الأولى لطلب CloudFront. تتأكد edge locations من أن المحتوى الشائع يمكن تقديمه بسرعة للعملاء. Regional edge caches تجلب مزيداً من المحتوى أقرب إلى العملاء حتى لو لم يكن شائعاً بما يكفي للبقاء في edge location. توجد edge locations في أمريكا الشمالية وأوروبا وآسيا وأستراليا وأمريكا الجنوبية والشرق الأوسط وأفريقيا والصين. تدعم edge locations خدمات AWS مثل Amazon Route 53 وAWS Global Accelerator وCloudFront. تُستخدم Regional edge caches افتراضياً مع CloudFront. تماماً كما يضع السوبر ماركت مخزناً مركزياً في المدينة وفروعاً صغيرة في الأحياء، تضع AWS edge locations صغيرة قريبة من المستخدمين.
📖 قاموس مصطلحات المحور الرابع
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| AWS Region | منطقة AWS | منطقة جغرافية فعلية تحتوي على منطقتي توفر أو أكثر. |
| Availability Zone | منطقة التوفر | موقع معزول داخل المنطقة، يحتوي على مركز بيانات واحد أو أكثر. |
| Local Zone | المنطقة المحلية | امتداد لمنطقة AWS يضع الخدمات أقرب للمستخدمين في مدن بدون منطقة. |
| Edge location | موقع الحافة | نقطة تواجد AWS لتخزين المحتوى مؤقتاً وتقديمه بسرعة للمستخدمين. |
| Regional edge cache | مخبئ الحافة الإقليمي | طبقة وسيطة من مخابئ الحافة للمحتوى الذي لا يستحق البقاء في موقع الحافة. |
| PoP | نقطة التواجد | موقع فعلي لشبكة AWS على الإنترنت، يشمل edge locations و regional edge caches. |
🚀 الخاتمة
في هذه الوحدة تعلمنا أن Cloud Architecting هي ممارسة تطبيق خصائص السحابة على الحلول، وأن AWS وُلدت من رحم تحديات أمازون نفسها في عام 2000. استكشفنا AWS Well-Architected Framework وركائزه الست من Operational Excellence إلى Sustainability، وأداة WA Tool التي تقيّم أحمال العمل. كما استعرضنا اثنتي عشرة أفضل ممارسة لبناء الحلول، من scalability وautomation إلى caching وsecurity. وأخيراً تعرفنا على البنية التحتية العالمية المكونة من Regions وAvailability Zones وLocal Zones وPoPs، وكيف نختار المنطقة المناسبة بناءً على الامتثال والقرب والتكلفة. هذه الوحدة هي الأساس الذي تبنى عليه الوحدات التالية في الدورة.