AWS SAA 10 - Implementing Elasticity, High Availability, and Monitoring

🎯 Module 10: Implementing Monitoring, Elasticity, and High Availability — تطبيق المراقبة والمرونة والتوفر العالي

تُعد هذه الوحدة محورية في مسار AWS Academy Cloud Architecting حيث تركز على تصميم بنى سحابية متفاعلة (Reactive Architectures) قادرة على المراقبة الذاتية والتوسع الديناميكي وتحمل الأعطال. ستتعلم كيفية استخدام Amazon CloudWatch وAmazon EventBridge للمراقبة، وAmazon EC2 Auto Scaling للتوسع المرن، وElastic Load Balancing وAmazon Route 53 لتحقيق التوفر العالي مع تطبيق مبادئ AWS Well-Architected Framework.

1️⃣ Monitoring Distributed Application Components — مراقبة مكونات التطبيق الموزعة

📖 لماذا تعتبر المراقبة (Monitoring) أمراً حيوياً في البنى السحابية؟
يجب أن تستجيب الأنظمة والتطبيقات الموزعة بشكل فوري حتى تحت الأحمال الثقيلة، مما يتطلب اهتماماً خاصاً بزمن الاستجابة (Latency). الحل هو دمج ملفات السجل (Logs) المنفصلة لكل خدمة في خدمة مركزية توفر سجلاً كاملاً وموحداً للتطبيق بالكامل، مع إمكانية ضبط إنذارات (Alarms) للحدود المتجاوزة.

📋 أنواع المقاييس التي يمكن مراقبتها:

• مقاييس الصحة التشغيلية (Operational Health Metrics): مراقبة البنية التحتية للتطبيق لضمان سلامة بيئة التشغيل.
• مقاييس استخدام الموارد (Resource Utilization Metrics): قياس استخدام مكونات التطبيق للتأكد من عدم الإفراط أو التفريط في استخدامها.
• مقاييس أداء التطبيق (Application Performance Metrics): قياس مدى تلبية التطبيق لمتطلبات الطلب.

على سبيل المثال تطبيق مصرفي يتكون من خدمات مصغرة متعددة.
بدلاً من البحث في سجلات 10 خدمات منفصلة عند حدوث عطل يتم جمع كل السجلات في CloudWatch Logs.
يتم ضبط إنذار عندما يتجاوز زمن استجابة خدمة تحويل الأموال 500 مللي ثانية لإعلام فريق العمليات فوراً.

2️⃣ Amazon CloudWatch — أمازون كلاودووتش

📖 ما هو Amazon CloudWatch؟
CloudWatch هو مستودع لمقاييس وسجلات خدمات AWS. يقوم بجمع وتتبع المقاييس من خدمات AWS عبر المناطق (Regions) في مستودع مركزي، ويدعم المقاييس المدمجة أو المقاييس المخصصة (Custom Metrics). يمكنك استخدام CloudWatch Logs لمراقبة وتخزين والوصول إلى ملفات السجل من مصادر مثل EC2 وCloudTrail وRoute 53 وAmazon VPC.

📋 الميزات الرئيسية لـ CloudWatch:

• جمع وتتبع المقاييس لخدمات AWS عبر المناطق.
• جمع السجلات باستخدام Amazon CloudWatch Logs مع دعم لغة استعلام قوية.
• حساب الإحصائيات (Statistics) من المقاييس وعرضها في رسوم بيانية على لوحات المعلومات (Dashboards).
• توفير إنذارات (Alarms) للبنى التفاعلية المبنية على الأحداث.
• إرسال إشعارات لإجراء تغييرات على الموارد المراقبة.

🔑 مساحات الأسماء: يتم تخزين المقاييس في حاوية تسمى Namespace. أسماء AWS تستخدم التسمية AWS/service مثل AWS/EC2. يتم عزل المقاييس في مساحات أسماء مختلفة عن بعضها.

على سبيل المثال فريق DevOps يريد مراقبة أداء 50 خادم EC2.
يستخدم CloudWatch لجمع مقاييس CPU Utilization وMemory عبر لوحة تحكم واحدة.
عندما يتجاوز استخدام المعالج 80% لمدة 5 دقائق يتم إطلاق إنذار يرسل إشعاراً لفريق العمليات.

3️⃣ CloudWatch Alarms — إنذارات كلاودووتش

📖 كيف تعمل إنذارات CloudWatch؟
يراقب الإنذار مقياساً واحداً خلال فترة زمنية محددة وينفذ إجراءً أو أكثر بناءً على قيمة المقياس مقارنة بحد معين. يتم تنشيط الإنذارات فقط لتغيرات الحالة المستمرة (Sustained State Changes) وليس للحالات العابرة. تتضمن الإجراءات إرسال إشعار إلى موضوع Amazon SNS أو تفعيل سياسة Auto Scaling.

📋 خصائص الإنذارات:

• مراقبة مقياس واحد خلال فترة زمنية محددة.
• تنفيذ إجراءات محددة بناءً على تجاوز الحدود.
• دعم فترات تقييم متعددة (Evaluation Periods) لضمان الدقة.
• دعم الإنذارات عالية الدقة (High-Resolution Alarms) بفترات 10 أو 30 ثانية.
• إمكانية إضافة الإنذارات إلى لوحات المعلومات (Dashboards).

🔑 مثال على الإنذار: يتم تفعيل إنذار عندما يكون مقياس CPUUtilization أكبر من 70% لمدة 5 دقائق. يقوم الإنذار عندها بتفعيل إجراء مثل إضافة مثيل إلى مجموعة Auto Scaling أو إرسال إشعار لفريق التطوير.

على سبيل المثال تطبيق للتجارة الإلكترونية يشهد زيادة مفاجئة في الزوار خلال موسم الجمعة البيضاء.
إنذار CloudWatch يكتشف أن استخدام المعالج تجاوز 75% لمدة 5 دقائق.
يقوم الإنذار تلقائياً بتشغيل سياسة Auto Scaling لإضافة خوادم إضافية قبل أن يلاحظ الزوار أي بطء.

4️⃣ CloudWatch Dashboards — لوحات معلومات كلاودووتش

📖 ما هي لوحات معلومات CloudWatch؟
تسمح لك لوحات المعلومات بإنشاء منظر موحد للمقاييس والإنذارات المنتشرة عبر مناطق (Regions) مختلفة. يمكنك تخصيص لوحات المعلومات لمراقبة مواردك في عرض واحد، وحتى عبر مناطق متعددة. توفر CloudWatch إحصائيات تعتمد على نقاط بيانات المقياس، حيث يتم تجميع المقاييس مع مرور الوقت لاتخاذ إجراء واحد يحل المشكلة.

🔑 قيمة لوحات المعلومات: يمكنك إنشاء دليل تشغيل تشغيلي (Operational Playbook) يوجه أعضاء الفريق أثناء الأحداث التشغيلية حول كيفية الاستجابة لحوادث محددة.

5️⃣ Amazon EventBridge — أمازون إيفنت بريدج

📖 ما هو Amazon EventBridge؟
عند اختراق إنذارات CloudWatch، يجب نشر الحدث (Event) ليتم تنفيذ إجراءات التصحيح التلقائية أو اليدوية. EventBridge هو ناقل أحداث (Event Bus) يُستخدم لتوجيه الأحداث. EventBridge هي خدمة بدون خوادم (Serverless) تستخدم الأحداث لربط مكونات التطبيق معاً، مما يساعدك على بناء تطبيقات قابلة للتوسع ومبنية على الأحداث (Event-Driven Architecture).

📋 مكونات EventBridge:

