[멘토링] 이미지 스토리지 용량 산정 방식 검증(답변희망멘토: jaws.bar)

[brixxt27]

🙋질문자

판교 3기 / 16조(카토피아) - jayoon.yoon(윤재상)/클라우드

🙋답변 희망 멘토

jaws.bar 멘토님 / @park0503

궁금한 내용

서비스의 이미지 스토리지 용량 산정 방식과 브라우저 단 리사이징 전략이 적절한지 검증받고 싶습니다.

산정 목적

• MAU 100명 / DAU 30명 기준, 월간 이미지 데이터 누적 저장 용량 예측
• 브라우저 단 리사이징을 통한 스토리지 최적화 및 서버 부하 감소

기능별 이미지 규격 및 용량

구분	리사이징 규격	예상 용량 (장당)	비고
게시물 이미지	1080 × 1440 (3:4)	약 0.5 MB	가로 1080px 기준 고정
프로필 이미지	400 × 400 (1:1)	약 0.1 MB	가로 400px 기준 고정

최대 업로드 허용 용량: 30MB (브라우저 리사이징 후 서버에는 위 규격으로 저장)

월간 예상 저장 용량 산출

A. 게시물 이미지

• 일간 게시물 생성 건수: 30명(DAU) × 0.2건 = 6건/일
• 일간 업로드 이미지 수: 6건 × 3장 = 18장/일
• 일간 소요 용량: 18장 × 0.5 MB = 9 MB/일
• 월간 누적 용량: 9 MB × 30일 = 270 MB/월

B. 프로필 이미지 (고정 점유 데이터)

• 회원가입 초기 등록 (신규): 100명(MAU) × 1장 = 100장/월
• 프로필 수정 시 처리: 기존 이미지 삭제 후 신규 이미지 교체 (Overwrite 방식)
• 월간 소요 용량: 100장 × 0.1 MB = 10 MB (누적 증가 없음)

산정 근거: 프로필 수정은 'Overwrite(삭제 후 생성)' 방식으로 설계하여 스토리지의 무분별한 증가 방지. 등록률 100% 가정으로 보수적 산출.

최종 산출 결과

• 첫 달 전체 저장 용량: 270 MB (게시물) + 10 MB (프로필) = 280 MB/월
• 이후 월간 증가량: 약 270 MB/월 (프로필은 초기 저장 후 용량 변경 없음)
• 분기(3개월) 누적 예상: 약 820 MB (≈ 0.8 GB)

인프라 설계 반영 사항

1. 데이터 관리: 프로필 이미지 업데이트 시 기존 파일 삭제 로직(Garbage Collection) 반드시 포함
2. 스토리지 할당: 로그 및 DB 백업 포함하여 EC2 EBS 10~20GB로 운영 가능
3. 네트워크 설정: Nginx client_max_body_size 30MB 유지하여 업로드 유연성 확보
4. 한계 분석: MAU 10,000명 증가 시 월간 약 29GB 필요 → V2 단계에서 S3 Lifecycle Policy 도입 검토

구체적 질문

1. 리사이징 규격의 적절성

   • 게시물 이미지 1080 × 1440 (3:4) 규격이 모바일/웹 최적 사이즈인가요?
   • 프로필 이미지 400 × 400이 충분한 해상도인가요?
   • JPG/JPEG 포맷이 최선인가요? (WebP 등 최신 포맷 고려?)

2. 용량 산정의 정확성

   • 1080 × 1440 이미지를 0.5 MB로 가정한 근거가 적절한가요?
   • 실제 JPG 압축률에 따라 용량 편차가 클 수 있지 않나요?
   • 게시물당 이미지 3장 가정의 합리성은?

3. 브라우저 단 리사이징 전략

   • 클라이언트 리사이징의 장단점은? (품질 저하, 클라이언트 부하 등)
   • 서버 단 리사이징 대비 실제 성능/비용 이점이 있나요?
   • 리사이징 실패 시 fallback 전략은?

4. 스토리지 관리 전략

   • Overwrite 방식의 프로필 이미지 관리가 모범 사례인가요?
   • 게시물 삭제 시 이미지 파일 삭제 정책은? (용량 산정에 미반영)
   • EC2 EBS 10~20GB가 충분한가요? (로그, 백업 고려 시)

5. 확장성 고려

   • MAU 10,000명 시 29GB/월 예측의 근거는?
   • S3 Lifecycle Policy 외 다른 대안(CDN, 이미지 서버 분리 등)은?

