YouTube はどうやって巨大なビデオ ファイルを保存しますか?

皆さんこんにちは、私はブツァイ・チェンです~

YouTube は Google に次いで 2 番目に人気のある Web サイトです。 2019 年 5 月には、毎分 500 時間以上のビデオ コンテンツがプラットフォームにアップロードされました。

このビデオ共有プラットフォームには 20 億人を超えるユーザーがおり、毎日 10 億時間以上のビデオが再生され、数十億回の視聴回数を生み出しています。これらは信じられないほどの数字です。

この記事では、YouTube が使用するデータベースとバックエンド データ インフラストラクチャについて詳しく説明します。これにより、ビデオ プラットフォームは膨大な量のデータを保存し、数十億のユーザーに拡張することができます。

それでは始めましょう。

1. はじめに

YouTube への取り組みは 2005 年に始まりました。ベンチャーキャピタルから資金提供を受けたこの技術新興企業は成功を収め続け、2006 年 11 月に Google に 16 億 5,000 万ドルで買収されました。

Google に買収される前、同社のチームは次のメンバーで構成されていました。

• 2 人のシステム管理者
• 2 人のスケーラビリティ ソフトウェア アーキテクト
• 2 つの機能開発者
• 2 人のネットワーク エンジニア
• 1 人の DBA

2. バックエンド インフラストラクチャ

YouTube バックエンド マイクロサービスは、Python、データベース、ハードウェア、 Java (Guice フレームワークを使用) と Go。ユーザー インターフェイスは JavaScript を使用して記述されています。

メインデータベースは Vitess がサポートする MySQL です Vitess は MySQL の水平拡張に使用されるデータベース クラスタ システムです。さらに、キャッシュには Memcache を、ノードの調整には Zookeeper を使用します。

人気のある動画は CDN を通じて提供されますが、一般的な再生回数の少ない動画はデータベースから取得されます。

各ビデオがアップロードされると、一意の識別子が与えられ、バッチ ジョブによって処理されます。このジョブは、サムネイル、メタデータ、ビデオの生成など、複数の自動プロセスを実行します。スクリプト、コーディング、収益化ステータスの設定など。

VP9 および H.264/MPEG-4 AVC Advanced Videocoding コーデックはビデオ圧縮に使用され、他のコーデックの半分の帯域幅を使用して HD および 4K 品質のビデオをエンコードできます。

ビデオ ストリーミングは、従来の HTTP Web サーバーから高品質のビデオ ストリーミングを実現できるアダプティブ ビットレート ストリーミング テクノロジである HTTP プロトコルに基づくダイナミック アダプティブ ストリーミングを使用します。このテクノロジーを使用すると、コンテンツをさまざまなビットレートで視聴者に提供できます。 YouTube クライアントは、バッファリング時間を最小限に抑えるために、ビデオのレンダリングを視聴者のインターネット接続速度に自動的に適応させます。

私はかつて専用の記事で YouTube のビデオ コード変換プロセスについて説明しました。「YouTube が低遅延で高品質のビデオを提供する方法」を参照してください。

それでは、プラットフォームのバックエンド テクノロジーについて簡単に紹介します。 YouTube で使用される主なデータベースは MySQL です。では、YouTube のエンジニアリング チームが Vitess を作成する必要性を感じた理由を見てみましょう。元の MySQL 環境でどのような問題に直面し、その上に追加のフレームワークを実装することになったのでしょうか?

3. Vitess が必要な理由

Web サイトには、最初はデータベース インスタンスが 1 つだけあります。 Web サイトが成長するにつれて、開発者は増大する QPS (1 秒あたりのクエリ数) 要件を満たすためにデータベースを水平方向に拡張する必要があります。

3.1 マスター/スレーブ レプリカ

レプリカはマスター データベース インスタンスに追加されます。読み取りリクエストはプライマリ データベースとレプリカにルーティングされ、プライマリ データベースの負荷が軽減されます。レプリカを追加すると、ボトルネックが緩和され、読み取りスループットが向上し、システムの耐久性が向上します。

マスター ノードは書き込みトラフィックを処理し、マスター ノードとレプリカ ノードは読み取りトラフィックを同時に処理します。

ただし、このシナリオでは、レプリカから古いデータを読み取る可能性があります。マスターがレプリカの情報を更新する前にリクエストがレプリカのデータを読み取る場合、ビューアは古いデータを取得します。

現時点では、プライマリノードとレプリカノードのデータが不整合です。この場合、矛盾するデータは、プライマリ ノードとレプリカ ノードでの特定のビデオのビュー数です。

