W zeszłym tygodniu byłem na konferencji IT DUMP (https://dump-ekb.ru/) w Jekaterynburgu i chciałbym opowiedzieć, o czym mówiono na sekcjach Backend i Devops, oraz czy regionalne konferencje IT są warte uwagi.
Nikołaj Swierczkow z Evil Martians o Serverless
Co tam w ogóle się działo?
Na konferencji odbyło się 8 sekcji: Backend, Frontend, Mobile, Testowanie i QA, Devops, Design, Science i Management.
Największe sale miały sekcje Science i Management, każda na ~350 osób. Backend i Frontend były nieco mniejsze. Sala Devops była najmniejsza, ale bardzo aktywna.
Słuchałem prezentacji w sekcjach Devops i Backend oraz trochę porozmawiałem z prelegentami. Chciałbym opowiedzieć o poruszanych tematach i zrobić przegląd tych sekcji na konferencji.
W sekcjach Devops i Backend wystąpili przedstawiciele SKB-Kontur, DataArt, Evil Martians, ekaterynburskiej agencji webowej Flag, Miro (RealTimeBoard). Tematy dotyczyły CI/CD, pracy z serwisami kolejkowymi, logowania, tematy Serverless oraz pracy z PostgreSQL w Go były dobrze omówione.
Były też prezentacje z Avito, Tinkoff, Yandex, Jetstyle, Megafon, banku Ak Bars, ale nie zdążyłem ich osobiście odwiedzić (nagrania wideo i slajdy prezentacji nie są jeszcze dostępne, obiecują udostępnić je w ciągu 2 tygodni na dump-ekb.ru).
Sekcja Devops
Co zaskakuje — sekcja odbywała się w najmniejszej sali, na około 50 miejsc. Ludzie stali nawet w przejściach 🙂 Opowiem o prezentacjach, które udało mi się wysłuchać.
Elastyczny z 1 petabajta
Sekcję rozpoczął wykład Władimira Lila (SKB-Kontur) na temat Elasticsearch w Konturze. Mają dość dużego i obciążonego Elastyka (~800 TB danych, ~1.3 petabajta z uwzględnieniem nadmiarowości). Elasticsearch dla wszystkich serwisów Kontura jest jeden, składa się z 2 klastrów (z 7 i 9 serwerów) i jest na tyle istotny, że w Konturze jest specjalny inżynier Elasticsearch (właśnie Władimir).
Władimir podzielił się również myślami o korzyściach z korzystania z Elasticsearch oraz problemami, które z tego wynikają.
Korzyści:
- Wszystkie logi w jednym miejscu, łatwy dostęp do nich
- Przechowywanie logów przez rok i ich łatwa analiza
- Wysoka prędkość pracy z logami
- Świetna wizualizacja danych “prosto z pudełka”
Problemy:
- broker wiadomości — must have (w Konturze tę rolę odgrywa Kafka)
- cechy pracy z Elasticsearch Curator (okresowo tworzona wysoka carga z regulaminowych zadań w Curatorze)
- brak wbudowanej autoryzacji (tylko za dodatkowe, dość duże pieniądze, albo jako wtyczki open source różnego stopnia gotowości do produkcji)
Opinie o Open Distro for Elasticsearch były tylko pozytywne 🙂 To samo pytanie dotyczące autoryzacji zostało rozwiązane.
Skąd petabajty?Ich węzły składają się z serwerów z 12*8 Tb SATA + 2*2 Tb SSD. Cold storage na SATA, SSD tylko pod gorący cache (hot storage).
7+9 serwerów, (7 + 9) * 12 * 8 = 1536 Tb.
Część miejsca jest w rezerwie, zaplanowane na nadmiarowość itd.
W Elasticsearch przesyłane są logi z około 90 aplikacji, w tym wszystkie usługi raportowe Kontura, Elba itd.
Cechy rozwoju na Serverless
Dalej referat Rusłana Serkina z DataArt na temat Serverless.
Rusłan opowiedział, co w ogóle oznacza rozwój z podejściem Serverless i jakie są jego cechy.
Serverless to podejście do rozwoju, w którym programiści w żaden sposób nie zajmują się infrastrukturą. Przykład — AWS Lambda Serverless, Kubeless.io (Serverless w Kubernetes), Google Cloud Functions.
Idealna aplikacja Serverless to po prostu funkcja wysyłająca zapytanie do dostawcy Serverless przez specjalny API Gateway. Idealny mikroserwis; w tym samym AWS Lambda obsługiwanych jest wiele nowoczesnych języków programowania. Koszt utrzymania i wdrożenia infrastruktury staje się zerowy w przypadku dostawców chmurowych, a wsparcie małych aplikacji również będzie bardzo tanie (AWS Lambda — 0,2$ / 1 milion prostych zapytań).
Skalowalność takiego systemu jest praktycznie idealna — dostawca chmurowy zajmuje się tym sam, Kubeless automatycznie skaluje się wewnątrz klastra Kubernetes.
Są pewne wady:
- Rozwój dużych aplikacji staje się trudniejszy
- Jest problem z profilowaniem aplikacji (dostępne są tylko logi, ale nie profilowanie w tradycyjnym rozumieniu)
- Brak wersjonowania
Powiem szczerze, o Serverless usłyszałem jeszcze kilka lat temu, ale przez te lata nie wiedziałem, jak poprawnie go zastosować. Po referacie Rusłana zrozumienie się pojawiło, a po referacie Nikolaja Swerczkowa (Evil Martians) z sekcji Backend się ustabilizowało. Już nie żałuję, że poszedłem na konferencję 🙂
CI dla ubogich, czyli czy warto pisać własny CI dla studia internetowego
Michaił Radionow, kierownik studia internetowego Flag z Jekaterynburga, opowiedział o własnoręcznie stworzonym CI/CD.
Jego studio przeszło drogę od "ręcznego CI/CD" (zalogowanie się na serwer przez SSH, wykonanie git pull, powtórzenie 100 razy dziennie) do Jenkins i do własnego narzędzia, które pozwala kontrolować kod i realizować wydania o nazwie Pullkins.
Dlaczego Jenkins nie spełnił oczekiwań? Nie zapewniał wystarczającej elastyczności domyślnie i był zbyt skomplikowany w dostosowywaniu.
„Flag” rozwija na Laravel (framework PHP). Podczas tworzenia serwera CI/CD Michał z kolegami skorzystali z wbudowanych mechanizmów Laravel o nazwach Telescope i Envoy. W efekcie powstał serwer PHP (zauważcie), który obsługuje przychodzące zapytania webhook, potrafi wykonywać kompilację frontendu, backendu, wdrażać na różne serwery i raportować w Slacku.
Następnie, aby umożliwić blue/green deploy i mieć jednolite ustawienia w środowiskach dev-stage-prod, przeszli na Docker. Plusy pozostały te same, dodano możliwości homogenizacji środowiska i płynnego wdrażania, a także konieczność nauki Dockera, aby poprawnie z nim pracować.
Jak zmniejszyliśmy liczbę rollbacków serwerowych wydań o 99%
Ostatnie wystąpienie w sekcji DevOps miało miejsce w wykonaniu Wiktora Jeremczenki, głównego inżyniera DevOps w Miro.com (dawniej RealTimeBoard).
Monolityczna aplikacja oparta na Java jest podstawą RealTimeBoard, głównego produktu zespołu Miro. Zbudowanie, przetestowanie i wdrożenie go bez przestojów to trudne zadanie. Ważne jest, aby wdrożenie danej wersji kodu było wykonane w taki sposób, aby nie trzeba było go cofać (to przecież ciężki monolit).
Na drodze do zbudowania systemu, który to umożliwia, Miro przeszło ścieżkę obejmującą pracę nad architekturą, używanymi narzędziami (Atlassian Bamboo, Ansible itd.) oraz budowaniem zespołów (teraz mają dedykowany zespół DevOps oraz wiele oddzielnych zespołów Scrum z programistami różnych profili).
Droga okazała się trudna i pełna cierni, a Wiktor podzielił się nagromadzonym bólem i niezakończonym przy tym optymizmem.
Wygrał książkę za pytania
Sekcja backendowa
Udało mi się dotrzeć na 2 wystąpienia — od Nikolaja Swierczkowa (Evil Martians), również o Serverless, oraz od Grigorija Koszelewa (firma Kontur) o telemetrii.
Serverless dla zwykłych ludzi
Jeśli Rusłan Sirkyn mówił o tym, czym jest Serverless, Nikolaj pokazał proste aplikacje przy użyciu Serverless oraz opowiedział o szczegółach, które wpływają na koszty i szybkość działania aplikacji w AWS Lambda.
Interesujący szczegół: minimalny opłacany element to 128 Mb pamięci i 100 ms CPU, kosztuje 0,000000208$. Przy tym 1 milion takich zapytań miesięcznie jest darmowy.
Niektóre funkcje u Mikołaja często przekraczały limit 100 ms (główna aplikacja była napisana w Ruby), więc przepisanie ich w Go przyniosło znaczne oszczędności.
Vostok Hercules — przywróć telemetrię w wielkim stylu!
Ostatni referat sekcji Backend autorstwa Grigorija Koszelewa (firma Kontur) na temat telemetrii. Telemetria to logi, metryki, śledzenie aplikacji.
Kontur korzysta z ręcznie napisanych narzędzi, które są dostępne na Githubie. Narzędzie z referatu — Hercules, , jest używane do dostarczania danych telemetrii.
W referacie Władimira Lili w sekcji Devops omawiano przechowywanie i obróbkę logów w Elasticsearch, ale jest jeszcze zadanie dostarczenia logów z tysięcy urządzeń i aplikacji, które rozwiązują narzędzia typu Vostok Hercules.
Kontur przeszedł znaną dla wielu drogę — od RabbitMQ do Apache Kafka, ale nie wszystko jest takie proste ) Musieli dodać do schematu Zookeeper, Cassandrę i Graphite. Informacji na temat tego referatu nie ujawnię w pełni (to nie mój profil), jeśli jesteś zainteresowany — możesz poczekać na slajdy i wideo na stronie konferencji.
Jak wypada w porównaniu do innych konferencji?
Nie mogę porównać z konferencjami w Moskwie i Sankt Petersburgu, mogę porównać z innymi wydarzeniami w Uralu i z 404fest w Samarze.
DUMP odbywa się w 8 sekcjach, to rekord dla uralskich konferencji. Bardzo duże sekcje nauki i zarządzania, co również jest nietypowe. Publiczność w Jekaterynburgu jest dość zróżnicowana — w mieście są duże działy rozwoju Yandex, Kontur, Tinkoff, co wpływa także na referaty.
Jeszcze jeden interesujący aspekt — wiele firm ma od razu 3–4 prelegentów na konferencji (tak było w przypadku Konturu, Evil Martians, Tinkoff). Wielu z nich było sponsorami, ale referaty były na poziomie z innymi, to nie były referaty reklamowe.
Iść czy nie iść? Jeśli mieszkasz na Uralu lub w pobliżu, masz możliwość i interesujące tematy — tak, oczywiście. Jeśli myślisz o dalszej podróży — to spojrzałbym na tematy referatów i wideo referatów z lat ubiegłych. i podejmowałbym decyzję.
Jeszcze jednym plusem konferencji w regionach jest to, że zazwyczaj łatwo porozmawiać z prelegentem po referatach, po prostu pretendentów do takiej rozmowy jest mniej.
Dziękuję DUMP i Jekaterynburgowi! )
Źródło: habr.com
