서버가 다운되거나 접속이 불가능해졌을 때, IT 전문가들이 가장 먼저 확인하는 것은 **’장애의 원인이 하드웨어인지, 시스템 자원인지, 네트워크인지’**를 빠르게 구분하는 것입니다. 서버 복구의 핵심은 정확한 진단과 신속한 대응에 달려 있습니다.
1. 서버 접속 가능 여부 (Connectivity)
서버가 정말로 다운된 것인지, 아니면 단순히 네트워크 문제로 인해 접속만 안 되는 것인지를 가장 먼저 확인합니다.
핑(Ping) 테스트
- 확인 사항: 메인 컴퓨터에서 서버의 IP 주소나 도메인으로 Ping 테스트를 시도합니다.
- 결과 해석:
- Ping 성공: 서버 자체는 켜져 있고 네트워크 연결은 살아있다는 의미입니다. (하드웨어/네트워크 문제는 아닐 가능성이 높음)
- Ping 실패/Timeout: 서버가 아예 꺼져 있거나, 네트워크가 단절되었거나, 방화벽 설정 오류로 인해 접속 자체가 차단되었을 가능성이 높습니다.
SSH 또는 원격 데스크톱 접속
- 확인 사항: Ping이 성공했다면, **SSH(Secure Shell)**나 **원격 데스크톱(RDP)**을 통해 서버 콘솔에 직접 접속을 시도합니다.
- 목적: 접속이 성공하면 로그 파일이나 자원 사용량을 확인할 수 있지만, 접속이 실패하면 웹 서버 애플리케이션 자체가 멈췄거나 과부하로 인해 접속을 받아들이지 못하고 있음을 의미합니다.
2. 서버 자원 사용 현황 (Resource Utilization)
서버에 접속이 가능하다면, 장애의 원인이 **과부하(Overload)**인지 확인하기 위해 핵심 자원 사용량을 즉시 확인합니다.
CPU 및 RAM 사용률
- 확인 사항:
top,htop(Linux) 또는 작업 관리자 (Windows) 같은 명령어나 도구를 사용하여 CPU 사용률과 메모리(RAM) 사용률을 확인합니다. - 결과 해석:
- CPU 90% 이상: 갑작스러운 트래픽 폭주, 무한 루프에 빠진 프로그램(버그), 또는 DDoS 공격 등으로 인해 서버가 과부하 상태에 빠졌음을 의미합니다.
- RAM 90% 이상 및 Swapping: 메모리 누수나 대규모 프로세스 실행으로 RAM이 부족해져 디스크를 사용(Swapping)하고 있음을 의미하며, 이 경우 서버는 극도로 느려집니다.
디스크 공간 확인
- 확인 사항:
df -h(Linux) 명령어로 디스크의 사용 가능한 공간을 확인합니다. - 결과 해석: 디스크 사용량이 100%에 근접하면, 로그 파일이 통제 불가능하게 쌓였거나, 디스크 공간 부족으로 인해 OS나 애플리케이션이 정상적으로 작동을 멈췄을 수 있습니다.
3. 핵심 서비스의 작동 상태 (Service Health)
서버가 켜져 있고 자원도 여유가 있다면, 웹사이트를 구동하는 핵심 소프트웨어가 멈췄는지 확인합니다.
웹 서버 및 DB 서버 상태
- 확인 사항:
systemctl status nginx또는systemctl status httpd(웹 서버),systemctl status mysql(DB 서버) 명령어로 해당 서비스가 ‘Active (running)’ 상태인지 확인합니다. - 결과 해석: 서비스가 **’inactive’**나 ‘failed’ 상태라면, 해당 서비스의 **오류 로그(Error Log)**를 확인하여 구체적인 원인(설정 파일 오류, 메모리 부족으로 인한 강제 종료 등)을 파악하고 재시작을 시도해야 합니다.
4. 서버 로그 파일 (Log Files)
장애의 직접적인 원인을 찾기 위해 **오류 로그(Error Log)**를 확인하는 것이 가장 중요하며, 이는 반드시 시간순으로 확인해야 합니다.
시스템 및 애플리케이션 오류 로그
- 확인 사항:
- 시스템 로그:
/var/log/syslog나/var/log/messages를 확인하여 하드웨어 고장, 커널 오류, 재부팅 기록 등을 확인합니다. - 웹 서버 오류 로그: Nginx나 Apache의 **
error.log**를 확인하여 장애 발생 직전 시간에 어떤 오류 메시지(예: 파일 권한 문제, 설정 파일 파싱 오류)가 기록되었는지 확인합니다.
- 시스템 로그:
마지막 변화 시점 파악
- 목적: 장애 발생 직전에 서버 설정 파일이나 애플리케이션 코드가 최근에 변경된 기록이 있는지 확인합니다. 대부분의 장애는 변경 사항 적용 후에 발생하므로, 마지막 변경 시점을 파악하면 문제 해결 시간을 크게 단축할 수 있습니다.
이 네 가지 단계를 통해 장애의 원인을 네트워크 → 하드웨어/자원 → 소프트웨어 순서로 좁혀 나가면 빠르고 체계적인 복구가 가능합니다.