• نواقل الأحداث (Event Buses): أجهزة توجيه تستقبل الأحداث وتوصلها إلى صفر أو أكثر من الوجهات.
• الأنابيب (Pipes): تكاملات نقطة إلى نقطة بين مصدر واحد ووجهة واحدة مع دعم التحويل المتقدم وإثراء الأحداث.
• القواعد (Rules): تطابق الأحداث الواردة وترسلها إلى الوجهات للمعالجة. يمكن أن تستند إلى نمط حدث (Event Pattern) أو جدول زمني (Schedule).
• الوجهات (Targets): مورد أو نقطة نهاية يرسل إليها EventBridge الحدث. يمكن تعريف حتى 5 وجهات لكل قاعدة.

على سبيل المثال شركة تريد مراقبة دورة حياة مثيلات EC2 لديها.
عند إنهاء أي مثيل EC2 يتم إرسال حدث إلى EventBridge.
قاعدة تطابق نمط الحدث (EC2 Instance State-change Notification مع حالة terminated) ترسل إشعاراً عبر البريد الإلكتروني لفريق العمليات لتسجيل الحادثة واتخاذ الإجراء اللازم.

6️⃣ Monitoring Your Resource Costs — مراقبة تكاليف مواردك

📖 ما هي أدوات مراقبة التكاليف في AWS؟
توفر AWS أدوات مراقبة وإعداد تقارير لفهم وإدارة تكلفة البنية التحتية، بما في ذلك AWS Cost Explorer لتصور التكاليف والاستخدام، وAWS Budgets لتعيين ميزانيات مخصصة مع تنبيهات، وAWS Cost and Usage Report الذي يحتوي على المجموعة الأكثر شمولاً من بيانات التكلفة والاستخدام.

✅ خلاصة: مراقبة مواردك

• إنذارات CloudWatch ترسل إشعارات إلى Amazon EC2 Auto Scaling وموضوعات SNS.
• CloudWatch يجمع السجلات والمقاييس من خدمات AWS عبر المناطق.
• يمكنك استخدام لوحات معلومات CloudWatch لتصور المقاييس والإنذارات.
• EventBridge يعالج ويوجه الأحداث باستخدام ناقل أحداث أو أنبوب.
• AWS Cost Explorer وAWS Budgets وAWS Cost and Usage Report تساعدك على فهم وإدارة تكلفة البنية التحتية.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon CloudWatch	أمازون كلاودووتش	خدمة مراقبة وجمع مقاييس وسجلات لموارد AWS وتوفير إنذارات ولوحات معلومات.
CloudWatch Alarms	إنذارات كلاودوووتش	آلية تراقب مقياساً معيناً وتنفذ إجراءات عند تجاوز حد محدد لفترة زمنية.
CloudWatch Logs	سجلات كلاودووتش	خدمة مركزية لتخزين ومراقبة والاستعلام عن ملفات السجل من مصادر متعددة.
CloudWatch Dashboards	لوحات معلومات كلاودووتش	صفحات رئيسية قابلة للتخصيص لعرض المقاييس والإنذارات في منظر واحد.
Amazon EventBridge	أمازون إيفنت بريدج	خدمة ناقل أحداث بدون خوادم لتوجيه الأحداث بين مكونات التطبيق.
Event Bus	ناقل الأحداث	جهاز توجيه يستقبل الأحداث ويوصلها إلى وجهات متعددة بناءً على قواعد محددة.
Custom Metrics	مقاييس مخصصة	مقاييس يحددها المستخدم ويرسلها إلى CloudWatch للمراقبة والإحصاء.

1️⃣ The Need for Reactive Architectures — الحاجة إلى البنى التفاعلية

📖 ما هي البنى التفاعلية (Reactive Architectures)؟
تتوقع التطبيقات الحديثة معالجة petabytes من البيانات وتتطلب توفراً يقارب 100% وزمن استجابة أقل من الثانية. لتلبية هذه المتطلبات، يمكنك تنفيذ تطبيق تفاعلي يكون مرناً (Elastic) وقادراً على التعافي (Resilient) وسريع الاستجابة (Responsive) ومبني على الرسائل (Message-Driven).

🔑 خصائص النظام التفاعلي:

• المرونة (Elastic): التوسع الديناميكي للموارد وإضافتها أو إزالتها للتفاعل مع التغيرات وتجنب التوقف أو الاختناقات.
• سرعة الاستجابة (Responsive): الاستجابة في الوقت المناسب بأقل زمن استجابة ممكن حتى تحت أعباء العمل المتغيرة.
• التعافي (Resilient): البقاء مستجيباً في مواجهة الفشل والضغط الناتج عن الأحمال والهجمات وفشل أي مكون.
• مبني على الرسائل (Message-Driven): الاعتماد على تمرير الرسائل غير المتزامن (Asynchronous Message-Passing) لضمان الاقتران الفضفاض والعزل.

2️⃣ Achieve Elasticity with Scaling — تحقيق المرونة من خلال التوسع

📖 الفرق بين Elasticity وScaling؟
المرونة (Elasticity) هي قدرة البنية التحتية على التوسع والانكماش مع تغير متطلبات السعة. أما التوسع (Scaling) فهو القدرة على زيادة أو تقليل سعة الحوسبة لتطبيقك، وهو الأسلوب المستخدم لتحقيق المرونة.

💡 مقارنة بين التوسع الرأسي والأفقي:

وجه المقارنة	التوسع الرأسي (Vertical Scaling)	التوسع الأفقي (Horizontal Scaling)
الوصف	استبدال المورد بآخر مختلف في الحجم (ترقية المواصفات)	إضافة أو إزالة موارد متاحة للتطبيق
مثال	ترقية EC2 من t2.micro إلى t2.large	إضافة خوادم EC2 إضافية لمجموعة Auto Scaling
الحدود	يصل إلى حد بسبب قيود الأجهزة وليس فعالاً من حيث التكلفة	طريقة جيدة لبناء أنظمة مرنة وعالية التوفر
التأثير	قد يتطلب نقلاً للتطبيق والبيانات مما يؤدي إلى توقف	يُشار إليه بـ Scaling Out (إضافة) وScaling In (إزالة)

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

3️⃣ Amazon EC2 Auto Scaling — التوسع التلقائي لحوسبة EC2

📖 ما هي خدمة Amazon EC2 Auto Scaling؟
تدير Amazon EC2 Auto Scaling مجموعة منطقية من مثيلات Amazon EC2 تسمى Auto Scaling Group عبر مناطق التوفر (Availability Zones). تقوم تلقائياً بإطلاق أو إنهاء المثيلات بناءً على سياسات التوسع وفحوصات الصحة وجداول زمنية. توفر هذه الخدمة تكاملاً مع Elastic Load Balancing (ELB) لتسجيل المثيلات الجديدة تلقائياً وتلقي إشعارات الصحة. وهي متاحة مجاناً (تدفع فقط مقابل الموارد التي تنشئها).

📋 فوائد Amazon EC2 Auto Scaling:

• تحمل أفضل للأعطال: يكتشف المثيلات غير الصحية وينهيها ويطلق مثيلات بديلة.
• توفر أفضل: يمكن استخدام مناطق توفر متعددة؛ إذا تعطلت منطقة تطلق الخدمة مثيلات في منطقة أخرى.
• إدارة أفضل للتكلفة: يمكن تعديل عدد المثيلات تلقائياً لتتناسب مع الطلب.
• موازنة المثيلات: يوازن عدد المثيلات عبر مناطق التوفر.

مكونات مجموعة Auto Scaling:

