マイクロサービスベースのアプリケーションの設計
マイクロサービス・アーキテクチャを使用してアプリケーションを設計する場合は、マイクロサービスのベスト・プラクティスおよびマイクロサービスの開発における成功の12パターンに準拠することを検討してください。これらのパターンには、12要素アプリケーションの考慮事項が組み込まれており、コンバージド・データベースとともにマイクロサービス・デプロイメントの経験から構築されます。
マイクロサービスを設計するためのベスト・プラクティスの学習
マイクロサービスの設計時に特定のベスト・プラクティスに従うことで、アプリケーションの拡張、デプロイ、保守が容易になります。ここで説明するすべてのベスト・プラクティスがアプリケーションに関連しているとはかぎりません。
各マイクロサービスは、アプリケーションの機能の1つの部分を実装する必要があります。開発チームは、各マイクロサービスの制限と責任を定義する必要があります。1つのアプローチは、アプリケーションで頻繁にリクエストされるタスクごとにマイクロサービスを定義することです。別の方法として、機能をビジネス・タスクで分割し、各領域のマイクロサービスを定義する方法があります。
設計では、次の要件について検討します。
- レスポンシブ・マイクロサービス: マイクロサービスは、サービスに障害が発生した場合でも、リクエスト元のクライアントにレスポンスを返す必要があります。
- 下位互換性: マイクロサービスの機能を追加または更新するときに、APIメソッドおよびパラメータの変更がクライアントに影響を与えないようにする必要があります。REST APIは下位互換性を維持する必要があります。
- 柔軟な通信: 各マイクロサービスは、クライアントとAPIゲートウェイ間の通信およびマイクロサービス間の通信に使用するプロトコルを指定できます。
- べき等性: クライアントがマイクロサービスを複数回コールする場合、同じ結果が生成されます。
- 効率的な操作: 設計により、監視とトラブルシューティングが容易になる必要があります。この要件の実装には、通常、ログ・システムが使用されます。
マイクロサービスで成功するための12のパターンを理解する
マイクロサービスの実装は困難であり、これらの12パターンにより、コンバージド・データベース・プラットフォームとコンテナおよびKubernetesを使用して、サービス・アーキテクチャの俊敏性とシンプルさの利点をより簡単に活用できます。
- バインドされたコンテキスト: 事前に設計するか、データ・リファクタリング・アドバイザを使用してモノリスをマイクロサービスに分解します。
- 疎結合: スキーマをマイクロサービスに分離し、信頼できるイベント・メッシュを使用してデータを分離します。
- マイクロサービス向けのCI/CD: マルチテナント・データベースにより、マイクロサービスに適しています。個別にデプロイおよび構築するプラガブル・データベース(PDB)を追加します。アプリケーション(Jenkinsを使用)およびスキーマ(データベース内のLiquibase、FlywayおよびEBR)も適切な選択です。
- マイクロサービスのセキュリティ: 各エンドポイントをAPIゲートウェイ、ロード・バランサ、イベント・メッシュ、データベースに保護します。
- マイクロサービスの統一された可観測性: チューニングと自己修復のために、メトリック、ログおよびトレースを単一のダッシュボードにまとめます。
- トランザクション送信ボックス: 単一のローカル・トランザクションでのメッセージおよびデータ操作操作の送信。
- 信頼できるイベント・メッシュ: 高スループットのトランザクション・メッセージングとpubおよびsubを持つすべてのイベントのイベント・メッシュ。イベント変換およびイベント・ルーティングがあります。
- イベント集計: イベントは一時的なもので、リアルタイム・アクションを通知またはトリガーします。その後、イベントがデータベースに集計されます。データベースは、究極のコンパクト・トピックです。
- コマンド・クエリー責任分離(CQRS): マイクロサービスで使用可能なデータの操作コピーと分析コピー。
- Sagas: データベースでのイベント・メッシュとエスクロー・ジャーナリングのサポートにより、マイクロサービス間のトランザクション。
- ポリグロット・プログラミング: JSONをペイロードとして使用して、様々な言語でのマイクロサービスおよびメッセージ形式をサポートします。
- Back-end as a Service (BaaS): クラウドまたはオンプレミス・デプロイメント上のテスト、開発および本番デプロイメント(小から中)に適したサイズのマイクロサービス・インフラストラクチャ(Spring Boot Apps用)。
バインドされたコンテキスト・パターンで開始
マイクロサービスの永続性を実装するための推奨パターンは、コンテナ・データベースで単一のプラガブル・データベース(PDB)を使用することです。マイクロサービスごとに、永続データをプライベートに保ち、マイクロサービス実装の一部としてプラガブル・データベースを作成します。
このパターンでは、プライベート永続データはマイクロサービスAPIを介してのみアクセスできます。
次の図は、マイクロサービスの永続性設計を示しています。
図microservices_persistence.pngの説明
- プライベート表: 各サービスは、表またはドキュメントのセットを所有します。
- スキーマ: 各サービスはプライベート・データベース・スキーマまたはコレクションを所有します。
- データベース: 図に示すように、各サービスはコンテナ・データベース内のプラガブル・データベースを所有します。
マイクロサービスの永続的なアンチパターンは、複数のマイクロサービス間で1つのデータベース・スキーマを共有することです。データの一貫性を保つために、アトミックで一貫性のある、分離された、耐久性のあるトランザクションを実装できます。このアンチパターンの利点は、単純なデータベースを使用することです。デメリットは、マイクロサービスがデータベースへのアクセス中に相互に干渉し、異なるマイクロサービスの開発者がスキーマの変更を調整する必要があるため、開発サイクルが遅くなる可能性があることです。これにより、サービス間の依存関係も増加します。
マイクロサービスは、Oracle Cloud Infrastructureで実行されているOracle Databaseインスタンスに接続できます。Oracleマルチテナント・データベースは、コンテナ内の複数のプラガブル・データベース(PDB)をサポートしています。これは、マイクロサービスの永続性レイヤー、データ、セキュリティの境界コンテキスト分離、および高可用性を実現するための最適な選択肢です。多くの場合、スキーマ・レベルの分離で使用できるPDBは少なくなります。
コンテナにマイクロサービスをデプロイする価値の理解
マイクロサービスを構築したら、それをコンテナ化する必要があります。独自のコンテナで実行されているマイクロサービスは、他のコンテナにデプロイされているマイクロサービスには影響しません。
コンテナは、アプリケーションの開発、出荷およびデプロイに使用される標準化されたソフトウェア・ユニットです。
コンテナは、Dockerなどのコンテナ・エンジンを使用して管理されます。コンテナ・エンジンは、すべてのアプリケーションの依存関係をコンテナとしてバンドルするために必要なツールを提供します。
Dockerエンジンを使用して、マイクロサービス・アプリケーションをコンテナで作成、デプロイおよび実行できます。Dockerコンテナで実行されるマイクロサービスには、次の特徴があります。
- 標準: マイクロサービスは移植可能です。彼らはどこでも走ることができる。
- 軽量: Dockerはオペレーティング・システム(OS)カーネルを共有し、インスタンスごとにOSを必要とせず、軽量プロセスとして実行されます。
- セキュア: 各コンテナは分離されたプロセスとして実行されます。マイクロサービスは安全です。
マイクロサービスをコンテナ化するプロセスには、Dockerfileの作成、その依存関係と環境構成を含むコンテナ・イメージの作成と構築、Dockerエンジンへのイメージのデプロイ、および格納と取得のためのコンテナ・レジストリへのイメージのアップロードが含まれます。
図docker_container_process.pngの説明
Kubernetesを使用したマイクロサービスのオーケストレーションについて学ぶ
コンテナで実行されているマイクロサービスは、必要なアプリケーション機能を提供するために相互作用および統合できる必要があります。この統合は、コンテナ・オーケストレーションによって実現できます。
コンテナ・オーケストレーションにより、クラスタ内のコンテナを起動、停止およびグループ化できます。また、高可用性とスケーリングも可能です。Kubernetesは、コンテナの管理に使用できるコンテナ・オーケストレーション・プラットフォームの1つです。
マイクロサービスをコンテナ化した後、それらをOracle Cloud Infrastructure Container Engine for Kubernetesにデプロイできます。
コンテナ化されたマイクロサービス・アプリケーションをクラウドにデプロイする前に、次のようにローカルKubernetesエンジンでデプロイおよびテストする必要があります:
- マイクロサービス・アプリケーションを作成します。
- Dockerイメージを構築して、マイクロサービスをコンテナ化します。
- マイクロサービスをローカルのDockerエンジンで実行します。
- コンテナ・イメージをコンテナ・レジストリにプッシュします。
- マイクロサービスをMinikubeなどのローカルのKubernetesエンジンにデプロイして実行します。
ローカルKubernetesエンジンでアプリケーションをテストした後、次のようにOracle Cloud Infrastructure Container Engine for Kubernetesにデプロイします:
- クラスタの作成
kubeconfigファイルをダウンロードします。- ローカル・デバイスに
kubectlツールをインストールします。 deployment.yamlファイルを準備します。- マイクロサービスをクラスタにデプロイします。
- マイクロサービスをテストします。
次の図は、コンテナ化されたマイクロサービス・アプリケーションをOracle Cloud Infrastructure Container Engine for Kubernetesにデプロイするプロセスを示しています。
図oke_deployment_process.pngの説明
Oracle Backend for Spring Boot and Microservicesについて学習
Spring Bootは、Javaでマイクロサービスを構築するための最も人気のあるフレームワークです。正常にデプロイされるマイクロサービス・アーキテクチャで成功するための12のパターンの1つは、Backend as a Service (BaaS)パターンです。Oracle BaaSは、OCI Marketplaceで利用でき、TerraformおよびAnsibleを使用して30分以内にデプロイできます。Oracle BaaSは、マイクロサービスのデプロイおよび操作に必要なプラットフォーム・サービスのセットを提供し、Spring Boot環境に不可欠です。Oracle Backend for Spring Boot and Microservicesプラットフォームの詳細は、次の図を参照してください。
