マイクロフロントエンドと代替アーキテクチャの比較 - AWS 規範ガイダンス

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

マイクロフロントエンドと代替アーキテクチャの比較

すべてのアーキテクチャ戦略と同様に、マイクロフロントエンドを採用する決定は、組織の原則に基づく評価基準に基づいている必要があります。マイクロフロントエンドには利点と欠点があります。組織がマイクロフロントエンドを使用することを決定した場合は、分散システムの課題に対処するための戦略を設定する必要があります。

アプリケーションアーキテクチャを選択する場合、マイクロフロントエンドの最も一般的な代替手段は、モノリス、n 層アプリケーション、マイクロサービスとシングルページアプリケーション (SPA) フロントエンドの組み合わせです。これらはすべて有効なアプローチであり、それぞれに利点と欠点があります。

モノリス

頻繁な変更を必要としない小さなアプリケーションは、モノリスとして非常に迅速に配信できます。大幅な成長が予想される状況でも、モノリスは自然な最初のステップです。後で、モノリスを廃止するか、より柔軟な構造にリファクタリングすることができます。モノリスから始めることで、組織は市場に進出し、顧客のフィードバックを得て、製品を迅速に改善できます。

ただし、モノリシックアプリケーションは、慎重に保守されていない場合や、コードベースのサイズが時間の経過とともに大きくなると、低下する傾向があります。複数のチームが同じコードベースに多大な貢献をしている場合、それらすべてがメンテナンスと運用に寄与することはほとんどありません。これにより、責任のバランスが崩れ、速度に影響し、非効率になります。同時に、モノリスのモジュール間で誤って結合すると、コードベースが進化するにつれて意図しない副作用が発生します。これらの副作用により、誤動作や機能停止が発生する可能性があります。

N 層アプリケーション

比較的静的な進化速度を持つより複雑なアプリケーションは、フロントエンドとバックエンドの間に REST または GraphQL レイヤーを持つ 3 層アーキテクチャ (表現、アプリケーション、データ) として構築できます。これははるかに柔軟で、異なる階層のチームはある程度独立して開発できます。n 層アプリケーションの欠点は、機能のデプロイがはるかに難しいことです。フロントエンドとバックエンドは API 契約によって分離されるため、重大な変更を一緒にデプロイするか、API をバージョニングする必要があります。

次の一般的なシナリオを考えてみましょう。新機能をリリースする際にデータスキーマの変更が必要な場合、製品所有者がフロントエンドチームと一連の機能について合意するまでに数日かかることがあります。次に、フロントエンドチームはバックエンドチームに、各自の側で機能を開発およびリリースするよう依頼します。バックエンドチームはデータ所有者と協力してデータベーススキーマの更新をリリースします。次に、バックエンドチームは API の新しいバージョンをリリースし、フロントエンドチームが変更を開発してリリースできるようにします。このシナリオでは、変更の開発、テスト、リリースに関する独自のバックログ、優先順位、メカニズムが各チームにあるため、本番環境へのすべての変更の伝播に数週間または数か月かかる場合があります。

マイクロサービス

マイクロサービスアーキテクチャでは、バックエンドは小さなサービスに分解され、それぞれが境界のあるコンテキスト内で特定のビジネス上の懸念に対処します。また、明確に定義されたインターフェイス契約を公開することで、各マイクロサービスが他のサービスと強く切り離されます。

境界コンテキストとインターフェイス契約は、適切に作成されたモノリスと n 層アーキテクチャにも存在する必要があることに注意する必要があります。ただし、マイクロサービスアーキテクチャでは、通信はネットワーク、通常は HTTP プロトコルを介して行われ、サービスには専用のランタイムインフラストラクチャがあります。これにより、各バックエンドサービスの開発、配信、運用が個別にサポートされます。

要件に対するアプローチの選択

モノリスと n 層アーキテクチャは、複数のドメインの懸念を 1 つの技術アーティファクトにバンドルします。これにより、依存関係や内部データフローなどの側面を管理しやすくなりますが、新しい機能の提供はより困難になります。一貫したコードベースを維持するために、チームは処理する必要のあるコードベースが大きいため、リファクタリングとデカップリングに時間を費やすことがよくあります。

いくつかのチームによって開発されたアプリケーションでは、マイクロフロントエンドへの移行に伴う追加の複雑さが不要な場合があります。これは、チームが高い結合とリリース変更への長いリードタイムのペナルティを支払っていない場合に特に当てはまります。

つまり、複雑で動きの速いアプリケーションには、多くの場合、より複雑で分散型のアーキテクチャが適切な選択です。小規模から中規模のアプリケーションでは、特にアプリケーションが短期間で劇的に進化しない場合、分散アーキテクチャがモノリシックアーキテクチャよりも必ずしも優れているとは限りません。