Understanding System Design of Netflix: Backend Architecture and Cloud Services

訳

Netflixのシステム設計を理解する： バックエンドアーキテクチャとクラウドサービス

Netflixは、受賞歴のあるテレビ番組、映画、アニメ、ドキュメンタリーなど、さまざまな作品をインターネットに接続された数千台のデバイスで楽しめるストリーミングサービスです。

Netflixは、世界200カ国以上で2億人以上の加入者を抱えています。

Netflixのアーキテクチャに入る前に、まずこのシステムが設計された重要な統計について説明します。

1. Netflixアプリケーションの1日あたりのイベント数は約4000億件

2. ピーク時に約800万イベント、毎秒17GBを実現

3. 200M以上の購読者数

4. 200カ国以上に広がる購読者数

5. 2000台以上のデバイスに対応

6. ユーザーが1日に視聴する動画の平均本数＝5本

7. 動画の平均サイズ＝500MB

8. バックエンドから1日にアップロードされる動画の平均本数＝1,000本

9. 1日に必要な総アップロード容量＝1,000×500MB＝500GB(約)

10. 5年後に必要な総ストレージ＝500GB * 5 * 365 = 912.5 TB

Netflixは、プロダクションから高品質の映像やコンテンツを受け取っています。しかし、Netflixは2000以上のデバイスに対応しており、それぞれ異なる解像度やフォーマットが要求されます。

Netflixは、ユーザーのネットワーク速度やデバイスに応じた画質を提供するために、同じ映画で解像度の異なる動画のレプリカを複数用意する。これを実現するために、Netflixは元の動画を異なる小さな塊に分割し、AWSの並列ワーカーを使って、これらの塊を異なる解像度（4k、1080pなど）の異なるフォーマット（MP4、3gpなど）に変換します。このプロセスはトランスコードと呼ばれます。

トランスコード後、同じ映画のファイルの複数のコピーができたら、これらのコピーは、世界中のさまざまな場所に配置された各Open Connectサーバーに転送されます。

クラウドサービス

オープンコネクト：- オープンコネクトまたはNetflix cdnは、異なる地理的位置に広がる分散型サーバーのネットワークである。同じ映画のファイルの異なるレプリカは、各オープンコネクトサーバーに転送されます。オープンコネクトは、主にNetflixのビデオストリーミングを担当しています。再生ボタンを押すと、最も近いオープンコネクトサーバーから動画が配信されるため、より速く、より良い体験ができます。また、システム全体のスケーラビリティも向上しています。これらのサーバーは、オープンコネクトアプライアンス（OCA）と呼ばれています。

注：- 上記のストレージの指標である912.5TBには、これらのレプリカによって取得されたストレージは含まれていません。

AWS：-Netflixは、ビデオストリーミング以外のほとんどすべてのことにAWSを使用しています。オンラインストレージ、レコメンデーションエンジン、ビデオトランスコーディング、データベース、アナリティクスなどです。

ユーザーが再生ボタンをクリックすると、Netflixはネットワーク速度や接続の安定性を分析し、ユーザーの近くにある最適なOpen Connectサーバーを割り出す。デバイスや画面サイズに応じて、適切なビデオフォーマットがユーザーのデバイスにストリーミングされます。

Netflixのバックエンドアーキテクチャ

https://miro.medium.com/v2/resize:fit:1400/format:webp/1*iML0WHLGyh6iQKF8OQ71Fw.png

Netflixでは、新しいコンテンツの登録、動画の処理、世界各地にあるサーバーへの配信、ネットワークトラフィックの管理など、動画配信以外のすべてをバックエンドサービスが担っています。

クライアントからのリクエストは、2層構造で構成されたAWS Elastic load balancerに送られます。

Tier 1:- ELBからのリクエストは、まずこのTierに到達し、異なるゾーンの負荷分散を担当する。DNSベースのラウンドロビンスケジューリングが使用されます。

Tier 2: - この階層は、ロードバランシングインスタンスのアレイで構成されています。これらのインスタンスは、同じゾーンにあるインスタンス間でラウンドロビンのロードバランシングを実行します。

ELBは、このリクエストをAPIゲートウェイに転送する。Netflixは、AWSのEC2インスタンス上で動作するAPIゲートウェイとしてZUULを使用しています。ZUULは、Netflixが開発し、動的なルーティング、モニタリング、セキュリティのために使用しているライブラリです。ZUULは、クエリパラメーター、URL、パスに基づくルーティングを提供します。

Netflixはサービスの集合体で構築されています。サービスの集合体を用いてアプリケーションを構築することは、マイクロサービス・アーキテクチャとして知られています。マイクロサービス・アーキテクチャでは、サービスは互いに独立しています。

ZUULは、デバイスやウェブサイトからNetflixストリーミングアプリケーションのバックエンドへのすべてのリクエストのためのフロントドアです。ZUULは、ユーザーのリクエストに基づいて、リクエストを特定のサービスにルーティングします。例えば、ユーザーがログインしようとすると、認証サービスにリクエストが送信されます。

