파일 관리 서비스 2 - S3 폴더 구조 설계

S3(스토리지) 폴더 구조 설계하기

스토리지에 파일을 저장할 때 다양한 기준으로 폴더 구조를 설계 하여 저장 할 수 있다.

S3는 내부적으로 데이터를 파티셔닝하여 분산 저장하는데, 우리가 할 수 있는 폴더 구조, prefix 등을 잘 활용하여 설계 할 수록 성능적인 이점 뿐만 아니라 관리 자체를 효율적으로 할 수 있다. 

설계 방법에 대한 규칙의 특징이 대해 알아본다.

 

날짜 기반 구조 (Date-Based Structure)

예시

• 2024/08/18/files/...
• 2024/08/17/files/...
• ...
• 2022/05/19/files/...

특징

• 백업, 로그 파일, 일별/월별 데이터 저장 관리시 적절
• 날짜 기준 데이터 조회시 폴더 구조가 명확해져 검색 성능 개선
• 단 files/ 아래에 파일들이 많을 때는 추가 규칙 prefix 등이 필요

 

서비스(=도메인) 기반 폴더 구조 (Service Based Structure)

예시

• service-A/images/...
• service-A/uploads/...
• service-A/images/users/...
• ...
• service-B/images/...
• service-B/uploads/...
• service-B/images/users/...

 

 

특징

• 서비스 (도메인, 객체)간 분리하여, 파일에 대한 충돌(다른 서비스 파일간 같은 이름의 파일이 존재 가능) 및 권한 관리가 보다 용이
• 만약 서비스별 사용자(/users/) 구분 필요시 추가적인 Folder 뎁스가 필요할 수 있음
• '서비스 단위의 데이터'를 유지보수 하고 관리하기가 용이
• 추가적인 하위 폴더 구조 고려시 유효한 폴더 구조인지 (너무 데이터가 없지 않은) 혹은 데이터가 잘 분산되었는지 확인

 

유저 기반 구조 (User Based Structure)

예시

• user-1/images/...
• user-2/documents/...
• user-3/images/service-A/...
• user-4/images/service-B/...

 

특징

• 사용자 별 데이터 구분시, 권한 및 접근 관리에도 용이 
• 마찬가지로 유저 안에서 서비스 별로 추가 뎁스가 필요할 수 있음
• 추가적인 하위 폴더 구조 고려시 유효한 폴더 구조인지 (너무 데이터가 없지 않은) 혹은 데이터가 잘 분산되었는지 확인

 

파일 유형 기반 구조 (File-Type Based Structure)

예시

• documents/txt/...
• images/png/...
• videos/mp4/...
• logs/server/...

 

특징 

• 유형별로 일괄 작업 처리 필요시 등에 유용
• 스토리지 최적화: 파일 유형별로 다른 스토리지 클래스(S3 Standard, S3 Glacier 등)를 적용하여 비용 효율적인 저장소 관리 가능

 

결론 - 혼합형 구조 (Hybrid Structure)

예시

• services/{service_id}/users/{user_id}/images/... : 서비스 -> 유저별로 구분 -> 이미지 파일 관리
• services/{service_id}/logs/2024-08-17/files/... : 서비스 -> 로그 -> 날짜별 로그 관리
• users/{user_id}/service-A/images/... : 유저 -> 서비스 A -> 이미지 파일 관리
• users/{user_id}/service-B/images/... : 유저 -> 서비스 B -> 이미지 파일 관리

 

사실 가장 이상적인 설계 방법은 앞서 나온 구조 방법들을 잘 혼합 하여, 각 특장점을 누릴 수 있게 유연하게 설계 하고, 추가 요구사항에 대해 확장성도 고려 하도록 하는 것. 비용, 보안, 성능 관리 용이성 등을 고려하여 설계 하는 것이 중요

 

주요 고려 사항

• 권한 관리 ↑ : 폴더 구조에 따라 IAM 정책을 적용하여 사용자 또는 서비스별로 접근 권한을 세분화 가능
• 네이밍 컨벤션 : 폴더/파일명 작성시 prefix 등을 적용하여 관리를 용이하게 하고 성능면에서도 최적화 가능
• 비용 최적화 : 파일 유형이나 성격에 따라 S3 Standard / S3 Glacier 같은 스토리지 클래스를 폴더별로 구분해 비용 최적화 가능
• 폴더 깊이 최적화 : 너무 깊은 폴더 구조는 오히려 성능을 저하시킬 수 있어, 적절한 깊이를 유지하여야 함
• 균형 잡힌 파티셔닝 : 각 파티션에 너무 많은/적은 데이터가 몰리지 않도록, 파티션을 적절히 나누는 것이 중요
• Prefix 균형화 : AWS S3는 동일한 프리픽스(Prefix)에서 너무 많은 요청이 발생하면 성능이 저하될 수 있습니다. 이를 방지하기 위해 데이터가 다양한 프리픽스로 분산되도록 설계해야 합니다.
• 폴더명/파일명 Prefix hash화 : 보안 및 경로 노출 방지 역할 + 객체 키(Key)에 기반한 데이터 분산으로 파일명에 hash를 활용시 균형 잡힌 데이터 분산이 될 가능성이 높아짐

 

S3 폴더 정리 - Before / After

기존에 S3 데이터를 특정 A폴더에 하위 구분 없이 다 저장 해두고 있었고, 다음과 같이 변경하였다.

 

<변경 전>

• service_A (service_A는 service_a, service_b, service_c .. 등을 포괄)
  • user_id
    • 파일명_시간

 

<변경 후>

• service_a
  • user_id (해시값) : user 한 뎁스 아래에 다 둔 것은 데이터가 비교적 적어서
    • 파일1 (해시값)
    • 파일2 (해시값)
    • ...
• service_b
  • user_id_1 (해시값)
    • service_b_id_1 (해시값) : user 와 서비스의 두 depth를 둔 것은 데이터가 많아서
      • 파일1 (해시값)
      • 파일2 (해시값)
      • ...
    • service_b_id_2 (해시값)
      • 파일1 (해시값)
      • 파일2 (해시값)
      • ...

• •  

 

1) 서비스 기반 구조 방식으로 a,b,c로 나누고 하위에 유저 기반을 구성

2) 파일 명들의 hash 화를 통해 균등 파티셔닝 및 URL 노출 등의 보안 대비

3) 서비스적으로 데이터가 너무 많아질 수 있음을 대비하여, 필요시 유저 기반(user_id) 하위 폴더 외에도 추가적인 서비스 기반(service_id) 폴더 뎁스를 추가로 두어 폴더간 파티셔닝 되어 성능 개선을 고려