Sa tagsibol na ito, natagpuan namin ang aming sarili sa napakasayang mga kondisyon. Dahil sa pandemya, naging malinaw na ang aming mga kumperensya sa tag-init ay kailangang ilipat online. At upang maisagawa ang mga ito nang mahusay sa online, ang mga handa na solusyon sa software ay hindi angkop para sa amin; kailangan naming magsulat ng sarili namin. At mayroon kaming tatlong buwan para gawin ito.
Ito ay malinaw na ito ay isang kapana-panabik na tatlong buwan. Ngunit mula sa labas ay hindi ito lubos na halata: ano ang isang online na platform ng kumperensya? Anong mga bahagi ang binubuo nito? Samakatuwid, sa huling mga kumperensya ng DevOops sa tag-araw, tinanong ko ang mga responsable para sa gawaing ito:
- Nikolay Molchanov - teknikal na direktor ng JUG Ru Group;
- Si Vladimir Krasilshchik ay isang pragmatic Java programmer na nagtatrabaho sa backend (maaari mo ring makita ang kanyang mga ulat sa aming mga Java conference);
- Si Artyom Nikonov ang responsable para sa lahat ng aming video streaming.
Sa pamamagitan ng paraan, sa mga kumperensya ng taglagas-taglamig ay gagamit kami ng pinahusay na bersyon ng parehong platform - napakaraming mga mambabasa ng habra ang magiging mga gumagamit nito.
Ang malaking larawan
— Ano ang komposisyon ng pangkat?
Nikolay Molchanov: Mayroon kaming isang analyst, isang designer, isang tester, tatlong front-enders, at isang back-end. At, siyempre, isang T-shaped na espesyalista!
— Ano ang hitsura ng proseso sa pangkalahatan?
Nikolay: Hanggang sa kalagitnaan ng Marso, wala kaming handa para sa online. At noong Marso 15, nagsimulang umikot ang buong online carousel. Nag-set up kami ng ilang mga repository, nagplano, tinalakay ang pangunahing arkitektura at ginawa ang lahat sa loob ng tatlong buwan.
Ito, siyempre, ay dumaan sa mga klasikong yugto ng pagpaplano, arkitektura, pagpili ng tampok, pagboto para sa mga tampok na iyon, patakaran para sa mga tampok na iyon, kanilang disenyo, pag-unlad, pagsubok. Bilang resulta, noong Hunyo 6, inilunsad namin ang lahat sa produksyon. . Mayroong 90 araw para sa lahat.
— Natupad ba natin ang ating pinangako?
Nikolay: Dahil nakikilahok na kami ngayon sa kumperensya ng DevOops online, nangangahulugan ito na gumana ito. Ako mismo ay nakatuon sa pangunahing bagay: Magdadala ako sa mga customer ng isang tool kung saan maaari silang gumawa ng online na kumperensya.
Ang hamon ay ito: bigyan kami ng tool kung saan maaari naming i-broadcast ang aming mga kumperensya sa mga may hawak ng ticket.
Ang lahat ng pagpaplano ay nahahati sa ilang mga yugto, at lahat ng mga tampok (mga 30 global) ay nahahati sa 4 na kategorya:
- na tiyak na gagawin natin (hindi tayo mabubuhay kung wala sila),
- na gagawin natin pangalawa,
- na hinding hindi natin gagawin,
- at hinding-hindi natin gagawin.
Ginawa namin ang lahat ng mga tampok mula sa unang dalawang kategorya.
— Alam kong may kabuuang 600 isyu sa JIRA ang nalikha. Sa tatlong buwan, gumawa ka ng 13 microservice, at pinaghihinalaan ko na ang mga ito ay isinulat hindi lamang sa Java. Gumamit ka ng iba't ibang teknolohiya, mayroon kang dalawang Kubernetes cluster sa tatlong availability zone at 5 RTMP stream sa Amazon.
Tingnan natin ngayon ang bawat bahagi ng system nang hiwalay.
Streaming
— Magsimula tayo kapag mayroon na tayong video na imahe, at ito ay ipinadala sa ilang mga serbisyo. Artyom, sabihin sa amin kung paano nangyayari ang streaming na ito?
Artyom Nikonov: Ganito ang hitsura ng aming pangkalahatang scheme: larawan mula sa camera -> aming control room -> lokal na RTMP server -> Amazon -> video player. Higit pang mga detalye sa Habré noong Hunyo.
Sa pangkalahatan, mayroong dalawang pandaigdigang paraan upang gawin ito: alinman sa hardware o batay sa mga solusyon sa software. Pinili namin ang ruta ng software dahil mas madali ito sa kaso ng mga remote speaker. Hindi laging posible na magdala ng hardware sa isang speaker sa ibang bansa, ngunit mukhang mas madali at mas maaasahan ang paghahatid ng software sa speaker.
Mula sa isang hardware point of view, mayroon kaming isang tiyak na bilang ng mga camera (sa aming mga studio at sa mga remote speaker), isang tiyak na bilang ng mga remote control sa studio, na kung minsan ay kailangang ayusin sa ilalim mismo ng mesa sa panahon ng broadcast.
Ang mga signal mula sa mga device na ito ay pumapasok sa mga computer na may mga capture card, input/output card, at sound card. Doon ang mga signal ay pinaghalo at pinagsama sa mga layout:
Halimbawa ng layout para sa 4 na speaker
Halimbawa ng layout para sa 4 na speaker
Dagdag pa, ang tuluy-tuloy na pagsasahimpapawid ay ibinibigay sa tulong ng tatlong mga computer: mayroong isang pangunahing makina at isang pares ng mga gumagana. Kinokolekta ng unang computer ang unang ulat, ang pangalawa - ang pahinga, ang una - ang susunod na ulat, ang pangalawa - ang susunod na pahinga, at iba pa. At hinahalo ng pangunahing makina ang una sa pangalawa.
Lumilikha ito ng isang uri ng tatsulok, at kung ang alinman sa mga node na ito ay nabigo, maaari naming mabilis at walang pagkawala ng kalidad na patuloy na maghatid ng nilalaman sa mga kliyente. Nagkaroon kami ng ganoong sitwasyon. Sa unang linggo ng mga kumperensya, inayos namin ang isang makina, i-on/i-off ito. Mukhang masaya ang mga tao sa ating katatagan.
Susunod, ang mga stream mula sa mga computer ay mapupunta sa isang lokal na server, na may dalawang gawain: ruta ng mga stream ng RTMP at pag-record ng mga backup. Kaya marami kaming recording point. Ang mga video stream ay ipinapadala sa bahagi ng aming system na binuo sa mga serbisyo ng Amazon SaaS. Ginagamit namin ,S3,CloudFront.
Nikolay: Ano ang nangyayari doon bago makarating ang video sa audience? Kailangan mong putulin ito kahit papaano, tama ba?
Artyom: Pinipilit namin ang video sa aming bahagi at ipinapadala ito sa MediaLive. Naglulunsad kami ng mga transcoder doon. Nag-transcode sila ng mga video sa real time sa ilang mga resolusyon upang mapanood ito ng mga tao sa kanilang mga telepono, sa pamamagitan ng mahinang Internet sa bansa, at iba pa. Pagkatapos ang mga batis na ito ay pinutol , ito ay kung paano gumagana ang protocol . Nagpapadala kami ng playlist sa frontend na naglalaman ng mga pointer sa mga chunks na ito.
— Gumagamit ba kami ng 1080p na resolusyon?
Artyom: Ang lapad ng aming video ay kapareho ng 1080p - 1920 pixels, at ang taas ay medyo mas mababa, ang larawan ay mas pinahaba - may mga dahilan para dito.
Manlalaro
— Inilarawan ni Artyom kung paano napupunta ang video sa mga stream, kung paano ito ipinamamahagi sa iba't ibang mga playlist para sa iba't ibang mga resolution ng screen, pinutol sa mga chunks at napupunta sa player. Kolya, ngayon sabihin sa akin kung anong uri ng manlalaro ito, kung paano nito kinokonsumo ang stream, bakit HLS?
Nikolay: Mayroon kaming isang manlalaro na mapapanood ng lahat ng mga manonood ng kumperensya.
Mahalaga, ito ay isang balot sa paligid ng library , kung saan maraming iba pang mga manlalaro ang nakasulat. Ngunit kailangan namin ng napaka-espesipikong pagpapagana: pag-rewind at pagmamarka sa lugar kung nasaan ang tao, kung anong ulat ang kasalukuyang pinapanood niya. Kailangan din namin ang aming sariling mga layout, lahat ng uri ng mga logo at lahat ng iba pa na binuo sa amin. Samakatuwid, nagpasya kaming magsulat ng sarili naming library (isang wrapper sa HLS) at i-embed ito sa site.
Ito ang root functionality, kaya halos nauna itong ipinatupad. At pagkatapos ay lumago ang lahat sa paligid nito.
Sa katunayan, sa pamamagitan ng awtorisasyon, natatanggap ng player mula sa backend ang isang playlist na may mga link sa mga chunks na nauugnay sa oras at kalidad, dina-download ang mga kinakailangan at ipinapakita ang mga ito sa user, na nagsasagawa ng ilang "magic" habang nasa daan.
Halimbawa ng timeline
— Ang isang pindutan ay binuo mismo sa player upang ipakita ang isang timeline ng lahat ng mga ulat...
Nikolay: Oo, agad naming nalutas ang problema sa nabigasyon ng user. Noong kalagitnaan ng Abril, nagpasya kaming hindi namin i-broadcast ang bawat isa sa aming mga kumperensya sa isang hiwalay na website, ngunit pagsasamahin ang lahat sa isa. Upang ang mga gumagamit ng tiket ng Full Pass ay maaaring malayang lumipat sa pagitan ng iba't ibang mga kumperensya: parehong mga live na broadcast at pag-record ng mga nakaraang kumperensya.
At upang gawing mas madali para sa mga user na mag-navigate sa kasalukuyang stream at magpalipat-lipat sa pagitan ng mga track, nagpasya kaming gumawa ng button na "Buong broadcast" at mga pahalang na report card para sa paglipat sa pagitan ng mga track at ulat. Mayroong kontrol sa keyboard.
— Mayroon bang anumang mga teknikal na paghihirap dito?
Nikolay: Mayroon silang scroll bar kung saan minarkahan ang mga panimulang punto ng iba't ibang ulat.
— Sa huli, ipinatupad mo ba ang mga markang ito sa scroll bar bago gumawa ng katulad na bagay ang YouTube?
Artyom: Nasa beta nila ito noon. Tila ito ay isang medyo kumplikadong tampok dahil bahagyang sinubukan nila ito sa mga gumagamit sa nakaraang taon. At ngayon ay umabot na sa benta.
Nikolay: Ngunit talagang nakuha namin ito sa pagbebenta nang mas mabilis. Sa totoo lang, sa likod ng simpleng feature na ito ay may malaking halaga ng backend, frontend, kalkulasyon at matematika sa loob ng player.
Frontend
— Alamin natin kung paano napupunta sa front end ang content na ito na ipinapakita natin (speech card, speaker, website, schedule)?
Vladimir Krasilshchik: Mayroon kaming ilang mga panloob na sistema ng IT. Mayroong isang sistema kung saan ang lahat ng mga ulat at lahat ng mga nagsasalita ay ipinasok. Mayroong proseso kung saan ang isang tagapagsalita ay nakikibahagi sa isang kumperensya. Ang tagapagsalita ay nagsumite ng isang aplikasyon, ang sistema ay nakukuha ito, pagkatapos ay mayroong isang tiyak na pipeline ayon sa kung saan ang ulat ay nilikha.
Ito ay kung paano nakikita ng tagapagsalita ang pipeline
Ang sistemang ito ay ang ating panloob na pag-unlad.
Susunod, kailangan mong bumuo ng iskedyul mula sa mga indibidwal na ulat. Tulad ng alam mo, ito ay isang mahirap na problema sa NP, ngunit kahit papaano ay nalutas namin ito. Para magawa ito, naglulunsad kami ng isa pang bahagi na bumubuo ng iskedyul at ina-upload ito sa third-party na cloud service na Contentful. Doon, ang lahat ay parang isang talahanayan kung saan may mga araw ng kumperensya, sa mga araw na may mga puwang ng oras, at sa mga puwang ay may mga ulat, pahinga o mga aktibidad sa pag-sponsor. Kaya't ang nilalaman na nakikita namin ay matatagpuan sa isang third-party na serbisyo. At ang gawain ay upang ihatid ito sa site.
Tila ang site ay isang pahina lamang na may manlalaro, at walang kumplikado dito. Maliban sa hindi. Ang backend sa likod ng page na ito ay napupunta sa Contentful, kinukuha ang iskedyul mula doon, bumubuo ng ilang bagay at ipinapadala ito sa frontend. Gamit ang isang koneksyon sa websocket, na ginagawa ng bawat kliyente ng aming platform, nagpapadala kami sa kanya ng update sa iskedyul mula sa backend hanggang sa frontend.
Tunay na kaso: ang tagapagsalita ay nagbago ng trabaho sa mismong kumperensya. Kailangan nating palitan ang kanyang employer company badge. Paano ito nangyayari mula sa backend? Ang isang pag-update ay ipinapadala sa lahat ng mga kliyente sa pamamagitan ng websocket, at pagkatapos ay ang frontend mismo ang nagre-redraw sa timeline. Ang lahat ng ito ay nangyayari nang walang putol. Ang kumbinasyon ng serbisyo sa cloud at ilan sa aming mga bahagi ay nagbibigay sa amin ng pagkakataong buuin ang lahat ng nilalamang ito at ibigay ito sa harapan.
Nikolay: Mahalagang linawin dito na ang aming site ay hindi isang klasikong SPA application. Ito ay parehong nakabatay sa layout, na-render na website at isang SPA. Talagang nakikita ng Google ang site na ito bilang na-render na HTML. Ito ay mabuti para sa SEO at para sa paghahatid ng nilalaman sa gumagamit. Hindi nito hinihintay na mag-load ang 1,5 megabytes ng JavaScript bago makita ang pahina, agad nitong nakikita ang na-render na pahina, at nararamdaman mo ito sa tuwing lilipat ka ng ulat. Ang lahat ay nangyayari sa kalahating segundo, dahil ang nilalaman ay handa na at nai-post sa tamang lugar.
— Gumuhit tayo ng linya sa ilalim ng lahat ng nasa itaas sa pamamagitan ng paglilista ng mga teknolohiya. Sinabi ni Tyoma na mayroon kaming 5 stream ng Amazon, at naghahatid kami ng video at tunog doon. Mayroon kaming mga bash script doon, ginagamit namin ang mga ito upang ilunsad at i-configure...
Artyom: Nangyayari ito sa pamamagitan ng AWS API, marami pang teknikal na side services doon. Hinati namin ang aming mga responsibilidad upang ako ay maghatid sa , at kinukuha ito ng mga front-end at back-end na developer mula doon. Mayroon kaming ilang sariling mga binding upang pasimplehin ang layout ng nilalaman, na pagkatapos ay gagawin namin sa 4K, atbp. Dahil napakahigpit ng mga deadline, halos lahat ay ginawa namin sa AWS.
— Pagkatapos ang lahat ng ito ay mapupunta sa player gamit ang backend system. Mayroon kaming TypeScript, React, Next.JS sa aming player. At sa backend mayroon kaming ilang mga serbisyo sa C#, Java, Spring Boot at Node.js. Na-deploy lahat ito gamit ang Kubernetes gamit ang imprastraktura ng Yandex.Cloud.
Nais ko ring tandaan na kapag kailangan kong makilala ang platform, naging madali: lahat ng mga repositoryo ay nasa GitLab, lahat ay maayos na pinangalanan, nakasulat ang mga pagsubok, mayroong dokumentasyon. Ibig sabihin, kahit emergency mode, inalagaan nila ang mga ganoong bagay.
Mga Limitasyon sa Negosyo at Analytics
— Nag-target kami ng 10 user batay sa mga kinakailangan sa negosyo. Oras na para pag-usapan ang tungkol sa mga paghihigpit sa negosyo na mayroon kami. Kinailangan naming tiyakin ang mataas na workload, tiyakin ang pagsunod sa batas sa pangangalaga ng personal na data. At ano pa?
Nikolay: Sa una, nagsimula kami sa mga kinakailangan sa video. Ang pinakamahalagang bagay ay ipinamahagi ang imbakan ng video sa buong mundo para sa mabilis na paghahatid sa kliyente. Kasama sa iba ang 1080p na resolusyon, pati na rin ang pag-rewind, na hindi ipinapatupad ng marami pang iba sa live na mode. Sa paglaon, idinagdag namin ang kakayahang paganahin ang 2x na bilis, sa tulong nito maaari kang "makahabol" sa live at patuloy na panoorin ang kumperensya sa real time. At kasama ang paraan, lumitaw ang pag-andar ng pagmamarka ng timeline. Dagdag pa, kailangan naming maging fault-tolerant at makayanan ang pagkarga ng 10 koneksyon. Mula sa isang backend point of view, ito ay humigit-kumulang 000 koneksyon na pinarami ng 10 kahilingan para sa bawat pag-refresh ng pahina. At ito ay 000 RPS/sec. Medyo ng.
— Mayroon bang iba pang mga kinakailangan para sa isang "virtual na eksibisyon" na may mga online na stand ng mga kasosyo?
Nikolay: Oo, kailangan itong gawin nang mabilis at pangkalahatan. Mayroon kaming hanggang 10 kasosyong kumpanya para sa bawat kumperensya, at lahat ng mga ito ay kailangang makumpleto sa isang linggo o dalawa. Gayunpaman, ang kanilang nilalaman ay bahagyang naiiba sa format. Ngunit ang isang tiyak na template engine ay ginawa na nag-assemble ng mga pahinang ito sa mabilisang, na halos walang karagdagang paglahok sa pag-unlad.
— Mayroon ding mga kinakailangan para sa analytics ng mga real-time na view at istatistika. Alam kong ginagamit namin ang Prometheus para dito, ngunit sabihin sa amin nang mas detalyado: anong mga kinakailangan ang natutugunan namin para sa analytics, at paano ito ipinapatupad?
Nikolay: Sa una, mayroon kaming mga kinakailangan sa marketing para sa pagkolekta para sa pagsubok sa A/B at pagkolekta ng impormasyon upang maunawaan kung paano maayos na maihatid ang pinakamahusay na nilalaman sa kliyente sa hinaharap. Mayroon ding mga kinakailangan para sa ilang analytics sa mga aktibidad ng kasosyo at ang analytics na nakikita mo (bisitahin ang counter). Ang lahat ng impormasyon ay nakolekta sa real time.
Maaari naming ibigay ang impormasyong ito sa pinagsama-samang anyo kahit sa mga nagsasalita: kung gaano karaming tao ang nanonood sa iyo sa isang partikular na punto ng oras. Kasabay nito, upang sumunod sa Federal Law 152, ang iyong personal na account at personal na data ay hindi sinusubaybayan sa anumang paraan.
Ang platform ay mayroon nang mga tool sa marketing at ang aming mga sukatan para sa pagsukat ng aktibidad ng user sa real time (na nanood kung anong segundo ng ulat) upang makabuo ng mga graph ng pagdalo sa mga ulat. Batay sa datos na ito, ginagawa ang pananaliksik na magpapaganda sa mga susunod na kumperensya.
Panloloko
— Mayroon ba tayong mga mekanismo laban sa pandaraya?
Nikolay: Dahil sa masikip na time frame mula sa pananaw ng negosyo, ang gawain ay hindi paunang naitakda upang agad na harangan ang mga hindi kinakailangang koneksyon. Kung nag-log in ang dalawang user sa ilalim ng parehong account, maaari nilang tingnan ang nilalaman. Ngunit alam namin kung gaano karaming mga sabay-sabay na view mula sa isang account. At pinagbawalan namin ang ilang partikular na malisyosong lumalabag.
Vladimir: Sa kredito nito, naunawaan ng isa sa mga ipinagbabawal na user kung bakit ito nangyari. Dumating siya, humingi ng tawad at nangakong bibili ng ticket.
— Para mangyari ang lahat ng ito, dapat mong ganap na subaybayan ang lahat ng mga user mula sa pagpasok hanggang sa paglabas, palaging alam kung ano ang kanilang ginagawa. Paano gumagana ang sistemang ito?
Vladimir: Gusto kong pag-usapan ang tungkol sa analytics at mga istatistika, na pagkatapos ay sinusuri namin para sa tagumpay ng ulat o pagkatapos ay maaari naming ibigay sa mga kasosyo. Ang lahat ng mga kliyente ay konektado sa pamamagitan ng isang websocket na koneksyon sa isang partikular na backend cluster. Nakatayo ito doon . Ang bawat kliyente sa bawat yugto ng panahon ay nagpapadala kung ano ang kanyang ginagawa at kung anong track ang kanyang pinapanood. Pagkatapos ang impormasyong ito ay pinagsama-sama gamit ang mabilis na mga trabaho sa Hazelcast at ibinabalik sa lahat ng nanonood ng mga track na ito. Kita namin sa sulok kung gaano karaming tao ang kasama namin ngayon.
Ang parehong impormasyon ay naka-imbak sa at pumupunta sa aming data lake, kung saan mayroon kaming pagkakataong bumuo ng mas kawili-wiling graph. Ang tanong ay lumitaw: gaano karaming mga natatanging user ang tumingin sa ulat na ito? Pumunta kami sa , may mga ping ng lahat ng taong dumating sa pamamagitan ng id ng ulat na ito. Nakolekta namin, pinagsama-sama ang mga natatangi, at ngayon ay naiintindihan na namin.
Nikolay: Ngunit sa parehong oras, nakakatanggap din kami ng real-time na data mula sa Prometheus. Nakatakda ito laban sa lahat ng serbisyo ng Kubernetes, laban sa Kubernetes mismo. Kinokolekta nito ang lahat ng bagay, at sa Grafana maaari kaming bumuo ng anumang mga graph sa real time.
Vladimir: Sa isang banda, dina-download namin ito para sa karagdagang pagproseso ng OLAP. At para sa OLTP, dina-download ng application ang buong bagay sa Prometheus, Grafana at ang mga graph ay nagsalubong pa!
- Ito ang kaso kapag ang mga graph ay nagtatagpo.
Mga Dynamic na Pagbabago
— Sabihin sa amin kung paano inilunsad ang mga dynamic na pagbabago: kung kinansela ang ulat 6 na minuto bago magsimula, ano ang hanay ng mga aksyon? Aling pipeline ang gumagana?
Vladimir: Napaka conditional ng pipeline. Mayroong ilang mga posibilidad. Ang una ay ang programa ng pagbuo ng iskedyul ay nagtrabaho at binago ang iskedyul. Ang binagong iskedyul ay ina-upload sa Contentful. Pagkatapos nito, naiintindihan ng backend na may mga pagbabago para sa kumperensyang ito sa Contentful, kinukuha ito at muling itinayo. Ang lahat ay kinokolekta at ipinadala sa pamamagitan ng websocket.
Ang pangalawang posibilidad, kapag nangyari ang lahat sa mabilis na bilis: manu-manong binabago ng editor ang impormasyon sa Contentful (link sa Telegram, presentasyon ng tagapagsalita, atbp.) at gumagana ang parehong lohika tulad ng unang pagkakataon.
Nikolay: Nangyayari ang lahat nang hindi nire-refresh ang page. Ang lahat ng mga pagbabago ay nangyayari nang walang putol para sa kliyente. Ang parehong napupunta para sa paglipat ng mga ulat. Pagdating ng oras, nagbabago ang ulat at interface.
Vladimir: Gayundin, may mga cutoff sa oras para sa pagsisimula ng mga ulat sa timeline. Sa simula pa lang ay wala. At kung i-hover mo ang iyong mouse sa pulang guhit, sa isang punto, salamat sa direktor ng broadcast, lilitaw ang mga cutoff. Itinakda ng direktor ang tamang pagsisimula ng broadcast, kukunin ng backend ang pagbabagong ito, kinakalkula ang mga oras ng pagsisimula at pagtatapos ng mga presentasyon ng buong track alinsunod sa iskedyul ng kumperensya, ipinapadala ito sa aming mga kliyente, at ang player ay kumukuha ng mga cutoff. Ngayon ang user ay madaling mag-navigate sa simula at dulo ng ulat. Ito ay isang mahigpit na kinakailangan sa negosyo, napaka maginhawa at kapaki-pakinabang. Hindi ka mag-aaksaya ng oras sa paghahanap ng aktwal na oras ng pagsisimula para sa ulat. At kapag gumawa kami ng isang preview, ito ay ganap na kahanga-hanga.
Deployment
— Gusto kong magtanong tungkol sa deployment. Si Kolya at ang koponan ay gumugol ng maraming oras sa simula upang i-set up ang buong imprastraktura kung saan ang lahat ay nagbubukas para sa amin. Sabihin mo sa akin, ano ang gawa ng lahat ng ito?
Nikolay: Mula sa isang teknikal na punto ng view, kami sa una ay nagkaroon ng isang kinakailangan para sa produkto na maging abstract hangga't maaari mula sa anumang vendor. Pumunta sa AWS upang gumawa ng mga script ng Terraform na partikular mula sa AWS, o partikular mula sa Yandex, o mula sa Azure, atbp. hindi talaga kasya. Kinailangan naming lumipat sa isang lugar sa isang punto.
Sa unang tatlong linggo, patuloy kaming naghahanap ng paraan para gawin ito nang mas mahusay. Bilang resulta, napagpasyahan namin na ang Kubernetes sa kasong ito ay ang aming lahat, dahil nagbibigay-daan ito sa amin na lumikha ng mga awtomatikong pag-scale ng mga serbisyo, auto-rollout, at makuha ang halos lahat ng mga serbisyo sa labas ng kahon. Naturally, ang lahat ng mga serbisyo ay kailangang sanayin upang gumana sa Kubernetes, Docker, at ang koponan ay kailangang matuto din.
Mayroon kaming dalawang kumpol. Pagsubok at produksyon. Ang mga ito ay ganap na magkapareho sa mga tuntunin ng hardware at mga setting. Ipinapatupad namin ang imprastraktura bilang code. Awtomatikong inilalabas ang lahat ng serbisyo sa tatlong kapaligiran mula sa mga feature branch, master branch, test branch, at GitLab gamit ang isang awtomatikong pipeline. Ito ay pinakamataas na isinama sa GitLab, na pinakamaraming isinama sa Elastic, Prometheus.
Nagkakaroon kami ng pagkakataong mabilis (para sa backend sa loob ng 10 minuto, para sa frontend sa loob ng 5 minuto) maglunsad ng mga pagbabago sa anumang kapaligiran kasama ang lahat ng pagsubok, pagsasama, pagpapatakbo ng mga functional na pagsubok, mga pagsubok sa pagsasama sa kapaligiran, at pagsubok din gamit ang mga pagsubok sa pag-load sa isang pagsubok na kapaligiran na humigit-kumulang sa parehong bagay na gusto naming makuha sa produksyon.
Tungkol sa mga pagsubok
— Sinusubukan mo ang halos lahat, mahirap paniwalaan kung paano mo isinulat ang lahat. Maaari mo bang sabihin sa amin ang tungkol sa mga pagsubok sa backend: gaano kalaki ang saklaw ng lahat, anong mga pagsubok?
Vladimir: Dalawang uri ng pagsusulit ang naisulat. Ang una ay mga pagsubok sa bahagi. Lift level test ng buong spring application at base in . Isa itong pagsubok sa pinakamataas na antas ng mga sitwasyon ng negosyo. Hindi ko sinusubukan ang mga function. Sinusubukan lang namin ang ilang malalaking bagay. Halimbawa, sa mismong pagsubok, ang proseso ng pag-log in sa isang user ay ginagaya, ang kahilingan ng user para sa mga tiket sa kung saan siya maaaring pumunta, at isang kahilingan para sa access upang mapanood ang stream. Napakalinaw ng mga senaryo ng gumagamit.
Humigit-kumulang ang parehong bagay ay ipinatupad sa tinatawag na mga pagsubok sa pagsasama, na aktwal na tumatakbo sa kapaligiran. Sa katunayan, kapag ang susunod na deployment sa produksyon ay inilunsad, ang mga tunay na pangunahing senaryo ay tumatakbo din sa produksyon. Ang parehong pag-login, paghiling ng mga tiket, paghiling ng access sa CloudFront, pagsuri na ang stream ay talagang kumokonekta sa aking mga pahintulot, pagsuri sa interface ng direktor.
Sa ngayon, mayroon akong humigit-kumulang 70 mga pagsubok sa bahagi at humigit-kumulang 40 na mga pagsubok sa pagsasama-sama. Ang saklaw ay napakalapit sa 95%. Ito ay para sa mga bahagi, mas kaunti para sa mga pagsasama, sadyang hindi gaanong kailangan. Isinasaalang-alang na ang proyekto ay nagsasangkot ng lahat ng uri ng pagbuo ng code, ito ay isang napakahusay na tagapagpahiwatig. Walang ibang paraan para gawin ang ginawa namin sa loob ng tatlong buwan. Dahil kung manu-mano kaming sumubok, na nagbibigay ng mga feature sa aming tester, at makakahanap siya ng mga bug at ibabalik niya ang mga ito sa amin para sa mga pag-aayos, ang round trip na ito upang i-debug ang code ay magiging napakatagal, at hindi kami makakatugon sa anumang mga deadline.
Nikolay: Karaniwan, upang magsagawa ng regression sa buong platform kapag binabago ang ilang function, kailangan mong umupo at sundutin kahit saan sa loob ng dalawang araw.
Vladimir: Samakatuwid, ito ay isang mahusay na tagumpay na kapag tinantya ko ang isang tampok, sinasabi ko na kailangan ko ng 4 na araw para sa dalawang simpleng panulat at 1 websocket, pinapayagan ito ng Kolya. Nasanay na siya sa katotohanan na ang 4 na araw na ito ay may kasamang 2 uri ng mga pagsubok, at pagkatapos, malamang, gagana ito.
Nikolay: Mayroon din akong 140 na pagsusulit na nakasulat: component + functional, na ginagawa ang parehong bagay. Ang lahat ng parehong mga sitwasyon ay nasubok sa produksyon, sa pagsubok, at sa produksyon. Nagdagdag din kami kamakailan ng mga functional na pangunahing pagsubok sa UI. Sa ganitong paraan sinasaklaw namin ang pinakapangunahing functionality na maaaring masira.
Vladimir: Siyempre, sulit na pag-usapan ang tungkol sa mga pagsubok sa pagkarga. Kinakailangang subukan ang platform sa ilalim ng isang load na malapit sa tunay upang maunawaan kung paano ang lahat, kung ano ang nangyayari sa Rabbit, kung ano ang nangyayari sa mga JVM, kung gaano karaming memorya ang talagang kailangan.
— Hindi ko alam kung may sinusubok tayo sa stream side, pero natatandaan ko na nagkaroon ng mga problema sa mga transcoder noong nagkita kami. Nasubukan na ba natin ang mga stream?
Artyom: Sinubukan nang paulit-ulit. Pag-aayos ng mga meetup. Sa proseso ng pag-aayos ng mga pagkikita-kita, mayroong humigit-kumulang 2300 JIRA ticket. Mga generic na bagay lang ito na ginawa ng mga tao para makipagkita. Kinuha namin ang mga bahagi ng platform sa isang hiwalay na pahina para sa mga meetup, na pinamamahalaan ni Kirill Tolkachev ().
Sa totoo lang, walang malalaking problema. Literal na ilang beses kaming nakahuli ng mga pag-cache ng mga bug sa CloudFront, nalutas namin ito nang mabilis - na-configure lang namin ang mga patakaran. Mayroong higit pang mga bug sa mga tao, sa mga streaming system sa site.
Sa panahon ng mga kumperensya, kinailangan kong magsulat ng ilan pang mga exporter upang masakop ang mas maraming kagamitan at serbisyo. Sa ilang mga lugar kailangan kong gumawa ng sarili kong mga bisikleta para lamang sa mga sukatan. Ang mundo ng AV (audio-video) na hardware ay hindi masyadong malabo - mayroon kang ilang uri ng "API" ng kagamitan na hindi mo maimpluwensyahan. At malayo sa katotohanan na makukuha mo ang impormasyong kailangan mo. Ang mga vendor ng hardware ay talagang mabagal, at halos imposibleng makuha ang gusto mo mula sa kanila. Sa kabuuan mayroong higit sa 100 piraso ng hardware, hindi nila ibinabalik ang kailangan mo, at sumulat ka ng mga kakaiba at kalabisan na mga exporter, salamat sa kung saan maaari mong kahit papaano ay i-debug ang system.
Оборудование
— Naaalala ko kung paano bago magsimula ang mga kumperensya ay bahagyang bumili kami ng karagdagang kagamitan.
Artyom: Bumili kami ng mga computer, laptop, at battery pack. Sa ngayon maaari tayong mabuhay nang walang kuryente sa loob ng 40 minuto. Noong Hunyo, nagkaroon ng matinding bagyo sa St. Petersburg - kaya nagkaroon kami ng blackout. Kasabay nito, maraming provider ang pumupunta sa amin na may mga optical link mula sa iba't ibang punto. Ito ay talagang 40 minuto ng downtime ng gusali, kung saan magkakaroon tayo ng mga ilaw, tunog, mga camera, atbp. na gumagana.
— Mayroon kaming katulad na kuwento sa Internet. Sa opisina kung saan matatagpuan ang aming mga studio, kinaladkad namin ang isang mabangis na lambat sa pagitan ng mga sahig.
Artyom: Mayroon kaming 20 Gbit ng fiber sa pagitan ng mga sahig. Sa kahabaan ng mga sahig, sa isang lugar na may optika, sa isang lugar na walang optika, ngunit mayroon pa ring mas kaunting mga channel kaysa sa gigabit - nagpapatakbo kami ng video sa mga ito sa pagitan ng mga track ng kumperensya. Sa pangkalahatan, napaka-maginhawang magtrabaho sa sarili mong imprastraktura; bihira mong magawa ito sa mga offline na kumperensya sa mga site.
— Bago ako magtrabaho sa JUG Ru Group, nakita ko kung paano na-set up ang mga hardware room sa mga offline na kumperensya nang magdamag, kung saan mayroong malaking monitor kasama ang lahat ng sukatan na iyong binuo sa Grafana. Ngayon ay mayroon ding isang silid ng punong-tanggapan kung saan nakaupo ang pangkat ng pag-unlad, na sa panahon ng kumperensya ay nag-aayos ng ilang mga bug at bumubuo ng mga tampok. Kasabay nito, mayroong isang sistema ng pagsubaybay na ipinapakita sa isang malaking screen. Si Artyom, Kolya at iba pang mga lalaki ay nakaupo at siguraduhin na ang lahat ay hindi mahuhulog at gumagana nang maganda.
Mga kuryusidad at problema
— Nagsalita ka nang maayos tungkol sa katotohanan na mayroon kaming streaming sa Amazon, mayroong isang manlalaro na may web, lahat ay nakasulat sa iba't ibang mga programming language, ibinibigay ang fault tolerance at iba pang mga kinakailangan sa negosyo, kabilang ang isang personal na account na suportado para sa mga legal na entity at mga indibidwal, at maaari tayong isama sa isang tao na gumagamit ng OAuth 2.0, mayroong anti-fraud, pagharang ng user. Maaari naming ilunsad ang mga pagbabago sa dynamic na paraan dahil nagawa namin ito nang maayos, at lahat ng ito ay nasubok.
Interesado akong malaman kung ano ang mga kakaibang kasangkot sa pagsisimula ng isang bagay. Nagkaroon ba ng anumang kakaibang sitwasyon noong nagde-develop ka ng backend, frontend, may nangyaring kabaliwan at hindi mo naiintindihan kung ano ang gagawin dito?
Vladimir: Para sa akin, ito ay nangyari lamang sa huling tatlong buwan. Araw-araw. As you can see, nabunot lahat ng buhok ko.
Vladimir Krasilshchik pagkatapos ng 3 buwan, nang may ilang uri ng laro at walang nakakaintindi kung ano ang gagawin dito
Araw-araw ay may ganito, kapag may ganoong sandali na kinuha mo ito at pinunit ang iyong buhok, o napagtanto na walang iba, at ikaw lamang ang makakagawa nito. Ang aming unang malaking kaganapan ay ang TechTrain. Noong Hunyo 6 sa 2 a.m. hindi pa namin inilunsad ang kapaligiran ng produksyon, inilunsad ito ni Kolya. At hindi gumana ang personal na account bilang server ng pahintulot gamit ang OAuth2.0. Ginawa namin itong OAuth2.0 provider para ikonekta ang platform dito. Malamang na 18 oras akong nagtatrabaho, tumingin ako sa computer at wala akong nakita, hindi ko maintindihan kung bakit hindi ito gumagana, at tiningnan ni Kolya ang aking code nang malayuan, naghanap ng bug sa configuration ng Spring , natagpuan ito, at ang LC ay nagtrabaho, at sa produksyon din.
Nikolay: At isang oras bago naganap ang paglabas ng TechTrain.
Maraming bituin ang nakahanay dito. Napakaswerte namin dahil nagkaroon kami ng super team, at lahat ay na-inspire sa ideyang gawin ito online. Sa lahat ng tatlong buwang ito, hinimok kami ng katotohanang "ginawa namin ang YouTube." Hindi ko pinahintulutan ang aking sarili na mapunit ang aking buhok, ngunit sinabi sa lahat na ang lahat ay gagana, dahil sa katunayan, ang lahat ay kinakalkula na matagal na ang nakalipas.
Tungkol sa performance
— Maaari mo bang sabihin sa akin kung ilang tao ang nasa site sa isang track? Mayroon bang anumang mga isyu sa pagganap?
Nikolay: Walang mga problema sa pagganap, gaya ng nasabi na namin. Ang maximum na bilang ng mga taong dumalo sa isang ulat ay 1300 tao, ito ay sa Heisenbug.
— Mayroon bang anumang mga problema sa lokal na panonood? At posible bang magkaroon ng teknikal na paglalarawan na may mga diagram kung paano gumagana ang lahat?
Nikolay: Gagawa tayo ng artikulo tungkol dito mamaya.
Maaari mo ring i-debug ang mga stream nang lokal. Sa sandaling nagsimula ang mga kumperensya, naging mas madali ito, dahil lumitaw ang mga stream ng produksyon na maaari nating panoorin sa lahat ng oras.
Vladimir: Tulad ng naiintindihan ko, ang mga front-end na developer ay nagtrabaho nang lokal sa mga pangungutya, at pagkatapos, dahil ang oras upang ilunsad sa mga dev sa harap ay maikli din (5 minuto), walang mga problema sa pagsuri kung ano ang nangyayari sa mga sertipiko.
— Lahat ay nasubok at na-debug, kahit lokal. Nangangahulugan ito na magsusulat kami ng isang artikulo na may lahat ng mga teknikal na tampok, ipapakita sa iyo, sasabihin sa iyo ang lahat gamit ang mga diagram, kung paano ito.
Vladimir: Maaari mo itong kunin at ulitin.
- Sa 3 buwan.
Kabuuan
— Lahat ng inilarawan nang magkasama ay mukhang cool, kung isasaalang-alang na ito ay ginawa ng isang maliit na koponan sa loob ng tatlong buwan.
Nikolay: Hindi ito gagawin ng isang malaking koponan. Ngunit ang isang maliit na grupo ng mga tao na medyo malapit at maayos na nakikipag-usap sa isa't isa at maaaring magkaroon ng isang kasunduan ay maaaring. Wala silang anumang mga kontradiksyon, ang arkitektura ay naimbento sa loob ng dalawang araw, natapos at hindi talaga nagbago. Mayroong napakahigpit na pagpapadali sa mga papasok na kinakailangan sa negosyo sa mga tuntunin ng pagtatambak ng mga kahilingan sa tampok at pagbabago.
— Ano ang nasa iyong listahan ng mga karagdagang gawain noong naganap na ang mga kumperensya sa tag-init?
Nikolay: Halimbawa, mga kredito. Gumagapang na mga linya sa video, mga pop-up sa ilang lugar sa video depende sa content na ipinapakita. Halimbawa, ang tagapagsalita ay gustong magtanong sa madla, at isang boto ang lumalabas sa screen, na babalik sa likod batay sa mga resulta ng pagboto sa mismong tagapagsalita. Ilang uri ng panlipunang aktibidad sa anyo ng mga gusto, puso, mga rating ng ulat sa panahon ng mismong pagtatanghal, upang mapunan mo ang feedback sa tamang sandali nang hindi naabala sa ibang pagkakataon ng mga form ng feedback. Sa simula ganito.
At pagdaragdag din sa buong platform, maliban sa streaming at conference, isang post-conference state din. Ito ay mga playlist (kabilang ang mga pinagsama-sama ng mga gumagamit), posibleng nilalaman mula sa iba pang mga nakaraang kumperensya, pinagsama, may label, naa-access ng gumagamit, at magagamit din para sa pagtingin sa aming website ().
— Guys, maraming salamat sa inyong mga sagot!
Kung sa mga mambabasa ay may mga dumalo sa aming mga kumperensya sa tag-init, mangyaring ibahagi ang iyong mga impression sa player at broadcast. Ano ang maginhawa, ano ang ikinairita mo, ano ang gusto mong makita sa hinaharap?
Kung interesado ka sa platform at gusto mong makita ito "sa labanan", muli namin itong ginagamit sa aming . Mayroong isang buong hanay ng mga ito, kaya halos tiyak na isa ang tama para sa iyo.
Pinagmulan: www.habr.com