MSA, Cloud Native App은 무엇인가

💭 소프트웨어 아키텍처의 역사

개인이 구매가능한 컴퓨터와 운영체제라는 개념은 1970년대쯤 처음 나왔습니다.

• 1960~1980 : 하드웨어의 성능이 중요하던 시대입니다. 회사마다 1대의 컴퓨터로 모든 작업을 처리합니다. 
• 1990~2000 : 회사 서버실에 여러 대의 컴퓨터를 두고 분산처리하기 시작합니다.
• 2010~ : 하드웨어가 저렴해지며 안정성과 유지보수성이 많이 개선됩니다. 네트워크 클라우드 서버가 등장합니다. 
  서버를 유연하게 확장할 수 있으며, 변화에 대응하기 쉽게 구성하기 시작합니다. (DevOps 직종의 등장)

멀티프로세스는 당연하고, 서버 컴퓨터가 없어도 클라우드를 통해 서버를 구축할 수 있습니다. 

과거에는 컴퓨터의 성능이 중요해서 유연하게 구성하기 어려웠지만, 현대에는 비교적 원하는데로 구성가능합니다.

 

 

📌 안정적이고 유연하다는게 무슨말이죠?

Antifragile. 즉 갑자기 대규모 트래픽이 몰리더라도, 장애를 격리하고 유연하게 구성을 바꿔 대처가능하다는 말입니다.

안정적이고 유연한 대규모 서버는 아래와 같은 특징을 가집니다.

 

1. Auto Scaling - 클라우드를 사용하는 경우, 트래픽에 따라 손쉽게 서버 자원을 늘렸다 줄였다 할 수 있습니다.

2. Microservice - 한 서버가 모든 것을 처리하는 방식(모놀리스)가 아니라, 각각의 분산된 서버가 협력해서 처리합니다.

개발 난이도는 올라가지만, 대규모 서비스(Netflix, Amazon, 네이버 배민)에서 장애격리, 유연성을 가지기 좋습니다.

3. Chaos engineering - 예상하지 못한 장애나 급격한 변화에도 빠르게 대응 가능한 아키텍처를 말합니다.

4. CI / CD (Continuous Integration, Deployments) - 수많은 서버, 개발자가 만든 기능을 안정적이게 통합하고, 지속적인 배포를 가능하도록 구성된 아키텍처를 의미합니다.

 

위의 특징들을 가진 앱을, Cloud Native Application이라고도 부릅니다.

 

 

📌 컨테이너 가상화?

서버를 운영하는데는 많은 설정과 프로그램이 필요합니다

매번 프로그램을 설치하고, 많은 설정들을 관리하기가 어려워서 '서버를 격리시키는' 가상화가 나오게 되었습니다.

가상화의 가장 큰 단점은, 한 컴퓨터에 독립적인 운영체제를 실제로 설치하고 띄운다는 점이 있습니다.

호스트가 되는 컴퓨터의 CPU와 메모리부하가 상당히 심해지고, 가상화를 사용했음에도 시스템 확장이 어렵습니다.

 

여기에서 한단계 더 나아간것이 Docker 같은 컨테이너 가상화입니다.

운영체제가 제공해주는 가상화 기술을 사용하여, 실제로 여러개를 띄우는게 아니라, 가상으로 격리된 공간을 만듭니다.

만약 똑같은 설정값, 자원이라면 [컨테이너 이미지] 설정 파일을 만들어 중복 설치없이 재사용 가능합니다.

이미 필요한 파일이 설치되어있다면, 새로운 O.S를 띄우는데 1분도 걸리지 않습니다.

 

 

---

💭 Cloud Native App은 만능인가

아닙니다. Cloud Native App을 개발할 때에는 기존 프로젝트보다 많은 것을 추가로 고려해야 합니다. (12 Factors)

이를 공식마냥 외울 필요는 없고, 각각을 설명하는 키워드를 한번 봐두면 책 읽거나 검색할 때 도움이 됩니다.

