마이크로서비스(Microservices) vs 모놀리식(Monolithic) 아키텍처: 풀스택 개발 파트너는 무엇을 구축해야 하는가?

작년에 한 창업자가 자신의 에이전시가 제안한 아키텍처를 검토해 달라고 요청했습니다. 11개의 서비스. 메시지 큐(Message queue). 서비스 메쉬(Service mesh). 제품은 캘린더와 결제 화면이 있는 예약 도구였고, 아직 사용자는 한 명도 없었습니다.

그것이 바로 한 장의 스크린샷에 담긴 함정입니다. 아키텍처 문제는 초기에 등장하며, 마치 엔지니어링의 각주처럼 들리지만, 여러분의 호스팅 비용, 배포 속도, 채용 계획, 그리고 새벽 2시의 호출(pages)을 위해 얼마나 많은 잠을 포기해야 할지를 조용히 결정합니다. 모놀리스(Monolith)냐 마이크로서비스(Microservices)냐는 작은 결정이 아닙니다. 따라서 풀스택(Full-stack) 개발 회사에 예산과 유행어를 건네기 전에, 각각의 방식이 실제로 어떤 비용을 치르게 하는지 아는 것이 가치가 있습니다.

그냥 모놀리스를 구축하세요 (대부분의 경우)

하나의 코드베이스(Codebase). 하나의 배포 대상. 하나의 데이터베이스(Database). 지루하지만, 지루함은 과소평가되어 있습니다.

제가 기술 혐오론자라서 하는 말이 아닙니다. Martin Fowler는 2015년에 "MonolithFirst"의 논거를 제시했고, 이는 시간이 흐르며 증명되었습니다. 첫날에는 도메인 경계(Domain boundaries)를 충분히 잘 알지 못하기 때문에 적절한 위치에서 분리할 수 없습니다. 너무 일찍 분리하면 잘못된 분리를 하게 되고, 결국 세워질 필요도 없었던 벽을 옮기는 데 비용을 지불하게 됩니다. Rails를 만든 DHH는 이와 반대되는 본능에 이름을 붙였습니다. 그는 이를 'Majestic Monolith(장엄한 모놀리스)'라고 부르며, Basecamp는 여전히 하나의 모놀리스로 운영되고 있습니다.

실제로 팀 규모가 작을 때는 모놀리스가 다루기 훨씬 쉽습니다. API를 구축하는 대신 함수(Function)를 호출하면 됩니다. 하나의 테스트 스위트(Test suite). 하나의 배포. 그리고 새벽 2시에 무언가 잘못되었을 때, 스택 트레이스(Stack trace)는 관련이 없을지도 모르는 두 서비스 사이의 불안정한 네트워크 홉(Network hop)이 아니라 버그를 직접 가리킵니다.

마이크로서비스가 제 역할을 하는 곳

이것들은 일시적인 유행이 아닙니다. 이들은 실제적이고 상당히 좁은 범위의 문제를 해결하며, 기술적인 문제라기보다는 조직적인 문제인 경우가 더 많습니다. 여러 팀이 각각 서비스를 소유하고, 각자의 일정에 맞춰 배포하며, 누구도 다른 사람을 가로막지 않는 구조입니다. 또한 앱의 나머지 부분을 끌어들이지 않고도 강력하게 확장해야 하는 단일 엔드포인트가 있는 경우도 해당됩니다. Netflix는 모두가 인용하는 사례입니다. 2008년 데이터베이스 장애로 인해 그들의 모놀리스(Monolith)가 다운되었고, 그들은 이후 단 하나의 결함이 전체 시스템을 침몰시키지 않도록 수백 개의 서비스로 분리하는 데 수년을 보냈습니다.

하지만 그 대가는 매일 치러야 합니다. 메모리 내에서는 비용이 들지 않았던 호출들이 이제 네트워크를 가로지르게 되므로, 지연 시간 (Latency), 재시도 (Retries), 그리고 절반만 완료된 요청 (Half-completed requests)을 직접 처리해야 합니다. 데이터는 서비스 전반에 퍼지게 되며, 데이터의 일관성 (Consistency)을 유지하는 것 자체가 하나의 로드맵이 됩니다. 트레이싱 (Tracing), 중앙 집중식 로그 (Centralized logs), 그리고 새벽 3시에 하나의 요청이 5~6개의 시스템을 타고 튀어 다닐 때 이를 추적할 수 있는 온콜 (On-call) 팀이 필요합니다.

