마이크로서비스 vs. 모놀리식 아키텍처: 무엇을 구축해야 하는가?
한 창업자가 저에게 아키텍처 제안서를 검토해 달라고 요청한 적이 있습니다.
그 에이전시는 11개의 서비스, 메시지 큐, 그리고 서비스 메시를 제안했습니다. 사용자가 한 명도 없는 단순한 예약 도구를 위한 것이었습니다.
그것은 함정입니다.
아키텍처 결정은 호스팅 비용, 배포 속도, 그리고 채용 계획을 결정합니다. 개발자에게 예산을 넘겨주기 전에 반드시 그 비용을 알고 있어야 합니다.
모놀리스 (The Monolith)
모놀리스는 하나의 코드베이스, 하나의 배포 단위, 하나의 데이터베이스를 사용합니다. 단순합니다.
시작 단계에서는 도메인 경계를 알 수 없습니다. 서비스를 너무 일찍 분리하면, 존재할 필요가 없는 경계선을 옮기는 데 시간을 허비하게 됩니다. 팀 규모가 작을 때는 모놀리스를 관리하는 것이 더 쉽습니다. API를 설정하는 대신 함수를 호출하면 됩니다. 새벽 2시에 버그가 발생했을 때, 에러는 네트워크 장애가 아닌 코드를 가리킵니다.
마이크로서비스 (Microservices)
마이크로서비스는 조직적인 문제를 해결합니다. 서로 다른 팀이 각자의 일정에 맞춰 코드를 배포할 수 있게 해줍니다. Netflix는 하나의 결함이 전체 시스템을 침몰시키는 것을 방지하기 위해 마이크로서비스를 사용합니다.
하지만 그 대가는 매일 치러야 합니다. 네트워크 호출은 지연 시간(latency)을 발생시킵니다. 데이터 일관성을 유지하는 것도 어려워집니다. 로그와 트레이싱을 관리하기 위해 전문적인 도구와 대규모 팀이 필요합니다. 적절한 인원이 없다면 결국 '분산된 모놀리스(distributed monolith)'가 되고 맙니다. 이는 네트워크의 복잡성은 모두 가져가면서, 독립성은 전혀 누리지 못하는 상태를 의미합니다.
모듈러 모놀리스 (The Modular Monolith)
이것은 절충안입니다. 코드의 서로 다른 부분 사이에 명확한 경계가 있는 하나의 애플리케이션입니다. 결제(Billing) 모듈이 주문(Orders)의 핵심 로직을 건드릴 수 없습니다.
Shopify와 GitHub가 이 방식을 사용합니다. 깔끔한 경계를 유지하면서 네트워크 비용(network tax)을 피할 수 있습니다. 앱의 특정 부분이 마침내 단독으로 확장(scale)되어야 할 때, 경계가 이미 정의되어 있으므로 쉽게 분리할 수 있습니다.
결정 방법:
- 팀 규모: 팀원이 3명뿐이라면, 별도의 서비스와 그에 따른 온콜(on-call) 순번을 관리할 수 없습니다.
- 제품 안정성: 제품이 매주 바뀐다면, 다음 달에는 서비스 경계가 잘못되어 있을 것입니다.
- 운영: 자동 롤백(rollback)과 로그 집계(log aggregation) 기능이 있습니까? 없다면 마이크로서비스는 고통을 초래할 것입니다.
- 확장성: 가상의 성장을 위해 구축하지 마십시오. 눈에 보이는 구체적인 경로를 위해 구축하십시오.
만약 답변이 "아직은 아니다"라면, 모듈러 모놀리스를 구축하십시오.
단순히 단어가 현대적으로 들린다는 이유로 마이크로서비스를 요구하지 마십시오. 제품이 무엇을 하는지, 그리고 누가 이를 유지보수할 것인지를 파트너에게 말하십시오.
제품은 출시되지 못하면 사장됩니다. 깔끔한 모놀리스(monolith) 구조는 사용자에게 가장 빠르게 다가갈 수 있는 방법입니다. 그것부터 먼저 구축하세요. 시스템을 분리해야 할 시점은 트래픽이 알려줄 것입니다.
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi