Istio ambient vs sidecar, 우리 팀은 뭘 골랐나

Istio ambient mode가 1.24에서 GA된 지 반년 좀 넘었다. 우리 팀은 sidecar 기반으로 운영해온 클러스터가 3개 있고, 신규로 붙일 클러스터가 하나 더 생기면서 자연스럽게 "이번엔 ambient로 갈까?"라는 논의가 시작됐다. 결론부터 말하면 신규 클러스터는 ambient, 기존 3개는 당분간 sidecar 유지다. 왜 그런 판단을 했는지 정리한다.

솔직히 처음엔 나도 "ztunnel이 좀 무섭다"는 인상이 있었다. 노드 단위로 프록시가 돌고, 특정 노드가 죽으면 그 노드에 있는 모든 워크로드의 mTLS가 흔들리는 거 아닌가 하는 걱정. 근데 몇 주 파보면서 그건 좀 오해였다.

리소스 관점: 이건 진짜 크다

sidecar 방식 클러스터에서 Envoy가 잡아먹는 리소스가 얼마나 되는지 실제 측정해봤다. 노드 60대, Pod 약 1800개 (그중 mesh에 들어간 게 1200개쯤). Envoy 사이드카 하나당 대략 memory 60~80MB, CPU 0.05~0.15 vCPU 정도로 잡혀 있었다. 곱하면 memory 100GB 가까이가 그냥 사이드카에 쓰인다. CPU도 100 vCPU 넘게 흘러가고.

Ambient는 ztunnel이 DaemonSet으로 노드당 하나만 뜬다. ztunnel 하나가 30~60MB, CPU 0.06 vCPU 수준. 노드 60대면 memory 4GB, CPU 4 vCPU. 자릿수가 다르다.

물론 L7 기능이 필요한 서비스는 waypoint proxy를 따로 띄워야 한다. 그거 감안해도 우리 케이스에선 sidecar 방식의 30% 정도 리소스로 끝났다. 벤치마크 자료들에서 얘기하는 70% 절감이 대충 맞는 수준이다. 자원 아낀 게 문제가 아니라, 새 노드 추가할 때마다 리소스 요청량 계산이 훨씬 단순해진다는 게 실제 운영에서 더 크게 느껴졌다.

배포/롤아웃 관점: ambient가 압도적으로 편하다

이게 사실 리소스보다 더 크리티컬한 차이였다. sidecar는 namespace에 라벨을 붙여도 기존 Pod은 재시작 전까지 mesh에 안 들어간다. kubectl rollout restart deployment 를 전 서비스에 돌려야 한다는 얘기. 이거 롤아웃 계획을 잡는 것부터 팀 캘린더에 올라간다. 우리는 그거 한 번 하는 데 하루 통째로 잡곤 했다.

Ambient는 그냥 라벨만 붙이면 된다. Pod 재시작 없이 트래픽 인터셉트가 몇 초 안에 시작된다. 뗄 때도 마찬가지. 처음 이걸 검증할 때 "정말 이렇게 간단해?" 싶어서 세 번쯤 확인했다.

운영자 입장에선 이게 진짜 크다. 서비스 개발팀에 "재기동 필요합니다"라고 말할 일이 없어진다는 것. 이 한 가지만 봐도 신규 클러스터는 ambient로 가는 게 맞다고 판단했다.

그럼 왜 기존 클러스터는 안 옮기나

여기서부터가 진짜 고민이었다. 세 가지 이유가 있다.

첫째, 우리 sidecar 설정에 붙어 있는 EnvoyFilter가 30개 넘는다. 로깅 커스텀, 헤더 조작, 특정 서비스만 대상으로 하는 retry 정책 등등. Ambient에서 이걸 다 waypoint로 옮기는 게 가능은 한데, 검증 공수가 크다. 기존 트래픽에 문제 생기면 그게 다 매출이랑 직결되는 곳이라 리스크 감내가 안 된다.

둘째, VirtualService 기반 라우팅이 ambient에서는 아직 alpha다. Gateway API가 정공법인데, 우리는 아직 Gateway API로 완전히 넘어가지 않았다. 게이트웨이 리소스 다시 그리는 작업이 별건이다.

셋째, multi-cluster mesh를 쓰고 있는데 ambient의 multi-cluster 지원은 릴리즈별로 제약이 좀 있다. 우리 케이스에는 아직 완전히 걸리는 지점이 있어서 검증이 더 필요하다.

이 세 개 중 첫 번째가 제일 크다. "지금 잘 굴러가는 걸 굳이 왜 건드려" 정신이 결국 이겼다.

그래서 지금 우리 팀 상황

새로 붙는 4번째 클러스터는 ambient로 세팅 중이다. Gateway API를 전제로 처음부터 설계했다. EnvoyFilter는 waypoint에 최소한만 넣고, 나머지는 애플리케이션 레벨에서 처리하도록 방향을 잡았다. 이렇게 하면 나중에 다른 클러스터를 ambient로 옮길 때도 표준화된 참고 사례가 생긴다.

기존 3개는 6개월 정도 ambient를 4번 클러스터에서 굴려보면서 우리가 걸릴 만한 케이스를 다 밟아본 뒤에 마이그레이션을 검토하기로 했다. 아마 EnvoyFilter를 얼마나 waypoint로 우아하게 옮길 수 있느냐가 결정적 요인이 될 것 같다.

한 가지 재밌었던 건, 팀 내부에서도 의견이 갈렸다는 것. "어차피 옮길 거면 지금 다 옮기자"는 쪽과 "쪼개서 리스크 관리하자"는 쪽. 결국 후자가 이겼는데, 나도 처음엔 전자였다. 근데 EnvoyFilter 하나하나 매핑해보다가 마음이 바뀌었다. 이게 그렇게 단순한 대체가 아니더라.

정리하자면

Ambient가 더 좋냐고 물으면 그렇다고 답한다. 리소스도 덜 먹고 롤아웃도 편하다. 근데 "지금 당장 옮겨야 하냐"에 대한 답은 상황마다 다르다. 특히 EnvoyFilter 많이 쓰고 있으면 급하게 옮길 필요 없다. VirtualService가 stable로 올라오는 것도 기다려볼 만하고.

혹시 요즘 ambient로 넘긴 팀 있으면 어떤 부분에서 걸렸는지 궁금하다. 우리가 아직 못 밟은 지뢰들이 분명 있을 텐데.