• Base Code 관리 - 각각 독립적인 서비스의 코드를 따로 관리해야하고, 지속적인 통합, 배포가 필요합니다.
• Dependency Isolation - 각각의 서비스는 다른 서비스에 의존성이 없어야합니다. (서비스의 인터페이스로 통신)
• Configurations - 코드 내부에서 직접 설정하는 것이 아니라, 시스템 외부에서 설정을 관리할 수 있어야 합니다.
• Linkable Backing Service - 핵심 로직과 세부 구현기술, 즉 Backing Service가 분리되어 갈아 끼울 수 있어야 합니다.
• Stage Of Creation - 빌드, 릴리즈, 운영버전을 독립적으로 관리하고 문제 발생시 이전으로 롤백 가능해야 합니다.
• Stateless Processes - 각각의 서비스는 Stateless하게 동작해야합니다. 이전 상태나 의존성을 가지면 안됩니다.
• Port Binding - 각각의 서비스는 스스로 실행가능해야합니다. (즉, 각각의 서버 Port를 제공해야합니다.)
• Concurrency - 동시성 문제와 성능에 대해 고려해야합니다. 
• Disposabilty - 서비스 인스턴스가 삭제 가능해야합니다. (컨테이너) 유연하게 갈아 끼울 수 있어야합니다.
• Development & Production Parity - 개발환경과 운영환경을 분리해서 운영해야합니다. 서로 영향이 없어야합니다.
• Log - 서비스와 독립적인 로그, 모니터링 시스템이 존재해야합니다. 서비스가 멈추더라도 로그는 작동해야합니다.
• Admin Processes for Eventual Processes - 각각의 서비스들의 동작 과정을 모니터링, 분석할 수 있어야 합니다.

 

스프링을 개발하는 Pivotal에선 12 Factors 에 3가지를 추가한 15 Factors를 블로그에 올리기도 했습니다.

• API first - 내부 서비스라고 하더라도, 외부 공개가 가능하게 API와 문서를 명확하게 정의, 설계해야합니다.
• Telemetry - 모든 장애와 수치는 시각화 되어야합니다.
• Authentication and authorization - 기업용, 모바일, 내부앱이라고 한들 보안을 무시하거나 미루면 안됩니다.

 

MSA 방식의 Cloud Native App은 많은 장점을 가지지만, 그만큼 구현하기 어렵고 더 많은 것을 고려해야합니다.

정답은 없습니다. 한 프로젝트에 모든 걸 만드는 모놀리스(Monolith Architecture)가 더 좋을 때도 많습니다.

모든 곳에 100% 완벽한 설계는 없습니다. 정하기 나름입니다.

 

이해를 돕기위해 더 구체적으로 비교해보자면, 아래와 같습니다.

과거에는 왼쪽 모놀리스가 누구나 사용하는 당연한 아키텍처였습니다. (* 참고 WS == Web Service)

 

 

 

📌 실제 대기업들은 어떤 식으로 만드나요?

2018년 조사기관에서 Netflix, Twitter, Amazon 아키텍처의 공통적인 흐름을 발표했습니다.

1. 각각의 서비스 API를 직접 제공하지 않고, API Gateway(서비스 라우터)를 사용해 단일 진입점을 제공합니다.
2. 필요한 서비스를 찾았다면 요청을 합니다. 이 때 서버가 여러 개라면 로드밸런서를 통해 트래픽을 분산시킵니다. 
3. 각각의 서버 인스턴스는 컨테이너로 가상화되어있고, 서버간 데이터 통신은 그 서버의 API나 이벤트를 사용합니다.

 

• 별도의 CI/CD (지속적인 통합, 테스트, 배포)를 제공하고, 이 흐름을 자동화 합니다.
• 모니터링, 진단(수치화) 시스템이 별도로 존재합니다.
• 구현 기술, Backing Service는 핵심 로직과 분리되어 갈아끼울 수 있습니다.
• 각각의 서버는 다른 서버에 의존성이 없습니다. 즉 필요한 서버만 골라 새로운 서비스를 만들 수도 있습니다.

이런 아키텍처를 구축하는데에 사용되는 기술은 아래와 같습니다. (*2017년 기준)

 

 

---

💭 MSA에 사용되는 패턴들

기존의 단일 프로젝트(Monolithic)에서는 트랜잭션 처리가 간단하다. 필요하다면 DB에 직접 접근할 수도 있다.

MSA (MicroService)는 각 서비스간의 의존성이 없어서 트랜잭션을 쉽게 걸 수 없다. 억지로 걸어도 rollback이 까다롭다.

서비스는 독립적인 DB를 가지며, 필요하다면 해당 서비스의 인터페이스(API)를 통해 받아와야한다.

주문서비스가, 카테고리 서비스 DB를 끄집어 낼 수 없다. / 만약 주문이 취소되었을 때 롤백은 어떻게..?

 

📌 방법1) Event Driven을 통한 트랜잭션 처리

각 서비스는 이벤트 큐를 통해, 일정시간마다 이벤트 여부를 확인하고 본인이 처리가능한 이벤트를 가져온다.

각 서비스에서 할 일을 마치고, 이벤트 큐에 메시지(=이벤트)를 전송한다.

• 주문을 했을 때, 주문정보를 생성하고 다른 서비스에 필요한 정보를 넣은 [주문 생성됨 이벤트]를 발행한다.
• [주문 생성됨 이벤트]를 처리하는 서비스들은, 메시지 큐에서 해당 이벤트를 가져온다.
• 각 서비스에서 할 일을 마치고, 다음 작업이 필요하다면 [다른 이벤트]를 발행시켜서 처리한다.

