マイクロサービス

マイクロサービス・アーキテクチャは、次のような理由から、モノリシック・アーキテクチャよりも優れたアプローチとみなされることがよくあります。

• スケーラビリティ:マイクロサービスは個別にスケーリングできるため、アプリケーション全体をスケーリングするのではなく、必要に応じてアプリケーションの特定の部分をスケーリングできます。
• 回復力:マイクロサービスは独立してデプロイできるため、1つ以上のサービスに障害が発生しても引き続き機能できるため、アプリケーション全体の回復力が向上します。
• 柔軟性:マイクロサービスは、さまざまなテクノロジーを使用して開発および導入できるため、サービスごとに最適なツールを選択できます。
• 市場投入までの時間の短縮:マイクロサービスにより、小規模で迅速な開発サイクルが可能になり、新しい機能や機能をより迅速に市場に投入できます。
• メンテナンス性の向上:マイクロサービスは小さく、明確に定義された単一の責任を持つため、メンテナンスが容易になり、変更が行われた場合の破損が少なくなります。
• テスト安定性の向上:マイクロサービスは個別にテストできるため、アプリケーション全体に影響を与える前にバグの捕捉と修正が容易になります。

マイクロサービス・アーキテクチャは問題の迅速な解決ではなく、複雑さの増大、ネットワーク・レイテンシ、サービス間通信の必要性など、新しい課題をもたらす可能性があることに注意してください。マイクロサービス・アーキテクチャを採用する前に、徹底的な評価を行います。

コンテナは、分離された環境でアプリケーションとその依存関係をパッケージ化および実行するための軽量で移植可能な方法を提供することで、マイクロサービス・アーキテクチャをサポートします。マイクロサービス用のコンテナを使用する主なメリットは次のとおりです。

• 分離:各マイクロサービスは独自のコンテナで実行でき、サービスごとに分離された環境を提供します。これにより、個々のサービスを個別にデプロイ、管理およびスケーリングすることが容易になります。
• 移植性:コンテナは、開発、テスト、本番などのさまざまな環境で一貫して実行できるため、マイクロサービスの導入と管理が容易になります。
• リソースの効率性:コンテナは軽量であり、従来の仮想化テクノロジよりも消費するリソースが少ないため、単一のホスト・システムでより多くのサービスを実行できます。
• スケーラビリティ: Kubernetesなどのコンテナ・オーケストレーション・プラットフォームにより、コンテナのデプロイメントとスケーリングが可能になり、必要に応じてサービスのインスタンスを簡単に追加または削除できます。
• 柔軟性:コンテナを使用すると、マイクロサービスを異なる言語で開発およびデプロイできるため、サービスごとに最適なツールを使用できます。
• 継続的な導入:コンテナを使用すると、マイクロサービスの導入と管理を自動化しやすくなり、より迅速かつ頻繁なリリースが可能になります。

コンテナは、分離された環境でマイクロサービスをパッケージ化および実行する方法を提供し、柔軟で効率的な方法でマイクロサービスのデプロイ、管理およびスケーリングを容易にします。

マイクロサービス・アーキテクチャは、ネットワークを介して相互に通信する小規模で独立したサービスの集合としてアプリケーションを構築するソフトウェア設計パターンです。各マイクロサービスは、明確に定義された特定の責任を持ち、他のマイクロサービスとは無関係に開発、導入、保守できます。これにより、組織はアプリケーションをより迅速に構築および更新でき、柔軟性が向上し、リスクが軽減されます。

マイクロサービス・アーキテクチャでは、サービスはAPIを介して通信し、通常はデプロイメント用のコンテナにパッケージ化されます。これにより、サービスを個別にデプロイおよびスケーリングできるため、スケーラビリティと自己回復性が向上します。アプリケーション全体は、小さく再利用可能なコンポーネントから構築でき、これらを組み合せて、より大規模で複雑なアプリケーションを形成できます。

