ASM イングレスゲートウェイアフィニティでスティッキーセッションを確保 - Alibaba Cloud Service Mesh

ショッピングカート、ログインセッション、パーソナライズされたダッシュボードなどのステートフルアプリケーションでは、同じクライアントからのすべてのリクエストが同じバックエンド Pod に到達する必要があります。ASM のセッション保持 (スティッキーセッション) は、Istio 宛先ルールで一貫したハッシュを適用することにより、リクエストを一貫したバックエンドにルーティングします。

一貫したハッシュは、Cookie、HTTP ヘッダー、ソース IP、またはクエリパラメーターなどのハッシュキーに基づいて、各リクエストをバックエンドにマッピングします。これにより、ソフトセッション保持が提供されます。同じクライアントからのリクエストは通常、同じ Pod に到達しますが、バックエンドが追加または削除されると、アフィニティが中断する可能性があります。

仕組み

ハッシュアルゴリズム

Envoy は 2 つの一貫したハッシュアルゴリズムをサポートしています。

アルゴリズム	デフォルト	使用場面
HashRing	はい	中程度のバックエンドの変動がある汎用セッション保持
Maglev	いいえ	ルックアップ速度が重要な高スループットシナリオ。ASM v1.16 以降が必要

前提条件

開始する前に、次のことを確認してください。

Container Service for Kubernetes (ACK) クラスターが Service Mesh (ASM) インスタンスに追加されていること。詳細については、「クラスターを ASM インスタンスに追加する」をご参照ください。
ポート 80 が公開されているイングレスゲートウェイがあること。詳細については、「イングレスゲートウェイを作成する」をご参照ください。
HTTPBin アプリケーションがデプロイされていること。詳細については、「HTTPBin アプリケーションをデプロイする」をご参照ください。

Cookie ベースのセッション保持を構成する

このチュートリアルでは、Cookie を使用したセッション保持を説明します。同じ DestinationRule 構造は、他のハッシュキーの種類にも適用できます — 対応するフィールドで httpCookie ブロックを置き換えます。

ステップ 1: HTTPBin デプロイメントを 3 つのレプリカにスケールする

リクエストが Pod 間でどのように分散されるかを観察するには、3 つのレプリカが必要です。kubectl を使用して ACK クラスターデータプレーンに接続し、以下を実行します。

kubectl scale deployment/httpbin --replicas 3

ステップ 2: セッション保持なしのリクエスト分散を検証する

ブラウザで http://<ingress-gateway-ip>/status/418 を開き、ページを数回リフレッシュします。
イングレスゲートウェイ IP の取得手順については、「Istio リソースを使用してトラフィックをサービスの異なるバージョンにルーティングする」のステップ 3 のサブステップ 1 をご参照ください。
リクエストが 3 つの Pod すべてに分散されていることを確認するために、ゲートウェイログを確認します。
1. ASM コンソールにログインします。[ASM コンソール] の左側のナビゲーションウィンドウで、[Service Mesh] > [メッシュ管理] を選択します。
2. [メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、[ASM ゲートウェイ] > [Ingress ゲートウェイ] を選択します。
3. [Ingress ゲートウェイ] ページで、対象の Ingress ゲートウェイを検索し、[ログセンター] をクリックします。[ゲートウェイログ] タブで、検索ボックスに and 418 を追加し、[検索と分析] をクリックします。左下の [生ログ] タブで、[upstream_addr] インデックスを展開します。
ログは、リクエストが 3 つの HTTPBin Pod 間でほぼ均等に分散されていることを示しています。

ステップ 3: Cookie ベースのセッション保持の宛先ルールを作成する

次の DestinationRule を適用します。宛先ルールの管理に関する詳細については、「宛先ルールを管理する」をご参照ください。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
  namespace: default
spec:
  host: httpbin.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: sticky-session-key
          ttl: 0s

フィールド	値	説明
`host`	`httpbin.default.svc.cluster.local`	このルールが適用される完全修飾サービスホスト名
`consistentHash.httpCookie.name`	`sticky-session-key`	ハッシュキーとして使用される Cookie 名
`consistentHash.httpCookie.ttl`	`0s`	Cookie の有効期間

このルールを適用した後:

最初のリクエスト (クッキーが存在しない場合) では、ゲートウェイはソースと宛先の IP アドレスおよびポートからハッシュを生成し、リクエストをバックエンドにルーティングし、応答に sticky-session-key クッキーをセットします。
後続のリクエストでは、クライアントはこの Cookie を送り返します。ゲートウェイは Cookie の値をハッシュ化してバックエンドを決定し、リクエストを同じ Pod にルーティングします。

この例では、デフォルトの HashRing アルゴリズムを使用しています。Maglev を使用するには（ASM v1.16 以降が必要）、要件に応じてトラフィックポリシーに hashAlgorithm フィールドを追加します。

ステップ 4: セッション保持が機能していることを検証する

ブラウザで http://<ingress-gateway-ip>/status/333 を開き、ページを数回リフレッシュします。
イングレスゲートウェイ IP の取得手順については、「Istio リソースを使用してトラフィックをサービスの異なるバージョンにルーティングする」のステップ 3 のサブステップ 1 をご参照ください。
すべてのリクエストが同じ Pod に到達することを確認するために、ゲートウェイログを確認します。
1. ASM コンソールにログインします。左側のナビゲーションウィンドウで、[Service Mesh] > [メッシュ管理] を選択します。
2. 「メッシュ管理」ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、「ASM ゲートウェイ」＞「Ingress ゲートウェイ」を選択します。
3. [Ingress ゲートウェイ] ページで、対象の Ingress ゲートウェイを検索し、[ログセンター] をクリックします。[ゲートウェイログ] タブで、検索ボックスに and 333 を追加し、[検索と分析] をクリックします。左下の [生ログ] タブで、[upstream_addr] インデックスを展開します。
ログは、すべてのリクエストが同じバックエンド Pod にルーティングされていることを示しています。
ブラウザで Cookie を確認します。開発者ツールを開き、[Network] タブをクリックして、ページをリフレッシュし、リクエストを確認します。応答には DestinationRule の名前と一致する sticky-session-key Cookie が含まれています。ゲートウェイはこの Cookie を使用してセッション保持を維持します。