• السعة الدنيا (Minimum Capacity): أصغر عدد من المثيلات اللازمة لتشغيل التطبيق.
• السعة القصوى (Maximum Capacity): أكبر عدد مسموح به من المثيلات للمجموعة.
• السعة المرغوبة (Desired Capacity): العدد الأمثل من المثيلات في الظروف العادية.
• قالب الإطلاق (Launch Template): يحدد تفاصيل تكوين المثيل مثل نوع المثيل وAMI.

على سبيل المثال موقع أخبار يشهد ارتفاعاً في الزيارات كل صباح عند نشر الأخبار اليومية.
مجموعة Auto Scaling تبدأ بمثيلين (Desired Capacity = 2).
عند ارتفاع الطلب يضاف مثيل ثالث ليصل إلى الحد الأقصى 3.
في المساء وعند انخفاض الطلب تنتهي المثيلات ويعود العدد إلى مثيل واحد (Minimum = 1) لتوفير التكاليف.

4️⃣ Amazon EC2 Auto Scaling Mechanisms — آليات التوسع التلقائي

📖 ما هي أنواع سياسات التوسع في Amazon EC2 Auto Scaling؟
توفر Amazon EC2 Auto Scaling عدة طرق لضبط التوسع لتناسب متطلبات الحوسبة لتطبيقاتك، تتراوح من الجداول الزمنية المتوقعة إلى السياسات الديناميكية والتنبؤية.

💡 مقارنة آليات التوسع:

الآلية	الوصف	متى تُستخدم
الإجراءات المجدولة (Scheduled Actions)	التوسع بناءً على تاريخ ووقت محددين	أعباء العمل المتوقعة (مثل زيادة الزيارات كل أربعاء)
السياسات الديناميكية (Dynamic Policies)	التوسع بناءً على مقاييس متتبعة مثل Target Tracking وStep Scaling وSimple Scaling	أعباء العمل المتقلبة بشكل معتدل
السياسة التنبؤية (Predictive Policy)	تحليل بيانات الأحمال التاريخية لاكتشاف الأنماط اليومية أو الأسبوعية والتنبؤ بالاحتياجات المستقبلية باستخدام Machine Learning	حركة المرور الدورية والأنماط المتكررة
هدف التتبع (Target Tracking)	زيادة أو تقليل السعة الحالية بناءً على قيمة مستهدفة لمقياس معين (مثل إبقاء CPU عند 50%)	الحفاظ على مقياس محدد عند قيمة ثابتة

على سبيل المثال منصة تعليمية عبر الإنترنت تشهد ازدحاماً في بداية كل فصل دراسي.
تستخدم Scheduled Scaling لزيادة السعة قبل أسبوع من بدء الفصل.
أثناء اليوم الدراسي تستخدم Target Tracking لإبقاء استخدام المعالج عند 60%.
في الليل تستخدم Predictive Scaling للاستعداد لارتفاع الزيارات الصباحية بناءً على أنماط الأيام السابقة.

5️⃣ More AWS Scaling Options — خيارات توسع إضافية

📖 ما هي خدمات التوسع الإضافية في AWS؟
AWS Auto Scaling يستخدم خطة توسع (Scaling Plan) لتكوين التوسع التلقائي لموارد متعددة مثل Amazon Aurora وAmazon ECS وDynamoDB. Application Auto Scaling هي خدمة ويب للمطورين ومسؤولي الأنظمة لتوسيع الموارد القابلة للتوسع تلقائياً لخدمات فردية تتجاوز Amazon EC2، مثل AWS Lambda وAmazon SageMaker وAmazon ElastiCache.

✅ خلاصة: توسيع موارد الحوسبة

• باستخدام Amazon EC2 Auto Scaling يمكنك إنشاء مجموعة لإدارة مجموعة منطقية من مثيلات EC2.
• للمجموعة إعدادات سعة تحدد الحد الأدنى والأقصى والعدد المرغوب من المثيلات.
• يمكن توسيع المجموعة عبر الإجراءات المجدولة والسياسات الديناميكية والتنبؤية.
• لتوسيع خدمات أكثر من مثيلات EC2 استخدم AWS Auto Scaling أو Application Auto Scaling.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Elasticity	المرونة	قدرة البنية التحتية على التوسع والانكماش تلقائياً مع تغير متطلبات السعة.
Vertical Scaling	التوسع الرأسي	زيادة أو تقليل مواصفات مورد فردي مثل ترقية نوع المثيل.
Horizontal Scaling	التوسع الأفقي	إضافة أو إزالة موارد للتطبيق مثل إضافة خوادم جديدة.
Auto Scaling Group	مجموعة التوسع التلقائي	مجموعة منطقية من مثيلات EC2 تُدار وتُوسع تلقائياً معاً.
Launch Template	قالب الإطلاق	قالب يحدد تكوين مثيل EC2 بما في ذلك نوعه و AMI والشهادات الأمنية.
Predictive Scaling	التوسع التنبؤي	استخدام التعلم الآلي لتحليل الأنماط التاريخية والتنبؤ باحتياجات السعة المستقبلية.
Application Auto Scaling	التوسع التلقائي للتطبيقات	خدمة لتوسيع الموارد القابلة للتوسع تلقائياً لخدمات AWS المتعددة.

1️⃣ Scaling AWS Databases — توسيع قواعد بيانات AWS

📖 كيف تتوسع قواعد البيانات في AWS؟
مثل موارد Amazon EC2، يمكن لخدمات قواعد البيانات في AWS أن تتوسع رأسياً وأفقياً أو كليهما. تختلف آلية التوسع لكل خدمة؛ بعضها يقدم توسعاً يدوياً وتلقائياً بينما يقدم البعض الآخر توسعاً تلقائياً فقط لمكونات معينة. يجب ملاحظة أن توسيع قاعدة البيانات ليس عملية فورية، رغم أنها قد تبدو كذلك لأن معظم التوسع يحدث كعمليات خلفية.

💡 مقارنة آليات توسيع قواعد البيانات:

آلية التوسع	Aurora	Aurora Serverless	Amazon RDS	DynamoDB
النطاق	مجموعة (Cluster)	مجموعة	قاعدة بيانات	جدول
التوسع الرأسي	حجم فئة المثيل	حدود إنتاجية ACU التلقائية	حجم فئة المثيل وحجم التخزين	غير متاح (N/A)
التوسع الأفقي	Aurora Auto Scaling لنسخ القراءة	نسخ Multi-AZ ونسخ القراءة	قواعد بيانات نسخ القراءة	الوضع حسب الطلب والوضع المزود مع Application Auto Scaling والفهارس الثانوية العامة
إدارة التخزين	تلقائي من AWS	تلقائي من AWS	يدوي	تلقائي من AWS

2️⃣ Scaling Aurora — توسيع Aurora

📖 كيف تتوسع قاعدة بيانات Aurora؟
يمكن توسيع مجموعة Aurora رأسياً بتغيير فئة مثيل قاعدة البيانات، أو أفقياً باستخدام Aurora Auto Scaling لإدارة عدد نسخ القراءة (Aurora Replicas) تلقائياً بناءً على مقاييس CloudWatch وقيم مستهدفة. يتم تعريف سياسة توسع تحدد الحد الأدنى والحد الأقصى لعدد نسخ Aurora Replicas التي يمكن إدارتها. لا يعتبر التوسع فورياً وقد يستغرق 15 دقيقة أو أكثر.

3️⃣ Scaling Aurora Serverless — توسيع Aurora Serverless

📖 كيف تعمل Aurora Serverless؟
Aurora Serverless هو تكوين عند الطلب يتوسع تلقائياً لمجموعات Amazon Aurora. يمكنك تشغيل قاعدة البيانات في السحابة دون إدارة أي مثيلات قاعدة بيانات. تحدد سعة قاعدة البيانات باستخدام الحد الأدنى والحد الأقصى لوحدات سعة Aurora (ACUs). كل ACU عبارة عن مزيج من حوالي 2 GiB من الذاكرة ووحدة CPU وشبكة مقابلة.

