N 層アーキテクチャとは何か
N 層アーキテクチャでは、アプリケーションは論理レイヤーと物理層に分離されます。 N はアプリケーションが分離される物理層の数を表し、通常は層の数と相互に関連付けられています。 2 層アーキテクチャ (クライアント/サーバー) や 5 層アーキテクチャを使用することも可能ですが、層の数を 4 以下にすることが一般的であり、多くの場合最善です。
何がレイヤーと層を構成しているかについて説明しましょう。
レイヤーとは何か
レイヤーは、アプリケーションを構成するアプリケーション コードを論理的に分離します。 各レイヤーには、ユーザーからの要求の処理、ビジネス ロジックの実行、データの格納の処理などの特定の役割があります。
アプリケーションをこれらの論理レイヤーに分離することで、各レイヤーを別々に扱うことができます。 この分離により、アプリケーションのコンポーネントがモジュール化され、アプリケーションの管理が簡単になります。 アプリケーションを役割ごとに最適化できます。 Web 要求を処理するレイヤーでは、Web 要求の処理という主要タスクに重点的に取り組みます。 データの格納やビジネス ロジックの実行には関与しません。 逆に、データ アクセス レイヤーでは、データ ストアへの通信を最適化することに焦点が当てられ、ユーザーにデータを表示する方法の詳細は無視されます。 このフォーカスを特定の機能に制限する概念は、"関心の分離" と呼ばれます。
一般的な N 層アーキテクチャのレイヤーを次の図に示します。 各レイヤーでは、アプリケーションの 1 つの側面が処理されます。 ビジネス レイヤーでは、ユーザー インターフェイス レイヤーとデータ アクセス レイヤー間の通信が管理されます。
層とは何か
層は、アプリケーションのパーツの独立したコンピューティング リソースへの物理的な分離を表します。 一般に、各物理層では、アプリケーションの 1 つの論理レイヤーが実行されます。
アーキテクチャを物理層に分割することには、いくつかのメリットがあります。
- 層ごとにリソースを追加することで、アプリケーションのコンポーネントを個別にスケーリングできます。
- 障害が発生したリソースを検出し、正常なシステムに要求をリダイレクトする負荷分散を追加することで、アプリケーションの回復性を向上させることができます。
- 各層の間のネットワーク通信を制限し、必要なアクセスのみを許可することによって、アプリケーションのセキュリティを強化できます。
このアーキテクチャでは、階層間の通信をトップダウン形式にする必要があります。 各層では、その下の層への通信のみが可能で、通常は層をスキップすることはできません。 この設計では、層の公開された領域を制限することで、セキュリティが向上します。
3 層アーキテクチャ
すべての N 層アーキテクチャの中で、最も一般的なのは 3 層アーキテクチャです。 各レイヤーと各層の役割と名前は、アプリケーションと会社によって異なりますが、典型的な 3 層のアプリケーションには、プレゼンテーション層、アプリケーション層または中間層、およびデータ層があります。 このアーキテクチャは、最も一般的な N 層のスタイルです。 このモジュールの残りの部分では、各層がアプリケーションの単一のレイヤーを実行する 3 層モデルを参照し、それらを同義的に層と呼びます。
プレゼンテーション層
プレゼンテーション層では、通常はユーザーの要求が促進されます。 これらの要求は、Web ページにアクセスするユーザーや、公開されている API 経由でのアプリケーションへのパブリック アクセスであることが考えられます。 この層の焦点は、ユーザー エクスペリエンスにあります。 直感的なインターフェイスなどを提供し、エンド ユーザーとアプリケーションの間でセキュリティで保護された通信が行われるようにします。
この層では、ユーザーへの表示方法を除いて、データ自体に関心はありません。 通常、この層ではデータ処理やデータ アクセスは発生しません。 それは下の層の役割です。
アプリケーション層
アプリケーション層 (しばしば中間層とも呼ばれます) では、通常はアプリケーションのビジネス ロジックの処理にフォーカスします。 これには、顧客の注文の処理や出荷の追跡、受け取った資材に基づく在庫の更新などが考えられます。 この層には、データ層に対して作成、読み取り、更新、削除 (CRUD) アクティビティを行う役割もあります。 これは、外部 API などの依存サービスへの呼び出しに適した場所でもあります。
この層では、ユーザーに対する情報の表示方法にも、データの格納や取得方法にも関心はありません。 フォーカスは、アプリケーションが受信した要求を満たすために必要なビジネス ロジックにあります。
データ層
この層では、フォーカスはデータの格納にあります。 テーブル、ファイル、またはその他のメディアへのデータの格納がこの層の役割です。 この層では、データにアクセスするためのインターフェイス (T-SQL など) が提供されます。 3 層アーキテクチャでは、データ レイヤーがアプリケーション層へのデータ アクセスを提供します。
この層では、ユーザーに対する情報の表示方法にも、データに関するロジックにも焦点が当てられません。 この層でストアド プロシージャが使用される可能性がありますが、データに関するロジックの大部分は上の層で処理される必要があります。
いつ N 層アーキテクチャを使用するか
N 層アーキテクチャとは何かについて説明したので、このスタイルのアーキテクチャをいつ使用するかについて説明しましょう。 次に該当する場合に、N 層アーキテクチャを考慮してください。
- 小規模から中規模の Web アプリケーション。
- 最小限のリファクタリングでオンプレミス アプリケーションを Azure に移行。
- オンプレミス開発者のスキル、能力、経験を使用する。
Web アプリケーションは、このスタイルのアーキテクチャ用の適切なユース ケースです。 このアーキテクチャ スタイルでは複雑さが軽減され、多くの場合 Web アプリケーションに含まれる役割が自然に分離されるため、N 層アーキテクチャがうまく機能する可能性があります。 一般公開されるアプリケーションや、組織によって内部的に使用される基幹業務アプリケーションが考えられます。 小規模なアプリケーションや複雑でないアプリケーションでは、プレゼンテーション層とアプリケーション層が分離されずに結合されている 2 階層 (クライアント/サーバー) アーキテクチャで十分な場合があります。
N 層アーキテクチャは従来のオンプレミス アプリケーションでよく使用されているため、既存のワークロードを Azure に移行するのにとても適しています。 多くの場合、このスタイルのアプリケーションは、最小限のリファクタリングや修正で Azure に移行されるため、初期移行が簡略化されます。 Azure に移行した後、サービスとしてのプラットフォーム (PaaS) サービスを活用して、アプリケーションをさらに改良できます。
これは一般的なアーキテクチャ スタイルであるため、多くの場合、エンジニアは高いレベルの経験と知識を持っています。 このアーキテクチャを選択することで、既存のスキル セットを使用してアプリケーションをデプロイでき、新しいアーキテクチャ パターンを学習する必要はありません。