- 1. فهم فاتورتك قبل محاولة تحسينها
- 2. ضبط حجم الحوسبة بشكل صحيح
- 3. السعة المحجوزة وخطط التوفير
- 4. Spot و Preemptible Instances
- 5. التخزين: التسرب البطيء الذي يصبح فيضانًا
- 6. قواعد البيانات المُدارة
- 7. Kubernetes والحاويات
- 8. الشبكات ونقل البيانات
- 9. البنية التحتية ككود
- 10. بناء ثقافة هندسية واعية بالتكلفة
- العائد المتراكم على الانضباط في البنية التحتية
هناك نوع معين من الرهبة التي تصيب مؤسس شركة ناشئة أو قائد هندسي في بداية الشهر. تصل فاتورة السحابة، وهي أعلى من الشهر الماضي، ولا يمكن لأي شخص في الفريق أن يشرح السبب فورًا. تقوم بالتعمق في وحدة التحكم، وتلاحق العناصر الفردية، وفي النهاية تجد مجموعة من المتسببين؛ Instance كبيرة الحجم لم يلمسها أحد منذ ستة أسابيع، بيئة اختبار منسية تعمل بكامل طاقتها، خط أنابيب بيانات يفرغ المخرجات في bucket لم يتم الاستعلام عنه منذ آخر تغيير في المنتج.
هذه ليست قصة نادرة. إنها القصة الافتراضية. البنية التحتية السحابية من السهل جدًا توفيرها ومن السهل جدًا نسيانها. يبدو نموذج الفوترة (ادفع مقابل ما تستخدمه، يتم الفوترة بالثانية) عادلاً حتى تدرك أن "ما تستخدمه" يشمل كل ما نسيت إيقافه.
بالنسبة للشركات الناشئة في مراحلها المبكرة، فإن هذا الأمر يهم أكثر مما هو عليه بالنسبة للشركات الكبيرة. شركة Fortune 500 التي تستوعب 50,000 دولار في إنفاق سحابي غير ضروري شهريًا هي عدم كفاءة. بالنسبة لشركة ناشئة في مرحلة Series A تحرق الأموال بسرعة، إنها مشكلة استراتيجية حقيقية. تؤثر على مدة التشغيل، وما يمكنك توظيفه، وما الرهانات التي يمكنك تحملها. الانضباط في تكاليف السحابة ليس مجرد قلق مالي أو تخصص DevOps. إنه جوهر كيفية تشغيل الشركة.
الخبر السار هو أن الإنفاق الزائد على السحابة هو مشكلة تم حلها إلى حد كبير. الأنماط مفهومة جيدًا، والأدوات ناضجة، والمدخرات حقيقية وسريعة. هذا الدليل يسير عبر كل رافعة رئيسية، من الأساسيات التي يجب أن تكون موجودة في اليوم الأول إلى القرارات المعمارية التي ستشكل اقتصاديات البنية التحتية لسنوات.
1. فهم فاتورتك قبل محاولة تحسينها
يبدو هذا واضحًا. لكنه ليس كذلك. معظم فرق الهندسة في الشركات الناشئة لديها فكرة تقريبية عن إجمالي إنفاقها الشهري على السحابة، وفكرة أكثر غموضًا عن مصدره، وتقريبًا لا يوجد إحساس بالخدمات أو الميزات أو البيئات المحددة المسؤولة عن اتجاهات التكلفة بمرور الوقت. هذا ليس إهمالًا، إنه فقط الحالة الافتراضية عندما لم يقم أحد بإعداد البنية التحتية للإجابة على تلك الأسئلة بشكل صريح.
قبل أن تتمكن من تحسين أي شيء، تحتاج إلى رؤية. رؤية حقيقية، دقيقة، منسوبة للفريق.
علامات تخصيص التكلفة هي الأساس. يدعم كل مزود سحابي رئيسي وضع علامات على الموارد بأزواج مفتاحية-قيمة عشوائية، وتلك العلامات تتدفق إلى بيانات الفوترة الخاصة بك. بمجرد أن تبدأ في وضع العلامات، يمكنك الإجابة على أسئلة مثل: كم يكلف خط أنابيب البيانات لدينا شهريًا؟ ما تكلفة تشغيل بيئة الاختبار لدينا؟ ما هي خدمات الفريق المسؤولة عن الزيادة التي رأيناها يوم الثلاثاء الماضي؟
بدون علامات، أنت تنظر إلى رقم واحد وتخمن. مع العلامات، لديك مجموعة بيانات منظمة يمكنك بالفعل التفكير فيها. قم بإعداد مخطط وضع العلامات في اليوم الأول، البيئة (prod، staging، dev)، الفريق أو المجموعة، الخدمة أو الميزة، ومركز التكلفة هي الأبعاد الأكثر فائدة وفرضها في البنية التحتية ككود بحيث يتم دائمًا وضع العلامات على الموارد الجديدة بشكل صحيح.
لوحات معلومات الفوترة وتنبيهات الشذوذ هي تأمين مجاني. يقدم كل مزود سحابي أدوات إدارة التكلفة الأصلية (AWS Cost Explorer، GCP Cost Management، Azure Cost Analysis) بدون تكلفة إضافية. قم بإعداد تنبيهات الميزانية عند 50%، 75%، و90% من هدفك الشهري. قم بتكوين اكتشاف الشذوذ بحيث يتم إعلامك عندما ترتفع النفقات على أي خدمة بشكل غير متوقع. هذه الأدوات لن تخبرك لماذا شيء ما مكلف، لكنها ستتأكد من أنك تعرف متى يكون كذلك والتوقيت مهم بشكل كبير. المشكلة التي يتم اكتشافها في اليوم الثاني من الشهر تكلف أقل بكثير من تلك التي تكتشفها في اليوم الثلاثين.
انظر إلى أعلى عشرة عناصر فردية وافهم كل واحد منها. في معظم الشركات الناشئة في المراحل المبكرة، تشكل أربع إلى ست خدمات 80-90% من إجمالي الفاتورة: EC2 أو الحوسبة المكافئة، RDS أو قاعدة البيانات المُدارة المكافئة، S3 أو التخزين الكائن المكافئ، نقل البيانات (الخروج)، وربما خدمة الحاويات المُدارة أو Kubernetes cluster. اعرف ما يفعله كل من هؤلاء، لماذا يكلف ما يكلف، وما الذي يبدو كخط أساس معقول. كل شيء آخر هو سياق.
2. ضبط حجم الحوسبة بشكل صحيح
الحوسبة هي تقريبًا العنصر الأكبر في الفاتورة وتكون تقريبًا مفرطة التخصيص. هذا ليس انتقادًا للمهندسين الذين حددوا حجم الـ Instances، إنه نتيجة هيكلية لكيفية اتخاذ الفرق قرارات البنية التحتية في ظل عدم اليقين.
عندما تطلق خدمة جديدة، لا تعرف بالضبط مقدار الحركة التي ستتلقاها أو كيف سيبدو ملف تعريف استخدام الموارد الخاص بها. لذا تقوم بتقدير محافظ وتضيف هامشًا. هذا معقول. لكن تلك الهوامش تتراكم. عبر عشرات الخدمات، عبر ثلاث بيئات، عبر سنتين من النمو العضوي، تجمع أسطولاً من الـ Instances التي تم تحديد حجمها لتحمل حمولة نادرًا ما تراها.
اسحب مقاييس الاستخدام الخاصة بك قبل إجراء أي تغييرات. انظر إلى متوسط استخدام وحدة المعالجة المركزية والذاكرة لكل Instance قيد التشغيل خلال الثلاثين يومًا الماضية. ليس الذروة، المتوسط. الـ Instance الذي يعمل بمتوسط استخدام وحدة معالجة مركزية 8-12% مع ذروات تصل إلى 35% لا يحتاج إلى أن يكون بالحجم الذي هو عليه. ستعرض معظم مزودي السحابة توصيات ضبط الحجم مباشرة في وحدات التحكم الخاصة بالتكلفة لديهم؛ خذها كنقطة انطلاق، تحقق منها مقابل بيانات الاستخدام الفعلية الخاصة بك، وكن مستعدًا للذهاب أبعد مما تقترحه التوصية.
افصل بين بيئات الإنتاج والبيئات غير الإنتاجية. هذا أحد التغييرات ذات الرافعة العالية التي يمكن لمعظم الشركات الناشئة القيام بها، ويتطلب تقريبًا أي عمل معماري. ليس لدى بيئات التطوير والاختبار أي سبب للعمل بسعة الإنتاج 24 ساعة في اليوم، سبعة أيام في الأسبوع. يعمل المهندسون عادة 10 ساعات في اليوم، 5 أيام في الأسبوع. مما يعني أن البنية التحتية غير الإنتاجية الخاصة بك تجلس خاملة لحوالي 70% من الوقت.
قم بتنفيذ جداول إيقاف التشغيل التلقائي. استخدم دالة Lambda، وظيفة Cloud Scheduler، أو نصًا بسيطًا يتم تشغيله بواسطة cron لإيقاف الـ Instances غير الإنتاجية في المساء وإعادة تشغيلها في الصباح. ضع علامات على بيئاتك بشكل صحيح بحيث يمكنك تطبيق هذا بشكل انتقائي. بيئة الاختبار التي تعمل فقط خلال ساعات العمل تكلف حوالي 30% مما ستكلفه على جدول 24/7 وتأثير تجربة المطور ضئيل إذا كان وقت بدء التشغيل مقبولاً (عادة أقل من دقيقتين).
بالنسبة لبيئات التطوير بشكل خاص، فكر فيما إذا كان الأفراد بحاجة إلى Instances سحابية دائمة على الإطلاق، أو ما إذا كانت إعدادات التطوير المحلية المحاكية يمكنها التعامل مع معظم أحمال العمل. تجد العديد من الفرق أن نقل التطوير إلى بيئات Docker المحلية والحفاظ على الموارد السحابية فقط للاختبار والإنتاج يقلل بشكل كبير من فاتورتهم دون التأثير على الإنتاجية.
عائلات الـ Instances تهم أكثر من أحجام الـ Instances. تقوم AWS وGCP وAzure بانتظام بإصدار عائلات Instances جديدة تقدم أداءً أفضل من حيث السعر مقارنة بالأجيال السابقة. الـ Instances الأحدث من حيث الأداء المحسن أو الأغراض العامة تكون دائمًا أرخص لكل وحدة أداء من الجيل السابق، أحيانًا بنسبة 10-20%. إذا كنت تقوم بتشغيل Instances من عائلة تزيد عن جيلين، فهناك على الأرجح خيار أفضل. راجع هذا سنويًا على الأقل.
3. السعة المحجوزة وخطط التوفير: القرار الأعلى عائدًا على الاستثمار
إذا كانت شركتك الناشئة تعمل منذ ستة أشهر أو أكثر ولديها قاعدة ثابتة من الحوسبة تعرف أنها ستحتاجها في المستقبل المنظور، وأنت تدفع أسعارًا عند الطلب لتلك القاعدة، فأنت ترتكب خطأ مكلفًا. هذه ليست حالة حافة. إنها واحدة من الأخطاء الأكثر شيوعًا والأكثر تكلفة في إدارة السحابة للشركات الناشئة.
تم تصميم تسعير عند الطلب للأحمال العمل غير المتوقعة حقًا. تدفع علاوة مقابل المرونة في تدوير الموارد لأعلى ولأسفل دون التزام. تلك العلاوة منطقية للأحمال العمل المتغيرة وغير المؤكدة. لا معنى لها للبنية التحتية الأساسية التي كانت تعمل دون تغيير على مدار العام الماضي.
تخفض الـ Reserved Instances وخطط التوفير تكاليف الحوسبة بنسبة 40-70% مقارنة بأسعار عند الطلب، اعتمادًا على مدة الالتزام وهيكل الدفع. عادةً ما يكون الالتزام لمدة عام واحد بدون دفعة مقدمة أرخص بنسبة 30-40% من عند الطلب. يمكن أن تصل مدة الالتزام لمدة ثلاث سنوات مع دفعة مقدمة جزئية أو كاملة إلى 60-70% من التوفير. بالنسبة لشركة ناشئة تنفق 20,000 دولار شهريًا على EC2، يمكن أن يوفر نقل القاعدة إلى الـ Reserved Instances ما بين 8,000 إلى 14,000 دولار شهريًا. هذا ليس خطأ تقريبيًا.
النهج العملي: حدد الحد الأدنى من الحوسبة الأساسية الخاصة بك، الأرضية التي تعمل في الساعة 3 صباحًا في يوم أحد هادئ، بغض النظر عن الحركة أو الحمل. تلك الأرضية هي ما يجب أن تغطيه بالسعة المحجوزة. كل شيء فوقها (الزيادات، ارتفاعات الحركة، إطلاق الميزات الجديدة) يبقى على عند الطلب أو spot. هذا يمنحك كفاءة التكلفة من الالتزامات مع مرونة عند الطلب لأي شيء متغير.
راجع التزاماتك ربع سنويًا. الـ Reserved Instances وخطط التوفير ليست إعدادًا ونسيانًا. ستتغير قاعدتك الأساسية مع تطور المنتج. راجع استخدام الالتزامات الحالية وفرصة إضافة جديدة كل ربع سنة. من الأفضل الالتزام قليلاً وزيادة الالتزام بدلاً من الالتزام الزائد وترك السعة المحجوزة غير مستخدمة. الالتزامات غير المستخدمة هي أموال مهدرة فعليًا.
خطط التوفير مقابل الـ Reserved Instances: تقدم خطط التوفير من AWS مرونة أكبر من الـ Reserved Instances التقليدية، تنطبق على أي استخدام لـ EC2 داخل عائلة، بغض النظر عن نوع الـ Instance المحدد، المنطقة، أو نظام التشغيل. بالنسبة لمعظم الشركات الناشئة، تكون خطط التوفير أسهل في الإدارة وتقريبًا بنفس الكفاءة من حيث التكلفة. إذا كانت بنيتك التحتية مستقرة نسبيًا ومحددة جيدًا، يمكن للـ Reserved Instances لأنواع الـ Instances المحددة أن تضغط على بضع نقاط مئوية إضافية من التوفير.
PlusClouds وتحسين تكاليف السحابة:
توقف عن التخمين بشأن التزامات الـ Reserved Instances.
تحلل PlusClouds أنماط الاستخدام التاريخية الخاصة بك وتخبرك بالضبط بكمية السعة المحجوزة التي يجب شراؤها — مقسمة حسب عائلة الـ Instance، المنطقة، وطول المدة. العملاء الذين يستخدمون توصيات الالتزام من PlusClouds يوفرون في المتوسط 41% على الحوسبة. يعمل عبر AWS Reserved Instances، Azure Reserved VMs، وGCP Committed Use Discounts.
شاهد كيف يعمل على plusclouds.com
4. Spot و Preemptible Instances: خصومات تصل إلى 90% للأحمال العمل المناسبة
تعد Spot Instances على AWS و Preemptible VMs على GCP من بين أقوى أدوات تقليل التكاليف المتاحة ومن بين الأقل استخدامًا من قبل الشركات الناشئة. السبب هو مزيج من تصور المخاطر وعدم الإلمام. بمجرد أن تفهم أي الأحمال العمل هي المرشحة المناسبة، تصبح الاقتصاديات شبه مستحيلة التجاهل.
تعمل Spot Instances على سعة مزود السحابة الفائضة. تقدم عرضًا لتلك السعة (أو، على Spot الحديثة من AWS، ببساطة تطلبها بالسعر الحالي للـ Spot)، وتحصل عليها حتى يحتاج مزود السحابة إليها مرة أخرى وفي هذه المرحلة تحصل على تحذير لمدة دقيقتين قبل الإنهاء. الخصم على هذا الإزعاج: يصل إلى 90% خصم على أسعار عند الطلب.
بالنسبة للأحمال العمل التي يمكن مقاطعتها أو إعادة تشغيلها، فإن هذا هو المال المجاني بشكل أساسي. الفئات التي تعمل فيها Spot Instances بشكل نظيف تشمل عمال خط أنابيب CI/CD (إذا تم مقاطعة وظيفة البناء، يلتقطها العداء مرة أخرى)، معالجة البيانات الدفعة وخطوط أنابيب ETL (احفظ تقدمك واستأنف)، وظائف تدريب التعلم الآلي (تدعم معظم الأطر حفظ النقاط)، التحليلات الليلية أو توليد التقارير، اختبار التحميل، وأي خدمة ويب عديمة الحالة يتم توجيهها بواسطة موازن تحميل حيث يتم التعامل مع إنهاء Instance واحد بشكل سلس عن طريق توجيه الحركة إلى الآخرين.
الأحمال العمل التي لا تناسبها Spot: أي شيء ذو حالة لا يمكنه تحمل الانقطاع، قواعد البيانات في معظم التكوينات، الخدمات ذات متطلبات زمن الاستجابة الفورية، وأي حمل عمل حيث يؤدي فشل العملية في منتصف الطريق إلى تلف الحالة أو يتطلب إعادة تشغيل كاملة من الصفر.
استراتيجية الـ Instances المختلطة تعمل بشكل أفضل. استخدم Spot لكل شيء يمكن مقاطعته، عند الطلب للخدمات عديمة الحالة التي تحتاج إلى موثوقية، ومحجوزة لقاعدتك الثابتة. تشغيل CI/CD الخاص بك على Spot Instances فقط يمكن أن يقلل من تكاليف بنية البناء التحتية بنسبة 80% مع تعقيد تشغيلي ضئيل.
5. التخزين: التسرب البطيء الذي يصبح فيضانًا
تكاليف التخزين صغيرة بشكل فردي وكبيرة بشكل جماعي. النمط الذي يتكرر في كل شركة ناشئة تقريبًا هو نفسه: يتم كتابة البيانات في التخزين الكائن، لا يقوم أحد ببناء عملية لتحديد متى تخرج، وبعد 18 شهرًا تدفع أسعار التخزين الكاملة لتيرابايت من البيانات التي لم يتم الوصول إليها منذ إصدار منتج سابق.
يبدو تسعير التخزين الكائن رخيصًا، 0.023 دولار لكل جيجابايت-شهر على S3 Standard. ولكن على نطاق واسع، أو مع تراكم كافٍ من البيانات، فإنه يتراكم. والأهم من ذلك، أن العديد من الشركات الناشئة تخزن البيانات في الطبقة الخاطئة: تحتفظ بكل شيء في Standard عندما يتم الوصول إلى معظمها نادرًا أو لا يتم الوصول إليها أبدًا، لأن أحدًا لم يقم بإعداد القواعد لنقلها تلقائيًا.
سياسات دورة الحياة ليست اختيارية. يجب أن تكون أول شيء تقوم بتكوينه عند إنشاء bucket للتخزين، وليس تحسينًا تصل إليه لاحقًا. حدد القواعد التي تنقل الكائنات إلى التخزين Infrequent Access بعد 30 أو 60 يومًا من عدم الوصول، انقلها إلى Glacier أو Archive بعد 90 أو 180 يومًا، واحذفها بعد فترة احتفاظ محددة. بالنسبة لملفات السجل، تكون فترة الاحتفاظ غالبًا 30-90 يومًا. بالنسبة للنسخ الاحتياطية، يعتمد ذلك على متطلبات الامتثال الخاصة بك. بالنسبة للبيانات الخام من الميزات المهملة، يكون الجواب غالبًا "احذف بعد 6 أشهر".
ستختلف الانتقالات الزمنية والطبقات المحددة حسب المزود وحالة الاستخدام، ولكن المبدأ عالمي: البيانات لها دورة حياة، وإدارتها بشكل متعمد يوفر أموالًا كبيرة بمرور الوقت.
تكاليف الخروج هي واحدة من مفاجآت الفوترة الأقل مناقشة في السحابة. تفرض مزودي السحابة رسومًا على البيانات التي تغادر شبكتهم، إلى الإنترنت، إلى مناطق أخرى، أو في بعض الحالات بين الخدمات داخل نفس الحساب. هذه الرسوم صغيرة لكل جيجابايت ولكنها تتزايد بسرعة مع حجم البيانات.
تشمل الفخاخ الشائعة للخروج: البنى التي تسحب مجموعات بيانات كبيرة عبر المناطق للمعالجة (انقل الحوسبة إلى البيانات بدلاً من ذلك)، التطبيقات التي تقدم ملفات كبيرة مباشرة من التخزين الكائن إلى المستخدمين النهائيين دون CDN، وهندسة الخدمات المصغرة التي تمرر حمولات كبيرة بين الخدمات دون داع. قبل قبول بنية تتضمن حركة بيانات كبيرة، احسب بوضوح ما ستكون تكاليف الخروج على نطاقك المتوقع.
راجع التخزين الخاص بك بانتظام. قم بتعيين تذكير في التقويم لمراجعة إنفاق التخزين الخاص بك ربع سنويًا. ابحث عن buckets بدون سياسة دورة حياة، buckets تخزن بيانات للميزات أو الخدمات المهملة، وحدات EBS غير المتصلة (مصدر شائع بشكل مدهش للهدر)، واللقطات القديمة التي تراكمت بعد متطلبات الاحتفاظ الخاصة بك. هذا عمل غير لامع، ولكن بعد ظهر واحد من التنظيف يمكن أن يحقق مدخرات تستمر لسنوات.
6. قواعد البيانات المُدارة: قوية، مكلفة، وغالبًا ما تكون مفرطة التخصيص
تعد خدمات قواعد البيانات المُدارة مثل RDS وCloud SQL وAzure Database من بين العروض الأكثر قيمة من مزودي السحابة، فهي تتعامل مع النسخ الاحتياطي، والتصحيح، والتبديل التلقائي، والمراقبة التي تتطلب بخلاف ذلك خبرة تشغيلية كبيرة. كما أنها غالبًا ما تكون العنصر الثاني أو الثالث الأكبر في فاتورة السحابة للشركة الناشئة، وهي تقريبًا دائمًا مخصصة لأحمال العمل المستقبلية بدلاً من الحالية.
مثيل RDS عالي التوافر متعدد المناطق مع نسخ القراءة و500 جيجابايت من IOPS المخصص هو الجواب الصحيح لمنتج يتعامل مع ملايين المعاملات يوميًا. بالنسبة لشركة ناشئة تحقق 50 ألف دولار من الإيرادات الشهرية المتكررة مع 10,000 مستخدم نشط، فهي استثمار كبير. الميزات التي تدفع مقابلها (التكرار المتزامن، التبديل التلقائي، الإنتاجية المخصصة) ذات قيمة، لكنك تدفع مقابلها على نطاق لم تصل إليه بعد.
طابق طبقة قاعدة البيانات الخاصة بك مع متطلباتك الفعلية اليوم، وليس متطلباتك الطموحة في 18 شهرًا. يمكنك دائمًا التوسع؛ التوسع بسيط ويمكن القيام به مع الحد الأدنى من التوقف في معظم خدمات قواعد البيانات المُدارة. الأموال التي توفرها الآن عن طريق تشغيل مثيل في منطقة واحدة أو فئة مثيل أصغر هي أموال حقيقية يمكن أن تذهب نحو النمو.
خيارات قواعد البيانات بدون خادم غير مقدرة بشكل كافٍ للمنتجات في المراحل المبكرة. Aurora Serverless v2، PlanetScale، وFirestore جميعها توسع سعة الحوسبة بناءً على الحمل الفعلي، بما في ذلك التوسع إلى ما يقرب من الصفر خلال فترات الخمول. بالنسبة لقواعد بيانات التطوير، الأدوات الداخلية ذات الحركة المنخفضة، والميزات ذات الأنماط غير المتوقعة للوصول، يمكن لقواعد البيانات بدون خادم أن تقلل بشكل كبير من التكاليف مقارنة بالمثيلات المخصصة التي تعمل بسعة دنيا بغض النظر عن الحمل.
حافظ على قواعد البيانات الخاصة بك نحيفة. قم بمراجعة المخطط الخاص بك بشكل دوري للبحث عن الجداول والأعمدة والفهارس التي لم تعد مستخدمة بواسطة الكود التطبيقي النشط. قم بأرشفة السجلات التاريخية إلى تخزين أرخص عندما لم تعد مطلوبة للاستعلامات في الوقت الفعلي. قم بتنظيف السجلات المحذوفة بشكل ناعم وفقًا لجدول زمني. قم بتنفيذ تجميع الاتصالات لتجنب تخصيص مثيل قاعدة بيانات بحجم الذروة للاتصالات المتزامنة بدلاً من الحمل النموذجي. هذه ممارسات هندسية جيدة تصادف أنها تقلل أيضًا من تكاليف البنية التحتية الخاصة بك.
Community
Further questions? Ask our team
7. Kubernetes والحاويات: قوة تتطلب الانضباط
أصبح Kubernetes منصة النشر الافتراضية للعديد من الشركات الناشئة، ولسبب وجيه، فهو يوفر تجريدًا قويًا لتشغيل الأحمال العمل المحاكية بشكل موثوق على نطاق واسع. كما أنه يقدم مجموعة جديدة من تحديات إدارة التكاليف التي يسهل التغاضي عنها، خاصة عندما تتحرك الفرق بسرعة ولا تولي اهتمامًا وثيقًا لتخصيص الموارد.
طلبات الموارد والحدود على كل pod ليست اختيارية. عندما لا يكون لدى pod طلبات موارد محددة، لا يوجد لدى جدولة Kubernetes أي معلومات لاستخدامها عند اتخاذ قرار بشأن مكان وضعها. النتيجة غالبًا ما تكون تعبئة غير فعالة، عقدًا "ممتلئة" اسميًا ولكن لديها سعة غير مستخدمة كبيرة، أو عقدًا محملة بشكل زائد حقًا لأن الطلبات لم تعكس الاستخدام الحقيقي. قم بتعيين طلبات وحدة المعالجة المركزية والذاكرة بناءً على الاستخدام الملاحظ، وليس التقديرات. قم بتعيين الحدود لمنع العمليات الجامحة من التأثير على جيرانها.
استخدم البدائل التلقائية التي يوفرها النظام البيئي. يقوم Horizontal Pod Autoscaler (HPA) بتوسيع عدد النسخ المتماثلة للـ pod بناءً على وحدة المعالجة المركزية، الذاكرة، أو المقاييس المخصصة. يقوم Vertical Pod Autoscaler (VPA) بضبط طلبات الموارد تلقائيًا بناءً على الاستخدام الملاحظ. يقوم Cluster Autoscaler وKarpenter الأحدث بإضافة وإزالة العقد من الكتلة الخاصة بك بناءً على طلب الـ pod المعلق. معًا، يمكن لهذه الأدوات تحسين استخدام الكتلة بشكل كبير ولكنها تتطلب طلبات موارد صحيحة لتعمل بشكل جيد، ولهذا السبب يهم هذا الأساس.
ضبط حجم العقدة مهم بقدر أهمية ضبط حجم الـ pod. يؤثر نوع الـ Instance الذي تختاره لمجموعة عقد Kubernetes الخاصة بك على كل من الأداء والتكلفة. راجع ما إذا كانت أنواع العقد الحالية الخاصة بك تتطابق مع ملف تعريف الحمل الفعلي الخاص بك: الأحمال العمل الثقيلة في الحوسبة تستفيد من الـ Instances المحسنة للحوسبة، الأحمال العمل الثقيلة في الذاكرة من الـ Instances المحسنة للذاكرة. مجموعة من الـ Instances للأغراض العامة التي تشغل أحمال عمل تعتمد في الغالب على الذاكرة تدفع مقابل سعة وحدة المعالجة المركزية التي لا تُستخدم أبدًا.
افصل تكلفة الكتلة الخاصة بك حسب الـ namespace، الفريق، أو التطبيق. يتطلب هذا إما نهج تخصيص تكلفة سحابي أصلي (وضع علامات على العقد ورسم خرائط للأحمال العمل) أو أداة مخصصة. بدون هذه الرؤية، تصبح مجموعات Kubernetes صناديق سوداء، تعرف ما تكلفه الكتلة، ولكن لا يمكنك معرفة أي الأحمال العمل أو الفرق المسؤولة عن أي جزء منها. هذا الغموض يجعل التحسين أكثر صعوبة.
8. الشبكات ونقل البيانات: عنصر الميزانية غير المرئي
نادراً ما تظهر تكاليف الشبكات في قوائم أولويات تحسين السحابة، ونادراً ما تكون العنصر الأكبر الوحيد في الفاتورة. لكنها غالبًا ما تكون محرك تكلفة مادي وغير مقدر، خاصة مع توسع التطبيقات ونمو أحجام البيانات.
داخل المنطقة، فكر بعناية في حركة المرور بين المناطق المتاحة. تفرض معظم مزودي السحابة رسومًا على البيانات المنقولة بين المناطق المتاحة داخل نفس المنطقة. بالنسبة للبنى التي تقوم بتواصل بين الخدمات بشكل كبير (الخدمات المصغرة التي تتصل ببعضها البعض، الخدمات التي تقرأ من التخزين المؤقت، العمال الذين يستهلكون من قوائم الانتظار)، يمكن أن تصبح نقل البيانات بين المناطق المتاحة تكلفة ملموسة. التواجد المشترك للخدمات التي تتواصل بشكل كبير في نفس المنطقة المتاحة هو أحد الحلول؛ استخدام موازنة تحميل مدركة للمناطق المتاحة لتفضيل الـ Instances المحلية هو حل آخر.
المبدأ الأساسي بسيط: حركة البيانات تكلف المال. كلما سافرت البيانات أبعد وكلما عبرت حدود الفوترة أكثر، زادت تكلفتها. تصميم من أجل محلية البيانات، الحفاظ على الحوسبة بالقرب من البيانات، تقليل التواصل عبر المناطق، وتجنب الرحلات ذهابًا وإيابًا غير الضرورية هو كل من الهندسة الجيدة والاقتصاد الجيد.
داخل المنطقة، فكر بعناية في حركة المرور بين المناطق المتاحة. تفرض معظم مزودي السحابة رسومًا على البيانات المنقولة بين المناطق المتاحة داخل نفس المنطقة. بالنسبة للبنى التي تقوم بتواصل بين الخدمات بشكل كبير (الخدمات المصغرة التي تتصل ببعضها البعض، الخدمات التي تقرأ من التخزين المؤقت، العمال الذين يستهلكون من قوائم الانتظار)، يمكن أن تصبح نقل البيانات بين المناطق المتاحة تكلفة ملموسة. التواجد المشترك للخدمات التي تتواصل بشكل كبير في نفس المنطقة المتاحة هو أحد الحلول؛ استخدام موازنة تحميل مدركة للمناطق المتاحة لتفضيل الـ Instances المحلية هو حل آخر.
استخدم CDN للمحتوى الموجه للمستخدم. تقديم الأصول الثابتة، الصور، والاستجابات المخزنة مؤقتًا مباشرة من التخزين الكائن أو الخوادم الأصلية يكون أكثر تكلفة بشكل كبير في تكاليف الخروج من تقديمها من حافة CDN. تسعير CDN يكون عمومًا أقل بكثير من تسعير الخروج من الأصل، وتحسين زمن الوصول للمستخدمين النهائيين هو مكافأة مجانية. هذه ممارسة جيدة مفهومة يتم أحيانًا تأجيلها في وقت مبكر من حياة الشركة الناشئة ثم لا يتم إعادة النظر فيها أبدًا.
راجع بنية VPC الخاصة بك للبحث عن فخاخ الخروج. تكاليف NAT Gateway هي مفاجأة شائعة. كل بايت من حركة المرور من شبكة فرعية خاصة إلى الإنترنت يمر عبر NAT Gateway، الذي يفرض رسومًا لكل ساعة ولكل جيجابايت. إذا كان لديك خدمات تقوم بإجراء مكالمات API خارجية بشكل متكرر، معالجة مجموعات بيانات كبيرة من مصادر خارجية، أو تنزيل حزم كبيرة في وقت البناء، يمكن أن تتراكم تكاليف NAT Gateway بسرعة. تقوم نقاط نهاية VPC لخدمات AWS (S3، DynamoDB، والعديد من الخدمات الأخرى) بتوجيه حركة المرور داخل شبكة AWS، مما يتجنب تكاليف NAT Gateway تمامًا لتلك الخدمات.
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% من خلال ضبط الحجم بشكل صحيح، اذكر ذلك في الاجتماع العام. تحسين التكلفة هو عمل غير لامع، وقليل من الاعتراف يقطع شوطًا طويلاً نحو جعله ممارسة مستدامة بدلاً من مبادرة لمرة واحدة.
العائد المتراكم على الانضباط في البنية التحتية
تحسين تكاليف السحابة ليس له منحنى عائد دراماتيكي، إنه ليس نوع العمل الذي يحول الشركة في ربع سنة واحد. إنه يتراكم. التحسينات الصغيرة والمتسقة في كيفية توفيرك، مراقبتك، وإدارة البنية التحتية تتراكم بمرور الوقت إلى ميزة تكلفة هيكلية تؤثر على اقتصاديات وحدتك، ومدى قدرتك على التشغيل، وقدرتك على اتخاذ رهانات لا يمكن لمنافسيك الأقل انضباطًا تحملها.
الشركات الناشئة التي تأخذ هذا على محمل الجد مبكرًا، التي تبني الرؤية، تؤسس الثقافة، وتعامل إنفاق البنية التحتية كرافعة استراتيجية بدلاً من تكلفة ثابتة، تنتهي بميزة تراكمية. مهندسوها يتخذون قرارات أفضل بشكل افتراضي. تتطور بنيتها مع الوعي بالتكلفة مدمجًا. فريقها المالي ليس مفاجئًا في نهاية كل شهر.
ابدأ بالأساسيات: الرؤية، وضع العلامات، تنبيهات الفوترة، وضبط حجم الـ Instances الأكثر تخصيصًا. أضف التزامات السعة المحجوزة بمجرد أن يكون لديك قاعدة ثابتة. قم ببناء العادات الثقافية، لوحات المعلومات المشتركة، المراجعات الواعية بالتكلفة، ملكية الفريق التي تجعل الانضباط مستدامًا. لا شيء من هذا معقد. كل ذلك يؤتي ثماره.
لا يجب أن تكون فاتورة السحابة شيئًا تخشاه. مع الأسس الصحيحة في مكانها، تصبح لوحة تحكم إشارة واضحة ومقروءة عن مدى كفاءة بناء فريقك ومدى فعالية خدمة بنيتك التحتية لمنتجك.
