アーキテクチャ スタイルは、特定の特性を共有するアーキテクチャのファミリです。 たとえば、 N 層 は一般的なアーキテクチャ スタイルです。 最近では、 マイクロサービス アーキテクチャ が好意を得始めている。 アーキテクチャ スタイルでは特定のテクノロジを使用する必要はありませんが、一部のテクノロジは特定のアーキテクチャに適しています。 たとえば、コンテナーはマイクロサービスに適しています。
クラウド アプリケーションでよく見られるアーキテクチャ スタイルのセットを特定しました。 各スタイルの記事には、次のコンポーネントが含まれています。
- スタイルの説明と論理図
- このスタイルを選択するタイミングに関する推奨事項
- 利点、課題、ベスト プラクティス
- 関連する Azure サービスを使用する推奨されるデプロイ
スタイルの簡単な紹介
このセクションでは、特定したアーキテクチャ スタイルのクイック ツアーと、その使用に関するいくつかの大まかな考慮事項について説明します。 このリストは、包括的ではありません。 詳細については、リンク先の記事を参照してください。
n 層
N 層 は、アプリケーションを論理層と物理層に分割するエンタープライズ アプリケーションの従来のアーキテクチャです。 各レイヤーには特定の責任があり、レイヤーは、その下のレイヤーのみを呼び出すことによって依存関係を管理します。 一般的なレイヤーには、プレゼンテーション、ビジネス ロジック、データ アクセスが含まれます。
N 層アーキテクチャは、既に階層化アーキテクチャを使用している既存のアプリケーションの移行に適しています。 この方法では、Azure に移行するときに最小限の変更が必要であり、オンプレミスとクラウドの両方のコンポーネントを含む混合環境がサポートされます。 ただし、水平レイヤーを使用すると、アプリケーションの複数の部分に影響を与えずに変更を導入することが困難になる可能性があるため、頻繁な更新の機敏性が制限されます。
Web キュー ワーカー
Web キュー ワーカー は、Web フロントエンド、メッセージ キュー、バックエンド ワーカーで構成されるアーキテクチャです。 Web フロントエンドは HTTP 要求とユーザー操作を処理しますが、ワーカーはリソースを集中的に消費するタスク、実行時間の長いワークフロー、またはバッチ操作を実行します。 フロントエンドとワーカーの間の通信は、非同期メッセージ キューを介して行われます。
このアーキテクチャは、リソースを集中的に使用する処理要件がある比較的単純なドメインを持つアプリケーションに最適です。 App Service や Azure Functions などのマネージド Azure サービスを使用すると、簡単に理解してデプロイできます。 フロントエンドとワーカーを個別にスケーリングして、リソース割り当ての柔軟性を提供できます。 しかし、慎重な設計がなければ、両方のコンポーネントが大きくモノリシックになる可能性があります。
マイクロサービス
マイクロサービス アーキテクチャは、アプリケーションを小規模で自律的なサービスのコレクションに分解します。 各サービスは、境界付きコンテキスト内に 1 つのビジネス機能を実装し、独自のデータ ストレージを持つ自己完結型です。 サービスは明確に定義された API を介して通信し、個別に開発、デプロイ、スケーリングできます。
マイクロサービスを使用すると、チームは自律的に作業し、リリース速度の高い頻繁な更新をサポートできます。 このアーキテクチャは、頻繁な変更とイノベーションを必要とする複雑なドメインに適しています。 ただし、サービスの検出、データの一貫性、分散システム管理などの領域では、非常に複雑になります。 成功するには、成熟した開発と DevOps プラクティスが必要です。これにより、高度な技術的機能を持つ組織に適しています。
イベントドリブン アーキテクチャ
イベント ドリブン アーキテクチャ では、イベント プロデューサーがイベントのストリームを生成し、イベント コンシューマーがそれらのイベントにほぼリアルタイムで応答するパブリッシュ/サブスクライブ モデルを使用します。 プロデューサーとコンシューマーは互いに切り離され、イベント チャネルまたはブローカーを介した通信が行われます。 このアーキテクチャでは、単純なイベント処理と複雑なイベント パターン分析の両方がサポートされています。
イベント ドリブン アーキテクチャは、待機時間を最小限に抑えたリアルタイム処理を必要とするシナリオで優れています。 たとえば、大量のストリーミング データを処理する必要がある IoT ソリューション、金融取引システム、アプリケーションなどがあります。 イベントドリブン アーキテクチャは、優れたスケーラビリティと障害の分離を提供しますが、分散コンポーネント間での確実な配信、イベントの順序付け、最終的な一貫性に関する課題が発生します。
ビッグ データ
ビッグ データ アーキテクチャは、従来のデータベース システムでは大きすぎるデータや複雑なデータの取り込み、処理、分析を処理します。 これらのアーキテクチャには、通常、データ ストレージ (データ レイクなど) のコンポーネント、履歴分析のバッチ処理、リアルタイム分析情報のストリーム処理、レポートと視覚化のための分析データ ストアが含まれます。
ビッグ データ アーキテクチャは、大規模なデータセットから分析情報を抽出したり、機械学習を使用して予測分析をサポートしたり、IoT デバイスからのリアルタイム ストリーミング データを処理したりする必要がある組織にとって不可欠です。 最新の実装では、多くの場合、Microsoft Fabric などのマネージド サービスを使用して、ビッグ データ ソリューションの構築と保守の複雑さを簡素化します。
ビッグ コンピューティング
大規模なコンピューティング アーキテクチャでは、計算負荷の高い操作に数百または数千のコアを必要とする大規模なワークロードがサポートされます。 作業は、多数のコアで同時に実行される個別のタスクに分割でき、各タスクは入力を受け取り、処理し、出力を生成します。 タスクは、独立した(ほとんど通信を必要としない並列処理)か、高速通信を必要とする密結合のいずれかとすることができます。
ビッグ コンピューティングは、シミュレーション、財務リスク モデリング、科学コンピューティング、エンジニアリング ストレス分析、3D レンダリングに不可欠です。 Azure には、マネージド ビッグ コンピューティング ワークロード用の Azure Batch や、従来のクラスター管理用の HPC Pack などのオプションが用意されています。 これらのアーキテクチャでは、オンデマンドで容量をバーストし、必要に応じて数千個のコアにスケーリングできます。
制約としてのアーキテクチャ スタイル
アーキテクチャ スタイルでは、表示できる要素のセットや、それらの要素間の許可されたリレーションシップなど、デザインに制約が設けられています。 制約は、選択肢のユニバースを制限することで、アーキテクチャの "形状" を導きます。 アーキテクチャが特定のスタイルの制約に準拠している場合、特定の望ましいプロパティが出現します。
たとえば、マイクロサービスの制約には次のようなものがあります。
- サービスは 1 つの責任を表します。
- すべてのサービスは、他のサービスとは独立しています。
- データは、データを所有するサービスに対してプライベートです。 サービスはデータを共有しません。
これらの制約に従うと、次のアクションを実行できるシステムが得られる。
- サービスを個別にデプロイします。
- 障害を分離する。
- より頻繁に更新をプッシュします。
- 新しいテクノロジをより簡単にアプリケーションに導入します。
各アーキテクチャ スタイルには、独自のトレードオフがあります。 アーキテクチャ スタイルを選択する前に、基になる原則と制約を理解することが不可欠です。 その理解がなければ、その完全な利点を実現することなく、表面的にスタイルに準拠するデザインを作成するリスクがあります。 実装する方法よりも、特定のスタイルを選択する理由に重点を置きます。 実用的である。 アーキテクチャの純度を追いかけるよりも、制約を緩和する方が良い場合があります。
理想的には、情報に基づくワークロード利害関係者からの入力を使用してアーキテクチャ スタイルを選択する必要があります。 ワークロード チームは、まず、解決している問題の性質を特定する必要があります。 その後、主要なビジネス ドライバーと対応するアーキテクチャ特性 ( 非機能要件とも呼ばれます) を定義し、優先順位を付ける必要があります。 たとえば、市場投入までの時間が重要な場合、チームは、迅速なデプロイを可能にするために、保守性、テスト容易性、信頼性に優先順位を付ける可能性があります。 チームに予算の制約が厳しい場合は、実現可能性とシンプルさが優先される可能性があります。 アーキテクチャ スタイルの選択と維持は、1 回限りではありません。 継続的な測定、検証、および絞り込みが必要です。 アーキテクチャの方向を後で変更するとコストがかかる可能性があるため、長期的な効率をサポートし、リスクを軽減するために、より多くの労力を事前に投資する価値があります。
次の表は、各スタイルが依存関係を管理する方法と、各スタイルに最適なドメインの種類をまとめたものです。
アーキテクチャ のスタイル | 依存関係の管理 | ドメインの種類 |
---|---|---|
n 層 | サブネットごとに分割された横方向の層 | 従来のビジネス ドメイン。 更新の頻度が低い。 |
Web-Queue-Worker | 非同期メッセージングによって切り離されたフロントエンド ジョブとバックエンド ジョブ。 | リソースを集中的に使用するタスクがある比較的単純なドメイン。 |
マイクロサービス | API を介して相互に呼び出すサービスを垂直方向 (機能的に) 分解します。 | 複雑なドメイン。 頻繁な更新。 |
イベント ドリブン アーキテクチャ | プロデューサーまたはコンシューマー。 各サブシステムの独立したビュー。 | モノのインターネット (IoT) とリアルタイム システム。 |
ビッグ データ | 巨大なデータセットを小さなチャンクに分割します。 ローカル データセットでの並列処理。 | バッチとリアルタイムのデータ分析。 機械学習を使用した予測分析。 |
ビッグ コンピューティング | 何千ものコアへのデータ割り当て。 | シミュレーションなどのコンピューティング集中型ドメイン。 |
課題と利点を検討する
制約によって課題も生まれるため、これらのスタイルのいずれかを採用する際のトレードオフを理解することが重要です。 アーキテクチャ スタイルの利点が、 このサブドメインと有界コンテキストの課題を上回るかどうかを判断します。
アーキテクチャ スタイルを選択するときは、次の種類の課題を考慮してください。
複雑さ: アーキテクチャの複雑さはドメインと一致している必要があります。 単純すぎると、依存関係が十分に管理されず、構造が分解される 大きな泥のボールが発生する可能性があります。
非同期メッセージングと最終的な整合性: 非同期メッセージングは、メッセージを再試行できるため、サービスを分離し、信頼性を向上させるために使用されます。 また、スケーラビリティも向上します。 ただし、非同期メッセージングでは、最終的な整合性と重複するメッセージの可能性を処理する上で課題も生じます。
サービス間通信: アプリケーションを別のサービスに分解すると、通信のオーバーヘッドが増加する可能性があります。 マイクロサービス アーキテクチャでは、多くの場合、このオーバーヘッドによって待機時間の問題やネットワークの輻輳が発生します。
管理: アプリケーションの管理には、監視、更新プログラムの展開、運用の正常性の維持などのタスクが含まれます。