레드햇이 이스트리오(Istio) 1.20을 출시했을 때, 웹어셈블리 플러그인, 개선된 텔레메트리, 그리고 오랫동안 약속되었던 멀티 클러스터 페더레이션 같은 화려한 신기능들이 화제였습니다. 쿠버네티스(Kubernetes)에서 마이크로서비스를 운영하는 사람이라면, 특히 레드햇 생태계에서 오픈시프트(OpenShift)를 사용하는 이들에게는 이번이 다음 도약이 될 것이라 기대했습니다. 더 강력한 성능, 더 나은 제어, 더 많은… 모든 것을 약속했으니까요. 소규모 배포에는 아마 그랬을 겁니다. 하지만 이걸 진짜 ‘최고 성능’으로 끌어올려야 한다면 어떻게 될까요? 여기서 이야기가 흥미로워지고, 동시에 비싸집니다.
이스트리오가 좋냐 나쁘냐의 문제가 아닙니다. 이건 쿠버네티스 도구함의 표준 도구이고, 테크 콘퍼런스에서 정전기처럼 어디에나 존재하죠. 언제나처럼 진짜 문제는, 실제로 춤추기 시작할 때 누가 비용을 지불하느냐는 겁니다. 그리고 이스트리오 1.20과 오픈시프트에서는 그 청구서가 예상보다 훨씬 더 높고 빠르게 올라가는 것 같습니다.
성능의 대가
다들 마케팅 자료는 봤잖아요. 기업들은 최신 릴리스를 대단한 발전이라고 홍보하기 좋아하죠. 하지만 수천 개의 파드를 관리할 때는 사소한 비효율성조차도 재앙적인 오버헤드로 쌓입니다. 그리고 이번 벤치마크 연구가 바로 이 점을 파고들었습니다. 레드햇 오픈시프트 4.14에서 이스트리오 1.20.1을 대상으로 말이죠. AWS에서 표준적인 8개 노드 클러스터를 구성하고, Nginx Plus 웹 서비스를 올린 뒤, 파드 1천 개에서 1만 개까지 밀어붙였을 때 어떤 일이 일어나는지 살펴본 겁니다. 결과는요? 매끄럽고 비용 효율적인 주행을 기대했던 이들에게는 좋지 않습니다.
결과를 보면, 이스트리오 1.20의 주요 기능들—Wasm 플러그인 검증이나 더 강력한 텔레메트리 파이프라인 같은 것들—이 공짜로 제공되지 않는다는 것을 알 수 있습니다. 파드 1천 개 수준에서는 컨트롤 플레인(istiod)이 약 2 vCPU와 6GB RAM으로 작동했습니다. 관리 가능하죠? 이제 1만 개 파드로 넘어가 봅시다. 갑자기 istiod는 8 vCPU와 무려 24GB RAM을 요구합니다. 기본 대비 CPU 사용량은 300%, 메모리 사용량은 400% 증가한 셈입니다. 이럴수가, 같은 규모에서 이스트리오 1.19보다 두 배나 많은 리소스를 소모합니다. 점진적인 개선이라더니만요.
문제는 컨트롤 플레인만이 아닙니다. 모든 파드는 더 덩치 큰 Envoy 사이드카를 달고 다녀야 합니다. 이스트리오 1.20은 이전 버전보다 사이드카당 메모리 15%, CPU 8%를 더 잡아먹습니다. 파드 1천 개에서는 클러스터에 추가로 18GB의 RAM이 더 투입됩니다. 이걸 1만 개 파드로 확장하면, 사이드카만 지원하기 위해 인프라 전반에 걸쳐 추가 180GB 메모리와 놀라운 800개의 추가 vCPU 코어가 필요하게 됩니다. 아래 표가 이 현실을 명확히 보여줍니다:
| Scale (Pods) | Avg Sidecar Memory (MB) | Avg Sidecar CPU (vCPU) | Total Sidecar Resource Cost (Relative to No Istio) |
|---|---|---|---|
| 1,000 | 138 | 0.14 | 1.2x |
| 5,000 | 141 | 0.16 | 1.8x |
| 10,000 | 145 | 0.18 | 2.3x |
이건 그냥 약간의 증가가 아닙니다. 복잡한 트래픽 정책을 적용하기 전에 이스트리오를 실행하는 데 필요한 리소스 발자국 자체가 근본적으로 늘어난 겁니다.
지연 시간의 느린 행진
지연 시간은 분산 시스템의 골칫거리입니다. 단 몇 밀리초 차이가 반응 좋은 애플리케이션과 느릿한 애플리케이션을 가릅니다. 낮은 트래픽 수준(동시 요청 100개)에서는 이스트리오 1.20이 p99 지연 시간에 미미한 3ms만 추가합니다. 하지만 이건 최상의 시나리오입니다. 동시 요청 5,000개로 밀어붙이면, 벤치마크 결과는 서비스 메쉬가 없는 기본 상태 대비 p99 지연 시간이 상당한 22%까지 부풀어 오르는 것을 보여줍니다. 더 나쁜 건, 같은 부하에서 이스트리오 1.19 대비 12%나 증가했다는 점입니다. 새로운 기본 텔레메트리 처리가 멋진 텔레메트리 기능을 사용하든 안 하든 모든 요청에 오버헤드를 추가하는 모양입니다. 마치 고성능 스포츠카를 샀는데 기본 모델에 낙하산이 영구적으로 장착되어 있는 걸 발견한 기분이죠.
운영상의 골치 아픔
단순한 리소스 소비와 지연 시간 외에도 운영 비용이 있습니다. 설정 전파(Configuration propagation)를 기억하시나요? 라우팅 규칙 업데이트 같은 변경 사항이 모든 파드에 실제로 적용되는 데 걸리는 시간입니다. 이스트리오 1.20에서는 이 시간이 파드 1천 개일 때의 빠른 2초에서 파드 1만 개일 때는 빙하기 같은 45초로 늘어납니다. 업그레이드는 어떻고요? 짧은 점검 시간 안에 끝나는 걸 기대하지 마세요. 파드 5천 개 클러스터의 업그레이드는 이스트리오 1.20에서 10.5분 걸렸는데, 1.19에서는 8분 걸렸습니다. 대규모 배포의 경우, 이전에는 필요 없었을 유지보수 기간을 계획해야 한다는 의미이며, 운영상의 마찰이 한층 더해집니다.
그리고 텔레메트리 자체도 문제입니다. 이스트리오 1.20은 기본적으로 12개의 새 메트릭을 내보냅니다. 물론 좋긴 하지만, 파드 5천 개 이상 클러스터에서는 프로메테우스(Prometheus) 텔레메트리 볼륨을 무려 40%나 늘릴 수 있습니다. 많은 운영팀처럼 30일치 메트릭을 보관한다면, 스토리지 비용이 약 35% 증가할 것입니다. 그리고 실제로 그 새로운 Wasm 플러그인을 사용하기로 결정한다면? 플러그인 당 추가 10ms의 지연 시간과 5% 더 많은 사이드카 메모리를 감당해야 합니다. ‘있으면 좋은’ 기능들이 조용히 인프라 비용을 부풀리는 연쇄 반응입니다.
“이스트리오 1.20은 기본적으로 12개의 새로운 기본 메트릭을 활성화하여, 5,000개 이상의 파드를 가진 클러스터의 프로메테우스 텔레메트리 볼륨을 40% 증가시킵니다.”
앞으로 나아갈 길 (만약 꼭 그래야 한다면)
이 글이 단순히 파티에 찬물을 끼얹으려는 건 아닙니다. 이미 오픈시프트에서 이스트리오 경로를 사용하기로 한 이들을 위한 몇 가지 현명한 조언도 제공합니다. 사용하지 않는 기능 비활성화는 당연한 일입니다—Wasm 검증을 사용하지 않는다면 끄세요. istiod와 사이드카에 하드 리소스 제한을 설정하면 무분별한 리소스 소비를 막을 수 있습니다. 이스트리오 리비전을 사용하여 제로 다운타임 업그레이드를 하는 것은 표준적인 방법이지만 언급할 가치가 있습니다. 그리고 오픈시프트의 Node Tuning Operator로 워커 노드를 최적화하면 해당 Envoy 사이드카의 오버헤드를 줄일 수 있습니다. 소스에서 메트릭을 필터링하는 것도 텔레메트리 볼륨을 대폭 줄일 수 있습니다. 이들은 훌륭하고 실용적인 단계입니다.
하지만 제 경험상, 20년간 기술 트렌드의 흥망성쇠를 지켜봐 온 결과, 복잡한 시스템에서 기능 비대화의 필연적인 결과를 보고 있는 셈입니다. 이스트리오 1.20은 분명 더 많은 기능을 갖췄습니다. 하지만 증가된 복잡성과 기본 설정은 특정 지점을 넘어서 확장할 때 상당하고, 종종 숨겨진, 성능 및 비용 페널티를 동반합니다. 오픈소스의 ‘무료’라는 단어가 이러한 강력한 도구를 대규모로 효과적으로 실행하는 데 필요한 엔지니어링 시간과 인프라 비용까지 포함하는 것은 아니라는 점을 상기시켜 줍니다. 철저하게 벤치마킹하고 튜닝하지 않으면, 성능과 돈을 모두 놓치고 있을 가능성이 높습니다.
이것이 이스트리오의 종말일까요? 전혀 아닙니다. 여전히 많은 이들에게 사실상의 표준입니다. 하지만 대규모 오픈시프트 환경에 이를 배포할 계획이라면 심각한 경고 신호입니다. 고급 기능의 약속은 매력적이지만, 벤치마크 결과는 냉혹한 현실을 강조합니다: 이스트리오 1.20을 오픈시프트에서 확장하는 데 드는 비용은 처음 예상보다 훨씬 높을 수 있으며, 성능 저하와 예상치 못한 인프라 급증을 피하려면 신중한 계획과 적극적인 최적화가 필요합니다.
