이번 봄에 우리는 매우 기분 좋은 환경에 있었습니다. 전염병으로 인해 여름 컨퍼런스를 온라인으로 옮겨야 한다는 것이 분명해졌습니다. 그리고 이를 온라인으로 효율적으로 수행하려면 기성 소프트웨어 솔루션이 우리에게 적합하지 않았으므로 직접 작성해야 했습니다. 그리고 우리는 이것을 하기 위해 XNUMX개월의 시간을 가졌습니다.

정말 흥미로운 XNUMX개월이었음이 분명합니다. 그러나 외부에서는 완전히 명확하지 않습니다. 온라인 회의 플랫폼이란 무엇입니까? 어떤 부분으로 구성되어 있나요? 따라서 여름 DevOops 컨퍼런스의 마지막에서 저는 이 작업을 담당하는 사람들에게 다음과 같이 물었습니다.

• Nikolay Molchanov - JUG Ru Group의 기술 이사;
• Vladimir Krasilshchik은 백엔드에서 작업하는 실용적인 Java 프로그래머입니다(Java 컨퍼런스에서도 그의 보고서를 볼 수 있습니다).
• Artyom Nikonov는 당사의 모든 비디오 스트리밍을 담당합니다.

그건 그렇고, 가을-겨울 컨퍼런스에서 우리는 동일한 플랫폼의 향상된 버전을 사용할 것입니다. 따라서 많은 Habra 독자가 여전히 사용자가 될 것입니다.

큰 그림

— 팀 구성은 어땠나요?

니콜라이 몰차노프: 우리는 분석가, 디자이너, 테스터, XNUMX명의 프런트엔더, XNUMX명의 백엔드를 보유하고 있습니다. 그리고 물론 T자 전문가!

— 전반적인 과정은 어땠나요?

니콜라이 : 15월 중순까지 우리는 온라인으로 준비한 것이 전혀 없었습니다. 그리고 XNUMX월 XNUMX일부터 전체 온라인 캐러셀이 회전하기 시작했습니다. 우리는 여러 저장소를 설정하고, 계획하고, 기본 아키텍처에 대해 논의하고 모든 작업을 XNUMX개월 만에 수행했습니다.

물론 이는 계획, 아키텍처, 기능 선택, 해당 기능에 대한 투표, 해당 기능에 대한 정책, 디자인, 개발, 테스트의 고전적인 단계를 거쳤습니다. 그 결과, 6월 XNUMX일에 모든 것을 프로덕션에 출시했습니다. TechTrain. 모든 일에는 90일이 걸렸습니다.

— 우리가 약속한 것을 성취할 수 있었나요?

니콜라이 : 우리는 이제 온라인으로 DevOops 컨퍼런스에 참여하고 있으므로 성공했다는 의미입니다. 저는 개인적으로 가장 중요한 일에 전념했습니다. 고객에게 온라인 회의를 할 수 있는 도구를 제공하는 것입니다.

문제는 티켓 소지자에게 컨퍼런스를 방송할 수 있는 도구를 제공하는 것이었습니다.

모든 계획은 여러 단계로 나누어졌으며 모든 기능(글로벌 약 30개)은 4가지 범주로 나누어졌습니다.

• 우리는 반드시 그렇게 할 것입니다(우리는 그들 없이는 살 수 없습니다).
• 두 번째로 할 일은
• 우리는 결코 하지 않을 일입니다.
• 그리고 우리는 결코 그렇게 하지 않을 것입니다.

우리는 처음 두 범주의 모든 기능을 만들었습니다.

— 총 600개의 JIRA 이슈가 생성된 것으로 알고 있습니다. 13개월 동안 5개의 마이크로서비스를 만들었고, 이 마이크로서비스가 Java로만 작성된 것은 아닐 것 같습니다. 서로 다른 기술을 사용했으며 Amazon에 XNUMX개의 가용 영역과 XNUMX개의 RTMP 스트림에 XNUMX개의 Kubernetes 클러스터가 있습니다.

이제 시스템의 각 구성요소를 개별적으로 살펴보겠습니다.

스트리밍

— 이미 비디오 이미지가 있고 일부 서비스로 전송되는 경우부터 시작해 보겠습니다. Artyom, 스트리밍이 어떻게 이루어지는지 알려주세요.

아르템 니코노프: 우리의 일반적인 계획은 다음과 같습니다: 카메라의 이미지 -> 제어실 -> 로컬 RTMP 서버 -> Amazon -> 비디오 플레이어. 자세한 내용은 그것에 대해 썼다 XNUMX월의 아브레에서.

일반적으로 이를 수행하는 전역적인 방법에는 하드웨어 또는 소프트웨어 솔루션을 기반으로 하는 두 가지 방법이 있습니다. 원격 스피커의 경우 더 쉽기 때문에 소프트웨어 경로를 선택했습니다. 다른 나라의 스피커에 하드웨어를 가져오는 것이 항상 가능한 것은 아니지만, 스피커에 소프트웨어를 전달하는 것이 더 쉽고 안정적입니다.

