새벽 3시 17분. 내 폰이 미친 듯이 진동했다. PagerDuty 알림, Lightsail 인스턴스 하나가 응답 불능. 맙소사, 또야?
ssh로 붙어보니 시스템 로그가 이상했다. CPU 크레딧 잔여 3분 시점에서 갑자기 커널 패닉 - 일반적인 크레딧 고갈로는 재부팅 로그만 남는데, 여긴 panic dump가 찍혀 있었다.
## 크레딧 소진이 원인이 아니었다
처음엔 "아, 크레딧 다 떨어져서 죽었나보다" 싶었다. 하지만 크레딧 고갈은 보통 점진적인 성능 저하를 일으키고, 인스턴스는 멈추지만 패닉은 안 난다. 그런데 왜 dump가?
AMI를 확인해보니 문제가 드러났다. Ubuntu 22.04 LTS (HVM)에 특정 커널 파라미터가 적용된 버전이었다. AWS 공식 AMI가 아니라, 어느 타사에서 튜닝한 이미지를 쓰고 있었는데, 이게 Lightsail의 가상화 환경과 충돌을 일으킨 거다.
### ENA 드라이버 버전 싱크 미스
Lightsail은 Nitro 기반이다. 그런데 이 AMI에 포함된 ENA 드라이버 버전이 2.x대였다. Lightsail이 지원하는 최신 ENA 드라이버는 2.8 이상인데, 이 AMI는 2.2에 고정되어 있었다. 크레딧이 바닥나면 인스턴스가 스로틀링 모드로 전환되는데, 이 과정에서 드라이버가 네트워크 인터럽트를 제대로 처리하지 못하고 패닉을 유발했다.
정확히 말하면: 크레딧이 0에 가까워지면 Nitro hypervisor가 vCPU 할당을 강제로 조정한다. 이 때 ENA 드라이버가 인터럽트를 재매핑하는 타이밍에 데드락이 걸리는 거다. 일반 EC2에선 이런 일이 잘 안 나는데, Lightsail의 특수한 크레딧 시스템 하에서만 발생하는 버그였다.
## 이걸 어떻게 찾았나
문제 재현 조건을 역추적했다.
1. 크레딧 잔여량이 3~5분 이하
2. 특정 AMI (Ubuntu 22.04, ENA 2.2 고정)
3. 트래픽이 급증하는 순간
이 세 조건이 겹치면 100% 패닉이 발생했다. 해결은 간단했다. 해당 AMI를 포기하고, aws에서 공식 제공하는 Ubuntu 22.04 LTS (최신 ENA 포함)로 교체했다. 크레딧 관리 정책도 변경했다: 사용률이 70% 넘으면 자동 스냅샷 + 마이그레이션 알림.
### 체크리스트: AMI 선택 전 확인할 것
- Ubuntu AMI의 경우, 사용 중인 ENA 드라이버 버전을 꼭 확인하라. `modinfo ena`로 버전을 체크하고, 2.8 미만이면 교체하라
- 커널 파라미터 중 `net.core.netdev_budget`이나 `net.core.dev_weight` 값이 기본값과 다른지 확인하라. 이 값이 튜닝된 AMI는 Lightsail에서 위험하다
- AMI 출처가 aws 공식인지, 타사인지. 타사면 반드시 Lightsail 지원 여부를 명시적으로 확인하라
server_room