قامت شركة URUS بتجربة Kubernetes بأشكال مختلفة: النشر المستقل على المعدن، في Google Cloud، ثم نقلت نظامها الأساسي إلى سحابة Mail.ru Cloud Solutions (MCS). يخبرنا إيجور شيشكين كيف اختاروا مزودًا سحابيًا جديدًا وكيف تمكنوا من الانتقال إليه في ساعتين قياسيتين ()، مدير النظام الأول في URUS.
ماذا تفعل أوروس؟
هناك العديد من الطرق لتحسين نوعية البيئة الحضرية، وأحدها هو جعلها صديقة للبيئة. وهذا بالضبط ما تعمل عليه شركة URUS - الخدمات الرقمية الذكية. ويقومون هنا بتنفيذ حلول تساعد المؤسسات على مراقبة المؤشرات البيئية المهمة وتقليل تأثيرها السلبي على البيئة. تقوم أجهزة الاستشعار بجمع البيانات حول تكوين الهواء ومستوى الضوضاء وغيرها من المعالم، ثم ترسلها إلى منصة URUS-Ekomon الموحدة للتحليل وتقديم التوصيات.
كيف يعمل URUS من الداخل
العميل النموذجي لشركة URUS هو شركة تقع في منطقة سكنية أو بالقرب منها. يمكن أن يكون هذا مصنعًا أو ميناء أو مستودعًا للسكك الحديدية أو أي منشأة أخرى. إذا تلقى عميلنا بالفعل تحذيرًا، أو تم تغريمه بسبب التلوث البيئي، أو يريد إحداث ضوضاء أقل، أو تقليل كمية الانبعاثات الضارة، فإنه يأتي إلينا، ونقدم له بالفعل حلاً جاهزًا للمراقبة البيئية.
يُظهر الرسم البياني لرصد تركيز كبريتيد الهيدروجين (H2S) الانبعاثات الليلية المنتظمة من مصنع مجاور
تحتوي الأجهزة التي نستخدمها في URUS على العديد من أجهزة الاستشعار التي تجمع معلومات حول محتوى غازات معينة ومستويات الضوضاء وغيرها من البيانات لتقييم الوضع البيئي. يتم دائمًا تحديد العدد الدقيق لأجهزة الاستشعار من خلال المهمة المحددة.
اعتمادا على تفاصيل القياسات، يمكن وضع الأجهزة ذات أجهزة الاستشعار على جدران المباني والأعمدة وغيرها من الأماكن التعسفية. يقوم كل جهاز بجمع المعلومات وتجميعها وإرسالها إلى بوابة استقبال البيانات. هناك نقوم بحفظ البيانات للتخزين على المدى الطويل ومعالجتها مسبقًا لتحليلها لاحقًا. إن أبسط مثال على ما نحصل عليه نتيجة للتحليل هو مؤشر جودة الهواء، المعروف أيضًا باسم AQI.
بالتوازي، تعمل العديد من الخدمات الأخرى على منصتنا، لكنها في الأساس ذات طبيعة خدمية. على سبيل المثال، ترسل خدمة الإشعارات إخطارات إلى العملاء إذا تجاوزت أي من المعلمات المراقبة (على سبيل المثال، محتوى ثاني أكسيد الكربون) القيمة المسموح بها.
كيف نقوم بتخزين البيانات. قصة Kubernetes على المعدن
يحتوي مشروع المراقبة البيئية URUS على العديد من مستودعات البيانات. في أحدهما، نحتفظ بالبيانات "الأولية" - ما تلقيناه مباشرة من الأجهزة نفسها. هذا التخزين عبارة عن شريط "مغناطيسي"، كما هو الحال في أشرطة الكاسيت القديمة، مع تاريخ جميع المؤشرات. يتم استخدام النوع الثاني من التخزين للبيانات المعالجة مسبقًا - بيانات من الأجهزة، معززة بالبيانات الوصفية حول الاتصالات بين أجهزة الاستشعار وقراءات الأجهزة نفسها، والانتساب إلى المنظمات، والمواقع، وما إلى ذلك. تتيح لك هذه المعلومات إجراء تقييم ديناميكي لكيفية عمل مؤشر معين تغيرت خلال فترة زمنية معينة. نحن نستخدم تخزين البيانات "الأولية"، من بين أمور أخرى، كنسخة احتياطية واستعادة البيانات المعالجة مسبقًا، إذا دعت الحاجة إلى ذلك.
عندما كنا نتطلع إلى حل مشكلة التخزين لدينا منذ عدة سنوات، كان لدينا خياران للنظام الأساسي: Kubernetes وOpenStack. ولكن بما أن الأخير يبدو وحشيًا للغاية (فقط انظر إلى هندسته المعمارية لتقتنع بذلك)، فقد استقرنا على Kubernetes. كانت الحجة الأخرى لصالحها هي التحكم البسيط نسبيًا في البرامج، والقدرة على قطع عقد الأجهزة بشكل أكثر مرونة وفقًا للموارد.
بالتوازي مع إتقان Kubernetes نفسه، قمنا أيضًا بدراسة طرق تخزين البيانات، بينما احتفظنا بكل مساحة تخزيننا في Kubernetes على أجهزتنا الخاصة، وحصلنا على خبرة ممتازة. كل ما عشناه بعد ذلك على Kubernetes: التخزين الكامل، ونظام المراقبة، وCI/CD. لقد أصبح Kubernetes منصة شاملة بالنسبة لنا.
لكننا أردنا العمل مع Kubernetes كخدمة، وليس المشاركة في دعمها وتطويرها. بالإضافة إلى ذلك، لم يعجبنا كم كلفنا صيانته على المعدن، وكنا بحاجة إلى التطوير باستمرار! على سبيل المثال، كانت إحدى المهام الأولى هي دمج وحدات تحكم Kubernetes Ingress في البنية التحتية للشبكة في مؤسستنا. هذه مهمة مرهقة، لا سيما بالنظر إلى أنه في ذلك الوقت لم يكن هناك شيء جاهز لإدارة الموارد البرمجية مثل سجلات DNS أو تخصيص عناوين IP. في وقت لاحق بدأنا بتجربة تخزين البيانات الخارجية. لم نتمكن مطلقًا من تنفيذ وحدة التحكم PVC، ولكن حتى ذلك الحين أصبح من الواضح أن هذا مجال عمل كبير يتطلب متخصصين متخصصين.
يعد التبديل إلى Google Cloud Platform حلاً مؤقتًا
لقد أدركنا أن هذا لا يمكن أن يستمر، ونقلنا بياناتنا من النظام الأساسي إلى Google Cloud Platform. في الواقع، في ذلك الوقت لم يكن هناك الكثير من الخيارات المثيرة للاهتمام بالنسبة لشركة روسية: إلى جانب Google Cloud Platform، قدمت خدمة مماثلة أمازون فقط، لكننا ما زلنا نستقر على الحل من Google. ثم بدا لنا أنه أكثر ربحية من الناحية الاقتصادية، وأقرب إلى المنبع، ناهيك عن حقيقة أن Google نفسها هي نوع من PoC Kubernetes في الإنتاج.
ظهرت المشكلة الرئيسية الأولى في الأفق مع نمو قاعدة عملائنا. عندما كنا بحاجة إلى تخزين البيانات الشخصية، كان أمامنا خيار: إما أن نعمل مع جوجل وننتهك القوانين الروسية، أو نبحث عن بديل في الاتحاد الروسي. الاختيار، على العموم، كان متوقعا. 🙂
كيف رأينا الخدمة السحابية المثالية
بحلول بداية البحث، كنا نعرف بالفعل ما أردنا الحصول عليه من مزود السحابة المستقبلي. ما هي الخدمة التي كنا نبحث عنها:
- سريعة ومرنة. بحيث يمكننا بسرعة إضافة عقدة جديدة أو نشر شيء ما في أي وقت.
- غير مكلف. كنا قلقين للغاية بشأن المسألة المالية، حيث كانت مواردنا محدودة. لقد علمنا بالفعل أننا نريد العمل مع Kubernetes، والآن كانت المهمة تتمثل في تقليل تكلفتها من أجل زيادة كفاءة استخدام هذا الحل أو على الأقل الحفاظ عليها.
- الآلي. لقد خططنا للعمل مع الخدمة من خلال واجهة برمجة التطبيقات (API)، بدون مديرين أو مكالمات هاتفية أو مواقف حيث نحتاج إلى رفع عدة عشرات من العقد يدويًا في وضع الطوارئ. نظرًا لأن معظم عملياتنا تتم تلقائيًا، فقد توقعنا نفس الشيء من الخدمة السحابية.
- مع خوادم في الاتحاد الروسي. بالطبع، خططنا للامتثال للتشريعات الروسية ونفس 152-FZ.
في ذلك الوقت، كان هناك عدد قليل من موفري خدمات Kubernetes aaS في روسيا، وعند اختيار المزود، كان من المهم بالنسبة لنا عدم التنازل عن أولوياتنا. قدم لنا فريق Mail.ru Cloud Solutions، الذي بدأنا العمل معه وما زلنا نتعاون معه، خدمة مؤتمتة بالكامل، مع دعم واجهة برمجة التطبيقات (API) ولوحة تحكم ملائمة تتضمن Horizon - حيث يمكننا بسرعة رفع عدد عشوائي من العقد.
كيف تمكنا من الانتقال إلى MCS خلال ساعتين
في مثل هذه التحركات، تواجه العديد من الشركات صعوبات وانتكاسات، لكن في حالتنا لم يكن هناك أي صعوبات. لقد كنا محظوظين: نظرًا لأننا كنا نعمل بالفعل على Kubernetes قبل بدء الترحيل، فقد قمنا ببساطة بتصحيح ثلاثة ملفات وأطلقنا خدماتنا على النظام الأساسي السحابي الجديد، MCS. اسمحوا لي أن أذكركم أنه بحلول ذلك الوقت كنا قد تركنا المعدن تمامًا وعشنا على Google Cloud Platform. لذلك، لم تستغرق الخطوة نفسها أكثر من ساعتين، بالإضافة إلى قضاء المزيد من الوقت (حوالي ساعة) في نسخ البيانات من أجهزتنا. في ذلك الوقت كنا نستخدم بالفعل Spinnaker (خدمة أقراص مضغوطة متعددة السحابة لتوفير التسليم المستمر). وقمنا أيضًا بإضافته بسرعة إلى المجموعة الجديدة وواصلنا العمل كالمعتاد.
بفضل أتمتة عمليات التطوير وCI/CD، يتم التعامل مع Kubernetes في URUS بواسطة متخصص واحد (وهذا أنا). في مرحلة ما، عمل مسؤول نظام آخر معي، ولكن بعد ذلك اتضح أننا قمنا بالفعل بأتمتة جميع الروتين الرئيسي وكان هناك المزيد والمزيد من المهام من منتجنا الرئيسي وكان من المنطقي إرسال الموارد إلى هذا.
لقد حصلنا على ما توقعناه من مزود السحابة، منذ أن بدأنا التعاون دون أوهام. إذا كانت هناك أية حوادث، فهي في الغالب تقنية ويمكن تفسيرها بسهولة من خلال الحداثة النسبية للخدمة. الشيء الرئيسي هو أن فريق MCS يزيل أوجه القصور بسرعة ويستجيب بسرعة للأسئلة في برامج المراسلة.
إذا قارنت تجربتي مع Google Cloud Platform، ففي حالتهم لم أكن أعرف حتى مكان زر التعليقات، حيث لم تكن هناك حاجة إليه ببساطة. وفي حالة حدوث أية مشكلات، ترسل Google نفسها الإشعارات من جانب واحد. ولكن في حالة شركة MCS، أعتقد أن الميزة الكبرى هي أنها قريبة قدر الإمكان من العملاء الروس - جغرافيًا وذهنيًا.
كيف نرى العمل مع السحب في المستقبل
الآن يرتبط عملنا ارتباطًا وثيقًا بـ Kubernetes، وهو يناسبنا تمامًا من وجهة نظر مهام البنية التحتية. لذلك، لا نخطط للانتقال منه إلى أي مكان، على الرغم من أننا نقدم باستمرار ممارسات وخدمات جديدة لتبسيط المهام الروتينية وأتمتة المهام الجديدة، وزيادة استقرار وموثوقية الخدمات... نحن الآن نطلق خدمة Chaos Monkey (تحديدًا) ، نحن نستخدم Chaoskube، لكن هذا لا يغير المفهوم: )، الذي تم إنشاؤه في الأصل بواسطة Netflix. يقوم Chaos Monkey بشيء واحد بسيط: فهو يحذف حجرة Kubernetes العشوائية في وقت عشوائي. يعد هذا ضروريًا لكي تعمل خدمتنا بشكل طبيعي مع عدد الحالات n-1، لذلك ندرب أنفسنا على الاستعداد لأية مشكلات.
الآن أرى أن استخدام حلول الجهات الخارجية - نفس المنصات السحابية - هو الشيء الصحيح الوحيد للشركات الناشئة. عادة، في بداية رحلتهم، تكون مواردهم محدودة، سواء البشرية أو المالية، كما أن إنشاء وصيانة السحابة أو مركز البيانات الخاص بهم أمر مكلف للغاية ويتطلب عمالة كثيفة. يسمح لك موفرو الخدمات السحابية بتقليل هذه التكاليف إلى الحد الأدنى، حيث يمكنك الحصول بسرعة منهم على الموارد اللازمة لتشغيل الخدمات هنا والآن، ودفع ثمن هذه الموارد بعد وقوعها. أما بالنسبة لشركة URUS، فسنظل مخلصين لـ Kubernetes في السحابة في الوقت الحالي. ولكن من يدري، قد نضطر إلى التوسع جغرافيًا، أو تنفيذ حلول تعتمد على بعض المعدات المحددة. أو ربما ستبرر كمية الموارد المستهلكة امتلاك Kubernetes على المعدن، كما كان الحال في الأيام الخوالي. 🙂
ما تعلمناه من العمل مع الخدمات السحابية
لقد بدأنا في استخدام Kubernetes على المعدن، وحتى هناك كان جيدًا بطريقته الخاصة. ولكن تم الكشف عن نقاط قوتها على وجه التحديد كمكون aaS في السحابة. إذا حددت هدفًا وقمت بأتمتة كل شيء قدر الإمكان، فستتمكن من تجنب تقييد البائع وسيستغرق التنقل بين موفري الخدمات السحابية بضع ساعات، وستبقى الخلايا العصبية معنا. يمكننا تقديم المشورة للشركات الأخرى: إذا كنت ترغب في إطلاق الخدمة (السحابية) الخاصة بك، ولديك موارد محدودة وأقصى سرعة للتطوير، فابدأ الآن بتأجير الموارد السحابية، وقم ببناء مركز البيانات الخاص بك بعد أن تكتب فوربس عنك.
المصدر: www.habr.com