アーキテクチャのアプローチArchitecture approaches

エンタープライズ アプリを設計するための既存のアプローチを理解することは、サーバーレスが果たす役割を明らかにするのに役立ちます。Understanding existing approaches to architecting enterprise apps helps clarify the role played by serverless. 数十年にわたるソフトウェア開発で進化した多くのアプローチとパターンがあり、それぞれに固有の長所と短所があります。There are many approaches and patterns that evolved over decades of software development, and all have their own pros and cons. 多くの場合、最終的な解決策は 1 つのアプローチに決定することではなく、複数のアプローチを統合することです。In many cases, the ultimate solution may not involve deciding on a single approach but may integrate several approaches. 移行シナリオでは、ハイブリッド アプローチを使用して 1 つのアーキテクチャ アプローチから別のアプローチに切り替えることがよくあります。Migration scenarios often involve shifting from one architecture approach to another through a hybrid approach.

この章では、エンタープライズ アプリケーションの論理アーキテクチャと物理アーキテクチャの両方の概要について説明します。This chapter provides an overview of both logical and physical architecture patterns for enterprise applications.

アーキテクチャのパターンArchitecture patterns

最新のビジネス アプリケーションは、さまざまなアーキテクチャ パターンに従います。Modern business applications follow a variety of architecture patterns. このセクションでは、一般的なパターンの調査について説明します。This section represents a survey of common patterns. ここに記載されているパターンは、必ずしもすべてがベスト プラクティスではありませんが、さまざまなアプローチを示しています。The patterns listed here aren't necessarily all best practices, but illustrate different approaches.

詳細については、「Azure アプリケーション アーキテクチャ ガイド」を参照してください。For more information, see Azure application architecture guide.

モノリスMonoliths

多くのビジネス アプリケーションは、モノリス パターンに従います。Many business applications follow a monolith pattern. レガシ アプリケーションは、多くの場合、モノリスとして実装されています。Legacy applications are often implemented as monoliths. モノリス パターンでは、すべてのアプリケーションの問題が単一の展開に含まれています。In the monolith pattern, all application concerns are contained in a single deployment. ユーザー インターフェイスからデータベースの呼び出しまで、すべてが同じコードベースに含まれています。Everything from user interface to database calls is included in the same codebase.

モノリス アーキテクチャ

モノリス アプローチにはいくつかの利点があります。There are several advantages to the monolith approach. 多くの場合、単一のコード ベースを開いて作業を開始するのは簡単です。It's often easy to pull down a single code base and start working. 準備期間は短くなる可能性があり、テスト環境の作成は新しいコピーを提供するのと同じように簡単です。Ramp up time may be less, and creating test environments is as simple as providing a new copy. モノリスは、複数のコンポーネントとアプリケーションを含むように設計されている場合があります。The monolith may be designed to include multiple components and applications.

残念ながら、モノリス パターンは大規模に破綻する傾向があります。Unfortunately, the monolith pattern tends to break down at scale. モノリス アプローチの主な欠点は次のとおりです。Major disadvantages of the monolith approach include:

  • 同じコード ベースで並行して作業することは困難です。Difficult to work in parallel in the same code base.
  • 変更を行った場合、どれだけ些細な変更であったとしても、アプリケーション全体の新しいバージョンを展開する必要があります。Any change, no matter how trivial, requires deploying a new version of the entire application.
  • リファクタリングを行うと、アプリケーション全体に影響を及ぼす可能性があります。Refactoring potentially impacts the entire application.
  • 多くの場合、スケーリングするための唯一の解決策は、リソースを大量に消費するモノリスの複数のコピーを作成することです。Often the only solution to scale is to create multiple, resource-intensive copies of the monolith.
  • システムの拡大や他のシステムの獲得に伴い、統合が困難な場合があります。As systems expand or other systems are acquired, integration can be difficult.
  • モノリス全体を構成する必要があるため、テストが困難な場合があります。It may be difficult to test due to the need to configure the entire monolith.
  • コードを再利用することは容易でなく、他のアプリで独自のコードのコピーが作成されることがよくあります。Code reuse is challenging and often other apps end up having their own copies of code.

多くの企業は、モノリス アプリケーションを移行すると同時にもっと使いやすいパターンにリファクタリングする機会として、クラウドに注目しています。Many businesses look to the cloud as an opportunity to migrate monolith applications and at the same time refactor them to more usable patterns. 個々のアプリケーションとコンポーネントを分割して個別に管理、展開、およびスケーリングできるようにするのが一般的です。It's common to break out the individual applications and components to allow them to be maintained, deployed, and scaled separately.

