MSA

MSA...MS.... Micro soft..?

이번 포스팅은 MSA 관련 개념과 왜 필요한지 알아보려 합니다.

 

MSA (Microservice Architecture)

단일 응용 프로그램을 나누어 작은 서비스의 조합으로 구축하는 방법

비즈니스 도메인을 중심으로 모델링된 소규모 자율 서비스 모음으로서 애플리케이션을 구성하는 아키텍처 스타일

---

 

어떤 의미인지 완벽하게 와닿진 않습니다만, 'Micro'한 'Service'를 의도한다는 것 쯤은 알 수 있습니다.

왜 MicroService가 등장하게 되었는지, 기존엔 어떤 방식이었는지 하나씩 알아 보겠습니다.

 

 

 

기존 서비스는 MonolithicService 입니다.

Monolithic의 사전적 정의는 아래와 같습니다.

1. 하나의 암석으로 된
2. 단일체의, 한 덩어리로 뭉친

 

즉, 이제까지 애플리케이션은 하나의 뭉쳐있는 단일체(Monolithic) 서비스로 존재했습니다.

Monolithic은 아래와 같은 장/단점을 가집니다.

장점

• 기술 단일화
• 관리 용이
• 심플한 구조
• 코드, 트랜잭션 관리 간편
• 설계/테스트 간편

단점

• 하나의 서비스가 모든 서비스에 영향을 줌
• 개발 언어에 종속적
• 수정이 용이하지 못함 (선택적 확장 불가)
• 빌드, 테스트 시간이 길어짐

 

 

 

이 Monolithic Architecture를 그림으로 그려보면 다음과 같습니다.

 

일반적으로 OOP 개념을 도입해 서비스를 개발한다면 이와 같은 구성을 많이 쓰셨을 겁니다.

 

각 객체별 구현이 잘 나뉘어 있고 잘 짜여진 서비스 같네요. 하지만, 문제가 하나 있습니다. 전체 서비스가 단일 데이터베이스를 공유하는 단일 인스턴스 아래에 있다는 점입니다.

 

이렇게 된 경우 위에서 말씀드린 장단점이 완벽하게 드러나겠죠.

특히, 규모가 커지면 커질수록 빌드/테스트 시간이 기하 급수적으로 늘어나는 것은 물론, 수정 작업 또한 상당히 번거로울 것입니다.

 

이런 복잡도를 줄이기 위해 각 기능에 각기 다른 서비스를 할당해 자체 데이터를 처리하고 각기 다른 기능을 수행하도록 의도하는 것이 Microservice Architecture 입니다.

 

 

---

 

 

 

오른쪽은 MicroService Architecture의 구조입니다.

 

Monolithic과 확연한 차이가 하나 보입니다. 바로 단일 Instance에 묶여있는 것이 아닌 각자 따로 구성되어있다는 것이죠.

 

이렇게 Micro한 단위로 나누어서 서비스를 설계하고 조립하듯이 각 서비스를 붙여 사용합니다.

 

또한, 구성을 보니 SOLID 5원칙 중 하나인 단일 책임 원칙(SRP)과 유사하게도 보입니다. (객체가 아닌 서비스에 적용이 됐네요)

 

 

 

 

그림 1. Monolithic Architecture vs MSA

구조적으로는 위와 같이 보셔도 좋을 것 같습니다.

 

MSA 구조 및 동작 방식

• 모든 서비스는 도메인과 기능에 따라 분리되며 개별 microservice로 할당
• 이러한 microservice에는 자체 로드 밸런서와 실행 환경이 있어 기능을 실행하는 동시에 자체 DB 데이터를 캡처
• 모든 microservice는 REST 또는 stateless 서버를 통해 서로 통신
• Microservices는 Service Discovery를 통해 통신 경로를 파악하고 자동화, 모니터링 등 운영 기능 수행
• 이후 microservice에서 수행하는 모든 기능이 API Gateway를 통해 클라이언트에 전달
• 모든 요소는 API Gateway에 연결, 즉, API Gateway에 연결된 모든 사용자는 자동으로 전체 시스템에 연결됨.

 

여기서 API Gateway가 상당히 중요한 역할을 해주는 것을 알 수 있습니다.

아래에서도 잠깐 언급하겠지만, 자세한 내용은 따로 포스팅 하도록 하겠습니다.

 

어쨋든 이렇게 MSA로 구성되는 경우 장/단점은 아래와 같습니다.

장점

• 다른 개발 기술 스택 사용 가능
• 단일 Business에 집중
• 소규모의 작은 배포 가능, SW 수시 업데이트 가능
• 각 서비스별 개발 및 배포 가능

단점

• trouble shooting 요구 증가
• 각 서비스간 통신으로 인한 지연 시간
• 설정과 기능 등의 연동으로 인한 번거로움
• 데이터 베이스간 트래킹이 어려움 등..

 

 

단점을 보니 MSA를 무조건 적용하는 것도 좋은 방법은 아닐 것 같습니다.

내용을 잘 파악해 활용하면 좋을 것 같아 MSA 특징에 대한 설명이 나와있는 사이트의 내용도 번역해 첨부합니다.

