アーキテクチャ スタイルArchitecture styles

"アーキテクチャ スタイル" とは、特定の性質を持つアーキテクチャのグループです。An architecture style is a family of architectures that share certain characteristics. たとえば、n 層is a common architecture style. More recently, microservice architecturesがよく使用されるようになりました。For example, N-tier is a common architecture style. More recently, microservice architectures have started to gain favor. アーキテクチャ スタイルによって特定のテクノロジの使用が必須となることはありませんが、一部のテクノロジは特定のアーキテクチャに適しています。Architecture styles don't require the use of particular technologies, but some technologies are well-suited for certain architectures. たとえば、コンテナーはマイクロサービスにとって最適なソリューションです。For example, containers are a natural fit for microservices.

クラウド アプリケーションで一般的に見られる一連のアーキテクチャ スタイルを特定しました。We have identified a set of architecture styles that are commonly found in cloud applications. 各スタイルの説明には次の内容が含まれています。The article for each style includes:

  • スタイルの説明と論理図。A description and logical diagram of the style.
  • そのスタイルの選択が推奨されるケース。Recommendations for when to choose this style.
  • 利点、課題、およびベスト プラクティス。Benefits, challenges, and best practices.
  • 関連する Azure サービスを使用する推奨デプロイ。A recommended deployment using relevant Azure services.

スタイルのクイック ツアーA quick tour of the styles

このセクションでは、特定したアーキテクチャ スタイルのクイック ツアーを行い、それぞれを使用する場合の考慮事項の要旨も説明します。This section gives a quick tour of the architecture styles that we've identified, along with some high-level considerations for their use. 詳しくはリンク先のトピックをご覧ください。Read more details in the linked topics.

n 層N-tier

n 層 は、エンタープライズ アプリケーション用の従来のアーキテクチャです。N-tier is a traditional architecture for enterprise applications. 論理的な機能 (プレゼンテーション、ビジネス ロジック、データ アクセスなど) を実行する "レイヤー" にアプリケーションを分割して依存関係を管理します。Dependencies are managed by dividing the application into layers that perform logical functions, such as presentation, business logic, and data access. レイヤーが呼び出すことができるのは、その下に配置されているレイヤーのみです。A layer can only call into layers that sit below it. ただし、このような横方向の階層化がデメリットになることもあります。However, this horizontal layering can be a liability. アプリケーションの一部に変更を加えるときに、その他の部分に手を付けることなく行うことが難しい場合があるためです。It can be hard to introduce changes in one part of the application without touching the rest of the application. これにより、頻繁な更新が困難になり、新機能の迅速な追加が妨げられます。That makes frequent updates a challenge, limiting how quickly new features can be added.

n 層は、階層化アーキテクチャを既に使用している既存アプリケーションの移行に最適です。N-tier is a natural fit for migrating existing applications that already use a layered architecture. この理由から、n 層は、サービスとしてのインフラストラクチャ (IaaS) ソリューション、または IaaS と管理対象サービスの両方を使用するアプリケーションで最もよく見られます。For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.

Web キューワーカーWeb-Queue-Worker

純粋な PaaS ソリューションの場合は、 Web キューワーカー アーキテクチャを検討できます。For a purely PaaS solution, consider a Web-Queue-Worker architecture. このスタイルでは、アプリケーションには HTTP 要求を処理する Web フロント エンドと、CPU 集中型タスクまたは実行時間の長い操作を行うバックエンド ワーカーがあります。In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations. フロント エンドは、非同期のメッセージ キューを介してワーカーと通信します。The front end communicates to the worker through an asynchronous message queue.

Web キューワーカーは、リソース集中型タスクを伴う比較的単純なドメインに適しています。Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. n 層と同様にわかりやすいアーキテクチャです。Like N-tier, the architecture is easy to understand. 管理対象サービスを使用することで、デプロイと操作が簡単になります。The use of managed services simplifies deployment and operations. ただし、複雑なドメインでは依存関係の管理が難しくなることがあります。But with complex domains, it can be hard to manage dependencies. フロント エンドおよびワーカーが、管理と更新の無図解しい大きなモノリシック コンポーネントになりやすいためです。The front end and the worker can easily become large, monolithic components that are hard to maintain and update. n 層の場合と同じく、これにより頻繁な更新が減少し、革新が制限されます。As with N-tier, this can reduce the frequency of updates and limit innovation.

