AWS Summit 2023 Seoul 을 다녀와서...

AWS Summit 2023 Seoul

워낙 자발적 은둔형 개발자 코스프레를 하다보니, 자연스럽게 인싸들만 가는 이런 컨퍼런스(?) 행사들은 유투브나 SlideShare 를 통해 자료가 공개되기만을 기다리곤 했다.
업무의 일환으로 반 강제적으로 참여하다보니 ‘하나라도 업무에 적용할 거리를 찾아보자!’ 라는 마음을 갖고 적극적으로 참여하게 되었다.

개발자로서는 모든 기술들을 습득하고 적용해보고 싶은 욕구가 컸지만, 한편으로 AWS 상품의 잠재적 구매자 입장에선 ‘이런 상품을 구매해서 만족하게 될까?’ 라는 의문도 갖게 되었다.

각설하고, 이번 포스팅에선 AWS Summit 2023 Seoul 세션중에서 가장 재미있고 인상깊게 들었던
12가지 패턴으로 알아보는 클라우드 네이티브 디자인패턴 에 대해 정리하고 짧게 후기를 작성해보려고 한다.

12가지 패턴으로 알아보는 클라우드 네이티브 디자인 패턴

김형일 솔루션즈 아키텍트(AWS)
박진현 솔루션즈 아키텍트(AWS)

클라우드 네이티브 마이크로 서비스 아키텍처 ; CN MSA

클라우드 네이티브(CN) 이란? : https://aws.amazon.com/ko/what-is/cloud-native/
- 클라우드 컴퓨팅 환경에서 현대적 애플리케이션을 구축, 배포 및 관리할 때의 소프트웨어 접근 방식
클라우드 네이티브 특징
- 확장성, 유연성, 복원력
- Loose Coupling (느슨한 결합) 시스템
- 자동화
MSA 설계 원칙
- 자율성과 기술 다양성에 따라 팀이 구성되어야 한다.
- Front Door 로 확장 가능한 API 설계
- 비동기를 통한 낮은 결합도와 높은 응집도 시스템 구축
- 테스트하기 좋은 환경구성
- 높은 자동화 수준 유지

디자인 패턴과 원칙

디자인 패턴이란? : 컨텍스트 내에서 공통적이고 일반적인 문제에 대한 재사용 가능한 솔루션
클라우드 네이티브 MSA 주요 디자인 패턴
- API 관리 및 소비 패턴
- 마이그레이션 패턴
- 데이터 관리 패턴
- 이벤트 드리븐 패턴
- 연결성 및 조합 패턴
- 커뮤니케이션 패턴
잘 설계 되었는 지 어떻게 검증하나요?
- 온디맨드 : 필요한 용량을 더 이상 추측하지 말 것
- 운영 규모에서 시스템을 테스팅
- 아키텍처 실험을 더 쉽게 하기 위한 자동화
- 진화적인 아키텍처를 허용

참조 아키텍처로 알아보는 디자인 패턴

API 관리 및 소비

API Gateway 패턴(API Facade pattern)
- 여러 클라이언트 애플리케이션이 포함된 복잡하거나 대규모 마이크로 서비스 기반 애플리케이션을 설계하고 구축하려는 경우 API 게이트웨이 패턴을 사용하는 것이 좋습니다.
  - Reverse Proxy (인증, 화이트 리스트, 캐싱, 데이터 압축)
  - 게이트웨이 라우팅
  - 여러 Microservice API 통합
- 다중 API Gateway
- 단일 API Gateway
BFF(Backend For Frontend) 패턴
- 전통적인 Back-end 는 모든 UI 유형을 수용하는 단일 서버측 API를 제공하고
  시간이 지남에 따라 새로운 유형의 UI와 상호작용을 지원하기 위해 더 많은 기능을 추가하게 됩니다.
  그런 결과 아래와 같은 유형의 문제가 발생할 수 있습니다.
  - 모바일 장치는 비교적 적은 수의 호출을 하고 데스크탑 장치와 다른 (더 콤팩트한)데이터 표시하기를 원합니다.
    이는 API 백엔드가 모바일 인터페이스를 지원하기 위한 추가 기능이 필요함을 의미합니다.
  - 최신 애플리케이션 UI는 사용자에게 실시간 피드백을 제공하기 위해 Websocket 같은 반응형 전략을 점점 더 많이 채택하고 있으며,
    서로 다른 장치는 이를 지원하기 위해 서로 다른 기술 스택을 구현할 수 있습니다.
  - 특정 UI 만을 위한 배포 진행 시(minor update) 이로 인해
    단일 API 백엔드가 롤아웃 시 병목 현상이 발생할 수 있습니다.

Migration