시도한 방식

1. 이미지 용량 조사

   • 다양한 해상도의 JPG 이미지 용량 샘플링
   • 1080 × 1440 기준 약 0.5 MB, 400 × 400 기준 약 0.1 MB 산출

2. 트래픽 기반 이미지 생성량 계산

   • 게시물 작성 0.2건/일 × DAU 30명 = 6건/일
   • 게시물당 이미지 3장 가정 (멀티 이미지 업로드 지원)

3. 프로필 이미지 관리 방식 설계

   • Overwrite 방식으로 스토리지 증가 최소화
   • 100% 등록률 가정으로 보수적 산정

4. 인프라 요구사항 계산

   • 3개월 기준 0.8 GB → EBS 10~20GB로 충분 판단
   • Nginx 최대 업로드 30MB 설정

문제점

• 실측 데이터 부족

  • 이미지 용량이 압축률/내용에 따라 크게 변동 가능
  • 게시물당 이미지 3장이 실제 사용 패턴과 맞는지 불확실

• 브라우저 리사이징 검증 부족

  • 품질 저하 정도 미측정
  • 다양한 디바이스/브라우저 호환성 미확인
  • 실패 시나리오 미고려

• 삭제 정책 미반영

  • 게시물 삭제 시 이미지 파일 처리 방안 누락
  • 고아 파일(orphan files) 발생 가능성

• 확장성 분석 부족

  • MAU 증가 시 선형적으로 용량 증가한다고 가정
  • CDN, 객체 스토리지 전환 시점 기준 불명확

이제 어떻게 하려고 하는지?

1. 멘토님께 검증받고 싶은 부분

   • 전체적인 스토리지 용량 산정 방식의 타당성
   • 브라우저 단 리사이징 전략의 적절성과 대안
   • 이미지 관리 정책(Overwrite, 삭제 등)의 모범 사례
   • 누락된 고려사항 및 리스크 요인

2. 개선 방향 고민 중

   • 실제 이미지 업로드 테스트로 용량 분포 측정
   • 브라우저 리사이징 vs 서버 리사이징 성능/품질 비교
   • 게시물/이미지 삭제 시 Garbage Collection 정책 수립
   • S3 + CloudFront 도입 시점 및 마이그레이션 계획

3. 기대하는 도움

   • 이미지 스토리지 산정의 정확도 개선 방안
   • 실무에서 검증된 이미지 처리/저장 아키텍처 조언
   • 초기 EBS → S3 전환 시점 판단 기준
   • 모니터링 시 주의할 메트릭 (용량, I/O 등)

추가 참고자료

• AWS EBS 용량 계획: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html
• S3 Lifecycle Policy: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html
• 이미지 최적화 가이드: https://web.dev/fast/#optimize-your-images
• #스토리지용량산정 #이미지최적화 #리사이징 #EBS #S3 #용량계획 #인프라설계

[brixxt27]

@park0503
기존에 정해진 형식과 달리 하나의 게시물에 세 개의 질문을 올려 이를 나눴습니다.
감사합니다.

[park0503]

이미지 스토리 용량 산정은 아키텍처 구성에 꼭 필요한 부분이라 생각합니다. 좋은 접근인 것 같아요.

저장 용량은 MB 단위까지 너무 디테일하게 예측하려 하지 않으셔도 됩니다. 여유 있게 크게 잡는 걸 추천드리구요. EBS의 경우 제가 써보진 않아서 잘 모르지만 용량 제한이 있어 보입니다. 10, 20 GB 단위는 추후 확장성을 생각할 때 충분하지 않아보여요. 처음 단계부터 S3를 고려해 봐도 문제 없을 것 같습니다. 나중에 마이그레이션 오버헤드가 생각보다 클 확률도 크구요.

자세한 이야기는 내일 멘토링 때 이어나가면 좋을 것 같습니다.

[brixxt27]

피드백

• 아이폰 사진으로 할 거면 이미지 변환이 필요할 거다. 아마 사파리에서만 보일 듯.
• 이미지 리사이징 서버를 따로 둬도 된다.
  • 지금 당장은 괜찮지만 유저의 반응이나 경험과 관련 있다.
  • 너무 느려지면 서버 나누는 거 생각해보란 이야기.
• 구글 analysis 붙이고 분석하기
• 원본을 저장을 할지도 더 생각해보기
  • 내가 생각해본 시나리오처럼 목록과 상세 조회 시 사진 퀄리티가 다를 수도 있다. 그러니 고려해봐!