Wiki iliyopita nilienda kwenye mkutano wa DUMP IT (https://dump-ekb.ru/) huko Yekaterinburg na ninataka kukuambia kile kilichojadiliwa katika sehemu za Backend na Devops, na ikiwa mikutano ya kikanda ya IT inafaa kuzingatiwa.
Nikolay Sverchkov kutoka kwa Martians mbaya kuhusu Serverless
Kulikuwa na nini?
Kwa jumla, mkutano huo ulikuwa na sehemu 8: Backend, Frontend, Mobile, Testing na QA, Devops, Design, Sayansi na Management.
Kumbi kubwa zaidi, kwa njia, ziko katika Sayansi na Usimamizi)) Kwa ~ watu 350 kila moja. Backend na Frontend si ndogo sana. Chumba cha Devops kilikuwa kidogo zaidi, lakini kilikuwa cha kazi.
Nilisikiliza ripoti katika sehemu za Devops na Backend na nikazungumza kidogo na wasemaji. Ningependa kuzungumzia mada zinazoshughulikiwa na kupitia sehemu hizi kwenye mkutano.
Wawakilishi wa SKB-Kontur, DataArt, Evil Martians, Bendera ya studio ya wavuti ya Ekaterinburg, Miro (RealTimeBoard) walizungumza katika sehemu za Devops na Backend. Mada zinazohusu CI/CD, kufanya kazi na huduma za foleni, ukataji miti; Mada zisizo na seva na kufanya kazi na PostgreSQL katika Go zilishughulikiwa vyema.
Pia kulikuwa na ripoti za Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, lakini sikuwa na wakati wa kuhudhuria kimwili (rekodi za video na slaidi za ripoti bado hazipatikani, wanaahidi kuzichapisha ndani ya wiki 2. kwenye dampo-ekb.ru).
Sehemu ya Devops
Kilichoshangaza ni kwamba sehemu hiyo ilifanywa katika jumba dogo zaidi, lenye viti 50 hivi. Watu walikuwa wamesimama hata kwenye aisles :) Nitawaambia kuhusu ripoti ambazo niliweza kusikiliza.
Elastic yenye uzito wa petabyte
Sehemu ilianza na ripoti ya Vladimir Lil (SKB-Kontur) kuhusu Elasticsearch huko Kontur. Zina Elastiki kubwa na iliyopakiwa (~ 800 TB ya data, ~ petabytes 1.3 ikizingatia upungufu). Elasticsearch kwa huduma zote za Kontur ni moja, ina makundi 2 (ya seva 7 na 9), na ni muhimu sana kwamba Kontur ana mhandisi maalum wa Elasticsearch (kwa kweli, Vladimir mwenyewe).
Vladimir pia alishiriki mawazo yake juu ya faida za Elasticsearch na shida zinazoleta.
Faida:
- Kumbukumbu zote ziko katika sehemu moja, ufikiaji rahisi kwao
- Kuhifadhi kumbukumbu kwa mwaka na kuchambua kwa urahisi
- Kasi ya juu ya kufanya kazi na magogo
- Taswira nzuri ya data nje ya kisanduku
Shida ni:
- wakala wa ujumbe ni lazima awe nao (kwa Kontur jukumu lake linachezwa na Kafka)
- vipengele vya kufanya kazi na Elasticsearch Curator (mara kwa mara hutengeneza mzigo wa juu kutoka kwa kazi za kawaida katika Curator)
- hakuna idhini iliyojumuishwa (kwa pesa tofauti, kubwa kabisa, au kama programu-jalizi huria za viwango tofauti vya utayari wa uzalishaji)
Kulikuwa na hakiki chanya tu kuhusu Open Distro kwa Elasticsearch :) Suala sawa la uidhinishaji limetatuliwa hapo.
Petabyte inatoka wapi?Nodes zao zinajumuisha seva na 12*8 Tb SATA + 2*2 Tb SSD. Hifadhi ya baridi kwenye SATA, SSD tu kwa kache ya moto (hifadhi ya moto).
Seva 7+9, (7 + 9) * 12 * 8 = 1536 Tb.
Sehemu ya nafasi iko kwenye hifadhi, iliyotengwa kwa ajili ya kupunguzwa, nk.
Kumbukumbu kutoka kwa takriban maombi 90 hutumwa kwa Elasticsearch, ikijumuisha huduma zote za kuripoti za Kontur, Elba, n.k.
Vipengele vya maendeleo kwenye Serverless
Ifuatayo ni ripoti ya Ruslan Serkin kutoka DataArt kuhusu Serverless.
Ruslan alizungumza juu ya maendeleo gani na mbinu ya Serverless kwa ujumla, na sifa zake ni nini.
Serverless ni mbinu ya maendeleo ambayo watengenezaji hawagusi miundombinu kwa njia yoyote. Mfano - AWS Lambda Serverless, Kubeless.io (Isio na Server ndani ya Kubernetes), Google Cloud Functions.
Programu bora isiyo na Seva ni chaguo la kukokotoa ambalo hutuma ombi kwa mtoa huduma bila Seva kupitia Lango maalum la API. Huduma ndogo ndogo, wakati AWS Lambda pia inasaidia idadi kubwa ya lugha za kisasa za programu. Gharama ya kudumisha na kupeleka miundombinu inakuwa sifuri katika kesi ya watoa huduma za wingu, kusaidia programu ndogo pia itakuwa nafuu sana (AWS Lambda - $0.2 / milioni 1 maombi rahisi).
Kuongezeka kwa mfumo kama huo ni karibu bora - mtoaji wa wingu anajitunza mwenyewe, Kubeless huweka kiotomatiki ndani ya nguzo ya Kubernetes.
Kuna hasara:
- kutengeneza programu kubwa inakuwa ngumu zaidi
- kuna ugumu wa kuchakachua programu (kumbukumbu pekee ndizo zinapatikana kwako, lakini sio kuorodhesha kwa maana ya kawaida)
- hakuna toleo
Kuwa waaminifu, nilisikia kuhusu Serverless miaka michache iliyopita, lakini miaka hii yote haikuwa wazi kwangu jinsi ya kuitumia kwa usahihi. Baada ya ripoti ya Ruslan, uelewa ulionekana, na baada ya ripoti ya Nikolai Sverchkov (Martians mabaya) kutoka sehemu ya Backend, iliunganishwa. Haikuwa bure kwamba nilienda kwenye mkutano :)
CI ni ya maskini, au inafaa kuandika CI yako mwenyewe kwa studio ya wavuti?
Mikhail Radionov, mkuu wa studio ya tovuti ya Bendera kutoka Yekaterinburg, alizungumza kuhusu kujiandikia CI/CD.
Studio yake imetoka kwa "mwongozo CI/CD" (ingia kwenye seva kupitia SSH, fanya git pull, rudia mara 100 kwa siku) hadi kwa Jenkins na kwa zana iliyojiandika ambayo hukuruhusu kufuatilia nambari na kutekeleza matoleo yanayoitwa Pullkins. .
Kwa nini Jenkins hakufanya kazi? Haikutoa unyumbulifu wa kutosha kwa chaguomsingi na ilikuwa ngumu sana kubinafsisha.
"Bendera" inakua katika Laravel (mfumo wa PHP). Wakati wa kutengeneza seva ya CI/CD, Mikhail na wenzake walitumia njia za ndani za Laravel zinazoitwa Telescope na Mjumbe. Matokeo yake ni seva katika PHP (tafadhali kumbuka) ambayo huchakata maombi yanayoingia ya webhook, inaweza kuunda sehemu ya mbele na ya nyuma, kupeleka kwa seva tofauti, na kuripoti kwa Slack.
Halafu, ili kuweza kutekeleza uwekaji wa bluu/kijani na kuwa na mipangilio sare katika mazingira ya uboreshaji wa hatua ya uboreshaji, walibadilisha hadi Docker. Faida zilibakia sawa, uwezekano wa kufanya homogenizing mazingira na kupelekwa kwa mshono uliongezwa, na haja ya kujifunza Docker kufanya kazi nayo kwa usahihi iliongezwa.
Jinsi tulivyopunguza idadi ya kurudishiwa toleo la seva kwa 99%
Ripoti ya mwisho katika sehemu ya Devops ilitoka kwa Viktor Eremchenko, Mhandisi Lead devops katika Miro.com (zamani RealTimeBoard).
RealTimeBoard, bidhaa kuu ya timu ya Miro, inategemea programu ya Java ya monolithic. Kukusanya, kupima na kuipeleka bila muda wa chini ni kazi ngumu. Katika kesi hii, ni muhimu kupeleka toleo kama hilo la msimbo ili sio lazima irudishwe nyuma (ni monolith nzito).
Katika njia ya kujenga mfumo unaokuruhusu kufanya hivyo, Miro alipitia njia ambayo ni pamoja na kufanya kazi kwenye usanifu, zana zinazotumiwa (Atlassian Bamboo, Ansible, nk), na kufanya kazi kwenye muundo wa timu (sasa wanayo. timu iliyojitolea ya Devops + timu nyingi tofauti za Scrum kutoka kwa watengenezaji wa wasifu tofauti).
Njia iligeuka kuwa ngumu na yenye miiba, na Victor alishiriki maumivu na matumaini yaliyokusanywa ambayo hayakuishia hapo.
Alishinda kitabu kwa kuuliza maswali
Sehemu ya nyuma
Niliweza kuhudhuria ripoti 2 - kutoka kwa Nikolay Sverchkov (Martians mabaya), pia kuhusu Serverless, na kutoka kwa Grigory Koshelev (kampuni ya Kontur) kuhusu telemetry.
Wasio na utumishi kwa wanadamu tu
Ikiwa Ruslan Sirkin alizungumza juu ya nini Serverless ni, Nikolay alionyesha programu rahisi kutumia Serverless, na alizungumza juu ya maelezo yanayoathiri gharama na kasi ya programu katika AWS Lambda.
Maelezo ya kuvutia: kipengele cha chini cha kulipwa ni 128 Mb ya kumbukumbu na 100 ms CPU, inagharimu $0,000000208. Zaidi ya hayo, maombi kama hayo milioni 1 kwa mwezi ni bure.
Baadhi ya utendakazi wa Nikolai mara nyingi ulizidi kikomo cha 100 ms (programu kuu iliandikwa kwa Ruby), kwa hivyo kuziandika upya katika Go kulitoa uokoaji bora.
Vostok Hercules - fanya telemetry kuwa nzuri tena!
Ripoti ya hivi karibuni ya sehemu ya Backend kutoka kwa Grigory Koshelev (kampuni ya Kontur) kuhusu telemetry. Telemetry inamaanisha kumbukumbu, vipimo, ufuatiliaji wa programu.
Kwa kusudi hili, Contour hutumia zana za kujiandikia zilizowekwa kwenye Github. Chombo kutoka kwa ripoti - Hercules, , hutumika kutoa data ya telemetry.
Ripoti ya Vladimir Lila katika sehemu ya Devops ilijadili kuhifadhi na kuchakata magogo katika Elasticsearch, lakini bado kuna kazi ya kutoa kumbukumbu kutoka kwa maelfu ya vifaa na programu, na zana kama Vostok Hercules huzitatua.
Mzunguko ulifuata njia inayojulikana kwa wengi - kutoka kwa RabbitMQ hadi Apache Kafka, lakini si kila kitu ni rahisi sana)) Walipaswa kuongeza Zookeeper, Cassandra na Graphite kwenye mzunguko. Sitafichua kikamilifu habari kwenye ripoti hii (sio wasifu wangu), ikiwa una nia, unaweza kusubiri slaidi na video kwenye tovuti ya mkutano.
Je, inalinganishwaje na mikutano mingine?
Siwezi kulinganisha na mikutano huko Moscow na St. Petersburg, naweza kulinganisha na matukio mengine katika Urals na kwa 404fest huko Samara.
DAMP inafanyika katika sehemu 8, hii ni rekodi ya mikutano ya Ural. Sehemu kubwa sana za Sayansi na Usimamizi, hii pia sio kawaida. Watazamaji huko Yekaterinburg wameundwa kabisa - jiji lina idara kubwa za maendeleo za Yandex, Kontur, Tinkoff, hii inaacha alama yake kwenye ripoti.
Jambo lingine la kuvutia ni kwamba makampuni mengi yana wasemaji 3-4 kwenye mkutano mara moja (hii ilikuwa kesi na Kontur, Evil Martians, Tinkoff). Wengi wao walikuwa wafadhili, lakini ripoti zinalingana kabisa na zingine, hizi sio ripoti za utangazaji.
Kwenda au kutokwenda? Ikiwa unaishi katika Urals au karibu, una fursa na una nia ya mada - ndiyo, bila shaka. Ikiwa unafikiria kuhusu safari ndefu, ningeangalia mada za ripoti na ripoti za video za miaka iliyopita na kufanya uamuzi.
Faida nyingine ya mikutano katika mikoa, kama sheria, ni kwamba ni rahisi kuwasiliana na mzungumzaji baada ya ripoti; kuna waombaji wachache wa mawasiliano kama haya.
Asante kwa Dampo na Ekaterinburg! )
Chanzo: mapenzi.com