EBS I/O 크레딧 소진 의심 — 부하 중 호스트 전체가 30초 창에서 동시 정지

[Khyojae]

배경

AI 워커 부하-중 장애 라운드 §6(MySQL 캡 재현 시도, 2026-08-28)에서 새로 열린 후보다.

1차 라운드는 MySQL InnoDB 내부 락 정체를 의심했다(로그가 "장기 세마포어 대기" 헤더에서 끊김). MySQL에 mem_limit=3072m을 걸고 재현을 시도했는데 — 사고가 다시 났고, 이번엔 사고 30~40초 전 SHOW ENGINE INNODB STATUS 직접 증거를 확보했다. 그 증거는 MySQL이 사고 직전 완전히 idle·healthy했다는 것을 보여줘서, 1차의 락 정체 가설을 반박한다.

관찰

부하 시작 후 10분 시점, 서로 다른 독립 채널 3개가 **같은 30초 창(09:38:2909:38:45 UTC)** 안에서 거의 동시에 멈췄다:

1. systemd 저널(호스트 커널/시스템 로그)
2. SHOW ENGINE INNODB STATUS 폴러(MySQL 컨테이너 docker exec)
3. Prometheus의 node-exporter 스크레이핑(컨테이너 간 HTTP)

그런데 메모리는 끝까지 평평했다 — node_memory_MemAvailable_bytes 13.4GB(전체 15GB 중)로 잠식 흔적 없음, shadowfit-ai 컨테이너 메모리도 604MB로 평평(cAdvisor 관측). 점진적 자원 고갈의 흔적이 없이 거의 순간적으로 멎었다.

가설

EBS(gp3) I/O 크레딧/처리량 한도 소진. 메모리는 안 튀었는데 디스크에 물린 모든 것(저널 쓰기·MySQL 쿼리·HTTP 응답·도커 로그 쓰기)이 동시에 멎는 건 디스크 I/O 자체가 막히는 그림과 맞는다. gp3 볼륨 기본값은 3,000 IOPS·125MB/s인데, 계정 193203개의 동시 가입·로그인·온보딩(각 23 보호 경로) + MySQL 커밋 + 도커 로그 쓰기가 겹치면 순간적으로 그 한도에 닿을 수 있다.

미검증

• EBS 지표(VolumeQueueLength·VolumeThroughputPercentage·VolumeConsumedReadWriteOps 등, CloudWatch)를 이 라운드는 안 걷었다 — 직접 확인 안 됨
• 재부팅 셧다운 도중(09:44:10) shadowfit-ai의 uvicorn이 OOM kill됐는데(anon-rss 4.5GB), 이게 이 사고의 원인인지 결과(시스템이 이미 얼어붙은 뒤 셧다운 절차 자체가 메모리를 눌러서)인지 이 라운드로는 못 갈랐다
• 이번 라운드는 obs 프로파일(Grafana 등) 추가와 MySQL 캡 적용이 같이 겹쳐서, 완전히 깨끗한 단일변수 대조는 아니다

다음에 필요한 것 (착수 여부·우선순위는 미결정)

• EBS CloudWatch 지표를 걷으면서 같은 강도로 재현 시도
• io2 볼륨 또는 gp3 처리량 프로비저닝 상향으로 재현 여부 대조

[Khyojae]

재현됨 — CloudWatch 증거 확보 (PR #619)

같은 조건(c7i.2xlarge, ROLE=p6-target 풀 스택, 계정 203개 부하)으로 재현했다. 결과:
loadtest/results/ebs-io-repro-ec2-2026-08-30/README.md

계정 준비 직후(17:14~17:15 UTC) 대상이 SSH·앱 포트 전부 무응답이 됐고, 이번엔 30분 뒤에도
회복 안 돼 강제 terminate했다(원 사고보다 심함 — 원 사고는 소프트 리부트로 회수됨).

첫 직접 증거: VolumeWriteOps가 분당 1,2001,500 → 사고 시점 761로 붕괴했는데
VolumeQueueLength는 2.1~2.6에서 28분간 안 내려왔다. "느려짐"이 아니라 "쓰기가 큐에
걸린 채 하나도 안 빠진다"는 그림이다.

정정: gp3는 크레딧 모델이 없다(BurstBalance 지표 자체가 이 볼륨에 없음, 조회해도
0건) — 원 제목의 "I/O 크레딧 소진"은 부정확한 표현이다. 더 정확히는 "EBS 볼륨(또는 그
경로)이 어느 시점부터 요청을 아예 못 처리하는 상태로 들어갔다"다.

VolumeStalledIOCheck 등 정확히 이 상황을 위한 체크 지표들은 이 볼륨에 데이터포인트가
0건이라 확정적 증거는 못 얻었다 — 원인(호스트 vs EBS 서비스)은 여전히 미확정.

이슈 제목을 "I/O 크레딧 소진" → "I/O 스톨(쓰기 붕괴+큐 고정)"로 바꾸는 걸 고려해볼 만하다 —
결정은 판단 몫.

🤖 Generated with Claude Code

[Khyojae]

2026-09-02: 새 EC2 라운드 없이 CloudWatch 사후 조회로 이 후보를 확인했다. PR #652.

두 인스턴스(R15·R16, 2026-08-28)는 이미 terminate됐지만 EBS 볼륨의 CloudWatch 지표는 볼륨이 사라진 뒤에도 남는다(리전 기본 보존 15개월). list-metrics로 InstanceId→VolumeId를 역추적해 VolumeAvgThroughput·VolumeAvgIOPS를 사고 전후로 조회했다.

결과: 두 사고 모두 EBS 볼륨 처리량이 정확히 gp3 기본 상한(125MiB/s ≈ 128,075 KiB/s)에 뛰어올라 사고 구간 내내 그대로 눌러붙어 있었다. IOPS는 상한(3,000) 밑 — 막힌 건 처리량이지 IOPS가 아니다.