N 層アプリケーションN-Layer applications

N 層アプリケーションでは、アプリケーション ロジックを特定のレイヤーに分割します。N-layer application partition application logic into specific layers. 最も一般的なレイヤーは次のとおりです。The most common layers include:

  • ユーザー インターフェイスUser interface
  • ビジネス ロジックBusiness logic
  • データ アクセスData access

その他のレイヤーには、ミドルウェア、バッチ処理、API などがあります。Other layers may include middleware, batch processing, and API. 重要なこととして、レイヤーは論理的なものである点に注意してください。It's important to note the layers are logical. これらは分離して開発されますが、すべて同じターゲット プラットフォームに展開される可能性があります。Although they're developed in isolation, they may all be deployed to the same target platform.

N 層アーキテクチャ

N 層アプローチには、次のようないくつかの利点があります。There are several advantages to the N-Layer approach, including:

  • リファクタリングはレイヤーに分離されます。Refactoring is isolated to a layer.
  • チームは別々のレイヤーを個別にビルド、テスト、展開、維持できます。Teams can independently build, test, deploy, and maintain separate layers.
  • レイヤーをスワップ アウトすることができます。たとえばデータ レイヤーから、UI レイヤーを変更することなく複数のデータベースにアクセスできます。Layers can be swapped out, for example the data layer may access multiple databases without requiring changes to the UI layer.

サーバーレスを使用して 1 つまたは複数のレイヤーを実装できます。Serverless may be used to implement one or more layers.

マイクロサービスMicroservices

マイクロサービス アーキテクチャには、次のような一般的な特性があります。Microservices architectures contain common characteristics that include:

  • アプリケーションは複数の小さいサービスで構成されています。Applications are composed of several small services.
  • 各サービスは独自のプロセスで実行されます。Each service runs in its own process.
  • サービスはビジネス ドメインに合わせて調整されます。Services are aligned around business domains.
  • サービス間の通信は軽量の API を介して行われ、通常はトランスポートとして HTTP が使用されます。Services communicate over lightweight APIs, typically using HTTP as the transport.
  • サービスは個別に展開およびアップグレードできます。Services can be deployed and upgraded independently.
  • サービスは 1 つのデータ ストアに依存していません。Services aren't dependent on a single data store.
  • システムはエラーを考慮して設計されており、特定のサービスにエラーが発生した場合でもアプリを実行できます。The system is designed with failure in mind, and the app may still run even when certain services fail.

マイクロサービスは、他のアーキテクチャ アプローチと相互に排他的である必要はありません。Microservices don't have to be mutually exclusive to other architecture approaches. たとえば、N 層アーキテクチャでは、中間層にマイクロサービスを使用できます。For example, an N-Tier architecture may use microservices for the middle tier. また、IIS ホスト上の仮想ディレクトリからコンテナーまで、さまざまな方法でマイクロサービスを実装することが可能です。It's also possible to implement microservices in a variety of ways, from virtual directories on IIS hosts to containers. マイクロサービスの特性は、サーバーレス実装に特に適しています。The characteristics of microservices make them especially ideal for serverless implementations.

マイクロサービス アーキテクチャ

マイクロサービス アーキテクチャの長所は次のとおりです。The pros of microservices architectures include:

  • リファクタリングは、多くの場合、1 つのサービスに分離されます。Refactoring is often isolated to a single service.
  • サービスは互いに独立してアップグレードできます。Services can be upgraded independently of each other.
  • 回復性と弾力性は、個々のサービスの需要に合わせて調整できます。Resiliency and elasticity can be tuned to the demands of individual services.
  • 開発は、異なるチームやプラットフォーム間で並行して行うことができます。Development can happen in parallel across disparate teams and platforms.
  • 分離されたサービスの包括的なテストを作成する方が簡単です。It's easier to write comprehensive tests for isolated services.

マイクロサービスには、次のような固有の課題があります。Microservices come with their own challenges, including:

  • 使用可能なサービスとその呼び出し方法の決定。Determining what services are available and how to call them.
  • サービスのライフサイクルの管理。Managing the lifecycle of services.
  • サービスがアプリケーション全体にどのように適合するかの理解。Understanding how services fit together in the overall application.
  • 異なるサービス間で行われる呼び出しの完全なシステム テスト。Full system testing of calls made across disparate services.

最終的には、これらすべての課題に対処するための解決策があります。これには、後で説明するサーバーレスの利点を活用することが含まれます。Ultimately there are solutions to address all of these challenges, including tapping into the benefits of serverless that are discussed later.