次の方法で共有


アーキテクチャ スタイル

アーキテクチャ スタイルは、特定の特性を共有するアーキテクチャのファミリです。 たとえば、 N 層 は一般的なアーキテクチャ スタイルです。 最近では、 マイクロサービス アーキテクチャ が好意を得始めている。 アーキテクチャ スタイルでは特定のテクノロジを使用する必要はありませんが、一部のテクノロジは特定のアーキテクチャに適しています。 たとえば、コンテナーはマイクロサービスに適しています。

クラウド アプリケーションでよく見られるアーキテクチャ スタイルのセットを特定しました。 各スタイルの記事には、次のコンポーネントが含まれています。

  • スタイルの説明と論理図
  • このスタイルを選択するタイミングに関する推奨事項
  • 利点、課題、ベスト プラクティス
  • 関連する Azure サービスを使用する推奨されるデプロイ

スタイルの簡単な紹介

このセクションでは、特定したアーキテクチャ スタイルのクイック ツアーと、その使用に関するいくつかの大まかな考慮事項について説明します。 このリストは、包括的ではありません。 詳細については、リンク先の記事を参照してください。

n 層

N 層アーキテクチャ スタイルの論理図。

N 層 は、アプリケーションを論理層と物理層に分割するエンタープライズ アプリケーションの従来のアーキテクチャです。 各レイヤーには特定の責任があり、レイヤーは、その下のレイヤーのみを呼び出すことによって依存関係を管理します。 一般的なレイヤーには、プレゼンテーション、ビジネス ロジック、データ アクセスが含まれます。

N 層アーキテクチャは、既に階層化アーキテクチャを使用している既存のアプリケーションの移行に適しています。 この方法では、Azure に移行するときに最小限の変更が必要であり、オンプレミスとクラウドの両方のコンポーネントを含む混合環境がサポートされます。 ただし、水平レイヤーを使用すると、アプリケーションの複数の部分に影響を与えずに変更を導入することが困難になる可能性があるため、頻繁な更新の機敏性が制限されます。

Web キュー ワーカー

WebQueue-Worker アーキテクチャ スタイルの論理図。

Web キュー ワーカー は、Web フロントエンド、メッセージ キュー、バックエンド ワーカーで構成されるアーキテクチャです。 Web フロントエンドは HTTP 要求とユーザー操作を処理しますが、ワーカーはリソースを集中的に消費するタスク、実行時間の長いワークフロー、またはバッチ操作を実行します。 フロントエンドとワーカーの間の通信は、非同期メッセージ キューを介して行われます。

このアーキテクチャは、リソースを集中的に使用する処理要件がある比較的単純なドメインを持つアプリケーションに最適です。 App Service や Azure Functions などのマネージド Azure サービスを使用すると、簡単に理解してデプロイできます。 フロントエンドとワーカーを個別にスケーリングして、リソース割り当ての柔軟性を提供できます。 しかし、慎重な設計がなければ、両方のコンポーネントが大きくモノリシックになる可能性があります。

マイクロサービス

マイクロサービス アーキテクチャ スタイルの論理図。

この図は、個別の機能レイヤーに編成された分散マイクロサービス アーキテクチャを示しています。 左側では、クライアント アプリケーションと外部システムは、集中型 API ゲートウェイを経由する要求を開始します。これは、システム全体の単一のエントリ ポイントとルーティング メカニズムとして機能します。 API ゲートウェイは、特定のビジネス機能をカプセル化するドメイン サービス、ドメイン サービス間の相互作用を調整するコンポジション サービス、個別の関数を処理する個々のサービスなど、複数のサービスの種類を含む適切なマイクロサービス レイヤーに要求を送信します。 各マイクロサービスは、独自の専用データベースを使用してデータの自律性を維持します。 この図は、各サービスの特定のデータ要件に合わせて調整された SQL データベースと NoSQL データベースの両方を使用したポリグロット永続化アプローチを示しています。 マイクロサービスは、メッセージ指向ミドルウェアを介して非同期的に通信します。 この方法では、パブリッシュ/サブスクライブ パターンとイベント ドリブンの相互作用によって疎結合が可能になります。 3 つの基本インフラストラクチャ レイヤーは、この分散アーキテクチャをサポートします。監視システムは、サービス境界を越えて包括的な監視、ログ記録、分散トレースを提供します。 管理プラットフォームとオーケストレーション プラットフォームは、自動デプロイ、スケーリング、サービス検出を処理します。 DevOps ツールチェーンを使用すると、独立したサービス デプロイの継続的インテグレーション、テスト、配信パイプラインを実現できます。

