블로그 서버 장애 회고

블로그 서버 장애 회고

안녕하세요. 최근 며칠간 블로그 접속이 원활하지 않았던 점에 대해 먼저 양해의 말씀을 드립니다.

지난 포스팅에서 언급했듯, 이 블로그는 Ubuntu 기반의 로컬 서버 위에 Rails 8 애플리케이션을 올리고, Docker 컨테이너와 Cloudflare Tunnel을 연결해 외부 트래픽을 처리하는 구조로 운영되고 있었습니다.

직접 홈 서버를 구축해 서비스를 운영하는 것은 개발자로서 즐거운 경험이었지만, 이번에 물리적인 하드웨어 장애라는 예상치 못한 난관을 마주하게 되었습니다.

사건의 발단

잘 돌아가던 서버가 갑자기 응답하지 않게 된 원인은 단순하면서도 치명적인 하드웨어 고장이었습니다. 클라우드 인스턴스가 아닌 집에 있는 물리 장비를 서버로 사용하다 보니, 장비 자체의 노후화나 전원 문제 등 물리적 리스크에 그대로 노출되어 있었던 것입니다.

단순히 서버가 꺼진 것이라면 재부팅하면 그만이었겠지만, 부팅 자체가 불가능한 상황이 되면서 블로그 서비스 전체가 중단되었습니다.

문제 해결

가장 큰 걱정은 그동안 작성해 둔 글들이었습니다. 특히 일본장기(쇼기) AI 연구나 강화학습 관련 글들은 다시 작성하기 어려운 소중한 기록들이었기에 식은땀이 흘렀습니다.

다행히 스토리지 자체는 무사했고, 고장 난 장비에서 디스크를 추출하여 기존 Rails 8 애플리케이션의 데이터베이스(SQLite3) 볼륨 데이터를 확보할 수 있었습니다. 이를 기반으로 복구 작업을 진행했고, 현재 보시는 것처럼 모든 게시글과 데이터를 손실 없이 되살려냈습니다.

교훈

이번 일을 겪으며 "데이터베이스 백업의 중요성"을 다시 한번 뼈저리게 느꼈습니다. 로컬 서버는 비용 효율적이고 자유도가 높지만, 단일 장애 지점(SPOF)이 명확합니다. 하드웨어가 죽으면 데이터도 함께 위험해질 수 있다는 사실을 간과하고 있었습니다.

향후 계획

이번 장애를 계기로 인프라 구조를 변경하려고 합니다. 지금처럼 데이터베이스를 로컬 서버 내부에 두는 방식은 리스크가 너무 크다고 판단했습니다. 따라서 향후에는 클라우드 기반의 관리형 데이터베이스(Managed DB) 혹은 별도의 클라우드 스토리지로 DB를 이전하여, 로컬 서버 하드웨어가 고장 나더라도 데이터는 안전하게 보존되고 서비스 복구가 즉시 가능한 구조로 개편할 예정입니다.

비 온 뒤에 땅이 굳어진다고 합니다. 이번 장애는 Rails 8과 서버 운영에 대해 한 수 더 배우는 계기가 되었습니다. 앞으로는 더 안정적인 환경에서 꾸준히 글을 올리도록 하겠습니다.

Previous Post

Rails 블로그에서 다단계 캐싱 전략 구현하기

Concern 패턴과 Rails.cache를 활용하여 중복 쿼리를 제거하고 페이지 로딩 속도를 10-15% 개선한 최적화 과정에 대해 이야기합니다.

Rails 블로그에서 다단계 캐싱 전략 구현하기

Next Post

가상 시착(VTON) 모델 최적화 과정

가상 시착 프로젝트 진행 중 겪었던 OmniTry 모델의 리소스 및 UX 이슈를 분석하고, 이를 FastFit 아키텍처 도입을 통해 해결한 과정에 대해 이야기합니다.

가상 시착(VTON) 모델 최적화 과정
scroll to top