06 · Istio 히스토그램 3종이 시리즈의 44%: vmstorage 인덱스 줄이기
약 1년 보관 · 복제 2벌·시리즈 비중은 실측 · 용량 효과는 적용 전 계산
용량을 차지하는 것은 샘플보다 인덱스
현재 vmstorage 디스크의 약 3분의 2는 인덱스입니다(실측). 하루 증가량도 인덱스가 데이터의 두 배쯤 됩니다. 지금 증가 속도로 약 1년의 보관 기간을 채우면 장기 필요량은 증설을 마친 볼륨 운영 한도의 약 130%입니다(계산).
용량 계산에서는 인덱스 증가량이 시리즈 수에 비례한다고 봤습니다. 수집 주기를 늘리거나 오래된 샘플을 성기게 집계해도 라벨 조합이 같으면 시리즈 수는 그대로여서, 인덱스를 줄이는 방법이 되지 않습니다. 05 vmagent AZ 분할에서 바꾼 수집 응답의 전송 경로도 저장량에는 영향을 주지 않습니다.
증설 뒤에도 운영 한도를 넘을 것으로 계산되어, 시리즈를 많이 만드는 메트릭과 이를 읽는 쿼리를 함께 조사했습니다. 현재 계획은 Istio 크기 히스토그램 2종을 집계하고 월 파티션 인덱스를 쓰는 버전으로 업그레이드하는 것입니다. 감축과 업그레이드는 아직 적용 전이며, 이하의 용량 효과는 계산과 추정입니다.
자동화가 읽는 Istio 메트릭, 현재는 전부 수집
워크로드는 Istio 사이드카를 거쳐 통신하고, vmagent는 사이드카가 내보내는 메트릭을 수집합니다. KEDA 스케일링 트리거는 요청 수와 지연 시간을 읽습니다. Argo Rollouts의 배포 분석 식은 지연 분위수를 읽습니다.
현재는 Istio 메트릭을 수집 단계에서 drop하지 않고 전부 저장합니다. Istio 사이드카는 scrape 응답 바이트의 약 80%를 차지합니다. 저장할 시리즈를 줄이려면 KEDA와 Argo Rollouts가 사용하는 정보부터 구분해야 합니다.
하루 고유 시리즈의 44%를 차지하는 히스토그램 3종
하루 동안 한 번이라도 나타난 고유 시리즈를 메트릭 이름별로 세었습니다. Istio 히스토그램 3종의 비중은 43.5%였습니다(실측). 살아 있는 시리즈가 가장 많은 시점을 기준으로 하면 47%입니다.
| 메트릭 | 하루 고유 시리즈 비중 |
|---|---|
istio_request_bytes_bucket | 약 14.5% |
istio_response_bytes_bucket | 약 14.5% |
istio_request_duration_milliseconds_bucket | 약 14.5% |
| 3종 합 | 43.5% |
세 메트릭은 라벨 구성이 같아 비중도 같습니다. le를 제외한 라벨 조합과 버킷 20개가 모두 동일합니다.
스케일링에 쓰는 istio_requests_total의 비중은 가장 많은 시점의 활성 시리즈 가운데 약 0.8%입니다. 히스토그램이 아니므로 버킷 배수가 붙지 않습니다.
크기 히스토그램은 조회되지 않았고, 지연은 워크로드 단위로 조회
쿼리 로그를 5일 동안 모으고, 대시보드·알림 규칙·KEDA 트리거·배포 분석 식의 원문도 검색했습니다.
| 메트릭 | 읽는 곳 | 파드 라벨 사용 |
|---|---|---|
| 요청·응답 크기 히스토그램 2종 | 없음. 닷새 동안 조회 0건 | – |
| 지연 히스토그램 | KEDA 지연 트리거, Argo Rollouts 분석 식, 대시보드 패널 | 자동화와 대시보드에서는 없음. 장애 진단 쿼리 2건만 사용 |
크기 히스토그램 2종은 하루 고유 시리즈의 29%를 차지하지만 읽는 곳을 찾지 못했습니다. 지연 히스토그램을 읽는 자동화와 대시보드의 식은 모두 워크로드 단위로 집계합니다. 파드별 지연 분위수를 조회한 경우는 장애 진단 쿼리 2건이 전부였습니다.
관측 기간은 닷새였습니다. 이 기간의 쿼리 로그와 설정 원문에서 참조를 찾지 못했더라도, 그보다 드물게 쓰는 쿼리까지 없다고 단정할 수는 없습니다.
시리즈 하나에 붙는 라벨 34개
지연 히스토그램의 시리즈 하나에서 라벨 구성을 확인했습니다. 아래 예시에서는 서비스와 네임스페이스 이름을 바꿨습니다.
{
"__name__": "istio_request_duration_milliseconds_bucket",
"pod": "order-api-7c9d8f6b5-x2k4q",
"pod_name": "order-api-7c9d8f6b5-x2k4q",
"instance": "10.0.12.34:15090",
"le": "250",
"response_code": "200",
"response_flags": "-",
"reporter": "destination",
"request_protocol": "http",
"connection_security_policy": "mutual_tls",
"source_workload": "ingress-gateway",
"source_workload_namespace": "istio-system",
"source_app": "ingress-gateway",
"source_canonical_service": "ingress-gateway",
"source_canonical_revision": "latest",
"source_principal": "spiffe://cluster.local/ns/istio-system/sa/ingress-gateway",
"source_cluster": "Kubernetes",
"destination_workload": "order-api",
"destination_workload_namespace": "shop",
"destination_app": "order-api",
"destination_service": "order-api.shop.svc.cluster.local",
"destination_service_name": "order-api",
"destination_service_namespace": "shop",
"destination_canonical_service": "order-api",
"destination_canonical_revision": "latest",
"destination_principal": "spiffe://cluster.local/ns/shop/sa/order-api",
"destination_cluster": "Kubernetes",
"namespace": "shop",
"pod_app": "order-api",
"pod_instance": "shop",
"cluster": "workload",
"job": "istio-dataplane",
"prometheus": "monitoring/vmagent",
"endpoint": "http-envoy-prom",
"container": "istio-proxy"
}파드 신원과 버킷처럼 조합 수를 늘리는 라벨이 있고, 다른 라벨에 따라 값이 정해지거나 상수인 라벨도 있습니다. 아래 표는 각 묶음이 시리즈 수에 주는 영향을 비교한 것입니다.
| 묶음 | 라벨 수 | 시리즈 수에 주는 영향 |
|---|---|---|
파드 신원: pod, pod_name, instance | 3 | 하루 약 94배 |
요청 차원: le, response_code, response_flags 등 | 6 | le 20배, 응답 코드 약 1.9배 |
워크로드·서비스: source_*, destination_*, namespace 등 | 20 | 서비스 쌍을 정함. 라벨 하나를 빼도 줄지 않음 |
상수: cluster, job, endpoint 등 | 5 | 없음 |
크기 히스토그램 2종도 라벨 구조는 같고, __name__과 le 값만 다릅니다.
파드 교체와 버킷이 늘리는 시리즈
히스토그램 한 종의 하루 고유 시리즈 수는 다음 네 값의 곱으로 풀립니다(실측 산술).
| 곱해지는 것 | 배수 | 뜻 |
|---|---|---|
| 서비스 쌍 | 수백 | source·destination 워크로드와 서비스의 조합 |
| 응답 코드·플래그 | 약 2.5 | 한 쌍에서 나타나는 응답 조합 수 |
le 버킷 | 20 | 지연 또는 크기 구간 |
| 파드 | 약 94 | 같은 조합이 하루 동안 갈라지는 파드 수 |
같은 조합이 파드별로 나뉘는 배수가 큽니다. 실행 중인 파드 수에 배포와 스케일링으로 하루에 약 3.7번 교체되는 효과가 곱해집니다. 파드가 바뀔 때마다 같은 서비스 쌍·응답 코드·버킷 조합이 새 시리즈로 등록됩니다.
라벨을 하나씩 빼 보아도 파드 신원이 시리즈 수를 늘린다는 점을 확인할 수 있습니다. 파드 신원 라벨과 le, 응답 코드를 제외한 나머지 라벨은 하나를 빼도 시리즈 수가 줄지 않습니다. 다른 라벨에 따라 값이 정해지는 종속 라벨이기 때문입니다.
이 조사에서 라벨을 하나씩 제외해 보았을 때 시리즈 수가 줄어든 것은 파드 신원 라벨과 le, 응답 코드(약 1.9배)였습니다.
파드 차원을 접는 방법과 감축 효과
vmagent의 스트림 집계로, 나머지 라벨 조합이 같은 파드들을 ReplicaSet 단위로 묶으려고 합니다. 히스토그램은 계속 수집하면서 개별 파드를 구분하던 라벨 3개를 바꾸는 방법입니다.
// 지금: 라벨 34개. 같은 조합이 하루 동안 파드 약 94개로 갈라짐
{ "pod": "order-api-7c9d8f6b5-x2k4q", "pod_name": "order-api-7c9d8f6b5-x2k4q", "instance": "10.0.12.34:15090",
"…": "나머지 31개" }
// 집계 뒤: 라벨 32개. 같은 조합이 ReplicaSet 하나로 묶임
{ "pod": "order-api-7c9d8f6b5-",
"…": "나머지 31개 그대로" }pod를 ReplicaSet 접두사로 바꾸고 pod_name과 instance를 제거합니다. 배포 분석 식에 필요한 리비전 구분은 남깁니다.
source_*·destination_* 라벨도 유지하므로 어느 워크로드가 어느 워크로드를 호출했는지 볼 수 있습니다. 없어지는 정보는 그 쌍 안에서 어느 파드가 처리했는지입니다.
파드별 요청 수와 5xx는 istio_requests_total에서, 파드별 평균 지연은 _sum·_count에서 계속 볼 수 있습니다. 파드별 지연 분위수는 볼 수 없게 됩니다.
집계 범위에 따른 감소율은 다음과 같이 계산했습니다.
| 범위 | 3종 시리즈 | 하루 고유 시리즈 전체 | 인덱스 증가량 |
|---|---|---|---|
| 크기 2종만 집계 | – | 약 29% 감소 | 약 25% 감소 |
| 3종 모두 집계 | 98% 감소 | 43.5% → 0.7% | 약 40% 감소 |
인덱스 증가량은 시리즈 수에 비례한다고 보고 추정했습니다. 3종을 모두 접으면 장기 필요량은 37~43% 줄어듭니다(추정).
먼저 적용할 범위는 크기 2종
조회가 확인되지 않은 크기 2종의 집계를 먼저 적용하려고 하며, 지금 검증 클러스터에서 확인 중입니다. KEDA와 배포 분석이 읽는 지연 히스토그램의 집계는 보류했습니다. 집계 전후의 분위수를 일정 기간 나란히 비교한 뒤 전환할 계획입니다.
집계하면 vmagent가 입력을 메모리에 유지해야 하므로 CPU와 메모리를 더 씁니다. 새 시리즈 유입은 적용 즉시 줄지만, 이미 쌓인 인덱스는 다음 회전 때 지워집니다. 저장소의 인덱스가 바로 줄어드는 것은 아닙니다.
AZ 분할과 함께 사용하려면 집계 키도 구분해야 합니다. agent 두 대가 같은 키로 각자의 부분 합을 보내면 저장소의 중복 제거가 하나만 남겨 값이 틀립니다. 각 결과가 서로 다른 시리즈로 저장되도록 agent마다 구분 라벨을 붙여 구성했습니다.
전체 수집 대상의 감축 상한 계산
실제 적용 범위를 정하는 것과 별도로, Istio를 포함한 모든 수집 대상에서 파드 신원 라벨을 제외한 조합을 다시 세었습니다. 아래 값은 수집 설정을 바꾼 뒤의 감소율이 아니라, 측정한 하루 고유 시리즈를 재집계한 결과입니다.
| 수집 대상 | 하루 고유 시리즈 중 비중 | 접은 뒤 남는 비율 |
|---|---|---|
| Istio 사이드카 | 약 66% | 1.1% |
| cAdvisor | 약 15% | 25.5% |
| node-exporter | 약 9% | 16.0% |
| kube-state-metrics | 약 4% | 7.4% |
| probes | 약 3% | 33.1% |
| kubelet | 약 3% | 97.1% |
| 전체 | 100% | 10.0% |
이렇게 재집계하면 전체 하루 고유 시리즈의 약 90%가 줄어듭니다. Istio는 파드 신원을 구분하지 않았을 때 1.1%만 남았습니다. 이 관측에서는 파드 교체가 고유 시리즈를 늘리는 큰 요인이었습니다.
cAdvisor와 node-exporter는 노드가 교체될 때도 새 시리즈가 생겨 파드 신원 라벨만 접으면 감소 폭이 작습니다. kubelet 메트릭에는 파드 라벨이 거의 없어 효과가 없습니다.
같은 비율이 유지된다고 가정하면 수집하는 시리즈를 두 배로 늘려도 하루 고유 시리즈는 지금의 20%이며, 원래보다 80% 적습니다. 이는 감축 가능 범위를 가늠하는 계산입니다.
10.0%만 남기는 계산은 조사한 범위에서 가능한 감축 효과의 상한입니다. Istio 밖의 수집 대상은 장애 진단에 파드·노드 라벨이 필요해 원본을 유지하기로 했습니다. 아래 적용 계획에는 Istio 히스토그램만 포함합니다.
월 파티션 인덱스로 업그레이드할 때의 조건
지금 쓰는 버전은 보관 기간마다 인덱스를 통째로 새로 만들고, 이전 세대를 한 주기 더 보관합니다. 인덱스가 최대 보관 기간의 두 배만큼 쌓이는 방식입니다. 회전 직전의 최고 시점에는 옛 세대가 장기 필요량의 약 38%를 차지합니다.
이후 버전은 인덱스를 월 단위 파티션으로 나눕니다. 지난달 인덱스가 데이터와 같은 보관 기간에 맞춰 지워져 두 세대가 겹치는 구간이 없어집니다. 업그레이드할 때는 다음 조건을 확인해야 합니다.
- 업그레이드 전에 쌓인 옛 세대는 다음 회전까지 유지됩니다. 따라서 첫 최고점은 버전을 올려도 거의 줄지 않으며, 시리즈를 일찍 줄여야 낮출 수 있습니다.
- 회전 시각에 vmstorage가 내려가 있으면 해당 샤드의 회전이 한 주기 밀립니다. 회전일 전후에는 재시작을 피합니다.
- 새 버전에서 되돌리면 그 기간에 만든 시리즈가 조회에서 빠집니다. 되돌리기 리허설을 먼저 진행합니다.
업그레이드와 2종 집계로 확보할 용량
앞의 효과 표는 시리즈와 인덱스 증가량의 감소율을 비교했습니다. 아래 표는 감축과 업그레이드를 조합한 뒤의 장기 필요량을 증설을 마친 볼륨 운영 한도와 비교한 값입니다(계산).
| 구성 | 장기 필요량(볼륨 한도 대비) |
|---|---|
| 지금 그대로 | 약 130% |
| 크기 히스토그램 2종 집계만 | 약 100% |
| 버전 업그레이드만 | 약 81% |
| 업그레이드 + 2종 집계 | 약 63% |
| 조회되지 않는 메트릭 drop과 지연 히스토그램 집계까지 | 35~40% |
우선 업그레이드와 2종 집계까지 진행합니다. 이 조합만으로 용량 조건을 맞출 수 있어, 조회되지 않는 메트릭의 drop은 보류했습니다.
앞서 조사한 같은 관측에서 하루 고유 시리즈의 약 66%는 한 번도 조회되지 않은 메트릭에 속했습니다. 관측 창을 이틀에서 닷새로 늘려도 이 비율은 1%p도 줄지 않았습니다.
그중 참조와 위험 신호가 모두 없는 약 650종을 drop 후보로 골랐습니다. 하루 고유 시리즈의 약 16%에 해당하며, 후보의 4분의 3가량은 Envoy가 내보내는 내부 통계입니다.
표의 마지막 줄에 해당하는 추가 감축은 인덱스 증가가 기대보다 크거나 디스크 사용률 예측이 한도에 가까워질 때 재개합니다.
2단 장기 보관을 보류한 이유
원본은 석 달만 두고, 이후에는 5분 단위로 집계한 사본을 약 1년 보관하는 2단 구성도 검토했습니다. 파드·노드 라벨을 빼면 필요량이 지금의 4분의 1 수준으로 내려간다는 계산이 나왔습니다.
라벨을 유지하면 같은 수의 시리즈가 장기 사본에 한 벌 더 생겨, 모델상 필요량이 지금보다 오히려 크게 늘었습니다. 인덱스는 샘플 간격과 무관하므로 이 구성에서 용량을 줄이려면 라벨을 제거해야 합니다.
이 안은 석 달이 지난 원본을 조회하지 않는다는 전제에 따릅니다. 관측 창을 늘렸을 때 그보다 훨씬 긴 구간을 조회한 쿼리가 몇 건 나와, 지금은 보류하고 업그레이드 뒤에 다시 판단하기로 했습니다.
일부 지표를 15초로 수집하려면
요청 수와 CPU·메모리처럼 판단에 직접 쓰는 지표를 15초로 수집하는 방안을 설계 중입니다. 이 지표들은 가장 많은 시점의 활성 시리즈 가운데 약 3.5%입니다. 용량 증가 속도를 낮춰 확보한 여유를 필요한 지표의 해상도에 쓸 계획입니다.
수집 주기는 메트릭이 아닌 수집 대상 단위로 정해집니다. Istio 사이드카의 수집 주기를 15초로 바꾸면 응답에 담긴 모든 시리즈를 15초마다 수집합니다. 일부 지표만 15초로 남기려면 먼저 히스토그램을 30초 집계로 바꿔야 합니다.
샘플이 깎이지 않도록 저장소의 중복 제거 간격도 15초로 내려야 합니다. AZ 분할도 먼저 끝내야 합니다. 분할 전에 수집 주기를 줄이면 두 배로 늘어난 scrape 응답이 그대로 AZ를 넘습니다.
적용 순서와 검증
| 순서 | 작업 | 상태 |
|---|---|---|
| 1 | vmagent AZ 분할 | 작은 클러스터에 적용, 가장 큰 클러스터는 준비 중 (05) |
| 2 | vmstorage 볼륨 증설 | 크기 결정 대기 |
| 3 | Istio 크기 히스토그램 2종 스트림 집계 | 검증 클러스터에서 확인 중 |
| 4 | 월 파티션 인덱스 버전으로 업그레이드 | 검토 완료, 되돌리기 리허설 예정 |
| 5 | 일부 지표 15초 수집 | 설계 |
| 보류 | 지연 히스토그램 집계, 조회되지 않는 메트릭 drop, 2단 장기 보관 | 조건이 맞으면 재개 |
볼륨 증설, 시리즈 감축, AZ 분할, 버전 업그레이드는 서로 다른 날에 적용합니다. 같은 날 겹치면 문제가 생겼을 때 원인을 구분할 수 없습니다.
적용 뒤에는 시리즈 수, 인덱스 증가량, 디스크 사용률을 다시 측정합니다. 이 글의 계산값도 그 실측 결과로 갱신할 예정입니다.
관련 문서: vmagent AZ 분할 · 스케일링·용량 기준치 · 실전 01 카디널리티