대기업들이 시장에 MSA라는 독을 풀었다
MSA와 도커, 쿠버네티스에 대한 생각 정리. 대부분의 기업들에게 MSA는 신기루와 같다.
요즘 여러 채용 공고를 보면 기업 규모도 작은데 너도나도 MSA, 쿠버네티스 등의 키워드를 남발하고 있다. MSA는 여러 대기업들에게는 축복이겠지만, 대기업을 선망하는 스타트업, 중소기업들은 충분한 고민 없이 이를 쉽게 따라해서는 안 될 것이다.
MSA로의 전환에 성공하고 MSA의 위대함에 대해 설파하는 기업들에는 공통점이 있다. 바로 DB가 SPOF가 됐다는 사실이다. 이 기업들은 트래픽과 데이터가 상상할 수 없을 정도로 많아 항상 DB에 장애가 발생했고, DB에서 발생한 장애가 모든 서비스로 전파됐기 때문에 MSA로의 전환을 생존 과제로 여겼으며 이윽고 전환에 성공했다. 그리고 이렇게 MSA로 전환에 성공한 기업들의 성공담에는 DB를 쪼개는 작업이 반드시라고 해도 좋을 정도로 높은 확률로 등장한다.
웹 애플리케이션들은 스케일아웃을 하면 CPU와 I/O의 부하 분산이 모두 쉽게 가능해지기 때문에 대부분의 기업들이 스케일아웃으로 처리를 한다. 웹 애플리케이션에서 DB로의 읽기가 한번 발생하면 읽어들인 데이터들이 OS레벨에서 캐싱되며 다음 읽기는 디스크 I/O가 발생하지 않을 확률이 높아지기 때문에 자연스레 I/O 부하 분산이 된다. CPU 부하 분산 역시 마찬가지다. 서버 인스턴스를 여러대로 늘리면 각각의 인스턴스에 독립적인 CPU들이 존재하게 되기 때문에 자연스럽게 CPU 부하 분산이 이뤄진다.
DB는 SSD나 HDD와 상호작용하며 직접적으로 읽기와 쓰기를 진행하는데, 읽기 역시 데이터가 너무 많지 않다면 대부분의 경우에 문제가 되지 않으나 쓰기의 경우는 얘기가 다르다. A와 B라는 DB가 두 개 있다고 가정해보자. 이 상황에서 웹 애플리케이션에서 A DB에 데이터를 쓰게되면 그 즉시 두 DB의 데이터는 상이해질 것이다. 이렇게 DB에서는 스케일아웃을 해버리면 쓰기 시 각 DB간의 데이터의 정합성을 맞추기가 어려워지기 때문에 스케일아웃이 매우 비효율적이다.
웹 애플리케이션 개발에서 가장 피해야 할 것은 메모리에 비해 끔찍하게 느린 디스크에서 작업을 하는 것이다. 메모리는 빛의 속도로 동작하는 전기 신호로 모든 것을 순식간에 제어할 수 있으나, HDD는 메모리와 다르게 데이터를 읽거나 쓰기 위해서는 디스크 암이 대상 섹터가 위치한 실린더로 이동한 후 마그네틱 원판이 회전하여 디스크 헤드가 섹터의 위치에 도달해야만 하는 구조이기 때문에, 하드웨어가 움직이기 위한 최소한의 물리적인 시간이 필요해지고 이는 빛의 속도와 절대 비교할 수 없다. 그리고 이렇게 하드웨어가 움직이는 시간들이 고스란히 API의 응답 시간에 +되기도 한다. 혹자는 SSD 쓰면 되는데요? 라고 반문할 수 있으나, 테라바이트 이상의 스토리지를 모조리 다 SSD로 처발라버리기에는 막대한 비용이 드는게 현실이기 때문에 아직도 많은 기업들에서는 HDD도 애용하고 있다. 디스크의 데이터를 메모리에 캐싱한다면 이렇게 끔찍하게 느린 디스크 I/O를 최소화 시킬 수 있기 때문에 DB는 메모리의 용량을 키워 더욱 많은 데이터를 메모리에 캐싱할 수 있게 스케일업을 주로 하게 된다.
DB의 성능이 나오지 않기 시작한다면 테이블을 컴팩트하게 재설계하고, 쿼리를 튜닝하고, DB의 물리 메모리를 늘려주면 된다. 테이블에 1억개의 레코드가 있다면, 8바이트짜리 컬럼 하나만 제거해도 스토리지 용량이 1GB정도 줄어드며, 레플리케이션과 테이블 파티셔닝을 더욱 잘 하고 웹 애플리케이션에서의 읽기 요청을 여러 슬레이브 노드에 분산시키면 각 슬레이브 노드가 정해진 테이블만을 액세스하게 되기 때문에 OS 캐시도 더욱 많이 활용할 수 있게 된다. 만약 어느 슬레이브 노드가 A 테이블을 스캔하여 이 데이터들을 모두 캐싱하고 있었는데, B 테이블 액세스 요청이 들어왔고 메모리가 부족해 페이지 스왑이 발생했다면? 메모리에 캐싱해둔 A 테이블의 데이터를 비우고 B 테이블의 데이터를 다시 캐싱할 것이다. 이렇게 되면 디스크 I/O가 빈번하게 발생해 캐싱이 별 의미가 없어진다. 반대로 해당 슬레이브 노드가 계속해서 A 테이블로만 액세스한다면 첫 액세스 이후로는 이미 필요한 데이터가 메모리에 캐싱되어있을 확률이 높기 때문에 디스크 I/O가 최소화될 것이다.
이러한 모든 작업들을 했음에도 불구하고 계속해서 DB에 장애가 발생한다면? 이미 그 기업은 아주 많은 사람들이 이름을 들어봤을 정도로 유명한 사회적인 기업이 되어있을 것이다. 그 정도로 사용자도 많고 밀려오는 트래픽과 쌓이는 데이터도 많다는 의미이기 때문이다. 이 정도가 되어야 그나마 MSA로의 전환을 고려해볼만한 최소 요건이 된다고 생각한다. 위의 내용이 납득된다면, MSA로의 전환을 성공적으로 진행한 기업들의 성공담들을 참고해보면 DB를 쪼개는 작업이 가장 핵심이 되는것도 이해가 될 것이다. 그리고 MSA로 전환할 때 DB를 쪼개며 덤으로 레디스, 몽고, 엘라스틱서치 등의 각 서비스에 맞는 효율적인 DB도 사용할 수 있게 될 것이다. 시간이 지난 후 쪼개어진 DB가 다시금 비대해진다면 위의 과정들을 반복해 또 다시 여러개의 마이크로 서비스로 쪼개게 될 것이다. (세계적인 기업들인 MAANG의 선례를 생각해보자. 그들의 마이크로 서비스는 전 세계에 그물망처럼 퍼져있다.)
이제 도커와 쿠버네티스에 대해 생각해보자. 도커는 대표적인 컨테이너 기술이다. 도커를 사용하게 된다면 프로세스를 컨테이너로 감싸 한정적인 컴퓨팅 리소스를 사용하게 강제하는데, 사실 이러한 효과가 유용해지려면 서버에 여러개의 중요한 프로세스가 뜨고, 이 프로세스들을 깔끔하게 격리해야만 한다는 요구사항이 있어야 한다. 이러한 요구사항이 있다면 도커는 훌륭한 솔루션이 될 수 있다. 하지만 상식적으로 서버 하나에 프로세스를 최대한 적게 혹은 하나만 올려 해당 프로세스들이 서버의 모든 컴퓨팅 리소스를 독점해서 사용하게 하는 것이 가장 효율적인 서버 운영일 것이다. 충분히 하나의 프로세스로 돌릴 수 있는 것을 굳이 여러개의 프로세스로 쪼개고 이를 하나하나 컨테이너로 래핑해 서버에 여러개의 프로세스로 띄울 필요가 없다는 것이다. 심지어 단일 프로세스였다면 메모리 내 함수 호출로 끝났을 것들이 IPC를 통해 진행되어야 하기 때문에 성능면에서도 오히려 더 손해가 커진다. 이러한 이유로 데이터도 많지 않고, 서비스도 충분히 작은 대부분의 기업들의 경우에는 그냥 프로젝트를 모노레포로 작업하고 서버에 단일 프로세스로 올려버리는게 가장 효율적이기 때문에 굳이 컨테이너 기술을 사용할 필요가 없다. (로컬에서 개발환경을 빠르게 구축하는데 도커가 아주 유용하다는 것에는 이견의 여지가 없다.)
쿠버네티스는 왜 사용할까? 서비스를 두개로 쪼개 서버에 A와 B라는 두 개의 프로세스를 컨테이너로 감싸 올리고, 각각의 프로세스가 컴퓨팅 리소스를 절반정도씩 점유해서 사용하게 했다고 가정하자. 만약 A 프로세스에 트래픽이 몰려 자신에게 주어진 컴퓨팅 리소스가 부족해진다면 서버 관리자가 B 프로세스에서 일부 리소스를 뺏어와 A 프로세스에 재할당 해주어야 할 것이다. 이러한 작업들을 수동으로 하기가 매우 번거롭고 귀찮기 때문에 쿠버네티스라는 기술이 나타난 셈이다. (이를 컨테이너 오케스트레이션이라 한다.) 역설적으로 이 역시 결국 컨테이너를 사용하지 않는다면 필요 없는 기술이기도 하다. 즉, MSA로의 전환을 할 필요가 없는 대부분의 기업들에서 도커와 쿠버네티스 역시 큰 의미가 없는 기술일 확률이 아주 높다. 나중에 정말 필요해지면 그때가서 학습하고 도입해도 늦지 않다고 생각한다.
나는 왜 이렇게 MSA에 부정적인가? 우리 회사는 내가 입사하기 전에, 예전에 잘못된 기술적인 판단과 결정으로 인해 아주 이른 시기에 MSA로의 전환을 꾀했지만 별다른 실효도 거두지 못하면서 오히려 트래픽이 많지 않음에도 불구하고 한 달에 약 4천만원의 서버비만 부담하고 있다. 서버는 수십개씩 떠있는데, 막상 각 서버들의 자원을 100% 다 활용하지는 못하고 있으며, 오히려 쓸데없이 많이 떠있는 서버로 인해 서버비만 무지막지하게 발생하고 관리 포인트만 많아지고 있다. 우리 회사는 아직 작기 때문에 개발자분들이 많이 안 계시는데, 이렇게 어설프게 진행된 MSA로 인해 관리 포인트가 너무 많아져 동료 개발자분들도 많이들 힘들어하고 계시다. MSA는 돈 잡아먹는 괴물이다. 이 돈이라는 표현에는 인력과 시간이 모두 포함된다. 나는 현재 A팀(영화 A팀에서 유래한 팀명이다)에 속해 이렇게 쪼개진 서비스들을 주섬주섬 주워모아 다시 재통합시키고 있으며, 관리되지 않는 클라우드 인스턴스들을 정리하는데 온 힘을 쏟고있다. 9월에는 서버비를 3천만원대로 줄였으며, 이번달에는 2천만원대에 진입했고, 다음달에는 천만원대에 진입할 예정이다. 그리고 이러한 작업들은 나처럼 신규 입사하여 회사의 히스토리를 잘 모르는 사람에게는 매우 까다롭고 힘겨운 작업이다.
우리 회사에서 MSA로 긍정적인 효과를 본 것은 단 하나도 없으며 상처만이 남았다. 내가 입사하기 전 MSA를 무지성으로 강력하게 밀어붙이다 퇴사한 전 CTO의 이력에 MSA 경험 단 한 줄만이 추가됐을 뿐이다. 나는 이전 CTO의 얼굴과 이름도 모르지만, 우리 회사의 상황에 MSA를 도입하려 한 그의 판단에는 경력이 일천한 내가 봐도 합당한 근거가 전무하다. 그래서 나는 이를 이력서 주도 개발이라고 부른다.
MSA는 단지 ‘핫’하기 때문에 등의 시답잖은 이유로 도입하기에는 너무 위험하다. 작게는 본인이 속한 개발팀에, 넓게는 본인이 속한 회사에 큰 상처를 남길 위험이 분명히 존재한다. 내 생각에는 MSA는 아주 유명하고 큰 사회적인 기업들이 자신들의 서비스가 너무 비대해졌을 때 자신들의 생존을 위해 시도하는 것이다. 그들은 그만큼 돈을 많이 벌고 있으며, MSA로 전환해 판관비가 늘어나는것과 장애가 줄어드는것을 저울질했을때 돈을 더 쓰는게 오히려 이득이라고 판단했기 때문에 MSA로 전환한 것이다. 갑각류인 바닷가재는 탈피 과정을 통해서 성장하게 된다고 하는데, 성장을 거듭하면서 껍질도 단단해지고 무거워져서 탈피가 힘들어질 수 있다고 한다. 그리고 이 탈피 과정에서 바닷가재가 죽는경우도 많다고 한다. MSA는 이와 비슷하다.
정 MSA가 하고 싶거든 차라리 나중에 MSA로의 전환이 수월할 수 있도록 프로젝트를 모노레포 + 멀티모듈로 설계하고, 추후에 모듈 하나를 마이크로 서비스 하나로 쉽게 뜯어낼 수 있게 아키텍처를 구성하는것이 더 현명할 것이며, 멀티모듈이든 DDD든 이 역시 자신들의 서비스가 충분히 복잡해진다면 그때가서 도입하고 시도해도 절대로 늦지 않을 것이다. 회사에 속해 일하는 우리 개발자들은 코드와 기술만 봐서는 안되며, 우리의 일에 반드시 경제논리를 도입해야 할 것이다. 엔지니어링이란 한정된 자원으로 유형의 가치를 만들어내는 것이다. 우리에게 주어진 상황에서 퀄리티와 비용, 무엇이 당장 더 중요한지 항상 고려해야만 할 것이다.
