애플리케이션 아키텍처 가이드

애플리케이션을 만들 때 확장성, 복원력 및 가용성을 고려하지 않을 수 없습니다. 

따라서 이러한 요소들을 고려하여 애플리케이션을 디자인하는 방법을 알아보겠습니다.

 

최근 애플리케이션은 모노리틱 프로그램에서 보다 작은 분산형 마이크로서비스로 분해되고 있습니다. 이러한 흐름으로 작업은 병렬 및 비동기식으로 수행되므로, 애플리케이션은 복원력이 있어야 합니다. 배포는 자동화되고 예측이 가능해야하며 모니터링을 통한 원격 분석은 시스템의 상태를 이해하는데 필수적입니다. 

 

(1) 아키텍처 스타일

먼저 아키텍처 스타일을 결정해야합니다. 그러기 위해서는 아키텍처 디자인 특성에 대해 파악하고 있어야 합니다.

 

아키텍처 스타일	종속성 관리	도메인 유형
N 계층	서브넷으로 분할되는 가로 계층	전통적인 비즈니스 도메인 (업데이트 빈도가 낮음)
웹-큐-작업자	비동기 메시징을 통해 분리되는 프런트와 백 엔드 작업	일부 리소스 집약적인 작업이 있는 비교적 간단한 도메인
마이크로 서비스	API를 통해 서로 호출하는 기능적으로 분리된 서비스	복잡한 도메인, 업데이트가 빈번함
이벤트 기반 아키텍처	하위 시스템마다 독립적으로 관리	IoT 및 실시간 시스템
빅 데이터	큰 데이터 세트를 작은 청크로 분할하고 로컬 데이터 셋을 병렬 처리함	배치 처리 및 실시간 데이터 분석 ML을 사용한 예측 분석

 

1. N 계층 아키텍처 

애플리케이션을 논리 레이어와 물리적 계층으로 나눕니다.

 

애플리케이션 기본 3계층

• 프레젠테이션 계층
• 중간 계층 (선택 사항)
• 데이터베이스 계층

 

다른 기능 영역을 캡슐화하는 두 개의 중간 계층이 있는 애플리케이션[1]

 

레이어를 통해 책임을 구분하고 종속성을 관리하는 방법이며, 상위 레이어는 하위 레이어의 서비스를 사용할 수 있지만 하위 레이어는 상위 레이어의 서비스를 사용할 수 없는 구조입니다. 

 

계층은 물리적으로 분리되어 별도의 시스템으로 실행되며, 계층은 다른 계층을 직접 호출하거나 비동기 메시지(메시지 큐)를 사용할 수 있습니다. 여러 레이어가 동일한 계층에 호스트될 수도 있는데, 계층을 물리적으로 분리하면 확장성과 복원력이 향상되지만 추가 네트워크 통신으로 인해 대기 시간이 증가합니다.

 

1.1 폐쇄형 레이어 아키텍처

레이어가 바로 아래에 있는 다음 레이어만 호출할 수 있습니다.

레이어 간의 종속성을 제한하지만, 불필요한 네트워크 트래픽을 줄일 수 있는 아키텍처 패턴입니다.

 

1.2 개방형 레이어 아키텍처

레이어가 아래에 있는 모든 레이어를 호출할 수 있습니다.

 

구현 방법

각 계층을 개별 VM 집합에서 실행되는 애플리케이션으로 구현합니다. 캐싱, 메시징, 데이터 스토리지와 같은 일부 아키텍처 부분은 관리형 서비스를 사용하는 것이 유리한 경우가 많습니다.

 

고려할 케이스

• 단순 웹 애플리케이션

• 최소 리팩터링을 통한 퍼블릭 클라우드로의 마이그레이션

• 하이브리드 클라우드 개발 환경

 

고려할 점

• 데이터베이스에서 유용한 작업 없이 대기 시간만 늘리는 중간 계층이 생성되기 쉬움

• 기능의 독립적 배포가 불가능

• 대규모 시스템에서 네트워크 보안을 관리하기 어려울 수 있음

• 가로 방향 레이어가 문제가 될 수 있음
  • 한 부분을 변경할 때 다른 나머지를 건드리지 않고 변경하기 어렵기 때문
  • 자주 업데이트 하기 어려움 (새 기능을 신속하게 추가할 수 없다.)

 

BEST PRACTICE

• Autoscaling을 사용하여 부하 처리를 합니다. 

• 비동기 메시징을 사용하여 계층을 분리합니다.

• 프런트 엔드와 인터넷 사이에 WAF(웹 애플리케이션 방화벽)를 배치합니다.

• 각 계층에 자체 서브넷을 배치하고 서브넷을 보안 경계로 사용합니다.

  • 각 계층은 자체 서브넷 안에 배치되므로 내부 IP 주소는 동일한 주소 범위 내에 있습니다.

• 중간 계층의 요청만 허용하고 데이터 계층에 대한 액세스를 제한합니다.

  • 데이터베이스 계층은 비즈니스 계층의 액세스만 허용합니다.

 

권장 아키텍처 다이어그램[2]

 

2. 웹-큐-작업자

