تحسين تكاليف السحابة: دليل عملي للشركات الناشئة

• 1. فهم فاتورتك قبل محاولة تحسينها
• 2. تحديد الحجم الصحيح لموارد الحوسبة
• 3. السعة المحجوزة وخطط التوفير
• 4. الخوادم الفورية والمسبقة
• 5. التخزين: من التسرب البطيء إلى الكارثة
• 6. قواعد البيانات المدارة
• 7. Kubernetes والحاويات
• 8. الشبكات ونقل البيانات
• 9. البنية التحتية ككود
• 10. بناء ثقافة هندسية واعية بالتكلفة
• العائد المركب على الانضباط في البنية التحتية

في اليوم الأول من الشهر، يأتي نوع من الخوف الخاص بمؤسس شركة ناشئة أو قائد هندسي. تصل فاتورة السحابة، وهي أعلى من الشهر الماضي، ولا يمكن لأحد في الفريق أن يشرح السبب فورًا. تغوص في وحدة التحكم، وتفحص النفقات بندًا بندًا، وفي النهاية تجد بعض المذنبين؛ خادم كبير لم يمسه أحد منذ ستة أسابيع، بيئة اختبار منسية تعمل بكامل طاقتها، خط بيانات يسكب البيانات في دلو لم يتم استجوابه منذ التغيير الأخير في المنتج.

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

بالنسبة للشركات الناشئة في مراحلها المبكرة، هذا الأمر أكثر أهمية بكثير مقارنة بالشركات الكبيرة. بالنسبة لشركة في قائمة Fortune 500، فإن إنفاق 50,000 دولار شهريًا على السحابة بلا جدوى هو عدم كفاءة. ولكن بالنسبة لشركة ناشئة في مرحلة السلسلة A التي تستهلك مدرجها بسرعة، فإن هذا يمثل مشكلة استراتيجية حقيقية. يؤثر بشكل مباشر على المدة التي يمكنك العمل بها، ومن يمكنك توظيفه، وما هي المخاطر التي يمكنك تحملها. الانضباط في تكاليف السحابة ليس مجرد مسألة مالية أو مجرد مجال DevOps. إنه جزء أساسي من كيفية إدارة شركتك.

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

1. فهم فاتورتك قبل محاولة تحسينها

يبدو هذا واضحًا. لكنه ليس كذلك. معظم فرق الهندسة في الشركات الناشئة على دراية تقريبية بإجمالي الإنفاق الشهري على السحابة، ولديهم فكرة غامضة عن مصدره، وليس لديهم تقريبًا أي فكرة عن أي خدمات أو ميزات أو بيئات محددة مسؤولة عن اتجاهات التكلفة بمرور الوقت. هذا ليس إهمالًا، إنه مجرد الوضع الافتراضي عندما لا يقوم أحد بوضوح بإعداد البنية التحتية للإجابة على هذه الأسئلة.

لتحسين أي شيء، تحتاج أولاً إلى رؤية. رؤية حقيقية، مفصلة، ومنسوبة للفريق.

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

بدون علامات، أنت تنظر إلى رقم واحد وتخمن. مع العلامات، لديك مجموعة بيانات منظمة يمكنك فعلاً التفكير فيها. قم بإنشاء مخطط وضع العلامات من اليوم الأول؛ البيئة (prod، staging، dev)، الفريق أو المجموعة، الخدمة أو الميزة، ومركز التكلفة هي الأبعاد الأكثر فائدة، وفرض ذلك في كود البنية التحتية الخاص بك بحيث يتم دائمًا وضع علامات صحيحة على الموارد الجديدة.

