この春はとても陽気な気候に恵まれました。 パンデミックのため、夏のカンファレンスをオンラインに移行する必要があることが明らかになりました。 そして、それらをオンラインで効率的に実行するには、既製のソフトウェア ソリューションは私たちには適しておらず、独自のソフトウェア ソリューションを作成する必要がありました。 そして、これを行うのにXNUMXか月かかりました。

刺激的な XNUMX か月だったことは明らかです。 しかし、外から見ると、オンライン会議プラットフォームとは何なのか、完全に明らかではありません。 どのような部品で構成されていますか? そこで、夏の DevOops カンファレンスの最後に、私はこのタスクの責任者に次の質問をしました。

• ニコライ・モルチャノフ - JUG Ru Group テクニカルディレクター。
• Vladimir Krasilshchik は、バックエンドで働く実用的な Java プログラマーです (Java カンファレンスで彼のレポートを見ることもできます)。
• Artyom Nikonov はすべてのビデオ ストリーミングを担当しています。

ちなみに、秋冬のカンファレンスでは、同じプラットフォームの改良版を使用する予定です。そのため、多くの Habra 読者が引き続きそのユーザーとなるでしょう。

大局

――チーム構成はどのような感じでしたか？

ニコライ・モルチャノフ： アナリスト、デザイナー、テスター、フロントエンダー XNUMX 名、バックエンド XNUMX 名がいます。 そしてもちろん、T字のスペシャリストです！

—全体的にはどのようなプロセスでしたか？

ニコライ： 15月中旬まではオンライン対応の準備がまったく整っていませんでした。 そして XNUMX 月 XNUMX 日、オンライン カルーセル全体が回転し始めました。 私たちはいくつかのリポジトリをセットアップし、基本的なアーキテクチャについて計画し、議論し、すべてを XNUMX か月で実行しました。

もちろん、これは、計画、アーキテクチャ、機能の選択、機能の投票、機能のポリシー、設計、開発、テストという古典的な段階を経ました。 その結果、6 月 XNUMX 日にすべてを実稼働環境にロールアウトしました。 テックトレイン。 すべての期間は90日でした。

— 約束したことは達成できましたか？

ニコライ： 私たちは現在、DevOops カンファレンスにオンラインで参加しているので、それがうまくいったことになります。 私は個人的に最も重要なことを約束しました。それは、顧客がオンライン会議を行うためのツールを提供するということです。

課題は、チケット所有者にカンファレンスをブロードキャストできるツールを提供してほしいということでした。

すべての計画はいくつかの段階に分割され、すべての機能 (グローバル約 30) は 4 つのカテゴリに分類されました。

• 私たちは必ずそうします（彼らなしでは生きていけません）、
• これは XNUMX 番目に行います。
• 私たちは決してそんなことはしませんが、
• そして私たちは決して、決してそんなことはしません。

最初の XNUMX つのカテゴリからすべての機能を作成しました。

— 合計 600 の JIRA 課題が作成されたと聞きました。 13 か月で 5 個のマイクロサービスを作成しましたが、それらは Java だけで書かれたものではないと思われます。 さまざまなテクノロジーを使用し、Amazon には XNUMX つのアベイラビリティ ゾーンに XNUMX つの Kubernetes クラスターと XNUMX つの RTMP ストリームがあります。

次に、システムの各コンポーネントを個別に見てみましょう。

ストリーミング

— すでにビデオ画像があり、それがいくつかのサービスに送信されるところから始めましょう。 Artyom、このストリーミングがどのようにして起こるのか教えてください。

アルチョム・ニコノフ: 一般的なスキームは次のようになります。カメラからの画像 -> コントロール ルーム -> ローカル RTMP サーバー -> Amazon -> ビデオ プレーヤー。 さらに詳しく それについて書きました XNUMX月のハブレで。

一般に、これを行うには XNUMX つのグローバルな方法があります。ハードウェアを使用するか、ソフトウェア ソリューションに基づくかのいずれかです。 リモートスピーカーの場合はソフトウェアの方が簡単なので、ソフトウェアのルートを選択しました。 別の国の講演者にハードウェアを持ち込むことが常に可能であるとは限りませんが、ソフトウェアを講演者に配信することはより簡単で確実であるように思えます。

ハードウェアの観点から見ると、一定数のカメラ (スタジオとリモート スピーカー) とスタジオ内に一定数のリモコンがあり、放送中にテーブルの真下で修理する必要がある場合があります。