하드웨어 관점에서 볼 때, 우리 스튜디오에는 특정 수의 카메라(스튜디오 및 원격 스피커에)가 있고, 스튜디오에 특정 수의 리모콘이 있으며, 방송 중에 테이블 바로 아래에서 수리해야 하는 경우도 있습니다.

이러한 장치의 신호는 캡처 카드, 입력/출력 카드 및 사운드 카드를 통해 컴퓨터로 입력됩니다. 거기에서 신호가 혼합되어 레이아웃으로 조립됩니다.

4개 스피커의 레이아웃 예

4개 스피커의 레이아웃 예

또한 세 대의 컴퓨터를 사용하여 연속 방송이 제공됩니다. 하나의 메인 머신과 한 쌍의 작업 머신이 차례로 있습니다. 첫 번째 컴퓨터는 첫 번째 보고서를 수집하고, 두 번째는 중단, 첫 번째는 다음 보고서, 두 번째는 다음 중단 등을 수집합니다. 그리고 메인 머신은 첫 번째와 두 번째를 혼합합니다.

이는 일종의 삼각형을 생성하며, 이러한 노드 중 하나라도 실패하면 품질 저하 없이 신속하게 콘텐츠를 클라이언트에 계속 전달할 수 있습니다. 우리에게는 그런 상황이 있었습니다. 컨퍼런스 첫 주 동안 우리는 기계 한 대를 고치고 켜고 껐습니다. 사람들은 우리의 탄력성에 만족하는 것 같습니다.

다음으로 컴퓨터의 스트림은 RTMP 스트림 라우팅과 레코드 백업이라는 두 가지 작업이 있는 로컬 서버로 이동합니다. 그래서 우리는 여러 개의 녹음 지점을 가지고 있습니다. 그런 다음 비디오 스트림은 Amazon SaaS 서비스를 기반으로 구축된 시스템의 일부로 전송됩니다. 우리는 사용 미디어라이브,S3,CloudFront.

니콜라이 : 동영상이 시청자에게 도달하기 전에 어떤 일이 발생하나요? 어떻게든 잘라야겠죠?

아르템: 우리는 비디오를 압축하여 MediaLive로 보냅니다. 거기서 트랜스코더를 실행합니다. 그들은 실시간으로 비디오를 여러 해상도로 변환하여 사람들이 휴대전화나 인터넷이 열악한 나라 등에서 볼 수 있도록 합니다. 그런 다음 이러한 스트림이 잘립니다. 덩어리, 이것이 프로토콜이 작동하는 방식입니다 HLS. 이러한 청크에 대한 포인터가 포함된 재생 목록을 프런트엔드로 보냅니다.

— 1080p 해상도를 사용하고 있나요?

아르템: 우리 비디오의 너비는 1080p - 1920 픽셀과 동일하고 높이는 조금 더 작고 사진이 더 길어집니다. 여기에는 이유가 있습니다.

플레이어

— Artyom은 비디오가 스트림에 들어가는 방법, 다양한 화면 해상도에 따라 다양한 재생 목록에 배포되는 방법, 덩어리로 잘라서 플레이어에 들어가는 방법을 설명했습니다. Kolya, 이제 이것이 어떤 종류의 플레이어인지, 스트림을 어떻게 소비하는지, 왜 HLS인지 말해 보세요.

니콜라이 : 모든 회의 시청자가 시청할 수 있는 플레이어가 있습니다.

본질적으로 이는 라이브러리를 둘러싼 래퍼입니다. hls.js, 다른 많은 플레이어가 작성되었습니다. 하지만 우리에게는 매우 구체적인 기능이 필요했습니다. 그 사람이 있는 장소를 되감고 표시하고, 그가 현재 보고 있는 보고서가 무엇인지 표시하는 것입니다. 우리는 또한 우리 자신의 레이아웃, 모든 종류의 로고 및 우리와 함께 내장된 모든 것이 필요했습니다. 따라서 우리는 자체 라이브러리(HLS에 대한 래퍼)를 작성하고 이를 사이트에 포함하기로 결정했습니다.

이는 루트 기능이므로 거의 먼저 구현되었습니다. 그리고 그 주위에 모든 것이 자랐습니다.

실제로 승인을 통해 플레이어는 백엔드로부터 시간 및 품질과 관련된 청크에 대한 링크가 포함된 재생 목록을 수신하고 필요한 항목을 다운로드하여 사용자에게 보여주면서 "마법"을 수행합니다.

타임라인 예시

— 모든 보고서의 타임라인을 표시하는 버튼이 플레이어에 내장되어 있습니다.

