다음을 통해 공유

아키텍처 스타일

  • 아티클

아키텍처 스타일이란 특정한 특성을 공유하는 아키텍처의 집합입니다. 예를 들어, 일반적인 아키텍처 스타일로 N 계층이 있습니다. 최근에는 마이크로서비스 아키텍처가 각광을 받기 시작했습니다. 아키텍처 스타일이 특정 기술의 사용을 필요로 하는 것은 아니지만, 특정 아키텍처에 일부 기술이 적절히 적용될 수 있습니다. 예를 들어 컨테이너는 기본적으로 마이크로 서비스와 잘 어울립니다.

우리는 클라우드 애플리케이션에서 흔히 발견되는 아키텍처 스타일 집합을 확인했습니다. 각 스타일에 대한 문서의 내용은 다음과 같습니다.

  • 스타일에 대한 설명 및 논리 다이어그램.
  • 스타일 선택 시기 추천.
  • 이점, 과제 및 모범 사례.
  • 관련 Azure 서비스를 사용한 권장되는 배포

스타일 둘러보기

이 섹션에서는 우리가 확인한 아키텍처 스타일 및 각 아키텍처 스타일을 사용할 때 고려해야 할 주요 사항을 신속하게 살펴보겠습니다. 목록은 완전하지 않습니다. 자세한 내용은 링크 연결된 항목을 참조하세요.

N 계층

N 계층 아키텍처 스타일의 논리 다이어그램

N 계층 은 엔터프라이즈 애플리케이션에 사용되는 전통적인 아키텍처입니다. 종속성은 애플리케이션을 프레젠테이션, 비즈니스 논리, 데이터 액세스 등의 논리 함수를 수행하는 레이어로 분할하여 관리됩니다. 레이어는 그 아래에 있는 레이어만 호출할 수 있습니다. 그러나 이와 같은 가로 방향 레이어는 문제가 될 수 있습니다. 애플리케이션의 한 부분을 변경할 때 다른 나머지 부분을 건드리지 않고는 변경 내용을 적용하기가 어렵기 때문입니다. 따라서 자주 업데이트하기가 어렵기 때문에 새 기능을 신속하게 추가할 수 없습니다.

N 계층은 기본적으로 이미 계층화된 아키텍처를 사용하는 기존 애플리케이션 마이그레이션에 적합합니다. 이러한 이유로 N 계층은 IaaS(Infrastructure as a Service) 솔루션, 또는 IaaS와 관리 서비스를 혼용하는 애플리케이션에서 가장 흔히 볼 수 있습니다.

웹-큐-작업자

웹 큐 작업자 아키텍처 스타일의 논리 다이어그램

순수한 PaaS 솔루션을 개발하려면 웹-큐-작업자 아키텍처를 고려해 보세요. 이 스타일의 경우 애플리케이션의 웹 프런트 엔드는 HTTP 요청을 처리하고 백 엔드 작업자는 CPU 집약적인 작업이나 장기 실행 작업을 수행합니다. 프런트 엔드는 비동기 메시지 큐를 통해 작업자와 통신합니다.

웹-큐-작업자는 리소스 집약적 작업이 약간 있는 비교적 단순한 도메인에 적합합니다. N 계층과 마찬가지로, 이 아키텍처는 이해하기 쉽습니다. 관리 서비스를 사용하면 배포 및 운영이 간단합니다. 하지만 복잡한 도메인의 경우 종속성 관리가 어려울 수 있습니다. 프런트 엔드 및 작업자가 유지 관리 및 업데이트가 어려운 커다란 모놀리식(Monolithic) 구성 요소로 쉽게 변할 수 있기 때문입니다. 이로 인해 N 계층과 마찬가지로, 업데이트 빈도가 감소되고 혁신이 제한됩니다.

마이크로 서비스

마이크로서비스 아키텍처 스타일의 논리 다이어그램

애플리케이션에 복잡한 도메인이 있는 경우 마이크로서비스 아키텍처로 전환하는 것을 고려해 보세요. 마이크로 서비스 애플리케이션은 여러 작은 독립 서비스로 구성됩니다. 각 서비스는 단일 비즈니스 기능을 구현합니다. 서비스는 서로 느슨하게 결합되며, API 계약을 통해 통신합니다.