لوحات الفوترة وتنبيهات الشذوذ هي تأمين مجاني. كل مزود سحابي يقدم أدوات إدارة التكلفة المحلية بدون تكلفة إضافية (AWS Cost Explorer، GCP Cost Management، Azure Cost Analysis). قم بإعداد تنبيهات الميزانية عند 50٪ و75٪ و90٪ من هدفك الشهري. قم بتكوين اكتشاف الشذوذ ليتم إعلامك عندما تزيد النفقات بشكل غير متوقع في أي خدمة. هذه الأدوات لن تخبرك لماذا شيء ما مكلف، لكنها ستخبرك متى يكون مكلفًا، والتوقيت مهم للغاية. المشكلة التي يتم اكتشافها في اليوم الثاني من الشهر تكلف أقل بكثير من المشكلة التي تكتشفها في اليوم الثلاثين.

راجع أكبر عشرة بنود إنفاق لديك وافهم كل واحد منها. في معظم الشركات الناشئة في المراحل المبكرة، تشكل أربع إلى ست خدمات 80-90٪ من الفاتورة الإجمالية: EC2 أو الحوسبة المكافئة، RDS أو قاعدة البيانات المدارة المكافئة، S3 أو التخزين الكائني المكافئ، نقل البيانات (الخروج)، وربما خدمة حاويات مدارة أو مجموعة Kubernetes. تعرف على ما يفعله كل واحد، ولماذا هو مكلف، وما الذي يبدو عليه المستوى الأساسي المعقول. كل شيء آخر هو السياق.

2. تحديد الحجم الصحيح لموارد الحوسبة

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

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

قبل إجراء أي تغييرات، اسحب مقاييس الاستخدام الخاصة بك. انظر إلى متوسط استخدام وحدة المعالجة المركزية والذاكرة لكل خادم يعمل خلال الثلاثين يومًا الماضية. انظر إلى المتوسط، وليس الذروة. الخادم الذي يعمل بمتوسط استخدام وحدة معالجة مركزية بنسبة 8-12٪ ويصل أحيانًا إلى 35٪ لا يحتاج إلى أن يكون بهذا الحجم. يقدم معظم مزودي السحابة توصيات تحديد الحجم الصحيح مباشرة في وحدات تحكم التكلفة الخاصة بهم؛ استخدمها كنقطة انطلاق، تحقق من صحة بيانات الاستخدام الفعلية الخاصة بك، وكن مستعدًا للذهاب إلى ما هو أبعد من التوصية.

افصل بين بيئات الإنتاج وغير الإنتاج. هذا هو أحد أكثر التغييرات فعالية التي يمكن أن تقوم بها معظم الشركات الناشئة، ولا يتطلب تقريبًا أي عمل معماري. لا تحتاج بيئات التطوير والتدريج إلى العمل بكامل طاقتها الإنتاجية على مدار الساعة طوال أيام الأسبوع. يعمل المهندسون عادةً 10 ساعات في اليوم، 5 أيام في الأسبوع. وهذا يعني أن البنية التحتية غير الإنتاجية تكون خاملة حوالي 70٪ من الوقت.

قم بتطبيق جداول الإيقاف التلقائي. باستخدام دالة Lambda، أو وظيفة Cloud Scheduler، أو برنامج نصي يتم تشغيله بواسطة cron بسيط، قم بإيقاف أمثلة غير الإنتاج في المساء وإعادة تشغيلها في الصباح. ضع علامات على بيئاتك بشكل صحيح حتى تتمكن من تطبيق ذلك بشكل انتقائي. بيئة التدريج التي تعمل فقط خلال ساعات العمل تعمل بتكلفة حوالي 30٪ مقارنة ببيئة تعمل على مدار الساعة طوال أيام الأسبوع، وإذا كان وقت بدء التشغيل مقبولًا (عادة أقل من دقيقتين)، فإن التأثير على تجربة المطور يكون ضئيلًا.

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

