الجزء 6 من سلسلة تعلّم AWS من الصفر

توزيع الحمل: كيف تخلي موقعك ما يوقف

الفرق بين التوسّع والتوفر العالي، وكيف يوزّع موزّع الحمل الزوار على عدة سيرفرات ويتجنب المعطّل منها، وأنواع ALB وNLB وGWLB، مع تطبيق عملي تشوف فيه التوزيع بعينك.

في هذا المقال
  1. التوسّع والتوفر العالي
  2. وش يسوي موزّع الحمل؟
  3. أنواع موزّعات الحمل
  4. فحص الصحة
  5. مجموعات الأمان الصحيحة
  6. HTTPS والشهادات
  7. إعدادات تحتاج تعرفها
  8. عملي: شوف التوزيع بعينك
  9. الخلاصة
  10. اختبر نفسك

إلى الآن كل تجاربنا كانت بسيرفر واحد. وهذا فيه مشكلتين: لو تعطّل وقف موقعك كله، ولو زاد الزوار ما يقدر يخدمهم. هذا القسم يحل المشكلتين، ونبدأ بالقطعة الأساسية: موزّع الحمل.

التوسّع والتوفر العالي

مصطلحين يتكررون كثير، وكثير يخلطون بينهم:

المفهوم معناه مثال
التوسّع العمودي سيرفر أقوى من t3.micro إلى m7i.xlarge
التوسّع الأفقي سيرفرات أكثر من سيرفر إلى خمسة
التوفر العالي التطبيق يعيش في أكثر من مكان، فيتحمل تعطّل واحد منها سيرفرات في منطقتي توفر

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

وش يسوي موزّع الحمل؟

موزّع الحمل (Load Balancer) يستقبل كل الطلبات، ويمررها للسيرفرات اللي خلفه. وفي AWS خدمته ELB (Elastic Load Balancing)، وهي مُدارة بالكامل: AWS تتكفّل بتشغيلها وتوسيعها وتوفرها.

اللي يعطيك إياه:

  • نقطة دخول واحدة: اسم نطاق واحد مهما تغيّرت السيرفرات خلفه.
  • فحص صحة: يكتشف السيرفر المعطّل ويوقف الإرسال له.
  • توزيع على مناطق التوفر: فتعطّل منطقة ما يوقف التطبيق.
  • إنهاء التشفير (TLS): يتكفّل بشهادة HTTPS بدل كل سيرفر.
  • عزل السيرفرات: تصير سيرفراتك غير مكشوفة مباشرة للإنترنت.

أنواع موزّعات الحمل

النوع يعمل على تختاره لما
ALB (Application) HTTP وHTTPS مواقع وAPIs، وتبي توجيه حسب المسار أو النطاق. الخيار الافتراضي
NLB (Network) TCP وUDP وTLS تحتاج أداء عالي جداً وتأخير قليل، أو عنوان IP ثابت
GWLB (Gateway) حزم الشبكة (IP) تمرير الحركة عبر أجهزة أمان من شركات ثانية، مثل جدران الحماية

وفيه نوع قديم اسمه Classic Load Balancer، لا تستخدمه في أي مشروع جديد.

كيف يوجّه ALB الطلبات

