2 計画
マイクロサービス対応トランザクション・マネージャ(MicroTx)のインストールおよび設定を計画するには、この項で説明する点を考慮してください。
- サポートされているコンテナ・プラットフォーム
- サポートされている言語およびフレームワーク
- サポートされているデータベース
- サポートされているアイデンティティ・プロバイダ
- 制限事項
- Kubernetesでのデプロイメントの考慮事項
KubernetesにMicroTxをデプロイする際は、次の要因を考慮してください。 - トランザクション・プロトコルの選択
業務要件に基づいてアプリケーションのトランザクション・プロトコルを選択します。 - トランザクション・リカバリについて
MicroTxリリース22.3.1から、トランザクション・コーディネータ・サーバーは、障害後にサーバーが再起動したときに進行中のトランザクションを再開します。 - セッション・アフィニティについて
MicroTxリリース22.3.1では、セッション・アフィニティがサポートされています。セッション・アフィニティを有効にすると、一意のトランザクションまたはセッションに対するすべてのリクエストは、最初のリクエストを処理した参加側サービスの同じエンドポイントまたはレプリカにルーティングされます。
2.1 サポートされているコンテナ・プラットフォーム
MicroTxは、DockerまたはKubernetesクラスタにデプロイできます。
MicroTxは、Kubernetes 1.21.xでテストされています。Kubernetes 1.21.xと互換性のあるKubernetesディストリビューションを使用できます。
MicroTxは、Docker 20.10.xでテストされています。Docker 20.10.xまたは互換性のあるバージョンをサポートする任意のオペレーティング・システムを使用できます。
親トピック: 計画
2.2 サポートされている言語およびフレームワーク
- TypeScriptまたはJavaScript (Node.jsの場合)
- Java 11 (Helidon、Spring Boot、WebLogic Serverなどのフレームワークで構築されたアプリケーション)
- Python 3.3以降
MicroTxでは、すべてのトランザクション・プロトコルでNode.jsおよびJavaがサポートされます。また、TCCのみでPythonがサポートされます。
サポートされるJavaフレームワーク
Javaアプリケーションは、Jerseyで実装されるREST APIを使用する必要があります。MicroTxライブラリには、Jerseyで実装されたJAX-RSと互換性のあるフィルタが用意されています。
MicroTx XAライブラリは、次のJavaフレームワークで使用できます:
- Spring Boot 2.x
- Helidon 2.x
- Oracle WebLogic Server 14
- Oracle Tuxedo 22c
- Oracle REST Data Services (ORDS) 19c
親トピック: 計画
2.3 サポートされているデータベース
MicroTxリリース22.3.1では、次のデータベースがサポートされます:
- サポートされているすべてのバージョンのOracleオンプレミス・データベース
- トランザクション処理および混合ワークロード向けのAutonomous Database - 共有および専用
- Oracle Cloud Infrastructureのベア・メタルおよび仮想マシンDBシステム
- Oracle Exadata Cloud Service
- Oracle Exadata Cloud@Customer
- etcd
オンプレミス環境でOracle Databaseに接続するか、Oracle Cloud Infrastructure Databaseサービスに接続できます。
トランザクション・イニシエータ・サービスおよびトランザクション参加側サービスが、アプリケーション・データを格納するためにデータベースを使用することもあります。アプリケーションでXAトランザクション・プロトコルを選択した場合は、MicroTxでサポートされるリソース・マネージャの詳細について「サポートされているリソース・マネージャ」を参照してください。XAトランザクションでは、MicroTxクライアント・ライブラリはリソース・マネージャのクライアント・ライブラリにアクセスする必要があります。
トランザクション・プロトコルとしてLRAまたはTCCを選択した場合は、任意のデータベースを使用してアプリケーション・データを格納できます。MicroTxは、LRAおよびTCCトランザクション・プロトコルではアプリケーション・データベースとやり取りすることはありません。
親トピック: 計画
2.4 サポートされているアイデンティティ・プロバイダ
次のアイデンティティ・プロバイダを使用して、認証情報を作成し、通信を保護できます。
- Oracle IDCS
- Oracle IAM
- Keycloak
- Microsoft Azure Active DirectoryおよびActive Directory
このガイドでは、Oracle IAMおよびOracle IDCSを使用したアクセス・トークンの作成について説明します。
KeycloakまたはMicrosoft ADをアイデンティティ・プロバイダとして使用する場合は、アイデンティティ・プロバイダの設定およびアクセス・トークンの作成の詳細について製品ドキュメントを参照してください。
親トピック: 計画
2.5 制限事項
MicroTxでは、すべてのトランザクション・プロトコルおよびトランザクション・コーディネータのすべてのレプリカで、1時間当たり4800トランザクションが許可されます。この制限を超えると、HTTP 429: Too Many requestsエラーが表示されます。期間は、MicroTxを起動した時点から考慮されます。
親トピック: 計画
2.6 Kubernetesでのデプロイメントの考慮事項
KubernetesにMicroTxをデプロイする際は、次の要因を考慮してください。
インストール・バンドルにはHelmチャートが用意されています。このドキュメントでは、Istioサービス・メッシュを使用したKubernetesクラスタでのMicroTxのサンプル・デプロイメントの詳細を示します。Kubernetesクラスタで別のサービス・メッシュを使用する場合は、独自のHelmチャートを作成します。
サポートされているKubernetesプラットフォーム
MicroTxは、データ・センターまたはクラウド環境で実行されているKubernetesクラスタにデプロイします。MicroTxは、次のプラットフォームでKubernetes 1.21.xまたは互換性のあるバージョンでテストされています:
- Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)Oracle Cloud InfrastructureドキュメントのKubernetesクラスタの作成を参照してください。
- Minikube
- Oracle Linux Container Native Environment
複数のKubernetesクラスタへのデプロイメント
アプリケーション・マイクロサービスおよびMicroTxは、単一のKubernetesクラスタ内の単一のIstioサービス・メッシュ内にデプロイできます。
アプリケーション・マイクロサービスが複数のKubernetesクラスタに分散される場合、またはMicroTxでOracle DatabaseまたはTuxedoと通信しようとする場合は、MicroTxを別のKubernetesクラスタにデプロイできます。このようなシナリオでは、各KubernetesクラスタがIstioサービス・メッシュを含みます。複数のIstioサービス・メッシュ間の通信を有効にするために、イングレス・ゲートウェイおよびエグレス・ゲートウェイを構成する必要があります。
親トピック: 計画
2.7 トランザクション・プロトコルの選択
業務要件に基づいてアプリケーションのトランザクション・プロトコルを選択します。
ビジネス・ユース・ケースが変わると必要な一貫性のレベルも変わります。たとえば、送金を行う金融アプリケーションには、厳密かつグローバルな一貫性が必要です。XAトランザクション・プロトコルはそのようなアプリケーションに適しています。XAは最適なトランザクション一貫性を提供する一方で、開発者の労力が最小限に抑えられるためです。また、通常、旅行予約ではこのレベルの一貫性は必要ないため、LRAが適しています。LRAトランザクションは、開発者にとっては複雑ですが、最大の柔軟性を提供します。
次の表に、アプリケーションのトランザクション・プロトコルの選択に役立ついくつかのパラメータを示します。
| パラメータ | XA | LRA | TCC |
|---|---|---|---|
| トランザクションの一貫性レベル | 最も厳密 | 結果 | 厳密 |
| 内容を保証しない読取り | 不可 | 可 | 不可 |
| アプリケーション開発の複雑さ | 低 | 高 | 中 |
| タイムアウトまたはエラー時の自動ロールバック | 可 | 可 | 可 |
| トランザクション・パフォーマンス | 良 | さらに良い | 最良 |
| トランザクション中のロックの保持 | 可 | 不可 | 不可 |
XA参加側は、トランザクションの間、ロックを保持します。LRAおよびTCCは、参加側のビジネス・ロジックの期間のみに対応するローカル・トランザクションを使用します。
XAトランザクションプロトコル
アプリケーションでこのプロトコルを使用するのは、プログラミング・モデルがアプリケーションに課す要件が最小限であり、アプリケーションのみがトランザクションの境界と結果を決定するときです。また、サービスがACID要件を満たす必要がある場合にもXAを使用できます。この要件では、すべての参加側が1つの一貫した状態から別の一貫した状態に移行し、完全な分離とシリアライズ可能性を備えることが必要です。
シリアライズ可能性を確保するために、リソース・マネージャは、トランザクションの処理中に、読取り、書込み、削除が行われたリソースをロックします。つまり、これらの同じリソースを使用する他のトランザクションは、それらのロックが解放されるまで待機する必要があります。このシリアライズでは、このようなロックをリクエストが待機するため、アプリケーションのパフォーマンスが大幅に制限される可能性があります。
XAで発生する可能性があるもう1つのパフォーマンスの問題は、トランザクションに追加される待機時間です。影響は、実際のビジネス・リクエストのレイテンシとXA操作のレイテンシによって異なります。たとえば、複数のマイクロサービスにまたがるビジネス・リクエストに800ミリ秒かかる場合は、XA操作によってさらに200ミリ秒が追加されても、重要性に大きな影響があるとはいえません。ただし、ビジネス・リクエストにかかるのが50ミリ秒で、XA操作のレイテンシによってさらに200ミリ秒追加される場合は、アプリケーションのパフォーマンスに大きな影響があるといえます。
LRAトランザクション・プロトコル
このプロトコルは、XAトランザクション・プロトコルの使用に適さない可能性があるアプリケーションに使用します。XAトランザクションにはリソースのロックが伴うため、XAトランザクションではマシン間の相互作用のみを行って比較的短時間で終わるようにすることをお薦めします。LRAプロトコルの方が適しているのは、ユーザーがトランザクションの意思決定プロセスに関与する場合、または数分もしくは数時間以上実行する可能性がある長いワークフローの場合です。
LRAプロトコルはリソースをロックしないため、シリアライズによるパフォーマンスの問題が発生せず、大きな利点があります。シリアライズの問題を回避できるためパフォーマンスに有利ですが、LRAによってアプリケーションに多少の負担がかかります。LRAトランザクションの中止すなわち取消しが行われるとき、アプリケーション開発者は、適切な補正アクションを実行するためにコードを用意する必要があります。預入れを引出しで補正するのは当然であるため、これは簡単に思えるかもしれません。ただし、さらに別の引出しが発生すると、補正のための引出しを行う十分な資金が存在しないことが考えられます。このケースでは、補正アクションが失敗し、トランザクションがヒューリスティックな結果になる可能性があります。その他の多くのケースで、補正アクションの実装が非常に困難または実用的でない場合があります。補正アクションを作成するのはアプリケーション開発者の責任ですが、すべての障害シナリオで補正アクションをテストするのは難しい可能性があります。
LRAとXAの両方のトランザクション・プロトコルで提供される利点を使用するために、XAトランザクションをLRAトランザクション内にネストできます。映画チケットを予約するアプリケーションについて考えてみましょう。席を予約するマイクロサービスは、LRAトランザクション・プロトコルを使用します。予約席の支払いを行うマイクロサービスは、XAトランザクションを使用します。このように、LRAとXAの両方のトランザクション・プロトコルで提供される利点を活用し、パフォーマンスを向上させることができます。
Try-Confirm/Cancel (TCC)トランザクション・プロトコル
このプロトコルは、アプリケーション・ビジネス・モデルが予約をサポートする場合に使用します。たとえば、航空券、レンタカー、ホテルを予約する旅行代理店アプリケーションなどです。
TCCトランザクション・プロトコルは、XAトランザクション・プロトコルによって提供されるのと同じグローバルな一貫性を保証しますが、TCCトランザクションプロトコルを利用できるアプリケーションのタイプに制限があります。TCCは、予約可能なアプリケーション・リソースでのみ機能します。たとえば、航空券やホテルの予約です。予約ごとに、システムが一貫した状態から別の一貫した状態に移行します。シリアライズの制約が課されないため、このプロトコルは完全にスケーラブルです。XAと同様に、開発者はTCCを簡単に利用できます。開発者は、トランザクション境界の位置を決め、トランザクションの結果を判断するだけで済むためです。トランザクション・コーディネータがワークフローを処理して、すべての参加側サービスがトランザクションを確定するか取り消すことを保証します。これにより、アプリケーション・コードの責任がさらに最小化されます。
親トピック: 計画
2.8 トランザクション・リカバリについて
MicroTxリリース22.3.1から、トランザクション・コーディネータ・サーバーは、障害後にサーバーが再起動したときに進行中のトランザクションを再開します。
トランザクション・コーディネータ・サーバーは、再起動するたびに、トランザクション・ストアに格納されている進行中のトランザクションをすべて処理し、進行中のトランザクションを再起動します。リカバリは、トランザクション・ストアで使用可能なデータによって異なります。トランザクション・ストアは、トランザクション・コーディネータがクラッシュまたは再起動した後でも、以前のトランザクションに関する情報を保持する必要があります。MicroTxがトランザクション・データを格納するようetcdまたはOracle Databaseを設定した場合は、コーディネータの再起動後、進行中のトランザクションに関する情報とトランザクションの詳細を取得できます。ただし、個別のトランザクション・ストアを設定しておらず、内部メモリーを使用してトランザクション詳細を格納している場合は、コーディネータがクラッシュまたは再起動すると、格納されているすべての情報が失われます。
MicroTxは、次の状態のトランザクションについて、トランザクション・ストアで使用可能なデータに基づいて進行中のトランザクションをリカバリします:
| トランザクション・プロトコル | トランザクション・ステータス | トランザクション・リカバリの一環としてトランザクション・コーディネータは... |
|---|---|---|
| XA | Preparing |
トランザクションをロールバックします |
| XA | Rolling back |
トランザクションをロールバックします |
| XA | Committing |
prepareおよびcommitコマンドを再送信し、トランザクションを正常にコミットするために再試行します |
| LRA | Closing |
closeコマンドを再発行してトランザクションをクローズします |
| LRA | Canceling |
cancelコマンドを再発行して、トランザクションを取り消します |
| TCC | Confirming |
confirmコマンドを再発行してトランザクションを確定します |
| TCC | Canceling |
cancelコマンドを再発行して、トランザクションを取り消します |
また、XAトランザクション・プロトコルの場合、トランザクション・コーディネータは、コミットされていないトランザクションを動的にリカバリします。「XAトランザクションの動的リカバリについて」を参照してください。
親トピック: 計画
2.9 セッション・アフィニティについて
MicroTxリリース22.3.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を参照してください。
親トピック: 計画