عائلات الأمثلة أكثر أهمية من أحجام الأمثلة. تقوم AWS وGCP وAzure بانتظام بإصدار عائلات أمثلة جديدة تقدم أداءً أفضل من حيث السعر مقارنة بالأجيال القديمة. الأمثلة المحسنة للمعالج أو الأغراض العامة من الجيل الأحدث تكون دائمًا تقريبًا أرخص لكل وحدة من الجيل السابق؛ أحيانًا يصل الفرق إلى 10-20٪. إذا كنت تقوم بتشغيل أمثلة من عائلة أقدم من جيلين، فمن المحتمل أن يكون هناك خيار أفضل. راجع هذا على الأقل مرة في السنة.

3. السعة المحجوزة وخطط التوفير: القرار الأعلى عائدًا

إذا كانت شركتك الناشئة تعمل منذ أكثر من ستة أشهر، ولديها قاعدة حوسبة ثابتة تحتاجها للمستقبل المنظور، وتدفع أسعار الطلب (on-demand) لهذه القاعدة، فأنت ترتكب خطأ مكلفًا. هذا ليس استثناءً. هذا هو الخطأ الأكثر شيوعًا والأكثر تكلفة الذي ترتكبه الشركات الناشئة في إدارة السحابة.

التسعير عند الطلب مصمم لأعباء العمل التي لا يمكن التنبؤ بها حقًا. تدفع مبلغًا إضافيًا مقابل القدرة على زيادة الموارد أو تقليلها بسرعة بدون التزام. هذه الرسوم الإضافية منطقية لأعباء العمل المتغيرة وغير المؤكدة. بالنسبة للبنية التحتية الأساسية التي تعمل دون تغيير لمدة عام، فهي لا معنى لها على الإطلاق.

الأمثلة المحجوزة وخطط التوفير تقلل تكاليف الحوسبة بنسبة 40-70٪ مقارنة بالاستخدام عند الطلب، اعتمادًا على مدة الالتزام وهيكل الدفع. عادةً ما يكون الالتزام لمدة عام بدون دفعة مقدمة أرخص بنسبة 30-40٪ مقارنة بالاستخدام عند الطلب. الالتزام لمدة ثلاث سنوات مع دفعة مقدمة جزئية أو كاملة يمكن أن يوفر ما يصل إلى 60-70٪. بالنسبة لشركة ناشئة تنفق 20,000 دولار شهريًا على EC2، فإن نقل الاستخدام الأساسي إلى أمثلة محجوزة يعني توفير 8,000-14,000 دولار شهريًا. هذا ليس رقمًا يمكن تجاهله.

النهج العملي: حدد الحد الأدنى من احتياجات الحوسبة الأساسية لديك؛ أي، القاعدة التي تعمل في الساعة 3 صباحًا يوم الأحد الهادئ بغض النظر عن الحركة أو الحمل. يجب أن تغطي هذه القاعدة بالسعة المحجوزة. كل شيء فوق ذلك (الارتفاعات المفاجئة، انفجارات الحركة، إطلاق الميزات الجديدة) يجب أن يبقى عند الطلب أو فوريًا. بهذه الطريقة، تحتفظ بالمرونة عند الطلب لكل شيء متغير، بينما تستفيد من كفاءة التكلفة للالتزامات.

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

خطط التوفير مقابل الأمثلة المحجوزة: تقدم خطط التوفير من AWS مرونة أكبر مقارنة بالأمثلة المحجوزة التقليدية؛ تنطبق على أي استخدام EC2 داخل عائلة معينة، بغض النظر عن نوع المثال أو المنطقة أو نظام التشغيل. بالنسبة لمعظم الشركات الناشئة، تكون خطط التوفير أسهل في الإدارة وتكاد تكون فعالة من حيث التكلفة. إذا كانت بنيتك التحتية مستقرة نسبيًا ومحددة جيدًا، يمكن أن توفر الأمثلة المحجوزة لأنواع أمثلة معينة بضع نقاط مئوية إضافية من التوفير.

PlusClouds وتحسين تكاليف السحابة:

توقف عن التخمين في التزامات الأمثلة المحجوزة.

