قياس البنية التحتية: أفقي مقابل عمودي، موازنة الأحمال والقياس التلقائي

تخدم Netflix 260 مليون مشترك عبر 190 دولة من خلال التوسع الديناميكي لآلاف المثيلات بناءً على الطلب في الوقت الفعلي. على الرغم من أن معظم الشركات لا تعمل على نطاق Netflix، إلا أن مبادئ التوسع هي نفسها: مطابقة سعة البنية التحتية مع الطلب على حركة المرور تلقائيًا، دون تدخل يدوي ودون دفع مقابل الموارد الخاملة. تحدد الاختيارات التي تقوم بها بين القياس الأفقي والرأسي، وموازنات التحميل L4 وL7، والقياس التلقائي التفاعلي والتنبؤي ما إذا كانت المنصة الخاصة بك ستنمو بأمان أو ستصطدم بالحائط.

الوجبات الرئيسية

• ابدأ عموديًا (الأجهزة الأكبر حجمًا) للبساطة، ثم انتقل إلى الوضع الأفقي (المزيد من الأجهزة) عندما تحتاج إلى توفر عالي أو تتجاوز حدود الجهاز الفردي
• توفر موازنات التحميل L7 توجيهًا قائمًا على المحتوى ضروريًا للتطبيقات الحديثة، بينما توفر موازنات L4 إنتاجية أولية لتوزيع TCP البسيط
• يجب أن تجمع سياسات القياس التلقائي بين المشغلات القائمة على القياس (وحدة المعالجة المركزية والذاكرة) والقياس التنبؤي لأنماط حركة المرور المعروفة
• يتبع قياس قاعدة البيانات قواعد مختلفة عن قياس التطبيق - قراءة النسخ المتماثلة لأحمال القراءة الثقيلة، والتقسيم لأحمال الكتابة الثقيلة

---

القياس الأفقي مقابل الرأسي

إن قرار التوسع الأساسي هو ما إذا كان سيتم تكبير الأجهزة الموجودة (عموديًا) أو إضافة المزيد من الأجهزة (أفقيًا). كل نهج له مقايضات متميزة.

متى يجب القياس عموديًا

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

القياس عموديًا عندما:

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

توقف عن القياس عموديًا عندما:

• أنت بحاجة إلى توفر عالي (مثيل واحد = نقطة فشل واحدة)
• أكبر مثيل متاح لا يكفي
• أنت تدفع مقابل السعة القصوى التي تظل خاملة بنسبة 90% من الوقت
• أنت بحاجة إلى التوزيع الجغرافي لوقت الاستجابة

متى يجب القياس أفقيًا

يتطلب القياس الأفقي أن يكون تطبيقك عديم الحالة - يمكن التعامل مع أي طلب بواسطة أي مثيل. هذا يعني:

• الجلسات المخزنة في Redis أو قاعدة البيانات، وليس في الذاكرة
• تحميلات الملفات المخزنة في وحدة تخزين الكائنات (S3)، وليس على القرص المحلي
• لا يوجد تكوين خاص بالمثيل أو تخزين مؤقت محلي بدون النسخ المتماثل
• معالجة رشيقة لإنهاء المثيل (فحوصات السلامة، واستنزاف الاتصال)

القياس أفقيًا عندما:

• يعد التوفر العالي مطلبًا (لا يمكن لشركتك أن تتحمل دقائق من التوقف)
• حركة المرور متغيرة ويمكن أن يؤدي التوسع التلقائي إلى توفير التكلفة عن طريق تقليصها خلال فترات الهدوء
• أنت بحاجة إلى النشر دون توقف (عمليات النشر المتوالية عبر المثيلات)
• تتجاوز متطلبات الأداء قدرة الآلة الواحدة

---

موازنة الأحمال الغوص العميق

يقوم موازن التحميل بتوزيع حركة المرور الواردة عبر خوادم خلفية متعددة. يحدد نوع موازن التحميل قرارات التوجيه الممكنة.

L4 (طبقة النقل) موازنة التحميل

تعمل موازنات التحميل L4 على مستوى TCP/UDP. يقومون بتوجيه الاتصالات بناءً على عنوان IP والمنفذ دون فحص محتويات الحزمة. فهي سريعة وبسيطة وتتعامل مع أي بروتوكول يعتمد على TCP.

الأفضل لـ: توزيع TCP الخام، وخادم وكيل اتصال قاعدة البيانات (PgBouncer)، والبروتوكولات غير HTTP، ومتطلبات الإنتاجية العالية للغاية

