서비스 메시 입문: Istio·Linkerd가 마이크로서비스 통신에 더하는 것

서비스 메시가 왜 필요한가요?

마이크로서비스가 늘어날수록 서비스 사이의 연결선이 폭발적으로 많아지기 때문입니다. 서비스가 셋일 때는 몇 개의 통신만 챙기면 되지만, 수십 개로 늘면 어느 서비스가 어디로 요청을 보내고 무엇이 느려지는지 파악하기 어려워집니다.

더 곤란한 건 공통 기능을 서비스마다 반복해서 넣어야 한다는 점입니다. 재시도, 타임아웃, 암호화, 요청 추적 같은 일은 어느 서비스에나 필요한데, 이걸 각 팀이 각 언어로 코드에 심으면 구현이 제각각이 되고 유지도 힘들어지죠. 서비스 메시는 이 반복되는 통신 처리를 애플리케이션 코드 밖으로 빼내, 인프라 계층에서 한 번에 관리하자는 접근입니다.

서비스 메시는 어떻게 동작하나요?

핵심은 사이드카 프록시입니다. 각 서비스 인스턴스 옆에 작은 프록시를 함께 배치하고, 그 서비스가 주고받는 모든 트래픽이 이 프록시를 거치게 합니다. 서비스는 평소처럼 통신할 뿐이고, 실제 재시도나 암호화, 측정은 옆에 붙은 프록시가 대신 처리하죠.

이 구조는 두 층으로 나뉩니다. 실제 트래픽을 처리하는 프록시들의 모음이 데이터 플레인이고, 이 프록시들에게 규칙과 정책을 내려보내고 상태를 모으는 두뇌가 컨트롤 플레인입니다. 운영자는 컨트롤 플레인에 "이 서비스는 재시도 3회, 이 구간은 암호화"라고 정책을 정의하고, 컨트롤 플레인이 그 정책을 모든 사이드카에 반영합니다. 서비스 코드는 그대로 두고 통신 규칙만 중앙에서 바꾸는 셈이에요.

서비스 메시는 무엇을 더해 주나요?

크게 세 가지를 코드 변경 없이 얹어 줍니다. 트래픽 관리, 관측성, 보안이죠.

먼저 트래픽 관리입니다. 어떤 버전으로 몇 퍼센트를 보낼지, 실패하면 몇 번 재시도할지, 특정 서비스가 흔들리면 잠시 차단할지(서킷 브레이커)를 정책으로 정합니다. 다음은 관측성이에요. 모든 트래픽이 프록시를 거치므로, 서비스별 요청 수·지연·오류율과 요청이 서비스를 건너가는 경로를 코드 수정 없이 수집할 수 있죠. 마지막은 보안입니다. 서비스 사이 통신을 자동으로 암호화하고 서로 신원을 확인하는 mTLS 상호 인증을 메시 차원에서 적용합니다. mTLS가 무엇이고 왜 필요한지는 mTLS 상호 인증: 클라이언트도 신원을 증명하는 양방향 신뢰 글에서 자세히 다뤘습니다.

Istio와 Linkerd는 어떻게 다른가요?

둘 다 대표적인 서비스 메시지만 지향점이 다릅니다. Istio는 기능의 폭, Linkerd는 단순함과 가벼움을 앞세웁니다.

정답은 없습니다. 정교한 트래픽 정책과 폭넓은 기능이 필요하면 Istio가, 최소한의 구성으로 관측성과 mTLS부터 빠르게 얻고 싶다면 Linkerd가 잘 맞아요. 팀의 운영 여력과 실제로 필요한 기능을 기준으로 고르는 것이 현실적입니다.

도입할 때 무엇을 주의해야 하나요?

서비스 메시가 공짜는 아닙니다. 비용도 함께 따라온다는 점을 알고 시작해야 해요.

먼저 모든 트래픽이 사이드카를 한 번 더 거치므로 약간의 지연과 리소스 오버헤드가 생깁니다. 프록시 수만큼 메모리와 CPU도 더 쓰죠. 다음은 운영 복잡도입니다. 컨트롤 플레인과 프록시를 관리하고 정책을 다루는 데 학습 곡선이 있어, 팀에 여력이 없으면 오히려 부담이 됩니다. 그래서 서비스 수가 적거나 통신이 단순하다면 서비스 메시 없이도 충분한 경우가 많아요. 관측성과 보안 같은 특정 목적이 뚜렷할 때, 그리고 그 이득이 운영 부담을 넘어설 때 도입하는 것이 현실적입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)