PlusClouds يحلل عادات الاستخدام السابقة الخاصة بك ويخبرك بالضبط بكمية السعة المحجوزة التي يجب عليك شراؤها — مفصلة حسب عائلة المثال، المنطقة، وطول المدة. العملاء الذين يستخدمون توصيات الالتزام من PlusClouds يوفرون في المتوسط 41٪ في تكاليف الحوسبة. يعمل على AWS Reserved Instances، Azure Reserved VMs، وGCP Committed Use Discounts.

شاهد كيف يعمل على plusclouds.com

4. الأمثلة الفورية والمسبقة: خصم 90٪ لأعباء العمل الصحيحة

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

الأمثلة الفورية تعمل على السعة الاحتياطية لمزود السحابة. تقوم بتقديم عرض لهذه السعة (أو في AWS الحديثة، تطلبها بالسعر الفوري الحالي) وتستخدمها حتى يحتاج مزود السحابة إلى السعة مرة أخرى؛ في هذه المرحلة، تحصل على تحذير لمدة دقيقتين قبل الإنهاء. الخصم المقدم لهذا الإزعاج: يصل إلى 90٪ مقارنة بأسعار الطلب.

بالنسبة لأعباء العمل التي يمكن مقاطعتها أو إعادة تشغيلها، فإن هذا يعني المال المجاني بشكل أساسي. تشمل الفئات التي تعمل فيها الأمثلة الفورية بسلاسة: عمال خطوط CI/CD (إذا تم مقاطعة وظيفة بناء، يقوم العامل بالاستلام مرة أخرى)، معالجة البيانات المجمعة وخطوط ETL (احفظ تقدمك واستمر)، وظائف تدريب التعلم الآلي (تدعم معظم الأطر نقاط التحقق)، التحليلات الليلية أو إنشاء التقارير، اختبار التحميل، والخدمات الويب عديمة الحالة التي يتم توجيهها بواسطة موازن تحميل (يتم إدارة إنهاء المثال بسلاسة عن طريق توجيه الحركة إلى الآخرين).

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

استخدم استراتيجية أمثلة مختلطة للحصول على أفضل النتائج. استخدم الفورية لكل شيء يمكن مقاطعته، والطلب للخدمات عديمة الحالة التي تحتاج إلى موثوقية، والأمثلة المحجوزة لقاعدتك الثابتة. تشغيل CI/CD الخاص بك على أمثلة فورية فقط يمكن أن يقلل من تكاليف بنية البناء التحتية بنسبة 80٪ مع الحد الأدنى من التعقيد التشغيلي.

5. التخزين: من التسرب البطيء إلى الكارثة

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

يبدو أن تسعير التخزين الكائني رخيص، 0.023 دولار لكل جيجابايت في الشهر في S3 Standard. ولكن مع زيادة الحجم أو تراكم البيانات الكافية، يرتفع هذا المبلغ. الأهم من ذلك، أن العديد من الشركات الناشئة تخزن البيانات في الطبقة الخاطئة: يتم الاحتفاظ بكل شيء في Standard على الرغم من أن معظم البيانات نادرًا ما يتم الوصول إليها أو لا يتم الوصول إليها أبدًا، لأن لا أحد قام بإعداد قواعد لنقل البيانات تلقائيًا.

سياسات دورة الحياة ليست اختيارية. يجب أن تكون أول شيء تقوم بتكوينه عند إنشاء دلو تخزين، وليس شيئًا تقوم بتحسينه لاحقًا. حدد قواعد لنقل الكائنات إلى التخزين النادر الوصول بعد 30 أو 60 يومًا من عدم الوصول، ونقلها إلى Glacier أو Archive بعد 90 أو 180 يومًا، وحذفها في نهاية فترة الاحتفاظ المحددة. بالنسبة لملفات السجل، تكون فترة الاحتفاظ عادةً 30-90 يومًا. بالنسبة للنسخ الاحتياطية، تعتمد هذه الفترة على متطلبات الامتثال الخاصة بك. بالنسبة للبيانات الخام من الميزات المهملة، يكون الجواب غالبًا "احذف بعد 6 أشهر".

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

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

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

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

