Alibaba Cloud Service Mesh:ASM でのフォールバックルーティングの設定

フォールバックとリトライ、サーキットブレーカーの違い

ASM は、いくつかの回復性メカニズムを提供します。対応する必要がある障害モードに基づいて、適切なものを選択してください。

フォールバックはルーティングレベルで動作します。サイドカープロキシは、リクエストを転送する前に、ターゲットサブセットに正常なエンドポイントがあるかどうかを確認します。正常なエンドポイントが存在しない場合、代わりにフォールバックターゲットにルーティングします。

前提条件

Bookinfo の reviews サービスのバージョン

Bookinfo の reviews サービスには 3 つのバージョンがあり、それぞれ製品ページの星評価で識別できます。

productpage サービスは reviews を呼び出します。VirtualService はすべてのトラフィックを reviews-v3 にルーティングします。v3 が利用できなくなった場合、フォールバックルールは 503 エラーを返す代わりに、リクエストを reviews-v2 にリダイレクトします。

このトピックで使用される構成ファイルをダウンロード

ステップ 1：reviews サービスの宛先ルールの作成

reviews サービスの各バージョンに対応するサブセットを持つ DestinationRule を定義します。

1. reviews.yaml という名前のファイルを作成し、次の内容を記述します。

      apiVersion: networking.istio.io/v1alpha3
      kind: DestinationRule
      metadata:
        name: reviews
      spec:
        host: reviews
        subsets:
        - name: v1
          labels:
            version: v1
        - name: v2
          labels:
            version: v2
        - name: v3
          labels:
            version: v3

2. kubectl と KubeConfig ファイルを使用して ASM インスタンスに接続し、ルールを適用します。

      kubectl apply -f reviews.yaml

3. いずれかの方法でイングレスゲートウェイの IP アドレスを取得します。

   • 次のコマンドを実行します。

     kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

   • ASM コンソールの [イングレスゲートウェイ] ページで IP を確認します。詳細は、ASM インスタンスのイングレスゲートウェイの IP アドレスの照会をご参照ください。

4. ブラウザで http://<gateway-ip>/productpage を開きます。Reviews served by フィールドと星評価によって、各リクエストを処理しているバージョンがわかります。ページを数回リフレッシュすると、リクエストは v1、v2、v3 に分散されます。例えば、reviews-v2 は黒い星を表示します。

   

ステップ 2：基本的なフォールバックルールの設定

すべてのトラフィックを reviews-v3 にルーティングし、reviews-v2 をフォールバックターゲットとして設定します。

1. reviews-route-fallback-sample1.yaml という名前のファイルを作成します。fallback.target フィールドは、reviews-v3 が到達不能な場合にリクエストを reviews-v2 に転送するようサイドカープロキシに指示します。

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2

2. VirtualService を適用します。

      kubectl apply -f reviews-route-fallback-sample1.yaml

3. http://<gateway-ip>/productpage を開いてリフレッシュします。すべてのリクエストが v3 (赤い星) にルーティングされるようになります。

   

4. v3 のデプロイメントを 0 レプリカにスケーリングして、v3 の障害をシミュレートします。

      kubectl scale deployment reviews-v3 --replicas=0

5. ページをリフレッシュします。リクエストは v2 (黒い星) にフォールバックされるようになります。

アクセスログによるフォールバックの検証

フォールバック関連のフィールドをカスタムアクセスログのフォーマットに追加して、フォールバックがトリガーされたことを確認します。設定手順については、アクセスログフィールドのカスタマイズをご参照ください。

フィールド	値	説明
fallback_path	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-path)%	フォールバックチェーン。A:B は A が B にフォールバックしたことを意味します。A:B:C は A が B に、その後 B が C にフォールバックしたことを意味します。
fallback_final_cluster_name	%DYNAMIC_METADATA(com.aliyun.fallback:final-cluster)%	フォールバックが成功した後に最終的にリクエストを処理したクラスター。
fallback_result	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%	フォールバックの結果。フォールバックが失敗した場合、リクエストは元のルートのクラスターに送られます。

productpage-v1 の istio-proxy ログを確認します。v3 から v2 へのフォールバックが成功すると、次のようなログエントリが生成されます。

{
    "authority": "reviews:9080",
    "authority_for": "reviews:9080",
    "bytes_received": "0",
    "bytes_sent": "442",
    "downstream_local_address": "192.168.255.46:9080",
    "downstream_remote_address": "172.16.0.252:57238",
    "duration": "10",
    "fallback_path": "outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_result": "fallback successful",
    "istio_policy_status": "-",
    "method": "GET",
    "path": "/reviews/0",
    "protocol": "HTTP/1.1",
    "request_id": "15b2dffc-5f3f-4060-b9fa-898eab08****",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "-",
    "start_time": "2023-05-30T07:02:26.990Z",
    "trace_id": "18b3aed8af41****",
    "upstream_cluster": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "upstream_host": "172.16.0.11:9080",
    "upstream_local_address": "172.16.0.252:44448",
    "upstream_service_time": "9",
    "upstream_transport_failure_reason": "-",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for": "-"
}

3 つのフォールバック固有のフィールドがこの動作を裏付けます。

• fallback_path は、v3 クラスターから v2 クラスターへのチェーンを示します。

• fallback_final_cluster_name は、リクエストを処理したクラスターが v2 であることを示します。

• fallback_result は "fallback successful" です。

ステップ 3：フォールバックと加重ルーティングの組み合わせ

フォールバックルールは加重ルーティングと連携して機能します。このシナリオでは、トラフィックは v3 と v2 の間で 50/50 に分割され、各バージョンには独自のフォールバックターゲットがあります。

1. v3 を復元します。

      kubectl scale deployment reviews-v3 --replicas=1

2. reviews-route-fallback-sample2.yaml という名前のファイルを作成します。2 つの独立したフォールバックチェーンが定義されています。テスト中にフォールバックの動作をリトライの動作から分離するため、リトライは無効 (attempts: 0) になっています。

   • v3 トラフィック (50%)：v3 が利用できない場合、v2 にフォールバックします

   • v2 トラフィック (50%)：v2 が利用できない場合、v1 にフォールバックします

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2
                weight: 50
              - destination:
                  host: reviews
                  subset: v2
                fallback:
                  target:
                    host: reviews
                    subset: v1
                weight: 50
            retries:
              attempts: 0

3. 更新された VirtualService を適用します。

      kubectl apply -f reviews-route-fallback-sample2.yaml

4. 製品ページをリフレッシュします。リクエストは v3 (赤い星) と v2 (黒い星) の間で均等に分散されます。

本番環境でのフォールバックの使用

フォールバックルーティングはサービスの障害をマスクするため、可用性にとっては価値がありますが、本番環境では慎重な計画が必要です。

関連トピック

• ASM インスタンスの作成

• データプレーン上のクラスターのアクセスログのカスタマイズ

• ASM インスタンスの更新