아키텍처 스타일Architecture styles

아키텍처 스타일이란 특정한 특성을 공유하는 아키텍처의 집합입니다.An architecture style is a family of architectures that share certain characteristics. 예를 들어, 일반적인 아키텍처 스타일로 N 계층이 있습니다.For example, N-tier is a common architecture style. 최근에는 마이크로서비스 아키텍처가 각광을 받기 시작했습니다.More recently, microservice architectures have started to gain favor. 아키텍처 스타일이 특정 기술의 사용을 필요로 하는 것은 아니지만, 특정 아키텍처에 일부 기술이 적절히 적용될 수 있습니다.Architecture styles don't require the use of particular technologies, but some technologies are well-suited for certain architectures. 예를 들어 컨테이너는 기본적으로 마이크로 서비스와 잘 어울립니다.For example, containers are a natural fit for microservices.

우리는 클라우드 애플리케이션에서 흔히 발견되는 아키텍처 스타일 집합을 확인했습니다.We have identified a set of architecture styles that are commonly found in cloud applications. 각 스타일에 대한 문서의 내용은 다음과 같습니다.The article for each style includes:

  • 스타일에 대한 설명 및 논리 다이어그램.A description and logical diagram of the style.
  • 스타일 선택 시기 추천.Recommendations for when to choose this style.
  • 이점, 과제 및 모범 사례.Benefits, challenges, and best practices.
  • 관련 Azure 서비스를 사용한 권장되는 배포A recommended deployment using relevant Azure services.

스타일 둘러보기A quick tour of the styles

이 섹션에서는 우리가 확인한 아키텍처 스타일 및 각 아키텍처 스타일을 사용할 때 고려해야 할 주요 사항을 신속하게 살펴보겠습니다.This section gives a quick tour of the architecture styles that we've identified, along with some high-level considerations for their use. 자세한 내용은 링크 연결된 항목을 참조하세요.Read more details in the linked topics.

N 계층N-tier

N 계층 은 엔터프라이즈 애플리케이션에 사용되는 전통적인 아키텍처입니다.N-tier is a traditional architecture for enterprise applications. 종속성은 애플리케이션을 프레젠테이션, 비즈니스 논리, 데이터 액세스 등의 논리 함수를 수행하는 레이어로 분할하여 관리됩니다.Dependencies are managed by dividing the application into layers that perform logical functions, such as presentation, business logic, and data access. 레이어는 그 아래에 있는 레이어만 호출할 수 있습니다.A layer can only call into layers that sit below it. 그러나 이와 같은 가로 방향 레이어는 문제가 될 수 있습니다.However, this horizontal layering can be a liability. 애플리케이션의 한 부분을 변경할 때 다른 나머지 부분을 건드리지 않고는 변경 내용을 적용하기가 어렵기 때문입니다.It can be hard to introduce changes in one part of the application without touching the rest of the application. 따라서 자주 업데이트하기가 어렵기 때문에 새 기능을 신속하게 추가할 수 없습니다.That makes frequent updates a challenge, limiting how quickly new features can be added.

N 계층은 기본적으로 이미 계층화된 아키텍처를 사용하는 기존 애플리케이션 마이그레이션에 적합합니다.N-tier is a natural fit for migrating existing applications that already use a layered architecture. 이러한 이유로 N 계층은 IaaS(Infrastructure as a Service) 솔루션, 또는 IaaS와 관리 서비스를 혼용하는 애플리케이션에서 가장 흔히 볼 수 있습니다.For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.

웹-큐-작업자Web-Queue-Worker

순수한 PaaS 솔루션을 개발하려면 웹-큐-작업자 아키텍처를 고려해 보세요.For a purely PaaS solution, consider a Web-Queue-Worker architecture. 이 스타일의 경우 애플리케이션의 웹 프런트 엔드는 HTTP 요청을 처리하고 백 엔드 작업자는 CPU 집약적인 작업이나 장기 실행 작업을 수행합니다.In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations. 프런트 엔드는 비동기 메시지 큐를 통해 작업자와 통신합니다.The front end communicates to the worker through an asynchronous message queue.

웹-큐-작업자는 리소스 집약적 작업이 약간 있는 비교적 단순한 도메인에 적합합니다.Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. N 계층과 마찬가지로, 이 아키텍처는 이해하기 쉽습니다.Like N-tier, the architecture is easy to understand. 관리 서비스를 사용하면 배포 및 운영이 간단합니다.The use of managed services simplifies deployment and operations. 하지만 복잡한 도메인의 경우 종속성 관리가 어려울 수 있습니다.But with complex domains, it can be hard to manage dependencies. 프런트 엔드 및 작업자가 유지 관리 및 업데이트가 어려운 커다란 모놀리식(Monolithic) 구성 요소로 쉽게 변할 수 있기 때문입니다.The front end and the worker can easily become large, monolithic components that are hard to maintain and update. 이로 인해 N 계층과 마찬가지로, 업데이트 빈도가 감소되고 혁신이 제한됩니다.As with N-tier, this can reduce the frequency of updates and limit innovation.

