서버 접속 불가 장애 원인 분석 및 재발 방지 대책

date

Apr 25, 2026 11:15

slug

server-outage-postmortem-april-2026

status

Published

먼저 사과의 말씀부터

안녕하세요. 자커마스를 운영하고 있는 유메카입니다.

2026년 4월 21일과 4월 25일, 총 세 차례에 걸쳐 자커마스를 포함한 서버 전체가 응답 불가 상태가 되어 강제 재부팅을 해야 했습니다. 이용하시던 분들께 불편을 드린 점 진심으로 사과드립니다.

이 글에서는 무슨 일이 있었는지, 왜 일어났는지, 앞으로 어떻게 방지할 것인지를 최대한 알기 쉽게 설명드리겠습니다.

장애 발생 일시

횟차	장애 인지 시각 (한국 시간)	복구 시각
1차	2026년 4월 21일 (화) 오전 5시 03분	오전 5시 12분 (재부팅 후 복구)
2차	2026년 4월 25일 (토) 오전 6시 19분	오전 6시 25분 (재부팅 후 복구)
3차	2026년 4월 25일 (토) 오전 10시 43분	오전 10시 48분 (재부팅 후 복구)

세 번 모두 SSH 접속(서버에 원격으로 접속하는 방법)이 완전히 차단되었고, 웹 서비스도 전부 응답하지 않았습니다. 서버가 켜져 있어도 아무것도 할 수 없는 상태였기 때문에 불가피하게 강제 재부팅을 진행했습니다.

원인: 서버의 메모리가 한계를 넘었습니다

메모리란 무엇인가요?

컴퓨터에는 저장 공간(하드디스크/SSD)과는 별개로 메모리(RAM) 라는 것이 있습니다. 하드디스크가 책장이라면, 메모리는 책상 위 공간입니다. 프로그램이 실행될 때는 반드시 메모리 위에 올라와야 하고, 책상이 가득 차면 아무것도 더 꺼낼 수 없게 됩니다.

이 서버의 메모리는 총 32GB입니다. 넉넉해 보이지만, 실제로는 그렇지 않았습니다.

서버에서 동시에 돌아가던 것들

이 서버 하나에는 단순히 마스토돈만 올라가 있는 게 아닙니다.

프로그램	역할	차지하는 메모리
Elasticsearch	마스토돈 검색 기능 담당	약 9 GB (고정)
Mastodon Puma (8개)	마스토돈 웹 서비스 처리	약 3.4 GB
Mastodon Sidekiq (2개)	마스토돈 백그라운드 작업	약 0.9 GB
Node.js (스트리밍)	실시간 타임라인 갱신	약 0.9 GB
Redis	임시 데이터 캐시	약 0.3 GB
authentik	로그인 인증 서비스	약 0.6 GB
기타 Python 서비스	부가 기능	약 0.4 GB
합계	ㅤ	약 16 GB 이상

여기에 운영체제 자체가 사용하는 메모리까지 더해지면, 여유 공간이 생각보다 훨씬 빠르게 줄어듭니다.

예비 메모리(스왑)도 너무 작았습니다

메모리가 부족해질 때를 대비해 하드디스크의 일부를 임시 메모리처럼 쓰는 방법이 있습니다. 이것을 스왑(Swap) 이라고 합니다. 그런데 이 서버의 스왑은 고작 2GB로 설정되어 있었습니다. 메모리가 한계에 달했을 때 2GB로는 버티기에 턱없이 부족했습니다.

실제로 얼마나 위험한 상태였나

서버 로그를 분석한 결과, 장애 당시 서버가 프로그램들에게 약속한 메모리 총량이 실제 처리 가능한 한계를 약 10.8GB 초과한 상태였습니다.

실제 처리 가능한 한계: 약 17.4 GB / 프로그램들에게 약속한 총량: 약 28.2 GB / 초과량: +10.8 GB

