서버를 운영하다 보면 갑자기 웹사이트에 접속되지 않거나 특정 서비스가 정상적으로 동작하지 않는 상황이 발생할 수 있습니다. 서버 장애는 하드웨어 문제부터 네트워크, 운영체제, 애플리케이션, 디스크 공간 부족 등 다양한 원인으로 발생하기 때문에 무작정 설정을 변경하면 오히려 문제를 해결하기 어려워질 수 있습니다.
특히 서버를 처음 공부하거나 직접 관리하는 사람이라면 장애가 발생했을 때 무엇부터 확인해야 하는지를 알고 있는 것이 중요합니다.
이번 글에서는 서버 장애가 발생했을 때 가장 먼저 확인해야 할 항목 7가지를 순서대로 알아보겠습니다. 특정 서버 제품이나 프로그램에 종속되지 않는 기본적인 점검 방법을 중심으로 설명하겠습니다.
서버 장애가 발생하면 무작정 재부팅하지 말아야 하는 이유
서버에 문제가 생기면 가장 먼저 재부팅부터 생각하기 쉽습니다. 실제로 일시적인 오류는 재부팅으로 해결되는 경우도 있지만, 장애 원인을 확인하기 전에 서버를 재부팅하면 중요한 정보가 사라질 수 있습니다.
예를 들어 장애가 발생하기 직전에 어떤 프로세스가 CPU를 과도하게 사용했는지, 메모리가 부족했는지, 디스크 오류가 발생했는지 등의 정보가 로그에 남아 있을 수 있습니다.
따라서 가능하다면 다음과 같은 순서로 접근하는 것이 좋습니다.
장애 증상 확인 → 네트워크 확인 → 서버 상태 확인 → CPU·메모리·디스크 확인 → 서비스 상태 확인 → 로그 확인 → 필요한 조치
장애의 원인을 찾는 과정에서는 문제를 해결하는 것만큼 현재 상태를 보존하고 원인을 추적하는 것도 중요합니다.
서버 장애 발생 시 확인해야 할 7가지
1. 서버에 실제로 접속할 수 있는지 확인하기
가장 먼저 확인해야 할 것은 서버 자체에 접근할 수 있는지 여부입니다.
웹사이트가 접속되지 않는다고 해서 반드시 서버가 완전히 다운된 것은 아닙니다. 웹 서버 프로그램만 중지되었거나 방화벽 설정에 문제가 있을 수도 있고, 네트워크 경로에 문제가 있을 수도 있습니다.
먼저 서버에 SSH 등으로 원격 접속을 시도해 볼 수 있습니다.
ssh 사용자이름@서버IP
SSH 접속 자체가 되지 않는다면 네트워크, 서버 전원, 운영체제, 방화벽, SSH 서비스 등의 여러 가능성을 확인해야 합니다.
반대로 SSH 접속은 정상적으로 되는데 웹사이트만 접속되지 않는다면 서버 전체의 장애보다는 웹 서버나 애플리케이션과 관련된 문제일 가능성을 먼저 살펴볼 수 있습니다.
즉, 서버 전체가 문제가 있는 것인지 특정 서비스만 문제가 있는 것인지 구분하는 것이 첫 번째 단계입니다.
2. 네트워크 상태 확인하기
서버에 접속할 수 있다면 다음으로 네트워크 상태를 확인합니다.
서버의 CPU와 메모리가 정상이어도 네트워크 인터페이스나 라우팅에 문제가 발생하면 외부에서 서버에 접근하지 못할 수 있습니다.
Linux 서버에서는 다음과 같은 명령어를 활용할 수 있습니다.
ip addr
현재 서버에 어떤 IP 주소가 설정되어 있는지 확인할 수 있습니다.
또한 네트워크 연결 상태를 확인하기 위해 다음과 같은 방법을 사용할 수 있습니다.
ip route
이 명령을 통해 기본 게이트웨이와 라우팅 정보를 확인할 수 있습니다.
DNS 문제인지 네트워크 연결 자체의 문제인지 구분하는 것도 중요합니다. 예를 들어 IP 주소를 이용한 통신은 가능한데 특정 도메인만 접속되지 않는다면 DNS 관련 문제를 의심해 볼 수 있습니다.
따라서 서버 장애가 발생했을 때는 IP 주소, 네트워크 인터페이스, 기본 게이트웨이, DNS, 방화벽 등을 함께 확인하는 것이 좋습니다.
3. CPU 사용량 확인하기
서버가 지나치게 느려졌다면 CPU 사용량을 확인해야 합니다.
Linux 서버에서는 다음 명령어를 사용할 수 있습니다.
top
또는 시스템에 설치되어 있다면 htop과 같은 도구를 활용할 수도 있습니다.
CPU 사용률이 높다면 어떤 프로세스가 CPU를 많이 사용하는지 확인해야 합니다.
예를 들어 특정 애플리케이션의 오류로 인해 프로세스가 비정상적으로 반복 실행되거나, 갑작스럽게 많은 요청이 들어오면서 CPU 사용량이 증가할 수 있습니다.
하지만 CPU 사용률이 높다는 사실만으로 장애 원인을 단정해서는 안 됩니다.
서버의 작업량이 증가하면 CPU 사용률이 높아지는 것은 자연스러운 현상일 수 있기 때문입니다.
중요한 것은 다음과 같은 정보를 함께 확인하는 것입니다.
- CPU 사용률이 언제부터 증가했는가?
- 특정 프로세스가 CPU를 과도하게 사용하는가?
- 사용자 요청이 갑자기 증가했는가?
- 메모리나 디스크에도 이상이 있는가?
- 특정 프로그램에서 오류가 발생하고 있는가?
CPU는 단독으로 판단하기보다 다른 자원과 함께 확인해야 합니다.
4. 메모리 사용량 확인하기
CPU 다음으로 확인할 항목은 메모리(RAM)입니다.
메모리가 부족하면 서버의 전체적인 성능이 떨어질 수 있고, 특정 프로그램이 정상적으로 실행되지 않는 상황도 발생할 수 있습니다.
Linux에서는 다음 명령어로 메모리 상태를 확인할 수 있습니다.
free -h
여기서 전체 메모리 용량뿐만 아니라 사용량과 사용 가능한 메모리 등을 확인할 수 있습니다.
메모리가 부족한 상황에서는 시스템이 디스크의 일부 공간을 메모리처럼 사용하는 스왑(Swap)이 발생할 수 있습니다. 스왑이 과도하게 발생하면 시스템 성능에 영향을 줄 수 있습니다.
메모리 문제를 확인할 때는 단순히 “사용 메모리가 많다”는 이유만으로 장애라고 판단하지 않는 것이 중요합니다.
운영체제는 성능을 위해 메모리를 캐시 등의 용도로 활용할 수 있기 때문입니다.
따라서 실제로 메모리가 부족한 상태인지, 특정 프로세스가 비정상적으로 많은 메모리를 사용하는지 함께 확인해야 합니다.
5. 디스크 용량과 디스크 상태 확인하기
서버 장애에서 의외로 자주 확인해야 하는 항목이 디스크입니다.
특히 로그 파일이나 임시 파일이 계속 쌓이면서 디스크 공간이 부족해지는 경우가 있습니다.
Linux에서는 다음 명령어로 파일 시스템의 사용량을 확인할 수 있습니다.
df -h
특정 디렉터리가 많은 공간을 사용하고 있는지 확인하려면 다음과 같은 명령어도 활용할 수 있습니다.
du -sh 디렉터리명
디스크가 거의 가득 차면 로그 기록, 데이터 저장, 프로그램 실행 등 다양한 작업에 문제가 발생할 수 있습니다.
예를 들어 웹 애플리케이션 자체에는 문제가 없더라도 데이터베이스가 데이터를 기록하지 못하거나 로그 파일을 생성하지 못하는 상황이 발생할 수 있습니다.
따라서 서버 장애가 발생했을 때는 디스크 용량 부족 여부를 빠르게 확인하는 습관이 중요합니다.
또한 디스크 공간과 디스크 성능은 서로 다른 문제라는 점도 알아둘 필요가 있습니다.
용량이 충분하더라도 디스크 I/O가 지나치게 느리거나 저장장치에 문제가 발생하면 서버 성능에 영향을 줄 수 있습니다.
6. 문제가 발생한 서비스의 상태 확인하기
서버에 여러 서비스가 실행되고 있다면 문제가 발생한 서비스를 직접 확인해야 합니다.
예를 들어 웹사이트에 문제가 있다면 웹 서버 또는 애플리케이션 서버가 정상적으로 실행되고 있는지 확인해야 합니다.
Linux에서 systemd를 사용하는 환경에서는 다음과 같은 형태로 서비스 상태를 확인할 수 있습니다.
systemctl status 서비스이름
예를 들어 특정 웹 서버 서비스가 중지되었는지, 실행 중인지, 오류가 발생했는지 확인할 수 있습니다.
서비스가 중지되어 있다면 단순히 다시 시작하는 것보다 왜 중지되었는지 원인을 먼저 확인하는 것이 중요합니다.
서비스가 반복적으로 중지되고 있다면 설정 파일 오류, 포트 충돌, 권한 문제, 디스크 부족, 애플리케이션 오류 등 다른 원인이 있을 수 있습니다.
따라서 “서비스 재시작”은 장애 대응의 최종 목적이 아니라 원인을 파악한 뒤 필요한 조치 중 하나로 생각하는 것이 좋습니다.
7. 서버 로그 확인하기
마지막으로 중요한 항목이 바로 로그입니다.
서버 로그에는 시스템이나 서비스에서 어떤 일이 발생했는지에 대한 기록이 남습니다.
장애가 발생한 시간대를 확인하고 그 시간의 로그를 살펴보면 원인을 찾는 데 도움이 될 수 있습니다.
Linux 시스템에서는 다음과 같은 명령어를 활용할 수 있습니다.
journalctl
특정 서비스의 로그를 확인하려면 다음과 같이 사용할 수 있습니다.
journalctl -u 서비스이름
웹 서버를 운영하고 있다면 웹 서버의 access log와 error log도 함께 확인해야 합니다.
로그에서는 다음과 같은 정보를 살펴볼 수 있습니다.
- 오류가 처음 발생한 시간
- 반복적으로 나타나는 오류 메시지
- 특정 IP에서 발생한 요청
- HTTP 상태 코드
- 서비스 재시작 기록
- 인증 실패 기록
- 프로그램 예외 또는 오류
- 디스크나 시스템 관련 메시지
단, 로그에서 error라는 단어가 발견되었다고 해서 그것이 반드시 장애의 직접적인 원인이라고 단정해서는 안 됩니다.
장애가 발생한 시간, 오류가 반복되는지 여부, 어떤 서비스에서 발생했는지, 실제 장애 증상과 관련이 있는지를 함께 비교해야 합니다.
서버 장애 점검 순서 한눈에 보기
서버 장애가 발생했을 때는 다음 순서로 확인하면 기본적인 원인을 좁혀가는 데 도움이 됩니다.
| 순서 | 확인 항목 | 주요 확인 내용 |
|---|---|---|
| 1 | 서버 접속 | SSH 접속 및 서버 접근 가능 여부 |
| 2 | 네트워크 | IP, 게이트웨이, DNS, 연결 상태 |
| 3 | CPU | 사용률과 과도하게 사용하는 프로세스 |
| 4 | 메모리 | RAM 사용량과 스왑 상태 |
| 5 | 디스크 | 저장 공간 및 디스크 I/O |
| 6 | 서비스 | 문제가 발생한 서비스 실행 상태 |
| 7 | 로그 | 장애 발생 시간대의 오류 및 이벤트 |
이 순서를 무조건 그대로 적용해야 하는 것은 아니지만, 서버 장애의 범위를 좁혀가는 기본적인 출발점으로 활용할 수 있습니다.
서버 장애 원인을 찾을 때 중요한 것은 기록이다
서버 장애를 해결하다 보면 여러 설정을 빠르게 변경하고 싶은 경우가 있습니다. 하지만 장애 원인을 확인하기 전에 설정을 계속 변경하면 무엇이 문제였는지 오히려 파악하기 어려워질 수 있습니다.
가능하다면 다음과 같은 내용을 기록하면서 작업하는 것이 좋습니다.
- 장애가 처음 발생한 시간
- 사용자가 경험한 증상
- 장애가 발생한 서비스
- CPU와 메모리 상태
- 디스크 사용량
- 네트워크 상태
- 관련 로그
- 변경한 설정
- 실행한 명령어
- 재시작 여부
- 장애가 해결된 시점