하나의 GIF 파일이 Discourse 백업 실패를 초래한 이유
Discourse 플랫폼의 한 포럼을 백업하던 중 기이한 사건이 발생했습니다: 동일한 1.6 MB GIF 파일이 246,173번이나 복제된 것입니다. 이로 인해 백업 크기가 377 GB나 부풀어 오르고 Linux 파일 시스템이 손상되어 백업 프로세스가 완전히 중단되었습니다. 문제는 코드 버그가 아니라 플랫폼의 보안 아키텍처와 ext4 파일 시스템의 제한 때문이었습니다.
하나의 파일이 수십만 개 복사본으로 불어난 이유
Discourse는 "안전한 업로드" 메커니즘을 사용합니다. 파일이 서로 다른 컨텍스트(예: 개인 메시지에서 공개 게시물로) 사이로 이동할 때마다 시스템은 고유한 SHA1 해시를 가진 새 복사본을 생성합니다. 파일 내용이 동일하더라도 플랫폼은 이를 별개의 객체로 취급합니다. 이는 보안 정책을 강제하고 미디어 파일에 대한 무단 접근을 막기 위해 필수적입니다.
인기 GIF—TV 쇼 Friends의 춤추는 레이철—의 경우 사용자들이 다양한 토픽, 댓글, 개인 메시지에 반복적으로 삽입했습니다. 새로운 컨텍스트에서 사용할 때마다 데이터베이스 항목과 디스크상의 새 파일이 생성되었는데, 바이너리 내용은 완전히 동일했습니다.
첫 번째 최적화 시도: 하드 링크
Discourse 팀은 백업 중 콘텐츠 해시에 따라 파일을 그룹화하는 솔루션을 개발했습니다. 중복 그룹마다 하나의 물리적 복사본만 유지하고 나머지는 그에 대한 하드 링크로 대체했습니다. 이 접근법은 백업 크기를 급격히 줄였고 대부분의 인스턴스에서 잘 작동했습니다.
그러나 대형 클라이언트 포럼에서 테스트한 결과 ext4 파일 시스템에 제한이 있음이 드러났습니다: inode당 최대 약 65,000개의 하드 링크입니다. 246,173개의 중복에서 제한에 도달하자 시스템은 새로운 물리적 복사본을 생성하기 시작했습니다—중복이 아니라 독립 파일로요. 결국 하나의 복사본 대신 ~181,000개의 추가 파일이 생겨 문제를 부분적으로만 해결했습니다.
최종 솔루션: 링크와 복사본 간 동적 전환
새 솔루션은 파일 시스템 제한을 고려해 모든 환경에서 작동합니다:
- 기존처럼 하드 링크 생성부터 시작합니다.
- Linux 커널로부터
EMLINK오류("링크가 너무 많음")를 받으면 로컬 파일 복사로 전환합니다. - 새 복사본이 후속 링크의 "기본"이 되고, 다음 제한에 도달하면 사이클이 반복됩니다.
이 접근법은 파일 시스템 조정이 필요 없고 모든 POSIX 준수 OS와 호환되며 극단적인 중복 수에서도 백업 크기를 효과적으로 줄입니다.
예제 처리 로직(간략화):
if hard_link_fails_with_emlink?
create_new_physical_copy
reset_link_counter
end주요 교훈
- 보안 vs. 효율성: 컨텍스트 격리를 위한 아키텍처 선택이 대규모에서 예상치 못한 부작용을 일으킬 수 있습니다.
- 파일 시스템 제한은 현실입니다: ext4의 inode당 65K 하드 링크 같은 저수준 제한이 고수준 앱을 방해할 수 있습니다.
- 범용 솔루션이 더 낫습니다: OS 오류에 적응하는 적응형 알고리즘은 이상 조건을 위한 정적 최적화보다 신뢰할 수 있습니다.
- 인기 콘텐츠가 부하를 유발합니다: 자주 쓰이는 미디어 파일(이모지, 반응, 밈)이 숨겨진 자원 소모원입니다.
- 프로덕션 데이터 테스트가 핵심입니다: 실제 사용 시나리오만 이런 엣지 케이스를 드러냅니다.
분산 시스템 개발자를 위한 교훈
Discourse 사건은 데이터 보안과 저장 효율성의 고전적 딜레마를 보여줍니다. 사용자 생성 콘텐츠를 다루는 시스템을 설계할 때 다음을 고려하세요:
- 디스크 쓰기 전에 애플리케이션 수준 중복 제거.
- 파일 수와 중복 관련 메트릭 모니터링.
- 시스템 제한 도달 시 우아한 저하.
문제는 하나의 GIF 대량 사용에서 비롯됐지만, 뿌리는 아키텍처 트레이드오프에 있습니다. Discourse 팀이 찾은 솔루션은 유사한 도전에 직면한 다른 프로젝트의 모범이 될 수 있습니다.
— Editorial Team
아직 댓글이 없습니다.