RCA 2026.07.22 4 min read

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

Kind의 Agent 3개를 1시간과 5시간 반복 관측했다. 수집 성공률, RSS 추세, 프로세스 재시작, 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 지문이 같은지 확인했다.

이 수치는 해당 Commit을 3노드 Kind에서 실행한 기준선이다. 실제 운영 정확도나 다른 Kubernetes 배포판의 성능까지 검증한 결과는 아니다.

이 표본만으로 공통 threshold를 낮추지는 않았다. 당시 다음 검증으로 남긴 것은 별도 승인 세션의 24시간 Production Profile과 managed Kubernetes canary였다.

5시간 실행 결과를 다시 비교할 수 있도록 Agent 버전, 설정, 수집 횟수, 자원 추세와 판정 기준을 함께 남겼다.

기능 테스트와 장기 관측을 분리했다. 이후에는 같은 조건의 표본이 쌓였는지 먼저 확인하고 안정성을 판단하려고 했다.