インターネットリクエストを高速化し、安らかに眠れます

Netflix はインターネット テレビ市場のリーダーであり、このセグメントを創設し、積極的に開発している会社です。 Netflix は、地球上のほぼあらゆる場所から視聴できる映画やテレビ シリーズの広範なカタログとディスプレイ付きのデバイスだけでなく、信頼性の高いインフラストラクチャと独自のエンジニアリング文化でも知られています。

複雑なシステムの開発とサポートに対する Netflix のアプローチの明確な例が DevOops 2019 で発表されました セルゲイ・フェドロフ - Netflix の開発ディレクター。 ニジニ・ノヴゴロド州立大学計算数学学部卒業。 Lobachevsky、Sergey は、Netflix の CDN チームである Open Connect の最初のエンジニアの XNUMX 人です。 彼はビデオ データを監視および分析するシステムを構築し、インターネット接続速度を評価するための人気サービス FAST.com を立ち上げ、ここ数年は Netflix アプリケーションがユーザーにとってできるだけ早く動作するようにインターネット リクエストの最適化に取り組んできました。

このレポートはカンファレンス参加者から最高のレビューを得たので、テキスト版を用意しました。

セルゲイ氏は報告書の中で詳細に語った。

• クライアントとサーバー間のインターネット要求の遅延に何が影響するかについて。
• この遅延を減らす方法。
• エラー耐性のあるシステムを設計、保守、監視する方法。
• ビジネスへのリスクを最小限に抑えながら、短期間で結果を達成する方法。
• 結果を分析し、間違いから学ぶ方法。

これらの質問に対する答えは、大企業で働く人だけが必要としているわけではありません。

提示された原則と技術は、インターネット製品を開発およびサポートするすべての人に知られ、実践されるべきです。

続いて、話者の視点でのナレーションです。

インターネット速度の重要性

インターネットリクエストの速度はビジネスに直接関係します。 ショッピング業界を考えてみましょう: 2009 年の Amazon 話した100 ミリ秒の遅延により、売上の 1% が失われるということです。

モバイル デバイスがますます増え、モバイル サイトやアプリケーションもそれに続きます。 ページの読み込みに 3 秒以上かかる場合は、ユーザーの約半分を失うことになります。 と 2018年XNUMX月 Google では、検索結果でのページの読み込み速度が考慮されます。ページが速いほど、Google での位置が高くなります。

遅延が重要な金融機関では、接続速度も重要です。 2015 年、ハイバーニア ネットワークス 終了した 400 億ドルをかけてニューヨークとロンドン間のケーブルを建設し、都市間の遅延を 6 ミリ秒削減しました。 66 ミリ秒の遅延短縮に 1 万ドルかかると想像してみてください。

による 探査、5 Mbit/秒を超える接続速度は、一般的な Web サイトの読み込み速度に直接影響しなくなりました。 ただし、接続レイテンシーとページの読み込み速度の間には線形関係があります。

ただし、Netflix は典型的な製品ではありません。 遅延と速度がユーザーに与える影響は、分析と開発の活発な領域です。 アプリケーションの読み込みとコンテンツの選択は遅延に依存しますが、静的要素の読み込みとストリーミングも接続速度に依存します。 ユーザーエクスペリエンスに影響を与える主要な要素の分析と最適化は、Netflix のいくつかのチームが積極的に開発を行っている分野です。 目標の XNUMX つは、Netflix デバイスとクラウド インフラストラクチャ間のリクエストの待ち時間を短縮することです。

このレポートでは、Netflix インフラストラクチャの例を使用して、遅延の削減に特に焦点を当てます。 複雑な分散システムの設計、開発、運用のプロセスにどのようにアプローチし、運用上の問題や故障を診断するのではなく、革新と結果に時間を費やすかを実践的な観点から考えてみましょう。

Netflix の内部

何千もの異なるデバイスが Netflix アプリをサポートしています。 これらは XNUMX つの異なるチームによって開発されており、Android、iOS、TV、Web ブラウザー用に個別のバージョンのクライアントを作成しています。 そして、私たちはユーザーエクスペリエンスの改善とパーソナライズに多大な労力を費やしています。 これを行うために、何百もの A/B テストを並行して実行します。

