1편. MSA(Micro Service Architecture)에 대해서

 

MSA를 공부하게 된 계기

예전에 모 스타트업의 기술면접에서 "유명 가수 공연 티켓팅으로 밀려올 특정 기간에 몰려올 트래픽에 대비하려면 어떻게 해야 하는가?"  
라는 질문을 받았었다.
당시 나의 답변은, Auto-Scaling과 Waiting Queue를 사용하는 방법이었다.
CPU 사용량은 특정 수치를 넘어가면 인스턴스를 복제하고, 메시징 큐를 사용하여 트래픽 제어에 따라 실제 대기 중인 사용자들의 식별 가능한 아이디를 담은 메시지를 관리하고 비용 효율성 있는 방법으로 해결할 수 있다고 생각했다.

 

하지만, 고려하지 않았던 부분이 있었는데 실제 사용자는 수만 명, 수십만 명이 동시에 같은 0.1초 이내로 몰릴 수도 있다는 것이다.
이런 상황에 Auto-Scaling 방식을 사용하면 인스턴스가 복제되고 애플리케이션이 실행되는 시간을 기다리다 보면 이미 장애가 발생해 있을 것이다. 🛑

 

해결 방법은 
             부하 테스트를 통해 하나의 인스턴스가 견딜 수 있는 스트레스를 측정하고 미리 예측되는 사용자의 수보다
             더 큰 Traffic을 견딜 수 있도록 인스턴스를 미리 여러 개 복제하여 실행해 두는 것이다. 
            (물론, 더 많은 복잡한 일이 남아 있을 것임)

 

또한, 여기서 MSA를 공부하게 된 계기가 있다.
트래픽이 몰리는 것은 상품과 티켓 구매 이벤트를 담당하는 서비스이다. 하지만, Monolithic 한 애플리케이션을 그대로 복제한다면 필요도 없는 다른 이벤트를 위한 자원도 늘리게 되고 구매 이벤트에 집중할 수 없다.

 

이때, 서비스를 Micro Service로 잘게 나누어 독립적으로 만들게 된다면, 구매 이벤트만 자원을 효과적으로 늘릴 수 있다.
이것이, Amazon의 0.66초 배포의 비밀이다.

 

 

Monolith와 Micro Service의 차이

Monolithic Architecture

모노리식 아키텍처는 우리가 자주 구성하던 단일 코드 베이스 애플리케이션 구조이다. 전체가 하나의 Language로 작성되어 단일 데이터베이스에 연결된다.

1) Monolithic Architecture 장점

1. 단순하다: 애플리케이션이 하나로 뭉쳐있기 때문에 변경 사항이 필요할 때 한 곳에서 처리가 가능하며, 단일 애플리케이션으로 실행하면 되기 때문에 인프라 관리도 편하다.
2. 테스트가 쉽다: 다른 애플리케이션에 대한 의존성이 없기 때문에, 테스트가 쉽다.
3. 아키텍처를 구성하기 쉽다: 애플리케이션을 분리하려면 서비스 간의 통신, 배포, 인프라 설계 등 많은 부분에 있어서 복잡해지지만, 모놀리식 한 구조는 단순하게 아키텍처를 구성할 수 있다.

2) Monolithic Architecture 단점

장점이 있으면 단점이 있는 게 이치다..

1. 유연하지 않다: 특정 이벤트에 대해서만 확장할 수 없고, 애플리케이션 전체를 확장해야 한다.
2. 팀을 분리하기 쉽지 않다: 모든 팀이 하나의 애플리케이션을 대상으로 작업을 진행하면, 아무리 규칙을 잘 정하더라도 수도 없이 충돌이 발생하고 커뮤니케이션에 많은 비용이 들 것이다.
3. 기술 사용이 제한된다: 애플리케이션에서 사용하고 있는 Language를 일부만 바꿀 수가 없기 때문에 오랜 기간 동일한 기술을 사용해야 한다. 

 

Micro Service Architecture

마이크로서비스 아키텍처는 애플리케이션을 작은 서비스로 나누고, 서로 상황에 따라 100% 독립적이지는 않지만 느슨하게 결합되도록 구성하는 방식이다. 각 서비스마다 개별 Database를 사용하고, 이에 따라 데이터 정합성 등 많은 문제가 발생함으로 많은 경험이 필요하다.

1) Micro Service Architecture 장점

Monolithic의 단점이 MSA의 장점이 된다.

