متطلبات خادم بوابة SMS: التحجيم من 1 إلى 200 msg/s

«ما الخادم الذي أحتاجه؟» هو أول سؤال يطرحه كل مشترٍ تقريبًا، والجواب أصغر مما يخشاه معظم الناس وأكثر تحديدًا مما يقوله معظم المورّدين. بوابة SMS ليست مُرمِّز فيديو. عملها هو الطوابير والتوجيه والفوترة ومسك الدفاتر، ومسك الدفاتر هو ما ينمو. يقدّم لك هذا الدليل متطلبات خادم بوابة SMS عند كل مستوى من مستويات الحركة بأرقام حقيقية، ويشرح لماذا تهمّ vCPU المخصّصة أكثر من عدد الأنوية، ويبيّن ما تفعله إشعارات التسليم والأرشيف بقرصك على مدى عام، ويختم بقائمة مختصرة بالمزوّدين وخطة النسخ الاحتياطي التي ينبغي أن تكون لديك قبل أن يبدأ أول عميل العمل الفعلي.

متطلبات خادم بوابة SMS حسب مستوى الحركة

الرقم الذي يحدّد خادمك هو عدد الرسائل في الثانية عند الذروة، لا عدد الرسائل في الشهر. العميل الذي يرسل 1,000,000 رسالة موزّعة على شهر يبلغ متوسطه 0.4 msg/s؛ أما العميل نفسه حين يطلق عرضًا ترويجيًا إلى 200,000 رقم في التاسعة صباحًا فيحتاج إلى 100 msg/s لمدة نصف ساعة. على البوابة أن تستوعب تلك الدفقة، وأن تسلّمها إلى المشغّلين بالسرعة التي يقبلونها بها، ثم أن تلتقط إشعارات التسليم العائدة، التي تصل عند الذروة بالمعدّل نفسه الذي خرجت به الرسائل.

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

المعدّل المستدام	الحجم الشهري	الخادم	ملاحظات
~1 msg/s	حتى ~1,000,000 رسالة SMS	4 vCPU، 8 GB RAM، SSD سعة 100 GB، كل شيء على آلة واحدة	هنا يقضي معظم الموزّعين عامهم الأول
~10 msg/s	من ~1,000,000 إلى 10,000,000	8 vCPU، من 16 إلى 32 GB RAM، SSD سعة 250 إلى 500 GB	فهرس البحث وقاعدة البيانات على قرصين مستقلين، مثاليًا
~50 msg/s فأكثر	10,000,000 فأكثر	16+ vCPU، من 32 إلى 64 GB RAM، NVMe سريع، مكوّنات موزّعة على عُقد	الطابور وقاعدة البيانات والبحث وطبقة SMPP، لكلٍّ منها مساحته

أمران يفاجئان الناس في هذا الجدول. الأول: صِغَر المستوى الأول، فمنصّة كاملة متعددة المستأجرين بلوحة تحكم ويب وخادم SMPP وطابور وقاعدة بيانات وفهرس بحث تتّسع لها آلة بـ 4 vCPU، لأن أيًّا منها لا يقع تحت ضغط عند 1 msg/s. الثاني: الانتقال إلى المستوى الثالث لا يتعلّق بالمعالج. إنه يتعلّق بالإدخال والإخراج (I/O): عند 50 msg/s تكتب قاعدة البيانات سطر الرسالة، وتحدّثه حين يُقرّ المشغّل باستلامها، وتحدّثه مرة أخرى حين يصل الإشعار، وتفهرسه للبحث. ثلاث عمليات كتابة لكل رسالة عند 50 msg/s تعني 150 عملية كتابة في الثانية، بشكل مستدام، إضافة إلى القراءات من كل لوحة معلومات مفتوحة لدى العملاء. هذه مشكلة قرص، ولهذا يظهر NVMe والعُقد الموزّعة في الصف الثالث لا قبله.

سؤال الدفقة: تبدأ صغيرًا وتحتاج إلى سعة احتياطية

ثمة حالة وسطى شائعة لا يلتقطها الجدول: أنت تبدأ من الصفر، فحجمك الشهري ضئيل، لكن أول عميل لديك سلسلة مدارس أو متجر إلكتروني يرسل كل شيء في دفقة صباحية واحدة ويتوقّع أن يصل خلال دقائق. تحتاج إلى سعة احتياطية من 100 إلى 200 msg/s بينما معدّلك المستدام لا يزال دون 1 msg/s.

الحل خادم مخصّص بـ 4 إلى 8 vCPU و32 GB من RAM. يكلّف 50 إلى 100 USD شهريًا لدى المزوّدين المذكورين أدناه، ويتحمّل الدفقة لأن الأنوية ملكك ولأن RAM تُبقي الطابور ومجموعة العمل (working set) في الذاكرة، ويحملك إلى أن يبدأ الحجم المستدام وإشعارات التسليم والتقارير في التنافس على القرص نفسه. تلك هي لحظة الانتقال إلى المستوى التالي، وهي تأتي عادةً بعد العميل العاشر، لا الأول.

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