パーソナライゼーションは AWS クラウドの何百ものマイクロサービスによってサポートされており、パーソナライズされたユーザー データ、クエリ ディスパッチ、テレメトリ、ビッグ データ、エンコーディングを提供します。 トラフィックの視覚化は次のようになります。

デモ付きビデオへのリンク (6:04-6:23)

左側はエントリ ポイントで、トラフィックはさまざまなバックエンド チームによってサポートされる数百のマイクロサービスに分散されます。

当社のインフラストラクチャのもう XNUMX つの重要なコンポーネントは、ビデオ、画像、クライアント コードなどの静的コンテンツをエンド ユーザーに配信する Open Connect CDN です。 CDN はカスタム サーバー (OCA - Open Connect Appliance) 上にあります。 内部には、NGINX と一連のサービスを備えた、最適化された FreeBSD を実行する SSD および HDD ドライブのアレイがあります。 このような CDN サーバーができるだけ多くのデータをユーザーに送信できるように、ハードウェアおよびソフトウェア コンポーネントを設計および最適化します。

インターネット トラフィック交換ポイント (Internet eXchange - IX) におけるこれらのサーバーの「壁」は次のようになります。

Internet Exchange は、インターネット サービス プロバイダーとコンテンツ プロバイダーが相互に「接続」し、インターネット上でより直接的にデータを交換できる機能を提供します。 当社のサーバーが設置されている Internet Exchange ポイントは世界中に約 70 ～ 80 あり、当社はそれらを独自に設置および保守しています。

さらに、当社はインターネットプロバイダーにサーバーを直接提供し、インターネットプロバイダーがそのネットワークにインストールすることで、Netflix トラフィックのローカライゼーションとユーザーのストリーミング品質を向上させます。

一連の AWS サービスは、クライアントから CDN サーバーへのビデオリクエストのディスパッチと、サーバー自体の構成 (コンテンツ、プログラムコード、設定などの更新) を担当します。 後者については、Internet Exchange ポイント内のサーバーと AWS を接続するバックボーン ネットワークも構築しました。 バックボーン ネットワークは、ニーズに基づいて設計および構成できる光ファイバー ケーブルとルーターのグローバル ネットワークです。

上の サンバインの推定値、当社の CDN インフラストラクチャは、ピーク時に世界のインターネット トラフィックの約 150/XNUMX を配信し、Netflix が最も長く存在している北米ではトラフィックの XNUMX/XNUMX を配信します。 印象的な数字ですが、私にとって最も驚くべき成果の XNUMX つは、CDN システム全体が XNUMX 人未満のチームによって開発および保守されているということです。

当初、CDN インフラストラクチャはビデオ データを配信するために設計されました。 しかし、時間が経つにつれ、AWS クラウド内のクライアントからの動的リクエストを最適化するためにも使用できることがわかりました。

インターネットアクセラレーションについて

現在、Netflix には 3 つの AWS リージョンがあり、クラウドへのリクエストのレイテンシーは、顧客が最も近いリージョンからどれだけ離れているかによって異なります。 同時に、静的コンテンツの配信に使用される CDN サーバーが多数あります。 このフレームワークを使用して動的クエリを高速化する方法はありますか? ただし、残念ながら、これらのリクエストをキャッシュすることは不可能です。API はパーソナライズされており、それぞれの結果は一意です。

CDN サーバー上にプロキシを作成し、それを介してトラフィックの送信を開始しましょう。 もっと速くなりますか？

婚姻

ネットワークプロトコルがどのように機能するかを思い出してください。 現在、インターネット上のほとんどのトラフィックは HTTPs を使用しており、これは下位層プロトコルの TCP および TLS に依存しています。 クライアントがサーバーに接続するにはハンドシェイクが行われ、安全な接続を確立するには、クライアントはサーバーとメッセージを 100 回交換し、データ転送のために少なくとももう 400 回メッセージを交換する必要があります。 往復あたりの遅延 (RTT) が XNUMX ミリ秒の場合、データの最初のビットを受信するのに XNUMX ミリ秒かかります。

