MSA 환경에서 발생하는 문제

MSA에서는 애플리케이션을 여러 개의 독립적인 서비스로 나눈다. 이러한 서비스가 몇 개 없을 때는 서비스 코드를 수정해서 통신 방식을 쉽게 관리할 수 있지만 수십, 수백개로 늘어나게 되면 다음과 같은 문제가 발생한다.

복잡한 트래픽 관리
- A 서비스가 B 서비스로 요청을 보낸다고 가정해보자. 이 때 B 서비스가 카나리 배포중이었으면 A 서비스의 요청이 어디로 가야할까? 또는 장애가 발생했을 때 어떻게 트래픽을 우회할 수 있을까? 이런 류의 트래픽 관리 문제(통신 정책)을 일일이 각 서비스에 적용해야한다.
- 근데, 각 서비스가 엄청 많을 경우 이런 공통 로직들을 매번 작성하는 것이 비효율적이고 어렵다.
보안 관리 어려움
- 서비스 간 통신을 전부 TLS로 암호화하거나 인증을 적용하려면, 각 서비스에 관련 설정 또는 코드를 추가해야한다.
- 이 역시 서비스가 엄청 많을 경우 공통 로직이 생기는 것이고, 번거로우며 귀찮은 작업이다.
관측성(Observability) 부족
- 장애나 성능 문제 발생시, 요청 경로를 추적하고 어느 서비스 구간에서 문제가 발생했는지 알아내는 것이 쉽지 않다.
- 모든 서비스마다 모니터링 코드를 넣거나 설정하는 것이 귀찮기 때문이다.

Service Mesh란

Service Mesh는 이러한 서비스 간 통신 관리를 별도의 계층에서 해결해주는 기술이다. 즉, 애플리케이션 서비스 코드를 건드리지 않고도, 네트워크 레벨에서 통신을 제어하고 보안, 정책, 모니터링 기능을 일관되게 적용할 수 있도록 해준다.

[핵심 포인트]

서비스들이 서로 통신할 때, 그 통신 경로 중간에 Proxy를 두어 모든 트래픽을 통제하고 관찰하는 구조를 만든다. 그리고 이 프록시들에게 어떤 정책을 적용할지 결정하고 전달하는 컨트롤 플레인을 둬서 중앙에서 설정을 관리한다.

데이터 플레인(Data Plane)
- 각 서비스 인스턴스 옆에 배치되는 프록시들이 이 영역에 속한다.
- 모든 서비스 간 요청과 응답은 이 프록시를 반드시 거쳐가게 된다.
- 개발자는 기존대로 B 서비스에 요청하는 코드를 쓰면 되지만, 실제 네트워크 상에선 이 프록시가 트래픽을 가로채고 제어한다.
컨트롤 플레인(Control Plane)
- 모든 프록시에게 적용할 정책 (예 : 암호화 규칙, 라우팅 규칙, 모니터링 설정)을 중앙에서 관리하는 영역이다.
- A 요청 중 10%만 B 서비스로 보내고 나머지는 B’ 서비스로 보내라 라는 식으로 설정하면, 프록시들이 그 설정을 받아들여 트래픽 흐름을 알아서 제어한다.
- 이를 사용해 애플리케이션 개발자는 각 서비스 코드를 만질 필요 없이 중앙에서 통신 관련 정책을 업데이트 할 수 있다.