앰비언트 메시 — 사이드카 없는 서비스 메시가 뜨는 이유

서비스 메시(service mesh)를 써본 사람이라면 사이드카(sidecar) 프록시의 부담을 알 것이다. 파드마다 프록시 컨테이너를 하나씩 더 붙이는 방식은 강력하지만 무겁다. 그 무게를 덜어내려는 흐름이 앰비언트 메시(ambient mesh), 즉 사이드카 없는 서비스 메시다. 핵심은 프록시를 파드마다 심는 대신 노드 단위와 필요할 때만 배치해 오버헤드를 줄이는 것이다.

나는 사이드카 메시를 운영하면서 두 가지에 계속 지쳤다. 첫째, 파드 수만큼 프록시가 늘어나 자원이 뭉텅이로 나갔다. 둘째, 프록시를 업그레이드하려면 모든 파드를 다시 띄워야 했다. 앰비언트는 이 두 아픔을 정면으로 겨냥한다.

사이드카 모델의 대가

사이드카 메시는 각 애플리케이션 파드 옆에 프록시를 하나씩 붙여, 그 파드를 드나드는 모든 트래픽을 프록시가 가로챈다. 덕분에 애플리케이션은 아무것도 몰라도 mTLS 암호화, 트래픽 라우팅, 관측성을 얻는다. 개념은 우아하다. 문제는 규모다.

파드가 수천 개면 프록시도 수천 개다. 각 프록시가 메모리와 CPU를 먹고, 시작할 때 지연을 더한다. 프록시를 새 버전으로 올리려면 파드를 재시작해야 하니, 애플리케이션과 메시의 생명주기가 억지로 엮인다. 이 결합이 대규모 운영에서 두고두고 발목을 잡았다.

부담은 자원만이 아니다. 모든 트래픽이 프록시를 한 번 더 거치니 지연이 미세하게 늘고, 파드 안에 컨테이너가 하나 더 늘어난 만큼 장애 지점도 늘어난다. 애플리케이션은 멀쩡한데 사이드카가 준비되지 않아 트래픽이 막히는 순간을 겪어본 사람이라면, 이 결합이 얼마나 성가신지 안다. 강력함의 대가가 결코 작지 않았던 셈이다.

앰비언트가 나눈 두 계층

보안 계층

가장 흔히 필요한 것이 서비스 간 암호화와 신원 확인이다. 앰비언트는 이 기능을 노드 단위 구성요소로 옮겨, 파드마다 프록시를 두지 않고도 트래픽에 mTLS를 입힌다. 이것만으로도 "제로 트러스트 네트워크"의 상당 부분이 채워지고, 자원 부담은 크게 준다.

L7 트래픽 계층

가중치 라우팅, 재시도, 세밀한 정책 같은 L7 기능은 모든 서비스가 늘 필요로 하지는 않는다. 앰비언트는 이 계층을 필요한 서비스에만 선택적으로 얹는다. 원하는 곳에만 무거운 처리를 태우니, 전체 비용이 실제 사용량에 비례하게 된다.

그래서 갈아타야 하나

정답은 "상황에 따라"다. 사이드카 모델은 성숙했고 실전 검증이 두텁다. 이미 잘 굴러가는 사이드카 메시를 억지로 걷어낼 이유는 없다. 다만 자원 낭비가 눈에 띄거나, 메시 업그레이드 때마다 전체 재배포에 시달리거나, 이제 막 메시를 처음 도입한다면 앰비언트는 진지하게 검토할 만하다.

주의할 점도 있다. 계층을 나눈 만큼 트래픽 경로와 디버깅 모델이 사이드카와 달라, 익숙해지는 시간이 필요하다. 노드 단위 구성요소에 문제가 생기면 영향 범위가 파드 하나보다 넓어질 수 있다는 점도 설계에서 고려해야 한다. 그럼에도 "메시를 가볍게"라는 방향 자체는 대세로 굳어지는 중이다.

자주 묻는 질문

앰비언트 메시를 쓰면 사이드카는 완전히 사라지나요?

꼭 그렇진 않다. 많은 구현이 둘의 공존을 허용해, 일부 워크로드는 사이드카로 두고 나머지는 앰비언트로 운영하는 혼합 구성이 가능하다. 점진적 전환을 염두에 둔 설계다.

애플리케이션 코드를 고쳐야 하나요?

아니다. 서비스 메시의 장점은 애플리케이션이 메시를 몰라도 된다는 점이고, 앰비언트도 그 원칙을 유지한다. 암호화나 라우팅은 인프라 계층에서 처리된다.

성능이 정말 더 좋아지나요?

워크로드에 따라 다르다. 파드가 많고 L7 기능을 일부만 쓰는 환경일수록 자원 절감 효과가 크다. 반대로 모든 서비스가 무거운 L7 처리를 필요로 한다면 차이는 줄어든다.