사람들이 간과하는 부분이 바로 여기입니다. 이를 운영할 도구와 인력이 없는 상태에서 그 모든 메커니즘을 떠맡는다면, 당신은 마이크로서비스를 얻는 것이 아닙니다. 대신 분산 모놀리스 (Distributed monolith)를 얻게 됩니다. 즉, 네트워크로 인한 모든 비용은 발생하지만 독립성은 전혀 없는 상태가 됩니다. 이것이 바로 경계해야 할 유일한 결과입니다.

모두가 잘못 인용하는 Amazon 이야기

아마도

하지만 세부 사항을 주의 깊게 읽어보아야 합니다. 이것은 내부 도구 중 하나였을 뿐, Prime Video 플랫폼 전체가 아니었으며, Amazon이 마이크로서비스 (Microservices)를 포기한 것도 아닙니다. 진짜 교훈은 더 조용하고 정직합니다. 바로 해당 특정 작업에 있어서, 유행하는 선택이 단지 잘못된 선택이었다는 점입니다.

아무도 팔지 않는 중간 지대

제안서에 거의 등장하지 않는 세 번째 옵션이 있습니다. 주로 인상적으로 들리게 만들기 어렵기 때문인데, 바로 모듈형 모놀리스 (Modular Monolith)입니다. 여전히 하나의 애플리케이션이며, 여전히 하나의 배포 (Deploy) 단위입니다. 하지만 코드베이스 내부의 도메인 (Domain) 사이에 견고한 벽을 세웁니다. 결제 (Billing) 모듈이 주문 (Orders)의 내부 구조에 접근할 수 없습니다. 각 모듈은 정문 (Front door)을 가지고 있으며 나머지 모든 것을 비공개로 유지합니다.

Shopify가 명확한 예시입니다. 그들의 핵심은 수백만 줄에 달하는 Rails 모놀리스 (Monolith)이며, 수십 개의 컴포넌트 (Component)로 나뉘어 있습니다. 또한 Packwerk라는 사내 도구를 사용하여, 한 모듈이 다른 모듈의 내부 구조에 접근하는 즉시 빌드 (Build)를 실패하게 만듭니다. GitHub도 여전히 모놀리스입니다. Gusto도 마찬가지입니다. 이들 모두 사람들이 반드시 분리해야만 한다고 가정하는 규모를 훨씬 넘어선 상태입니다.

이는 훌륭한 거래입니다. 깨끗한 경계와 팀의 정신적 안정 (Sanity)을 얻으면서, 네트워크 비용 (Network tax)을 완전히 피할 수 있습니다. 그리고 특정 도메인이 정말로 모놀리스의 규모를 초과하게 될 때, 이미 견고한 경계를 가진 모듈을 떼어내는 것은 한 분기(Quarter)가 아닌 주말 정도의 작업이 됩니다. 코드상에 먼저 선을 긋고 그것이 유지되는지 확인함으로써, 분리할 권리를 획득하는 것입니다.

결정을 내리는 방법

이론은 건너뛰고 몇 가지 불편한 질문들을 마주해 보십시오.

첫 번째는 팀 규모입니다. 만약 세 명의 인원이 모든 것을 책임져야 한다면, 별도의 서비스들을 운영하면서 그에 따라 발생하는 온콜 (on-call) 순번까지 감당할 인력이 부족할 것입니다. 다음은 경계 (Boundaries)입니다. 만약 제품이 매주 변하고 있다면, 지금 긋는 어떤 경계선도 다음 달이면 잘못된 위치에 있게 될 것이므로 경계를 유연하게 두십시오. 그다음은 운영 (operations), 즉 화려하지 않은 부분입니다. 트레이싱 (Tracing), 로그 집계 (log aggregation), 자동 롤백 (automated rollbacks), 그리고 제대로 작동하는 순번제 (rotation). 이것들이 빠져 있습니까? 그렇다면 마이크로서비스 (Microservices)는 당신을 괴롭힐 것입니다. 마지막으로 확장성 (scale)입니다.

잘못된 배포 토폴로지 (deploy topology)를 선택했다고 해서 죽는 제품은 거의 없습니다. 제품이 죽는 이유는 출시하지 못했기 때문입니다. 마이크로서비스 (Microservices)는 조직을 확장하는 하나의 방법이며, 실제로 그 문제에 직면하는 날이 온다면 그때 도입하십시오. 그때 전까지는? 견고한 내부 벽을 갖춘 깔끔한 모놀리스 (monolith)가 실제 사용자들에게 선보일 수 있는 가장 저렴하고 빠른 것입니다. 그것을 구축하십시오. 그런 다음 트래픽이 무엇이, 혹은 만약 있다면 무엇이 분리할 가치가 있는지를 말해주게 하십시오.