Անցյալ շաբաթ ես գնացի Եկատերինբուրգում DUMP IT կոնֆերանսին (https://dump-ekb.ru/) և ուզում եմ պատմել ձեզ, թե ինչ է քննարկվել Backend և Devops բաժիններում, և արդյոք արժե ուշադրություն դարձնել տարածաշրջանային ՏՏ համաժողովներին:
Նիկոլայ Սվերչկովը Չար մարսեցիներից՝ առանց սերվերի մասին
Ինչ կար, այնուամենայնիվ:
Ընդհանուր առմամբ, համաժողովն ուներ 8 բաժին՝ Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management:
Ամենամեծ սրահները, ի դեպ, Գիտություն և Մենեջմենթում են)) ~350 հոգու համար։ Backend-ը և Frontend-ը շատ ավելի փոքր չեն: Devops սենյակը ամենափոքրն էր, բայց ակտիվ:
Ես լսեցի Devops և Backend բաժինների զեկույցները և մի փոքր խոսեցի խոսնակների հետ: Ես կցանկանայի խոսել համաժողովում ընդգրկված թեմաների մասին և վերանայել այս բաժինները:
Devops և Backend բաժիններում ելույթ ունեցան SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) ներկայացուցիչները։ CI/CD-ի վրա ընդգրկված թեմաները, հերթերի ծառայությունների հետ աշխատելը, գրանցամատյանները, առանց սերվերի թեմաները և PostgreSQL-ի հետ աշխատելը Go-ում լավ լուսաբանված էին:
Զեկուցումներ եղան նաև Avito-ի, Tinkoff-ի, Yandex-ի, Jetstyle-ի, Megafon-ի, Ak Bars Bank-ի կողմից, սակայն ես ժամանակ չունեի ֆիզիկապես ներկա գտնվելու դրանց (տեսանյութերի ձայնագրություններն ու զեկույցների սլայդները դեռ չկան, խոստանում են դրանք տեղադրել 2 շաբաթվա ընթացքում: dump-ekb.ru կայքում):
Devops բաժինը
Զարմանալին այն էր, որ հատվածն անցկացվում էր ամենափոքր դահլիճում՝ մոտ 50 նստատեղով։ Մարդիկ նույնիսկ միջանցքներում էին կանգնած :) Ես ձեզ կպատմեմ այն զեկույցների մասին, որոնք հասցրել եմ լսել:
Պետաբայթ կշռող էլաստիկ
Բաժինը սկսվեց Վլադիմիր Լիլի (SKB-Kontur) զեկույցով Կոնթուրում Elasticsearch-ի մասին: Նրանք ունեն բավականին մեծ և բեռնված Elastic (~800 TB տվյալներ, ~1.3 petabytes հաշվի առնելով ավելորդությունը): Kontur-ի բոլոր ծառայությունների համար Elasticsearch-ը միայնակ է, բաղկացած է 2 կլաստերներից (7 և 9 սերվերներից) և այնքան կարևոր է, որ Kontur-ն ունի հատուկ Elasticsearch ինժեներ (իրականում, ինքը՝ Վլադիմիրը):
Վլադիմիրը նաև կիսվել է իր մտքերով Elasticsearch-ի առավելությունների և դրա հետ կապված խնդիրների մասին:
Առավելությունները,
- Բոլոր տեղեկամատյանները մեկ տեղում են, դրանց հասանելիությունը հեշտ է
- Տեղեկամատյանների պահպանում մեկ տարի և հեշտությամբ վերլուծելով դրանք
- Տեղեկամատյանների հետ աշխատելու բարձր արագություն
- Տվյալների հիանալի վիզուալիզացիա տուփից դուրս
Խնդիրներ:
- Հաղորդագրությունների միջնորդը պարտադիր է (Կոնտուրի համար նրա դերը խաղում է Կաֆկան)
- Elasticsearch Curator-ի հետ աշխատելու առանձնահատկությունները (Պարբերաբար ստեղծված բարձր ծանրաբեռնվածություն Curator-ում սովորական առաջադրանքներից)
- ոչ ներկառուցված թույլտվություն (միայն առանձին, բավականին մեծ գումարի համար կամ որպես արտադրության տարբեր աստիճանի պատրաստակամության բաց կոդով պլագիններ)
Open Distro-ի մասին միայն դրական կարծիքներ եղան Elasticsearch-ի համար :) Նույն թույլտվության հարցը լուծվել է այնտեղ։
Որտեղի՞ց է առաջանում petabyte-ը:Նրանց հանգույցները բաղկացած են 12*8 Tb SATA + 2*2 Tb SSD սերվերներից։ Սառը պահեստավորում SATA-ում, SSD միայն տաք քեշի համար (տաք պահեստ):
7+9 սերվեր, (7 + 9) * 12 * 8 = 1536 Tb:
Տարածքի մի մասը պահուստային է, հատկացված է ավելորդության և այլն։
Շուրջ 90 հավելվածների տեղեկամատյաններն ուղարկվում են Elasticsearch, ներառյալ Kontur, Elba և այլն հաշվետվությունների բոլոր ծառայությունները:
Առանց սերվերի վրա մշակման առանձնահատկությունները
Հաջորդը Ռուսլան Սերկինի զեկույցն է DataArt-ից Serverless-ի մասին:
Ռուսլանը խոսեց այն մասին, թե ընդհանրապես ինչ է զարգացումը Serverless մոտեցմամբ, և որոնք են դրա առանձնահատկությունները:
Անսերվերը զարգացման մոտեցում է, որտեղ ծրագրավորողները ոչ մի կերպ չեն դիպչում ենթակառուցվածքին: Օրինակ՝ AWS Lambda Serverless, Kubeless.io (Serverless in Kubernetes), Google Cloud Functions:
Իդեալական Serverless հավելվածը պարզապես գործառույթ է, որը հարցում է ուղարկում առանց սերվերի մատակարարին հատուկ API Gateway-ի միջոցով: Իդեալական միկրոծառայություն, մինչդեռ AWS Lambda-ն աջակցում է նաև ժամանակակից ծրագրավորման մեծ թվով լեզուների: Ենթակառուցվածքների պահպանման և տեղակայման ծախսերը ամպային մատակարարների դեպքում դառնում են զրոյական, փոքր հավելվածների աջակցությունը նույնպես շատ էժան կլինի (AWS Lambda - $0.2 / 1 միլիոն պարզ հարցումներ):
Նման համակարգի մասշտաբայնությունը գրեթե իդեալական է. ամպի մատակարարն ինքն է հոգում դրա մասին, Kubeless-ը ինքնաբերաբար մասշտաբվում է Kubernetes կլաստերում:
Կան թերություններ.
- խոշոր հավելվածների մշակումն ավելի դժվար է դառնում
- հավելվածների պրոֆիլավորման հետ կապված դժվարություններ կան (դուք ունեք մուտք դեպի տեղեկամատյաններ, բայց ոչ սովորական իմաստով պրոֆիլավորում)
- ոչ մի տարբերակում
Անկեղծ ասած, ես մի քանի տարի առաջ լսել էի Serverless-ի մասին, բայց այս տարիների ընթացքում ինձ համար պարզ չէր, թե ինչպես այն ճիշտ օգտագործել։ Ռուսլանի զեկույցից հետո հասկացողություն հայտնվեց, և Նիկոլայ Սվերչկովի (Չար մարսեցիներ) զեկույցից հետո Backend բաժնից այն համախմբվեց: Իզուր չէի գնացել համաժողովի :)
CI-ն աղքատների համար է, թե՞ արժե գրել ձեր սեփական CI-ն վեբ ստուդիայի համար:
Եկատերինբուրգից «Դրոշ» վեբ ստուդիայի ղեկավար Միխայիլ Ռադիոնովը խոսեց ինքնուրույն գրված CI/CD-ի մասին:
Նրա ստուդիան «մեխանիկական CI/CD»-ից (մուտք գործեք սերվեր SSH-ի միջոցով, կատարեք git pull, կրկնեք օրական 100 անգամ) դեպի Jenkins և ինքնուրույն գրավոր գործիք, որը թույլ է տալիս վերահսկել կոդը և կատարել թողարկումներ, որոնք կոչվում են Pullkins: .
Ինչու Ջենկինսը չաշխատեց: Այն լռելյայն բավարար ճկունություն չէր ապահովում և չափազանց դժվար էր հարմարեցնելը:
«Դրոշը» զարգանում է Laravel-ում (PHP Framework): CI/CD սերվեր մշակելիս Միխայիլը և նրա գործընկերները օգտագործել են Laravel-ի ներկառուցված մեխանիզմները, որոնք կոչվում են աստղադիտակ և բանագնաց: Արդյունքը PHP-ում սերվեր է (խնդրում ենք նկատի ունենալ), որը մշակում է մուտքային վեբհուկի հարցումները, կարող է կառուցել ճակատը և հետնամասը, տեղակայվել տարբեր սերվերների վրա և զեկուցել Slack-ին:
Այնուհետև, որպեսզի կարողանան կատարել կապույտ/կանաչ տեղակայում և ունենալ միատեսակ կարգավորումներ dev-stage-prod միջավայրերում, նրանք անցան Docker-ին: Առավելությունները մնացին նույնը, ավելացվեցին շրջակա միջավայրի համասեռացման և անխափան տեղակայման հնարավորությունները, ավելացվեց Docker-ին սովորելու անհրաժեշտությունը դրա հետ ճիշտ աշխատելու համար։
Ինչպես մենք կրճատեցինք սերվերի թողարկման հետադարձումների քանակը 99%-ով
Devops բաժնի վերջին զեկույցը Վիկտոր Էրեմչենկոյից էր՝ Miro.com-ի առաջատար devops ինժեներ (նախկինում՝ RealTimeBoard):
RealTimeBoard-ը՝ Miro թիմի առաջատար արտադրանքը, հիմնված է միաձույլ Java հավելվածի վրա: Այն հավաքելը, փորձարկելը և տեղակայելը առանց պարապուրդի դժվար գործ է: Այս դեպքում կարևոր է տեղակայել կոդի նման տարբերակը, որպեսզի այն ետ չվերցվի (դա ծանր մոնոլիտ է):
Համակարգ ստեղծելու ճանապարհին, որը թույլ է տալիս դա անել, Միրոն անցավ մի ճանապարհով, որը ներառում էր ճարտարապետության, օգտագործվող գործիքների (Atlassian Bamboo, Ansible և այլն) վրա աշխատելը և թիմերի կառուցվածքի վրա աշխատելը (այժմ նրանք ունեն. Devops-ի նվիրված թիմ + բազմաթիվ առանձին Scrum թիմեր տարբեր պրոֆիլների մշակողներից):
Ճանապարհը դժվար ու փշոտ ստացվեց, և Վիկտորը կիսեց կուտակված ցավն ու լավատեսությունը, որն այսքանով չավարտվեց։
Հարցեր տալու համար գիրք շահեց
Backend բաժինը
Ինձ հաջողվեց ներկա լինել 2 զեկույցի՝ Նիկոլայ Սվերչկովից (Չար մարսեցիներ), նաև առանց սերվերի, և Գրիգորի Կոշելևից (Կոնտուր ընկերություն) հեռաչափության մասին։
Անսերվեր հասարակ մահկանացուների համար
Եթե Ռուսլան Սիրկինը խոսեց այն մասին, թե ինչ է Serverless-ը, Նիկոլայը ցույց տվեց պարզ հավելվածներ՝ օգտագործելով Serverless, և խոսեց այն մանրամասների մասին, որոնք ազդում են AWS Lambda հավելվածների արժեքի և արագության վրա:
Հետաքրքիր մանրամասն. նվազագույն վճարովի տարրը 128 Մբ հիշողություն է և 100 մվ պրոցեսոր, արժե $0,000000208։ Ընդ որում, ամսական 1 միլիոն նման հարցում անվճար է։
Նիկոլայի որոշ գործառույթներ հաճախ գերազանցում էին 100 ms-ի սահմանաչափը (հիմնական հավելվածը գրված էր Ruby-ով), ուստի Go-ում դրանք վերաշարադրելը գերազանց խնայողություններ էր ապահովում:
Վոստոկ Հերկուլես. Հեռուստաչափությունը կրկին հիանալի դարձրեք:
Գրիգորի Կոշելևի (Կոնտուր ընկերություն) «Backend» բաժնի վերջին զեկույցը հեռաչափության մասին: Հեռուստաչափությունը նշանակում է տեղեկամատյաններ, չափումներ, կիրառական հետքեր:
Այս նպատակով Contour-ն օգտագործում է Github-ում տեղադրված ինքնուրույն գրավոր գործիքներ: Գործիք զեկույցից՝ Հերկուլես, , օգտագործվում է հեռաչափության տվյալները փոխանցելու համար։
Վլադիմիր Լիլայի զեկույցը Devops բաժնում քննարկել է Elasticsearch-ում տեղեկամատյանների պահպանումն ու մշակումը, բայց դեռևս խնդիր կա՝ առաքել տեղեկամատյանները հազարավոր սարքերից և հավելվածներից, և Vostok Hercules-ի նման գործիքները լուծում են դրանք:
Շրջանակը գնաց շատերին հայտնի ճանապարհով՝ RabbitMQ-ից մինչև Apache Kafka, բայց ամեն ինչ այդքան էլ պարզ չէ)) Նրանք պետք է միացնեն Zookeeper-ը, Cassandra-ն և Graphite-ը: Ես ամբողջությամբ չեմ բացահայտի այս զեկույցի տեղեկատվությունը (ոչ իմ պրոֆիլը), եթե հետաքրքրված եք, կարող եք սպասել սլայդներին և տեսանյութերին համաժողովի կայքում:
Ինչպե՞ս է այն համեմատվում այլ կոնֆերանսների հետ:
Ես չեմ կարող դա համեմատել Մոսկվայի և Սանկտ Պետերբուրգի կոնֆերանսների հետ, կարող եմ համեմատել Ուրալի այլ իրադարձությունների և Սամարայի 404fest-ի հետ:
DAMP-ն անցկացվում է 8 բաժիններով, սա ռեկորդ է Ուրալյան կոնֆերանսների համար։ Գիտություն և կառավարում շատ մեծ բաժիններ, սա նույնպես անսովոր է: Եկատերինբուրգի հանդիսատեսը բավականին կառուցված է. քաղաքն ունի զարգացման մեծ բաժիններ Yandex-ի, Kontur-ի, Tinkoff-ի համար, և դա իր հետքն է թողնում զեկույցների վրա:
Հետաքրքիր է նաև այն, որ շատ ընկերություններ կոնֆերանսում ունենում են միանգամից 3-4 խոսնակ (այդպես է եղել Կոնթուրի, Չար Մարսիանսի, Թինկոֆի դեպքում): Նրանցից շատերը հովանավորներ են եղել, բայց հաշվետվությունները բավականին հավասար են մյուսներին, դրանք գովազդային ռեպորտաժներ չեն:
Գնա՞լ, թե՞ չգնալ. Եթե դուք ապրում եք Ուրալում կամ մոտակայքում, դուք հնարավորություն ունեք և հետաքրքրված եք թեմաներով - այո, իհարկե: Եթե մտածում եք երկար ճանապարհորդության մասին, ես կանդրադառնամ նախորդ տարիների ռեպորտաժների և վիդեո ռեպորտաժների թեմաներին և որոշում կայացրեց.
Մարզերում կոնֆերանսների մյուս առավելությունը, որպես կանոն, այն է, որ զեկուցումներից հետո հեշտ է շփվել բանախոսի հետ, պարզապես նման հաղորդակցության համար դիմողները քիչ են։
Շնորհիվ Դամպի և Եկատերինբուրգի: )
Source: www.habr.com