これらのデバイスからの信号は、キャプチャ カード、入出力カード、サウンド カードを備えたコンピュータに入力されます。 そこで信号は混合され、レイアウトに組み立てられます。

4スピーカーのレイアウト例

4スピーカーのレイアウト例

さらに、継続的なブロードキャストは XNUMX 台のコンピュータの助けを借りて提供されます。XNUMX 台のメイン マシンと XNUMX 台の稼働マシンが順番に存在します。 最初のコンピューターは最初のレポートを収集し、XNUMX 番目のコンピューターは休憩、最初のコンピューターは次のレポート、XNUMX 番目のコンピューターは次の休憩、というようになります。 そして、メインマシンは最初のものとXNUMX番目のものを混合します。

これにより一種の三角形が形成され、これらのノードのいずれかに障害が発生した場合でも、品質を損なうことなく、迅速にコンテンツをクライアントに配信し続けることができます。 そんな状況がありました。 カンファレンスの最初の週に、私たちは XNUMX 台のマシンを修理し、電源を入れたり切ったりしました。 人々は私たちの回復力に満足しているようです。

次に、コンピュータからのストリームはローカル サーバーに送られます。ローカル サーバーには、RTMP ストリームのルーティングとレコードのバックアップという XNUMX つのタスクがあります。 したがって、複数の記録ポイントがあります。 ビデオストリームは、Amazon SaaS サービス上に構築されたシステムの一部に送信されます。 を使用しております メディアライブ、S3、クラウドフロント。

ニコライ： ビデオが視聴者に届くまでに何が起こっているのでしょうか? 何とかカットしないといけないですよね？

アルチョム: 弊社側でビデオを圧縮し、MediaLive に送信します。 そこでトランスコーダーを起動します。 彼らはビデオをリアルタイムでいくつかの解像度にトランスコードし、人々が携帯電話や田舎の貧弱なインターネットなどを通じてビデオを視聴できるようにします。 次に、これらのストリームは次のように分割されます。 チャンク、これがプロトコルの仕組みです HLS。 これらのチャンクへのポインターを含むプレイリストをフロントエンドに送信します。

— 1080p の解像度を使用していますか?

アルチョム: 私たちのビデオの幅は1080p - 1920ピクセルと同じですが、高さは少し低く、画像はより長くなります。これには理由があります。

プレイヤー

— Artyom は、ビデオがどのようにストリームに取り込まれ、異なる画面解像度の異なるプレイリストにどのように分散され、チャンクに分割されてプレーヤーに取り込まれるかを説明しました。 Kolya、今度はこれがどのような種類のプレーヤーなのか、ストリームをどのように消費するのか、なぜ HLS なのか教えてください。

ニコライ： すべてのカンファレンスの視聴者が視聴できるプレーヤーがあります。

本質的に、これはライブラリのラッパーです hls.js, そこには他の多くの選手が書かれています。 しかし、私たちは非常に特殊な機能を必要としていました。巻き戻して、その人がいる場所、現在どのレポートを見ているかをマークする機能です。 また、独自のレイアウト、あらゆる種類のロゴ、その他組み込みのものすべても必要でした。 したがって、独自のライブラリ (HLS 上のラッパー) を作成し、サイトに埋め込むことにしました。

これはルート機能なので、ほぼ最初に実装されました。 そして、その周りにすべてが成長しました。

実際、プレーヤーは認証を通じて、時間と品質に関連付けられたチャンクへのリンクを含むプレイリストをバックエンドから受け取り、必要なものをダウンロードしてユーザーに表示し、途中でいくつかの「魔法」を実行します。

タイムラインの例

— すべてのレポートのタイムラインを表示するボタンがプレーヤーに組み込まれています...

ニコライ： はい、ユーザー ナビゲーションの問題はすぐに解決されました。 XNUMX 月中旬、私たちは各カンファレンスを別の Web サイトで放送せず、すべてを XNUMX つの Web サイトに統合することを決定しました。 フルパスチケットのユーザーは、ライブブロードキャストと過去の会議の録画の両方で、さまざまなカンファレンスを自由に切り替えることができます。

また、ユーザーが現在のストリームをナビゲートし、トラックを切り替えるのを容易にするために、「全体ブロードキャスト」ボタンと、トラックとレポートを切り替えるための水平レポート カードを作成することにしました。 キーボードコントロールあり。

