編集

次の方法で共有

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

Azure Storage
Azure クラウド サービス
Azure Virtual Machines

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

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

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

階層は物理的に分離され、個別のマシンで実行されます。 契約上、レベルは、通信モデルを厳密または緩和することができます。 厳密なモデルでは、要求は隣接する層を 1 つずつ通過する必要があり、その間にどの層もスキップできません。 たとえば、Web アプリケーション ファイアウォールから Web 層、中間層 1 などです。 これに対し、緩やかなアプローチでは、必要に応じて一部のレベルが要求によってスキップされる場合があります。 厳密なアプローチでは待機時間とオーバーヘッドが増え、緩やかなアプローチでは結合が多く、その後変更が困難になります。 システムはハイブリッド アプローチを使用できます。必要に応じて、緩やかなレベルと厳密なレベルの両方を持つことができます。

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

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

N 層アプリケーションには、のクローズド レイヤー アーキテクチャ または オープンレイヤー アーキテクチャを含めることができます。

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

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

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

N 層アーキテクチャは通常、サービスとしてのインフラストラクチャ (IaaS) アプリケーションとして実装され、各層は個別の VM セットで実行されます。 ただし、N 層アプリケーションは純粋な IaaS である必要はありません。 多くの場合、アーキテクチャの一部 (特にキャッシュ、メッセージング、データ ストレージ) にマネージド サービスを使用すると便利です。

次の N 層アーキテクチャについて考えてみましょう。

  • 単純な Web アプリケーション。
  • アーキテクチャ要件がまだ明確でない場合の出発点として適しています。
  • 最小限のリファクタリングでオンプレミス アプリケーションを Azure に移行する。
  • オンプレミスアプリケーションとクラウド アプリケーションの統合開発。

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

利点

  • クラウドとオンプレミス間、およびクラウド プラットフォーム間の移植性。
  • ほとんどの開発者にとって学習曲線が少なくなります。
  • ソリューションを再設計しないことで比較的低コスト
  • 従来のアプリケーション モデルからの自然な進化。
  • 異種環境に対して開く (Windows/Linux)

課題

  • 最終的には、データベースに対して CRUD 操作を行うだけの中間層が簡単に作成され、便利な作業を行わずに待機時間が長くなります。
  • モノリシック設計により、機能の独立した展開が防止されます。
  • IaaS アプリケーションの管理は、マネージド サービスのみを使用するアプリケーションよりも機能します。
  • 大規模なシステムでネットワーク セキュリティを管理することは困難な場合があります。
  • 通常、ユーザー フローとデータ フローは複数の層にまたがり、テストや監視などの問題に複雑さが加えられています。

ベスト プラクティス

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

仮想マシン上の N 層アーキテクチャ

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

N 層アーキテクチャ の物理図

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

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

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

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

手記

参照図の "ビジネス層" というラベルが付いたレイヤーは、ビジネス ロジック層のモニカーです。 同様に、プレゼンテーション層も "Web 層" と呼びます。この例では、これは Web アプリケーションですが、多層アーキテクチャは他のトポロジ (デスクトップ アプリなど) にも使用できます。 チームがアプリケーションでその論理層や物理層の意図を伝えるために最適なレベルに名前を付けます。その階層を表すために選択したリソースでその名前付け (vmss-appName-business-layer など) を表現することもできます。

その他の考慮事項

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

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

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

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

  • セキュリティを強化するために、アプリケーションの前にネットワーク DMZ を配置します。 DMZ には、ファイアウォールやパケット検査などのセキュリティ機能を実装するネットワーク仮想アプライアンス (NVA) が含まれています。 詳細については、「ネットワーク DMZ リファレンス アーキテクチャの」を参照してください。

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

  • アプリケーション コードを実行している VM への直接 RDP または SSH アクセスを許可しないでください。 代わりに、オペレーターはジャンプボックス (要塞ホストとも呼ばれます) にログインする必要があります。 これは、管理者が他の VM への接続に使用するネットワーク上の VM です。 ジャンプボックスには、承認されたパブリック IP アドレスからのみ RDP または SSH を許可するネットワーク セキュリティ グループがあります。

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

  • 組織で Active Directory を使用して ID を管理する場合は、Active Directory 環境を Azure VNet に拡張できます。 詳細については、「ID 管理リファレンス アーキテクチャの」を参照してください。

  • VM の Azure SLA よりも高い可用性が必要な場合は、2 つのリージョン間でアプリケーションをレプリケートし、フェールオーバーに Azure Traffic Manager を使用します。 詳細については、「複数のリージョンで Linux VM を実行する 」を参照してください。