18강 / 20강

장애 대응 — 서버가 아플 때

디스크·메모리·포트, 그리고 침착한 순서

새벽 2시, 사이트가 죽었다는 연락이 옵니다. 무엇부터 볼까요?

경험 많은 관리자는 정해진 순서로 확인합니다. 당황해서 아무거나 만지면 오히려 상황이 나빠지거든요.

① systemctl status서비스가 살아 있나

② df -h디스크가 찼나 ← 1위 원인

③ free -h메모리가 모자라나

④ top누가 CPU를 먹나

⑤ ss -ltnp포트가 열려 있나

⑥ 로그왜 그랬나

고등학생서버가 아플 때

이 강이 진짜 관리자를 만드는 부분입니다.

중요한 것은 지식이 아니라 순서다

왜 순서인가

장애 때는 당황합니다. 그때는 생각이 아니라 체크리스트가 필요해요.

상태	필요한 것
평소	이해
새벽 3시	순서 — 생각할 여유가 없다

비행기 조종사도 체크리스트를 읽는다 — 외워도

기본 순서

순서	확인	명령
1	디스크	`df -h`
2	메모리	`free -h`
3	부하	`top` · `uptime`
4	서비스	`systemctl status`
5	로그	`journalctl -xe`
6	포트	`ss -tlnp`

1~3번은 30초면 된다 — 여기서 대부분 잡힌다

그리고 침착함

하지 말 것	왜
여러 개를 한꺼번에 고친다	무엇이 고쳤는지 모른다
일단 재부팅	증거가 사라진다
기록 없이 고친다	다음에 또 헤맨다

한 번에 하나씩 바꾸고 확인한다

고등학생장애 원인 1위는 놀랍게도 디스크 꽉 참

note 의 이 통계가 경험과 일치합니다.

화려한 원인보다 단순한 원인이 훨씬 흔하다

왜 디스크가 1위인가

이유	설명
서서히 찬다	어느 날 갑자기 임계점
알림이 없다	안 보다가 터진다
증상이 이상하다	"DB 오류" 처럼 보인다

증상이 원인을 가린다 — 그래서 df 부터 본다

디스크가 차면 나타나는 증상들

보이는 것	진짜 원인
"DB 에 쓸 수 없음"	디스크
로그인이 안 됨	디스크 (세션 파일)
앱이 500 오류	디스크
로그가 안 남음	디스크

전혀 달라 보이는 증상이 한 원인에서 나온다

비유 — 몸이 아플 때

여러 증상이 있는데 원인은 탈수 하나인 경우가 있죠.

증상	원인
두통 · 어지러움 · 피로	물을 안 마셨다

기본부터 확인하면 여러 증상이 한 번에 설명된다

inode 함정

df -h 는 여유 있는데 "No space left" 라면?

df -i      # inode 를 본다

부족한 것	원인
용량	큰 파일
inode	작은 파일이 수백만 개

파일 개수에도 한도가 있다 — 세션·캐시 파일이 흔한 범인

① 디스크

사용률 90%가 넘으면 빨간불입니다

bash 내 가상 Ubuntu 서버에서 실행

df -h

무엇이 용량을 먹는지 — du 는 폴더별 크기

bash 내 가상 Ubuntu 서버에서 실행

sudo du -sh /var/log
du -sh ~/shop

고등학생범인 폴더를 찾는 공식

note 의 이 명령이 가장 자주 쓰는 진단 도구입니다.

