N계층 아키텍처란?
N계층 아키텍처는 애플리케이션을 논리적 레이어와 물리적 계층으로 나눕니다. N은 애플리케이션이 구분되는 물리적 계층의 수를 나타내며, 일반적으로 레이어 수와 상관 관계가 있습니다. 일반적으로 2계층 아키텍처(클라이언트-서버), 심지어 5계층 아키텍처도 있을 수 있지만, 계층의 수를 4개 이하로 유지하는 것이 가장 좋습니다.
레이어와 계층을 구성하는 요소에 대해 살펴보겠습니다.
레이어란?
레이어는 애플리케이션을 구성하는 애플리케이션 코드를 논리적으로 구분합니다. 각 레이어에는 사용자의 요청 처리, 비즈니스 논리 실행 또는 데이터 스토리지 처리와 같은 특정 책임이 있습니다.
애플리케이션을 이러한 논리적 레이어로 구분하여 각 레이어를 독립적으로 처리합니다. 이러한 분리로 애플리케이션의 구성 요소가 모듈화되어 앱을 더 쉽게 유지 관리할 수 있습니다. 각 책임에 맞게 애플리케이션을 최적화할 수 있습니다. 웹 요청을 처리하는 레이어는 웹 요청 처리라는 기본 작업에 중점을 둡니다. 데이터 스토리지 또는 실행 중인 비즈니스 논리와는 관련이 없습니다. 반대로, 데이터 액세스 레이어는 데이터 저장소에 대한 통신을 최적화하는 데 중점을 두고, 사용자에게 데이터가 표시되는 방법에 대한 세부 정보는 무시합니다. 특정 기능에 대한 초점을 제한하는 이 개념을 문제 구분이라고 합니다.
다음은 일반적인 N계층 아키텍처의 레이어를 보여 주는 다이어그램입니다. 각 레이어는 애플리케이션의 한 측면을 처리합니다. 비즈니스 레이어는 사용자 인터페이스 레이어와 데이터 액세스 레이어 간의 통신을 관리합니다.
계층이란?
계층은 개별 컴퓨팅 리소스에서 애플리케이션 부분의 물리적 구분을 나타냅니다. 일반적으로 각 물리적 계층은 애플리케이션에 대한 하나의 논리적 레이어를 실행합니다.
아키텍처를 물리적 계층으로 구분하면 다음과 같은 몇 가지 이점이 있습니다.
- 애플리케이션 구성 요소는 각 계층에 리소스를 추가하여 개별적으로 크기 조정할 수 있습니다.
- 부하 분산을 추가하여 실패한 리소스를 탐지하고 요청을 정상 상태의 시스템으로 리디렉션함으로써 애플리케이션의 복원력을 높일 수 있습니다.
- 계층 간의 네트워크 통신을 제한하고 필요한 액세스만 허용하여 애플리케이션의 보안을 강화할 수 있습니다.
아키텍처는 계층 간의 통신이 하향식이어야 한다는 것을 나타냅니다. 각 계층은 해당 계층 아래의 다음 계층과 통신할 수 있지만 일반적으로 계층을 건너뛸 수는 없습니다. 이는 계층의 노출 영역을 제한하여 보안을 향상시키기 위해 설계됩니다.
3계층 아키텍처
모든 N계층 아키텍처 중에서 3계층 아키텍처가 가장 일반적입니다. 각 레이어 및 계층의 책임과 이름은 애플리케이션 및 비즈니스에 따라 다르지만, 일반적인 3계층 애플리케이션에는 프레젠테이션 계층, 애플리케이션 또는 중간 계층 및 데이터 계층이 포함됩니다. 이 아키텍처는 가장 일반적인 N 계층 스타일입니다. 이 모듈의 나머지 부분에서는 각 계층에서 애플리케이션의 단일 레이어를 실행하는 3계층 모델을 참조하고, 이를 계층과 동의어로 참조합니다.
프레젠테이션 계층
프레젠테이션 계층은 일반적으로 사용자 요청을 용이하게 합니다. 이러한 요청은 사용자가 웹 페이지에 액세스하거나 노출된 API를 통해 애플리케이션에 공개적으로 액세스할 수 있습니다. 이 계층은 사용자 환경에 중점을 둡니다. 이 계층은 직관적인 인터페이스와 같은 유용한 기능을 제공하고 최종 사용자와 애플리케이션 간의 보안 통신을 보장합니다.
이 계층에서는 데이터가 사용자에게 제시되는 방법에만 관심이 있고, 데이터 자체에는 관심이 없습니다. 일반적으로 이 계층에서 수행되는 데이터 처리 또는 데이터 액세스는 없습니다. 이는 하위 계층의 책임입니다.
애플리케이션 계층
일반적으로 애플리케이션 계층(중간 계층이라고도 함)은 애플리케이션의 비즈니스 논리를 처리하는 데 중점을 둡니다. 이는 고객 주문을 처리하거나, 배송을 추적하거나, 수령한 자재에 따라 재고를 업데이트할 수 있습니다. 이 계층은 데이터 계층에 대한 CRUD(만들기, 읽기, 업데이트, 삭제) 작업도 담당합니다. 또한 외부 API와 같은 종속 서비스를 호출하는 데에도 적합한 위치입니다.
이 계층은 사용자에게 정보가 다시 제시되는 방법이나 데이터가 저장되고 검색되는 방식과는 관련이 없습니다. 애플리케이션에서 받은 요청을 수행하는 데 필요한 비즈니스 논리에 중점을 둡니다.
데이터 계층
이 계층에서는 데이터 스토리지에 중점을 둡니다. 테이블, 파일 또는 다른 매체에 데이터를 스토리지하는 것은 이 계층의 책임입니다. 이 계층은 데이터에 액세스하기 위한 인터페이스(예: T-SQL)를 제공합니다. 3계층 아키텍처에서 데이터 레이어는 애플리케이션 계층에 대한 데이터 액세스를 제공합니다.
이 계층은 사용자에게 데이터를 제공하는 방법 또는 모든 데이터 관련 논리에 중점을 두지 않습니다. 저장 프로시저의 사용은 이 계층에 있을 수 있지만, 데이터의 논리는 대부분 더 높은 계층에서 처리해야 합니다.
N계층 아키텍처를 사용하는 경우
이제 N 계층 아키텍처가 무엇인지 설명했으므로 이 스타일의 아키텍처를 사용하는 경우를 살펴보겠습니다. 다음과 같은 경우 N계층 아키텍처를 고려합니다.
- 중소규모의 웹 애플리케이션
- 최소 리팩터링으로 온-프레미스 애플리케이션을 Azure로 마이그레이션.
- 온-프레미스 개발자의 기술, 기능 및 환경을 사용합니다.
웹 애플리케이션은 이 스타일의 아키텍처에 적합한 사용 사례입니다. 이 아키텍처 스타일의 복잡성이 줄어들고 웹 애플리케이션의 책임이 자연스럽게 구분되는 경우가 많으므로 N계층 아키텍처가 제대로 작동할 수 있습니다. 이러한 애플리케이션은 조직에서 내부적으로 사용되는 퍼블릭 애플리케이션 또는 LOB(기간 업무) 애플리케이션일 수 있습니다. 더 작거나 덜 복잡한 애플리케이션의 경우 프레젠테이션 계층과 애플리케이션 계층을 구분하는 대신 결합하여 2계층(클라이언트/서버) 아키텍처로도 충분할 수 있습니다.
N계층 아키텍처는 기존 온-프레미스 애플리케이션에서 일반적이므로 기존 워크로드를 Azure로 마이그레이션하는 데 적합합니다. 이 스타일의 애플리케이션은 종종 리팩터링 또는 수정을 최소화하여 Azure로 마이그레이션되므로 초기 마이그레이션이 간소화됩니다. Azure를 사용하면 PaaS(Platform as a Service) 서비스를 활용하여 애플리케이션을 더 향상할 수 있습니다.
이는 일반적인 아키텍처 스타일이므로 엔지니어는 종종 이를 통해 더 높은 수준의 환경과 친숙함을 경험할 수 있습니다. 이 아키텍처를 선택하면 기존 기술 집합을 사용하여 새 아키텍처 패턴을 늘리지 않고도 애플리케이션을 배포할 수 있습니다.