トラフィックシェーピングがKubernetesスケーリング戦略に欠けている理由
Author: Thomas Mathew (opens in a new tab) Date: March 12, 2026
2019年、Netflixはメンバーがコンテンツを再生できなくなる障害を経験しました。動画再生、UIアニメーション、分析、A/Bテストのロギングなど、あらゆるリクエストが過負荷状態の同じインフラを奪い合いました。解決策はより多くの容量ではありませんでした。それは優先度ベースの負荷シェディングでした。低優先度のトラフィック（ロギング、分析、UI拡張）を自動的に廃棄しながら、コア体験である動画再生を維持するシステムでした。展開から数日後、同様のインシデントが発生しました。しかし今回、メンバーは気づきませんでした。 (opens in a new tab)
Netflixだけではありません。Google、Uber、LinkedIn、Shopify、Agodaもすべて本番環境で優先度ベースのトラフィックシェーピングを運用しています。これは大規模での標準的な信頼性パターンとなっています。しかしKubernetesエコシステムでは、ほとんどのチームがまだこれを持っていません。
オートスケーラーは容量を処理します。トラフィックシェーピングは優先度を処理します。 両方なければ、不可能な選択を迫られます。安全のために過剰プロビジョニング（リソースの30〜50%を無駄に）するか、スパイク時のパフォーマンス低下を受け入れるかです。
実証済みのパターン：業界のリーダーたちの方法
優先度ベースの負荷シェディングは新しいアイデアではありません。毎秒数百万件のリクエストを処理する企業が使用する実証済みの信頼性パターンです。彼らの共通点は：すべてのトラフィックが同等に作られているわけではなく、過負荷時に同等に扱うことが誤ったデフォルトだということです。
Netflix：段階的な優先度スコアリング
Netflixはすべてのリクエストに0（最高）から100（最低）の優先度スコア (opens in a new tab)を割り当てます。システム負荷が増加するにつれ、シェディングは最も低い優先度のトラフィックから上向きに段階的に拡大します。35%過負荷時には、95点以上のリクエストのみが廃棄されます。80%過負荷時には、閾値は約50に下がります。動画再生リクエストは0に近く、絶対に廃棄されません。このアプローチはゲートウェイレベル（Zuul）からサービスレベルへと進化し、各サービスが自身の優先度決定を制御できるようになりました。
Google：リクエストの重要度伝播
GoogleのSREプラクティスはすべてのリクエストに「重要なユーザー向け」から「非重要なバックグラウンド」までの重要度レベル (opens in a new tab)を付与します。重要度はRPCシステムを通じて自動的に伝播されます。リクエストAがサービスBとCを呼び出すと、両方がAの優先度を継承します。サービスが過負荷になると、最も低い重要度から先にシェディング (opens in a new tab)します。Googleはまた負荷下でのグレースフルデグラデーションを採用しており、検索が完全なインデックスを照会する代わりにキャッシュされた結果を返すことで、完全に失敗するのではなく品質を下げてユーザー体験を維持します。
Uber：動的負荷シェディング（Cinnamon）
UberはQALM（QoS-Aware Load Management） (opens in a new tab)を構築しました。リクエストを階層にランク付けし、P99レイテンシーメトリクスを使用して同時実行制限を動的に調整するフレームワークです。CinnamonロードシェダーがアクティブになるとP99、レイテンシー敏感な操作が影響を受ける前に低優先度のトラフィックが廃棄されます。過負荷時の結果：スループット約80%増加、重要な操作のP99レイテンシー約70%低下。
LinkedIn：Hodor - 3つのトラフィック層
LinkedInのHodorシステム (opens in a new tab)はすべてのトラフィックを3つの層に分類します：低下不可能（メンバー向けリクエストは絶対に廃棄不可）、低下可能（品質を下げて提供可能）、オプション（オフライン/ニアラインシステムはユーザーへの影響なしに廃棄可能）。過負荷検出器は各プロセス内で実行され、すべての受信リクエストをこれらの層に対してクエリします。
共通パターン
実装方法は異なりますが、すべての企業が同じ原則に収束しています：
- ビジネス優先度によってリクエストを分類する：すべてのトラフィックが同等に重要なわけではない
- 最も低い優先度から段階的にシェディングする：あらゆるコストを払っても重要なパスを保護する
- リアルタイムシグナルを使用する：同時実行数、レイテンシー、エラーレート、リソース圧迫
- 応答を自動化する：トラフィックスパイク時には人間の対応が遅すぎる
パターンは実証済みです。課題は導入です。 これらの企業は数年間のエンジニアリングを必要とするカスタムシステムを構築しました。ほとんどのKubernetesチームは、Netflix式のロードシェダーをゼロから構築するリソースを持っていません。
Kubernetesにおけるギャップ
業界のコンセンサスにもかかわらず、ほとんどのKubernetesクラスターは優先度ベースのトラフィックシェーピングなしで運用されています。チームはこの問題のために設計されていないツールに依存しています：
レート制限はビジネスコンテキストを無視します。 リクエストが何であるかに関係なく、毎秒のリクエスト数を上限で制限します。レートリミッターは決済の送信とプリフェッチ呼び出しを同等に扱います。これはまさにNetflix、Google、Uberが優先度認識を追加することで解決した問題です。
サーキットブレーカーは二進法的です。 サービスが不健全なときにトリップし、すべてのトラフィックを遮断します。段階的な応答はありません。サーキットブレーカーは「分析トラフィックは廃棄するがチェックアウトは流し続ける」と言うことができません。これはまさにLinkedInのHodorが3層モデルで行っていることです。
EnvoyFilter YAMLは静的で手動です。 IstioのEnvoyFilterはカスタムトラフィックルールを記述できますが、リアルタイムのワークロード圧迫への認識がない静的な設定です。UberのCinnamonはライブP99レイテンシーを使用して閾値を動的に調整します。静的なYAMLではそれはできません。
| アプローチ | 優先度認識 | 動的 | ビジネスコンテキスト |
|---|---|---|---|
| レート制限 | なし | なし（静的制限） | なし |
| サーキットブレーカー | なし（二進on/off） | リアクティブのみ | なし |
| EnvoyFilter YAML | 手動（ルールごと） | なし（静的YAML） | 手動 |
| Netflix（カスタム） | あり（0-100スコアリング） | あり（段階的） | 完全 |
| Google（カスタム） | あり（重要度レベル） | あり（伝播） | 完全 |
| Wave Flow | あり（4層優先度） | あり（リソース認識） | 完全 |
ギャップは知識ではなく実装にあります。Netflix式のロードシェダーを構築するには深いインフラエンジニアリングが必要です。Wave Flowはこの実証済みパターンを展開可能なソリューションとしてあらゆるKubernetesクラスターにもたらします。
Wave Flow：実証済みのパターン、Kubernetesにすぐ適用可能
Wave FlowはNetflix、Google、Uberが使用する同じ優先度ベースの負荷シェディングパターンを実装しますが、既存のサービスメッシュプロキシ（Istio、Envoy、Kong、NGINX）に直接統合される展開可能なWebAssembly（WASM）モジュールとして提供されます。カスタムインフラ不要。意思決定オーバーヘッド約0.1ms。
大規模で実証された階層型アプローチをモデルにした4つの優先度層にすべての受信リクエストを分類します：
| 優先度 | 動作 | シェディング閾値 | トラフィック例 |
|---|---|---|---|
| CRITICAL | 絶対にシェディングしない | — | 決済、認証、注文送信 |
| IMPORTANT | 極度の負荷時のみシェディング | 95%+使用率 | プレミアムユーザーダッシュボード、重要な読み取り |
| MODERATE | 予防的にシェディング | 80%+使用率 | 商品閲覧、検索、無料ユーザー |
| BULK | 積極的にシェディング | 60%+使用率 | レコメンデーション、分析、プリフェッチ |
リクエストはHTTPヘッダー、URLパスプレフィックス、HTTPメソッドによって分類されます。これはGoogleが使用する同じ分類次元（ホスト名、URLパス、ユーザーID）です。マッチしないトラフィックはデフォルトでBULKになり、重要なトランザクションが常に最初に保護されます。
実際の動作
フラッシュセール中のeコマースプラットフォームを考えてみましょう。Shopifyが広範に書いているシナリオ (opens in a new tab)で、トラフィックが通常の100倍にスパイクする可能性があります：
/checkout/*および/payment/*パス → CRITICAL（絶対にシェディングしない）/cart/*およびX-User-Tier: premiumヘッダー → IMPORTANT（95%以上でのみシェディング）/products/*および/search→ MODERATE（80%以上でシェディング）/recommendations、/analytics→ BULK（60%以上でシェディング）
CPU使用率が65%に達すると、Wave Flowはレコメンデーションと分析の呼び出しのシェディングを開始します。Netflixがロギングとゴー/B テストトラフィックを最初にシェディングする方法と同様です。圧力が85%に上がると、商品閲覧もスロットリングされますが、決済は全容量で流れ続けます。オートスケーラーの新しいポッドが準備完了になるまでの間、移行期間を通じて重要な収益が保護されます。
UberのCinnamonのようなワークロード認識: Wave Flowのスロットリングは静的な閾値ではなく、実際のCPUとメモリの圧迫からトリガーされます。P99レイテンシーを使用して制限を調整するUberの動的アプローチと同様に、Wave Flowの優先度決定は実際のインフラ状態に合わせ、条件の変化に適応します。
3つの展開モード
Wave Flowは既存のインフラと統合されます。サービスメッシュの置き換え不要：
- イングレスゲートウェイモード：クラスターに入るすべてのトラフィックを保護します。Istio Ingress Gateway、Kong、NGINX、Envoy Gateway、APISIXで動作します。
- サイドカーモード：きめ細かい制御のためのサービスごとのトラフィックシェーピング。Netflixがゲートウェイレベルからサービスレベルの負荷シェディングへ進化したのと同様です。
- アンビエントメッシュモード：Istioアンビエントメッシュ（1.18+）を使用したサイドカーなしの展開。サービスごとの制御と共有プロキシ効率性を組み合わせます。
マルチクラスター対応: Wave Autoscaleは単一コンソールからのマルチクラスター管理をサポートします。トラフィック優先度層を一度定義し、開発、ステージング、本番クラスター全体に一貫して適用します。クラスターごとの設定ドリフトなし。
チームにとっての意味
プラットフォームエンジニアリングチームへ
Netflix、Google、LinkedInはすべて内部プラットフォームにカスタム負荷シェディングを組み込みました。Wave Flowはカスタムエンジニアリングなしにプラットフォームに同じ機能を提供します。 プラットフォーム契約の一部となります。すべての開発チームが使用する標準化された4層トラフィック優先度モデル。一度定義し、どこにでも展開します。
SRE / 信頼性チームへ
深夜3時、ページが鳴ります。Wave Flowがすでに実行中であれば、使用率が上がるにつれてBULKとMODERATEのトラフィックが自動的にスロットリングされます。NetflixのZuulゲートウェイが2020年のインシデント中に低優先度のトラフィックを自動的にシェディングしたのと同じ方法です。あなたの役割は「プレッシャー下で緊急レート制限を適用する」から「自動化が機能しているか確認する」に変わります。グレースフルデグラデーションが連鎖的な障害を置き換えます。
エンジニアリングリーダーシップへ
eコマースのダウンタイムコストが平均分あたり$14,056 (opens in a new tab)、大企業では平均分あたり$23,750に達する状況で、トラフィックスパイク時に収益重要なトランザクションを保護することは直接的な財務的影響をもたらします。Wave Flowは、トラフィックが容量を超える瞬間に、収益を生み出すリクエストが通過できるようにします。
| 影響エリア | トラフィックシェーピングなし | Wave Flow使用時 |
|---|---|---|
| ピークイベント障害 | 重要と非重要が等しく失敗 | 重要なトラフィックを保護し、バルクトラフィックを先にシェディング |
| インシデント対応 | プレッシャー下での手動レート制限 | 自動優先度ベースシェディング |
| 過剰プロビジョニング | 「万が一のため」に30〜50%の過剰容量 | 削減されたランタイム保護が過剰容量を置き換え |
| スパイク時の収益 | 保護なし | 収益重要なトランザクションを優先 |
始め方
Wave FlowはWASMモジュールとして既存のIstioまたはEnvoyインフラに展開されます。サービスメッシュの置き換えなし、追加サイドカーなし、カスタムコードなし。
実践的なロールアウトパス：
- 分類: 重要なサービスを特定し、優先度層を割り当てます。NetflixとLinkedInが優先度スコアリングシステムを定義したときと同じ作業です。
- 展開: 1つのクラスターにWave Flowポリシーを適用します。通常トラフィック下で1〜2週間シェーピング動作を監視します。
- 拡張: 一貫した優先度ポリシーで残りのクラスターにロールアウトします。
優先度ベースの負荷シェディングはNetflix、Google、Uber、LinkedIn、Shopifyで実証済みのパターンです。違いは、それらの企業がカスタムシステムの構築に数年を費やしたということです。Wave Flowは同じパターンを展開可能で設定可能なソリューションとしてKubernetesクラスターにもたらします。
オートスケーリングは容量を処理します。トラフィックシェーピングは優先度を処理します。共に、どちらか一方だけでは解決できないギャップを埋めます。
KubernetesトラフィックマネジメントをNext Levelへ
KubernetesスタックにPriority-Basedのトラフィックインテリジェンスを追加する準備ができていますか？
詳細はこちら：
Wave AutoscaleはCNCFシルバーメンバーおよびAWS EKS Service Ready Partnerである STCLabによって開発されています。