넷플릭스도, 아마존도 쓴다는 구조가 있습니다.
그렇다면 우리 서비스도 처음부터 그 구조로 만들어야 할까요?
결론부터 말하면, 대부분은 그럴 필요가 없습니다.
아마존 프라임 비디오 팀은 2023년에 오히려 반대로 움직였습니다.
영상 모니터링 서비스를 한 덩어리로 합친 것입니다.
그 결과 해당 서비스의 인프라 비용을 90% 줄였다고 공개했습니다.
서비스를 쪼개는 것이 항상 정답은 아닙니다.
오늘은 MSA 뜻과 모놀리식의 차이, 쓰는 시점을 3가지로 정리합니다.
하나. 하나의 서비스를 작은 서비스 여러 개로 나눈 구조입니다
MSA는 Microservice Architecture, 즉 마이크로서비스 아키텍처의 약자입니다.
쇼핑몰이라면 회원, 상품, 주문, 결제를 각각 독립된 서비스로 만듭니다.
서비스끼리는 API로 데이터를 주고받습니다.
API는 정해진 형식으로 요청과 응답을 주고받는 창구입니다.
반대로 모놀리식(Monolithic)은 모든 기능을 한 프로그램에 모은 구조입니다.
코드와 배포, 데이터베이스가 대부분 하나로 묶여 있습니다.
모놀리식은 한 덩어리이고, 마이크로서비스는 여러 조각이 협력하는 구조입니다.
둘. 차이는 배포, 장애, 확장에서 드러납니다
배포: 모놀리식은 결제 코드 한 줄만 고쳐도 전체를 다시 배포합니다.
마이크로서비스는 결제 서비스만 따로 배포할 수 있습니다.
장애: 모놀리식은 한 기능의 오류가 전체를 멈추게 할 수 있습니다.
MSA는 차단 장치를 두면 장애를 한 서비스 안에 가둘 수 있습니다.
다만 장치가 없으면 장애가 서비스를 타고 연쇄로 번지기도 합니다.
확장: 모놀리식은 트래픽이 몰리면 프로그램 전체를 복제해야 합니다.
마이크로서비스는 트래픽이 몰리는 서비스만 서버를 늘릴 수 있습니다.
대신 대가가 따릅니다.
서비스 사이의 통신 오류와 데이터 정합성, 모니터링을 따로 챙겨야 합니다.
쿠버네티스처럼 여러 서비스를 배치하고 관리하는 운영 도구도 필요해집니다.
| 기준 | 모놀리식 | MSA |
|---|---|---|
| 배포 | 결제 코드 한 줄만 고쳐도 전체를 다시 배포 | 결제 서비스만 따로 배포 |
| 장애 | 한 기능의 오류가 전체를 멈출 수 있음 | 차단 장치를 두면 한 서비스 안에 가둠 |
| 확장 | 트래픽이 몰리면 프로그램 전체를 복제 | 몰리는 서비스만 서버를 늘림 |
| 운영 부담 | 하나만 관리하면 되므로 단순함 | 통신 오류·데이터 정합성·모니터링을 서비스마다 챙겨야 함 |
개발의 복잡함을 운영의 복잡함으로 옮기는 선택입니다.
셋. 이런 신호가 보일 때 나눕니다
소프트웨어 설계 전문가인 마틴 파울러의 권고가 있습니다.
바로 '모놀리스 먼저(Monolith First)'입니다.
처음에는 하나로 만들고, 필요가 확인된 부분만 떼어내라는 뜻입니다.
나누어도 되는 신호는 3가지입니다.
- 여러 팀이 같은 코드를 고치면서 배포 일정이 자주 부딪힐 때
- 특정 기능에만 트래픽이 크게 몰릴 때
- 기능마다 다른 언어나 데이터베이스가 필요할 때
초기 서비스나 MVP 단계라면 모놀리식이 더 빠릅니다.
요구사항이 자주 바뀌는 시기에는 서비스 경계를 잘못 긋기 쉽기 때문입니다.
내부를 모듈로 잘 나눈 모놀리식에서 시작하는 방식이 현실적입니다.
구조는 문제를 따라가야 합니다
MSA 뜻을 한 줄로 줄이면 '나누어 독립시키는 구조'입니다.
하지만 나누는 이유는 유행이 아니라 지금 겪는 문제여야 합니다.
배포 충돌인지, 트래픽 쏠림인지 먼저 확인해 보세요.
뚜렷한 문제가 없다면 아직은 모놀리식으로 충분합니다.
개발만 하는 업체와 운영까지 하는 업체, 그 차이를 아시나요?
개발만 하는 업체는 기능을 완성하면 일이 끝납니다.
운영까지 하는 업체는 출시 뒤에 생길 문제까지 고려해서 만듭니다.
에그코드는 자체 서비스를 직접 운영하는 개발사입니다.
그 운영 노하우를 바탕으로 외주 개발을 진행합니다.
함께 읽어보세요 — DDD 뜻과 도메인 주도 설계가 더 중요해진 이유 · MVP 뜻부터 제작까지, 개발비 아끼는 현실적인 순서 · 무중단 배포로 '점검 중' 없이 업데이트하는 법 · 에그코드 웹 개발 서비스