운영 중 서버가 다운되면 가장 중요한 것은 “빨리 고치는 것”이 아니라 “순서대로 확인하는 것”이다.
무작정 재부팅부터 하면 원인 분석이 불가능해지고, 동일 장애가 반복된다.
복구 프로세스는 감각이 아니라 절차다.
점검 순서를 고정해 두면 장애 상황에서도 판단이 흔들리지 않는다.
1. 1차 확인 — 서버 자체 생존 여부
가장 먼저 확인할 것은 서버가 살아 있는지 여부다.
네트워크 단절인지, 프로세스 문제인지, 자원 고갈인지 구분해야 한다.
ping server-ip
ssh user@server-ip
SSH 접속이 되지 않는다면 인스턴스 다운 또는 네트워크 문제일 가능성이 높다.
AWS 환경이라면 EC2 상태 체크(Status Check Failed)를 먼저 확인한다.
2. 2차 확인 — 자원 고갈 여부
접속이 가능하다면 CPU, 메모리, 디스크 상태를 점검한다.
자원 고갈은 가장 흔한 다운 원인이다.
top
free -m
df -h
디스크가 100% 찼다면 로그 폭증 가능성이 높다.
메모리가 부족하다면 OOM(Out Of Memory)로 프로세스가 종료됐을 수 있다.
이 경우 불필요한 로그 정리 후 서비스 재시작으로 복구되기도 한다.
하지만 왜 자원이 고갈됐는지는 반드시 추적해야 한다.
3. 3차 확인 — 웹 서버 / 애플리케이션 상태
서버는 살아 있으나 서비스가 응답하지 않는다면 웹 서버 또는 애플리케이션 프로세스를 확인한다.
systemctl status nginx
systemctl status php-fpm
systemctl status mysql
프로세스가 죽어 있다면 로그를 먼저 확인한다.
tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/php-fpm/error.log
로그 확인 없이 재시작하면 근본 원인을 놓칠 수 있다.
원인을 파악한 뒤 재시작해야 동일 장애를 막을 수 있다.
4. 4차 확인 — DB 연결 문제
웹 서버는 정상인데 500 오류가 발생한다면 DB 연결 문제일 가능성이 있다.
커넥션 고갈 또는 DB 다운 여부를 점검한다.
mysqladmin ping -u root -p
SHOW PROCESSLIST;
Sleep 상태 커넥션이 과도하게 많다면 애플리케이션에서 커넥션을 반환하지 않는 구조일 수 있다.
이 경우 코드 레벨 수정이 필요하다.
5. AWS 환경에서의 추가 점검
AWS 사용 시에는 인프라 레벨도 함께 확인해야 한다.
- Security Group 변경 여부
- 로드밸런서 Target 상태
- Auto Scaling 동작 여부
- EBS 상태 확인
로드밸런서 Health Check 실패라면 애플리케이션 헬스 체크 경로를 점검한다.
6. 복구 후 반드시 할 일
복구가 끝났다고 종료하면 안 된다.
재발 방지 조치가 남아 있다.
- 원인 정리 문서화
- 로그 백업
- 모니터링 지표 추가
- 임계치 알람 설정
예를 들어 디스크 부족이 원인이었다면 로그 로테이션 정책을 추가해야 한다.
logrotate -f /etc/logrotate.conf
장애 대응은 복구가 아니라 개선까지 포함해야 한다.
한 줄 요약
서버 다운 시 접속 가능 여부 → 자원 점검 → 프로세스 확인 → DB 상태 확인 → 인프라 설정 점검 순으로 접근. 복구 후에는 반드시 원인 문서화와 재발 방지 조치를 수행해야 한다.
댓글 0