N 層アーキテクチャ スタイル

N 層アーキテクチャでは、アプリケーションを 論理層 に分割し、物理層します。

レイヤーは責任を分離し、依存関係を管理します。 各レイヤーには、特定の責任があります。 上位レイヤーでは下位レイヤーでサービスを使用できますが、下位レイヤーでは上位レイヤーのサービスを使用できません。

階層は物理的に分離され、個別のマシンで実行されます。 契約上、階層には厳密な通信モデルまたは緩やかな通信モデルを含めることができます。 厳密なモデルでは、要求は隣接する層を 1 つずつ通過する必要があり、その間にどの層もスキップできません。 たとえば、要求は Web アプリケーション ファイアウォール (WAF) から Web 層に移動し、次に中間層 1 に移動して続行します。 これに対し、緩やかなアプローチでは、必要に応じて要求で一部のレベルをスキップできます。 厳密なアプローチでは、待機時間とオーバーヘッドが大きくなります。 柔軟なアプローチは、カップリングが多いため、変更がより困難になります。 同じシステムで両方の方法を組み合わせることもできます。

レベルは、別の層を直接呼び出すか、メッセージ キューを介して 非同期メッセージング パターンを 使用できます。 各レイヤーは独自の層でホストできますが、この方法は必要ありません。 同じ層で複数のレイヤーをホストできます。 階層を物理的に分離すると、スケーラビリティと回復性が向上しますが、追加のネットワーク通信からの待機時間も増えます。

従来の 3 層アプリケーションには、プレゼンテーション層、オプションの中間層、およびデータベース層があります。 より複雑なアプリケーションには、3 つ以上のレベルを含めることができます。 前の図は、機能のさまざまな領域をカプセル化する 2 つの中間層を持つアプリケーションを示しています。

N 層アプリケーションには、 クローズド レイヤー アーキテクチャ または オープン レイヤー アーキテクチャを使用できます。

• 閉じたレイヤー アーキテクチャでは、レイヤーは直ちに次のレイヤーのみを呼び出すことができます。
• オープン レイヤー アーキテクチャでは、レイヤーは、その下の任意のレイヤーを呼び出すことができます。

クローズド レイヤー アーキテクチャでは、レイヤー間の依存関係が制限されます。 ただし、1 つのレイヤーが要求を次のレイヤーに渡すだけの場合、このアーキテクチャによって不要なネットワーク トラフィックが作成される可能性があります。

このアーキテクチャを使用する場合

次のシナリオでは、N 層アーキテクチャを検討してください。

• まだ進化しているアーキテクチャ要件をサポートします。
• 最小限の変更でオンプレミス アプリケーションを Azure に移行します。
• オンプレミス環境とクラウド環境の両方にまたがるアプリケーションを開発します。

N 層アーキテクチャは、従来のオンプレミス システムで一般的であり、既存のワークロードを Azure に移行するのに自然に適しています。

スケーラビリティ、信頼性、運用オーバーヘッドまたは仮想マシン (VM) の削減を実現するマネージド サービスを使用して、N 層アーキテクチャを効果的に実装します。 多くの場合、これらのワークロードは、キャッシュ、メッセージング、データ ストレージなどの主要なコンポーネントにマネージド ソリューションを使用することでメリットを得られます。

メリット

• クラウドとオンプレミス間、およびクラウド プラットフォーム間で移植可能
• ほとんどの開発者にとって必要な学習曲線が少ない
• ソリューションを再設計しないことでコストが比較的少ない
• 従来のアプリケーション モデルからの自然な進化に従う
• Windows と Linux を含む混合環境をサポートします

課題

• 中間層では、基本的な作成、読み取り、更新、削除 (CRUD) 操作のみを実行できます。これによって、意味のある値を提供することなく待機時間と複雑さが増します。
• モノリシック設計により、機能の独立した展開が防止されます。
• 大規模なシステムでは、ネットワーク セキュリティの管理が困難になる可能性があります。
• 複数の層を通過するユーザー要求とデータにより、テストと監視がより困難になります。

ベスト プラクティス

