التوسع الرأسي مقابل التوسع الأفقي

التوسع الرأسي مقابل التوسع الأفقي

كل نظام يحقق نجاحًا سيصطدم في نهاية المطاف بسقف من الأداء. يتضاعف المستخدمون، وترتفع حدة حركة المرور، ويبدأ الخادم الذي كان يتعامل مع بضع مئات من الطلبات في الثانية بالترنح تحت آلافها. عند تلك اللحظة يواجه كل مهندس ذات التقاطع: توسّع للأعلى (التوسع الرأسي) أم توسّع للخارج (التوسع الأفقي). إدراك الفرق بين الاستراتيجيتين وفهم مقايضاتهما يُعدّ من أهم القرارات في تصميم الأنظمة.

التوسع الرأسي (Scale Up)

يعني التوسع الرأسي جعل الآلة الواحدة أكبر وأقوى. تُرقّي المعالج من 4 أنوية إلى 32، وتضاعف ذاكرة الوصول العشوائي من 32 جيجابايت إلى 256، وتستبدل القرص الدوار بوحدة NVMe سريعة، أو تنتقل إلى واجهة شبكة أسرع. يظل التطبيق يعمل على عقدة واحدة فحسب، غير أنك تمنح تلك العقدة طاقةً أكبر.

مثال واقعي: شركة ناشئة في مراحلها الأولى تشغّل بنيتها التقنية الكاملة — خادم الويب والتطبيق وقاعدة البيانات — على مثيل AWS واحد من نوع t3.medium (معالجان افتراضيان و4 جيجابايت رام). مع نمو قاعدة المستخدمين إلى نحو 50 ألف مستخدم نشط يوميًا، يُرقّى المثيل إلى r6i.8xlarge (32 معالجًا افتراضيًا و256 جيجابايت رام). لا تغييرات في الكود، ولا بنية تحتية جديدة — مجرد صندوق أضخم.

• مزايا: بساطة — لا تعديلات في كود التطبيق، ولا تعقيدات الأنظمة الموزعة، ولا حمل إضافي لاتصالات بين العقد.
• مزايا: زمن استجابة منخفض — تجري كل العمليات داخل عملية واحدة على آلة واحدة.
• عيوب: سقف صلب — أكبر آلة منفردة تتيحها AWS اليوم لا تتجاوز 448 معالجًا افتراضيًا و24 تيرابايت رام، وكثير من الأنظمة الحقيقية تتخطى ذلك بسهولة.
• عيوب: نقطة فشل واحدة — إذا توقفت الآلة الوحيدة، توقف الخدمة بالكامل.
• عيوب: تكلفة متصاعدة بشكل غير خطي — مضاعفة قدرة المعالج تُضاعف التكلفة أربع مرات أو أكثر في الفئات العليا.
• عيوب: توقف أثناء الترقيات — تغيير حجم الآلة الافتراضية أو استبدال العتاد يستلزم عادةً إعادة التشغيل.

التوسع الأفقي (Scale Out)

يعني التوسع الأفقي إضافة المزيد من الآلات لتوزيع الحمل. بدلًا من خادم واحد قوي، تشغّل عشرة (أو مئة، أو عشرة آلاف) من الخوادم التقليدية وتوزع العمل عليها جميعًا. كل آلة منفردة متواضعة الموارد؛ والأسطول ككل يتعامل مع إنتاجية هائلة.

مثال واقعي: تعمل Netflix على عشرات الآلاف من مثيلات AWS EC2. لا يوجد مثيل فردي ضخم بشكل خاص — كثيرها من نوع m5.xlarge أو ما يماثله. الحجم ينبع من العدد الكبير للعقد والبنية التحتية التي توجّه الحمل وتوازنه بينها.

• مزايا: لا سقف من الناحية النظرية — أضف المزيد من العقد كلما نما الطلب.
• مزايا: توافر عالٍ — إذا فشلت عقدة واحدة، تستوعب الأخريات حركة مرورها؛ لا نقطة فشل واحدة.
• مزايا: كفاءة تكلفة على نطاق واسع — العتاد التقليدي أو المثيلات السحابية أرخص بكثير لكل وحدة حوسبة مقارنةً بالآلات الأعلى رتبةً.
• عيوب: تعقيد — يجب أن يُصمَّم التطبيق للعمل الصحيح على عقد كثيرة بالتوازي (اللاحالة، الحالة المشتركة، الاتساق الموزع).
• عيوب: حمل الشبكة — تتصل العقد عبر الشبكة مما يُدخل زمن استجابة واحتمالية أعطال جزئية.
• عيوب: تكلفة تشغيلية — تحتاج إلى موازنات تحميل، واكتشاف الخدمات، ومراقبة الصحة، والتنظيم (Kubernetes وما شابهه).

مخطط المقارنة المتجانبة

حيث تصبح الأمور معقدة: الحالة (State)

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

لهذا يرتبط التوسع الأفقي ارتباطًا وثيقًا بمفهوم اللاحالة (Statelessness). يجب أن تُصبح خوادم التطبيق عديمة الحالة — لا تحتفظ بأي بيانات جلسة أو مستخدم في ذاكرتها المحلية. يجب أن تقطن جميع الحالات المشتركة في نظام خارجي: قاعدة بيانات، أو كاش موزع كـ Redis، أو مخزن جلسات. عندها يستطيع كل خادم التعامل مع أي طلب باستقلالية تامة.

الأرقام: متى يُناسب كل نهج؟

لا توجد عتبات عالمية ثابتة، لكن هذه الإرشادات التقريبية تنطبق على كثير من الأنظمة الإنتاجية:

• 0 – 10 آلاف طلب/يوم: مثيل صغير واحد يكفي. الترقية الرأسية إلى آلة متوسطة هي الطريق الأسرع.
• 10 آلاف – مليون طلب/يوم: مثيل رأسي كبير يعمل في الغالب، لكن ابدأ الآن في القضاء على الحالة المحلية استعدادًا للمرحلة التالية.
• مليون – 100 مليون طلب/يوم: توسع أفقي لخوادم التطبيق عديمة الحالة، مع طبقة قاعدة بيانات مستقلة، وربما نسخ قراءة وكاش.
• أكثر من 100 مليون طلب/يوم: توزيع أفقي كامل على كل طبقة — موازنات تحميل وخوادم تطبيقات وكاشات وقواعد بيانات مُجزّأة وشبكات CDN على الحافة.

في الممارسة: معظم الأنظمة تستخدم الاثنتين

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

1. توسيع قاعدة البيانات رأسيًا بأقصى ما يمكن (قواعد البيانات يصعب توزيعها دون مقايضات كبيرة).
2. توسيع طبقة التطبيق اللاحالة (خوادم الويب وAPI) أفقيًا — هذه الخوادم سهلة التكرار.
3. توسيع العقد الأفقية الفردية رأسيًا عند الحاجة إلى طاقة أكبر لكل عقدة، مع إضافة المزيد من العقد في آنٍ واحد.

الخلاصة الجوهرية

• التوسع الرأسي بسيط لكنه يصطدم بسقف صلب ويمثل نقطة فشل واحدة.
• التوسع الأفقي لا سقف له من الناحية النظرية لكنه يستلزم خدمات عديمة الحالة وبنية تحتية إضافية.
• الاستراتيجيتان تكمّلان بعضهما — الأنظمة الحقيقية تستخدم كلتيهما على طبقات مختلفة.
• جعل خوادم التطبيق عديمة الحالة منذ البداية هو أهم خطوة تحضيرية للتوسع الأفقي.