Энэ хавар бид маш хөгжилтэй нөхцөлд орлоо. Цар тахлын улмаас манай зуны чуулганыг онлайн болгох шаардлагатай болсон нь тодорхой болсон. Тэдгээрийг онлайнаар үр дүнтэй явуулахын тулд бэлэн програм хангамжийн шийдлүүд бидэнд тохирохгүй байсан тул бид өөрсдөө бичих хэрэгтэй болсон. Бид үүнийг хийхэд гурван сарын хугацаа байсан.
Сэтгэл хөдөлгөм гурван сар байсан нь ойлгомжтой. Гэхдээ гаднаас нь харахад энэ нь тодорхойгүй байна: онлайн хурлын платформ гэж юу вэ? Энэ нь ямар хэсгүүдээс бүрддэг вэ? Тиймээс, зуны сүүлчийн DevOops чуулган дээр би энэ ажлыг хариуцаж байсан хүмүүсээс асуув.
- Николай Молчанов - JUG Ru группын техникийн захирал;
- Владимир Красильщик бол арын программ дээр ажилладаг прагматик Java програмист (та түүний илтгэлүүдийг манай Java чуулгануудаас үзэх боломжтой);
- Артём Никонов манай бүх видео дамжуулалтыг хариуцдаг.
Дашрамд хэлэхэд, намар-өвлийн чуулган дээр бид ижил платформын сайжруулсан хувилбарыг ашиглах болно - маш олон хабра уншигчид түүний хэрэглэгчид хэвээр байх болно.
Том зураг
-Багийн бүрэлдэхүүн ямар байсан бэ?
Николай Молчанов: Бид шинжээч, дизайнер, шалгагч, гурван урд, арын хэсэгтэй. Мэдээжийн хэрэг, Т хэлбэрийн мэргэжилтэн!
-Ер нь энэ үйл явц ямар байсан бэ?
Николас: Гуравдугаар сарын дунд үе хүртэл бид онлайнаар ажиллахад бэлэн юу ч байгаагүй. Гуравдугаар сарын 15-нд онлайн тойруулга бүхэлдээ эргэлдэж эхлэв. Бид хэд хэдэн репозитор байгуулж, төлөвлөж, үндсэн архитектурыг хэлэлцэж, гурван сарын дотор бүгдийг хийсэн.
Энэ нь мэдээж төлөвлөлт, архитектур, онцлогийг сонгох, тэдгээр шинж чанаруудын төлөө санал өгөх, тэдгээр шинж чанаруудын бодлого, дизайн, боловсруулалт, туршилтын сонгодог үе шатуудыг дамжсан. Үүний үр дүнд 6-р сарын XNUMX-нд бид бүх зүйлийг үйлдвэрлэлд нэвтрүүлсэн. . Бүх зүйлд 90 хоног байсан.
-Бид амласан зүйлээ биелүүлж чадсан уу?
Николас: Бид одоо DevOops бага хуралд онлайнаар оролцож байгаа тул энэ нь амжилттай болсон гэсэн үг. Би хувьдаа гол зүйлээ амласан: Би үйлчлүүлэгчдэдээ онлайн хурал хийх хэрэгсэл авчрах болно.
Асуудлын гол нь бидэнд бага хурлаа тасалбар эзэмшигчдэд дамжуулах хэрэгсэл өгөх явдал байв.
Бүх төлөвлөлтийг хэд хэдэн үе шатанд хувааж, бүх шинж чанарыг (30 орчим дэлхийн) 4 ангилалд хуваасан.
- Бид үүнийг хийх нь гарцаагүй (бид тэдэнгүйгээр амьдарч чадахгүй),
- Үүнийг бид хоёрдугаарт хийх болно
- Бид хэзээ ч хийхгүй,
- мөн үүнийг бид хэзээ ч, хэзээ ч хийхгүй.
Бид эхний хоёр ангиллын бүх функцийг хийсэн.
- Нийтдээ 600 гаруй JIRA асуудал үүсгэгдсэн гэдгийг би мэднэ. Гурван сарын хугацаанд та 13 микро үйлчилгээ хийсэн бөгөөд тэдгээрийг зөвхөн Java хэл дээр бичээгүй гэж би сэжиглэж байна. Та өөр өөр технологи ашигласан, танд гурван боломжит бүсэд хоёр Kubernetes кластер, Amazon-д 5 RTMP урсгал байна.
Одоо системийн бүрэлдэхүүн хэсэг бүрийг тусад нь авч үзье.
Дамжуулж байна
— Бидэнд аль хэдийн видео зураг байгаа бөгөөд энэ нь зарим үйлчилгээнд дамждаг үеэс эхэлцгээе. Артём, энэ дамжуулалт хэрхэн явагддагийг бидэнд хэлээч?
Артём Никонов: Манай ерөнхий схем иймэрхүү харагдаж байна: камерын зураг -> манай хяналтын өрөө -> дотоод RTMP сервер -> Amazon -> видео тоглуулагч. Илүү дэлгэрэнгүй мэдээллийг зургадугаар сард Habré дээр.
Ерөнхийдөө үүнийг хийх дэлхийн хоёр арга байдаг: техник хангамж дээр эсвэл програм хангамжийн шийдэл дээр суурилсан. Алсын чанга яригчийн хувьд энэ нь илүү хялбар байдаг тул бид програм хангамжийн замыг сонгосон. Өөр улсын чанга яригч руу техник хангамж авчрах нь үргэлж боломжгүй байдаг ч програм хангамжийг чанга яригч руу хүргэх нь илүү хялбар бөгөөд найдвартай мэт санагддаг.
Техник хангамжийн үүднээс авч үзвэл бидэнд тодорхой тооны камер (манай студи болон алсын чанга яригч), студид тодорхой тооны алсын удирдлага байдаг бөгөөд заримдаа нэвтрүүлгийн үеэр шууд ширээний доор засвар хийх шаардлагатай болдог.
Эдгээр төхөөрөмжүүдийн дохио нь бичлэг хийх карт, оролт/гаралтын карт, дууны карт бүхий компьютерт ордог. Тэнд дохионуудыг хольж, зохион байгуулалтад угсардаг.
4 чанга яригчийн зохион байгуулалтын жишээ
4 чанга яригчийн зохион байгуулалтын жишээ
Цаашилбал, тасралтгүй өргөн нэвтрүүлгийг гурван компьютерийн тусламжтайгаар хангадаг: нэг үндсэн машин, ээлжлэн ажилладаг хос машин байдаг. Эхний компьютер эхний тайланг, хоёр дахь нь - завсарлага, эхний - дараагийн тайлан, хоёр дахь - дараагийн завсарлага гэх мэтийг цуглуулдаг. Мөн үндсэн машин нь эхнийх нь хоёр дахь нь холилддог.
Энэ нь нэг төрлийн гурвалжин үүсгэдэг бөгөөд хэрэв эдгээр зангилааны аль нэг нь бүтэлгүйтвэл бид хурдан бөгөөд чанараа алдалгүйгээр контентыг үйлчлүүлэгчдэд хүргэх болно. Бидэнд ийм нөхцөл байдал байсан. Чуулганы эхний долоо хоногт бид нэг машиныг засч, асааж, унтраасан. Хүмүүс бидний тэсвэр хатуужилд сэтгэл хангалуун байх шиг байна.
Дараа нь компьютерийн урсгалууд нь RTMP урсгалыг чиглүүлэх, нөөцлөлт хийх гэсэн хоёр үүрэг бүхий локал сервер рүү очдог. Тиймээс бидэнд олон бичлэг хийх цэг бий. Дараа нь видео урсгалыг Amazon SaaS үйлчилгээн дээр суурилуулсан манай системийн хэсэг рүү илгээдэг. Бидний хэрэглэдэг ,S3, CloudFront.
Николас: Видео үзэгчдэд хүрэхээс өмнө тэнд юу болдог вэ? Та ямар нэгэн байдлаар таслах хэрэгтэй, тийм үү?
Артём: Бид өөрсдийн зүгээс видеог шахаж MediaLive руу илгээдэг. Бид тэнд хөрвүүлэгч төхөөрөмж ажиллуулдаг. Тэд видеог бодит цаг хугацаанд хэд хэдэн нарийвчлалтайгаар хөрвүүлдэг бөгөөд ингэснээр хүмүүс утсаараа, тухайн улсын интернет муу гэх мэтээр үзэх боломжтой. Дараа нь эдгээр урсгалыг зүснэ , протокол ингэж ажилладаг . Бид эдгээр хэсгүүдэд заагч агуулсан тоглуулах жагсаалтыг урд хэсэгт илгээдэг.
- Бид 1080p нягтрал ашиглаж байна уу?
Артём: Манай видеоны өргөн нь 1080p - 1920 пикселтэй ижил, өндөр нь арай бага, зураг нь илүү сунасан - үүнд шалтгаан бий.
Тоглогч
— Артём видео хэрхэн цацагдаж, янз бүрийн дэлгэцийн нягтралтай өөр өөр тоглуулах жагсаалтад хэрхэн хуваарилагдаж, хэсэг хэсгээрээ хуваагдаж, тоглуулагч руу ордог талаар тайлбарлав. Коля, одоо надад хэлээч энэ нь ямар төрлийн тоглогч вэ, энэ нь урсгалыг хэрхэн зарцуулдаг, яагаад HLS?
Николас: Бүх хурлын үзэгчид үзэх боломжтой тоглогч бидэнд бий.
Үндсэндээ энэ бол номын сангийн эргэн тойронд байгаа боодол юм , үүн дээр бусад олон тоглогч бичигдсэн байдаг. Гэхдээ бидэнд маш тодорхой функц хэрэгтэй байсан: тухайн хүний хаана байгаа, ямар тайланг үзэж байгаа зэргийг эргүүлж, тэмдэглэх. Бидэнд өөрсдийн гэсэн зураг төсөл, бүх төрлийн лого болон бусад бүх зүйл хэрэгтэй байсан. Тиймээс бид өөрсдийн номын сан (HLS дээр боодол) бичиж, сайтад оруулахаар шийдсэн.
Энэ бол үндсэн функц учраас бараг анх хэрэгжсэн. Тэгээд түүний эргэн тойронд бүх зүйл ургасан.
Үнэн хэрэгтээ зөвшөөрөл авснаар тоглогч арын хэсгээс цаг хугацаа, чанартай холбоотой хэсгүүдийн холбоос бүхий тоглуулах жагсаалтыг хүлээн авч, шаардлагатайг нь татаж аваад хэрэглэгчдэд үзүүлж, замдаа "ид шид" хийдэг.
Цаг хугацааны жишээ
- Бүх тайлангийн цагийн хуваарийг харуулах товчлуурыг тоглуулагчид шууд суулгасан болно...
Николас: Тийм ээ, бид хэрэглэгчийн навигацийн асуудлыг нэн даруй шийдсэн. Дөрөвдүгээр сарын дундуур бид хурал болгоныг тусдаа вэб сайтаар дамжуулахгүй, бүгдийг нэг дор нэгтгэхээр шийдсэн. Ингэснээр Full Pass тасалбар хэрэглэгчид өөр өөр хурлын хооронд чөлөөтэй шилжих боломжтой: шууд дамжуулалт болон өмнөх хурлын бичлэгүүд.
Хэрэглэгчдэд одоогийн урсгалыг чиглүүлэх, замуудын хооронд шилжихэд хялбар болгохын тулд бид "Бүтэн нэвтрүүлэг" товчлуур болон зам, тайлангийн хооронд шилжих хэвтээ тайлангийн карт хийхээр шийдсэн. Гарын удирдлага байдаг.
-Үүнд техникийн хүндрэл гарсан уу?
Николас: Тэд өөр өөр тайлангийн эхлэлийн цэгүүдийг тэмдэглэсэн гүйлгэх самбартай байв.
- Эцэст нь, YouTube үүнтэй төстэй зүйл хийхээс өмнө та эдгээр тэмдгийг гүйлгэх самбар дээр хэрэгжүүлсэн үү?
Артём: Тэд тэр үед бета хувилбартай байсан. Өнгөрсөн нэг жилийн хугацаанд хэрэглэгчид үүнийг хэсэгчлэн туршиж үзсэн тул энэ нь нэлээд төвөгтэй функц юм шиг санагдаж байна. Тэгээд одоо худалдаанд гарсан.
Николас: Гэхдээ бид үүнийг илүү хурдан борлуулах боломжтой болсон. Үнэнийг хэлэхэд, энэ энгийн функцын ард тоглуулагчийн дотор асар их хэмжээний арын хэсэг, урд хэсэг, тооцоолол, математик байдаг.
Frontend
— Бидний үзүүлж буй энэ контент (ярианы карт, чанга яригч, вэбсайт, хуваарь) хэрхэн нүүрэнд хүрч байгааг олж мэдье?
Владимир Красильщик: Бид хэд хэдэн дотоод мэдээллийн технологийн системтэй. Бүх тайлан, бүх илтгэгчийг оруулдаг систем байдаг. Чуулганд илтгэгч оролцдог процесс байдаг. Илтгэгч өргөдөл гаргаж, систем нь түүнийг барьж аваад дараа нь тайланг үүсгэдэг тодорхой шугам хоолой байдаг.
Илтгэгч нь дамжуулах хоолойг ингэж хардаг
Энэ тогтолцоо бол бидний дотоод хөгжил.
Дараа нь та хувийн тайлангаас хуваарь гаргах хэрэгтэй. Таны мэдэж байгаагаар энэ бол NP-д хэцүү асуудал боловч бид үүнийг ямар нэгэн байдлаар шийддэг. Үүнийг хийхийн тулд бид хуваарь гаргаж, гуравдагч этгээдийн Contentful үүлэн үйлчилгээнд байршуулдаг өөр бүрэлдэхүүн хэсгийг ажиллуулж байна. Тэнд бүх зүйл нь хурлын өдрүүд, өдрүүдэд цаг зав, завсарлагаануудад тайлан, завсарлага эсвэл ивээн тэтгэх үйл ажиллагаа байдаг ширээ шиг харагдаж байна. Тиймээс бидний харж буй контент нь гуравдагч талын үйлчилгээнд байрладаг. Мөн даалгавар бол үүнийг сайтад хүргэх явдал юм.
Энэ сайт нь зүгээр л тоглогчтой хуудас юм шиг санагдаж байна, энд ямар ч төвөгтэй зүйл байхгүй. Түүнээс биш тийм биш. Энэ хуудасны ард байгаа арын хэсэг нь Contentful руу очиж, тэндээс хуваарийг авч, зарим объектыг үүсгэж, үүнийг frontend руу илгээдэг. Манай платформын үйлчлүүлэгч бүрийн хийдэг вэбсокет холболтыг ашиглан бид түүнд хуваарийн шинэчлэлтийг backend-ээс frontend руу илгээдэг.
Бодит тохиолдол: илтгэгч чуулганы үеэр шууд ажлаа сольсон. Бид түүний ажил олгогч компанийн тэмдгийг өөрчлөх хэрэгтэй. Энэ нь арын хэсгээс хэрхэн тохиолддог вэ? Шинэчлэлтийг вэбсокетоор дамжуулан бүх үйлчлүүлэгчид илгээдэг бөгөөд дараа нь урд хэсэг нь цаг хугацааны шугамыг дахин зурдаг. Энэ бүхэн саадгүй явагддаг. Үүл үйлчилгээ болон манай хэд хэдэн бүрэлдэхүүн хэсгүүдийн хослол нь бидэнд энэ бүх агуулгыг бий болгож, үүнийг урд нь өгөх боломжийг олгодог.
Николас: Манай сайт сонгодог SPA програм биш гэдгийг энд тодруулах нь чухал юм. Энэ нь зохион байгуулалтад суурилсан, рэндэрлэсэн вэбсайт ба SPA юм. Google үнэндээ энэ сайтыг HTML-ээр дүрсэлсэн гэж үздэг. Энэ нь SEO болон хэрэглэгчдэд контент хүргэхэд тохиромжтой. Энэ нь хуудсыг харахын өмнө 1,5 мегабайт JavaScript ачаалагдахыг хүлээхгүй бөгөөд аль хэдийн үзүүлсэн хуудсыг шууд хардаг бөгөөд та тайланг солих бүрт үүнийг мэдэрдэг. Агуулга аль хэдийн бэлэн болж, зөв газартаа байрлуулсан тул бүх зүйл хагас секундын дотор болдог.
- Технологийг жагсаан дээрх бүх зүйлийн доор шугам татъя. Тиома хэлэхдээ, бидэнд 5 Amazon урсгал байдаг бөгөөд бид тэнд видео, дууг хүргэдэг. Бидэнд bash скриптүүд байгаа бөгөөд тэдгээрийг эхлүүлэх, тохируулахад ашигладаг ...
Артём: Энэ нь AWS API-ээр дамждаг тул өөр олон техникийн үйлчилгээ байдаг. Бид үүрэг хариуцлагаа хуваасан бөгөөд ингэснээр би түүнд хүргэх болно , мөн урд болон хойд талын хөгжүүлэгчид үүнийг тэндээс авдаг. Бид агуулгын зохион байгуулалтыг хялбарчлахын тулд хэд хэдэн өөрийн холбоосуудтай бөгөөд дараа нь 4K гэх мэтээр хийдэг. Хугацаа маш хатуу байсан тул бид үүнийг бараг бүхэлд нь AWS дээр хийсэн.
— Дараа нь энэ бүхэн арын систем ашиглан тоглуулагч руу ордог. Манай тоглуулагчид TypeScript, React, Next.JS байдаг. Мөн арын хэсэгт бид C#, Java, Spring Boot болон Node.js хэл дээр хэд хэдэн үйлчилгээтэй. Энэ бүгдийг Yandex.Cloud дэд бүтцийг ашиглан Kubernetes ашиглан байрлуулдаг.
Би платформтой танилцах шаардлагатай үед энэ нь хялбар болсон гэдгийг тэмдэглэхийг хүсч байна: бүх репозиторууд GitLab дээр байгаа, бүх зүйл сайн нэртэй, тестүүд бичигдсэн, баримт бичиг байдаг. Өөрөөр хэлбэл, онцгой байдлын үед ч гэсэн тэд ийм зүйлд санаа тавьдаг байсан.
Бизнесийн хязгаарлалт ба аналитик
— Бид бизнесийн шаардлагад тулгуурлан 10 хэрэглэгчдэд чиглэсэн. Бидэнд байсан бизнесийн хязгаарлалтын талаар ярих цаг болжээ. Бид ажлын өндөр ачаалал, хувийн мэдээллийг хадгалах тухай хуулийн хэрэгжилтийг хангах ёстой байсан. Тэгээд өөр юу?
Николас: Эхлээд бид видеоны шаардлагаас эхэлсэн. Хамгийн чухал зүйл бол үйлчлүүлэгчид хурдан хүргэхийн тулд дэлхий даяар тархсан видео хадгалах сан юм. Бусад нь 1080p нягтралтай, мөн бусад олон хүмүүс шууд горимд хэрэгжүүлдэггүй ухрах боломжтой. Хожим нь бид 2 дахин хурдыг идэвхжүүлэх боломжийг нэмсэн бөгөөд үүний тусламжтайгаар та шууд дамжуулалтыг "хөхөж", чуулганыг бодит цаг хугацаанд үргэлжлүүлэн үзэх боломжтой. Замдаа он цагийн хэлхээсийг тэмдэглэх функц гарч ирэв. Дээрээс нь бид алдаатай байж, 10 холболтын ачааллыг тэсвэрлэх ёстой байсан. Арын талын үүднээс авч үзвэл энэ нь хуудсыг шинэчлэх бүрт 000 хүсэлтээр үржүүлсэн 10 орчим холболт юм. Энэ нь аль хэдийн 000 RPS / сек байна. Бага зэрэг.
— Түншүүдийн онлайн стенд бүхий “виртуал үзэсгэлэн”-д өөр шаардлага тавьсан уу?
Николас: Тийм ээ, үүнийг маш хурдан бөгөөд бүх нийтээр хийх ёстой байсан. Бид хурал болгонд 10 хүртэл түншлэгч компанитай байсан бөгөөд бүгдийг нь нэг юмуу хоёр долоо хоногийн дотор дуусгах ёстой байв. Гэсэн хэдий ч тэдгээрийн агуулга нь форматын хувьд бага зэрэг ялгаатай. Гэхдээ эдгээр хуудсыг шууд угсардаг тодорхой загвар хөдөлгүүр хийгдсэн бөгөөд цаашид боловсруулахад бараг оролцоогүй болно.
- Бодит цагийн үзэл бодол, статистикийн дүн шинжилгээ хийх шаардлага бас байсан. Үүний тулд бид Prometheus-ийг ашигладаг гэдгийг би мэднэ, гэхдээ илүү дэлгэрэнгүй хэлээрэй: аналитикийн хувьд бид ямар шаардлагыг хангадаг вэ, үүнийг хэрхэн хэрэгжүүлдэг вэ?
Николас: Ирээдүйд хамгийн сайн контентыг үйлчлүүлэгчид хэрхэн зөв хүргэх талаар ойлгохын тулд бид эхлээд A/B тест хийх, мэдээлэл цуглуулах маркетингийн шаардлагуудыг тавьдаг. Түншийн үйл ажиллагааны талаархи зарим дүн шинжилгээ болон таны харж буй аналитикт тавигдах шаардлага бас бий. Бүх мэдээллийг бодит цаг хугацаанд цуглуулдаг.
Бид энэ мэдээллийг нэгтгэсэн хэлбэрээр илтгэгчид хүртэл өгч чадна: тодорхой цагт таныг хичнээн хүн харж байсан бэ. Үүний зэрэгцээ, Холбооны хуулийн 152-ыг дагаж мөрдөхийн тулд таны хувийн данс болон хувийн мэдээллийг ямар ч байдлаар хянахгүй.
Энэхүү платформ нь маркетингийн хэрэгслүүд болон хэрэглэгчийн үйл ажиллагааг бодит цаг хугацаанд (танилангийн хэдэн секундыг хэн үзсэн) хэмжих хэмжигдэхүүнтэй болсон байна. Энэ мэдээлэлд үндэслэн дараагийн чуулгануудыг илүү сайн болгох судалгаа хийж байна.
Луйвар
-Манайд залилангийн эсрэг механизм бий юу?
Николас: Бизнесийн үүднээс цаг хугацааны хувьд давчуу байсан тул шаардлагагүй холболтыг шууд хаах даалгавар өгөөгүй. Хэрэв хоёр хэрэглэгч нэг бүртгэлээр нэвтэрсэн бол контентыг үзэх боломжтой. Гэхдээ нэг данснаас хэдэн удаа нэгэн зэрэг үзсэнийг бид мэднэ. Мөн бид хэд хэдэн онцгой хорлонтой зөрчигчдийг хориглосон.
Владимир: Хориглосон хэрэглэгчдийн нэг нь яагаад ийм зүйл болсныг ойлгосон. Ирээд уучлалт гуйгаад тасалбар авна гэж амласан.
— Энэ бүхэн тохиолдохын тулд та бүх хэрэглэгчдийг орохоос гарах хүртэлх хугацаанд бүрэн хянах, юу хийж байгааг нь үргэлж мэдэж байх ёстой. Энэ систем хэрхэн ажилладаг вэ?
Владимир: Бид тайлангийн амжилтад дүн шинжилгээ хийх эсвэл түншүүдэд өгөх боломжтой аналитик, статистикийн талаар ярихыг хүсч байна. Бүх үйлчлүүлэгчид тодорхой backend кластерт вэбсокет холболтоор холбогддог. Тэнд зогсож байна . Үйлчлүүлэгч бүр цаг тутамд юу хийж байгаагаа, ямар замаа үзэж байгаагаа илгээдэг. Дараа нь энэ мэдээллийг хурдан Hazelcast ажлуудыг ашиглан нэгтгэж, эдгээр дууг үзэж буй бүх хүмүүст буцааж илгээдэг. Одоо бидэнтэй хэдэн хүн байгааг бид булангаас харж байна.
Үүнтэй ижил мэдээлэл хадгалагдана мөн манай өгөгдлийн нуур руу очдог бөгөөд үүнээс илүү сонирхолтой график бүтээх боломжтой. Асуулт гарч ирнэ: энэ тайланг хичнээн өвөрмөц хэрэглэгчид үзсэн бэ? Бид очдог , энэ тайлангийн id-ээр ирсэн бүх хүмүүсийн пинг байдаг. Бид өвөрмөц зүйлсийг цуглуулж, нэгтгэсэн, одоо бид ойлгох болно.
Николас: Гэхдээ үүнтэй зэрэгцэн бид Прометейгээс бодит цагийн мэдээллийг хүлээн авдаг. Энэ нь Kubernetes-ийн бүх үйлчилгээнүүдийн эсрэг, Kubernetes-ийн эсрэг хийгдсэн. Энэ нь үнэхээр бүх зүйлийг цуглуулдаг бөгөөд Grafana-ийн тусламжтайгаар бид ямар ч графикийг бодит цаг хугацаанд бүтээх боломжтой.
Владимир: Нэг талаас бид үүнийг OLAP боловсруулалтанд зориулж татаж авдаг. Мөн OLTP-ийн хувьд програм нь Prometheus, Grafana руу бүх зүйлийг татаж авдаг бөгөөд графикууд нь бүр нэгддэг!
- Графикууд нийлэх үед ийм байдаг.
Динамик өөрчлөлтүүд
- Динамик өөрчлөлтүүд хэрхэн явагдаж байгааг хэлээч: хэрэв тайлан эхлэхээс 6 минутын өмнө цуцалсан бол үйл ажиллагааны гинжин хэлхээ юу вэ? Аль шугам хоолой ажилладаг вэ?
Владимир: Дамжуулах хоолой нь маш нөхцөлтэй байдаг. Хэд хэдэн боломж бий. Эхнийх нь хуваарь үүсгэх хөтөлбөр ажиллаж, хуваарийг өөрчилсөн. Өөрчлөгдсөн хуваарийг Contentful-д байршуулсан. Үүний дараа арын хэсэг нь Contentful-д энэ хуралд өөрчлөлт орсон гэдгийг ойлгож, үүнийг авч, дахин бүтээдэг. Бүгдийг цуглуулж, вэбсокетээр илгээдэг.
Хоёрдахь боломж, бүх зүйл хурдацтай явагдах үед: редактор нь Contentful дахь мэдээллийг гараар өөрчилдөг (Telegram-ийн холбоос, илтгэгчийн танилцуулга гэх мэт) бөгөөд эхнийхтэй ижил логик ажилладаг.
Николас: Хуудсыг шинэчлэхгүйгээр бүх зүйл тохиолддог. Бүх өөрчлөлтүүд үйлчлүүлэгчийн хувьд ямар ч саадгүй явагддаг. Тайлан солиход ч мөн адил. Цаг нь ирэхэд тайлан болон интерфейс өөрчлөгддөг.
Владимир: Мөн цагийн хуваарьт тайлангуудыг эхлүүлэхэд цаг завсарласан байдаг. Эхэндээ юу ч байхгүй. Хэрэв та хулганаа улаан зураасан дээр аваачих юм бол хэзээ нэгэн цагт нэвтрүүлгийн найруулагчийн ачаар таслагдах хэсгүүд гарч ирнэ. Захирал нэвтрүүлгийн эхлэлийг зөв тогтоож, арын ажилтан энэ өөрчлөлтийг авч, хурлын хуваарийн дагуу бүх дууны илтгэлүүдийн эхлэх, дуусах цагийг тооцоолж, манай үйлчлүүлэгчид рүү илгээж, тоглогч тасалбар зурдаг. Одоо хэрэглэгч тайлангийн эхэн ба төгсгөл рүү хялбархан шилжих боломжтой. Энэ бол бизнесийн хатуу шаардлага, маш тохиромжтой, хэрэгцээтэй байсан. Та тайлангийн жинхэнэ эхлэх цагийг олох гэж цаг үрэхгүй. Мөн бид урьдчилан үзэх үед энэ нь үнэхээр гайхалтай байх болно.
Байрлуулалт
-Би байршуулалтын талаар асуумаар байна. Коля болон багийнхан эхэндээ бүх зүйл бидэнд тохиолдож болох бүх дэд бүтцийг бий болгоход маш их цаг зарцуулсан. Надад хэлээч, энэ бүхэн юунаас бүтсэн бэ?
Николас: Техникийн үүднээс авч үзвэл, бид эхлээд бүтээгдэхүүнээ аль болох хийсвэр байх ёстой гэсэн шаардлагыг аль ч борлуулагчаас тавьдаг байсан. AWS-д ирж Terraform скриптүүдийг тусгайлан AWS, эсвэл Yandex, эсвэл Azure гэх мэтээс тусгайлан хийх боломжтой. үнэхээр тохирохгүй байсан. Бид хэзээ нэгэн цагт хаа нэг газар нүүх хэрэгтэй болсон.
Эхний гурван долоо хоногт бид үүнийг илүү сайн хийх арга замыг байнга хайж байсан. Үүний үр дүнд бид энэ тохиолдолд Кубернетес бол бидний бүх зүйл гэсэн дүгнэлтэд хүрсэн, учир нь энэ нь автоматаар өргөтгөх үйлчилгээг бий болгох, автоматаар нэвтрүүлэх, бараг бүх үйлчилгээг хайрцагнаас гаргах боломжийг олгодог. Мэдээжийн хэрэг, бүх үйлчилгээг Кубернетес, Докер нартай ажиллахын тулд сургах шаардлагатай байсан бөгөөд баг ч бас суралцах ёстой байв.
Бид хоёр кластертай. Туршилт ба үйлдвэрлэл. Техник хангамж, тохиргооны хувьд тэдгээр нь яг адилхан. Бид дэд бүтцийг код болгон хэрэгжүүлдэг. Бүх үйлчилгээг автомат шугам ашиглан функцын салбар, мастер салбар, туршилтын салбар, GitLab гэсэн гурван орчинд автоматаар нэвтрүүлдэг. Үүнийг GitLab-д дээд зэргээр нэгтгэсэн, Elastic, Prometheus-тай хамгийн дээд хэмжээнд нэгтгэсэн.
Бид бүх туршилт, интеграци, ажиллаж буй функциональ тест, хүрээлэн буй орчны интеграцийн тест, мөн ачааллын тестээр ямар ч орчинд өөрчлөлтийг хурдан нэвтрүүлэх боломжийг (backend-д 10 минутын дотор, frontend-д 5 минутын дотор) олгож байна. туршилтын орчин нь бидний үйлдвэрлэлд авахыг хүсч буйтай ижил төстэй зүйл юм.
Туршилтын тухай
- Та бараг бүх зүйлийг туршиж үздэг, яаж бүгдийг бичсэн гэдэгт итгэхэд бэрх. Та арын тестүүдийн талаар хэлж чадах уу: бүх зүйл хэр их хамрагдсан, ямар туршилтууд?
Владимир: Хоёр төрлийн тест бичсэн. Эхнийх нь бүрэлдэхүүн хэсгүүдийн туршилтууд юм. Хаврын бүх хэрэглээ болон суурийн өргөлтийн түвшний туршилт . Энэ бол хамгийн дээд түвшний бизнесийн хувилбаруудын шалгалт юм. Би функцуудыг шалгадаггүй. Бид зөвхөн том зүйлийг л шалгадаг. Жишээлбэл, туршилтын явцад хэрэглэгч рүү нэвтрэх үйл явц, хэрэглэгчийн хаана очиж болох тасалбар авах хүсэлт, дамжуулалтыг үзэх эрх авах хүсэлтийг дуурайлган хийдэг. Маш тодорхой хэрэглэгчийн хувилбарууд.
Ойролцоогоор ижил зүйлийг интеграцийн туршилт гэж нэрлэдэг бөгөөд энэ нь үнэхээр хүрээлэн буй орчинд ажилладаг. Үнэн хэрэгтээ, үйлдвэрлэлд дараагийн байршуулалт гарах үед бодит үндсэн хувилбарууд нь үйлдвэрлэлд ажиллаж байна. Үүнтэй ижил нэвтрэлт, тасалбар хүсэх, CloudFront руу нэвтрэх хүсэлт гаргах, урсгал миний зөвшөөрөлтэй үнэхээр холбогдож байгаа эсэхийг шалгах, захирлын интерфейсийг шалгах.
Одоогоор надад 70 орчим бүрэлдэхүүн тест, 40 орчим интеграцийн тест байна. Хамрах хүрээ 95% дөхөж байна. Энэ нь бүрэлдэхүүн хэсгүүдийн хувьд, интеграцийн хувьд бага, тийм ч их шаардлагагүй юм. Төсөл нь бүх төрлийн код үүсгэхийг хамардаг гэж үзвэл энэ нь маш сайн үзүүлэлт юм. Гурван сарын хугацаанд хийсэн ажлаа хийхээс өөр арга байгаагүй. Учир нь хэрэв бид гар аргаар туршиж, шалгагчдаа боломжуудыг өгвөл тэр алдааг олж засварлахаар бидэнд буцааж өгөх юм бол кодыг дибаг хийх энэ удаагийн аялал маш удаан үргэлжлэх бөгөөд бид ямар ч эцсийн хугацааг биелүүлэхгүй байх болно.
Николас: Уламжлал ёсоор, зарим функцийг өөрчлөхдөө бүх платформ дээр регресс хийхдээ хоёр өдрийн турш хаа сайгүй сууж, нудрах хэрэгтэй.
Владимир: Тиймээс, би ямар нэг онцлог шинж чанарыг тооцоолохдоо хоёр энгийн үзэг, 4 вэб залгуурт 1 хоног хэрэгтэй гэж хэлэхэд Коля зөвшөөрч байгаа нь маш том амжилт юм. Тэрээр энэ 4 хоногт 2 төрлийн шинжилгээг багтаасан бөгөөд дараа нь үр дүнтэй байх магадлалтай гэдэгт тэрээр аль хэдийн дассан байна.
Николас: Би бас 140 тест бичсэн: бүрэлдэхүүн + функциональ, тэдгээр нь ижил зүйлийг хийдэг. Бүх ижил хувилбаруудыг үйлдвэрлэл, туршилт, үйлдвэрлэлд туршиж үздэг. Бид саяхан функциональ үндсэн UI тестүүдийг нэмсэн. Ингэснээр бид эвдэрч болзошгүй хамгийн үндсэн функцуудыг хамарна.
Владимир: Мэдээжийн хэрэг, ачааллын туршилтын талаар ярих нь зүйтэй. Бүх зүйл хэрхэн байгааг, Rabbit-д юу болж байгааг, JVM-д юу болж байгааг, хэр их санах ой хэрэгтэйг ойлгохын тулд платформыг бодит байдалд ойрхон ачааллын дор турших шаардлагатай байв.
- Бид урсгалын тал дээр ямар нэг зүйлийг туршиж байгаа эсэхийг би сайн мэдэхгүй байна, гэхдээ бид уулзах үед код хувиргагчид асуудалтай байсныг санаж байна. Бид урсгалуудыг туршиж үзсэн үү?
Артём: Давталттайгаар туршиж үзсэн. Уулзалт зохион байгуулах. Уулзалтыг зохион байгуулах явцад ойролцоогоор 2300 JIRA тасалбар байсан. Эдгээр нь зүгээр л хүмүүсийн уулзалт хийх гэж хийдэг нийтлэг зүйлүүд юм. Бид платформын зарим хэсгийг Кирилл Толкачевын удирддаг уулзалтын тусдаа хуудас руу авав.).
Үнэнийг хэлэхэд тийм ч том асуудал байгаагүй. CloudFront дээр бид хэд хэдэн удаа кэш хийх алдааг олж илрүүлсэн ч бид үүнийг маш хурдан шийдвэрлэсэн - бид зүгээр л бодлогуудыг дахин тохируулсан. Хүмүүст, сайт дээрх дамжуулалтын системд илүү олон алдаа гарсан.
Чуулганы үеэр би илүү олон тоног төхөөрөмж, үйлчилгээг хамрахын тулд хэд хэдэн экспортлогчдыг бичих шаардлагатай болсон. Зарим газарт би зөвхөн хэмжүүрийн үүднээс өөрөө унадаг дугуй хийх шаардлагатай болсон. AV (аудио-видео) тоног төхөөрөмжийн ертөнц тийм ч ягаан биш - танд ямар нэгэн "API" төхөөрөмж байгаа бөгөөд үүнд нөлөөлж чадахгүй. Мөн та өөрт хэрэгтэй мэдээллээ олж авах боломжтой гэсэн ойлголтоос хол байна. Техник хангамжийн борлуулагчид үнэхээр удаан бөгөөд тэднээс хүссэн зүйлээ авах нь бараг боломжгүй юм. Нийтдээ 100 гаруй техник хангамж байдаг бөгөөд тэдгээр нь танд хэрэгтэй зүйлийг буцааж өгөхгүй бөгөөд та хачирхалтай, илүүдэл экспортлогчдыг бичдэг бөгөөд үүний ачаар та ядаж ямар нэгэн байдлаар системийг дибаг хийх боломжтой болно.
Тоног төхөөрөмж
- Чуулган эхлэхээс өмнө бид нэмэлт тоног төхөөрөмжийг хэсэгчлэн худалдаж авснаа санаж байна.
Артём: Бид компьютер, зөөврийн компьютер, батерей худалдаж авсан. Одоогоор бид цахилгаангүй 40 минут амьдрах боломжтой. 40-р сард Санкт-Петербургт хүчтэй аадар бороо орсон - тиймээс бид ийм харанхуй болсон. Үүний зэрэгцээ хэд хэдэн үйлчилгээ үзүүлэгч өөр өөр цэгээс оптик холбоосоор бидэнд ирдэг. Энэ бол үнэхээр XNUMX минутын барилгын зогсолт бөгөөд энэ хугацаанд бид гэрэл, дуу чимээ, камер гэх мэт ажиллах болно.
- Бид интернеттэй төстэй түүхтэй. Манай студиуд байрладаг оффист бид давхруудын хооронд ширүүн тор чирсэн.
Артём: Бид давхар хооронд 20 Гбит шилэн утастай. Цаашид шалан дээр, хаа нэгтээ оптик байдаг, хаа нэгтээ оптик байхгүй, гэхдээ гигабитаас цөөн суваг байдаг - бид хурлын замуудын хооронд видео бичлэг хийдэг. Ерөнхийдөө өөрийн дэд бүтэц дээр ажиллах нь маш тохиромжтой, та сайт дээрх офлайн хурал дээр үүнийг хийх нь ховор байдаг.
— Би JUG Ru Group-т ажиллахаасаа өмнө офлайн хурал дээр нэг шөнийн дотор техник хангамжийн өрөөнүүд хэрхэн зохион байгуулагдаж байгааг харсан бөгөөд тэнд таны Графана-д барьсан бүх хэмжигдэхүүн бүхий том монитор байдаг. Одоо мөн хурлын үеэр зарим алдааг засч, функцуудыг хөгжүүлдэг хөгжлийн баг байрладаг төв байрны өрөө байдаг. Үүний зэрэгцээ том дэлгэц дээр харагдах хяналтын систем байдаг. Артём, Коля болон бусад залуус сууж, бүгд унахгүй, сайхан ажиллаж байгаа эсэхийг шалгаарай.
Сонирхол, асуудал
— Бид Amazon-тэй стриминг хийдэг, вэбтэй тоглуулагчтай, бүх зүйл өөр өөр програмчлалын хэлээр бичигдсэн, алдааг тэсвэрлэх чадвар, бизнесийн бусад шаардлагыг хангасан, тэр дундаа хуулийн этгээдэд зориулсан хувийн данс болон хувь хүмүүс, мөн бид OAuth 2.0-ийг ашиглан хэн нэгэнтэй нэгтгэх боломжтой, залилангийн эсрэг, хэрэглэгчийг хориглох боломжтой. Бид үүнийг сайн хийсэн учраас өөрчлөлтийг динамикаар гаргаж чадна, бүгдийг туршиж үзсэн.
Ямар нэг зүйлийг эхлүүлэхэд ямар хачирхалтай зүйл байдгийг мэдэхийг сонирхож байна. Чамайг backend, frontend хөгжүүлж байх үед ямар нэгэн галзуу зүйл гарч ирээд юу хийхээ ойлгохгүй байх үед ямар нэгэн хачирхалтай нөхцөл байдал гарч байсан уу?
Владимир: Сүүлийн гурван сар л ийм зүйл болсон юм шиг надад санагдаж байна. Өдөр бүр. Таны харж байгаагаар миний бүх үс зулгаасан байна.
Владимир Красильщик 3 сарын дараа ямар нэгэн тоглоом болж, юу хийхээ хэн ч ойлгохгүй байв.
Өдөр бүр ийм зүйл гарч ирдэг байсан, үүнийг аваад үсээ зулгаах, эсвэл өөр хэн ч байхгүй, зөвхөн чи л үүнийг хийж чадна гэдгийг ухаарах үе байдаг. Бидний анхны томоохон арга хэмжээ бол TechTrain байлаа. 6-р сарын 2-ны 2.0 цагт бид үйлдвэрлэлийн орчинг хараахан гаргаж амжаагүй байхад Коля үүнийг гаргаж байсан. Мөн хувийн данс нь OAuth2.0 ашиглан зөвшөөрлийн сервер болж ажиллаагүй. Бид платформыг холбохын тулд үүнийг OAuth18 үйлчилгээ үзүүлэгч болгосон. Би бараг XNUMX цаг тасралтгүй ажилласан, би компьютер руу хараад юу ч хараагүй, яагаад ажиллахгүй байгааг ойлгохгүй байна, Коля алсаас миний кодыг харж, хаврын тохиргоонд алдаа хайж байсан. , үүнийг олж, LC ажиллаж, үйлдвэрлэлд ч бас .
Николас: TechTrain-ээс нэг цагийн өмнө нээлтээ хийсэн.
Энд маш олон одод зэрэгцэв. Бид маш азтай байсан, учир нь бид супер багтай байсан бөгөөд бүгд үүнийг онлайнаар хийх санаанаас урам зориг авсан. Энэ гурван сарын турш бид "YouTube" хийсэндээ хөтлөгдсөн. Би үсээ тайлахыг зөвшөөрөөгүй ч бүх зүйл бүтнэ гэж бүгдэд хэлсэн, учир нь үнэндээ бүх зүйлийг аль эрт тооцоолсон байсан.
Гүйцэтгэлийн тухай
- Нэг зам дээр хэдэн хүн сайтад байсныг хэлж чадах уу? Гүйцэтгэлийн асуудал гарсан уу?
Николас: Бидний хэлсэнчлэн гүйцэтгэлийн асуудал гараагүй. Нэг тайланд оролцсон хүмүүсийн дээд тоо 1300 хүн байсан нь Heisenbug дээр байна.
- Орон нутгийг үзэхэд ямар нэгэн асуудал гарсан уу? Энэ бүхэн хэрхэн ажилладаг талаар диаграмм бүхий техникийн тодорхойлолттой байх боломжтой юу?
Николас: Бид дараа нь энэ тухай нийтлэл гаргах болно.
Та урсгалыг дотооддоо дибаг хийх боломжтой. Чуулганууд эхэлмэгц энэ нь илүү хялбар болсон, учир нь бид үргэлж үзэх боломжтой үйлдвэрлэлийн урсгалууд гарч ирсэн.
Владимир: Миний ойлгож байгаагаар, урд талын хөгжүүлэгчид доог тохуутай ажилладаг байсан бөгөөд дараа нь урд талын хөгжүүлэгчид рүү шилжих хугацаа бас богино (5 минут) тул гэрчилгээнд юу болж байгааг шалгахад ямар ч асуудал гардаггүй.
— Орон нутагт ч гэсэн бүх зүйлийг туршиж, дибаг хийдэг. Энэ нь бид бүх техникийн шинж чанаруудыг агуулсан нийтлэл бичиж, танд үзүүлж, бүх зүйлийг диаграммтай, яаж байсныг танд хэлэх болно гэсэн үг юм.
Владимир: Та үүнийг аваад давтаж болно.
- 3 сарын дотор.
Үр дүн
- Гурван сарын дотор жижиг баг хийсэн гэдгийг бодоход хамтад нь дүрсэлсэн бүх зүйл сайхан сонсогдож байна.
Николас: Том баг үүнийг хийхгүй. Гэхдээ бие биетэйгээ нэлээд ойр, сайн харилцаж, тохиролцож чаддаг цөөн тооны хүмүүс байж болно. Тэдэнд ямар ч зөрчилдөөн байхгүй, архитектурыг хоёр өдрийн дотор зохион бүтээж, эцэслэн боловсруулж, үнэндээ өөрчлөгдөөгүй. Онцлогын хүсэлт, өөрчлөлтийг бөөгнөрүүлэх үүднээс ирж буй бизнесийн шаардлагыг маш хатуу хөнгөвчлөх байдаг.
- Зуны чуулганууд болж байхад таны цаашдын хийх ажлын жагсаалтад юу байсан бэ?
Николас: Жишээлбэл, зээл. Видеон дээрх мөлхөгч шугамууд, үзүүлж буй контентоос хамааран видеоны зарим хэсэгт гарч ирэх цонхнууд. Жишээлбэл, илтгэгч үзэгчдээс асуулт асуухыг хүсч байгаа бөгөөд дэлгэцэн дээр санал хураалт гарч ирэх бөгөөд энэ нь илтгэгч өөрөө санал хураалтын үр дүнд үндэслэн буцаж ирдэг. Танилцуулгын үеэр тайланд таалагдах, зүрх сэтгэл, үнэлгээ өгөх хэлбэрээр нийгмийн зарим төрлийн үйл ажиллагаа явуулдаг бөгөөд ингэснээр та дараа нь санал хүсэлтийн маягтуудад сатааралгүйгээр зөв цагт санал хүсэлтээ бөглөх боломжтой. Эхэндээ иймэрхүү.
Мөн түүнчлэн дамжуулалт, бага хурлаас бусад бүх платформ дээр хурлын дараах төлөвийг нэмж оруулав. Эдгээр нь тоглуулах жагсаалт (хэрэглэгчийн эмхэтгэсэн гэх мэт), магадгүй бусад өмнөх бага хурлын контент, нэгдсэн, шошготой, хэрэглэгчдэд хүртээмжтэй, мөн манай вэбсайтаас үзэх боломжтой ().
- Залуус аа, хариулт өгсөнд маш их баярлалаа!
Уншигчдын дунд манай зуны чуулганд оролцсон хүмүүс байвал тоглогч болон нэвтрүүлгийн талаарх сэтгэгдлээ хуваалцана уу. Юу нь тохиромжтой байсан, юу таныг бухимдуулсан, ирээдүйд юу үзэхийг хүсч байна вэ?
Хэрэв та платформыг сонирхож байгаа бөгөөд үүнийг "тулаан дээр" үзэхийг хүсвэл бид үүнийг дахин ашиглах болно . Тэдгээрийн олон төрөл байдаг тул танд тохирох нэг нь бараг гарцаагүй.
Эх сурвалж: www.habr.com