• logo

      SeolMyeongTang

    • 대규모 서비스엔 MSA?

    2021년 12월 06일

    MSA라는 단어를 심심찮게 들어보셨을 겁니다. 특히, 트래픽이 많은 서비스 회사에서 MSA는 선택이 아닌 생존의 문제로 치부하면서 많은 관심과 도입을 하고 있습니다. 작은 규모의 서비스는 MSA가 당장 매력적으로 보이지 않겠지만, 점점 규모가 커지는 서비스 회사라면 도저히 MSA를 지나칠 수 없을 겁니다.

    MSA는 Micro Service Architecture으로 서비스의 기능들을 독립적으로 나누어 운영하는 방식입니다. 이 말만 들어선 어떤 물건인지 감이 잘 오지 않습니다. MSA랑 더 친해지기 위해 MSA에 대한 정의를 더 살펴봅시다.

    미국의 소프트웨어 개발자인 Martin Folwer는 위와 같이 말합니다. 이 중 핵심 단어 3개를 선택한다면 small, lightweight, API을 꼽을 수 있습니다. MSA는 작고, 가볍고, API를 통해 통신한다는 것을 알 수 있습니다. 또다른 정의를 살펴봅시다.

    microservices.io 사이트에서는 MSA의 특징을 위 5가지로 정의하였습니다. 유지보수성과 테스트 용이하고, 결합도가 낮으며, 독립적인 배포가 가능하고, 비즈니스 중심의 기능으로 돌아가며, 작은 팀으로 구성된다는 특징을 꼽았습니다. MSA가 어떤 물건인지 감이 오셨나요?

    MSA를 본격적으로 이야기하기 전에, MSA 이전 방식을 소개하면서 어떤 문제점이 있었는지 살펴보도록 하겠습니다. MSA 이전에는 MA(Monolithic Architecture)방식으로, 서비스가 하나의 큰 아키텍처로 이루어져 있는 형태였습니다. 쉽게 말해 한 서버에 모든 코드, DB가 때려 박혀져 있는 것으로 생각하면 됩니다. 이러한 방식은 아키텍처에 대해 공부 할 필요 없이 단순하고, 초기에 부담 없이 운영할 수 있지만 서비스가 커지면 커질수록 문제점들이 나타납니다. 하나의 예시를 들어보겠습니다.

    1. 여러분들은 큰 꿈을 안고 중계 플랫폼 IT 스타트업을 차렸습니다.
    2. 개발자들은 열심히 서비스 개발을 하고 어느 정도의 트래픽을 받기 시작했습니다.
    3. 처음엔 개발자 3~4명으로 감당이 가능했지만 서비스 사용자가 점점 늘어나다보니 인력이 부족하여 개발자를 뽑았습니다.
    4. 많아진 개발자들을 효율적으로 관리하기 위해 결제, 주문, 사용자 관리 팀으로 나누었습니다.
    5. 서비스가 계속 성장함에 따라 개발자 팀들 간의 겹치는 코드가 많아집니다.
    6. 개발자 한 팀에서 새로운 기능을 개발하고 싶어도 겹치는 코드 때문에 3명의 개발 팀장이 정기적으로 모여 회의를 해야합니다.
    7. 결제 팀에서 서버에 테스트를 하고 싶은데 다른 팀들의 일정, 이슈를 파악하기 힘들어 섣불리 나서지 못 합니다.
    8. 결제 팀에서 새로운 코드를 서버에 올렸는데 이런! 버그가 발생해 서버가 죽어버렸습니다.
    9. 서비스 사용자는 결제 뿐만 아니라 주문, 로그인도 하지 못하게 되었습니다. 사용자들은 화가 났습니다. 눈 앞이 깜깜합니다.

    MA의 단점을 살펴보면 기능들 간의 의존성입니다. 그리고 스택 마냥 새로운 코드들을 계속 쌓아올려 나중에는 유지보수하기 힘든 형태로 남아버립니다. 서비스가 성장함에 따라 새로운 기능을 추가하고 안정된 운영이 필요한데 MA 방식으로 관리하기에 한계가 있습니다. 그래서 생각합니다. 각 기능별로 잘라서 관리하자!

    MA와 MSA 구조
    MA와 MSA 구조

    MA에서 MSA로 구성하면 다음과 같은 특징을 갖게 됩니다.

    1. Scability

      서비스별 확장이 유연하다.

    2. Independency

      서비스와 조직을 일치시킬 수 있어 서비스별 별도 기술 적용이 가능하다.

    3. HTTP API

      분리된 서비스들은 HTTP API 통신으로 데이터를 주고 받는다.

    MSA로 구성하게 되면 MA로 구성했던 문제점들을 해결할 수 있습니다. 서비스마다 독립적으로 운영이 되므로 서비스 단위로 팀을 나눌 수 있습니다. HTTP API로 다른 서비스들과 통신을 하므로, 팀 단위로 자체적으로 테스트, 배포, 확장을 보다 자유롭게 추진할 수 있습니다. 혹여나 한 서비스가 죽더라도 다른 서비스는 운영하는 그 자체로는 지장이 없습니다.

    대규모 서비스를 운영한다면 유지보수가 큰 숙제일텐데 MSA로 구성한다면 어느 정도의 압박으로부터 해방할 수 있다고 생각합니다. MSA 환경을 구성하는데 험난한 과정이 예상되지만 안정된 서비스를 위해서라면 MSA가 좋은 선택으로 보여집니다.