아키텍처 스타일은 특정 특성을 공유하는 아키텍처 제품군입니다. 예를 들어 N 계층 은 일반적인 아키텍처 스타일입니다. 최근에는 마이크로 서비스 아키텍처가 선호되기 시작했습니다. 아키텍처 스타일에는 특정 기술을 사용할 필요가 없지만 일부 기술은 특정 아키텍처에 더 적합합니다. 예를 들어 컨테이너는 마이크로 서비스에 적합합니다.
클라우드 애플리케이션에서 일반적으로 발견되는 아키텍처 스타일 집합을 확인했습니다. 각 스타일에 대한 문서에는 다음 구성 요소가 포함됩니다.
- 스타일의 설명 및 논리 다이어그램
- 이 스타일을 선택하는 경우에 대한 권장 사항
- 이점, 과제 및 모범 사례
- 관련 Azure 서비스를 사용하는 권장 배포
스타일 둘러보기
이 섹션에서는 식별한 아키텍처 스타일에 대한 간략한 둘러보기 및 해당 용도에 대한 몇 가지 높은 수준의 고려 사항을 제공합니다. 이 목록은 완전하지 않습니다. 연결된 문서에서 자세한 내용을 읽어보세요.
N 계층
N 계층 은 애플리케이션을 논리 계층 및 물리적 계층으로 나누는 엔터프라이즈 애플리케이션의 기존 아키텍처입니다. 각 계층에는 특정 책임이 있으며 계층은 하위 계층으로만 호출하여 종속성을 관리합니다. 일반적인 계층에는 프레젠테이션, 비즈니스 논리 및 데이터 액세스가 포함됩니다.
N 계층 아키텍처는 이미 계층화된 아키텍처를 사용하는 기존 애플리케이션을 마이그레이션하는 데 적합합니다. 이 방법을 사용하려면 Azure로 이동할 때 최소한의 변경이 필요하며 온-프레미스 및 클라우드 구성 요소가 모두 포함된 혼합 환경을 지원합니다. 그러나 수평 계층화는 애플리케이션의 여러 부분에 영향을 주지 않고 변경 내용을 도입하기 어렵게 만들 수 있으며, 이는 빈번한 업데이트에 대한 민첩성을 제한합니다.
웹Queue-Worker
Web-Queue-Worker 는 웹 프런트 엔드, 메시지 큐 및 백 엔드 작업자로 구성된 아키텍처입니다. 웹 프런트 엔드는 HTTP 요청 및 사용자 상호 작용을 처리하고 작업자는 리소스 집약적 작업, 장기 실행 워크플로 또는 일괄 처리 작업을 수행합니다. 프런트 엔드와 작업자 간의 통신은 비동기 메시지 큐를 통해 발생합니다.
이 아키텍처는 리소스 집약적인 처리 요구 사항이 있는 비교적 간단한 도메인을 사용하는 애플리케이션에 적합합니다. App Service 및 Azure Functions와 같은 관리되는 Azure 서비스를 사용하여 쉽게 이해하고 배포할 수 있습니다. 프런트 엔드와 작업자를 독립적으로 확장하여 리소스 할당의 유연성을 제공할 수 있습니다. 그러나 신중하게 설계하지 않으면 두 구성 요소가 모두 크고 모놀리식이 될 수 있습니다.
마이크로 서비스
마이크로 서비스 아키텍처는 애플리케이션을 소규모 자율 서비스 컬렉션으로 분해합니다. 각 서비스는 제한된 컨텍스트 내에서 단일 비즈니스 기능을 구현하며 자체 데이터 스토리지와 함께 자체 포함됩니다. 서비스는 잘 정의된 API를 통해 통신하며 독립적으로 개발, 배포 및 확장할 수 있습니다.
마이크로 서비스를 사용하면 팀이 자율적으로 작업하고 릴리스 속도가 더 높은 빈번한 업데이트를 지원할 수 있습니다. 이 아키텍처는 자주 변경하고 혁신해야 하는 복잡한 도메인에 적합합니다. 그러나 서비스 검색, 데이터 일관성 및 분산 시스템 관리와 같은 영역에서 상당한 복잡성이 발생합니다. 성공하려면 완성도 높은 개발 및 DevOps 사례가 필요하므로 고급 기술 기능이 있는 조직에 더 적합합니다.
이벤트 기반 아키텍처
이벤트 기반 아키텍처는 이벤트 생산자가 이벤트 스트림을 생성하고 이벤트 소비자가 거의 실시간으로 해당 이벤트에 응답하는 게시-구독 모델을 사용합니다. 생산자와 소비자는 이벤트 채널 또는 브로커를 통해 통신이 이루어지면서 서로 분리됩니다. 이 아키텍처는 간단한 이벤트 처리와 복잡한 이벤트 패턴 분석을 모두 지원합니다.
이벤트 기반 아키텍처는 최소 대기 시간으로 실시간 처리가 필요한 시나리오에서 탁월합니다. 일부 예로는 대량의 스트리밍 데이터를 처리해야 하는 IoT 솔루션, 금융 거래 시스템 또는 애플리케이션이 있습니다. 이벤트 기반 아키텍처는 뛰어난 확장성 및 오류 격리를 제공하지만 분산 구성 요소 간에 보장된 배달, 이벤트 순서 지정 및 최종 일관성과 관련된 문제를 발생합니다.
빅 데이터
빅 데이터 아키텍처는 기존 데이터베이스 시스템에 비해 너무 크거나 복잡한 데이터의 수집, 처리 및 분석을 처리합니다. 이러한 아키텍처에는 일반적으로 데이터 스토리지(예: 데이터 레이크), 기록 분석을 위한 일괄 처리, 실시간 인사이트를 위한 스트림 처리, 보고 및 시각화를 위한 분석 데이터 저장소가 포함됩니다.
빅 데이터 아키텍처는 대규모 데이터 세트로부터 인사이트를 추출하거나, 기계 학습을 사용하여 예측 분석을 지원하거나, IoT 디바이스에서 실시간 스트리밍 데이터를 처리해야 하는 조직에 필수적입니다. 최신 구현에서는 종종 Microsoft Fabric과 같은 관리되는 서비스를 사용하여 빅 데이터 솔루션을 빌드하고 유지 관리하는 복잡성을 간소화합니다.
빅 컴퓨팅
빅 컴퓨팅 아키텍처는 계산 집약적인 작업을 위해 수백 또는 수천 개의 코어가 필요한 대규모 워크로드를 지원합니다. 작업은 여러 코어에서 동시에 실행되는 개별 작업으로 분할될 수 있으며, 각 태스크는 입력을 받고 처리하며 출력을 생성합니다. 작업은 독립적이거나(병렬로) 긴밀하게 결합되어 고속 통신이 필요할 수 있습니다.
대규모 컴퓨팅은 시뮬레이션, 재무 위험 모델링, 과학 컴퓨팅, 엔지니어링 스트레스 분석 및 3D 렌더링에 필수적입니다. Azure는 관리형 빅 컴퓨팅 워크로드를 위한 Azure Batch 또는 보다 전통적인 클러스터 관리를 위한 HPC 팩과 같은 옵션을 제공합니다. 이러한 아키텍처는 필요에 따라 성능을 폭증시키고 필요할 때 수천 개의 코어로 확장할 수 있습니다.
제약 조건으로 아키텍처 스타일
아키텍처 스타일은 표시할 수 있는 요소 집합과 해당 요소 간의 허용된 관계를 포함하여 디자인에 제약 조건을 적용합니다. 제약 조건은 선택의 우주를 제한하여 아키텍처의 "모양"을 안내합니다. 아키텍처가 특정 스타일의 제약 조건을 준수하면 특정 바람직한 속성이 나타납니다.
예를 들어 마이크로 서비스의 제약 조건은 다음과 같습니다.
- 서비스는 단일 책임을 나타냅니다.
- 모든 서비스는 다른 서비스와 독립적입니다.
- 데이터는 데이터를 소유한 서비스에 비공개입니다. 서비스는 데이터를 공유하지 않습니다.
이러한 제약 조건을 준수하면 다음 작업을 수행할 수 있는 시스템이 제공됩니다.
- 서비스를 독립적으로 배포합니다.
- 결함을 격리합니다.
- 더 자주 업데이트를 푸시합니다.
- 애플리케이션에 새로운 기술을 더 쉽게 도입합니다.
각 아키텍처 스타일에는 고유한 절충이 있습니다. 아키텍처 스타일을 선택하기 전에 기본 원칙과 제약 조건을 이해해야 합니다. 이 점을 이해하지 못하면 전체 혜택을 실현하지 않고도 피상적으로 스타일을 준수하는 디자인을 만들 위험이 있습니다. 구현하는 방법보다 특정 스타일을 선택하는 이유에 더 집중합니다. 실용적이어야 합니다. 때로는 건축 순도를 쫓는 것보다 제약 조건을 완화하는 것이 좋습니다.
아키텍처 스타일의 선택은 정보에 입각한 워크로드 관련자의 입력을 통해 선택하는 것이 이상적입니다. 워크로드 팀은 해결 중인 문제의 특성을 식별하여 시작해야 합니다. 그런 다음 핵심 비즈니스 동인 및 해당 아키텍처 특성( 비기능 요구 사항이라고도 함)을 정의하고 우선 순위를 지정해야 합니다. 예를 들어 출시 시간이 중요한 경우 팀은 유지 관리 효율성, 테스트 용이성 및 안정성을 우선 순위로 지정하여 신속한 배포를 가능하게 할 수 있습니다. 팀에 엄격한 예산 제약 조건이 있는 경우 타당성 및 단순성이 우선할 수 있습니다. 아키텍처 스타일을 선택하고 유지하는 것은 일회성 작업이 아닙니다. 지속적인 측정, 유효성 검사 및 구체화가 필요합니다. 나중에 아키텍처 방향을 변경하는 것은 비용이 많이 들 수 있으므로 장기적인 효율성을 지원하고 위험을 줄이기 위해 더 많은 노력을 선불로 투자하는 것이 좋습니다.
다음 표에는 각 스타일이 종속성을 관리하는 방법과 각 스타일에 가장 적합한 도메인 유형이 요약되어 있습니다.
| 아키텍처 스타일 | 종속성 관리 | 도메인 유형 |
|---|---|---|
| N 계층 | 수평 계층을 서브넷으로 나눕니다. | 기존 비즈니스 도메인입니다. 업데이트 빈도가 낮습니다. |
| Web-Queue-Worker | 비동기 메시징으로 분리된 프런트 엔드 및 백 엔드 작업입니다. | 리소스를 많이 사용하는 작업이 있는 비교적 간단한 도메인입니다. |
| 마이크로 서비스 | API를 통해 서로를 호출하는 수직(기능적으로) 분해된 서비스입니다. | 복잡한 도메인. 자주 업데이트합니다. |
| 이벤트 기반 아키텍처 | 생산자 또는 소비자. 각 하위 시스템에 대한 독립 보기입니다. | IoT(사물 인터넷) 및 실시간 시스템. |
| 빅 데이터 | 거대한 데이터 세트를 작은 청크로 나눕니다. 로컬 데이터 세트에 대한 병렬 처리입니다. | 일괄 처리 및 실시간 데이터 분석. 기계 학습을 사용하여 예측 분석 |
| 빅 컴퓨팅 | 수천 개의 코어에 데이터 할당. | 시뮬레이션과 같은 계산 집약적 도메인 |
과제 및 이점 고려
제약 조건은 도전을 안겨주므로 이러한 스타일을 채택할 때 절충안을 이해하는 것이 중요합니다. 이 하위 도메인 및 제한된 컨텍스트의 경우 아키텍처 스타일의 이점이 문제보다 중요한지 확인합니다.
아키텍처 스타일을 선택할 때 다음과 같은 유형의 문제를 고려합니다.
복잡성: 아키텍처의 복잡성은 도메인과 일치해야 합니다. 너무 단순하다면 종속성이 잘 관리되지 않고 구조가 무너질 수 있는 큰 진흙 공이 발생할 수 있습니다.
비동기 메시징 및 최종 일관성: 비동기 메시징은 메시지를 다시 시도 할 수 있으므로 서비스를 분리하고 안정성을 향상시키는 데 사용됩니다. 또한 확장성을 향상시킵니다. 그러나 비동기 메시징은 최종 일관성 및 중복 메시지의 가능성을 처리하는 데 어려움을 줍니다.
서비스 간 통신: 애플리케이션을 별도의 서비스로 분해하면 통신 오버헤드가 증가할 수 있습니다. 마이크로 서비스 아키텍처에서 이러한 오버헤드는 대기 시간 문제 또는 네트워크 정체를 초래하는 경우가 많습니다.
관리: 애플리케이션 관리에는 모니터링, 업데이트 배포 및 운영 상태 유지 관리와 같은 작업이 포함됩니다.
관련 리소스
- Azure 애플리케이션을 위한 10가지 설계 원칙