Гэтай вясной мы аказаліся ў вельмі вясёлых умовах. З-за пандэміі стала зразумела, што нашы летнія канферэнцыі неабходна пераносіць у анлайн. А каб правесці іх у анлайне якасна, нам не падыходзілі гатовыя софтавыя рашэнні, патрабавалася напісаць уласнае. І на гэта ў нас было тры месяцы.
Зразумела, што гэта былі захапляльныя тры месяцы. Але з боку не зусім відавочна: што наогул уяўляе сабой платформа для анлайн-канферэнцый? З якіх частак яна складаецца? Таму на апошняй з летніх канферэнцый DevOops я распытаў тых, хто адказваў за гэтую задачу:
- Мікалай Малчанаў - тэхнічны дырэктар JUG Ru Group;
- Уладзімір Красільшчык - прагматычны Java-праграміст, які займаецца бэкэндам (вы таксама маглі бачыць яго даклады на нашых Java-канферэнцыях);
- Арцём Ніканаў - адказвае за ўвесь наш відэастрымінг.
Дарэчы, на асенне-зімовых канферэнцыях мы будзем выкарыстоўваць палепшаную версію той жа платформы - так што многія хабрачытачы яшчэ апынуцца яе карыстальнікамі.
Агульная карціна
- Якім быў склад каманды?
Мікалай Малчанаў: У нас ёсць аналітык, дызайнер, тэсціроўшчык, тры франдэндары, бэкендэр. І, вядома, T-shaped спецыяліст!
- Як у цэлым выглядаў працэс?
Мікалай: Да сярэдзіны сакавіка ў нас да анлайну не было гатова наогул нічога. А 15 сакавіка закруцілася ўся карусель з анлайнам. Мы завялі некалькі рэпазітараў, спланавалі, абмеркавалі базавую архітэктуру і зрабілі ўсё за тры месяцы.
Гэта, вядома, прайшло класічныя этапы планавання, архітэктуры, выбару фіч, галасаванне за гэтыя фічы, палітыкі гэтых фіч, іх дызайну, распрацоўкі, тэсціравання. У выніку 6 чэрвеня мы выкацілі ўсё ў харчаванне. . На ўсё пра ўсё было 90 дзён.
- Ці атрымалася паспець тое, на што мы каміціліся?
Мікалай: Раз мы цяпер удзельнічаем у канферэнцыі DevOops у анлайне - значыць, атрымалася. Я асабіста закаміціўся на галоўную рэч: прынясу заказчыкам інструмент, пры дапамозе якога можна будзе зрабіць канферэнцыю ў анлайне.
Задача стаяла так: дайце нам інструмент, з дапамогай якога мы зможам трансліраваць нашы канферэнцыі ўладальнікам білетаў.
Усё планаванне было разбіта на некалькі этапаў, і ўсе фічы (каля 30 глабальных), былі падзелены на 4 катэгорыі:
- якія мы зробім абавязкова (без іх жыць не можам),
- якія мы зробім у другую чаргу,
- якія мы ніколі не зробім,
- і якія ніколі-ніколі не зробім.
Усе фічы з першых дзвюх катэгорый мы зрабілі.
- Я ведаю, што ўсяго было заведзена 600 JIRA-задач. За тры месяцы вы зрабілі 13 мікрасэрвісаў, і падазраю, што яны напісаны не толькі на Java. Вы выкарыстоўвалі розныя тэхналогіі, у вас паднята два Kubernetes-кластара ў трох зонах даступнасці і 5 RTMP-стрымаў у Amazon.
Давайце зараз разбярэмся з кожнай складніку сістэмы па асобнасці.
Стрымінг
- Пачнем з таго, калі ў нас ужо ёсць відэа-карцінка, і яна перадаецца на нейкія сэрвісы. Арцём, раскажы, як адбываецца гэты стрымінг?
Арцём Ніканаў: Агульная схема ў нас выглядае так: малюнак з камеры -> наша пультавая -> лакальны RTMP-сервер -> Amazon -> відэаплэер. Больш падрабязна на Хабры ў чэрвені.
Наогул ёсць два глабальных шляху, як гэта можна рабіць: альбо на жалезе, альбо на базе софтверных рашэнняў. Мы выбралі шлях софту, таму што гэта прасцей у выпадку з аддаленымі спікерамі. Не заўсёды ёсць магчымасць прывезці спікеру ў іншай краіне жалезку, а паставіць ПЗ спікеру здаецца прасцей і надзейней.
З пункту гледжання жалеза ў нас ёсць некаторая колькасць камер (у нашых студыях і ў выдаленых спікераў), некаторая колькасць пультаў у студыі, якія часам даводзіцца чыніць прама падчас эфіру пад сталом.
Сігналы ад гэтых прылад трапляюць у кампутары з поплаткамі захопу, уводу/высновы, гукавымі карткамі. Там сігналы міксуюцца, збіраюцца ў лейаўты:
Прыклад лейаўта на 4-х спікераў
Прыклад лейаўта на 4-х спікераў
Далей бесперапынны эфір забяспечваецца з дапамогай трох кампутараў: ёсць адна галоўная машына і пара якія працуюць па чарзе. Першы кампутар збірае першы даклад, другі - перапынак, першы - наступны даклад, другі - наступны перапынак і гэтак далей. А галоўная машына міксуе першую з другой.
Такім чынам атрымліваецца нейкі трыкутнік, і ў выпадку падзення любога з гэтых вузлоў мы можам хутка і без страты якасці працягнуць дастаўляць кліентам кантэнт. Такая сытуацыя ў нас была. На першым тыдні канферэнцый мы правілі адну машыну, уключалі/выключалі. Здаецца, што людзі задаволеныя нашай адмоваўстойлівасцю.
Далей струмені з кампутараў пападаюць на лакальны сервер, у якога дзве задачы: роўціць RTMP-струмені і запісваць бэкап. Такім чынам, у нас ёсць некалькі кропак запісу. Затым струмені відэа адпраўляюцца ў частку нашай сістэмы, пабудаваную на амазонаўскіх SaaS-сэрвісах. Выкарыстоўваны , S3, CloudFront.
Мікалай: А што там адбываецца да таго, як відэа патрапіць да гледачоў? Вы ж павінны яго наразаць неяк?
Арцём: Мы сціскаем са свайго боку відэа, адпраўляем яго ў MediaLive. Там запускаем транскодэры. Яны перакадуюць відэа ў рэжыме рэальнага часу ў некалькі дазволаў для таго, каб людзі маглі глядзець іх на тэлефонах, праз дрэнны інтэрнэт на лецішчы і гэтак далей. Потым гэтыя стрымы рэжуцца на , так працуе пратакол . На фронтэнд мы аддаём плэйліст, у якім ёсць паказальнікі на гэтыя чанкі.
- Мы выкарыстоўваем дазвол 1080р?
Арцём: Па шырыні ў нас як 1080p відэа – 1920 пікселяў, а па вышыні крыху менш, карцінка больш выцягнутая – на гэта ёсць свае прычыны.
плэер
- Арцём апісаў, як відэа трапляе ў стрымы, як размяркоўваецца на розныя плэйлісты для розных дазволаў экранаў, рэжацца на чанкі і трапляе ў плэер. Коля, раскажы цяпер, што гэта за плэер, як ён спажывае стрым, чаму HLS?
Мікалай: У нас ёсць плэер, які назіраюць усе гледачы канферэнцыі.
Па сутнасці, гэта абгортка над бібліятэкай , на якой напісана шмат іншых плэераў. Але нам была неабходна вельмі спецыфічная функцыянальнасць: перамотка назад і адзнака на месцы, у якім знаходзіцца чалавек, які даклад ён зараз глядзіць. Таксама патрэбны былі ўласныя лейаўты, усякія лагатыпы і ўсё іншае, што ўбудавалася ў нас. Таму мы вырашылі напісаць уласную бібліятэку (абгортку над HLS) і ўбудаваць гэта на сайт.
Гэта каранёвая функцыянальнасць, так што яе рэалізавалі практычна першай. А потым вакол гэтага ўсё ўжо абрастала.
Па факце плэер праз аўтарызацыю атрымлівае ад бэкенда плэйліст са спасылкамі на чанкі, суаднесеныя з часам і якасцю, выпампоўвае патрэбныя і паказвае карыстачу, праводзячы па ходзе некаторую "магію".
Прыклад таймлайна
— Прама ў плэер убудавана кнопка для вывядзення таймлайна ўсіх дакладаў…
Мікалай: Так, мы адразу вырашалі праблему навігацыі карыстальніка. У сярэдзіне красавіка вырашылі, што не будзем трансляваць кожную з нашых канферэнцый на асобным сайце, а аб'яднаем усё на адным. Каб карыстачы квіткоў Full Pass маглі вольна перамыкацца паміж рознымі канферэнцыямі: і прамым эфірам, і запісамі мінулых.
А каб карыстачам было прасцей перасоўвацца па бягучым стрыме і перамыкацца паміж трэкамі, вырашылі зрабіць кнопку «Увесь эфір» і гарызантальныя карткі дакладаў для пераключэння паміж трэкамі і дакладамі. Там ёсць кіраванне з клавіятуры.
- Былі нейкія тэхнічныя складанасці з гэтым?
Мікалай: Былі з палоскай пракруткі, на якой адзначаюцца кропкі пачатку розных дакладаў.
- У выніку вы рэалізавалі гэтыя адзнакі на паласе пракруткі раней, чым падобнае зрабіў YouTube?
Арцём: У іх гэта тады было ў бэце. Здаецца, што гэта даволі складаная фіча, таму што яны часткова тэсціравалі яе на карыстальніках на працягу апошняга года. І вось зараз яна дайшла да прода.
Мікалай: Але мы сапраўды да прода данеслі хутчэй. Сапраўды сказаць, што за гэтай простай фічай варта велізарная колькасць і бэкенда, і фронтенда, і разлікаў і матана ўсярэдзіне плэера.
Франтэнд
- Давайце разбяромся, як гэты кантэнт, які мы паказваем (картку дакладу, спікеры, сайт, расклад), выходзіць на фронтэнд?
Уладзімір Красільшчык: У нас ёсць некалькі ўнутраных айцішных сістэм. Ёсць сістэма, у якой заведзены ўсе даклады і ўсе спікеры. Ёсць працэс, па якім дакладчык бярэ ўдзел у канферэнцыі. Спікер падае заяўку, сістэма яе захоплівае, далей ёсць нейкі пайплайн, па якім ствараецца даклад.
Так спікер бачыць пайплайн
Гэтая сістэма - наша ўнутраная распрацоўка.
Далей з асобных дакладаў трэба пабудаваць расклад. Як вядома, гэта NP-складаная задача, але мы яе неяк развязальны. Для гэтага запускаем іншы кампанент, які фармуе расклад і засоўвае яго ў іншы хмарны сэрвіс Contentful. Там усё выглядае ўжо як табліца, у якой ёсць дні канферэнцыі, у днях - часовыя слоты, а ў слотах - даклады, перапынкі або спонсарскія актыўнасці. Так што кантэнт, які мы бачым, размяшчаецца ў іншым сэрвісе. І стаіць задача данесці яго да сайта.
Здавалася б, сайт - гэта проста старонка з плэерам, і нічога складанага тут няма. За выключэннем таго, што гэта ня так. Бэкэнд, які стаіць за гэтай старонкай, ідзе ў Contentful, дастае адтуль расклад, фармуе некаторыя аб'екты і адсылае на фронтэнд. Пры дапамозе вэбсокет-злучэння, якое робіць кожны кліент нашай платформы, мы з бэкенда на фронтэнд закідваем яму абнаўленне ў раскладзе.
Рэальны выпадак: спікер падчас канферэнцыі змяніў працу. Трэба памяняць яму плашчак кампаніі-працадаўцы. Як гэта адбываецца з бэкенда? Па вэбсокеце ўсім кліентам ляціць абнаўленне, і далей фронтэнд ужо сам перамалёўвае таймлайн. Усё гэта праходзіць бясшвоўна. Сукупнасць хмарнага сэрвісу і некалькіх нашых кампанентаў даюць нам магчымасць сфарміраваць увесь гэты кантэнт і падаць яго фронту.
Мікалай: Тут важна ўдакладніць, што наш сайт не з'яўляецца класічным SPA-дадаткам. Гэта і звярстаны, адрэндэраваны сайт, і SPA. Насамрэч Google бачыць гэты сайт як адрэндэраваны HTML. Гэта добра для SEO і для дастаўкі карыстачу кантэнту. Ён не чакае загрузкі 1,5 мегабайт JavaScript, каб потым убачыць старонку, ён адразу бачыць ужо адрэндэраваны старонку, а вы гэта адчуваеце кожны раз, калі перамыкае даклад. Усё атрымліваецца за паўсекунды, бо кантэнт ужо гатовы і выкладзены ў правільнае месца.
- Падвядзем рысу пад усім вышэйсказаным, пералічыўшы тэхналогіі. Тэма распавёў, што ў нас ёсць 5 Amazon-стрымаў, туды дастаўляем відэа і гук. Там у нас bash-скрыпты, з іх дапамогай запускаем, канфігуруем…
Арцём: Гэта адбываецца праз API AWS, тамака ёсць яшчэ шмат пабочных тэхнічных сэрвісаў. Мы падзялілі свае абавязкі так, што я дастаўляю на , а фронтэнд- і бэкэнд-распрацоўшчыкі адтуль забіраюць. У нас некаторая колькасць сваіх абвязак для спрашчэння выкладкі кантэнту, які мы робім потым у 4К і г.д. Паколькі тэрміны былі вельмі сціснутыя, мы практычна цалкам зрабілі гэта на базе AWS.
- Далей усё гэта трапляе ў плэер, выкарыстоўваючы бэкэнд сістэмы. У нас у плэеры TypeScript, React, Next.JS. І на бэкендзе ў нас ёсць некалькі сэрвісаў на С#, Java, Spring Boot і Node.js. Гэта ўсё разгортваецца з дапамогай Kubernetes, выкарыстоўваючы інфраструктуру Яндэкс.Аблокі.
Яшчэ хачу заўважыць, што калі мне спатрэбілася пазнаёміцца з платформай, гэта аказалася нескладана: усе рэпазітары знаходзяцца на GitLab, усё добра названа, напісаны тэсты, ёсць дакументацыя. Гэта значыць, нават у аўральным рэжыме клапаціліся пра такія рэчы.
Бізнес-абмежаванні і аналітыка
- Мы таргетаваліся па бізнес-патрабаванням на 10 000 карыстальнікаў. Самы час расказаць пра бізнес-абмежаванні, якія ў нас былі. Мы павінны былі забяспечваць высокую нагрузку, забяспечваць выкананне закону аб захаванні персанальных дадзеных. А што яшчэ?
Мікалай: Першапачаткова мы адштурхоўваліся ад патрабаванняў да відэа. Самае галоўнае - размеркаванае захоўванне відэа па свеце для хуткай дастаўкі кліенту. З іншых - дазвол 1080р, а таксама перамотка назад, што ў шматлікіх іншых у лайв-рэжыме не рэалізавана. Пазней мы дадалі магчымасць уключыць хуткасць 2x, з яе дапамогай можна "дагнаць" лайв і далей глядзець канферэнцыю ў рэальным часе. І яшчэ па ходзе з'явілася функцыянальнасць разметкі таймлайна. Плюс да гэтага мы павінны былі быць адмоваўстойлівымі і вытрымліваць нагрузку 10 000 злучэнняў. З пункту гледжання бэкенда гэта прыкладна 10 000 злучэнняў памножыць на 8 запытаў на кожны рэфрэш старонкі. А гэта ўжо 80 RPS/сек. Даволі шмат.
— Яшчэ былі патрабаванні да «віртуальнай выставы» з анлайн-стэндамі партнёраў?
Мікалай: Так, гэта трэба было зрабіць даволі хутка і ўніверсальна. У нас было да 10 кампаній-партнёраў на кожную канферэнцыю, і старонкі іх усіх трэба было завярстаць за тыдзень-два. Пры гэтым кантэнт у іх крыху адрозніваецца па фармаце. Але быў зроблены пэўны шаблонізатар, які збірае гэтыя старонкі на лета, практычна без далейшага ўдзелу па распрацоўцы.
- Было яшчэ патрабаванні па аналітыцы праглядаў у рэал-тайме і статыстыцы. Ведаю, што мы выкарыстоўваем для гэтага Prometheus, а раскажыце падрабязней: якія патрабаванні мы выконваем па аналітыцы, і як гэта рэалізуецца?
Мікалай: Першапачаткова ў нас ёсць маркеталагічныя патрабаванні па зборы для А/У-тэставанні і па зборы інфармацыі для таго, каб зразумець, як правільна кліенту дастаўляць лепшы кантэнт у далейшым. Яшчэ ёсць патрабаванні па нейкай аналітыцы па партнёрскіх актыўнасцях і аналітыка, якую вы бачыце (лічыльнік наведванняў). Уся інфармацыя збіраецца ў рэал-тайме.
Гэтую інфармацыю мы можам выдаваць у агрэгаваным выглядзе нават спікерам: колькі людзей цябе глядзелі ў пэўны момант часу. Пры гэтым для захавання 152 ФЗ асабісты кабінет і персанальныя дадзеныя не трэкаюцца ніяк.
На платформе ўжо ёсць і маркеталагічныя інструменты, і нашы метрыкі для вымярэння карыстацкай актыўнасці менавіта ў рэалтайме (хто глядзеў якую секунду даклада), каб будаваць графікі наведвання дакладаў. На аснове гэтых дадзеных робяцца даследаванні, якія дазволяць зрабіць наступныя канферэнцыі лепш.
Фрод
- У нас ёсць механізмы антыфроду?
Мікалай: У сувязі з цвёрдымі часавымі рамкамі з пункта гледжання бізнэсу першапачаткова не ставілася задача адразу ж блакаваць лішнія злучэнні. Калі два карыстачы заходзілі пад адным і тым жа акаўнтам, яны маглі паглядзець кантэнт. Але мы ведаем, колькі адначасовых праглядаў было з аднаго акаўнта. І некалькіх асоба злосных парушальнікаў мы забанілі.
Уладзімір: Трэба аддаць належнае, адзін з забаненных карыстальнікаў зразумеў, чаму гэта адбылося. Прыйшоў, папрасіў прабачэння і абяцаў купіць білет.
- Каб гэта ўсё адбывалася, вы павінны цалкам трасаваць усіх карыстальнікаў ад уваходу да выхаду, заўсёды ведаць што яны робяць. Як уладкованая гэтая сістэма?
Уладзімір: Я б хацеў расказаць пра аналітыку і статыстыку, якую мы потым аналізуем для паспяховасці даклада ці можам падаць потым партнёрам. Усе кліенты далучаны па вэбсокет-злучэнні да вызначанага кластара бэкенда. Там стаіць . Кожны кліент у кожны перыяд часу дасылае, што ён робіць і які трэк ён глядзіць. Далей гэтая інфармацыя хуткімі Hazelcast-джобамі агрэгуецца і адсылаецца ў зваротны бок усім, хто глядзіць гэтыя трэкі. Мы бачым у куце, колькі людзей зараз знаходзяцца разам з намі.
Гэтая ж інфармацыя складуецца ў і з'яжджае ў наша возера дадзеных, па якім мы маем магчымасць будаваць цікавейшы графік. Прыходзіць пытанне: колькі ўнікальных карыстальнікаў паглядзелі дадзены даклад? Мы ідзем у , там пінгі ўсіх людзей, якія прыйшлі па id гэтага даклада. Сабралі, агрэгавалі ўнікальных, і зараз можам зразумець.
Мікалай: Але пры гэтым мы атрымліваем яшчэ рэалтайм-дадзеныя з Prometheus. Ён націснуты на ўсе Kubernetes-сэрвісы, на сам Kubernetes. Збірае абсалютна ўсё, і з Grafana мы можам будаваць любыя графікі ў рэальным часе.
Уладзімір: З аднаго боку, мы гэта згружаем для далейшай апрацоўкі тыпу OLAP. А для OLTP прыкладанне згружае ўсю гэтую справу ў Prometheus, Grafana і графікі нават сыходзяцца!
- Той самы выпадак, калі графікі сыходзяцца.
Дынамічныя змены
- Раскажыце, як выкочваюцца дынамічныя змены: калі даклад адмяніўся за 6 хвілін да пачатку, які ланцужок дзеянняў? Які пайплайн спрацоўвае?
Уладзімір: Пайплайн вельмі ўмоўны. Ёсць некалькі магчымасцей. Першая - праграма фарміравання раскладу спрацавала і змяніла гэты расклад. Зменены расклад выгружаецца ў Contentful. Пасля чаго бэкенд разумее, што ёсць змены па дадзенай канферэнцыі ў Contentful, бярэ і перазбірае. Усё збіраецца і дасылаецца па websocket.
Другая магчымасць, калі ўсё адбываецца ў шалёным тэмпе: рэдактар рукамі мяняе ў Contentful інфармацыю (спасылку на Telegram, прэзентацыю дакладчыка і г.д.) і спрацоўвае тая ж самая логіка, што і ў першы раз.
Мікалай: Усё адбываецца без рэфрэша старонкі. Усе змены адбываюцца абсалютна бясшвоўна для кліента. Таксама і з пераключэннем дакладаў. Калі падыходзіць час, мяняецца даклад і інтэрфейс.
Уладзімір: Таксама і часовыя адсечкі пачатку дакладаў у таймлайне. У самым пачатку нічога няма. А калі навесці мышку на чырвоную палоску, то ў нейкі момант, дзякуючы рэжысёру трансляцыі, з'явяцца адсечкі. Рэжысёр ставіць правільны пачатак трансляцыі, бэкенд гэтае змяненне схоплівае, разлічвае адпаведна раскладу канферэнцыі час пачатку і канчаткі дакладаў усяго трэка, адпраўляе нашым кліентам, плэер малюе адсечкі. Цяпер карыстач можа спакойна навігавацца ў пачатак і канец дакладу. Гэта было цвёрдае бізнэс-патрабаванне, вельмі зручнае і карыснае. Ты не марнуеш час, каб знайсці цяперашні час пачатку даклада. А калі мы зробім прэв'ю, будзе ўвогуле выдатна.
Дэплаймент
- Я б хацеў спытаць пра дэплаймент. Коля і каманда спачатку забілі шмат часу, каб наладзіць усю інфраструктуру, у якой у нас усё разгортваецца. Раскажы, з чаго гэта ўсё?
Мікалай: У нас першапачаткова было патрабаванне з тэхнічнага пункта гледжання да прадукта максімальна абстрагавацца ад які-небудзь вендара. Прыйсці ў AWS рабіць Terraform-скрыпты канкрэтна AWS-аўскія, ці канкрэтна яндэксаўскія, ці Azure-аўскія і г.д. не вельмі падыходзіла. Мы павінны былі ў свой час некуды з'ехаць.
Першыя тыдні тры мы ўвесь час шукалі шлях, як гэта лепш зрабіць. У выніку прыйшлі да таго, што Kubernetes у дадзеным выпадку - гэта наша ўсё, таму што дазваляе рабіць аўтаматычна-маштабуюцца сэрвісы, автовыкатку і атрымаць з скрынкі практычна ўсе сэрвісы. Натуральна, трэба было навучыць усе сэрвісы працы з Kubernetes, Docker, і камандзе таксама навучыцца.
У нас два кластары. Тэставы і харчоўскі. Яны абсалютна аднолькавыя з пункту гледжання жалеза, настроек. Імплементуем інфраструктуру як код. Усе сэрвісы аўтаматычным пайплайнам раскочваюцца ў тры асяроддзі з фічы-галінак, з майстар-галінак, з тэставых, з GitLab. Гэта максімальна інтэгравана ў GitLab, максімальна інтэгравана з Elastic, Prometheus.
Мы атрымліваем магчымасць хутка (для бэкенда на працягу 10 хвілін, для фронтэнда на працягу 5 хвілін) выкаціць змены ў любую сераду з усімі тэстамі, інтэграцыямі, запускам функцыянальных тэстаў, інтэграцыйных тэстаў на асяроддзі, і яшчэ і пратэставаць нагрузачнымі тэстамі на тэставым асяроддзі прыкладна тое ж самае, што мы хочам атрымаць у прадакшэне.
Пра тэсты
- Вы амаль усё тэстуеце, цяжка паверыць, як вы ўсё напісалі. Можаце расказаць як па бэкенду па тэстах: наколькі ўсё пакрыта, якія тэсты?
Уладзімір: Напісана два тыпы тэстаў. Першыя - кампанентныя тэсты. Тэсты ўзроўню ўздыму за ўсё спрынгавага прыкладання і базы ў . Гэта праверка самых высокаўзроўневых бізнес-сцэнарыяў. Я не тэстую функцыі. Мы тэстуем толькі нейкія буйныя штукі. Напрыклад, прама ў цесцю эмулюецца працэс лагіна карыстача, запыт гэтым карыстачом квіткоў, куды ён можа схадзіць, запыт доступу на прагляд стрыму. Вельмі зразумелыя карыстацкія сцэнары.
Прыкладна тое ж самае рэалізавана ў так званых інтэграцыйных тэстах, якія рэальна бягуць на асяроддзі. Фактычна, калі чарговы дэплаймент у прод раскочваецца, на продзе таксама бягуць сапраўдныя базавыя сцэнары. Той жа самы лагін, запыт квіткоў, запыт доступу да CloudFront, праверка таго, што стрым сапраўды чапляецца з маімі дазволамі, праверка рэжысёрскага інтэрфейсу.
На дадзены момант у мяне на борце прыкладна 70 кампанентных тэстаў і каля 40 інтэграцыйных. Пакрыццё вельмі блізка да 95%. Гэта па кампанентных, па інтэграцыйных менш, там столькі проста не трэба. Улічваючы тое, што ў праекце ўсякія кодагенерацыі, гэта вельмі добры паказчык. Ніякага іншага спосабу зрабіць тое, што мы зрабілі за тры месяцы, не было. Таму што калі б мы тэсціравалі ручным чынам, аддаючы фічы нашай тэсціроўшчыцы, а яна б знаходзіла багі і вяртала нам на фіксы, то гэты round trip па адладжванні кода быў бы вельмі доўгі, і мы б не ўлезлі ні ў якія тэрміны.
Мікалай: Умоўна, каб правесці рэгрэс на ўсёй платформе пры змене нейкай функцыі, трэба два дні сядзець і тыкаць усюды.
Уладзімір: Таму вялікі поспех, што, калі я эстымірую фічу, кажу, што мне трэба 4 дні на дзве простыя ручкі і 1 websocket, Коля дазваляе. Ён ужо прывык, што ў гэтыя 4 дні закладзены 2 тыпы тэстаў, і потым, хутчэй за ўсё, гэта будзе працаваць.
Мікалай: У мяне таксама напісана 140 тэстаў: кампанентных + функцыянальных, якія робяць тое ж самае. Усе тыя ж самыя сцэнары тэстуюцца і на прадакшэне, на цесцю і на панне. Таксама нядаўна ў нас з'явіліся функцыянальныя базавыя UI-ныя тэсты. Так мы пакрываем самыя базавыя функцыянальнасці, якія могуць разваліцца.
Уладзімір: Вядома ж, варта расказаць пра нагрузачныя тэсты. Трэба было праверыць платформу пад нагрузкай, набліжанай да рэальнай, каб зразумець, як яно ўсё, што адбываецца з Rabbit, што адбываецца з JVM-камі, колькі рэальна трэба памяці.
— Я не ведаю дакладна, ці тэсціруем мы што-небудзь на баку стрымаў, але я памятаю, што былі праблемы з транскодэрамі, калі мы рабілі мітапы. Ці тэсціравалі мы стрымныя?
Арцём: Тэсцілі ітэратыўна. Арганізоўваючы мітапы. У працэсе арганізацыі мітапаў было прыкладна 2300 JIRA-тыкетаў. Гэта проста шаблонныя рэчы, якія людзі рабілі, каб зрабіць мітапы. Мы бралі часткі платформы на асобную старонку для мітапаў, якой займаўся Кірыл Талкачоў ().
Сапраўды кажучы, вялікіх праблем не было. Літаральна пару разоў лавілі багі па кэшаванні на CloudFront, вырашылі даволі хутка - проста пераналадзілі палітыкі. Багаў было значна больш у людзях, у сістэмах стрымінгу на пляцоўцы.
Падчас канферэнцый прыйшлося пісаць яшчэ некалькі экспарцёраў для таго, каб пакрыць больш абсталявання і сэрвісаў. Месцамі даводзілася рабіць свае веласіпеды толькі дзеля метрык. Свет AV (аўдыё-відэа) жалеза не вельмі вясёлкавы - у цябе ёсць нейкае "API" абсталявання, на якое ты проста не можаш паўплываць. І далёка не факт, што атрымаецца забраць тую інфармацыю, якая табе патрэбная. Вендары жалеза рэальна павольныя, і ад іх амаль немагчыма дабіцца жаданага. Разам больш за 100 жалязяк, аддаюць яны не тое, што трэба, а ты пішаш дзіўныя і залішнія экспарцёры, дзякуючы якім можна хоць неяк дэбажыць сістэму.
Абсталяванне
- Я памятаю, як да пачатку канферэнцый мы часткова дазакуплялі абсталяванне.
Арцём: Закуплялі камп'ютары, ноўтбукі, батарэйныя блокі. На дадзены момант мы можам жыць без электрычнасці 40 хвілін. У чэрвені ў Піцеры былі моцныя навальніцы - так што такое адключэнне ў нас было. Пры гэтым да нас прыходзяць некалькі правайдэраў аптычнымі лінкамі з розных кропак. Гэта сапраўды 40 хвілін даунтайму будынка, пры якіх у нас будзе гарэць святло, працаваць гук, камеры і г.д.
- З інтэрнэтам у нас падобная гісторыя. У офісе, дзе знаходзяцца нашы студыі, мы паміж паверхамі працягнулі лютую сетку.
Арцём: У нас 20 Гбіт оптыкі паміж паверхамі. Далей па паверхах недзе оптыка, недзе не, але ўсё ж менш, чым гігабітных, каналаў няма — мы ганяем па іх паміж трэкамі канферэнцыі відэа. Наогул вельмі зручна працаваць на сваёй інфраструктуры, на афлайн-канферэнцыях на пляцоўках так рэдка атрымоўваецца рабіць.
- Яшчэ не працуючы ў JUG Ru Group, я бачыў, як за ноч разгортваюцца апаратныя на афлайн-канферэнцыях, дзе стаіць вялікі манітор з усімі метрыкамі, якія вы будуеце ў Grafana. Цяпер таксама ёсць памяшканне-штаб, у якім сядзіць каманда распрацоўкі, якая падчас канферэнцыі чыніць нейкія багі і распрацоўвае фічы. Пры гэтым ёсць сістэма маніторынгу, якая выводзіцца на вялікі экран. Арцём, Коля і іншыя хлопцы сядзяць і глядзяць, каб гэта ўсё не падала і прыгожа працавала.
Кур'ёзы і праблемы
— Вы добра распавялі аб тым, што ў нас ёсць стрымінг з Амазонам, ёсць плэер з вэбам, усё напісана на розных мовах праграмавання, забяспечваецца адмоваўстойлівасць і іншыя бізнес-патрабаванні, у тым ліку ёсць асабісты кабінет, які падтрымліваецца для юрыдычных і фізічных асоб, і мы можам інтэгравацца з кімсьці па OAuth 2.0, ёсць антыфрод, блакіроўка карыстальніка. Мы можам дынамічна выкочваць змены, таму што зрабілі гэта добра, і пры гэтым гэта ўсё тэстуецца.
Мне цікава даведацца, якія былі кур'ёзы з тым, каб нешта запусцілася. Ці былі дзіўныя сітуацыі, калі вы распрацоўвалі бэкэнд, фронтэнд, атрымлівалася нейкая дзічына і вы не разумелі, што з гэтым рабіць?
Уладзімір: Мне здаецца, такое было толькі апошнія тры месяцы. Кожны дзень. Як вы можаце ўбачыць, усе мае валасы вырваныя.
Уладзімір Красільшчык пасля 3 месяцаў, калі атрымлівалася нейкая дзічына і ніхто не разумеў, што з гэтым рабіць
Кожны дзень нешта такое было, калі быў такі момант, калі ты бярэш і рвеш на сабе валасы, альбо разумееш, што больш нікога няма, і толькі ты можаш гэта зрабіць. Першым вялікім мерапрыемствам у нас быў TechTrain. 6 чэрвеня ў 2 гадзіны ночы ў нас яшчэ не было раскочана прадакшэн-акружэнне, яго раскочваў Коля. І не працаваў асабісты кабінет, як сервер аўтарызацыі па OAuth2.0. Мы ператварылі яго ў правайдэра OAuth2.0, каб да яго падлучыць платформу. Я працаваў, мусіць, ужо 18 гадзіну запар, глядзеў у кампутар і нічога не бачыў, не разумеў, чаму ён не працуе, і выдалена Коля глядзеў у мой код, шукаў баг у канфігурацыі Spring, знайшоў, і ЛК зарабіў, і ў прадакшэне таксама .
Мікалай: І за гадзіну да TechTrain рэліз адбыўся.
Тут склаліся вельмі многія зоркі. Нам вельмі павезла, таму што ў нас склалася проста супер-каманда, і ўсё задрайвіліся ідэяй зрабіць анлайн. Усе гэтыя тры месяцы нас драйвіла тое, што мы "рабілі YouTube". Я не дазваляў сабе рваць валасы, а казаў усім, што ўсё атрымаецца, бо насамрэч усё даўно пралічана.
Пра прадукцыйнасць
- Ці можаце расказаць, колькі было максімальна людзей на сайце на адным трэку? Ці былі праблемы з прадукцыйнасцю?
Мікалай: Праблем з прадукцыйнасцю, як мы ўжо казалі, не было. Максімальная колькасць людзей, якія былі на адным дакладзе, - 1300 чалавек, гэта на Heisenbug.
- Ці былі праблемы з лакальным праглядам? І ці магчыма тэхнічнае апісанне са схемамі таго, як гэта ўсё ўладкована?
Мікалай: Зробім пра гэта пазней артыкул.
Лакальна можна аддэбажыць нават стрымныя. Як толькі пачаліся канферэнцыі, гэта стала нават прасцей, таму што з'явіліся прадакшэн-стрымы, якія мы можам глядзець увесь час.
Уладзімір: Як я разумею, фронтэнд-дэвелаперы лакальна працавалі з мокамі, а потым, паколькі час выкаткі на паннаў у фронце таксама невялікае (5 хвілін), паглядзець, што там з сертыфікатамі, праблем ніякіх няма.
- Усё тэстуецца, дэбажыцца, нават лакальна. Значыць, напішам артыкул з усімі тэхнічнымі асаблівасцямі, пакажам, раскажам усё са схемамі, як было.
Уладзімір: Зможаце ўзяць і паўтарыць.
- За 3 месяцы.
Вынік
- Усё апісанае разам гучыць крута з улікам таго, што гэта зроблена маленькай камандай за тры месяцы.
Мікалай: Вялікая каманда гэтага б не зрабіла. А вось маленькая група людзей, якія даволі шчыльна і добра адзін з адным маюць зносіны і могуць дамовіцца, магла б. У іх няма нейкіх супярэчнасцяў, архітэктура была прыдумана за два дні, была фіналізавана і фактычна не памянялася. Ёсць вельмі цвёрдая фасілітацыя якія паступаюць бізнэс-патрабаванняў з пункта гледжання навальвання фіч-рэквестаў і змен.
- Што апынулася ў вашым спісе далейшых задач, калі летнія канферэнцыі ўжо адбыліся?
Мікалай: Напрыклад, тытры. Бягучыя радкі на відэа, усплывашкі ў некаторых месцах відэа ў залежнасці ад паказу кантэнту. Напрыклад, спікер хоча задаць пытанне ў аўдыторыю, і на экране ўсплывае галасавалка, якая назад у бэк па выніках галасавання ідзе самому спікеру. Нейкая сацыяльная актыўнасць у выглядзе лайкаў, сэрцайкаў, адзнак дакладу падчас самой прэзентацыі, каб можна было, не адцягваючыся потым на формы зваротнай сувязі, запоўніць фідбэк у патрэбную секунду. Першапачаткова вось так.
А яшчэ даданне ўсёй платформе, акрамя стрымінгавага і канферэнцыйнага, таксама постканферэнцыйны стан. Гэта плэйлісты (у тым ліку складзеныя карыстальнікамі), магчыма, кантэнт з іншых мінулых канферэнцый, інтэграваныя, прамаркіраваныя, даступныя для карыстальніка, ну і даступныя для прагляду на нашым сайце ().
- Хлопцы, дзякуй вялікі за адказы!
Калі сярод чытачоў ёсць тыя, хто быў на нашых летніх канферэнцыях - падзяліцеся вашымі ўражаннямі ад плэера і трансляцыі. Што было зручна, што ятрыла, што жадаецца ўбачыць у будучыні?
Калі платформа зацікавіла і захацелася ўбачыць яе «у баі» - мы зноў выкарыстоўваем яе на нашых . Іх цэлы шэраг, так што амаль напэўна ёсць прыдатная для вас.
Крыніца: habr.com