장애 회고
스토리
SM 업무 중 선착순 이벤트가 예정되어 있었다.
평소 프로덕션 사이트는 트래픽이 많이 발생하지 않아 2대의 서버로 운영하기에 충분했다.
하지만, 선착순 업무를 대비하여 서버를 추가로 2대를 추가적으로 증설 및 DB 부하가 걸릴만한 곳은 없는지, Hikari CP, 인덱스는 잘 설정되어있는지 확인했다.
준비는 다 맞췄다. 이제 선착순 모집을 할 시간이 되었다. 선착순 모집 1분 후 에러 로그가 셀 수없을 정도 발생하고, 로드 밸런서는 서버의 헬스 체크를 실패하여 서버가 정지되었다고 판단했다.
에러
에러 로그
Connection ReadTime Exception 및 Hikari CP 관련 로그가 많이 보였으며, 그 중 데드락을 의미하는 에러 로그도 간간히 보였다. 대부분 커넥션을 30초안에 획득하지 못해 데이터 베이스와 커넥션을 맺지 못하고 예외가 발생했다.
에러 분석
에러 로그 대부분이 Connection 관련 로그밖에 없어서 당연히 데이터 베이스 또는 애플리케이션 커넥션 풀 문제인것으로 생각해 데이터 베이스 성능 및 커넥션 풀을 조정해보았지만 계속해서 에러가 발생했다.
원인 찾기
커넥션 관련을 수정해도 계속해서 발생하기에 최초 에러가 발생한 시간을 찾고, 또 최초로 발생한 에러는 무엇인지 찾기위해 로그를 보는 중
Too many open files라는 에러 로그가 보였다.
★ 에러가 발생했을 경우 반드시 첫번째 에러가 무엇인지, 언제 발생했는지, 어디서 발생했는지가 중요하다. 많이 발생한 로그가 문제일 수도 있지만, 지금 같은 경우는 처음으로 발생한 에러가 정말 중요했다. 첫 에러 로그를 파악하는 습관을 들이자
Too many open files
원인
Too many open files 에러는 프로세스가 OS에 요청할 수 있는 리소스의 개수/양에 Limit가 있고, 프로세스의 요청 리소스의 수가 Limit를 초과했기 때문에 발생한다.
리소스에 해당하는 파일
일반 파일: 텍스트 파일, 바이너리 파일 등이 포함되며, NAS 등 이미지 파일을 서버 내에 저장할 경우 같이 포함된다.
소켓 파일: 네트워크 통신을 위해 열린 소켓, DB Connection 등 네트워크 연결에 사용되는 리소스
수정
/etc/security/limits.conf
서버(인스턴스)의 디렉토리를 찾아 들어가보면 limits를 수정할 수 있다.
ulimit -a 명령어를 사용하여 OS의 limit를 확인 가능
open file에 대한 limit는 soft와 hard가 존재하고, soft는 권한이 있는 OS 계정에서도 변경이 가능하지만, hard의 경우 OS의 root계정만 limit 변경이 가능하다.
ulimit -Hn : hard open file limit를 확인 (default : 4096)
ulimit -Sn : sofr open file limit를 확인 (default : 1024)
<domain> <type> <item> <value>
* hard nofile 65535
* soft nofile 65535
OS의 모든 계정에 대해 limit를 65535로 변경해주었다.
트래픽이 많이 발생하는 애플리케이션이면 반드시 openfile limit를 수정해주어야한다.레퍼 런스
