리얼스에서 "프렌즈"의 레이첼 춤 GIF 클립이 수백 기가바이트로 성장해 디스코스 백업을 붕괴시켰다

디스코어는 현재 22,000개가 넘는 커뮤니티를 보유한 온라인 토론 플랫폼입니다.

최근 사이트 백업 중 하나의 GIF 파일(1.6 MB)이 사용자에 의해 246,173번 복사되어 ext4 파일 시스템에서 허용하는 하드 링크 한계(≈65,000)를 초과했고, 백업 크기가 377 GB로 급증했습니다.

아래는 상황 분석, 원인 및 해결책을 자세히 설명합니다.

1. 무엇이 일어났나요?
- 디스코어 플랫폼은 이모지와 GIF 파일을 모든 게시물에 삽입할 수 있게 해줍니다.
- 파일을 한 컨텍스트에서 다른 컨텍스트(예: 개인 채팅 → 공개 포스트)로 이동하면 시스템은 무작위 SHA‑1 해시를 가진 새 복사본을 만듭니다. 내용이 동일해도 디스코어는 이를 새로운 객체로 간주합니다.
- 따라서 같은 GIF가 수만 개의 게시물과 채팅에 나타나며, 매번 별도의 파일이 생성됩니다. 결과적으로 246,173개의 복사본이 ext4 한계를 초과하고 시스템은 하드 링크 대신 새 파일을 만들기 시작해 백업 크기가 급증했습니다.

2. 첫 번째 해결책 – 해시 기반 정리
- 디스코어는 먼저 SHA‑1 해시별로 업로드를 그룹화하려 했습니다.
1) 백업 시 동일한 해시의 파일들을 한 그룹으로 모음.
2) 각 그룹에서 최초 복사본만 저장.
3) 나머지는 하드 링크 생성.
- 이 방식은 우아해 보였지만 ext4의 링크 수 제한을 고려하지 않았습니다. 한계에 도달하면 시스템이 자동으로 새 파일을 만들었고 백업 크기가 급증했습니다.

3. 새로운 해결책 – EMLINK 오류 시 전환
- 디스코어는 보다 유연한 전략을 개발했습니다.
1) 일반적으로 하드 링크를 생성합니다.
2) 파일 시스템이 EMLINK(링크 수 초과) 오류를 반환하면, 다음 복사본을 “기본” 파일로 지정합니다.
3) 이후 새 링크는 이 새로운 기본 버전을 가리키게 됩니다.
- 이렇게 하면 한계가 초과될 때마다 새로운 ‘부모’ 파일로 전환되어 시스템이 에러 없이 계속 동작합니다. 이 방법은 모든 파일 시스템에서 호환되며 추가 설정이 필요 없습니다.

4. 결론 및 시사점
- “프렌즈”의 레이첼 댄스 GIF 한 개가 백업 크기를 377 GB로 증가시켰습니다.
- ext4의 약 65,000개의 하드 링크 제한이 핵심 문제였습니다.
- 첫 번째 해시 기반 해결책은 파일 시스템 제약을 무시해 데이터 손실을 초래했습니다.
- EMLINK 오류 시 전환 전략은 대량 복사본을 효과적으로 관리하고 백업 효율성을 유지합니다.

> “지금 우리는 제니퍼 애니스턴이 인프라스트럭처를 스트레스 테스트할 수 있다는 것을 알게 되었습니다.” — 디스코어가 블로그에 아이러니로 적었습니다.