• 自動スケールを使用して、負荷の変化を処理します。 詳細については、「 自動スケールのベスト プラクティス」を参照してください。
• 非同期メッセージングを使用して階層を分離します。
• 頻繁に変更されないデータをキャッシュします。 詳細については、「 キャッシュのベスト プラクティス」を参照してください。
• SQL Server Always On 可用性グループなどのソリューションを使用して、高可用性のためにデータベース層を構成します。
• フロントエンドとインターネットの間に WAF を配置します。
• 各層を独自のサブネットに配置し、セキュリティ境界としてサブネットを使用します。
• 中間層からの要求のみを許可することで、データ層へのアクセスを制限します。

VM 上の N 層アーキテクチャ

このセクションでは、VM 上で実行される N 層アーキテクチャについて説明します。

各層は、2 つ以上の VM を持つ仮想マシン スケール セットで構成されます。 1 つの VM で障害が発生した場合、複数の VM が回復性を提供します。 ロード バランサーは、層内の VM 間で要求を分散します。 プールに VM を追加することで、階層を水平方向にスケーリングできます。

各層は独自のサブネット内にも配置されます。つまり、内部 IP アドレスは同じアドレス範囲内に収まることになります。 この方法を使用すると、ネットワーク セキュリティ グループの規則を簡単に適用し、テーブルを個々の層にルーティングできます。

Web 層とビジネス層はステートレスです。 どの VM でも、その層の要求を処理できます。 データ層は、レプリケートされたデータベースで構成されている必要があります。 可能であれば、マネージド データベースを使用しますが、VM でホストされているデータベースでデータベースをホストすることもできます。 Windows の場合、高可用性のために Always On 可用性グループを使用する SQL Server をお勧めします。 Linux の場合は、Apache Cassandra などのレプリケーションをサポートするデータベースを選択します。

ネットワーク セキュリティ グループは、各層へのアクセスを制限します。 たとえば、データベース層では、ビジネス層からのアクセスのみが許可されます。

その他の考慮事項

• N 層アーキテクチャは、3 つのレベルに制限されません。 複雑なアプリケーションでは、多くの場合、より多くのレベルがあります。 その場合は、レイヤー 7 ルーティングを使用して、要求を特定の層にルーティングすることを検討してください。

• レベルによって、スケーラビリティ、信頼性、およびセキュリティの境界が作成されます。 これらの領域で異なる要件を持つサービスに対して個別のレベルを用意することを検討してください。

• 自動スケールを するには、仮想マシン スケール セットを使用します。

• 重要なリファクタリングを行わずにマネージド サービスを使用できるアーキテクチャ内の場所を見つけます。 特に、キャッシュ、メッセージング、ストレージ、データベースを検討してください。

• セキュリティを強化するために、境界ネットワーク ( DMZ、 非武装地帯、 スクリーン サブネットとも呼ばれます) をアプリケーションの前に配置します。 境界ネットワークには、ファイアウォールやパケット検査などのセキュリティ機能を実装するネットワーク仮想アプライアンス (NVA) が含まれています。 詳細については、「 セキュリティで保護されたハイブリッド ネットワークを実装する」を参照してください。

• 仮想マシン スケール セットで 2 つ以上の NVA を使用し、外部ロード バランサーを使用して、高可用性のためにインスタンス間でインターネット要求を分散します。 詳細については、「 高可用性 NVA のデプロイ」を参照してください。

• アプリケーション コードを実行する VM への直接リモート デスクトップ プロトコル (RDP) または Secure Shell (SSH) アクセスをブロックします。 代わりに、Azure Bastion を使用して、RDP と SSH 接続を提供するプライベート IP アドレスを介して VM に安全に接続します。 詳細については、 Azure Bastion の概要に関するページを参照してください。

• サイト間仮想プライベート ネットワーク (VPN) または Azure ExpressRoute を使用して、Azure 仮想ネットワークをオンプレミス ネットワークに拡張します。 詳細については、「ハイブリッド ネットワークリファレンスアーキテクチャ 」を参照してください。

次のステップ

• App Service でセキュリティで保護された N 層アプリを作成する

関連リソース

• Azure での N 層アーキテクチャ スタイルでのメッセージング