6. قواعد البيانات المدارة: قوية، مكلفة، وغالبًا ما تكون مفرطة التخصيص

خدمات قواعد البيانات المدارة مثل RDS وCloud SQL وAzure Database هي من بين أكثر الخدمات قيمة التي تقدمها مزودات السحابة؛ فهي تدير النسخ الاحتياطية، والتحديثات، وتحمل الأخطاء، والمراقبة بطرق تتطلب خلاف ذلك خبرة تشغيلية كبيرة. في الوقت نفسه، غالبًا ما تكون ثاني أو ثالث أكبر بند في فاتورة السحابة لشركة ناشئة، وهي دائمًا تقريبًا محددة الحجم لتحمل عبء عمل مستقبلي بدلاً من العبء الحالي.

مثال RDS عالي التوفر متعدد المناطق مع نسخ قراءة و500 جيجابايت من IOPS الموفرة هو الإجابة الصحيحة لمنتج يقوم بملايين المعاملات يوميًا. ولكن بالنسبة لشركة ناشئة لديها 10,000 مستخدم نشط وMRR بقيمة 50,000 دولار شهريًا، فإن هذا يمثل استثمارًا مفرطًا كبيرًا. الميزات التي تدفع مقابلها (التكرار المتزامن، تحمل الأخطاء التلقائي، عرض النطاق الترددي الموفرة) قيمة، لكنك تدفع مقابلها لمقياس لم تصل إليه بعد.

قم بمطابقة طبقة قاعدة البيانات الخاصة بك مع المتطلبات الحقيقية اليوم، وليس الأهداف بعد 18 شهرًا. يمكنك دائمًا التوسع؛ التوسع عادةً ما يكون بسيطًا ويمكن القيام به مع الحد الأدنى من التعطيل في معظم خدمات قواعد البيانات المدارة. الأموال التي ستوفرها الآن من خلال تشغيل مثال AZ واحد أو فئة مثال أصغر هي أموال حقيقية يمكن استخدامها للنمو.

خيارات قواعد البيانات بدون خادم لا تحظى بتقدير كافٍ للمنتجات في المراحل المبكرة. حلول مثل Aurora Serverless v2 وPlanetScale وFirestore تقوم بتوسيع سعة المعالجة بناءً على حالة الحمل الفعلية ويمكن أن تنخفض إلى ما يقرب من الصفر عندما تكون خاملة. بالنسبة لقواعد البيانات التطويرية، والأدوات الداخلية ذات الحركة المنخفضة، والميزات ذات أنماط الوصول غير المتوقعة، يمكن أن تقلل قواعد البيانات بدون خادم التكاليف بشكل كبير مقارنة بالأمثلة المخصصة التي تعمل بحد أدنى من السعة بغض النظر عن الحمل.

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

7. Kubernetes والحاويات: قوة تتطلب انضباطًا

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

طلبات الموارد والحدود إلزامية في كل pod. عندما لا يتم تحديد طلبات الموارد لـ pod، لا يملك مجدول Kubernetes أي معلومات لاتخاذ قرار بشأن مكان وضعه. النتيجة غالبًا ما تكون وضع حاويات غير فعال، عقد تبدو "ممتلئة" ولكن لديها سعة غير مستخدمة بشكل كبير، أو عقد محملة بشكل زائد لأن الطلبات لا تعكس الاستخدام الفعلي. قم بضبط طلبات وحدة المعالجة المركزية والذاكرة بناءً على الاستخدام الملاحظ، وليس التقديرات. قم بتعيين الحدود لمنع العمليات الخارجة عن السيطرة التي يمكن أن تؤثر على جيرانها.

