타사 MSA 분석하기

1. 우아한 형제

https://techblog.woowahan.com/7835/

회원시스템 이벤트기반 아키텍처 구축하기 | 우아한형제들 기술블로그

 

무엇을 이벤트로 발행할 것인가?

“회원의 본인인증이 초기화되는 경우 가족계정 서비스에서 탈퇴되어야 한다"  정책 존재

 

MSA 변경 과정

 

1. 가족계정 서비스 탈퇴 로직은 회원의 본인인증 해제 로직에 깊게 관여되어 강한 결합을 가지고  있음 이를 회원 시스템, 가족계정 시스템 으로 물리적 분리

2. 비동기 호출을 통한 물리적 분리 http 방식과, 메시징 방식을 통해 분리 가능

3. http 방식은 별로 쓰레드를 생성해서 해상을 호출한다는 의도가 있기 때문에, 결합이 느슨하다고 볼 수 없다.

4. 회원의 본인인증 해제가 발생할 때 가족계정 탈퇴 메시지를 발송하게 되면은 가족계정 탈퇴를 기대하는 메시지를 발행했기 때문에 결합이 느슨하다고 볼수 없다. 로직에 종속 성이 있기 때문이다.

5. 대상 도메인에게 기대하는 목적을 담은 메시지를 발행하면 종속성이 있기 때문에 안된다. 

6. 회원의 본인인증 해제가 발생할 때 본인인증 해제 이벤트를 발송하여 가족계정 시스템에서 단순 이벤트 발생을 구독하여 처리 하도록 변경

 

이후 내용 추후 정리...

 

2.  카카오

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

이모티콘 서비스는 왜 MSA를 선택했나?

 

1. MSA 변경 과정

1-1). 현장조사

-> 운영되고 있는 모놀리스 서비스 파악

-> 운영이슈 파악 : CI/CD 관리, 코드 관리, 트랙픽 관리

-> 기술이슈  파악 : 무거운 서비스에 대한 변경 어려움, 과거 기술에 종송적

 

1-2). 설계

MSA도입을 통해 예상되는 장점

운영 측면 

• 배포 단위가 작아진다.
• 배포 영향 범위가 줄어든다.
• 배포 버전 관리가 독립적이 된다.
• Branch 엉키는 일이 줄어든다.

 

기술 측면 

• 서비스가 작아져 역할이 명확해지고, 디버깅 포인트를 고립시킬 수 있다.
• 설계변경에 대한 부담이 낮아진다.
• 각 서비스별로 기술 선택의 의존성이 낮아져서 각 서비스에 맞는 최적 기술을 선택이 가능해진다.

 

MSA도입을 통해 예상되는 고통

 

기술 측면

• 함수 호출이 Network I/O 호출로 바뀌게 된다. (서비스간 상태 동기화가 어려워진다.)
• DB 분리 시에 Join이 어려워진다.

 

운영 측면 

• 관리해야 할 서비스가 많아진다.

 

1-3) 시공

 

MSA 적용을 위해 해야 할 일

• 서비스 배포 환경을 통합하고 리소스 설정이 간단하게 되도록 하자
• 서비스 간 연결 관계와 모니터링을 쉽게 만들자
• 서비스를 나누자

 

서비스 간 연결 관계와 모니터링을 쉽게 만들자

 

클러스터를 나누고, 스테이지를 구분 짓고, 서비스를 나누다 보니 기본 쿠버네티스 컨트롤러만으로는 커버하기 힘든 상황들이 나오기 시작했습니다.

 

-> 도입된 것이 이스티오(Istio) 으로 모니터링

 

서비스를 나누자 

알려진 방법인 Api gateway를 사용해 레거시를 고립시키는 방법을 선택

-> Spring Cloud Gateway를 선택

 

Ingress 를 둔 이유는

 

트레픽 고립과는 별도로 auth 서비스를 하기 위해, ingress 라우팅만 사용하면 모든 서비스에 인증 관련 컨트롤 코드가 들어 가야 하지만, Spring Could GateWay 를 통해 특정 controller 에서 auth 사용하게 분리가 가능하기 때문에 사용

 

Microservice의 단위 정의 

 

• 기능 목적이 2개 이상이 되지 않도록 한다. 
• 여러 기능에서 사용하는 단위 리소스라면 서비스로 분리하여 공동 사용한다.
• 사내 통제 대상인 Admin인 경우, 최소한으로 통제 Cluster에 넣도록 서비스를 분리한다.
• 개인 정보 대상으로 분류된 데이터를 관리하는 서비스는 해당 데이터 관리에 필요한 기능을 최소화하여 분리한다.
• 마지막으로 서버 렌더링을 배제하기 위해 Front서비스와 Backend 서비스는 서로 분리한다.

 

1-4) 감리

 

Microservice로 분리 후 좋아진 점

1.업무 역할 분담이 명확해졌다

2.배포의 부담이 많이 낮아졌다

3.신규 서비스 기능 추가가 쉽다

 

Microservice로 분리 후 힘들어진 점

1.설계 제약 사항과 고민들이 늘어난다 : 네트워크 I/O, 서비스간 동기화, 서비스 개발시 DB 분리