実際には、これはまったく問題ありません。視聴者は再生回数に多少のばらつきがあっても気にしませんよね?さらに、ビデオはブラウザでレンダリングできます。

マスター ノードとレプリカ ノード間のデータは、最終的には一貫性のあるものになります。

ということで、エンジニアも大満足でしたし、観客も大満足でした。レプリカの導入もあり、順調に進んでいます。

Web サイトは引き続き人気があり、QPS は上昇し続けています。マスター/スレーブ レプリカ戦略は現在、Web サイトのトラフィックの増加に対応することが困難になっています。 ＃＃＃＃＃＃何をするべきだろう？

3.2 シャーディング

次の戦略は、データベースをシャーディングすることです。シャーディングは、マスター/スレーブ レプリカ、マスター/マスター レプリカ、フェデレーション、非正規化に加えて、リレーショナル データベースを拡張する方法の 1 つです。

データベースのシャーディングは単純なプロセスではありません。これにより、システムの複雑さが大幅に増大し、管理がより困難になります。

ただし、QPS の成長に合わせてデータベースをシャード化する必要があります。開発者がデータベースをシャーディングすると、データは複数のマシンに分散されます。これにより、システムの書き込みスループットが向上します。書き込みを処理する 1 つのマスター インスタンスだけでなく、複数のシャード マシン間で書き込み操作を実行できるようになりました。

同時に、冗長性とスループットを確保するために、マシンごとに個別のコピーが作成されます。

プラットフォームの人気は高まり続けており、コンテンツ作成者によって大量のデータがデータベースに追加されています。

マシンの故障や未知の外部イベントによるデータ損失やサービスの利用不能を防ぐために、システムに災害管理機能を追加する必要があります。

3.3 災害管理

災害管理とは、停電や自然災害 (地震や火災など) に直面した場合の緊急措置を指します。冗長性があり、ユーザー データを世界のさまざまな地理的領域にあるデータ センターにバックアップする必要があります。ユーザーデータの損失やサービスの利用不能は許可されません。

世界中に複数のデータ センターがあることは、ユーザー リクエストが異なる大陸にあるオリジン サーバーにルーティングされるのではなく、最も近いデータ センターにルーティングされるため、YouTube のシステム レイテンシの削減にも役立ちます。

さあ、インフラストラクチャがどれほど複雑になるか想像できるでしょう。

最適化されていないフル テーブル スキャンにより、データベース全体がクラッシュすることがよくあります。データベースは不正なクエリから保​​護する必要があります。効率的なサービスを確保するには、すべてのサーバーを追跡する必要があります。

開発者は、システムの複雑さを抽象化し、スケーラビリティの課題を解決し、最小限のコストでシステムを管理できるシステムを必要としています。これらすべてが、YouTube が Vitess を開発するきっかけとなりました。

4.Vitess: MySQL データベース クラスタの水平拡張システム

Vitess は、MySQL 上で動作し、MySQL の水平拡張を可能にするデータベース クラスタ システムです。シャーディング機能が組み込まれているため、開発者はアプリケーションにシャーディング ロジックを追加することなくデータベースを拡張できます。これは NoSQL の動作と似ています。

#Vites は、フェイルオーバーとバックアップも自動的に処理します。リソースを大量に消費するクエリをインテリジェントに書き換えてキャッシュを実装することで、サーバーを管理し、データベースのパフォーマンスを向上させます。このフレームワークは、YouTube に加えて、GitHub、Slack、Square、New Relic などの業界の他の有名プレーヤーでも使用されています。

Vitess は、ACID トランザクションと強整合性のサポートが必要であり、同時に NoSQL データベースのようなリレーショナル データベースを迅速に拡張したい場合に役立ちます。

YouTube では、各 MySQL 接続に 2MB のオーバーヘッドがあります。各接続には計算されたコストがあり、接続数が増えると、追加の RAM を追加する必要があります。

Vitess は、Go プログラミング言語の同時実行サポートに基づいて構築された接続プールを通じて、これらの接続を非常に低コストで管理できます。 Zookeeper を使用してクラスターを管理し、最新の状態に保ちます。

5. クラウドへの展開

Vitess はクラウド ネイティブであり、クラウド モデルと同様に容量が徐々にデータベースに追加されるため、クラウド展開に適しています。 Kubernetes 対応のクラウドネイティブ分散データベースとして実行できます。

YouTube では、Vites はコンテナ化された環境で実行され、コンテナ オーケストレーション ツールとして Kubernetes を使用します。