マイクロサービスMicroservices

アプリケーションのドメインがさらに複雑な場合には、 マイクロサービス アーキテクチャへの移行を検討してください。If your application has a more complex domain, consider moving to a Microservices architecture. マイクロサービス アプリケーションは、小規模の独立したサービス多数で構成されます。A microservices application is composed of many small, independent services. 各サービスが 1 つのビジネス機能を実装します。Each service implements a single business capability. サービス同士はゆるやかに結び付いており、API コントラクトを介してやりとりします。Services are loosely coupled, communicating through API contracts.

各サービスは小規模の専門開発チームによって構築できます。Each service can be built by a small, focused development team. 個々 のサービスをデプロイする際にチーム間での調整があまり必要ないため、頻繁な更新が促進されます。Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates. マイクロサービス アーキテクチャは、n 層または Web キューワーカーに比べて構築や管理が複雑です。A microservice architecture is more complex to build and manage than either N-tier or web-queue-worker. 成熟した開発技術および DevOps カルチャが必要です。It requires a mature development and DevOps culture. ただし、適切に行えば、このスタイルによってリリースにかかる時間が短縮され、革新が進み、回復力のあるアーキテクチャが実現します。But done right, this style can lead to higher release velocity, faster innovation, and a more resilient architecture.

イベントドリブン アーキテクチャEvent-driven architecture

イベントドリブン アーキテクチャ は、プロデューサーがイベントをパブリッシュし、コンシューマーがサブスクライブするパブリッシュ - サブスクライブ (pub-sub) モデルを使用します。Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. プロデューサーはコンシューマーとは独立しており、各コンシューマーは互いに独立しています。The producers are independent from the consumers, and consumers are independent from each other.

イベントドリブン アーキテクチャは、ごく短い待機時間で大容量のデータを取り込んで処理するアプリケーション (IoT ソリューションなど) について検討してください。Consider an event-driven architecture for applications that ingest and process a large volume of data with very low latency, such as IoT solutions. このスタイルは、さまざまサブシステムが同じイベント データに対してさまざまな種類の処理を実行する必要がある場合にも役立ちます。The style is also useful when different subsystems must perform different types of processing on the same event data.

ビッグ データ、ビッグ コンピューティングBig Data, Big Compute

ビッグ データ および ビッグ コンピューティング は、特定のプロファイルと一致するワークロードに特化したアーキテクチャ スタイルです。Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. ビッグ データでは、きわめて大きなデータセットをチャンクに分割して、分析やレポート作成のためにセット全体に並列処理を実行します。Big data divides a very large dataset into chunks, performing parallel processing across the entire set, for analysis and reporting. ビッグ コンピューティングはハイ パフォーマンス コンピューティング (HPC) とも呼ばれ、多数 (数千単位) のコアに対して並列コンピューティングを行います。Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. ドメインには、シミュレーション、モデリング、および 3-D レンダリングが含まれます。Domains include simulations, modeling, and 3-D rendering.

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

アーキテクチャ スタイルによって設計 (含めることができる要素のセットや、それらの要素間で許可される関係など) が制約されます。An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. 制約によって、選択肢の範囲が狭められ、アーキテクチャの "シェイプ" が決まります。Constraints guide the "shape" of an architecture by restricting the universe of choices. アーキテクチャがあるスタイルの制約に準拠すると、特定の望ましいプロパティが出現します。When an architecture conforms to the constraints of a particular style, certain desirable properties emerge.

たとえば、マイクロサービスの制約は次のとおりです。For example, the constraints in microservices include:

  • 1 つのサービスが 1 つの役割を表します。A service represents a single responsibility.
  • すべてのサービスは互いに独立しています。Every service is independent of the others.
  • データはそれを所有するサービス専用です。Data is private to the service that owns it. サービスは、データを共有しません。Services do not share data.

このような制約に準拠することで出現するシステムでは、サービスを個別にデプロイでき、障害が分離され、頻繁な更新が可能になります。また、新しいテクノロジをアプリケーションに容易に導入できます。By adhering to these constraints, what emerges is a system where services can be deployed independently, faults are isolated, frequent updates are possible, and it's easy to introduce new technologies into the application.

