すべてのプロダクト
Search
ドキュメントセンター

Alibaba Cloud Service Mesh:サービス間の呼び出しトラフィックのサーキットブレーキングルールを ASMCircuitBreaker を使用して構成する

最終更新日:Jan 13, 2025

Service Mesh (ASM) では、特定のサービス間および特定のルートの East-West 呼び出しトラフィックのサーキットブレーキングルールを構成できます。このようにして、ASM プロキシは、障害が発生したアップストリームサービスからのリクエストを拒否し、非侵入型のトラフィックサーキットブレーキングを実現します。このトピックでは、ASMCircuitBreaker CustomResourceDefinitions (CRD) を使用して East-West 呼び出しトラフィックのサーキットブレーキングルールを構成する方法について説明します。

背景情報

トラフィックサーキットブレーキングは過負荷保護メカニズムであり、主に短期間のトラフィックバーストによるシステムクラッシュを防ぐために使用されます。クラウドネイティブサービス間の East-West 呼び出しの場合、1 つのサービスの障害 (低速な応答や障害率の増加など) により、トレース内の一連のサービス全体にカスケード障害が発生する可能性があります。

サービス間の East-West 呼び出しトラフィックのサーキットブレーキングルールを構成して、障害率または応答タイムアウト数が対応するしきい値に達した場合に、アップストリームサービスからのリクエストを拒否することができます。これは、アップストリームサービスを保護し、障害がトレース全体に影響を与えてシステム全体がクラッシュするのを効果的に防ぎます。

サーキットブレーキングルールを構成すると、各 ASM プロキシは、受信したリクエストに基づいて障害率または応答タイムアウト数を計算します。したがって、同じ障害が発生したアップストリームサービスの場合、異なる ASM プロキシでサーキットブレーキングが発生する時点は若干異なる場合があります。

前提条件

