MSA-2.1-MSA로 전환하기

jaegeunsong97·2023년 9월 4일

msa

MSA

목록 보기

5/6

MSA 전환이 필요한 상황 진단

필요성 측면
- 개발, 배포 시 다른 팀의 소스 혹은 공통 모듈 등으로 인한 일정 조율/커뮤니케이션이 방해될 정도?
- 느려지는 개발, 배포 과정으로 인해 필요한 비즈니스 개발지 지연된 적이 있나?
  - Business Capability
- 단 건의 배포로 인한 전체적인 영향도 파악이 어렵고, 실제로 이로 인해 놓친 부분으로 인해 장애가 빈번하게 발생?
- 공통적으로 사용하는 모듈 수정 시, 영향도 파악과 커뮤니케이션에 대한 부담이 압박으로 옴?
- 주요 서비스로 인한 빈번한 DB 부하로 인해, 타 서비스에서 영향을 받은 적이 있나?
가능 여부 측면
- 엔지니어링 조직에서 MSA 구조와 각 서비스의 통신에 대한 기본적인 아키텍쳐 이해?
- CI/CD 파이프라인을 위한 Devops/SRE 조직이 별도로 존재하고 트러블 슈팅을 위한 인프라 지식이 있나?
- 어려워진 트러블 슈팅과 모니터링 난이도를 해결하기 위한 (EFK, Prometheus, Elastic Search, Grafana...) 들 구축을 적절하게 할 수 있는 상황?
- MSA/Cloud 환경에 대한 적절한 보안을 책임질 수 있는 보안 담당자 존재?
- 사내 엔지니러이 최고 책임자 MSA 전환에 대한 충분한 필요성 공감?

MSA 전환을 위해서 풀어야 할 문제 식별 및 패턴, 분해패턴, 통신패턴, 트랜젝션패턴

분해패턴 : 분해를 해결하기 위한 패턴
- 모놀리식에서는 1개의 서비스였지만 MSA로 이동하며 1개의 서비스를 N개로 분리
- 그럼 어떤 판단 기준으로 분리를 할 것인가?
- 비즈니스와 하위 도메인 패턴별 분리 2가지는 유동적임
  - 즉, 칼로 무 자르듯이 확실하게 분리할 수 없다는 뜻
- 비즈니스 능력에 대한 분해 : Business Ability
  - 복잡한 비즈니스 능력을 기준
  - 원래 송금에는 여러 기능들이 있음, 이 1개의 서비스를 기능별로 분리하면 비즈니스 측면으로 분리하는 것
  - 장점
    - 비즈니스 복잡 -> 대규모 조직(금융)
    - 비즈니스 특성으로 인해 내부 서비스간 통신이 빈번한 경우
  - 단점
    - 비즈니스로 나눴기 때문에 서비스간 응집도와 결합도, 종속성 높음
    - 서비스, 즉 도메인 별 팀의 구조가 희석될 가능성 높음
      - 콘웨이 법칙 : 만든 시스템 구조에 따라서 비즈니스 구조가 따라감
- 하위 도메인 패턴별 분해(Sub-Domain) from DDD
  - 복잡한 비즈니스여도, 포함된 내부의 하위 도메인을 단위로 분리
  - 행동을 한다(상위 개념)
    - 계좌 도메인
    - 내부 머니 도메인
    - 뱅킹
  - 장점
    - 독립성, 격리성 증가 -> 결합도 감소
    - 종속성 최소화, 서비스 간 영향도 감소 -> 특정 서비스 하나하나가 규모가 큼
    - 따라서 장애 영향이 최소가 됨(혼자만 터지니까)
    - MSA 철학에 부합
  - 단점
    - 서비스가 너무 많아서 불필요한 통신 많음 -> 성능 이슈
    - 따라서 지나치게 많은 서비스로 분리 가능성 높음
    - 대규모 시스템에는 매우 비효율적
      - 따라서 적절하게 분리해야 함
송금 서비스 예시
- AML : 자금 세탁 방지
- CTR, STR : 고액, 의심 현금 거래

통신패턴
- 서비스가 쪼개졌으니까 어떻게 통신 할래? 해결
- Sync Pattern : 동기
  - Request 보내고 Response 받을 때까지 멈취있어도 되는 경우
  - 즉, 프로세스가 놀고있는 것, 비효율적
  - HTTP, gRPC
