대기업들이 시장에 MSA 라는 독을 풀었다
개발자 구인 공고들을 보면, 기업 규모가 크지 않은데도 MSA, Docker, K8s 등의 키워드가 보이는 경우가 많습니다. MSA는 실제로 규모가 특출나게 큰 일부 대기업에게는 매우 유용한 아키텍처일 수 있습니다. 하지만, 대부분의 소규모 기업들이 그저 대기업을 따라 하기 위해 MSA를 도입하는 것은 절대적으로 지양해야 합니다. MSA는 소규모 기업에서 도입했을 때, 장점은 거의 없고 단점만 가득한 최악의 아키텍처가 됩니다.
저는 현재 시리즈 B 수준의 작은 스타트업에 근무하고 있으며, MSA를 모놀리식 아키텍처로 전환하는 작업을 2년에 걸쳐 진행했고, 최근에서야 겨우 마무리할 수 있었습니다. 제가 입사 후 가장 큰 문제로 인지하고 제기했던 것은 서버 비용으로, 당시 무분별하게 구축된 마이크로 서비스로 인해 매월 약 4,000만 원의 비용이 발생하고 있었습니다. 이제는 모든 마이크로 서비스가 통합되어 현재는 매월 약 1,000만 원의 비용이 발생하고 있는 상황입니다. 자금 흐름이 중요한 소규모 기업에게 이 정도의 고정 비용은 큰 부담이 됩니다. 그리고 아직도 비용을 절감할 여지는 많이 남아있습니다.
소규모 기업에서 MSA를 도입했을 때 발생하는 문제는 소규모 기업에서 감당하기 어려운 막대한 비용이 발생한다는 것입니다. 여기서 비용이라는 것은 모든 물적, 인적 자원에 대한 비용을 의미합니다.
우선 아주 간단한 테스트라도 하려면 관련된 마이크로 서비스가 모두 필요합니다. 결국 로컬 머신에 마이크로 서비스를 모두 실행하는 번거로움이 발생하는데, 이 문제를 회피하려면 정교한 인프라가 구축되어 있어야만 합니다. 항상 시간과 인력이 부족한 소규모 기업에서 별도의 인프라를 구축하는 데 자원을 투자하기는 어렵기 때문에, 결국 로컬 머신에서 다수의 마이크로 서비스를 띄우는 방향으로 가게 될 확률이 높습니다.
프로젝트가 여러 개의 마이크로 서비스로 분리되면 각 마이크로 서비스 간의 의존성이 정교하게 관리되어야 하고, 각 마이크로 서비스의 API 문서도 잘 관리되어야 합니다. 배포 절차가 복잡해지며, 이 역시 인프라를 구축해 어느 정도 해결할 수 있으나, 소규모 기업에서 이런 인프라에 투자하기는 쉽지 않습니다. 트러블슈팅을 하려면 여러 마이크로 서비스를 넘나들며 디버깅해야 합니다. 이는 개발 생산성의 저하로 이어집니다.
트래픽이 적기 때문에 각 마이크로 서비스가 서버 자원을 100% 활용하기 어렵습니다. 결국 서버 자원의 낭비로 이어지고, 이 문제를 해결하기 위해서는 또 별도의 인프라가 필요해집니다. 우리 회사의 문제였는데, 웹 애플리케이션 서버는 분리되어있는데 반해 모든 마이크로 서비스가 동일한 DB 서버를 바라보고 있었습니다. DB 테이블의 스키마 변경을 불가능에 가깝게 만드는 가장 큰 원인이 되었습니다.
결국 큰 문제는 두 가지로, 금전적인 비용과 인적 자원에 대한 비용으로 정리할 수 있습니다. 회사가 작기 때문에 돈이 없고 개발자가 적습니다. MSA는 이 두 가지 자원을 굉장히 많이 요구합니다. 우리 회사는 이전 라운드에 근무하던 CTO가 합당한 근거 없이 MSA를 도입했고, 이 결정으로 회사는 회복하기 어려운 손해를 입었습니다. 현재 개발팀에는 이번 라운드에 입사하신 CTO님과 개발자들만 근무하고 있는데, 우리는 모두 MSA로 인한 문제가 크다는 데 동의했고, MSA를 모놀리식 아키텍처로 되돌리는 데 약 2년에 가까운 시간과 개발력을 쏟아부었습니다.
MSA가 왜 탄생했고 왜 유행했을까요? 이에 대해 한번이라도 생각해봤다면 소규모 기업에서 MSA를 도입하려는 시도가 얼마나 어이없는 것인지 알기 어렵지 않을 겁니다.
MSA로의 전환에 성공하고 MSA를 찬양하는 모든 기업에는 공통점이 있습니다. DB 서버가 SPOF(Single Point of Failure)가 되었다는 점입니다. 이러한 기업들은 유입되는 트래픽과 축적되는 데이터가 상상할 수 없을 정도로 많기 때문에 DB 서버에 장애가 자주 발생하고, 이 장애가 모든 서비스의 셧다운으로 이어집니다. 이 최악의 사태를 회피하기 위해 DB 서버를 분리하고 최적화하는데 막대한 투자를 하게 되고, 이 시도가 결국 MSA를 낳게 되었죠. 그래서 MSA로의 전환에 성공한 기업들의 성공 이야기에는 DB 서버를 분리하는 작업이 항상 핵심적으로 언급됩니다.
하지만 소규모 기업은 애초에 DB 서버가 SPOF가 될 정도로 트래픽과 데이터가 많지 않습니다. 즉, MSA를 도입할 근거가 없다는 것입니다. 소규모 기업에서는 DB 서버로 인한 장애가 발생하는 것이 어렵고, DB 서버를 잘 관리하기까지 한다면 장애는 더욱 드물 것입니다.
웹 애플리케이션 서버는 DB 서버가 ACID를 보장해주기 때문에 대량의 외부 요청이 입력되어도 스케일아웃을 통해 CPU와 I/O 부하를 쉽게 분산시킬 수 있지만, DB 서버는 컴퓨터 부품 중 가장 느린 HDD와 직접 상호작용하며 읽기와 쓰기 작업을 수행하기 때문에 속도가 매우 느립니다. 또한, 데이터의 정합성을 보장해야 하는 막중한 책임을 갖고 있어 스케일아웃으로 부하를 분산시키기 어렵습니다. 예를 들어, DB 서버를 스케일아웃해 A와 B라는 두 개의 DB 서버가 존재하게 되면, A에 데이터를 쓰는 즉시 A와 B 두 DB 서버의 데이터가 상이해집니다. 이를 해결하기 위해 모든 DB 서버를 실시간으로 동기화해야 하는 기술적인 과제가 발생하며, 이는 해결하기가 상당히 어렵습니다. 이러한 이유와 외의 몇가지 이유로 DB 서버는 주로 스케일업을 통해 문제를 해결합니다. 메모리는 전기 신호를 통해 빛의 속도로 데이터를 처리할 수 있지만, HDD는 디스크 암을 움직여야 하므로 느리게 동작합니다. 이러한 디스크 I/O 시간은 웹 애플리케이션의 API 지연 시간에 포함되며, SSD를 사용하면 개선될 수 있지만, 비용 문제로 여전히 많은 기업이 HDD를 사용하고 있습니다.
소프트웨어적으로는 테이블을 정규화 이론에 따라 설계하고, 인덱스를 사용해 쿼리를 튜닝하는 것도 가능합니다. 예를 들어, 1억 개의 레코드가 있는 테이블에서 8바이트 크기의 컬럼을 제거하는 것만으로 약 1GB의 스토리지 용량을 절약할 수 있습니다.
이 모든 작업을 잘 수행해도 여전히 DB 서버에 장애가 발생한다면, 그 기업은 이미 많은 트래픽과 데이터를 다루는 큰 기업일 가능성이 높습니다. 이런 상황에 이르러서야 비로소 MSA를 고려해보는 것이 타당할 수 있습니다.
이제 Docker와 K8s에 대해 짚어봅시다. Docker는 대표적인 컨테이너 기술로, 프로세스를 격리된 환경에서 동작시켜 한정된 컴퓨팅 리소스를 사용할 수 있도록 돕습니다. 원래 Docker는 이식성 문제를 해결하기 위해 도입되었습니다. 로컬에서는 잘 작동하는데 배포만 하면 문제가 발생하는 문제를 해결하기 위해서죠. 그러나 이 문제는 사실 JVM 기반의 생태계에서는 거의 문제가 되지 않습니다. 그리고 한국의 대부분의 기업들은 Java를 사용하고 있지요.
Docker의 다른 이점은 프로세스들이 한정된 컴퓨팅 리소스를 사용하도록 강제하는 것인데, 이러한 효과를 누리기 위해서는 서버에 여러 프로세스가 떠 있어야 합니다. 이는 MSA와 같은 환경에서 유용할 수 있습니다. MSA가 아니라면 Docker를 사용할 이유가 딱히 없습니다.
회사 서비스가 Python, Javascript 같이 배포가 어려운 언어로 개발되었다면, 개발과 배포를 위해 Docker를 사용하는 것이 합당할 수 있습니다.
K8s는 왜 사용할까요? 예를 들어, 하나의 프로세스를 A와 B라는 프로세스로 분리하여 띄운다고 가정해봅시다. A 프로세스에 트래픽이 집중되어 리소스가 부족해지면, 서버 관리자는 B 프로세스에서 일부 리소스를 A에게 할당해야 합니다. 이 작업을 자동화하기 위해 K8s가 존재합니다. K8s는 컨테이너 오케스트레이션을 쉽게 해주는 환경을 제공하지만, 이는 컨테이너를 사용할 때만 의미가 있습니다. 대부분의 소규모 기업에서는 MSA가 필요 없으므로 Docker와 K8s도 유의미한 효과를 보기 어렵습니다. 회사가 커졌을 때 필요해지면 그때 도입해도 늦지 않습니다.
MSA를 도입하기 전에 DB 서버의 성능 개선을 통해 문제를 해결할 수 있는지, 기업의 규모와 트래픽이 반드시 MSA로 전환해야 하는 수준인지 등을 신중하게 고려해야 합니다. MSA는 막대한 물적, 인적 자원을 요구하므로 특히 소규모 기업에서는 MSA 도입을 신중하게 결정해야 합니다.
