Service Mesh (ASM) では、特定のサービス間および特定のルートの East-West 呼び出しトラフィックのサーキットブレーキングルールを構成できます。このようにして、ASM プロキシは、障害が発生したアップストリームサービスからのリクエストを拒否し、非侵入型のトラフィックサーキットブレーキングを実現します。このトピックでは、ASMCircuitBreaker CustomResourceDefinitions (CRD) を使用して East-West 呼び出しトラフィックのサーキットブレーキングルールを構成する方法について説明します。
背景情報
トラフィックサーキットブレーキングは過負荷保護メカニズムであり、主に短期間のトラフィックバーストによるシステムクラッシュを防ぐために使用されます。クラウドネイティブサービス間の East-West 呼び出しの場合、1 つのサービスの障害 (低速な応答や障害率の増加など) により、トレース内の一連のサービス全体にカスケード障害が発生する可能性があります。
サービス間の East-West 呼び出しトラフィックのサーキットブレーキングルールを構成して、障害率または応答タイムアウト数が対応するしきい値に達した場合に、アップストリームサービスからのリクエストを拒否することができます。これは、アップストリームサービスを保護し、障害がトレース全体に影響を与えてシステム全体がクラッシュするのを効果的に防ぎます。
サーキットブレーキングルールを構成すると、各 ASM プロキシは、受信したリクエストに基づいて障害率または応答タイムアウト数を計算します。したがって、同じ障害が発生したアップストリームサービスの場合、異なる ASM プロキシでサーキットブレーキングが発生する時点は若干異なる場合があります。
前提条件
Enterprise Edition または Ultimate Edition の ASM インスタンスが作成されており、ASM インスタンスのバージョンが V1.14.3 以降であること。詳細については、「ASM インスタンスの作成」をご参照ください。
サンプルアプリケーション sleep と httpbin がデプロイされていること。詳細については、「データプレーン上の Container Service for Kubernetes (ACK) クラスタに HTTPBin アプリケーションをデプロイする」および「データプレーン上のクラスタに sleep サービスをデプロイする」をご参照ください。
ステップ 1:sleep サービスと httpbin サービス間の East-West トラフィックのリクエストパスルーティングを構成する
ASM コンソール にログインします。左側のナビゲーションペインで、 を選択します。
次のいずれかの方法を使用して仮想サービスを作成します。
ASM コンソールの使用
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。表示されるページで、[作成] をクリックします。
[名前空間] ドロップダウンリストから名前空間を選択し、[名前] フィールドに作成する仮想サービスの名前を入力します。[ゲートウェイ] セクションで、[すべてのサイドカーに適用] の横にあるスイッチをオンにします。
[ホスト] セクションで、[ホストの追加] をクリックして httpbin サービスを追加します。
[HTTP ルート] セクションで、[ルートの追加] をクリックし、次の図に示すようにパラメータを構成します。



