N 層アーキテクチャに関する考慮事項
N 層アーキテクチャの構成要素を確認し、3 層アーキテクチャのサンプルをデプロイしました。 このアーキテクチャのいくつかのメリットと課題、そして、パフォーマンスとセキュリティを最適化するためのベスト プラクティスを調べていきましょう。
メリット
このスタイルのアーキテクチャは、その単純さにメリットがあります。 それは、オンプレミスとクラウドでのデプロイの両方にとって、使用頻度が高く十分に定義されたアーキテクチャ パターンであり、広範囲のアプリケーションで機能できます。
プラットフォームに依存しないアーキテクチャであり、Windows または Linux にデプロイされるアプリケーションに適しています。 サンプル環境で紹介したように、すべての層で PaaS または IaaS サービスを使用できます。
アプリケーションを層に分離することで、各層のスケーリング、更新、またはアップグレードを個別に実行できます。 Web サイトに対する要求が増加した場合は、負荷に対応するために他の層に影響を与えずに Web サーバーを追加できます。 同様に、データ層に対する要求が増加した場合は、要求を処理する容量が大きくなるようにデータベースをスケーリングできます。
ネットワークの分離は、このアーキテクチャの当然の副産物です。 アプリケーションが層に分離されるため、各層を隔離して、必要なネットワーク アクセスのみを許可する必要があります。 プレゼンテーション層をインターネットに公開でき、データベースを複数のネットワーク層の背後で完全に保護できますが、アプリケーションはまったく同じように機能します。 各層の間のネットワーク アクセスを保護することで、アプリケーションの攻撃対象領域が減り、セキュリティが強化されます。
課題と考慮事項
アプリケーションを複数の層に分離するときに、データベースの操作のみを実行する中間層は避けてください。 各層には、具体的な価値を追加する必要があります。 層を追加すると、複雑さ、処理時間、待機時間が追加され、最終的にはユーザーへの対応が遅れます。
各アプリケーション レベルのドメイン用の API は個別のサービスに分離されないため、まとめてスケーリングする必要があります。 アプリケーションの単一のメソッドで、より多くの処理能力やより多くの要求を処理する必要がある場合に、その負荷を処理するには、個別のサービスではなく、アプリケーション層全体をスケールアウトする必要があります。
アプリケーションを N 層アーキテクチャとして開発したが、デプロイは一枚岩として実行する場合があります。 完全に分離された各層は、個別にデプロイする必要があります。 完全に分離するには、共有されている依存関係の削除が不可欠であり、各層の間での API 呼び出しへの依存度が高まります。 適切に実行すると、アプリケーションのデプロイの柔軟性が確保されます。
多くの場合、N 層アーキテクチャのアプリケーションは、VM 上にデプロイされます。 これは最初の一歩に適していますが、PaaS サービスを使用するようにアプリケーションを進化させると、セキュリティ、スケーラビリティ、および管理の点で多大なメリットがもたらされます。 このような進化はしばしば見落とされ、N 層アーキテクチャは、VM 上に存在したままになります。
n 層は優れたアーキテクチャ スタイルですが、多くのシナリオでは、マイクロサービス アーキテクチャなどの他の最新の設計パターンに取って代わられています。 多くの場合、時間をかけて他のアーキテクチャを評価し、それらの方がお使いのアプリケーションにより適しているかどうかを確認する価値があります。
N 層アーキテクチャのベスト プラクティス
N 層アーキテクチャが最良の状態で実行されるようにするには、いくつかの事柄を実行する必要があります。 次の図は、N 層アーキテクチャをどのように改良することができるかを示しています。
パフォーマンスを最適化する
N 層アーキテクチャでパフォーマンスとセキュリティの両方を最適化する方法を見てみましょう。
自動スケール
層に分離されたアプリケーションでは、自動スケールなどのクラウドの機能を使用して、システムの負荷に対応できます。 ユーザーまたは要求が増加したら、複数の層で自動スケールを使用して、要求を処理するリソースを追加します。 要求が減少したら、自動スケールによってコンピューティング リソースが減少し、コストも削減されます。 自動スケールを使用すると、コストを抑えながら、ユーザーに最良のエクスペリエンスを簡単に提供できます。 VM ベースのワークロードでは、Azure Virtual Machine Scale Sets を使用できます。自動スケール機能は、Azure App Service などの多くの PaaS サービスに組み込まれています。
負荷分散
自動スケールを使用してアプリケーションをスケールアウトするときは、アーキテクチャの一部として負荷分散を使用する必要があります。 負荷分散では、層にコンピューティング リソースが追加されると、追加された処理能力を活用できるように、そのリソースがロード バランサーの分散先に追加されます。 逆に、システムで障害が発生した場合は、負荷から削除され、パフォーマンスの低下や誤った要求によるユーザーへの影響が最小限に抑えられます。 これにより、ユーザーの要求は、確実に正常なシステムで処理されます。 Azure Load Balancer はネットワーク機能に組み込まれている機能であり、Application Gateway には豊富な機能を備えた HTTP 負荷分散ソリューションが提供されます。
メッセージング
層の間でメッセージング サービスを使用すると、特に本質的に非同期である要求の場合は、パフォーマンスに対してプラスの効果がもたらされます。 メッセージは、サービスによってキューに格納され、処理されるまでそこにとどまり、ダウン ストリームの負荷の影響が相殺されます。 システムの停止が発生した場合でも、メッセージング サービスによって、メッセージが引き続き処理されることが保証されます。 メッセージはキュー内にとどまり、システムがオンラインに戻った後に処理されます。 Azure には、要件に応じて選択できるいくつかのメッセージング ソリューションがあります。 Azure Service Bus、Azure Storage キュー、および Azure Event Hubs は、メッセージング サービスを探しているときに考慮できるものの一例です。
データのキャッシュ
アクセスの頻度は高いが、変更されることは少ないデータや、長期間保存する必要がないセッション状態などのデータでは、キャッシュを使用します。 層の間にキャッシュ システムを配置すると、この種のデータを取得するための時間が短縮されます。 Azure Cache for Redis は、このシナリオに適した PaaS サービスです。
セキュリティを最適化する
多くの場合、アプリケーションのセキュリティの最適化は、これまで "行われた" ことのない作業です。アプリケーションが層に分離されていても、十分に練られたセキュリティ プラクティスをアーキテクチャに織り込む必要があります。 層を追加すればするほど、必要なセキュリティ保護が増加し、システムは複雑化します。 さまざまな対策を行って、アプリケーションを実行するためのセキュリティ保護された環境を提供するアーキテクチャを構築する必要があります。
ネットワークの分離
VM 上で N 層アーキテクチャを実行する場合は、必ず各層が独自のサブネット内に存在するようにします。 このサブネットはセキュリティ境界として機能し、ネットワーク アクセス制御リストを通して接続を分離できます。 また、サブネット内の新しいシステムに同じ規則が確実に適用されることにより、管理が容易になります。 Azure では、これは、ネットワーク セキュリティ グループ (NSG) によってネイティブに実行されます。 PaaS サービスに対しても同様の事柄を考慮する必要がありますが、ネットワーク統合機能はサービスによって異なるため、個別に評価する必要があります。 ベスト プラクティスは、各層がその下の層とのみ通信できるようにすることです。 プレゼンテーション層はアプリケーション層とのみ通信でき、アプリケーション層はデータ層とのみ通信できるようにします。 接続性を最小限に抑えることで、ネットワーク セキュリティに対して階層化アプローチを適用して、アーキテクチャの総合的なセキュリティ状況を向上させることができます。
Web アプリケーション ファイアウォール
サブネット間でセキュリティを分離することで、一般に公開されるフロント エンドがセキュリティで保護され、必要なものへのアクセスのみが許可されるようにすることができます。 プレゼンテーション層は受信インターネット トラフィックのみに公開される必要があります。 プレゼンテーション層の前に Web アプリケーション ファイアウォール (WAF) テクノロジを配置することで、この層のセキュリティが強化されます。 WAF によって、トラフィック内の悪意のあるアクティビティが調査され、通信が暗号化され、異常が発生した場合にアラートが生成されます。 Azure には、HTTP ロード バランサーである Application Gateway に WAF が組み込まれており、有効にすることができます。