마이크로 서비스Microservices

애플리케이션에 복잡한 도메인이 있는 경우 마이크로서비스 아키텍처로 전환하는 것을 고려해 보세요.If your application has a more complex domain, consider moving to a Microservices architecture. 마이크로 서비스 애플리케이션은 여러 작은 독립 서비스로 구성됩니다.A microservices application is composed of many small, independent services. 각 서비스는 단일 비즈니스 기능을 구현합니다.Each service implements a single business capability. 서비스는 서로 느슨하게 결합되며, API 계약을 통해 통신합니다.Services are loosely coupled, communicating through API contracts.

각 서비스는 소규모의 집중 개발 팀에서 구축할 수 있습니다.Each service can be built by a small, focused development team. 개별 서비스를 배포할 때 팀 간의 조정이 거의 필요 없으므로 업데이트를 자주 수행할 수 있습니다.Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates. 마이크로 서비스 아키텍처는 N 계층 또는 웹-큐-작업자보다 빌드 및 관리 방법이 좀 더 복잡합니다.A microservice architecture is more complex to build and manage than either N-tier or web-queue-worker. 성숙한 개발 및 DevOps 문화가 필요합니다.It requires a mature development and DevOps culture. 하지만 이 스타일을 제대로 수행하기만 한다면 보다 빠른 릴리스 개발속도, 보다 빠른 혁신, 보다 복원력 있는 아키텍처로 이어질 수 있습니다.But done right, this style can lead to higher release velocity, faster innovation, and a more resilient architecture.

이벤트 기반 아키텍처Event-driven architecture

이벤트 기반 아키텍처 는 생산자가 이벤트를 게시하고 소비자가 그 이벤트를 구독하는 게시-구독(pub-sub) 모델을 사용합니다.Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. 생산자는 소비자와 독립적 관계이며, 각 소비자는 서로 독립적 관계입니다.The producers are independent from the consumers, and consumers are independent from each other.

IoT 솔루션처럼 대규모 데이터를 수집하여 처리하고 대기 시간이 매우 짧은 애플리케이션에는 이벤트 기반 아키텍처를 고려해 보세요.Consider an event-driven architecture for applications that ingest and process a large volume of data with very low latency, such as IoT solutions. 이 스타일은 여러 하위 시스템이 동일한 이벤트 데이터에서 다양한 종류의 처리 작업을 수행해야 하는 경우도 유용합니다.The style is also useful when different subsystems must perform different types of processing on the same event data.

빅 데이터, 빅 컴퓨팅Big Data, Big Compute

빅 데이터빅 컴퓨팅 은 특정 프로필에 적합한 특수 아키텍처 스타일입니다.Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. 빅 데이터는 매우 거대한 데이터 세트를 여러 청크로 분할한 후 전체 집합에 걸쳐 병렬 처리를 수행하여 데이터를 분석 및 보고합니다.Big data divides a very large dataset into chunks, performing parallel processing across the entire set, for analysis and reporting. HPC(고성능 컴퓨팅)라고도 하는 빅 컴퓨팅(Big compute)은 수많은(수천 개) 코어에 걸쳐 병렬 계산을 수행합니다.Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. 도메인에는 시뮬레이션, 모델링 및 3D 렌더링이 포함됩니다.Domains include simulations, modeling, and 3-D rendering.

아키텍처 스타일의 제약 조건Architecture styles as constraints

아키텍처 스타일에는 표시할 수 있는 요소 집합 및 그러한 요소 사이에 허용되는 관계 등의 디자인 제약 조건이 따릅니다.An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. 제약 조건은 선택 범위를 제한하여 아키텍처의 "모양"을 좌우합니다.Constraints guide the "shape" of an architecture by restricting the universe of choices. 아키텍처가 특정 스타일의 제약 조건을 준수하면 바람직한 특정 속성이 드러납니다.When an architecture conforms to the constraints of a particular style, certain desirable properties emerge.

예를 들어 마이크로 서비스의 제약 조건은 다음과 같습니다.For example, the constraints in microservices include:

  • 하나의 서비스는 단일 역할을 담당합니다.A service represents a single responsibility.
  • 모든 서비스는 서로 독립적입니다.Every service is independent of the others.
  • 데이터는 해당 데이터를 소유하는 서비스에 대한 프라이빗입니다.Data is private to the service that owns it. 서비스는 데이터를 공유하지 않습니다.Services do not share data.

이러한 제약 조건을 준수하면 서비스를 독립적으로 배포할 수 있고, 오류가 격리되고, 업데이트를 자주할 수 있고, 새 기술을 애플리케이션에 쉽게 도입할 수 있는 시스템이 구성됩니다.By adhering to these constraints, what emerges is a system where services can be deployed independently, faults are isolated, frequent updates are possible, and it's easy to introduce new technologies into the application.