マイクロサービス・アーキテクチャは、クラウド・コンピューティング環境で使用されることが多く、高いレベルのスケーラビリティ、アジリティおよび自己回復性を必要とするアプリケーションに適しています。

マイクロサービスを設計する際のベストプラクティスに従うことで、アプリケーションの拡張、導入、保守が容易になるようにすることができます。前述のすべてのベスト・プラクティスは、アプリケーションに関連しない場合があります。

各マイクロサービスは、アプリケーションの機能の1つの部分を実装する必要があります。開発チームは、各マイクロサービスの制限と責任を定義する必要があります。1つのアプローチは、アプリケーションで頻繁にリクエストされるタスクごとにマイクロサービスを定義することです。別の方法として、機能をビジネス・タスクで分割し、領域ごとにマイクロサービスを定義する方法があります。

設計では、次の要件について検討します。

• 応答マイクロサービス:サービスが失敗した場合でも、マイクロサービスはリクエスト元のクライアントに応答を返す必要があります。
• 下位互換性:マイクロサービスの機能を追加または更新するときに、APIメソッドおよびパラメータの変更がクライアントに影響しないようにする必要があります。REST APIは下位互換性を維持する必要があります。
• 柔軟な通信:各マイクロサービスは、クライアントとAPIゲートウェイ間の通信、およびマイクロサービス間の通信に使用するプロトコルを指定できます。
• 冪等性:クライアントがマイクロサービスを複数回コールした場合、同じ結果が生成されます。
• 効率的な操作:設計により、監視とトラブルシューティングが容易になる必要があります。ログ・システムは、この要件を実装するために一般的に使用されます。

デプロイ前にマイクロサービスをパッケージ化するには、通常、アプリケーション・コード、ライブラリおよび依存関係を含むコンテナ・イメージを作成します。次のステップでは、マイクロサービスをコンテナ・イメージにパッケージ化する方法について説明します。

1. アプリケーションを定義します。まず、マイクロサービスに必要なアプリケーション・コード、ライブラリおよび依存関係を定義します。この情報は、コンテナ・イメージの作成に使用されます。
2. Dockerfileを記述します。Dockerfileは、コンテナ・イメージを構築するための指示を含むスクリプトです。使用するベース・イメージ、含めるアプリケーション・コードと依存関係、構成またはランタイム要件を指定します。
3. イメージの構築: Docker CLIまたはCI/CDツールを使用して、Dockerfileに基づいてイメージを構築します。これにより、マイクロサービスの実行に使用できるコンテナ・イメージが作成されます。
4. イメージを保存します。イメージをDocker Hubなどのコンテナ・レジストリに格納します。このレジストリでは、他のユーザーが簡単にアクセスして再利用できます。
5. イメージをテストします。イメージをテストして、正しく動作し、マイクロサービスの要件を満たしていることを確認します。これには、テスト環境でのイメージの実行、マイクロサービスの機能のテスト、およびイメージのパフォーマンスとスケーラビリティの検証が含まれます。

マイクロサービスをコンテナ・イメージにパッケージ化することで、マイクロサービスを導入する準備が整い、さまざまな環境で一貫して実行できるようになります。コンテナを使用すると、マイクロサービスの導入、管理、拡張が容易になり、CI/CDツールを使用して導入プロセスを自動化できます。

マイクロサービスは、次のような複数の方法でデプロイできます。