マイクロサービス アーキテクチャは、アプリケーションを小規模で自律的なサービスのコレクションに分解します。 各サービスは、境界付きコンテキスト内に 1 つのビジネス機能を実装し、独自のデータ ストレージを持つ自己完結型です。 サービスは明確に定義された API を介して通信し、個別に開発、デプロイ、スケーリングできます。

マイクロサービスを使用すると、チームは自律的に作業し、リリース速度の高い頻繁な更新をサポートできます。 このアーキテクチャは、頻繁な変更とイノベーションを必要とする複雑なドメインに適しています。 ただし、サービスの検出、データの一貫性、分散システム管理などの領域では、非常に複雑になります。 成功するには、成熟した開発と DevOps プラクティスが必要です。これにより、高度な技術的機能を持つ組織に適しています。

イベントドリブン アーキテクチャ

イベント ドリブン アーキテクチャ スタイルの図。

この図は、イベント ドリブン アーキテクチャに対する分離された非同期通信パターンの基礎を示しています。 複数のイベント プロデューサーが独立して動作します。 ビジネス活動、ユーザーのやり取り、またはシステム状態の変化に基づいて生成されたイベントストリームは、ダウンストリームコンシューマーに関する知識がなくても生成されます。 プロデューサーは、インテリジェント ブローカーとして機能する一元化されたイベント インジェスト システムにイベントをフィードします。 ブローカーは、イベントを受け取り、検証し、永続化し、アーキテクチャ全体に確実に分散します。 イベント インジェスト コンポーネントは、重要な分離ポイントとして機能します。 これにより、プロデューサーはコンシューマーから分離されたままになりますが、イベントの配信、順序付け、持続性に関する保証が提供されます。 この中央ハブから、イベントはファンアウト パターンを介して、図の右側に配置された複数の独立したイベント コンシューマーに配布されます。 各コンシューマーは、ドメインの責任に関連する特定のイベントの種類をサブスクライブする個別のビジネス機能またはサービスを表します。 コンシューマーはイベントを非同期的かつ並列に処理し、疎結合を維持しながらシステムを水平方向にスケーリングできるようにします。 このアーキテクチャ パターンでは、プロデューサーとコンシューマーの間の直接的な依存関係が削除されます。 これにより、イベント ブローカーのバッファリングと再試行の機能を通じてシステムの回復性を維持しながら、各コンポーネントを個別に進化、スケーリング、デプロイできます。

イベント ドリブン アーキテクチャ では、イベント プロデューサーがイベントのストリームを生成し、イベント コンシューマーがそれらのイベントにほぼリアルタイムで応答するパブリッシュ/サブスクライブ モデルを使用します。 プロデューサーとコンシューマーは互いに切り離され、イベント チャネルまたはブローカーを介した通信が行われます。 このアーキテクチャでは、単純なイベント処理と複雑なイベント パターン分析の両方がサポートされています。

イベント ドリブン アーキテクチャは、待機時間を最小限に抑えたリアルタイム処理を必要とするシナリオで優れています。 たとえば、大量のストリーミング データを処理する必要がある IoT ソリューション、金融取引システム、アプリケーションなどがあります。 イベントドリブン アーキテクチャは、優れたスケーラビリティと障害の分離を提供しますが、分散コンポーネント間での確実な配信、イベントの順序付け、最終的な一貫性に関する課題が発生します。

ビッグ データ

ビッグ データ アーキテクチャ スタイルの論理図。

この図は、さまざまなデータ速度と分析要件を処理する 2 つの補完的な処理パイプラインを備えた包括的なビッグ データ アーキテクチャを示しています。 バッチ処理パイプラインは、スケーラブルなデータ ストレージ システム (通常はデータ レイク)、または大量の構造化データ、半構造化データ、非構造化データを格納できる分散ファイル システムにフィードする多様なデータ ソースから始まります。 バッチ処理コンポーネントは、履歴データに対して大規模な変換、集計、および分析計算を実行します。 スケジュールされた間隔で、または十分なデータが蓄積されたときに動作します。 バッチ処理の結果は、2 つの経路を通って流れ、すぐに使用できるように分析システムとレポート システムに直接送られ、処理されたデータが複雑なクエリと履歴分析用に最適化された形式で保持される分析データ ストアに送られます。 同時に、リアルタイム処理パイプラインは、IoT デバイス、Web アプリケーション、トランザクション システムなどのソースからの高速データ ストリームを処理するリアルタイム メッセージ インジェスト システムを介してストリーミング データをキャプチャします。 ストリーム処理コンポーネントは、このデータをモーションで分析し、リアルタイムの集計、フィルター処理、パターン検出を実行して、すぐに分析情報を生成します。 リアルタイムの結果も 2 つの経路に従い、インスタント ダッシュボードとアラートの分析とレポートに直接フィードし、同じ分析データ ストアに送り込んで、履歴データと現在のデータを組み合わせた統一されたビューを作成します。 オーケストレーションレイヤーは両方のパイプラインにまたがる。 複雑なワークフローを調整し、バッチ ジョブとストリーミング ジョブ間の依存関係を管理し、処理タスクをスケジュールし、アーキテクチャ全体でデータの一貫性を確保します。 このオーケストレーションを使用すると、バッチ処理とリアルタイム処理の両方が同じデータセットで動作できるラムダ アーキテクチャを作成でき、包括的な履歴分析と即時の運用インテリジェンスの両方が提供されます。