証明書を CDN サーバーに置く場合、CDN が近くにあれば、クライアントとサーバー間のハンドシェイク時間を大幅に短縮できます。 CDN サーバーへの遅延が 30 ミリ秒であると仮定します。 その後、最初のビットを受信するのに 220 ミリ秒かかります。

しかし、メリットはそれだけではありません。 接続が確立されると、TCP は輻輳ウィンドウ (その接続上で並行して送信できる情報の量) を増やします。 データ パケットが失われた場合、TCP プロトコルの従来の実装 (TCP New Reno など) では、開いている「ウィンドウ」が半分に減ります。 輻輳ウィンドウの拡大と、輻輳ウィンドウの損失からの回復速度は、サーバーまでの遅延 (RTT) によって決まります。 この接続が CDN サーバーまでのみである場合、この回復はより速くなります。 同時に、パケット損失は、特にワイヤレス ネットワークでは標準的な現象です。

ユーザーからのトラフィックにより、特にピーク時間帯にインターネット帯域幅が減少し、トラフィック渋滞が発生する可能性があります。 ただし、インターネットでは、一部のリクエストを他のリクエストよりも優先する方法はありません。 たとえば、ネットワークに負荷をかける「重い」データ ストリームよりも、小規模で遅延の影響を受けやすいリクエストを優先します。 ただし、私たちの場合、独自のバックボーン ネットワークがあるため、CDN とクラウドの間のリクエスト パスの一部でこれを行うことができ、完全に構成できます。 小さくて遅延の影響を受けやすいパケットが優先され、大きなデータ フローが少し遅れて送信されるようにすることができます。 CDN がクライアントに近づくほど、効率が向上します。

アプリケーション レベルのプロトコル (OSI レベル 7) も遅延に影響します。 HTTP/2 などの新しいプロトコルにより、並列リクエストのパフォーマンスが最適化されます。 ただし、新しいプロトコルをサポートしていない古いデバイスを使用する Netflix クライアントが存在します。 すべてのクライアントを更新したり、最適に構成したりできるわけではありません。 同時に、CDN プロキシとクラウドの間では完全な制御が行われ、新しい最適なプロトコルと設定を使用することができます。 古いプロトコルの非効率な部分は、クライアントと CDN サーバーの間でのみ動作します。 さらに、CDN とクラウドの間にすでに確立されている接続上で多重リクエストを行うことができ、TCP レベルでの接続使用率が向上します。

測定します

理論によって改善が約束されているという事実にもかかわらず、私たちはすぐにシステムを実稼働環境に投入することを急ぐわけではありません。 その代わりに、まずそのアイデアが実際に機能することを証明する必要があります。 これを行うには、いくつかの質問に答える必要があります。

• スピード: プロキシを使用すると高速になりますか?
• 信頼性：壊れることが多くなりますか？
• 難易度: アプリケーションと統合するにはどうすればよいですか?
• のコスト: 追加のインフラストラクチャを展開するにはどれくらいの費用がかかりますか?

最初の点を評価するためのアプローチを詳しく検討してみましょう。 残りも同様の方法で処理されます。

リクエストの速度を分析するには、開発に多くの時間を費やすことなく、本番環境を中断することなく、すべてのユーザーのデータを取得したいと考えています。 これにはいくつかのアプローチがあります。

1. RUM、またはパッシブリクエスト測定。 ユーザーからの現在のリクエストの実行時間を測定し、ユーザーを完全にカバーしていることを保証します。 欠点は、さまざまな要因 (リクエスト サイズ、サーバーとクライアントの処理時間の違いなど) により、信号があまり安定していないことです。 さらに、新しい構成をテストしても実稼働環境に影響を与えることはできません。
2. 臨床検査。 クライアントをシミュレートする特別なサーバーとインフラストラクチャ。 彼らの協力を得て、必要なテストを実施します。 このようにして、測定結果とクリアな信号を完全に制御できます。 しかし、デバイスとユーザーの場所を完全にカバーすることはできません (特に世界規模のサービスと数千のデバイス モデルのサポート)。

両方の方法の利点を組み合わせるにはどうすればよいでしょうか?