각 서비스는 소규모의 집중 개발 팀에서 구축할 수 있습니다. 개별 서비스를 배포할 때 팀 간의 조정이 거의 필요 없으므로 업데이트를 자주 수행할 수 있습니다. 마이크로 서비스 아키텍처는 N 계층 또는 웹-큐-작업자보다 빌드 및 관리 방법이 좀 더 복잡합니다. 성숙한 개발 및 DevOps 문화가 필요합니다. 하지만 이 스타일을 제대로 수행하기만 한다면 보다 빠른 릴리스 개발속도, 보다 빠른 혁신, 보다 복원력 있는 아키텍처로 이어질 수 있습니다.

이벤트 기반 아키텍처

이벤트 기반 아키텍처 스타일의 다이어그램

이벤트 기반 아키텍처 는 생산자가 이벤트를 게시하고 소비자가 그 이벤트를 구독하는 게시-구독(pub-sub) 모델을 사용합니다. 생산자는 소비자와 독립적 관계이며, 각 소비자는 서로 독립적 관계입니다.

IoT 솔루션처럼 대규모 데이터를 수집하여 처리하고 대기 시간이 매우 짧은 애플리케이션에는 이벤트 기반 아키텍처를 고려해 보세요. 이 스타일은 여러 하위 시스템이 동일한 이벤트 데이터에서 다양한 종류의 처리 작업을 수행해야 하는 경우도 유용합니다.

빅 데이터, 빅 컴퓨팅

빅 데이터 아키텍처 스타일의 논리 다이어그램

빅 데이터 및 빅 컴퓨팅 은 특정 프로필에 적합한 특수 아키텍처 스타일입니다. 빅 데이터는 매우 거대한 데이터 세트를 여러 청크로 분할한 후 전체 집합에 걸쳐 병렬 처리를 수행하여 데이터를 분석 및 보고합니다. HPC(고성능 컴퓨팅)라고도 하는 빅 컴퓨팅(Big compute)은 수많은(수천 개) 코어에 걸쳐 병렬 계산을 수행합니다. 도메인에는 시뮬레이션, 모델링 및 3D 렌더링이 포함됩니다.

아키텍처 스타일의 제약 조건

아키텍처 스타일에는 표시할 수 있는 요소 집합 및 그러한 요소 사이에 허용되는 관계 등의 디자인 제약 조건이 따릅니다. 제약 조건은 선택 범위를 제한하여 아키텍처의 "모양"을 좌우합니다. 아키텍처가 특정 스타일의 제약 조건을 준수하면 바람직한 특정 속성이 드러납니다.

예를 들어 마이크로 서비스의 제약 조건은 다음과 같습니다.

  • 하나의 서비스는 단일 역할을 담당합니다.
  • 모든 서비스는 서로 독립적입니다.
  • 데이터는 해당 데이터를 소유하는 서비스에 대한 프라이빗입니다. 서비스는 데이터를 공유하지 않습니다.

이러한 제약 조건을 준수하면 서비스를 독립적으로 배포할 수 있고, 오류가 격리되고, 업데이트를 자주할 수 있고, 새 기술을 애플리케이션에 쉽게 도입할 수 있는 시스템이 구성됩니다.

각 아키텍처 스타일에는 고유한 장부가 있습니다. 따라서 아키텍처 스타일을 선택하기 전에 해당 스타일의 기본 원칙과 제약 조건을 이해해야 합니다. 그렇지 않으면 디자인이 표면적인 수준에서는 스타일을 준수하겠지만 해당 스타일의 잠재력을 모두 끌어내지는 못하는 결과를 초래할 수 있습니다. 구현하는 방법보다 특정 아키텍처 스타일을 선택하는 이유에 더 많은 주의를 기울여야 합니다. 실용성도 중요합니다. 즉, 아키텍처의 순수성(purity)을 고집하기 보다는 제약 조건을 완화하는 것이 더 좋은 경우도 있습니다.

