Өнгөрсөн долоо хоногт би Екатеринбургт болсон DUMP IT бага хуралд (https://dump-ekb.ru/) очиж, Backend болон Devops хэсгүүдэд юу хэлэлцсэн, бүс нутгийн мэдээллийн технологийн бага хурал нь анхаарал татахуйц байгаа эсэхийг танд хэлэхийг хүсч байна.
Evil Martians киноны Николай Сверчков Сервергүй тухай
Тэнд юу байсан бэ?
Тус хурал нь Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management гэсэн нийт 8 хэсэгтэй байв.
Хамгийн том танхимууд нь Шинжлэх ухаан ба менежментэд байдаг)) Тус бүрдээ ~350 хүнд зориулагдсан. Backend болон Frontend нь тийм ч жижиг биш юм. Devops өрөө хамгийн жижиг боловч идэвхтэй байсан.
Би Devops болон Backend хэсгүүдийн илтгэлүүдийг сонсож, илтгэгчидтэй бага зэрэг ярилцсан. Чуулган дээр хөндсөн сэдвүүдийн талаар ярилцаж, эдгээр хэсгүүдийг тоймлон үзэхийг хүсч байна.
Devops болон Backend хэсгүүдэд SKB-Kontur, DataArt, Evil Martians, Екатеринбургийн вэб студи Flag, Miro (RealTimeBoard)-ын төлөөлөгчид үг хэлэв. CI/CD, дарааллын үйлчилгээтэй ажиллах, сервергүй сэдвүүд болон Go-д PostgreSQL-тэй ажиллах зэрэг сэдвүүд сайн тусгагдсан.
Мөн Авито, Тинкофф, Яндекс, Жетстайл, Мегафон, Ак Барс банкны тайлангууд байсан, гэхдээ би тэдэнд биечлэн очиж амжаагүй (видео бичлэг, тайлангийн слайд хараахан гараагүй байна, тэд хогийн цэг дээр байрлуулахаа амлаж байна) ekb.ru 2 долоо хоногийн дотор).
Devops хэсэг
Хамгийн хачирхалтай нь секц хамгийн жижиг буюу 50 орчим хүний суудалтай танхимд болдог байсан. Хүмүүс коридорт хүртэл зогсож байсан :) Би сонсож амжсан тайлангаа танд хэлье.
Петабайт жинтэй уян харимхай
Энэ хэсэг Контур дахь Elasticsearch-ийн тухай Владимир Лилийн (SKB-Kontur) илтгэлээр эхэлсэн. Тэдгээр нь нэлээд том бөгөөд ачаалал ихтэй уян хатан (~800 TB өгөгдөл, илүүдлийг харгалзан ~ 1.3 петабайт) байдаг. Контурын бүх үйлчилгээнд зориулсан Elasticsearch нь дан бөгөөд 2 кластераас (7 ба 9 серверээс) бүрддэг бөгөөд Контур нь тусгай Elasticsearch инженертэй (үнэндээ Владимир өөрөө) маш чухал юм.
Владимир мөн Elasticsearch-ийн ашиг тус, түүний авчрах асуудлуудын талаар санал бодлоо хуваалцав.
Ашиг тус:
- Бүх бүртгэлүүд нэг дор байгаа тул тэдгээрт хялбар хандах боломжтой
- Бүртгэлийг нэг жилийн турш хадгалж, тэдгээрийг хялбархан шинжлэх
- Логтой ажиллах өндөр хурд
- Хайрцагнаас гарсан гайхалтай өгөгдөл дүрслэл
Асуудлууд:
- мессеж брокер бол заавал байх ёстой (Контурын хувьд түүний үүргийг Кафка гүйцэтгэдэг)
- Elasticsearch Куратортой ажиллах онцлог (Curator дахь ердийн ажлуудаас үе үе өндөр ачаалал үүсгэдэг)
- суурилагдсан зөвшөөрөл байхгүй (зөвхөн тусдаа, нэлээд их мөнгө, эсвэл үйлдвэрлэхэд бэлэн янз бүрийн түвшний нээлттэй эхийн залгаасууд)
Open Distro for Elasticsearch-ийн талаар зөвхөн эерэг тоймууд байсан :) Зөвшөөрлийн ижил асуудал тэнд шийдэгдсэн.
Петабайт хаанаас гардаг вэ?Тэдний зангилаа нь 12*8 Tb SATA + 2*2 Tb SSD бүхий серверүүдээс бүрдэнэ. SATA дээр хүйтэн хадгалах, зөвхөн халуун кэш (халуун хадгалах) зориулалттай SSD.
7+9 сервер, (7 + 9) * 12 * 8 = 1536 Tb.
Орон зайн нэг хэсэг нь нөөцөд байгаа, нөөцлөх гэх мэт.
90 орчим програмын бүртгэлийг Elasticsearch руу илгээдэг бөгөөд үүнд Kontur, Elba гэх мэт мэдээллийн бүх үйлчилгээ орно.
Serverless дээр хөгжүүлэлтийн онцлогууд
Дараа нь DataArt-аас Руслан Серкиний хийсэн Сервергүй байдлын талаархи тайлан.
Руслан Сервергүй хандлагын хөгжил гэж юу болох, түүний онцлог шинж чанаруудын талаар ярилцав.
Сервергүй гэдэг нь хөгжүүлэгчид дэд бүтцэд ямар ч байдлаар хүрдэггүй хөгжлийн арга юм. Жишээ - AWS Lambda Serverless, Kubeless.io (Kubernetes дотор сервергүй), Google Cloud Functions.
Хамгийн тохиромжтой сервергүй програм нь тусгай API гарцаар дамжуулан сервергүй үйлчилгээ үзүүлэгч рүү хүсэлт илгээдэг энгийн функц юм. AWS Lambda нь орчин үеийн олон тооны програмчлалын хэлүүдийг дэмждэг бол хамгийн тохиромжтой микро үйлчилгээ юм. Үүл үйлчилгээ үзүүлэгчийн хувьд дэд бүтцийг хадгалах, ашиглах зардал тэг болж, жижиг програмуудыг дэмжих нь маш хямд байх болно (AWS Lambda - 0.2 доллар / 1 сая энгийн хүсэлт).
Ийм системийн өргөтгөх чадвар нь бараг тохиромжтой - үүл үйлчилгээ үзүүлэгч өөрөө үүнийг хариуцдаг, Kubeless нь Кубернетес кластер дотор автоматаар хэмжигддэг.
Сул талууд байдаг:
- том програмуудыг хөгжүүлэх нь улам хэцүү болж байна
- Профайл үүсгэхэд бэрхшээлтэй байдаг (та зөвхөн бүртгэлд хандах боломжтой, гэхдээ ердийн утгаараа профайл хийх боломжгүй)
- хувилбар байхгүй
Үнэнийг хэлэхэд, би хэдэн жилийн өмнө Serverless-ийн талаар сонссон боловч энэ олон жилийн турш үүнийг хэрхэн зөв ашиглах нь надад тодорхойгүй байсан. Руслан илтгэл тавьсны дараа ойлголт гарч ирж, Николай Сверчковын (Муу Ангарагчууд) арын хэсгийн илтгэлийн дараа нэгтгэв. Чуулганд дэмий л явсангүй :)
CI нь ядуу хүмүүст зориулагдсан эсвэл вэб студид зориулж өөрийн CI бичих нь зүйтэй болов уу?
Екатеринбургийн "Flag" вэб студийн тэргүүн Михаил Радионов өөрөө бичсэн CI/CD-ийн талаар ярьжээ.
Түүний студи нь "гарын авлагын CI/CD" (SSH-ээр серверт нэвтэрч, git pull хийж, өдөрт 100 удаа давт) Женкинс болон Пулкинс гэж нэрлэгддэг кодыг хянах, хувилбаруудыг гаргах боломжийг олгодог гэртээ бичсэн хэрэгсэл рүү шилжсэн. .
Женкинс яагаад ажиллаагүй юм бэ? Энэ нь анхдагчаар хангалттай уян хатан байдлыг хангаагүй бөгөөд өөрчлөхөд хэтэрхий хэцүү байсан.
"Туг" нь Laravel (PHP framework) дээр хөгждөг. CI/CD серверийг боловсруулахдаа Михаил болон түүний хамтрагчид Телескоп ба Элч гэж нэрлэгддэг Laravel механизмуудыг ашигласан. Үр дүн нь ирж буй вэб дэгээний хүсэлтийг боловсруулж, урд болон арын хэсгийг бүтээж, өөр серверт байршуулж, Slack-д тайлагнадаг PHP-д сервер гарч ирнэ (санна уу).
Дараа нь цэнхэр/ногоон байршуулалт хийж, dev-stage-prod орчинд жигд тохиргоотой байхын тулд тэд Docker руу шилжсэн. Давуу талууд хэвээр үлдэж, хүрээлэн буй орчныг нэгэн төрлийн болгох, саадгүй байршуулах боломжууд нэмэгдэж, Docker-тэй зөв ажиллаж сурах хэрэгцээ нэмэгдсэн.
Бид хэрхэн серверийн хувилбарыг буцаах тоог 99% бууруулсан бэ?
Devops хэсгийн сүүлчийн тайланг Miro.com (хуучнаар RealTimeBoard)-ийн ахлах инженер Виктор Еремченкогийн хийсэн.
Miro багийн тэргүүлэх бүтээгдэхүүн болох RealTimeBoard нь цул Java програм дээр суурилдаг. Сул зогсолтгүйгээр цуглуулах, турших, ашиглах нь хэцүү ажил юм. Энэ тохиолдолд кодын ийм хувилбарыг ашиглах нь чухал бөгөөд ингэснээр үүнийг буцааж эргүүлэх шаардлагагүй (энэ нь хүнд цул юм).
Үүнийг хийх боломжийг олгодог системийг бий болгох замдаа Миро архитектур, ашигласан багаж хэрэгсэл (Atlassian Bamboo, Ansible гэх мэт) болон багуудын бүтэц (тэд одоо байгаа) дээр ажиллах зэрэг замыг туулсан. зориулагдсан Devops баг + өөр өөр профайл хөгжүүлэгчдээс олон тусдаа Scrum баг).
Зам нь хэцүү, өргөстэй болж, Виктор хуримтлагдсан өвдөлт, өөдрөг үзлийг хуваалцсан нь үүгээр дуусаагүй юм.
Асуулт асууж ном хожсон
Ар талын хэсэг
Би Николай Сверчковын (Муу Ангарагчууд), Сервергүйн тухай, Григорий Кошелевын (Контур компани) телеметрийн талаархи хоёр илтгэлд оролцож чадсан.
Энгийн мөнх бус хүмүүсийн хувьд сервергүй
Хэрэв Руслан Сиркин Сервергүй гэж юу болох талаар ярьсан бол Николай Сервергүй програмыг ашиглан энгийн програмуудыг үзүүлж, AWS Lambda програмын өртөг, хурдад нөлөөлдөг нарийн ширийн зүйлсийн талаар ярилцав.
Сонирхолтой мэдээлэл: хамгийн бага төлбөртэй элемент нь 128 Мб санах ой, 100 мс CPU, 0,000000208 долларын үнэтэй. Түүгээр ч барахгүй сард 1 сая ийм хүсэлт үнэ төлбөргүй байдаг.
Николайгийн зарим функцууд нь ихэвчлэн 100 мс-ийн хязгаараас хэтэрдэг (үндсэн програм нь Ruby дээр бичигдсэн) тул тэдгээрийг Go дээр дахин бичих нь маш сайн хэмнэлт өгсөн.
Восток Геркулес - телеметрийг дахин гайхалтай болго!
Григорий Кошелевын (Контур компани) телеметрийн талаархи Backend хэсгийн хамгийн сүүлийн тайлан. Телеметр гэдэг нь лог, хэмжүүр, програмын мөр гэсэн үг.
Энэ зорилгоор Contour нь Github дээр байрлуулсан өөрөө бичсэн хэрэгслүүдийг ашигладаг. Тайлангийн хэрэгсэл - Геркулес, , нь телеметрийн өгөгдлийг дамжуулахад ашиглагддаг.
Владимир Лилагийн Devops хэсэгт хийсэн илтгэл нь Elasticsearch-д бүртгэлийг хадгалах, боловсруулах талаар ярилцсан боловч олон мянган төхөөрөмж, програмын бүртгэлийг хүргэх ажил байсаар байгаа бөгөөд Vostok Hercules зэрэг хэрэгслүүд үүнийг шийддэг.
Энэхүү хэлхээ нь RabbitMQ-аас Апачи Кафка хүртэлх олон хүнд мэддэг замаар явсан, гэхдээ бүх зүйл тийм ч энгийн биш юм)) Тэд хэлхээнд Zookeeper, Cassandra, Graphite нарыг нэмэх шаардлагатай болсон. Би энэ тайлангийн мэдээллийг бүрэн задруулахгүй (миний профайл биш), хэрэв та сонирхож байгаа бол хурлын вэбсайт дээрх слайд, видеог хүлээж болно.
Бусад чуулгантай харьцуулахад ямар байна вэ?
Би үүнийг Москва, Санкт-Петербургт болсон бага хуралтай харьцуулж чадахгүй, би Уралын бусад арга хэмжээ, Самара дахь 404fest-тэй харьцуулж чадна.
DAMP нь 8 хэсэгт явагддаг бөгөөд энэ нь Уралын бага хурлын дээд амжилт юм. Шинжлэх ухаан, менежментийн маш том хэсгүүд, энэ нь бас ер бусын юм. Екатеринбург дахь үзэгчид нэлээд бүтэцтэй байдаг - тус хотод Yandex, Kontur, Tinkoff зэрэг томоохон хөгжлийн хэлтэсүүд байдаг бөгөөд энэ нь тайланд өөрийн гэсэн ул мөр үлдээдэг.
Өөр нэг сонирхолтой зүйл бол олон компаниуд чуулганд нэг дор 3-4 илтгэгчтэй байдаг (энэ нь Kontur, Evil Martians, Tinkoff-д байсан). Тэдний олонх нь ивээн тэтгэгч байсан ч тайлангууд нь бусадтай нэлээн зэрэгцэж байгаа бөгөөд эдгээр нь сурталчилгааны тайлан биш юм.
Явах уу, явахгүй юу? Хэрэв та Урал эсвэл ойролцоо амьдардаг бол танд боломж байгаа бөгөөд сэдвүүдийг сонирхож байгаа бол - тийм ээ, мэдээжийн хэрэг. Хэрэв та холын аялал хийхээр төлөвлөж байгаа бол өмнөх жилүүдийн тайлан, видео сурвалжлагын сэдвүүдийг үзэх болно мөн шийдвэр гаргасан.
Бүс нутаг дахь бага хурлын өөр нэг давуу тал нь илтгэлийн дараа илтгэгчтэй харилцахад хялбар байдаг.
Дамп болон Екатеринбургт баярлалаа! )
Эх сурвалж: www.habr.com
