[EAT-SSU / 잇슈] - RDS 다운 원인을 찾아 떠난 트러블슈팅 기록 #1

✏️ 상황

운영 중인 서비스의 EC2/RDS가 종종 알 수 없이 꺼져 있는 걸 발견했다. 매번 발견도 늦었고("어? 서버가 왜 안 켜지지?"), 왜 꺼졌는지도 알 수 없었다. 이번엔 제대로 원인을 추적해보기로 했다.

프리티어 계정이라는 것도 하나의 변수였다. "혹시 프리티어라서 뭔가 제한이 걸린 건가?"라는 의심부터 시작해서, CloudTrail·Billing·Health Dashboard·RDS 로그·CloudWatch까지 순서대로 뒤진 기록을 남겨둔다.

 

✏️ 1. 일단 의심되는 것부터 지운다

가장 먼저 떠올린 가설은 두 가지였다.

• 자격증명 유출로 인한 자동 격리: 코드/워크플로우에 AWS 키가 커밋된 적이 있는지 레포 전체 히스토리를 grep으로 뒤졌다. AKIA로 시작하는 액세스 키 패턴은 없었고, CI/CD의 실제 키는 전부 GitHub Secrets로 관리되고 있었다. → 이건 아니었다.
• 결제 실패: Billing → Invoices를 확인했는데 인보이스 자체가 0건. 애초에 청구가 발생한 적이 없어서 결제 실패로 인한 정지도 아니었다.

✏️ 2. CloudTrail 탐색

CloudTrail 이벤트 기록에서 root로 반복 로그인한 이력, GetSessionToken으로 발급된 임시 액세스 키, UpgradeAccountPlan(프리티어 → 유료 플랜 자동 전환) 이벤트를 발견했다. 얼핏 보면 계정 탈취처럼 보였지만, 시간 순서를 다시 맞춰보니 전부 DB가 이미 죽어있는 걸 알아채고 복구하려던 내 흔적이었다.

진짜 단서는 다른 데 있었다.

 

✏️ 3. RDS 자체 로그가 정확한 타임스탬프를 준다

RDS 콘솔의 로그 파일(error/mysql-error-running.log)을 열어보니, mysqld 자체 로그에 이런 게 남아있었다.
UTC 기준이라 KST로 환산하면, 8/11 06:55에 정지되어 8/12 15:54에야 재시작됐다. 무려 약 42시간 다운..

2026-08-10T21:55:36Z [System] Received SHUTDOWN from user <via user signal>. Shutting down mysqld...
2026-08-10T21:55:45Z [System] Shutdown complete
2026-08-12T06:54:43Z [System] mysqld starting as process ...

 

✏️ 4. "누가 껐는지"가  나오지 않는다.

CloudTrail에서 이 시점 전후로 StopDBInstance, RebootDBInstance 이벤트를 각각 검색했는데 둘 다 0건이었다. (재시작을 위한 StartDBInstance는 내가 root로 호출한 기록이 명확히 남아있었다.)

즉, API 호출을 통한 정지가 아니었다. CloudTrail은 계정 내에서 발생한 API 호출만 기록하는데, 여기에 아무 흔적이 없다는 건 사용자(나든 침입자든) 쪽에서 정지 버튼을 누른 게 아니라는 뜻이다.

 

 

✏️ 5. Health Dashboard, CloudWatch 살펴보기

• AWS Health Dashboard: 미해결 문제, 예정된 변경 사항, 기타 알림, 이벤트 로그 - 전부 우리 계정/리전(ap-northeast-2)과 관련된 항목 없음
• CloudWatch 지표: FreeStorageSpace, FreeableMemory, CPUUtilization 등을 정지 시각 전후로 확인하려 했으나, 콘솔의 자동 생성 대시보드가 특정 리소스에 스코프되지 않아 계속 빈 화면만 나왔다. (참고로 RDS 기본 지표 수집 자체는 항상 켜져있는 기능이라 "연동이 안 된 것"은 아니었다 - 콘솔 UI 탐색 문제였다)

여기까지 오니 자체 콘솔만으로는 더 이상 파고들 방법이 없었다.

 

✏️ 6. 결론: AWS Support 케이스 오픈

고객에게 노출되지 않는 AWS 내부 호스트 레벨 로그를 봐야 하는 상황이라 판단, Support 케이스를 열었다. 케이스에 넣은 내용은 대략 이렇다.

RDS 인스턴스 prod-db(리전: ap-northeast-2)가 2026-08-11 06:55:36 UTC에 원인 불명으로 정지, 2026-08-12 15:52:59 UTC에 수동으로 StartDBInstance를 호출해서야 복구됨(약 42시간 다운). CloudTrail에서 StopDBInstance/RebootDBInstance 호출 이력 없음, Health Dashboard 이슈 없음, 결제 문제 없음. 내부 로그 확인 요청.

현재 이 부분은 조사 중이다. 답변 오는 대로 이 글도 업데이트할 예정.

 

✏️ 7. 원인과 무관하게 지금 해둔 것

원인이 뭐가 됐든, 다운된 지 하루 넘게 지나서야 알아챈 것 자체가 문제였다. 그래서 원인 규명과 별개로 재발 방지책부터 걸어뒀다.

• RDS 이벤트 구독 생성: prod-db의 상태 변화(정지/재시작/장애조치 등)가 생기면 이메일로 즉시 알림이 오도록 SNS 구독 설정. 다음엔 최소한 "언제 알아챌 것이냐"는 문제는 해결된다.
• Performance Insights 활성화는 Support 답변을 보고 필요 여부를 판단하기로 보류했다.