[마이크로서비스 아키텍처 구축] 3. 모놀리스 분해

해당 글은 마이크로서비스 아키텍처 구축에서 학습한 내용을 다룹니다.

목차

1. 모놀리스가 적이 경우는 드물다
2. 무엇을 MSA로 먼저 전황해야할까?
3. MSA 전환 방식 - 교살자 무화과 패턴(Strangler Fig Pattern)
4. MSA의 DB 이슈

1. 모놀리스가 적인 경우는 드물다

• MSA에서 성취하고자 하는 것을 명확하게 이해하지 못하면 MSA를 만드는데만 집착하게 될 수 있고, 이는 MSA 도입 후 새로운 복잡성을 도래한다
• 다시 말하지만 Monolithic != 레거시 라는 것을 기억하자
• 시스템을 조기에 MSA로 분해하면 많은 비용이 발생한다 (특히 해당 프로젝트의 도메인 지식이 없는 사람은 더더욱)
• 때문에 MSA로 분해하려는 기존 코드베이스를 보유하는 것이 처음부터 MSA를 진행하는 것 보다 훨씬 빠르고 쉽다

나의 사례

• 생각해보니 회사에서 Monolithic -> MSA로 전환할 때, 외부 API를 호출하는 부분에서 단순 OpenFeign으로 외부 API를 호출하는 것이 아닌, 프로젝트 내부에 멀티 모듈을 통해서 외부 도메인에 대해 API를 호출하는 로직이 있었다
• 초기에는 모듈을 가지고 있지만, 나중에는 점점 OpenFeign으로 API를 호출하는 방향, 즉, 모듈에 대한 의존성을 제거하는 방향으로 간다고 했다 (여기서 일부 모듈은 또 다른 MSA 프로젝트로 생성될 예정)
• 모듈 안에서도 최종적으로는 OpenFeign으로 외부 API를 호출하는데, 굳이 왜 모듈을 추가한걸까?
• 이는 초기 개발 속도를 빠르게 하기 위함이었다 (중복코드 제거, 재사용성 상승, 코드의 일관성 유지 등)

2. 무엇을 MSA로 먼저 전환해야할까?

• MSA 전환이 필요한 이유를 중점으로 생각해야 함
• 어플리케이션 확장을 원하면 부하 처리 능력을 제한하는 기능이 가장 높은 순위
• 서비스 출시 시간을 단출하고 싶으면 자주 변동되는 기능을 찾아 MSA로 전환
  • CodeScene같은 정적 분석 도구로 어플리케이션의 핫스팟 분석 가능

3. MSA 전환 방식 - 교살자 무화과 패턴 (Strangler fig pattern)

• 레거시 시스템을 점진적으로 교체하여 레거시 시스템을 단계적으로 페이드 아웃
• 단계적으로 이루어지기 떄문에 단기간에는 이룰 수 없음

4. MSA의 DB 이슈

MSA로 아키텍쳐가 구성될 경우 결국 한 마이크로서비스 당 최소 1개의 고유 DB를 갖게된다.
그리고 대다수의 성능 이슈는 여기서 발생한다.

(1) DB Join

• DB 조인이 불가능하며, 자체적으로 마이크로서비스 자체로 조인 작업을 해야함
  • 같은 DB에서 자체 조인이 가능했던 Monolithic 보다 속도가 빨라지기 힘듦

(2) 데이터 무결성

• 서로 다른 DB에서는 더 이상 데이터 모델의 무결성을 강제할 수 없음
• 대처 패턴이 방법이 될 수 있는데, 데이터 삭제시 식제로 사제가 진행되는 물리적 삭제, 즉, Hard Delete가 아닌 논리적 삭제인 Soft Delete를 실행
  • ex : SET isDelete = true

(3) 트랜잭션

• MSA에서 트랜잭션의 안정성을 보장하는데 한계가 존재
• 분산 트랜잭션으로 대응책은 가능하나, 구현의 복잡성 및 적용 범위의 한계가 명확
• 관련 개념으로 사가(SAGA) 패턴 존재