10.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から参加側サービスへの後続のすべてのコールにも、このヘッダーが含まれます。このようにして、すべてのリクエストはトランザクション参加側サービスの単一のレプリカにルーティングされます。

ビジネス・ユース・ケースに基づいて、参加側サービスまたはトランザクション・コーディネータに対してセッション・アフィニティを有効にする必要があります。不要なときにセッション・アフィニティを有効にすると、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

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

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

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

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

内部メモリーをデータ・ストアとして使用し、トランザクション・コーディネータを複数のレプリカにデプロイする場合は、LRAおよびXAトランザクションのトランザクション・コーディネータに対してセッション・アフィニティを有効にする必要があります。これにより、すべてのリクエストがトランザクション・コーディネータの単一のレプリカにルーティングされます。TCCトランザクションに対してセッション・アフィニティを有効にする必要はありません。

トランザクション・コーディネータおよび参加側サービスのセッション・アフィニティを有効化するプロセスは似ています。トランザクション・コーディネータのセッション・アフィニティを有効にするには、トランザクション・コーディネータのYAMLファイルを更新します。

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

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

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