애플리케이션의 웹 프론트 엔드는 HTTP 요청을 처리하고, 백 엔드 작업은 Worker에 의해 CPU 집약적인 작업이나 장기 실행 작업을 수행하게 됩니다. 그리고 프론트 엔드는 비동기 메시지 큐를 통해 개발자와 통신합니다.

 

비교적 간단한 아키텍쳐이며, 배포와 관리가 쉽습니다. 비동기식 메시지를 통해서 작업자와 프런트 엔드를 분리시킨 구조를 가지고 있습니다. 

 

웹-큐-작업자 아키텍처 다이어그램[3]

구성요소

• 하나 이상의 데이터베이스

• 데이터베이스의 값을 저장하는 캐시

• 정적 콘텐츠를 제공하기 위한 CDN(Content Delievery Network)

 

고려할 케이스

• 비교적 간단한 도메인을 가진 응용 프로그램

• 장기 실행되는 워크플로, 일괄처리 작업이 일부 포함된 응용 프로그램

 

고려할 점

• 디자인 할 때 조심하지 않으면, 시스템이 유지 관리 및 업데이트가 어려운 복잡하고 커다란 모노리틱 구조로 변할 수 있습니다.

 

BEST PRACTICE

• 클라이언트에 잘 디자인된 API를 노출할 수 있도록 디자인합니다.

• Autoscaling을 통해 자동으로 크기를 조정합니다.

• 반정적 데이터를 캐싱합니다.

• 데이터를 분할하여 확장성을 향상시키고 경합을 줄여 성능을 최적화합니다.

 

3. 마이크로 서비스

마이크로 서비스 애플리케이션은 다수의 독립된 서비스로 구성되며, 각 서비스는 단일한 비즈니스 로직을 수행합니다. 서비스는 서로 느슨하게 결합되며, API를 가지고 통신합니다.

 

마이크로 서비스 아키텍처는 개별 서비스를 배포할 때 다른 서비스에 영향을 끼치는 것이 적기 때문에 업데이트를 자주 수행할 수 있지만, N계층 및 웹-큐-작업자 아키텍처보다 빌드 및 관리 방법이 복잡합니다. 

 

그러나, 마이크로 서비스 아키텍처 및 DevOps 문화를 가지고 있다면 보다 빠르게 개발할 수 있으며, 복원력 있는 애플리케이션을 구축할 수 있습니다.

 

장점

• 마이크로 서비스는 독립적으로 배포되 버그 수정 및 기능 릴리즈를 관리하기 더 쉬우며, 부분적으로 서비스를 업데이트할 수 있습니다. 이렇게 함으로써 문제가 발생한 부분만 롤백할 수 있습니다.
• 다양한 기술 스택을 적절히 사용하여 서비스에 가장 적합한 기술을 선택할 수 있습니다.
• 서비스 마다 별도로 확장 가능해, 리소스가 더 많이 필요한 하위 시스템의 규모만 확장할 수도 있습니다.
• 단일 마이크로 서비스만 영향 받기 때문에 스키마 업데이트가 훨씬 쉽습니다.

 

 

마이크로 서비스 아키텍처 다이어그램[4]

 

API Gateway의 이점

API 게이트웨이는 클라이언트가 서비스를 직접 호출하는 대신에 호출을 백 엔드의 적절한 서비스에 전달해줍니다. 

• 클라이언트와 서비스가 분리되 모든 클라이언트를 업데이트하지 않고 서비스 버전을 관리하거나 서비스를 리팩토링할 수 있습니다.

• AMQP 등의 메시징 프로토콜을 사용할 수 있습니다.

• 인증, 로깅, SSL 종료, 부하 분산 등의 다른 교차 기능을 수행할 수 있습니다.

 

고려할 점

• 각 서비스는 단순하지만, 전체 시스템은 복잡합니다.

• 언어와 프레임워크가 너무 많아지면 애플리케이션 유지 관리가 어려워질 수 있습니다.

  • 몇 가지 프로젝트 전체 표준을 적용하는 것이 유용할 수 있습니다.

• 다수의 작고 세분화된 서비스를 사용하면 서비스 간 통신이 증가할 수 있으며, 이러한 종속성 체인이 길어지면 오버헤드가 발생할 수 있으며 문제를 야기할 수 있습니다. 따라서 API를 신중하게 디자인해야 합니다.

• 마이크로 서비스 각각이 데이터 지속성을 담당하기 때문에 데이터 일관성 문제가 생길 수 있으므로 결과적 일관성을 수용합니다.

 

BEST PRACTICE

• 서비스에 느슨한 결합 및 기능 응집력이 있어야 하며, 함께 변경될 가능성이 큰 기능은 함께 패키지하고 배포해야 합니다. 

• 도메인 정보를 게이트웨이에서 숨겨 비즈니스 규칙 또는 도메인 논리를 몰라도 요청을 처리할 수 있도록 라우트하게 만듭니다.

 

 

참고 : 

[1][2] N계층 아키텍처 스타일

[3] 웹-큐-작업자 아키텍처 스타일

[4] 마이크로 서비스 아키텍처 스타일