Table of Contents
Microservice Architecture(MSA)? Monolithic?
말 그대로 작은 서비스.
큰 서비스를 잘게 쪼개어 각각 하나의 독립적인 서비스로 나누는 설계 방식이다.
규모가 큰 서비스의 경우에 이를 하나의 프로젝트로 관리하고 개발하고, 하나의 큰(이를 monolithic이라고 표현한다.) 서비스로 운영하게 되면 부작용이 생긴다. 작은 기능 수정인데도, 프로그램을 통째로 내려받아서 수정하고, 테스트하고, 빌드하고 배포해야 한다. 작은 하나의 기능에 문제가 생겨도 프로그램 전체에 문제가 생길 수도 있다.
이런 부작용들이 있다보니 기능(서비스) 간의 종속을 최소화하고, 각각을 분리 개발/운영/배포하며 각 서비스 간에는 REST API(다른 방식도 존재)를 통해 통신하여 하나의 큰 서비스를 수행하는 MSA가 각광을 받았다.
한동안 MSA의 신봉자들이 정말 많았다. “모든 기능을 API로 쪼개야 한다. 심지어는 서비스 하나에 API 하나여야 한다.” 재밌는 것은 모든 것에는 Trade-off가 있다는 것이다. 큰 서비스를 작은 서비스들의 군집으로 잘라내다 보니 개발/빌드/배포도 다 따로 해주어야 하고, 운영도 다 따로 해주어야 하고, 각 서비스 간에 통신에서 발생하는 지연도 존재한다. 이를 극복하기 위해서 많은 기술들이 발전해왔다. Container, Container Orchestration, Observability, Service Discovery 등… 근데 결국 이런 복잡한 구조와 기술들은 가파른 학습 곡선과 인력 수급과 비용에 문제가 생기기 마련이다.
그래서 최근에는 Monolithic과 MSA의 중간에서 Trade-off를 잘 고려한 설계를 하는 방식으로 흘러가고 있다.
MSA Web Service Arichitecture
사실 MSA는 B2C를 대상으로 한 웹 서비스 때문에 생겨났다고 해도 과언은 아닐 것이다. 일반 대중을 대상으로 한 서비스는 트래픽이 예상되지 않고, 각자 독립적이고 병렬적인 기능들을 요구하다보니 위에서 언급한 MSA의 구조가 적절했던 것이다. 웹 서비스는 어떤 구조를 가져야 할까? 하나하나 읊어보자.
웹 페이지를 통한 데이터 통찰 웹 서비스에서 클라이언트가 취하는 행동에 따라 필요한 웹서비스 기술들에 대해 따라가는 식으로 이야기를 풀고자 한다. 하드웨어나 모든 기술들을 전부 설명하며 이야기를 하자니 내용이 너무 많아서 일단 웹 서비스 개발에서 중요하게 여겨지는 개념들만 나열하겠다.
- 서비스 사용자가 인터넷 브라우저를 실행하여 우리가 제공하는 서비스의 도메인(www.sample.com/service1)을 입력하여 접속을 요청한다.
- 인터넷에 노출되어 있는 Gateway가 해당 요청을 수신하고 요청 서브 도메인에 따라 적절한 서비스로 라우팅 해준다.
- 이 때 서비스는 MSA 구조로 Container Cluster에 복수개 배포되어 있다.
- 이 서비스의 실제 IP 주소를 알기 위해 Gateway는 서비스 디스커버리를 통해 해당 서비스를 운영 중인 서버의 IP 주소를 받는다.
- 사용자의 요청을 수신한 서비스 서버는 해당 요청이 정당한지 판단하기 위해 인증/인가 서버에 토큰을 보내 확인한다.
- 서비스는 적절한 요청이었다면 작업을 수행한다. 이 때 다른 서비스의 기능이 필요하다면 서비스 간에도 API를 통해 수행한다.(Backend)
- 적절한 응답을 만들어 API Respose를 보낸다. 들어온 역순으로 해당 응답이 사용자에게 Return된다.
- 요청이 웹 페이지에 접근하는 것이었으므로 웹 서버와 WAS를 통해 만들어진 HTML을 수신해 브라우저에 시각화한다.(Frontend)
- 위에서 언급된 모든 요청과 응답, 서버의 로그, 그리고 서버의 상태 등을 Observability Stack에 집중 저장한다.
위에서 언급하지 못한 개념들도 많고, 위에 언급된 기술들도 하나하나 강의를 해도 되는 사이즈의 내용이다. 어쨌든 요약하자면 MSA한 웹 서비스 구조는 프론트엔드 서버, 백엔드 서버, 게이트웨이, 서비스 디스커버리, Container Cluster, Observability Stack으로 이뤄진다. 여기에 더 저수준의 개념들까지 포함한다면, DNS, L4 Switch, 방화벽, HTTP 통신, SSH 인증서 등도 포함시킬 수 있을 거 같다.
Trade-off 고려하기
듣기만 해도 복잡하다. 뭐가 이렇게 많은 기술들이 필요한걸까?
그래서 사실 대규모 또는 B2C를 고려한 웹 서비스가 아니라면 MSA 구조의 웹 서비스는 과도한 면이 있다. 진짜 간단하거나, UI/UX가 필요 없고, 트래픽이 작을 것으로 예상되는 웹 서비스는 그냥 인터넷 IP 배정된 서버 하나 띄우고, 여기에 풀스택 프레임워크(Blazor나 Next.js 같은 거) 하나 잡아서 Monolithic 하게 개발하는 게 훨씬 나은 선택이다.
결국엔 다 Trade-off를 고려해서 적절히 선택하는 게 중요하다.
답글 남기기