N 계층 아키텍처 스타일

N계층 아키텍처는 애플리케이션을 논리적 레이어와 물리적 계층으로 나눕니다.

계층은 책임을 분리하고 종속성을 관리하는 방법입니다. 각 계층에는 특정 책임이 있습니다. 상위 계층은 하위 계층에서 서비스를 사용할 수 있지만 그 반대로는 사용할 수 없습니다.

계층은 물리적으로 분리되어 별도의 컴퓨터에서 실행됩니다. 계층은 다른 계층을 직접 호출하거나 메시지 큐를 통해 비동기 메시징 패턴을 사용할 수 있습니다 . 각 계층은 자체 계층에서 호스트될 수 있지만 필수는 아닙니다. 여러 계층이 동일한 계층에서 호스트될 수 있습니다. 계층을 물리적으로 분리하면 확장성 및 복원력이 향상되지만 추가 네트워크 통신에서 대기 시간이 추가됩니다.

기존의 3계층 애플리케이션에는 프레젠테이션 계층, 중간 계층 및 데이터베이스 계층이 있습니다. 중간 계층은 선택 사항입니다. 더 복잡한 애플리케이션에는 3개 이상의 계층이 있을 수 있습니다. 위의 다이어그램은 서로 다른 기능 영역을 캡슐화하는 두 개의 중간 계층이 있는 애플리케이션을 보여 줍니다.

N 계층 애플리케이션에는 닫힌 계층 아키텍처 또는 개방형 계층 아키텍처가 있을 수 있습니다.

• 닫힌 계층 아키텍처에서 계층은 즉시 다음 계층을 호출할 수 있습니다.
• 개방형 계층 아키텍처에서 계층은 아래 계층 중 어느 계층을 호출할 수 있습니다.

닫힌 계층 아키텍처는 레이어 간의 종속성을 제한합니다. 그러나 레이어가 단순히 요청을 다음 레이어로 전달하는 경우 불필요한 네트워크 트래픽을 만들 수 있습니다.

이 아키텍처를 사용하는 경우

N 계층 아키텍처는 일반적으로 IaaS(Infrastructure-as-Service) 애플리케이션으로 구현되며 각 계층은 별도의 VM 집합에서 실행됩니다. 그러나 N 계층 애플리케이션은 순수 IaaS일 필요는 없습니다. 특히 캐싱, 메시징, 데이터 스토리지 같은 일부 아키텍처 부분에는 관리 서비스를 사용하는 것이 유리한 경우가 많습니다.

다음과 같은 경우 N계층 아키텍처를 고려합니다.

• 간단한 웹 애플리케이션.
• 최소 리팩터링으로 온-프레미스 애플리케이션을 Azure로 마이그레이션.
• 온-프레미스 및 클라우드 애플리케이션의 통합 개발.

N 계층 아키텍처는 기존 온-프레미스 애플리케이션에서 매우 일반적이므로 기존 워크로드를 Azure로 마이그레이션하는 데 자연스럽게 적합합니다.

이점

• 클라우드와 온-프레미스 간 및 클라우드 플랫폼 간의 이식성.
• 대부분의 개발자를 위한 학습 곡선이 줄어듭니다.
• 기존 애플리케이션 모델에서 자연스럽게 진화합니다.
• 다른 유형의 환경에 개방(Windows/Linux)

당면 과제

• 데이터베이스에서 CRUD 작업을 수행하는 중간 계층으로 쉽게 끝날 수 있으므로 유용한 작업을 수행하지 않고 대기 시간을 더 추가할 수 있습니다.
• 모놀리식 디자인은 기능의 독립적인 배포를 방지합니다.
• IaaS 애플리케이션 관리는 관리되는 서비스만 사용하는 애플리케이션보다 더 많은 작업입니다.
• 대규모 시스템에서 네트워크 보안을 관리하기 어려울 수 있습니다.

모범 사례

• 자동 크기 조정을 사용하여 부하 변경 내용을 처리합니다. 자동 크기 조정 모범 사례를 참조하세요.
• 비동기 메시징을 사용하여 계층을 분리합니다.
• 반정적 데이터를 캐시합니다. 캐싱 모범 사례를 참조하세요.
• SQL Server Always On 가용성 그룹 등의 솔루션을 사용하여 고가용성을 위해 데이터베이스 계층을 구성합니다.
• 프런트 엔드와 인터넷 사이에 WAF(웹 애플리케이션 방화벽)를 배치합니다.
• 각 계층을 자체 서브넷에 배치하고 서브넷을 보안 경계로 사용합니다.
• 중간 계층의 요청만 허용하여 데이터 계층에 대한 액세스를 제한합니다.

가상 머신의 N 계층 아키텍처

이 섹션에서는 VM에서 실행되는 권장 N 계층 아키텍처에 대해 설명합니다.

