N계층 아키텍처에 대한 고려 사항
N 계층 아키텍처를 구성하는 요소를 살펴보고 3계층 아키텍처의 예제를 배포했습니다. 이제 이 아키텍처 스타일의 몇 가지 이점과 과제 및 성능과 보안을 위해 이를 최적화하는 모범 사례에 대해 살펴보겠습니다.
이점
이 아키텍처 스타일의 강점은 단순성에 있습니다. 온-프레미스 및 클라우드 배포 모두에서 자주 사용되고 잘 정의된 아키텍처 패턴이며, 광범위한 애플리케이션에서 작동할 수 있습니다.
플랫폼에 구속받지 않는 아키텍처이며, Windows 또는 Linux에 배포된 애플리케이션에 적합합니다. 예제 환경에서 살펴보았듯이 PaaS 또는 IaaS 서비스는 모든 계층에서 사용할 수 있습니다.
애플리케이션을 계층으로 구분하면 각 계층을 개별적으로 크기 조정, 업데이트 또는 업그레이드할 수 있습니다. 웹 사이트에 대한 요청이 증가하면 다른 계층에 영향을 주지 않으면서 부하에 웹 서버를 추가할 수 있습니다. 마찬가지로, 데이터 계층에 대한 요청이 증가하면 해당 요청을 처리할 수 있도록 데이터베이스를 확장하여 더 많은 용량을 확보할 수 있습니다.
네트워크 분리는 이 아키텍처의 자연스러운 부산물입니다. 애플리케이션이 계층으로 구분되므로 각 계층을 격리하고 필요한 네트워크 액세스만 허용해야 합니다. 프레젠테이션 계층은 인터넷에 공개될 수 있고, 데이터베이스는 여러 네트워크 계층 뒤에서 완벽하게 보호될 수 있으며, 애플리케이션 기능도 동일합니다. 계층 간의 네트워크 액세스를 보호하여 애플리케이션에 대한 공격 표면을 줄이고 해당 보안을 강화합니다.
과제 및 고려 사항
애플리케이션을 여러 계층으로 구분할 때는 데이터베이스 작업만 수행하는 중간 계층을 방지합니다. 각 계층에서 특정 값을 추가해야 합니다. 추가 계층은 복잡성, 처리 시간, 대기 시간을 늘리고, 궁극적으로 사용자의 대기 시간도 늘립니다.
각 애플리케이션 수준 도메인에 대한 API는 개별 서비스로 구분되지 않으므로 함께 확장해야 합니다. 단일 애플리케이션 방법에 더 많은 처리 능력이 필요하거나 다른 애플리케이션보다 더 많은 요청을 처리해야 하는 경우 개별 서비스 대신 애플리케이션 계층을 전체적으로 확장하여 부하를 처리해야 합니다.
경우에 따라 애플리케이션을 N계층 아키텍처로 개발할 수 있지만, 배포는 여전히 모놀리식으로 수행할 수 있습니다. 각 계층이 완벽하게 구분되면 각 계층을 개별적으로 배포해야 합니다. 전체 분리로 공유 종속성이 제거되고 계층 간의 API 호출에 대한 의존도가 더 높아집니다. 제대로 완료되면 애플리케이션 배포가 유연해집니다.
N 계층 아키텍처의 애플리케이션은 VM에 배포되는 경우가 많습니다. 이는 첫 단계로 유용하지만, PaaS 서비스를 사용하도록 애플리케이션을 진화시키면 보안, 확장성 및 관리 측면에서 많은 이점을 얻을 수 있습니다. 이러한 진화를 간과하는 경우가 많으며, N 계층 아키텍처가 VM에 상주합니다.
N 계층은 클래식 아키텍처 스타일이지만, 많은 시나리오에서 마이크로 서비스 아키텍처와 같은 다른 최신 설계 패턴으로 대체됩니다. 다른 아키텍처를 평가하여 애플리케이션에 더 적합한지 확인하는 데 시간을 투자할 필요가 있는 경우가 많습니다.
N계층 아키텍처에 대한 모범 사례
N계층 아키텍처가 최상의 상태로 실행되도록 하려면 수행해야 할 몇 가지 작업이 있습니다. 다음 다이어그램에서는 N계층 아키텍처를 향상시킬 수 있는 방법을 시각적으로 보여 줍니다.
성능 최적화
성능과 보안 모두에 맞게 N계층 아키텍처를 최적화하는 방법을 살펴보겠습니다.
자동 크기 조정
애플리케이션을 계층으로 구분하면 자동 스케일링과 같은 클라우드 기능을 사용하여 시스템 부하에 적응할 수 있습니다. 사용자 또는 요청이 늘어남에 따라 이러한 요청을 처리하기 위해 여러 계층에서 자동 크기 조정을 사용하여 더 많은 리소스를 추가합니다. 요청이 줄어들면 자동 크기 조정에서 컴퓨팅 리소스를 줄이고 요금 청구도 줄입니다. 자동 스케일링을 사용하면 사용자가 최상의 환경을 유지하고 비용을 낮게 유지할 수 있습니다. Azure Virtual Machine Scale Sets는 VM 기반 워크로드에 사용할 수 있으며, Azure App Service와 같은 많은 PaaS 서비스에는 자동 스케일링이 기본적으로 제공됩니다.
부하 분산
자동 크기 조정을 사용하여 애플리케이션을 확장하면 부하 분산을 사용하는 것이 아키텍처의 필수 요소가 됩니다. 부하 분산을 사용하면 계층에 더 많은 컴퓨팅 리소스를 추가할 때 해당 컴퓨팅 리소스가 부하 분산 장치 배포에 추가되어 추가 처리 성능을 활용할 수 있습니다. 반대로, 시스템에 오류가 발생하면 부하에서 제거되어 떨어진 성능 또는 오류가 있는 요청을 통해 사용자의 영향을 최소화합니다. 이렇게 하면 사용자 요청이 정상 상태의 시스템으로 이동합니다. Azure 부하 분산 장치는 네트워킹 기능의 기본 제공 기능이며, Application Gateway는 더 풍부한 기능을 갖춘 HTTP 부하 분산 솔루션을 제공합니다.
메시징
계층 간에 메시징 서비스를 사용하면 성능, 특히 실질적인 비동기 요청에 긍정적인 효과를 줍니다. 서비스는 메시지가 처리될 때까지 남아 있는 큐에 배치해 다운스트림 부하의 영향을 상쇄합니다. 시스템 중단이 발생하는 경우 메시징 서비스는 메시지가 계속 처리되도록 합니다. 메시지는 큐에 남아 있으며 시스템이 다시 온라인 상태가 된 후에 처리됩니다. Azure에는 요구 사항에 따라 선택할 수 있는 몇 가지 메시징 솔루션이 있습니다. Azure Service Bus, Azure Storage 큐 및 Azure Event Hubs는 메시징 서비스를 찾을 때 고려해야 할 몇 가지 항목입니다.
데이터 캐싱
자주 액세스되고 변경률이 낮은 데이터 또는 세션 상태와 같이 장기적인 지속성이 필요하지 않은 데이터에는 캐시를 사용합니다. 캐싱 시스템은 계층 사이에 배치되어 이러한 형식의 데이터에 대한 데이터 검색 시간을 줄입니다. Azure Cache for Redis는 이 시나리오에 적합한 PaaS 서비스입니다.
보안 최적화
보안을 위해 애플리케이션을 최적화하는 것은 이 작업을 “완료”되지 않도록 하는 경우가 종종 있습니다. 애플리케이션이 계층으로 구분되어 있는 경우에도 아키텍처에 적절하게 구성된 보안 사례가 잘 계획되어 있어야 합니다. 계층이 더 많이 추가될수록 보안이 더 강화되고 시스템에 더 많은 복잡성을 도입해야 합니다. 아키텍처에서 애플리케이션을 실행할 수 있는 보안 환경을 제공하기 위해 수행해야 할 몇 가지 작업이 있습니다.
네트워크 격리
VM에서 N 계층 아키텍처를 실행하는 경우 각 계층이 자체의 서브넷에 있어야 합니다. 이 서브넷은 보안 경계로서 작동하며 네트워크 액세스 컨트롤 목록을 통해 연결을 격리할 수 있습니다. 또한 서브넷은 서브넷의 새 시스템이 동일한 규칙을 받도록 해 관리를 용이하게 합니다. Azure에서 이 작업은 기본적으로 NSG(네트워크 보안 그룹)를 통해 수행됩니다. PaaS 서비스에서도 이와 비슷하게 고려해야 하지만, 네트워크 통합 기능은 서비스마다 다르므로 자체적으로 평가해야 합니다. 각 계층은 아래의 다음 계층에만 통신할 수 있도록 하는 것이 가장 좋습니다. 프레젠테이션 계층은 애플리케이션 계층과만 통신할 수 있어야 하며, 애플리케이션 계층은 데이터 계층과만 통신할 수 있어야 합니다. 이러한 연결을 최소화하면 네트워크 보안에 대한 계층화된 접근 방식을 제공하고 아키텍처의 전반적인 보안 상태를 향상시킬 수 있습니다.
웹 애플리케이션 방화벽
서브넷 간의 보안 격리를 적절히 사용하여 공개적으로 노출된 프런트 엔드의 보안을 유지하고 필요한 것에만 액세스할 수 있도록 해야 합니다. 프레젠테이션 계층을 인바운드 인터넷 트래픽에만 노출해야 합니다. 프리젠테이션 계층 전의 웹 애플리케이션 방화벽(WAF) 기술은 이 계층에서 보안을 향상합니다. WAF는 악의적인 활동이 있는지 트래픽을 검사하고, 통신이 암호화되었는지 확인하며, 비정상적인 활동이 있으면 사용자에게 알려줍니다. Azure에서 Application Gateway는 사용하도록 설정할 수 있는 기본 제공 WAF가 있는 HTTP 부하 분산 장치입니다.