Envoy: サーキットブレイキング

tldr

勉強がてらにEnvoyのドキュメントを邦訳してみました。ベースはGoogle Translateで、ところどころ不自然な箇所を直しています。

原文としたのEnvoyのドキュメントはこちらのディレクトリ以下にあります（ライセンス：Apache License 2.0, NOTICE）。

サーキットブレイキング

サーキットブレイキングは分散システムの重要な構成要素です。すぐに失敗し、できるだけ早く下流にバックプレッシャーをかけるのが、ほとんどの場合より良いです。 Envoyメッシュの主な利点の1つは、Envoyが各アプリケーションを個別に設定してコーディングするのではなく、ネットワークレベルで回線遮断の制限を強制することです。 Envoyは、さまざまな種類の完全分散型（調整されていない）のサーキットブレイキングをサポートしています。

• クラスタ最大接続数：Envoyがアップストリームクラスタ内のすべてのホストに対して確立する最大接続数。 HTTP / 2は各ホストへの単一の接続を使用するため、実際にはこれはHTTP / 1.1クラスタにのみ適用可能です。このサーキットブレーカがオーバーフローすると、クラスタのupstream_cx_overflowカウンタが増加します。
• クラスター最大保留要求数：接続プール接続の待機中にキューに入れられる要求の最大数。 HTTP / 2要求は単一の接続を介して送信されるので、要求は直後に多重化されるため、このサーキットブレーカは最初の接続が作成されたときにのみ有効になります。 HTTP / 1.1の場合、リクエストをすぐにディスパッチするのに十分なアップストリーム接続が利用できないときはいつでも、リクエストは保留中のリクエストのリストに追加されるので、このサーキットブレーカはプロセスの存続期間中有効です。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_pending_overflowカウンタが増加します。
• クラスタ最大要求数：クラスタ内のすべてのホストに対して同時に未解決になる可能性がある要求の最大数。 HTTP / 1.1クラスタは最大接続数のサーキットブレーカによって管理されているため、実際にはこれはHTTP / 2クラスタに適用できます。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_pending_overflowカウンタが増加します。
• クラスタの最大アクティブ再試行回数：クラスタ内のすべてのホストに対して同時に未解決になることができる最大再試行回数。一般に、散発的な失敗に対する再試行は許可されますが、全体的な再試行回数が爆発して大規模なカスケード失敗を引き起こすことがないように、積極的に回線を切断することをお勧めします。このサーキットブレーカがオーバーフローすると、クラスタのupstream_rq_retry_overflowカウンタが増加します。
• クラスタ最大同時接続プール：同時にインスタンス化できる最大接続プール数。 Original Src Listener Filterなどの一部の機能では、無制限の数の接続プールを作成できます。クラスタがその同時接続プールを使い果たすと、アイドル状態のクラスタを取り戻そうとします。それができない場合は、サーキットブレーカがオーバーフローします。これは、接続プールがタイムアウトしないという点でクラスタ最大接続数とは異なりますが、通常、接続プールはタイムアウトします。接続は自動的にクリーンアップされます。接続プールはしません。接続プールが機能するには、少なくとも1つのアップストリーム接続が必要であるため、この値はクラスタの最大接続数以下にする必要があります。このサーキットブレーカがオーバーフローすると、クラスタのupstream_cx_pool_overflowカウンタが増加します。

各回線遮断制限は設定可能で、アップストリームクラスタごとおよび優先順位ごとに追跡されます。これにより、分散システムのさまざまなコンポーネントを個別に調整し、さまざまな制限を設けることができます。サーキットブレーカが開くまでに残っているリソースの数を含む、これらのサーキットブレーカの稼働状態は、統計によって観察できます。

サーキットブレイクによりHTTPリクエストの場合にはx-envoy-overloadのヘッダがルータフィルタによって設定されることに注意してください。