Múlt héten részt vettem az IT DUMP konferencián (https://dump-ekb.ru/) Jekatyerinburgban, és szeretném elmondani, miről volt szó a Backend és Devops szekciókban, illetve érdemesek-e a figyelemre a regionális IT konferenciák.
Svercsakov Nikoláj az Evil Martianstól a Serverless-ről
Mi történt egyáltalán?
Összesen 8 szekció volt a konferencián: Backend, Frontend, Mobil, Tesztelés és QA, Devops, Design, Tudomány és Menedzsment.
A legnagyobb termek a Tudomány és a Menedzsment szekciókban voltak, körülbelül 350 fővel mindegyik. A Backend és a Frontend nem sokkal kisebb. A Devops terem volt a legkisebb, de a legaktívabb.
A Devops és Backend szekciókban hallgattam előadásokat, és egy kicsit beszélgettem az előadókkal. Szeretném elmondani az érintett témákról és átnézni ezeket a szekciókat a konferencián.
A Devops és Backend szekciókban a SKB-Kontur, DataArt, Evil Martians, a jekatyerinburgi Flag webstúdió, és a Miro (RealTimeBoard) képviselői szerepeltek. A témák a CI/CD-re, az üzenetsorok kezelésére, a naplózásra vonatkoztak, és jól körbejárták a Serverless-t és a PostgreSQL Go-ban való használatát.
Emellett voltak előadások az Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank részéről, de azokat fizikailag nem tudtam meglátogatni (az előadások videófelvételei és diákképei még nem elérhetők, ígérik, hogy 2 héten belül közzéteszik a dump-ekb.ru-n).
Devops szekció
Ami meglepett — a szekció a legkisebb teremben zajlott, körülbelül 50 hellyel. Az emberek már a folyosókon is álltak 🙂 Elmondom az előadásokat, amelyeket sikerült megfigyelnem.
Petabájtos Elastic
A szekció Vladimír Lilának (SKB-Kontur) az Elasticsearchről szóló előadásával indult. Náluk elég nagy és terhelt az Elastic (~800 TB adat, ~1,3 petabájtnyi redundanciával). Az Elasticsearch a Contour összes szolgáltatásához egységes, két klaszterből áll (7 és 9 szerverből), és annyira fontos, hogy a Contourban van egy külön Elasticsearch mérnök (maga Vladimír).
Vladimír szintén megosztotta a gondolatait az Elasticsearch hasznosságáról és a felmerülő problémákról.
Hasznosság:
- Minden napló egy helyen, könnyű hozzáférésük
- A naplók egy éven át történő tárolása és könnyű elemzése
- Magas sebesség a naplókkal való munkavégzéshez
- Kiváló adatalapú vizualizáció "do-it-yourself"
Problémák:
- üzenetbroker — elengedhetetlen (a Contournál ezt a szerepet a Kafka tölti be)
- az Elasticsearch Curator működésének sajátosságai (időszakosan magas terhelés a Curator rendszeres feladatai miatt)
- nincs beépített hitelesítés (csak külön, elég magas összegért, vagy nyílt forráskódú plug-inek különböző fokú készségét tekintve a produkcióhoz)
Az Open Distro for Elasticsearchről csak pozitív visszajelzések érkeztek 🙂 Ugyanaz a hitelesítési kérdés ott is megoldott.
Honnan van petabájt?A csomópontjaik 12*8 Tb SATA + 2*2 Tb SSD szerverekből állnak. A hideg tárolás SATA-n, az SSD csak a meleg gyorsítótárhoz (hot storage) szükséges.
7+9 szerver, (7 + 9) * 12 * 8 = 1536 Tb.
Részben tartalékban van hely, amely a redundanciára van fenntartva, stb.
Az Elasticsearchbe körülbelül 90 alkalmazás naplói érkeznek, beleértve a Kontúr és az Elba összes jelentési szolgáltatását.
Jellemzők a Serverless fejlesztésre
Most következik Ruslan Serkin előadása a DataArt-tól a Serverless-ről.
Ruslan arról beszélt, hogy mi a Serverless megközelítés, és mik a jellemzői.
A Serverless egy fejlesztési megközelítés, amelyben a fejlesztők egyáltalán nem érintkeznek az infrastruktúrával. Példa - AWS Lambda Serverless, Kubeless.io (Serverless a Kubernetes belsejében), Google Cloud Functions.
Az ideális Serverless alkalmazás egyszerűen egy funkció, amely kérdést küld a Serverless szolgáltatónak egy speciális API Gateway-en keresztül. Ideális mikroszolgáltatás, miközben az AWS Lambda-ban számos modern programozási nyelvet támogatnak. Az infrastruktúra fenntartásának és telepítésének költsége nullára csökken a felhőszolgáltatók esetében; a kis alkalmazások támogatása szintén nagyon olcsó lesz (AWS Lambda - 0,2 $ / 1 millió egyszerű kérés).
Ennek a rendszernek a skálázhatósága gyakorlatilag tökéletes - a felhőszolgáltató erre magától vigyáz, a Kubeless automatikusan méreteződik a Kubernetes klaszteren belül.
Vannak hátrányok:
- nagyobb alkalmazások fejlesztése összetettebbé válik
- komplikációk vannak az alkalmazások profilozásában (csak a naplók érhetőek el, de a szokásos értelemben nem létezik profilozás)
- nincs verziózás
Bevallom, hogy a Serverless-ről már évek óta hallottam, de mindezek alatt nem volt világos számomra, hogyan kell helyesen alkalmazni. Ruslan előadása után megértettem, és Nikolaj Svertshkov (Evil Martians) Backend szekciójából származó előadása után megerősítést nyert. Már megérte elmenni a konferenciára 🙂
CI a szegényeknek, vagy érdemes-e saját CI-t írni a webstúdió számára
Mihail Radionov, az Ekaterinburgi Flag webstúdió vezetője a saját CI/CD-jéről beszélt.
Stúdiója átment a „kézi CI/CD”-n (SSH-n belépve a szerverre, git pull, naponta 100-szor megismételve) Jenkins-re és egy saját eszközre, amely lehetővé teszi a kód ellenőrzését és a kiadásokat Pullkins néven.
Miért nem vált be a Jenkins? Alapértelmezetten nem biztosított elegendő rugalmasságot, és túl bonyolult volt a testreszabása.
A "Flag" Laravelban (PHP keretrendszer) készült. A CI/CD szerver fejlesztése során Mihail és kollégái a Laravel beépített mechanizmusait, a Telescope-ot és az Envoy-t használták. Ennek eredményeképpen létrejött egy PHP-alapú szerver (figyelem), amely képes feldolgozni a bejövő webhook kéréseket, front-end és back-end build elvégzésére, különböző szerverekre való telepítésre és jelentések küldésére a Slackbe.
Továbbá, hogy lehetőség legyen blue/green deploy végrehajtására, és egységes beállításokat biztosítani a dev-stage-prod környezetekben, átálltak a Dockera. Az előnyök maradtak a régiek, új lehetőségekkel bővült a környezet homogenizálására és a zökkenőmentes deploy-ra, és szükséges lett a Docker tanulmányozása a helyes használat érdekében.
Hogyan csökkentettük a szerver verziók visszavonásainak számát 99%-kal
Az utolsó előadás a DevOps szekcióban Viktor Jeremcsenko-tól érkezett, a Miro.com (korábbi RealTimeBoard) vezető devops mérnökétől.
A RealTimeBoard, a Miro csapat fő terméke, egy monolitikus Java alkalmazásra épül. Az alkalmazás összegyűjtése, tesztelése és telepítése leállás nélkül nehéz feladat. Fontos olyan kódverziót telepíteni, amelyet nem szükséges visszavonni (ez egy nehéz monolit).
A rendszerek kiépítése felé vezető úton a Miro olyan folyamatokon ment keresztül, amelyek magukba foglalták az architektúrán, a használt eszközökön (Atlassian Bamboo, Ansible, stb.), és a csapatok felépítésén végzett munkát (jelenleg van egy dedikált DevOps csapatuk + sok külön Scrum-csapat különböző profilú fejlesztőkből).
Az út nehéz és fáradságos volt, Viktor pedig megosztotta a felgyülemlett fájdalmát és az abból fakadó optimizmusát.
Könyvet nyertem a kérdésekért
Backend szekció
Két előadást sikerült meglesnem — Nikolaj Szerivcskovtól (Evil Martians), szintén a Serverless-ről, és Grigorij Kosselektól (Kontur cég) a telemetriáról.
Serverless a hétköznapi embereknek
Míg Ruszlan Szirkin a Serverless lényegéről beszélt, Nikolaj egyszerű alkalmazásokat mutatott be, amelyeket Serverless használatával készítettek, és elmesélte azokat a részleteket, amelyek befolyásolják az AWS Lambda-ban futó alkalmazások költségét és sebességét.
Érdekes részlet: a legkisebb számlázott elem — 128 Mb memória és 100 ms CPU, ami 0,000000208 $-ba kerül. Emellett havi 1 millió ilyen kérdés ingyenes.
Néhány funkció Nikolájánál gyakran túllépte a 100 ms-os határt (a fő alkalmazás Ruby nyelven készült), ezért ezek Go-ra való átírása kiváló megtakarítást hozott.
Vostok Hercules — állítsa vissza a telemetriát a régi fényébe!
Grigory Košeljev (Kontur cég) legutóbbi előadása a Backend szekcióban a telemetriáról. A telemetria logokat, metrikákat és alkalmazásnyomokat jelent.
A Kontur a saját írású eszközeit használja, amelyeket a Github-on tett közzé. Az előadásban említett eszköz — Hercules, , a telemetriai adatok átvitelére szolgál.
Vladimir Lila előadása a Devops szekcióban a logok Elasticsearch-on való tárolásáról és feldolgozásáról szólt, de van még egy feladat, hogy az ezernyi eszköz és alkalmazás logjait továbbítsuk, amit a Vostok Hercules-hoz hasonló eszközök oldanak meg.
A Kontur sokak számára ismert utat járt be — a RabbitMQ-tól az Apache Kafka-ig, de nem minden olyan egyszerű )) A sémához Zookeeper, Cassandra és Graphite hozzáadása is szükséges volt. Ezen előadás részleteit nem tudom teljes mértékben feltárni (nem az én területem), ha érdekli — meg lehet várni a konferencia weboldalán elérhető diákat és videókat.
Hogyan hasonlítják más konferenciákhoz?
Nem tudom összehasonlítani a moszkvai és a szentpétervári konferenciákkal, de tudom más rendezvényekhez az Uralban és a 404fesztiválhoz Szamarában.
A DAMP 8 szekciót tart, ami rekord auraliai konferenciák számára. Nagy, Science és Management szekciók is vannak, ami szintén szokatlan. Jekatyerinburgban a közönség elég strukturált — a városban nagy fejlesztési részlegek vannak, mint a Yandex, Kontur, Tinkoff, ami nyomot hagy az előadásokon is.
Egy érdekes dolog még — sok cégnél hárman-négyen is előadók a konferencián (így volt a Konturnál, Evil Martians-nál, Tinkoff-nál). Sok közülük szponzor volt, de az előadások színvonala teljesen azonos más előadásokkal, nem reklám jellegűek.
Menni vagy nem menni? Ha az Uralban él, és érdeklik a témák — igen, természetesen. Ha távolabbi utazásban gondolkodik — megnézném az előadások témáit és a korábbi évek videóit. és ennek alapján döntenék.
A regionális konferenciák egyik másik előnye, hogy általában könnyen lehet beszélgetni a beszélőkkel az előadások után, mivel kevesebb jelölt van az ilyen beszélgetésekre.
Köszönet a DAMP-nak és Jekatyerinburgnak! )
Forrás: habr.com