du -sh /* 2>/dev/null | sort -rh | head

10강의 파이프가 여기서 무기가 된다

한 단계씩 좁혀 갑니다

단계	명령
1	`du -sh /* \| sort -rh \| head`
2	큰 게 /var 면 → `du -sh /var/*`
3	/var/log 면 → `du -sh /var/log/*`

이진 탐색처럼 절반씩 좁힌다

2>/dev/null 이 왜 필요한가

권한이 없는 폴더에서 오류가 쏟아집니다. 그걸 버리는 거예요.

번호	스트림
1	표준 출력 (결과)
2	표준 오류

4강의 /dev/null — 버리는 구멍이 여기 쓰인다

지워도 되는 것부터

순서	대상	안전도
1	`apt clean`	매우 안전
2	`journalctl --vacuum-size`	안전
3	오래된 로그 압축본	안전
4	임시 파일	대체로 안전
5	앱 캐시	확인 후

급하다고 아무거나 지우면 더 큰 사고가 난다

⚠ 지웠는데 안 줄어들 때

프로세스가 붙잡고 있는 파일은 지워도 공간이 안 돌아옵니다.

lsof +L1      # 지워졌는데 열려 있는 파일

그 프로세스를 재시작해야 공간이 돌아온다

로그 파일을 지웠는데 df 가 그대로 라면 대개 이 경우입니다.

② 메모리 · ③ CPU

9강에서 배운 것 — available 과 load average 를 보세요

bash 내 가상 Ubuntu 서버에서 실행

free -h
uptime

load average: 0.42, 0.31, 0.28 은 1분·5분·15분 동안 CPU를 기다린 평균 작업 수입니다. CPU가 2개인 서버라면 2.0까지는 정상이에요. 그보다 크면 밀리고 있다는 뜻입니다.

누가 범인인지 한눈에

bash 내 가상 Ubuntu 서버에서 실행

top

④ 포트 — 누가 어디서 듣고 있나

"앱이 돌고 있는데 접속이 안 돼요"의 절반은 포트 문제입니다.

-l 듣는 중 · -t TCP · -n 숫자로 · -p 어느 프로세스인지

bash 내 가상 Ubuntu 서버에서 실행

sudo ss -ltnp

0.0.0.0:80모든 곳에서 접속 가능nginx — 바깥에 열려 있음

127.0.0.1:8000이 컴퓨터 안에서만gunicorn — 일부러 막아 둔 것

0.0.0.0:22SSH원격 접속용

만약 우리 앱이 0.0.0.0:8000 이었다면, 누구나 nginx를 건너뛰고 앱에 직접 접속할 수 있습니다. 16강에서 세운 방벽이 무너지는 거예요.

고등학생포트 충돌 — Address already in use

note 가 든 이 오류는 배포할 때마다 만납니다.

그 포트를 이미 누가 쓰고 있다

범인 찾기

ss -tlnp | grep 8000
lsof -i :8000

옵션	뜻
-t	TCP
-l	듣고 있는 것만
-n	이름 대신 번호로 (빠르다)
-p	어느 프로세스인지

-p 를 보려면 sudo 가 필요하다 — 남의 프로세스니까

흔한 원인

원인	확인
이전 프로세스가 안 죽었다	PID 를 보고 kill
systemd 가 이미 띄웠다	`systemctl status`
다른 앱이 쓴다	포트를 바꾼다
TIME_WAIT	기다리면 풀린다

두 번째가 가장 흔하다 — 손으로 띄우고 systemd 도 띄운 것

TIME_WAIT 이 뭔가

연결을 닫은 뒤에도 잠깐 포트를 잡고 있습니다. 늦게 오는 패킷을 제대로 버리려고 요.

상태	기간
TIME_WAIT	보통 60초

개발 서버 옵션 SO_REUSEADDR 이 이걸 건너뛴다

비유 — 회의실 예약

상황	이유
회의는 끝났는데 못 들어간다	정리 시간이 남았다

"끝났다" 와 "쓸 수 있다" 사이에 틈이 있다

🎮 장애 대응 실험실

장애 시나리오를 하나씩 드립니다. 증상을 보고 어느 명령으로 확인할지 골라 보세요. 틀리면 왜 그 명령으로는 알 수 없는지 알려 줍니다.

실전 · 쇼핑몰이 죽었습니다

아래 순서를 그대로 따라가 보세요. 이것이 실제 대응 절차입니다.

장애 발생 — 손님에게는 502 가 보입니다

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl stop shop
curl http://localhost/

① 서비스 상태 확인 → inactive (dead)

bash 내 가상 Ubuntu 서버에서 실행

systemctl status shop

② 왜 죽었는지 로그 확인

bash 내 가상 Ubuntu 서버에서 실행

journalctl -u shop -n 5

③ 복구하고 ④ 확인까지 — 여기서 끝내지 마세요

bash 내 가상 Ubuntu 서버에서 실행

sudo systemctl start shop
systemctl status shop
curl -s http://localhost/healthz

🤔 확인 문제

사이트가 죽었을 때 df -h 를 일찍 확인해야 하는 이유는?

🤔 확인 문제

ss -ltnp 결과에서 앱이 127.0.0.1:8000 으로 듣고 있는 것은?

해설 127.0.0.1 은 이 컴퓨터 자신입니다. 바깥에서 닿을 수 없어요. 손님은 반드시 nginx(80)를 거쳐야 하므로, 16강에서 세운 보호막이 지켜집니다.

🤔 확인 문제

장애를 복구한 뒤 반드시 해야 할 일은?