القيود: لا يمكن اتخاذ قرارات التوجيه بناءً على مسار عنوان URL أو الرؤوس أو ملفات تعريف الارتباط. لا يمكن إنهاء SSL (يجب أن يتم ذلك على الواجهات الخلفية).

L7 (طبقة التطبيق) موازنة التحميل

تعمل موازنات التحميل L7 على مستوى HTTP. يقومون بفحص رؤوس الطلبات وعناوين URL وملفات تعريف الارتباط وحتى هيئات الطلب لاتخاذ قرارات التوجيه. إنهم يتعاملون مع إنهاء SSL والضغط ويمكنهم تعديل الطلبات والاستجابات.

الأفضل لـ: تطبيقات الويب، وبوابات واجهة برمجة التطبيقات (API)، والتوجيه المستند إلى المحتوى، وإنهاء SSL، واختبار A/B، وعمليات نشر Canary

خوارزميات موازنة التحميل

فحوصات الصحة والتدهور اللطيف

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

• فحص صحي سطحي - فحص بسيط لاتصال TCP أو HTTP 200 على نقطة نهاية مخصصة. يكتشف أعطال الخادم ولكن ليس الفشل على مستوى التطبيق.
• فحص صحي عميق - يتحقق من اتصال قاعدة البيانات، وتوافر Redis، وإمكانية الوصول إلى الخدمة الخارجية. يكتشف المزيد من المشكلات ولكنه يخاطر بالسلبيات الكاذبة إذا كانت التبعية غير الحرجة معطلة.
• فترة السماح - تحتاج المثيلات الجديدة إلى وقت للإحماء (تجميع JIT، ومحتوى ذاكرة التخزين المؤقت). قم بتعيين فترة سماح لبدء التشغيل قبل أن يرسل موازن التحميل حركة المرور الكاملة.
• استنزاف -- عند إزالة مثيل، توقف عن إرسال طلبات جديدة ولكن اسمح للطلبات الموجودة بالاكتمال (استنزاف الاتصال). عادة 30-60 ثانية.

---

سياسات القياس التلقائي

يقوم القياس التلقائي بضبط عدد المثيلات بناءً على الطلب، ومطابقة السعة مع حركة المرور دون تدخل يدوي.

القياس المبني على القياس

يقوم الأسلوب الأكثر شيوعًا بتشغيل إجراءات القياس عندما يتجاوز المقياس الحد.

القياس التنبؤي

إذا كانت حركة المرور الخاصة بك تتبع أنماطًا يمكن التنبؤ بها (ذروات يومية، دورات أسبوعية، أحداث موسمية)، فستكون سعة توفير القياس التنبؤي قبل وصول حركة المرور. يدعم AWS Auto Scaling القياس التنبؤي الذي يتعلم من الأنماط التاريخية ويقيس بشكل استباقي.

الجمع بين التنبؤي والتفاعلي: استخدم القياس التنبؤي للأنماط المعروفة (منحدر حركة المرور الصباحي، التزويد المسبق بالجمعة السوداء) والقياس التفاعلي للزيادات المفاجئة غير المتوقعة.

أفضل ممارسات التوسع

1. التوسيع السريع والتوسيع البطيء -- قم بإضافة المثيلات بقوة (فترة التهدئة لمدة 1-2 دقيقة) ولكن قم بإزالتها تدريجيًا (فترة التهدئة لمدة 10-15 دقيقة) لتجنب الخفقان
2. استخدام مقاييس متعددة -- القياس على وحدة المعالجة المركزية أو الذاكرة أو عدد الطلبات، باستخدام المقياس الأول الذي يتم تشغيله
3. تعيين الحدود الدنيا والقصوى -- منع التوسع إلى الصفر (عدم توفر) أو التوسع إلى أجل غير مسمى (انفجار التكلفة)
4. اختبار القياس أثناء اختبارات التحميل -- تأكد من تشغيل القياس التلقائي بشكل صحيح وأن المثيلات الجديدة تخدم حركة المرور خلال الإطار الزمني المتوقع
5. مراقبة أحداث القياس - تنبيه بشأن القياس المتكرر لاكتشاف مشكلات التكوين أو مشكلات الأداء الأساسية

---

استراتيجيات توسيع قاعدة البيانات

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

قراءة النسخ المتماثلة

قراءة النسخ المتماثلة ونسخ البيانات من قاعدة البيانات الأساسية وتقديم استعلامات القراءة. إنها تعمل على قياس إنتاجية القراءة خطيًا ولكنها لا تساعد في إنتاجية الكتابة.