이런 식으로 트랜잭션을 처리하는 것을 Commit Transcation이라 부른다.

다른 서비스가 [완료됨 서비스]를 발행하면, 이를 확인한 주문서비스가 [주문 완료]로 상태를 바꿔 저장하는 것이다.

 

 

만약 한 서비스에서 처리를 실패했다면, 똑같이 [실패 이벤트]를 발생시켜서 처리하면 된다.
정확히 말해 롤백이라기보단, 일단 실행한 뒤 실패하면 전체 서비스에 보상트랜잭션을 발생시키는 방법.

[주문 대기]중인 Order 서비스는, [취소 이벤트]를 받거나 서비스 응답없음 같이 특정 상태 값에 따라 주문을 취소한다.

 

 

 

📌 방법2) Event Sourcing

이벤트로 데이터의 마지막 상태만 전달하는게 아니라, 수행된 전체 이력을 기록하는 방법이다.
별도의 업데이트 없이 새로운 이벤트를 계속 추가하면 되는거라, 동시성 문제를 해결하기 쉽다.
이벤트 드리븐의 가장 큰 단점은, 이벤트 재발행 처리 + 중복 발행되었을 때 처리가 복잡하다는 점이다. 이벤트 소싱은 중복 발생되어도 별 상관없음. 전체를 기록하는거라

 

물론 이벤트 드리븐에 비해 아래와 같은 단점이 있다.

• 🧨각 데이터의 이벤트 기록이 너무 길어진다. 예를 들어 트랜잭션을 복원할 때, 각 이벤트를 전부 롤백해야한다.
  -> 이는 스냅샷으로 나눠서 일정부분까지만 기록하면 어느정도 해결된다.
• 🧨객체를 변경하는건 괜찮지만, 수십만 건이 발생하는 조회성 데이터에는 답이 없음. 이벤트 기록이 너무 복잡해짐
  -> CQRS로 해결가능. 조회와 쓰기를 나눠서 사용하자

물론 쓰기와 읽기를 나누면 잠깐동안 정합성이 깨지지만, 이벤트 소싱이라 최종적(Eventually)으로는 정합성이 맞아집니다. 

위 그림과 같이 동작한다고 이해하면 된다.

 

• 🧨이벤트는 영구저장되므로, 기존의 입력 형식을 바꾸기가 어려움.
  -> 각 이벤트에 버전 값을 두고, 이벤트 소싱 프레임워크를 통해서 관리하면 어느정도 해결가능.
• 🧨 기존 트랜잭션 방식으로 처리하면 간단한데, MSA + 이벤트소싱 배워서 하려고하니 너무 프로젝트가 복잡해짐-> 이건.. 단점이 맞다. 학습에 대한 러닝커브도 높은 편.

 

위 문제를 고려해서 데이터베이스가 1개 일 때 CQRS + Kafka를 사용하면 대충 아래와 같은 아키텍처가 나온다.

잠깐동안 정합성이 깨지긴 한다. (Command에서 이벤트를 발생시킴 -> 이벤트 저장됨 -> Query에서 읽어옴)

 

 

📌 Saga Pattern

위 이벤트 소싱에서 특정 서버가 죽었다거나, 처리에 실패한 경우 롤백 처리가 필요하다.

이 경우 데이터의 일관성을 보장하기위해 Saga Pattern을 많이 사용한다.

'Saga'라는 단어는 영어로 어떤 영웅의 긴 모험담을 의미한다.
Saga Pattern은 비동기 메시징을 이용해 전체 트랜잭션없이, 로컬 트랜잭션만으로 데이터 일관성을 유지하는 방법이다.

물론 두 서비스를 한 트랜잭션처럼 묶어 처리하는 방법(2PC, 2 Phase Commit)도 있겠지만, 성능이 매우 구려진다.

각각의 서비스는 '본인의 트랜잭션'만 관리한다. 이후 성공/실패에 대한 결과만 이벤트로 전달한다.

이런식으로 성공/실패 흐름을 만들어, 실패한다면 [보상 트랜잭션] 과정을 통해 데이터의 일관성을 맞춘다.

 

자주 사용하는 Saga 패턴은 크게 2가지가 있다.

 

Choreography-based Saga (안무 중심의 사가패턴)

*Choreography는 안무, 무도, 몸동작 이런 의미

전체를 지휘하는 서비스가 없고, 서로 이벤트를 주고 받으며 소통합니다. (= 이벤트 핸들러가 중심이 됨)

코레오그래피 사가 패턴 시나리오
서비스 목록 : (주문) (고객) (영화관) (회계)
1. 주문 서비스가 [Pending] 상태가 되고, [💨주문 생성 이벤트]를 발행합니다.