🔑 حالات استخدام Aurora Serverless: مثالية لأعباء العمل المتقطعة وغير المتوقعة مثل مواقع البيع بالتجزئة ذات الأحداث الموسمية وقواعد بيانات التقارير وبيئات التطوير والاختبار والتطبيقات الجديدة ذات المتطلبات غير المؤكدة.

4️⃣ Scaling Amazon RDS — توسيع Amazon RDS

📖 كيف تتوسع قاعدة بيانات Amazon RDS؟
يمكن التوسع الرأسي لـ Amazon RDS بتغيير فئة مثيل قاعدة البيانات أو حجم ونوع تخزين EBS، أو باستخدام Amazon RDS Storage Auto Scaling. يمكن التوسع الأفقي بإضافة قواعد بيانات نسخ القراءة (Read Replicas) لتوجيه حركة القراءة لأغراض إعداد التقارير وتحسين أداء التطبيق. عند التوسع الرأسي في بيئة Multi-AZ، يتم ترقية قاعدة البيانات الاحتياطية أولاً ثم يحدث تجاوز الفشل إلى قاعدة البيانات ذات الحجم الجديد مما يقلل وقت التوقف.

5️⃣ Scaling DynamoDB — توسيع DynamoDB

📖 كيف تتوسع جداول DynamoDB؟
عند إنشاء جدول جديد في DynamoDB، يجب تحديد وضع سعة الجدول: إما الوضع المزود (Provisioned Mode) أو الوضع حسب الطلب (On-Demand Mode). في الوضع حسب الطلب، يتكيف DynamoDB تلقائياً مع أعباء العمل بناءً على القراءات والكتابات الفعلية. في الوضع المزود، يتم تفعيل التوسع التلقائي لسعة القراءة (RCUs) والكتابة (WCUs) افتراضياً باستخدام Application Auto Scaling.

على سبيل المثال موقع مزاد إلكتروني يشهد ارتفاعاً هائلاً في عدد المستخدمين خلال الساعة الأخيرة من كل مزاد.
يستخدم DynamoDB On-Demand لاستيعاب الزيادات المفاجئة دون الحاجة لتخطيط مسبق.
عند انتهاء المزاد يعود الاستخدام إلى مستوياته الطبيعية ولا تدفع الشركة ثمن سعة غير مستخدمة.

مثل محطة وقود لديها 4 مضخات في الأيام العادية لكنها تضيف 6 مضخات مؤقتة في موسم العطلات وتزيلها بعد انتهاء الموسم هكذا يعمل التوسع التلقائي لقواعد البيانات. وكما أن بعض السيارات تتسع لراكبين فقط (توسع رأسي محدود) بينما يمكن للحافلة أن تحمل 50 راكباً (توسع أفقي) فإن قواعد البيانات تختار آلية التوسع المناسبة لاحتياجاتها.

✅ خلاصة: توسيع قواعد البيانات

• مع Aurora يمكنك اختيار حجم فئة المثيل وعدد نسخ Aurora Replicas.
• Aurora Serverless توسع الموارد تلقائياً بناءً على الحد الأدنى والحد الأقصى للسعة.
• يمكنك توسيع سعة الحوسبة لمثيل RDS رأسياً يدوياً.
• يمكن استخدام نسخ القراءة للتوسع الأفقي لمثيل RDS.
• الوضع حسب الطلب في DynamoDB يقدم نموذج تسعير يعتمد على القراءات والكتابات الفعلية.
• التوسع التلقائي لـ DynamoDB يستخدم Application Auto Scaling لضبط السعة المزودة ديناميكياً.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Aurora Replicas	نسخ Aurora	نسخ قراءة فقط لقاعدة بيانات Aurora تدعم التوسع الأفقي وتحسين أداء القراءة.
Aurora Serverless	أورورا بدون خوادم	تكوين عند الطلب يتوسع تلقائياً مع إدارة تلقائية للذاكرة والمعالج والشبكة.
ACU (Aurora Capacity Unit)	وحدة سعة Aurora	وحدة قياس تتكون من حوالي 2 GiB ذاكرة مع CPU وشبكة مقابلة.
Read Replica	نسخة قراءة	نسخة من قاعدة بيانات RDS تستخدم لتحسين أداء القراءة وتقليل الضغط على قاعدة البيانات الرئيسية.
On-Demand Mode	وضع حسب الطلب	نموذج دفع في DynamoDB يتكيف تلقائياً مع القراءات والكتابات الفعلية.
RCU / WCU	وحدة سعة القراءة/الكتابة	وحدات قياس سعة القراءة والكتابة المزودة في جداول DynamoDB.

1️⃣ Highly Available Systems — الأنظمة عالية التوفر

📖 ما هو النظام عالي التوفر (Highly Available System)؟
النظام عالي التوفر هو نظام يمكنه تحمل درجة معينة من التدهور مع البقاء متاحاً. يتم تقليل وقت التوقف (Downtime) قدر الإمكان، ويتطلب الحد الأدنى من التدخل البشري لإعادة النظام إلى مستويات التشغيل الطبيعية. يتطلب التوفر العالي تجنب نقاط الفشل الواحدة (Single Points of Failure) وتصميم البنية لتكون قادرة على التعافي التلقائي (Resilient).

💡 مستويات التوفر وما يعادلها من وقت التوقف:

نسبة التوفر	أقصى وقت توقف سنوياً	ما يعادله يومياً
90% (One Nine)	36.5 يوم	2.4 ساعة
99% (Two Nines)	3.65 يوم	14 دقيقة
99.9% (Three Nines)	8.76 ساعة	86 ثانية
99.99% (Four Nines)	52.6 دقيقة	8.6 ثانية
99.999% (Five Nines)	5.25 دقيقة	0.86 ثانية

2️⃣ Elastic Load Balancing (ELB) — موازنة الأحمال المرنة

📖 ما هي خدمة Elastic Load Balancing (ELB)؟
ELB تحل مشكلة نقطة الفشل الواحدة لخدمات AWS مثل مثيلات EC2 والحاويات. تقوم بتوزيع حركة المرور الواردة تلقائياً عبر أهداف متعددة في منطقة توفر واحدة أو أكثر. يمكن أن تكون موازنات الأحمال خارجية (External Facing) لتوزيع حركة المرور العامة، أو داخلية (Internal Facing) لتوزيع حركة المرور الخاصة. تراقب ELB صحة الأهداف المسجلة باستخدام فحوصات الصحة (Health Checks) وتوجه حركة المرور إلى الأهداف الصحية فقط.

3️⃣ Types of AWS Load Balancers — أنواع موازنات الأحمال

💡 مقارنة أنواع موازنات الأحمال:

النوع	طبقة OSI	الاستخدام الرئيسي	البروتوكولات
Application Load Balancer (ALB)	الطبقة 7 (التطبيق)	تطبيقات الويب والبنى التطبيقية	HTTP وHTTPS
Network Load Balancer (NLB)	الطبقة 4 (النقل)	ملايين الطلبات في الثانية بزمن استجابة فائق الانخفاض	TCP وUDP وTLS
Gateway Load Balancer (GWLB)	الطبقة 3 (الشبكة)	تحسين الأمان والامتثال عبر الأجهزة الافتراضية	GENEVE
Classic Load Balancer (CLB)	الطبقتان 3 و7	الشبكات القديمة EC2-Classic	HTTP وHTTPS وTCP

4️⃣ Load Balancer Components — مكونات موازن الأحمال