私たちのチームは解決策を見つけました。 私たちは小さなコード (サンプル) を作成し、それをアプリケーションに組み込みました。 プローブを使用すると、デバイスから完全に制御されたネットワーク テストを実行できます。 それはこのように動作します：

1. アプリケーションをロードして最初のアクティビティを完了した直後に、プローブを実行します。
2. クライアントはサーバーにリクエストを送信し、テストの「レシピ」を受け取ります。 レシピは、HTTP(s) リクエストを行う必要がある URL のリストです。 さらに、レシピはリクエスト間の遅延、リクエストされたデータの量、HTTP(s) ヘッダーなどのリクエスト パラメーターを構成します。 同時に、いくつかの異なるレシピを並行してテストできます。構成をリクエストするときに、発行するレシピをランダムに決定します。
3. プローブの起動時間は、クライアント上のネットワーク リソースのアクティブな使用と競合しないように選択されます。 基本的に、クライアントがアクティブではない時間が選択されます。
4. レシピを受信した後、クライアントは各 URL に並行してリクエストを送信します。 各アドレスへのリクエストは、いわゆる、繰り返すことができます。 「パルス」。 最初のパルスで、接続を確立してデータをダウンロードするのにかかった時間を測定します。 XNUMX 番目のパルスでは、すでに確立されている接続を介してデータをロードするのにかかる時間を測定します。 XNUMX 番目の前に、遅延を設定し、再接続の確立などの速度を測定できます。

   テスト中に、デバイスが取得できるすべてのパラメータを測定します。

   • DNS リクエスト時間。
   • TCP 接続のセットアップ時間。
   • TLS 接続のセットアップ時間。
   • データの最初のバイトを受信した時刻。
   • 合計ロード時間。
   • ステータス結果コード。
5. すべてのパルスが完了すると、サンプルは分析のためにすべての測定値をロードします。

重要な点は、クライアント上のロジックへの依存が最小限であること、サーバー上のデータ処理、および並列リクエストの測定です。 したがって、クエリのパフォーマンスに影響を与えるさまざまな要因の影響を分離してテストし、単一のレシピ内でそれらを変化させ、実際のクライアントから結果を取得することができます。

このインフラストラクチャは、クエリ パフォーマンス分析以上の用途に役立つことが証明されています。 現在、14 のアクティブなレシピがあり、6000 秒あたり XNUMX サンプルを超え、地球の隅々からデータを受信し、デバイスを完全にカバーしています。 Netflixが同様のサービスをサードパーティから買収した場合、年間数百万ドルの費用がかかり、カバー範囲ははるかに悪くなります。

実際のテスト理論: プロトタイプ

このようなシステムを使用することで、リクエストの遅延に対する CDN プロキシの有効性を評価することができました。 今必要なものは次のとおりです。

• プロキシ プロトタイプを作成します。
• プロトタイプを CDN に置きます。
• クライアントを特定の CDN サーバー上のプロキシに誘導する方法を決定します。
• プロキシを使用しない AWS でのリクエストとパフォーマンスを比較します。

課題は、提案されたソリューションの有効性をできるだけ早く評価することです。 優れたネットワーキング ライブラリが利用できるため、プロトタイプの実装に Go を選択しました。 各 CDN サーバーには、依存関係を最小限に抑え、統合を簡素化するために、プロトタイプ プロキシを静的バイナリとしてインストールしました。 初期実装では、可能な限り標準コンポーネントを使用し、HTTP/2 接続プーリングとリクエストの多重化に若干の変更を加えました。

AWS リージョン間のバランスをとるために、クライアントのバランスを取るために使用したのと同じ地理的 DNS データベースを使用しました。 クライアントの CDN サーバーを選択するには、Internet Exchange (IX) のサーバーに TCP Anycast を使用します。 このオプションでは、すべての CDN サーバーに対して XNUMX つの IP アドレスを使用し、クライアントは IP ホップ数が最も少ない CDN サーバーにリダイレクトされます。 インターネット プロバイダー (ISP) によってインストールされた CDN サーバーでは、ルーターを制御して TCP エニーキャストを構成することができないため、 同じロジック、顧客をビデオストリーミング用のインターネットプロバイダーに誘導します。