――技術的に難しい点はありましたか？

ニコライ： スクロール バーがあり、そこにさまざまなレポートの開始点がマークされていました。

— 結局のところ、スクロールバーにこれらのマークを実装したのは、YouTubeが同様のことを行う前だったのですか？

アルチョム: 当時はベータ版でした。 過去 XNUMX 年間にわたってユーザーを対象に部分的にテストしてきたため、これはかなり複雑な機能のようです。 そして今、それが販売に至った。

ニコライ： しかし実際には、より早く販売できるようになりました。 正直なところ、このシンプルな機能の背後には、プレーヤー内で膨大な量のバックエンド、フロントエンド、計算、数学が存在します。

フロントエンド

— 私たちが表示するこのコンテンツ (スピーチ カード、講演者、ウェブサイト、スケジュール) がどのようにしてフロントエンドに届くのかを考えてみましょう。

ウラジミール・クラシルシチク： 当社にはいくつかの社内 IT システムがあります。 すべてのレポートとすべての発言者を入力するシステムがあります。 講演者が会議に参加するまでにはプロセスがあります。 講演者がアプリケーションを送信すると、システムがそれをキャプチャし、それに従ってレポートが作成される特定のパイプラインが存在します。

講演者はパイプラインをこのように見ています

このシステムは弊社社内で開発したものです。

次に、個々のレポートからスケジュールを作成する必要があります。 ご存知のとおり、これは NP 困難な問題ですが、なんとか解決できます。 これを行うには、スケジュールを生成し、それをサードパーティのクラウド サービス Contentful にアップロードする別のコンポーネントを起動します。 そこでは、すべてがすでにテーブルのように見え、その中にはカンファレンスの日があり、その日にはタイムスロットがあり、そのスロットにはレポート、休憩、またはスポンサー活動が含まれています。 したがって、私たちが見るコンテンツはサードパーティのサービスにあります。 そしてそれを現場に伝えるのが仕事です。

このサイトはプレーヤーが含まれる単なるページであるように見えますが、ここでは複雑なことは何もありません。 そうではないことを除いて。 このページの背後にあるバックエンドは Contentful に移動し、そこからスケジュールを取得し、いくつかのオブジェクトを生成してフロントエンドに送信します。 私たちのプラットフォームのすべてのクライアントが行う WebSocket 接続を使用して、バックエンドからフロントエンドにスケジュールの更新を送信します。

実際のケース: 講演者は会議の途中で転職しました。 彼の雇用主の社章を変更する必要があります。 これはバックエンドからどのようにして起こるのでしょうか? 更新は WebSocket 経由ですべてのクライアントに送信され、フロントエンド自体がタイムラインを再描画します。 これらすべてがシームレスに行われます。 クラウド サービスといくつかのコンポーネントを組み合わせることで、このすべてのコンテンツを生成してフロントに提供する機会が得られます。

ニコライ： ここで、私たちのサイトが古典的な SPA アプリケーションではないことを明確にすることが重要です。 これは、レイアウトベースのレンダリングされた Web サイトであり、SPA でもあります。 実際、Google はこのサイトをレンダリングされた HTML として認識します。 これは SEO とユーザーへのコンテンツ配信に適しています。 ページを表示する前に 1,5 メガバイトの JavaScript が読み込まれるのを待たずに、すでにレンダリングされたページがすぐに表示され、レポートを切り替えるたびにそれが感じられます。 コンテンツはすでに準備ができており、適切な場所に投稿されるため、すべてが XNUMX 秒で行われます。

— テクノロジーを列挙して、上記すべての下に線を引いてみましょう。 Tyoma 氏は、Amazon ストリームが 5 つあり、そこでビデオと音声を配信していると述べました。 そこには 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 条を遵守するため、お客様の個人アカウントと個人データはいかなる方法でも追跡されません。

このプラットフォームには、レポートへの参加状況のグラフを作成するために、ユーザーのアクティビティ (誰がレポートの何秒目を見たのか) をリアルタイムで測定するためのマーケティング ツールとメトリクスがすでに組み込まれています。 このデータに基づいて、次回のカンファレンスをより良いものにするための研究が行われています。

詐欺

— 不正防止メカニズムはありますか?