아키텍처 스타일을 선택하기 전에 해당 스타일의 기본 원칙 및 제약 조건을 이해해야 합니다.Before choosing an architecture style, make sure that you understand the underlying principles and constraints of that style. 그렇지 않으면 디자인이 표면적인 수준에서는 스타일을 준수하겠지만 해당 스타일의 잠재력을 모두 끌어내지는 못하는 결과를 초래할 수 있습니다.Otherwise, you can end up with a design that conforms to the style at a superficial level, but does not achieve the full potential of that style. 실용성도 중요합니다.It's also important to be pragmatic. 즉, 아키텍처의 순수성(purity)을 고집하기 보다는 제약 조건을 완화하는 것이 더 좋은 경우도 있습니다.Sometimes it's better to relax a constraint, rather than insist on architectural purity.

다음 표에는 각 스타일이 종속성을 관리하는 방법과 각 스타일에 가장 적합한 도메인 유형이 요약되어 있습니다.The following table summarizes how each style manages dependencies, and the types of domain that are best suited for each.

아키텍처 스타일Architecture style 종속성 관리Dependency management 도메인 유형Domain type
N 계층N-tier 서브넷으로 분할되는 가로 계층Horizontal tiers divided by subnet 전통적인 비즈니스 도메인.Traditional business domain. 업데이트 빈도가 낮습니다.Frequency of updates is low.
웹-큐-작업자Web-Queue-Worker 비동기 메시징을 통해 분리되는 프런트 및 백 엔드 작업.Front and backend jobs, decoupled by async messaging. 일부 리소스 집약적인 작업이 있는 비교적 간단한 도메인.Relatively simple domain with some resource intensive tasks.
마이크로 서비스Microservices API를 통해 서로 호출하는 세로 방향으로(기능적으로) 분리된 서비스.Vertically (functionally) decomposed services that call each other through APIs. 복잡한 도메인.Complicated domain. 업데이트가 빈번합니다.Frequent updates.
이벤트 기반 아키텍처.Event-driven architecture. 생산자/소비자.Producer/consumer. 하위 시스템마다 독립적 보기.Independent view per sub-system. IoT 및 실시간 시스템IoT and real-time systems
빅 데이터Big data 큰 데이터 세트를 작은 청크로 분할.Divide a huge dataset into small chunks. 로컬 데이터 세트의 병렬 처리.Parallel processing on local datasets. 일괄 처리 및 실시간 데이터 분석.Batch and real-time data analysis. ML을 사용한 예측 분석.Predictive analysis using ML.
빅 컴퓨팅Big compute 수천 개의 코어에 데이터 할당.Data allocation to thousands of cores. 시뮬레이션 같은 계산 집약적 도메인.Compute intensive domains such as simulation.

과제 및 이점 고려Consider challenges and benefits

제약 조건은 그에 따른 과제가 있으므로 스타일을 채택할 때 반대 급부를 이해하는 것이 중요합니다.Constraints also create challenges, so it's important to understand the trade-offs when adopting any of these styles. 아키텍처 스타일의 이점이 이 하위 도메인 및 제한된 컨텍스트에 대한 과제보다 큽니까?Do the benefits of the architecture style outweigh the challenges, for this subdomain and bounded context.

다음은 아키텍처 스타일을 선택할 때 고려해야 할 몇 가지 도전 과제입니다.Here are some of the types of challenges to consider when selecting an architecture style:

  • 복잡성.Complexity. 아키텍처의 복잡성을 감수하고 도메인에 사용할 만한 가치가 있습니까?Is the complexity of the architecture justified for your domain? 정반대로, 도메인에 사용하기에 스타일이 너무 단순하지는 않습니까?Conversely, is the style too simplistic for your domain? 이 경우 아키텍처가 종속성을 깔끔하게 관리하는 데 도움이 되지 않기 때문에 결국에는 "엉망진창"이 될 위험이 있습니다.In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.

  • 비동기 메시지 및 결과적 일관성.Asynchronous messaging and eventual consistency. 비동기 메시지를 사용하여 서비스를 분리하면 안정성(메시지를 검색할 수 있으므로) 및 확장성을 높일 수 있습니다.Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. 그러나 이로 인해 메시지의 중복 가능성뿐만 아니라 궁극적인 일관성을 처리하는 데에도 어려움이 생깁니다.However, this also creates challenges in handling eventual consistency, as well as the possibility of duplicate messages.

  • 서비스 간 통신.Inter-service communication. 애플리케이션을 별도의 서비스로 분해하면 서비스 간 통신에서 허용할 수 없는 대기 시간이 발생하거나 네트워크 정체가 발생할(예를 들어 마이크로 서비스 아키텍처에서) 위험이 있습니다.As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).

  • 관리 효율성.Manageability. 애플리케이션을 관리, 모니터링, 배포, 업데이트하는 방법이 얼마나 어렵습니까?How hard is it to manage the application, monitor, deploy updates, and so on?