したがって、リクエスト パスには XNUMX 種類があります。オープン インターネット経由、IX の CDN サーバー経由、またはインターネット プロバイダーにある CDN サーバー経由のクラウドへです。 私たちの目標は、リクエストが本番環境に送信される方法と比較して、どちらの方法が優れているのか、プロキシの利点は何なのかを理解することです。 これを行うために、次のようなサンプリング システムを使用します。

それぞれのパスが個別の目標となり、到達した時間を確認します。 分析のために、プロキシの結果を XNUMX つのグループに結合し (IX プロキシと ISP プロキシ間の最適な時間を選択)、プロキシを使用しないクラウドへのリクエストの時間と比較します。

ご覧のとおり、結果はまちまちでした。ほとんどの場合、プロキシによって速度が大幅に向上しましたが、状況が大幅に悪化するクライアントも十分な数ありました。

その結果、私たちはいくつかの重要なことを行いました。

1. CDN プロキシ経由でクライアントからクラウドへのリクエストの予想されるパフォーマンスを評価しました。
2. 私たちは実際のクライアントから、あらゆる種類のデバイスからデータを受け取りました。
3. この理論は 100% 確認されておらず、CDN プロキシを使用した最初の提案は機能しないことがわかりました。
4. 私たちはリスクを冒しませんでした。クライアントの運用構成を変更しませんでした。
5. 何も壊れていませんでした。

プロトタイプ 2.0

したがって、振り出しに戻ってプロセスをもう一度繰り返します。

その考え方は、100% プロキシを使用する代わりに、各クライアントの最速パスを決定し、そこにリクエストを送信する、つまり、いわゆるクライアント ステアリングを実行するというものです。

これを実装するにはどうすればよいでしょうか? サーバー側でロジックを使用することはできません。なぜなら... 目標は、このサーバーに接続することです。 クライアント上でこれを行う何らかの方法が必要です。 そして理想的には、多数のクライアント プラットフォームとの統合の問題を解決しないように、最小限の複雑なロジックでこれを実行します。

答えは、DNS を使用することです。 私たちの場合、独自の DNS インフラストラクチャがあり、サーバーが権威を持つドメイン ゾーンを設定できます。 それはこのように動作します：

1. クライアントは、ホスト (api.netflix.xom など) を使用して DNS サーバーにリクエストを送信します。
2. リクエストがDNSサーバーに到着します
3. DNS サーバーは、このクライアントにとってどのパスが最速であるかを認識し、対応する IP アドレスを発行します。

このソリューションにはさらに複雑さが伴います。権威主義的な DNS プロバイダーはクライアントの IP アドレスを認識せず、クライアントが使用する再帰リゾルバーの IP アドレスしか読み取ることができません。

その結果、権威主義リゾルバーは、個々のクライアントではなく、再帰的リゾルバーに基づいてクライアントのグループに対して決定を下す必要があります。

解決するには、同じサンプルを使用し、再帰リゾルバーごとにクライアントからの測定結果を集約し、このグループの送信先 (TCP エニーキャストを使用した IX 経由のプロキシ、ISP プロキシ経由、またはクラウドへの直接送信) を決定します。

次のシステムが得られます。

結果として得られる DNS ステアリング モデルにより、クライアントからクラウドへの接続速度の履歴観察に基づいてクライアントを誘導できます。

繰り返しになりますが、問題は、このアプローチがどの程度効果的に機能するかということです。 それに答えるために、私たちは再びプローブ システムを使用します。 したがって、ターゲットの XNUMX つが DNS ステアリングからの指示に従い、もう XNUMX つがクラウド (現在の本番環境) に直接送信されるプレゼンター構成を構成します。

その結果、結果を比較して有効性を評価します。

その結果、いくつかの重要なことが分かりました。

1. DNS ステアリングを使用して、クライアントからクラウドへのリクエストの予想されるパフォーマンスを評価しました。
2. 私たちは実際のクライアントから、あらゆる種類のデバイスからデータを受け取りました。
3. 提案されたアイデアの有効性が証明されました。
4. 私たちはリスクを冒しませんでした。クライアントの運用構成を変更しませんでした。
5. 何も壊れていませんでした。