니콜라이 : 예, 사용자 탐색 문제를 즉시 해결했습니다. XNUMX월 중순에 우리는 각 컨퍼런스를 별도의 웹사이트에 방송하지 않고 모든 것을 하나로 통합하기로 결정했습니다. 풀 패스 티켓 사용자는 실시간 방송과 과거 회의 녹화 등 다양한 회의 간에 자유롭게 전환할 수 있습니다.

그리고 사용자가 현재 스트림을 더 쉽게 탐색하고 트랙 간 전환을 할 수 있도록 트랙과 보고서 간 전환을 위한 "전체 방송" 버튼과 가로 성적표를 만들기로 결정했습니다. 키보드 컨트롤이 있습니다.

— 기술적인 어려움은 없었나요?

니콜라이 : 다양한 보고서의 시작 지점이 표시된 스크롤 막대가 있었습니다.

— 결국 YouTube가 유사한 작업을 수행하기 전에 스크롤 막대에 이러한 표시를 구현했습니까?

아르템: 그 당시에는 베타 버전이었습니다. 지난 XNUMX년 동안 사용자를 대상으로 부분적으로 테스트를 진행했기 때문에 이는 꽤 복잡한 기능인 것 같습니다. 그리고 지금은 판매에 이르렀습니다.

니콜라이 : 하지만 실제로는 더 빨리 판매하게 되었습니다. 솔직히 이 간단한 기능 뒤에는 플레이어 내부에 엄청난 양의 백엔드, 프런트엔드, 계산 및 수학이 있습니다.

프런트엔드

— 우리가 보여주는 이 콘텐츠(스피치 카드, 연사, 웹사이트, 일정)가 어떻게 프론트 엔드에 도달하는지 알아볼까요?

Владимир Красильщик: 우리는 여러 내부 IT 시스템을 보유하고 있습니다. 모든 보고서와 모든 발표자가 입력되는 시스템이 있습니다. 컨퍼런스에 발표자가 참여하는 과정이 있습니다. 발표자가 신청서를 제출하면 시스템이 이를 캡처한 다음 보고서가 생성되는 특정 파이프라인이 있습니다.

화자가 파이프라인을 보는 방식은 다음과 같습니다.

이 시스템은 우리의 내부 개발입니다.

다음으로 개별 보고서에서 일정을 작성해야 합니다. 아시다시피 이것은 NP-난해한 문제이지만 우리는 어떻게든 해결합니다. 이를 위해 일정을 생성하고 이를 타사 클라우드 서비스인 Contentful에 업로드하는 또 다른 구성 요소를 시작합니다. 그곳에서는 모든 것이 회의가 열리는 날, 날에 시간표가 있고, 그 날에는 보고서, 휴식 시간, 후원 활동이 있는 테이블처럼 보입니다. 따라서 우리가 보는 콘텐츠는 제XNUMX자 서비스에 있습니다. 그리고 임무는 그것을 현장에 전달하는 것입니다.

사이트는 플레이어가 있는 페이지일 뿐이고 여기에는 복잡한 것이 없습니다. 그렇지 않다는 점만 빼면요. 이 페이지 뒤에 있는 백엔드는 Contentful로 이동하여 거기에서 일정을 가져오고 일부 개체를 생성하여 프런트엔드로 보냅니다. 우리 플랫폼의 모든 클라이언트가 만드는 웹소켓 연결을 사용하여 우리는 그에게 백엔드에서 프런트엔드로 일정 업데이트를 보냅니다.

실제 사례: 발표자는 회의 중에 바로 직업을 바꿨습니다. 그의 고용주 회사 배지를 변경해야 합니다. 백엔드에서는 어떻게 이런 일이 발생합니까? 업데이트는 websocket을 통해 모든 클라이언트로 전송된 다음 프런트엔드 자체가 타임라인을 다시 그립니다. 이 모든 일이 원활하게 이루어집니다. 클라우드 서비스와 여러 구성요소의 결합을 통해 우리는 이 모든 콘텐츠를 생성하고 전면에 제공할 수 있는 기회를 얻었습니다.

니콜라이 : 여기서 우리 사이트가 전형적인 SPA 애플리케이션이 아니라는 점을 명확히 하는 것이 중요합니다. 이는 레이아웃 기반의 렌더링된 웹사이트이자 SPA입니다. Google은 실제로 이 사이트를 렌더링된 HTML로 간주합니다. 이는 SEO와 사용자에게 콘텐츠를 전달하는 데 좋습니다. 페이지를 보기 전에 1,5MB의 JavaScript가 로드될 때까지 기다리지 않고 이미 렌더링된 페이지를 즉시 보고 보고서를 전환할 때마다 이를 느낍니다. 콘텐츠가 이미 준비되어 올바른 위치에 게시되어 있으므로 모든 작업이 XNUMX초 안에 이루어집니다.

