Instagram Stories 디자인: 업로드부터 만료까지

Source: Dev.to

핵심 요구 사항

기능 요구 사항

• 사용자는 사진 또는 동영상 스토리를 게시할 수 있다
• 스토리는 24시간 후 자동으로 만료된다
• 가시성은 제한된다 (팔로워, 친한 친구, 연락처)
• 시청자는 스토리를 보고 반응할 수 있다

비기능 요구 사항

• 피드 로딩에 대한 낮은 지연 시간
• 높은 가용성
• 수평 확장성
• 최종 일관성(eventual consistency) 허용

고수준 아키텍처 (HLD)

전체적으로 시스템은 각각 단일 관심사를 담당하는 독립 서비스들로 분리된다:

• API Gateway – 인증, 인가, 라우팅, 속도 제한
• Story Service – 스토리 생성 및 수명 주기 관리
• Content Service – 미디어, 텍스트, 링크 처리
• Feed Service – 스토리 피드 생성
• Visibility Service – 프라이버시 및 대상자 적용
• Expiration Service – 24시간 TTL 처리
• Kafka & Background Workers – 비동기 처리
• Analytics & Notification Services – 참여 인사이트 및 알림

스토리 생성 흐름 (쓰기 경로)

사용자가 스토리를 게시할 때:

1. 클라이언트가 API Gateway를 통해 요청을 보낸다.
2. Content Service가 사전 서명된 업로드 URL을 반환한다.
3. 클라이언트가 미디어를 객체 스토리지(예: S3)로 직접 업로드한다.
4. Story Service가 24시간 만료 타임스탬프와 함께 메타데이터를 저장한다.

핵심 설계 결정: 미디어 업로드와 메타데이터 저장을 분리함으로써 쓰기 경로를 빠르고 확장 가능하게 만든다.

스토리 소비 흐름 (읽기 경로)

사용자가 스토리 트레이를 열 때:

1. Feed Service가 팔로우 중인 사용자들의 활성 스토리를 가져온다.
2. Visibility Service가 프라이버시 규칙에 따라 스토리를 필터링한다.
3. 만료된 스토리는 무시한다.
4. 미디어 URL이 클라이언트에 반환된다.
5. 클라이언트가 CDN에서 직접 미디어를 스트리밍한다.

이 설계는 스토리 사용량의 대부분을 차지하는 읽기 중심 트래픽에 최적화되어 있다.

가시성 및 프라이버시 규칙

스토리는 여러 가시성 모드를 지원한다:

• 팔로워 전용
• 친한 친구
• 연락처 기반 가시성(WhatsApp 상태)
• 차단된 사용자

전용 Visibility Service가 다음을 활용해 규칙을 적용한다:

• 팔로워/연락처 그래프
• 빠른 권한 검사를 위한 Redis 캐시

가시성 로직을 분리함으로써 일관된 프라이버시 적용과 향후 확장이 쉬워진다.

만료 및 수명 주기 관리

일시적인 콘텐츠는 일급 객체로 다뤄진다:

• 각 스토리는 엄격히 24시간 TTL을 가진다.
• Expiration Service가 스토리 타임스탬프를 모니터링한다.
• 만료된 스토리는 수명 주기 이벤트를 트리거한다.
• 만료된 콘텐츠는 더 이상 제공되지 않는다.

이는 높은 트래픽 상황에서도 정확성을 보장한다.

Kafka를 활용한 이벤트 기반 정리

Kafka는 수명 주기 이벤트와 정리 로직을 분리한다. 일반적인 이벤트 예시:

• story_created
• story_expired
• story_viewed
• story_reacted

Media Cleanup Worker가 만료 이벤트를 소비하고:

• 객체 스토리지에서 미디어를 삭제한다.
• CDN 참조를 제거한다.

정리는 비동기적으로 수행되어 사용자‑대면 API의 응답성을 유지한다.

참여 추적 (조회 및 반응)

사용자 참여는 별도 서비스에서 처리한다:

• View Tracking Service – 스토리 조회를 추적
• Reaction Service – 좋아요, 이모지, 답글

이 서비스들은:

• 매우 높은 쓰기 처리량을 감당
• 최종 일관성을 보장
• 피드 읽기 성능에 영향을 주지 않음

참여 데이터는 이후 분석을 위해 집계된다.

마무리 생각

스토리 시스템은 겉보기와 달리 복잡하다. 만료, 가시성, 확장성을 명시적으로 설계함으로써 탄력적이고 효율적이며 진화하기 쉬운 시스템을 구축할 수 있다. 이 설계는 Instagram 및 WhatsApp과 같은 플랫폼이 대규모 일시적 콘텐츠를 처리하는 방식과 매우 유사하다. 피드백 및 대안적인 접근법을 환영한다.