さて、難しい部分ですが、本番環境で起動します。

簡単な部分は終わりました。動作するプロトタイプが完成しました。 ここで最も難しいのは、Netflix のすべてのトラフィックに対応するソリューションを立ち上げ、150 億 XNUMX 万人のユーザー、数千のデバイス、数百のマイクロサービス、そして常に変化する製品とインフラストラクチャに展開することです。 Netflix サーバーは XNUMX 秒あたり数百万件のリクエストを受信するため、不用意な操作でサービスを中断するのは簡単です。 同時に、インターネット上の何千もの CDN サーバーを介してトラフィックを動的にルーティングしたいと考えています。インターネットでは、常に何かが変化したり、最も不都合な瞬間に壊れたりします。

これらすべてにより、チームにはシステムの開発、導入、完全なサポートを担当する 3 人のエンジニアがいます。

したがって、私たちは安らかな健康的な睡眠について引き続き話していきます。

サポートにすべての時間を費やさずに開発を続けるにはどうすればよいでしょうか? 私たちのアプローチは 3 つの原則に基づいています。

1. 潜在的な故障規模（爆発範囲）を縮小します。
2. 私たちは驚きに備えて準備をしています。テストや個人的な経験にもかかわらず、何かが壊れることは予想されます。
3. グレースフル デグラデーション - 何かが正しく動作しない場合は、たとえ最も効率的な方法でなくても、自動的に修正される必要があります。

私たちの場合、問題に対するこのアプローチにより、シンプルで効果的な解決策を見つけ、システム サポートを大幅に簡素化できることがわかりました。 私たちは、クライアントに小さなコードを追加して、接続の問題によって引き起こされるネットワーク リクエスト エラーを監視できることに気付きました。 ネットワークエラーが発生した場合は、クラウドに直接フォールバックします。 このソリューションは、クライアント チームにとって多大な労力を必要としませんが、私たちにとって予期せぬ故障や予期せぬ事態が発生するリスクを大幅に軽減します。

もちろん、フォールバックにもかかわらず、私たちは開発中に明確な規律に従います。

1. サンプルテスト。
2. A/B テストまたはカナリア。
3. 段階的なロールアウト。

サンプルを使用してアプローチを説明しました。変更は、カスタマイズされたレシピを使用して最初にテストされます。

カナリア テストでは、変更前と変更後のシステムの動作を比較できる、比較可能なサーバーのペアを取得する必要があります。 これを行うために、多くの CDN サイトから、同等のトラフィックを受信するサーバーのペアを選択します。

次に、変更を加えたビルドを Canary サーバーにインストールします。 結果を評価するために、約 100 ～ 150 のメトリクスをコントロール サーバーのサンプルと比較するシステムを実行します。

Canary テストが成功した場合は、段階的に、段階的にリリースします。 各サイトのサーバーを同時に更新することはありません。問題によりサイト全体を失うことは、別の場所で同じ数のサーバーを失うことよりも、ユーザーへのサービスに大きな影響を与えます。

一般に、このアプローチの有効性と安全性は、収集されるメトリクスの量と品質に依存します。 クエリ高速化システムでは、考えられるすべてのコンポーネントからメトリクスを収集します。

• クライアントから - セッションとリクエストの数、フォールバック率。
• プロキシ - リクエストの数と時間に関する統計。
• DNS - リクエストの数と結果。
• クラウド エッジ - クラウドでのリクエストの処理数と時間。

これらすべてが XNUMX つのパイプラインに収集され、ニーズに応じて、どのメトリクスをリアルタイム分析に送信するか、より詳細な診断のためにどのメトリクスを Elasticsearch またはビッグ データに送信するかを決定します。

私たちは監視します

この例では、クライアントとサーバー間のリクエストのクリティカル パスに変更を加えています。 同時に、クライアント上、サーバー上、インターネット経由のさまざまなコンポーネントの数は膨大です。 クライアントとサーバーの変更は、数十のチームの作業中やエコシステムの自然な変化中に常に発生します。 私たちはその中間にいます。問題を診断する際には、私たちが関与する可能性が十分にあります。 したがって、問題を迅速に切り分けるために、メトリクスを定義、収集、分析する方法を明確に理解する必要があります。

