[빗썸테크아카데미] 여덟번째 - MSA Monitoring, 장애 대응/대비, Transaction, anti pattern, 보완 설계 패턴

 

 

[빗썸테크아카데미] 여덟번째 - MSA Monitoring, 장애 대응/대비, Transaction, anti pattern, 보완 설계 패턴

 

 

 

 

전날은 팔팔했는데, 다시 피곤하다 ㅎㅎㅎㅎ

아 너무 힘드렁

 

수업도 수업인데,

수업 내용을 다음날 포스팅 하는게 진짜 진빠진다

 

첫주에는 질문이 거의 한시간이라

질문하면 이미 한시간이 지나있는데

요즘은 20분정도면 끝나서

수업 내용이 30분 더 길다보니

정리해야 할 내용이 더 많은 것 같다.

 

과제도 해야하고

포스팅도 해야하고

수업도 들어야하고...

 

아 CS 스터디 강의 자료도 준비해야 허네~~

 

6주 과정중 3주 수업, 3주 프로젝트라고 하니

그래도 이제 수업은 반을 넘었으니 조금만 더 힘내잣

 

 

 

---

 

1. MSA Monitoring

MSA Monitoring이 어려운 이유

• 분산된 각각의 서비스 Health check 문제
• 클라우드 환경에서 App Data는 특정 장비에 종속되지 않음
• 배포 장비의 변동성
• 컨테이너의 짧은 수명
• 로그는 디스크의 저장 상태에 의존하지 않음
• 로그는 각 Service별로 파편화

-> 중앙 집중형 Monitoring Service 구축 필요

 

 

중앙 집중형 Monitoring Service 

• MSA 내 모든 log message 수집
• Transaction 연결 추적
• Log 장기 보관 가능

• MSA의 LogStream을 한곳에 모아 DB에 쌓은 후, 이것들을 시각화하는 모니터링 툴로 확인!
• AWS watch같은 클라우드 자체 모니터링을 사용해도 되지만, AWS watch의 경우 log가 2주밖에 저장이 안되어 로그를 내려받아 따로 관리하는 과정 필요

 

 

 

 

 

2. MSA 장애 대응/대비

2.1. 장애 전파 차단

• Circuit breaker : 장애가 계속 발생하는 모듈이 있으면, 장애가 해결될 때 까지 그쪽으로 가는 신호를 끊어버림
• Fall-back Messaging : 오류가 났을시 기본 값을 던져줌

 

2.2. 분산 저장/운영

• Public Cloud에서 복수개의 service region 운영

 

2.3. Canari 배포

• 옛날에 광부들이 광산에 들어가기 전에 카나리아 새를 광산에 날려보내서, 잘 돌아오면 일을 하러 들어가고, 돌아오지 않으면 가스같은 것들이 누출되었다고 생각해서 그날은 일을 하지 않고 다음날 다시 와서 확인하는 것에서 차용한 시스템
• 새로운 버전의 앱을 배포할때 일부의 트래픽만 새로운 버전에 할당시켜 보고 문제가 없으면 점진적으로 구 배포 버전에서 신 배포 버전으로 교체를 하는 방식

 

2.4. 장애 시나리오

• 가상의 장애 상황을 가정하고, 그것이 일어났을 때 어떻게 할 것인가?

 

Chaos Monkey (Netflix)

임의의 상황을 발생시키는 Testing 용 툴

• Chaos Monkey : 랜덤하게 돌아다니면서 인스턴스를 하나씩 꺼서 우리의 시스템이 죽는지 확인을 하고 대비
• Chaos Gorilla : az(available zone)를 하나씩 끔..... -> 해당 az의 인스턴스가 다 죽음 -> az를 한개만 쓰고 있으면 서비스가 죽겠지? -> 하나의 az가 죽어도 바로 다른 az로 연결 할 수 있게 대비
• Chaos Kong : region을 하나씩 끔..... -> 해당 region의 인스턴스가 다 죽음 -> region을 한개만 쓰고 있으면 서비스가 죽겠지? -> 하나의 ag가 죽어도 바로 다른 ag로 연결 할 수 있게 대비
• Latency Monkey : 무작위로 요청 지연시킴
• Security Monkey : 무작위로 권한 취득을 시도
• Janitor Monkey : GC를 좀 더 빨리빨리 실행시키는 것 -> GC가 되면 안되는 것들이 지워져 버릴 경우에 대한 대비

 

 

 

 

 

