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

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

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

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

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

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

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

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

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

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

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

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

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

2. تحسين موارد الحوسبة الخاصة بك

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

توقف عن التخمين بشأن الالتزامات لل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 VM's على GCP من أقوى أدوات توفير التكاليف المتاحة، ولكنها الأقل استخدامًا من قبل الشركات الناشئة. السبب في ذلك هو مزيج من تصور المخاطر وعدم المعرفة. بمجرد أن تفهم أي الأحمال هي المرشحة المناسبة، تكون الفوائد الاقتصادية شبه مستحيلة التجاهل.

تعمل الSpot-instances على السعة الفائضة لمزود السحابة. تقوم بالمزايدة على تلك السعة (أو، في AWS-spot الحديثة، تطلبها ببساطة بالسعر الحالي للspot)، وتحصل عليها حتى يحتاج مزود السحابة إلى السعة مرة أخرى. في تلك اللحظة، تحصل على تحذير لمدة دقيقتين قبل إنهاء الinstance. الخصم لهذا الإزعاج: خصم يصل إلى 90% على أسعار الطلب.

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

الأحمال التي لا تناسبها ال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 أشهر."

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تحديد حجم العقد مهم بقدر أهمية تحديد حجم الpods. يؤثر نوع الinstance الذي تختاره لمجموعة عقد Kubernetes الخاصة بك على الأداء والتكلفة. تحقق مما إذا كانت أنواع العقد الحالية الخاصة بك تتوافق مع ملف تعريف الحمل الفعلي: الأحمال المكثفة في الحوسبة تستفيد من الinstances المحسنة للحوسبة، الأحمال المكثفة في الذاكرة تستفيد من الinstances المحسنة للذاكرة. مجموعة من الinstances العامة التي تشغل في الغالب أحمال مكثفة في الذاكرة تدفع مقابل سعة وحدة المعالجة المركزية التي لا تُستخدم أبدًا.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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