#개발 #기술블로그 #동아리 #ACC #AWS #S3 #CloudFront #인프라 #infra #백엔드 ![[ACC_Storage.pdf]]  # Cloud Storage란? - `정의` 데이터와 파일을 인터넷에 저장할 수 있는 클라우드 컴퓨팅 모델 - `사용 방법` 퍼블릭 인터넷 / 전용 프라이빗 네트워크 연결을 통해 액세스 - `장점` - 비용 효율성 - 민첩성 향상 - 더 빠른 배포 - 효율적 데이터 관리 - 확장성 - `종류` - File Storage - `정의` 데이터를 파일 단위의 계층 구조로 저장하는 데이터 스토리지 - `특징` - 애플리케이션에 가장 널리 사용 - 직접 데이터 관리 (서버 기능도 수행) $\to$ NFS, NAS 기술 사용 가능 - 로컬 하드 드라이브와 유사한 접근 방식 - **[[Amazon EFS]]** - `사용 사례` - 여러 서버, 사용자가 동일한 파일 시스템에 동시 접근하는 경우 - 파일, 디렉토리릍 통해 데이터를 관리하고 싶은 경우 - 네트워크를 통한 파일 공유가 필요한 경우 - Block Storage - `정의` 물리적 하드웨어 (HDD, SSD) 와 비슷한 역할 - `특징` - 데이터를 Block 형태로 Read & Write - 이때 빠른 Read & Write를 위해 Block에 고유한 식별자 `ID#` 를 부여해서 사용 - 백업 기능을 제공하기도 함 $\to$ SAN 역할 - **[[Amazon EBS]]** - Object Storage - `정의` 대용량 미디어 파일, 이미지, 백업 등의 비정형 데이터를 저장하기 위한 스토리지 - `특징` - **전송된 형식 그대로를 객체 데이터로** 저장 - 사용자가 직접 메타데이터 지정 가능 - 객체는 **보안 버킷**이라는 저장 공간에 저장 - HTTP 프로토콜 기반 REST API 호출을 통해 접근 - **Amazon S3** - `사용 사례` - 정적 웹 컨텐츠(이미지, 비디오, HTML)를 호스팅할 경우 - 전 세계 여러 데이터센터에 데이터를 분산시키는 경우 - 저렴한 비용으로 데이터를 오래 보관하는 경우 # Amazon S3  - `정의` 데이터를 버킷 내 객체로 저장하는 객체 스토리지 서비스 - `특징` - 파일을 하나의 객체로 저장 $\to$ Key를 통해 관리 - `확장성` 저장 용량 신경 X - `데이터 보호` 버전 관리, 암호화, 복제 기능 - `비용 효율성` 사용한 만큼만 비용 지불 - 즉, **다량의 데이터를 안전하게 저장할 수 있다** - 비즈니스 요구에 맞게 데이터에 대한 접근 제어 *(e.g., ACL, IAM 정책)* - `구성` 버킷 & 객체 - `버킷` 최상위 디렉토리 - `객체` 디렉토리 내에 저장되는 파일 ## Bucket - `정의` S3에 저장된 객체에 대한 컨테이너 = 폴더? - `특징` - 객체를 무제한으로 저장 가능 - 한 계정당 최대 100개의 버킷 생성 가능 - AWS 전역에서 **단 하나만 존재**, 리전과 관계 없이 **전역적으로 유일한** 이름 사용 ## Object - `정의` S3에 저장되는 기본 개체 = 파일? - `특징` - 객체는 하나 이상의 버킷에 저장, 각 객체의 크기는 최대 5TB - 객체 데이터 + 메타 데이터로 구성 - `Key`와 `버전 ID`로 버킷 내에서 고유하게 식별 - `구성 요소` - Key - 객체에 할당한 이름. 객체 키를 사용하여 객체를 검색. - Value - 저장하는 콘텐츠. 객체 값은 임의의 바이트 시퀀스. - Version ID - 버킷 내에서 키와 버전 ID를 사용하여 각 객체를 고유하게 식별 가능함. 버전 ID는 버킷에 객체를 추가할 때 Amazon S3가 생성하는 문자열. - Metadata - 객체 관련 정보를 저장하기 위한 이름-값 페어의 세트. Amazon S3의 객체에 사용자 정의 메타데이터라고 하는 메타데이터를 지정 가능. Amazon S3는 이러한 객체의 관리에 사용되는 시스템 메타데이터를 객체에 지정. - Tag - 태그를 사용하여 액세스 제어 또는 비용 할당을 위해 저장된 객체를 분류 가능. - 액세스 제어 정보 - Amazon S3는 ACL(액세스 제어 목록), 버킷 정책 등의 리소스 기반 액세스 제어와 사용자 기반 액세스 제어를 모두 지원. - Amazon S3 리소스(예: 버킷, 객체)는 기본적으로 비공개. 명시적으로 권한을 부여해야 다른 사용자가 이러한 리소스에 액세스 가능. - `URL 형식` - `https://awsinaction.s3.ap-southeast-2..amazonaws.com/img/cat.png` - `awsinaction` Bucket Name - `s3.ap-southeast-2..amazonaws.com` Region - `/img/cat.png` Key name - `보안` - `데이터 암호화` - `서버 측 암호화` - `정의` 서버가 데이터를 자동으로 보호해주는 기능 - `방식` - `"x-amz-server-side-encryption": "AES256"` 설정해서 요청 - 업로드 시 AWS가 데이터를 대신 암호화해서 저장 - 다운로드 시 자동으로 복호화해 원래 상태로 반환 - **[[SSE-S3]]** - [[SSE-KMS]] / [[DSSE-KMS]] / [[SSE-C]] - **현재는 서버 측 암호화(SSE-S3)를 S3 내 모든 버킷 암호화의 기본 수준으로 적용** - `클라이언트 측 암호화` - `정의` 전송 및 저장 시, 보안을 보장하기 위해 로컬에서 데이터 암호화 - AWS를 포함한 제3자에게 객체 노출 방지 가능 - `방식` - S3 암호화 클라이언트를 사용해 객체 암호화 - 버킷에 업로드 - 즉, S3 암호화 클라이언트가 사용자-S3 간 중개자 역할 - `특징` - 높은 보안 보장 - 관리, 구현 복잡성 증가 - `액세스 제어` - `IAM` - `정의` 사용자를 생성하고 **사용자의 버킷 권한** 액세스 관리 - `사용자/역할 기준` 누가 무엇을 할 수 있나? - 자신의 계정 내의 IAM 사용자를 단위로 해 액세스 제어 - IAM Policy 적용 범위는, 자신의 AWS 계정 내의 - IAM User - IAM Group - IAM Role - 접근하려는 출발지 IP 주소나 도메인명에 의한 액세스 제어도 가능 - `ACL` - `정의` 권한이 있는 사용자에 대해 **간단한 개별 오브젝트를 액세스 가능하게** 만듦 - `계정 기준` 어떤 계정이 접근할 수 있나? - AWS 계정 단위로 액세스 권한 설정 - 다른 AWS 계정에 대해 객체, 버킷에 대한 읽기/쓰기 허용 - `버킷 정책` - `정의` 단일 S3 버킷 내 모든 객체에 대한 권한을 세부적으로 구성 - `버킷/객체 기준` 이 버킷에 누가 접근할 수 있나? - Bucket 단위로 액세스 권한 설정 - 자신의 AWS 계정의 IAM 사용자 / 또 다른 AWS 계정의 IAM 사용자에 대해 S3 리소스 액세스 권한 설정 - 접근하려는 출발지 IP 주소나 도메인명에 의한 액세스 제어도 가능 - `CORS(Cross-Origin Resource Sharing)` [[CORS]] - `정의` 교차 출처 리소스 공유 - 일종의 협약 - 출처가 교차한다 = 리소스를 주고받으려는 '두 출처가 서로 다르다' - CORS를 설정한다 = '출처가 다른 서버 간의 리소스 공유'를 허용한다 - `Access-Control-Allow-Origin` 헤더 사용 - `Pre-signed URL` - `정의` 임시 URL을 사용하여 다른 사용자에게 기간 제한 (임시 권한) 액세스 부여 - 임시 URL 지정 $\to$ TIMEOUT! - S3 접근 권한이 없는 이용자 대상 - Pre-signed 임시 URL 지정, 일정 시간 후 public 접근 불가 - 단, URL 생성자가 **유효한 보안 자격 증명 + 허용하려는 작업 권한** 보유하고 있어야 함 - `스토리지 관리` - `버전 관리` - 한 버킷에 여러 버전의 객체 보관 $\to$ 실수로 삭제되거나 덮어써진 객체 복원 가능 - 버전 관리 활성화 시, 저장되는 객체에 대해 고유한 Version ID 자동 생성 - 단, 한 번 활성화하면 비활성화 불가 - 각 버전은 독립적으로 존재 - `객체 복제` - 하나 이상의 대상 버킷에 대한 객체를 **동일한 리전 or 다른 리전**에 비동기적으로 자동 복제 - `종류` - `SRR` S3 동일 리전 복제 - `효과` 같은 리전에 있으므로 *로그 집계, 계정 간 라이브 복제, 액세스 제어* - 로그 집계: S3 access log / CloudFront log / ALB log 같은 건 보통 **여러 버킷에 분산 저장되는데**, SRR 걸어두면 `[서비스별 로그 버킷들] → (SRR) → [중앙 로그 버킷]` 이런 식의 동작 가능해짐. 즉, 로그가 생성되는 순간 중앙 버킷으로 모임 - 계정 간 라이브 복제: SRR은 같은 리전이지만 **계정은 달라도 됨** - 액세스 제어: 복제 시점에 ownership / ACL / KMS를 바꿀 수 있음 - `CRR` S3 리전 간 복제 - 서로 다른 리전 버킷에서 새 객체 복제 - `효과` 대기시간 최소화, 운영 효율적 - `S3 배치 복제` 기존 객체를 *온디맨드*로 다른 버킷에 복제 - `효과` 데이터 안정성과 운영 효율성 향상! - `클래스` - S3 버킷의 각 객체에는 그와 연결된 **스토리지 클래스** 존재 - 사용자는 **사용 사례 & 요구사항에 맞게** 스토리지 클래스 선택 - `종류` Access Frequency 기준 Frequent $\to$ Infrequent [[S3 Storage Class]] - `S3 Standard` 자주 접근 - `S3 Intelligent-Tiering` 접근 패턴이 불확실 - `S3 Standard-IA` 가끔 접근하지만, 빠른 조회 필요 - `S3 One Zone-IA` 복구 가능. 비용 줄이고 싶을 때. - `S3 Glacier Instant Retrieval` 거의 안 쓰지만, 즉시 조회 필요. - `S3 Glacier Flexible Retrieval` 몇 분 ~ 몇 시간 기다려도 될 때 - `S3 Glacier Deep Archive` 거의 접근 안 할 때. 최저 비용 저장 가능. - `수명 주기` - `정의` 객체를 효율적으로 저장 & 관리하기 위해 S3 객체 그룹에 적용할 작업을 정의하는 수명 주기 구성 - `종류` - `전환 작업` - 객체가 다른 스토리지 클래스로 전환되는 시기 정의 - *e.g.,* - 30일 지나면 S3 Standard-IA, - 60일 지나면 S3 Glacier Instance Retrieval로 옮기기 - `만료 작업` - 객체가 만료되는 시기 정의 - 만료되면? S3가 해당 객체 자동 삭제 # Amazon CloudFront  ## 개념 ### CloudFront란? - `정의` CDN (글로벌 콘텐츠 전송 네트워크) 서비스 - 짧은 지연 시간 + 빠른 전송 속도로 데이터, 동영상, 애플리케이션, API를 전세계 고객에게 안전하게 전송 - 기본 보안 기능 제공 ### [[CDN]]이란? - `정의` 콘텐츠 전송 네트워크 - 콘텐츠를 효율적으로 전달하기 위해 여러 서버에 데이터를 분산시켜 캐싱 - **원본 서버 위치와 상관없이, 사용자에게 더 가까이 있는 서버로부터 캐싱된 컨텐츠 배포 $\to$ 빠름!** - *e.g., 영국 웹사이트를 미국에서 접근하려면? 미국 근처 ISA에서 배포!* ### Edge Location: CloudFront의 콘텐츠 제공 방식 - `정의` 사용자에게 더 가까운 지리적 위치에 콘텐츠를 저장하는 Origin Server의 **Caching Server** - `방식` - 사용자 요청 발생 시, - 지연 시간이 가장 적은 Edge Location으로 Routing ### REC (Regional Edge Caches) - `정의` Origin Server - Edge Location 사이에 존재하는 **캐시 계층** - Edge Location에서 캐시하지 않는 콘텐츠 저장 - Edge Location에서 캐시 Miss $\to$ - Origin Server X - REC O $\to$ 빠름 ### Origin Server - `정의` 데이터의 원본이 위치한 곳 - `역할` static contents & dynamic contents 모두 처리 - `static contents` - `정의` EC2 서버가 필요로 하지 않는 콘텐츠 - e.g., 이미지 - S3 Bucket (기본) - `dynamic contents` - `정의` 서버가 필요로 하는 콘텐츠 - e.g., 로그인 자료, 실시간 추가 자료 - dynamic contents를 정적 캐싱한다면 TTL 시간 동안 사용자는 새로 추가 or 수정된 데이터를 볼 수 없음 - EC2 Instance, ELB (Elastic Load Balancing) ## CloudFront 동작 방식 1. 클라이언트 $\to$ Edge Server 요청 2. Edge Server: 해당 데이터 캐싱 여부 확인 3. 동작 1. 캐시 사본이 있다면 1. 사용자에게 응답 2. 캐시 사본이 없다면 1. Origin Server로 포워딩 2. Edge Server에 캐싱 데이터 생성 3. 사용자에게 응답 ## CloudFront 기능 1. HTTPS 지원 1. origin에서 HTTPS 지원하지 않아도 알아서 HTTPS 통신을 해줌 2. 인증키 설치 등의 작업이 불필요 $\to$ 간편함! 2. 특정 지역 콘텐츠 접근 제한 1. 지리적 제한이 가능함 1. e.g., 회사 사정으로 특정 지역을 제한하고 싶을 때 사용 3. Signed URL 1. S3 pre-signed URL과 비슷한 기능 2. 허용된 사용자에게만 접근할 수 있는 signed url 제공 1. e.g., 유료결제를 한 사용자에게만 동영상 URL 제공 3. 하나의 콘텐츠에만 사용 가능 4. 접근 허용 사용자를 정해둠 $\to$ signed url 생성 $\to$ 사용자 검증 $\to$ URL 제공 4. Signed Cookie 1. 다수의 파일에 대한 access 제공 (다수의 파일 - 하나의 signed cookie) 2. 만료 시간, IP 주소 범위 등 지정 1. e.g., ID/PW를 입력해 로그인한 유료 회원에게 유료 콘텐츠를 모두 제공 3. 로그인 $\to$ 인증정보 기반 cookie 발급 $\to$ 이 cookie를 포함해 보내면 인증 완료! ![[ACC_Storage_핸즈온.pdf]]