理想的には、あらゆる種類のメトリクスとフィルターにリアルタイムで完全にアクセスできることです。 しかし、指標がたくさんあるため、コストの問題が生じます。 私たちの場合、次のようにメトリクスと開発ツールを分離します。

問題を検出して優先順位を付けるために、当社は独自のオープンソース リアルタイム システムを使用しています。 Atlas и ルーメン - 視覚化のため。 集約されたメトリクスをメモリに保存し、信頼性が高く、アラート システムと統合されます。 ローカリゼーションと診断のために、Elasticsearch と Kibana のログにアクセスできます。 統計分析とモデリングには、Tableau のビッグデータと視覚化を使用します。

このアプローチは非常に難しいようです。 ただし、メトリクスとツールを階層的に編成することで、問題を迅速に分析し、問題の種類を特定し、詳細なメトリクスを掘り下げることができます。 通常、故障の原因を特定するのに約 1 ～ 2 分かかります。 その後、特定のチームと協力して、数十分から数時間かけて診断を行います。

たとえ診断が迅速に行われたとしても、このようなことが頻繁に起こることは望ましくありません。 理想的には、サービスに重大な影響がある場合にのみ重大なアラートを受信します。 クエリ高速化システムの場合、通知するアラートは 2 つだけです。

• クライアント フォールバック率 - 顧客の行動の評価。
• プローブエラーの割合 - ネットワークコンポーネントの安定性データ。

これらの重要なアラートは、システムが大多数のユーザーに対して機能しているかどうかを監視します。 リクエストの高速化を実現できなかった場合にフォールバックを使用したクライアントの数を調べます。 システム内で大量の変更が行われているにもかかわらず、重大なアラートは 1 週間あたり平均 XNUMX 件未満です。 なぜこれだけで十分なのでしょうか?

1. プロキシが機能しない場合は、クライアントのフォールバックがあります。
2. トラブルに対応する自動操舵システムもある。

後者についてはさらに詳しく説明します。 当社の試用システムでは、クライアントからクラウドへのリクエストの最適な経路を自動で決定するシステムにより、一部の問題にも自動的に対応できます。

サンプル構成と 3 つのパス カテゴリに戻りましょう。 読み込み時間に加えて、配信自体の事実も確認できます。 データをロードできなかった場合は、さまざまなパスに沿って結果を確認することで、どこで何が壊れたのかを判断し、リクエスト パスを変更することで自動的に修正できるかどうかを判断できます。

Примеры：

このプロセスは自動化できます。 ステアリングシステムに組み込みます。 そして、パフォーマンスと信頼性の問題に対処する方法を教えます。 何かが壊れ始めたら、より良い選択肢があるかどうかに応じてください。 同時に、クライアントへのフォールバックのおかげで、即時の反応は重要ではありません。

したがって、システム サポートの原則は次のように定式化できます。

• 故障の規模を減らす。
• メトリクスを収集する。
• 可能な場合は故障を自動的に修復します。
• それができない場合は、通知します。
• 私たちは、迅速な対応のためのダッシュボードと優先順位付けツールセットの開発に取り組んでいます。

学んだ教訓

プロトタイプの作成にはそれほど時間はかかりません。 私たちの場合、4か月後に準備が整いました。 それによって新しいメトリクスを受け取り、開発開始から 10 か月後に最初の運用トラフィックを受け取りました。 それから、退屈で非常に困難な作業が始まりました。システムを徐々に製品化して拡張し、主要なトラフィックを移行し、間違いから学びました。 ただし、この効果的なプロセスは直線的ではありません。あらゆる努力にもかかわらず、すべてを予測することはできません。 迅速に反復して新しいデータに対応する方がはるかに効果的です。

私たちの経験に基づいて、次のことをお勧めします。

