W zeszłym tygodniu pojechałem na konferencję DUMP IT (https://dump-ekb.ru/) w Jekaterynburgu i chcę opowiedzieć o tym, co było omawiane w sekcjach Backend i Devops oraz czy regionalne konferencje IT są warte uwagi.
Nikolay Sverchkov z Evil Marsians o Serverless
Co tam w ogóle było?
Łącznie konferencja składała się z 8 sekcji: Backend, Frontend, Mobile, Testowanie i QA, Devops, Design, Science i Management.
Nawiasem mówiąc, największe sale są w Science and Management)) Dla ~350 osób każda. Backend i Frontend nie są dużo mniejsze. Pokój Devopsa był najmniejszy, ale aktywny.
Wysłuchałem raportów w sekcjach Devops i Backend oraz trochę porozmawiałem z prelegentami. Chciałbym poruszyć poruszane tematy i przejrzeć te sekcje na konferencji.
W sekcjach Devops i Backend wypowiadali się przedstawiciele SKB-Kontur, DataArt, Evil Martians, jekaterynburskiego studia internetowego Flag, Miro (RealTimeBoard). Tematy dotyczyły CI/CD, pracy z usługami kolejek, rejestrowania; tematy bezserwerowe i praca z PostgreSQL w Go zostały dobrze omówione.
Były też raporty Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ale nie miałem czasu, aby fizycznie w nich uczestniczyć (nagrania wideo i slajdy z raportów nie są jeszcze dostępne, obiecują je opublikować w ciągu 2 tygodni na dump-ekb.ru).
Sekcja Devopsa
Zaskoczeniem było to, że sekcja odbywała się w najmniejszej sali, mieszczącej około 50 miejsc. Ludzie stali nawet w przejściach :) Opowiem Wam o relacjach, które udało mi się wysłuchać.
Elastyczny ważący petabajt
Sekcja rozpoczęła się od raportu Vladimira Lila (SKB-Kontur) na temat Elasticsearch w Kontur. Mają dość duży i obciążony Elastic (~800 TB danych, ~1.3 petabajtów, biorąc pod uwagę redundancję). Elasticsearch dla wszystkich usług Kontur jest pojedynczy, składa się z 2 klastrów (po 7 i 9 serwerów) i jest na tyle ważny, że Kontur ma specjalnego inżyniera Elasticsearch (w rzeczywistości samego Vladimira).
Vladimir podzielił się także swoimi przemyśleniami na temat korzyści płynących z Elasticsearch i problemów, jakie ze sobą niesie.
Korzyści:
- Wszystkie logi znajdują się w jednym miejscu, łatwy do nich dostęp
- Przechowywanie logów przez rok i łatwa ich analiza
- Wysoka prędkość pracy z kłodami
- Fajna wizualizacja danych od razu po wyjęciu z pudełka
Problemy:
- broker komunikatów to must have (dla Kontura jego rolę pełni Kafka)
- cechy pracy z Elasticsearch Curator (okresowo tworzone duże obciążenie z regularnych zadań w Curatorze)
- brak wbudowanej autoryzacji (tylko za osobne, dość duże pieniądze, lub jako wtyczki open source o różnym stopniu gotowości do produkcji)
O Open Distro for Elasticsearch pojawiły się same pozytywne recenzje :) Rozwiązano tam ten sam problem autoryzacji.
Skąd pochodzi petabajt?Ich węzły składają się z serwerów z 12*8 Tb SATA + 2*2 Tb SSD. Zimna pamięć na SATA, dysk SSD tylko dla gorącej pamięci podręcznej (gorąca pamięć masowa).
7+9 serwerów, (7 + 9) * 12 * 8 = 1536 Tb.
Część powierzchni jest rezerwowa, przeznaczona na potrzeby redundancji itp.
Do Elasticsearch wysyłane są logi z około 90 aplikacji, w tym ze wszystkich usług raportowania Kontur, Elba itp.
Funkcje programowania na Serverless
Następny jest raport Ruslana Serkina z DataArt na temat Serverless.
Ruslan opowiedział ogólnie o rozwoju podejścia Serverless i jego funkcjach.
Serverless to podejście do rozwoju, w którym programiści nie dotykają w żaden sposób infrastruktury. Przykład - AWS Lambda Serverless, Kubeless.io (Serverless wewnątrz Kubernetes), Google Cloud Functions.
Idealna aplikacja Serverless to po prostu funkcja, która wysyła żądanie do dostawcy Serverless za pośrednictwem specjalnej bramy API. Idealna mikrousługa, podczas gdy AWS Lambda obsługuje również dużą liczbę nowoczesnych języków programowania. Koszt utrzymania i wdrożenia infrastruktury staje się zerowy w przypadku dostawców usług chmurowych, obsługa małych aplikacji również będzie bardzo tania (AWS Lambda – 0.2 USD / 1 milion prostych żądań).
Skalowalność takiego systemu jest wręcz idealna – dostawca chmury zajmuje się tym sam, Kubeless skaluje się automatycznie w ramach klastra Kubernetes.
Istnieją wady:
- tworzenie dużych aplikacji staje się coraz trudniejsze
- występują trudności z profilowaniem aplikacji (dostępne są tylko logi, ale nie profilowanie w zwykłym znaczeniu)
- brak wersjonowania
Szczerze mówiąc, słyszałem o Serverless kilka lat temu, ale przez te wszystkie lata nie było dla mnie jasne, jak poprawnie go używać. Po raporcie Rusłana pojawiło się zrozumienie, a po raporcie Nikołaja Swierczkowa (Zli Marsjanie) z sekcji Backend – ugruntowane. Nie na próżno pojechałem na konferencję :)
CI jest dla biednych, czy warto napisać własny CI dla studia internetowego?
Michaił Radionow, szef studia internetowego Flag z Jekaterynburga, mówił o samodzielnie napisanym CI/CD.
Jego studio przeszło od „ręcznego CI/CD” (logowanie się do serwera przez SSH, wykonanie polecenia git pull, powtarzane 100 razy dziennie) do Jenkinsa i do samodzielnie napisanego narzędzia, które pozwala kontrolować kod i wykonywać wydania o nazwie Pullkins.
Dlaczego Jenkins nie zadziałał? Domyślnie nie zapewniał wystarczającej elastyczności i był zbyt trudny do dostosowania.
„Flag” rozwija się w Laravel (framework PHP). Tworząc serwer CI/CD, Michaił i jego współpracownicy wykorzystali wbudowane mechanizmy Laravela zwane Telescope i Envoy. Rezultatem jest serwer w PHP (pamiętaj), który przetwarza przychodzące żądania webhooka, może budować frontend i backend, wdrażać na różnych serwerach i raportować do Slacka.
Następnie, aby móc przeprowadzić wdrożenie w kolorze niebieskim/zielonym i mieć jednolite ustawienia w środowiskach deweloperskich i produkcyjnych, przeszli na Docker. Zalety pozostały te same, dodano możliwości ujednolicenia środowiska i bezproblemowego wdrożenia oraz dodano konieczność nauczenia się Dockera, aby poprawnie z nim pracować.
Jak zmniejszyliśmy liczbę wycofywania wersji serwerów o 99%
Ostatni raport w sekcji Devops pochodzi od Viktora Eremczenki, głównego inżyniera Devops w Miro.com (dawniej RealTimeBoard).
Flagowy produkt zespołu Miro, RealTimeBoard, oparty jest na monolitycznej aplikacji Java. Gromadzenie, testowanie i wdrażanie ich bez przestojów jest trudnym zadaniem. W tym przypadku ważne jest wdrożenie takiej wersji kodu, aby nie trzeba było go cofać (to ciężki monolit).
W drodze do zbudowania systemu, który na to pozwala, Miro przeszedł ścieżkę obejmującą pracę nad architekturą, używanymi narzędziami (Atlassian Bamboo, Ansible itp.) oraz pracę nad strukturą zespołów (teraz mają dedykowany zespół Devops + wiele odrębnych zespołów Scrumowych od programistów o różnych profilach).
Ścieżka okazała się trudna i ciernista, a Victor podzielił skumulowany ból i optymizm, który na tym się nie skończył.
Wygraj książkę do zadawania pytań
Sekcja backendu
Udało mi się obejrzeć 2 raporty - od Nikolaya Sverchkova (Evil Marsians), także o Serverless i od Grigorija Kosheleva (firma Kontur) o telemetrii.
Bezserwerowy dla zwykłych śmiertelników
Jeśli Ruslan Sirkin mówił o tym, czym jest Serverless, Nikolay pokazał proste aplikacje wykorzystujące Serverless i opowiedział o szczegółach, które wpływają na koszt i szybkość aplikacji w AWS Lambda.
Ciekawostka: minimalnie płatny element to 128 Mb pamięci i 100 ms procesora, kosztuje 0,000000208 dolarów. Co więcej, 1 milion takich żądań miesięcznie jest bezpłatnych.
Niektóre funkcje Mikołaja często przekraczały limit 100 ms (główna aplikacja została napisana w Ruby), więc przepisanie ich w Go zapewniło znakomite oszczędności.
Vostok Hercules — spraw, by telemetria znów była świetna!
Najnowszy raport sekcji Backend od Grigorija Kosheleva (firma Kontur) na temat telemetrii. Telemetria oznacza logi, metryki, ślady aplikacji.
W tym celu Contour korzysta z samodzielnie napisanych narzędzi zamieszczonych na Githubie. Narzędzie z raportu - Herkules, , służy do dostarczania danych telemetrycznych.
Raport Vladimira Lili w sekcji Devops omawiał przechowywanie i przetwarzanie logów w Elasticsearch, ale nadal istnieje zadanie dostarczania logów z wielu tysięcy urządzeń i aplikacji, a narzędzia takie jak Vostok Hercules je rozwiązują.
Obwód podążał ścieżką znaną wielu - od RabbitMQ do Apache Kafka, ale nie wszystko jest takie proste)) Musieli dodać do obwodu Zookeepera, Cassandrę i Graphite. Nie będę w pełni ujawniał informacji na temat tego raportu (nie mojego profilu), jeśli jesteście zainteresowani, możecie poczekać na slajdy i filmy na stronie konferencji.
Jak wypada na tle innych konferencji?
Nie mogę tego porównać z konferencjami w Moskwie i Petersburgu, mogę to porównać z innymi wydarzeniami na Uralu i z 404fest w Samarze.
DAMP odbywa się w 8 sekcjach, co jest rekordem wśród konferencji Uralu. Bardzo duże sekcje Nauki i Zarządzania, to też jest niezwykłe. Publiczność w Jekaterynburgu jest dość zorganizowana - miasto ma duże działy rozwoju dla Yandex, Kontur, Tinkoff, co pozostawia ślad w raportach.
Kolejną ciekawostką jest to, że wiele firm ma na konferencji 3-4 prelegentów jednocześnie (tak było w przypadku Kontur, Evil Martians, Tinkoff). Wielu z nich było sponsorami, ale raporty są na równi z innymi, nie są to raporty reklamowe.
Iść czy nie iść? Jeśli mieszkasz na Uralu lub w pobliżu, masz taką możliwość i interesują Cię tematy - oczywiście, że tak. Jeśli myślisz o dłuższym wyjeździe, to zerknęłabym na tematy reportaży i relacji wideo z poprzednich lat i podjąłem decyzję.
Kolejną zaletą konferencji w regionach jest z reguły to, że po sprawozdaniach łatwo jest porozumieć się z prelegentem, chętnych na taką komunikację jest po prostu mniej.
Dzięki Dumpowi i Jekaterynburgowi! )
Źródło: www.habr.com