アーキテクチャ スタイルを選択する前に、そのスタイルの基本原則と制約を理解してください。Before choosing an architecture style, make sure that you understand the underlying principles and constraints of that style. そうしないと、表面的なレベルでスタイルに準拠した設計ができあがり、そのスタイルの潜在力すべてを引き出すことはできません。Otherwise, you can end up with a design that conforms to the style at a superficial level, but does not achieve the full potential of that style. 実際的に対処することも重要です。It's also important to be pragmatic. アーキテクチャの正しい形にこだわるよりも、場合によっては制約を緩和する方が適しています。Sometimes it's better to relax a constraint, rather than insist on architectural purity.

次の表には、各スタイルでの依存関係の管理方法と各スタイルに最適なドメインの種類をまとめています。The following table summarizes how each style manages dependencies, and the types of domain that are best suited for each.

アーキテクチャ スタイルArchitecture style 依存関係の管理Dependency management ドメインの種類Domain type
n 層N-tier サブネットごとに分割された横方向の層Horizontal tiers divided by subnet 従来のビジネス ドメイン。Traditional business domain. 更新の頻度は低いです。Frequency of updates is low.
Web キューワーカーWeb-Queue-Worker 非同期メッセージングによって分離されているフロント ジョブとバックエンド ジョブ。Front and backend jobs, decoupled by async messaging. ある程度のリソース集中型タスクを含む比較的単純なドメイン。Relatively simple domain with some resource intensive tasks.
マイクロサービスMicroservices API を介して互いに呼び出しを行う、垂直方向 (機能別) に分解されたサービス。Vertically (functionally) decomposed services that call each other through APIs. 複雑なドメイン。Complicated domain. 頻繁に更新されます。Frequent updates.
イベントドリブン アーキテクチャ。Event-driven architecture. プロデューサー/コンシューマー。Producer/consumer. サブシステムごとに独立したビュー。Independent view per sub-system. IoT およびリアルタイムのシステムIoT and real-time systems
ビッグ データBig data 大きなデータセットを小さなチャンクに分割します。Divide a huge dataset into small chunks. ローカル データセットを並列処理します。Parallel processing on local datasets. バッチおよびリアルタイムのデータ分析。Batch and real-time data analysis. ML を使用した予測分析。Predictive analysis using ML.
ビッグ コンピューティングBig compute 数千のコアへのデータの割り当て。Data allocation to thousands of cores. シミュレーションなどコンピューティング集中型ドメイン。Compute intensive domains such as simulation.

課題と利点の検討Consider challenges and benefits

制約によって課題も生じます。これらのうちどのスタイルを採用する場合でもトレードオフを理解することが重要です。Constraints also create challenges, so it's important to understand the trade-offs when adopting any of these styles. "このサブドメインと制限付きコンテキストについて"、アーキテクチャ スタイルの利点が課題を上回るようにしてください。Do the benefits of the architecture style outweigh the challenges, for this subdomain and bounded context.

アーキテクチャ スタイルを選択するときに検討する必要がある課題の一部を次に示します。Here are some of the types of challenges to consider when selecting an architecture style:

  • 複雑さComplexity. アーキテクチャの複雑さがドメインに対して正当かどうか。Is the complexity of the architecture justified for your domain? 逆に、ドメインに対してスタイルが単純すぎないか。Conversely, is the style too simplistic for your domain? この場合は、"大きな泥だんご" ができあがるリスクがあります。アーキテクチャが依存関係を適切に管理できないためです。In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.

  • 非同期メッセージングと最終的な一貫性Asynchronous messaging and eventual consistency. 非同期メッセージングを使用すると、サービスを切り離すことができ、信頼性 (メッセージは再試行可能) とスケーラビリティを向上できます。Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. ただし、これにも、always-once セマンティクスや最終的な一貫性などの課題があります。However, this also creates challenges such as always-once semantics and eventual consistency.

  • サービス間の通信Inter-service communication. アプリケーションを個々のサービスに分割するため、サービス間の通信によって、許容できない待ち時間が発生したり、ネットワークの混雑が生じたりするリスクがあります (たとえばマイクロサービス アーキテクチャ)。As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).

  • 管理のしやすさManageability. アプリケーションの管理、監視、更新のデプロイなどがどれくらい困難か。How hard is it to manage the application, monitor, deploy updates, and so on?