2024.09.05 19시경에 발생한 서버 다운 오류 관련 포스트 모템

[Recyclingbottle]

포스트 모템

원인 분석

2024년 9월 6일 오전 7시 40분 경, EC2 내에서 실행 중이던 스프링부트 애플리케이션이 데이터베이스 연결이 끊기며 애플리케이션이 종료되는 문제가 발생했습니다. RDS 모니터링을 살펴본 결과, 모니터링 지표는 튀거나 이상한 부분이 없었고, 연결 수가 최대 60임에도 대부분 20대 중반을 유지하고 있었습니다.

해당 시간에 RDS 로그에서 외부 IP로의 접근 시도가 있었으며, VPC 설정에서 모든 IPv4와 IPv6를 허용한 상태에서 발생한 문제였습니다.

무슨 일이 있었나요?

• 애플리케이션의 데이터베이스 연결이 끊겨 종료되는 상황이 발생했습니다.
• RDS 로그에는 여러 외부 IP의 접근 실패 내역이 기록되어 있었습니다.
• 이는 VPC 설정을 모든 IP에 열어둔 상태에서 외부 접근 시도 때문에 발생한 문제로 추정됩니다.

기여 요인 또는 근본 원인 식별

기여 요인

• RDS가 프리티어 상태로 사용 중이었고, 과부하에 취약한 상태였습니다.
• VPC 설정에서 IP를 제한하지 않고 모든 IPv4와 IPv6를 열어두었습니다.
• 스프링부트 내에서 connectionTimeout 설정이 적절히 적용되지 않았을 가능성이 있다고 멘토인 '웨슬리'를 통해 확인했습니다.

근본 원인

• RDS의 max_connections 설정이 한계에 다다른 상태에서 외부 접근 시도 및 연결 문제로 인해 애플리케이션의 데이터베이스 연결이 끊겼습니다.

다운타임으로 인한 영향

• 다운타임 동안 애플리케이션은 완전히 종료되어 사용자 접근이 불가능했습니다.
• 외부 IP 접근 시도와 DB 연결 끊김으로 인해 약 1시간 가량의 서비스 중단이 발생했습니다.
• 다운타임 동안 접속한 유저 수는 기록되지 않았으나, GA 확인 시 해당 시간에 서비스 이용자가 두 자리수였기에 큰 영향은 없었을 것으로 추정됩니다.

문제를 어떻게 발견했나요

• WhaTap 서비스에서 서버 응답이 502 오류 코드를 나타낸다고 메일을 통해 확인하였고, 디스코드에 여러 오류 관련 연락이 와서 확인하였습니다.

응답 관련 요소들

• 이메일을 통해 해당 오류가 발생한지 5분도 채 되지 않은 시간에 모든 팀원이 오류를 발견하였습니다. (오전 7시 40분)
• 이후 오류 확인을 통해 EC2 Spring Boot 어플리케이션의 로그를 읽어보았고, Hikari DB 연결 종료로 인해 어플리케이션이 종료됨을 확인했습니다. (오전 7시 45분)
• 모든 팀원이 뿔뿔이 흩어진 상태였기에, '준원'이 RDS, EC2, Github Actions을 통한 CICD를 구축하였기 때문에 가장 빨리 오류를 해결할 수 있다고 판단하여 그가 해당 오류에 대처하였습니다.
• 최종적으로 다운 시간이 30분 정도 있었고, Github Actions을 통하여 CD 부분의 Jobs을 재실행하고 RDS를 micro에서 small로 업그레이드하면서 max_connections 수를 늘려 해당 오류를 방지하였습니다.
• RDS 오류 로그는 skip-name-resolve 설정을 통해 처리하였습니다.

해결

• RDS 인스턴스를 micro에서 small로 업그레이드하여 max_connections을 늘렸습니다.
• RDS 파라미터 그룹 설정에서 skip-name-resolve 옵션을 추가해 불필요한 DNS 조회를 막았습니다.
• 스프링부트의 connectionTimeout 설정을 확인한 결과 문제가 없음을 확인했습니다.

타임라인

• ⏰ 19:40 애플리케이션 종료 및 데이터베이스 연결 끊김 발생.
• ⏰ 19:40 RDS 로그 및 모니터링 확인.
• ⏰ 19:50 RDS 설정 변경 및 업그레이드 완료.
• ⏰ 20:00 애플리케이션 정상화 및 모니터링 종료.

재발생 여부 및 분석

• 이전에도 프리티어 RDS 사용 시 성능 문제가 일부 보고된 적이 있었으나, 연결 끊김 현상은 처음 발생한 문제였습니다.
• 성능 한계가 초래된 이유는 외부 IP 접근 시도와 맞물려 발생한 것으로 보입니다.

배운 교훈

잘된 점

• 빠르게 로그를 확인하고 RDS 모니터링을 통해 문제의 원인을 파악했습니다.
• 즉각적인 대응으로 RDS 업그레이드 및 파라미터 그룹 설정 변경을 진행했습니다.

잘못된 점

• VPC 설정에서 모든 IP를 허용한 부분은 보안적으로 취약했습니다.
• RDS의 성능을 충분히 고려하지 않고 프리티어를 계속 사용한 점이 문제를 일으켰습니다.

조치 항목 (액션 아이템)

향후 기여 요인을 방지하는 데 필요한 수정 사항

• VPC 설정을 수정하여 특정 IP만 허용하도록 제한.
• RDS 성능 모니터링을 강화하고, 추가적인 부하 테스트를 진행.

문제가 다시 발생할 경우 문제를 완화하는 데 도움이 될 수 있는 준비 작업

• 스프링부트 connectionTimeout 설정을 확인하여 문제 없음을 확인.

남은 사후 단계

• 해당 문제와 관련된 리소스 사용량을 계속해서 모니터링하고 필요한 경우 RDS 인스턴스를 추가로 업그레이드.

사고 대응 프로세스 개선

• 문제 발생 시 더 빠르게 팀 내에 알리고, 디스코드를 통해 실시간 대화를 하면서 처리하는 등 대응 시간을 줄이기 위한 모니터링 및 알림 체계 강화.

[ej31]

• 가독성을 위해 백틱(`) 래핑을 통해 코드 등을 나타내주시고 하이픈("-")을 통해 개조식 형태로 작성해주시면 더욱 좋은 모템이 될 것 같습니다 👴
• 오타도 없애주시구요 하하

samll 로 업그레이드 하면서 -> small