3. MSA Transaction

3.1 Monoliths -> MSA 전환 시 DB 설계

• Application Logic layer부터 순차적 분해
• 주로 3Tier Monoliths로 시작하는 경우가 많음 -> 프론트는 일단 냅두고 WAS부터 쪼개보자 !

 

전환 절차

1. Router 구축

2. Monoliths가 Router를 통해 요청 받게 하기

3. API 분리 가능한 작은 규모 MS 1개 구축

4. 구축된 서비스만 proxy 전환

5. DB 또는 Schema 분리

6. 첫 MS를 위한 Data Migragtion

7. 검증 및 확장

 

 

DB 이관 전략 세가지

• 물리적(DB) / 논리적(Schema) 분리 모두 적용 가능

1. 서버를 내리고 한번에 이관한다 -> 서버 다운만 감수 가능하다면, 가장 쉽고 명확한 방법

2. MS가 새 DB와 구 DB에 둘다 CUD하고, Monoliths는 구 DB를 ReadOnly 하는 방법

    ->한동안은 두개의 시스템을 동시에 운영해야 하는 필요가 있을 때

    -> 이후 다 이관할 준비가 되면 Monoliths는 구 DB를 죽이면 됨

3. 새 DB에만 쓰고 CDC solution

    -> CDC(Change Data Capture) : DB가 변경될때마다 새 target DB에 저장하는 솔루션

    -> 약간의 자금력 필요

    -> 돈만 있으면 제일 편함

 

 

 

 

3.2 MSA에서의 DB 설계

이상적인 설계

• Microservice 1개당 독립된 1개의 Database
• 다른 MS에서 관리하는 Data는 API를 통해서만 참조

 

현실적인 설계

• 서로 다른 MS가 같은 데이터를 동시에 CUD하지 않도록 하는 전략 중요
• 반드시 물리적으로 DB 분리할 필요는 없음

 

 

 

 

3.3 분산 DB의 Transaction 유지

Transaction이란?

• DB에 저장된 Data에 대한 하나의 논리적 기능을 수행하기 위해 연산 집합(Create, Delete, Update)으로 구성된 쪼갤 수 없는 작업 단위
• 동시성 제어와 Recovery 기본 단위

 

ACID란?

원자성(Atomicity) : All or Nothing 

일관성(Consistency) : Transaction 수행 후 논리적 모순이 없어야 함

고립성(Isolation) : 한 Transaction 수행 중 다른 Transaction 접근 차단

지속성(Durability) : 성공한 Transaction는 영구적으로 저장되어야 함

 

 

 

 

3.4 어떻게 분산 BD의 트랜잭션 일관성을 유지할 것인가?

3.4.1 2PC (Two-Phased Commit)

• MSA에 없었을때의 교과서에 나오는 옛날 방법

 

• 분산 Tx를 지원하는 단일 DBMS가 Tx를 관리
• Tx 참여 node가 2단계로 Commit 수행

 

 

 

3.4.2 SAGA

• 다중 DB 환경에서 Tx를 App이 관리
• 각 App은 자기 DB Tx만 관리

-> 결과적 일관성

-> 보상 트랜잭션 처리

 

 

Orchestration SAGA

• 여러 MSA가 참여하는 한개의 논리적 Transaction Saga
• 전부 다 성공하면 -> 기쁨!
• 하나라도 실패하면 -> Tx Saga가 보상 logic 호출                                                                                       ex) A,B,C DB가 1이라는 데이터를 insert 하기로 했는데 A,B는 이미 Commit을 성공했지만 C가 실패했을 경우 A, B의 1번 데이터를 지우라는 보상 logic을 호출함 -> 결과적으론 데이터의 일관성을 얻을 수 있음
• Orchestration saga에 의한 중앙 집중화 주의

 

Choreography

