تحدث إيفان كروغلوف ، المطور الرئيسي في Booking.com ، عن برنامج SlOmer DevOps مع موضوع SRE ، وبعد التحدث ، وافق على التحدث حول Kubernetes ، وشبكة الخدمة ، والحلول مفتوحة المصدر و "غير القياسية" في Booking.com عبر فنجان قهوة
نظرًا لأن موضوع SRE أصبح أوسع بكثير ، وافق إيفان وزميله بن تايلر ، المطور الرئيسي في Booking.com ، على أن يصبحا متحدثين في Slurm SRE ، والذي سيعقد في 3-5 فبراير 2020 . سيناقش نظرية وممارسة تطبيق ميزانية SLI / SLO / error ، التحليل اللاحق للوفاة ، التخلص الفعال من حوادث تكنولوجيا المعلومات ، بناء أنظمة موثوقة (الرصد والإنذار ، التدهور الرشيق ، الحقن بالفشل ، تخطيط القدرات ، منع حالات الفشل المتتالية ).
والآن كلمة لأيفان.
ما كان تحديًا مثيرًا للاهتمام بالنسبة لك مؤخرًا؟
في السنتين الأخيرتين ، كنت أفعل شيئين. أولاً: القيام بالسحابة الداخلية لـ Booking.com. إنه مبني على Kubernetes. في هذه المناسبة ، كان لدي تقرير طويل وشامل عن برنامج Highload.
كان لدينا طريقة طويلة ومثيرة للاهتمام كيف بنينا سحابة لدينا. هذا هو مشروعي السابق ، والذي تركته لزميلي.
الآن أنا أتعامل مع موضوع يسمى Service Mesh. هذا ، في الواقع ، موضوع ساخن ، مثل Big Data و Kubernetes في وقت واحد.
الفكرة أن هناك ، من جهة ، بسيطة ، من ناحية أخرى ، معقدة - في بنية الخدمات المصغرة ، كل التفاعل يمر عبر الشبكة ، حسنًا ، إنها مثل جزء لا يتجزأ من الخدمات الصغيرة. والتفاعل في حد ذاته عملية معقدة ، يمكن أن يحدث الكثير هناك. هذا كله يحتاج الى السيطرة عليها. على وجه الخصوص ، يتم فرض قيود - إذا كان لدينا مجموعة متجانسة وتعمل وظيفتان ، ويمكن أن تثق هاتان الوظيفتان في بعضهما البعض ، لأنهما جزء من نفس العملية ، والآن ، من الناحية النظرية ، لا تستطيع الخدمات الدقيقة أن تثق في بعضها البعض.
كيف تعرف من أين يأتي الطلب؟ فيما يلي خدمة microservice ، ويأتي طلب HTTP. هل جاء فعلاً من الخدمة التي أعتقد منها؟ وبنفس الطريقة ، الخدمة التي تدعو إليها خدمة أخرى. أحتاج إلى التأكد من أن الخدمة التي أتصل بها هي الخدمة التي أحتاجها ، وليست نوعًا من الخدمة المزيفة. في المؤسسات الصغيرة ، ربما هذا ليس صحيحًا. وفي السيارات الكبيرة ، عندما يكون لديك آلاف وعشرات الآلاف من السيارات ، فلن تتبع كل آلة. وبالنسبة للشركات الكبيرة ، فهذه مشكلة خطيرة إلى حد ما. وهذا هو ، دعنا نقول ، كل شيء مبني على أساس عدم الثقة. كلما قمت بإجراء بعض الاتصالات ، يجب عليك إجراء التحقق. اتضح أنه على مستوى تفاعل الشبكة ، من الضروري المصادقة على العملية والترخيص بها. هذه كلها عمليات صعبة للغاية من حيث التنفيذ. واتضح أن Service Mesh تتولى هذه المهام لضمان تفاعل آمن. هذه مجرد واحدة من الميزات التي تقوم بها شبكة الخدمة. هناك ما هو أكثر من ذلك بكثير - الموثوقية والرصد والتعقب وغيرها.
وهل تعتقد أن هذه التكنولوجيا هي المستقبل؟
شبكة الخدمة هو الاتجاه الذي ينمو. هذا هو رأيي الشخصي. انها بالفعل شائعة جدا. على سبيل المثال ، هناك Istio. ثم في الغيوم ، في نفس الأمازون ، ظهرت شبكة الخدمة. أعتقد أن جميع الموردين الرئيسيين سيحصلون قريبًا أو بالفعل على شبكة خدمة كاملة.
وهذا هو ، نفس التكنولوجيا اختراق كما كان من قبل ، والآن هناك Kubernetes؟
أعتقد ذلك. على الرغم من أنه من المثير للاهتمام أن نلاحظ هنا أنه في رأيي لا يخترع Kubernetes ولا Service Mesh أي شيء جديد. استغرق Kubernetes كومة التكنولوجيا الحالية وجعلها الأتمتة. شبكة الخدمة يفعل الشيء نفسه تقريبا. انه يعطي أدوات جديدة على قاعدة موجودة. لقد ظهر المبعوث في شبكة الخدمة ، والتي سأظهرها اليوم. (ملاحظة عالج إيفان هذه المشكلة في كلمة ألقاها في Slurm DevOps بشكل مكثف ). والفكرة هي أن شبكة الخدمة هي أداة عالية المستوى تتيح لك تنظيم اتصالات أسطول كبير من الخدمات المصغرة. سأشرح ... من أجل بدء تشغيل بنية الخدمات المصغرة ، ستحتاج أولاً إلى وقت التشغيل المزعوم - هذا هو المكان الذي سيتم فيه تشغيل التطبيق. هذا ما يفعله Kubernetes. تكملها شبكة الخدمة ، بمعنى أنها توفر التفاعل بين هذه الخدمات الصغيرة التي سيتم تشغيلها في وقت التشغيل.
هل ستطور هذه التكنولوجيا في المستقبل القريب؟
يمكنني التحدث عن نفسي. أنا مشترك في البنية التحتية. وفيما يتعلق بالبنية التحتية ، خلال السنوات القليلة المقبلة ، سيكون هذا أحد الموضوعات الرئيسية - Kubernetes و Service Mesh.
هل سيتطورون بالتوازي؟
بالتأكيد ، لأنها تكمل بعضها البعض. Kubernetes لا وقت التشغيل. توفر شبكة الخدمة إمكانية التشغيل المتداخل.
بتعبير أدق ، لدى Kubernetes بعض المكونات التي يبدو أنها تغطي جوانب شبكة الخدمة. ولكن في Kubernetes أنها أساسية للغاية. وهذا هو ، Kubernetes ، من حيث الشبكات ، يمنحك الشبكات ذات المستوى المنخفض فقط. أقصد ، يمكن أن تنتقل حزم IP من النقطة A إلى النقطة B. حسنًا ، هناك وحدات تحكم Ingress ، هناك لحظات من التوجيه على مستوى أعلى ، وهذا ليس فقط تفاعل الشبكة. ومع ذلك ، في Kubernetes ، على سبيل المثال ، لا توجد آليات مدمجة لضمان موثوقية تنفيذ الاستعلام. هذا مثال بسيط جدا. في Kubernetes ، إذا سقطت كلمة "under" (Pod) ، فإن Kubernetes ستلتقطها بنفسها. افتراضيا. هذه هي آلية إعادة المحاولة. لكن على مستوى تفاعل الشبكة ، لا يحدث هذا. أي إذا أرسلت خدمة الصفحة الرئيسية طلبًا إلى خدمة السلة ، ولم يعمل هذا لسبب ما ، فلن تتم إعادة محاولة الطلب.
شبكة الخدمة في هذا الصدد يضيف وظيفة. يسمح ، في حالة فشل الطلب ، بتكراره مرة أخرى. هناك آليات أخرى مثل الكشف الخارجي. إذا كان لدينا ، على سبيل المثال ، أسطول من "السنفات" التي تعمل لخدمة "الصفحة الرئيسية" ، وأسطول من "السنفات" التي تمثل خدمة سلة. إذا كانت منفصلة جغرافياً ، يمكن أن تظهر الأشياء فيها أن أحد أجزاء "الموقد" يرى جزءًا من "الموقد" والجزء الآخر من "الموقد" يرى الجزء الآخر من "الموقد". وفقًا لذلك ، توجد في شبكة الخدمة آليات تتيح لك إنشاء صورة ديناميكية لأي شخص متاح لأي شخص ، والتبديل بينها - كل هذا في الوقت الفعلي. وإذا كان لدى أحد "الموقد" الكثير من الكمون ، فاتركه بعيدًا. يمكن للجميع "دون" أن يقرروا أنه مع هذه "الموقد" تكون محادثتي بطيئة - أي شخص آخر طبيعي ، وبطيء - لأنني سوف أخرجه من حمام السباحة الخاص بي. هذه هي الطريقة التي تعمل بها آلية الكشف عن الحالات الشاذة. عندما يكون لدينا عشرة "موقد" ، تعمل تسعة "موقد" دون أخطاء ، والعاشر يرسل باستمرار أخطاء. أو تسعة "الموقد" الاستجابة مع الكمون من 15 مللي ثانية ، وإجابة واحدة مع الكمون من 400 مللي ثانية. وتقرر خدمة شبكة لرميها بعيدا.
خدمة شبكة جيدة أيضا في السماح لك بجمع الإحصاءات من جانب العميل. هذا هو ، لدينا عميل ، ولدينا خادم. عادة ما يتم جمع الإحصاءات على جانب الخادم. حسنًا ، لأنها الأسهل. نريد استخدام المقاييس لفهم مدى تفاعل المستخدم مع خدمتنا. وفقًا لذلك ، من الناحية النظرية ، تحتاج إلى القياس من جانب العميل ، وليس من جانب الخادم. لأن هناك فجوة كبيرة بينهما ، وهي مليئة بتفاعلات الشبكة.
كل مكون من هذه المجموعة الكاملة يمكن أن يفشل.
وشبكة الخدمة جيدة من حيث أنها تعيد الوكلاء جيئة وذهابا - وترسل إحصائيات من طرفين. وقد تنشأ مواقف عندما يكون زمن الوصول على الخدمة 20 مللي ثانية ، وعلى جانب العميل ثانيتين. على سبيل المثال ، على جانب الخادم ، نقوم بتجميع الإحصاءات من خادم الويب ، ولكن لدينا 5٪ من الحزم المفقودة لسبب ما. نتيجة لذلك ، بسبب إعادة الإرسال في مكدس TCP ، اتضح أن عميلنا يرى زمن الوصول خلال ثانيتين. وعلى جانب الخادم ، ما زلنا نرى استتارًا ممتازًا: حيث تم إرسال كل شيء إلى المخزن المؤقت ، هذا كل شيء! أنا بخير ، لدي كمون 20 مللي ثانية. وما هو العميل مثل؟!
وكيف يمكنك حل هذا؟
في الأساس ، يتم حل هذا عن طريق الأجهزة العميل. بطريقة جيدة ، يجب جمع الإحصاءات في أقرب وقت ممكن للعميل. لكن أدوات العملاء ليست ممكنة دائمًا وغير مريحة دائمًا.
ما هي مقاييس موثوقية وتوافر شركتك؟
كل شيء إلى حد كبير القياسية. اليوم سأتحدث عن ذلك. (ملاحظة. خطاب إيفان في اليوم الثالث من Slurm DevOps ) هناك خمسة أو ستة مؤشرات رئيسية. ما يسمى بمؤشرات مستوى الخدمة: الكمون والمتانة والنضارة والصحة ... عندما كنت أستعد للعرض التقديمي على Slurm ، حاولت أن أجد حالات غير قياسية في Booking.com ، وهي أمثلة مثيرة للاهتمام عن SLI لم تتناسب مع هذا النموذج. نظرًا لأن الفكرة الأساسية لـ SRE تستند ، من الناحية النظرية ، إلى أحد هذه العبارات رفيعة المستوى - نحتاج إلى إبراز مقياس أو مقاييس تعكس تجربة المستخدم. وبالنسبة لبعض الخدمات ، الكمون ، المتانة مناسبة ، وبالنسبة للآخرين فهي ليست كذلك. وكيفية العثور على نقطة التوازن هذه التي ستعكس تجربة المستخدم - هذه مهمة مثيرة للاهتمام.
ما هي الحلول الفريدة التي شاهدتها على Booking.com عندما أتيت للعمل هناك؟ أو هل كل شيء قياسي؟
لا. لدينا الكثير من الأشياء "غير القياسية". دعنا نفسر سبب كونه غير قياسي في علامات الاقتباس. من أين تأتي المعايير غير القياسية ... غالباً ما تأتي المعايير غير القياسية من حقيقة أن الشركة واجهت مشكلة في وقت أبكر من السوق ، وبالتالي لا يوجد حل "قياسي". في هذا الصدد ، Booking.com ، كونها شركة تعمل في السوق منذ عام 1997 ونمت إلى هذا الحجم ، واجهت في وقت واحد مع عدد من المشاكل التي لم يتم حلها.
على سبيل المثال ، جوجل. وفقا لملاحظاتي ، يبدو شيء من هذا القبيل. في الداخل ، يقومون بإجراء تطورات كبرى ، يتم طرحها في الأماكن العامة خلال خمس أو عشر سنوات. على سبيل المثال ، تحدثت مع اللاعبين من Google الذين قاموا بتصحيح نواة Linux. ثم كان لدي بعض المشاكل في مكدس TCP. أقول لهم: "من الواضح أن هذه هي المشكلة الأساسية. كيف تحارب هذا؟ " يقولون: "آه ، لذلك لدينا نواة مصححة. هنا يمكننا قرص الإعداد. في عام 2013 ، قمنا بتصحيحها. ونحن نطرحها في المصدر المفتوح عام 2018. "
عن نفسه مع شبكة الخدمة. وهي أيضًا مدمجة في صورة التكنولوجيا التي تستخدمها Google داخليًا. لكنهم لا تحميله مباشرة لفتح المصدر. Istio هو في الأساس إعادة تطبيق مفتوح المصدر لنظامهم الداخلي. مع Kubernetes كذلك. في رأيي ، هذا لأنه عندما تكون الشركة رائدة ، فإنها تخلق حلولًا لنفسها. لأنه أسرع وأرخص. المصدر المفتوح باهظ الثمن. وبغض النظر عمن يقول أنك بحاجة إلى نشرها ، فأنت بحاجة حقًا إلى بناء مجتمع. لبناء مجتمع ، تحتاج إلى استثمار مجموعة كبيرة من الجهود. وعندها فقط ستذهب العودة إليك. يبدو لي أنه خلف أي "صيدليات" جادة ، يوجد تسويق أكثر جدية ، حيث يتم استثمار الأموال بشكل طبيعي.
لماذا أنا ... كما قلت ، عند حل مشكلة ، فإن الشركة تفعل الكثير لنفسها. ثم وضعه في المصدر المفتوح صعب للغاية. تحتاج إلى قطع منطق العمل ومجموعة من التفاصيل الصغيرة. لدينا شبكة الخدمة الخاصة بنا ، ونظام المراقبة الخاص بنا. ولنشرها في المصادر المفتوحة ، يجب إعادة بنائها. منشور مفتوح المصدر له مزاياه ...
أي ، على سبيل المثال؟
العلامة التجارية التكنولوجيا ، والولاء ، وأسهل على متن الطائرة. إنها مهمة.
لا يمكنك حسابها مباشرة.
نعم هذا صحيح. لا تحسب مباشرة. هذا استثمار استراتيجي طويل الأجل. أنا لست مع أو ضد المصدر المفتوح. يجب أن تكون متوازنا ، وتقييم ما تعطيه الشركة لنشر تقنية معينة. التوازن بين استراتيجية طويلة الأجل وقصيرة الأجل.
بالرجوع إلى السؤال ، كم هو قياسي وغير قياسي في Booking.com. سأقول هذا ، وليس الغالبية غير قياسية ، لكن الكثير. لأننا كنا نحل المشاكل التي لا تزال غير معروفة في السوق ، أو أن الشركات الأخرى كانت فقط في بداية الرحلة. فقط للشركة ، فهي أسهل وأسرع وأرخص في حل المشكلات بأنفسهم.
ملحوظة : لا يمكن تغطية موضوع SRE بأكمله في عرض تقديمي واحد. لا توجد أدوات فقط ، فهناك أيضًا فلسفة النهج. لذلك ، سلطنا الضوء على Slurm SRE مكثفة بالكامل لهذا الموضوع ، والذي سيعقد في الفترة من 3-5 فبراير 2020 . سيكون المتحدثون هم إيفان كروغلوف ، المطور الرئيسي في Booking.com ، وزميله بن تايلر ، المطور الرئيسي في Booking.com ، إدوارد ميدفيديف ، CTO لدى Tungsten Labs ، يوجين فاراففا ، مطور غوغل واسع النطاق.