ALB يفهم محتوى الطلب، وهذا اللي يميزه. يتكوّن من:

  • Listener: يستقبل على منفذ معين، مثل 443.
  • Rules: قواعد توجيه حسب المسار (/api/*)، أو النطاق (shop.example.com)، أو الترويسات.
  • Target Group: مجموعة الأهداف اللي تستقبل الطلب: سيرفرات EC2، أو حاويات، أو دوال Lambda، أو عناوين IP.

فتقدر تخلي example.com/api يروح لخدمة، وexample.com/images لخدمة ثانية، بموزّع واحد.

فحص الصحة

كل فترة، الموزّع يرسل طلب لكل هدف على مسار تحدده، مثل /health. إذا ما رد بالنجاح عدة مرات متتالية، يعتبره معطّل ويوقف الإرسال له، ولما يتعافى يرجع له تلقائياً.

اجعل مسار الفحص خفيف، بس يعبّر عن حالة التطبيق فعلياً. وصفحة ثابتة ترجع 200 حتى لو قاعدة البيانات واقفة، ما تكشف لك المشكلة.

مجموعات الأمان الصحيحة

هذا النمط لازم تحفظه، لأنه يتكرر في كل تطبيق: السيرفرات ما تقبل إلا من الموزّع.

الزوار موزّع الحمل ALB يقبل 443 من الجميع منطقة توفر A سيرفر 1 يقبل من الموزّع فقط منطقة توفر B سيرفر 2 يقبل من الموزّع فقط
الزوار يصلون للموزّع فقط، والسيرفرات في منطقتي توفر تقبل الطلبات من مجموعة أمان الموزّع وحده.
مجموعة الأمان القاعدة الداخلة المصدر
الموزّع 80 و443 أي مكان (0.0.0.0/0)
السيرفرات 80 مجموعة أمان الموزّع

بهذا ما يقدر أحد يوصل للسيرفر مباشرة ويتجاوز الموزّع، حتى لو عرف عنوانه.

HTTPS والشهادات

تربط شهادة TLS بالموزّع، والأسهل من AWS Certificate Manager، اللي يصدر الشهادات العامة مجاناً ويجددها تلقائياً. فيستقبل الموزّع الطلب مشفّر، ويتولى فك التشفير بدل كل سيرفر. وعادةً تضيف قاعدة تحوّل كل HTTP إلى HTTPS.

وتقدر تستضيف عدة نطاقات بشهادات مختلفة على موزّع واحد، بفضل تقنية SNI اللي تخبر الموزّع أي نطاق يطلبه المتصفح.

إعدادات تحتاج تعرفها

  • الجلسات اللاصقة (Sticky Sessions): تخلي نفس الزائر يرجع لنفس السيرفر عبر كوكي. مفيدة لو الجلسة محفوظة في السيرفر، لكنها تخل بالتوزيع. والأفضل تخزن الجلسات خارج السيرفر، وهذا بنوصله في قسم قواعد البيانات.
  • التوزيع عبر المناطق (Cross-Zone): يوزّع الطلبات بالتساوي على كل السيرفرات مهما كانت منطقة توفرها. مفعّل افتراضياً في ALB وبدون رسوم نقل، ومعطّل في NLB وGWLB.
  • مهلة التفريغ (Deregistration Delay): لما تشيل سيرفر، يوقف الموزّع إرسال طلبات جديدة له، ويعطي الطلبات الحالية وقت تكمل، وهو 300 ثانية افتراضياً. وقلّلها إذا طلباتك قصيرة.

عملي: شوف التوزيع بعينك

بنشغّل سيرفرين في منطقتي توفر مختلفتين، ونضع قدامهم ALB.

  1. السيرفرات: شغّل سيرفرين بنفس خطوات الجزء الثالث ونفس User Data، واختر لكل واحد منطقة توفر مختلفة. الصفحة تعرض اسم السيرفر، وهذا اللي بنستفيد منه.
  2. Target Group: من EC2 افتح Target Groups ثم Create target group. اختر Instances وHTTP على المنفذ 80، وخل مسار الفحص /، وسجّل السيرفرين.
  3. مجموعة أمان الموزّع: أنشئ مجموعة تسمح بـ HTTP من أي مكان.
  4. الموزّع: من Load Balancers اختر Application Load Balancer بنوع Internet-facing، وحدد منطقتي التوفر، واربط مجموعة الأمان، وخل الـ Listener على 80 يوجّه للـ Target Group.
  5. السيرفرات: عدّل مجموعة أمانها، وخل HTTP يقبل من مجموعة أمان الموزّع فقط.

انتظر لين تصير حالة الأهداف healthy، وانسخ DNS name من صفحة الموزّع:

Bash
# كرر الطلب وشوف اسم السيرفر يتبدّل
for i in 1 2 3 4 5 6; do
  curl -s http://اسم-الموزع-هنا
  echo
done

بتشوف اسمين يتناوبون. الحين جرّب الأهم: أوقف واحد من السيرفرين وكرر الأمر. بعد ما يكتشف فحص الصحة العطل، كل الطلبات تروح للسيرفر الباقي، والموقع ما وقف. هذا هو التوفر العالي.

وجرّب كمان تفتح عنوان IP السيرفر مباشرة في المتصفح: الطلب يعلّق ويطلع Timeout، لأن مجموعة الأمان ما تقبل إلا من الموزّع.

الخلاصة

  • التوسّع الأفقي عبر مناطق توفر متعددة يعطيك القدرة والحماية مع بعض.
  • ALB هو الخيار الافتراضي للويب، وNLB للأداء العالي وعنوان IP الثابت، وGWLB لأجهزة الأمان.
  • فحص الصحة يبعد السيرفر المعطّل تلقائياً.
  • خل السيرفرات تقبل من مجموعة أمان الموزّع فقط.
  • الشهادات من ACM مجانية وتتجدد تلقائياً.

اختبر نفسك

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

السؤال 1 من 5

شركة تشغّل المسارين /api و/images كخدمتين منفصلتين، وتبيهم خلف نطاق واحد عبر HTTPS. أي حل يحقق هذا بأقل جهد تشغيلي؟

اعرض الجواب

الجواب الصحيح: B

ALB يفهم محتوى طلبات HTTP، فمستمع واحد يقدر يرسل كل مسار لـ Target Group خاص فيه.

  • A: NLB يشتغل على الاتصالات، وما يقرأ مسار الطلب.
  • C: هذا لتمرير البيانات عبر أجهزة الأمان.
  • D: هذا نوع قديم، ويقسم الخدمة على نطاقين.

للمراجعة: كيف يوجه ALB الطلبات في هذا الجزء، وComparing load balancer types في موقع AWS.

السؤال 2 من 5

سيرفر لعبة جماعية يتواصل عبر UDP بزمن استجابة منخفض جداً. وبعض شبكات اللاعبين تسمح بالخروج لعناوين IP ثابتة محددة مسبقاً فقط. أي موزع حمل يناسب؟

اعرض الجواب

الجواب الصحيح: D

NLB يدعم UDP ويعطي عنوان IP ثابت في كل منطقة توفر، وتقدر تربط به عناوين Elastic IP حقتك.

  • A: ALB لـ HTTP وHTTPS، وعناوينه مو ثابتة.
  • B: هذا يمرر البيانات عبر أجهزة الأمان، وما يخدم تطبيق مباشرة.
  • C: هذا نوع قديم، وما ينستخدم لأي شي جديد.

للمراجعة: أنواع موزعات الحمل في هذا الجزء، وElastic Load Balancing features في موقع AWS.

السؤال 3 من 5

سيرفرات خلف Application Load Balancer، بس تدقيق كشف إن أي أحد يعرف عنوان IP العام لسيرفر يقدر يفتح الموقع مباشرة. كيف تقفل هذا؟

اعرض الجواب

الجواب الصحيح: A

لما يكون مصدر قاعدة السيرفرات هو Security Group حق موزع الحمل، الطلبات اللي تجي من طريق ثاني ما تعدي، حتى لو كان العنوان معروف.

  • B: فحص الصحة يراقب السيرفرات، وما يتحكم في مين يوصلها.
  • C: هذا يبقي الزائر على سيرفر واحد، وما له علاقة بالوصول المباشر.
  • D: قواعد Security Group تسمح فقط، فما فيه قاعدة منع تضيفها.

للمراجعة: مجموعات الأمان الصحيحة في هذا الجزء، وSecurity groups for your Application Load Balancer في وثائق AWS.

السؤال 4 من 5

بعد ما انتقل تطبيق خلف Application Load Balancer، صارت سجلاته تبين كم عنوان خاص لكل الزوار. يحتاج فريق الأمن عنوان IP الحقيقي لكل زائر، بأصغر تغيير. وش يسوي الفريق؟

اعرض الجواب

الجواب الصحيح: C

السيرفر يشوف عنوان موزع الحمل، لأن الاتصال جاي منه. وALB يمرر عنوان الزائر الحقيقي في هذا الهيدر.

  • A: الطلبات بتظل توصل عبر موزع الحمل.
  • B: هذا يغير طريقة توزيع الطلبات، مو العنوان اللي يشوفه السيرفر.
  • D: هذا يشيل موزع الحمل وحمايته من الأعطال.

للمراجعة: كيف يوجه ALB الطلبات في هذا الجزء، وX-Forwarded headers في وثائق AWS.

السؤال 5 من 5

تطبيق يحفظ جلسات المستخدمين في ذاكرة كل سيرفر. وبعد ما انتقل لعدة سيرفرات خلف Application Load Balancer، صار المستخدمين يطلعون من حساباتهم عشوائياً. أي تغييرين يحلون هذا؟ (اختر اثنين.)

اعرض الجواب

الجواب الصحيح: B + D

كل سيرفر يعرف جلساته هو بس. الجلسات اللاصقة تبقي الزائر على نفس السيرفر، والكاش المشترك يخلي الجلسة متاحة لكل السيرفرات. والكاش هو التصميم الأفضل، لأن الجلسات تبقى لو اختفى سيرفر.

  • A: هذا يوزع الطلبات بشكل أعدل، وممكن يرسل الزائر لسيرفر ثاني برضو.
  • C: هذا يخص الطلبات الجارية على سيرفر ينشال.
  • E: هذا يأخر اكتشاف السيرفرات الفاشلة فقط.

للمراجعة: إعدادات تحتاج تعرفها في هذا الجزء، وTarget group attributes وMake services stateless في وثائق AWS.

بس عدد السيرفرات عندنا الحين ثابت، وأنت اللي تشغّلها بيدك. في الجزء السابع نخلي AWS تزيدها وتنقصها لحالها، ونجمع كل اللي تعلمناه في تطبيق كامل.