🌱 서론

• 📣 스피커 : 이희창 (29cm)
• 세션을 선택한 이유
  - 서비스가 폭발적으로 성장하면서 MSA 로 전환을 한 과정에서 어떠한 고민을 했고, 어떤 선택을 했는지 궁금했다.

✍🏻 세션 정리

1. 시작은 모놀리틱

모든 비지니스의 시작은 모놀리틱 구조로 시작한다.
모놀리틱의 장점은 '단순함과 명료함' 에 있다.

이러한 모놀리틱의 장점은 서비스의 성장 📈 과정에서 한계점을 맞이하게 된다.

서비스가 성장할수록 어플리케이션의 도메인과 비지니스 로직이 늘어나게되고,
이러한 모든 도메인들이 하나의 어플리케이션에 담기게 되면서 장애 빈도가 높아지게 된다.

모놀리틱이 한게를 맞이하는 증상

• 코드를 고칠 때 시스템 장애 빈도가 잦아진다.
• 대량 트래픽 인입 시, 장애가 생긴다.
• 코드 배포 주기가 느려지게 된다.
• 요구사항 추가 및 변경이 될 때 많은 것을 고민하게 되면서 어려워진다.
• 하나의 코드를 고칠 때 예상치도 못한 사이드 이펙트가 생긴다.

그리하여, 29cm 는 MSA 로의 전환을 고려하게 된다.

2. MSA 로의 전환

🍧 왜 MSA 인가?

MSA 의 장점

• 확장성을 제공해주는 아키텍처
• 점진적인 코드 구조 개선이 가능함

하.지.만,
늘 그렇듯 MSA 는 은탄환이 아니다.
트레이드 오프의 관계로서 이해되어야 한다.

MSA Tax (MSA 세금)

• 의미 : MSA 로 전환을 하게 되면서 지불해야 하는 것들을 의미한다.
• 구현의 복잡도
• 테스트 디버깅 비용이 커짐
• API 호출 레이턴시의 증가

🍬 Output Goal vs Input Goal

29cm 의 MSA 전환으로서의 Output Goal 은 MSA 로의 전환 이었다.

그렇다면 Output Goal 이루기 위한 Input Goal 은 무엇인가?

🔑 Input Goal #1. MSA 전환을 위한 전략

전략 1. 스트랭글러 패턴

• 기존 기능과 동일한 로직을 신규 서비스에 구현한다.
• ALB 등을 활용하여 기존 서비스와 신규 서비스에 트래픽을 적절하게 분배한다.
• 신규 서비스 검증이 완료되면 모든 트래픽을 신규서비스에 전달한다.
• 기존 서비스 로직을 제거한다.

-> 스트랭글러 패턴 전략을 통해 점진적으로 신규 MSA 서비스로 이관 했다.

전략 2. 새 술은 새 부대에

• 새로운 기능은 신규 서비스에 구현한다.
• 새로운 기능 요건이 생기면 신규 MSA 도메인에서 구현을 시켰다.

전략 3. 도메인의 '임팩트 기준'으로 기존 모놀리틱 레거시 로직의 분해 순서 결정

• 도메인의 의존 관계를 생각하면 가장 하단의 베이스 도메인을 먼저 전환 하는 것이 좋다. (유저, 인증 등)
• 하지만, 29cm 는 비지니스 임팩트가 큰 '상품', '커머스' 도메인을 먼저 분해하여 전환했다.
• 비지니스 임팩트가 큰 것을 먼저 전환할 때 얻는 이익에 더 초점을 맞췄다.

전략 4. 기존 모놀로틱 서비스의 활용

• 기존 서비스는 인증등 분리된 도메인의 트래픽을 분배하는 역할로 활용했다.
• 기존 서비스를 없애기 전까지 최대한 활용하는 전략을 사용했다.

🔑 Input Goal #2. 동료 개발자 채용

MSA 는 비용이 많이 드는 아키텍처다.
채용을 위해서 기술 스텍을 Spring 으로 전환 한 29cm.

기존의 개발자들은 비지니스 모델에 대해 잘 알고 있고,
새로 채용된 개발자들은 변경한 언어와 프레임워크에 대한 이해도가 있었다.
서로 상호 보완하며 MSA 로의 전환을 이루어 냈다.

🍰 MSA 전환을 위한 주요 팁

모놀리틱이 무조건 나쁜건가요?

• 절대 아니다.
• 29cm 또한 상황에 따른 선택을 한 것 뿐이다.
• 인프런 아키텍처 강의에서도 들었듯이, 각 팀과 비지니스 모델, 환경등 여러가지 요인을 고려하여 선택해야한다.

기술에 대한 선택은?

• MSA 이므로 다양한 기술 스택 선택이 가능하다.
• 하지만 29cm 가 채용을 위해 기술 스텍을 전환한 것 처럼, 팀의 상황과 효율을 고려해야한다.

처음 도메인을 쪼갤 때는 어떻게 해야하나요?

• 처음부터 세분화 하려는 욕심을 버려라.
• 우선은 크게 쪼개고 점진적으로 세분화한다.
• MSA 의 장점은 도메인별로 점진적인 변화가 가능하다는 것이다.
• 처음부터 세분화를 하여 분리하면 인프라 운영 비용이 늘어난다.

3. 성장 과정에서의 도전

⛔️ 장애 발생

'장애' 라는 것은 정상적으로 돌아가는 시스템에 '새로운 것이 도입될 때' 즉, '변화가 생길 때' 장애가 생기는 것이다.

MSA 서비스에서 클라이언트가 다양한 도메인 정보를 필요로 할 때, 도메인 별 API 를 호출하고 응답을 받아야한다.
이 문제를 해결하기 위해 29cm 는 'Materialized View' 를 활용했다.
즉, 각각의 도메인 서비스에서 필요한 정보를 사전에 수신하여 별도로 저장하였다.
클라이언트는 Materialized View 를 통해 반정규화된 정보를 빠르고 단순하게 가져올 수 있도록 구현했다.

가장 중요한 것은, 동일한 사유로, 동일한 장애가 발생하지 않도록 하는 것이 중요하다.

개발 디자인 문서 작성

29cm 는 개발 디자인 문서를 작성하는 문화를 정착 시켰고, 이를 통해 많은 이득을 가졌다고 한다.

시스템의 일관성, 업무 속도, 구성원의 성장 모두를 얻을 수 있었다고 한다.🤔

🙏🏻 개인 소감

• 비지니스의 폭발적인 성장으로 인해 모놀로틱에서 MSA 로 전환하는 과정을 짧은 시간이었지만 생생하게 들을 수 있었다.
  역시나 MSA 도입에 있어서는 많은 고민과 깊이가 필요하다는 생각이 들었다.
  아직 개인적으로 MSA 를 경험해본적이 없어서 막연하게 MSA 에 대한 환상을 가지고 있는데, 이번 세션을 비롯한 올해 인프콘에서 여러가지 생각을 하게 된것 같다.
  귀한 경험을 공유해주신 발표자님께 감사하다.