마이리얼트립은 어떻게 MSA로 전환하고 있는가?
안녕하세요. 마이리얼트립의 CTO 정재훈입니다.
이번 포스트에서는 모놀리식(Monolithic)으로 구성된 마이리얼트립 서비스를 어떻게 MSA로 전환하고 있는지, 또 이 과정에서 어떤 문제가 있었고, 어떻게 풀고 있는지에 대해 설명을 드리겠습니다.
혹시 MSA에 대해서 더 자세히 알고 싶다면 문지응님이 2020년에 작성한 “MSA(Micro Service Architecture)로의 전환” 포스트를 읽어보시면 좋을 것 같습니다.
1. 마이리얼트립은 마이크로 서비스 아키텍처를 통해 어떤 문제를 해결하고자 할까요?
빠르게 성장하는 서비스의 기본 골격을 변경하는 것은 많은 비용과 시간, 그리고 노력이 수반되어야 합니다. 이것은 시속 100km로 달리고 있는 차에서 멈추지 않고 바퀴를 바꿔 다는 것만큼 어려운 일입니다. 더욱이 한 조직을 책임지는 경영진의 입장에서는 구조 개선이 당장의 수익으로 돌아오는 것이 아니기 때문에 많은 비용과 시간이 들어가는 구조 개선 프로젝트를 선택하는 것이 쉽지 않습니다.
여행 회사에게는 가장 어려운 시기였던 팬데믹 시기에, 마이리얼트립은 왜 이렇게 많은 시간과 비용이 드는 프로젝트를 선택했을까요?
첫째, 고객에게 최적화된 탐색과 구매 경험을 제공하고자 했습니다.
마이리얼트립은 ‘투어’를 기반으로 서비스를 성장시켰습니다. 투어 상품에 적합한 서비스 구조를 기반으로 티켓, 숙박, 항공, 렌터카 등 다양한 버티컬로 확장하다 보니, 고객에게 각 버티컬에 최적화된 올바른 탐색과 구매 경험을 제공하는 데에 어려움이 있었습니다. 이런 점들을 해결하기 위해 각 버티컬 단위로 서비스(마이크로 서비스 단위)를 쪼개면서 상품 구조 개선 작업을 진행하고 있습니다.
둘째, 서비스의 복잡성과 의존성을 제거하고자 했습니다.
마이리얼트립의 서비스는 크게 여행자 사이트, 파트너 사이트, 매니저 사이트로 구성되어 있습니다. 그러나 이런 서비스들이 독립된 서비스로 분리되지 않고, 소스 레포지토리부터 배포 단위까지 모두 동일한 저장소와 동일한 서버를 사용해 서비스를 제공하고 있습니다. 이렇게 모든 서비스가 한곳에서 제공되다 보니 작은 장애가 전체 서비스의 장애로 확장되는 경우가 종종 있습니다. 이런 서비스의 복잡성과 의존성을 제거하기 위해 단일의 거대한 서비스를 작은 서비스 단위로 분리하고 있습니다.
셋째, 큰 조직 규모에서도 서비스 개선과 새로운 기능 출시의 효율성을 유지하고자 했습니다.
마이리얼트립은 팬데믹 시기에도 지속적으로 조직이 확장되었습니다. 제가 처음 마리트에 입사할 당시 17명이었던 개발자가 지금은 100명 이상으로 조직이 빠르게 성장했습니다. 모놀리식 아키텍처에서는 조직이 일정 규모를 넘어서게 되면 개발자의 수와 제품의 생산성이 더이상 비례하지 않습니다. 수많은 뛰어난 개발자들을 채용해 새로운 기능을 수없이 개발해도 해당 기능을 출시하기 전에는 반드시 코드 프리징과 테스트, 배포의 단계를 순차적으로 거쳐야 합니다. 이는 전체의 서비스 출시의 병목으로 작동해 조직과 서비스의 성장을 저해합니다. 우리는 배포의 효율성을 개선하기 위해 거대한 단일의 서비스를 작은 서비스 단위로 분할하고 있습니다.
그리고 이와 동시에, 루비 온 레일즈에서 자바로의 전환도 함께 진행하고 있습니다. 마이리얼트립의 메인 서비스는 루비 온 레일즈를 기반으로 개발되었습니다. 루비 온 레일즈는 작은 비용으로 빠르게 서비스를 만들 수 있고, 고객으로부터 피드백을 빠르게 받을 수 있는 장점이 있기 때문에 많은 스타트업들이 이 언어를 활용해 서비스를 개발하고 있습니다. 루비 온 레일즈를 선택한 이유는 그 당시 회사가 내릴 수 있는 최선이었기 때문입니다.
그러나 서비스가 성장해 더 많은 개발자들이 필요한 시점에서는 루비 온 레일즈로 인해 채용에 많은 어려움이 있었습니다. 한국의 개발자 시장에는 루비 온 레일즈 개발자보다는 자바 개발자의 수요와 풀이 절대적으로 많은 편이라, 자바 개발자의 채용이 상대적으로 쉬운 편입니다. 자바로의 전환을 통해 빠르게 더 많은 핵심인재를 채용하고, 서비스를 폭발적으로 성장시키고자 했습니다.
마이리얼트립은 궁극적으로 더 빠른 서비스의 성장을 위해 가장 큰 구조적인 병목지점 가지를 제거하고자 위와 같은 투자를 지속하고 있습니다. 코로나로 인해 여행이 잠시 멈춘 이 시점이 이런 기술적인 도전을 하기 위한 최적인 시기라고 판단하고 있습니다.
2. 모든 회사들이 모놀리식에서 마이크로 서비스로 전환하는 것이 항상 정답일까요? 마이크로 서비스 아키텍처로 전환하는 시점은 언제가 좋을까요?
‘모놀리식 아키텍처와 마이크로 서비스 아키텍처 중에서 어떤것이 더 좋다’라고 비교하는 것은 의미가 없습니다. 저는 서비스의 상황이나 성장 단계에 따라서 최선의 아키텍처가 다르다고 생각합니다. 협업하는 개발자의 인원이 수십명 수준이거나 간단한 형태의 서비스에는 모놀리식 아키텍처가 더 적합할 수 있습니다.
그러나 서비스의 규모가 커지고, 협업하는 개발자가 많아진다면, 이로 인해 발생하는 복잡성을 줄이기 위해 마이크로 서비스 아키텍처로의 전환을 고려하는 것이 좋습니다. 반대로 성장이 제한적이거나, 작은 서비스에서 마이크로 서비스 아키텍처로의 전환은 over-architecturing 이라고 생각합니다.
3. 하나의 서비스를 어느 정도의 서비스 단위로 분리하는 것이 좋을까요?
사실 여기에 논리적인 정답은 없습니다. 우리가 풀고자 하는 문제, 즉 “서비스의 복잡성을 제거하고 효율적으로 일하기 위한 최적의 서비스 단위”에 대해서 고민하는 것이 중요합니다. 기존의 모놀리식 서비스를 개발하면서 느낀 문제에 집중했다면 어렵지 않게 정답을 찾아갈 수 있을 것입니다.
개인적인 경험으로는 무조건 작은 서비스 단위로 분리하는 것이 정답은 아닙니다. 너무 작은 단위의 서비스로 분리하면 서비스의 복잡성이 nCr과 같은 형태로 증가합니다. 결국 단일 서비스에 너무 많은 도메인이 있어 발생한 복잡성이 작은 마이크로 서비스 단위로 분리된 상태에서도 동일하게 발생하는 문제가 일어나는 것입니다. 이런 부분들을 유의하면서 서비스의 최소 단위를 결정해야 합니다.
<무분별한 서비스의 분할이 가져오는 서비스간의 복잡성 그래프>
4. 모놀리식 구조에서 강하게 결합된 트랜잭션을 분리하는 가장 효과적인 방법은 무엇일까요?
기존의 모놀리식 서비스 환경에서는 DBMS가 기본적으로 제공해주는 트랜잭션을 통해 서비스의 일관성을 쉽게 관리할 수 있었습니다. 이 결과 오래된 서비스일수록, 그리고 복잡한 서비스일수록 단일 트랜잭션에 많은 비즈니스 로직들이 강하게 연결되어 있습니다. 이런 서비스를 여러 개의 작은 서비스로 분리하면 DBMS에서 제공하는 트랜잭션을 더 이상 사용할 수 없기 때문에 많은 어려움이 생깁니다. 일반적으로는 Two-Phase Commit 또는 이벤트 기반의 Saga 패턴을 활용해 이러한 문제를 해결할 수 있습니다. 이런 기술적인 부분들은 이미 여러 글에서도 다루고 있어 이 포스트에서는 자세히 다루지 않겠습니다.
지금까지 마이리얼트립이 어떤 문제를 풀고자 하는지, 그리고 문제를 풀기 위해 마이크로 서비스 아키텍처를 도입할 때 어떤 기준으로 이런 결정을 내렸는지, 이 과정에서 우리가 고려할 점들이 무엇인지에 대해서 이야기를 나누었습니다.
다음 포스트에서는 어떻게 하면 효과적으로 마이크로 서비스 아키텍처로 전환할 수 있는지, 그리고 마이리얼트립은 어떤 과정을 통해서 전환하고 있는지에 대해 다뤄보도록 하겠습니다.
마이리얼트립에서는 이런 기술적인 도전을 함께 즐길 역량 있는 개발자 분들을 모시고 있습니다.
많은 지원 부탁드립니다 :)
