Strapi 설계 정리
컬렉션 → 여러 데이터를 가지는 모델 → 레스토랑[이름, 카테고리], 포스트[제목, 내용]
싱글 → 단일 데이터만 가지는 모델 → 웹 - 웹소개
컴포넌트 → 재사용 가능한 모델 → 포스트, 리뷰, [제목, 내용]
이미지 저장 & 전달 방식
저장될 이미지가 많기 때문에 클라우드 상에서 확장과 데이터 보존을 위해 s3 버킷을 활용한다.
이때 버킷은 비공개 상태로 유지하고자 한다.
이미지 저장 방식
비공개된 버킷에 접근하기 위해서는 권한이 필요하다.
하지만 권한을 클라이언트 측에서 사용하고자하면 악의적인 유저에게 권한과 엑세스키를 다 털릴 수 있기 때문에 함부로 권한을 설정할 수 없다.
보안을 챙기면서 권한을 설정하고자하면 역할이 서버에서 할당되어야 하며 클라이언트 → 서버 → 버킷으로 가는 구조를 갖게 되는데 이렇게 되면 이미지를 s3로 저장하는데만 서버 자원이 낭비될 수 있다.
따라서 private s3에 직접 저장을 할 수 있으면서 클라이언트에게 직접적인 권한을 주지않고 설정하고자 한다면 s3 pre-signed url이 필요하다.
구조를 정리하면 서버에 upload가 가능한 pre-signed url을 생성하게 된다. 그것을 클라이언트에게 전달하고 클라이언트는 해당 pre-signed url을 통해 직접 업로드하게 된다. 이후 url은 바로 만료된다.
이 방식은 개발, 프로덕션 환경 모두 동일하다고 생각하지만 비용 효율적인 생각을 했을 때 개발 환경에선 용량을 제한하거나, 업로드가 잘 되는지 확인만 할 수 있도록 제어해야겠다.
만약 민감한 정보를 저장해야하거나 보안을 더 신경써야 한다면 가이드 참고하면 좋을거같다.
Uploading objects with presigned URLs - Amazon Simple Storage Service
Uploading objects with presigned URLs You may use presigned URLs to allow someone to upload an object to your Amazon S3 bucket. Using a presigned URL will allow an upload without requiring another party to have AWS security credentials or permissions. A pr
docs.aws.amazon.com
AWS S3 presignedURL을 이용해서 image Upload 하기
presigned URL을 이용한 S3 image 동적 업로드 가이드입니다. 😁
velog.io
이미지 전달 방식
s3에 저장하게 되면 필연적으로 네트워크 비용을 고민하게 된다.
왜냐하면 인터넷에 대용량의 파일들을 전송하게 되면 요금 폭탄을 맞을 수 있기 때문인데 이 같은 상황을 해결하기 위해 CloudFront같은 CDN((Content Delivery Network)을 사용하며 성능과 보안성을 더 높일 수 있다.
일단 CloudFront를 제외하고 클라이언트에서 어떻게 이미지를 사용할 수 있을지를 고민해보면, 위 방식과 마찬가지로 pre-signed url을 사용하는 방식이 있다.
최소 권한의 원칙에 따라 이땐 읽기만 할당하여 객체에 대한 pre-signed url을 생성하고 만료시킨다. 다만 이렇게 생성하게 되면 관리하기도 힘들고 특정 상황(해외유저)시 비용이 많이 청구될 수 있다.
하지만 CloudFront를 활용한다면 CDN에 저장된 이미지는 굳이 pre-signed url을 발급받을 필요 없다 서버 설정을 CloudFront로 옮겨 설정하고 CloudFront를 거쳐야만 s3에 접근 가능한 OAI를 적용하면 캐싱된 이미지는 빠르게 전송이 가능해지며, AWS 사설 네트워크를 사용하기 때문에 비용을 아낄 수 있고 s3는 private성격과 보안을 유지할 수 있다.
동시에 Route53과 연결하여 도메인 주소를 할당 할 수 있다.
이 또한 자료가 많으니 쉽게 참고하면 된다.
개발 단계 아키텍쳐 정리
s3 버킷과 인스턴스를 연결 하는 것을 목표로 인프라를 구축하면 되고 개발 단계이기 때문에 데이터베이스를 구축하진 않았다.
sqlite를 활용하고 있지만 문제가 많기 때문에 추후에 구조를 수정하고 RDS를 추가할 예정이다.
또한 개발 환경에서 많은 비용을 사용할 순 없으니 가급적이면 제한을 걸어두려 한다.
마지막으로 인스턴스에서 객체 정보를 사용할 거 같아서 VPC 엔드포인트를 열어두었다.
프로덕션 단계 아키텍쳐 정리
확장을 고려하여 기본적인 설계를 하였다.
ALB 혹은 CloudFront가 추가되는 것은 어디까지나 성능과 장애 없이 배포할 수 있도록 하기 위함이고 비용적으로 고려할 게 많기 때문에 최대한 비용 효율적으로 구성하고자 했다.
동시에 클라우드 내부 기본적인 것들만 신경써서 분리하였다.
'TIL > 트러블슈팅' 카테고리의 다른 글
| i18n을 위한 데이터베이스 설계 고민하기 (0) | 2023.10.28 |
|---|---|
| CI/CD 구성하면서 발생한 문제들 (0) | 2023.08.01 |
| KPT 회고로 프로젝트 실패 회고하기 (0) | 2023.04.01 |
| 클라이언트와 서버 포트로 인해 발생했던 보안 그룹 문제 (0) | 2023.03.27 |
| NestJS 코드 리팩토링 하기 (0) | 2023.03.21 |