- Async Pattern : 비동기
  - Response를 당장 받을 필요 없는 경우
  - 그 동안 프로세스가 놀지 않고 다른 일을 하는 거니까 효율적
  - Kafka를 이용한 Message Queueing : event 쌓기
  - Callback : 비동기로 받은 response를 main 스레드와 관계없이 받으면 처리하는 것
    - event trigger method
  - Polling : 일정 주기마다 HTTP, gRPC를 통해 "아까 request 잘 됨?"이라고 물어보는 것
    - 그래서 response가 필요없는 경우 DB에 저장해서 Polling으로 물어보면 답해줌

트랜젝션패턴
- 서비스가 많으니까 트랜젝션을 관리해야되는 문제 해결
- 2PC : 2 Phase Commit, 고전적 방식
  - 코디네이터 : 2PC manage
    - 이 녀석도 관리를 해줘야하는 문제가 있음
  - 트랜젝션 관리 2단계로 관리
  - 2번의 커밋 전부 성공해도 코디네이터에게 알려주는 과정에서도 Error 발생 가능성이 있음
- 보상 트랜젝션 : Compensating Transactions
  - 완정히 종료된 트랜젝션을 그 이전 상태로 되돌리기 위한 트랜젝션
- 사가 패턴 : Sage Pattern
  - 보상 트랜젝션의 장점 + 2PC 장점
2PC
- 보상 트랜젝션 등장 이유 : 4번에서 커밋/롤백 을 코디네이터에게 알려주는 과정에서 요청이 안 날라갈 수 있어서

보상 트랜젝션
- 결론 : 트랜젝션 관리 너무너무너무너무너무 어려줌
- 사용안하는 것이 가장 BEST

Saga
- Saga 시작 후, 일정시간 동안 코디네이터에게 롤백/커밋 이 날라오지 않으면 자동으로 보상트랜젝션 사용

데이터쿼리, 가시성, 신뢰성 그 외 패턴들

데이터 쿼리 패턴 : MSA 설계하면서 생긴 데이터 쿼리의 어려움을 해결하는 패턴
- 2가지 패턴 모두 목적은 동일
- API Aggregation 패턴 : API 조합 패턴
  - API 조합기를 통해 여러개의 도메인에 대한 데이터 요청 후, 받아와서 1개의 값으로 return 하는 패턴
- CQRS 패턴 : Command와 Query 분리 패턴
  - Command : Write, Update, Delete
  - Query : Read
  - Command에서 수정된 값을 이벤트에 저장해서, Query 전용 DB에 저장 후, 복잡한 쿼리를 담당하는 것
가시성 : Visibility, Observability
- MSA 설계를 하면서 생긴 로깅, 모니터링의 어려움 해결하기 위한 패턴
- 한곳에서 모니터링
- 하나의 요청처럼 보이게 하는 트레이싱(여러개의 트랜잭션을)
- 로깅 : 트러블 슈팅, 누락 X
  - 목적 : 문제를 디테일하게 봐야하기 때문에 누락이 되면 안됨.
- 메트릭 : 시계열 지표들 저장, 누락 가능
  - 목적 : 증감률을 확인하는 것이 목적, 따라서 누락 가능
  - 증감 수치를 통해 alert
  - 일정 시간으로 확인 : N second
    - 프로메테우스, Influx
- 즉, 어떻게 구체적으로 로깅, 메트릭을 저장하고 인덱싱하여 검색할 지에 집중하는 패턴
신뢰성 : Reliablilty
- MSA 설계하면서 분리/분해로 인해 떨어진 신뢰성을 해결하기 위한 패턴
- 서킷 브레이커 : Circuit Breaker
  - 분산 시스템에서 장애 전파를 막고 피해를 최소화 하기 위한 패턴
  - 서킷 브레이커 있는 경우
    - 500 대신, 200과 msg 전달, 이를 통해 A는 신뢰할 수 있는 서비스
    - 장애 복구 -> 자가 치유
  - 서킷 브레이커 없는 경우
    - 전부 500
- 장애복구, 자가 치유, 무정지 배포
MSA로 인한 문제 발생 후, 해결 방법 패턴
- 테스트 패턴
  - Mono : 서버 1개의 간단한 테스트
  - MSA : 서버 여러개이기 때문에 모듈끼리, 비즈니스끼리, 서비스끼리 테스트 필요, 복잡
  - 따라서 여러방식의 테스트 본질을 해결하기 위한 패턴
- 외부 API 패턴
  - MSA에서 서비스 호출 시, 직접 호출이 아닌 외부 API를 통해 호출
  - 즉, 통신과 관련된 종속성을 해결하기 위한 패턴
- 디스커버리 패턴
  - Mono : 서버 1개, 관리 간단
  - MSA : 서버 여러개, 관리 복잡 -> 해결을 위한 패턴
  - 서비스가 정상작동하는지, 적절한 동작을 하는 메커니즘을 제공하는 패턴