ステップ 1:sleep サービスと httpbin サービス間の East-West トラフィックのリクエストパスルーティングを構成する

  1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

  2. 次のいずれかの方法を使用して仮想サービスを作成します。

    ASM コンソールの使用

    1. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[トラフィック管理センター] > [virtualservice] を選択します。表示されるページで、[作成] をクリックします。

    2. [名前空間] ドロップダウンリストから名前空間を選択し、[名前] フィールドに作成する仮想サービスの名前を入力します。[ゲートウェイ] セクションで、[すべてのサイドカーに適用] の横にあるスイッチをオンにします。

    3. [ホスト] セクションで、[ホストの追加] をクリックして httpbin サービスを追加します。

    4. [HTTP ルート] セクションで、[ルートの追加] をクリックし、次の図に示すようにパラメータを構成します。

    image

    image

    image

    YAML テンプレートの使用

    1. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[トラフィック管理センター] > [virtualservice] を選択します。表示されるページで、[YAML から作成] をクリックします。

    2. 次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。

      YAML コンテンツを表示

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: httpbin
        namespace: default
      spec:
        hosts:
          - httpbin.default.svc.cluster.local
        http:
          - match:
              - uri:
                  exact: /status/500
            name: error-route  // エーラールート
            route:
              - destination:
                  host: httpbin.default.svc.cluster.local
          - match:
              - uri:
                  prefix: /delay
            name: delay-route // 遅延ルート
            route:
              - destination:
                  host: httpbin.default.svc.cluster.local
          - name: default-route // デフォルトルート
            route:
              - destination:
                  host: httpbin.default.svc.cluster.local

    次の表に、リクエストとパスの関係を示します。

    リクエストパス

    一致タイプ

    ルート名

    説明

    /status/500

    完全一致

    error-route

    常にステータスコード 500 が返されます。

    /delay

    プレフィックス一致

    delay-route

    指定された時間が経過した後、ステータスコード 200 が返されます。 /delay リクエストの使用方法の詳細については、「delay」を参照してください。

    /*

    任意のパス

    default-route

    デフォルトルート。

ステップ 2:サーキットブレーキングルールを構成する

このセクションでは、エラー率と低速リクエストの数に基づいてサーキットブレーキングを構成する方法について説明します。また、テスト結果についても説明します。

エラー率に基づいてサーキットブレーキングを構成する

エラー率ベースのサーキットブレーキングとは、特定の時間枠内で検出されたサーバー応答エラー率が指定されたしきい値を超えた場合にサーキットブレーキングがトリガーされることを意味します。

  1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

  2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[トラフィック管理センター] > [サーキットブレーキングとデグレード] を選択します。

  3. 表示されるページで、[作成] をクリックします。 [作成] ページで、次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。

    YAML コンテンツを表示

    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ASMCircuitBreaker
    metadata:
      name: httpbin-error-circuitbreak
      namespace: default
    spec:
      configs:
        - breaker_config:
            break_duration: 60s
            custom_response:
              body: error break!
              header_to_add:
                x-envoy-overload: 'true'
              status_code: 499
            error_percent:  // エラー率
              value: 60
            min_request_amount: 5  // 最小リクエスト数
            window_size: 10s  // 時間枠
          match:
            vhost:
              name: httpbin.default.svc.cluster.local
              port: 8000
              route:  // ルート
                name_match: error-route
      workloadSelector:  // ダウンストリームサービスワークロード
        labels:
          app: sleep
    

    次の表に、サーキットブレーキング構成のパラメータを示します。

    パラメータ

    説明

    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 が返されます。これにより、サーキットブレーキングがトリガーされます。

  4. 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;

    予期される出力:

    詳細を表示

    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 499 Unknown  // ステータスコード 499 が返される
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    ...

    出力は、6 番目のリクエストが送信されたときにサーキットブレーキングがトリガーされたことを示しています。サーキットブレーキングがトリガーされると、後続のリクエストに対してステータスコード 499 が返されます。サーキットブレーキングは 60 秒間有効です。

  5. サーキットブレーキング中に、次のコマンドを実行して 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;

    予期される出力:

    詳細を表示

    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable  // 影響を受けない
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    HTTP/1.1 503 Service Unavailable
    
    ...
    

    出力は、httpbin サービスの別のパスに送信されたリクエストは、error-route ルートのサーキットブレーキング構成の影響を受けず、httpbin サービスによって正常に応答できることを示しています。

低速リクエストの数に基づいてサーキットブレーキングを構成する

低速リクエストベースのサーキットブレーキングとは、特定の時間枠内で検出された低速リクエストの数が指定されたしきい値を超えた場合にサーキットブレーキングがトリガーされることを意味します。指定された時間枠内で応答時間がしきい値を超えるリクエストは、低速リクエストと呼ばれます。

  1. ASM コンソール にログインします。左側のナビゲーションペインで、[service Mesh] > [メッシュ管理] を選択します。

  2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションペインで、[トラフィック管理センター] > [サーキットブレーキングとデグレード] を選択します。

  3. 表示されるページで、[作成] をクリックします。 [作成] ページで、次のコードブロックに示されているコンテンツを [YAML] コードエディタにコピーし、[作成] をクリックします。

    YAML コンテンツを表示

    apiVersion: istio.alibabacloud.com/v1beta1
    kind: ASMCircuitBreaker
    metadata:
      name: httpbin-slow-circuitbreak // 低速リクエストのサーキットブレーカー
      namespace: default
    spec:
      configs:
        - breaker_config:
            break_duration: 60s
            custom_response:
              body: error break!
              header_to_add:
                x-envoy-overload: 'true'
              status_code: 498 // ステータスコード 498 を返す
            max_slow_requests: 5 // 最大低速リクエスト数
            min_request_amount: 5
            slow_request_rt: 0.5s // 低速リクエストの基準応答時間
            window_size: 10s
          match:
            vhost:
              name: httpbin.default.svc.cluster.local
              port: 8000
              route:
                name_match: delay-route // delay-route に適用
      workloadSelector:
        labels:
          app: sleep
    

    次の表に、サーキットブレーキング構成のパラメータを示します。

    パラメータ

    説明

    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 秒を超える時間で応答するように手動で構成できます。これにより、サーキットブレーキングがトリガーされます。

  4. 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; 

    予期される出力:

    詳細を表示

    HTTP/1.1 200 OK
    
    HTTP/1.1 200 OK
    
    HTTP/1.1 200 OK
    
    HTTP/1.1 200 OK
    
    HTTP/1.1 200 OK
    
    HTTP/1.1 498 Unknown // ステータスコード 498 が返される
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    HTTP/1.1 498 Unknown
    
    ...

    出力は、6 番目のリクエストが送信されたときにサーキットブレーキングがトリガーされたことを示しています。サーキットブレーキングがトリガーされると、後続のリクエストに対してステータスコード 498 が返されます。サーキットブレーキングは 60 秒間有効です。

  5. サーキットブレーキング中に、次のコマンドを実行して ステップ 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;

    予期される出力:

    詳細を表示

    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 500 Internal Server Error
    
    HTTP/1.1 499 Unknown // ステータスコード 499 が返される
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    HTTP/1.1 499 Unknown
    
    ...

    上記の出力は、異なるルートで構成されたサーキットブレーキングルールが互いに影響を与えないことを示しています。ビジネス要件に基づいてサーキットブレーキングを実装するために、異なる特性を持つ East-West サービス呼び出しトラフィックのサーキットブレーキングルールを柔軟に構成できます。

関連操作

サービスレベルのサーキットブレーキングに関連するメトリックを表示する

V1.22.6.28 以降の ASM インスタンスでは、ASMCircuitBreaker CRD を使用して構成されたサービスレベルのサーキットブレーキングに関連するメトリックを表示できます。

メトリック

タイプ

説明

envoy_asm_circuit_breaker_total_broken_requests

カウンター

サーキットブレーキングのために拒否されたリクエストの総数

サイドカープロキシの proxyStatsMatcher を構成して、関連するメトリックを報告できます。

  1. proxyStatsMatcher を選択した後、[正規表現一致] を選択し、値を 正規表現の一致.*circuit_breaker.* に設定します。詳細については、「proxyStatsMatcher」をご参照ください。

  2. 新しいプロキシ構成を有効にするには、httpbin サービスを再デプロイします。詳細については、「ワークロードの再デプロイ」をご参照ください。

  3. ステップ 1ステップ 2 を再度実行して、サーキットブレーキングを再構成します。

  4. 次のコマンドを実行して、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 を使用します。

  1. Managed Service for Prometheus では、データプレーン上のクラスタを [alibaba Cloud ASM] コンポーネントに接続するか、Alibaba Cloud ASM コンポーネントを最新バージョンにアップグレードできます。これにより、公開されたサーキットブレーキングに関連するメトリックを Managed Service for Prometheus で収集できます。コンポーネントを ARMS に統合する方法の詳細については、「コンポーネント管理」をご参照ください。(自己管理型 Prometheus インスタンスを使用して ASM インスタンスを監視する を参照して、自己管理型 Prometheus インスタンスを使用して ASM インスタンスのメトリックを収集するように設定を構成している場合は、この手順を実行する必要はありません。)

  2. サービスレベルのサーキットブレーキングのアラートルールを作成します。詳細については、「カスタム 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 分間にサーキットブレーキングのために拒否されたリクエストの数が表示されます。