Netflixのアーキテクチャは、複雑な分散構造になっています。多くの利点がある一方で、いくつかの依存関係もあります。例えば、あるサーバーの動作は、他のサーバーの出力に依存することがあります。このようなサーバー間の依存関係は、遅延を生じさせ、また、サーバーの1つが停止した場合、単一障害点となる可能性があります。

上記の問題に対して、Netflixはhystrixを使用しています。HystrixはNetflixが開発した非常に強力なライブラリで、各マイクロサービスを互いに分離し、障害の数を最小限に抑えます。Hystrixは、サービス間のアクセスポイントを分離することでこれを実現します。Hystrixは、フェイルファストと迅速な回復、ほぼリアルタイムの監視、警告、および運用管理、サードパーティのクライアントライブラリを介して（通常はネットワーク経由で）アクセスされる依存関係からの待ち時間と障害の低減、複雑な分散システムでのカスケード障害の停止に使用されます。

ユーザーの行動や履歴データは、ストリーム処理パイプラインに送られ、後で映画の推薦をするために使用されます。

このデータは、AWS、Hadoop、Cassandraなどのビッグデータ処理ツールに送られ、さらなるアクションが行われます。

Netflixのデータベース

Netflixは2種類のデータベースを使用しています。

1. MySQL

2. カサンドラ

MySQL

課金情報、ユーザー情報、トランザクション情報などのデータについて、NetflixはACIDコンプライアンスを必要とするためMySQLを使用しています。NetflixはMySQLのマスター・マスターセットアップを行い、Amazonの大規模EC2インスタンスにデプロイしています。

マスターマスター設定によると、書き込み者がプライマリーマスターノードである場合、それは別のマスターノードにもレプリケートされます。プライマリーマスターノードとリモートマスターノードの両方の書き込みが確認された場合にのみ、確認応答が送信される。これにより、データの高い可用性が保証されます。

Netflixは、各ノード（ローカルおよびクロスリージョン）に対してリードレプリカを設定しています。これにより、高い可用性とスケーラビリティが確保されます。

Cassandra

Netflixは、そのスケーラビリティと単一障害点の欠如、および地域横断的な展開のためにCassandraを使用しています。事実上、単一のグローバルなCassandraクラスタは、同時にアプリケーションをサービスし、複数の地理的な場所にデータを非同期に複製することができます。

NetflixにおけるCassandraのデータ・モデル

1. 50以上のCassandraクラスタ

2. 500ノード以上

3. 30TBの日次バックアップ

4. 各ノードで250k Writes/s

NetflixにおけるKafkaとApache Chukwaの利用について

上述したように、Netflixはマイクロサービスの集合体で構築されており、これらのマイクロサービスは連携してユーザーに多くのサービスを提供します。

多くの場合、マイクロサービス・アーキテクチャでは、ある程度の割合の失敗は許容されます。しかし、いくつかの失敗は、より大きな問題につながる可能性があります。マイクロサービスの呼び出しのどれか1つに障害が発生すると、多数の計算が同期しなくなり、データが数百万円単位でずれてしまう可能性があります。また、可用性の問題にもつながり、「このデータの不一致は何が原因なのか」というビジネス上の疑問を効果的に追跡して答えようとする際に、盲点になる可能性がある。

この問題を解決するには、サービス間のやりとりを、同期的なリクエストの連続ではなく、非同期的なイベント交換として考え直すことです。これにより、次のような利点が得られます。

1. 私たちのインフラは本質的に非同期なものになる

2. 私たちのアプリケーションは疎結合になり、エラーのトレーサビリティが改善されました。

Netflixは、イベント、メッセージング、ストリーム処理のニーズに合わせてApache Kafkaを使用しています。

Apache Kafkaはパブリッシュ/サブスクライブモデルで動作します。Netflixのサービスは、変更をイベントとしてメッセージバスに公開し、それを世界の状態を調整する必要がある関心のある別のサービスが消費します。

これにより、状態の変化に関してサービスが同期しているかどうか、同期していない場合はどれくらいで同期できるようになるかを追跡することができます。これらの洞察は、依存するサービスの大きなグラフを運用する際に非常に強力なものとなります。

イベントベースの通信と分散型消費は、（前述のように）大規模な同期型コールグラフで通常見られる問題を克服するのに役立ちます。

Apache Chukwa

Apache chukwaは、複雑な分散システムを監視するために使用されるオープンソースのデータ収集システムです。chukwaは、異なるマイクロサービスからイベントを収集し、Hadoopファイルシーケンス形式でそれらを書き込みます。Chukwaはまた、様々なシンクにイベントをアップロードするためにKafkaへのトラフィックを提供します：S3、Elastic searchなど。

Elastic Search

Elastic searchは、Netflixでカスタマーケアサポート、データの可視化、エラー検出のために使用されています。例えば、ユーザーがビデオを再生できない場合、再生チームはエラスティックサーチにアクセスして問題の原因を探します。また、リソースの使用状況を把握し、サインアップやログインの問題を検出するためにも使用されています。