MSA를 왜 적용하는 걸까? MSA 개념
MSA의 개념과 MSA를 시스템 개발, 운영에 적용하는 이유를 간략하게 살펴보려한다.
MSA(Microservice Architecture) 란?
MSA는 “이 서비스에서는 다른 서비스를 모른다.”라는 독립된 서비스라는 개념을 기반으로 한다. 모든 서비스는 독립된 서비스로서 자신 혼자 배포되며, 이 서비스들이 API 등을 통해 조합되어 사용자에게 특정한 기능으로 제공되는 아키텍처 디자인 패턴 이라고 할 수 있다.
정리하면, 각 서비스들은 독립적인 배포가 가능하고, 특정한 기능 제공을 위해 마치 서비스들이 블록처럼 조립되는 것이 MSA라고 할 수 있다.
MSA 적용사례
많은 기업들이 MSA를 적용하여 서비스 배포 비용을 절감하고, 시스템의 성능을 개선해왔다. 몇 가지 예시를 살펴보자.
넷플릭스
Netflix는 1억 1,800만 명의 가입자에게 1일 1억 이상의 비디오 스트리밍을 제공하고 있다. 서버를 배포하고, 발급받던 기존의 온프레미스(On-premise)
방식을 MSA로 교체하여 “18 배의 비용”을 감소시켰다고 한다.
쿠팡
쿠팡은 MSA를 도입하여 하루에 약 100회 이상의 배포를 이상없이 실행하고 있다고 한다. 이는 100여 가지의 다양한 업데이트와 신기능 도입이 이뤄진다는 의미와도 같다.
MSA 특징
위키피디아 - MSA에 따르면 MSA는 아직까지 공식적으로 합의된 정의는 없다. 그저 MSA를 적용한 사람들로부터 자주 인용되는 특징(공감대)만 있을 뿐이다.
- 각 서비스들의 Network, HTTP를 통해 통신
- 독립된 배포 단위
- 각 서비스는 쉽게 교체 가능
- 각 서비스는 기능 중심으로 구성 e.g. 사용자 인터페이스, 프론트엔드, 추천, 로지스틱스, 청구서 발부 등
- 각 서비스의 특징에 가장 부합하는 각기 다른 프로그래밍 언어, 데이터베이스, 하드웨어, 소프트웨어 환경을 사용하여 구현 가능
- 서비스들은 규모가 작고, 메시지 전달이 가능
- 컨텍스트별로 묶여 자율적으로 개발되며,독립적인 전개 가능
- 분산적이며 빌드가 가능하고, 자동화된 프로세스들로 출시
MSA 적용 범위
MSA를 적용할 때, 어느 정도 규모에 MSA가 적합할지 고민한다고 한다. 공식적인 합의는 없지만, 보통 팀에서 개발할 수 있는 크기를 상한으로 둔다. 절대로 3~9명의 사람들이 스스로 더 많은 개발을 할 수 없을 정도로 커지면 안된다. 다시 말하면, 9명을 초과할 때는 반드시 또 다른 MSA를 구축해야하는 것이다.
모놀리틱 아키텍처 vs 마이크로서비스 아키텍처
위 그림은 모놀리틱 아키텍처와 마이크로서비스 아키텍처를 비교한 것이다. 모놀리식 아키텍처는 애플케이션을 하나로 통합하여 개발, 배포하는 방식이고, 마이크로서비스 아키텍처는 개별 서비스 단위로 애플리케이션을 개발, 배포하는 방식이라고 할 수 있다.
앞서, 마이크로서비스 아키텍처는 서비스별 독립성이 보장된다고했다. 그렇기 때문에 서비스별로 개발, 배포 및 테스트가 가능하다. 이로부터 서비스를 빠르게 개선하고, 업데이트 할 수 있어 고효율, 저비용이라는 장점을 갖는다.
마이크로서비스 아키텍처를 보며 Github의 브랜치 기능이 떠오르기도 했다. 시스템을 기능별로 브랜치를 나누어 독립적으로 개발을 진행하고, 마스터 브랜치에서는 배포가 이루어지는 과정과 유사해보인다. 다만, MSA는 각 서비스들이 독립적으로 소스를 공유하지 않는다는 점이 차이일 것 같다.
MSA 방식의 단점은 배포나 테스트, 서비스를 관리하는 복잡성이 증가한다는 것이다. 서비스별로 독립적으로 관리를 하기 때문에 시스템 전체의 관점에서 봤을 떄, 복잡한구조를 갖는다.
MSA 예시
CAFE를 도메인으로하는 애플리케이션을 MSA 방식으로 구현한다면 위와 같은 그림으로 표현할 수 있다. 서비스인 order 기능과 production 기능은 독립적인 DB
를 가지고 있다. 만약 다른 서비스에 대한 요청이 필요하다면 REST API 인터페이스
를 통해서 통신한다. MSA는 코드를 공유하면서 서비스를 호출하면 안되기 때문이다.
정리
지금까지 MSA의 개념과 MSA를 적용했을 때 얻을 수 있는 장,단점, 예제를 살펴봤다. 사실, 아직까지 MSA는 완벽하게 검증이 된 아키텍처는 아니며, 검증하는 과정에 있다고 한다. 프로젝트의 특성에 맞게 MSA 방식을 적용해본다면 좋을 것 같다.
Leave a comment