출처는 아래 참고자료에 기입해두었습니다.

그림 2. MSA 특징

Decoupling – 시스템 내의 서비스는 전반적으로 분리됩니다. 따라서 애플리케이션 전체를 쉽게 구축, 변경 및 확장할 수 있습니다.

Componentization - Microservices는 쉽게 교체 및 업그레이드할 수 있는 독립적인 구성 요소입니다.

Business Capabilities - Microservices는 매우 단순하며 단일 기능에 초점을 맞춥니다.

Autonomy - 개발자, 팀이 서로 의존도 없이 진행할 수 있기 때문에 개발 속도가 빠릅니다.

Continous Delivery - 소프트웨어 생성, 테스트 및 승인에 대한 체계적인 자동화를 통해 빈번한 SW release를 가능하게 합니다.

Responsibility - Microservices는 프로젝트에 초점을 맞추는 것이 아닌 어플리케이션을 책임지는 제품으로 취급합니다.

Decentralized Governance - 개발자는 자신의 문제를 해결하기 위해 가장 유용한 도구를 자유롭게 선택할 수 있습니다.

Agility - 새로운 기능을 신속하게 개발하고, 다시 폐기할 수 있습니다.

 

 

MSA는 이러한 장/단점, 특징을 가집니다.

관련 특징을 잘 파악해서 개발하려는 프로젝트에 알맞는 방법인지 고려해보시면 좋을 것 같습니다.

 

---

마지막으로 실제 사례를 통해 구조 및 필요성에 대해 이해해 보고 마무리하겠습니다.

이미 내용 파악이 되었다면 아래 내용은 생략하셔도 되겠습니다.

 

현재 다양한 회사에서 MSA 방식을 도입해 사용하고 있습니다.

이름만 들어도 유명한 회사들이죠.. (아마존, 넷플릭스, 우버 등등...)

 

어떻게 활용하고 왜 사용했는지에 대한 내용을 하나씩 예로 들긴 힘드니 공통적인 부분을 정리해보겠습니다.

아래는 Uber의 Microservice Architecture로 지칭되는 다이어그램입니다.

그림 3. Uber Microservice Architecture

 

이 구조는 Uber뿐만 아니라 대부분의 Microservice Architecture의 공통점입니다.

우선, 기능/도메인으로 묶여 서비스가 나누어진 것을 볼 수 있습니다.

또한, REST API를 통해 필요한 경우 서로 통신하며 사용자는 API Gateway를 통해 모든 서비스에 접근할 수 있습니다.

 

위와 같은 구성이 필요했던 이유는 다음과 같습니다.

• 하나의 기능을 업데이트하기 위해 모든 기능을 반복적으로 재구성하고 배포하고 테스트 해야함
• 하나의 소스 레포지토리에서 각각의 파트를 담당하는 개발자가 코드를 수정해야하는 어려움
• 새로운 기능을 전 세계적으로 동시에 적용하면서 그에 따른 인프라 성능 확장이 매우 어려움

 

예를 들어, Uber로 자신의 목적지까지 데려다 줄 수 있는 차량을 찾는 것은 시간이 꽤 걸립니다.

그에 따라 차량 검색 서비스의 사용자가 많아져 이를 개선한다고 가정하겠습니다. (로직 성능 완화 또는 Scale up 등..)

Monolithic에선 검색 서비스만 개선한다 하더라도 검색 서비스만 따로 처리할 수 없습니다.

즉, 테스트 및 배포를 하기 위해선 전체 서비스를 모두 실행해봐야 합니다.

 

하나의 서비스가 모든 서비스에 영향을 주거나, 테스트 및 빌드 시간이 오래 걸리는 등의 문제가 실제로 발생한 것이죠.

 

Microservice에선 위의 작업을 각 서비스 단위로 구분짓기 때문에, 개선이 필요한 서비스가 있다면 해당 서비스만 변경, 빌드, 테스트, 배포를 진행할 수 있으니 훨씬 효율적으로 처리할 수 있습니다.

 

 

 

도커 컨테이너와 이를 쿠버네티스로 묶어 배포하는 방식 또한 Microservice와 유사한 방식 같습니다.

MSA를 체계적으로 사용하기 위해 쿠버네티스를 사용하는 것이 정확한 이야기일 것 같은데, 관련해서 찾아보시면 이해에 조금 도움이 될까 싶네요.

 

이 내용은 생각대로 글로만 정리하기엔 큰 한계가 있네요..

제대로 알지 못해서 그렇겠지만, 개인 프로젝트 규모에선 제대로 써볼 일이 없다는게 가장 아쉬운 점인 것 같습니다.

이외에도 MSA 관련해서 첨언해주시면 저 같은 입문자에게 좋은 돌다리가 될 것 같습니다.

 

 

 

 

 

 

 

참고 자료

Microservice Architecture - Uber

서비스 경량화를 위해 MSA 설계시 고려 사항 - 삼성 SDS

What is Microservices - Introduction to Microservice Architecture (edureka!)

MicroService Architecture - Learn, Build, and Deploy Applications (DZone)

마이크로서비스의 철학, 개념 간단히 말씀드립니다. - 기술노트with 알렉 (Youtube)