📖 ما هي المكونات الرئيسية لموازن الأحمال؟
يعمل موازن الأحمال كنقطة اتصال واحدة للعملاء. يضيف المستمعون (Listeners) الذين يتحققون من طلبات الاتصال باستخدام البروتوكول والمنفذ المكونين. تحدد القواعد (Rules) كيفية توجيه الطلبات إلى الأهداف المسجلة. تتكون كل قاعدة من أولوية وإجراء واحد أو أكثر وشرط واحد أو أكثر. مجموعات الأهداف (Target Groups) توجه الطلبات إلى هدف واحد أو أكثر مثل مثيلات EC2 باستخدام البروتوكول والمنفذ المحددين.

مكونات إضافية:

• شهادات SSL/TLS: بعض المستمعين مثل HTTPS يحتاجون إلى شهادات لتأمين حركة المرور. يمكن استخدام AWS Certificate Manager (ACM) لإدارة الشهادات.
• إعدادات فحص الصحة (Health Check Settings): تراقب صحة جميع الأهداف المسجلة وتوجه الطلبات إلى الأهداف الصحية فقط.

5️⃣ High Availability with ALB and RDS Multi-AZ — التوفر العالي مع ALB وRDS متعدد مناطق التوفر

📖 كيف تحقق ALB وRDS Multi-AZ التوفر العالي؟
في هذا النموذج، يتم التخلص من نقاط الفشل الواحدة. Application Load Balancer خارجي يستقبل حركة المرور العامة ويوزعها على مجموعة أهداف طبقة الويب عبر منطقتي توفر. إذا فشل فحص الصحة لمثيل EC2، يوقف ALB إرسال حركة المرور إليه ويرسل إشعاراً لمجموعة Auto Scaling لاستبداله. إذا فشلت منطقة توفر بأكملها، يوجه ALB حركة المرور إلى المنطقة الأخرى. في طبقة البيانات، يوفر Amazon RDS Multi-AZ التوفر العالي عن طريق مزامنة البيانات بشكل متزامن من قاعدة البيانات الرئيسية في منطقة توفر إلى قاعدة بيانات ثانوية في منطقة أخرى. في حالة الفشل، تتم ترقية قاعدة البيانات الثانوية لتصبح رئيسية.

على سبيل المثال تطبيق مصرفي يتطلب توفراً بنسبة 99.99% (أقل من ساعة توقف سنوياً).
يتم توزيع خوادم التطبيق عبر 3 مناطق توفر خلف ALB.
قاعدة البيانات مهيأة بتكوين Multi-AZ مع نسخ احتياطي فوري.
عند انقطاع التيار الكهربائي في إحدى مناطق التوفر يستمر التطبيق في العمل دون أي انقطاع يلاحظه المستخدمون.

6️⃣ Security Service with Gateway Load Balancer — خدمة أمان مع Gateway Load Balancer

📖 كيف يعمل Gateway Load Balancer (GWLB)؟
GWLB هو حل أمني محدد لفحص حركة المرور الواردة والصادرة باستخدام الأجهزة الافتراضية (Virtual Appliances). يعمل في طبقة الشبكة (الطبقة 3 من OSI) ويستمع لجميع حزم IP عبر جميع المنافذ. يتبادل GWLB والأجهزة الافتراضية المسجلة حركة المرور باستخدام بروتوكول GENEVE. يتم أولاً توجيه كل حركة المرور الداخلة إلى نقطة نهاية GWLB، ثم إلى GWLB نفسه الذي يوزعها على أجهزة الفحص الأمني.

✅ خلاصة: استخدام موازنات الأحمال لتحقيق التوفر العالي

• ELB توزع حركة المرور عبر أهداف متعددة في منطقة توفر أو أكثر وتراقب صحة الأهداف المسجلة.
• Application Load Balancer يُستخدم للتطبيقات ويعمل في طبقة التطبيق (الطبقة 7).
• Network Load Balancer يُستخدم لملايين الطلبات المتزامنة بزمن استجابة فائق ويعمل في طبقة النقل (الطبقة 4).
• Gateway Load Balancer يُستخدم لتحسين الأمان والامتثال ويعمل في طبقة الشبكة (الطبقة 3).
• RDS Multi-AZ يوفر تكراراً متزامناً لقاعدة البيانات عبر مناطق توفر لتجاوز الفشل تلقائياً.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Elastic Load Balancing (ELB)	موازنة الأحمال المرنة	خدمة توزع حركة المرور تلقائياً عبر أهداف متعددة وتراقب صحتها.
Application Load Balancer	موازن أحمال التطبيقات	موازن أحمال يعمل في طبقة التطبيق لتوجيه HTTP/HTTPS بناءً على محتوى الطلب.
Network Load Balancer	موازن أحمال الشبكة	موازن أحمال يعمل في طبقة النقل للتعامل مع ملايين الطلبات بزمن استجابة منخفض جداً.
Gateway Load Balancer	موازن أحمال البوابة	موازن أحمال لفحص حركة المرور باستخدام الأجهزة الافتراضية الأمنية.
Health Check	فحص الصحة	اختبار دوري للتحقق من توفر الهدف وقدرته على استقبال حركة المرور.
Multi-AZ	متعدد مناطق التوفر	تكوين قاعدة بيانات RDS ينسخ البيانات تلقائياً عبر مناطق توفر لتجاوز الفشل.
Listener	المستمع	مكون يتحقق من طلبات الاتصال بالبروتوكول والمنفذ المكونين ويطبق القواعد لتوجيه الطلبات.

1️⃣ DNS Lookups — عمليات بحث DNS

📖 كيف يعمل نظام أسماء النطاقات (DNS)؟
DNS هو خدمة موزعة عالمياً تترجم الأسماء المقروءة بشرياً مثل www.myweb.com إلى عناوين IP رقمية مثل 192.0.2.1 التي تستخدمها أجهزة الكمبيوتر للاتصال ببعضها. عادة لا يتصل العملاء مباشرة بخوادم DNS الرسمية، بل يتصلون بخدمة DNS تسمى المحلل (Resolver) الذي يعمل كوسيط ويحصل على معلومات DNS نيابة عنهم.

📋 خطوات بحث DNS النموذجي:

• يدخل المستخدم www.myweb.com في المتصفح ويُوجه الطلب إلى محلل DNS لمزود خدمة الإنترنت (ISP).
• يوجه المحلل الطلب إلى خادم جذر DNS (Root Name Server) الذي يعيد موقع خادم النطاق الأعلى (TLD) لـ .com.
• يوجه المحلل الطلب إلى خادم TLD الذي يعيد أسماء خوادم الأسماء المرتبطة بالنطاق myweb.com.
• يختار المحلل خادم اسم ويوجه الطلب إليه. يبحث الخادم في المنطقة المستضافة (Hosted Zone) عن السجل ويعيد عنوان IP.
• يعيد المحلل عنوان IP إلى المتصفح الذي يرسل طلب HTTP إلى الخادم ويعرض الصفحة.
• يخزن المحلل عنوان IP مؤقتاً (Cached) للاستجابة بشكل أسرع في المرة القادمة.

2️⃣ Amazon Route 53 — أمازون Route 53

📖 ما هي خدمة Amazon Route 53؟
Route 53 هي خدمة DNS عالية التوفر وقابلة للتوسع. يمكنك استخدامها لأداء ثلاث وظائف رئيسية: تسجيل النطاق (Domain Registration) وتوجيه DNS وفحوصات الصحة (Health Checks). توفر Route 53 خوادم أسماء (Name Servers) لتشكيل جزء من DNS الذي يساعد في ترجمة أسماء النطاقات إلى عناوين IP. يمكنها توصيل طلبات المستخدمين بالبنية التحتية التي تعمل على AWS مثل EC2 وELB وS3. كما تجري Route 53 فحوصات صحية لمراقبة صحة مواردك من خلال فحص نقاط النهاية (Endpoints) أو الفحوصات المحسوبة (Calculated Health Checks) أو مراقبة إنذارات CloudWatch.

