서비스 메시

서비스 간 통신에서 모든 서비스가 반복 구현하던 것을 밖으로 빼냅니다.

가장 큰 값은 언어와 무관해진다는 점입니다. Java 와 Go 와 Python 서비스가 섞여 있으면 라이브러리를 세 개 만들고 각각 갱신해야 하는데, 프록시는 하나로 끝납니다.

두 번째 값은 코드 변경 없이 정책을 바꾸는 것입니다. 재시도 횟수나 타임아웃을 조정하려고 20개 서비스를 재배포하지 않아도 됩니다.

흔한 실수: 서비스 메시를 서비스 디스커버리와 같은 것으로 보는 것. 디스커버리는 그 기능의 일부이고, 메시의 범위는 인증, 트래픽 제어, 관측까지 포함합니다.

세 번째가 실제 사고로 이어집니다. 제어 평면 설정을 잘못 배포하면 모든 서비스의 통신이 동시에 영향을 받습니다. 라이브러리 방식이면 서비스별로 배포되므로 영향 범위가 좁습니다.

첫 번째도 지연이 중요한 서비스에서는 무시할 수 없습니다. 요청당 1밀리초가 붙고 호출이 5단계면 5밀리초입니다.

흔한 실수: 기능 목록만 보고 도입하는 것. 얻는 기능은 명확하지만, 그 기능이 지금 실제로 필요한지와 운영할 여력이 있는지가 판단의 중심입니다.

애플리케이션과 같은 실행 단위에 프록시를 함께 두고, 들고 나가는 모든 트래픽을 그 프록시로 우회시킵니다.

3번이 이 방식의 값입니다. 애플리케이션 코드는 프록시의 존재를 모릅니다. 라이브러리를 넣거나 주소를 바꾸지 않아도 됩니다.

첫 두 줄이 실제로 자주 겪는 문제입니다. 컨테이너 시작과 종료 순서를 제어하지 않으면 배포마다 소수의 요청이 실패합니다.

흔한 실수: 프록시가 모든 통신을 처리한다고 가정하는 것. 설정에 따라 특정 포트나 대상은 우회하며, 그 부분에는 정책과 지표가 적용되지 않습니다.

서비스가 적을 때는 첫 번째가 합리적입니다. 언어가 하나이고 서비스가 다섯 개면, 라이브러리 하나로 대부분을 해결하고 운영할 것도 늘지 않습니다.

규모가 커질 때 첫 번째의 한계가 드러납니다.

그 시점에 서비스 메시가 값이 나옵니다. 순서를 뒤집어 말하면, 라이브러리로 감당이 안 될 때가 도입 시점입니다.

흔한 실수: 마이크로서비스를 시작하면서 함께 도입하는 것. 서비스가 세 개일 때 도입하면 운영 부담만 늘고, 정작 필요한 기능은 프레임워크로 충분합니다.