모든 비지니스의 시작은 모놀리틱 구조로 시작한다.
모놀리틱의 장점은 '단순함과 명료함' 에 있다.
이러한 모놀리틱의 장점은 서비스의 성장 📈 과정에서 한계점을 맞이하게 된다.
서비스가 성장할수록 어플리케이션의 도메인과 비지니스 로직이 늘어나게되고,
이러한 모든 도메인들이 하나의 어플리케이션에 담기게 되면서 장애 빈도가 높아지게 된다.
모놀리틱이 한게를 맞이하는 증상
- 코드를 고칠 때 시스템 장애 빈도가 잦아진다.
- 대량 트래픽 인입 시, 장애가 생긴다.
- 코드 배포 주기가 느려지게 된다.
- 요구사항 추가 및 변경이 될 때 많은 것을 고민하게 되면서 어려워진다.
- 하나의 코드를 고칠 때 예상치도 못한 사이드 이펙트가 생긴다.
그리하여, 29cm 는 MSA 로의 전환을 고려하게 된다.
MSA 의 장점
- 확장성을 제공해주는 아키텍처
- 점진적인 코드 구조 개선이 가능함
하.지.만,
늘 그렇듯 MSA 는 은탄환이 아니다.
트레이드 오프의 관계로서 이해되어야 한다.
MSA Tax (MSA 세금)
- 의미 : MSA 로 전환을 하게 되면서 지불해야 하는 것들을 의미한다.
- 구현의 복잡도
- 테스트 디버깅 비용이 커짐
- API 호출 레이턴시의 증가
29cm 의 MSA 전환으로서의 Output Goal 은 MSA 로의 전환 이었다.
그렇다면 Output Goal 이루기 위한 Input Goal 은 무엇인가?
전략 1. 스트랭글러 패턴
- 기존 기능과 동일한 로직을 신규 서비스에 구현한다.
- ALB 등을 활용하여 기존 서비스와 신규 서비스에 트래픽을 적절하게 분배한다.
- 신규 서비스 검증이 완료되면 모든 트래픽을 신규서비스에 전달한다.
- 기존 서비스 로직을 제거한다.
-> 스트랭글러 패턴 전략을 통해 점진적으로 신규 MSA 서비스로 이관 했다.
전략 2. 새 술은 새 부대에
- 새로운 기능은 신규 서비스에 구현한다.
- 새로운 기능 요건이 생기면 신규 MSA 도메인에서 구현을 시켰다.
전략 3. 도메인의 '임팩트 기준'으로 기존 모놀리틱 레거시 로직의 분해 순서 결정
- 도메인의 의존 관계를 생각하면 가장 하단의 베이스 도메인을 먼저 전환 하는 것이 좋다. (유저, 인증 등)
- 하지만, 29cm 는 비지니스 임팩트가 큰 '상품', '커머스' 도메인을 먼저 분해하여 전환했다.
- 비지니스 임팩트가 큰 것을 먼저 전환할 때 얻는 이익에 더 초점을 맞췄다.
전략 4. 기존 모놀로틱 서비스의 활용
- 기존 서비스는 인증등 분리된 도메인의 트래픽을 분배하는 역할로 활용했다.
- 기존 서비스를 없애기 전까지 최대한 활용하는 전략을 사용했다.
MSA 는 비용이 많이 드는 아키텍처다.
채용을 위해서 기술 스텍을 Spring 으로 전환 한 29cm.
기존의 개발자들은 비지니스 모델에 대해 잘 알고 있고,
새로 채용된 개발자들은 변경한 언어와 프레임워크에 대한 이해도가 있었다.
서로 상호 보완하며 MSA 로의 전환을 이루어 냈다.
'장애' 라는 것은 정상적으로 돌아가는 시스템에 '새로운 것이 도입될 때' 즉, '변화가 생길 때' 장애가 생기는 것이다.
MSA 서비스에서 클라이언트가 다양한 도메인 정보를 필요로 할 때, 도메인 별 API 를 호출하고 응답을 받아야한다.
이 문제를 해결하기 위해 29cm 는 'Materialized View' 를 활용했다.
즉, 각각의 도메인 서비스에서 필요한 정보를 사전에 수신하여 별도로 저장하였다.
클라이언트는 Materialized View 를 통해 반정규화된 정보를 빠르고 단순하게 가져올 수 있도록 구현했다.
가장 중요한 것은, 동일한 사유로, 동일한 장애가 발생하지 않도록 하는 것이 중요하다.
29cm 는 개발 디자인 문서를 작성하는 문화를 정착 시켰고, 이를 통해 많은 이득을 가졌다고 한다.
시스템의 일관성, 업무 속도, 구성원의 성장 모두를 얻을 수 있었다고 한다.🤔
개발자로서 성장하는 데 큰 도움이 된 글이었습니다. 감사합니다.