YAML テンプレートの使用
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。表示されるページで、[YAML から作成] をクリックします。
次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。
次の表に、リクエストとパスの関係を示します。
リクエストパス
一致タイプ
ルート名
説明
/status/500完全一致
error-route常にステータスコード 500 が返されます。
/delayプレフィックス一致
delay-route指定された時間が経過した後、ステータスコード 200 が返されます。 /delay リクエストの使用方法の詳細については、「delay」を参照してください。
/*任意のパス
default-routeデフォルトルート。
ステップ 2:サーキットブレーキングルールを構成する
このセクションでは、エラー率と低速リクエストの数に基づいてサーキットブレーキングを構成する方法について説明します。また、テスト結果についても説明します。
エラー率に基づいてサーキットブレーキングを構成する
エラー率ベースのサーキットブレーキングとは、特定の時間枠内で検出されたサーバー応答エラー率が指定されたしきい値を超えた場合にサーキットブレーキングがトリガーされることを意味します。
ASM コンソール にログインします。左側のナビゲーションペインで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。
表示されるページで、[作成] をクリックします。 [作成] ページで、次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。
次の表に、サーキットブレーキング構成のパラメータを示します。
パラメータ
説明
workloadSelector.labels
ダウンストリームサービスワークロード。この例では、ダウンストリームサービスワークロードは sleep サービスです。したがって、
app: sleepラベルを使用して sleep サービスを選択します。break_duration
サーキットブレーキングがトリガーされてから httpbin サービスへのアクセスが復元されるまでの期間。この例では、値は 60 秒に設定されています。
window_size
リクエストエラー率が検出される時間枠。この例では、値は 10 秒に設定されています。これは、10 秒以内にルート上のリクエストのエラー率が指定されたしきい値を超えた場合、サーキットブレーキングがトリガーされ、リクエストが拒否されることを示します。
error_percent
サーキットブレーキングをトリガーするかどうかを判断するために使用される、指定された時間枠内のリクエストのエラー率。この例では、値は 60 に設定されています。これは、10 秒の時間枠内でルート上のリクエストのエラー率が 60% を超えた場合、サーキットブレーキングがトリガーされ、リクエストが拒否されることを示します。
min_request_amount
時間枠内でサーキットブレーキングをトリガーするために必要なリクエストの最小数。少数のリクエストのためにサーキットブレーキングが誤ってトリガーされるのを防ぐために、このパラメータを構成できます。
この例では、値は 5 に設定されています。これは、10 秒の時間枠内で指定されたルートに 5 つ以上のリクエストが送信され、エラー率が 60% を超えた場合にのみサーキットブレーキングがトリガーされることを示します。
custom_response
サーキットブレーキングのトリガー後に ASM プロキシがリクエストを拒否したときに返されるカスタム応答コンテンツ。
body パラメータは
error break!に設定されています。これは、カスタム応答本文がerror break!であることを示します。header_to_add パラメータは
x-envoy-overload: 'true'に設定されています。これは、サーキットブレーキングのトリガー後に拒否されたリクエストの応答ヘッダーにx-envoy-overload: 'true'が追加されることを示します。status_code パラメータは
499に設定されています。これは、サーキットブレーキングのトリガー後にリクエストに対して応答コード499が返されることを示します。
match.vhost
ルート。ルートは、仮想サービスで宣言されたルートと一致する必要があります。
name:トレース内のアップストリームサービスのドメイン名に設定する必要があります。この例では、値は httpbin サービスのドメイン名
httpbin.default.svc.cluster.localに設定されています。 httpbin サービスは sleep サービスのアップストリームサービスです。port:アップストリームサービスのサービスポートに設定する必要があります。この例では、値は httpbin サービスのサービスポート
8000に設定されています。route.name_match:仮想サービスで構成されたルート名に設定する必要があります。サーキットブレーキング構成は、対応するルートに有効になります。この例では、値は ステップ 2 で構成された
error-routeに設定されています。このルートに一致するリクエストに対しては、常にステータスコード 500 が返されます。これにより、サーキットブレーキングがトリガーされます。
kubectl を使用して ACK クラスタに接続し、次のコマンドを実行します。
for i in {1..100}; do kubectl exec -it deploy/sleep -- curl httpbin:8000/status/500 -I | grep 'HTTP'; echo ''; sleep 0.1; done;予期される出力:
出力は、6 番目のリクエストが送信されたときにサーキットブレーキングがトリガーされたことを示しています。サーキットブレーキングがトリガーされると、後続のリクエストに対してステータスコード 499 が返されます。サーキットブレーキングは 60 秒間有効です。
サーキットブレーキング中に、次のコマンドを実行して httpbin サービスの別のパスにアクセスできます。
for i in {1..100}; do kubectl exec -it deploy/sleep -- curl httpbin:8000/status/503 -I | grep 'HTTP'; echo ''; sleep 0.1; done;予期される出力:
出力は、httpbin サービスの別のパスに送信されたリクエストは、
error-routeルートのサーキットブレーキング構成の影響を受けず、httpbin サービスによって正常に応答できることを示しています。
低速リクエストの数に基づいてサーキットブレーキングを構成する
低速リクエストベースのサーキットブレーキングとは、特定の時間枠内で検出された低速リクエストの数が指定されたしきい値を超えた場合にサーキットブレーキングがトリガーされることを意味します。指定された時間枠内で応答時間がしきい値を超えるリクエストは、低速リクエストと呼ばれます。
ASM コンソール にログインします。左側のナビゲーションペインで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、 を選択します。
表示されるページで、[作成] をクリックします。 [作成] ページで、次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。
次の表に、サーキットブレーキング構成のパラメータを示します。
パラメータ
説明
workloadSelector.labels
ダウンストリームサービスワークロード。この例では、ダウンストリームサービスワークロードは sleep サービスです。したがって、
app: sleepラベルを使用して sleep サービスを選択します。break_duration
サーキットブレーキングがトリガーされてから httpbin サービスへのアクセスが復元されるまでの期間。この例では、値は 60 秒に設定されています。
window_size
リクエストエラー率が検出される時間枠。この例では、値は 10 秒に設定されています。これは、10 秒以内にルート上の低速リクエストの数が指定されたしきい値を超えた場合、サーキットブレーキングがトリガーされ、リクエストが拒否されることを示します。
slow_request_rt
低速リクエストを判断するために使用される基準応答時間。この例では、値は 0.5 秒に設定されています。これは、応答時間が 0.5 秒を超えるリクエストは低速リクエストと見なされることを示します。
max_slow_requests
サーキットブレーキングがトリガーされる前に時間枠内で許可される低速リクエストの最大数。この例では、値は 5 に設定されています。これは、10 秒の時間枠内で 5 つを超える低速リクエストが発生した場合、サーキットブレーキングがトリガーされ、リクエストが拒否されることを示します。
min_request_amount
時間枠内でサーキットブレーキングをトリガーするために必要なリクエストの最小数。少数のリクエストのためにサーキットブレーキングが誤ってトリガーされるのを防ぐために、このパラメータを構成できます。
この例では、値は 5 に設定されています。これは、10 秒の時間枠内で指定されたルートに 5 つ以上のリクエストが送信され、低速リクエストの数が 5 を超えた場合にのみサーキットブレーキングがトリガーされることを示します。
custom_response
サーキットブレーキングのトリガー後に ASM プロキシがリクエストを拒否したときに返されるカスタム応答コンテンツ。
body パラメータは
error break!に設定されています。これは、カスタム応答本文がerror break!であることを示します。header_to_add パラメータは
x-envoy-overload: 'true'に設定されています。これは、サーキットブレーキングのトリガー後に拒否されたリクエストの応答ヘッダーにx-envoy-overload: 'true'が追加されることを示します。status_code パラメータは
498に設定されています。これは、サーキットブレーキングのトリガー後にリクエストに対して応答コード498が返されることを示します。
match.vhost
ルート。ルートは、仮想サービスで宣言されたルートと一致する必要があります。
name:トレース内のアップストリームサービスのドメイン名に設定する必要があります。この例では、値は httpbin サービスのドメイン名
httpbin.default.svc.cluster.localに設定されています。 httpbin サービスは sleep サービスのアップストリームサービスです。port:アップストリームサービスのサービスポートに設定する必要があります。この例では、値は httpbin サービスのサービスポート
8000に設定されています。route.name_match:仮想サービスで構成されたルート名に設定する必要があります。サーキットブレーキング構成は、対応するルートに有効になります。この例では、値は ステップ 2 で構成された
delay-routeに設定されています。このルートに一致するリクエストは、0.5 秒を超える時間で応答するように手動で構成できます。これにより、サーキットブレーキングがトリガーされます。
kubectlを使用して ACK クラスタに接続し、次のコマンドを実行します。
for i in {1..100}; do kubectl exec -it deploy/sleep -- curl httpbin:8000/delay/1 -I | grep 'HTTP'; echo ''; sleep 0.1; done;予期される出力:
出力は、6 番目のリクエストが送信されたときにサーキットブレーキングがトリガーされたことを示しています。サーキットブレーキングがトリガーされると、後続のリクエストに対してステータスコード 498 が返されます。サーキットブレーキングは 60 秒間有効です。
サーキットブレーキング中に、次のコマンドを実行して ステップ 3 で構成されたエラー率ベースのサーキットブレーキングをテストできます。
for i in {1..100}; do kubectl exec -it deploy/sleep -- curl httpbin:8000/status/500 -I | grep 'HTTP'; echo ''; sleep 0.1; done;予期される出力:
上記の出力は、異なるルートで構成されたサーキットブレーキングルールが互いに影響を与えないことを示しています。ビジネス要件に基づいてサーキットブレーキングを実装するために、異なる特性を持つ East-West サービス呼び出しトラフィックのサーキットブレーキングルールを柔軟に構成できます。
関連操作
サービスレベルのサーキットブレーキングに関連するメトリックを表示する
V1.22.6.28 以降の ASM インスタンスでは、ASMCircuitBreaker CRD を使用して構成されたサービスレベルのサーキットブレーキングに関連するメトリックを表示できます。
メトリック | タイプ | 説明 |
envoy_asm_circuit_breaker_total_broken_requests | カウンター | サーキットブレーキングのために拒否されたリクエストの総数 |
サイドカープロキシの proxyStatsMatcher を構成して、関連するメトリックを報告できます。
proxyStatsMatcher を選択した後、[正規表現一致] を選択し、値を 正規表現の一致
.*circuit_breaker.*に設定します。詳細については、「proxyStatsMatcher」をご参照ください。新しいプロキシ構成を有効にするには、httpbin サービスを再デプロイします。詳細については、「ワークロードの再デプロイ」をご参照ください。
次のコマンドを実行して、httpbin サービスのサービスレベルのサーキットブレーキングメトリックを表示します。
kubectl exec -it deploy/httpbin -c istio-proxy -- curl localhost:15090/stats/prometheus|grep asm_circuit_breaker予期される出力:
# TYPE envoy_asm_circuit_breaker_total_broken_requests counter envoy_asm_circuit_breaker_total_broken_requests{cluster="outbound|8000||httpbin.default.svc.cluster.local",uuid="af7cf7ad-67e8-49c5-b5fe-xxxxxxxxx"} 1430 # TYPE envoy_total_asm_circuit_breakers gauge envoy_total_asm_circuit_breakers{} 1
サービスレベルのサーキットブレーキングのメトリック収集とアラートを構成する
サービスレベルのサーキットブレーキングに関連するメトリックを構成した後、メトリックを Prometheus に収集し、主要なメトリックに基づいてアラートルールを構成するように設定できます。このようにして、サーキットブレーキングが発生したときにアラートを生成できます。次のセクションでは、サービスレベルのサーキットブレーキングのメトリック収集とアラートを構成する方法を示します。この例では、Managed Service for Prometheus を使用します。
Managed Service for Prometheus では、データプレーン上のクラスタを [alibaba Cloud ASM] コンポーネントに接続するか、Alibaba Cloud ASM コンポーネントを最新バージョンにアップグレードできます。これにより、公開されたサーキットブレーキングに関連するメトリックを Managed Service for Prometheus で収集できます。コンポーネントを ARMS に統合する方法の詳細については、「コンポーネント管理」をご参照ください。(自己管理型 Prometheus インスタンスを使用して ASM インスタンスを監視する を参照して、自己管理型 Prometheus インスタンスを使用して ASM インスタンスのメトリックを収集するように設定を構成している場合は、この手順を実行する必要はありません。)
サービスレベルのサーキットブレーキングのアラートルールを作成します。詳細については、「カスタム PromQL ステートメントを使用してアラートルールを作成する」をご参照ください。次の例は、アラートルールを構成するための主要なパラメータを指定する方法を示しています。その他のパラメータの構成方法の詳細については、上記のドキュメントを参照してください。
パラメータ
例
説明
カスタム PromQL ステートメント
(sum by(cluster, namespace) (increase(envoy_asm_circuit_breaker_total_broken_requests[1m]))) > 0
increase ステートメントは、過去 1 分間にサーキットブレーキングのために拒否されたリクエストの数をクエリします。リクエストの数は、サーキットブレーキングをトリガーしたサービスの名前空間と名前でグループ化されます。 1 分以内にサーキットブレーキングのために拒否されたリクエストの数が 0 より大きい場合、アラートが報告されます。
アラートメッセージ
サービスレベルのサーキットブレーキングが発生しました。名前空間: {{$labels.namespace}}、サーキットブレーキングをトリガーしたサービス: {{$labels.cluster}}。現在の 1 分以内にサーキットブレーキングのために拒否されたリクエストの数: {{ $value }}
アラート情報には、サーキットブレーキングをトリガーしたサービスの名前空間、サービス名、およびサービスに送信されたが過去 1 分間にサーキットブレーキングのために拒否されたリクエストの数が表示されます。