2.개인이 담당할 서비스가 늘어난다

3.서비스가 도메인 지식 공유가 힘들다

 

MSA 적용이 수월했던 간접적인 이유

기술적인 부분도 있었지만 팀의 분위기도 적지 않은 영향을 줬다고 생각합니다. 기존 환경에 대한 불편함을 뭉개고 앉아있는 것이 아니라, 어떻게든 개선을 하려고 하는 구성원들 덕분

 

3. 카카오 페이

https://tech.kakaopay.com/post/msa-transaction/

MSA 환경에서 네트워크 예외를 잘 다루는 방법 | 카카오페이 기술 블로그

 

고객에게 정확한 결제서비스를 제공하기 위해선 높은 수준의 무결성이 요구되는데요, 이번 글에서는 마이크로 서비스 환경의 다양한 네트워크 통신 과정에서 어떤 문제들이 발생할 수 있고 상품권 도메인은 결제 트랜잭션을 보장하기 위해 어떻게 문제를 풀어가고 있는지 공유드리고자 합니다.

 

MSA와 글로벌 트랜잭션

 

 

결제 트랜잭션 관리

 

데이터를 저장하는 서버들은 트랜잭션 관리가 기본이지만 결제 도메인에 있어서는 매우 중요하고 민감하게 다뤄야 한다고 생각합니다. 단 한 번의 예외적인 상황으로도 고객에게 큰 불편을 야기할 수 있고 서비스 신뢰도까지 영향을 줄 수 있기 때문입니다.

 

 

글로벌 트랜잭션 관리

 

MSA는 각 서비스마다 DB가 따로 있기 때문에 트랜잭션에 참여하는 서비스가 여럿이라 하더라도 각 DB에 걸쳐서 데이터 일관성을 보장할 수 있어야 합니다. 이를 여러 서버, DB에 걸친 트랜잭션을 글로벌 트랜잭션, 분산 트랜잭션이라고도 표현합니다.

 

 

MSA에서 글로벌 트랜잭션을 관리하는 방식은 여러 가지가 제시되어 있지만(대표적인 saga pattern) 어떤 방식이든 이기종간 네트워크 요청을 주고받는 형태가 됩니다.

 

네트워크 요청의 성공과 예외 처리

 

예외가 발생 할 수 있는 경우

• 같은 요청이 짧은 시간에 두 번 이상 발생한 경우
• 네트워크 순서가 뒤집힌 경우 (취소 요청 후 결제 요청)
• 각종 타임아웃
• 인프라 문제로 인한 실패

 

API를 요청하는 입장
-> 알 수 없는 에러를 처리하기

API를 제공하는 입장
-> 멱등성 API 제공하기

 

 

알 수 없는 에러 처리

 

에러로 인한 결과 예상

• 결제 서버로 요청이 들어갔는지?
• 요청은 갔으나 성공했는지?
• 요청은 갔으나 실패했는지?

 

결제 서버는 요청을 받아 잔액을 차감했지만, 주문 서버에서는 타임아웃으로 제대로 응답을 받지 못하여 실패로 저장했다면 고객 입장에서는 돈이 빠져나갔는데 주문은 실패가 된 상황이겠죠.😭

 

해당 에러의 경우 후처리 방식

• 즉시 재요청 시도
• 일정 시간 뒤 재시도
• 요청이 성공했는지 확인 후 재시도
• 결제 취소 요청 (트랜잭션 무효화 요청, 보상 트랜잭션 개념)
• 무조건 성공 후 뒤처리
• 수기로 처리

무한 루프 에러 처리

-> 에러처리를 위한 에러후속처리 (결제 실패로 결제 취소를 호출 했는데, 결제 취소가 에러나 가서 결제 취소를 취소 해야 하는 현상 등...)

 

멱등성 API

 

동일한 요청을 여러 번 보내도 같은 응답을 줄 수 있으면 해당 API는 멱등성이 있다고 표현하고, 결제 서버에서 멱등성을 제공한다는 것은 한 번 성공, 실패가 되었다면 동일한 결제 요청이 이후 여러 번 오더라도 같은 응답을 준다는 것입니다.

• 이미 성공한 결제 요청이 두 번(혹은 여러 번) 들어왔을 때
  1. 실패로 응답
  2. 성공으로 응답

한편 동일한 요청이 무엇인지 정의하는 것은 매우 중요합니다.

 

동일한 요청임을 구분할 수 있게 API 요청 값에 유니크한 값을 추가로 받도록 하면 반복해서 동일한 응답을 주는 것이 가능합니다. 유니크 키는 API 요청 혹은 헤더값에 포함할 수 있습니다.

 

예외를 잘 다루는 방법

 

try catch 가 깊어지는 부분에서의 리팩토링은 주의할 점이 있는데요. exception을 상위로 전파시키는 형식의 트랜잭션 분리는 의도치 않은 롤백이 될 수 있기 때문입니다. 

 

Optional<T> java data type 을 이용한, 성공, 실패, 그외 의 경우를 다룰 수 있습니다.