وحدات vCPU المخصّصة مقابل المشتركة

تطمس قوائم أسعار الاستضافة خطًا مهمًا. الخادم الافتراضي المشترك بـ «4 vCPU» يمنحك أربع شرائح زمنية من أنوية يستخدمها مستأجرون آخرون أيضًا؛ أما الخادم الافتراضي المخصّص بـ «4 vCPU» فيمنحك أربع أنوية هي ملكك. بالنسبة لموقع ويب، الفرق غير مرئي. أما لبوابة SMS فهو الفرق بين عرض ترويجي يصل في عشر دقائق وآخر يصل في أربعين.

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

القاعدة العملية: vCPU مشتركة للعرض التجريبي ولخادم التجهيز والاختبار (staging)، وvCPU مخصّصة لكل ما يدفع العميل ثمنه. فارق السعر في المستوى الأول من 20 إلى 40 USD شهريًا، وهو أقل من ساعة واحدة من وقتك تقضيها في أن تشرح لعميل لماذا لا يزال تقرير الأمس قيد التحديث.

ذاكرة RAM: ما الذي يقيم فعلًا في الذاكرة

احتياجات الذاكرة أسهل في التقدير. ثلاثة أشياء تحتاج إلى البقاء مقيمة في الذاكرة: الطابور (كل رسالة قُبلت ولم تُسلَّم بعد إلى مشغّل، إضافة إلى كل إشعار لم يُطابَق بعد)، ومجموعة العمل لقاعدة البيانات (رسائل الأيام القليلة الأخيرة، وقوائم الأسعار، وحسابات العملاء)، وذاكرة التخزين المؤقت لفهرس البحث. في المستوى الأول تتّسع الثلاثة معًا في 8 GB مع متّسع لنظام التشغيل ولوحة التحكم على الويب. في المستوى الثاني تنمو مجموعة العمل مع سجلّك التاريخي، و16 إلى 32 GB تُغني قاعدة البيانات عن اللجوء إلى القرص في التقارير التي يفتحها العملاء كل صباح.

ما يستنفد RAM عمليًا ليس الطابور، بل التقارير. عميل يطلب «كل الرسائل إلى هذا البلد في الربع الماضي» من قاعدة بيانات مضطرة إلى قراءة ذلك من القرص يحوّل استعلامًا يستغرق ثانيتين إلى استعلام يستغرق دقيقتين، ويُبطئ الجميع أثناء تنفيذه. إضافة RAM هي الحل الأرخص؛ أما أرشفة الرسائل القديمة في مخزن مستندات، وهو ما يفعله التصميم الموزّع للمستوى الثالث، فهي الحل الدائم.

القرص: إشعارات التسليم والأرشيف هي مصدر النمو

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

في المستوى الأول، تعني 1,000,000 رسالة شهريًا نموًا بنحو 1 GB شهريًا. قرص SSD سعة 100 GB يتّسع لسنوات من ذلك. في المستوى الثاني، تعني 10,000,000 رسالة شهريًا 10 GB شهريًا، أي 120 GB سنويًا، ويضيف فهرس البحث فوقها من 30 إلى 50 بالمئة، ولهذا يذكر الصف الثاني 250 إلى 500 GB، ولهذا يوضع فهرس البحث وقاعدة البيانات «مثاليًا» على قرصين مستقلين: فهما يتنافسان على عرض نطاق الكتابة نفسه حين يتشاركان قرصًا واحدًا.

خياران في التصميم يمنعان تحوّل ذلك إلى مشكلة. الأول: طبقة أرشيف، إذ تحتفظ قاعدة البيانات الرئيسية بالنافذة الحديثة (لنقل 90 يومًا) وتنتقل الرسائل الأقدم إلى مخزن مستندات حيث تبقى قابلة للبحث لكنها لم تعد تُبطئ جداول المعاملات. الثاني: سياسة احتفاظ تقرّرها فعلًا، فكثير من المشغّلين يحتفظون بإشعارات التسليم من 12 إلى 24 شهرًا لأغراض النزاعات ويحذفون نصوص الرسائل قبل ذلك، وبعض الأسواق تنظّم مدة الاحتفاظ، فتأكّد من القاعدة في البلدان التي ترسل إليها. المنصّة التي تأتي بطبقة أرشيف مدمجة، وهكذا رُسمت حزمة Smppcube، مع MongoDB للأرشيف إلى جانب MySQL بوصفه نظام السجلّ، تجعل الخيارين إعدادًا بدل أن يكونا مشروعًا.

الشبكة والمنافذ