이 상태에서 프로그램들이 실제로 그 메모리를 전부 사용하려 하면, 운영체제는 공간이 없으니 강제로 프로그램을 종료시킵니다. 이것을 OOM Killer(메모리 부족 강제 종료) 라고 합니다. 이번 장애는 이 OOM Killer가 SSH나 마스토돈 같은 핵심 프로그램들까지 강제로 꺼버려 서버 전체가 응답 불가 상태가 된 것입니다.

로그가 남지 않은 이유(장애 분석까지 오래 걸린 이유)

"OOM Killer가 발동했다면 기록이 남아야 하지 않나?" 하고 의문을 가지실 수 있습니다. 맞는 말이지만, 이번처럼 극단적으로 메모리가 부족한 상황에서는 로그를 기록하는 프로그램(journald) 자체도 메모리 부족으로 종료되어버립니다. 그래서 장애 순간의 기록이 거의 남지 않습니다.

실제로 재부팅 후 서버 기록 파일이 "비정상 종료로 인해 손상됨" 이라는 메시지와 함께 교체된 것이 확인되었습니다. 이것이 서버가 정상적으로 종료된 게 아니라 갑자기 쓰러진 증거입니다.

장애가 하드웨어 문제는 아닌가요?

이번 분석에서 다음 항목들은 모두 정상임을 확인했습니다.

디스크 오류 없음 — 저장장치에 이상 없음 (디스크 사용량 61%, 여유 충분)

디스크 아이노드 정상 — 파일 개수도 여유 있음

커널 패닉 없음 — 운영체제 핵심 오류가 아님

하드웨어 오류 없음 — 메모리 칩 오류(MCE), CPU 과열 등 없음

네트워크 오류 없음 — 회선이나 네트워크 카드 문제 아님

자동 업데이트 연관성 없음 — 장애 당일 패키지 업데이트 기록 없음

원인은 순수하게 소프트웨어(메모리 관리) 문제였습니다.

재발 방지 대책

1. 스왑 공간 대폭 확장 ✅ 적용 완료

2GB에 불과했던 스왑을 16GB로 늘렸습니다. 메모리가 부족해지기 시작하면 하드디스크를 임시 메모리로 활용해 버틸 수 있는 시간이 확보됩니다. 속도는 다소 느려질 수 있지만, 서버가 완전히 쓰러지는 최악의 상황을 막는 데 중요한 역할을 합니다.

2. Elasticsearch 메모리 사용량 조정 ✅ 적용 완료

검색 담당 프로그램인 Elasticsearch가 기존에는 최소 9GB를 항상 독점하고 있었습니다. 32GB 서버에서 다른 서비스들과 함께 운영하기에는 과도한 양이었기 때문에, 이를 3~4GB 수준으로 낮춰 다른 프로그램들이 사용할 여유 공간을 확보했습니다.

3. 메모리 부족 경보 시스템 도입 ✅ 적용 완료

메모리 사용량이 일정 수준을 넘으면 관리자에게 자동으로 알림이 오는 시스템을 구축했습니다. 서버가 위험한 상태에 접어들기 전에 미리 조치를 취할 수 있게 됩니다.

4. 서버 모니터링 강화 ✅ 적용 완료

10분 단위로 CPU/메모리 사용량을 기록하는 시스템을 정기적으로 검토하는 체계를 갖췄습니다. 이상 징후를 조기에 발견해 장애로 이어지기 전에 대응할 수 있도록 했습니다.

마치며

이번 장애는 서버 관리자인 제가 서버 전체의 메모리 사용량 합계를 충분히 점검하지 않은 채 새로운 서비스들을 올린 결과입니다. 특히 4월 25일 하루에 두 번이나 장애가 발생한 것은, 첫 번째 재부팅 후에도 근본 원인이 해결되지 않았기 때문입니다.

위에서 말씀드린 대책들은 모두 이미 적용을 완료했습니다. 자커마스를 믿고 이용해 주시는 분들께 다시 한번 사과드리며, 더 안정적인 서비스를 제공할 수 있도록 노력하겠습니다.

감사합니다.

— 유메카