Noong nakaraang linggo nagpunta ako sa DUMP IT conference (https://dump-ekb.ru/) sa Yekaterinburg at gusto kong sabihin sa iyo kung ano ang tinalakay sa mga seksyon ng Backend at Devops, at kung ang mga regional IT conference ay nagkakahalaga ng pansin.
Nikolay Sverchkov mula sa Evil Martians tungkol sa Serverless
Ano ang mayroon pa rin?
Sa kabuuan, ang kumperensya ay may 8 seksyon: Backend, Frontend, Mobile, Pagsubok at QA, Devops, Disenyo, Agham at Pamamahala.
Ang pinakamalaking bulwagan, sa pamamagitan ng paraan, ay nasa Science and Management)) Para sa ~350 katao bawat isa. Ang Backend at Frontend ay hindi gaanong mas maliit. Ang silid ng Devops ay ang pinakamaliit, ngunit aktibo.
Nakinig ako sa mga ulat sa mga seksyon ng Devops at Backend at nakipag-usap ng kaunti sa mga speaker. Gusto kong pag-usapan ang mga paksang sakop at suriin ang mga seksyong ito sa kumperensya.
Ang mga kinatawan ng SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) ay nagsalita sa mga seksyon ng Devops at Backend. Saklaw ng mga paksa ang CI/CD, pagtatrabaho sa mga serbisyo ng queue, pag-log; Ang mga paksang walang server at pagtatrabaho sa PostgreSQL sa Go ay mahusay na sakop.
Mayroon ding mga ulat ng Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, ngunit wala akong oras upang pisikal na dumalo sa kanila (hindi pa magagamit ang mga pag-record ng video at mga slide ng mga ulat, nangangako silang mai-post ang mga ito sa loob ng 2 linggo sa dump-ekb.ru).
seksyon ng Devops
Ang nakakagulat ay ang seksyon ay ginanap sa pinakamaliit na bulwagan, mga 50 upuan. Nakatayo pa nga ang mga tao sa mga aisles :) Sasabihin ko sa iyo ang tungkol sa mga ulat na nagawa kong pakinggan.
Nababanat na tumitimbang ng isang petabyte
Nagsimula ang seksyon sa isang ulat ni Vladimir Lil (SKB-Kontur) tungkol sa Elasticsearch sa Kontur. Mayroon silang medyo malaki at load na Elastic (~800 TB ng data, ~1.3 petabytes na isinasaalang-alang ang redundancy). Ang Elasticsearch para sa lahat ng serbisyo ng Kontur ay iisa, binubuo ng 2 kumpol (ng 7 at 9 na server), at napakahalaga na ang Kontur ay may espesyal na Elasticsearch engineer (sa katunayan, si Vladimir mismo).
Ibinahagi din ni Vladimir ang kanyang mga saloobin sa mga benepisyo ng Elasticsearch at ang mga problemang dulot nito.
Makinabang:
- Ang lahat ng mga log ay nasa isang lugar, madaling ma-access ang mga ito
- Pag-iimbak ng mga log sa loob ng isang taon at madaling pag-aralan ang mga ito
- Mataas na bilis ng pagtatrabaho sa mga log
- Mahusay na visualization ng data sa labas ng kahon
Mga problema:
- Ang broker ng mensahe ay dapat magkaroon (para kay Kontur ang papel nito ay ginampanan ni Kafka)
- mga tampok ng pagtatrabaho sa Elasticsearch Curator (pana-panahong nilikha ang mataas na pagkarga mula sa mga regular na gawain sa Curator)
- walang built-in na awtorisasyon (para lamang sa hiwalay, medyo malaking pera, o bilang open source na mga plugin na may iba't ibang antas ng kahandaan para sa produksyon)
Mayroon lamang mga positibong review tungkol sa Open Distro para sa Elasticsearch :) Ang parehong isyu ng awtorisasyon ay nalutas doon.
Saan nagmula ang petabyte?Ang kanilang mga node ay binubuo ng mga server na may 12*8 Tb SATA + 2*2 Tb SSD. Cold storage sa SATA, SSD para lang sa hot cache (hot storage).
7+9 server, (7 + 9) * 12 * 8 = 1536 Tb.
Ang bahagi ng espasyo ay nakalaan, nakalaan para sa redundancy, atbp.
Ang mga log mula sa humigit-kumulang 90 na aplikasyon ay ipinapadala sa Elasticsearch, kasama ang lahat ng serbisyo sa pag-uulat ng Kontur, Elba, atbp.
Mga tampok ng pag-unlad sa Serverless
Susunod ay isang ulat ni Ruslan Serkin mula sa DataArt tungkol sa Serverless.
Napag-usapan ni Ruslan kung ano ang pag-unlad gamit ang Serverless na diskarte sa pangkalahatan, at kung ano ang mga tampok nito.
Ang Serverless ay isang diskarte sa pag-unlad kung saan hindi ginagalaw ng mga developer ang imprastraktura sa anumang paraan. Halimbawa - AWS Lambda Serverless, Kubeless.io (Serverless sa loob ng Kubernetes), Google Cloud Functions.
Ang perpektong Serverless na application ay simpleng function na nagpapadala ng kahilingan sa isang Serverless provider sa pamamagitan ng isang espesyal na API Gateway. Isang perpektong microservice, habang sinusuportahan din ng AWS Lambda ang isang malaking bilang ng mga modernong programming language. Ang halaga ng pagpapanatili at pag-deploy ng imprastraktura ay nagiging zero sa kaso ng mga cloud provider, ang pagsuporta sa maliliit na application ay magiging napakamura din (AWS Lambda - $0.2 / 1 milyong simpleng kahilingan).
Ang scalability ng naturang sistema ay halos perpekto - ang cloud provider ang nag-aalaga dito, ang Kubeless ay awtomatikong nagsusukat sa loob ng Kubernetes cluster.
May mga disadvantages:
- ang pagbuo ng malalaking aplikasyon ay nagiging mas mahirap
- may kahirapan sa mga aplikasyon sa pag-profile (mga log lang ang available sa iyo, ngunit hindi pag-profile sa karaniwang kahulugan)
- walang versioning
Sa totoo lang, narinig ko ang tungkol sa Serverless ilang taon na ang nakalilipas, ngunit sa lahat ng mga taon na ito ay hindi malinaw sa akin kung paano ito gamitin nang tama. Matapos ang ulat ni Ruslan, lumitaw ang pag-unawa, at pagkatapos ng ulat ni Nikolai Sverchkov (Evil Martians) mula sa seksyong Backend, ito ay pinagsama-sama. Walang kabuluhan ang pagpunta ko sa kumperensya :)
Ang CI ay para sa mahihirap, o sulit ba ang pagsulat ng sarili mong CI para sa isang web studio?
Si Mikhail Radionov, pinuno ng Flag web studio mula sa Yekaterinburg, ay nagsalita tungkol sa self-written CI/CD.
Ang kanyang studio ay napunta mula sa "manual CI/CD" (mag-log in sa server sa pamamagitan ng SSH, gumawa ng git pull, ulitin ng 100 beses sa isang araw) sa Jenkins at sa isang self-written na tool na nagbibigay-daan sa iyong subaybayan ang code at magsagawa ng mga release na tinatawag na Pullkins .
Bakit hindi gumana si Jenkins? Hindi ito nagbigay ng sapat na kakayahang umangkop bilang default at napakahirap i-customize.
Ang “Flag” ay nabuo sa Laravel (PHP framework). Sa pagbuo ng isang CI/CD server, ginamit ni Mikhail at ng kanyang mga kasamahan ang mga built-in na mekanismo ni Laravel na tinatawag na Telescope at Envoy. Ang resulta ay isang server sa PHP (pakitandaan) na nagpoproseso ng mga papasok na kahilingan sa webhook, maaaring bumuo ng frontend at backend, mag-deploy sa iba't ibang mga server, at mag-ulat sa Slack.
Pagkatapos, upang makapagsagawa ng asul/berde na pag-deploy at magkaroon ng pare-parehong mga setting sa mga dev-stage-prod na kapaligiran, lumipat sila sa Docker. Ang mga kalamangan ay nanatiling pareho, ang mga posibilidad ng homogenizing ang kapaligiran at tuluy-tuloy na pag-deploy ay idinagdag, at ang pangangailangan na matutunan ang Docker upang gumana dito nang tama ay idinagdag.
Paano namin binawasan ng 99% ang bilang ng mga rollback ng release ng server
Ang huling ulat sa seksyong Devops ay mula kay Viktor Eremchenko, Lead devops engineer sa Miro.com (dating RealTimeBoard).
Ang RealTimeBoard, ang pangunahing produkto ng Miro team, ay batay sa isang monolitikong Java application. Ang pagkolekta, pagsubok at pag-deploy nito nang walang downtime ay isang mahirap na gawain. Sa kasong ito, mahalagang i-deploy ang naturang bersyon ng code para hindi na ito kailangang ibalik (ito ay isang mabigat na monolith).
Sa paraan sa pagbuo ng isang sistema na nagpapahintulot sa iyo na gawin ito, si Miro ay dumaan sa isang landas na kasama ang pagtatrabaho sa arkitektura, ang mga tool na ginamit (Atlassian Bamboo, Ansible, atbp), at paggawa sa istraktura ng mga koponan (mayroon na silang isang dedikadong Devops team + maraming hiwalay na Scrum team mula sa mga developer ng iba't ibang profile).
Naging mahirap at matinik ang landas, at ibinahagi ni Victor ang naipon na sakit at optimismo na hindi nagtapos doon.
Nanalo ng libro para sa pagtatanong
Seksyon ng backend
Nagawa kong dumalo sa 2 ulat - mula kay Nikolay Sverchkov (Evil Martians), tungkol din sa Serverless, at mula kay Grigory Koshelev (Kontur company) tungkol sa telemetry.
Walang server para sa mga mortal lang
Kung pinag-uusapan ni Ruslan Sirkin kung ano ang Serverless, ipinakita ni Nikolay ang mga simpleng application gamit ang Serverless, at pinag-usapan ang mga detalyeng nakakaapekto sa gastos at bilis ng mga application sa AWS Lambda.
Isang kawili-wiling detalye: ang minimum na bayad na elemento ay 128 Mb ng memorya at 100 ms CPU, nagkakahalaga ito ng $0,000000208. Bukod dito, libre ang 1 milyong mga naturang kahilingan kada buwan.
Ang ilan sa mga function ni Nikolai ay madalas na lumampas sa 100 ms na limitasyon (ang pangunahing application ay isinulat sa Ruby), kaya ang muling pagsulat sa mga ito sa Go ay nagbigay ng mahusay na pagtitipid.
Vostok Hercules — gawing mahusay muli ang telemetry!
Ang pinakabagong ulat ng seksyong Backend mula kay Grigory Koshelev (kumpanya ng Kontur) tungkol sa telemetry. Ang ibig sabihin ng telemetry ay mga log, sukatan, mga bakas ng aplikasyon.
Para sa layuning ito, gumagamit ang Contour ng mga self-written na tool na nai-post sa Github. Tool mula sa ulat - Hercules, , ay ginagamit upang maghatid ng data ng telemetry.
Ang ulat ni Vladimir Lila sa seksyong Devops ay tinalakay ang pag-iimbak at pagproseso ng mga log sa Elasticsearch, ngunit mayroon pa ring gawain na maghatid ng mga log mula sa libu-libong mga device at application, at ang mga tool tulad ng Vostok Hercules ay malulutas ang mga ito.
Sinundan ng circuit ang landas na kilala ng marami - mula RabbitMQ hanggang Apache Kafka, ngunit hindi lahat ay napakasimple)) Kailangan nilang idagdag ang Zookeeper, Cassandra at Graphite sa circuit. Hindi ko ganap na ibubunyag ang impormasyon sa ulat na ito (hindi ang aking profile), kung interesado ka, maaari kang maghintay para sa mga slide at video sa website ng kumperensya.
Paano ito kumpara sa ibang mga kumperensya?
Hindi ko ito maihahambing sa mga kumperensya sa Moscow at St. Petersburg, maihahambing ko ito sa iba pang mga kaganapan sa Urals at sa 404fest sa Samara.
Ang DAMP ay gaganapin sa 8 mga seksyon, ito ay isang talaan para sa mga kumperensya ng Ural. Napakalaking seksyon ng Science at Pamamahala, ito ay hindi pangkaraniwan. Ang madla sa Yekaterinburg ay medyo nakaayos - ang lungsod ay may malalaking departamento ng pag-unlad para sa Yandex, Kontur, Tinkoff, at nag-iiwan ito ng marka sa mga ulat.
Ang isa pang kawili-wiling punto ay ang maraming mga kumpanya ay may 3-4 na tagapagsalita sa kumperensya nang sabay-sabay (ito ang kaso sa Kontur, Evil Martians, Tinkoff). Marami sa kanila ay mga sponsor, ngunit ang mga ulat ay medyo pare-pareho sa iba, ang mga ito ay hindi mga ulat sa advertising.
pupunta o hindi pupunta? Kung nakatira ka sa Urals o malapit, mayroon kang pagkakataon at interesado sa mga paksa - oo, siyempre. Kung iniisip mo ang tungkol sa isang mahabang paglalakbay, titingnan ko ang mga paksa ng mga ulat at mga ulat sa video mula sa mga nakaraang taon at gumawa ng desisyon.
Ang isa pang bentahe ng mga kumperensya sa mga rehiyon, bilang panuntunan, ay madaling makipag-usap sa tagapagsalita pagkatapos ng mga ulat; mas kaunti lang ang mga aplikante para sa naturang komunikasyon.
Salamat sa Dump at Ekaterinburg! )
Pinagmulan: www.habr.com