1. 유연하다: 애플리케이션이 독립적으로 분리되어 있으므로 특정 이벤트를 담당하는 서비스만 확장하거나 축소할 수 있다.
2. 팀을 분리하기 쉽다: 애플리케이션이 분리되어 있기 때문에 각 팀마다 하나의 서비스를 담당하는 식으로, 팀마다의 느슨한 결합이 형성될 수 있다.
3. 기술 사용이 유연하다: 각 팀에서 Language나 기술 스택을 정의하고 개발할 수 있다. 토스, 당근 등 여러 기업에서 팀마다 Python, Java, Kotlin, Ruby, Golang 등 다양한 기술을 사용하고 있다.
4. 민첩하다: 아마존이 0.66초마다 새로운 사항을 배포하듯이, 마이크로서비스 아키텍처를 사용하면 민첩하게 새 버전을 배포하는 것이 가능해진다.
5. 전체 서비스 장애 위험 감소: 모노리스는 애플리케이션의 한 부분에서 장애가 발생하면 전체로 전이되지만, 마이크로 서비스는 자기 자신의 서비스에만 영향을 미치므로, 다른 마이크로 서비스에는 장애가 발생하지 않는다. 

2) Micro Service Architecture 단점

MSA도 많은 대가를 치뤄야 다룰 수 있다..

1. 마이크로서비스 간 통신: 각 서비스마다 통신하기 위해서는 동기 or 비동기 통신을 사용하여야 하며, 이런 부분에서 kafka 혹은 다른 기술을 도입해야 하므로 복잡해질 수 있다.
2. 테스트가 어렵다: 여러 기능이 다른 마이크로서비스에 의존하고 있는 경우가 있다. 이 경우에 단위 테스트는 Mock 객체를 이용하여 진행할 수 있겠지만, 통합 테스트의 경우 각 마이크로서비스나 메시지 큐가 실행되고 있는 환경에서 진행해야 하기에 복잡해질 수 있다.
3. 데이터 정합성을 위한 작업이 필요하다: 각 마이크로 서비스에서 서로 중복되는 데이터를 가지고 있는 경우 데이터 정합성을 위한 작업이 필요하다.
4. 장애 발생 시 디버깅이 어렵다: 디버깅 시에 여러 마이크로 서비스와 메시징 큐 등 여러 서비스를 실행한 상태로 진행해야 하기 때문에 복잡하다.

 

 

MSA 특징

위에서 언급한 MSA의 장점과 비슷하지만, 마틴파울러가 언급한 MSA의 특징은 아래와 같다.

• 업무 기능을 중심으로 팀을 구성할 수 있다.
  • 기획자, 설계자, FE•BE 개발자, 디자이너, 테스터 등의 직군이 One Team
• 중앙 거버넌스 형식이 아니라, 자율적인 분권 거버넌스로 폴리그랏하게 자율적인 선택을 할 수 있다.
• 프로젝트가 아니라, 프로덕트를 중심으로 개발 생명주기가 변화되었다.
  • 점진 반복적인 모델, 제품 중심의 Agile 개발 방식으로 2~3주 단위의 Sprint를 통해 소프트웨어를 개발 및 배포한다.
• 많은 마이크로 서비스를 효율적으로 배포하기 위해 인프라 자동화를 구성해야 한다.
  • 이전에, 프로젝트를 진행할 때 배포 자동화 파이프라인을 구성한 적이 있다. 
    이때, 플로우를 말하자면
    1. Github의 Master 브랜치에 새로운 코드가 Merge된다.
    2. Github Webhook 을 통해 Jenkins의 빌드 파이프라인이 Trigger된다.
    3. 소스 코드를 빌드하고 Docker Image를 AWS ECR로 업로드 한다.
    4. 운영 환경에 저장된 배포 Shell Script가 실행되어 새로운 버전이 실행된다.
  • 여기서, 더 실무적으로는 테스트 환경에 먼저 배포해서 테스트가 전체 성공했을 때, 운영 환경에 배포되도록 하는 것이 좋다.
• 분산된 DB 환경을 가진다.
  • 물론, DB가 분산되어 있지 않다고 해서 MSA가 아니다라고는 하지 못하지만, MSA의 장점을 살리지 못하는 방법이다.
  • 분산된 DB 환경에서 데이터 정합성을 맞춰주기 위해서 트랜잭션을 분리하고 Message Queue 매커니즘을 사용하여 보상 트랜잭션을 활용하는 방법을 적용해야 한다.

업무 기능 중심의 팀 예시 - 토스뱅크