ニコライ： ビジネスの観点からすると時間枠が厳しいため、タスクは当初、不要な接続を即座にブロックするように設定されていませんでした。 XNUMX 人のユーザーが同じアカウントでログインした場合、コンテンツを表示できます。 しかし、XNUMX つのアカウントからの同時視聴数はわかっています。 そして、特に悪質な違反者数名を禁止しました。

ウラジミール： 名誉のために言っておきますが、禁止されたユーザーの XNUMX 人は、なぜこれが起こったのかを理解していました。 彼はやって来て謝罪し、チケットを買うと約束した。

— これらすべてを実現するには、すべてのユーザーを入口から出口まで完全に追跡し、彼らが何をしているのかを常に把握する必要があります。 このシステムはどのように機能するのでしょうか?

ウラジミール： 分析と統計についてお話したいと思います。分析と統計は、レポートを成功させるために分析したり、パートナーに提供したりできます。 すべてのクライアントは、WebSocket 接続を介して特定のバックエンド クラスターに接続されます。 そこに立っています ハシバミ。 各クライアントは、各時間帯で、何をしていて、どのトラックを見ているかを送信します。 次に、この情報は高速 Hazelcast ジョブを使用して集約され、これらのトラックを視聴するすべてのユーザーに送信されます。 隅には今何人の人がいるかがわかります。

同じ情報が保存されています モンゴ そしてデータレイクに移動し、そこからより興味深いグラフを構築する機会が得られます。 このレポートを閲覧したユニーク ユーザーの数は何人ですか? 私たちは行く Postgres、このレポートの ID でアクセスしたすべての人の ping があります。 ユニークなものを集めて集計して、理解できるようになりました。

ニコライ： しかし同時に、私たちはプロメテウスからリアルタイムのデータも受け取ります。 これは、すべての Kubernetes サービス、および Kubernetes 自体に対して設定されます。 あらゆるものを収集し、Grafana を使用するとリアルタイムであらゆるグラフを構築できます。

ウラジミール： 一方では、さらなる OLAP 処理のためにこれをダウンロードします。 OLTP の場合、アプリケーションはすべてを Prometheus、Grafana にダウンロードし、グラフも収束します。

- グラフが収束する場合にこれが当てはまります。

動的な変化

— 動的な変更がどのように展開されるのか教えてください。開始の 6 分前にレポートがキャンセルされた場合、一連のアクションはどうなりますか? どのパイプラインが機能しますか?

ウラジミール： パイプラインは非常に条件付きです。 いくつかの可能性があります。 XNUMX つ目は、スケジュール生成プログラムが動作してスケジュールを変更したことです。 変更されたスケジュールはContentfulにアップロードされます。 その後、バックエンドは Contentful でこの会議に変更があることを認識し、それを取得して再構築します。 すべてが WebSocket 経由で収集および送信されます。

XNUMX 番目の可能性は、すべてが猛烈なペースで起こった場合です。編集者が Contentful 内の情報 (テレグラムへのリンク、講演者のプレゼンテーションなど) を手動で変更し、最初と同じロジックが機能します。

ニコライ： ページを更新せずにすべてが行われます。 すべての変更はクライアントに対して完全にシームレスに行われます。 レポートの切り替えについても同様です。 時間が来ると、レポートとインターフェイスが変わります。

ウラジミール： また、タイムラインのレポートの開始には制限時間があります。 一番最初は何もありません。 そして、赤いストライプの上にマウスを置くと、放送ディレクターのおかげで、ある時点でカットオフが表示されます。 ディレクターがブロードキャストの正しい開始時間を設定し、バックエンドがこの変更を取得し、カンファレンスのスケジュールに従ってトラック全体のプレゼンテーションの開始時刻と終了時刻を計算し、それをクライアントに送信し、プレーヤーがカットオフを描画します。 これで、ユーザーはレポートの最初と最後に簡単に移動できるようになりました。 これは厳格なビジネス要件であり、非常に便利で役に立ちました。 レポートの実際の開始時刻を見つけるのに時間を無駄にする必要はありません。 そして試写をしてみると、本当に素晴らしいものになるでしょう。

展開

――展開についてお聞きしたいのですが。 Kolya とチームは、最初に多くの時間を費やして、すべてが展開されるインフラストラクチャ全体をセットアップしました。 教えてください、これは一体何でできているのですか？

