서버 이중화의 함정: 엑스박스로 변해버린 내 웹사이트 썸네일 구출 작전

👤 인스피

조회 수 13

1. 악몽의 시작: 과거의 미디어 파일이 모두 엑스박스가 되다

클라우드플레어 로드밸런서와 터널 설정을 마치고, 오라클 클라우드 서버에 파이썬 백엔드(FastAPI) 코드를 성공적으로 배포했습니다. "이제 메인 서버가 죽어도 끄떡없다!"라고 환호하며 사이트에 접속한 순간, 제 눈을 의심할 수밖에 없었습니다.

텍스트로 된 게시글은 멀쩡하게 잘 나오는데, 과거에 유저들이 올려두었던 수많은 썸네일과 본문 이미지들이 모조리 '엑스박스(X표시)'로 깨져서 나오고 있었기 때문입니다. 등줄기에 식은땀이 흘렀습니다. '설마 데이터베이스를 마이그레이션 하다가 30GB가 넘는 소중한 미디어 파일들을 다 날려버린 건가?' 하는 끔찍한 생각이 스쳐 지나갔습니다.

하지만 침착하게 테스트를 해보던 중, 아주 결정적인 단서를 하나 발견했습니다. 과거의 글들은 이미지가 다 깨지는데, 방금 막 새로 테스트 삼아 업로드한 게시글의 이미지는 아주 정상적으로 잘 보인다는 것이었습니다. 데이터가 날아간 것이 아니라, 무언가 논리적인 연결 고리가 끊어졌다는 확신이 들었습니다.

2. 원인 파악: 두 개의 뇌, 물리적 저장소의 분리(Split-Brain)

문제의 원인은 바로 서버 인프라 구조 그 자체에 있었습니다. 서버를 이중화한다는 것은 '코드를 실행하는 컴퓨터(서버)'를 2대로 늘린다는 뜻입니다.

트래픽 분산 처리에 의해 제 브라우저의 요청은 새로 구축한 오라클 클라우드(예비 서버)로 향했습니다. 오라클 서버의 백엔드는 데이터베이스에 접속해 "이 글의 썸네일은 uploads/image_123.png에 있습니다"라는 정보는 잘 가져왔습니다. 하지만 막상 오라클 서버의 하드디스크 내부 uploads/ 폴더를 뒤져보니 그 사진 파일이 없는 것입니다. 왜냐하면 그 30GB의 과거 사진 파일들은 메인 서버의 하드디스크에만 물리적으로 저장되어 있었기 때문입니다.

반대로 새로 업로드한 파일은 현재 트래픽이 연결된 오라클 서버의 하드디스크에 저장되었으니 정상적으로 보이는 것이 당연했습니다. 이렇게 여러 대의 서버가 각자의 로컬 스토리지에만 파일을 저장하고 서로 공유하지 못해 발생하는 데이터 불일치 현상, 이것이 바로 인프라 엔지니어들이 가장 경계하는 저장소 분리 문제입니다.

3. 해결책 1: 긴급 처방 (Rsync를 통한 과거 데이터 동기화)

당장 깨져있는 사이트의 엑스박스를 고치기 위해 첫 번째 긴급 처방을 내렸습니다. 메인 서버에 쌓여있던 30GB의 과거 미디어 파일들을 오라클 서버로 고스란히 복사해 주는 것입니다.

리눅스의 강력한 파일 동기화 툴인 rsync를 사용하면 이 작업을 백그라운드에서 아주 빠르고 안전하게 수행할 수 있습니다. 메인 서버 터미널에 접속하여 다음 명령어를 입력했습니다.

명령어를 실행하자 수만 개의 파일이 오라클 서버로 전송되기 시작했고, 동기화가 완료된 후 웹사이트를 새로고침하자 깨져있던 썸네일과 미디어 파일들이 마법처럼 다시 나타났습니다. 유저들에게는 장애 복구가 완료된 것이죠.

4. 해결책 2: 근본적인 아키텍처 개선 (Object Storage 분리)

하지만 rsync는 어디까지나 임시방편일 뿐입니다. 앞으로 사용자들이 메인 서버와 오라클 서버를 번갈아 가며 이미지를 업로드할 텐데, 매분 매초마다 두 서버의 폴더를 동기화시킬 수는 없는 노릇이니까요.

서버 이중화(Scale-out) 환경에서 미디어 파일을 처리하는 가장 근본적이고 우아한 해결책은, 웹 서버(Compute)와 저장소(Storage)를 완전히 분리하는 것입니다.

저는 로컬 서버의 uploads/ 폴더에 이미지를 저장하던 기존 파이썬 코드를 전면 수정했습니다. 유저가 이미지를 업로드하면, 백엔드 서버는 그 파일을 즉시 AWS S3나 Supabase Storage 같은 중앙 집중형 '오브젝트 스토리지(Object Storage)'로 전송해 버립니다.

이렇게 아키텍처를 바꾸면, 메인 서버든 오라클 서버든 이미지를 직접 가지고 있을 필요가 없습니다. 어떤 서버로 트래픽이 들어오더라도 모두 똑같은 중앙 스토리지(S3)를 바라보고 파일을 읽고 쓰기 때문에, 완벽한 무상태(Stateless) 아키텍처가 완성되고 스플릿 브레인 현상은 영원히 사라지게 됩니다.