2. 고객 서비스가 [💨주문 생성 이벤트]를 수신, 소비자 검증 후  [✔ 소비자 확인 이벤트]를 발행합니다.
2. 회계 서비스가 [💨주문 생성 이벤트]를 수신, 신용카드 승인을 [Pending]으로 생성합니다.
2. 영화관 서비스가 [💨주문 생성 이벤트]를 수신, 주문 내역을 확인하고 티켓을 [Create_Peding]으로 변경합니다.
   그리고 [✔ 티켓 생성됨] 이벤트를 발행합니다.

3. 회계 서비스가 [✔ 티켓 생성됨] 이벤트를 수신, 신용카드를 과금하고 [📧신용카드 승인됨] 을 발행합니다.
3. 영화관 서비스가 [📧 신용카드 승인됨] 이벤트를 수신, 티켓 상태를 [Awaiting_Accept]로 변경합니다.
3. 주문 서비스가 [📧 신용카드 승인됨] 이벤트를 수신, 주문 상태를 [Approve]로 변경합니다.
    그리고 [주문 승인됨] 이벤트를 발행합니다.

4. 이후 [주문 승인됨] 을 구독하는 서비스가 이를 받아서 처리합니다.

참고로 중간에 실패하면, [주문 실패 이벤트] 같은 걸 발행시켜 각각의 서비스가 보상 트랜잭션을 실행합니다.

 

 

 

Orchestration-based Saga (오케스트레이션, 지휘 중심의 사가패턴)

전체를 지휘하는 서비스가 존재합니다. (= 특정 서비스가 중심이됨)

서비스 목록 : (주문) (고객) (영화관) (회계)
오케스트레이션 담당 : 주문 서비스

1. 주문 서비스는 🏗Saga 오케스트레이터를 생성합니다. 이를 이용해 각 서비스와 비동기로 응답을 합니다.
2. 🏗Saga 는 [소비자 확인 커맨드]를 소비자 서비스에게 전송합니다.
3. 소비자 서비스는 소비자를 확인하고, [소비자 확인 메시지]를 응답합니다.

2. 🏗Saga 는 [티켓 생성 커맨드]를 영화관 서비스에 전송합니다.
3. 영화관 서비스는 티켓을 생성하고, [티켓 생성 메시지]를 응답합니다.

2. 🏗Saga 는 [신용카드 승인 커맨드]를 회계 서비스에 전송합니다.
3. 회계 서비스는 신용카드 결제 후, [신용카드 승인됨 메시지]를 응답합니다.

4. 🏗Saga 는 [티켓 승인 커맨드]를 영화관 서비스에 전송합니다.
4. 🏗Saga 는 [주문 승인 커맨드]를 주문 서비스에 전송합니다.

 

📌 코레오그래피 Saga vs 오케스트레이션 Saga

코레오 그래피는 이벤트를 구독/발행할 뿐, 서로를 알지 못한다.

• 각 서비스의 처리가 단순하고, 전체 서비스간의 결합이 느슨해진다.
• 서비스간 의존관계가 복잡해서 전체 흐름을 한눈에 보기어렵다. 즉 이해가 어렵다.
  여러 작업이 있을 경우 객체의 상태가 복잡해질 수있다. Pending -> Ready -> Approval Ready -> Approved등
• 순환참조가 발생하기 쉽고, 모든 서비스를 구독해야한다. (ex 회계서비스의 경우 전체이벤트를 받는다. 결합도 높음)

 

오케스트레이션은 중심 지휘를 맞는 서비스가 별도로 존재한다.

• 중심 서비스가 있어서, 각 서비스간의 의존 관계가 깔끔해진다.
• 중심 서비스가 전체를 관리하므로, 각 서비스간 결합도가 낮다.
• 전체 이벤트를 알 필요가 없다. 그냥 중심서비스가 보내는 걸 처리하면 된다.
• 중심 서비스가 있어서 중간 상태(Pending -> Ready -> Approvel)가 딱히 필요없다. 비즈니스 로직이 단순해진다.
  Pending으로 생성하고, 처리완료되면 Approved 로 바꾸면 된다. 중간에 Ready 같은 걸 끼워넣을 필요가 없다. 

그래서 대부분의 경우 오케스트레이션 방식을 권장한다.

하지만 대충 만들경우, 오케스트레이션 서비스에 모든 로직이 들어있고 나머지는 깡통 서비스가 될 수 있다.
이렇게 Saga를 억지로 구현하는 거보다, 차라리 모놀리스 방식의 단일 프로젝트가 더 나을 수 있다.

오케스트레이션 서비스는 가급적 전체 작업의 순서화만 담당하고, 비즈니스 로직은 가지고 있지 않는게 좋다.

 

---

 

📔 레퍼런스

인프런 - Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)

https://www.gartner.com/en/blog

https://tech.kakao.com/2021/09/14/msa/

https://developer.ibm.com/articles/15-factor-applications/