Istio 모니터링, 서비스 메시 토폴로지로 마이크로서비스 의존성 한눈에 파악하기

마이크로서비스 아키텍처를 운영하다 보면 어느 순간 "우리 서비스가 정확히 어떻게 연결되어 있는지 아무도 모르는 상태"에 도달합니다. 처음에는 5개였던 서비스가 30개가 되고, 50개가 됩니다. 네임스페이스도 account, portal, platform, living, kids처럼 도메인별로 분리되며, 각 네임스페이스 안에서 또 여러 서비스가 서로를 호출합니다.

이런 환경에서 운영자가 가장 자주 마주치는 질문은 다음과 같습니다.

• "이 서비스를 누가 호출하고 있나? 함부로 내려도 되는가?"
• "결제 API에 장애가 났는데, 어떤 서비스들이 영향을 받는가?"
• "이 마이크로서비스 간의 호출이 의도한 경로가 맞는가?"
• "스테이징 환경의 서비스가 실수로 운영 환경 DB를 부르고 있지는 않은가?"

이 질문들의 공통점은 단순한 메트릭 숫자로는 답할 수 없다는 점입니다. 필요한 것은 서비스들 사이의 연결 관계를 한눈에 보여주는 지도입니다.

이번 글에서는 마이크로서비스 모니터링이 왜 일반적인 메트릭 대시보드만으로는 부족한지, 그리고 와탭(WhaTap)의 Istio 서비스 메시 대시보드가 이 문제를 어떻게 해결하는지 살펴봅니다.

‍

마이크로서비스 모니터링이 어려운 이유

1. 메트릭 숫자만으로는 '관계'가 보이지 않습니다

전통적인 모니터링 대시보드는 패널 단위로 구성됩니다. CPU 사용률, 요청 처리량, 응답 시간은 모두 개별 서비스의 상태를 보여주는 지표입니다. 문제는 마이크로서비스 환경에서 진짜 중요한 정보는 서비스 사이에 있다는 점입니다.

"결제 서비스의 응답 시간이 늘어났다."

이 문장만으로는 부족합니다. 진짜 알아야 할 것은 다음과 같습니다.

• 결제 서비스가 호출하는 인증 서비스의 응답 시간이 늘어났는가?
• 결제 서비스를 호출하는 주문 서비스도 함께 느려졌는가?
• 이 지연이 어느 호출 경로에서 시작되었는가?

이런 질문에 답하려면 메트릭 차트가 아닌 연결 그래프가 필요합니다.

2. Istio 자체 메트릭은 양이 많지만 정리되어 있지 않습니다

Istio는 4대 골든 시그널(4 Golden Signals: latency, traffic, errors, saturation) 기반의 풍부한 메트릭을 제공합니다. Envoy 사이드카가 모든 인바운드/아웃바운드 트래픽을 가로채면서 매우 상세한 데이터를 노출합니다.

문제는 이 데이터가 너무 세분화되어 있다는 점입니다. istio_requests_total, istio_request_duration_milliseconds, istio_request_bytes 등의 메트릭이 source/destination 서비스, 워크로드, 응답 코드 라벨까지 포함해 노출되므로 카디널리티가 폭증합니다.

이 데이터를 의미 있게 보려면 결국 PromQL을 통해 "어떤 서비스가 어떤 서비스를 부르는가"를 직접 조립해야 하는데, 이 작업이 만만치 않습니다.

sum by (source_workload, destination_workload) (
  rate(istio_requests_total[5m])
)

‍위 쿼리로 호출 관계의 일부는 볼 수 있지만, 이를 시각적인 그래프로 만들려면 결국 별도 도구가 필요합니다.

3. Kiali·Grafana 조합도 운영 부담이 큽니다

Istio 진영에서 가장 많이 쓰이는 조합은 Prometheus, Grafana, Kiali입니다. Kiali가 토폴로지 그래프를 그려주고, Grafana가 메트릭 차트를 보여주는 구조입니다.

훌륭한 조합이지만 운영 관점에서 보면 다음과 같은 부담이 있습니다.

• Prometheus 클러스터를 직접 운영해야 함(시계열 DB(TSDB), 고가용성(HA), 카디널리티 관리)
• Kiali, Grafana 각각의 업그레이드와 호환성 관리
• 인증·접근 제어를 도구마다 따로 설정
• 다중 클러스터 환경에서는 메트릭 페더레이션 추가 구성

특히 카디널리티 폭증은 Istio 환경에서 가장 자주 발생하는 비용 이슈입니다. Istio는 Envoy 네이티브 stats(envoy_cluster_*, envoy_listener_* 등 수천 개)는 기본적으로 최소한만 노출하지만, 그럼에도 istio_* 표준 메트릭의 라벨 조합(source/destination 워크로드 × 응답 코드 등)이 워낙 많아 별다른 필터링 없이 수집하면 메트릭 백엔드가 빠르게 포화됩니다. Istio 공식 문서도 "CPU·메모리 풋프린트를 줄이기 위해 기본적으로 최소한의 Envoy 통계만 기록하도록 설정되어 있다"고 명시합니다.