Strangler Fig 패턴
- 복잡도가 높고 대규모의 모놀리식 애플리케이션의 특정 기능을 새로운 MSA 로 마이그레이션 하는 경우 적용 가능한 패턴으로, 목표는 기존 버전과 현대화된 새 버전이 공존하는 것입니다.
- 새로운 시스템은 처음에 기존 시스템에서 지원되며 기존 시스템을 대체합니다. 이러한 지원을 통해 새 시스템을 확장하고 기존 시스템을 완전히 대체할 수 있는 시간을 확보할 수 있습니다.
  - Strangler Fig ; 교살자 무화과 : 무화과 나무의 일종으로 공생할 Host Tree 위 쪽 가지에 스스로 씨를 뿌리는 것이 특징입니다.
    Host Tree를 지지 기반으로 삼으며 뿌리를 땅으로 보내고, Host Tree 가 죽을때 까지 공존합니다.
  - Strangler Fig 패턴을 적용한 Migration 과정
    1. Migration 대상인 모놀리식 시스템이 존재합니다.
    2. MSA 로 일부 서비스만 우선 분리하고, Reverse Proxy 를 활용하여 동일한 사용자 요청에 대해 새로운 서비스로 유도합니다.
      (이 때, 필요에 따라 모놀리식의 구버전 서비스와 새로운 Microservice 가 공존할 수 있습니다.)
    3. MSA 의 운영 안정성을 충분히 검토한 후 구버전 서비스를 종료합니다.
    4. ii. 의 과정을 서비스마다 반복하여 모놀리식 시스템을 안정적으로 CN MSA 로 전환할 수 있습니다.

장점	단점
서비스에서 하나 이상의 대체 서비스로 정상적으로 마이그레이션 할 수 있습니다.	복잡성이 낮고 크기가 작은 소규모 시스템에는 적합하지 않습니다.
업데이트된 버전으로 리팩터링 하는 동안 이전 서비스를 계속 사용할 수 있습니다.	백엔드 시스템에 대한 요청을 가로채서 라우팅할 수 없는 시스템은 이 패턴을 사용할 수 없습니다. (Reverse Proxy 역할을 수행할 수 있는 모듈이 반드시 필요합니다.)
이전 서비스를 리팩터링 하면서 새 서비스 및 기능을 추가할 수 있는 기능을 제공합니다.	프록시 또는 파사드 레이어는 새로운 서비스가 제대로 설계되지 않은 경우 단일 장애 지점이나 성능 병목현상의 지점이 될 수 있습니다.
API 버전 관리에 사용할 수 있습니다.	문제가 발생할 경우 작업을 빠르고 안전하게 수행하는 이전 방식으로 되돌리려면 각 리팩터링된 서비스에 대한 롤백 계획이 필요합니다.
업그레이드 되지 않았거나 업그레이드 되지 않을 솔루션의 기존 상호작용에 사용할 수 있습니다.
Reverse Proxy가 존재한다면, 구버전 서비스와 새로운 서비스가 공존하는 기간에 쉽게 롤백 할 수 있습니다.

데이터 관리

Database Per Service 패턴
- 마이크로서비스 간 느슨한 결합을 필요로 하거나 각 마이크로서비스 간 상이한 규정 혹은 보안 요구사항이 있는 경우 마이크로서비스 별로 다른 Database를 사용하는 것이 이 패턴의 핵심입니다.
  - 마이크로서비스 간 데이터 계층을 공유하지 않습니다.
  - 마이크로서비스간 적합한 DBMS 솔루션을 선택할 수 있습니다.
  - 마이크로서비스의 개별 데이터베이스에 대한 변경 사항은 다른 마이크로서비스에 영향을 미치지 않습니다.
  - 개별 데이터 스토어는 다른 마이크로서비스에서 직접 액세스할 수 없으며, 영구 데이터는 API를 통해 허용된 인터페이스로만 액세스할 수 있습니다.
  - Database를 분리하면 전체 애플리케이션의 복원력이 향상되고, 단일 Database에 비해 단일 장애지점(병목현상)이 생기지 않도록 할 수 있습니다.
CQRS(Command Query Responsibility Segregation) 패턴
- 일반적인 시스템은 데이터의 상태변경 보다 조회에 대한 처리가 훨씬 많습니다.
  따라서 애플리케이션을 명령(create, delete, update)과 조회(query)로 분리하거나,
  Command 용도의 별도 서비스와 Query 용도의 별도 서비스를 분리합니다.
  - 명령 : 데이터의 변경 혹은 시스템의 명령 부분(회원 정보 업데이트, 회원 생성, 회원 삭제 등등..)
  - 쿼리 : 조회 목적의 모든 기능
- Database per service 패턴과 복합적으로 적용한다면, 조회용 데이터 저장소(OpenSearch, 등등 …)와
  명령 서비스에는 Transaction을 지원하는 데이터 정합성을 위한 저장소를 별도로 구성하는 것을 고려할 수 있습니다.
