Oracle Banking MicroservicesおよびOCI Kubernetes Engineのデプロイについて
Oracle Cloud Infrastructure Kubernetes EngineとOracle Banking Microservicesを使用して、銀行インフラを最新化する方法をご紹介します。OCI Kubernetes Engine (OKE)は、完全に管理されたスケーラブルで可用性の高いサービスであり、コンテナ化されたアプリケーションをクラウドにデプロイするために使用されます。開発チームがクラウドネイティブ・アプリケーションを確実に構築、デプロイおよび管理する場合、OKEを使用します。アプリケーションで必要なコンピュート・リソースを指定すると、OKEは既存のOCIテナンシでOCIにプロビジョニングします。
アーキテクチャ
このアーキテクチャでは、Oracle Banking MicroservicesとOCI Kubernetes Engineを実装してマイクロサービスを効率的に活用する方法について説明します。
Oracle Banking Microservices Architecture
Oracleは、小売およびコーポレート・バンキングを網羅する業界で最も広範なドメイン主導のバンキング・ソリューション・セットを提供し、顧客のデジタル・エクスペリエンス・レイヤーからバンキング製品プロセッサまたはコア・バンキング・ドメインまで、フロント・ツー・バックを実現します。
これらの機能はすべて、ドメイン主導の設計を使用して設計され、最先端のマイクロサービス・アーキテクチャを使用して実装された一連の自律型モジュールとして提供されます。すべてのモジュールは、一連のビジネス・ドメイン固有のマイクロサービス、すべてのモジュールにわたる共通の機能基盤マイクロサービス(共通コア)のセット、および必要な技術機能を提供するプラットフォーム・サービスで構成されます。
次の図は、ブランチ・モジュール内の様々なレベルのマイクロサービスを示しています。
このアーキテクチャは、最大限のデプロイメントの柔軟性を提供します。すべてのマイクロサービスはdockerイメージでコンテナ化でき、個別にデプロイできます。このオプションを使用すると、デプロイメントを完全に制御できるため、特定の顧客の要件に基づいて特定のマイクロサービスを更新またはスケール・アップできます。
一部のお客様は、プラットフォーム管理にそのレベルの粒度を必要とせず、マイクロサービスを少数のdockerイメージにグループ化して、簡素化されたアプローチを好む場合があります。このアプローチにより、個別のレベルで更新およびスケーリングの柔軟性が低下しますが、スケーラビリティ、高可用性などに関する標準要件を顧客に備えた必要なレベルの制御が引き続き提供されます。このシナリオでは、マイクロサービスの意味と特定の性質を考慮して、マイクロサービスをグループ化することが重要です。このリファレンス・アーキテクチャでは、次の要素を考慮したグループ化を提案します。
- ワークロードのタイプ: RESTベース、バッチベース、イベントベース、ワークフローベース。
- 重要なコンポーネント: 一部のコンポーネントはプラットフォームにとって重要です。他のワークロードよりも高いワークロードがあります。
次の図は、提案されたグループ化を示しています。
図obma-service-landscape-branch-module-proposed.pngの説明
次に、これらのグループの説明を示します。
- ドメインSD: モジュールのビジネス・ドメイン・マイクロサービス(この場合はブランチ・モジュール)が含まれます。
- CMC SD: コア基盤または機能基盤の共通マイクロサービス。
- Plato SD: 個別にデプロイされていない技術プラットフォームのマイクロサービスが含まれています。
- Kafka: マイクロサービスと外部システム間の通信にプラットフォームEvent Hubで使用されます。
- コンダクタ: マイクロサービスのオーケストレーションおよびヒューマン・ワークフローの作成に使用されるプラットフォームのワークフロー・エンジン。
- バッチ・サーバー: ビジネス・ドメインに必要なバッチ・プロセスを実行します。
このソリューションは、7つのdockerイメージをグループ化します。
OKEを使用したデプロイメント・アーキテクチャ
OCI Kubernetes EngineはKubernetesを使用します。これは、ホストのクラスタ間でコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化するためのオープンソース・システムです。Kubernetesでは、アプリケーションを構成するコンテナが論理ユニット(ポッドと呼ばれる)にグループ化されるため、管理と検出が簡単になります。
Kubernetesでコンテナを実行するには、ポッドで囲む必要があります。ポッドは、Kubernetesの最小原子単位であり、同じネットワーク、ストレージ、メモリーおよびIPCネームスペースを共有するコンテナのグループを実行する構成です。ポッドにはメイン・コンテナが1つあり、後続のコンテナはメイン・コンテナをサポートします。たとえば、アプリケーション・ログをロギング・サーバーに送信するサポート・コンテナがあるアプリケーション・コンテナなどです。このアーキテクチャでは、マルチコンテナ・ポッドのユースケースの詳細はわかりませんが、ほとんどの場合、ポッド当たりコンテナは1つのみです。
Oracle Bankingソリューションのデプロイには、独自のポッドにデプロイしている7つのコンテナ・イメージのそれぞれを同封します。これを行うには、コンテナ・イメージごとにKubernetesポッド・マニフェスト・ファイルを定義します。
ポッドはKubernetesに直接デプロイできますが、Kubernetesデプロイメントでポッドをデプロイする方がより堅牢です。Kubernetesデプロイメントでは、特定のポッドのコピー数やレプリカ数など、ポッドの希望する状態または動作を定義できます。Kubernetesデプロイメントでは、既存のポッドを新しいアプリケーション・バージョンにアップグレードすることもできます。ポッドの指定された状態を維持するのはKubernetesのみです。
Oracleバンキング・ソリューションには、合計7つのデプロイメントを用意します。デプロイメント内の各ポッドにはIPアドレスが割り当てられますが、ポッドのIPアドレスはエフェメラルであり、ポッドが作成および破棄されると変更されます。デプロイメント内のポッドに一貫した方法でアクセスできるように、デプロイメントごとにKubernetesサービスが作成されます。Kubernetesサービスは、ポッドのセットを定義する抽象化です。Kubernetesサービスがデプロイメントに関連付けられている場合、デプロイメント内のすべてのポッドを表し、各ポッドにトラフィックをロード・バランシングします。ポッドへのアクセス方法に応じて、Kubernetesクラスタ内の他のリソース、OCI VCN内の他のリソース、またはインターネット経由の外部リソースによってのみアクセスされるかどうかに応じて、様々なタイプのKubernetesサービスがデプロイメントに割り当てられます。
自己回復性を実現するために、OKEノード・プールはリージョン内の3つの可用性ゾーンすべてにまたがります。可用性ゾーンに障害が発生した場合、障害が発生した可用性ゾーンのノードにデプロイされているすべてのポッドは、別の可用性ゾーンのノードで自動的に再作成されます。
マイクロサービスのデータを格納するOracleデータベースでは、それぞれに個別のスキーマを使用して、2つのフォルト・ドメインでOracle Real Application Clusters (Oracle RAC)構成を使用します。
次のダイアグラムにこのアーキテクチャを示します。
マイクロサービスのデータを格納するOracleデータベースでは、それぞれに個別のスキーマを使用して、2つの可用性ドメインでRAC構成を使用します(図に示されていない2つのフォルト・ドメインを使用します)。データは、2番目の可用性ドメインでOracle Data Guardを使用してレプリケートされます。
このアーキテクチャには、次のコンポーネントがあります。
- リージョン
Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。
- 可用性ドメイン
可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、ある可用性ドメインでの障害は、リージョン内の他の可用性ドメインには影響しません。
- フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあり、電源とハードウェアは独立しています。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションは、物理サーバーの障害、システム・メンテナンスおよびフォルト・ドメイン内の電源障害を許容できます。
- 仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用するとネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- 要塞ホスト
要塞ホストは、クラウド外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは、通常非武装ゾーン(DMZ)でプロビジョニングされます。機密リソースは、クラウドの外部から直接アクセスできないプライベート・ネットワークに配置することで保護できます。トポロジには、定期的にモニターおよび監査できる単一の既知のエントリ・ポイントがあります。そのため、トポロジへのアクセスを損なうことなく、より機密性の高いコンポーネントの公開を回避できます。
- DBシステム
小規模なデプロイメントでは、VM.Standard2.2シェイプで十分です。このアーキテクチャでは、Oracle Real Application Clusters (RAC)を使用して、Oracle Database Enterprise Edition - Extreme Performanceを備えたDBシステムを使用します。また、256 GB以上のOracle Automatic Storage Management (Oracle ASM)も使用します。
- ブロック・ボリューム
ブロック・ストレージ・ボリュームを使用すると、ストレージ・ボリュームを作成、アタッチ、接続および移動し、ボリューム・パフォーマンスを変更して、ストレージ、パフォーマンスおよびアプリケーションの要件を満たすことができます。ボリュームをインスタンスにアタッチおよび接続した後は、そのボリュームを通常のハード・ドライブのように使用できます。また、データを失うことなく、ボリュームを切断して別のインスタンスにアタッチすることもできます。
- オブジェクト・ストレージ
オブジェクト・ストレージでは、データベースのバックアップ、分析データ、イメージやビデオなどのリッチ・コンテンツなど、任意のコンテンツ・タイプの構造化データおよび非構造化データにすばやくアクセスできます。インターネットから直接またはクラウド・プラットフォーム内から、安全かつセキュアにデータを格納し、取得できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージを拡張できます。迅速、即時、頻繁にアクセスする必要があるホット・ストレージには、標準ストレージを使用します。長期間保持し、ほとんどまたはほとんどアクセスしないコールド・ストレージには、アーカイブ・ストレージを使用します。
- ネットワーク・アドレス変換(NAT)ゲートウェイ
NATゲートウェイを使用すると、VCN内のプライベート・リソースは、受信インターネット接続にこれらのリソースを公開することなく、インターネット上のホストにアクセスできます。
- サービス・ゲートウェイ
サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.