마이크로서비스 vs 모듈러 모놀리스: 20인 미만 팀을 위한 의사결정 프레임워크

열두 명의 엔지니어로 구성된 팀이 3주에 한 번씩 새로운 기능을 출시합니다. 이들의 빌드 파이프라인은 17개의 서비스를 실행하고, 배포하려면 4개의 리포지토리를 조율해야 하며, 지난 화요일에는 고장 난 user-preferences 엔드포인트 하나가 결제 흐름을 90분 동안 중단시켰습니다. 이 팀의 아키텍처는 서류상으로는 아무런 문제가 없습니다. 단지 그들에게 맞지 않을 뿐입니다. 마이크로서비스와 모듈러 모놀리스 중 무엇을 선택할지는 순수하게 기술적인 질문인 경우가 드뭅니다. 이는 아키텍처의 운영 비용이 그것을 운영해야 하는 팀의 규모와 속도에 부합하는가에 대한 질문입니다.

숨겨진 비용은 코드가 아니라 운영입니다

20명 미만의 팀에게는 어떤 기능을 HTTP로 노출하기 위해 작성하는 코드는 그 주변에 구축해야 하는 모든 것에 비하면 사소합니다. 각 서비스에는 자체 배포 파이프라인, 자체 모니터링, 자체 알림 규칙, 자체 온콜 플레이북, 자체 데이터베이스 마이그레이션 전략, 그리고 이를 호출하는 서비스들과의 자체 계약 테스트가 필요합니다. 이러한 배관 작업의 비용은 서비스가 한 가지 일을 하든 백 가지 일을 하든 대체로 동일합니다. 소규모 팀이 열두 개의 서비스를 운영할 때는 제품을 만들어야 할 바로 그 엔지니어들을 사용하여 이 고정 비용을 열두 배로 지불하게 됩니다.

모듈러 모놀리스는 이 비율을 뒤집습니다. 하나의 배포 파이프라인. 하나의 로그 스트림. 공유된 마이그레이션 타임라인을 가진 하나의 데이터베이스. 모듈들은 새벽 3시에 프로덕션에서 실패하는 JSON 계약 대신 컴파일 타임에 실패하는 타입 지정 함수 호출을 통해 통신합니다. 모듈 경계를 깨끗하게 유지하는 규율은 여전히 실제 작업이지만, 운영 오버헤드는 거의 0에 가깝습니다. 그 결과 10명 규모의 팀이 잘 구조화된 모놀리스를 거의 전담 플랫폼 투자 없이 운영할 수 있는 반면, 같은 팀이 마이크로서비스를 운영하면 일반적으로 한두 명의 엔지니어가 인프라 작업에 영구적으로 흡수되는 결과를 낳습니다.

정면 대결: 두 방식이 크게 갈리는 다섯 가지 결정

배포 주기

마이크로서비스는 이론적으로 독립적인 배포를 허용합니다. 실제로 소규모 팀은 진정으로 독립적인 서비스를 갖는 경우가 드뭅니다. pricing 서비스의 변경은 보통 order 서비스 및 invoicing 서비스와의 조율된 릴리스가 필요합니다. 여러분은 모놀리스의 조율 비용을 그대로 이어받으면서 원자적 배포의 안전성은 잃게 됩니다. 모듈러 모놀리스는 한 번에 배포됩니다. 전체가 함께 작동하거나 함께 롤백됩니다. 시간 단위가 아니라 주 단위로 출시하는 팀에게 이 방식은 속도와 예측 가능성 양쪽에서 우세합니다.

디버깅

마이크로서비스 시스템에서 요청이 실패하면, 네트워크, 역직렬화, 재시도, 타임아웃의 서너 홉을 따라가야 합니다. 분산 추적이 도움은 되지만 스택 트레이스를 대체하지는 못합니다. 모듈러 모놀리스에서는 하나의 스택 트레이스가 전체 호출 경로를 한 화면에 보여줍니다. 소규모 팀에게 디버깅에 소요되는 엔지니어 시간은 회사에서 가장 희소한 자원입니다. 이를 줄이는 모든 것은 곧바로 기능 개발 속도로, 그리고 곧바로 매출로 전환됩니다.

확장성

마이크로서비스에 대한 고전적인 논거는 핫한 컴포넌트를 독립적으로 확장할 수 있다는 것입니다. 이는 진정으로 사실이지만, 20명 규모의 팀이 운영하는 규모에서는 관련성이 거의 없습니다. 대부분의 시스템은 단일 서비스의 CPU에서 병목이 발생하기 훨씬 전에 데이터베이스에서 병목이 발생합니다. 읽기 복제본, 캐싱 레이어, 백그라운드 작업 큐를 갖춘 잘 설계된 모놀리스는 사람들이 예상하는 것보다 더 많은 트래픽을 처리합니다. 만약 그 한계를 넘어서게 되더라도, 모듈러 경계 덕분에 하나의 핫한 모듈을 자체 서비스로 추출하는 것이 처음부터 다시 작성하는 것이 아니라 간단한 리팩터링이 됩니다.

채용 및 온보딩

