☕ 시작
저기 저... 바이러스처럼 생긴 구조도가 몇 년 전에 넷플릭스에서 공개한 자사의 MSA구조도이다. 😮
(초록색이 서비스들이고, 파랑색 선이 서로 서로 참조하고 있는 모습이다.)
MSA라는 개념이 나온지 얼마되지 않은 것 같은데, 어느새 굉장히 많은 회사에서 MSA 구조로 시스템을 개발하고 운영하는 것 같다.
그래~서 이번 기회에, 어느새 백엔드 개발자의 필수 스펙으로 자리잡은 MSA에 대한 개념을 익히고, 로컬에서 구현까지 해볼까 한다.
그 시리즈 첫번째 글로써 MSA의 개념을 잡는 시간을 가져보자!
a.k.a 'MSA학 개론' 레츠고 🔥
MSA 란?
Micro Service는 말 그대로 작고 독립적인 하나의 서비스를 이야기한다.
즉, Micro Service Architecture는 복수의 Micro Service들이 모여서 군집을 이루어 하나의 서비스처럼 동작하는 것을 이야기한다.
🧐 MSA는 만병통치약!?
많은 회사들에서 MSA로 시스템을 설계하고 있고, 수~~~ 많은 장점들이 있지만, MSA가 만사형통인 것은 아니다.
MSA를 구축하고 운영하려면 많은 물질적, 시간적 비용이 든다. 그리고 MSA의 반대 개념인 Monolithic Architecture에 비해 러닝커브도 상당히 높다.
즉, 아무 회사나 MSA를 도입할 수 있는 것은 아니다.
또, MSA를 안정적으로 운영하려면 사실상 필수적으로 시스템 모니터링, 로깅기능 그리고 CICD 자동화가 매우 잘 구축이 되어 있어야 한다.
하나의 기능이 여러 서비스를 거쳐서 수행되므로, 위의 것들이 잘 구축되어 있지 않은 상태에서 장애가 발생한다면, 장애 원인을 파악하기 매우 어렵게 된다.
Why MSA?
MSA의 트렌드를 이끌어 가는 회사 중에 하나가 바로 넷플릭스이다.
이 넷플릭스를 생각하며, 왜 MSA가 등장했고 트렌드로 자리잡게 되었는지 알아보자. 🤭
🤔 MSA... 왜 등장했을까?
먼저, 넷플릭스는 전~ 세계에 고객들이 있고, 고객들이 이용하는 컨텐츠도 단순 텍스트가 아니라 무려! 영화와 드라마이다. ㅎㅎ
또, 핸드폰, 태블릿, 컴퓨터, TV등등 화면이 있는 온갖 기기로 우리는 넷플릭스를 이용한다.
즉, 넷플릭스는 24시간 헤비한 트래픽을 견디며, 디바이스의 종류에 상관없이 원활한 서비스를 제공해야하는 것이다.
(크... 어케 했누... 😂)
다시 말해 넷플릭스는 엄청 튼튼하고, 엄청 빠르고, 엄청 유연하고, 엄청 개발 및 운영이 용이한 서비스를 만들어야만 하는 상황인 것이다.
이러한 역경을 극복하기 위해서 MSA라는 개념이 등장하고 관련된 기술들이 쏟아지게 된 것이라고 할 수 있다.
MSA의 구조
사실, MSA는 무조건 이래야한다! 라는 것은 없다.
하지만, 몇 년에 걸쳐 자리잡은 MSA의 Best Practice가 있는데 한번 살펴보자.
이 그림이 개인적으로는 MSA의 핵심을 가장 잘 표현한 것 같다.
MSA의 대략적인 구조는 이러하다.
- 다양한 클라이언트는 하나의 서버(API Gateway)로 API 요청을 한다.
- 게이트웨이 서버에서 클라이언트의 요청을 적절한 서비스(서버)로 라우팅한다.
- 각 서비스(서버)들은 언어가 달라도 되고, DB도 달라도 된다.
MSA의 핵심 구성요소 6가지
이전 그림은 사실 에피타이저였고, MSA를 더 잘 보여주는 그림은 아래의 그림이라고 할 수 있다.
그림에서도 볼 수 있듯이 MSA는 크게 6가지의 필수 및 핵심 요소로 구성이 된다.
1) External Gateway
클라이언트의 API요청의 진입점이라고 이야기할 수 있다.
ex) Spring cloud gateway, Netflix Zuul등등
2) Service Mesh
Service Mesh는 마이크로 서비스 간의 감지(Discovery), 라우팅, 분산처리, 인증/인가, 보안을 담당한다. 사실상 "감지, 라우팅, 분산처리"가 한 덩어리이고, "인증/인가, 보안"이 한 덩어리이다.
🧐 감지, 라우팅, 분산처리의 흐름
- 게이트웨이를 통해 들어온 요청을 어디로 보내면 될지
Service Discovery로 찾아서,Load Balancing으로 적절한 서비스로 전달한다.
3) Runtime Platform
실제 비지니스 로직이 수행되는 영역이다.
실질적인 기능들이 있는 서버와 이 서버들을 사용량에 따라 Auto scaling 하는 기능도 이 영역에 포함된다.
이러한 서버 오케스트레이션은 요즘은 도커와 쿠버네티스로 많이 처리한다.
ex) AWS EKS, Azure AKS, Google Cloud GKE등등
4) Backing Services
Backing Service는 DB영역(?)이라고 할 수 있다. 실제 DB와 캐싱, 비동기 처리 및 메세징 처리를 수행하는 영역이다.
- DB: MySQL, MongoDB, PostGres등등
- 캐싱: Redis등등
- MOM(Message-oriented Middleware): 선입선출방식의 자료구조인 Queue를 활용해서 대용량 데이터 처리, 비동기 데이터 처리를 하기 위한 서비스. Ex, RabbitMQ, Kafka
5) Telementry
MSA는 보다시피 매우 복잡한 구조이므로, 시스템 진단 기능과 모니터링 기능이 필수적이다.
- Diagnostics(로깅, 추적): Spring cloud Sleuth, Zipkin등등
- Monitoring: Prometheus & Grafana, 네이버 핀포인트
6) CI/CD Automation
MSA에는 사실상 CICD 자동화를 필수 조건이다. 구조가 워낙 복잡하다보니, 사람이 CICD를 직접 수행하는 것은 뭐.. 불가능에 가깝다고 할 수 있다. ㅎㅎ
ex) Jenkins, Github Action, AWS Code deploy등등
++ 각 영역별 대표적인 제품들
☕ 마무리
MSA... 공부할 게 너무 많아서 공부할 엄두가 안..난..다... 🤭
이럴땐, 무지성 돌격st. 공부를 해야할 것 같다 ㅎㅎ
아무튼 이번 글에서는 MSA의 전반에 대해서 알아보았으니, 다음 글부터는 한 부분씩 구축해나가며 좀 더 세세한 것들을 다뤄보도록 하겠다.
그럼 다음 글에서 꼭... 만나길 🙏