اعتبارات التنفيذ:

• تأخر النسخ المتماثل - تكون النسخ المتماثلة متسقة في النهاية. الاستعلامات مباشرة بعد الكتابة قد لا ترى التغيير. استخدم الأساسي للقراءة بعد الكتابة.
• توجيه الاتصال - يحتاج تطبيقك إلى منطق لتوجيه عمليات القراءة إلى النسخ المتماثلة والكتابة إلى الملف الأساسي. يمكن لـ ORMs ووكلاء الاتصال (ProxySQL وPgBouncer) أتمتة ذلك.
• تجاوز الفشل -- في حالة فشل العملية الأساسية، يمكن ترقية النسخة المتماثلة. يؤدي تجاوز الفشل التلقائي (AWS RDS Multi-AZ، وAWS Aurora) إلى تقليل وقت التوقف عن العمل إلى ثوانٍ.

تقسيم الجدول

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

تجمع الاتصال

إن إنشاء اتصالات قاعدة البيانات باهظ الثمن ومحدود العدد. تجمعات الاتصال مثل اتصالات تجمع PgBouncer من العديد من مثيلات التطبيق إلى عدد أقل من اتصالات قاعدة البيانات.

بدون التجميع: 20 مثيل تطبيق × 20 اتصالًا لكل = 400 اتصال قاعدة بيانات (من المحتمل أن يتجاوز حدود PostgreSQL)

باستخدام PgBouncer: تتصل 20 نسخة تطبيق بـ PgBouncer، الذي يحافظ على 50-100 اتصال بـ PostgreSQL، مما يؤدي إلى تعدد الإرسال بكفاءة.

---

تحليل الخدمات المصغرة

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

متى تتحلل

لا تبدأ بالخدمات الصغيرة. ابدأ بوحدة متراصة جيدة التنظيم وتتحلل عندما:

• تحتوي المكونات المختلفة على متطلبات قياس مختلفة إلى حد كبير (يحتاج البحث إلى 20 مثيلًا، ويحتاج الخروج إلى 5 مثيلات)
• تحتاج الفرق المختلفة إلى النشر بشكل مستقل دون تنسيق جداول الإصدار
• يحتاج مكون معين إلى مجموعة تقنيات مختلفة (التعلم الآلي في Python، API في Node.js)
• يتجاوز وقت نشر المونوليث 30 دقيقة بسبب حجم قاعدة التعليمات البرمجية

ما يجب استخراجه أولاً

---

الأسئلة المتداولة

كيف أعرف متى أحتاج إلى التوسع؟

راقب أربعة مقاييس رئيسية: استخدام وحدة المعالجة المركزية (أعلى من 70%) باستمرار، واستخدام الذاكرة (أعلى من 80%)، ووقت الاستجابة P95 (أعلى من SLO)، ومعدل الخطأ (أعلى من 0.1%). عندما ينتهك أي مقياس حده باستمرار، فإنك تحتاج إلى التوسع. المراقبة الاستباقية مع التنبيه تلتقط هذه الاتجاهات قبل أن يلاحظها المستخدمون. راجع دليل المراقبة.

هل التوسع التلقائي أو التوفير المسبق أكثر فعالية من حيث التكلفة؟

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

هل يجب أن أستخدم الحاويات (Docker/Kubernetes) أم الأجهزة الافتراضية التقليدية؟

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

كيف يمكنني التعامل مع فشل قاعدة البيانات دون فقدان البيانات؟

استخدم النسخ المتماثل المتزامن لتجاوز فشل فقدان البيانات - لا يتعرف الملف الأساسي على الكتابة حتى تؤكدها النسخة المتماثلة. يؤدي هذا إلى إضافة زمن انتقال للكتابة (عادةً 1-5 مللي ثانية داخل نفس المنطقة) ولكنه يضمن عدم فقدان البيانات أثناء تجاوز الفشل. يوفر AWS RDS Multi-AZ وAurora نسخًا متزامنًا مُدارًا مع تجاوز الفشل تلقائيًا.

---

ما هو التالي

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

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

تقوم ECOSIRE بتصميم وتنفيذ بنية تحتية قابلة للتطوير لمنصات الأعمال على AWS والبيئات السحابية المتعددة. اتصل بفريق DevOps لتقييم تطوير البنية التحتية.

---

تم النشر بواسطة ECOSIRE — لمساعدة الشركات على التوسع باستخدام الحلول المدعومة بالذكاء الاصطناعي عبر Odoo ERP، وShopify eCommerce، وOpenClaw AI.