11.1 セッション・アフィニティについて

セッション・アフィニティを有効にすると、一意のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。

スティッキー・セッションを使用して、サービス・インスタンス、Kubernetesポッドまたはレプリカを、oracle-tmm-txn-id HTTPヘッダーに基づいてアプリケーションに関連付けます。oracle-tmm-txn-id HTTPヘッダーに基づいてコンシステント・ハッシュが作成され、スティッキー・セッションが確立されます。MicroTxライブラリおよびトランザクション・コーディネータは、後続のすべてのコールにoracle-tmm-txn-id HTTPヘッダーを含めます。

トランザクション・イニシエータ・サービスが参加側サービスをコールすると、MicroTxライブラリはoracle-tmm-txn-id HTTPヘッダーを送信リクエストに注入します。MicroTxから参加側サービスへの後続のすべてのコールにも、このヘッダーが含まれます。このようにして、すべてのリクエストはトランザクション参加側サービスの関連レプリカにルーティングされます。

ビジネス・ユース・ケースに基づいて、参加側サービスまたはトランザクション・コーディネータに対してセッション・アフィニティを有効にする必要があります。参加側サービスのレプリカが複数ある場合、リクエストは1つのトランザクションで異なるレプリカに向けられることがあります。参加側サービスのセッション・アフィニティを有効にすると、特定のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。

不要なときにセッション・アフィニティを有効にすると、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

XA参加側サービスのセッション・アフィニティを有効にする必要がある場合

すべてのリクエストが関連レプリカにルーティングされるように、参加側サービスの複数のインスタンスまたはレプリカが存在する場合にのみ、次のシナリオでXA参加側サービスのセッション・アフィニティを有効にします。次のシナリオで、XA参加側サービスのセッション・アフィニティまたはスティッキー・セッションを有効にする必要があります。

  • トランザクション参加側が非XAリソースを使用し、ロギング・ラスト・リソース(LLR)またはラスト・レコード・コミット(LRC)の最適化が有効になっている場合。
  • トランザクション参加側がリソース・マネージャとしてPostgreSQLを使用する場合、XAトランザクションの開始と後続のすべてのリクエストに同じセッションを使用する必要があります。

Saga参加側サービスのセッション・アフィニティを有効にする必要がある場合

すべてのリクエストが関連レプリカにルーティングされるように、参加側サービスの複数のインスタンスまたはレプリカが存在する場合にのみ、Saga参加側サービスのセッション・アフィニティを有効にします。

トランザクション・コーディネータのセッション・アフィニティを有効にする必要がある場合

TCCトランザクションに対してセッション・アフィニティを有効にする必要はありません。SagaおよびXAトランザクションの場合、次のシナリオで、トランザクション・コーディネータのセッション・アフィニティを有効にする必要があります:

  • 内部メモリーをデータ・ストアとして使用し、トランザクション・コーディネータを複数のレプリカにデプロイする場合。これにより、すべてのリクエストがトランザクション・コーディネータの関連レプリカにルーティングされます。
  • キャッシュを有効にする場合。

参加側サービスまたはトランザクション・コーディネータのセッション・アフィニティの有効化の詳細は、「セッション・アフィニティの有効化」を参照してください。

参加側サービスごとに、サービスのレプリカを1つ以上実行できます。参加側サービスのレプリカを追加または削除すると、特定のホストへのセッション・アフィニティは失われます。詳細は、https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLBを参照してください。