Design patterns for Cloud Native Application

Cloud 기본 개념

why MSA?

개발 리드 타임 감소 및 scale-out/in

 

SOA

각 모듈이 독자 표준 프로토콜로 통신

중앙 집중화된 제어

하나의 모놀리식 서비스로 배포됨

 

컨테이너

앱 코드 및 의존성(라이브러리), 실행 환경 등을 모두 포함

컨테이너 레지스트리에 보관

 

Container Orchestration

scaling, resource management(자원 할당)

high availability (pod 문제 시 다른 pod 사용 및 재기동 등)

automatic provisioning (자동으로 컨테이너 인스턴스 생성 및 배포)

service interface / load balancing (부하 분산)

네트워크 인프라 추상화

service discovery (service name으로 search)

control plane (컨테이너 시스템 관리 및 모니터링)

health monitoring

rolling upgrade (무중단 update)

componentization & isolation (namespace 등으로 구분 및 격리)

 

Kubernetes

Orchestration tool

Kubernetes API server + control plane nodes + worker nodes

Kubelet: 노드 상과 관리 agent

pod: 앱 실행 단위 - 하나의 pod에 하나의 container가 보통, 고유 IP 주소 할당

service: 여러 pod과 하나의 network 서비스 (논리) 묶음

replica set: pod 수 정의/관리

 

serverless

AWS lambda, Azure Function, Google clound Function

부하에 따른 scaling

event-driven

 

CI/CD

CI는 지속적인 빌드 및 테스트 (후 binary artifact를 산출)

CD:는 이 artifact를 release 하여 staging 및 production 반영

 

 

Operation 시 관리 항목

Auto scaling: trafifc, load에 따라 instance 수 조절

high availability: 오류/중단 감지 시 새 인스턴스 생성 혹은 다른 데이터 센터로 traffic 전달

resource optimization: 실시간 요구에 따라 동적으로 크기 조절 / 비용 청구

observability: 로그, 메트릭 수집

QoS: 단말 간 보안, 스로틀링, 규정/정책 준수, 버전 관리

Central control plane: 중앙 제어 방법

resource provisioning: CPU, memory, network, stroage 동작 할당/관리

multi cloud support: private, public, hybrid 관리

 

DDD와 clean architecture

DDD의 application service, domain service, aggregate root, entity, value object라는 개념을 기반으로 모듈을 모델링 하되, 이들이 어떻게 어떤 레이어에 어떤 관계로 엮이는지는 clean architecture냐, hexagonal이냐, layered냐에 따라 달라지는 것

 

DDD의 전술적 패턴인 Aggregate, Entity, Value Object, Service는 무엇을 만들 것인가에 대한 내용물

Architecture인 Layered, Hexagonal, Clean 등은 그 내용물을 어디에 어떻게 배치하고 연결할 것인가에 대한 구조도

즉, 아키텍처에 따라 변하지 않는 것이 DDD의 전술적 패턴 요소들이고, 나머지는 아키텍처에 따라 변경됨

 

Layered Architecture 적용 시

 

 

앱 설계

미디어 처리 기능을 DDD로 설계

aggregate: 상태와 수명 주기를 관리하는 객체 덩어리

포맷 변환, 크기 조절 등의 '행위'는 method 나 domain service의 역할

 

aggregate는 데이터 변경 시 일관성을 보장하는 단위 / 혹은 트랜젝션 단위

ex. 자동차 aggregate: 운전하기, 멈추기, 가속하기 라는 기능을 지님

 

Bounded Context	Media Processing	MSA 단위가 될 수 있음 ex. Main Processing Context
		여기 안에 여러 aggregate가 존재할 수 있음 ex. Job aggregate, preset aggregate, worker node aggregate
application service	트랜잭션 흐름만 제어 (요청을 도메인 모델로 전달/위임)	여기서 CreateTranscodingJobCommand(DTO)가 들어옴 app service는 이를 풀어서 Job 객체를 생 성
Aggregate	Bounded Context 내에서 관리해야 할 주체	비즈니스 규칙과 상태를 책임
	구성	InputSource, OutputOption 등의 Value Object등을 속성으로 지님
	행동	start, onComplete 등