3️⃣ Route 53 Routing Policies — سياسات التوجيه في Route 53

📖 ما هي أنواع سياسات التوجيه في Route 53؟
يدعم Route 53 أنواعاً متعددة من سياسات التوجيه التي تحدد كيفية استجابة Route 53 للاستعلامات. يمكن دمج هذه السياسات مع تجاوز الفشل في DNS لتمكين بنى منخفضة زمن الاستجابة ومتسامحة مع الأعطال.

💡 مقارنة سياسات التوجيه في Route 53:

السياسة	الوصف	حالة الاستخدام
Simple	توجيه قياسي لسجل DNS واحد عادةً إلى مورد واحد	أبسط تكوين لموقع ويب واحد
Weighted	ربط عدة موارد باسم مجال واحد مع توزيع حركة المرور حسب أوزان نسبية	اختبار إصدارات جديدة من البرامج وموازنة الأحمال
Latency	توجيه الطلبات إلى المنطقة التي توفر أقل زمن استجابة للمستخدم	تحسين الأداء للتطبيقات المستضافة في مناطق متعددة
Failover	توجيه حركة المرور إلى مورد صحي أو إلى مورد آخر عند فشل الأول	النسخ الاحتياطي النشط-السلبي (Active-Passive)
Geolocation	توجيه حركة المرور بناءً على الموقع الجغرافي للمستخدم	توطين المحتوى وتقييد التوزيع حسب المنطقة
Geoproximity	توجيه حركة المرور بناءً على الموقع الجغرافي للمستخدم والمورد مع تحيز قابل للتعديل	توسيع أو تضييق المنطقة الجغرافية للتوجيه
Multivalue Answer	إعادة قيم متعددة (مثل عناوين IP) في استعلام DNS مع فحص صحة كل مورد	تحسين التوفر باستخدام DNS (ليس بديلاً عن موازن الأحمال)
IP-based	توجيه دقيق بناءً على عنوان IP للمستخدم لتحسين أداء الشبكة والتطبيق	ضبط دقيق للتوجيه بناءً على عنوان IP المصدر

4️⃣ Public and Private Hosted Zones — المناطق المستضافة العامة والخاصة

📖 الفرق بين المناطق المستضافة العامة والخاصة؟
المناطق المستضافة العامة (Public Hosted Zones) تُستخدم لتوجيه حركة مرور الإنترنت إلى مواردك مثل استضافة موقع الشركة على EC2. المناطق المستضافة الخاصة (Private Hosted Zones) تُستخدم لتوجيه حركة المرور داخل VPC. Route 53 Resolver يستجيب بشكل متكرر لاستعلامات DNS من موارد AWS للسجلات العامة وأسماء VPC الخاصة والمناطق الخاصة، وهو متاح افتراضياً في جميع VPCs.

5️⃣ Multi-Region Failover — تجاوز الفشل عبر المناطق

📖 كيف يعمل تجاوز الفشل عبر المناطق في Route 53؟
عند وجود موارد متعددة تؤدي نفس الوظيفة، يمكنك تكوين تجاوز فشل DNS بحيث يوجه Route 53 حركة المرور من المورد غير الصحي إلى المورد الصحي. في تكوين النشط-السلبي (Active-Passive Failover)، يكون لديك مورد أساسي أو مجموعة موارد أساسية متاحة معظم الوقت، ومورد ثانوي أو مجموعة موارد ثانوية في وضع الاستعداد. يستجيب Route 53 باستخدام السجل الأساسي عندما يكون المورد الأساسي صحياً، وعند فشله يستخدم السجل الثانوي.

على سبيل المثال شركة عالمية تستضيف موقعها في منطقتين: us-east-1 (أساسية) وeu-west-1 (ثانوية).
تستخدم Latency Routing لتوجيه المستخدمين إلى المنطقة الأقرب إليهم.
إذا تعطلت المنطقة الأساسية تماماً يكتشف Route 53 الفشل عبر فحص الصحة ويوجه كل حركة المرور إلى المنطقة الثانوية.
يستمر الموقع في العمل دون أي تأثير على المستخدمين النهائيين.

مثل دليل الهاتف الذي يربط اسم الشخص برقم هاتفه فإن DNS يربط اسم الموقع بعنوان IP الخاص به. وكما أن سائقي سيارات الأجرة يستخدمون تطبيقات الملاحة لاختيار الطريق الأسرع بناءً على موقع الراكب فإن Latency Routing توجه المستخدم إلى الخادم الأقرب له لأداء أسرع.

✅ خلاصة: استخدام Route 53 لتحقيق التوفر العالي

• Route 53 هي خدمة DNS تدير تسجيل النطاقات وتوفر المناطق المستضافة وخوادم الأسماء وتجري توجيه DNS وفحوصات الصحة.
• تدعم Route 53 خيارات توجيه متعددة: Simple وWeighted وLatency وFailover وGeoproximity وGeolocation وMultivalue Answer وIP-based.
• المناطق المستضافة العامة للإنترنت والخاصة داخل VPC.
• تجاوز الفشل النشط-السلبي يضمن استمرارية الخدمة عند فشل المورد الأساسي.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon Route 53	أمازون Route 53	خدمة DNS عالية التوفر تدير تسجيل النطاقات والتوجيه وفحوصات الصحة.
DNS Resolver	محلل DNS	خادم وسيط يحصل على معلومات DNS نيابة عن العميل ويخزنها مؤقتاً.
Hosted Zone	منطقة مستضافة	حاوية للسجلات تحدد كيفية توجيه حركة المرور لنطاق معين ونطاقاته الفرعية.
Failover Routing	توجيه تجاوز الفشل	سياسة توجيه توجه حركة المرور تلقائياً من المورد الفاشل إلى المورد البديل الصحي.
Latency Routing	توجيه زمن الاستجابة	سياسة توجيه توجه المستخدمين إلى المنطقة التي توفر أقل زمن استجابة لهم.
Geolocation Routing	توجيه الموقع الجغرافي	سياسة توجيه بناءً على الموقع الجغرافي الذي تنشأ منه استعلامات DNS.
Active-Passive Failover	تجاوز فشل نشط-سلبي	تكوين يكون فيه المورد الأساسي نشطاً والثانوي في وضع الاستعداد حتى الحاجة.

1️⃣ Failure Management – Use Fault Isolation — إدارة الفشل – استخدام عزل الأعطال

📖 كيف يدير AWS Well-Architected Framework فشل الأنظمة؟
تضمن حدود عزل الأعطال (Fault Isolation Boundaries) ألا تؤثر الأعطال على النظام بأكمله. باستخدام حدود عزل متعددة، يمكنك تحديد تأثير الفشل على عدد محدود من المكونات. من أفضل الممارسات نشر أعباء العمل في مواقع متعددة (مناطق توفر أو مناطق جغرافية) وأتمتة التعافي للمكونات المحصورة في موقع واحد إذا كان النشر في مواقع متعددة غير ممكن تقنياً.

2️⃣ Failure Management – Design Workload to Withstand Component Failures — تصميم أعباء العمل لتحمل أعطال المكونات