— 기술을 나열하여 위의 모든 항목에 선을 그어 보겠습니다. Tyoma는 우리가 5개의 Amazon 스트림을 가지고 있으며 그곳에서 비디오와 사운드를 전달한다고 말했습니다. 거기에 bash 스크립트가 있고 이를 사용하여 실행하고 구성합니다...

아르템: 이는 AWS API를 통해 발생하며 더 많은 기술적 측면 서비스가 있습니다. 우리는 책임을 나누어서 다음 사항을 전달합니다. CloudFront를, 프런트엔드 및 백엔드 개발자가 이를 가져옵니다. 우리는 콘텐츠 레이아웃을 단순화한 다음 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개에 달했고, 모두 XNUMX~XNUMX주 안에 완료해야 했습니다. 그러나 내용의 형식이 약간 다릅니다. 그러나 실제로 더 이상의 개발 참여 없이 이러한 페이지를 즉석에서 조합하는 특정 템플릿 엔진이 만들어졌습니다.

— 실시간 조회수 및 통계 분석에 대한 요구사항도 있었습니다. 이를 위해 Prometheus를 사용한다는 것을 알고 있지만 분석을 위해 어떤 요구 사항을 충족해야 하며 어떻게 구현됩니까?

니콜라이 : 처음에는 향후 고객에게 최고의 콘텐츠를 적절하게 전달하는 방법을 이해하기 위해 A/B 테스트를 위한 수집 및 정보 수집에 대한 마케팅 요구 사항이 있습니다. 파트너 활동에 대한 일부 분석 및 귀하가 보는 분석(방문 카운터)에 대한 요구 사항도 있습니다. 모든 정보는 실시간으로 수집됩니다.

우리는 이 정보를 집계된 형태로 발표자에게도 제공할 수 있습니다. 즉, 특정 시점에 얼마나 많은 사람이 귀하를 시청하고 있었는지입니다. 동시에 연방법 152를 준수하기 위해 귀하의 개인 계정과 개인 데이터는 어떤 방식으로도 추적되지 않습니다.

플랫폼에는 보고서 참석 그래프를 작성하기 위해 실시간으로 사용자 활동(보고서의 몇 초를 시청했는지)을 측정하기 위한 마케팅 도구와 지표가 이미 있습니다. 이 데이터를 바탕으로 다음 회의를 더 좋게 만들 수 있는 연구가 진행되고 있습니다.

사기

— 사기 방지 메커니즘이 있습니까?

니콜라이 : 비즈니스 관점에서 시간이 촉박한 관계로 초기에는 불필요한 연결을 즉시 차단하도록 작업이 설정되지 않았습니다. 두 명의 사용자가 동일한 계정으로 로그인하면 콘텐츠를 볼 수 있습니다. 하지만 우리는 한 계정에서 동시 조회수가 몇 건인지 알고 있습니다. 그리고 우리는 몇몇 특히 악의적인 위반자를 금지했습니다.

블라디미르 : 다행히도 금지된 사용자 중 한 명이 이런 일이 발생한 이유를 이해했습니다. 그는 와서 사과하고 표를 사겠다고 약속했습니다.

— 이 모든 일이 발생하려면 모든 사용자를 처음부터 끝까지 완전히 추적해야 하며, 항상 그들이 무엇을 하고 있는지 알아야 합니다. 이 시스템은 어떻게 작동하나요?

블라디미르 : 저는 보고서의 성공 여부를 분석하거나 파트너에게 제공할 수 있는 분석 및 통계에 대해 이야기하고 싶습니다. 모든 클라이언트는 websocket 연결을 통해 특정 백엔드 클러스터에 연결됩니다. 거기 서 있네 헤이젤 캐스트. 각 기간의 각 클라이언트는 자신이 무엇을 하고 있는지, 어떤 트랙을 시청하고 있는지를 보냅니다. 그런 다음 이 정보는 빠른 Hazelcast 작업을 사용하여 집계되어 이 트랙을 보는 모든 사람에게 다시 전송됩니다. 구석에서 지금 우리와 함께 있는 사람이 몇 명인지 알 수 있습니다.

동일한 정보가 저장됩니다. 몽고 그리고 우리의 데이터 레이크로 이동하여 더 흥미로운 그래프를 만들 수 있는 기회를 얻습니다. 질문이 생깁니다. 이 보고서를 본 고유 사용자는 몇 명입니까? 우리는 간다 포스트그레스, 이 보고서의 ID로 온 모든 사람들의 핑이 있습니다. 고유한 항목을 수집하고 집계하여 이제 이해할 수 있습니다.

니콜라이 : 하지만 동시에 우리는 Prometheus로부터 실시간 데이터도 받습니다. 이는 모든 Kubernetes 서비스, Kubernetes 자체에 대해 설정됩니다. 그것은 절대적으로 모든 것을 수집하며 Grafana를 사용하면 실시간으로 모든 그래프를 작성할 수 있습니다.

