🎯 عن هذا المقال
1️⃣ ماذا ستتعلم؟ تحقيق المرونة والتوفر العالي عبر Auto Scaling وElastic Load Balancing، ومراقبة كل شيء عبر Amazon CloudWatch وAWS CloudTrail، وتوجيه حركة DNS عبر Amazon Route 53.
2️⃣ لماذا هو مهم؟ التطبيقات التي لا تتوسع تنهار تحت الضغط، والتي لا تُراقب تفشل بصمت — المرونة والمراقبة هما الفرق بين تطبيق ينجح وآخر يفشل.
3️⃣ كيف يرتبط بما سبق؟ هذه الوحدة تجمع كل ما تعلمناه — الحوسبة (EC2) + الشبكات (VPC) + التخزين (S3/EBS) + قواعد البيانات (RDS) — في بنية واحدة مرنة وموثوقة وقابلة للمراقبة.
1️⃣ المرونة (Elasticity) في السحابة
📖 المرونة (Elasticity) هي قدرة بنيتك على التوسع تلقائياً مع زيادة الطلب والتقلص مع انخفاضه. التوفر العالي (High Availability) هو قدرة النظام على الاستمرار في العمل رغم فشل بعض مكوناته. المراقبة (Monitoring) هي العيون التي ترى كل هذا وتنبهك قبل فوات الأوان.
هذه الركائز الثلاث معاً تصنع تطبيقاً سحابياً حقيقياً — ليس مجرد خوادم في السحابة، بل نظاماً حياً يتكيف مع ظروفه.
📋 الخدمات الأساسية للوحدة
هذه الركائز الثلاث معاً تصنع تطبيقاً سحابياً حقيقياً — ليس مجرد خوادم في السحابة، بل نظاماً حياً يتكيف مع ظروفه.
- Amazon EC2 Auto Scaling: يضيف ويزيل مثيلات EC2 تلقائياً حسب الطلب — عمودياً (حجم المثيل) أو أفقياً (عدد المثيلات).
- Elastic Load Balancing (ELB): يوزع حركة المرور تلقائياً بين المثيلات المتعددة — يكتشف المثيلات المعطوبة ويتجنبها.
- Amazon CloudWatch: يجمع المقاييس والسجلات والأحداث من كل خدمات AWS — لوحة القيادة المركزية لمراقبة كل شيء.
- AWS CloudTrail: يسجل كل استدعاء API في حسابك — من ضغط على زر ومتى ومن أي IP.
- Amazon Route 53: خدمة DNS عالية التوفر مع توجيه متقدم يدعم failover وgeolocation وweighted routing.
تطبيق تجارة إلكترونية يستعد ليوم التخفيضات الكبرى (Prime Day).
قبل الحدث: يعمل التطبيق على 4 مثيلات خلف ALB — تكفي 10,000 زائر متزامن.
صباح يوم التخفيضات: الزوار يقفزون إلى 50,000 — CloudWatch يرصد ارتفاع CPU فوق 70%، وAuto Scaling يضيف 12 مثيلاً تلقائياً خلال 3 دقائق.
بعد ساعتين: الزوار يصلون إلى 200,000 — Auto Scaling يضيف 20 مثيلاً إضافياً. ALB يوزع الحمل بين الجميع.
منتصف الليل: الزوار يعودون إلى 2,000 — Auto Scaling يزيل المثيلات الزائدة، والتكلفة تنخفض معها.
طوال اليوم: CloudWatch يراقب الأداء وCloudTrail يسجل كل حدث، وRoute 53 يتأكد من وصول المستخدمين لأقرب نقطة نهاية.
النتيجة: صفر توقف، أداء ثابت، وتكلفة متناسبة تماماً مع الحمل الفعلي.
قبل الحدث: يعمل التطبيق على 4 مثيلات خلف ALB — تكفي 10,000 زائر متزامن.
صباح يوم التخفيضات: الزوار يقفزون إلى 50,000 — CloudWatch يرصد ارتفاع CPU فوق 70%، وAuto Scaling يضيف 12 مثيلاً تلقائياً خلال 3 دقائق.
بعد ساعتين: الزوار يصلون إلى 200,000 — Auto Scaling يضيف 20 مثيلاً إضافياً. ALB يوزع الحمل بين الجميع.
منتصف الليل: الزوار يعودون إلى 2,000 — Auto Scaling يزيل المثيلات الزائدة، والتكلفة تنخفض معها.
طوال اليوم: CloudWatch يراقب الأداء وCloudTrail يسجل كل حدث، وRoute 53 يتأكد من وصول المستخدمين لأقرب نقطة نهاية.
النتيجة: صفر توقف، أداء ثابت، وتكلفة متناسبة تماماً مع الحمل الفعلي.
المرونة والتوفر العالي مثل محرك سيارة ذكي.
Auto Scaling مثل نظام الحقن الإلكتروني: يضخ وقوداً أكثر عند الضغط على دواسة البنزين (زيادة الطلب) ويقلل عند التوقف (انخفاض الطلب).
Elastic Load Balancing مثل ناقل الحركة الأوتوماتيكي: يوزع القوة على العجلات الأربع حسب الحاجة — إذا انزلقت عجلة، ينقل القوة للأخرى.
CloudWatch مثل لوحة العدادات: ترى السرعة والحرارة والضغط — تعرف متى تتوقف للصيانة قبل أن يحترق المحرك.
Route 53 مثل نظام الملاحة GPS: يجد أسرع طريق ويتجنب الزحام ويحول مسارك إذا انغلق طريق.
Auto Scaling مثل نظام الحقن الإلكتروني: يضخ وقوداً أكثر عند الضغط على دواسة البنزين (زيادة الطلب) ويقلل عند التوقف (انخفاض الطلب).
Elastic Load Balancing مثل ناقل الحركة الأوتوماتيكي: يوزع القوة على العجلات الأربع حسب الحاجة — إذا انزلقت عجلة، ينقل القوة للأخرى.
CloudWatch مثل لوحة العدادات: ترى السرعة والحرارة والضغط — تعرف متى تتوقف للصيانة قبل أن يحترق المحرك.
Route 53 مثل نظام الملاحة GPS: يجد أسرع طريق ويتجنب الزحام ويحول مسارك إذا انغلق طريق.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Elasticity | المرونة | قدرة النظام على التوسع والتقلص تلقائياً مع تغير الطلب. |
| High Availability | التوفر العالي | استمرار النظام في العمل رغم فشل بعض مكوناته. |
| Scalability | قابلية التوسع | قدرة البنية على النمو لاستيعاب أحمال عمل متزايدة. |
| Fault Tolerance | تحمل الأخطاء | استمرار العمل دون انقطاع حتى عند فشل المكونات. |
1️⃣ EC2 Auto Scaling
📖 EC2 Auto Scaling يضمن أن لديك العدد المناسب من مثيلات EC2 في كل لحظة — لا أكثر (تهدر مالاً) ولا أقل (تخسر أداءً).
يراقب صحة المثيلات ويستبدل المعطوبة تلقائياً، ويضيف مثيلات جديدة عند زيادة الطلب ويزيلها عند انخفاضه — كل ذلك دون تدخل بشري.
📋 المكونات الثلاثة لـ Auto Scaling
يراقب صحة المثيلات ويستبدل المعطوبة تلقائياً، ويضيف مثيلات جديدة عند زيادة الطلب ويزيلها عند انخفاضه — كل ذلك دون تدخل بشري.
- قالب الإطلاق (Launch Template): يحدد مواصفات المثيل — AMI، نوع المثيل، Security Groups، User Data... كل ما يحتاجه المثيل الجديد.
- مجموعة Auto Scaling (Auto Scaling Group - ASG): تحتوي على المثيلات وتديرها — تحدد الحد الأدنى (min)، الأقصى (max)، والعدد المطلوب (desired).
- سياسة التوسع (Scaling Policy): القاعدة التي تقرر متى يضاف مثيل أو يُزال — مبنية على مقاييس CloudWatch مثل CPU Utilization أو Request Count.
ASG نموذجي لتطبيق ويب:.
Launch Template: Amazon Linux 2023، t3.medium، SG-Web، User Data ينصب Apache وPHP.
ASG: min=2, max=20, desired=2 (في الحالة الطبيعية مثيلان).
Scaling Policy: إذا تجاوز متوسط CPU لجميع المثيلات 70% لمدة 3 دقائق ← أضف مثيلاً واحداً.
Scaling Policy: إذا انخفض متوسط CPU عن 30% لمدة 10 دقائق ← أزل مثيلاً واحداً.
النتيجة: التطبيق يحافظ على CPU بين 30-70% في كل الأوقات — لا إرهاق ولا هدر.
Launch Template: Amazon Linux 2023، t3.medium، SG-Web، User Data ينصب Apache وPHP.
ASG: min=2, max=20, desired=2 (في الحالة الطبيعية مثيلان).
Scaling Policy: إذا تجاوز متوسط CPU لجميع المثيلات 70% لمدة 3 دقائق ← أضف مثيلاً واحداً.
Scaling Policy: إذا انخفض متوسط CPU عن 30% لمدة 10 دقائق ← أزل مثيلاً واحداً.
النتيجة: التطبيق يحافظ على CPU بين 30-70% في كل الأوقات — لا إرهاق ولا هدر.
2️⃣ أنواع سياسات التوسع
📖 لديك أربعة أنواع من سياسات التوسع تمنحك تحكماً دقيقاً في كيفية استجابة ASG لتغيرات الطلب.
اختيار النوع المناسب يعتمد على نمط حمل التطبيق ومدى سرعة التغيرات.
📋 أنواع سياسات التوسع
اختيار النوع المناسب يعتمد على نمط حمل التطبيق ومدى سرعة التغيرات.
- Target Tracking: تحدد قيمة مستهدفة (مثلاً CPU=50%) وASG يضيف/يزيل المثيلات للحفاظ على هذا الهدف. الأبسط والأكثر استخداماً.
- Step Scaling: تحدد خطوات — إذا تجاوز CPU 60% أضف 1، إذا تجاوز 80% أضف 3. استجابة متدرجة للتغيرات الكبيرة.
- Simple Scaling: بسيط: إذا تجاوز CPU 70% ← أضف 1. لكن يحتاج cooldown period (فترة انتظار) قبل التوسع التالي مما يجعله أبطأ.
- Scheduled Scaling: توسع حسب جدول زمني — مثلاً أضف مثيلات كل يوم اثنين 9 صباحاً وأزلها 5 مساءً. مثالي للأحمال المتوقعة.
نظام رواتب يُستخدم بكثافة آخر 3 أيام من كل شهر.
Scheduled Scaling: في اليوم 28 من كل شهر 7 صباحاً ← ارفع min إلى 5 وdesired إلى 5 (استعداداً للذروة).
Target Tracking: CPU مستهدف 60% — إذا زاد الحمل أكثر، يضاف المزيد تلقائياً.
Scheduled Scaling: في اليوم 1 من الشهر الجديد 12 منتصف الليل ← أرجع min إلى 1 وdesired إلى 1.
النتيجة: النظام يتسع تلقائياً للأيام الحرجة وينكمش باقي الشهر — توفير تكلفة 80% مقارنة بتشغيل 5 مثيلات طوال الشهر.
Scheduled Scaling: في اليوم 28 من كل شهر 7 صباحاً ← ارفع min إلى 5 وdesired إلى 5 (استعداداً للذروة).
Target Tracking: CPU مستهدف 60% — إذا زاد الحمل أكثر، يضاف المزيد تلقائياً.
Scheduled Scaling: في اليوم 1 من الشهر الجديد 12 منتصف الليل ← أرجع min إلى 1 وdesired إلى 1.
النتيجة: النظام يتسع تلقائياً للأيام الحرجة وينكمش باقي الشهر — توفير تكلفة 80% مقارنة بتشغيل 5 مثيلات طوال الشهر.
3️⃣ فحوصات الصحة والتكامل مع ELB
📖 Auto Scaling يفحص صحة المثيلات باستمرار — إذا فشل مثيل، يستبدله تلقائياً بآخر جديد سليم.
فحوصات EC2 (العتاد والبرنامج الأساسي) + فحوصات ELB (استجابة التطبيق لطلبات HTTP) = اكتشاف شامل للمشكلات.
📋 أنواع فحوصات الصحة
فحوصات EC2 (العتاد والبرنامج الأساسي) + فحوصات ELB (استجابة التطبيق لطلبات HTTP) = اكتشاف شامل للمشكلات.
- فحص EC2: يتحقق من أن المثيل يعمل (running) وأن العتاد سليم. أساسي وإجباري.
- فحص ELB: يتحقق من أن التطبيق يستجيب لطلبات HTTP على المسار المحدد (مثلاً /health). يكتشف مشاكل التطبيق وليس فقط العتاد.
- عند فشل الفحص: ASG يضع المثيل في وضع "غير صحي" (Unhealthy) ثم يستبدله بمثيل جديد من نفس القالب.
- فترة السماح (Grace Period): وقت يُعطى للمثيل الجديد قبل بدء الفحوصات — يمنع استبدال مثيل ما زال يُقلع.
🔑 أفضل ممارسات Auto Scaling:
وزّع المثيلات على AZs متعددة داخل ASG — إذا تعطلت AZ كاملة، المثيلات في الـ AZ الأخرى تستمر.
استخدم Target Tracking مع Metric Math لمراقبة مقاييس مركبة (مثلاً CPU + Request Count معاً).
فعّل فحوصات ELB الصحية بالإضافة لفحوصات EC2 — EC2 قد يعمل لكن تطبيقك متوقف.
اضبط Cooldown Period (افتراضي 300 ثانية) — يمنع التوسع المتكرر السريع (flapping).
وزّع المثيلات على AZs متعددة داخل ASG — إذا تعطلت AZ كاملة، المثيلات في الـ AZ الأخرى تستمر.
استخدم Target Tracking مع Metric Math لمراقبة مقاييس مركبة (مثلاً CPU + Request Count معاً).
فعّل فحوصات ELB الصحية بالإضافة لفحوصات EC2 — EC2 قد يعمل لكن تطبيقك متوقف.
اضبط Cooldown Period (افتراضي 300 ثانية) — يمنع التوسع المتكرر السريع (flapping).
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| ALB | موازن التطبيقات | طبقة 7 — توجيه حسب المسار والمحتوى مع مصادقة مدمجة. |
| NLB | موازن الشبكة | طبقة 4 — أداء فائق بملايين الطلبات وعنوان IP ثابت. |
| Target Group | مجموعة الهدف | مجموعة من الأهداف (مثيلات) يتوزع عليها الحمل. |
| Health Check | فحص الصحة | اختبار دوري لاستجابة الأهداف — المعطوبة تُستبعد تلقائياً. |
| Sticky Sessions | جلسات لاصقة | توجيه المستخدم لنفس الهدف طوال الجلسة. |
1️⃣ Elastic Load Balancing (ELB)
📖 Elastic Load Balancing يوزع حركة المرور الواردة تلقائياً بين عدة أهداف (مثيلات، حاويات، عناوين IP) لضمان عدم إرهاق هدف واحد وتجنب الأهداف المعطوبة.
ثلاثة أنواع من موازنات الحمل تلبي احتياجات مختلفة من الطبقة 4 إلى الطبقة 7.
📋 أنواع موازنات الحمل
ثلاثة أنواع من موازنات الحمل تلبي احتياجات مختلفة من الطبقة 4 إلى الطبقة 7.
- Application Load Balancer (ALB): الطبقة 7 (HTTP/HTTPS) — يفهم محتوى الطلبات. يدعم التوجيه حسب المسار (/api → مجموعة، /images → أخرى) أو hostname أو headers. مثالي لتطبيقات الويب وAPIs والخدمات المصغرة.
- Network Load Balancer (NLB): الطبقة 4 (TCP/UDP/TLS) — أسرع وأعلى أداءً (ملايين الطلبات في الثانية). يحتفظ بعنوان IP المصدر الأصلي. مثالي لتطبيقات الوقت الفعلي والألعاب وIoT.
- Gateway Load Balancer (GWLB): يوزع حركة المرور إلى أجهزة افتراضية طرف ثالث (جدران حماية، أنظمة كشف التسلل). مثالي لنشر وتوسيع أجهزة الأمان الافتراضية.
منصة خدمات مصغرة (Microservices) تستخدم ALB لتوجيه ذكي.
ALB أمام 3 مجموعات مستهدفة:.
/api/users/* → مجموعة مثيلات خدمة المستخدمين.
/api/orders/* → مجموعة مثيلات خدمة الطلبات.
/api/products/* → مجموعة مثيلات خدمة المنتجات.
كل خدمة لها ASG مستقل يتوسع حسب حملها الخاص — خدمة الطلبات قد تحتاج 20 مثيلاً بينما خدمة المنتجات تحتاج 3 فقط.
ALB واحد أمام الجميع — توجيه ذكي، اكتشاف صحة كل مجموعة مستقلة، وتوزيع حمل مثالي.
ALB أمام 3 مجموعات مستهدفة:.
/api/users/* → مجموعة مثيلات خدمة المستخدمين.
/api/orders/* → مجموعة مثيلات خدمة الطلبات.
/api/products/* → مجموعة مثيلات خدمة المنتجات.
كل خدمة لها ASG مستقل يتوسع حسب حملها الخاص — خدمة الطلبات قد تحتاج 20 مثيلاً بينما خدمة المنتجات تحتاج 3 فقط.
ALB واحد أمام الجميع — توجيه ذكي، اكتشاف صحة كل مجموعة مستقلة، وتوزيع حمل مثالي.
2️⃣ مقارنة ALB وNLB
| المعيار | Application Load Balancer (ALB) | Network Load Balancer (NLB) |
|---|---|---|
| الطبقة | Layer 7 (HTTP/HTTPS) | Layer 4 (TCP/UDP/TLS) |
| التوجيه | حسب المسار، hostname، headers، query strings | حسب IP ومنفذ فقط |
| الأداء | عالٍ (~100K RPS) | فائق (~ملايين RPS) |
| IP ثابت | لا (يتغير — استخدم NLB أمامه أو AWS Global Accelerator) | نعم — IP ثابت لكل AZ |
| زمن الوصول | ~1-3ms إضافية | ~100µs إضافية |
| WebSockets | مدعوم | مدعوم (TCP) |
| المصادقة | يدعم مصادقة Cognito وOIDC مباشرة | لا يدعم |
| حالات الاستخدام | تطبيقات الويب، REST APIs، خدمات مصغرة | تطبيقات الوقت الفعلي، ألعاب، IoT، TCP |
3️⃣ ميزات متقدمة في ALB
📖 ALB يقدم ميزات متقدمة تتجاوز مجرد توزيع الحمل — توجيه ذكي، مصادقة، واستجابات ثابتة مدمجة.
هذه الميزات تقلل الحاجة لخوادم وسيطة وتجعل ALB بوابة ذكية وليس مجرد موزع حمل.
📋 ميزات ALB المتقدمة
هذه الميزات تقلل الحاجة لخوادم وسيطة وتجعل ALB بوابة ذكية وليس مجرد موزع حمل.
- التوجيه حسب المحتوى (Content-Based Routing): يوجه الطلبات بناءً على المسار (/api، /images)، أو hostname (api.example.com)، أو headers، أو query strings.
- المصادقة المدمجة (Built-in Authentication): ALB يمكنه مصادقة المستخدمين عبر Cognito أو OIDC قبل أن تصل الطلبات للتطبيق — يوفر طبقة مصادقة بدون كود.
- الاستجابات الثابتة (Fixed Responses): ALB يرد مباشرة برسائل HTTP محددة (مثلاً 503 Service Unavailable) دون إرسال الطلب للتطبيق.
- إعادة التوجيه (Redirects): يحول HTTP إلى HTTPS تلقائياً على مستوى ALB — لا حاجة لإعداد ذلك في التطبيق.
- تسجيل الطلبات (Access Logs): يسجل كل طلب إلى S3 للتحليل والتدقيق — يعرف من زار تطبيقك ومتى ومن أين.
ALB واحد يدير 4 مهام في آن واحد لتطبيق ويب:.
1. يحول كل HTTP إلى HTTPS تلقائياً (redirect 301).
2. يصادق المستخدمين عبر Cognito — إذا لم يسجل دخوله، يحوله لصفحة تسجيل الدخول.
3. يوجه /api/* إلى خوادم التطبيق ويوجه /static/* إلى خوادم المحتوى الثابت.
4. إذا كانت كل الخوادم معطوبة، يرد مباشرة بـ 503 مع رسالة "سنعود قريباً".
كل هذا بدون سطر كود واحد في التطبيق.
1. يحول كل HTTP إلى HTTPS تلقائياً (redirect 301).
2. يصادق المستخدمين عبر Cognito — إذا لم يسجل دخوله، يحوله لصفحة تسجيل الدخول.
3. يوجه /api/* إلى خوادم التطبيق ويوجه /static/* إلى خوادم المحتوى الثابت.
4. إذا كانت كل الخوادم معطوبة، يرد مباشرة بـ 503 مع رسالة "سنعود قريباً".
كل هذا بدون سطر كود واحد في التطبيق.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| ALB | موازن التطبيقات | موازن طبقة 7 — توجيه حسب المسار والمحتوى مع مصادقة مدمجة. |
| NLB | موازن الشبكة | موازن طبقة 4 — أداء فائق بملايين الطلبات في الثانية وعنوان IP ثابت. |
| GWLB | موازن البوابة | يوزع حركة المرور إلى أجهزة افتراضية طرف ثالث مثل جدران الحماية. |
| Target Group | مجموعة الهدف | مجموعة من الأهداف (مثيلات أو حاويات) يتوزع عليها الحمل حسب قواعد محددة. |
| Content-Based Routing | التوجيه حسب المحتوى | توجيه الطلبات بناءً على المسار أو اسم النطاق أو الترويسات. |
| Health Check | فحص الصحة | اختبار دوري لاستجابة الأهداف — المعطوبة تُستبعد تلقائياً من التوزيع. |
1️⃣ توسيع Amazon Aurora
📖 Amazon Aurora توفر ثلاث آليات للتوسع: توسيع رأسي (تغيير فئة المثيل)، توسيع أفقي (Aurora Auto Scaling للنسخ المتماثلة)، وAurora Serverless (وحدات ACU تتوسع تلقائياً بالثواني).
Aurora تجمع بين أداء قواعد البيانات التجارية ومرونة وبساطة قواعد البيانات مفتوحة المصدر — مع توسع تلقائي كامل.
📋 آليات توسيع Aurora
Aurora تجمع بين أداء قواعد البيانات التجارية ومرونة وبساطة قواعد البيانات مفتوحة المصدر — مع توسع تلقائي كامل.
- التوسع الرأسي (Vertical Scaling): تغيير فئة مثيل Aurora DB إلى فئة أكبر أو أصغر. تتطلب إعادة تشغيل المثيل وتستغرق 15 دقيقة أو أكثر.
- التوسع الأفقي (Aurora Auto Scaling): يضبط عدد نسخ Aurora المتماثلة (Aurora Replicas — مثيلات قارئ فقط) تلقائياً حسب مقاييس CloudWatch. تحدد حداً أدنى وأقصى في سياسة التوسع.
- Aurora Serverless: تعمل بوحدات حوسبة Aurora (ACUs). تحدد الحد الأدنى والأقصى لـ ACU وتتوسع تلقائياً في ثوانٍ. التخزين يُدار بالكامل من AWS — تدفع فقط مقابل السعة المستخدمة.
منصة تحليلات تستخدم Aurora للتقارير اليومية.
في الأيام العادية: Aurora Serverless يعمل بين 2-8 ACU. حمل الاستعلامات خفيف — يعمل عند 2 ACU معظم الوقت.
نهاية الشهر: قسم المالية يشغل تقارير ثقيلة — Aurora Serverless يتوسع تلقائياً إلى 8 ACU خلال 30 ثانية.
بعد التقارير: يعود إلى 2 ACU — تكلفة يوم التقرير الثقيل = 3 أضعاف اليوم العادي فقط (وليس 24 ساعة كاملة بطاقة قصوى).
في الأيام العادية: Aurora Serverless يعمل بين 2-8 ACU. حمل الاستعلامات خفيف — يعمل عند 2 ACU معظم الوقت.
نهاية الشهر: قسم المالية يشغل تقارير ثقيلة — Aurora Serverless يتوسع تلقائياً إلى 8 ACU خلال 30 ثانية.
بعد التقارير: يعود إلى 2 ACU — تكلفة يوم التقرير الثقيل = 3 أضعاف اليوم العادي فقط (وليس 24 ساعة كاملة بطاقة قصوى).
2️⃣ توسيع Amazon RDS
📖 Amazon RDS يدعم التوسع الرأسي عبر تغيير فئة المثيل، والتوسع الأفقي عبر النسخ المتماثلة للقراءة (Read Replicas)، بالإضافة إلى التوسع التلقائي للتخزين.
على عكس Aurora، النسخ المتماثلة في RDS للقراءة فقط ولا يمكن ترقيتها إلى أساسي تلقائياً.
📋 آليات توسيع RDS
على عكس Aurora، النسخ المتماثلة في RDS للقراءة فقط ولا يمكن ترقيتها إلى أساسي تلقائياً.
- التوسع الرأسي: تغيير فئة مثيل DB (مثلاً من db.t3.medium إلى db.r6g.large). يتطلب إعادة تشغيل قصيرة.
- RDS Storage Auto Scaling: يزيد سعة التخزين تلقائياً عندما تنخفض المساحة الحرة دون حد أقصى. يفحص كل 5 دقائق — إذا قلت المساحة الحرة عن 10%، يضيف تلقائياً. لا حاجة لإيقاف قاعدة البيانات.
- التوسع الأفقي (Read Replicas): إنشاء نسخ متماثلة للقراءة (حتى 15 نسخة) لتوزيع حمل القراءة. النسخ المتماثلة للقراءة فقط ولا تُرقى تلقائياً.
تطبيق ويب مرتفع القراءة يستخدم RDS PostgreSQL.
الأساسي: db.r6g.xlarge في AZ-a — يستقبل الكتابة وبعض القراءة.
3 نسخ متماثلة للقراءة موزعة عبر 3 AZs. RDS Storage Auto Scaling: مثيل بحجم 500 GB — عندما تصل المساحة الحرة إلى 50 GB، يضيف RDS تلقائياً 50 GB إضافية.
إذا زاد حمل الكتابة: يعدّل الفريق فئة الأساسي إلى db.r6g.2xlarge — إعادة تشغيل مدتها دقيقتان أثناء نافذة الصيانة.
الأساسي: db.r6g.xlarge في AZ-a — يستقبل الكتابة وبعض القراءة.
3 نسخ متماثلة للقراءة موزعة عبر 3 AZs. RDS Storage Auto Scaling: مثيل بحجم 500 GB — عندما تصل المساحة الحرة إلى 50 GB، يضيف RDS تلقائياً 50 GB إضافية.
إذا زاد حمل الكتابة: يعدّل الفريق فئة الأساسي إلى db.r6g.2xlarge — إعادة تشغيل مدتها دقيقتان أثناء نافذة الصيانة.
3️⃣ توسيع Amazon DynamoDB
📖 DynamoDB تقدم نموذجين للتوسع: On-Demand (ادفع لكل طلب — لا تخطيط للسعة) وProvisioned مع Application Auto Scaling (تحدد السعة الدنيا والقصوى ويتولى التوسع التلقائي).
المفاتيح الثانوية العالمية (GSIs) لها سعتها المستقلة التي يمكن توسيعها مستقلة عن الجدول الأساسي.
📋 آليات توسيع DynamoDB
المفاتيح الثانوية العالمية (GSIs) لها سعتها المستقلة التي يمكن توسيعها مستقلة عن الجدول الأساسي.
- وضع On-Demand: تدفع مقابل كل طلب قراءة وكتابة فعلي — لا حاجة لتخطيط السعة. DynamoDB تتوسع تلقائياً مع زيادة الطلبات دون أي إعدادات.
- وضع Provisioned مع Application Auto Scaling: تحدد الحد الأدنى والأقصى لوحدات السعة (RCUs/WCUs). Application Auto Scaling يضبط السعة تلقائياً بناءً على نسبة الاستخدام المستهدفة.
- الجداول العالمية (Global Tables): توسيع جغرافي — ينسخ الجدول تلقائياً عبر عدة مناطق AWS. أي منطقة يمكنها القراءة والكتابة محلياً مع تزامن تلقائي.
| المعيار | Amazon Aurora | Aurora Serverless | Amazon RDS | Amazon DynamoDB |
|---|---|---|---|---|
| النطاق | عنقود (Cluster) | عنقود (Cluster) | قاعدة بيانات (Database) | جدول (Table) |
| التوسع الرأسي | تغيير فئة مثيل DB | تعديل نطاق ACU — تلقائي بالثواني | تغيير فئة مثيل DB | لا ينطبق — السعة بالمقاييس (RCU/WCU) |
| التوسع الأفقي | Aurora Auto Scaling للنسخ المتماثلة | ACUs تتوسع تلقائياً | Read Replicas يدوية (حتى 15) | Application Auto Scaling للجدول وكل GSI |
| توسيع التخزين المُدار | تخزين مشترك ينمو تلقائياً حتى 128 TB | مثل Aurora — تخزين مشترك مُدار | RDS Storage Auto Scaling | لا حدود تخزين عملياً |
توسيع قواعد البيانات مثل إدارة مطاعم مختلفة.
Aurora مثل مطعم فاخر بمطبخ مركزي: يمكنك إضافة طهاة مساعدين (النسخ المتماثلة) يجهزون الأطباق الباردة (القراءة) بينما الشيف الرئيسي يركز على الساخنة (الكتابة).
Aurora Serverless مثل مطعم آلي بالكامل: ينشط مواقد أكثر تلقائياً (ACUs) عندما يزداد الزبائن ويطفئها عندما يقلون — تدفع فقط على المواقد المشغلة.
DynamoDB مثل مطعم وجبات سريعة حديث: أماكن الجلوس (RCU/WCU) تتوسع وتتقلص تلقائياً — وإذا ازدحم المكان، النظام يفتح مناطق جلوس جديدة (GSIs مستقلة) دون إشعارك.
Aurora مثل مطعم فاخر بمطبخ مركزي: يمكنك إضافة طهاة مساعدين (النسخ المتماثلة) يجهزون الأطباق الباردة (القراءة) بينما الشيف الرئيسي يركز على الساخنة (الكتابة).
Aurora Serverless مثل مطعم آلي بالكامل: ينشط مواقد أكثر تلقائياً (ACUs) عندما يزداد الزبائن ويطفئها عندما يقلون — تدفع فقط على المواقد المشغلة.
DynamoDB مثل مطعم وجبات سريعة حديث: أماكن الجلوس (RCU/WCU) تتوسع وتتقلص تلقائياً — وإذا ازدحم المكان، النظام يفتح مناطق جلوس جديدة (GSIs مستقلة) دون إشعارك.
📌 خلاصة توسيع قواعد البيانات:
Aurora تقدم التوسع الأكثر أتمتة — Auto Scaling للنسخ المتماثلة وAurora Serverless للتوسع الفوري بالثواني.
RDS يمنحك تحكماً تقليدياً مع Storage Auto Scaling وRead Replicas (حتى 15).
DynamoDB تلغي مفهوم الخوادم — On-Demand للأحمال غير المتوقعة وProvisioned + Auto Scaling للأحمال المتوقعة بتكلفة أقل.
القاعدة الذهبية: ابدأ بـ On-Demand أو Aurora Serverless عندما لا تعرف نمط الحمل — وعندما تستقر التوقعات، انتقل إلى Provisioned مع Auto Scaling لتوفير التكلفة.
Aurora تقدم التوسع الأكثر أتمتة — Auto Scaling للنسخ المتماثلة وAurora Serverless للتوسع الفوري بالثواني.
RDS يمنحك تحكماً تقليدياً مع Storage Auto Scaling وRead Replicas (حتى 15).
DynamoDB تلغي مفهوم الخوادم — On-Demand للأحمال غير المتوقعة وProvisioned + Auto Scaling للأحمال المتوقعة بتكلفة أقل.
القاعدة الذهبية: ابدأ بـ On-Demand أو Aurora Serverless عندما لا تعرف نمط الحمل — وعندما تستقر التوقعات، انتقل إلى Provisioned مع Auto Scaling لتوفير التكلفة.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| ACU | وحدة حوسبة Aurora | وحدة قياس السعة في Aurora Serverless — تجمع vCPU وذاكرة وتتوسع تلقائياً. |
| Aurora Replica | نسخة Aurora متماثلة | مثيل قارئ فقط في عنقود Aurora — يوزع حمل القراءة ويدعم Auto Scaling التلقائي. |
| Read Replica | نسخة قراءة متماثلة | نسخة للقراءة فقط من قاعدة بيانات RDS — توزع حمل القراءة ولا تُرقى تلقائياً. |
| RCU / WCU | وحدات سعة القراءة / الكتابة | وحدة قياس السعة في DynamoDB — RCU لقراءة 4 KB/ثانية، WCU لكتابة 1 KB/ثانية. |
| Storage Auto Scaling | توسيع التخزين التلقائي | زيادة سعة تخزين RDS تلقائياً عند نقص المساحة الحرة دون توقف. |
1️⃣ Amazon CloudWatch
📖 Amazon CloudWatch هو خدمة المراقبة والملاحظة المركزية في AWS — يجمع المقاييس (Metrics) والسجلات (Logs) والأحداث (Events) وينشئ لوحات تحكم وتنبيهات.
يشبه "غرفة التحكم" لعملياتك السحابية — من مكان واحد ترى كل شيء وتتصرف قبل أن يتأثر المستخدمون.
📋 مكونات CloudWatch
يشبه "غرفة التحكم" لعملياتك السحابية — من مكان واحد ترى كل شيء وتتصرف قبل أن يتأثر المستخدمون.
- CloudWatch Metrics: مقاييس رقمية — CPU Utilization، Network In/Out، Disk Read/Write، RequestCount... خدمات AWS ترسل مقاييسها تلقائياً كل 5 دقائق (أو دقيقة مع Detailed Monitoring).
- CloudWatch Logs: مستودع مركزي للسجلات — تطبيقاتك وخدمات AWS ترسل سجلاتها هنا. يمكن البحث والتصفية والتحليل.
- CloudWatch Alarms: تنبيهات تُطلق إجراءً عندما يتجاوز مقياس حداً معيناً — مثلاً إذا تجاوزت CPU 80%، أرسل إشعاراً أو نفذ Auto Scaling.
- CloudWatch Dashboards: لوحات تحكم مخصصة تعرض مقاييس متعددة في مكان واحد — تشاهد صحة نظامك كاملاً في لمحة.
- CloudWatch Synthetics: اختبارات مراقبة مستمرة (Canaries) — تحاكي سلوك المستخدم وتنبهك إذا تعطل مسار حرج (مثل تسجيل الدخول أو الدفع).
فريق عمليات يدير منصة SaaS بـ 50 خدمة مصغرة.
Dashboard مخصصة في CloudWatch تعرض:.
الصف العلوي: عدد المستخدمين النشطين، متوسط زمن الاستجابة، نسبة الأخطاء (4xx/5xx).
الصف الأوسط: CPU وMemory لكل خدمة (10 مقاييس).
الصف السفلي: عدد رسائل SQS المتراكمة، اتصالات RDS النشطة، وحجم بيانات S3.
Alarms: إذا زادت نسبة الأخطاء عن 1% ← إنذار للمهندس المناوب. إذا قفزت رسائل SQS المتراكمة عن 1,000 ← توسيع ASG للمستهلكين تلقائياً.
Synthetics: كل 5 دقائق، Canary يحاكي مستخدم يسجل دخوله ويشتري منتجاً — إذا فشل الاختبار 3 مرات، إنذار فوري.
Dashboard مخصصة في CloudWatch تعرض:.
الصف العلوي: عدد المستخدمين النشطين، متوسط زمن الاستجابة، نسبة الأخطاء (4xx/5xx).
الصف الأوسط: CPU وMemory لكل خدمة (10 مقاييس).
الصف السفلي: عدد رسائل SQS المتراكمة، اتصالات RDS النشطة، وحجم بيانات S3.
Alarms: إذا زادت نسبة الأخطاء عن 1% ← إنذار للمهندس المناوب. إذا قفزت رسائل SQS المتراكمة عن 1,000 ← توسيع ASG للمستهلكين تلقائياً.
Synthetics: كل 5 دقائق، Canary يحاكي مستخدم يسجل دخوله ويشتري منتجاً — إذا فشل الاختبار 3 مرات، إنذار فوري.
2️⃣ مقاييس مخصصة وسجلات موحدة
📖 بالإضافة للمقاييس التلقائية من AWS، يمكنك إرسال مقاييسك المخصصة (Custom Metrics) — مثلاً عدد المستخدمين المسجلين دخولهم، عدد العربات المهملة، أرباح الساعة الأخيرة.
المقاييس المخصصة تعطيك رؤية خاصة بعملك لا توفرها المقاييس التقنية وحدها.
📋 السجلات الموحدة (Unified CloudWatch Agent)
المقاييس المخصصة تعطيك رؤية خاصة بعملك لا توفرها المقاييس التقنية وحدها.
- وكيل CloudWatch الموحد يُثبت على مثيلات EC2 والخوادم المحلية — يجمع مقاييس إضافية (استخدام الذاكرة، مساحة القرص) وسجلات التطبيق.
- يرسل السجلات مباشرة إلى CloudWatch Logs مع إمكانية تصفيتها وتوجيهها إلى وجهات متعددة (S3، Lambda، Kinesis، ElasticSearch).
- Logs Insights: لغة استعلام قوية لتحليل السجلات — ابحث عن أخطاء، احسب متوسط زمن استجابة، اكتشف أنماطاً غير عادية.
استعلام في CloudWatch Logs Insights يكشف مشكلة أداء:.
يظهر أن الأخطاء تقفز كل ساعة عند الدقيقة 00 — تحقيق سريع يكشف أن وظيفة Cron تسحب بيانات ضخمة من قاعدة البيانات كل ساعة وتسبب أخطاء timeout.
الفريق يصلح الوظيفة — CloudWatch يؤكد أن الأخطاء اختفت في الساعات التالية. تم اكتشاف المشكلة وإصلاحها في 15 دقيقة بفضل السجلات المركزية.
filter @message like /ERROR/ | stats count(*) by bin(5m)يظهر أن الأخطاء تقفز كل ساعة عند الدقيقة 00 — تحقيق سريع يكشف أن وظيفة Cron تسحب بيانات ضخمة من قاعدة البيانات كل ساعة وتسبب أخطاء timeout.
الفريق يصلح الوظيفة — CloudWatch يؤكد أن الأخطاء اختفت في الساعات التالية. تم اكتشاف المشكلة وإصلاحها في 15 دقيقة بفضل السجلات المركزية.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Metric | مقياس | قيمة رقمية تراقبها CloudWatch مثل CPU Utilization. |
| CloudWatch Logs | سجلات CloudWatch | مستودع مركزي لسجلات التطبيقات وخدمات AWS. |
| CloudWatch Alarm | إنذار CloudWatch | تنبيه يُطلق إجراءً عندما يتجاوز مقياس حداً. |
| Dashboard | لوحة القيادة | عرض مرئي مخصص لمقاييس متعددة في مكان واحد. |
| Synthetics | Canary | اختبار يحاكي سلوك المستخدم وينبه عند فشل مسار حرج. |
1️⃣ Amazon EventBridge — ناقل الأحداث الخادم-less
📖 Amazon EventBridge هو ناقل أحداث (Event Bus) خادم-less يربط التطبيقات معاً باستخدام الأحداث — يستقبل أحداثاً من مصادر متنوعة (خدمات AWS، تطبيقات SaaS، تطبيقات مخصصة) ويوجهها إلى أهداف (Lambda، SQS، SNS، Step Functions، وغيرها).
EventBridge يمكّن البنى المبنية على الأحداث (Event-Driven Architectures) حيث تتفاعل المكونات بشكل غير مباشر عبر الأحداث بدلاً من الاستدعاءات المباشرة — مما يحقق ترابطاً فضفاضاً (Loose Coupling).
📋 مكونات EventBridge الأساسية
EventBridge يمكّن البنى المبنية على الأحداث (Event-Driven Architectures) حيث تتفاعل المكونات بشكل غير مباشر عبر الأحداث بدلاً من الاستدعاءات المباشرة — مما يحقق ترابطاً فضفاضاً (Loose Coupling).
- نواقل الأحداث (Event Buses): الناقل الافتراضي (Default) يستقبل الأحداث من خدمات AWS تلقائياً. الناقل المخصص (Custom) لتطبيقاتك الخاصة. ناقل الشريك (Partner) لتطبيقات SaaS مثل Zendesk وDatadog.
- الأحداث (Events): كائنات JSON تصف تغييراً في حالة مورد أو نظام. كل حدث له مصدر (source) ونوع (detail-type) وحقل بيانات (detail).
- القواعد (Rules): تطابق الأحداث الواردة بناءً على أنماط (Event Patterns) وتوجهها إلى هدف واحد أو أكثر. يمكن أن تستجيب قاعدة واحدة لعدة أنماط أحداث مختلفة.
- جدولة EventBridge (Scheduler): تنشئ وتدير المهام المجدولة على نطاق واسع. تدعم جداول لمرة واحدة أو متكررة باستخدام تعابير cron أو rate. يمكنه استدعاء 270+ خدمة AWS مباشرة دون كود Lambda وسيط.
منصة حجز طيران تستخدم EventBridge لتنسيق الخدمات.
عندما يحجز مسافر تذكرة: خدمة الحجز تنشر حدث "TicketBooked" إلى EventBridge.
القاعدة 1: ترسل الحدث إلى Lambda يرسل تأكيداً بالبريد الإلكتروني للمسافر.
القاعدة 2: ترسل الحدث إلى Lambda آخر يحدث برنامج الولاء (يضيف أميالاً).
القاعدة 3: ترسل الحدث إلى SQS لطابور يُعالج الفوترة لاحقاً.
النتيجة: خدمة الحجز لا تعرف شيئاً عن البريد أو الولاء أو الفوترة — فقط تنشر حدثاً وتمضي.
عندما يحجز مسافر تذكرة: خدمة الحجز تنشر حدث "TicketBooked" إلى EventBridge.
القاعدة 1: ترسل الحدث إلى Lambda يرسل تأكيداً بالبريد الإلكتروني للمسافر.
القاعدة 2: ترسل الحدث إلى Lambda آخر يحدث برنامج الولاء (يضيف أميالاً).
القاعدة 3: ترسل الحدث إلى SQS لطابور يُعالج الفوترة لاحقاً.
النتيجة: خدمة الحجز لا تعرف شيئاً عن البريد أو الولاء أو الفوترة — فقط تنشر حدثاً وتمضي.
2️⃣ EventBridge مقابل SQS وSNS — متى تستخدم ماذا؟
📖 الثلاثة خدمات تكامل ولكن بأغراض مختلفة: EventBridge = موجه ذكي (Intelligent Router)، SQS = طابور انتظار (Buffer Queue)، SNS = إشعارات دفع (Push Notification).
اختيار الخدمة المناسبة يعتمد على نمط التواصل: هل تحتاج توجيهاً بناءً على محتوى الحدث؟ هل تحتاج طابوراً لامتصاص الضغط؟ هل تحتاج نشراً واسعاً لعدة مشتركين؟
اختيار الخدمة المناسبة يعتمد على نمط التواصل: هل تحتاج توجيهاً بناءً على محتوى الحدث؟ هل تحتاج طابوراً لامتصاص الضغط؟ هل تحتاج نشراً واسعاً لعدة مشتركين؟
| المعيار | Amazon EventBridge | Amazon SQS | Amazon SNS |
|---|---|---|---|
| النمط | موجه ذكي — توجيه حسب محتوى الحدث | طابور رسائل — تخزين لحين الاستهلاك | نشر/اشتراك — إرسال لعدة مشتركين |
| التوجيه | Pattern Matching — يطابق حقول JSON | لا توجيه — كل المستهلكين يرون الرسائل | تصفية حسب سمات الرسالة — بسيطة |
| استمرارية الرسالة | الأحداث تمر فقط — Archive اختياري | تخزين حتى 14 يوماً | لا تخزين — إذا لم يوجد مشترك، تضيع الرسالة |
| حالات الاستخدام | تفاعل خدمات متعددة مع نفس الحدث — بنى الأحداث | معالجة غير متزامنة — فصل المنتِج عن المستهلك | إشعارات جماعية — تنبيهات |
نظام معالجة طلبات يجمع EventBridge + SQS + SNS معاً.
1. تطبيق الويب ينشر حدث "NewOrder" إلى EventBridge.
2. EventBridge يوجه الحدث حسب المحتوى: طلبات أقل من $100 → SQS "معالجة عادية". طلبات أكثر من $100 → SQS "معالجة ممتازة".
3. المستهلكون (EC2 في ASG) يسحبون من طوابير SQS حسب الأولوية.
4. عند اكتمال الطلب: خدمة المعالجة تنشر إلى SNS Topic "OrderCompleted".
5. SNS يرسل: SMS للعميل + بريداً إلكترونياً للإيصال + تحديثاً لنظام المحاسبة. كل خدمة استُخدمت لما صُممت له.
1. تطبيق الويب ينشر حدث "NewOrder" إلى EventBridge.
2. EventBridge يوجه الحدث حسب المحتوى: طلبات أقل من $100 → SQS "معالجة عادية". طلبات أكثر من $100 → SQS "معالجة ممتازة".
3. المستهلكون (EC2 في ASG) يسحبون من طوابير SQS حسب الأولوية.
4. عند اكتمال الطلب: خدمة المعالجة تنشر إلى SNS Topic "OrderCompleted".
5. SNS يرسل: SMS للعميل + بريداً إلكترونياً للإيصال + تحديثاً لنظام المحاسبة. كل خدمة استُخدمت لما صُممت له.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| EventBridge | جسر الأحداث | ناقل أحداث خادم-less يربط التطبيقات عبر أنماط أحداث — موجه ذكي. |
| Event Bus | ناقل الأحداث | قناة تستقبل الأحداث من مصادر وتوصلها للقواعد — افتراضي، مخصص، أو شريك. |
| Event Pattern | نمط الحدث | قاعدة تطابق JSON تحدد أي الأحداث تلتقطها القاعدة بناءً على محتواها. |
| Scheduler | المجدول | ينشئ ويدير مهام cron/rate على نطاق واسع — استدعاء مباشر لأكثر من 270 خدمة AWS. |
| SQS | خدمة الطوابير البسيطة | طابور رسائل — يخزن ويصطف الرسائل لحين استهلاكها. |
| SNS | خدمة الإشعارات البسيطة | نشر/اشتراك — تنشر رسالة إلى عدة مشتركين (fan-out). |
1️⃣ AWS CloudTrail
📖 AWS CloudTrail يسجل كل استدعاء API في حساب AWS — من فعل ماذا ومتى ومن أين وبأي نتيجة.
إذا كان CloudWatch يراقب صحة النظام، فـ CloudTrail يسجل من لمس النظام — وهما معاً يوفران المراقبة الكاملة.
📋 مكونات CloudTrail
إذا كان CloudWatch يراقب صحة النظام، فـ CloudTrail يسجل من لمس النظام — وهما معاً يوفران المراقبة الكاملة.
- أحداث الإدارة (Management Events): كل عمليات إدارة الموارد — إنشاء/حذف/تعديل أي شيء في AWS (CreateVPC، RunInstances، DeleteBucket...). مفعل افتراضياً ومجاني.
- أحداث البيانات (Data Events): عمليات على مستوى البيانات — قراءة/كتابة كائنات S3 (GetObject/PutObject) واستدعاءات Lambda. اختيارية ومدفوعة.
- رؤى CloudTrail (CloudTrail Insights): تحليل آلي لاكتشاف الأنشطة غير العادية — مثلاً اكتشاف أن حساباً بدأ فجأة يطلق 50 مثيلاً EC2 بينما عادة يطلق 2.
- السجلات تُخزن في S3 ويمكن تحليلها بـ Athena أو توجيهها إلى SIEM.
حادثة أمنية في شركة: اكتشفوا أن بيانات حساسة نُشرت في S3 bucket عام.
يفتحون CloudTrail ويستعلمون: من عدّل سياسة الـ bucket في آخر 24 ساعة؟.
CloudTrail يظهر: user "ahmed" قام بـ PutBucketPolicy عند 3:14 صباحاً من IP خارجي 203.0.113.50 (وليس من شبكة المكتب).
استنتاج: حساب ahmed اختُرق. يلغون صلاحياته فوراً ويستعيدون bucket policy الأصلية.
كل هذا في 5 دقائق بفضل CloudTrail — لولاه، لربما لم يكتشفوا الاختراق لأيام.
يفتحون CloudTrail ويستعلمون: من عدّل سياسة الـ bucket في آخر 24 ساعة؟.
CloudTrail يظهر: user "ahmed" قام بـ PutBucketPolicy عند 3:14 صباحاً من IP خارجي 203.0.113.50 (وليس من شبكة المكتب).
استنتاج: حساب ahmed اختُرق. يلغون صلاحياته فوراً ويستعيدون bucket policy الأصلية.
كل هذا في 5 دقائق بفضل CloudTrail — لولاه، لربما لم يكتشفوا الاختراق لأيام.
🔑 أفضل ممارسات CloudTrail:
فعّل CloudTrail في كل الحسابات وكل المناطق — ليس فقط في الحساب الرئيسي.
وجّه السجلات إلى S3 bucket مركزي في حساب أمان منفصل — لا يمكن للمخترق حذف سجلاته إذا وصل لحساب الإنتاج.
فعّل CloudTrail Insights لاكتشاف الأنشطة غير العادية تلقائياً.
استخدم AWS Athena للاستعلام عن سجلات CloudTrail مباشرة من S3 دون الحاجة لنقلها.
فعّل CloudTrail في كل الحسابات وكل المناطق — ليس فقط في الحساب الرئيسي.
وجّه السجلات إلى S3 bucket مركزي في حساب أمان منفصل — لا يمكن للمخترق حذف سجلاته إذا وصل لحساب الإنتاج.
فعّل CloudTrail Insights لاكتشاف الأنشطة غير العادية تلقائياً.
استخدم AWS Athena للاستعلام عن سجلات CloudTrail مباشرة من S3 دون الحاجة لنقلها.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Management Events | أحداث الإدارة | تسجيل عمليات إدارة الموارد مثل إنشاء وحذف وتعديل — مفعل افتراضياً ومجاني. |
| Data Events | أحداث البيانات | تسجيل عمليات على مستوى البيانات مثل قراءة وكتابة كائنات S3 — اختياري ومدفوع. |
| CloudTrail Insights | رؤى CloudTrail | تحليل آلي لاكتشاف الأنشطة غير العادية مثل الارتفاع المفاجئ في استخدام الموارد. |
| CloudTrail | سجل التدقيق السحابي | خدمة تسجل كل استدعاء API في حساب AWS للتدقيق الأمني والامتثال. |
| Athena | أثينا | خدمة استعلام تفاعلية لتحليل سجلات CloudTrail المخزنة في S3 باستخدام SQL. |
1️⃣ Amazon Route 53
📖 Amazon Route 53 هو خدمة DNS عالية التوفر وقابلة للتوسع — تترجم أسماء النطاقات إلى عناوين IP وتدعم توجيهاً متقدماً لتحسين الأداء والتوفر.
Route 53 ليس مجرد DNS — إنه طبقة توجيه ذكية تدعم failover وgeolocation وlatency-based routing وweighted routing.
📋 ميزات Route 53
Route 53 ليس مجرد DNS — إنه طبقة توجيه ذكية تدعم failover وgeolocation وlatency-based routing وweighted routing.
- تسجيل النطاقات: يمكنك شراء وإدارة أسماء النطاقات مباشرة من Route 53 — .com, .net, .org, وأكثر من 300 امتداد.
- استضافة DNS: تخزين سجلات DNS (A, CNAME, MX, TXT...) مع دعـم كامل لـ IPv4 وIPv6.
- فحوصات الصحة (Health Checks): مراقبة صحة نقاط النهاية — إذا فشلت، Route 53 يوجه الحركة تلقائياً إلى نقطة نهاية بديلة.
- سياسات التوجيه (Routing Policies): 7 أنواع من التوجيه لتلبية احتياجات مختلفة.
2️⃣ سياسات التوجيه السبعة
📖 Route 53 يقدم سبع سياسات توجيه تمنحك تحكماً كاملاً في كيفية وصول المستخدمين إلى تطبيقك.
كل سياسة تناسب حالة استخدام محددة — من التوزيع الجغرافي إلى تجارب A/B إلى التعافي من الكوارث.
📋 سياسات التوجيه
كل سياسة تناسب حالة استخدام محددة — من التوزيع الجغرافي إلى تجارب A/B إلى التعافي من الكوارث.
- Simple Routing: توجيه مباشر — اسم النطاق يشير إلى عنوان IP واحد أو عدة عناوين (يُختار عشوائياً). لا يدعم فحوصات الصحة.
- Failover Routing: توجيه بين أساسي (primary) واحتياطي (secondary) — إذا فشل الأساسي (فحص الصحة)، يتحول للاحتياطي. مثالي للتعافي من الكوارث.
- Geolocation Routing: توجيه حسب الموقع الجغرافي للمستخدم — المستخدمون في أوروبا يذهبون لخوادم أوروبا، وفي آسيا لخوادم آسيا. مثالي لتوطين المحتوى والامتثال القانوني.
- Geoproximity Routing: مثل Geolocation لكن مع إمكانية تحويل نسبة من الحركة من منطقة لأخرى عبر "bias" — تحكم أكثر دقة.
- Latency-Based Routing: توجيه إلى المنطقة الأقل زمن وصول للمستخدم — الأفضل أداءً تلقائياً. مثالي لتحسين سرعة التطبيق عالمياً.
- Weighted Routing: توزيع الحركة بنسب محددة — 80% للإصدار A و20% للإصدار B. مثالي لاختبارات A/B والترقيات التدريجية.
- Multi-Value Answer Routing: إرجاع عدة نقاط نهاية سليمة (حسب فحص الصحة) ويختار العميل إحداها. يشبه Simple لكن مع فحوصات صحة.
تطبيق عالمي يستخدم 3 سياسات توجيه معاً.
Geoproximity: المستخدم في السعودية يوجه إلى خوادم البحرين (منطقة AWS الأقرب).
في نفس المنطقة: Weighted Routing يوزع 90% من المستخدمين على الإصدار الحالي و10% على الإصدار الجديد لاختباره تدريجياً.
Failover: إذا تعطل الإصدار الأساسي في البحرين، يتحول تلقائياً إلى المنطقة الاحتياطية في فرانكفورت.
النتيجة: مستخدم سعودي يصل للإصدار الجديد في البحرين خلال 20ms — وإذا تعطلت المنطقة، يتحول لفرانكفورت خلال 60 ثانية دون أن يلاحظ المستخدم شيئاً.
Geoproximity: المستخدم في السعودية يوجه إلى خوادم البحرين (منطقة AWS الأقرب).
في نفس المنطقة: Weighted Routing يوزع 90% من المستخدمين على الإصدار الحالي و10% على الإصدار الجديد لاختباره تدريجياً.
Failover: إذا تعطل الإصدار الأساسي في البحرين، يتحول تلقائياً إلى المنطقة الاحتياطية في فرانكفورت.
النتيجة: مستخدم سعودي يصل للإصدار الجديد في البحرين خلال 20ms — وإذا تعطلت المنطقة، يتحول لفرانكفورت خلال 60 ثانية دون أن يلاحظ المستخدم شيئاً.
3️⃣ فحوصات الصحة (Health Checks)
📖 فحوصات Route 53 الصحية تراقب نقاط النهاية وتحدد ما إذا كانت سليمة أم لا — أساس سياسات Failover وMulti-Value.
ثلاثة أنواع من الفحوصات تغطي احتياجات المراقبة المختلفة.
📋 أنواع فحوصات الصحة
ثلاثة أنواع من الفحوصات تغطي احتياجات المراقبة المختلفة.
- فحص نقطة نهاية (Endpoint Check): Route 53 يرسل طلبات HTTP/HTTPS/TCP إلى عنوان IP أو اسم نطاق — إذا استجاب بنجاح، النقطة سليمة.
- فحص CloudWatch Alarm: يرتبط بإنذار CloudWatch — إذا اشتعل الإنذار (مثلاً CPU > 90%)، اعتبر النقطة غير سليمة.
- الفحص المحسوب (Calculated Check): يجمع نتائج عدة فحوصات فرعية — مثلاً اعتبر الخدمة سليمة فقط إذا 3 من 4 فحوصات فرعية نجحت.
تطبيق مالي حساس لا يحتمل التوقف.
ينشئ Calculated Health Check يراقب 3 أشياء:.
1. فحص HTTP لصفحة /health (التطبيق يستجيب؟).
2. فحص TCP لمنفذ قاعدة البيانات (قاعدة البيانات تستمع؟).
3. CloudWatch Alarm على metric "عدد الطلبات الفاشلة" (أقل من 1%).
إذا فشل أي فحصين من الثلاثة: Route 53 يحول فوراً إلى منطقة AWS أخرى.
هذا يمنع التحويل الخاطئ بسبب فحص واحد فشل مؤقتاً — دقة وموثوقية أعلى.
ينشئ Calculated Health Check يراقب 3 أشياء:.
1. فحص HTTP لصفحة /health (التطبيق يستجيب؟).
2. فحص TCP لمنفذ قاعدة البيانات (قاعدة البيانات تستمع؟).
3. CloudWatch Alarm على metric "عدد الطلبات الفاشلة" (أقل من 1%).
إذا فشل أي فحصين من الثلاثة: Route 53 يحول فوراً إلى منطقة AWS أخرى.
هذا يمنع التحويل الخاطئ بسبب فحص واحد فشل مؤقتاً — دقة وموثوقية أعلى.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Hosted Zone | منطقة مستضافة | حاوية لسجلات DNS الخاصة بنطاقك. |
| Failover Routing | توجيه التعافي | توجيه بين أساسي واحتياطي حسب فحص الصحة. |
| Latency Routing | توجيه زمن الوصول | توجيه المستخدم لأقرب منطقة بأقل زمن استجابة. |
| Weighted Routing | التوجيه الموزون | توزيع الحركة بنسب محددة — مثالي لاختبار A/B. |
| Geolocation Routing | التوجيه الجغرافي | توجيه حسب موقع المستخدم الجغرافي. |
1️⃣ أنماط التوفر العالي
📖 التوفر العالي يتحقق عبر القضاء على نقاط الفشل المفردة (Single Points of Failure) في كل طبقة من طبقات البنية.
لا توجد "وصفة سحرية" واحدة — التوفر العالي هو مجموع ممارسات في الحوسبة والشبكة والتخزين وقاعدة البيانات.
📋 أنماط التصميم للتوفر العالي
لا توجد "وصفة سحرية" واحدة — التوفر العالي هو مجموع ممارسات في الحوسبة والشبكة والتخزين وقاعدة البيانات.
- Active-Passive: موقع أساسي يستقبل كل الحركة، وموقع احتياطي خامل ينتظر. عند فشل الأساسي، يفعل الاحتياطي (عادة يدوياً أو عبر Route 53 Failover). أبسط وأرخص لكن وقت التعافي أطول.
- Active-Active: موقعان أو أكثر يستقبلان الحركة معاً — Route 53 أو Global Accelerator يوزعان بينهم. عند فشل أحدهما، الآخر يمتص الحمل. أغلى لكن وقت تعافي = صفر.
- التكرار في كل الطبقات: مثيلات في AZs متعددة + RDS Multi-AZ + ALB أمام الجميع + Route 53 Failover بين المناطق = تطبيق ينجو من فشل مثيل أو AZ أو حتى منطقة كاملة.
بنية Active-Active بين منطقتين AWS لتطبيق بنكي.
المنطقة A في فرانكفورت (أساسية): 6 مثيلات، RDS Multi-AZ، DynamoDB Global Tables.
المنطقة B في أيرلندا (أساسية أيضاً): 6 مثيلات، Read Replica من RDS (قابلة للترقية)، نفس DynamoDB Global Tables.
Route 53 Latency-Based Routing يوزع المستخدمين: أوروبا الشرقية → فرانكفورت، أوروبا الغربية → أيرلندا.
إذا تعطلت فرانكفورت: Route 53 يوجه الجميع إلى أيرلندا — Read Replica تُرقى إلى أساسي في 3 دقائق — التطبيق يعمل بكامل طاقته.
زمن التعافي: 3 دقائق. فقدان بيانات: صفر (DynamoDB Global Tables تزامن لحظي).
المنطقة A في فرانكفورت (أساسية): 6 مثيلات، RDS Multi-AZ، DynamoDB Global Tables.
المنطقة B في أيرلندا (أساسية أيضاً): 6 مثيلات، Read Replica من RDS (قابلة للترقية)، نفس DynamoDB Global Tables.
Route 53 Latency-Based Routing يوزع المستخدمين: أوروبا الشرقية → فرانكفورت، أوروبا الغربية → أيرلندا.
إذا تعطلت فرانكفورت: Route 53 يوجه الجميع إلى أيرلندا — Read Replica تُرقى إلى أساسي في 3 دقائق — التطبيق يعمل بكامل طاقته.
زمن التعافي: 3 دقائق. فقدان بيانات: صفر (DynamoDB Global Tables تزامن لحظي).
2️⃣ Architected على المرونة والمراقبة
📖 ركيزة الموثوقية (Reliability) في Well-Architected تركز على قدرة النظام على العمل بشكل صحيح ومستمر حتى في ظل فشل المكونات.
مع ركيزة التميز التشغيلي (Operational Excellence) التي تركز على المراقبة والاستجابة الآلية.
📋 تطبيق الركائز على المرونة والتوفر
مع ركيزة التميز التشغيلي (Operational Excellence) التي تركز على المراقبة والاستجابة الآلية.
- التميز التشغيلي: لوحات CloudWatch Dashboards شاملة، CloudTrail في كل مكان، أتمتة الاستجابة للحوادث عبر Lambda + CloudWatch Alarms، توثيق إجراءات التشغيل القياسية (Runbooks).
- الأمان: ALB مع مصادقة Cognito، ACM لشهادات TLS، CloudTrail للتدقيق، Security Groups مقيدة على كل طبقة.
- الموثوقية: Auto Scaling لاستبدال المثيلات الفاشلة، ALB/NLB لتجنب المثيلات المعطوبة، Multi-AZ لكل الخدمات، Route 53 Failover للتعافي من الكوارث، نسخ احتياطي منتظم ومختبر.
- كفاءة الأداء: اختيار نوع ELB المناسب (ALB للتطبيقات، NLB للأداء الفائق)، Target Tracking Scaling للاستجابة السريعة، Latency-Based Routing للتوجيه الأمثل، CloudFront للتخزين المؤقت.
- تحسين التكلفة: Scheduled Scaling للأحمال المتوقعة، Spot Instances في ASG لتقليل التكلفة 70-90%، Reserved Instances للحمل الأساسي، حذف مثيلات الليل تلقائياً عبر Scheduled Scaling.
- الاستدامة: تقليل عدد المثيلات الزائدة (تقليل استهلاك الطاقة)، اختيار مناطق AWS الخضراء، استخدام ARM (Graviton) الأقل استهلاكاً للطاقة.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Auto Scaling | التوسع التلقائي | إضافة وإزالة موارد الحوسبة تلقائياً حسب الطلب الفعلي. |
| Launch Template | قالب الإطلاق | يحدد مواصفات المثيل الجديد المستخدم في Auto Scaling. |
| ASG | مجموعة التوسع التلقائي | تحتوي على المثيلات وتديرها بحدود min/max/desired. |
| ELB | موازن الحمل المرن | يوزع حركة المرور بين عدة أهداف ويكتشف المعطوبة منها. |
| ALB | موازن التطبيقات | موازن طبقة 7 مع توجيه حسب المحتوى ومصادقة مدمجة. |
| NLB | موازن الشبكة | موازن طبقة 4 بأداء فائق وعنوان IP ثابت. |
| CloudWatch | مراقبة السحابة | خدمة المراقبة المركزية — مقاييس، سجلات، إنذارات، لوحات. |
| CloudWatch Alarms | إنذارات CloudWatch | تنبيهات تنطلق عند تجاوز مقياس حداً — تطلق إجراءات آلية. |
| CloudTrail | سجل التدقيق السحابي | يسجل كل استدعاء API في حساب AWS للتدقيق والتحليل. |
| Route 53 | الطريق 53 | خدمة DNS عالية التوفر مع توجيه متقدم وفحوصات صحة. |
| Failover Routing | توجيه التعافي | سياسة توجيه تحول الحركة لموقع احتياطي عند فشل الأساسي. |
1️⃣ AWS Cost Explorer
📖 ما هو Cost Explorer؟
AWS Cost Explorer أداة تحليلية تتيح لك تصور وفهم وإدارة تكاليف AWS واستخدامك عبر الزمن، مع إمكانية عرض البيانات على مستوى يومي أو شهري.
📋 قدرات Cost Explorer:
AWS Cost Explorer أداة تحليلية تتيح لك تصور وفهم وإدارة تكاليف AWS واستخدامك عبر الزمن، مع إمكانية عرض البيانات على مستوى يومي أو شهري.
- عرض التكاليف حسب الخدمة، الحساب، المنطقة، العلامات (tags)، والمزيد.
- تصفية وتجميع البيانات لتحليل مفصل للتكاليف.
- توقعات التكلفة المستقبلية بناءً على أنماط الاستخدام التاريخية (حتى 12 شهراً).
- حفظ التقارير المخصصة ومشاركتها مع الفريق.
- تحديد الاتجاهات غير الطبيعية في الإنفاق.
- متاح عبر واجهة المستخدم وAPI.
مدير مالي في شركة يلاحظ ارتفاعاً مفاجئاً في فاتورة AWS بنسبة 40% عن الشهر الماضي.
يستخدم Cost Explorer لتصفية التكاليف حسب الخدمة، فيكتشف أن التكلفة الإضافية كلها من EC2 في منطقة us-west-2.
يكتشف أن فريق التطوير نسي إيقاف 10 مثيلات اختبار كبيرة بعد انتهاء مشروع تجريبي. يوفر إيقافها $3,200 شهرياً.
يستخدم Cost Explorer لتصفية التكاليف حسب الخدمة، فيكتشف أن التكلفة الإضافية كلها من EC2 في منطقة us-west-2.
يكتشف أن فريق التطوير نسي إيقاف 10 مثيلات اختبار كبيرة بعد انتهاء مشروع تجريبي. يوفر إيقافها $3,200 شهرياً.
2️⃣ AWS Budgets
📖 ما هي AWS Budgets؟
AWS Budgets تتيح لك وضع حدود للإنفاق وإرسال تنبيهات عند تجاوزها أو توقع تجاوزها، مما يمنع المفاجآت في نهاية الشهر.
📋 أنواع الميزانيات:
AWS Budgets تتيح لك وضع حدود للإنفاق وإرسال تنبيهات عند تجاوزها أو توقع تجاوزها، مما يمنع المفاجآت في نهاية الشهر.
- ميزانية التكلفة (Cost budget): تنبيه عند تجاوز حد إنفاق معين.
- ميزانية الاستخدام (Usage budget): تنبيه عند تجاوز حد استخدام خدمة معينة (مثلاً عدد ساعات EC2).
- ميزانية الحجز (Reservation budget): تنبيه عند انخفاض نسبة تغطية Reserved Instances أو Savings Plans عن حد معين.
- ميزانية Savings Plans: تنبيه عند انخفاض نسبة التغطية أو الاستخدام الفعلي للخطط المدخرة.
فريق مالي يضع ميزانية شهرية قدرها $5,000 لحساب التطوير.
يُعيّن تنبيهاً عند 80% ($4,000) لإشعار مدير الفريق، وتنبيهاً عند 100% لإشعار المدير المالي.
في الأسبوع الثالث، يصل التنبيه الأول — يراجع الفريق المصاريف ويخفض بعض الموارد غير الضرورية قبل تجاوز الميزانية.
يُعيّن تنبيهاً عند 80% ($4,000) لإشعار مدير الفريق، وتنبيهاً عند 100% لإشعار المدير المالي.
في الأسبوع الثالث، يصل التنبيه الأول — يراجع الفريق المصاريف ويخفض بعض الموارد غير الضرورية قبل تجاوز الميزانية.
3️⃣ AWS Cost and Usage Report (CUR)
📖 ما هو تقرير التكلفة والاستخدام؟
AWS Cost and Usage Report (CUR) هو التقرير الأكثر تفصيلاً لتكاليف AWS، يُسلم يومياً إلى حاوية Amazon S3 ببيانات على مستوى الموارد الفردية.
📋 خصائص CUR:
AWS Cost and Usage Report (CUR) هو التقرير الأكثر تفصيلاً لتكاليف AWS، يُسلم يومياً إلى حاوية Amazon S3 ببيانات على مستوى الموارد الفردية.
- بيانات على مستوى كل مورد فردي (كل مثيل EC2، كل حاوية S3).
- تفصيل بالساعة أو اليوم لكل خدمة ولكل عملية.
- يمكن تحليله باستخدام Amazon Athena أو Amazon QuickSight أو Amazon Redshift.
- يدعم تصدير البيانات إلى Amazon S3 بصيغة Parquet أو CSV لسهولة التحليل.
- يشمل معلومات العلامات (tags) لتتبع التكاليف حسب القسم أو المشروع.
مؤسسة كبيرة تدير 500 مثيل EC2 عبر 10 فرق.
تصدّر CUR يومياً إلى S3 وتحلله مع Amazon Athena لإنشاء تقارير Per-Team و Per-Project.
تكتشف أن فريق التسويق ينفق 3 أضعاف الفرق الأخرى بسبب استخدام مثيلات كبيرة لحمل عمل بسيط.
بعد التوصية بمثيلات أصغر، تنخفض تكاليف الفريق بنسبة 65%.
تصدّر CUR يومياً إلى S3 وتحلله مع Amazon Athena لإنشاء تقارير Per-Team و Per-Project.
تكتشف أن فريق التسويق ينفق 3 أضعاف الفرق الأخرى بسبب استخدام مثيلات كبيرة لحمل عمل بسيط.
بعد التوصية بمثيلات أصغر، تنخفض تكاليف الفريق بنسبة 65%.
🔑 نصيحة أساسية: اجمع بين الأدوات الثلاث: Cost Explorer للمراقبة اليومية السريعة، Budgets للتنبيهات التلقائية، وCUR للتحليل العميق الشهري. هذا التكامل يمنع المفاجآت ويمنحك رؤية كاملة لتكاليف السحابة.
✅ خلاصة: مراقبة التكاليف
- Cost Explorer: تحليل بصري للتكاليف الحالية والتاريخية مع توقعات مستقبلية.
- AWS Budgets: تنبيهات تلقائية عند تجاوز حدود الإنفاق أو توقع تجاوزها.
- CUR: تقرير مفصل يومي على مستوى الموارد الفردية يُحلل بـ Athena/QuickSight.
- تكامل الأدوات الثلاث يمنح رؤية كاملة: مراقبة + تنبيه + تحليل.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Cost Explorer | مستكشف التكاليف | أداة AWS لتحليل وتصور التكاليف والاستخدام عبر الزمن. |
| AWS Budgets | ميزانيات AWS | خدمة لوضع حدود إنفاق وإرسال تنبيهات عند تجاوزها. |
| CUR | تقرير التكلفة والاستخدام | التقرير الأكثر تفصيلاً لتكاليف AWS على مستوى الموارد الفردية. |
| Parquet | صيغة Parquet | صيغة ملفات عمودية فعالة لتخزين وتحليل البيانات الكبيرة. |
| Athena | Amazon Athena | خدمة استعلام تفاعلية لتحليل البيانات المخزنة في S3 باستخدام SQL. |
1️⃣ AWS Auto Scaling
📖 ما هو AWS Auto Scaling؟
AWS Auto Scaling هو خدمة موحدة تمكنك من إنشاء خطط توسع (scaling plans) تشمل مجموعة من الموارد المتعددة — ليس فقط مثيلات EC2، بل يشمل أيضاً قواعد البيانات وخدمات التطبيقات الأخرى.
📋 الخدمات المدعومة:
AWS Auto Scaling هو خدمة موحدة تمكنك من إنشاء خطط توسع (scaling plans) تشمل مجموعة من الموارد المتعددة — ليس فقط مثيلات EC2، بل يشمل أيضاً قواعد البيانات وخدمات التطبيقات الأخرى.
- Amazon EC2 Auto Scaling groups — المثيلات ومجموعات التوسع.
- Amazon ECS — خدمات الحاويات.
- Amazon DynamoDB — قدرة القراءة والكتابة للجداول والمؤشرات الثانوية.
- Aurora — عدد النسخ المتماثلة (read replicas).
- Amazon SageMaker — نقاط نهاية نماذج التعلم الآلي.
- Lambda — التزامن المحجوز (provisioned concurrency).
- ElastiCache — عدد عقد الـ Redis.
تطبيق توصيل طعام يستخدم Scaling Plan موحداً.
عند زيادة الطلبات: EC2 Auto Scaling يضيف خوادم ويب، DynamoDB Auto Scaling يرفع قدرة القراءة/الكتابة، وECS يضيف حاويات لمعالجة الطلبات.
خطة توسع واحدة تدير جميع الموارد بتناغم — لا حاجة لإعدادات منفصلة لكل خدمة.
عند زيادة الطلبات: EC2 Auto Scaling يضيف خوادم ويب، DynamoDB Auto Scaling يرفع قدرة القراءة/الكتابة، وECS يضيف حاويات لمعالجة الطلبات.
خطة توسع واحدة تدير جميع الموارد بتناغم — لا حاجة لإعدادات منفصلة لكل خدمة.
2️⃣ سياسات التوسع التفصيلية
📖 كيف تعمل سياسات التوسع؟
سياسات التوسع تعتمد على مقاييس CloudWatch وتعريف حدود (thresholds) مع استجابات محددة، وأكثر أنواعها دقة هي Step Scaling التي تستجيب بنسب مختلفة حسب حجم التغير في المقياس.
📋 مثال سياسة Step Scaling لاستخدام CPU:
سياسات التوسع تعتمد على مقاييس CloudWatch وتعريف حدود (thresholds) مع استجابات محددة، وأكثر أنواعها دقة هي Step Scaling التي تستجيب بنسب مختلفة حسب حجم التغير في المقياس.
- أقل من 30%: حذف 30% من المثيلات (تقليص).
- 30% إلى 39%: حذف 10% من المثيلات (تقليص طفيف).
- 40% إلى 60%: لا تغيير (المنطقة المثالية).
- 61% إلى 70%: إضافة 10% من المثيلات (توسع طفيف).
- أعلى من 70%: إضافة 30% من المثيلات (توسع سريع).
منصة فيديو حسب الطلب تلاحظ أن استخدام CPU يرتفع تدريجياً من 40% إلى 65% مع زيادة المشاهدين مساءً.
Step Scaling تضيف مثيلاً واحداً (10% من 10 مثيلات) عند تجاوز 60%، مما يخفض CPU إلى 45% قبل أن يصل لأي مستوى خطر.
لو قفز CPU فجأة إلى 85% (هجوم DDoS مثلاً)، السياسة تضيف 3 مثيلات فوراً للتعامل مع الضغط.
Step Scaling تضيف مثيلاً واحداً (10% من 10 مثيلات) عند تجاوز 60%، مما يخفض CPU إلى 45% قبل أن يصل لأي مستوى خطر.
لو قفز CPU فجأة إلى 85% (هجوم DDoS مثلاً)، السياسة تضيف 3 مثيلات فوراً للتعامل مع الضغط.
3️⃣ نموذج uptime والتوفر العالي
📖 ما هي مستويات التوفر (uptime)؟
التوفر يُقاس بنسبة مئوية سنوية، وكل "تسعة" إضافية تعني وقت توقف أقل بكثير. فهم هذه النسب يساعدك في تصميم بنية تلبي متطلبات العمل.
📋 جدول مستويات التوفر:
التوفر يُقاس بنسبة مئوية سنوية، وكل "تسعة" إضافية تعني وقت توقف أقل بكثير. فهم هذه النسب يساعدك في تصميم بنية تلبي متطلبات العمل.
- 99% (تسعتان): توقف مسموح 3.65 يوم سنوياً (~7.2 ساعة شهرياً).
- 99.9% (ثلاث تسعات): توقف مسموح 8.76 ساعة سنوياً (~43.8 دقيقة شهرياً).
- 99.95%: توقف مسموح 4.38 ساعة سنوياً (~21.9 دقيقة شهرياً).
- 99.99% (أربع تسعات): توقف مسموح 52.56 دقيقة سنوياً (~4.38 دقيقة شهرياً).
- 99.999% (خمس تسعات): توقف مسموح 5.26 دقيقة سنوياً (~26.3 ثانية شهرياً).
تطبيق مصرفي يحتاج توفر 99.99% (أربع تسعات) — أي توقف أقصى 52 دقيقة سنوياً.
لتحقيق ذلك: ينشر التطبيق على 3 AZs مع Auto Scaling وMulti-AZ RDS وALB.
كل طبقة مصممة لتحمل فشل AZ كامل دون انقطاع الخدمة، مما يضمن تحقيق الأربع تسعات.
لتحقيق ذلك: ينشر التطبيق على 3 AZs مع Auto Scaling وMulti-AZ RDS وALB.
كل طبقة مصممة لتحمل فشل AZ كامل دون انقطاع الخدمة، مما يضمن تحقيق الأربع تسعات.
🔑 نصيحة أساسية: كل "تسعة" إضافية من التوفر تزيد التكلفة بشكل كبير (أضعاف). لا تصمم لتوفر 99.999% إذا كان تطبيقك يحتاج فقط 99.9%. اسأل صاحب العمل: "كم دقيقة توقف يمكن أن يتحملها تطبيقك سنوياً؟" وصمم بناءً على الإجابة.
مثل المصعد في ناطحة سحاب: مصعد واحد (99%) يكفي لمبنى صغير، أما ناطحة السحاب فتحتاج 4 مصاعد مع أنظمة طوارئ (99.99%). كلما زادت أهمية الخدمة، زادت الحاجة للتكرار والموارد الاحتياطية.
✅ خلاصة: Auto Scaling والتوفر العالي
- AWS Auto Scaling يدير خطط توسع موحدة تشمل EC2 وECS وDynamoDB وAurora وغيرها.
- Step Scaling يستجيب بنسب مختلفة حسب حجم التغير في المقياس (توسع تدريجي).
- مستويات التوفر من 99% إلى 99.999% — كل تسعة إضافية تضاعف التكلفة.
- صمم مستوى التوفر بناءً على احتياجات العمل الفعلية، ليس الأعلى لمجرد أنه متاح.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Scaling Plan | خطة التوسع | مجموعة تعليمات تحدد كيف ومتى تتوسع مجموعة من موارد AWS معاً. |
| Step Scaling | التوسع التدريجي | سياسة توسع تستجيب بنسب مختلفة بناءً على حجم تجاوز الحدود المعرفة. |
| Uptime | وقت التشغيل | النسبة المئوية للوقت الذي تكون فيه الخدمة متاحة ومستجيبة. |
| Provisioned Concurrency | التزامن المحجوز | ميزة في Lambda تضمن جاهزية عدد محدد من النسخ للاستجابة دون تأخير البدء البارد. |
| Five Nines | خمس تسعات | مستوى توفر 99.999% يعني توقف أقصى 5.26 دقيقة سنوياً. |
🚀 الخاتمة
في هذه الوحدة تعلمنا أن المرونة والتوفر العالي والمراقبة هم الركائز الثلاث التي تحول بنيتك من "خوادم في السحابة" إلى "تطبيق سحابي حقيقي" يتكيف مع الظروف وينجو من الفشل.
استكشفنا EC2 Auto Scaling بمكوناته الثلاثة: قالب الإطلاق، مجموعة ASG، وسياسات التوسع (Target Tracking وStep Scaling وScheduled Scaling) التي تضمن العدد الأمثل من المثيلات في كل لحظة.
تعمقنا في أنواع Elastic Load Balancing الثلاثة: ALB (طبقة 7، توجيه ذكي حسب المحتوى، مصادقة مدمجة)، NLB (طبقة 4، أداء فائق بملايين الطلبات)، وGWLB (للأجهزة الافتراضية).
تعلمنا Amazon CloudWatch كمركز قيادة موحد: Metrics للمقاييس، Logs للسجلات، Alarms للتنبيهات، Dashboards للوحات، وSynthetics للمراقبة الاستباقية.
استعرضنا AWS CloudTrail لتسجيل كل حدث API — التدقيق الكامل لكل ما يحدث في حسابك.
تعمقنا في Amazon Route 53 وسياسات التوجيه السبع من Simple إلى Geoproximity وFailover — وكيف تحول فحوصات الصحة DNS من خدمة أسماء بسيطة إلى طبقة توجيه ذكية.
استعرضنا أنماط التوفر العالي: Active-Passive للبساطة، Active-Active لصفر وقت تعافي، والتكرار في كل الطبقات.
وأخيراً، طبقنا ركائز Well-Architected — خصوصاً الموثوقية والتميز التشغيلي — لضمان تطبيق يراقب نفسه ويصلح نفسه ويتوسع تلقائياً.
تذكر: لا تنتظر الفشل لتستعد له — صمم بنيتك بحيث تفشل فيها المكونات دون أن يفشل النظام ككل.