1. 自分の直感を信じないでください。

   チームメンバーの豊富な経験にもかかわらず、私たちの直感は常に裏切られました。 たとえば、CDN プロキシの使用によって予想される高速化や、TCP エニーキャストの動作を誤って予測しました。

2. 本番環境からデータを取得します。

   少なくとも少量の実稼働データにできるだけ早くアクセスすることが重要です。 実験室条件における固有のケース、構成、設定の数を取得することはほとんど不可能です。 結果に素早くアクセスできるため、潜在的な問題をすぐに知り、それをシステム アーキテクチャで考慮することができます。

3. 他の人のアドバイスや結果に従うのではなく、自分自身のデータを収集してください。

   データの収集と分析の原則に従いますが、他人の結果や発言を盲目的に受け入れないでください。 ユーザーにとって何が役立つかを正確に知ることができるのはあなただけです。 貴社のシステムや顧客は、他の企業とは大きく異なる場合があります。 幸いなことに、現在では分析ツールが利用可能であり、使いやすくなっています。 得られる結果は、Netflix、Facebook、Akamai、その他の企業が主張しているものと異なる場合があります。 私たちの場合、TLS、HTTP2、または DNS リクエストの統計のパフォーマンスは、Facebook、Uber、Akamai の結果とは異なります。これは、デバイス、クライアント、データ フローが異なるためです。

4. 不必要に流行を追わず、効果を評価してください。

   シンプルに始めましょう。 必要のないコンポーネントの開発に膨大な時間を費やすよりも、シンプルで実用的なシステムを短時間で作成する方が良いでしょう。 測定と結果に基づいて、重要なタスクと問題を解決します。

5. 新しいアプリケーションの準備をしましょう。

   すべての問題を予測することが難しいのと同様に、利点や用途を事前に予測することも困難です。 スタートアップ企業の顧客の状況に適応する能力を参考にしてください。 あなたの場合、新たな問題とその解決策が見つかるかもしれません。 私たちのプロジェクトでは、リクエストのレイテンシを短縮するという目標を設定しました。 ただし、分析と議論の過程で、プロキシ サーバーも使用できることがわかりました。

   • AWS リージョン間でトラフィックのバランスをとり、コストを削減するため。
   • CDN の安定性をモデル化する。
   • DNS を設定するため。
   • TLS/TCPを設定します。

まとめ

このレポートでは、クライアントとクラウド間のインターネット リクエストの高速化の問題を Netflix がどのように解決しているかについて説明しました。 クライアント上のサンプリング システムを使用してデータを収集し、収集された履歴データを使用してクライアントからの制作リクエストをインターネット上の最速のパスにルーティングする方法。 このタスクを達成するために、ネットワーク プロトコル、CDN インフラストラクチャ、バックボーン ネットワーク、DNS サーバーの原則をどのように使用するか。

ただし、私たちのソリューションは、Netflix がそのようなシステムをどのように実装したかの一例にすぎません。 私たちにとって何がうまくいったのか。 私のレポートの応用部分は、私たちが従って良い結果を達成する開発とサポートの原則です。

私たちの問題に対する解決策はあなたに合わないかもしれません。 ただし、独自の CDN インフラストラクチャを持っていない場合や、それが当社の CDN インフラストラクチャと大きく異なる場合でも、理論と設計原則は変わりません。

ビジネスリクエストのスピードも引き続き重要です。 また、単純なサービスであっても、クラウド プロバイダー、サーバーの場所、CDN プロバイダー、DNS プロバイダーの中から選択する必要があります。 あなたの選択は、顧客に対するインターネット クエリの有効性に影響します。 そして、この影響を測定し、理解することが重要です。

シンプルなソリューションから始めて、製品をどのように変更するかに注意してください。 学びながら、顧客、インフラストラクチャ、ビジネスからのデータに基づいてシステムを改善します。 設計プロセス中に予期せぬ故障が発生する可能性について考えてください。 そうすれば、開発プロセスをスピードアップし、ソリューションの効率を向上させ、不必要なサポートの負担を回避し、安らかに眠ることができます。

今年 会議は6月10日からXNUMX日まで開催されます オンライン形式で。 DevOps の父の XNUMX 人である John Willis 本人に質問することができます。

出所： habr.com