ニコライ： 技術的な観点から見ると、私たちは当初、製品がどのベンダーに対しても可能な限り抽象的なものであることを要求していました。 AWS にアクセスして、具体的には AWS、具体的には Yandex、または Azure などから Terraform スクリプトを作成します。 あまり合わなかった。 私たちはいつかどこかに移動しなければなりませんでした。

最初の XNUMX 週間、私たちはこれをより良く行う方法を常に探していました。 その結果、この場合は Kubernetes がすべてであるという結論に達しました。Kubernetes を使用すると、自動的にスケーリングするサービスの作成、自動ロールアウトが可能になり、ほぼすべてのサービスをすぐに利用できるからです。 当然のことながら、すべてのサービスは Kubernetes や Docker と連携できるようにトレーニングする必要があり、チームも学習する必要がありました。

クラスターが XNUMX つあります。 テストと本番。 ハードウェアと設定の点ではまったく同じです。 インフラストラクチャをコードとして実装します。 すべてのサービスは、自動パイプラインを使用して、フィーチャー ブランチ、マスター ブランチ、テスト ブランチ、GitLab の XNUMX つの環境に自動的にロールアウトされます。 これは GitLab に最大限に統合され、Elastic、Prometheus にも最大限に統合されます。

すべてのテスト、統合、機能テストの実行、環境での統合テスト、および負荷テストによるテストをすべての環境に迅速に (バックエンドの場合は 10 分以内、フロントエンドの場合は 5 分以内) ロールアウトする機会が得られます。本番環境で取得したいものとほぼ同じテスト環境。

テストについて

— ほとんどすべてをテストしていますが、すべてをどうやって書いたのか信じられません。 バックエンドのテストについて教えてください。すべてがどの程度カバーされているか、どのようなテストが行​​われていますか?

ウラジミール： XNUMX 種類のテストが作成されました。 XNUMX つ目はコンポーネントのテストです。 スプリングアプリケーション全体とベースインのリフトレベルテスト テストコンテナ。 これは最高レベルのビジネス シナリオのテストです。 機能のテストはしません。 私たちはいくつかの大きなことだけをテストします。 たとえば、テストでは、ユーザーへのログインのプロセス、このユーザーの行き先へのチケットのリクエスト、およびストリームを視聴するためのアクセスのリクエストがエミュレートされます。 非常に明確なユーザーシナリオ。

ほぼ同じことが、実際に環境上で実行される、いわゆる統合テストにも実装されます。 実際、本番環境での次のデプロイメントが展開されると、実際の基本シナリオも本番環境で実行されます。 同じログイン、チケットのリクエスト、CloudFront へのアクセスのリクエスト、ストリームが実際に私の権限に接続していることの確認、ディレクターのインターフェースの確認。

現時点では、約 70 のコンポーネント テストと約 40 の統合テストを実行しています。 カバレッジは 95% に非常に近いです。 これはコンポーネントに関するものであり、統合に関するものではありません。必要なものはそれほど多くありません。 プロジェクトにはあらゆる種類のコード生成が含まれることを考えると、これは非常に良い指標です。 XNUMXか月でやったことをやるには他に方法はありませんでした。 なぜなら、私たちが手動でテストしてテスターに​​機能を提供し、テスターがバグを見つけて修正するために私たちに返してくれるとしたら、コードをデバッグするためのこのラウンドトリップが非常に長くなり、期限を守れなくなるからです。

ニコライ： 従来、何らかの機能を変更するときにプラットフォーム全体で回帰を実行するには、XNUMX 日間座ってあちこちを調査する必要がありました。

ウラジミール： したがって、機能を見積もるときに、4 つの単純なペンと 1 つの WebSocket に 4 日必要だと言うと、Kolya はそれを許可します。これは大成功です。 彼は、この 2 日間に XNUMX 種類のテストが含まれるという事実にすでに慣れており、おそらくうまくいくでしょう。

ニコライ： また、同じことを行うコンポーネント + 関数の 140 個のテストも作成しました。 すべて同じシナリオが、本番環境、テスト環境、そして本番環境でテストされます。 最近、機能的な基本的な UI テストも追加しました。 このようにして、バラバラになる可能性のある最も基本的な機能をカバーします。

ウラジミール： もちろん、負荷テストについて話すことは価値があります。 すべてがどのようになっているのか、Rabbit で何が起こっているのか、JVM で何が起こっているのか、実際に必要なメモリの量を理解するには、実際の負荷に近い負荷でプラットフォームをテストする必要がありました。

