アーキテクチャ スタイルは、特定の特性を共有するアーキテクチャのファミリです。 たとえば、 N 層 は一般的なアーキテクチャ スタイルです。 最近では、 マイクロサービス アーキテクチャが 好意を得るようになった。 アーキテクチャ スタイルでは特定のテクノロジを使用する必要はありませんが、一部のテクノロジは特定のアーキテクチャに適しています。 たとえば、コンテナーはマイクロサービスに適しています。
クラウド アプリケーションでよく見られるアーキテクチャ スタイルのセットを特定しました。 各スタイルの記事には次のものが含まれます。
- スタイルの説明と論理図。
- このスタイルを選択するタイミングに関する推奨事項。
- 利点、課題、ベスト プラクティス。
- 関連する Azure サービスを使用して推奨されるデプロイ。
スタイルの簡単な紹介
このセクションでは、特定したアーキテクチャ スタイルの概要と、その使用に関する考慮事項について簡単に説明します。 一覧は完全ではありません。 詳細については、リンクされたトピックを参照してください。
n 層
N 層 は、エンタープライズ アプリケーションの従来のアーキテクチャです。 依存関係は、プレゼンテーション、ビジネス ロジック、データ アクセスなどの論理機能を実行する レイヤー にアプリケーションを分割することによって管理されます。 レイヤーは、その下にあるレイヤーのみを呼び出すことができます。 ただし、この水平レイヤー化は問題を引き起こす可能性があります。 アプリケーションの残りの部分に触れることなく、アプリケーションの一部に変更を導入するのは難しい場合があります。 これにより、頻繁な更新が難しくなり、新機能を追加する速度が制限されます。
N 層は、既に階層化アーキテクチャを使用している既存のアプリケーションを移行する場合に自然に適しています。 そのため、N 層は、サービスとしてのインフラストラクチャ (IaaS) ソリューション、または IaaS とマネージド サービスの組み合わせを使用するアプリケーションでよく見られます。
Web キュー ワーカー
純粋な PaaS ソリューションの場合は、 Web-Queue-Worker アーキテクチャを検討してください。 このスタイルでは、アプリケーションには、HTTP 要求を処理する Web フロントエンドと、CPU を集中的に使用するタスクまたは実行時間の長い操作を実行するバックエンド ワーカーがあります。 フロントエンドは、非同期メッセージ キューを介してワーカーと通信します。
Web キュー ワーカーは、リソースを集中的に使用するタスクがある比較的単純なドメインに適しています。 N 層と同様に、アーキテクチャは簡単に理解できます。 マネージド サービスを使用すると、デプロイと操作が簡略化されます。 しかし、複雑なドメインでは、依存関係を管理するのが難しい場合があります。 フロントエンドとワーカーは、保守と更新が困難な大型のモノリシック コンポーネントになりやすくなります。 N 層と同様に、更新の頻度を減らし、イノベーションを制限することができます。
マイクロサービス
アプリケーションに複雑なドメインがある場合は、 マイクロサービス アーキテクチャへの移行を検討してください。 マイクロサービス アプリケーションは、多数の小規模な独立したサービスで構成されます。 各サービスは、1 つのビジネス機能を実装します。 サービスは疎結合され、API コントラクトを介して通信します。
各サービスは、小規模で集中した開発チームによって構築できます。 個々のサービスは、チーム間で多くの調整を行わなくてもデプロイできるため、頻繁な更新が推奨されます。 マイクロサービス アーキテクチャは、N 層または Web キュー ワーカーよりもビルドと管理が複雑です。 成熟した開発と DevOps カルチャが必要です。 しかし、このスタイルは、リリース速度の向上、イノベーションの高速化、回復性の高いアーキテクチャにつながる可能性があります。
イベントドリブン アーキテクチャ
Event-Driven アーキテクチャ では、パブリッシュ/サブスクライブ (pub-sub) モデルが使用されます。このモデルでは、プロデューサーがイベントを発行し、コンシューマーがイベントをサブスクライブします。 プロデューサーはコンシューマーから独立しており、コンシューマーは互いに独立しています。
IoT ソリューションなど、待機時間が非常に短い大量のデータを取り込んで処理するアプリケーションのイベント ドリブン アーキテクチャについて考えてみましょう。 このスタイルは、異なるサブシステムが同じイベント データに対して異なる種類の処理を実行する必要がある場合にも役立ちます。
ビッグ データ、ビッグ コンピューティング
ビッグ データ と ビッグ コンピューティング は、特定のプロファイルに適合するワークロードに特化したアーキテクチャ スタイルです。 ビッグ データでは、非常に大きなデータセットがチャンクに分割され、セット全体で並列処理が実行され、分析とレポートが行われます。 ハイ パフォーマンス コンピューティング (HPC) とも呼ばれるビッグ コンピューティングでは、多数 (数千) のコアにわたって並列計算が行われます。 ドメインには、シミュレーション、モデリング、3-D レンダリングが含まれます。
制約としてのアーキテクチャ スタイル
アーキテクチャ スタイルでは、表示できる要素のセットや、それらの要素間の許可されたリレーションシップなど、デザインに制約が設けられています。 制約は、選択肢のユニバースを制限することで、アーキテクチャの "形状" を導きます。 アーキテクチャが特定のスタイルの制約に準拠している場合、特定の望ましいプロパティが出現します。
たとえば、マイクロサービスの制約には次のようなものがあります。
- サービスは 1 つの責任を表します。
- すべてのサービスは、他のサービスとは独立しています。
- データは、データを所有するサービスに対してプライベートです。 サービスはデータを共有しません。
これらの制約に従うことで生じるのは、サービスを個別にデプロイできるシステムであり、障害が分離され、頻繁に更新される可能性があり、新しいテクノロジをアプリケーションに簡単に導入できます。
各アーキテクチャ スタイルには、独自のトレードオフがあります。 したがって、アーキテクチャ スタイルを選択する前に、そのスタイルの基になる原則と制約を理解していることを確認してください。 それ以外の場合は、最終的に表面的なレベルでスタイルに準拠するデザインになりますが、そのスタイルの可能性を最大限に発揮することはできません。 実装する方法よりも、特定のアーキテクチャ スタイルを選択する理由に注意する必要があります。 また、実用的になることも重要です。 アーキテクチャの純粋性を主張するのではなく、制約を緩和する方が良い場合があります。
適切なアーキテクチャ スタイルの選択は、情報に基づくワークロード利害関係者のコンセンサスを使用して行うのが理想的です。 ワークロード チームは、まず、解決しようとしている問題の性質を特定する必要があります。 次に、ビジネス ドライバーと対応するアーキテクチャ特性 (非機能要件とも呼ばれます) を特定し、優先順位を付ける必要があります。 たとえば、市場投入までの時間を短縮する必要がある場合は、迅速なデプロイ機能によって保守性、テスト容易性、信頼性に優先順位を付ける可能性があります。 または、ワークロード チームが予算を制約している場合は、実現可能性とシンプルさに優先順位を付ける可能性があります。 アーキテクチャ スタイルの選択と維持は、1 回限りのアクティビティではなく、継続的なアプローチです。アーキテクチャは、時間の経過とともに継続的に測定、検証、微調整する必要があります。 通常、アーキテクチャ スタイルの切り替えに大きなコストがかかるため、チームの長期的な効率とリスク軽減のために、より多くの労力を前もって正当化できます。
次の表は、各スタイルが依存関係を管理する方法と、それぞれに最適なドメインの種類をまとめたものです。
| アーキテクチャ のスタイル | 依存関係の管理 | ドメインの種類 |
|---|---|---|
| n 層 | サブネットごとに分割された横方向の層 | 従来のビジネス ドメイン。 更新の頻度が低い。 |
| Webキュー作業者 | 非同期メッセージングによって分離された、フロント ジョブとバックエンド ジョブ。 | リソースを集中的に使用するタスクがある比較的単純なドメイン。 |
| マイクロサービス | API を介して相互に呼び出すサービスを垂直方向 (機能的に) 分解します。 | 複雑なドメイン。 頻繁な更新。 |
| イベント ドリブン アーキテクチャ | プロデューサー/コンシューマー。 サブシステムごとの独立したビュー。 | IoT とリアルタイム システム。 |
| ビッグ データ | 巨大なデータセットを小さなチャンクに分割します。 ローカル データセットでの並列処理。 | バッチとリアルタイムのデータ分析。 ML を使用した予測分析。 |
| ビッグ コンピューティング | 何千ものコアへのデータ割り当て。 | シミュレーションなどのコンピューティング集中型ドメイン。 |
課題と利点を検討する
制約によって課題も生まれるため、これらのスタイルのいずれかを採用する際のトレードオフを理解することが重要です。 アーキテクチャ スタイルの利点は、 このサブドメインと有界コンテキストの課題を上回ります。
アーキテクチャ スタイルを選択する際に考慮すべき課題の種類を次に示します。
複雑さ。 アーキテクチャの複雑さはドメインに対して正当化されますか? 逆に、スタイルはドメインにとって単純すぎますか? その場合、アーキテクチャは依存関係をクリーンに管理するのに役立たないため、最終的に "泥の大きなボール" が発生するリスクがあります。
非同期メッセージングと最終的な整合性。 非同期メッセージングを使用すると、サービスを分離し、信頼性 (メッセージを再試行できるため) とスケーラビリティを向上させることができます。 ただし、これにより、最終的な整合性を処理する上で課題が生じ、メッセージが重複する可能性もあります。
サービス間通信。 アプリケーションを別のサービスに分解すると、サービス間の通信によって許容できない待機時間が発生したり、ネットワークの輻輳が発生したりするリスクがあります (マイクロサービス アーキテクチャなど)。
管理容易性。 アプリケーションの管理、監視、更新プログラムの展開などがどのくらい難しいですか?