マイクロサービスへのモノリスの分解 - AWS 規範的ガイダンス
ターゲットを絞ったビジネス成果

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マイクロサービスへのモノリスの分解

タビー・ウォードとドミトリー・グリン、Amazon Web Services（AWS）

2023 年 4 月（ドキュメント履歴）

Amazon Web Services（AWS）クラウドへの移行には、技術的・ビジネス的な俊敏性、新たな収益機会、コスト削減など多くの利点 があります。これらの利点を最大限に活用するには、モノリシックアプリケーションをマイクロサービスにリファクタリングして、組織のソフトウェアを継続的に最新化する必要があります。このプロセスは主に 3 つのステップで構成される：

モダナイゼーションには通常、次の 2 種類のプロジェクトが含まれます。

  • ブラウンフィールドプロジェクトでは、既存またはレガシーシステムのコンテキスト内で新しいソフトウェアシステムを開発して展開します。

  • グリーンフィールドプロジェクトでは、レガシーコードを一切使用せずに、まったく新しい環境用のシステムをゼロから構築します。

ブラウンフィールドプロジェクトの場合、アプリケーションモダナイゼーションの第一歩は、ポートフォリオ内のモノリスをマイクロサービスに分解することです。

ほとんどのアプリケーションは、特定のビジネスユースケースのために設計されたモノリスとして始まります。モノリスのアーキテクチャがモジュラー設計を強制しない場合でも、確立されたドメイン知識の範囲内で責任が明確に定義されていないアプリケーションでは、モノリスが有効な選択肢であり続ける可能性があります。モノリスが展開の単一ユニットであるという中心的な特性は、緊密な結合や内部構造の欠如といった設計上の欠陥を軽減するのにも役立ちます。

モノリスはユースケースによっては有効なオプションですが、一般的に最新のアプリケーションには適していません。モノリスの内部構造が適切に定義されていないと、コードの保守が難しくなり、新規開発者は習得に時間がかかり、追加のサポートコストが発生します。結合率が高くまとまりが小さいと、新機能の追加にかかる時間が大幅に長くなる可能性があり、トラフィックパターンに基づいて個々のコンポーネントをスケーリングできない場合があります。モノリスはまた、1 つの大きなリリースのために複数のチームが調整する必要があり、コラボレーションと知識移転の負担を増大させます。最後に、ビジネスやユーザーベースが拡大すると、新機能の追加や新しいユーザーエクスペリエンスの構築が難しくなることがわかります。

これを回避するには、分解パターンを使用してモノリシックなアプリケーションを分割し、複数のマイクロサービスに変換し、マイクロサービスアーキテクチャに移行することができます。マイクロサービス・アーキテクチャは、疎結合の一連のサービスとしてアプリケーションを構成します。マイクロサービスは、継続的デリバリーと継続的デプロイメント（CI/CD）プロセスを可能にすることで、ソフトウェア開発を加速するように設計されています。

分解プロセスを開始する前に、どのモノリスを分解するかを評価する必要があります。信頼性やパフォーマンスに問題があるモノリスや、緊密に結合したアーキテクチャーの複数のコンポーネントを含むモノリスを必ず含めること。また、モノリスのビジネスユースケース、そのテクノロジー、他のアプリケーションとの相互依存性を十分に理解しておくことをお勧めします。

このガイドは、アプリケーションオーナー、ビジネスオーナー、アーキテクト、テクニカルリード、プロジェクトマネージャーを対象としています。モノリスの分解に使用される次の 6 つのクラウドネイティブパターンについて説明し、それぞれの長所と短所について説明します。

このガイドは、AWS が推奨するアプリケーション近代化アプローチをカバーするコンテンツシリーズの一部です。このシリーズには以下の内容も含まれている：

ターゲットを絞ったビジネス成果

モノリスをマイクロサービスに分解すると、次のような結果が得られるはずです。

  • モノリシック・アプリケーションをマイクロサービス・アーキテクチャーに効率的に移行すること。

  • これにより、高いスケーラビリティ、回復力の向上、継続的デリバリー、障害隔離といった中核的な活動を中断することなく、変動するビジネスニーズに迅速に対応することができます。

  • 各マイクロサービスを個別にテストしてデプロイできるため、イノベーションが早くなります。