4. 다중 네임스페이스를 아우르는 통합 시야가 부족합니다

엔터프라이즈 환경에서는 네임스페이스가 도메인별·환경별로 분리되어 있습니다. account-stg, portal-stg, platform-stg, living-stg처럼 나뉩니다.

운영자가 정작 보고 싶은 것은 이들을 가로지르는 호출 관계입니다. 그런데 일반적인 대시보드는 네임스페이스 단위로 분리되어 있거나, 합쳐 보더라도 시각적으로 구분되지 않는 경우가 많습니다.

‍

와탭 Istio 서비스 메시 대시보드: 메트릭이 아니라 '지도'를 그립니다

와탭의 Istio 모니터링은 일반적인 메트릭 차트 대시보드와 본질적으로 다릅니다. 패널 형태의 그래프가 아니라, 마이크로서비스 간 호출 관계를 그래프로 시각화한 토폴로지 맵을 메인 화면으로 제공합니다.

한 화면으로 보는 전체 메시 구조

화면의 구성 요소를 하나씩 살펴보겠습니다.

• 삼각형(▲): 외부 진입점 또는 엣지 서비스(Ingress Gateway 등)
• 원형(●): 메시 내부 서비스 워크로드
• 색상: 녹색은 정상 트래픽 발생 중, 회색은 비활성

서비스 간 화살표로 연결되며, 화살표의 굵기는 트래픽량을 반영합니다. 각 엣지에는 운영자가 즉시 필요로 하는 3가지 지표가 라벨로 표시됩니다.

• TPS(Transactions Per Second): 초당 트랜잭션 수(트래픽 양)
• 응답 시간(ms): 호출의 평균 지연
• 대역폭(bps): 데이터 전송량

화면 상단의 Namespace 필터를 통해 여러 네임스페이스를 한 화면에 겹쳐서 표시할 수 있습니다. account-stg부터 portal-stg까지 도메인별로 분리된 네임스페이스를 모두 선택하면, 그 사이를 가로지르는 호출 관계가 같은 토폴로지 위에 그려집니다.

토폴로지 맵이 답해주는 질문들

이 화면 한 장이 다음 질문들에 즉시 답합니다.

대상 노드로 들어오는 화살표를 따라가면 됩니다. 호출하는 서비스의 이름, TPS, 응답 시간이 한눈에 표시됩니다.

장애가 발생한 노드에서 나가는 화살표와 들어오는 화살표를 따라가면, 영향이 전파될 가능성이 있는 서비스 집합이 즉시 식별됩니다.

토폴로지에 의도하지 않은 엣지(예: kids-stg의 서비스가 portal-stg의 DB를 직접 부르는 패턴)가 그려지면 즉시 시각적으로 발견됩니다. 텍스트 로그를 일일이 분석할 필요가 없습니다.

엣지의 굵기와 TPS 라벨이 핫 패스(hot path)를 즉시 보여줍니다. 용량 계획과 캐싱 전략의 출발점이 됩니다.

‍

실전 시나리오: '결제 API 응답 지연' 알람을 받았을 때

토폴로지 시각화의 가치를 구체적인 상황에서 살펴보겠습니다. 가상의 마이크로서비스 환경에서 "결제 API의 p95(상위 95백분위) 응답 시간이 2초를 초과했다"는 알람을 받았다고 가정합니다.

T+0초, 알람 수신. payment-service p95 latency exceeded 2s

T+30초, 토폴로지 맵에서 결제 서비스 노드 확인.payment-service 노드를 찾습니다. 들어오는 엣지 3개, 나가는 엣지 5개가 보입니다.

T+1분, 나가는 엣지의 응답 시간 라벨 스캔. 나가는 5개 엣지 중 auth-service로 향하는 엣지의 응답 시간 라벨이 1.8s로 비정상적으로 높습니다. 나머지는 모두 10ms 이하입니다.

T+1분 30초, 인증 서비스로 시야 이동. auth-service 노드를 살펴봅니다. 이 서비스가 호출하는 redis-cache로 향하는 엣지의 응답 시간이 1.5s로 늘어나 있습니다. 정상 시 5ms 수준이었던 호출입니다.

T+2분, 진단 완료. 진짜 원인은 결제 서비스가 아니라 Redis 캐시의 지연이었음이 토폴로지 한 장으로 명확해졌습니다. 결제 서비스에서 인증 서비스, Redis 캐시로 이어지는 호출 체인의 가장 깊은 지점이 진원지였던 것입니다.

직접 구축한 환경에서 같은 진단을 했다면 어땠을까요? Grafana에서 결제 서비스 대시보드를 열고, 인증 서비스 대시보드를 또 열고, Redis 메트릭을 또 열어가며 시간축을 맞춰 비교해야 했을 것입니다. 토폴로지 맵은 이 모든 비교를 공간 한 장에서 끝냅니다.

‍

