フォールバックメカニズムは、サービスコールが失敗した場合の代替呼び出しパスを提供します。マイクロサービスが失敗した場合、または使用できない場合、フォールバックメカニズムは代替サービスを呼び出してリクエストを処理し、システム全体の安定性と可用性を確保します。たとえば、サービスエンドポイントが使用できない場合、フォールバックメカニズムを使用してリクエストを代替サービスに転送し、クライアントリクエストがエラーや中断なしに処理されるようにすることができます。 サービスメッシュ (ASM) では、仮想サービスでフォールバックパラメータを定義して、リクエストされたサービスが失敗した場合にフォールバックを実行できるようにすることができます。このトピックでは、ASM フォールバックメカニズムの使用方法について説明します。
前提条件
Enterprise Edition または Ultimate Edition の ASM インスタンスが作成されており、そのバージョンが 1.17.2.22 以降であること。詳細については、「ASM インスタンスの作成」をご参照ください。
説明ASM インスタンスのバージョンが 1.17 より前の場合、ASM インスタンスを 1.17.2.22 以降に更新するか、チケットを送信してテクニカルサポートを受けてください。 ASM インスタンスの更新方法の詳細については、「ASM インスタンスの更新」をご参照ください。
コンテナサービス Kubernetes 版 (ACK) クラスタが ASM インスタンスに追加されていること。詳細については、「ASM インスタンスへのクラスタの追加」をご参照ください。
Bookinfo という名前のサンプルアプリケーションがデプロイされていること。詳細については、「ASM インスタンスへのアプリケーションのデプロイ」をご参照ください。
データプレーン上のサイドカープロキシのバージョンが 1.17 以降であること。
構成の説明
この例では、Bookinfo アプリケーションの reviews サービスを使用します。 productpage サービスが v1、v2、v3 の 3 つのバージョンを持つ reviews サービスにアクセスする場合、v3 が使用できない場合は、フォールバックが実行されて v2 の reviews サービスにアクセスし、HTTP 503 ステータスコードは返されません。
[構成ファイル] をクリックして、この例で使用されている YAML ファイルをダウンロードできます。
手順 1：Bookinfo アプリケーションへのアクセス
次の内容を含む reviews.yaml ファイルを作成して、reviews サービスの v1、v2、v3 バージョンを宣言します。
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: v3KubeConfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行してデスティネーションルールをデプロイします。
kubectl apply -f reviews.yaml次のいずれかの方法を使用して、イングレスゲートウェイの IP アドレスを取得します。
方法 1：次のコマンドを実行して、イングレスゲートウェイの IP アドレスを取得します。
kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'方法 2：ASM コンソールの [イングレスゲートウェイ] ページからイングレスゲートウェイの IP アドレスを取得します。詳細については、「ASM インスタンスのイングレスゲートウェイの IP アドレスのクエリ」をご参照ください。
ブラウザで
http://${YourGatewayIp}/productpageにアクセスします。${YourGatewayIp}は、前の手順で取得したイングレスゲートウェイの IP アドレスです。 [Reviews served by] の値、または星の表示に基づいて、reviews サービスのバージョンを判断できます。 v1 バージョンには星がなく、v2 バージョンには黒い星があり、v3 バージョンには赤い星があります。たとえば、次の図では、値 reviews-v2 は黒い星が付いた v2 バージョンを示しています。
ページを更新し続けます。 サービスリクエストは、reviews サービスの v1、v2、v3 バージョンにバランスされていることがわかります。
手順 2：reviews サービスにアクセスするためのルーティングルールとフォールバックルールを定義する
次の内容を含む reviews-route-fallback-sample1.yaml ファイルを作成します。
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: v2KubeConfig ファイルの情報に基づいて kubectl を使用して ASM インスタンスに接続し、次のコマンドを実行して reviews サービスにアクセスするためのルーティングルールとフォールバックルールをデプロイします。
kubectl apply -f reviews-route-fallback-sample1.yamlブラウザで
http://${YourGatewayIp}/productpageにアクセスし、ページを更新し続けます。サービスリクエストは常に reviews サービスの v3 バージョンにルーティングされていることがわかります。
reviews-v3 インスタンスの数を 0 に変更することにより、reviews-v3 での障害をシミュレートするには、次のコマンドを実行します。
kubectl scale deployment reviews-v3 --replicas=0ブラウザで
http://${YourGatewayIp}/productpageにアクセスし、ページを更新し続けます。サービスリクエストが reviews サービスの v2 バージョンにフォールバックしていることがわかります。 カスタムアクセスログ形式にフォールバック関連のフィールドを追加してからログを表示して、フォールバックが実行されたかどうかを確認できます。
次のフィールドをカスタムアクセスログ形式に追加します。 詳細については、「手順 2：アクセスログのフィールドをカスタマイズする」をご参照ください。
フィールド
値
説明
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)%
フォールバックが正常に実行された場合のフォールバック先クラスタの名前。 たとえば、service1|v1 が存在しない場合、リクエストは service|base にフォールバックします。
fallback_result
%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%
フォールバック結果。 フォールバックが失敗した場合、フォールバック結果は元のルートのクラスタに送信されます。
produpage-v1 istio-proxy のログを表示します。
リクエストが reviews-v3 から reviews-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":"-" }ログには、次の新しいフィールドが表示されます。
"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"ログは、元のルート先は v3 であることを示しています。 v3 のインスタンスが使用できないため、リクエストはフォールバックルールに基づいて reviews-v2 にフォールバックします。
手順 3：重み付けルートでのフォールバックルールを構成する
次のコマンドを実行して、reviews-v3 を使用可能に設定します。
kubectl scale deployment reviews-v3 --replicas=1次の内容を含む reviews-route-fallback-sample2.yaml ファイルを作成して、reviews-route の定義を変更します。
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次のコマンドを実行して、reviews サービスの新しいルーティングルールとフォールバックルールをデプロイします。
kubectl apply -f reviews-route-fallback-sample1.yamlブラウザで
http://${YourGatewayIp}/productpageにアクセスし、ページを更新し続けます。リクエストが 50:50 の比率で reviews-v2 と reviews-v3 にルーティングされていることがわかります。 結果を簡単に観察できるように、この例では再試行は無効になっています。
次のコマンドを実行して reviews-v3 インスタンスの数を 0 に変更し、reviews-v3 のフォールバックルールが期待どおりかどうかを確認します。
kubectl scale deployment reviews-v3 --replicas=0ページを更新し続けます。 リクエストは常に reviews-v2 にルーティングされていることがわかります。これは期待どおりです。
次のコマンドを実行して reviews-v2 インスタンスの数を 0 に変更します。
kubectl scale deployment reviews-v2 --replicas=0ページを更新し続けます。 次のページのようなページが表示されます。これは、productpage サービスが reviews サービスにアクセスできないことを示しています。 このページが表示される確率は 50% で、残りの 50% の確率でリクエストは reviews-v2 にルーティングされます。 reviews-v2 は正常でないため、リクエストは実際には reviews-v1 にフォールバックします。
次のコマンドを実行してログをクエリします。
kubectl logs -f deployment/productpage-v1 -c istio-proxy --tail=10期待される出力：
{ "authority":"reviews:9080", "authority_for":"reviews:9080", "bytes_received":"0", "bytes_sent":"19", "downstream_local_address":"192.168.255.46:9080", "downstream_remote_address":"172.16.0.252:47738", "duration":"0", "fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local", "fallback_final_cluster_name":"-", "fallback_result":"fallback cluster is unhealthy", "istio_policy_status":"-", "method":"GET", "path":"/reviews/0", "protocol":"HTTP/1.1", "request_id":"b207a764-b6d7-4ef8-bc71-59f264c3****", "requested_server_name":"-", "response_code":"503", "response_flags":"UH", "route_name":"-", "start_time":"2023-05-30T07:32:08.999Z", "trace_id":"a40c32a7b2cf****", "upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local", "upstream_host":"-", "upstream_local_address":"-", "upstream_service_time":"-", "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":"-" }productpage-v1 に上記の HTTP 503 ステータスコードに類似したログが存在することがわかります。 reviews-route の重み付けルーティング構成に基づいて、productpage サービスは 50% の確率で reviews-v3 をリクエストします。 reviews-v3 は使用できないため、サイドカープロキシ (istio-proxy) はフォールバックルールに基づいて reviews-v3 から reviews-v2 へのフォールバックを試みます。 reviews-v2 が正常でないため、リクエストは reviews-v3 に送信されます。 フィールド
"upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local"に基づいてフォールバックを確認できます。