استخدم أدوات التوسيع التلقائي التي يقدمها النظام البيئي. Horizontal Pod Autoscaler (HPA) يقوم بتوسيع عدد نسخ pod بناءً على وحدة المعالجة المركزية أو الذاكرة أو المقاييس المخصصة. Vertical Pod Autoscaler (VPA) يقوم بتعديل طلبات الموارد تلقائيًا بناءً على الاستخدام الملاحظ. Cluster Autoscaler وKarpenter الأحدث يقومان بإضافة أو إزالة عقد من الكتلة تلقائيًا بناءً على طلبات pod المعلقة. هذه الأدوات يمكن أن تزيد بشكل كبير من استخدام الكتلة، لكنها تحتاج إلى طلبات موارد صحيحة لتعمل بشكل جيد؛ لذلك فإن هذا الأساس مهم للغاية.

تحديد حجم العقدة مهم بقدر أهمية تحديد حجم pod. نوع المثال الذي تختاره لمجموعة عقد Kubernetes يؤثر على الأداء والتكلفة. قم بمراجعة ما إذا كانت أنواع العقد الحالية الخاصة بك مناسبة لملف العمل الفعلي الخاص بك: تستفيد أعباء العمل الثقيلة في الحوسبة من الأمثلة المحسنة للحوسبة؛ تستفيد أعباء العمل الثقيلة في الذاكرة من الأمثلة المحسنة للذاكرة. مجموعة تتكون من أمثلة للأغراض العامة تعمل بشكل رئيسي على أعباء العمل المرتبطة بالذاكرة تدفع مقابل سعة وحدة المعالجة المركزية التي لا يتم استخدامها أبدًا.

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

8. الشبكات ونقل البيانات: بند ميزانية غير مرئي

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

فكر بعناية في حركة المرور بين AZ داخل منطقة واحدة. تفرض معظم مزودي السحابة رسومًا على البيانات المنقولة بين مناطق التوافر (AZ) داخل نفس المنطقة. في المعماريات التي تقوم باتصالات مكثفة بين الخدمات (الميكروخدمات التي تستدعي بعضها البعض، الخدمات التي تقرأ من ذاكرة التخزين المؤقت، العمال الذين يستهلكون البيانات من الطوابير)، يمكن أن تصبح نقل البيانات من AZ إلى AZ تكلفة كبيرة. وضع الخدمات التي تتواصل بكثافة في نفس AZ يمكن أن يكون حلاً؛ استخدام موازنة تحميل مدركة لـ AZ التي تفضل الأمثلة المحلية هو حل آخر.

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

فكر بعناية في حركة المرور بين AZ داخل منطقة واحدة. تفرض معظم مزودي السحابة رسومًا على البيانات المنقولة بين مناطق التوافر (AZ) داخل نفس المنطقة. في المعماريات التي تقوم باتصالات مكثفة بين الخدمات (الميكروخدمات التي تستدعي بعضها البعض، الخدمات التي تقرأ من ذاكرة التخزين المؤقت، العمال الذين يستهلكون البيانات من الطوابير)، يمكن أن تصبح نقل البيانات من AZ إلى AZ تكلفة كبيرة. وضع الخدمات التي تتواصل بكثافة في نفس AZ يمكن أن يكون حلاً؛ استخدام موازنة تحميل مدركة لـ AZ التي تفضل الأمثلة المحلية هو حل آخر.

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

راجع بنية VPC الخاصة بك بحثًا عن فخاخ الخروج. تكاليف بوابة NAT هي مفاجأة شائعة. كل بايت من البيانات يخرج من شبكة فرعية خاصة إلى الإنترنت يمر عبر بوابة NAT، ويتم تحصيل رسوم لكل ساعة ولكل جيجابايت. إذا كانت خدماتك تقوم بإجراء مكالمات API خارجية بشكل متكرر، أو معالجة مجموعات بيانات كبيرة من مصادر خارجية، أو إجراء تنزيلات حزم مكثفة أثناء البناء، يمكن أن تتراكم رسوم بوابة NAT بسرعة. نقاط نهاية VPC لخدمات AWS (S3، DynamoDB، وغيرها) توجه الحركة داخل شبكة AWS، مما يسمح لك بتجنب رسوم بوابة NAT تمامًا لتلك الخدمات.