• 手動デプロイメント:これには、各マイクロサービスを1つまたは複数のサーバーに手動でデプロイすることが含まれます。この方法は簡単ですが、自動化が欠如しており、特に大規模なマイクロサービスの導入には時間がかかる場合があります。
• 仮想マシン(VM): VMsは、マイクロサービスを実行するための仮想環境を提供します。この方法は、高度な分離を提供し、様々な環境でマイクロサービスをテストするのに役立ちます。
• コンテナ:コンテナは、分離された環境でマイクロサービスをパッケージ化および実行するための軽量で移植可能な方法を提供します。マイクロサービスの導入は、移植性、スケーラビリティ、リソースの効率性から人気があります。
• サーバーレス・アーキテクチャ:サーバーレス・アーキテクチャでは、クラウド・プロバイダがインフラストラクチャとスケーリングを処理する完全管理環境でマイクロサービスを実行できます。この方法はコスト効率が高く、自動スケーリングを提供しますが、すべてのユースケースに適しているとはかぎりません。
• クラスタ管理: Kubernetesなどのクラスタ管理プラットフォームは、マイクロサービスのデプロイメント、スケーリングおよびオーケストレーションを管理および自動化する方法を提供します。この方法は高度な自動化を提供し、大規模なマイクロサービスの導入に適しています。

導入方法の選択は、各マイクロサービスの特定の要件とシステム全体のアーキテクチャによって異なります。マイクロサービスの中には、手動デプロイメントのメリットがあるものと、クラスタ管理プラットフォームによって提供される自動化とスケーラビリティが必要なものがあります。

Oracle Cloud Infrastructure(OCI)には、マイクロサービスをデプロイおよび管理するための様々なオプションが用意されています。

• Oracle Kubernetes Engine (OKE): OKEは、コンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を簡素化する完全管理型のKubernetesサービスです。OKEを使用して、マイクロサービスをコンテナとしてKubernetesクラスタにデプロイできます。
• Oracle Functions: Oracle Functionsはサーバーレス・コンピューティング・サービスであり、インフラストラクチャを管理することなくイベントに応答してコードを実行できます。マイクロサービスをファンクションとしてOracle Functionsにデプロイできます。
• Oracle Container Instance: Oracle Containerインスタンスは、サーバーを管理せずにコンテナを即時に実行できるサーバーレス・コンピュート・サービスです。これにより、コンテナ用に最適化されたサーバーレス・コンピュートでアプリケーションを簡単に実行できます。
• Oracle Container Registry: Oracle Container Registryは、コンテナ・イメージを格納および管理できるプライベート・コンテナ・レジストリです。Oracle Container Registryを使用して、マイクロサービスのコンテナ・イメージをホストできます。

マイクロサービスの要件や組織の要件に応じて、OCIにマイクロサービスをデプロイするために使用できるオプションを使用します。

次の情報は、アプリケーションおよび組織のニーズに関する意思決定を行う際に考慮すべき、マイクロサービス・アーキテクチャに関連する一般的な落とし穴のいくつかを示しています。

• 複雑性:多数のマイクロサービスの管理は複雑になり、堅牢なインフラストラクチャと監視システムが必要になります。
• サービス間通信:マイクロサービスは相互に通信する必要があるため、ネットワーク・レイテンシが発生し、複雑さが増す可能性があります。
• テストとデプロイメント:マイクロサービスのテストとデプロイは、特にサービスが相互に依存関係を持つ場合に困難になることがあります。
• 分散システム:マイクロサービス・アーキテクチャには、分散システムの構築および管理に関連する新しい課題が導入されています。
• データ管理:マイクロサービスではデータの共有が必要になる場合があり、分散システムで管理することが困難な場合があります。
• セキュリティ:多数のマイクロサービスの保護は困難であり、包括的なセキュリティ戦略が必要です。
• デバッグ:マイクロサービスのデバッグは、複数のサービスや依存関係にまたがる可能性があるため、モノリシック・アプリケーションをデバッグするよりも難しい場合があります。
• リソースのオーバーヘッド:マイクロサービス・アーキテクチャでは、各サービスで独自のインフラストラクチャとリソースが必要になる可能性があるため、リソース・オーバーヘッドが増加する可能性があります。

これらは、マイクロサービス・アーキテクチャに関連する課題のほんの一部です。マイクロサービス・アプローチを採用する前に、ニーズと要件を慎重に評価します。

• サーバーレス