今日のコンピューティング時代では、あらゆる大規模なサービスが分散環境のクラウドで実行されます。クラウドでサービスを実行することには多くの利点があります。

Google Cloud Platform は、Google 検索や YouTube などの Google 社内のエンドユーザー製品で使用されているものと同じインフラストラクチャに基づく一連のクラウド コンピューティング サービスです。

すべての大規模オンライン サービスには、多言語永続アーキテクチャが採用されています。これは、リレーショナルであろうと NoSQL であろうと、単一のデータ モデルではサービスのすべての使用シナリオを処理できないためです。

この記事の調査では、YouTube で使用されている特定の Google Cloud データベースのリストは見つかりませんでしたが、Google Cloud Spanner、Cloud SQL、Cloud Datastore などの GCP 固有の製品が使用されていることは間違いありません。 、Memorystore などを使用して、サービスのさまざまな機能を実行します。

この記事では、Google Adwords、Google Finance、Google Trends など、他の Google サービスで使用されるデータベースについて詳しく説明します。

6.CDN

YouTube は、低遅延、低コストのコンテンツ配信のために Google のグローバル ネットワークを使用しています。グローバルに分散された POP エッジ ポイントを使用すると、顧客はオリジン サーバーからデータを取得することなく、より迅速にデータを取得できるようになります。

ここまで、YouTube で使用されているデータベース、フレームワーク、テクノロジーについて説明してきました。さて、今回はストレージの話です。

YouTube では、これほど大量のデータ (毎分 500 時間のビデオ コンテンツがアップロードされる) をどのようにして保存しているのでしょうか?

7. データ ストレージ: YouTube はこのような膨大な量のデータをどのように保存しているのでしょうか?

ビデオは Google データ センターのハード ドライブに保存されます。このデータは Google File System と BigTable によって管理されます。

GFS Google ファイル システムは、分散環境で大規模なデータを管理するために Google によって開発された分散ファイル システムです。

BigTable は、Google ファイル システム上に構築された低遅延の分散データ ストレージ システムで、数千台のマシンに分散されたペタバイト単位のデータを処理するために使用されます。 60 以上の Google 製品で使用されています。

したがって、ビデオはハードドライブに保存されます。関係、メタデータ、ユーザー設定、プロフィール情報、アカウント設定、ストレージからビデオを取得するために必要な関連データなどはすべて MySQL に保存されます。

7.1 プラグアンドプレイの商用サーバー

Google データセンターには同種のハードウェアがあり、ソフトウェアは社内で構築され、管理されています。数千の独立したサーバー クラスター。

Google によって導入されたサーバーは、データセンターのストレージ機能を強化できます。これらはすべて商用サーバー (コモディティ サーバー) であり、商用既製サーバー (商用既製サーバー) とも呼ばれます。 。これらのサーバーは低価格で広く入手可能であり、大量に購入できるため、最小限のコストと出費でデータセンター内の同じハードウェアを交換または構成できます。

追加のストレージの必要性が高まると、新しい汎用サーバーがシステムに接続されることになります。

商用サーバーは問題が発生すると、修理ではなく交換されることがよくあります。これらはカスタムメイドではないため、企業はこれを使用することで、カスタムメイドのサーバーを実行する場合に比べてインフラストラクチャ コストを大幅に削減できます。

7.2 データセンター向けに設計されたストレージ ディスク

YouTube では、毎日ペタバイトを超える新しいストレージが必要です。回転ハードドライブは、低コストで信頼性が高いため、主要な記憶媒体です。

SSD ソリッド ステート ドライブは半導体をベースとしているため、回転ディスクよりも高性能ですが、大規模に使用するとコスト効率が悪くなります。

これらは非常に高価であり、時間の経過とともにデータが失われる傾向があります。このため、アーカイブ データの保存には適していません。

さらに、Google は大規模データセンターに適した新しいディスク シリーズを開発しています。

データ ストレージ用に構築されたハードウェアの品質を判断するために使用できる 5 つの重要な指標があります。

• ハードウェアは、高速入出力操作をサポートできる必要があります。秒のオーダー。
• 組織が指定するセキュリティ標準に準拠する必要があります。
• 通常のストレージ ハードウェアと比較して、より大きなストレージ容量が必要です。
• ハードウェアの購入コスト、電力コスト、メンテナンスコストはすべて許容できるはずです。
• ディスクは信頼性が高く、遅延が安定している必要があります。

以上がYouTube はどうやって巨大なビデオ ファイルを保存しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。