마이크로서비스 팀에 새로 합류한 엔지니어는 처음 2주 동안 배포 도구, 서비스 카탈로그, 공유 라이브러리, 그리고 상태가 존재하는 열두 곳을 배우는 데 시간을 씁니다. 모듈러 모놀리스에서는 리포지토리 하나를 클론하고, 명령 하나를 실행하며, 이틀 차에는 IDE에서 어떤 동작이든 처음부터 끝까지 추적할 수 있습니다. 시니어 엔지니어가 비싸고 생산성 도달 시간이 주 단위로 측정되는 채용 시장에서, 모놀리스는 온보딩 비용을 상당히 줄여줍니다. 이는 여러분이 지출하지 않은 돈이자, 더 일찍 확보한 역량입니다.

장애 격리

이것은 마이크로서비스가 진정으로 우세한 유일한 영역입니다. 한 서비스의 버그가 다른 서비스들을 직접적으로 크래시시키지 않습니다. 그러나 소규모 팀에게 "크래시하지 않음"은 종종 "조용히 오래되었거나 잘못된 데이터를 반환함"을 의미하며, 이는 감지하는 데 더 오래 걸리기 때문에 명시적인 장애보다 오히려 더 나쁠 수 있습니다. 서킷 브레이커, 타임아웃, 백오프를 동반한 재시도, 우아한 성능 저하는 제대로 구현하기가 결코 간단하지 않으며, 소규모 팀은 거의 항상 여기에 과소투자합니다. 모놀리스는 시끄럽고 완전하게 실패하므로, 알림을 걸기 쉽고 복구하기도 쉽습니다.

마이크로서비스가 실제로 효과를 발휘하는 경우

마이크로서비스가 정직하게 운영 비용을 감당해 낼 만한 세 가지 패턴이 있습니다. 첫째, 시스템의 서로 다른 부분이 진정으로 다른 런타임 특성을 가질 때입니다: 열 명의 내부 사용자에게 서비스하는 CRUD 관리자 패널 옆에 실시간 비디오 처리 파이프라인이 있는 경우입니다. 둘째, 독립적인 팀들이 조율 오버헤드 없이 독립적인 주기로 출시해야 할 때이며, 이는 일반적으로 30~40명의 엔지니어 임계점을 넘어서고 조직적 경계가 굳어진 상태를 의미합니다. 셋째, 시간당 수백만 건의 요청을 받는 이벤트 수집 엔드포인트처럼 단일 컴포넌트가 함께 배치되면 다른 모든 것의 리소스 형태를 왜곡할 만한 엄격한 확장 요구사항을 가질 때입니다.

이 세 가지 조건 중 어느 것도 여러분의 비즈니스에 적용되지 않는다면, 마이크로서비스는 절약해 주는 것보다 거의 확실히 더 많은 비용을 발생시키고 있습니다. 그리고 이 조건들이 오늘날 진정으로 적용되는지, 아니면 결코 도래하지 않을지도 모르는 어떤 가상의 미래에나 적용될지에 대해 스스로에게 정직해질 필요가 있습니다.

다리로서의 모듈러 모놀리스

20명 미만의 팀에게 가장 방어 가능한 아키텍처는 모듈 간의 깨끗하고 강제된 경계를 가진 모듈러 모놀리스입니다. 각 모듈은 자체 데이터를 소유합니다. 다른 모듈에 좁고 타입 지정된 인터페이스를 노출합니다. 직접적인 크로스 모듈 데이터베이스 읽기가 없으며, 순환 의존성이 없고, 경계를 넘나드는 공유된 가변 상태 유출이 없습니다. 이를 디렉터리 구조, 패키지 규칙, 린팅, 코드 리뷰로 강제하십시오. 모든 위반을 실제 버그로 취급하십시오.

잘 수행하면 오늘 필요한 운영 단순성과 2년 후에 필요할 수 있는 아키텍처적 선택권을 동시에 얻게 됩니다. 어느 날 한 모듈이 진정으로 독립적으로 확장되어야 하거나 자체 주기로 출시되어야 할 때가 오면, 이를 추출하는 것은 여러 분기에 걸친 고고학 프로젝트가 아니라 기계적인 리팩터링이 됩니다. 마이크로서비스의 이점을 실제로 필요할 때만 얻고, 그때만 그 대가를 지불합니다.

올바른 아키텍처는 여러분의 팀이 현재 규모에서 잘 운영할 수 있으면서, 도달할 수 있는 규모에 대한 명확한 진화 경로를 가진 아키텍처입니다. 대부분의 SME 규모 팀에게 그것은 분산 시스템이 아니라 모듈러 모놀리스입니다. 재설계를 저울질하고 있거나, 팀의 속도를 늦추고 있는 마이크로서비스 스프롤을 물려받았다면, 경험 많은 파트너가 실제 비용 표면을 매핑하고 로드맵을 중단시키지 않는 마이그레이션을 설계하는 데 도움을 줄 수 있습니다. MerkTechs 팀은 이커머스, 핀테크, 사내 도구 작업 전반에 걸쳐 고객들과 함께 이 길을 걸어왔으며, 여러분의 구체적인 상황에 대한 트레이드오프를 함께 논의해 드리게 되어 기쁩니다.