📖 كيف تصمم أعباء العمل لتحمل أعطال المكونات؟
من أفضل الممارسات التحويل إلى الموارد الصحية (Fail Over to Healthy Resources) عند حدوث فشل في المورد. يجب توزيع الحمل دائماً عبر الموارد ومناطق التوفر والمناطق، وتحويل حركة المرور إلى الموارد الصحية المتبقية يمكن أن يخفف من تأثير فشل المورد الفردي. أيضاً، يجب إرسال الإشعارات (Send Notifications) عند اكتشاف تجاوز الحدود حتى لو تم حل المشكلة تلقائياً. يساعد الشفاء التلقائي (Auto Healing) في جعل أعباء العمل موثوقة، لكنه قد يخفي مشاكل أساسية تحتاج إلى معالجة.

3️⃣ Compute and Hardware — الحوسبة والأجهزة

📖 ما هي أفضل ممارسات الحوسبة للتوفر العالي؟
قم بتوسيع موارد الحوسبة ديناميكياً (Scale Your Compute Resources Dynamically). توفر AWS المرونة لتوسيع الموارد لأعلى أو لأسفل ديناميكياً من خلال آليات توسع متنوعة لتلبية تغيرات الطلب. من مناهج التوسع المختلفة: تتبع الهدف (Target-Tracking) والتوسع التنبؤي (Predictive Scaling) والتوسع المجدول (Schedule-Based) وتوسع الخدمة (Service Scaling) مثل اختيار الخدمات بدون خوادم التي تتوسع تلقائياً بطبيعتها.

🔑 الخدمات الداعمة في هذه الوحدة: تدعم العديد من خدمات AWS هذه الممارسات بما في ذلك Route 53 وCloudWatch وAmazon EC2 Auto Scaling وELB.

✅ خلاصة: تطبيق مبادئ إطار العمل المتقن للتوفر العالي

• انشر أعباء العمل في مواقع متعددة.
• أتمت التعافي للمكونات المحصورة في موقع واحد.
• حول إلى الموارد الصحية عند حدوث الفشل.
• أرسل الإشعارات عندما تؤثر الأحداث على التوفر.
• وسع موارد الحوسبة ديناميكياً.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Fault Isolation Boundary	حد عزل الأعطال	حد يحد من تأثير الفشل داخل عبء العمل بحيث لا يؤثر على المكونات خارجه.
Auto Healing	الشفاء التلقائي	آلية تكتشف وتصلح الأعطال تلقائياً دون تدخل بشري.
Target-Tracking	تتبع الهدف	نهج توسع يراقب مقياساً ويضبط السعة تلقائياً للحفاظ على قيمة مستهدفة.
Active-Passive Failover	تجاوز الفشل النشط-السلبي	نموذج تتوفر فيه الموارد الأساسية معظم الوقت والموارد الثانوية في وضع الاستعداد.
KPI (Key Performance Indicator)	مؤشر الأداء الرئيسي	مقياس قابل للقياس يستخدم لتقييم نجاح النظام في تحقيق أهداف الأداء.

1️⃣ Guided Lab: Creating a Highly Available Environment — المعمل الموجه: إنشاء بيئة عالية التوفر

📖 ماذا ستتعلم في المعمل الموجه لهذه الوحدة؟
في هذا المعمل، ستقوم بتنفيذ المهام الرئيسية التالية: فحص VPC مزود، إنشاء Application Load Balancer، إنشاء مجموعة Amazon EC2 Auto Scaling باستخدام قالب إطلاق، تحديث مجموعات الأمان (Security Groups)، اختبار التطبيق، واختبار التوفر العالي. تشمل المهام الاختيارية جعل قاعدة البيانات عالية التوفر وتكوين بوابة NAT عالية التوفر.

2️⃣ Café Lab: Creating a Scalable and Highly Available Environment — معمل التحدي: إنشاء بيئة قابلة للتوسع وعالية التوفر للمقهى

📖 ما هو تحديث الإصدار 6 من بنية المقهى؟
يمثل الإصدار 6 (V6) نقلة نوعية في بنية المقهى. يستمر الموقع الديناميكي في استقبال الطلبات الإلكترونية بنجاح، وبدأ أصحاب المقهى (سارة وأحمد) في استخدام بيانات سجل الطلبات للمحاسبة واتخاذ قرارات الإنتاج. بسبب العدد المتزايد من المستخدمين واستعلامات قاعدة البيانات الإضافية، تشعر Sofia بالقلق بشأن الأداء والأمان. في هذا الإصدار، ستتم إضافة موازن تحميل (Load Balancer) وتنفيذ التوسع التلقائي على مثيلات EC2 وتوزيع مثيلات الحوسبة وقاعدة البيانات عبر منطقتي توفر.

💡 تطور بنية المقهى (V1 إلى V6):

الإصدار	السبب التجاري للتحديث	التحديثات التقنية
V1	إنشاء موقع ثابت لمقهى صغير	استضافة الموقع على Amazon S3
V2	إضافة الطلبات الإلكترونية	نشر تطبيق الويب وقاعدة البيانات على EC2
V3	تقليل جهد صيانة قاعدة البيانات وتأمينها	فصل طبقتَي الويب وقاعدة البيانات ونقلها إلى Amazon RDS
V4	تعزيز أمان تطبيق الويب	استخدام ميزات VPC لتكوين شبكات فرعية عامة وخاصة
V5	إنشاء آليات وصول منفصلة حسب الدور	إضافة مجموعات IAM وسياسات موارد
V6	ضمان قدرة الموقع على التعامل مع زيادة الزيارات المتوقعة	إضافة موازن تحميل وتوسع تلقائي عبر منطقتي توفر

على سبيل المثال المقهى الذي بدأ بموقع ثابت بسيط على S3 في V1 أصبح الآن في V6 بنية متكاملة مع موازن تحميل وتوسع تلقائي وقاعدة بيانات موزعة على منطقتي توفر. هذا التطور يعكس كيف تنمو البنية السحابية مع نمو الأعمال، وكيف أن كل إصدار يبني على سابقه دون الحاجة لإعادة اختراع العجلة.

1. A company runs a web application on EC2 instances behind an Application Load Balancer. The application experiences high latency during peak hours. The operations team needs to monitor the average request latency over 5-minute intervals. Which CloudWatch feature should they use?

A) CloudWatch Metrics with a custom statistic for average latency B) CloudWatch Logs Insights C) CloudWatch Synthetics D) AWS CloudTrail

✅ Correct! CloudWatch Metrics collect and track performance data such as request latency, and you can define custom statistics to aggregate data over specified periods. This is the direct way to monitor average latency.

❌ Incorrect. The correct answer is A. CloudWatch Metrics collect and track performance data and support custom statistics for aggregation over time. CloudWatch Logs Insights is for querying logs, not metrics. Synthetics creates canaries for endpoint monitoring. CloudTrail records API activity, not performance metrics.

2. A DevOps engineer wants to receive an email notification whenever the CPU utilization of an EC2 instance exceeds 80% for at least 10 minutes. What is the MOST efficient way to achieve this?

A) Write a custom script on the EC2 instance that checks CPU and sends an email via SMTP B) Create a CloudWatch alarm on the CPUUtilization metric that triggers an SNS topic with an email subscription C) Use AWS Config to monitor CPU and trigger a Lambda function to send email D) Set up a scheduled Lambda function to poll CloudWatch every 10 minutes and send email

✅ Correct! A CloudWatch alarm monitors a metric over time and can trigger an SNS topic. SNS can then send email notifications to subscribed endpoints. This is the native, managed approach with no custom code required.

❌ Incorrect. The correct answer is B. CloudWatch alarms natively evaluate metrics over a specified period and trigger SNS topics for notifications. The custom script approach is fragile and not managed. AWS Config tracks configuration changes, not performance metrics. A polling Lambda is unnecessarily complex when CloudWatch alarms already handle this.

3. A company wants its Auto Scaling group to add EC2 instances when CPU utilization exceeds 70% and remove instances when it drops below 30%. Which scaling policy type should they use?

