Kävin viime viikolla DUMP IT -konferenssissa (https://dump-ekb.ru/) Jekaterinburgissa ja haluan kertoa, mitä keskusteltiin Backend- ja Devops-osioissa ja ovatko alueelliset IT-konferenssit huomion arvoisia.
Nikolay Sverchkov Evil Martiansista palvelimettomuudesta
Mitä siellä muuten oli?
Konferenssissa oli yhteensä 8 osiota: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
Suurimmat salit muuten ovat Science and Managementissa)) Kukin ~350 hengelle. Backend ja Frontend eivät ole paljon pienempiä. Devops-huone oli pienin, mutta aktiivinen.
Kuuntelin Devops- ja Backend-osioiden raportteja ja puhuin vähän puhujien kanssa. Haluaisin puhua käsitellyistä aiheista ja käydä läpi nämä osiot konferenssissa.
SKB-Konturin, DataArtin, Evil Martiansin, Jekaterinburgin web-studion Flagin, Miron (RealTimeBoard) edustajat puhuivat Devops- ja Backend-osioissa. Aiheet kattoivat CI/CD:n, työskentelyn jonopalveluiden kanssa, kirjaamisen; Palvelimeton aiheet ja työ PostgreSQL:n kanssa Gossa käsiteltiin hyvin.
Raportteja olivat myös Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, mutta minulla ei ollut aikaa fyysisesti osallistua niihin (raporttien videotallenteita ja dioja ei ole vielä saatavilla, he lupaavat lähettää ne 2 viikon sisällä osoitteessa dump-ekb.ru).
Devops-osio
Yllättävää oli, että jakso pidettiin pienimmässä, noin 50-paikkaisessa salissa. Ihmisiä jopa seisoi käytävillä :) Kerron teille raporteista, jotka onnistuin kuuntelemaan.
Petabutin painava elastinen
Osio alkoi Vladimir Lilin (SKB-Kontur) raportilla Elasticsearchista Konturissa. Niissä on melko suuri ja ladattu Elastic (~800 TB dataa, ~1.3 petabyyttiä redundanssi huomioiden). Elasticsearch kaikille Kontur-palveluille on yksittäinen, koostuu 2 klusterista (7 ja 9 palvelimesta) ja on niin tärkeä, että Konturilla on erityinen Elasticsearch-insinööri (itse asiassa Vladimir itse).
Vladimir jakoi myös ajatuksensa Elasticsearchin eduista ja sen tuomista ongelmista.
etuja:
- Kaikki lokit ovat yhdessä paikassa, helppo pääsy niihin
- Tukkien säilytys vuoden ajan ja niiden helppo analysointi
- Suuri nopeus puun kanssa työskentelyssä
- Upea datan visualisointi pakkauksesta
ongelmat:
- viestivälittäjä on pakollinen (Konturille sen roolia esittää Kafka)
- Elasticsearch Curatorin kanssa työskentelyn ominaisuudet (sajoittain luotu korkea kuormitus tavallisista tehtävistä Curatorissa)
- ei sisäänrakennettua valtuutusta (vain erillisillä, melko suurilla rahoilla tai avoimen lähdekoodin laajennuksina, joiden tuotantovalmius vaihtelee)
Open Distro for Elasticsearchista oli vain positiivisia arvosteluja :) Sama valtuutusongelma on ratkaistu siellä.
Mistä petatavu tulee?Niiden solmut koostuvat palvelimista, joissa on 12*8 Tb SATA + 2*2 Tb SSD. Kylmäsäilytys SATA:lla, SSD vain kuumalle välimuistille (kuuma tallennus).
7+9 palvelinta, (7 + 9) * 12 * 8 = 1536 Tb.
Osa tilasta on varattu, varattu irtisanomiseen jne.
Elasticsearchille lähetetään lokit noin 90 hakemuksesta, mukaan lukien kaikki Konturin, Elban jne. raportointipalvelut.
Serverless-kehityksen ominaisuudet
Seuraavana on Ruslan Serkinin raportti DataArtista Serverlessistä.
Ruslan puhui siitä, mitä Serverless-lähestymistavan kehittäminen yleensä on ja mitkä ovat sen ominaisuudet.
Serverless on lähestymistapa kehitykseen, jossa kehittäjät eivät kosketa infrastruktuuria millään tavalla. Esimerkki - AWS Lambda Serverless, Kubeless.io (palvelinton Kubernetesin sisällä), Google Cloud Functions.
Ihanteellinen palvelinton sovellus on yksinkertaisesti toiminto, joka lähettää pyynnön palvelimettomalle palveluntarjoajalle erityisen API-yhdyskäytävän kautta. Ihanteellinen mikropalvelu, kun taas AWS Lambda tukee myös monia moderneja ohjelmointikieliä. Infrastruktuurin ylläpito- ja käyttöönottokustannukset ovat nolla pilvipalveluntarjoajien tapauksessa, ja pienten sovellusten tukeminen on myös erittäin halpaa (AWS Lambda - 0.2 dollaria / 1 miljoonaa yksinkertaista pyyntöä).
Tällaisen järjestelmän skaalautuvuus on lähes ihanteellinen - pilvipalveluntarjoaja huolehtii tästä itse, Kubeless skaalautuu automaattisesti Kubernetes-klusterin sisällä.
Haittoja on:
- suurten sovellusten kehittäminen on yhä vaikeampaa
- sovellusten profiloinnissa on vaikeuksia (vain lokit ovat käytettävissäsi, mutta ei profilointia tavallisessa merkityksessä)
- ei versiointia
Ollakseni rehellinen, kuulin Serverlessistä muutama vuosi sitten, mutta kaikkien näiden vuosien aikana minulle ei ollut selvää, kuinka sitä käytetään oikein. Ruslanin raportin jälkeen ymmärrys ilmestyi, ja Nikolai Sverchkovin (Pahat marsilaiset) raportin jälkeen taustaosasta se konsolidoitiin. Ei turhaan mennyt konferenssiin :)
CI on köyhille, vai kannattaako kirjoittaa oma CI web-studioon?
Mikhail Radionov, Flag-verkkostudion johtaja Jekaterinburgista, puhui itse kirjoitetusta CI/CD:stä.
Hänen studionsa on siirtynyt "manuaalisesta CI/CD:stä" (kirjaudu palvelimelle SSH:n kautta, tee git pull, toista 100 kertaa päivässä) Jenkinsiin ja itsekirjoitettuun työkaluun, jonka avulla voit seurata koodia ja suorittaa Pullkins-nimiä julkaisuja. .
Miksi Jenkins ei toiminut? Se ei tarjonnut tarpeeksi joustavuutta oletuksena, ja sitä oli liian vaikea muokata.
"Flag" kehittyy Laravelissa (PHP-kehys). Kehittäessään CI/CD-palvelinta Mikhail ja hänen kollegansa käyttivät Laravelin sisäänrakennettuja mekanismeja nimeltä Telescope and Envoy. Tuloksena on PHP-palvelin (huomaa), joka käsittelee saapuvat webhook-pyynnöt, voi rakentaa käyttöliittymän ja taustajärjestelmän, ottaa käyttöön eri palvelimia ja raportoida Slackiin.
Sitten he siirtyivät Dockeriin, jotta he voisivat suorittaa sinisen/vihreän käyttöönoton ja saada yhtenäiset asetukset dev-stage-prod-ympäristöissä. Edut säilyivät ennallaan, lisättiin mahdollisuudet ympäristön homogenisointiin ja saumattomaan käyttöönottoon sekä tarve oppia Docker työskentelemään sen kanssa oikein.
Kuinka vähennimme palvelinjulkaisujen palautusten määrää 99 %
Viimeisin Devops-osion raportti oli Viktor Eremchenkolta, Miro.comin (entinen RealTimeBoard) johtava devops-insinööri.
RealTimeBoard, Miro-tiimin lippulaivatuote, perustuu monoliittiseen Java-sovellukseen. Sen kerääminen, testaus ja käyttöönotto ilman seisokkeja on vaikea tehtävä. Tässä tapauksessa on tärkeää ottaa käyttöön tällainen koodiversio, jotta sitä ei tarvitse rullata takaisin (se on raskas monoliitti).
Matkalla rakentaakseen järjestelmää, jonka avulla voit tehdä tämän, Miro kävi läpi polun, joka sisälsi työskentelyn arkkitehtuurin, käytettyjen työkalujen (Atlassian Bamboo, Ansible jne.) parissa ja työskentelyn tiimien rakenteen parissa (niillä on nyt omistautunut Devops-tiimi + useita erillisiä Scrum-tiimiä eri profiilien kehittäjiltä).
Polku osoittautui vaikeaksi ja hankalaksi, ja Victor jakoi kertyneen tuskan ja optimismin, joka ei päättynyt siihen.
Voitti kirjan kysymysten esittämisestä
Taustaosa
Onnistuin osallistumaan kahteen raporttiin - Nikolay Sverchkovilta (Pahat marsilaiset), myös palvelimettomuudesta ja Grigory Koshelevilta (Kontur-yhtiö) telemetriasta.
Palvelimeton kuolevaisille
Jos Ruslan Sirkin puhui siitä, mitä Serverless on, Nikolay esitteli yksinkertaisia Serverless-sovelluksia ja puhui yksityiskohdista, jotka vaikuttavat AWS Lambdan sovellusten kustannuksiin ja nopeuteen.
Mielenkiintoinen yksityiskohta: pienin maksettu elementti on 128 Mt muistia ja 100 ms CPU, se maksaa 0,000000208 dollaria. Lisäksi miljoona tällaista pyyntöä kuukaudessa on ilmaisia.
Jotkut Nikolain toiminnot ylittivät usein 100 ms:n rajan (pääsovellus oli kirjoitettu Rubylla), joten niiden uudelleenkirjoittaminen Go:lla tuotti erinomaisia säästöjä.
Vostok Hercules – tee telemetriasta jälleen mahtavaa!
Viimeisin Backend-osion raportti Grigory Koshelevilta (Kontur-yhtiö) telemetriasta. Telemetria tarkoittaa lokeja, mittareita, sovellusjälkiä.
Tätä tarkoitusta varten Contour käyttää itse kirjoitettuja työkaluja, jotka on julkaistu Githubissa. Työkalu raportista - Hercules, , käytetään telemetriatietojen toimittamiseen.
Vladimir Lilan raportissa Devops-osiossa käsiteltiin lokien tallentamista ja käsittelyä Elasticsearchissa, mutta tehtävänä on edelleen toimittaa lokit useista tuhansista laitteista ja sovelluksista, ja Vostok Herculesin kaltaiset työkalut ratkaisevat ne.
Rata seurasi monien tuntemaa polkua - RabbitMQ:sta Apache Kafkaan, mutta kaikki ei ole niin yksinkertaista)) Heidän piti lisätä Zookeeper, Cassandra ja Graphite piiriin. En paljasta tämän raportin tietoja kokonaisuudessaan (ei profiiliani), jos olet kiinnostunut, voit odottaa dioja ja videoita konferenssin verkkosivuilla.
Miten se on verrattuna muihin konferensseihin?
En voi verrata sitä Moskovan ja Pietarin konferensseihin, voin verrata sitä muihin Uralin tapahtumiin ja Samaran 404festiin.
DAMP järjestetään 8 jaksossa, tämä on Ural-konferenssien ennätys. Erittäin suuret tiede- ja hallintoosastot, tämä on myös epätavallista. Jekaterinburgin yleisö on melko jäsentynyt - kaupungissa on suuret kehitysosastot Yandexille, Konturille, Tinkoffille, ja tämä jättää jälkensä raportteihin.
Toinen mielenkiintoinen seikka on, että monilla yrityksillä on konferenssissa 3-4 puhujaa kerralla (tämä oli Kontur, Evil Martians, Tinkoff). Monet heistä olivat sponsoreita, mutta raportit ovat melko samanlaisia kuin muut, nämä eivät ole mainosraportteja.
Mennäänkö vai eikö mennä? Jos asut Uralilla tai sen lähistöllä, sinulla on mahdollisuus ja olet kiinnostunut aiheista - kyllä, tietysti. Jos ajattelet pitkää matkaa, katsoisin aikaisempien vuosien raporttien ja videoraporttien aiheita ja teki päätöksen.
Toinen alueiden konferenssien etu on pääsääntöisesti se, että puhujan kanssa on helppo kommunikoida raporttien jälkeen, hakijoita on yksinkertaisesti vähemmän.
Kiitos Dumpille ja Jekaterinburgille! )
Lähde: will.com