몇 주 전, 회사에서 MSA에 대한 교육을 들었다.
굉장히 흥미로운 내용이기도 했고,
최근 국내 기업들에서도 MSA 도입 사례가 많아지는 것 같아 공부한 내용을 정리할 겸 글을 남겨본다.
총 두 개의 글을 작성하였다.
What is MSA ?
용어 의미
일단 MSA라는 용어에 대해 알아보자.
Microservice Architecture의 줄임말로,
해외에서는 Microservices라는 용어를 많이 사용한다고 하지만 여기서는 편의상 MSA로 통칭하겠다.
단어들의 뜻 그대로,
어떠한 Service를 만들 때 Micro 단위,
즉, 하나의 기능을 하는 서비스 단위로 쪼갠 구조를 뜻한다.
간단한 예를 들어,
하나의 상품을 선택하고 결제 후 배송까지 하는 쇼핑몰을 만든다고 해보자.
기존에는 상품 선택, 결제, 배송을 담당하는 소스 코드들을 한데 뭉치거나 서로 연관되고 얽히게 만들었다.
그러한 구조를 Monolithic Architecture이라고 부른다
(아래에서 좀 더 자세히 알아보자).
하지만 MSA에서는 각 서비스를 떼어 내어
상품 선택 기능만 하는 A 서비스,
결제 기능만 하는 B 서비스,
배송 기능만 하는 C 서비스를 만들고
각 서비스들이 서로 필요할 때만 호출하는 식이다.
정의
MSA의 정의는 다음과 같다.
"하나의 어플리케이션을 다수의 독립적인 서비스들의 집합으로 구성하는 것"
좀 더 세부적인 정의를 해보자면 아래와 같다.
- 각자 "별도의 프로세스에서 실행"되며 HTTP API 같은 "가벼운 매커니즘으로 통신"하는 애플리케이션
- 작은 "서비스들은 각자의 비즈니스 기능을 담당"하고 완전 "자동화된 절차에 따라 독립적으로 배포"됨
- 각 서비스는 "서로 다른 프로그래밍 언어나 서로 다른 데이터 저장 기술을 사용"할 수 있음
MSA 이전의 서비스 구조 - Monolithic Architecture
MSA가 적용되기 전 대다수의 서비스는
하나의 서비스를 이루고 있는 기능들이 서로 얽혀있는 형태인 Monolithic 구조를 따랐다.
즉, 서비스를 이루고 있는 전체 기능을 단 하나의 코드 베이스로 개발하고
그러한 대규모 단일 코드 베이스를 빌드하고 배포할 때에는 단일 통합 데이터베이스를 사용한다.
이 글 초반부에서 언급했던 쇼핑몰을 다시 생각해보자.
쇼핑몰을 Monolithic 구조로 만들게 되면,
상품 선택, 결제, 배송을 담당하는 소스 코드들이 한데 뭉치거나 서로 연관되고 얽히게 된다.
서비스를 구현하기 전 설계할 당시에는 큰 문제점이 없고 오히려 구조를 짜기 쉽겠지만,
사용자가 많아져 결제 기능이 장애가 생기게 되면 결제 기능 뿐만 아니라
그와 얽힌 상품 선택, 배송 기능 또한 장애가 발생할 것이다.
아주 간단한 기능들만 하는 쇼핑몰을 예로 들었지만,
보통의 서비스들은 더 많은 기능을 하므로 하나의 기능이 장애가 발생하여 다른 모든 기능들이 멈추게 되면..
상상도 하기 싫은 큰 사고가 발생하는 것이다.
MSA의 역사
MSA라는 용어가 탄생하기까지의 역사를 간략하게만 살펴보자.
- 2005년, Cloud Computing Conference에서 "Mircro Web Service"라는 개념 발표
- 2011년, SW Architecture 워크샵에서 "Microservice"라는 용어 탄생
- 2012년, "Microservices"라는 용어가 더 적절하다고 판단
- 2014년, James Lewis와 Martin Fowler가 Microservices의 정의, 특징들을 정리
Microservices
Defining the microservices architectural style by describing their nine common characteristics
martinfowler.com
이렇듯, MSA라는 개념 자체가 나온지 이제 10년밖에 안됐다.
그렇지만 산업계의 두 서비스에서 MSA를 적용하며 MSA의 진정한 태동을 알렸는데,
바로 우리도 잘 아는 Amazon, Netflix다.
MSA의 적용 - Amazon
2001년까지 Amazon은 Monolithic 구조로 서비스를 유지했다.
하지만 새롭게 수정, 개발 및 추가되는 코드들이 점점 많아지고,
그러한 코드들이 한데 모여 있다보니 실 사용자가 사용하는 운영 시스템에 배포되려면 굉장히 많은 시간이 걸리게 되었다.
그래서 Amazon의 수장인 Jeff Bazos는 이러한 거대한 시스템을 Decomposition하여
독립적인 서비스들의 집합으로 재설계하기 위해 MSA로의 전환을 결정하고,
전직원에게 아래와 같은 내용을 담은 이메일을 보냈다고 한다.
- "모든 팀은 해당 팀의 기능 및 데이터를 Service Interface를 통해서만 노출할 것"
- "다른 팀의 기능 및 데이터를 사용하려면 Network를 통한 Service Interface를 호출해야 함"
- "Service Interface 기술은 상관하지 않겠음(HTTP, Corba, etc.)"
- "단, 누구든 이것을 지키지 않으면 해고(!)"
그로 인해 Amazon은 MSA로의 전환을 통해 아래와 같은 향상된 성능을 얻을 수 있었다고 한다.
- 평균 서비스 배포 간격 -> 11.6초
- 1시간 동안의 최대 배포 수 -> 1,079개
- 단일 배포를 받는 평균 호스트 개수 -> 10,000개
- 단일 배포를 받는 최대 호스트 개수 -> 30,000개
"배포의 횟수는 고객에게 주는 가치 전달의 속도"라는 말이 있듯이,
Amazon은 MSA가 갖고 있는 가장 큰 장점 중 하나를 얻게 되었다.
MSA의 적용 - Netflix
Netflix 역시, 초기에는 Monolithic 구조로 개발되었다.
그런데 2008년, Netflix가 갖고 있는 데이터베이스에 큰 장애가 발생했고,
무려 3일(!)동안 Netflix의 모든 비즈니스가 정지되었다고 한다.
아마 그 장애가 서버 증설이 필요한 것이었는지,
2008~2009년에 모든 시스템을 AWS Cloud로 Migration 하기로 결정했다.
하지만 이 때는 AWS가 아직 믿고 맡길 정도의 수준이 아니었기 때문에,
모든 시스템을 한 번에 옮기는 Big Bang Migration이 아닌,
단계적 Migration으로 진행했다(2016년 2월까지, 총 7년간 진행).
그로 인해 자연스럽게 Monolithic 시스템이 분할되었고,
MSA를 설계 및 구현하게 되었다고 한다.
2009년에 시작한 시스템 재설계 및 구현이 2011년에 완료되었고,
2015년 기준, Netflix는 500개 이상의 Microservices로 구성되었다.
Netflix OSS
Netflix는 Cloud 환경 및 MSA 전환 중 다양한 문제에 봉착했고,
이러한 문제들을 해결하기 위한 Architecture Pattern 및 OSS를 개발하게 되었다고 한다.
Netflix OSS 중 대표적인 기능은 Eureka라 불리우는 client-side service discovery가 있다.
(추후 다른 포스팅으로 다뤄 볼 예정)
MSA 적용 - 국내 사례들
Amazon이나 Netflix가 성공적으로 MSA로 전환을 하고 좋은 성과를 내자,
국내 기업들도 하나둘 MSA를 적용하기 시작했다.
대표적인 사례로는, PAYCO 쇼핑, 11번가, 삼성전자, 삼성SDS, 쿠팡, 배달의 민족 등이 있다.
이 중 11번가에서 MSA로 전환하며 만든 영상(링크)을 강력 추천한다.
1시간 15분 정도로 좀 길어도 굉장히 유익한 내용이다.
대강 요약하자면,
11번가도 기존에 어마무시한 Monolithic 시스템을 갖고 있었고,
이를 MSA 구조로 탈바꿈하는 프로젝트에서 얻은 교훈과 배움들을 공유하는 영상이다.
기술 스택으로는 Spring Boot와 Netflix OSS를 사용했는데,
특히 Netflix OSS의 유명한 Eureka 기능 말고도 여러 기능을 소개해줘서 굉장히 알찼다.
참고로, 얼마 전 배달의 민족에서도 우아한 테크 콘서트(후기 글 링크)라는 것을 통해
배민이 Cloud 및 MSA로의 전환을 하며 얻은 교훈을 여러 영상으로 공개했지만,
11번가처럼 유튜브에 공개되어 있지는 않다.
이번 글에서는 MSA의 정의, 역사, 적용 사례 등을 작성했다.
다음 글에서는 MSA / Monolithic Architecture의 장단점, 오해 등에 대해 작성할 예정이다.
끝!