A) Scheduled scaling B) Simple scaling C) Target tracking scaling D) Manual scaling

✅ Correct! Target tracking scaling automatically adjusts the number of instances to keep the specified metric (e.g., CPU utilization) at or near the target value. In this case, you would set a target of 50% to maintain headroom for spikes.

❌ Incorrect. The correct answer is C. Target tracking scaling is the simplest approach — you select a metric and a target value, and Auto Scaling adjusts capacity to maintain that target. Scheduled scaling is for predictable patterns. Simple scaling requires manual creation of separate scale-out and scale-in policies with cooldown periods. Manual scaling requires human intervention.

4. An application runs on EC2 instances in an Auto Scaling group behind an Application Load Balancer. The application requires that all user sessions from the same client IP be routed to the same EC2 instance. Which ALB routing algorithm should the company configure?

A) Round robin B) Least outstanding requests C) Sticky sessions (session affinity) D) Weighted random

✅ Correct! Sticky sessions (session affinity) enable the ALB to bind a user's session to a specific target. The load balancer uses a cookie to remember which instance served the request and routes subsequent requests from the same client to that same instance.

❌ Incorrect. The correct answer is C. Sticky sessions (also called session affinity) ensure the same client is always directed to the same target instance. Round robin distributes evenly across all targets. Least outstanding requests sends traffic to the least busy target. Weighted random distributes based on weights.

5. A company is designing a highly available architecture for a web application across two Availability Zones. Each AZ has EC2 instances in an Auto Scaling group. What is the MINIMUM number of Elastic Load Balancer nodes required for high availability?

A) One load balancer node in one AZ B) Two load balancer nodes in the same AZ C) One load balancer node in each AZ where targets are deployed D) Four load balancer nodes, two in each AZ

✅ Correct! Elastic Load Balancer automatically creates one load balancer node per enabled Availability Zone where you deploy targets. For high availability across two AZs, you need at least one node in each AZ so that if one AZ fails, the other node continues to route traffic.

❌ Incorrect. The correct answer is C. ELB automatically scales its nodes and places one in each AZ where targets are registered. If you only enable one AZ, you have a single point of failure. The minimum for HA is a node in each AZ where targets exist. You don't need to specify a number — ELB handles this automatically.

6. A company needs to route traffic to different target groups based on the URL path. Requests to /images/* should go to one target group and requests to /api/* to another. Which load balancer type should they use?

A) Network Load Balancer (NLB) B) Application Load Balancer (ALB) C) Classic Load Balancer (CLB) D) Gateway Load Balancer (GWLB)

✅ Correct! Application Load Balancer supports path-based routing, which allows you to define listener rules that route requests to different target groups based on the URL path. This is ideal for microservices and container-based architectures.

❌ Incorrect. The correct answer is B. ALB operates at Layer 7 and supports content-based routing including path patterns, host headers, and query strings. NLB operates at Layer 4 (TCP/UDP) and does not support path-based routing. CLB is legacy and has limited rules. GWLB is for third-party virtual appliances.

7. A company wants to ensure that an EC2 Auto Scaling group replaces an unhealthy instance automatically. The Auto Scaling group uses an Application Load Balancer. What must be configured to enable automatic replacement of unhealthy instances?

A) A CloudWatch alarm that triggers a Lambda function to replace the instance B) An ELB health check on the Auto Scaling group C) A scheduled scaling policy D) An Amazon EventBridge rule

✅ Correct! When you configure an ELB health check for an Auto Scaling group, the group uses the load balancer's health check results to determine instance health. If an instance fails the health check, Auto Scaling automatically terminates it and launches a new instance to replace it.

❌ Incorrect. The correct answer is B. Associating an ELB health check with the Auto Scaling group enables automatic replacement of instances that fail the health check. CloudWatch alarms and Lambda are extra complexity. Scheduled scaling is for predictable traffic patterns. EventBridge is for event-driven automation, not health-check-based replacement.

8. A company runs a stateful web application. They want to use an Auto Scaling group for elasticity but need to preserve user session data. Which architecture should they use?

A) Store session data on local instance storage B) Use sticky sessions on the ALB and store sessions on the EC2 instances C) Store session data on EBS volumes and reattach them to new instances D) Store session data externally in ElastiCache or DynamoDB

✅ Correct! For Auto Scaling groups where instances are ephemeral, session data should be stored externally in a shared data store like ElastiCache or DynamoDB. This ensures sessions survive instance terminations and are accessible from any instance in the group.

❌ Incorrect. The correct answer is D. Externalizing session state to a managed service like ElastiCache (for fast in-memory storage) or DynamoDB (for durable storage) is the recommended pattern for elastic, stateless application tiers. Local storage is ephemeral. Sticky sessions still lose data if the instance is terminated. EBS volumes cannot be easily reattached across instances in an Auto Scaling group.

9. A company needs to send operational metrics from their on-premises data center to AWS for monitoring alongside their cloud resources. Which CloudWatch feature supports this use case?

A) CloudWatch Synthetics B) CloudWatch custom metrics C) CloudWatch Contributor Insights D) CloudWatch ServiceLens

✅ Correct! CloudWatch custom metrics allow you to publish your own metrics from any source, including on-premises servers, using the PutMetricData API. These custom metrics appear in CloudWatch alongside AWS-provided metrics for unified monitoring.

❌ Incorrect. The correct answer is B. Custom metrics are designed to let you send any operational data to CloudWatch from any source. Synthetics creates canaries for endpoint monitoring. Contributor Insights analyzes log data. ServiceLens integrates with X-Ray for tracing — none of these ingests custom operational metrics from on-premises.

10. A company uses a Network Load Balancer (NLB) to handle millions of requests per second with extremely low latency. The instances in the target group need to see the original client IP address. How does NLB preserve the client IP by default?

A) NLB preserves the client IP address natively because it operates at Layer 4 B) NLB uses the X-Forwarded-For header C) NLB adds a custom TCP header with the client IP D) NLB does not preserve the client IP — the instances always see the NLB IP

✅ Correct! NLB operates at Layer 4 (TCP/UDP) and preserves the original client IP address natively in the packets. There is no proxy or termination at Layer 7, so the target instances receive packets with the true source IP of the client.

❌ Incorrect. The correct answer is A. Because NLB operates at Layer 4 and does not terminate the TCP connection, it passes packets through to targets with the original client IP intact. X-Forwarded-For is an HTTP header used by ALB (Layer 7). NLB does not add custom TCP headers. The client IP is not replaced by the NLB IP.

🚀 الخاتمة

في هذه الوحدة، تعلمنا كيفية بناء بنى سحابية متفاعلة (Reactive Architectures) تجمع بين المراقبة الذكية والمرونة الديناميكية والتوفر العالي. استعرضنا كيفية استخدام Amazon CloudWatch وAmazon EventBridge لمراقبة الموارد والتطبيقات وجمع السجلات والمقاييس وتفعيل الإنذارات. تعمقنا في Amazon EC2 Auto Scaling بآلياته المتعددة (المجدولة والديناميكية والتنبؤية) لتوسيع موارد الحوسبة، كما استعرضنا كيفية توسيع قواعد البيانات المختلفة (Aurora وRDS وDynamoDB). تعرفنا على أنوع موازنات الأحمال الأربعة (ALB وNLB وGWLB وCLB) ودورها الحيوي في تحقيق التوفر العالي، وكيفية استخدام Amazon Route 53 مع سياسات التوجيه المتنوعة لتجاوز الفشل على مستوى المنطقة. وأخيراً، طبقنا مبادئ AWS Well-Architected Framework لضمان تصميم أنظمة موثوقة وقادرة على التعافي التلقائي من الأعطال.

تعديل المقال