블라디미르 : 한편으로는 추가 OLAP 처리를 위해 이를 다운로드합니다. 그리고 OLTP의 경우 애플리케이션은 모든 것을 Prometheus, Grafana에 다운로드하고 그래프도 수렴합니다!

- 그래프가 수렴하는 경우입니다.

동적 변화

— 동적 변경 사항이 어떻게 롤아웃되는지 알려주십시오. 시작 6분 전에 보고서가 취소된 경우 일련의 작업은 무엇입니까? 어떤 파이프라인이 작동하나요?

블라디미르 : 파이프라인은 매우 조건적입니다. 여러 가지 가능성이 있습니다. 첫 번째는 일정 생성 프로그램이 작동하여 일정을 변경했다는 것입니다. 수정된 일정은 Contentful에 업로드됩니다. 그 후 백엔드는 Contentful에서 이 컨퍼런스에 대한 변경 사항이 있음을 이해하고 이를 가져와 다시 빌드합니다. 모든 것은 웹소켓을 통해 수집되고 전송됩니다.

두 번째 가능성은 모든 일이 엄청난 속도로 일어날 때입니다. 편집자는 Contentful(텔레그램 링크, 발표자 프레젠테이션 등에 대한 링크)의 정보를 수동으로 변경하고 처음과 동일한 논리가 작동합니다.

니콜라이 : 페이지를 새로 고치지 않고도 모든 일이 발생합니다. 모든 변경 사항은 클라이언트에 대해 완벽하게 원활하게 발생합니다. 보고서 전환도 마찬가지입니다. 때가 되면 보고서와 인터페이스가 변경됩니다.

블라디미르 : 또한 타임라인에는 보고서 시작에 대한 시간 제한이 있습니다. 맨 처음에는 아무것도 없습니다. 그리고 빨간 줄무늬 위에 마우스를 올리면 어느 시점에서 방송 감독 덕분에 컷오프가 나타납니다. 감독은 방송의 올바른 시작을 설정하고, 백엔드는 이 변경 사항을 포착하고, 컨퍼런스 일정에 따라 전체 트랙 프레젠테이션의 시작 및 종료 시간을 계산하여 고객에게 보내고, 플레이어는 컷오프를 그립니다. 이제 사용자는 보고서의 시작과 끝으로 쉽게 이동할 수 있습니다. 이는 엄격한 비즈니스 요구 사항이었고 매우 편리하고 유용했습니다. 보고서의 실제 시작 시간을 찾는 데 시간을 낭비하지 않습니다. 그리고 미리보기를 하면 정말 멋질 것입니다.

전개

— 배포에 관해 문의하고 싶습니다. Kolya와 팀은 처음부터 모든 것이 펼쳐지는 전체 인프라를 설정하는 데 많은 시간을 보냈습니다. 말해 보세요, 그게 다 무엇으로 만들어졌나요?

니콜라이 : 기술적인 관점에서 볼 때, 처음에는 제품이 모든 공급업체에서 가능한 한 추상적이어야 한다는 요구 사항이 있었습니다. AWS로 오셔서 특별히 AWS, 특히 Yandex, Azure 등에서 Terraform 스크립트를 만드십시오. 정말 맞지 않았습니다. 우리는 어느 시점에 어딘가로 이동해야 했습니다.

처음 XNUMX주 동안 우리는 이를 더 잘 수행할 수 있는 방법을 끊임없이 찾았습니다. 결과적으로 우리는 이 경우 Kubernetes가 우리의 전부라는 결론에 도달했습니다. Kubernetes를 통해 자동 확장 서비스 생성, 자동 롤아웃 및 거의 모든 서비스를 즉시 사용할 수 있기 때문입니다. 당연히 모든 서비스는 Kubernetes, Docker와 함께 작동하도록 교육을 받아야 했고 팀도 배워야 했습니다.

두 개의 클러스터가 있습니다. 테스트 및 생산. 하드웨어 및 설정 측면에서 완전히 동일합니다. 우리는 인프라를 코드로 구현합니다. 모든 서비스는 자동 파이프라인을 사용하여 기능 브랜치, 마스터 브랜치, 테스트 브랜치 및 GitLab의 세 가지 환경으로 자동 롤아웃됩니다. 이는 GitLab에 최대한 통합되며 Elastic, Prometheus와 최대한 통합됩니다.

모든 테스트, 통합, 기능 테스트 실행, 환경에 대한 통합 테스트 및 부하 테스트를 통해 모든 환경에 변경 사항을 신속하게(백엔드의 경우 10분 이내, 프런트엔드의 경우 5분 이내) 롤아웃할 수 있는 기회를 얻습니다. 테스트 환경은 우리가 프로덕션에서 원하는 것과 거의 동일합니다.

