10/02/2025
لقد وفرنا 76% من فواتيرنا السحابية مع زيادة قدرتنا ثلاث مرات عن طريق الانتقال إلى Hetzner من AWS وDigitalOcean.
خلفية
جميع البرامج التي نبنيها في رقميمجتمع يعمل في السحابة. قبل الترحيل، قمنا بتشغيل أعباء العمل على نظامين أساسيين:
- “AWS” سرك=”http://digitalsociety.coop/images/aws-logo.svg”>
نحن نستخدم AWS لبعض احتياجات الاستضافة الأساسية لدينا (DNS عبر”https://aws.amazon.com/route53″ الهدف=”_blank”>الطريق53 وإرسال رسائل البريد الإلكتروني عبر”https://aws.amazon.com/ses/” الهدف=”_blank”>سيس).
لقد اخترنا أيضًا AWS للاستضافة”https://tapintodata.com/” الهدف=”_blank”>اضغط، أول منتج SaaS لدينا، باستخدام مجموعة متنوعة من خدمات AWS (“https://aws.amazon.com/ecs/” الهدف=”_blank”>ECS لتنسيق الحاويات،”https://aws.amazon.com/rds/” الهدف=”_blank”> آر دي إس لقواعد البيانات العلائقية،”https://aws.amazon.com/elasticloadbalancing/application-load-balancer/” الهدف=”_blank”> ألب للدخول، وذيل طويل من الخدمات الطرفية، كما هو الحال في طريقة AWS).
لقد اخترنا AWS من أجل الألفة لأننا عملنا معها منذ ما يقرب من 15 عامًا. نحن نقدر أيضًا موثوقيتها، خاصة عندما يتعلق الأمر باستقرار واجهة برمجة التطبيقات (API). نحن نقوم بأتمتة أكبر قدر ممكن من إدارة البنية التحتية لدينا، ولا نريد قضاء الوقت في مطاردة تغييرات كسر واجهة برمجة التطبيقات.
- “DigitalOcean” سرك=”http://digitalsociety.coop/images/digitalocean-logo.svg”>
استخدمنا”https://www.digitalocean.com/products/kubernetes” الهدف=”_blank”>المحيط الرقمي Kubernetes لاستضافة العديد من الخدمات خفيفة الوزن، مثل”https://epcdata.scot/” الهدف=”_blank”>epcdata.scotوخدمات المراقبة (“https://umami.is/” الهدف=”_blank”> أومامي لتحليلات الويب،”https://openobserve.ai/” الهدف=”_blank”>فتح المراقبة للقياس عن بعد، و”https://uptime.kuma.pet/” الهدف=”_blank”> الجهوزية كوما لمراقبة التوافر).
لقد اخترنا DigitalOcean لعرض Kubernetes المُدار البسيط نسبيًا والفعال من حيث التكلفة، حيث تدفع مقابل موارد المجموعة (العقد، وتخزين الكتل، وموازنات التحميل) ولكن لوحة التحكم مجانية.
لقد اخترنا Kubernetes من أجل الألفة لأننا عملنا معه منذ ما يقرب من 10 سنوات. على الرغم من أنه يتطلب الكثير”https://github.com/digital-society-coop/runtime” الهدف=”_blank”> التكوين النموذجي، بمجرد إعداده، يتيح Kubernetes تجربة مطور سلسة لنشر التطبيقات بسرعة.
لماذا اثنين من مقدمي الخدمات السحابية؟ في البداية استخدمنا DigitalOcean فقط، ولكن SaaS كثيفة البيانات مثل Tap تحتاج إلى الكثير من الموارد السحابية وتتمتع AWS بثروة سخية”https://aws.amazon.com/startups/credits#packages” الهدف=”_blank”> رصيد بقيمة 1000 دولار حزمة للشركات الناشئة الممولة ذاتيا. يتيح لنا الاستفادة من أرصدة AWS تجربة احتياجات البنية التحتية لدينا دون القلق بشأن التكلفة.
الاعتمادات لا تدوم إلى الأبد
انطلاقًا من روح تقليل تكاليفنا التشغيلية، اخترنا استخدام وقت تشغيل الحاوية بدون خادم من AWS،”https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html” الهدف=”_blank”>فارجيت. يتيح لنا ذلك الدفع في الثانية لوحدة المعالجة المركزية والذاكرة التي يستخدمها تطبيقنا. ينخفض تسعير Fargate الشهري بشكل جيد إلى حد ما، مع الحد الأدنى من عبء العمل (0.25 وحدة المعالجة المركزية، 0.5 غيغابايت من ذاكرة الوصول العشوائي) بتكلفة حوالي 10 دولارات شهريًا.
ومع ذلك، فإن Tap عبارة عن SaaS كثيفة البيانات ويجب أن تكون قادرة على تنفيذ استعلامات معقدة عبر غيغابايت من البيانات في ثوانٍ. بالرغم من أننا نستخدم السرعة الفائقة”https://www.rust-lang.org/” الهدف=”_blank”> الصدأ لغة البرمجة وتقنيات البيانات الحديثة والفعالة مثل”https://arrow.apache.org/” الهدف=”_blank”> سهم أباتشي و”https://datafusion.apache.org/” الهدف=”_blank”> داتا فيوجن، لقد وجدنا أن الحد الأدنى لمتطلبات الموارد للأداء الجيد هو حوالي 2x وحدات المعالجة المركزية (CPUs) وذاكرة الوصول العشوائي (RAM) سعة 4 جيجا بايت – ومن الأفضل أن يكون أكثر من ذلك للحصول على تجربة جيدة للاستعلامات كثيرة المتطلبات.
ما هي تكلفة وحدة المعالجة المركزية 2x وحاوية ذاكرة الوصول العشوائي سعة 4 جيجا بايت على AWS Fargate؟ ما يزيد قليلاً عن 70 دولارًا في الشهر. نحن ندير مثيلين عاملين، يحتاجان إلى هذه الموارد الأعلى، جنبًا إلى جنب مع مثيلات الويب الأصغر وجميع البنية التحتية الأخرى اللازمة لاستضافة تطبيق على AWS (موازن التحميل، قاعدة البيانات العلائقية، بوابة NAT، …). معًا، ارتفع إجمالي تكاليفنا لبيئتين من الصنبور إلى 449.50 دولارًا شهريًا.
في النهاية، استخدمنا أرصدتنا المجانية في أقل من 6 أشهر، وباعتبارنا شركة ناشئة ذات موارد محدودة، فإن استيعاب هذا النوع من تكلفة التشغيل أمر مؤلم.
دراسة البدائل
في مواجهة تكاليف التشغيل المرتفعة هذه، بدأنا في التحقيق في موفري الخدمات السحابية البديلة. وفي الوقت نفسه تقريبًا، جعلتنا حروب التعريفات الجمركية ونمو الإقطاع التكنولوجي المدعوم بالذكاء الاصطناعي نبحث عن ما هو محدد على وجه التحديد”https://european-alternatives.eu/” الهدف=”_blank”> مقرها في المملكة المتحدة أو الاتحاد الأوروبي مقدمي الخدمات السحابية.
لقد صادفنا بسرعة”https://www.hetzner.com/cloud/” الهدف=”_blank”> هيتزنر، وعلى الرغم من أن عروضهم موجهة نحو VPS المُدار ذاتيًا، مما يعني صيانة إضافية مقارنة بالحلول المُدارة، فقد تم إقناعنا بأسعارهم (مزيد من التفاصيل لاحقًا). لدرجة أننا قررنا ترحيل البنية التحتية الرقمية الخاصة بنا أيضًا.
نظرًا لأن معظم خدماتنا كانت تعمل بالفعل في Kubernetes، وكان Tap يعتمد بالفعل على الحاويات، فقد قررنا تشغيل Kubernetes. إن تشغيل مجموعات Kubernetes قبل ذلك لم يكن قرارًا تم اتخاذه بسهولة، لكننا اكتشفنا ذلك”https://www.talos.dev/” الهدف=”_blank”> تالوس لينكس والتي وعدت بتبسيط إعداد المجموعة وصيانتها.
استخدمت مجموعات Kubernetes الموجودة لدينا في DigitalOcean”https://github.com/digital-society-coop/runtime” الهدف=”_blank”> وقت التشغيل التي أنشأناها لتغطية احتياجات البنية التحتية الأساسية لتطبيقات الويب. بالإضافة إلى ميزات تنسيق الحاويات الأصلية في Kubernetes، غطت هذه الميزات جميع الوظائف التي كنا نستخدمها في AWS وDigitalOcean باستثناء قواعد بيانات PostgreSQL المُدارة. ونظرًا لأن هذه الأجزاء بالغة الأهمية من البنية التحتية، فقد أردنا حلاً قويًا يتضمن مراقبة تفصيلية وتجاوز الفشل التلقائي والترقيات السلسة والنسخ الاحتياطية المجدولة. وجدنا”https://cloudnative-pg.io/” الهدف=”_blank”>CloudNativePG الذي يضع علامة على كل صناديقنا.
المكدس الجديد
وإجمالاً، هذه هي المجموعة التي وصلنا إليها:
- هيتزنر كمزود البنية التحتية الأساسية. نحن نستخدم خوادمهم السحابية vCPU المشتركة من ARM، ووحدات تخزين الكتل، وموازنات التحميل، والشبكات، وجدران الحماية، وتخزين الكائنات المتوافقة مع S3.
- تالوس لينكس كنظام تشغيل للخوادم السحابية. يتيح لك Talos إدارة عقد Kubernetes بطريقة مشابهة لموارد Kubernetes، من خلال تطبيق التكوين التعريفي الذي يحدد نظام التشغيل من خلاله التغييرات الفعلية (إن وجدت) التي سيتم إجراؤها على العقدة.
- CloudNativePG يملأ دور خدمة قاعدة البيانات المُدارة (مثل RDS) للمجموعة. يمكن الإعلان عن مجموعات PostgreSQL في بيانات Kubernetes جنبًا إلى جنب مع أعباء العمل التي تستخدمها، ويمكن تهيئتها باستخدام النسخ الاحتياطية المجدولة، والنسخ المتماثلة لتجاوز الفشل، وتجاوزات التكوين، وما إلى ذلك.
- دخول وحدة تحكم NGINX يملأ دور موازن التحميل المُدار أو بوابة API للمجموعة، مما يؤدي إلى دمج مسارات الدخول المعلنة بواسطة أحمال العمل وإتاحتها.
- DNS الخارجي يسمح بربط أسماء DNS بموارد الدخول. تقريبًا، يقوم Ingress NGINX Controller بإدارة توجيه HTTP في المجموعة بينما يقوم ExternalDNS بمعالجة التوجيه ل الكتلة.
- مدير الشهادات ينشئ شهادات TLS لتأمين مسارات عبء العمل باستخدام HTTPS.
يتم تقنين جميع البنية التحتية باستخدام”https://developer.hashicorp.com/terraform” الهدف=”_blank”> تيرافورم و”https://helm.sh/” الهدف=”_blank”> خوذة مع عمليات النشر الآلية من خلال”https://docs.github.com/en/actions” الهدف=”_blank”> إجراءات جيثب.
ما المدخرات
ليس من السهل إجراء مقارنة شاملة بين موفري الخدمات السحابية نظرًا لأنهم يميلون إلى الاختلاف في الميزات (تقنية أو تعاقدية، مثل اتفاقيات مستوى الخدمة)، ولكن نقطة المقارنة السهلة هي فاتورتنا الشهرية:
AWS وDigitalOcean*
559.36 دولار
* بناءً على مبلغ الفاتورة الأقصى. من الناحية الفنية، بلغت DigitalOcean ذروتها في يوليو (109.86 دولارًا) قبل أن نبدأ عملية الترحيل. بلغت AWS ذروتها في أغسطس (449.50 دولارًا) منذ أن قمنا بترحيل النقر لاحقًا.
نحصل على سعة أكبر بكثير لهذا السعر أيضًا:
AWS وDigitalOcean
12 وحدات المعالجة المركزية الافتراضية
24 جيجا بايت كبش
هيتزنر*
44 وحدات المعالجة المركزية الافتراضية +367%
88 جيجا بايت كبش +367%
* هذه مجرد السعة المتاحة لأحمال العمل، مع استبعاد طائرات التحكم (6 وحدات معالجة مركزية افتراضية إضافية و12 جيجا بايت من ذاكرة الوصول العشوائي).
التحديات
هناك الكثير من الإيجابيات، لكن الهجرة لم تكن دائمًا واضحة. إن عقاراتنا السحابية صغيرة في المخطط الكبير للأشياء، ولكن كانت هناك تحديات حتماً.
مناطق شبكة Hetzner ليست معادلة لمناطق توافر AWS.
تعتمد طوبولوجيا AWS على”https://aws.amazon.com/about-aws/global-infrastructure/regions_az/” الهدف=”_blank”>المناطق ومناطق التوفر. عادةً ما تكون البنية الأساسية الخاصة بك موجودة في منطقة واحدة، ولكن سيتم تقسيمها عبر مناطق التوفر من أجل التسامح مع الأخطاء. ومن الجدير بالذكر أن الشبكات الخاصة تشمل جميع أنحاء المنطقة (أي يمكن للخوادم الموجودة في مناطق توافر مختلفة الاتصال بسهولة عبر الشبكات الخاصة).
تعتمد طوبولوجيا هيتزنر على”https://docs.hetzner.com/cloud/general/locations/” الهدف=”_blank”> المواقع ومناطق الشبكة. هناك منطقة شبكة واحدة فقط في الاتحاد الأوروبي، eu-central، والتي لديها 3 مواقع. نظرًا لأن الخوادم الموجودة في مواقع مختلفة في نفس منطقة الشبكة يمكنها الاتصال عبر شبكات خاصة، فقد قمنا بمعادلتها بمناطق توافر خدمات AWS.
في الواقع، هناك زمن استجابة كبير بين مواقع Hetzner مما يجعل تشغيل أعباء العمل متعددة المواقع أمرًا صعبًا، ومن المحتمل أن يكون ضارًا بالأداء كما اكتشفنا من خلال مراقبة ما بعد النشر.
وبدلاً من ذلك، اخترنا استخدام موقع واحد (نورمبرغ) واستخدامه”https://docs.hetzner.com/cloud/placement-groups/overview” الهدف=”_blank”> مجموعات المواضع لتحسين المرونة. تضمن مجموعات المواضع تشغيل الخوادم الافتراضية في نفس المجموعة على خوادم فعلية مختلفة، مما يقلل بشكل كبير من احتمال فشلها معًا.
لا يعني كون الخدمة قائمة على عامل الإرساء أنه سيكون من السهل ترحيلها.
في AWS، قمنا بنشر منتج SaaS الخاص بنا، انقر فوق، في وقت تشغيل حاوية Elastic Container Service (ECS). وهذا يعني أننا كنا نبني وندفع الحاويات بالفعل كجزء من البناء الآلي وكنا نتوقع أن ترحيل بقية التكوين من ECS CloudFormation إلى بيانات Kubernetes لن يكون شاقًا للغاية.
لسوء الحظ لم يتم النظر في أتمتة النشر حول التكوين. على وجه الخصوص، كان لدينا نصوص برمجية لجمع التكوين الصحيح من GitHub وتمريره إلى CloudFormation. لم تكن الصعوبة في تكييف البرامج النصية مع Kubernetes، بل في أننا لم نتوقع العمل ولذلك استغرق هذا الجزء من الترحيل وقتًا أطول مما توقعنا.
في النهاية استخدمنا”https://kustomize.io/” الهدف=”_blank”>تخصيص كما يظهر الغراء بين التكوين الحساس في GitHub وKubernetes الخاص بنا. لقد قمنا بنقل التكوين غير الحساس الخاص بنا من إعدادات GitHub إلى ملفات التكوين في الريبو نفسه نظرًا لأن هذا يعمل بسهولة أكبر مع Kustomize. كما أنه يجعل تتبع ومراجعة التغييرات على هذه الإعدادات أسهل، لذلك نحن سعداء بالنتيجة.
الاستنتاجات
تعتبر Hetzner مزودًا سحابيًا فعالاً من حيث التكلفة بشكل لا يصدق. على الرغم من أن عروضهم أقل اتساعًا وعدم التدخل من AWS أو DigitalOcean’s، فمن الممكن التخفيف من ذلك باستخدام مجموعتك إذا كنت لا تمانع في إتلاف يديك.
نحن سعداء بشكل خاص لأن هذا سيسمح لنا بالاحتفاظ به”https://tapintodata.com/” الهدف=”_blank”>اضغط يعمل بتكلفة زهيدة والأداء بينما نقوم بتطويره وإطلاقه.