モノリシック アプリケーションのパフォーマンス制約

完了

システムのアーキテクチャ変更を選択する理由は数多くあります。 運用上の機敏性、コスト、スケーラビリティ、パフォーマンスなど、システムのアーキテクチャ決定で役割を果たす要因にはさまざまなものがあります。 この例では、パフォーマンスがどのようにドローン配送システムの要因になるのかを詳しく見ていきます。

Fabrikam のドローン配送事業が拡大するにつれて、システムの負荷が増大します。 現在のアーキテクチャには負荷がかかっています。 Fabrikam は、アプリケーションのスケーリングに柔軟性を与えたいと考えています。これは、現在のモノリシック アーキテクチャではできないことです。 アプリケーションのスケーラビリティ向上は、Fabrikam がアプリケーションのマイクロサービス アーキテクチャへの移行を検討する推進要因の 1 つです。

モノリスとマイクロサービスのスケーリングの比較

マイクロサービス アーキテクチャの主な利点の 1 つが、スケーリング機能の向上です。 サービスが分離されているため、負荷の増大に伴い、各サービスを個別にスケーリングすることが簡単になります。

ドローン配送システムで、機能の違いを確認できます。 モノリシック アーキテクチャを使用すると、すべてのサービスがアプリケーションの 1 つのインスタンス内に含まれます。 配送依頼を送信および管理する API インターフェイスを顧客に公開します。 顧客からの依頼が増えるにつれ、システムの負荷が増大します。 ユーザー エクスペリエンスに悪影響を及ぼさないように、より多くのリソースをシステムに割り当てる必要があります。

モノリシック アーキテクチャでは、このサービスを個別にスケーリングするには、他のサービスのリソースもスケーリングする必要があります。各アプリケーション インスタンス内に含まれるためです。 他のサービスに対する負荷は、最小限でよい場合があり、リソース使用量を増やす必要もないため、この配置は効率的ではありません。

マイクロサービス アーキテクチャでは、各サービスが分離されているため、他のサービスとは独立して API をスケーリングできます。 不要なサービスのリソースを使用する必要がないため、この配置は効率が向上します。

ドローン配送モノリシック アーキテクチャに関する課題

荷物サービスは、ビジネスの重要な部分として確認されましたが、もともとはモノリシックの一部でした。 顧客による依存度は、劇的に上昇しています。この負荷が増大するにつれて、パフォーマンスが悪影響を受けます。 この状況に対処するため、Fabrikam では、このビジネスを完全に制御する専任の開発チームを設けました。 チームは、このサービスの開発と反復処理を行い、荷物サービスのあらゆる側面に単独で責任を負う予定です。

荷物サービスはモノリシックに含まれているため、チームが自律的に処理することはできません。 共有データとデータ構造に依存する必要があります。 また、必要に応じてすぐに反復処理することもできません。 パフォーマンスとスケーラビリティの問題と併せて、このサービスは、マイクロサービスの有力候補と確認されています。

Fabrikam がマイクロサービス アーキテクチャを活用するためにアプリケーションを分析および分解する方法について詳しく見ていきましょう。