테스트 정보

— 거의 모든 것을 테스트하는데, 모든 것을 어떻게 작성했는지 믿기 어렵습니다. 백엔드 테스트에 대해 알려주실 수 있나요? 모든 것이 얼마나 다루어지고, 어떤 테스트를 수행하나요?

블라디미르 : 두 가지 유형의 테스트가 작성되었습니다. 첫 번째는 구성 요소 테스트입니다. 전체 스프링 적용 및 베이스의 리프트 레벨 테스트 테스트 컨테이너. 이는 최고 수준의 비즈니스 시나리오에 대한 테스트입니다. 나는 기능을 테스트하지 않습니다. 우리는 몇 가지 큰 것들만 테스트합니다. 예를 들어, 테스트에서 바로 사용자 로그인 프로세스, 사용자가 갈 수 있는 티켓 요청, 스트림 시청을 위한 액세스 요청이 에뮬레이션됩니다. 매우 명확한 사용자 시나리오.

실제로 환경에서 실행되는 소위 통합 테스트에서도 거의 동일한 작업이 구현됩니다. 실제로 프로덕션의 다음 배포가 출시되면 실제 기본 시나리오도 프로덕션에서 실행됩니다. 동일한 로그인, 티켓 요청, CloudFront에 대한 액세스 요청, 스트림이 실제로 내 권한과 연결되는지 확인하고 디렉터의 인터페이스를 확인합니다.

현재 약 70개의 구성 요소 테스트와 약 40개의 통합 테스트가 진행 중입니다. 커버력은 거의 95%에 가깝습니다. 이는 구성요소용이고 통합용이 아니며 그다지 많이 필요하지 않습니다. 프로젝트에 모든 종류의 코드 생성이 포함된다는 점을 고려하면 이는 매우 좋은 지표입니다. 우리가 XNUMX개월 동안 한 일을 다른 방법은 없었습니다. 우리가 수동으로 테스트하고 테스터에게 기능을 제공하면 그녀가 버그를 찾아 수정을 위해 우리에게 반환한다면 코드 디버깅을 위한 왕복 여행은 매우 길어지고 마감 기한을 지키지 못할 것이기 때문입니다.

니콜라이 : 일반적으로 일부 기능을 변경할 때 전체 플랫폼에서 회귀를 수행하려면 이틀 동안 앉아서 여기저기 찔러야 합니다.

블라디미르 : 그래서 기능을 추정할 때 간단한 펜 4개와 웹소켓 1개에 4일이 필요하다고 했더니 Kolya가 이를 허용해주는 것이 대성공입니다. 그는 이 2일 동안 XNUMX가지 유형의 테스트가 포함된다는 사실에 이미 익숙하며, 그러면 성공할 가능성이 높습니다.

니콜라이 : 나는 또한 140개의 테스트를 작성했습니다: 구성 요소 + 기능, 동일한 작업을 수행합니다. 동일한 시나리오가 모두 프로덕션, 테스트 및 프로덕션에서 테스트됩니다. 최근에는 기능적 기본 UI 테스트도 추가했습니다. 이런 식으로 우리는 무너질 수 있는 가장 기본적인 기능을 다룹니다.

블라디미르 : 물론 부하 테스트에 대해 이야기할 가치가 있습니다. 모든 것이 어떻게 진행되고 있는지, Rabbit에 무슨 일이 일어나고 있는지, JVM에 무슨 일이 일어나고 있는지, 실제로 얼마나 많은 메모리가 필요한지 이해하려면 실제 부하에 가까운 부하에서 플랫폼을 테스트해야 했습니다.

— 스트림 측에서 테스트하고 있는 것이 있는지는 잘 모르겠지만, 밋업을 했을 때 트랜스코더에 문제가 있었던 것으로 기억합니다. 스트림을 테스트했습니까?

아르템: 반복적으로 테스트되었습니다. 모임을 조직합니다. 모임을 조직하는 과정에서 약 2300장의 JIRA 티켓이 있었습니다. 이것은 사람들이 모임을 만들기 위해 하는 일반적인 일들입니다. 우리는 플랫폼의 일부를 Kirill Tolkachev가 운영하는 모임을 위한 별도의 페이지로 가져왔습니다(토크크브).

솔직히 큰 문제는 없었습니다. 말 그대로 CloudFront에서 캐싱 버그를 몇 번 발견하여 매우 빠르게 해결했습니다. 정책을 재구성하기만 하면 됩니다. 사이트의 스트리밍 시스템에는 사람들의 버그가 훨씬 더 많았습니다.

