AWS S3 (NCP Object Storage)
in DevOps
본 글은 부스트캠프에서 정적 이미지 파일을 저장하기 위한 방법을 학습하기 위해 작성한 게시글입니다.
1. 오브젝트 스토리지
1.1. 정의
- 클라우드에서 일반적으로 사용되는 계층 없는 데이터 저장 방법
- 다른 데이터 스토리지 방법과 달리, 디렉터리 트리를 사용하지 않음
- 개별 단위(오브젝트)가 스토리지 풀의 동일한 레벨에 있음
- 각 오브젝트에는 애플리케이션에서 검색하는 데 사용되는 고유 식별자가 있음
- 각 오브젝트는 함께 검색되는 메타 데이터를 포함할 수 있음
1.2. 특징
관계형 데이터베이스와 같은 트리 형태로 저장되는 것이 아닌, 파일 단위로 어딘가 저장해두고 그 주소만 발급받으면 쉽게 접근할 수 있는 느낌
1.3. 일반적인 사용
이미지는 오브젝트 스토리지에 넣어서 빠르게 저장, 접근하고 나머지 메타 데이터는 연관성 있는 정보와 함꼐 관계형 데이터베이스에 저장하는 형식으로 많이 사용됨
2. 데이터베이스에 이미지를 저장하지 않는 이유
MySQL에 이미지를 저장 시 일반적으로, BLOB(Binary Large Object) 타입으로 DB에 저장됨
⇒ 기본적으로 binary string으로 취급
2.1. 발생하는 문제점
2.1.1 비용 문제
- 이미지를 BLOB으로 저장하게 된다면 url을 저장하는 것보다 차지하는 용량이 큼 ⇒ 백업 용량도 커짐
- Amazon RDS for MySQL(시간 당)과 S3를 비교했을 때 S3(GB 당)가 비용이 저렴한 듯
- Amazon RDS for MySQL 비용 : https://aws.amazon.com/ko/rds/mysql/pricing/
- Amazon S3 비용 : https://aws.amazon.com/ko/s3/pricing/?nc=sn&loc=4
2.1.2. 속도 문제
- 이미지 로딩속도가 상대적으로 느림 (고해상도, 고용량일 수록 더 체감됨)
- 병목 현상이 발생할 수 있음
2.1.3. 확장성 문제
- 관계형 데이터베이스는 이미지와 같이 크기가 큰 데이터를 관리하게 되면 순식간에 규모가 커지게 됨
- 관리가 어려워짐
- 규모가 커질 경우 확장성 면에서 불리할 수 있음
- 데이터 타입 자체를 다루기 어렵지는 않음
2.2. MySQL에 이미지를 저장(DB에 바로 이미지를 저장하는 경우)하고자 한다면…
- 아래 세가지의 경우에는 고려해볼 수 있음
- 모든 데이터의 백업을 한 번에 모아서 해야 할 때
- 잦은 수정이 없고 소량의 고정된 이미지를 사용하는 경우
- 보안 관련 이슈 : ex) 개인 회원 반명함판 사진같은 것들은 image에 암호화 해서 저장할 수 있음
3. Amazon Simple Storage Service (S3)
3.1. S3란
- 온라인 스토리지 서비스
- 온라인이 붙는 이유 : 데이터 조작에 HTTP/HTTPS를 통한 API가 사용되기 때문
- REST, SOAP와 같은 단순한 웹 서비스 인터페이스를 사용함
3.1.1. 사용하는 이유
서비스 내에서 유저가 유동적으로 이미지를 선택하고, 이 이미지에 대한 조회가 잦아지는 경우 모든 걸 서버에 넣어 두기는 현실적으로 어렵고, 관리 또한 까다로움
3.1.2. 특징
- 최대 99.999%의 내구성
- 99.999%의 가용성이라는 높은 신뢰성
- 용도에 따른 미세한 접속 관리를 통한 안정성 확보
- 사실상 무제한적인 용량 (저장하는 데이터 양에 대한 비용도 저렴하고, 저장할 수 있는 데이터 양이 무한에 가까움)
3.1.3. 용도
- FTP처럼 단순한 파일 저장 영역으로 사용할 수도 있으며, 다양한 AWS 서비스의 사용 로그 저장, 정적 웹 사이트 호스팅 기능 등을 가지고 있음
- EBS 스냅샷의 저장 영역으로도 사용 (비용 체계와 사용 방법이 다르긴 함)
- 빅데이터 분석의 데이터 소스로 활용하거나 On-Premise 환경의 재난복구 전용 데이터 백업, Auto Scaling을 활용한 EC2 인스턴스의 로그 저장 등으로 폭 넓게 활용됨
3.2. S3의 개념
- 버킷(Bucket)이라는 컨테이너를 놓을 리전을 선택하고, 해당 컨테이너 내부에 객체(Object)라는 형태로 데이터를 저장
- 버킷은 여러 개 만들수 있으며, 버킷 단위로 접근 제한을 설정할 수도 있음
- 객체의 최대 크기는 5TB이며, 저장할 수 있는 수에 제한은 없음
- 추가로 객체를 그룹화하는 디렉터리를 생성할 수 있음
- 따라서 파일 서버처럼 디렉터리를 계층화해서 객체를 저장할 수 있음
3.2.1. 버킷(Bucket)
- 생성 시 default는 private
- 한 계정 당 최대 100개의 버킷 사용 가능
- 버킷 소유권은 이전할 수 없음
- 버킷의 이름은 region에 상관없이 globally unique 해야함
- 버킷 주소는 https://s3-리전이름.amazonaws.com/버킷이름
- S3 데이터 모델은 flat structure라서 버킷에 hierarchie나 folder는 없음
- 하지만 keyname prefix (Folder1/Object1)를 사용해서 논리적인 hierarchies를 암시할 수 있음
- 버킷 안에 다른 버킷을 둘 수 없음
- Access Control
- Bucket Policies
- Access Control Lists
- Path-Style URL에서 버킷 이름은 Region specific endpoint를 사용하지 않는 이상 도메인명에 포함되지 않음
- Virtual Hosted Style URL에서 버킷이름은 URL의 도메인명의 일부가 됨
- Virtual hosting은 HTTP Host Header를 사용해서 REST API 콜의 버킷을 address하는 데 사용될 수 있음
3.2.2. 객체(Object)
- Object level storage(not a Block level storage)
- 객체 하나의 크기는 1Byte ~ 5TB
- 저장 가능한 객체 갯수 무제한
- 객체마다 각각의 접근 권한 설정 가능
- default로 private
- 객체 metadata는 객체가 업로드 된 후에는 수정될 수 없고, 복사해서 수정해야 함
- 객체는 Range HTTP header를 이용해서 부분적으로 검색할 수 있음
- 객체는 Pre-signed url를 사용해서 다운로드 할 수 있음
- 객체의 metadata는 response header에 반환
3.3. S3의 스토리지 옵션
3.3.1. 표준 스토리지
- 지정한 1년 동안 99.999%의 견고성과 99.99%의 가용성을 제공
- 2개의 거점에 데이터를 제공
- 데이터 손실이 발생해도 데이터가 유지되게 설계
- 심각할 정도로 요금을 확실하게 낮춰야 한다는 경우가 아니라면 일반적으로 표준 스토리지를 사용함
3.3.2. Reduced Redundancy Storage(RRS)
- 지정한 1년에 99.99%의 견고성과 99.99%의 가용성을 제공
- 단일 시설에서 데이터 손실을 막게 설계되어 있음
- 주로 요금 절감을 해야할 목적일 때 RRS를 사용
3.4. 장점
- S3는 저장 용량이 무한대이고 파일 저장에 최적화되어 있음
- 용량을 추가하거나 성능을 높이는 작업이 필요 없음
- 비용은 EC2와 EBS로 구축하는 것보다 훨씬 저렴
- S3 자체가 수천 대 이상의 매우 성능이 좋은 웹 서버로 구성되어 있어서 EC2와 EBS로 구축했을 때 처럼 Auto Scaling이나 Load Balancing에 신경쓰지 않아도 됨
- 동적 웹페이지와 정적 웹페이지가 섞여있을 때 동적 웹페이지만 EC2에서 서비스하고 정적 웹페이지는 S3를 이용하면 성능도 높이고 비용도 절감할 수 있음
- 웹하드 서비스와 비슷하지만, 별도의 클라이언트 설치나 ActiveX를 통하지 않고 HTTP 프로토콜로 파일 업로드/다운로드 처리
- S3 자체로 정적 웹서비스 가능
3.5. 제공하는 기능
3.5.1. S3 암호화
- S3에 데이터를 저장할 때는 데이터를 자동으로 암호화하는 서버 사이드 암호화(SSE)를 활용할 수 있음
- S3에서 객체를 생성하거나 속성을 변경할 때 암호화 옵션을 지정하면, 자동으로 모든 것이 이루어짐
- 이때 암호화 방식은 AES-256 알고리즘으로 구현되었으며, 다음 3가지 패턴 중에서 키 관리 방식을 선택할 수 있음
- S3 Managed Keys : SSE-S3 (Amazon S3 키관리)
- AWS Key Management Service, Managed Keys : SSE-KMS (AWS KMS)
- Customer Provided Keys : SSE-C (클라이언트 키)
- 이때 암호화 방식은 AES-256 알고리즘으로 구현되었으며, 다음 3가지 패턴 중에서 키 관리 방식을 선택할 수 있음
3.5.2. S3 접근 관리
- 버킷 정책, ACL, IAM 제어로 분류
- 버킷 정책 : 버킷 단위로 접근 제어
- ACL : 객체 단위로 접근 제어
IAM : 사용자 단위로 접근 제어
항목 버킷 정책 ACL IAM 제어 AWS 계정 단위 제어 ○ ○ X IAM 사용자 단위 제어 △ X ○ S3 버킷 단위 제어 ○ ○ ○ S3 객체 단위 제어 ○ ○ ○ IP 주소/도메인 단위 제어 ○ X ○
3.5.3. S3 이벤트 알림
- S3 버킷, 객체에서 이벤트가 발생했을 때, 다음과 같은 이벤트 알림을 보낼 수 있음
- SNS 토픽으로 메시지 발행
- SQS 큐에 메시지 생성
- Lambda의 Lambda Function으로 알림
- S3에서 지원하는 이벤트로 PUT, POST 메서드로 인한 객체 생성, 덮어쓰기, 복사, 멀티 파트 업로드 완료, Reduced Redundancy Storage(RRS) 내부의 객체 삭제 등이 있음
3.5.4. **S3의 웹 호스팅 기능**
- 정적 콘텐츠를 제공하는 웹 호스팅 기능도 제공
- 정적 콘텐츠 배포는 일반적인 S3 사용과 마찬가지로 S3 버킷에 저장하기만 하면 됨
- 추가로 S3의 정적 웹 사이트에는 S3의 자체적인 도메인이 할당되는데, Route53 등의 도메인 이름 서비스(DNS)를 사용해서 다른 도메인을 부여할 수 있음
- 이러한 때는 호스팅하는 버킷 이름과 도메인 이름을 맞춰줘야 함
- 동적 웹 콘텐츠 호스팅은 Elastic Beanstalk 또는 EC2를 활용하며, Ruby, Pyhon, PHP, Perl 등을 사용한 동적 콘텐츠 웹 호스팅은 불가능
4. NCP Object Storage
4.1. NCP Object Storage란
- Object Storage는 사용자가 언제 어디서나 원하는 데이터를 저장하고 탐색할 수 있도록 파일 저장 공간을 제공하는 서비스
- 제공되는 API는 Amazon S3와 호환되므로 Amazon S3를 활용한 일반 도구(Third-party 도구)를 사용해 스토리지를 관리
4.2. NCP Object Storage 활용 예제
[nest.js] AWS s3 bucket 에 파일 여러개 업로드 + rest api 만들기
React, express, NCP를 활용한 파일 업로드 및 접근 (1)
Javascript용 AWS SDK - Amazon S3 API 활용 예제
추가하면 좋을 내용
- 이미지를 저장하는 시점은 언제가 좋을까?
- 이미지를 처음 선택 할 때 (ex: 이미지를 드래그 앤 드롭 했을 때)
- 이미지에 관련된 DB의 정보를 추가 및 수정할때 (ex: 회원 정보를 추가 및 수정 했을 때)