9. البنية التحتية ككود: يبدأ الانضباط في التكلفة عند النشر

إحدى أكثر الطرق فعالية للسيطرة على تكاليف السحابة هي أخذ التكلفة في الاعتبار أثناء توفير البنية التحتية، وليس تركها كعملية تدقيق بعد أشهر. أدوات البنية التحتية ككود (IaC) (Terraform، Pulumi، AWS CDK، وغيرها) هي الآلية التي تجعل ذلك ممكنًا.

عندما يتم تعريف كل البنية التحتية بالكود ويتم مراجعتها من خلال عملية طلب سحب قياسية، تصبح التأثيرات التكلفة مرئية قبل إنشاء الموارد. يمكن للمراجع أن ينظر إلى تغيير Terraform يضيف مثال RDS جديدًا ويسأل: هل يجب أن يكون هذا متعدد المناطق حقًا؟ ما هي فترة الاحتفاظ بالنسخ الاحتياطية؟ هل فئة المثال هذه مناسبة للحمل المتوقع؟ هذه المحادثات رخيصة في مرحلة المراجعة، لكنها مكلفة لاحقًا.

فرض وضع العلامات من خلال السياسة. أدوات مثل OPA (Open Policy Agent)، Sentinel، أو أطر السياسة السحابية الأصلية (AWS Service Control Policies، GCP Organization Policies) يمكن أن ترفض تغييرات البنية التحتية التي لا تحتوي على تسميات تخصيص التكلفة المطلوبة. هذا يضمن أن الموارد الجديدة تكون دائمًا قابلة للتتبع من اللحظة التي يتم إنشاؤها فيها، ويزيل الاعتماد على الأفراد لتذكر مخطط وضع العلامات.

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

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

10. بناء ثقافة هندسية واعية بالتكلفة

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

هذا سؤال تقني بقدر ما هو ثقافي وعملي.

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

قم بنشر لوحات التكلفة في نفس القنوات التي تشارك فيها مقاييس الأداء. قم بتضمين بيانات التكلفة في اجتماعات الهندسة العامة الخاصة بك. اجعل السؤال "كم سيكلف هذا؟" طبيعيًا مثل السؤال "كيف سيتوسع هذا؟" أو "ما هي أوضاع الخطأ؟" في المناقشات المعمارية.

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

اجعل التكلفة جزءًا من عملية المراجعة المعمارية الخاصة بك. قبل إطلاق خدمة جديدة كبيرة أو تغيير في البنية التحتية للإنتاج، قم بتضمين تقدير التكلفة في المراجعة. كم سيكلف هذا على النطاق الحالي؟ كم سيكلف على نطاق 10 أضعاف الحالي؟ هل هناك نهج بديلة يمكن أن تكون أرخص بشكل ملحوظ؟ لا يجب أن يكون هذا نموذجًا ماليًا مفصلًا، تقدير تقريبي للمقياس الذي يتم مناقشته كجزء من المراجعة العادية كافٍ لإبراز المشاكل الواضحة.

احتفل بالنجاحات. عندما يجد مهندس مصدرًا للهدر ويزيله، اجعل ذلك مرئيًا. عندما يقوم فريق بتقليل تكاليف البنية التحتية الشهرية بنسبة 20٪ عن طريق تحديد الحجم الصحيح للموارد، اذكر ذلك في الاجتماع العام. تحسين التكلفة ليس عملًا لامعًا، وقليل من التقدير يقطع شوطًا طويلًا في جعله ممارسة مستدامة بدلاً من مبادرة لمرة واحدة.

العائد المركب على الانضباط في البنية التحتية

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

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

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

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