• 서비스간 event Pub/Sub
• Message Queue를 통해 비동기로 Tx logic 요청
• Event Subscribe한 MS가 Tx 실패 -> 약속된 fallback url을 통해 보상 Tx logic 호출
• 시스템 복잡도 증가

 

 

 

3.4.3 CQRS(Command and Query Responsibility Segregatioin)

  : 쓰는 역할과 읽는 역할 구분

 

수준1) MS 수준에서 CUD / R 구분

• Bounded Context 걸쳐져 있는 Entity는 한곳에서만 CUD를 해야 함

 

수준2) DB를 main과 read-replica로 구분

쓰는 역할을 하는 MS는 메인 DB를 연결하고, 쓰지 않아도 되는 DB는 read-replica를 연결. read-replica는 지속적으로 동기. 쓰기와 읽기의 DB가 같을 경우 select 속도 저하. CUD는 많은 연산 로드가 필요하기 때문에 조회와 같이 하면 조회 속도가 느려짐.

 

수준3) CUD DB와 R DB를 분리하고 동기화

• CUD DB에서 read용으로 R DB를 아예 따로 만들고 Event Broker를 두어서 CUD DB의 변경사항을 캐치해서 R DB에 반영.
• CUD DB와 R DB는 스키마가 같을 필요가 없고, CUD DB는 RDBMS로 테이블을 구성하고, RDBMS를 조인해서 한번에 원하는 데이터를 전부 조회할 수 있게 스키마를 짜서 R DB는 NoSQL에 저장 할 수도 있다.

 

수준4) EventSourcing

• CUD DB랑 R DB 분리
• MS의 모든 Tx를 event로 streaming
• EventStream 저장용 Data Storage 관리
• MS에서 관리하는 Data의 상태 변경 이력 관리

 

 

 

 

 

 

4. MSA anti pattern

1. Microliths

• 기존의 Monoliths에서 MSA로의 분해 단계의 실패
• 기존의 Monoliths 크기만 작아진 딱히 달라진게 없는 패턴
• 다른 MS에서 격리되지 못함
• MS끼리 강한 의존성 : 각각의 service는 데면데면 해야 함

-> 이렇게 할바에는 그냥 Monoliths으로 쓰자!

 

 

2. Death Star

• DB를 제대로 안나누어서 모든 MS가 같은 DB를 바라보고 있음
• 연결되는 루프가 별같다고 해서 Death star

-> 비즈니스 로직이 서로 너무 강한 연관성을 갖고 있을 경우 그냥 Monoliths으로 쓰자!

 

 

 

5. MSA 보완 설계 패턴

1. Service Mesh : 요즘 떠오르고 있는 패턴

• MSA 구동 리소스는 내부 traffic에 집중
• 통신 흐름을 제어하기 위한 Mesh
• 기타부분을 Sidecar로 다 싣고, 비즈니스 로직에만 집중하자는 패턴
• 컨테이너에 MS와 Sidecar를 같이 올림
• Sidecar는 전부 Proxy화 되어 있어 잡스러운건 Sidecar가 다 알아서 해주겠지!

 

 

 

2. Severless Computing

• Business logic 외 모든 부분을 cloud에 위임
• 개발자는 business code만 작성해서 코드를 Severless platform에 업로드
• 정해진 run-time limit 안에 로직 수행 후 결과 반환하고 종료
• Cold-Start lssue 있을 수 있음

 

 

 

---

이번엔 아는내용이 좀 있어서

ex) ACID, Serverless

편하게 들은 시간이 있었다.

 

오늘은 과제하는 날이라

수업이 없어서 행복하다

 

 

 

근데 과제가

도메인 모델 그리고

MSA 설계하고 REST API 설계하고

Service Interface 만들기인데

 

서버 개발하는건 그렇다 쳐도

도메인 모델을 어떻게 그려야 할지 잘 모르겠다.

 

인터넷에 쳐봐도

딱 이렇게 그리세요! 하는 참고자료가 없고

다들 제 각각이고

 

강사님도

필요한 내용만 들어가면 되고

그리고싶은대로 그리라고 하셔서

오히려 더 헷갈린다

 

그래도 수업이 없어서 행복해