ビッグ データ アーキテクチャは、従来のデータベース システムでは大きすぎるデータや複雑なデータの取り込み、処理、分析を処理します。 これらのアーキテクチャには、通常、データ ストレージ (データ レイクなど) のコンポーネント、履歴分析のバッチ処理、リアルタイム分析情報のストリーム処理、レポートと視覚化のための分析データ ストアが含まれます。

ビッグ データ アーキテクチャは、大規模なデータセットから分析情報を抽出したり、機械学習を使用して予測分析をサポートしたり、IoT デバイスからのリアルタイム ストリーミング データを処理したりする必要がある組織にとって不可欠です。 最新の実装では、多くの場合、Microsoft Fabric などのマネージド サービスを使用して、ビッグ データ ソリューションの構築と保守の複雑さを簡素化します。

ビッグ コンピューティング

大規模なコンピューティング アーキテクチャ スタイルを示す図。

この図は、ハイ パフォーマンス コンピューティング ワークロード用に設計された高度なジョブの分散と運用システムを示しています。 エントリ ポイントでは、クライアント アプリケーションは、受信した作業要求のバッファーと取り込みメカニズムとして機能するジョブ キュー インターフェイスを介して、計算量の多いジョブを送信します。 ジョブは、ジョブの特性、リソース要件、および計算依存関係の分析を担当する、システムのインテリジェントな頭脳として機能する一元化されたスケジューラまたはコーディネーター コンポーネントに流れます。 スケジューラは、ジョブの分解、リソース割り当ての計画、使用可能なコンピューティング リソースとタスクの相互依存関係に基づくワークロードの最適化など、重要な機能を実行します。 この中央の調整ポイントから、スケジューラは、各ジョブの計算特性に基づいて、2 つの異なる操作経路に沿って作業をインテリジェントにルーティングします。 最初の経路は、処理ユニット間の通信を必要とせずに個々のタスクを独立して実行できる、驚異的な並列ワークロード用に設計された並列タスク処理環境に作業を指示します。 これらの並列タスクは、数百または数千のコアに同時に分散され、各コア処理の個別の作業単位が分離されます。 2 番目の経路は、頻繁なプロセス間通信、共有メモリ アクセス、または同期された操作パターンを必要とする密結合タスクを処理します。 これらの密結合ワークロードでは、通常、InfiniBand やリモート ダイレクト メモリ アクセス (RDMA) ネットワークなどの高速相互接続を使用して、処理ノード間の高速データ交換を可能にします。 スケジューラは、両方の操作環境を継続的に監視し、リソースの割り当てを管理し、フォールト トレランスを処理し、システム容量、ジョブの優先順位、および完了要件に基づいて作業の分散を動的に調整することでパフォーマンスを最適化します。 二つのアプローチにより、アーキテクチャは、コンピューティング インフラストラクチャ全体でリソースの使用を最大化しながら、多様なコンピューティング ワークロードを効率的に処理できます。

大規模なコンピューティング アーキテクチャでは、計算負荷の高い操作に数百または数千のコアを必要とする大規模なワークロードがサポートされます。 作業は、多数のコアで同時に実行される個別のタスクに分割でき、各タスクは入力を受け取り、処理し、出力を生成します。 タスクは、独立した(ほとんど通信を必要としない並列処理)か、高速通信を必要とする密結合のいずれかとすることができます。

ビッグ コンピューティングは、シミュレーション、財務リスク モデリング、科学コンピューティング、エンジニアリング ストレス分析、3D レンダリングに不可欠です。 Azure には、マネージド ビッグ コンピューティング ワークロード用の Azure Batch や、従来のクラスター管理用の HPC Pack などのオプションが用意されています。 これらのアーキテクチャでは、オンデマンドで容量をバーストし、必要に応じて数千個のコアにスケーリングできます。

制約としてのアーキテクチャ スタイル