적절한 아키텍처 스타일을 선택하는 것은 정보에 입각한 워크로드 관련자의 합의로 이상적으로 수행되어야 합니다. 워크로드 팀은 먼저 해결하려는 문제의 특성을 식별해야 합니다. 그런 다음 비즈니스 드라이버와 해당 아키텍처 특성(비기능적 요구 사항이라고도 함)을 식별한 다음 우선 순위를 지정해야 합니다. 예를 들어 출시 시간이 더 짧아야 하는 경우 신속한 배포 기능으로 유지 관리 효율성, 테스트 가능성 및 안정성을 우선시할 수 있습니다. 또는 워크로드 팀에 예산이 제한된 경우 타당성 및 단순성의 우선 순위를 지정할 수 있습니다. 아키텍처 스타일을 선택하고 유지 관리하는 것은 일회성 작업이 아니라 지속적인 접근 방식입니다. 아키텍처는 시간이 지남에 따라 지속적으로 측정, 유효성 검사 및 미세 조정되어야 합니다. 일반적으로 아키텍처 스타일을 전환하는 데 상당한 비용이 들기 때문에 장기적인 팀 효율성과 위험 완화를 위해 더 많은 노력을 정당화할 수 있습니다.

다음 표에는 각 스타일이 종속성을 관리하는 방법과 각 스타일에 가장 적합한 도메인 유형이 요약되어 있습니다.

아키텍처 스타일 종속성 관리 도메인 유형
N 계층 서브넷으로 분할되는 가로 계층 전통적인 비즈니스 도메인. 업데이트 빈도가 낮습니다.
웹-큐-작업자 비동기 메시징을 통해 분리되는 프런트 및 백 엔드 작업. 일부 리소스 집약적인 작업이 있는 비교적 간단한 도메인.
마이크로 서비스 API를 통해 서로 호출하는 세로 방향으로(기능적으로) 분리된 서비스. 복잡한 도메인. 업데이트가 빈번합니다.
이벤트 기반 아키텍처 생산자/소비자. 하위 시스템마다 독립적 보기. IoT 및 실시간 시스템
빅 데이터 큰 데이터 세트를 작은 청크로 분할. 로컬 데이터 세트의 병렬 처리. 일괄 처리 및 실시간 데이터 분석. ML을 사용한 예측 분석.
빅 컴퓨팅 수천 개의 코어에 데이터 할당. 시뮬레이션 같은 컴퓨팅 집약적 도메인.

과제 및 이점 고려

제약 조건은 그에 따른 과제가 있으므로 스타일을 채택할 때 반대 급부를 이해하는 것이 중요합니다. 아키텍처 스타일의 이점이 이 하위 도메인 및 제한된 컨텍스트에 대한 과제보다 큽니까?

다음은 아키텍처 스타일을 선택할 때 고려해야 할 몇 가지 도전 과제입니다.

  • 복잡성. 아키텍처의 복잡성을 감수하고 도메인에 사용할 만한 가치가 있습니까? 정반대로, 도메인에 사용하기에 스타일이 너무 단순하지는 않습니까? 이 경우 아키텍처가 종속성을 깔끔하게 관리하는 데 도움이 되지 않기 때문에 결국에는 "엉망진창"이 될 위험이 있습니다.

  • 비동기 메시지 및 결과적 일관성. 비동기 메시지를 사용하여 서비스를 분리하면 안정성(메시지를 검색할 수 있으므로) 및 확장성을 높일 수 있습니다. 그러나 이로 인해 메시지의 중복 가능성뿐만 아니라 궁극적인 일관성을 처리하는 데에도 어려움이 생깁니다.

  • 서비스 간 통신. 애플리케이션을 별도의 서비스로 분해하면 서비스 간 통신에서 허용할 수 없는 대기 시간이 발생하거나 네트워크 정체가 발생할(예를 들어 마이크로 서비스 아키텍처에서) 위험이 있습니다.

  • 관리 효율성. 애플리케이션을 관리, 모니터링, 배포, 업데이트하는 방법이 얼마나 어렵습니까?