— ストリーム側で何かテストしているかどうかは定かではありませんが、ミートアップを行ったときにトランスコーダーに問題があったことを覚えています。 ストリームをテストしましたか?

アルチョム: 繰り返しテストされました。 交流会の企画。 ミートアップを企画する過程で、約 2300 枚の JIRA チケットがありました。 これらは、人々が交流会を開くために行った一般的なことです。 私たちはプラットフォームの一部をミートアップ用の別のページに移しました。このページはキリル・トルカチョフが運営していました (トーククブ).

正直に言うと、大きな問題はありませんでした。 文字通り、CloudFront でキャッシュのバグを数回発見しましたが、ポリシーを再構成するだけで非常に迅速に解決しました。 人々やサイト上のストリーミング システムには、より多くのバグがありました。

カンファレンス中に、より多くの機器とサービスをカバーするために、さらにいくつかの輸出業者を書く必要がありました。 場所によっては、測定のためだけに自転車を自作しなければならないところもありました。 AV (オーディオビデオ) ハードウェアの世界はあまりバラ色ではありません。単純に影響を与えることのできない、ある種の機器の「API」が存在します。 そして、必要な情報を入手できるかというと、決してそうではありません。 ハードウェア ベンダーの対応は非常に遅く、希望するものをベンダーから入手することはほぼ不可能です。 合計 100 個を超えるハードウェアがあり、必要なものは返されず、奇妙で冗長なエクスポーターを作成することになります。そのおかげで、少なくとも何らかの形でシステムをデバッグできます。

機器

— カンファレンスの開始前に追加の機器を部分的に購入したことを覚えています。

アルチョム: 私たちはコンピューター、ラップトップ、バッテリーパックを購入しました。 現在、私たちは電気なしで40分間生活することができます。 40月にサンクトペテルブルクでは激しい雷雨があり、そのような停電が発生しました。 同時に、いくつかのプロバイダーがさまざまなポイントから光リンクを使用して私たちにやって来ます。 これは実際には XNUMX 分間の建物のダウンタイムであり、その間、照明が点灯し、音響、カメラなどが動作します。

— インターネットに関しても同様の話があります。 私たちはスタジオのあるオフィスで、フロアの間に激しいネットを引きずりました。

アルチョム: フロア間には 20 G ビットのファイバーがあります。 さらにフロアに沿って進むと、どこかに光学系があり、どこかに光学系がないのですが、それでもチャンネルの数はギガビットよりも少なく、カンファレンスのトラックの間にビデオを流しています。 一般に、独自のインフラストラクチャで作業するのは非常に便利ですが、サイト上のオフライン会議ではこれを行うことはほとんどできません。

— JUG Ru Group で働く前、オフラインカンファレンスのハードウェアルームが一晩でセットアップされる様子を見ました。そこには、Grafana で構築したすべてのメトリクスを表示する大型モニターがありました。 現在は開発チームが座る本社室もあり、カンファレンス中にいくつかのバグを修正したり機能を開発したりしています。 同時に、大画面に表示される監視システムもあります。 Artyom、Kolya、その他の人たちは座って、すべてが落ちずに美しく機能することを確認します。

好奇心と問題

— Amazon でストリーミングを行っており、Web プレーヤーがあり、すべてが異なるプログラミング言語で書かれており、フォールト トレランスや、法人向けにサポートされる個人アカウントを含むその他のビジネス要件が提供されているという事実についてうまく話しました。 OAuth 2.0 を使用して誰かと統合でき、不正行為防止やユーザー ブロックが可能です。 変更を動的にロールアウトできるのは、変更がうまく行われ、すべてがテストされているためです。

何かを始めるにあたって、どんな奇妙なことがあったのか知りたいです。 バックエンドやフロントエンドを開発しているときに、何かおかしなことが判明して、それをどうすればよいのか理解できなかったなど、奇妙な状況に遭遇したことはありますか?

ウラジミール： このようなことが起こったのは、ここ XNUMX か月だけのような気がします。 毎日。 ご覧のとおり、髪の毛が全部抜けてしまいました。

ウラジミール・クラシルシチク、ある種のゲームが判明し、それをどうすればよいのか誰も理解できなかった3か月後

