Múlt héten elmentem a DUMP IT konferenciára (https://dump-ekb.ru/) Jekatyerinburgban, és szeretném elmondani, miről esett szó a Backend és a Devops szekciókban, és hogy érdemes-e figyelni a regionális informatikai konferenciákat.
Nikolay Sverchkov a Gonosz marslakókból a szerver nélküliről
Amúgy mi volt ott?
A konferencia összesen 8 szekcióból állt: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
A legnagyobb termek egyébként a Science and Management-nél vannak)) Egyenként ~350 fős. A háttér és a frontend nem sokkal kisebbek. A Devops szoba volt a legkisebb, de aktív.
Meghallgattam a beszámolókat a Devops és a Backend szekciókban, és beszélgettem egy kicsit az előadókkal. A tárgyalt témákról szeretnék beszélni, és áttekinteni ezeket a szekciókat a konferencián.
Az SKB-Kontur, a DataArt, az Evil Martians, az Ekaterinburg webstúdió Flag, Miro (RealTimeBoard) képviselői beszéltek a Devops és a Backend szekciókban. A témák kiterjedtek a CI/CD-re, a sorszolgáltatásokkal való munkavégzésre, a naplózásra; a kiszolgáló nélküli témákat és a PostgreSQL-lel való munkát a Go-ban jól lefedték.
Az Avito, a Tinkoff, a Yandex, a Jetstyle, a Megafon, az Ak Bars Bank riportjai is voltak, de nem volt időm fizikailag részt venni rajtuk (a riportokról videófelvételek és diafilmek még nem elérhetők, ígérik, hogy 2 héten belül közzéteszik őket a dump-ekb.ru oldalon).
Devops szakasz
Meglepő volt, hogy a szekció a legkisebb, mintegy 50 férőhelyes teremben zajlott. Még a folyosókon is álltak az emberek :) Mesélek a beszámolókról, amiket sikerült meghallgatnom.
Petabájt súlyú rugalmas
A szekció Vladimir Lil (SKB-Kontur) riportjával kezdődött a konturi Elasticsearchról. Meglehetősen nagy és terhelt Elastic van bennük (~800 TB adat, ~1.3 petabájt a redundanciát figyelembe véve). Az összes Kontur szolgáltatáshoz tartozó Elasticsearch egyetlen, 2 klaszterből áll (7 és 9 szerverből), és annyira fontos, hogy Konturnak van egy speciális Elasticsearch mérnöke (valójában maga Vladimir).
Vladimir megosztotta gondolatait az Elasticsearch előnyeiről és a vele járó problémákról is.
előnyök:
- Minden napló egy helyen található, könnyen elérhetők
- A naplók egy évig történő tárolása és egyszerű elemzése
- Nagy sebességű munka rönkökkel
- Menő adatvizualizáció a dobozból
A problémák a következők:
- az üzenetközvetítő kötelező (Kontur számára a szerepét Kafka játssza)
- az Elasticsearch Curatorral való munkavégzés jellemzői (időnként nagy terhelés a Curator rendszeres feladataiból)
- nincs beépített jogosultság (csak külön, meglehetősen nagy pénzért, vagy nyílt forráskódú bővítményként, különböző fokú gyártáskészültséggel)
Az Open Distro for Elasticsearch-ről csak pozitív vélemények érkeztek :) Ugyanez az engedélyezési probléma ott is megoldódott.
Honnan származik a petabájt?Csomópontjaik 12*8 Tb SATA + 2*2 Tb SSD-vel rendelkező szerverekből állnak. Hideg tárolás SATA-n, SSD csak a gyorsítótárhoz (hot storage).
7+9 szerver, (7 + 9) * 12 * 8 = 1536 Tb.
A hely egy része tartalék, redundanciára van fenntartva, stb.
Körülbelül 90 alkalmazás naplója kerül elküldésre az Elasticsearch-nek, beleértve a Kontur, Elba stb. összes jelentési szolgáltatását.
A szerver nélküli fejlesztés jellemzői
Következő Ruslan Serkin jelentése a DataArttól a Serverlessről.
Ruslan arról beszélt, hogy általában mi a szerver nélküli megközelítéssel történő fejlesztés, és mik a jellemzői.
A szerver nélküli fejlesztés olyan megközelítése, amelyben a fejlesztők semmilyen módon nem érintik az infrastruktúrát. Példa - AWS Lambda Serverless, Kubeless.io (Serverless a Kubernetesen belül), Google Cloud Functions.
Az ideális szerver nélküli alkalmazás egyszerűen egy olyan funkció, amely egy speciális API-átjárón keresztül kérést küld a szerver nélküli szolgáltatónak. Ideális mikroszolgáltatás, miközben az AWS Lambda számos modern programozási nyelvet is támogat. Az infrastruktúra fenntartási és telepítési költsége nullává válik a felhőszolgáltatók esetében, a kis alkalmazások támogatása is nagyon olcsó lesz (AWS Lambda - 0.2 USD / 1 millió egyszerű kérés).
Egy ilyen rendszer skálázhatósága szinte ideális - erről a felhőszolgáltató maga gondoskodik, a Kubeless a Kubernetes klaszteren belül automatikusan skáláz.
Vannak hátrányai:
- a nagy alkalmazások fejlesztése egyre nehezebb
- nehézségek vannak az alkalmazások profilozásával (csak a naplók állnak rendelkezésre, de a szokásos értelemben vett profilozás nem)
- nincs verziószámítás
Hogy őszinte legyek, néhány évvel ezelőtt hallottam a Serverlessről, de az évek során nem volt világos számomra, hogyan kell helyesen használni. Ruslan jelentése után megjelent a megértés, és Nyikolaj Szvercskov (Gonosz marslakók) jelentése után a Backend szekcióból konszolidálták. Nem hiába mentem el a konferenciára :)
A CI szegényeknek való, vagy érdemes saját CI-t írni egy webstúdióhoz?
Mikhail Radionov, a jekatyerinburgi Flag webstúdió vezetője a saját írású CI/CD-ről beszélt.
Stúdiója a „manuális CI/CD-ről” (bejelentkezés a szerverre SSH-n keresztül, git lehúzás, napi 100-szor ismétlés) Jenkins-re és egy saját írású eszközre vált, amely lehetővé teszi a kód figyelését és a Pullkins nevű kiadások végrehajtását. .
Miért nem dolgozott Jenkins? Alapértelmezés szerint nem biztosított kellő rugalmasságot, és túl nehéz volt testreszabni.
A „Flag” a Laravelben (PHP-keretrendszer) fejlődik. A CI/CD szerver fejlesztése során Mikhail és kollégái a Laravel Telescope and Envoy nevű beépített mechanizmusait használták. Az eredmény egy PHP-beli szerver (kérjük, vegye figyelembe), amely feldolgozza a bejövő webhook kéréseket, fel tudja építeni a frontendet és a háttérrendszert, telepíteni tudja különböző kiszolgálókra, és jelentést készít a Slacknek.
Ezután a kék/zöld üzembe helyezés végrehajtása és a dev-stage-prod környezetekben egységes beállítások elvégzése érdekében Dockerre váltottak. Az előnyök változatlanok maradtak, hozzáadták a környezet homogenizálásának és a zökkenőmentes telepítésnek a lehetőségeit, valamint a Dockerrel való helyes munkavégzés megtanulásának szükségességét.
Hogyan csökkentettük a szerverkiadások visszaállításainak számát 99%-kal
Az utolsó jelentés a Devops részben Viktor Eremchenkotól, a Miro.com (korábban RealTimeBoard) vezető devops mérnökétől származott.
A RealTimeBoard, a Miro csapat zászlóshajója, egy monolitikus Java alkalmazáson alapul. Összegyűjtése, tesztelése és üzembe helyezése állásidő nélkül nehéz feladat. Ebben az esetben fontos a kód ilyen verziójának telepítése, hogy ne kelljen visszaforgatni (ez egy nehéz monolit).
Egy olyan rendszer felépítése felé vezető úton, amely lehetővé teszi ezt, Miro végigment egy utat, amely magában foglalta az architektúrán, a használt eszközökön (Atlassian Bamboo, Ansible stb.), valamint a csapatok felépítésén való munkát (most már megvannak). egy elkötelezett Devops csapat + sok különálló Scrum csapat különböző profilú fejlesztőktől).
Az út nehéznek és tüskésnek bizonyult, és Victor osztozott a felgyülemlett fájdalomban és optimizmusban, ami ezzel még nem ért véget.
Nyert egy könyvet a kérdések feltevésére
Háttérszakasz
Sikerült 2 riporton részt vennem - Nikolay Sverchkovtól (Gonosz marslakók), szintén a szerver nélküliről, és Grigory Koshelevtől (Kontur cég) a telemetriáról.
Szerver nélküli egyszerű halandók számára
Ha Ruslan Sirkin arról beszélt, hogy mi az a Serverless, Nikolay egyszerű alkalmazásokat mutatott be a Serverless használatával, és beszélt azokról a részletekről, amelyek befolyásolják az AWS Lambda alkalmazások költségeit és sebességét.
Érdekes részlet: a minimálisan fizetett elem 128 Mb memória és 100 ms CPU, 0,000000208 dollárba kerül. Ráadásul havonta 1 millió ilyen kérés ingyenes.
Nikolai egyes funkciói gyakran túllépték a 100 ms-os határt (a fő alkalmazás Ruby nyelven íródott), így Go-ban való átírásuk kiváló megtakarítást eredményezett.
Vostok Hercules – tegye ismét nagyszerűvé a telemetriát!
A Backend szekció legújabb jelentése Grigory Koshelevtől (Kontur cég) a telemetriáról. A telemetria naplókat, mérőszámokat, alkalmazásnyomokat jelent.
Erre a célra a Contour a Githubon közzétett, saját írású eszközöket használ. Eszköz a jelentésből – Hercules, , telemetriai adatok továbbítására szolgál.
Vladimir Lila jelentése a Devops szekcióban a naplók tárolását és feldolgozását tárgyalta az Elasticsearch programban, de továbbra is sok ezer eszközről és alkalmazásról kell naplókat szállítani, és az olyan eszközök, mint a Vostok Hercules megoldják ezeket.
A körút sokak által ismert úton haladt - RabbitMQ-tól Apache Kafkáig, de nem minden olyan egyszerű)) Hozzá kellett adni a Zookeepert, Cassandra-t és Graphite-ot a körhöz. A jelentéssel kapcsolatos információkat nem fogom teljes körűen nyilvánosságra hozni (nem a profilomat), ha érdekel, várhatja a diákat és a videókat a konferencia honlapján.
Hogyan viszonyul más konferenciákhoz?
Nem tudom összehasonlítani a moszkvai és szentpétervári konferenciákkal, össze tudom hasonlítani más uráli eseményekkel és a szamarai 404festtel.
A DAMP 8 szekcióban zajlik, ez az uráli konferenciák rekordja. Nagyon nagy Science and Management szekciók, ez is szokatlan. A jekatyerinburgi közönség meglehetősen strukturált - a városban nagy fejlesztési osztályok vannak a Yandex, a Kontur, a Tinkoff számára, és ez rányomja bélyegét a jelentésekre.
További érdekesség, hogy sok cégnek egyszerre 3-4 előadója van a konferencián (ilyen volt Kontur, Evil Martians, Tinkoff). Sokan közülük szponzorok voltak, de a beszámolók teljesen egyenrangúak a többiekkel, ezek nem reklámriportok.
Menni vagy nem menni? Ha az Urálban vagy a közelben élsz, akkor van rá lehetőséged és érdeklődsz a témák iránt – persze, igen. Ha hosszabb utazásban gondolkodik, akkor a korábbi évek beszámolóinak, videós riportjainak témáit nézem és hozott egy döntést.
A régiókonferenciák másik előnye általában, hogy a beszámolók után könnyen lehet kommunikálni az előadóval, egyszerűen kevesebb jelentkező van ilyen kommunikációra.
Köszönet Dumpnak és Jekatyerinburgnak! )
Forrás: will.com