Main aggregate (= Job)	Encoding Task (= Job)	사용자가 요청한 영상 변환 작업을 대표
	Job	Job은 처리 요청부터 완료까지 라이프사이클을 관리하는 주인 그래서 이는 aggregate root 명령을 받고 이를 Job 객체로 변환
	Root Entity	Job (Job ID, 상태, 생성일시)
	Value Object	InputSource (입력 경로) OutputOption (해상도, 코덱 등)
	Job	처리의 전체 라이프사이클 관리
	Job의 기능(behavior)	start()
		completeResize()
		fail()
Domain service	상태 없이 도메인 로직만 수행
Infrastructure

 

1. API Layer

VideoUploadRequest를 받고 Command로 변환하여 application service에 전달

 

2. application service

command parsing 후 Job 객체 생성 

이때 여러 value object들을 설정

JobRepository.save(job)으로 DB에 저장 (상태: CREATED)

 

실제 변환을 수행하는 domain service (or infra)  호출

transcodingService.encode(job)

 

결과 수신: job.complete(resultUrl) 

 

application service

job 객체의 정보를 JobResponseDTO로 변호나 후 외부(interface)에 DTO 를 전달

 

 

핵심 비즈니스 로직(규칙, 검증, 상태 변경)의 90%는 aggregate(entity) 내에 위치

application service가 aggregate root에 작업을 요청하면, 내부의 여러 entity를 제어해서 요청을 처리

domain service는 stateless logic과 reference로만 구성됨

 

 

DDD Lite

Tactical DDD이며 이를 마틴 파울러는 DDD Lite라 함

용어에 대한 통일

aggregate root 객체를 통한 요구사항 구현의 접근

불변 상태는 value object에, 그리고 변하는 상태는 entity에 저장

 

• 보편 언어
  • 기획자, 도메인 전문가, 개발자가 동일한 용어 사전을 만들어 코드의 클래스명, 메서드 명까지 일치시키는 DDD 앞이자 오메가
• Aggregate root 
  • 외부에서 내부 상태를 마음대로 조작하지 못하게 막고, 트랜잭션의 단위를 root로 강제하여 데이터의 무결성을 지킴
• 상태 저장
  • 불변상태: Value Objects
  • 가변상태: Entity

Boundary Context

시스템이 작을때는 위 3개로 충분하나, MSA 수준으로 넘어가면 용어 통일 자체가 불가능해지는 상황이 발생

인코딩 시의 Video와 정산/결제에서의 Video(과금 단가의 집합)은 서로 다른 용어로 처리됨

그래서 Video aggregate를 공통으로 사용할 수 없음

 

진정한 DDD는 

문맥에 따라 서로 다른 bounded context를 두고 그 안에서 각자의 용어를 통일하는 것

 

 

로직과 상태

stateless processing case

DDD에서 Aggregate root 의 역할은 비즈니스 상태의 정합성을 유지하는 것

Image라는 aggregate root에 Resize와 같은 메서드를 넣는다면, 이는 특정 library나 기술에 종속적이 되어 오염됨

 

domain service의 역할

이미지 변환은 행위이며 이는 domain service에 위치

ImageProcessor port (interface)가 domain service의 delegate 역할

 

즉, Image라는 aggregate root는 리사이즈된 상태 등을 유지(비즈니스 상태)

domain service (port 상속)은 실제 행위를 수행

 

이 경우  domain에는 Image라는 (save, processing 등의 상태 유지) aggregate root만 존재

 

stateful processing case

이 경우 processing 쪽도 상태가 필요하므로, aggregate는 2개가 필요함

하나는 Image aggregate이고 다른 하나는 Image processing aggregate 임

보통 후자는 xxx Job 으로 표현

 

processing 상태 완료 시 Image의 상태도 갱신하고자 한다면, job.complete() 후 image.update() 하여 둘 다 상태를 갱신

 

둘을 decouple 하고자 한다면, 보통 Job이 완료되면 event를 emit 하고 Image aggregate가 이를 비동기로 수신(listener나 flow) 하여 자신의 상태를 갱신