각 계층은 두 개 이상의 VM으로 구성되며 가용성 집합 또는 가상 머신 확장 집합에 배치됩니다. 여러 VM은 하나의 VM이 실패할 경우 복원력을 제공합니다. 부하 분산 장치는 계층의 VM 간에 요청을 분산하는 데 사용됩니다. 풀에 더 많은 VM을 추가하여 계층의 크기를 수평으로 조정할 수 있습니다.

또한 각 계층이 자체 서브넷 안에 배치되므로 내부 IP 주소가 동일한 주소 범위 내에 있습니다. 이렇게 하면 네트워크 보안 그룹 규칙을 적용하고 테이블을 개별 계층으로 라우팅하기 쉽습니다.

웹 및 비즈니스 계층은 상태 비지정 계층입니다. 모든 VM은 해당 계층에 대한 모든 요청을 처리할 수 있습니다. 데이터 계층은 복제본(replica)ted 데이터베이스로 구성되어야 합니다. Windows의 경우 SQL Server가 권장되며 고가용성을 위해 Always On 가용성 그룹을 사용하는 것이 좋습니다. Linux의 경우 복제를 지원하는 Apache Cassandra 등의 데이터베이스를 선택합니다.

네트워크 보안 그룹은 각 계층에 대한 액세스를 제한합니다. 예를 들어 데이터베이스 계층은 비즈니스 계층에서만 액세스를 허용합니다.

추가 고려 사항

• N 계층 아키텍처는 3개의 계층으로 제한되지 않습니다. 더 복잡한 애플리케이션의 경우 더 많은 계층이 있는 것이 일반적입니다. 이 경우 계층 7 라우팅을 사용하여 요청을 특정 계층으로 라우팅하는 것이 좋습니다.

• 계층은 확장성, 안정성 및 보안의 경계입니다. 해당 영역에서 요구 사항이 다른 서비스에 대해 별도의 계층을 사용하는 것이 좋습니다.

• 자동 크기 조정에 가상 머신 확장 집합을 사용합니다.

• 아키텍처에서 중요한 리팩터링 없이 관리되는 서비스를 사용할 수 있는 위치를 찾습니다. 특히 캐싱, 메시징, 스토리지 및 데이터베이스를 살펴봅니다.

• 보안을 강화하려면 애플리케이션 앞에 네트워크 DMZ를 배치합니다. DMZ에는 방화벽 및 패킷 검사와 같은 보안 기능을 구현하는 NVA(네트워크 가상 어플라이언스)가 포함되어 있습니다. 자세한 내용은 네트워크 DMZ 참조 아키텍처를 참조 하세요.

• 고가용성을 위해 외부 부하 분산 장치와 함께 가용성 집합에 둘 이상의 NVA를 배치하여 인스턴스 간에 인터넷 요청을 분산합니다. 자세한 내용은 고가용성 네트워크 가상 어플라이언스 배포 및 IaaS 앱에 대한 고가용성 및 재해 복구의 이 예제 시나리오를 참조하세요.

• 애플리케이션 코드를 실행하는 VM에 대한 직접 RDP 또는 SSH 액세스를 허용하지 않습니다. 대신, 운영자가 요새 호스트라고도 하는 Jumpbox에 로그인해야 합니다. 이는 관리자가 다른 VM에 연결할 때 사용하는 네트워크의 VM입니다. Jumpbox에는 승인된 공용 IP 주소의 RDP 또는 SSH만 허용하는 네트워크 보안 그룹이 있습니다.

• 사이트-사이트 VPN(가상 사설망) 또는 Azure ExpressRoute를 사용하여 Azure 가상 네트워크를 온-프레미스 네트워크로 확장할 수 있습니다. 자세한 내용은 하이브리드 네트워크 참조 아키텍처를 참조 하세요.

• 조직에서 Active Directory를 사용하여 ID를 관리하는 경우 Active Directory 환경을 Azure VNet으로 확장할 수 있습니다. 자세한 내용은 ID 관리 참조 아키텍처를 참조 하세요.

• VM용 Azure SLA가 제공하는 가용성보다 높은 가용성이 필요한 경우, 두 지역 간에 애플리케이션을 복제한 다음 장애 조치(failover)를 위해 Azure Traffic Manager를 사용합니다. 자세한 내용은 여러 지역에서 Windows VM 실행 또는 여러 지역에서 Linux VM 실행을 참조하세요.

관련 리소스

• Apache Cassandra를 통한 N 계층 애플리케이션
• [SQL Server를 사용하는 Azure의 Windows N 계층 애플리케이션] [n-tier-windows-SQL]
• Microsoft Learn 모듈: N 계층 아키텍처 스타일 둘러보기
• Azure Bastion
• Azure에서 N 계층 아키텍처 스타일의 메시징에 대한 자세한 정보