베트남 상위권 전자지갑의 지갑 코어와 위성 시스템 뒤에 있던 아키텍처 결정들 — 그리고 다시 한다면 무엇을 다르게 할지.
"마이크로서비스"는 흔히 모든 것을 잘게 쪼개는 것으로 읽힙니다. 실제로 가치는 서비스의 개수가 아니라 올바른 경계를 긋는 데 있습니다 — 조직도가 아니라 비즈니스 역량을 중심으로요.
전국 규모 전자지갑의 지갑 코어와 위성 시스템을 구축하며, 일관성·보안·확장성에 대한 엄격한 요구 하에 수백만 건의 거래를 처리했습니다. 프로덕션과 부딪히며 살아남은 몇 가지 교훈을 소개합니다.
1. 서비스 경계는 비즈니스를 따른다
하나의 서비스는 완결된 비즈니스 역량과 그 데이터를 소유해야 합니다. 두 서비스가 매번 업데이트마다 함께 바뀌어야 한다면, 그것은 경계가 잘못되었다는 신호입니다 — 둘은 하나여야 합니다.
2. 동기적일 필요가 없는 것은 이벤트 기반으로
- 자금 이동은 강한 일관성이 필요합니다 — 멱등성을 갖춰 동기적으로 처리합니다.
- 알림, 대사, 분석은 이벤트로 밀어내 비동기로 처리하여 메인 흐름을 막지 않게 합니다.
- 각 이벤트는 명령이 아니라 이미 일어난 사실입니다 — 생산자를 건드리지 않고 새 소비자를 추가할 수 있습니다.
3. 명확한 계약을 갖춘 API 우선
코딩에 앞서 API 계약을 정의하면 팀이 병렬로 일할 수 있고 마지막의 고통스러운 통합을 줄입니다. 모든 계약 변경은 버전으로 관리되며 기존 소비자를 절대 깨뜨리지 않습니다.
마이크로서비스는 공짜로 속도를 주지 않습니다 — 코드의 복잡성을 운영의 복잡성과 맞바꿉니다. 규모가 정말로 요구할 때만 그 비용을 치르십시오.
다시 한다면 다르게 할 것
더 적은 서비스로 시작하십시오. 잘 모듈화된 모놀리스를 확장 압력이 나타날 때 점진적으로 쪼개는 편이, 너무 일찍 쪼갠 뒤 다시 합치는 것보다 거의 언제나 저렴합니다. 관측성 인프라는 열 번째 서비스가 아니라 두 번째 서비스 이전에 존재해야 합니다.