عرض النطاق ليس القيد؛ فالرسالة بضع مئات من البايتات. ما يهمّ هو عنوان IP عام ثابت، لأن المشغّلين يضعون عادةً عنوان IP الخاص بارتباط SMPP (bind) لديك في قائمة سماح ولا يرحّبون بتحديثه، ومنفذ وارد مفتوح هو 2775 (أو المنفذ الذي تختاره) إذا كان عملاؤك سيرتبطون بخادم SMPP لديك. وخلف ذلك، HTTPS للوحة التحكم ولواجهة HTTP API، ووصول صادر إلى نقاط نهاية SMPP وHTTP لدى المشغّلين. إذا كنت تعمل داخل DMZ أو في بيئة معزولة شبكيًا (air-gap)، فلا تحتاج البوابة إلا إلى روابط المشغّلين وشبكة لوحة التحكم، وهذا أحد أسباب نجاح الاستضافة الذاتية في البيئات الخاضعة للتنظيم حيث لا يمكن حتى اعتماد لوحة SaaS.

قائمة مختصرة بالمزوّدين مع الأسعار

يكفي أي مزوّد يبيع vCPU مخصّصة، وتخزين SSD أو NVMe، وعنوان IP ثابتًا، ويتيح لك فتح منفذ. هؤلاء هم الذين نراهم أكثر من غيرهم. خادم مخصّص بـ 4 إلى 8 vCPU و32 GB، يغطّي المستوى الأول الجاهز للدفقات واحتياجات المستوى الثاني من المعالج وRAM، يكلّف عادةً 50 إلى 100 USD شهريًا لدى أيٍّ من الأربعة الأوائل؛ أما المستوى الثالث بأقراص NVMe وعُقد موزّعة فيخضع لعرض سعر مخصّص في كل مكان.

المزوّد	يناسب	سبب ذكره
Hetzner	أوروبا	خطط vCPU مخصّصة وخوادم مادية (bare metal) بأسعار منخفضة
Netcup	أوروبا	أنوية مخصّصة بتكلفة منخفضة؛ ونحن أنفسنا نعمل على Netcup
DigitalOcean	مناطق حول العالم	لوحة تحكم بسيطة، وتسعير متوقَّع، ولقطات (snapshots) سهلة
OVHcloud	أوروبا وأمريكا الشمالية	خوادم مادية متاحة حين تتجاوز حاجتك الآلات الافتراضية
Alibaba Cloud	المملكة العربية السعودية والخليج	مركز بيانات داخل المملكة لتوطين البيانات
عتادك الخاص	البيئات المعزولة شبكيًا أو الخاضعة للتنظيم	رسوم الاستضافة المشتركة (colocation) فقط؛ لا تحتاج البوابة شيئًا من الخارج سوى روابط المشغّلين

عبارة «نحن أنفسنا نعمل على Netcup» موجودة لأن المشترين يسألون؛ إنها بيان لما ينجح في المستويين الأولين، لا توصية بتجاهل الآخرين. راجع قوائم الأسعار الحالية قبل أن تقرّر. إذا كان عملاؤك في بلد واحد، فإن مزوّدًا لديه منطقة هناك يختصر زمن الذهاب والإياب إلى المشغّلين، والأهم من ذلك أنه يُبقي البيانات حيث تتوقّعها الجهة التنظيمية.

الفاتورة كاملة، بصدق

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

1. الترخيص، مرة واحدة: 6,400 USD للمنصّة، وكل قناة، وكل ميزة، والسنة الأولى من الدعم. هذه هي صفحة الأسعار في رقم واحد.
2. الخادم، شهريًا: 50 إلى 100 USD في المستويين الأولين، تُدفع للمزوّد الذي تختاره، في حسابك أنت، ويمكنك نقله متى شئت.
3. حركتك عبر المشغّلين، بالأسعار التي تتفاوض عليها مع SMSC الخاص بك أو مع مجمّعك. نحن لا نقف في وسطها أبدًا.

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

النسخ الاحتياطي والمراقبة والأجزاء المملّة

الخادم ليس خطة. قبل أن يبدأ أول عميل العمل الفعلي، ينبغي أن توجد ثلاثة أشياء وأن تكون مختبَرة:

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

متى لا تحتاج إلى أيٍّ من هذا

إذا كنت ترسل بضعة آلاف من الرسائل شهريًا من تطبيق واحد وليس لديك عملاء خاصّون بك، فأنت لا تحتاج إلى خادم بوابة إطلاقًا؛ فواجهة HTTP API من أي مورّد، تستدعيها من تطبيقك، هي الحجم المناسب. التحجيم في هذا الدليل موجّه لمن يبيعون المراسلة للآخرين: الموزّعين، والمجمّعين، والمشغّلين، أو شركة تشغّل المراسلة لفرق داخلية كثيرة. عند تلك النقطة يكون الخادم أقل أجزاء النشاط تكلفة، ومعرفة المستوى الذي أنت فيه، وما الذي سينقلك إلى المستوى التالي، هي معظم ما عنته كلمة «المتطلبات» في أي وقت.