컨퍼런스 동안 더 많은 장비와 서비스를 다루기 위해 여러 수출업체에 대한 글을 더 작성해야 했습니다. 어떤 곳에서는 단지 측정을 위해 자전거를 직접 만들어야 했습니다. AV(오디오-비디오) 하드웨어의 세계는 그다지 장밋빛이 아닙니다. 단순히 영향을 미칠 수 없는 일종의 장비 "API"가 있습니다. 그리고 필요한 정보를 얻을 수 있다는 것은 사실과는 거리가 멀습니다. 하드웨어 공급업체는 정말 느리기 때문에 원하는 것을 얻는 것이 거의 불가능합니다. 전체적으로 100개가 넘는 하드웨어가 있는데 필요한 것을 돌려주지 않으며 이상하고 중복되는 내보내기 프로그램을 작성합니다. 덕분에 적어도 어떻게든 시스템을 디버깅할 수 있습니다.

Оборудование

— 컨퍼런스가 시작되기 전에 추가 장비를 부분적으로 구입했던 일이 기억납니다.

아르템: 우리는 컴퓨터, 노트북, 배터리 팩을 구입했습니다. 현재 우리는 전기 없이 40분 동안 살아갈 수 있다. 40월에는 상트페테르부르크에 심한 뇌우가 내려 정전이 되기도 했습니다. 동시에 여러 제공업체가 서로 다른 지점에서 광 링크를 가지고 우리에게 왔습니다. 이것은 실제로 XNUMX분의 건물 가동 중단 시간이며, 그 동안 조명, 사운드, 카메라 등이 작동하게 됩니다.

— 인터넷에도 비슷한 이야기가 있습니다. 저희 스튜디오가 위치한 사무실에서는 층간으로 치열한 그물을 끌고 다녔습니다.

아르템: 층 사이에는 20Gbit의 광섬유가 있습니다. 바닥을 따라 더 가면 광학 장치가 있는 곳, 광학 장치가 없는 곳이 있지만 여전히 기가비트 채널보다 채널 수가 적습니다. 회의 트랙 사이에 비디오를 실행합니다. 일반적으로 자체 인프라에서 작업하는 것은 매우 편리하지만 사이트의 오프라인 회의에서는 거의 수행할 수 없습니다.

— JUG Ru Group에서 일하기 전에 저는 Grafana에서 구축한 모든 지표가 포함된 대형 모니터가 있는 오프라인 회의의 하드웨어 룸이 밤새 어떻게 설정되었는지 보았습니다. 이제는 개발팀이 앉아 회의 중에 일부 버그를 수정하고 기능을 개발하는 본사실도 있습니다. 동시에 대형 화면에 표시되는 모니터링 시스템도 있습니다. Artyom, Kolya 및 다른 사람들은 앉아서 모든 것이 떨어지지 않고 아름답게 작동하는지 확인합니다.

호기심과 문제

— 우리가 Amazon을 통해 스트리밍하고, 웹 플레이어가 있고, 모든 것이 다양한 프로그래밍 언어로 작성되었으며, 내결함성과 기타 비즈니스 요구 사항이 제공된다는 사실에 대해 잘 말씀해 주셨습니다. 여기에는 법인에 지원되는 개인 계정과 OAuth 2.0을 사용하여 누군가와 통합할 수 있으며 사기 방지, 사용자 차단 기능이 있습니다. 우리는 잘 해냈고 모두 테스트를 거쳤기 때문에 변경 사항을 동적으로 출시할 수 있습니다.

나는 무언가를 시작하는 데 어떤 이상한 점이 있었는지 알고 싶습니다. 백엔드, 프론트엔드를 개발할 때 이상한 상황이 발생했는데 어떻게 해야 할지 몰랐던 이상한 상황이 있었나요?

블라디미르 : 제가 보기엔 이런 일이 최근 XNUMX개월 동안만 있었던 것 같습니다. 매일. 보시다시피 머리카락이 다 뽑혔어요.

3개월 후 Vladimir Krasilshchik, 어떤 종류의 게임이 나왔고 아무도 그걸로 무엇을 해야할지 이해하지 못했습니다.

매일 이런 일이 있었는데, 그것을 가져다가 머리를 찢거나 다른 사람이없고 오직 당신 만이 할 수 있다는 것을 깨닫는 그런 순간이있었습니다. 우리의 첫 번째 큰 이벤트는 TechTrain이었습니다. 6월 2일 오전 2.0시에 우리는 아직 프로덕션 환경을 출시하지 않았지만 Kolya는 이를 출시하고 있었습니다. 그리고 개인 계정은 OAuth2.0을 사용하는 인증 서버로 작동하지 않았습니다. 우리는 플랫폼을 연결하기 위해 이를 OAuth18 공급자로 전환했습니다. 나는 아마 XNUMX시간 연속으로 일했고, 컴퓨터를 보았지만 아무것도 보지 못했고, 그것이 왜 작동하지 않는지 이해하지 못했고, Kolya는 원격으로 내 코드를 보고 Spring 구성에서 버그를 찾았습니다. , 그것을 찾았고 LC가 작동했고 생산에서도 마찬가지였습니다.