• 1차(07:31:54 부하 시작): 07:25 448 KiB/s → 07:30 128,074 KiB/s, 리부트 직전(08:05)까지 35분 내내 그대로
• 2차(09:28:27 부하 시작, 09:38:29~09:38:45 세 채널 동시 정지): 09:30 667 → 09:35 69,053(54%) → 09:40 128,075(100%, 정확히 정지 구간을 담는 버킷)

AWS 공식 "Check" 지표(VolumeIOPSExceededCheck·VolumeThroughputExceededCheck·VolumeStalledIOCheck)는 그 하루 종일 데이터가 하나도 없었다 — 이 지표만으론 이 사고를 못 잡는다는 것도 같이 확인됨.

정정: "크레딧 소진"은 부정확한 표현이었다 — gp3는 버스트 크레딧이 없다(gp2/st1/sc1 전용 개념). 있는 건 늘 켜져 있는 고정 처리량 상한이다.

여전히 안 갈린 것: 상관관계이지 인과관계의 증명은 아니다. 상한 도달이 얼어붙음의 원인인지, 앱이 먼저 이상해져서 쓰기가 쌓인 결과인지는 이 데이터만으론 못 가른다 — 그걸 가르려면 앱 쪽 쓰기 요청량(예: Innodb_data_writes)을 같은 시간축에 놓고 봐야 하는데 그 라운드가 안 걸었고, 인스턴스가 사라진 지금은 못 메운다.

실용적으로 남는 것: 원인이든 결과든, 이 워크로드(동접 193~203 가입·로그인·온보딩 + MySQL 커밋 + 컨테이너 로그)는 gp3 기본 처리량 상한을 실제로, 반복적으로, 지속적으로 채운다. 처리량을 추가 프로비저닝(gp3 최대 1,000MiB/s 별도 과금)하거나 io2로 옮기는 게 다음 실용적 손잡이지만, 얼마를 살지는 이 라운드만으론 근거가 없어 결정하지 않는다.

전체 시계열·방법: loadtest/results/ai-worker-load-soak-2026-08-28/README.md §6-7.

이 이슈는 열어둔다 — 인과 방향과 프로비저닝 결정이 남아 있다.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[Khyojae]

2026-09-08 라운드 결과 — EBS 상한은 원인이 아니다

이 이슈가 연 가설(gp3 기본 처리량 상한 125MiB/s 가 박스를 세운다)을 통제된 대조로 재봤다. 팔은 볼륨 처리량 하나만 달랐다(팔 A gp3 기본 3000/125 ↔ 팔 B 16000/1000, describe-volumes 로 확인). 나머지(커밋·컨테이너 캡·검출기 풀·부하)는 동일.

결과: 반증이다.

팔	최대 write_KiBps	기본 상한(128,000) 대비	박스 멈춤
A (기본)	1,239.4	0.97%	718초 통째로
B (상한 8배)	3,035.4	2.37%	74s · 217s · 44s

• 팔 B 도 멎었다 — 상한을 8배로 걷어도 같은 현상이 난다.
• 더 센 것은 팔 A 조차 상한 근처에 못 갔다는 것이다. 08-28 두 사고의 서명이던 125MiB/s 눌러붙음이 재현되지 않았다(40~100배 차이).

즉 §6-7 이 CloudWatch 로 본 「상한에 눌러붙음」은 상관이었고, 이 워크로드에서는 그 상관조차 안 나타난다.

새 후보로 갈아탄다 — #698

같은 라운드에서 AI 컨테이너 캡(19.5GiB)이 호스트 RAM(15.3GiB)보다 크다는 것을 잡았고, 회수 스래싱 증거가 나왔다(팔 A pgscan/pgsteal_kswapd = 225:1, 부하 종료 78분 뒤에도 kswapd 65% CPU · load 105). 캡 > RAM 이면 cgroup 한도에 안 닿아 OOMKilled=false 가 나오고 압력이 호스트로 샌다 — 이 이슈가 남긴 관측 넷(AWS healthy · 앱 무응답 · OOM 아님 · "메모리 안 튐")을 한 기제로 설명한다. 08-28 도 같은 조합이었다.

원 질문도 처음으로 답을 내기 시작했다

shadowfit-ai RestartCount 가 실제로 올랐다 — 팔 A 0→1, 팔 B 0→1→2, 전부 OOMKilled=false·ExitCode=0. 08-28 은 박스가 먼저 죽어 이 채널을 한 번도 못 봤다. 🔴 다만 어느 워커가 왜 죽었는지는 안 갈렸다(재기동이 로그를 지운다 — 로그 영속화가 선행).

🔴 이 이슈를 닫지 않는 이유

• 반증이 1판짜리다 — 게이트 2판째를 못 돌렸다
• 새 후보(bootstrap.sh 의 AI_MEM_LIMIT 기본값(20000m)이 c7i.2xlarge 호스트 RAM(15.3GiB)을 넘는다 — OOMKilled 없이 호스트가 회수 스래싱에 빠진다 #698)는 정황이지 인과가 아니다. 「캡을 내리면 멈춤이 사라지는가」 판을 걸었으나 측정자 조작 실수로 한 판도 못 돌았다(결과 §6)
• 「박스가 얼었다」와 「docker 가 막혔다」를 이 판은 못 가른다 — 폴러가 docker exec 를 쓴다

다음 라운드 1순위: 캡 하나만 다르게 놓고 멈춤이 사라지는지 본다(#698 ㉠/㉡ 결정도 그 뒤).

결과: loadtest/results/ebs-causality-2026-09-08/ · 절차: loadtest/aws/ROUND-2026-09-08-ebs-causality.md