ذهبت الأسبوع الماضي إلى مؤتمر DUMP IT (https://dump-ekb.ru/) في يكاترينبرج وأريد أن أخبركم بما تمت مناقشته في قسمي Backend وDevops، وما إذا كانت مؤتمرات تكنولوجيا المعلومات الإقليمية تستحق الاهتمام.
نيكولاي سفيرشكوف من فيلم Evil Martians حول Serverless
ماذا كان هناك على أي حال؟
في المجمل، كان المؤتمر يتكون من 8 أقسام: الواجهة الخلفية، الواجهة الأمامية، الهاتف المحمول، الاختبار وضمان الجودة، Devops، التصميم، العلوم والإدارة.
بالمناسبة، أكبر القاعات موجودة في قاعة العلوم والإدارة)) وتتسع كل منها لحوالي 350 شخصًا. الواجهة الخلفية والواجهة الأمامية ليست أصغر بكثير. كانت غرفة Devops هي الأصغر حجمًا، ولكنها نشطة.
لقد استمعت إلى التقارير الموجودة في قسمي Devops وBackend وتحدثت قليلاً مع المتحدثين. أود أن أتحدث عن المواضيع التي تم تناولها ومراجعة هذه الأقسام في المؤتمر.
تحدث ممثلو SKB-Kontur، وDataArt، وEvil Martians، وEkaterinburg web studio Flag، وMiro (RealTimeBoard) في قسمي Devops وBackend. تمت تغطية المواضيع بشكل جيد مع CI/CD، والعمل مع خدمات قائمة الانتظار، والتسجيل، والموضوعات التي لا تحتوي على خادم، والعمل مع PostgreSQL في Go.
كانت هناك أيضًا تقارير من Avito، وTinkoff، وYandex، وJetstyle، وMegafon، وAk Bars Bank، لكن لم يكن لدي الوقت الكافي لحضورها فعليًا (تسجيلات الفيديو وشرائح التقارير غير متوفرة بعد، ويعدون بنشرها في غضون أسبوعين) على dump-ekb.ru).
قسم المطورين
وما كان مفاجئاً هو أن القسم أقيم في أصغر قاعة، حوالي 50 مقعداً. حتى أن الناس كانوا يقفون في الممرات :) سأخبركم بالتقارير التي تمكنت من الاستماع إليها.
مرونة تزن بيتابايت
بدأ القسم بتقرير بقلم فلاديمير ليل (SKB-Kontur) حول Elasticsearch في Kontur. لديهم مرونة كبيرة ومحملة إلى حد ما (~ 800 تيرابايت من البيانات، ~ 1.3 بيتابايت مع الأخذ في الاعتبار التكرار). يعد Elasticsearch لجميع خدمات Kontur واحدًا، ويتكون من مجموعتين (من 2 و7 خوادم)، وهو مهم جدًا لدرجة أن Kontur لديه مهندس Elasticsearch خاص (في الواقع، فلاديمير نفسه).
شارك فلاديمير أيضًا أفكاره حول فوائد Elasticsearch والمشكلات التي يجلبها.
الفوائد:
- جميع السجلات في مكان واحد، وسهولة الوصول إليها
- تخزين السجلات لمدة عام وتحليلها بسهولة
- سرعة عالية في العمل مع السجلات
- تصور رائع للبيانات خارج الصندوق
المشاكل هي:
- وسيط الرسائل أمر لا بد منه (بالنسبة لكونتور، يلعب كافكا دوره)
- ميزات العمل مع Elasticsearch Curator (يتم إنشاء تحميل عالي بشكل دوري من المهام العادية في Curator)
- لا يوجد ترخيص مدمج (فقط للحصول على أموال منفصلة أو كبيرة جدًا، أو كمكونات إضافية مفتوحة المصدر بدرجات متفاوتة من الاستعداد للإنتاج)
لم تكن هناك سوى مراجعات إيجابية حول Open Distro for Elasticsearch :) وتم حل نفس مشكلة الترخيص هناك.
من أين يأتي البيتابايت؟تتكون العقد الخاصة بهم من خوادم مزودة بـ 12*8 تيرابايت SATA + 2*2 تيرابايت SSD. التخزين البارد على SATA وSSD فقط لذاكرة التخزين المؤقت الساخنة (التخزين الساخن).
7+9 خوادم، (7 + 9) * 12 * 8 = 1536 تيرابايت.
جزء من المساحة احتياطي، مخصص للتكرار، وما إلى ذلك.
يتم إرسال سجلات من حوالي 90 تطبيقًا إلى Elasticsearch، بما في ذلك جميع خدمات إعداد التقارير الخاصة بـ Kontur وElba وما إلى ذلك.
ميزات التطوير على Serverless
التالي هو تقرير بقلم رسلان سيركين من DataArt حول Serverless.
تحدث رسلان عن التطوير مع النهج بدون خادم بشكل عام، وما هي ميزاته.
يعد Serverless أسلوبًا للتطوير لا يلمس فيه المطورون البنية التحتية بأي شكل من الأشكال. مثال - AWS Lambda Serverless، Kubeless.io (بدون خادم داخل Kubernetes)، Google Cloud Functions.
التطبيق المثالي بدون خادم هو ببساطة وظيفة ترسل طلبًا إلى موفر بدون خادم من خلال بوابة API خاصة. إنها خدمة صغيرة مثالية، بينما تدعم AWS Lambda أيضًا عددًا كبيرًا من لغات البرمجة الحديثة. تصبح تكلفة صيانة ونشر البنية التحتية صفرًا في حالة مقدمي الخدمات السحابية، وسيكون دعم التطبيقات الصغيرة أيضًا رخيصًا جدًا (AWS Lambda - 0.2 دولار أمريكي / 1 مليون طلب بسيط).
تعد قابلية التوسع لمثل هذا النظام مثالية تقريبًا - حيث يعتني موفر السحابة بذلك بنفسه، ويقوم Kubeless بالتوسع تلقائيًا داخل مجموعة Kubernetes.
هناك عيوب:
- أصبح تطوير التطبيقات الكبيرة أكثر صعوبة
- هناك صعوبة في ملفات تعريف التطبيقات (السجلات فقط متاحة لك، ولكن ليس ملفات التعريف بالمعنى المعتاد)
- لا الإصدارات
لأكون صادقًا، سمعت عن Serverless منذ بضع سنوات، لكن طوال هذه السنوات لم يكن من الواضح بالنسبة لي كيفية استخدامه بشكل صحيح. بعد تقرير رسلان، ظهر التفاهم، وبعد تقرير نيكولاي سفيرشكوف (المريخيون الأشرار) من قسم الواجهة الخلفية، تم توحيده. لم يكن عبثًا أن أذهب إلى المؤتمر :)
CI مخصص للفقراء، أم أنه يستحق كتابة CI الخاص بك لاستوديو الويب؟
تحدث ميخائيل راديونوف، رئيس استوديو الويب Flag من يكاترينبرج، عن CI/CD المكتوب ذاتيًا.
انتقل الاستوديو الخاص به من "CI/CD اليدوي" (تسجيل الدخول إلى الخادم عبر SSH، وإجراء عملية سحب git، والتكرار 100 مرة يوميًا) إلى Jenkins وإلى أداة مكتوبة ذاتيًا تسمح لك بمراقبة التعليمات البرمجية وتنفيذ إصدارات تسمى Pullkins .
لماذا لم يعمل جنكينز؟ لم توفر مرونة كافية بشكل افتراضي وكان من الصعب جدًا تخصيصها.
تم تطوير "Flag" في Laravel (إطار عمل PHP). عند تطوير خادم CI/CD، استخدم ميخائيل وزملاؤه آليات Laravel المدمجة والتي تسمى Telescope وEnvoy. والنتيجة هي خادم بلغة PHP (يرجى ملاحظة ذلك) يعالج طلبات خطاف الويب الواردة، ويمكنه إنشاء الواجهة الأمامية والخلفية، والنشر على خوادم مختلفة، وتقديم تقرير إلى Slack.
بعد ذلك، لكي يتمكنوا من تنفيذ النشر باللون الأزرق/الأخضر والحصول على إعدادات موحدة في بيئات dev-stage-prod، قاموا بالتبديل إلى Docker. ظلت المزايا كما هي، وأضيفت إمكانيات تجانس البيئة والنشر السلس، وأضيفت الحاجة إلى تعلم Docker للعمل معها بشكل صحيح.
كيف قمنا بتقليل عدد عمليات التراجع عن إصدار الخادم بنسبة 99%
آخر تقرير في قسم Devops كان من Viktor Eremchenko، مهندس رئيسي في Miro.com (RealTimeBoard سابقًا).
RealTimeBoard، المنتج الرئيسي لفريق Miro، يعتمد على تطبيق Java متجانس. يعد جمعها واختبارها ونشرها دون توقف عن العمل مهمة صعبة. في هذه الحالة، من المهم نشر مثل هذه النسخة من التعليمات البرمجية بحيث لا يلزم التراجع عنها (إنها كتلة متراصة ثقيلة).
في طريقه لبناء نظام يسمح لك بالقيام بذلك، مر ميرو بمسار شمل العمل على البنية والأدوات المستخدمة (Atlassian Bamboo، Ansible، إلخ)، والعمل على هيكل الفرق (لديهم الآن فريق Devops مخصص + العديد من فرق Scrum المنفصلة من مطورين من ملفات تعريف مختلفة).
وتبين أن الطريق كان صعبا وشائكا، وشارك فيكتور الألم المتراكم والتفاؤل الذي لم ينته عند هذا الحد.
فاز بكتاب لطرح الأسئلة
قسم الواجهة الخلفية
تمكنت من حضور تقريرين - من نيكولاي سفيرشكوف (المريخيون الأشرار)، وأيضًا عن Serverless، ومن غريغوري كوشيليف (شركة Kontur) حول القياس عن بعد.
بدون خادم لمجرد البشر
إذا تحدث رسلان سيركين عن ماهية Serverless، فقد أظهر نيكولاي تطبيقات بسيطة باستخدام Serverless، وتحدث عن التفاصيل التي تؤثر على تكلفة وسرعة التطبيقات في AWS Lambda.
تفاصيل مثيرة للاهتمام: الحد الأدنى للعنصر المدفوع هو 128 ميجابايت من الذاكرة و100 مللي ثانية من وحدة المعالجة المركزية، ويكلف 0,000000208 دولار. علاوة على ذلك، هناك مليون طلب من هذا القبيل شهريًا مجانًا.
غالبًا ما تجاوزت بعض وظائف نيكولاي الحد الأقصى البالغ 100 مللي ثانية (تمت كتابة التطبيق الرئيسي بلغة Ruby)، لذا فإن إعادة كتابتها في Go قدمت توفيرًا ممتازًا.
فوستوك هرقل - اجعل القياس عن بعد رائعًا مرة أخرى!
أحدث تقرير لقسم الواجهة الخلفية من Grigory Koshelev (شركة Kontur) حول القياس عن بعد. القياس عن بعد يعني السجلات والمقاييس وآثار التطبيق.
ولهذا الغرض، يستخدم Contour أدوات مكتوبة ذاتيًا منشورة على Github. أداة من التقرير - هرقل، ، يستخدم لتقديم بيانات القياس عن بعد.
ناقش تقرير فلاديمير ليلا في قسم Devops تخزين السجلات ومعالجتها في Elasticsearch، ولكن لا تزال هناك مهمة تسليم السجلات من عدة آلاف من الأجهزة والتطبيقات، وأدوات مثل Vostok Hercules تحلها.
اتبعت الدائرة مسارًا معروفًا للكثيرين - من RabbitMQ إلى Apache Kafka، ولكن ليس كل شيء بهذه البساطة)) كان عليهم إضافة Zookeeper وCassandra وGraphite إلى الدائرة. لن أقوم بالكشف بشكل كامل عن المعلومات الواردة في هذا التقرير (وليس ملفي الشخصي)، إذا كنت مهتمًا، يمكنك انتظار الشرائح ومقاطع الفيديو على الموقع الإلكتروني للمؤتمر.
وكيف يمكن مقارنته بالمؤتمرات الأخرى؟
لا أستطيع مقارنتها بالمؤتمرات التي عقدت في موسكو وسانت بطرسبرغ، بل يمكنني مقارنتها بأحداث أخرى في جبال الأورال ومع مهرجان 404 في سمارة.
يتم عقد DAMP في 8 أقسام، وهذا سجل لمؤتمرات الأورال. أقسام العلوم والإدارة كبيرة جدًا، وهذا أيضًا أمر غير معتاد. الجمهور في يكاترينبرج منظم تمامًا - يوجد في المدينة أقسام تطوير كبيرة لـ Yandex و Kontur و Tinkoff وهذا يترك بصماته على التقارير.
نقطة أخرى مثيرة للاهتمام هي أن العديد من الشركات لديها 3-4 متحدثين في المؤتمر في وقت واحد (كان هذا هو الحال مع Kontur، Evil Martians، Tinkoff). كان العديد منهم من الجهات الراعية، لكن التقارير كانت على قدم المساواة تمامًا مع الآخرين، وهذه ليست تقارير إعلانية.
هل نذهب ام لا؟ إذا كنت تعيش في جبال الأورال أو بالقرب منها، فلديك الفرصة وتكون مهتمًا بالموضوعات - نعم بالطبع. إذا كنت تفكر في رحلة طويلة، فسألقي نظرة على موضوعات التقارير وتقارير الفيديو من السنوات السابقة واتخذ قرارا.
ميزة أخرى للمؤتمرات في المناطق، كقاعدة عامة، هي أنه من السهل التواصل مع المتحدث بعد التقارير، فإن المتقدمين لمثل هذا التواصل أقل ببساطة.
بفضل Dump و Ekaterinburg! )
المصدر: www.habr.com