Materialized View 패턴
- 계산된 결과 데이터 Materialized View 로 미리 구성해서 실행부에 가깝게 배치하는 방법
복잡한 조인이나 의존적인 외부 데이터 서비스 영향으로 데이터 조회 성능 저하가 발생하는 경우
- 요구되는 데이터를 로컬 데이터 저장소나 캐시에 미리 최적의 형식으로 저장하여 조회 성능 향상

이벤트 드리븐

Publish - Subcribe 패턴
메시지 발행자가 메시지를 토픽에 발행하면 모든 구독자가 수신하는 비동기 메시지 전달 패턴
- 대규모 분산 시스템의 병렬성과 확장성 요구와 동기식 이벤트 전달이 가지는 대기시간 문제 해결
- 복수의 발행자가 메시지 브로커의 토픽으로 전송한 메시지를 복수의 구독자가 모두 수신

연결성 및 조합

SideCar 패턴 : 하나의 컨테이너에는 하나의 책임만 가지고 있어야 한다.
- 애플리케이션 컨테이너의 기능을 확장하고 강화하는 용도로 사이드카 컨테이너를 추가하는 방식
  - 애플리케이션 컨테이너의 변경 없이 통신, 모니터링, 보안 등의 공통적인 기능을 확장
  - 주 컨테이너와 함께 스케줄링 및 동작하는 사이드카 컨테이너를 추가해 재사용 가능한 부가 기능 구현
    - 이기종 application container과 sidecar container 가 공존 가능
    - 애플리케이션에선 비즈니스 로직에 집중, 부수적인 역할은 sidecar 의 책임
Service Mesh 패턴
- 분산 애플리케이션에서 서비스 간 통신과 보안, 로깅, 로드밸런싱, 모니터링 등의 기능을 중앙에서 관리
  - 마이크로서비스들과 시스템들 간의 통신에서 연결성 로직을 마이크로서비스가 직접 관리해야 하는 문제
  - 서비스간 통신 로직 처리는 Sidecar proxy (Data Plane)를 사용하고 제어는 Control Plane 이 담당
Service Choreography 패턴
- 여러 마이크로서비스를 조합하는 비즈니스 기능의 구현을 이벤트 기반의 비동기 통신으로 합성하는 패턴
  - 유연성과 확장성, 변경 비용을 고려해서 서비스들간의 낮은 결합도와 비동기 통신이 필요한 경우
    - 다른 마이크로 서비스를 직접 호출하지 않고, 이벤트와 메시지를 기반으로 반응모드로 작동
Service Orchestration 패턴
- 중앙 컨트롤러 서비스(Orchestrator)가 서비스 흐름 제어, 서비스 상호작용을 조정하여 프로세스 관리
  - 단일 마이크로 서비스의 분산에 따른 한계 존재
    - 여러 마이크로 서비스에 분산되어 있는 상호작용을 중앙의 단일 서비스를 통해 비즈니스 로직 구현
Saga 패턴
- 여러 트랜잭션을 그룹으로 관리 및 조정하여 일관성을 유지하도록 하는 분산 트랜잭션의 장애 관리 패턴
  - 마이크로 서비스 구조에서 긴밀한 결합 없이 여러 마이크로 서비스에 걸친 트랜잭션 처리의 복잡성
    (결제 → 재고관리 → 배송 → 외부 결제 시스템 결제 여부 → …)
  - 모든 트랜잭션 이벤트를 게시하고 결과에 따라 다음 트랜잭션을 시작, 혹은 실패할 경우 보상 트랜잭션 실행

간략 정리

작고 서비스 목적에 맞는 MSA 설계
비동기 통신을 통한 느슨한 결합
독립적 테스트와 배포
필요한 만큼 확장 또는 축소
목적에 맞는 데이터베이스와 툴 사용

짧은 회고

패턴은 시험 문제 족보와 다름없다.
AWS Summit 2023 의 핵심 키워드는 ‘비동기’

인프라적인 패턴으로부터 소스코드 작성에 대한 패턴으로의 확장

API Gateway → 일종의 Facade

public void purchaseFacadeService(){
  productService.manageInventory();
  paymentService.payment();
  // ... 
}

Strangler Fig → 리팩터링 방법으로 접목

// AS - IS

@GetMapping("/api/v1/purchase")
public void oldPurchase() {
  // ...
  purchaseService.oldFashionedPurchase();
}

public void newPurchase() {
  // ...
  purchaseService.newPurchase();
}

// TO - BE : Strangler Fig 패턴 적용

public void oldPurchase() {
  // ...
  purchaseService.oldFashionedPurchase();
}

@GetMapping("/api/v1/purchase")
public void newPurchase() {
  // ...
  purchaseService.newPurchase();
}