re:Invent 2025: Netflixの効率性と信頼性を両立するFleet運用とリスク調整済み容量計画
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - How Netflix Shapes our Fleet for Efficiency and Reliability (IND387)
この動画では、NetflixのスタッフソフトウェアエンジニアArghaが、効率性と信頼性のバランスを取りながらグローバルスケールでコンピュートインフラを運用する方法を解説しています。4リージョンのactive-activeアーキテクチャで運用するNetflixは、効率性を「リスク調整済みネット価値」として定義し、tier zeroサービスを30%、best effortを60-70%の利用率で実行する戦略的なフリート構成を採用しています。供給側ではsuccess bufferとfailure bufferの概念を用いた容量計画、需要側ではワークロードプロファイリングとservice capacity modelingを実施し、dynamic traffic shapingやpriority-based load sheddingなどの信頼性技術と組み合わせることで、数ヶ月単位のfleet shaping、数分単位のreactive scaling、数秒単位のload sheddingという多層的なリスク管理を実現しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
イントロダクション：Netflixの効率性と信頼性のバランスへの挑戦
おはようございます。皆さん、Reinvent 2025 へようこそ。私は Pratik Sharma で、AWS のプリンシパルソリューションズアーキテクトです。ここ6年間、Netflix と非常に密接に協力してきました。そして、ここ数年、Netflix は皆さんと彼らのジャーニーを共有してくれています。Netflix は AWS のスケールと柔軟性を活用した耐障害性のあるアーキテクチャを構築することのパイオニアとなっています。以前は、Netflix がどのようにコンピュートインフラストラクチャを効率的にスケールしているか、そしてどのようにサービスキャパシティモデリングを行っているかについて話しました。今日は、さらに深く掘り下げて、Netflix がどのように効率性と信頼性のバランスを取っているかについて見ていきます。本日は Argha をお招きする喜びがあります。Argha は Netflix のスタッフソフトウェアエンジニアで、現在 Netflix のライブオペレーションのスケーラビリティを確保する責任を負っています。
長年にわたって、彼はスケーラビリティと Netflix エッジでの可用性に関して Netflix が素晴らしいパフォーマンスを発揮することを確保することに取り組んできました。最近、彼と彼のチームは、Netflix がコンピュートスケーリングとキャパシティモデリングをどのように効果的に行うかを再定義しています。では、深く掘り下げて、Argha をステージにお迎えしましょう。ありがとうございます、Pratik。おはようございます、皆さん。私は Argha です。 Pratik が言ったように、私はインフラストラクチャ組織に属しています。Netflix での大部分の時間を、私たちが「エンドツーエンドストリーミングアーキテクチャ」と呼ぶものに焦点を当ててきました。これはグローバルデバイスから Netflix エッジ、つまり私たちの CDN、そしてクラウドエッジへと続き、当然のことながら私たちのユニークなマイクロサービスアーキテクチャへと続きます。私はほとんどの場合ネットワーク側に焦点を当ててきましたが、過去1年間は、コンピュート側のいくつかの難しい問題を解決することに関わってきました。
では、今日は何について議論するのでしょうか。私は、これがかなり密度の濃いトークだと言われていることを警告しておきます。これは意図的なもので、私たちが過去数年間、そして昨年の Reinvent を含めて話してきた多くの異なる側面にわたって、ほぼ2年間の投資をまとめていると思うからです。主なポイントは、Netflix がどのように信頼性を犠牲にすることなく効率性にアプローチしているかについて、より詳しく見ることです。これが意味することは、コンピュート供給をどのように計画するか、供給をどのように理解するか、需要がどのように見えるか、そして私たちのワークロードをどのように見るかなどのことを見ていくということです。
Netflixのグローバルアーキテクチャ：4リージョンアクティブ・アクティブ構成とOpen Connect CDN
そして最後に、私が任されている私のお気に入りの部分に至ります。それは、供給側がどのように見えるかと、リソース使用の観点から需要が実際にどのように見えるかのバランスをどのように取るかです。ただし、信頼できる技術をどのように実際に使用するか、例えばリスクをどのように管理し軽減するかについて掘り下げることなしには不完全です。定義上、皆さんのほとんどが知っているように、私たちはグローバル製品です。私たちは世界中、赤くない部分を除く地球上のあらゆる場所にいます。これが何を意味するかは、いつでも誰かが目を覚まして、K-pop を見たり、Demon Hunters を見たり、または最新の Stranger Things シーズンを見たり、ビンジウォッチしたいと思う可能性があるということです。そして彼らはこれをデバイスの全体的なフリートにわたって行うことができます。
これらはモバイルデバイス、PC、iPad、そしてテレビです。 これが意味することは、これらすべてが単一の安定したネットワークを共有していると仮定することはできないということです。これらがデバイス上で同じコンピュート機能を持っていると仮定することはできず、さらに重要なことに、これらが同じ解像度を持っていると仮定することはできません。これは、私たちがエンコードするバイトストリームの数と、それが必要とするストレージの量に影響を与えます。グローバルオーディエンスにサービスを提供する方法は、私たちが「4リージョンアクティブ・アクティブグローバルコントロールプレーン」と呼ぶものを実行することです。 アクティブ・アクティブの部分は非常に興味深いです。なぜなら、皆さんが推測できるように、私たちのスケールでアクティブ・アクティブモードで実行することを選択する企業は非常に少ないからです。私たちは4つの AWS リージョンにいます。US East 1、US East 2、US West 2、そして EU West 1 です。私たちがこのアーキテクチャを選択して固守する理由は十分にあります。
このうちの一つは、世界中のどこからでも、あのマップで見たような地球上のあらゆる場所から、低レイテンシー、本当に極めて低いレイテンシーでユーザーにサービスを提供できるようにしたいということです。さらに重要なのは、最近のAWSの障害のように、あるリージョンで何か問題が起きたときに、Twitterでトレンドになりたくないということです。Netflixがダウンしているなんて聞きたくないわけです。それは私の仕事の大きな部分であり、同僚たちがやっていることの一部でもあります。
これにより、以前話した failover という機能を実現できます。Netflixがどのようにそれを行うかについての詳細なトークがありますが、これが active-active モードが非常に重要である理由です。最後に、グローバルなコントロールプレーンを、実際のグローバルなデータプレーンで補完しています。それは Open Connect と呼ばれる自社開発のCDNです。CDNアーキテクチャについて本当に深く掘り下げた専用のトークがありますが、これがすべてがどのように組み合わさるかです。これはしばしば、エンジニアリングの観点から crown jewel と呼ばれるメトリクスとして参照されます。
効率性の定義：ビジネス価値とリスク調整済みネット価値の考え方
これが私たちがこれから深く掘り下げていくことの始まりです。ここで強調したいのは、私は多くの効率化技術と、私たちがどのようにして効率性にアプローチしているかについて話すつもりですが、同時に、私たちがこれを高い信頼性と可用性を保ちながらどのように実現しているかについても話すということです。ここにいる人の中で、自分たちのシステムをもっと効率的にするよう求められたことがある人は何人いますか？年間コスト、コンピュート支出、またはネットワーク支出を削減するよう求められたことがある人は何人いますか？
上司に対して、それはすべて良いことだけれど、代償は何か、リスクの観点から何をトレードオフしているのかを説明する機会を得た人は何人いますか？かなり少ない数だと思います。これが重要な理由は、一方なしにもう一方を持つことはできないということです。非常に効率的になることはできますが、信頼性の高い製品がなければ、ビジネスには大きなコストが発生します。ですから、いくつかの定義についてレベルセットしましょう。なぜなら、これらの2つの用語は人によって異なる意味を持つからです。
私は主に、Netflixにおいて効率性が何を意味するのか、Netflixにおいて信頼性が何を意味するのか、そして私たちがどのようにしてその両方を測定するのかについて焦点を当てるつもりです。効率性から始めましょう。ワークロードが存在する理由、またはあなたのサービスが存在する理由は、何らかのビジネス価値を生み出さなければならないということです。ビジネスに付加価値をもたらさないサービスを実行する意味はありません。どんなに tier 0 や tier 1 であっても、すべてのサービスはビジネス価値を生み出さなければなりません。それが最終的な目標です。
では、ビジネス価値を生み出すワークロードにはコストがかかります。そのワークロードのコストを理解する最もシンプルな方法は、そのワークロードを確実かつ効率的に実行するために必要なリソースの量です。リソース使用量について話すときは、サービス自体が行う作業だけではありません。その作業をサポートするために必要なインフラストラクチャの総量なのです。単一のワークロードから複数のワークロードを大規模にサポートするへと移行する必要があります。
最後に、これはしばしば見落とされることですが、障害はビジネスにコストをもたらします。障害のコストについてもっと深く掘り下げたいのですが、これは重要なことです。ワークロード推定やコストを考える際に、そのワークロードがダウンした場合にビジネスにとって何を意味するのかを考慮に入れずにはいられません。これがリスク面です。これはおそらく私がリーダーたちと一緒に使う好きなグラフの一つで、本質的にはポアソン分布のようなものです。
これが示しているのは、このグリーンラインのようにテールの方向に、非常に興味深い数字があるということです。その数字は確率の観点からだけでなく、スケールの観点からも興味深いのです。これを視点に入れるために、Netflix や Amazon のような本当に大きなビジネスを想定してみましょう。年間 ARR が 1000 億ドルの収益がある場合、1 分間のダウンタイムの良い推定値は何だと思いますか？1 分間のダウンタイムのコストは約 2000 ドルに近づきます。
もう一度それを心に留めてください。私たちのようなビジネスの 10 分間のダウンタイム、そして私は 1000 億ドルの収益だけを考えていますが、10 分間のダウンタイムは 200 万ドルの収益に相当します。これはビジネスがより重要になり、より大きくなるにつれて、本当にテールコストを気にし始める必要があるということを強調しています。障害のテールリスクには指数関数的な増加があり、これが私がこれをコストの一部として考慮に入れることの意味です。
では、システムの詳細に入らずに、まず効率がビジネスにとって何を意味するのかを見てみましょう。ビジネスにとって効率のビジネス価値は何でしょうか？価値の部分をもっとよく理解しましょう。私は本当にこのビジュアライゼーションが好きです。これはワークロードがいくつかの価値を生み出す方法について説明しています。
そのワークロードを実行するためのコストがあります。うまくいけば、それが提供する価値はそれを実行するコストより大きいはずです。でも、重要な部分が見落とされることがあります。私たちが考え出した用語が「リスク調整済みネット価値」です。そのワークロードが失敗した場合のコストは何でしょうか？ビジネスとして失敗を防ぐために、そのリスクを軽減するためにどれだけのお金を支払うか、または投資する必要があるのか？これが私たちが「リスク調整済みネット価値」と呼んでいるものです。だからこそコストがシフトするわけです。あなたのサービスの真の価値、つまり ROI は、単なるコスト対価値の比較ではなく、リスク調整済みネット価値を見たときにはるかに高くなります。
システム効率の測定：Kingsman近似と利用率の真実
これを 展開して、私のチームが何千ものサービスとバッチワークロードを実行している場合、フリート レベルではどのようになるでしょうか？最初のものは、私たちが「適度に効率的なワークロード」と呼んでいるものです。コストは価値より低く、良好なネット ROI があります。真ん中のものは、ビジネスに莫大な価値を生み出すワークロードのセットであり、私たちはそれらを比較的低いコストで実行できています。少ないお金でビジネスに対して巨大な ROI のようなものです。最後に、これは何としても避けたいものです。コストがビジネスに大きな悪影響を与える、非常に非効率なサービスのセットで、提供される集計値を大きく損なうものです。
ビジネス価値についてはまた後で戻ってきますが、私たちが深く気にかけている効率のもう一つの側面も見てみましょう。システム レベルで効率をどのように理解するかです。 私は自分のすべてのトークで最小限の数学を約束しましたが、ここにはいくつかの数学があります。 これはおそらく、少なくとも Netflix では、システム効率についてどのように考えるかについて、最も使用されているメカニズムの一つです。非常にシンプルで、パフォーマンス エンジニアリング全般を、私たちが Kingsman の近似と呼ぶものを通じて考えることができます。 まだ読んでいない場合は、このペーパーを読むことを強くお勧めします。リンクが張られています。簡単に言うと、基本的にはコンピュータ システムのパフォーマンスを、システムが新しい作業にどれだけ速く応答するかを近似することで予測できるということです。
システムに負荷と作業を追加し続けると、システムはどれだけ速く応答するでしょうか？右側のグラフでは、利用率を高くしていく、つまり作業を追加し続けると、到着率は実際にはあまり変わりません。新しい作業をサービスするのにかかる時間が非線形で、ほぼホッケースティックのようなスパイク状に増加する地点に近づいています。簡単に言うと、本質的にはキューイング遅延のようなものです。これが重要な理由は、少なくとも 2 つの重要なポイントがあるからです。1 つは、システム負荷、サービス時間、到着率を含むこの方程式に焦点を当てると、これらのいずれかを調整すれば、実際に結果が変わるはずだということです。
低い効率にすることができます。つまり、負荷の数が下がり、サービス レートは高いか安定したままになります。ロード バランシングや他のテクニックを試すことができ、それでもサービス時間は非常に予測可能なままです。最後に、利用率の観点からシステムをさらに高く、右の方へ押し続け、そのリスクを軽減するための他の対策がない場合、テールに近づいており、これは混雑による障害のリスクがあります。これは物理法則です。これを回避する方法はありません。ただ、これを設計で対処する必要があるだけです。
つまり、これは同僚が 利用率だけでは嘘だと言うことを指しているんです。そう言う理由は、このグラフに3つの例があるからです。3つのサービスすべてが、実は30パーセントの利用率で動作していると報告しています。しかし、これらのサービスの動作は根本的に異なっているんです。黄色い線の Service B に注目してください。どれだけスパイクしているか見てください。これを私たちはサービスタイムと呼びます。このサービスを私たちは非常に信頼性の低いサービスと呼ぶんです。30パーセントの効率がターゲットだからといって、それを達成できたから良いんだと言うことはできないんです。
一方、Service C には確かにばらつきがありますが、それはしきい値の範囲内に収まっています。Service A はただ平坦です。つまり、30パーセントの効率がターゲットだからといって、それを達成できたから良いんだと言うことはできないんです。
これはもう一つ強調したいポイントで、純粋な利用率だけを見て効率を測定することはできないし、すべきではないということです。到着率のようなその他のレバーを使ったり、負荷を分散させたりして、システムの効率を真に向上させるべきなんです。では、少なくとも高いレベルでワークロードのビジネス価値 をどのように理解するか、システムの効率をどのように測定するか、そしてそれを実際にフリート、つまりサービスのフリートに適用するとどのようになるかについての思考モデルを構築してきました。今は数千のマイクロサービスとバッチワークロードについて話しています。
ワークロード分類と効率的なフリート運用：Tier別の最適化戦略
これは非常に興味深いビジュアライゼーションです。このグラフでは、基本的に4つの異なるクラス のワークロードがあると言っています。最初のものは、私たちが深く気にかけているものです。これらは tier 0 で、フォールバックがありません。もしそれがダウンしたら、あなたのプロダクトはダウンします。ダウンタイムが発生します。2番目のものは degraded で、つまりそれらのワークロードのセットがダウンしたら、何らかの劣化した体験がありますが、大体においてプロダクトはまだ動作しています。最後の部分は best effort で、その次が batch です。Batch ワークロードは完了まで実行されますが、待つことができます。キューに入れることができるんです。
ただし、非常に興味深いのは、これら4つのクラスのサービスすべてを、大体50パーセント近くで実行しているということです。さて、これは通常、ビジネスのコンピュート支出がどのようになるかを示しています。これが5000万ドルか1億ドルか、どんな数字であれ、そうだと仮定しましょう。つまり、これら4つのクラスのサービスを50パーセントの効率で実行するために1億ドルを配分しているんです。みんなが満足していて、レポートが出てきて、人々はビジネスが素晴らしく進んでいると思っています。しかし、これは効率的でしょうか？答えはノーです。Netflix にとって、これは非常に非効率なフリートを反映しているんです。
効率性とはどのような形をしているのか。私たちにとって効率的なフリートというのは、実はこのような形をしています 。ここで私たちが意図的に選択しているのは、最も重要な tier zero のワークロードを、50% ではなく 30% という低い効率で実行するということです。もちろん、これは中央値または平均値です。フォールバックや劣化した体験を受け入れられるサービスは 50% で実行することを選択しています。しかし、より興味深いのは、best effort と batch という、私たちのサービスの全体的なコホートを、60% から 70% に近い、はるかに高い利用率で実行することを選択しているということです。
さて、このような形のフリートを実行するための総ドル支出がいくらになるか、推測できますか？興味深い答えは、これもまた正確に 100 万ドルなのです。より効率的になるために、さらに多くのドルを追加しているわけではありません。これはビジュアライゼーションですが、過去 2 年間、特に live ads のような私たちの取り組みを含めて、Netflix でサービスを実行する方法に対して、これは本当のことです。これにより、私たちは効率性が私たちにとって何を意味するのかを再定義する必要がありました。前のスライド とこのスライドの間で、コンピュート支出は正確に同じであることを再度強調します。
では、メトリクスについてです。Netflix では本当に数字が好きです 。効率性についての私たちの考え方と、測定したいものをまとめると、まず 1 つ目は、私たちがドルをどこに使っているのか、明らかにビジネスにとって重要だからです。次のものは非常に興味深いです。ドルを使っているところであれば、それらのドルが何らかの形で私たちのリスクを軽減しているかどうか 。3 番目は、Kingsman approximation が登場するところですが、リスクを管理しながら、コストを削減するために私たちが引くことができるレバーは何か ということです。これは非常に重要であり、私は何度も強調し続けます。Netflix では、信頼性とリスクも考慮せずに、効率性について考えることはありません。
信頼性の定義：予測可能なレイテンシと障害ドメイン分離
最後のポイント、これは私の追加ですが、正当な理由のために、単に利用率を上げることに対する近視眼的な焦点に対する魅力があります。つまり、物事をより熱く実行するだけで、私たちは皆効率的になることができるということです。それに対する私たちの反論は、はい、しかしそれは単なる 1 つのレバーに過ぎないということです。私たちは他のレバーを引くことができます。それは効率性を管理するだけでなく、リスクも無視しないという、より良い仕事をしています。 信頼性について深く掘り下げる前に、重要なポイントは、効率性と信頼性についての私たちの考え方を表現しなければならないとすれば、私たちは信頼性を、それ自体のものではなく、実は補完的な構成要素として見ているということです。信頼性は効率性に対する補完的な構成要素です。そして、それは私たちにとって何を意味するのか？最低限、それは、特に tier 0 と tier 1 のサービスが、予測可能なレイテンシで応答できることを意味しています。
低い部分は高スケールでは明らかですが、より多くの負荷を投げかけるとき、ライブイベント中や新しいシーズンの殺到中に、それらのホッケースティックスパイクを受け入れるとき、レイテンシの劣化や野生のスパイクは望みません。これが最初の原則です。
バッチワークロードについては、私たちは大量のエンコーディングジョブをコンテンツ用に実行する必要があるため、低レイテンシーでスケジュールしたいと考えています。つまり、ワークが実行されるのに X 時間かかってもいいのですが、バッチワークロードのスケジューリング遅延に大きなスパイクが発生することは避けたいということです。これらはトランザクション的ではありません。
私たちは、ゼロの障害が存在すると信じていません。あるいは、障害を完全に防ぐことができると信じていません。しかし、障害が稀であることは重要です。また、何か問題が発生したときに、それが迅速に回復することを深く気にかけています。
最後に、信頼性のもう一つしばしば見落とされている側面は、障害ドメインの分離を深く気にかけているということです。障害ドメインがどのようなものであるべきかを明確に説明することに優れていなければなりません。そのソフトウェア、ワークロード、またはシステムが障害を起こしたとき、他に何が影響を受けるのか？そのスコープをどのように最小化できるか？
では、信頼性について、私たちは何を測定しているのか？単にラインを測定するだけではなく、業界として私たちは多くの議論をしてきており、今も続けており、それは重要ですが、Netflix では他に何を測定しているのか？私たちはビジネスへの影響、つまり爆発半径のようなものを気にかけています。1 つのシステムまたは一連のシステムが障害を起こしたとき、ビジネスへのコストは何か？
私たちは、それがどのくらいの頻度で障害を起こすかを気にかけています。これの非常に良いメトリクスは、平均故障間隔です。私たちは回復時間を気にかけており、つまり平均復旧時間を多く測定しています。
では、効率性と信頼性についての理解を深めたところで、ここからは私たちが実際に使っている技術についてお話しします。ただ、ここで一度立ち止まって強調しておきたいのは、これからお話しすることは単に効率性に焦点を当てたものではないということです。定義上、リスク管理をしながらどのように効率的になれるかということも含まれています。
サプライサイド管理：キャパシティプランニングとバッファ戦略
これが実現可能であるためには、まず第一に、私たちのサプライサイドがどのような状況にあるのかを理解する必要があります。私の場合、それはコンピュートサプライを意味します。AWS が私たちのベンダーであるおかげで、すべてのリージョンで必要なコンピュートの量がどのくらいなのか、それがどのように割り当てられるのか、そしてそれをどのように効率的に使うのかについて、非常に正確である必要があります。
最初の部分は、多くの皆さんがご存知のように、スケールで事業を行っているほとんどの組織が行っていることです。これはキャパシティプランニングと呼ばれています。これは本質的に、特にコンピュート支出に対して、私たちがどのようにドルを配分するかについて述べています。
これは可視化として非常に興味深いのですが、これは本質的に Netflix の場合、私たちが最小限でも非常に異なる 2 つのサービスセットを持っていることを示しています。黄色は stateful レイヤーで、つまり Cassandra、EVCache、そして私たちのキーバリューストアのような永続的なストアです。これらは興味深いのは、オートスケーリングの激しいパターンを本当に持っていないということです。つまり、私たちはこれらのノードを非常に予測可能な方法で、一定量のクォーラムで実行する必要があります。私たちはこれらのためにキャパシティを事前に予約する必要があります。定義上、これらは高速にスケールすることはできません。ノードが起動するとき、調整に 30 分から 60 分かかります。これは、キャパシティ配分についての考え方が、私たちは常にこれらのためにコンピュートを予約する必要があるということを意味します。これは簡単です。
しかし、マイクロサービスフリートという別のサービスセットがあります。これらは定義上 stateless で、負荷に応じて非常に異なるスケーリングパターンを持っています。これは単なる日周パターンですが、追加の負荷がある場合、ピークが若干異なるのと同様に見えます。
問題は、そのピーク時の容量を予約することができないということです。つまり、できなくはないんですが、それは非常に非効率になってしまいます。では、どうするのか？実際のところ、答えはAmazonとの価格設定に基づいて、どのようにして reserved spend と呼ばれるものにドルの何パーセントを充てるべきかを明確にできるかによって異なります。この黄色い領域全体は、stateful だけでなく、stateless フリートの一部も含めることができ、また含めるべきです。しかし、その上に、非常に重要なのは、on-demand 容量にどのくらい支払うべきかを決定することです。
興味深いのは、reserved に使いすぎると、非効率になるということです。一方、on-demand に使いすぎると、これはおそらくより高い価格ですが、これもまた効率的ではありません。Netflix は reservation trough を再利用することに関して賢明です。私たちのワークロードはグローバルなトラフィックパターンを持つ diurnal なので、私たちは長年にわたって容量のシフトに投資してきました。これらの大規模なバッチワークロードをこの容量にスケジュールして移動させます。つまり、私たちはすでに支払っている reservation があるので、どうせならその容量を使ってサービスができないときにバッチを実行した方がいいということです。
容量計画への別の非常に重要な入力は、ハードウェアの可用性です。その reservation グラフでは、ファミリーとハードウェアシェイプについて詳しく説明しますが、AWS が素晴らしいパートナーとして素晴らしい仕事をしてくれているとしても、私たちが望むすべてが常にオンデマンドで利用可能だと仮定することはできません。これが実際に私たちにとって意味することは、compute availability を考慮に入れる必要があるということです。これは非常に興味深いグラフで、おそらく私のお気に入りの一つです。よく見ると、わかりやすくするために色分けしてあります。これは約1年前のものです。ハードウェアの安定した世代、主に fifth-generation と sixth-generation を見ると、容量の可用性はほぼ保証されています。ハードウェアベンダーが本当に良い仕事をしてラッキングとスタッキングをしているので、深い供給があります。しかし、新しい世代のハードウェアに到達すると、これは seventh-generation の AMD と Intel です。ここが私たちが目指す場所です。私たちはフリートを新しい世代の効率的なハードウェアに向けて移動し続けたいのですが、その後、私たちは volatile frontier と呼ばれるものに近づいています。
ハードウェアベンダーがここで deep supply pool で提供できるのと同じ容量を保証できるとは仮定できないというのは興味深いことです。これを行う方法は、新しい世代のハードウェアを採用したいということですが、段階的に、フリートの一部で採用し、私たちはこれについて本当に上手です。もう一つの部分は、新しいハードウェアをベンチマークする必要があるということで、これは私の最も強い学習の一つです。すぐにプールに足を踏み入れなくても、これらの異なるファミリーがどのように比較されるかについての確かなベンチマーク参照を持つ必要があります。これについて多くの重い作業をしてくれている performance engineering チームに大きな感謝を送ります。
もう一つの部分は、前のグラフを補完するもので、ファミリーだけの問題ではありません。また shapes についても同じです。このグラフが示しているのは、X軸上に、1 Xcel から 16 Xcel まで右に向かう shapes があります。これは素晴らしいです。なぜなら、右に向かうほど、定義上、より効率的になるからです。これらのインスタンスをより高くプッシュできますし、これらのインスタンスでより高温で実行できます。これは素晴らしいことです。しかし、同時に供給のリスクを引き受けています。ここでのリスクは、これらのインスタンスでより高く、またはより大きく進むにつれて、ベンダーはより複雑な bin packing の仕事をする必要があるためです。皆さんの中には、bin packing は簡単な問題だという私のジョークを知っている人もいるかもしれません。何が悪くなる可能性があるでしょうか？Bin packing は本当に難しい問題です。ですから、ベンダーが誰であるかは関係ありません。効率的である間、より大きなインスタンスに向かい続けるなら、ここでの可用性リスクについても認識する必要があります。これは容量計画のためのもう一つのトレードオフです。
3番目の要素は、Netflix が行ったことの中でも非常にユニークなものです。私たちは供給を理解するためのアプローチに3番目の構成要素を追加しました。これを私たちは buffer と呼んでいます。本質的には、ヘッドルームを理解するための方法です。 Buffer の定義によれば、あるサービスが与えられたとき、そのサービスのヘッドルーム内には2つの領域があります。1つは success buffer と呼ぶものです。これは黄色い部分です。この部分は、ある一定のポイントを超えて、つまりここでサービスが順調に動作している状態を超えて、この領域にさらに負荷をかけた場合、サービスはまだどのくらいの追加負荷を吸収できるのかということを意味しています。予測可能なレイテンシーや他の点で何の影響もなく吸収できるということです。劣化がありません。これが success buffer と呼ぶものです。さて、その黄色い線を超えてさらに高くまで行くことができますが、最終的にはサービスが落ちるまで行くことができます。そしてこの小さな領域がここにあるのが failure buffer と呼ぶものです。
これが重要な理由は、これらの構成要素がハードウェアにワークロードを割り当てるときの容量計画に役立つからです。success buffer と failure buffer の両方を考慮に入れる必要があります。もう1つの理由は、おそらく最も重要な理由ですが、このプレゼンテーションでは CPU コア、メモリ効率、クロック周波数、またはハイパースレッドのような構成要素を使用していませんが、その情報はマップに含まれています。単にそれらの詳細には深く掘り下げていないだけです。
これが可能にすることは、高レベルの構成要素を取り、ファミリーの形状の詳細、スレッド、クロック周波数をこれらの構成要素に変換することです。これらは instance family と shape の両方にわたって変わります。定義上、これはポータビリティを実現します。私は success buffer と failure buffer のこのコンセプトが本当に好きで、Netflix がこれを容量計画にどのように使用しているかを見ていきます。
しかし、2番目に最も重要なことは、buffer の定義によれば、ワークロードによっても異なるということです。この部屋にいる人の中で、例えば compaction ワークロードを実行していたためにデータセンタークラスタが落ちたという話を聞いたことがある人は何人いますか？これが意味することは、stateless サービス、つまり私たちが非常に JVM ヘビーなものは、理由付けが簡単だということです。それらは一定の負荷で実行され、より多くの負荷を受け取り、それを超えると劣化します。Cassandra や Memcached のような stateful サービスに行くと、それらは計画する必要がある独自の奇妙な特性を持っています。
ここの背景 buffer は、Cassandra ノードのセットが compaction を実行した場合、それがどのようなヘッドルームに見えるかを計画している私たちを表しています。これを容量計画の一部としてどのように計画するのでしょうか？これは数学がまったく異なることを意味します。Cassandra ワークロードの success buffer を同じしきい値のセットにピン留めしていません。簡潔にするために、これらは CPU 番号ですが、それらがどのように異なるかを見ることができます。私たちはこの追加 buffer を計算し、容量計画に組み込んでいます。
ワークロードに加えて、バッファもハードウェアタイプによって異なります。これは私たちの内部ベンチマークからの数字で、実際にはどのようなものかというと、7世代の AMD と Intel の両方がありますが、形状も異なっています。これが示しているのは、7世代の 8XL をより強くプッシュできるということです。これは CPU の 88% に対して、ハイパースレッド Intel でプッシュするものと比較しています。また、形状が大きいほど、より強くプッシュできます。サービスによって異なりますが、tier zero はフォールバックがなく、tier one は劣化しています。異なる量のバッファを計画しているため、意図的にそれらをあまり高温で実行しないことを選択しています。この例では、tier zero は 35%、tier one は 46% で実行されます。これは容量計画でバッファを計画する際に念頭に置く必要があるもう1つのことです。
デマンドサイド理解：ワークロードプロファイリングとトラフィックパターン
これで供給側を理解したので、実際の compute 需要がどのようなものであり、どこから来ているのかも理解する必要があります。バランシングの部分に到達する前に、このメンタルモデルを持つ必要があります。需要を理解するための最初のステップは、ワークロードレベルで彼らが仕事をするために必要なリソースが何であるか、そしてそれを推定するためのアプローチを理解する必要があります。
これは複雑ではありません。基本的に、CPU、メモリ、ネットワークという、仕事を推定するための3つの最も一般的な方法を使用しています。CPU 側では、これはずっとシンプルです。VM で実行しているか、コンテナで実行しているかに関わらず、利用率を示すメトリクスがあることを願っています。メモリはもう少し興味深くなります。ここ1年ほどで最も興味深い時間の1つは、私たちが非常に JVM ヘビーなフリートであるため、ヒープサイズに基づいてメモリを推定することはできないということを理解することでした。また、allocation rate を深く気にする必要があり、それは使用している garbage collector、parallel allocator かどうかなど、によって大きく変わります。ワークロードに基づいてメモリを推定するための独自の数学を考え出す必要があります。
ネットワークも興味深いです。ステートレスサービスの場合、それらは本当にネットワークバウンドですが、ステートフルサービスの場合、非常に興味深いパターンが見られます。そのワークロードが何をしているかによって、ベースラインがある一方で、ネットワークのバーストを考慮する必要があります。これらすべてが意味するのは、ワークロードのメンタルモデルを持つ必要があるということですが、本番環境でそれらを観察する必要もあります。これは、既存の本番ワークロードを見て、この例では CPU から RPS への比率にフィットさせようとしている実際のグラフです。
これは、与えられた RPS に対して、どの程度の効率または利用率で実行されているかを示しています。明らかに、フェアロードバランシングおよび他の要因を想定しています。これが私たちにできることは、特定のターゲットとスケーリングターゲットにフィットさせることで、これについては後でプレゼンテーションで説明します。ここでの重要なポイントは、モデルを持つことができますが、これを行う最良の方法は本番環境でワークロードを観察することです。
もう一つ、しばしば見落とされたり無視されたりする重要な点は、サービスのスタートアップ時間を本当に気にかける必要があるということです。容量を追加することはできますし、できれば素早く追加できますが、JVM の起動にかかる時間、OS の起動時間、そしてスケジューリングにかかる時間を考慮に入れる必要があります。これを考慮しないと、パフォーマンスの低下が生じ、新しい容量が追加される前に保持する必要があるバッファを補うことができなくなります。サービスのスタートアップ時間は、私たちがワークロードでモデル化する 3 番目の要素です。
ワークロードプロファイリングとワークロードレベルでの使用状況の理解について説明してきましたが、ここからは Netflix のトラフィック全体という観点から、これがどのように見えるかを見ていきましょう。 これは私たちのマイクロサービスアーキテクチャの簡略図です。デバイスがフロントドアを通ってやってきます。これは Zo という私たちのオープンソースゲートウェイです。トラフィックは services という federation レイヤーに流れ、そこから data gateways を通じてデータストレージを呼び出します。しかし、負荷という観点では、フロントドアを通じて 4 倍の負荷スパイクが発生した場合、 それが自動的にすべてのサービスに対して 4 倍のスパイクに変換されるわけではありません。
これは非常に興味深いことです。再生に不可欠な tier zero ワークロードに対しては 2 倍のスパイクになるかもしれません。あるいは、ブラウジングや番組を見つけるときの discovery に不可欠な何かに対しては 3 倍のスパイクになるかもしれません。そして、次に見たい番組を決定する ranking のようなものに対しては 1.5 倍のスパイクになるかもしれません。つまり、バッファと容量配分に関して、同じ計算式をすべてに適用することはできないということです。要点は、マイクロサービスの呼び出しパターンとあなたのユニークなアーキテクチャが、需要をどのように推定し理解する必要があるかに非常に大きな影響を与えるということです。
これが本番環境での私たちの状況です。4 つのリージョンで運用しているため、非常に予測可能な要素があります。これは良い点です。24 時間の周期性があります。つまり、同じリージョン内では 24 時間ごとに、毎日、週ごとにほぼ同じ量の使用量があるということです。しかし、リージョンのピークとトラフの間には 10 倍のデルタがあります。これが重要な理由は、このピークのために計算リソースを予約することは非常に非効率だからです。私たちはそれができません。これを 4 つのリージョンに掛けると、それは私たちが使いたくない多くのドルになります。
しかし、この予測可能性には価値があります。これにより、フェイルオーバーのようなことができます。US East 1 に問題が発生した場合、私たちはそのリージョンから抜け出します。そしてこの予測可能性により、US East 1 から X 量のトラフィックを移動させた場合、他の 3 つのリージョンでこのトラフィックをバランスさせるために必要な追加の計算リソースはどのくらいかを言うことができます。 その後、予測不可能な、つまり不確実な需要があり、これについても考慮する必要があります。これは、タイトルが非常に人気になったとき、ライブイベント、Jake Paul のファイト、あるいは Stranger Things のローンチのような場合に発生します。これらのケースでは、需要は非常に異なって見えます。ですから、定義上、私たちはこれについても考慮する必要があります。
需要と供給のバランシング：Pre-scalingとDynamic Traffic Shaping
では、供給側と需要側の両方について、ある程度まともなメンタルモデルが得られたと思うので、ここからが私の仕事の楽しい部分です。私たちは需要と供給を完璧に管理するという任務を与えられています。私はよく冗談で、この任務は未来を予測するよう求めているようなものだと言います。株価が上がるか下がるか予測できるか、あるいはどの株が上がるか下がるか知ることができるかと聞かれるのと似ていて、もし間違ったらどうなるか想像してみてください。では、私たちが何をしているのか深掘りしていきましょう。ただし、まず基本原則から始めます。
バランシングについて話すときは、私たちが話す効率性が、ローカルな最適化ではなくグローバルな最適化である必要があることを非常に正確に理解する必要があります。つまり、ローカルレベルでは非常に効率的な最適化の決定に終わることがよくありますが、それはグローバルレベルでリスクを追加します。そのリスクはサービスのためのものであったり、ドルのためのものであったりします。 次に、バッファーまたはヘッドルームは、私が説明したように、最も重要なサービスが必要な時に存在する必要があります。ここで強調したいのは、バッファーが存在するだけでは十分ではないということです。バッファーは適切な時期に、適切なサービスセットのために存在する必要があります。
最後に、私が話していることすべてが、供給側と需要側の両方を管理するこの大きな負担を伴うことを想像できます。 これはサービスチームレベルではスケールしません。私たちのようなインフラストラクチャチームが、供給側と需要側の両方で大部分のこの重い作業を行う必要があります。バランシングについて話してきましたが、今は供給管理をどのように行うかについて説明しています。 最初のポイントは、ハードウェアの可用性、適用可能性、ワークロードプロファイリングについて議論しましたが、どのワークロードがどのハードウェアで実行されるべきかというマッチングゲームを行う必要があるということです。それをどのように行うかを見てみましょう。
これは、私たちが通常 service capacity modeling と呼ぶものの可視化です。 最低限、良い単純化は、私たちが考慮する必要があるモデリングパターンが2種類あるということです。1つは stateless 用で、もう1つは stateful 用です。私たちはそれ以上のことをしていますが、それが最低限です。これが示しているのは、3つの重要なデータを考慮する必要があるということです。1つはハードウェアデータそのもの、つまりどのファミリー、どの世代、どのクロック周波数、ハイパースレッドされているかどうか、そしてコア数です。2つ目は価格データで、これはベンダーとの関係に非常に固有のものです。3つ目は、当然のことながら、私たちが以前見たワークロードデータです。
これら3つをすべて組み合わせると、私たちが実行するすべてのサービスに対する一連の推奨事項を得たいと考えています。それは、このサービスを実行するのに最も最適なハードウェアが何であるかを示しています。こんな感じです。この場合、これは私たちの stateless サービスの1つです。モデルは本質的に、これら3つのデータをすべて組み合わせると、C7A2 Excels で実行するのが最も最適なハードウェアであるべきだと言っています。 これをすべてのサービスに対して中央リポジトリに保持していることに注意してください。C だからというのは、これはコンピュート集約的なワークロードだと思われます。つまり、これを R で実行するのは非効率的です。これは非常に重要な気づきです。
では、推奨事項の2行目は何かというと、興味深いことに、サービス全体で推奨ハードウェアタイプのリストを持つだけで終わらせることもできるんですが、実際にはそれではうまくいかないんです。ハードウェアの可用性が保証されていないからです。では、可用性がない場合はどうするか。各ワークロードが実行できるフォールバックシェイプもたくさん推奨しています。ただし重要なのは、これらも本番環境でカナリアを通じて検証する必要があるということで、本番環境でのテストについてはよく話題になります。ここで一貫性が見られるのは、これがコンピュート バウンドだからこそ、C-series の両方を推奨しているということで、違いは6世代と7世代です。6世代の方が7世代に移行するよりも安いと思われますが、別のハードウェアになります。
最後に、ワークロード レベルでハードウェアの供給と需要を理解した後、推奨事項を適用した後、それがどのように見えるかを確認する必要があります。フリート全体にどのように適用するのか。数千のサービスがあります。これを fleet shaping と呼んでいます。これが意味するのは、任意の時点で3つの異なるコンテキスト、パフォーマンス、コスト、ビジネス容量を見ると、すべてのリージョンに対してハードウェア シェイプとファミリーの分布がどのようであるべきかの概算を出すことができるということです。右側に示しているのがこれです。playback、discovery、personalization、tier zero、tier one。これは M7A、R7A、C7A、6世代 Intel の大まかな分割です。
ただし、リージョン内で一定量の容量が必要な場合を考慮していません。しかし、特定のファミリーで不足している場合はどうなるでしょうか。それはかなり可能性があります。例えば7世代では、私たちは本当にこれを経験しました。これらのプールが逼迫している場合、どうしますか。ここで興味深いのは、7世代 AMD M7A が容量不足である一方で、わずかに効率は落ちるかもしれませんが、はるかに堅牢な可用性を持つ他のハードウェア シェイプで実行できる機会を見つけるオプションがあるということです。ここで代替シェイプが活躍します。
実際にはどのように見えるかというと、その例では、このフリート全体のシェイピング ループを開始しようとしています。これは tier zero サービスに触れずに、それらは最も重要なものだからですが、他にどのようなワークロードに触れることができるか、現在 M7A で実行されているが、1万 vCPU が不足しているため、それらを移動し始めるのに何が必要かを言うことになります。
では R7 です。これは明らかに、主にメモリ バウンド ワークロードについて話していることを過度に単純化していると仮定していますが、メモリ バウンド ワークロードのそのコホートを見つけることができれば、M7XL から R7 XL への移動のフリート シェイピング ループをオンデマンドで実行できます。ベンダーは、その容量が十分にあるかどうかを教えてくれます。
もう一つのポイントは、リージョンに必要なキャパシティの見積もりが出たので、シェーピングが完了したということです。では、実際にフロントドアから入ってくるトラフィックをどのようにアカウントするのか。これは pre-scaling と呼ばれるものです。こういったことをする必要があります。これは科学であり、同時にアートでもあります。定義上、これは crystal ball predictions と呼ぶものを含んでいます。例えば Stranger Things シーズン56の立ち上げ時のピークビューアーシップがどのようになるかを見積もる必要があります。
つまり、そのピークビューアーシップをグローバルなピークトラフィック推定に変換する必要があります。その後、そのトラフィック推定をリージョナルトラフィックに分割し、そこからコンピュート需要に進むことができます。しかし最後に、そのようなことが起こった時に私たちが望むよりもホットに実行されている可能性があるため、フリートをスケールアップする必要があります。実際には、こんな感じになります。ここで午前7時に特定のものを立ち上げるとトラフィックが到着することがわかっています。
私たちは数学とモデリングを使ってフリートを事前にスケールします。これを min pinning と呼びます。ご覧のように、ここでフリートをスケールアップし、ここでトラフィックが到着し、うまく処理できます。しかし、ここで私のお気に入りの部分は、この部分ではなく、もっと深く掘り下げます。これは auto scaling と呼ばれています。その理由は、サービスをスケールアップしすぎて非効率に実行されるようにしたくないからです。最後にこの auto scaling が欲しいのです。
そして最後に、トラフィックが去った後、すべてが自動的にスケールダウンされます。サービスオーナーはここで何もする必要がありません。pre-scaling はいろいろな方法で行うことができます。非常に非効率な方法で pre-scaling を行うことができます。これを overscale と呼びます。ターゲットをはるかに下回っており、これをフリート全体で合計すると、数百万ドル、数億ドルになります。
これを行うこともできます。underscale することができます。これはサービスを非常に厳しく押し、特に tier 1、tier 2、tier 0 がほぼキャパシティで実行されているため、落ちるリスクがあります。これはかなり悪いです。
しかし、私たちは確実にしたいのです。tier zero がターゲットに近く、少し下で効率的に実行されるように、tier one がホットに実行されているが落ちるほどではなく、tier two も同じように pre-scale したいのです。
では、効率的な pre-scale とは何かというと、もしあなたがジョブをうまくやり遂げたら、これはどのように見えるのかというと、pre-scale があったのと同じグラフの中にあります。ここにトラフィックが到着するのが見えます。この緑の線がスパイクアップします。つまり、平均 RPS が高くなるということです。しかし、その後、別のツールがあります。これについては少し詳しく説明しますが、load shedding が起動します。しかし重要なのは、それが非常に短く、最小限だということです。そして、新しい容量が追加されるとすぐに、RPS が正常化します。つまり、私たちは再び順調に進んでいるわけです。
そして、前の部分で言ったように、auto scaling のこの短い期間があります。つまり、これは私が本当に気に入っているグラフです。なぜなら、これを参考資料として指し示すのが好きだからです。pre-scaling を正しくやっているなら、これのすべての要素が必要です。load shedding がまったくなかった場合は正しくありません。それは overscale したということを意味します。reactive scaling がまったくなかった場合は正しくありません。それは overscale したということを意味します。そして、sustained load shedding があった場合は、underscale したということを意味します。そこにいたくはありません。
リスク管理技術：Reactive ScalingとPriority-based Load Shedding
では、実際にこれをどのように達成するのかというと、私はこれを dynamic traffic shaping と呼んでいます。そして、それには 2 つの重要なことが関わっています。1 つは、既に region にあるトラフィックを取得して、それを 4 つの region 全体に再配分する方法を見つけなければならないということです。これがどのように見えるかというと、もし私が何もしなかったら、任意の時点で、regional delta のこの奇妙なパターンが見えるでしょう。EU West のような 1 つの region はおそらく trough に向かっており、別の region は非常に異なる容量で実行されています。
それが trouble である理由は、容量を計画するのが非常に難しくなるからです。しかし、私はこれを行うことができます。そして、ここの真ん中を見ると、実際にこのトラフィックのバランスを取ることに成功しています。つまり、この wild delta は今、削減されています。これが重要なのは、そうすることが、データセンターにヒットする新しいトラフィックで何をするかを理解するための前提条件だからです。Sergei と他の人からの深いトークがあります。Netflix は独自の DNS と authoritative resolver を使用して、トラフィックを region にステアリングしています。これは通常、何も介入しない場合のように見えます。US East 1 がはるかに多くのトラフィックを受け取っているのに対し、West 2 と East 2 はそれほど多くを受け取っていないのが見えます。
これはバランスが取れていません。新しいトラフィックについては、shaping rule を公開し、steering を強制することも好みます。これは一時的に latency にとって最適ではないかもしれませんが、バランスをもたらします。US East 1 に行ったであろう人々を他の 2 つの region に押し出し、こうしてバランスを達成しています。これは新しいトラフィックについてです。そして、これら 2 つのステップは補完的です。新しいトラフィックを取り出し、region 全体に再配分し、その後、そうでなければ最も負荷がかかっている region のいくつかにおおよそ到着したであろう新しいトラフィックを再ステアリングします。
新しい負荷 がやってくると、こうした予測不可能な変動が大幅に増幅されてしまい、ほぼ確実に「iced」と呼ぶ状態になってしまいます。つまり、キャパシティを計画できていない、あるいは不可能な状態ですね。もし計画していたとしても、コンピュート費用が非常に大きくなって、極めて非効率になってしまいます。しかし、shaping を使うことで、これが実現できるようになります。予測不可能なスパイクを抑えて 、キャパシティをより良く管理できるようになります。ピークは増幅されますが、今はそれが十分な範囲内に収まっており、より効率的に運用することができるようになります。Traffic shaping はツールキットの中で非常に重要なツールです。
ここまで バランシングと、供給と需要を完璧にバランスさせることについて話してきましたが、実際にはこれは非常に難しいということは誰もが知っています。そうなることを望むことはできますが、同時にこれを実現する方法、あるいはそうでない場合のリスクを管理する戦略も必要です。リスクを管理するために使う最後のレバーをいくつか簡単に説明します。これらは信頼性技術です。
最初のものは reactive scaling です。キャパシティ計画を完璧に正確に行わない場合、新しいキャパシティをどのくらい速く追加できるかを考慮する必要があります。 このために、3 つのことが必要です。サービスレベルでは、scaling targets を設定します。少なくとも 3 つの異なる数値があります。 私たちが target tracking と呼ぶものがあります。これはサービスがこのしきい値に達したときのしきい値です。新しいキャパシティの注入を開始したいのですが、ゆっくりです。hammers と呼ぶ別のしきい値があります。非常に適切に名付けられていますが、これに達すると、より多くのキャパシティを追加し始めますが、ボリュームとスケールの両方でより速くなります。最後に、すべてのスケーリングに対応できない場合でも、トラフィックを削減したいのです。
クラスタレベルでは、これはすべて自動化されています。 私たちのシステムは CPU-based scale-up と呼ばれるイベントを発火させます。基本的には、target tracking が発火したため、フリートシェイプをバンプアップし、新しいインスタンスをスピンアップする必要があることを示しています。これは基本的に目的のコンピュートがあるべき場所であり、これが現在の場所です。その補完的な側面は、キャパシティを永遠に保持することはできないということです。 トラフィックが減少したとき、そのキャパシティを返したいのです。私たちはこれを scale down と呼びます。これも非常に自動化されています。
興味深いのは、以前に fleet loop について話しましたが、それはハードウェア計画、調達、そしてそれをフリート全体に展開することのため、数ヶ月の単位でしか動作できないということです。 そこから、しかし、私たちはちょうど reactive scaling について話しました。そしてそれが行ったことは 数ヶ月ではなく、数分の単位で反応する別のレバーを私たちに与えることです。これは補完的な信頼性技術であり、月次または四半期ごとの変更だけに頼ることはできません。数分の単位で動作するものが必要です。 しかし、order scaling は遅くなる可能性があります。コントロールプレーンに遅延が生じたり、OS スタートアップに遅延が生じたり、JVM を実行している場合は JIT と JVM スタートアップに時間がかかる可能性があります。昨年の re:Invent での Ryan のトークを見ることを本当にお勧めします。彼はこれらの問題のいくつかをどのように修正するかについてはるかに深く掘り下げています。重要なポイントは、真にリスクを軽減したい場合、auto scaling だけに頼ることはできないということです。
では、容量を素早く追加できない場合、どうするのか。私たちは 負荷を削減する必要があります。これが意味するところは、負荷削減には2つの方法があるということです。すべてを削減することもできます。これを bulk load shedding と呼びます。 あるいは、どの負荷を削減するかについて、もっと意見を持ち、スマートに対応することもできます。これを priority-based load shedding と呼びます。
同じグラフで、これがどのように見えるかというと、サービスが良好なモードで動作し、健全に機能していて、その後新しいトラフィックが入ってきます。追加のトラフィックが到着しても、まだ success buffer の領域内です。すべてが緑です。しかし、さらに負荷が加わると、私が failure buffer と呼ぶものに近づき始めます。 ここが注意を払う必要があるところです。ここが負荷削減を開始したいカットポイントです。 避けたいことは、もしそれをしなかったら、ここに終わってしまうということです。これは私たちが崩壊することであり、ご覧の通り、これは大混乱です。実際の高速道路の交通の例えを使うなら、重要なことは、トラフィックを落とすことはできますが、影響があるということです。トラフィックを無差別に落とすだけなら、顧客への影響が出てきます。
だから、実際にやりたいことは、ここのトラフィックだけを削減したいということです。友人の例えを使うと、非常に混雑した高速道路で、人を追加しようとしていて、本当に高速道路に乗る必要がある救急車がいて、その一方で週末のドライブを楽しんでいるポルシェに乗った別の人がいるとします。その人は待つことができるでしょう。では、どうやってそれをするのか。ここでその負荷を削減します。これが prioritized load shedding と呼ぶものです。うまくやれば、こんな感じになります。 より高い利用率に達するにつれて、段階的に右に向かって移動したいのです。まず bulk traffic から始めます。ここでは最小限の劣化と best effort があり、その後になって初めて critical traffic の削減に手をつけます。
これが、スケーリングが不足していたり、スケーリングに追いつけず、負荷を削減する必要があるときでも、最小限の影響、最小限の顧客への影響を確保する方法です。これが実際の本番環境のグラフからどのように見えるかです。 ここに3つのことがあります。非 critical な削減をもっと早く開始します。Critical な削減はもっと後まで待ちます。しかし、これらすべてにおいて、トラフィックを削減しているため、これらのエラーは増加しますが、私たちは RPS レートを正常に維持することができました。これが重要です。つまり、定義上、顧客とサービス体験への劣化は最小限で、本当に最小限だったということです。
では、これを fleet loops に戻します。これが意味するところは何か。プロアクティブなスケーリングには数ヶ月ありました。リアクティブなオートスケーリングには数分ありました。そして最後に、それでも十分でなかったとき、秒単位で動作する別のレイヤーを追加することができました。 Hammer rules は、大量の容量を素早く追加し、負荷を削減することで、fleet 全体で秒単位で動作します。 これで、純粋なコンピュート支出と容量計画に加えて、リスクを軽減するために組み合わさるテクニックの全体像が見えてきました。
まとめ：エンドツーエンドのシステム思考と数学的アプローチの重要性
では、レッスンと重要なポイントについて、私が価値があると思うことを素早くまとめてお話しします。まず第一に、このような演習を行う際には、プロアクティブなレバーとリアクティブなレバーの両方について考える必要があります。私はネットワークの背景があるので、これを pre-ingress と post-ingress という観点で考えるのが好きです。Pre-ingress というのは、トラフィックがデータセンターに入る前に実施できることで、フリートのシェーピング、予測的スケーリング、そして私が示したようなトラフィックシェーピングが含まれます。そして、既にデータセンターに追加のトラフィックを吸収した後に何が起こるかについても考慮する必要があります。これらがリアクティブなテクニックで、リアクティブスケーリングとロードシェディングです。
第二に、これは明らかなことだと思いますが、多くの場合見落とされていることがあります。それはエンドツーエンドのシステム思考が必要だということです。純粋なコンピュートと純粋な支出だけをリスク軽減の方法として見ることはできません。もう一つのポイントは、私たちのような規模で運用している場合、素晴らしいことは効率が定義上複合的に増加するということです。最後に、エンドツーエンドのトラフィック管理が必要です。最後のポイントは、私の最も好きなステートメントで、私の親友の Joey も気に入っているものです。「数学は私たちの安全毛布だ」と私は呼んでいます。経済学の基本的な概念を取り入れて、数学を適用すれば、最も難しい問題のいくつかを解くことができます。
Joey に感謝の言葉を述べたいと思います。彼は過去 1、2 年間、私の相棒でした。ぜひ、サービス容量モデリング用の Oasis ライブラリをチェックしてください。そのについてのトークもあります。ご視聴ありがとうございました。このセッションを楽しんでいただけたら幸いです。残りの時間も良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion