RCA 2026.07.22 4 min read

3노드 Agent Fleet를 1시간·5시간 검증하며 본 것

한 번의 수집 성공이 아니라 장시간 안정성을 보기 위해 3노드 Agent Fleet를 1시간과 5시간 반복 검증하고 자원 추세·수집 품질·spool 상태를 비교했습니다.

SeongwookBAE

한 번 성공한 Agent가 5시간 뒤에도 정상인지는 별개의 문제다

Agent E2E가 한 번 통과한 뒤에는 장시간 실행에서만 보이는 문제가 남았다.

그래서 단일 성공 여부가 아니라 시간에 따른 Agent 상태를 보는 Operational Burn-in을 만들었다.

Profile	반복	간격	목적
smoke	3	1초	설치와 계약 확인
standard	60	60초	1시간 기준선
extended	300	60초	5시간 장기 표본
production	1,440	60초	24시간 별도 검증

일반 CI에는 smoke만 넣고 standard와 extended는 승인된 별도 Workflow로 분리했다. 개발 피드백 시간을 늘리지 않으면서 장기 결과를 독립 artifact로 남기기 위해서다.

Ready 상태의 DaemonSet Pod 내부에서 고정된 read-only 관측 코드만 실행했다.

사용자 입력 shell이나 환경 변수, spool 본문은 실행하거나 artifact에 남기지 않는다.

Python 런타임과 Collector cache는 초기 워밍업 동안 RSS가 증가할 수 있다. 시작과 종료 값만 비교하면 정상 워밍업을 누수로 오판한다.

장시간 Profile에서는 앞 50%를 warm-up으로 제외한 뒤 다음 값을 계산했다.

전체 증가량 Gate도 함께 유지했다. 초기 급증과 후반 지속 상승을 다른 방식으로 잡기 위해서다.

1 control-plane과 2 worker로 Kind Cluster를 만들고 Agent 3개를 같은 반복 구간에서 병렬 관측했다. Pod 이름은 artifact에 저장하지 않고 run별 salt를 적용한 HMAC 기반 target_id로 바꿨다.

1시간 Standard 결과는 다음과 같았다.

5시간 Extended에서는 다음 결과를 기록했다.

Standard와 Extended의 Platform, architecture, Agent version, Collector와 threshold 지문이 같은지 먼저 확인한 뒤 회귀를 비교했다.

이 결과는 3노드 Kind와 해당 Commit에 대한 안정성 기준선이다. 실제 운영 정확도나 모든 Kubernetes 배포판의 성능을 뜻하지 않는다.

단일 표본만으로 공통 threshold를 낮추지 않았다. 다음 단계는 별도 승인 세션의 24시간 Production Profile과 managed Kubernetes canary다.

장시간 테스트에서 중요한 것은 “5시간 동안 실패하지 않았다”는 문장이 아니다. 어떤 Agent 버전과 설정으로 몇 번 수집했고, 자원 추세와 오류를 어떤 기준으로 판정했는지 재검증할 수 있어야 한다.

Burn-in을 통해 기능 테스트와 운영 안정성 테스트를 분리하고, 한 번의 성공을 장기 안정성으로 확대 해석하지 않는 기준을 만들었다.