هفته گذشته به کنفرانس DUMP IT (https://dump-ekb.ru/) در یکاترینبورگ رفتم و می‌خواهم به شما بگویم که در بخش‌های Backend و Devops چه بحث شده است و آیا کنفرانس‌های IT منطقه‌ای ارزش توجه دارند یا خیر.
نیکولای سورچکوف از مریخی های شیطانی در مورد سرور بدون سرور
اصلا اونجا چی بود؟
در مجموع، کنفرانس دارای 8 بخش بود: Backend، Frontend، Mobile، Testing و QA، Devops، Design، Science و Management.
به هر حال بزرگترین سالن ها در علم و مدیریت هستند)) برای هر 350 نفر. Backend و Frontend خیلی کوچکتر نیستند. اتاق Devops کوچکترین اما فعال بود.
من به گزارش های بخش Devops و Backend گوش دادم و کمی با بلندگوها صحبت کردم. من می خواهم در مورد موضوعات مطرح شده صحبت کنم و این بخش ها را در کنفرانس بررسی کنم.
نمایندگان SKB-Kontur، DataArt، Evil Martians، استودیوی وب Ekaterinburg Flag، Miro (RealTimeBoard) در بخش Devops و Backend صحبت کردند. موضوعات تحت پوشش CI/CD، کار با خدمات صف، ورود به سیستم؛ موضوعات بدون سرور و کار با PostgreSQL در Go به خوبی پوشش داده شدند.
همچنین گزارش هایی توسط Avito، Tinkoff، Yandex، Jetstyle، Megafon، Ak Bars Bank وجود داشت، اما من فرصت حضور فیزیکی در آنها را نداشتم (فیلم های ضبط شده و اسلایدهای گزارش ها هنوز در دسترس نیستند، آنها قول می دهند ظرف 2 هفته آنها را ارسال کنند. در dump-ekb.ru).
بخش Devops
چیزی که تعجب آور بود این بود که این بخش در کوچکترین سالن برگزار شد، حدود 50 صندلی. مردم حتی در راهروها ایستاده بودند :) من در مورد گزارش هایی که موفق به گوش دادن به آنها شدم به شما خواهم گفت.
الاستیک با وزن یک پتابایت
بخش با گزارشی از ولادیمیر لیل (SKB-Kontur) درباره Elasticsearch در Kontur آغاز شد. آنها یک الاستیک نسبتاً بزرگ و بارگذاری شده دارند (800 ترابایت داده، ~ 1.3 پتابایت با در نظر گرفتن افزونگی). Elasticsearch برای همه سرویس های Kontur تک است، از 2 خوشه (از 7 و 9 سرور) تشکیل شده است و به قدری مهم است که Kontur یک مهندس Elasticsearch ویژه دارد (در واقع خود ولادیمیر).
ولادیمیر همچنین نظرات خود را در مورد مزایای Elasticsearch و مشکلات آن به اشتراک گذاشت.
مزایا:
- همه سیاههها در یک مکان هستند، دسترسی آسان به آنها
- ذخیره سیاهههای مربوط به مدت یک سال و تجزیه و تحلیل آسان آنها
- سرعت بالای کار با لاگ
- تجسم داده های جالب خارج از جعبه
مشکلات این است:
- واسطه پیام ضروری است (برای کنتور نقش آن را کافکا بازی می کند)
- ویژگی های کار با Elasticsearch Curator (به طور دوره ای بار زیادی از وظایف معمول در Curator ایجاد می شود)
- بدون مجوز داخلی (فقط برای پول جداگانه، بسیار زیاد، یا به عنوان پلاگین منبع باز با درجات مختلف آمادگی برای تولید)
فقط نظرات مثبتی درباره Open Distro برای Elasticsearch وجود داشت :) همین مسئله مجوز در آنجا حل شده است.
پتابایت از کجا می آید؟نودهای آنها از سرورهایی با 12*8 ترابایت SATA + 2*2 ترابایت SSD تشکیل شده است. ذخیره سازی سرد در SATA، SSD فقط برای کش داغ (ذخیره سازی داغ).
7+9 سرور، (7 + 9) * 12 * 8 = 1536 ترابایت.
بخشی از فضا در رزرو است، برای افزونگی و غیره در نظر گرفته شده است.
گزارش‌ها از حدود 90 برنامه به Elasticsearch ارسال می‌شوند، از جمله کلیه خدمات گزارش‌دهی Kontur، Elba و غیره.
ویژگی های توسعه در سرور بدون سرور
در ادامه گزارشی از Ruslan Serkin از DataArt در مورد سرور بدون سرور ارائه شده است.
Ruslan در مورد اینکه به طور کلی توسعه با رویکرد سرور بدون سرور چیست و چه ویژگی هایی دارد صحبت کرد.
بدون سرور رویکردی برای توسعه است که در آن توسعه دهندگان به هیچ وجه زیرساخت را لمس نمی کنند. مثال - AWS Lambda Serverless، Kubeless.io (بدون سرور در Kubernetes)، Google Cloud Functions.
یک برنامه بدون سرور ایده آل به سادگی تابعی است که درخواستی را از طریق یک دروازه API ویژه به یک ارائه دهنده بدون سرور ارسال می کند. یک میکروسرویس ایده آل، در حالی که AWS Lambda از تعداد زیادی زبان برنامه نویسی مدرن نیز پشتیبانی می کند. هزینه نگهداری و استقرار زیرساخت در مورد ارائه دهندگان ابری صفر می شود، پشتیبانی از برنامه های کوچک نیز بسیار ارزان خواهد بود (AWS Lambda - 0.2 دلار / 1 میلیون درخواست ساده).
مقیاس‌پذیری چنین سیستمی تقریباً ایده‌آل است - ارائه‌دهنده ابر خودش این کار را انجام می‌دهد، Kubeless به طور خودکار در خوشه Kubernetes مقیاس می‌شود.
معایبی وجود دارد:
- توسعه برنامه های کاربردی بزرگ دشوارتر می شود
- در پروفایل کردن برنامه‌ها مشکل وجود دارد (فقط گزارش‌ها در دسترس شما هستند، اما پروفایل‌سازی به معنای معمول نیست)
- بدون نسخه سازی
راستش را بخواهید چند سال پیش در مورد Serverless شنیدم اما در تمام این سال ها نحوه استفاده درست از آن برایم روشن نبود. پس از گزارش روسلان، تفاهم ظاهر شد و پس از گزارش نیکولای سورچکوف (مریخی های شیطانی) از بخش Backend، ادغام شد. بیهوده نبودم که به کنفرانس رفتم :)
CI برای فقرا است یا ارزش نوشتن CI خود را برای یک استودیو وب دارد؟
میخائیل رادیونوف، رئیس استودیوی وب پرچم از یکاترینبورگ، در مورد CI/CD خودنوشته صحبت کرد.
استودیوی او از «CI/CD دستی» (ورود به سرور از طریق SSH، انجام git pull، 100 بار در روز تکرار) به Jenkins و به یک ابزار خودنویس تبدیل شده است که به شما امکان نظارت بر کد و اجرای نسخه‌هایی به نام Pullkins را می‌دهد. .
چرا جنکینز کار نکرد؟ به‌طور پیش‌فرض انعطاف‌پذیری کافی را ارائه نمی‌کرد و سفارشی‌سازی آن بسیار دشوار بود.
"Flag" در لاراول (فریم ورک پی اچ پی) توسعه می یابد. هنگام توسعه یک سرور CI/CD، میخائیل و همکارانش از مکانیزم های داخلی لاراول به نام تلسکوپ و فرستاده استفاده کردند. نتیجه یک سرور به زبان PHP است (لطفاً توجه داشته باشید) که درخواست‌های وب هوک دریافتی را پردازش می‌کند، می‌تواند فرانت‌اند و باطن را بسازد، در سرورهای مختلف مستقر شود و به Slack گزارش دهد.
سپس برای اینکه بتوانند در محیط‌های dev-stage-prod پیاده‌سازی آبی/سبز را انجام دهند و تنظیمات یکسانی داشته باشند، به Docker تغییر مکان دادند. مزایا ثابت ماند، امکانات همگن کردن محیط و استقرار بدون درز اضافه شد و نیاز به یادگیری Docker برای کار صحیح با آن اضافه شد.
چگونه تعداد بازگرداندن سرور را 99٪ کاهش دادیم
آخرین گزارش در بخش Devops از ویکتور ارمچنکو، مهندس پیشرو devops در Miro.com (RealTimeBoard سابق) بود.
RealTimeBoard، محصول شاخص تیم Miro، مبتنی بر یک برنامه جاوا یکپارچه است. جمع آوری، آزمایش و استقرار آن بدون توقف کار دشواری است. در این مورد، مهم است که چنین نسخه ای از کد را استقرار دهید تا نیازی به بازگرداندن آن نباشد (این یک یکپارچه سنگین است).
در مسیر ساختن سیستمی که به شما امکان انجام این کار را می‌دهد، میرو مسیری را طی کرد که شامل کار بر روی معماری، ابزارهای مورد استفاده (Atlassian Bamboo، Ansible و غیره) و کار بر روی ساختار تیم‌ها (آنها اکنون دارند). یک تیم اختصاصی Devops + بسیاری از تیم های Scrum جداگانه از توسعه دهندگان پروفایل های مختلف).
مسیر دشوار و پرخار بود و ویکتور درد و خوش بینی انباشته شده را که به همین جا ختم نشد با هم تقسیم کرد.
برنده کتاب برای پرسیدن سوال
بخش Backend
من موفق شدم در 2 گزارش شرکت کنم - از نیکولای سورچکوف (مریخیان شیطانی)، همچنین در مورد بدون سرور، و از گریگوری کوشلف (شرکت کنتور) در مورد تله متری.
بدون سرور برای انسان فانی
اگر روسلان سیرکین در مورد اینکه بدون سرور چیست صحبت کرد، نیکولای برنامه های ساده ای را با استفاده از سرور بدون سرور نشان داد و در مورد جزئیاتی صحبت کرد که بر هزینه و سرعت برنامه ها در AWS Lambda تأثیر می گذارد.
یک جزئیات جالب: حداقل عنصر پرداخت شده 128 مگابایت حافظه و 100 میلی ثانیه CPU است، قیمت آن 0,000000208 دلار است. علاوه بر این، 1 میلیون درخواست در ماه رایگان است.
برخی از عملکردهای نیکولای اغلب از حد 100 میلی‌ثانیه فراتر می‌رفتند (برنامه اصلی به زبان روبی نوشته شده بود)، بنابراین بازنویسی آنها در Go باعث صرفه‌جویی عالی شد.
Vostok Hercules - تله متری را دوباره عالی کنید!
آخرین گزارش بخش Backend از 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 بود). بسیاری از آنها حامیان مالی بودند، اما گزارش ها کاملاً برابر با دیگران است، اینها گزارش های تبلیغاتی نیستند.
رفتن یا نرفتن؟ اگر در اورال یا نزدیک آن زندگی می کنید، این فرصت را دارید و به موضوعات علاقه مند هستید - بله، البته. اگر به یک سفر طولانی فکر می کنید، به موضوعات گزارش ها و گزارش های تصویری سال های گذشته نگاه می کنم و تصمیم گرفت.
مزیت دیگر کنفرانس ها در مناطق، به عنوان یک قاعده، این است که پس از گزارش ها، به راحتی می توان با سخنران ارتباط برقرار کرد؛ به سادگی متقاضیان کمتری برای چنین ارتباطی وجود دارد.
با تشکر از دامپ و اکاترینبورگ! )
منبع: www.habr.com