니콜라이 : 그리고 TechTrain이 출시되기 한 시간 전에 말이죠.

수많은 별들이 이곳에 모였습니다. 우리에게는 슈퍼 팀이 있었기 때문에 매우 운이 좋았고 모두가 온라인에서 수행한다는 아이디어에 영감을 받았습니다. 지난 XNUMX개월 동안 우리는 '유튜브를 만들었다'는 사실에 이끌렸습니다. 나는 머리를 찢는 것을 허용하지 않았지만 실제로 모든 것이 오래 전에 계산 되었기 때문에 모든 것이 잘 될 것이라고 모든 사람에게 말했습니다.

성능 정보

— 한 트랙에 몇 명이 사이트에 있었는지 알려주실 수 있나요? 성능 문제가 있었나요?

니콜라이 : 이미 말했듯이 성능 문제는 없었습니다. 한 리포트에 참석한 최대 인원은 1300명인데, 이는 하이젠버그에 있습니다.

— 로컬 시청에 문제는 없었나요? 그리고 그것이 어떻게 작동하는지에 대한 기술적인 설명을 다이어그램과 함께 갖는 것이 가능합니까?

니콜라이 : 이에 대해서는 나중에 기사를 작성하겠습니다.

로컬에서 스트림을 디버깅할 수도 있습니다. 컨퍼런스가 시작되자 우리가 항상 시청할 수 있는 프로덕션 스트림이 등장했기 때문에 더욱 쉬워졌습니다.

블라디미르 : 제가 알기로는 프론트엔드 개발자들이 로컬에서 모의 ​​작업을 했고, 그다음 프론트에 있는 개발자들에게 롤아웃하는 시간도 짧기 때문에(5분) 인증서에 무슨 일이 일어나고 있는지 확인하는데 문제가 없었습니다.

— 로컬에서도 모든 것이 테스트되고 디버깅됩니다. 이는 우리가 모든 기술적 기능을 포함하는 기사를 작성하고, 보여주고, 다이어그램을 통해 모든 것을 설명할 것임을 의미합니다.

블라디미르 : 가져가서 반복하시면 됩니다.

- 3개월 안에요.

합계

— 함께 설명하는 모든 것이 소규모 팀에서 XNUMX개월 만에 수행했다는 점을 고려하면 멋져 보입니다.

니콜라이 : 큰 팀은 이런 일을 하지 않을 것이다. 그러나 서로 매우 긴밀하고 원활하게 의사소통하고 합의에 도달할 수 있는 소수의 사람들은 그럴 수 있습니다. 그들은 모순이 없으며 아키텍처는 이틀 만에 발명되었으며 최종 완료되었으며 실제로 변경되지 않았습니다. 기능 요청 및 변경 사항이 쌓이는 측면에서 들어오는 비즈니스 요구 사항을 매우 엄격하게 촉진합니다.

— 여름 컨퍼런스가 이미 열렸을 때 추가 작업 목록에는 무엇이 있었나요?

니콜라이 : 예를 들어 크레딧. 영상에 크리프 라인이 나타나며, 표시되는 콘텐츠에 따라 영상의 일부 위치에 팝업이 나타납니다. 예를 들어, 발표자가 청중에게 질문을 하려고 하면 화면에 투표 팝업이 뜨고, 투표 결과에 따라 발표자 자신에게 다시 돌아가는 식이다. 프레젠테이션 자체에서 보고서에 대한 좋아요, 마음, 평가 형태의 일종의 소셜 활동을 통해 나중에 피드백 양식으로 인해 방해받지 않고 적절한 순간에 피드백을 작성할 수 있습니다. 처음에는 이렇습니다.

또한 스트리밍 및 회의를 제외한 전체 플랫폼에 회의 후 상태도 추가합니다. 이는 재생 목록(사용자가 편집한 재생 목록 포함)이며 과거 다른 회의의 콘텐츠일 수 있으며 통합되고 레이블이 지정되어 사용자가 액세스할 수 있으며 당사 웹 사이트에서도 볼 수 있습니다(live.jugru.org).

— 여러분, 답변해 주셔서 정말 감사합니다!

독자 중에 여름 컨퍼런스에 참석한 분들이 계시다면, 선수와 방송에 대한 감상을 나눠주세요. 무엇이 편리했는지, 무엇이 짜증났는지, 앞으로 어떤 모습을 보고 싶나요?

플랫폼에 관심이 있고 "전투"에서 보고 싶다면 우리는 이를 다시 사용합니다. 가을 겨울 회의. 그 범위는 매우 다양하므로 귀하에게 적합한 것이 거의 확실합니다.

출처 : habr.com