アーキテクチャ スタイルでは、表示できる要素のセットや、それらの要素間の許可されたリレーションシップなど、デザインに制約が設けられています。 制約は、選択肢のユニバースを制限することで、アーキテクチャの "形状" を導きます。 アーキテクチャが特定のスタイルの制約に準拠している場合、特定の望ましいプロパティが出現します。

たとえば、マイクロサービスの制約には次のようなものがあります。

  • サービスは 1 つの責任を表します。
  • すべてのサービスは、他のサービスとは独立しています。
  • データは、データを所有するサービスに対してプライベートです。 サービスはデータを共有しません。

これらの制約に従うと、次のアクションを実行できるシステムが得られる。

  • サービスを個別にデプロイします。
  • 障害を分離する。
  • より頻繁に更新をプッシュします。
  • 新しいテクノロジをより簡単にアプリケーションに導入します。

各アーキテクチャ スタイルには、独自のトレードオフがあります。 アーキテクチャ スタイルを選択する前に、基になる原則と制約を理解することが不可欠です。 その理解がなければ、その完全な利点を実現することなく、表面的にスタイルに準拠するデザインを作成するリスクがあります。 実装する方法よりも、特定のスタイルを選択する理由に重点を置きます。 実用的である。 アーキテクチャの純度を追いかけるよりも、制約を緩和する方が良い場合があります。

理想的には、情報に基づくワークロード利害関係者からの入力を使用してアーキテクチャ スタイルを選択する必要があります。 ワークロード チームは、まず、解決している問題の性質を特定する必要があります。 その後、主要なビジネス ドライバーと対応するアーキテクチャ特性 ( 非機能要件とも呼ばれます) を定義し、優先順位を付ける必要があります。 たとえば、市場投入までの時間が重要な場合、チームは、迅速なデプロイを可能にするために、保守性、テスト容易性、信頼性に優先順位を付ける可能性があります。 チームに予算の制約が厳しい場合は、実現可能性とシンプルさが優先される可能性があります。 アーキテクチャ スタイルの選択と維持は、1 回限りではありません。 継続的な測定、検証、および絞り込みが必要です。 アーキテクチャの方向を後で変更するとコストがかかる可能性があるため、長期的な効率をサポートし、リスクを軽減するために、より多くの労力を事前に投資する価値があります。

次の表は、各スタイルが依存関係を管理する方法と、各スタイルに最適なドメインの種類をまとめたものです。

アーキテクチャ のスタイル 依存関係の管理 ドメインの種類
n 層 サブネットごとに分割された横方向の層 従来のビジネス ドメイン。 更新の頻度が低い。
Web-Queue-Worker 非同期メッセージングによって切り離されたフロントエンド ジョブとバックエンド ジョブ。 リソースを集中的に使用するタスクがある比較的単純なドメイン。
マイクロサービス API を介して相互に呼び出すサービスを垂直方向 (機能的に) 分解します。 複雑なドメイン。 頻繁な更新。
イベント ドリブン アーキテクチャ プロデューサーまたはコンシューマー。 各サブシステムの独立したビュー。 モノのインターネット (IoT) とリアルタイム システム。
ビッグ データ 巨大なデータセットを小さなチャンクに分割します。 ローカル データセットでの並列処理。 バッチとリアルタイムのデータ分析。 機械学習を使用した予測分析。
ビッグ コンピューティング 何千ものコアへのデータ割り当て。 シミュレーションなどのコンピューティング集中型ドメイン。

課題と利点を検討する

制約によって課題も生まれるため、これらのスタイルのいずれかを採用する際のトレードオフを理解することが重要です。 アーキテクチャ スタイルの利点が、 このサブドメインと有界コンテキストの課題を上回るかどうかを判断します。

アーキテクチャ スタイルを選択するときは、次の種類の課題を考慮してください。

  • 複雑さ: アーキテクチャの複雑さはドメインと一致している必要があります。 単純すぎると、依存関係が十分に管理されず、構造が分解される 大きな泥のボールが発生する可能性があります。

  • 非同期メッセージングと最終的な整合性: 非同期メッセージングは、メッセージを再試行できるため、サービスを分離し、信頼性を向上させるために使用されます。 また、スケーラビリティも向上します。 ただし、非同期メッセージングでは、最終的な整合性と重複するメッセージの可能性を処理する上で課題も生じます。

  • サービス間通信: アプリケーションを別のサービスに分解すると、通信のオーバーヘッドが増加する可能性があります。 マイクロサービス アーキテクチャでは、多くの場合、このオーバーヘッドによって待機時間の問題やネットワークの輻輳が発生します。

  • 管理: アプリケーションの管理には、監視、更新プログラムの展開、運用の正常性の維持などのタスクが含まれます。

次のステップ