새벽 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