منصة امتحان خيالية بأرقام حقيقية: خادم frontend واحد، اثنين backend ثابتين، عقدة قاعدة بيانات واحد و standbys اثنين مطفأين. يغطي الجزء تعريف high availability و الاختناقات الأولى التي احتفظت بالتحرك.
Author
Anichur Rahaman
Part 1 of 5
من خادم واحد إلى جاهز لليلة الامتحانفي 25 سبتمبر، أثناء الامتحانات، بدأ الطلاب يرون HTTP 429، «طلبات كثيرة جداً». السبب لم يكن نقصاً في الخوادم، بل قاعدة تعد الشيء الخاطئ: محدِّد المعدل كان يعد حسب عنوان IP، والمدرسة تضع مئات الطلاب خلف عنوان واحد. أمام محدِّد المعدل، بناء كامل بدا كشخص واحد صبور جداً.
بعد أحد عشر يوماً، الساعة 02:28 من 6 أكتوبر، اختبار تحميل backend أرجع 2,854 خطأ تطبيق. كل واحد يقول نفس الشيء: انتهت مهلة انتظار الاتصال بـ Valkey. طبقة مختلفة، سبب مختلف، إصلاح مختلف. بعد ذلك جاءت CPU عادية، وهي المشكلة الوحيدة التي يحلها المزيد من الخوادم فعلاً.
هذا التسلسل هو القصة الحقيقية لهذا المشروع: الاختناق ظل يتحرك. إضافة خوادم ليست معمارية. إنها حركة واحدة بين عدة حركات، والأخيرة.
بين أواخر سبتمبر و 7 أكتوبر 2026، نقلنا منصة Laravel و Next.js على DigitalOcean من خادم frontend واحد وخادمي backend ثابتين إلى إعداد جاهز لذروة امتحان مجدول. هذا الجزء الأول يغطي نقطة البداية: المشكلة التجارية، ما ورثناه، لماذا لم يكن كافياً، ماذا كانت «التوفرية العالية» تعني لنا، وماذا أخبرتنا الاختبارات الأولى.
قبل أن نبدأ: NovaCommerce اسم خيالي، مستخدم لهذه الدراسة الحالة. حذفت أي شيء قد يميز الشركة أو خوادمها أو طلابها.
هذا الجزء الأول من سلسلة خماسية «من خادم واحد إلى جاهز لليلة الامتحان». NovaCommerce اسم خيالي؛ المعمارية والأرقام والأخطاء حقيقية.
NovaCommerce منصة تبيع الدورات وتدير امتحانات تفاعلية مجدولة للطلاب. يسجلون ويدفعون ويأخذون امتحانات حية ويرون نتائجهم ويستخدمون مساعدة الذكاء الاصطناعي للدراسة.
معظم حركة الويب تشبه تلة: تصعد في الصباح وتنزل في الليل. حركة الامتحانات جرف. تصور أبواب قاعة حفلات موسيقية. لا شيء يحدث لساعات، ثم تفتح الأبواب والجميع يصلون معاً. عندما يبدأ امتحان مجدول، آلاف الطلاب يضربون المنصة في نفس الدقيقة.
الخبر الجيد أن الجرف له جدول زمني. نعرف متى سيأتي. وصفت هذا الميزة بشكل عام في الدليل إلى auto-scaling للطفرات المرورية. هذه السلسلة هي النصف الآخر: منصة حقيقية، بأرقام حقيقية.
أعطتنا الأعمال أربعة متطلبات، بلغة واضحة.
كل اختيار تقني في هذه السلسلة يعود لواحد من هذه الأسطر الأربعة.
إليك الإعداد كما وجدناه قبل 5 أكتوبر 2026، في منطقة DigitalOcean واحدة وشبكة خاصة واحدة.
frontend كان droplet واحد بـ 8 vCPU و 16 GB من الذاكرة، يشغل حاوية Next.js واحدة. النطاق أشار مباشرة إليه، و TLS جاء من certbot على droplet نفسه. لا يوجد load balancer. إذا مات هذا الخادم، الموقع كان ميتاً.
كان يهدر الأموال أيضاً. عملية Node.js واحدة تقدِّم على أساس core واحد تقريباً، لذا معظم الـ vCPU الثمانية كانت خاملة: متجر به ثمانية ستة دفع وأمين صندوق واحد.
DigitalOcean load balancer استهدف droplets backend ثابتين، كل واحد بـ 4 vCPU و 8 GB. التطبيق Laravel (PHP-FPM) خلف nginx في Docker، كحاويتين لكل عقدة: web لـ nginx و app لـ php-fpm. الطوابير (Horizon)، المجدول و Reverb، خادم WebSockets، تشغلوا على عامل بدلاً من ذلك.
استهدف load balancer كل backend برقم معرف خاص به ثابت، ليس بوسم. هذا الفرق بين قائمة ضيوف بها أسماء وقاعدة تقول «أي شخص يرتدي شارة طاقم العمل». مع الأسماء، الخادم الجديد لا يستطيع أن يدخل من تلقاء نفسه. يجب على شخص ما أن يعدّل القائمة.
كانت أخبار جيدة هنا، وأهميتها تفوق أي شيء آخر. عقد backend الويب كانت بالفعل بدون حالة. الجلسات والذاكرة المؤقتة والطوابير تعيش في Valkey المُدار، والسجلات تذهب إلى stderr. خادم يمكنك حذفه دون فقدان أي شيء هو خادم يمكنك ضربه. بدون هذه الخاصية بقية السلسلة لما كانت حدثت.
كانت قاعدة البيانات عقدة Managed MySQL «Advanced» واحدة بـ 8 vCPU و 32 GB: عقدة واحدة، بدون standby.
ثم كانت droplets «standby» اثنين، محفوظة كنسخة احتياطية. كانت مطفأة. droplet مطفأ لا يزال يكلف أموالاً، وإعادة تشغيل أحدها تستغرق دقائق. إنها عجلة احتياطية في مرآب مقفل عبر المدينة: موجودة، تدفع عنها، وهي لا تساعد بينما أنت عالق في الطريق. هذا ليس توفراً عالياً.
شيئان أصغر جلسا في الزاوية. شهادات TLS للـ load balancer كانت تحميلات يدوية بتاريخ انتهاء صلاحية، لذا التجديد كان مهمة متكررة على شخص أن يتذكرها. وحد الـ droplet للحساب كان 25، وهذا سيهم مرة يستطيع فيها بركان اثنان النمو واستبدال العقد (الجزء 2).
| جزء الإعداد | كيف بُني | ما يحدث تحت الضغط أو الفشل |
|---|---|---|
| Frontend | Droplet واحد 8 vCPU / 16 GB، حاوية Next.js واحدة، لا load balancer | الموقع ميت إذا مات؛ معظم الأنوية خاملة، لأن عملية Node واحدة تستخدم تقريباً core واحد |
| Backend | Droplets ثابتة اثنين 4 vCPU / 8 GB خلف load balancer، مستهدفة برقم معرف | لا نمو تلقائي؛ الخادم الجديد لا يستطيع أن ينضم بنفسه |
| قاعدة البيانات | عقدة Managed MySQL واحدة، 8 vCPU / 32 GB، بدون standby | لا توجد عقدة ثانية جاهزة للاستيلاء إذا فشلت العقدة |
| Standbys | Droplets اثنين، مطفأة | مفروضة عليها رسوم بينما مطفأة؛ دقائق للتشغيل |
انظر إلى ما غائب من تلك الجدول: خطأ برمجي. لا شيء كان مكسوراً. الإعداد فعل ما بُني فعله. المشكلة كانت عدم توافق بين جرف مجدول وإعداد لم يستطع فقدان خادم، لم يستطع إضافة واحد بنفسه، واحتفظ بطاقته الاحتياطية مطفأة. لا تستطيع إصلاح عدم توافق. يجب أن تغيّر شكل النظام، وهذا ما تعنيه المعمارية.
«التوفرية العالية» واحدة من تلك العبارات التي يومئ بها الجميع ولا أحد يعرّفها. قبل أن نغيّر أي شيء، كتبنا ما تعنيه لهذه المنصة. انحصرت في أربعة أسطر.
لا خادم واحد يأخذ الموقع تحته. قاعدة البيانات تنجو من فقدان عقدة. النشرات والتقليص غير مرئية للطلاب. الطاقة جاهزة قبل امتحان يبدأ، وليس خمس دقائق بعده.
أحب تعريف يمكنك اختباره بسؤال. هل يمكننا سحب القابس على أي خادم واحد والاستمرار في الخدمة؟ هل يمكن لعقدة قاعدة بيانات أن تفشل بدون توقف الامتحان؟ هل يمكننا شحن إصدارة بدون لاحظ الطالب؟ هل الطاقة موجودة بالفعل عندما ينقر الطالب الأول «ابدأ»؟
قاعدتان تجاريتان تجلس فوقه: الإرسالات لا تُفقد أبداً، والتكلفة تبقى معقولة. الشكل يخطّط كل متطلب إلى الطبقة التي يجب أن تسلمه ولجزء السلسلة الذي يغطيه.
السطر الأخير من التعريف، «وليس خمس دقائق بعده»، هو الذي ألم. في اختباراتنا، autoscaling أضاف العقدة الإضافية الأولى حول سبع دقائق بعد وصول CPU إلى 99%. سبع دقائق وقت طويل عندما يبدأ امتحان في واحدة. الطاقة يجب أن تكون موجودة قبل الجرف، وليس بعده.
مع التعريف مكتوب، فعلنا ما تتطلبه الطريقة: قِس أولاً. بين أواخر سبتمبر و 6 أكتوبر راقبنا الإنتاج وأجرينا اختبارات تحميل، ووجدنا ثلاث مشاكل متتالية. تبدو غير مرتبطة، وهذا هو المقصود.
مقاس على الإنتاج: الطلاب كانوا يحصلون على HTTP 429 أثناء الامتحانات. محدِّد المعدل الشامل للـ API مفتاح على IP، لأن حارس المصادقة الافتراضي كان فارغاً للطلاب مستند على token، لذا محدِّد المعدل لم يستطيع معرفة من كان الطالب. مدرسة أو شركة نقل الهاتف تضع مئات الطلاب خلف عنوان NAT واحد، والبناء كله شارك جرة واحدة.
Status: Implemented. مفتاحنا محدِّد المعدل على طالب أو حساب معلم، و IP فقط للضيوف. عم قريب لهذا الخطأ عاد في 7 أكتوبر في throttles مستوى الطريق، وتلك القصة في الجزء 4.
الساعة 02:28 من 6 أكتوبر، اختبار تحميل backend أرجع 2,854 خطأ 500 تطبيق. كل واحد كان RedisException: Operation timed out أثناء الاتصال، مع timeout اتصال 5 ثوان. Valkey (4 GB، primary زائد standby) لم يستطع قبول اتصالات سريعة بما يكفي تحت الحمل.
كيفية استخدام التطبيق لها أضافت إلى الضغط. كل طلب فتح اتصال TLS جديد إلى Valkey (حول 5.4 ملسة من CPU لكل طلب) وآخر إلى MySQL (حول 3.3 ملسة). تصور متجراً حيث كل عميل يُفحص في الباب، في كل مرة واحدة. تحت حشد، الباب يصبح الطابور.
Status: Implemented, then Tested. عدنا حجم Valkey في المكان إلى 8 GB مع عقدتين (primary و standby)، البيانات احتفظت والخادم لم يتغير. بعدها أعدنا الاختبار مع ارتقاء تدريجي من 25 إلى 500 طلب في الثانية، بدء على عقدتي backend بينما يتسع البركة تحت الحمل: 0 أخطاء تطبيق و 0 backend 5xx. كانت هناك 143 خطأ في load balancer، لكن فقط بينما الأنوية كانت مشبعة CPU. هذا الإشارة المتوقعة «خارج الطاقة»، ليس خطأ. طبقة البيانات تأخذ الجزء 3، و Valkey عود في الجزء 4. للنسخة الشاملة، انظر طبقة البيانات تحت الحمل.
مع الأول اثنين ثابتين، ما بقي حساب عادي. عقدة backend واحدة 4 vCPU / 8 GB تخدم حول 65 إلى 70 طلب في الثانية من خليط API الحقيقي في CPU كامل، حول 59 ملسة من CPU لكل طلب. كل قرار طاقة لاحق مبني على هذا الرقم.
هذا واحد فقط من الثلاثة اختناق أن أكثر خوادم حقاً يحلون، وحتى هنا التوقيت هو الفخ: العقدة الإضافية الأولى جاءت حول سبع دقائق بعد وصول CPU إلى 99%. كيفية جعل الطاقة تصل في وقت مبكر هو موضوع الجزء 2.
لذا الترتيب كان محدِّد معدل (الكود)، ثم Valkey اتصالات (تحجيم طبقة البيانات)، ثم backend CPU (طاقة). إذا كنا قد ابتدأنا بإضافة خوادم، محدِّد المعدل كان قد قال 429 و Valkey كان قد لا يزال timeout.
قبل الحديث عن الشكل الجديد، يساعد أن نعرف ما كلّف الشكل القديم. هذه أسعار DigitalOcean القائمة الشهرية للـ web tier القديم.
| البند | التكلفة | ما اشترته |
|---|---|---|
| Web tier القديم: frontend، اثنين backend، worker، load balancer واحد، standbys اثنين | حول $416 شهرياً | موقع نشط مع عدة نقاط فشل مفردة |
| Droplets standby اثنين مطفأين | $112 شهرياً | لا توفرية: مفروضة عليها رسوم بينما مطفأة، دقائق للتشغيل |
| عقدة backend إضافية واحدة، للمقارنة | حول $0.08 في الساعة | طاقة تخدم الطلبات فعلاً |
الـ $112، قليل أكثر من ربع web tier، هو الرقم الذي بقي معي. اشترى خادمين لا يستطيعان خدمة طلب واحد. Pre-scaling عقدة backend إضافية تكلّف حول $0.08 في الساعة، لذا رفع الطاقة لمساء يكلّف سنتات. الدفع طول الشهر عن طاقة مطفأة هو الطريقة الأكثر تكلفة للشعور بالأمان.
ملاحظة صادقة: الـ $416 تغطي فقط web tier، وليس قواعد البيانات أو Valkey أو storage، لذا لا يمكن مقارنتها مع فاتورة كاملة. في الجزء 5 أقارن مثل مع مثل.
النموذج الذي كررناه طول المشروع هو ما رأيته للتو: قِس، جد الاختناق، افهم السبب، غيّر المعمارية، اختبر ثانية، وقِس ثانية. إضافة خوادم ليست معمارية. المعمارية اختيار طبقة تتغير، ولماذا.
إليك كيفية ملاءمة الخمسة أجزاء.
| الجزء | الطبقة | ما ستراه |
|---|---|---|
| 1 (هذا الجزء) | نقطة البداية | المشكلة التجارية، الإعداد القديم، تعريف التوفرية العالية، الاختناقات الأولى والتكلفة القديمة |
| 2 | طبقة التطبيق | اثنين load balancers، اثنين autoscale pools، pre-scaling، image-based deploys ودرس rollout |
| 3 | قاعدة البيانات | من عقدة MySQL واحدة إلى primary مع standby في نافذة 26 دقيقة، read/write split، PostgreSQL مع pgvector |
| 4 | Valkey، workers، logs | طوابير، worker، logging، monitoring وخطأ scale-in أثناء امتحان حقيقي |
| 5 | الإثبات | مساء امتحان حقيقي من 7 أكتوبر، load و soak testing، والمعمارية النهائية |
فكّرنا أيضاً في أفكار لم نبنِها، وأنا أصنّفها. load balancer واحد لكلا الطبقتين كان Considered، بعدها Rejected. «warm standby جاهز في ثوان» كان Considered، لكن autoscale pools لا دافئة، لذا استخدمنا طاقة احتياطية تخدم بالفعل زائد pre-scaling. Kubernetes كان Considered للاحقة وليس implemented.
ليس كل شيء منته، وسأقول ذلك. عامل واحد مفرد هو نقطة فشل مفردة معروفة؛ إصلاحه Planned، وليس done (الجزء 4). اختبار soak رسمي متعدد الساعات أيضاً Planned (الجزء 5).
الهدف كقائمة تحقق، مع الجزء حيث يُبنى أو يُختبر كل سطر.
بعد ذلك، في الجزء 2، نبني طبقة التطبيق: اثنين load balancers، اثنين autoscale pools، pre-scaling، وطريقة rollout تعلمت من blip 503 قصير.
About the Author
Anichur Rahaman
Continue Reading