와탭 Istio 서비스 메시 대시보드를 써야 하는 5가지 이유

1. 토폴로지 자체가 핵심 가치 - 메트릭 차트로는 대체 불가능

대부분의 모니터링 도구는 메트릭 차트를 핵심으로 제공하고, 토폴로지는 부가 기능으로 둡니다. 와탭 Istio 대시보드는 토폴로지를 메인 화면으로 제공합니다.

마이크로서비스 환경에서 가장 가치 있는 정보는 "이 서비스가 얼마나 빠른가"가 아니라 "이 서비스가 어떻게 연결되어 있는가"입니다. 그 정보가 메인 화면에 있다는 것은 운영자의 사고 흐름과 도구의 구조가 일치한다는 뜻입니다.

2. 다중 네임스페이스 통합 시야 - 도메인 경계를 가로지르는 가시성

엔터프라이즈 환경의 네임스페이스 분리 정책이 모니터링의 사각지대를 만들지 않도록, 와탭은 여러 네임스페이스를 한 화면에 겹쳐서 표시합니다.

account, portal, platform, kids, living 같은 도메인이 모두 한 토폴로지에 그려지면, 도메인 간 의도하지 않은 의존성이나 잘못된 호출 경로가 시각적으로 즉시 드러납니다. 이는 거버넌스와 아키텍처 검토에도 직접적인 가치를 제공합니다.

3. 엣지 라벨에 핵심 3대 지표가 압축되어 있습니다

각 호출 엣지에 표시되는 TPS, 응답 시간, 대역폭은 마이크로서비스 운영자가 호출 관계를 진단할 때 가장 자주 확인하는 지표입니다.

별도의 패널을 클릭해서 메트릭을 펼치지 않아도, 토폴로지 위에서 모든 호출 경로의 핵심 지표를 동시에 비교할 수 있습니다. 5초 안에 핫 패스와 슬로우 패스를 동시에 식별하는 것이 가능합니다.

4. 운영 부담 0 - Prometheus·Kiali·Grafana 조합이 필요 없습니다

Istio 모니터링의 표준 조합인 Prometheus, Kiali, Grafana는 강력하지만 셋업과 유지보수에 상당한 공수가 필요합니다.

• Prometheus 시계열 DB(TSDB)·고가용성(HA) 운영
• Kiali 업그레이드와 호환성 관리
• 메트릭 카디널리티 관리(Envoy 메트릭은 특히 폭증하기 쉬움)
• 멀티 클러스터일 경우 페더레이션·Thanos 추가 구성

와탭은 이 모든 인프라 운영을 SaaS 측에서 처리합니다. OpenAgent를 설치하고 Istio 메트릭 엔드포인트를 등록하면 위 화면이 즉시 동작합니다. 글로벌 SaaS 환경에서 검증된 확장성을 그대로 활용할 수 있습니다.

5. 와탭 컨테이너 모니터링과 같은 콘솔에서 동작

화면 URL(/cpm/4/openmx/plugin/istio?...)에서 짐작할 수 있듯, 이 Istio 대시보드는 와탭 컨테이너 모니터링의 일부로 통합되어 있습니다.

같은 콘솔 안에서 컨테이너 맵, Pod 메트릭, Istio 토폴로지로 자연스럽게 이동할 수 있다는 의미입니다. 토폴로지에서 이상이 감지되면, 해당 서비스를 호스팅하는 Pod의 CPU·메모리 메트릭과 컨테이너 로그까지 한 콘솔에서 검증할 수 있습니다. 도구 전환 비용이 0입니다.

‍

직접 구축 vs 와탭 Istio 서비스 메시 대시보드

‍

결론: 마이크로서비스 시대의 모니터링은 '지도'여야 합니다

서비스 수가 적었던 시절에는 개별 서비스의 상태를 차트로 보는 것으로 충분했습니다. 하지만 마이크로서비스가 수십 개를 넘어가는 순간부터, 진짜 가치 있는 정보는 서비스들 사이의 관계 안에 있습니다.

와탭 Istio 서비스 메시 대시보드는 이 관계를 메인 화면의 지도로 제공합니다. 메트릭 패널을 여러 개 펼쳐서 시간축을 맞추는 작업 대신, 한 장의 토폴로지 위에서 호출 경로를 따라가며 진단할 수 있습니다.

운영자의 사고 흐름이 "차트를 본다 → 차트를 비교한다 → 가설을 세운다"에서 "지도를 본다 → 경로를 따라간다 → 원인을 찾는다"로 바뀝니다. 마이크로서비스 시대의 모니터링은 상태를 나열하는 계기판이 아니라, 관계를 따라 원인까지 안내하는 지도여야 합니다.

15일 무료 체험으로 Istio 서비스 메시 대시보드를 직접 확인해보세요.
와탭 15일 무료 체험하기

‍‍

함께 보면 좋은 자료

• 와탭 쿠버네티스 모니터링
• 와탭 OpenMetrics 제품 페이지
• Istio Observability 공식 문서