毎日、このようなことがあり、それを手に取って髪を引き裂く、または他の誰もいない、あなただけがそれを行うことができることに気づくような瞬間がありました。 最初の大きなイベントは TechTrain でした。 6 月 2 日の午前 2.0 時、私たちはまだ実稼働環境を展開していませんでしたが、Kolya がそれを展開していました。 また、個人アカウントはOAuth2.0を使用した認可サーバーとして機能しませんでした。 これを OAuth18 プロバイダーに変えてプラットフォームに接続しました。 私はおそらく XNUMX 時間連続で作業していました。コンピューターを見ても何も表示されませんでした。なぜ機能しないのか理解できませんでした。Kolya は私のコードをリモートで調べ、Spring 構成のバグを探しました。 、それを見つけたところ、LC は動作し、運用環境でも動作しました。

ニコライ： そして、TechTrain のリリースの XNUMX 時間前に行われました。

ここにはたくさんの星が並んでいた。 私たちにはスーパーチームがいて、オンラインでやるというアイデアにみんなが刺激を受けていたので、とても幸運でした。 この XNUMX か月間、私たちは「YouTube を作った」という事実に突き動かされていました。 私は髪を引き裂くことを自分に許しませんでしたが、実際にはすべてがずっと前に計算されていたので、すべてがうまくいくだろうとみんなに言いました。

性能について

— XNUMXつのトラックに何人の人が現場にいたのか教えてもらえますか？ パフォーマンス上の問題はありましたか?

ニコライ： すでに述べたように、パフォーマンスの問題はありませんでした。 1300 つのレポートに参加した最大人数は XNUMX 人でした。これはハイゼンバグにあります。

――現地での視聴に問題はありませんでしたか？ また、それがどのように機能するかを図付きで技術的に説明することは可能でしょうか?

ニコライ： これについては後ほど記事にします。

ストリームをローカルでデバッグすることもできます。 カンファレンスが始まると、いつでも視聴できる制作ストリームが登場したため、さらに簡単になりました。

ウラジミール： 私の理解では、フロントエンド開発者はローカルでモックを使用して作業し、フロントエンドの開発者にロールアウトする時間も短い (5 分) ため、証明書で何が起こっているかを確認するのに問題はありません。

— ローカルでもすべてがテストおよびデバッグされます。 これは、すべての技術的特徴を含む記事を作成し、すべてを図で示し、実際にどうだったかを説明することを意味します。

ウラジミール： それを受け取って繰り返すことができます。

- 3か月後。

合計

— 小規模なチームによって XNUMX か月で完了したことを考えると、説明されているすべてがクールに聞こえます。

ニコライ： 大きなチームならこんなことはしないだろう。 しかし、互いに非常に緊密かつ良好にコミュニケーションを図り、合意に達することができる少数の人々のグループであれば、それは可能です。 それらに矛盾はなく、アーキテクチャは XNUMX 日で発明され、完成し、実際には変更されていません。 山積する機能リクエストや変更に関しては、入ってくるビジネス要件を非常に厳密に促進する必要があります。

— サマーカンファレンスがすでに開催されていたとき、さらなるタスクのリストには何が入っていましたか?

ニコライ： たとえば、クレジット。 ビデオ上に忍び寄る線、表示されているコンテンツに応じてビデオ内のいくつかの場所にポップアップが表示されます。 たとえば、講演者が聴衆に質問したいとすると、画面上に投票が表示され、投票結果に基づいて講演者自身に投票が戻ってきます。 プレゼンテーション自体中にレポートに対する「いいね！」、ハート、評価の形で行われる、ある種のソーシャル アクティビティ。これにより、後でフィードバック フォームに気を取られることなく、適切なタイミングでフィードバックを記入できます。 最初はこんな感じ。

また、ストリーミングと会議を除くプラットフォーム全体に、会議後の状態も追加されます。 これらはプレイリスト (ユーザーによって編集されたものを含む) であり、他の過去のカンファレンスのコンテンツである可能性があり、統合され、ラベルが付けられ、ユーザーがアクセスでき、当社の Web サイトでも閲覧できます (live.jugru.org).

—皆さん、ご回答ありがとうございました！

読者の中にサマーカンファレンスに参加された方がいらっしゃいましたら、選手や放送の感想を教えてください。 便利だったこと、イライラしたこと、今後見てみたいことは何ですか？

このプラットフォームに興味があり、「戦闘中」を見たい場合は、私たちはそれを再び使用します。 秋冬カンファレンス。 さまざまな種類があるので、あなたに合ったものがほぼ確実に見つかります。

出所： habr.com