woongs dogfoot

Amazon SQS

• SQS Queue : Producer와 Consumer를 분리하는 buffer역할을 하는 메세지 저장소(?)

• Producer : SQS Queue에 메세지(ex. 명령 등)를 보내는 생산자

• Comsumer : SQS Queue에 있는 메세지를 수신하는 대상, polling 방식으로 Queue로부터 메세지를 가져옴 (Queue에게 수신자 대상의 메세지가 있는지 확인 후, 있으면 가져옴) -> 메세지 수신 후, Queue에서 해당 메세지 삭제
  
  
  

• Standard Queue

1. 가장 오래된 Queue
2. 완전 관리형 for decouple application
3. 무제한 처리량, 대기열 메세지 수도 제한 없음
4. 메세지는 수명이 짧음 -> 메세지는 기본적으로 Queue에 4일 동안 저장되고, 최대 14일까지도 유지됨 -> Consumer가 메세지 수명 기간안에 수신해야 함
5. 저지연 성능 -> 메세지 송신/수신 시간이 매우 짧음
6. 메세지 크기는 작아야 함 (< 256KB)
7. 동일 메세지가 여러번 송/수신 되는 경우가 있음 (중복 메세지 있을 수 있음)
8. can have out of order messages (best effort ordering) -> 메세지 수신 순서를 정할 수 있다는 말인 듯?
   
   
   

• Producing Messages

1. Producer(application)는 SQS로 메세지를 보내는 SDK를 통해 SQS Queue에 메세지를 보낼 수 있음
2. use case : 어떤 처리를 위한 오더 메세지를 보낼 수 있음 (처리에 필요한 값과 함께)

• Consuming Messages

1. Consumer는 application으로 EC2 인스턴스나 온프레미스, Lambda가 될 수 있음
2. polling방식으로 메세지 수신 -> consumer가 SQS Queue에 자신에게 온 메세지가 있는지 질의
3. 한번에 최대 10개까지의 메세지 수신
4. consumer가 메세지를 수신한 후, DB에 메세지의 값을 저장하는 등 처리를 완료하면 SQS Queue상의 해당 메세지를 삭제해야할 의무가 있음 (SQS SDK의 DeleteMessage API 활용)
5. Consumer를 여러개 가질 수 있음 -> 메세지를 먼저 수신한 Consumer가 메세지를 빠르게 처리하여 삭제하는 것이 아니라면 다수의 Consumer들이 메세지를 수신할 수 있음 -> 메세지 수신 순서를 정해야 함
6. Consumer를 늘리는 방식으로 처리량을 늘릴 수 있음

• SQS with Auto Scaling Group (ASG)
  : Queue의 길이(ApproximateNumberOfMessages, CloudWatch 지표 : Queue내 메세지 갯수)가 특정 기준을 넘으면 CloudWatch Alarm이 발생하도록 할 수 있음 -> 더 많은 양의 메세지 처리가 필요하기 때문에 ASG에 Alarm을 보내어 Scale-Out이 되도록 함 -> SQS의 메세지 처리량 증가 -> 축소도 가능

• SQS to decouple between application tiers
  : front에서 S3로 video처리를 바로 요청하여 받으면 느릴 수 있음 -> 아래 사진의 SQS + ASG 구조 적용, 더 좋은 성능의 Back 서버를 경유하게 하여 Video 처리 진행 -> 성능 개선
  
  
  

• SQS Security

1. HTTPS로 메세지를 보내고 수신함 -> 전송중 암호화 (SSE-SQS, SSE-KMS 두 가지 key 지원)
2. KMS키를 활용하여 전송중 암호화 가능
3. client에서 직접 암호화/복호화 가능 -> SQS에서 기본적으로 지원하는 기능은 아님
4. IAM 정책을 통해 SQS API로의 접근을 제어할 수 있음 (호출측? 제어)
5. S3 Bucket Policy와 같은 SQS Access Policy도 있음 -> 교차계정 접근이나 다른 서비스에서의 접근을 허용하는 데 유용함 (응답측? 제어)
   
   
   

Message Visibility Timeout

• Message Visibility Timeout : Consumer가 Queue의 Message받고 처리하기 시작했을 때부터 Visibility Timeout 시간동안 다른 Consumer가 Message를 수신할 수 없음 -> 다른 Consumer는 해당 시간동안 Message가 보이지 않음 (default : 30s)
• Visibility Timeout 시간이 지나고 Message가 삭제되지 않으면 다른 Consumer가 해당 Message를 수신하여 처리할 수 있게됨 -> 해당 시간 동안 처리되지 않으면 동일한 Consumer가 동일한 Message를 수신하거나, 다른 Consumer가 수신할 수 있게됨
• ChangeMessageVisibility API를 호출하여 더 많은 Visibility 시간을 확보할 수 있음

Long Polling

• Long Polling : Consumer가 Queue에 메세지를 요청했을 때, 메세지가 없을 경우 메세지가 Queue에 생성될 때까지 기다리는 것

• Long Polling시간은 1s~20s사이로 설정 가능
  
  
  

• 활용이유

1. 지연시간과 API호출을 줄이기 위해 활용
2. Long Polling중 메세지가 Queue에 수신되면, 해당 메세지를 Consumer가 저지연시간으로 빠르게 읽을 수 있음
   
   
   

• 활용방법

1. WaitTimeSeconds를 지정하여 Consumer가 스스로 Long Polling 진행
2. Queue레벨에서 Polling하는 아무 소비자가 Long Polling 진행할 수 있도록 설정함
   
   
   

FIFO Queue

• FIFO Queue : 선입선출 Queue로써, 기존 Queue보다 순서가 보장되는 Queue -> Consumer가 polling할 경우, 입력 순서대로 메세지를 수신함
• 순서를 보장하기 때문에 Queue처리량에 제한이 있음 (Batch성이 아닐 경우, 초당 300개 / Batch성일 경우, 초당 3,000개)
• 순서를 보장하여 정확히 한 번만 보내기 때문에 중복을 제거할 수 있음
• FIFO Queue의 이름은 뒤에 .fifo를 붙여줘야 함
• Content-based deduplication : 5분 이내의 짧은 시간동안 동일 메세지가 두 번 발송되었을 경우, 중복을 방지해주는 기능
• Message Deduplication ID : 같은 메세지 그룹 내 중복을 방지하기 위한 순서 key 값

SQS with Auto Scaling Group (ASG)

• SQS Scaling

• 사용 패턴
  : 광고 등의 이벤트 때문에 많은 양의 트래픽이 application에 몰리게 됨 -> 많은 처리량 때문에 DB로의 특정 트랜잭션에 에러가 발생되면 유실됨 -> 해결책으로 SQS를 사용할 수 있음 -> DB에 직접 붙는 것이 아닌 SQS에 메세지를 보내고, 다른 Consumer측 ASG가 이를 처리하게 하여 처리량 문제 해결 -> 많은 양의 트랜잭션을 처리할 수 있음 -> 트랜잭션 유실 우려 감소
• 조건 : client에 DB저장에 대한 결과를 응답하지 않아도 되는 경우에만 사용 가능 -> SQS Queue에 메세지를 전송했다는 것으로 대체할 수 있음

Amazon SNS (Simple Notification Service)

• Amazon SNS : 특정 서비스에서 여러 개의 타서비스로 연동이 필요할 때, 직접 붙는방식 대신 Pub/Sub 패턴을 이용하여 SNS Topic으로 메세지를 보내면, 해당 Topic을 구독하고있는 Consumer가 메세지를 수신하여 연동하게 하는 AWS 서비스 (SQS는 polling, SNS는 Topic 구독)

• 특징

1. event producer는 하나의 SNS Topic에만 메세지를 보냄
2. event receiver(subscriber)는 구독하고있는 Topic의 메세지를 수신함
3. Topic당 1,200만까지 구독자를 가질 수 있음
4. 계정당 가질 수 있는 Topic의 갯수는 최대 100,000개
   
   
   

• SNS에서 보낼 수 있는 Subscribers

• SNS로 알림을 보낼 수 있는 주체

• SNS 게시 방법 (SDK 활용)

1. topic 생성
2. 하나 이상의 구독자 생성
3. topic에 메세지 발행
   
   
   

• SNS 게시 방법 (mobile apps전용 SDK 활용)

1. application 생성
2. endpoint 생성
3. endpoint에 메세지 발행
4. 수신 가능 application : Google GCM, Apple APNS, Amazon ADM
   
   
   

• SNS Security

1. HTTPS로 메세지를 보내고 수신함 -> 전송중 암호화 (SSE-SNS, SSE-KMS 두 가지 key 지원)
2. KMS키를 활용하여 전송중 암호화 가능
3. client에서 직접 암호화/복호화 가능 -> SNS에서 기본적으로 지원하는 기능은 아님
4. IAM 정책을 통해 SNS API로의 접근을 제어할 수 있음 (호출측? 제어)
5. S3 Bucket Policy와 같은 SNS Access Policy도 있음 -> 교차계정 접근이나 다른 서비스에서의 접근을 허용하는 데 유용함 (응답측? 제어)
   
   
   

SNS + SQS : Fan Out

• Fan Out 패턴 : 다수의 SQS가 SNS의 Topic을 Subscribe하여 SNS에 수신된 메세지를 받고, SQS가 application에 메세지를 전달하는 방식 -> 특정 application이 직접 다수의 SQS에 붙어 메세지를 전송하면 유실가능성이 있음

• SQS의 기능 활용 가능 : 데이터 지속성, 지연처리, 작업재처리 등

• SQS Policy에 SNS의 write가 가능하도록 설정 필요

• 특정 Region의 SNS에서 다른 Region의 SQS에 메세지 전송 가능
  
  
  

• S3 Events to multiple queues
  : 다수의 SQS로 S3 Event를 전송하는 방법

• SNS to Amazon S3 through Kinesis Data Firehose
  : Kinesis Data Firehose를 활용해 SNS에서 S3로 데이터를 전송하는 방법

• SNS FIFO

1. SQS FIFO와 유사한 특징
2. 순서보장
3. 중복제거
4. SQS Standard와 FIFO 모두 Subscriber가 될 수 있음 (다른 서비스는 불가)
5. SQS FIFO와 동일 처리량
   
   
   

• Message Filtering
  : SNS Topic 구독자들에게 전송할 message를 filtering하는 JSON 정책 -> Filtering 기능이 없으면 모든 구독자들에게 모든 메세지가 전송됨

Amazon Kinesis

• Kinesis : 실시간 스트리밍 데이터(실시간으로 빠르게 생성되는 데이터, SNS/SQS와의 차이?)를 쉽게 수집하고 처리하여 분석할 수 있음 (application logs, metrics, iot 원격측정 데이터 등)
  
  
  

• types

1. Kinesis Data Streams : 데이터 스트림을 수집하여 처리
2. Kinesis Data Firehose : 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어들임
3. Kinesis Data Analytics : SQL이나 Apache Flink를 활용하여 데이터 스트림을 분석
4. Kinesis Video Streams : 비디오 스트림을 수집하고 처리하여 저장
   
   
   

Kinesis Data Streams

1. 데이터를 프로비저닝할 Shard를 설정해야 함 (갯수도 미리 설정)
2. Shard는 Stream의 용량 결정
3. 데이터 생산자는 SDK를 활용하여 Data Stream에 데이터 전송
4. Record : Data Stream에 전송되는 데이터의 단위
   • Partition Key : Record가 이용할 Shard를 결정
   • Data Blob : 데이터 자체, 최대 1MB
   • Sequence No : Shard내 Record의 위치
5. Shard마다 초당 천 개의 메세지 or 1MB를 보낼 수 있음
6. 데이터를 소비하는 방법
   • Shard마다 초당 2MB처리를 모든 Consumer가 공유
   • Consumer마다 Shard당 1초에 2MB씩 받을 수 있음
7. 데이터는 생산하는 과정 in CLI
   • Data Stream의 이름, partition key, data 3개의 파라미터로 데이터 저장 요청 (인코딩 타입도 설정 가능)
8. 데이터를 소비하는 과정 in CLI
   • Data Stream의 Shard 정보를 가져옴
   • Shard ID를 파라미터로 하여 읽을 데이터의 Shard Iterator를 가져옴 (shard-iterator-type 옵션을 통해 Iterator를 다르게 반환받을 수 있음)
   • 받은 Iterator로 해당 메세지 수신
   • 메세지와 함께 NextShardIterator를 수신하여 다음 요청 시, 다음 메세지부터 받을 수 있게 할 수 있음
9. Shard Iterator를 활용하여 특정 부분부터 데이터를 읽을 수 있음

• 특징

1. 1일~1년까지의 보존기간
2. 데이터를 보존기간내 다시 처리할 수 있음
3. 데이터 임의 삭제 불가 -> 불변성
4. partition key가 같으면 같은 Shard로 들어가고, 해당 key를 기반으로 데이터 정렬
5. Producer는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 사용하여 데이터 전송
6. Consumer는 SDK, Kinesis Client Library (KCL)를 사용하여 데이터 직접 수신 (Lambda나 Firehost같은 AWS 서비스도 활용 가능)
   
   
   

• Capacity Modes

1. Provisioned Mode
   • 위에서 설명된 특징 모두 적용 (처리량, API접근, Shard설정 등)
   • 한계 : Shard를 프로비저닝할 때마다 시간당 비용 부과
2. On-Demand Mode
   • 프로비저닝/용량관리 필요하지 않음 (자동으로 용량 조정되기 때문)
   • 언제든 용량 조정 가능
   • 초당 4MB 또는 4천개의 Record 처리
   • 30일 동안 측정된 최대 처리량에 기반하여 자동으로 용량 조정
   • 시간당 스트림당 송수신 데이터량(GB단위)에 따라 비용 부과
   • 사전에 사용량을 예측할 수 없을 때 유용
     
     
     

• Kinesis Data Streams Security

1. IAM Policy를 활용하여 Shard 생성 및 데이터 수신 접근 권한을 제어
2. HTTPS로 전송중 암호화
3. 미사용 데이터는 KMS로 암호화
4. Client 자체적으로 데이터 암/복호화 가능
5. VPC Endpoint 사용 가능 -> 인터넷을 거치지않고 private subnet의 인스턴스에서 이용 가능
6. 모든 API 요청은 CloudTail로 모니터링 가능

Kinesis Data Firehose

• Kinesis Data Firehose : 데이터스트림을 여러 source로부터 받아서 처리하고 Batch로 저장하는 방법을 제시함

• 데이터 제공 및 저장 유형

1. Amazon Service
   • Amazon S3
   • Amazon Redshift (웨어하우징 DB) -> 먼저 S3에 저장된 데이터 대상으로 Firehose에서 COPY명령을 내리면, Redshift 저장소로 S3의 데이터가 COPY됨
   • Amazon OpenSearch
2. third party
   • Datadog
   • Splunk
   • New Relic
   • mongoDB
3. Custom API (with HTTP)
   
   
   

• 특징

1. 데이터 저장 이후에 optional하게 모든 데이터 or 실패한 데이터를 백업으로 S3에 저장할 수 있음
2. 자동확장 및 서버리스 기능이 있기에 관리가 필요없는 서비스 (Data Stream과의 차별점)
3. Firehost를 통하는 데이터 대상으로만 요금 부과
4. 자체적으로 1MB단위로 데이터를 묶어서 저장하기 때문에 Near Realtime (완전 실시간x) -> 데이터가 완전히 묶이지 않을경우, 최소 60초의 지연 발생 -> Buffer 기능 활용
5. 데이터 포맷, 변환, 압축 지원
6. Lambda활용 데이터 변환 가능
7. Firehose내 데이터 저장 불가 (Data Stream과의 차별점)
8. Console의 Delivery Stream메뉴에서 설정 가능
   
   
   

• Data Stream vs Data Firehose

Ordering Data

• 사례 : 각각의 ID를 가진 트럭 100대가 도로위에 있고, 각 트럭은 GPS데이터를 AWS에 보내고 있다. AWS에서는 각 트럭의 데이터를 순서대로 받아 각 트럭의 이동을 정확하게 측정하려고 한다.
  
  
  

• Kinesis
  : Partition key를 트럭의 ID로 활용 -> 같은 Partition key일 경우, 동일 Shard로 데이터 전송 -> 특정 트럭 데이터는 동일 Shard에서 계속 처리가 됨 (Kinesis가 트럭의 partition key와 shard id를 해싱하는 방식)

• SQS
  : Group ID를 가지지 않는 한, SQS Queue의 message 소비는 순서가 보장됨

• 특정 그룹마다 연관된 메세지를 보내고 싶을 경우, Group ID 활용 (Group ID in SQS = Partition key in Kinesis) -> Consumer는 자신과 연관된 Group ID의 메세지만 수신

• Kinesis vs SQS (100개의 트럭, 5개의 Kinesis Shard, 1개의 SQS FIFO)

1. Kinesis
   • Shard당 평균 20개의 트럭
   • 각 Shard당 순서가 보장된 데이터
   • 최대 5개의 Consumer
   • 초당 5MB 데이터 수신
2. SQS
   • Only 1 SQS FIFO
   • 각 트럭 ID에 상응하는 Group ID 생성 -> 100개의 Group ID -> 최대 100개의 Consumer
   • 초당 300개의 메세지, 배치 사용 시 초당 3,000개의 메세지
     
     
     

SQS vs SNS vs Kinesis

Amazon MQ

• 온프레미스에서 기존 application을 실행하는 경우, MQTT/AMQP/STOMP/Openwire/WSS protocol 사용

• 온프레미스 application을 cloud로 마이그레이션 하는 경우, SNS/SQS를 사용하는 것이 아닌 기존 protocol을 사용하고 싶을 때 Amazon MQ를 사용하면 됨

• Amazon MQ : 관리형 메세지 브로커 서비스 (for RabbitMQ, ActiveMQ) -> RabbitMQ, ActiveMQ를 cloud에서 사용할 수 있음

• RabbitMQ, ActiveMQ : 개방형 프로토콜(ex. MQTT 등)로의 access 제공
  
  
  

• 특징

1. 확장성(scale)이 크지 않음
2. 고가용성을 위해 Multi-AZ 구축 필요
3. SQS/SNS의 일부 기능을 제공
   
   
   

• 고가용성
  : 장애조치의 저장소로 활용하기 위해 두 가용영역에 걸쳐 EFS 구축

AWS Snow Family

• AWS Snow Family : 보안성 있는 휴대기기 -> edge에서 데이터를 수집하고 처리하거나, 데이터를 AWS 안팎으로 마이그레이션

• Use cases

1. Data migration : 많은 양의 데이터를 제한없이 전송하기위한 경우 -> AWS에서 우편을 통해 물리적인 기기를 배송 -> 해당 기기에 데이터를 올리고 다시 AWS에 배송 (네트워크가 아닌 물리적 배송방식을 이용)
   • Snowcone
   • Snowball Edge
   • Snowmobile
2. Edge computing
   • Snowcone
   • Snowball Edge
     
     
     

• Snowball Edge

1. TBs or PBs 용량의 데이터를 AWS와 교환하기 위해 사용
2. 전송작업당 비용 지불
3. Storage Optimized : 80TB 하드디스크 용량 제공, block volume이나 S3 호환
4. Compute Optimized : 42TB 하드디스크 or 28TB NVMe 용량 제공
   
   
   

• Snowcone

1. 작은 휴대기기, 견고하고 안전
2. 열악한 환경에 강함
3. 가벼움, 드론탑재 가능
4. 8TB HDD or 14TB SSD 제공
5. 공간제약이 있는 경우 활용
6. 오프라인으로 데이터 전송 or 기기에 데이터를 담은 후에 인터넷을 통해 데이터센터에 연결 (AWS DataSync 서비스 사용, 사전 설치 되어있음)
   
   
   

• Snowmobile

1. 데이터를 옮기는 실제 트럭임
2. 1EB(1,000PB)급 데이터를 옮길 수 있음 (한 대당 100PB 가능, 1EB는 10대 필요)
3. 에어컨이 있어 온도조절 가능
4. 실시간 GPS 추적 및 비디오 감시

• Data migration을 위한 처리과정

1. AWS console에서 기기배송 요청
2. Snowball client or AWS OpsHub 설치
3. Snowball을 설치된 서버에 연결하고 파일복사 시작
4. 전자마커를 통해 목적지 AWS시설로 기기반송
5. S3 Bucket에 데이터 로딩
6. Snowball에서 데이터 완전삭제
   
   
   

• Edge Computing : Edge 위치에서 데이터를 생성하고 해당 데이터를 기기내 AWS인스턴스를 활용하여 처리한다음 AWS에 반송하는 case (Edge : 인터넷이 없거나 Cloud에서 멀리 떨어진 환경, ex. 도로 위 트럭, 바다 위 배, 지하광산 등) -> Snowball Edge, Snowcone 활용

1. 해당 Snowcone 기기들은 EC2 인스턴스와 Lambda Function 실행 가능 (AWS IoT Greengrass 서비스 활용)
2. 장기렌트 가능
   
   
   

• OpsHub : 컴퓨터에 설치하는 소프트웨어 -> Snow Device에 연결하고 설정할 수 있음, 파일전송 및 Snow Family의 인스턴스를 시작하고 관리 가능
  
  
  

• Snowball 데이터를 Glacier로 옮기는 방법

1. Snowball 데이터를 먼저 S3로 옮김
2. S3 lifecycle policy를 생성하여 object를 Glacier로 전환

Amazon FSx

• Amazon FSx : AWS에서 완전 관리해주는 서비스로 타사의 고성능 파일 시스템을 실행 (RDS에서 MySQL or Postgres를 실행하는 것과 동일개념)

• FSx for Windows File Server

1. SMB protocol과 Windows NTFS를 지원
2. 사용자 보안 추가, ACL로 Access 제어 가능
3. Linux EC2 인스턴스에도 Windows Fil Server 마운트 가능
4. DFS (Distributed File System)을 활용하여 File System 그룹화 가능 (온프레미스와 결합 가능)
5. 초당 수십GB, 수백만 IOPS, 수백PB 데이터 확장
6. SSD : 지연시간이 짧아야 하는 경우 (DB, 미디어 처리, 데이터 분석 등)
7. HDD : 비용이 저렴, 더 넓은 스펙트럼 (홈 디렉토리, CMS 등)
8. Private하게 온프레미스에서 접근 가능
9. Multi-AZ 가능
10. 재해복구 목적으로 S3에 매일 백업
    
    
    

• FSx for Lustre

1. Lustre (Linux + Cluster) : 분산 파일 시스템, 대량 처리 연산에 활용 (머신러닝, HPC 등)
2. 동영상처리나 금융모델링, 전자설계 자동화 등의 app에서 활용
3. 확장성이 높음
4. 초당 수백GB, 수백만 IOPS, ms보다 짧은 지연시간
5. SSD : 지연시간이 짧아야 하는 경우
6. HDD : 처리량이 많거나 크기가 큰 시퀀스 파일 작업에 활용하는 경우
7. FSx로 S3를 File System처럼 읽을 수 있음 (다시 연산 출력값을 S3에 쓸 수 있음)
8. VPN 및 직접 연결을 통해 온프레미스 서버에서 활용 가능
   
   
   

• FSx File System Deployment Options

1. Scratch File System
   • 임시 스토리지로 데이터 복제 x (파일 유실 가능성 있음)
   • High burst 사용 가능 (최적화로 성능을 높일 수 있다는 말, 200MBps per TiB)
   • 단기 처리데이터에 쓰임
   • 비용 최적화 가능
   • 추가 데이터 저장소로 S3 Bucket을 둘 수 있음
2. Persistence File System
   • 동일 AZ에 데이터복제됨
   • 민감 데이터의 장기 처리 및 Storage에 활용

• FSx for NetApp ONTAP

1. AWS 관리형 NetApp ONTAP File System
2. NFS, SMB, iSCSI Protocol 호환
3. 온프레미스의 ONTAP이나 NAS에서 실행중인 워크로드를 AWS로 옮길 수 있음
4. 스토리지는 자동으로 확장/축소됨
5. 복제 및 스냅샷 기능 제공
6. 저비용, 데이터 압축, 데이터 중복제거 가능
7. 지정시간 복제 기능 -> 신속한 복제 및 스테이징 File System 구축 가능
8. 호환 OS

• FSx for OpenZFS

1. AWS 관리형 OpenZFS File System
2. 여러 버전에서의 NFS Protocol과 호환 가능
3. ZFS에서 사용된 워크로드를 AWS로 옮길 때 사용
4. 최대 백만 IOPS, 지연시간은 0.5ms 이하
5. 스냅샷, 압축 기능 제공
6. 지정시간 동시 복제 기능 -> 새로운 워크로드 테스트 시에 유용
7. 호환 OS

AWS Storage Gateway

• AWS에서는 Hybrid Cloud 권장 (Hybrid Cloud : 일부는 AWS, 나머지는 온프레미스인 환경)

• Cloud Migration이 오래걸림

• 보안/규정 준수 요건이 있는 경우

• S3는 EFS/NFS와는 다른 Storage 기술 -> S3를 온프레미스에 연결하는 방법 고안 필요 -> AWS Storage Gateway 활용
  
  
  

• AWS Storage Cloud Native Options

• AWS Storage Gateway : 온프레미스 데이터와 클라우드 데이터 간의 다리역할
  
  
  

• Use cases

1. 재해복구 목적으로 온프레미스 데이터를 클라우드에 백업
2. 백업 및 복구 목적으로 Cloud Migration 및 Cloud간 Storage 확장 (Cloud엔 Cold Data, 온프레미스엔 Warm Data)
3. 파일 액세스 지연을 줄이기 위해 온프레미스 Cache 활용
   
   
   

• Storage Gateway Types

1. S3 File Gateway
2. FSx File Gateway
3. Volume Gateway
4. Tape Gateway
   
   
   

• S3 File Gateway

1. S3 class중 Glacier는 활용 불가
2. 온프레미스 app -> AWS S3 Bucket, 온프레미스에서는 NFS or SMB protocol을 활용하여 S3 File Gateway에 요청을 보냄
3. S3 File Gateway는 해당 요청을 받아 HTTPS요청으로 변환하여 S3 Bucket에 전달함
4. S3 Life Cycle Policy를 통해 Object를 Glacier로 저장 가능
5. S3 File Gateway를 통해 받은 데이터는 해당 Gateway에 캐싱됨
6. 각 File Gateway마다 IAM Role 생성 필요
7. SMB Protocol을 활용하는 경우, 사용자 인증을 위해 Gateway와 Active Directory를 통합해야 함 -> 사용자가 File Gateway에 접근할 때 인증처리 진행

• FSx File Gateway

1. Amazon FSx for Windows File Server에 Native Access 제공 -> 온프레미스에서의 접근 가능
2. 온프레미스에서 접근 가능함에도 불구하고 FSx File Gateway를 사용하는 이유는 캐싱기능 떄문
3. SMB, NTFS, Active Directory 호환 가능 -> 그룹 파일 공유나 온프레미스를 연결할 홈 디렉토리로 사용 가능

• Volume Gateway

1. iSCSI protocol 사용
2. Volume이 EBS snapshot으로 저장되어 필요에 따라 온프레미스에서 Volume을 복구할 수 있음
3. Cached volumes : 저지연 접근
4. Stored volumes : 전체 데이터가 온프레미스에 있고, 주기적으로 S3에 백업

• Tape Gateway

1. 물리적으로 Tape을 사용하는 백업 시스템이 있는 회사가 백업으로 Tape대신 Cloud에 데이터를 백업할 수 있도록 해줌
2. VTL (Virtual Tape Library)로 Amazon S3와 Glacier를 이용
3. 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업

• Hardware appliance

1. 온프레미스에 Gateway를 설치할 가상서버가 없는 경우에 활용 (Amazon.com에서 신청)
2. Hardware appliance를 Amazon에서 주문 후, 온프레미스에 물리적 설치 -> Gateway로 설정

• Summary

AWS Transfer Family

• AWS Transfer Family : FTP protocol로 S3 및 EFS에 데이터를 전송하려는 경우 사용
  
  
  

• Supported Protocols

1. AWS Transfer for FTP
2. AWS Transfer for FTPS
3. AWS Transfer for SFTP

DataSync

• DataSync : 데이터 동기화를 통한 대용량의 데이터를 한곳에서 다른 곳으로 옮김
  
  
  

• 온프레미스나 AWS의 다른 클라우드로 데이터를 옮길 수 있음

• 서버를 NFS, SMB, HDFS, others... 다른 프로토콜에 연결해야 함 -> 연결할 온프레미스나 다른 클라우드의 Agent가 필요

• 다른 Storage간 데이터 Migration도 가능 -> Agent 불필요

• 복제는 일정을 지정하여 주기적으로 실행

• 파일 권한과 메타데이터 저장기능이 있음 -> NFS POSIX 파일 시스템 및 SMB 권한 준수

• Agent 하나의 task가 초당 10Gb까지 사용 가능, 대역폭 제한 가능

• 네트워크 용량이 부족한 경우, Snowcone 장치 사용 가능 (DataSync Agent가 사전에 설치)

• NFS or SMB 서버에 연결하려면 DataSync Agent 설치 필요
  
  
  

• 동기화 가능 Storage list

1. Glacier를 포함한 모든 Storage Class의 S3
2. Amazon EFS
3. Amazon FSx
   
   
   

• SMB/NFS 프로토콜의 온프레미스 파일을 AWS로 동기화하는 예시

• 서로다른 AWS Storage 서비스간 동기화 예시

Storage 비교

CloudFront

• CloudFront : CDN (Content Delivery Network), 웹사이트의 컨텐츠들을 서로 다른 edge location에 캐싱하여 읽기 성능을 높임
  
  
  

• 특징

1. 전세계 216개의 edge location 활용
2. 컨텐츠가 여러 location에 분산되어 있어 DDoS(동시에 모든 서버가 공격받는 방식) 공격에서 보호받을 수 있음
   
   
   

• 미국의 사용자는 주변 edge location에 호주에 있는 S3 Object를 요청하면, edge location을 통해 호주의 S3 Bucket에 접근함 -> 그후 해당 컨텐츠는 edge location에 캐싱되어 다른 미국 사용자가 바로 받아올 수 있음
  
  
  

• Origin(AWS 인스턴스를 말하는 듯) 제공 방식

1. S3 Bucket으로 CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 설정 (CloudFront를 생성하면서 origin 선택) -> S3 Bucket에는 CloudFront만 접근할 수 있게 설정 -> OAC (Origin Access Control) 활용 (Legacy OAI (Origin Access Identity) 대체) -> CloudFront의 접근권한은 S3 Bucket 권한에 따름 -> CloudFront에서 OAC 활성화 후, CloudFront를 허용하는 S3 Bucket policy를 선택해주면 됨
2. Ingress : CloudFront를 통해 S3 Bucket으로 데이터를 보낼 수 있음
3. S3 Bucket 말고도 Load Balancer, EC2 등의 HTTP Origin을 제공받을 수 있음
   
   
   

• CloudFront 동작방식 : client가 Edge location에 get 요청을 보내면, edge location의 CloudFront는 해당 객체가 캐싱되어 있는지 먼저 확인 -> 캐싱되어 있지 않는 경우, 원본 origin으로 가서 객체를 가져옴 -> 가져온 객체는 캐싱됨

• Origin이 CloudFront에 의해 Object를 전달할 경우, 해당 origin은 OAS(Origin Access Control)에 의해 관리되고, S3 Bucket policy와 같은 개별 origin policy에 의해 접근을 제어

• CloudFront (정적 컨텐츠) vs S3 Cross Region Replication (동적 컨텐츠도 포함)

ALB or EC2 as an Origin

• EC2 : public EC2 필수, edge location의 public ip가 EC2에 접근할 수 있도록 Security Group을 설정해줘야 함

• ALB : private EC2 가능 (public ALB와 연결 가능), public ALB 필수, edge location의 public ip가 ALB에 접근할 수 있도록 Security Group을 설정해줘야 함

Geo Restriction

• Geo Restriction : 지역에 따라 Object 접근을 제한하는 기능 -> 접근이 가능한(Allow List) 또는 불가능한(Block List) 지역 list를 만드는 방식
  
  
  

• Use cases : 컨텐츠 저작권법으로 인한 제한이 필요할 때 등

• CloudFront의 Geographic restrictions에서 설정 가능
  
  
  

Pricing

• Edge Location마다 데이터 전송 비용이 상이
• Price Classes (global Edge location 수를 줄이는 방식으로 가격 절감)

1. Price Class All : 모든 region 대상
2. Price Class 200 : 가장 비싼 region을 제외한 대부분의 region 대상
3. Price Class 100 : 저렴한 region 100개만 대상

Cache Invalidations (무효화)

• Cache Invalidations : 전체 또는 일부의 cache를 새로고침하여 캐시의 TTL을 모두 삭제하는 기능 (특정 Object 대상 전달 필요)
• CloudFront는 백엔드의 업데이트 사항을 인지하지 못함 -> TTL로 캐시가 만료되기 전까진 백엔드의 업데이트 사항을 못받음 -> Cache Invalidations 활용

Global Accelerator

• 문제 상황

1. global application을 global 사용자들이 접근함
2. application은 하나의 region에만 배포되어 있음
3. 하나의 region에만 있기 때문에 전세계 사용자가 해당 ALB로 public internet을 통해 접근하게 되면 상당한 지연시간 발생
4. public internet으로 인한 지연시간을 최소화하기 위해 AWS Network 활용 필요 -> Global Accelerator 활용

• Unicast vs Anycast

1. Unicast : 하나의 client 한 개의 Server IP일 때, 해당 IP로 접근하게 되면 해당 Server로 접근
2. Anycast : 하나의 client 한 개의 Server IP이고, 여러 서버가 한 개의 Server IP를 공유할 때, client가 해당 ip로 접근하게 되면 동일 ip를 공유하는 다수의 Server중 client로부터 가장 가까운 서버로 접근하게 됨 -> Global Accelerator의 원리
   
   
   

• Global Accelerator

1. 두 개의 고정 ip 제공 -> 보안성 확보
2. 두 개의 고정 ip에 요청 시, Anycast원리대로 edge location을 통해 AWS 네트워크를 거쳐 application에 요청이 전달됨
3. Elastic IP, EC2, ALB, NLB가 활용됨
4. 아무것도 Caching하지 않음
5. HTTP가 아닌 서비스에 유용

• Health Checks

1. Global Accelerator가 application에 대한 Health Check 진행
2. 특정 Region의 ALB에 대한 Health check에 실패하면, Global Accelerator의 정상 endpoint로 자동화된 장애조치 진행
   
   
   

• Global Accelerator vs CloudFront

• 실습 -> 생성된 Global Accelerator의 Listener로 테스트 시, 현재 위치와 가까운 Region의 Endpoint로 redirect 됨 (Global Accelerator의 Listener로 요청 -> 가장 가까운 edge location -> edge location에서 가까운 endpoint로 routing -> 해당 endpoint의 application에 접근)

1. Global Accelerator 생성
2. Listener 설정 (포트/TCP/UDP 등)
3. Listener를 통해 접근할 Endpoint group 설정 (Endpoint group은 Target application이 있는 Region)
4. Endpoint group의 Endpoint 설정(target application), Endpoint type은 ALB/NLB/EC2/Elastic IP 중 택 1

Object Encryption

• 암호화 종류

1. SSE (Server-Side Encryption)
   • SSE-S3 : Amazon S3에서 관리하는 키를 이용 (default)
   • SSE-KMS : KMS 키를 이용하여 암호화 키 관리
   • SSE-C : 고객이 제공한 키 사용 (client에서 키 제공)
2. CSE (Client-Side Encyption) : 클라이언트 측의 모든 걸 암호화한 다음에 S3에 업로드
   
   
   

• SSE-S3

1. AWS가 처리/관리/소유하는 키를 이용 (사용자가 접근할 수 없음)
2. Encryption Type : AES-256
3. request header에 "x-amz-server-side-encryption":"AES256" 설정 필요

• SSE-KMS

1. KMS (키 관리 서비스)를 이용해서 client가 자신의 키를 직접 관리 -> 사용자가 통제 가능 -> KMS에서 신규 키 생성 가능
2. CloudTail (AWS 로깅 서비스) 이용하여 키 사용을 검사할 수 있음
3. request header에 "x-amz-server-side-encryption":"aws:kms" 설정 필요

• SSE-KMS 제한사항
  • S3에 KMS키 활용 암호화된 Object를 업로드하고 다운로드하기 때문에 사용자가 직접 KMS키를 사용해야 함
  • 복호화 : KMS 키의 자체 API인 GenerateDataKey를 활용하여 Object를 복호화 함
  • 복호화 시, KMS API 호출 건은 초당 API 호출에 합산됨 (region마다 다르지만 초당 API 호출에 제한이 있음) -> 쓰로틀링 발생 가능성 있음

• SSE-C

1. 외부에서 관리되는 키 사용 (client가 서버로 해당 키 전송)
2. AWS에서는 해당 키를 저장하지 않음
3. 반드시 HTTPS를 이용하여 요청해야 함

• CSE (Client-Side Encryption)

1. 클라이언트가 직접 데이터를 암호화한 다음에 Amazon S3에 전송하는 방식 (복호화도 마찬가지)
2. 클라이언트측 암호화 라이브러리를 활용한다면 쉽게 구현 가능

• SSL/TLS (전송 중 암호화)

1. S3에는 HTTP/HTTPS 두 개의 endpoint 존재 (HTTPS endpoint에서 전송 중 암호화 제공)
2. HTTPS 권장
3. 강제화 방법 : Bucket 정책 활용
   • Bucket Policies를 활용하여 암호화를 강제하고 올바른 암호화 헤더가 없는 경우에는 S3 API호출을 거절할 수도 있음

CORS

• CORS : Cross-Origin Resource Sharing, 웹 브라우저 기반 보안 메커니즘
  
  
  

• 작동 원리

1. origin : scheme (protocol) + host (domain) + port (ex. https://www.example.com)
2. 메인 origin에서 다른 origin에 대한 요청을 허용하거나 거부
   • same origin : http://example.com/app1 = http://example.com/app2
   • defferent origin : http://www.example.com != http://other.example.com
3. 웹 브라우저가 main origin에 접속한 상태에서 다른 origin으로 요청해야하는 상황일 때, 다른 origin에서 CORS헤더(Access-Control-Allow-Origin) 허용을 하지 않는 이상 요청이 전달되지 않음 (ex. 웹 브라우저가 front 서버에 접속한 상태에서 back 서버에 요청을 보내야 할 때, front서버 origin != back서버 origin)
   
   
   

• 예제

1. 웹 브라우저가 https://www.example.co(main origin)에 요청하여 index.html을 받아옴
2. 받아온 index.html에서 https://www.other.com(cross origin)에 file을 요청
3. cross origin에 main origin 값을 실어 사전요청을 보냄
4. cross origin에서 CORS를 허용했다면, main origin으로부터 GET/PUT/DELETE 호출을 허용
5. 웹 브라우저에서 cross origin에 파일을 요청하여 받아옴

• S3에 적용한다면, S3는 cross origin으로서 CORS 허용 필요 (permissions - CORS 에서 JSON 형식으로 설정 가능)

MFA Delete

• MFA Delete : S3상에서 중요한 작업을 진행할 때, 특정 Device(ex. Google Authenticator, MFA Hardware Device 등)에서 생성한 코드를 통한 인증을 강제화 하는 것
  
  
  

• object의 특정 version을 삭제하거나, versioning 옵션을 중단할 때 두 가지 경우에 주로 사용됨

• MFA 활용을 위해서 Bucket Versioning을 활성화해야 함

• Bucket소유자(root 계정)만 활성화할 수 있음

• MFA Delete 활성화는 CLI를 통해서 가능

• MFA Delete가 활성화된 상태에서 객체 버전 삭제를 할 경우, CLI를 통해서 MFA Delete를 비활성화한 후에 삭제 진행해야 함
  
  
  

S3 Access Logs

• S3 Access Logs : S3 Bucket에 접근한 모든 case는 다른 S3 Bucket에 log로 저장
  
  
  

• Amazon Athena와 같은 데이터 분석 도구로 분석 가능

• logging bucket은 같은 region내에 있어야 함 -> 같은 region내에 Bucket 생성 후 logging되도록 설정하면 됨

• properties -> Server access logging 설정 -> Enable -> log가 저장될 bucket 선택 -> bucket 정책 자동 현행화
  
  
  

• 주의사항 : 로깅 버킷과 모니터링 버킷을 동일하게 설정x -> 로깅 loop가 생성되어 로깅이 무한반복됨

Pre-Signed URLs

• Pre-Signed URLs : URL에 private bucket의 특정 object에 public하게 접근할 수 있는 권한을 부여 -> URL을 받는 사용자는 생성한 사용자에게 GET/PUT권한을 상속받음 -> 외부의 사용자에게 특정 Object에 대한 권한을 부여해야할 때 사용
  
  
  

• Console, CLI, SDK에서 생성 가능

• Object actions -> share with presigned URL

• 만료시간

1. Console : 최대 12시간
2. CLI : 최대 168시간

• use cases

1. 로그인한 유저에게만 파일을 다운로드할 수 있게끔 함
2. 사용자 list가 계속 변하는 경우, url을 동적으로 생성하여 권한 부여 지속
3. 일시적으로 외부 사용자가 bukcet에 접근해야할 경우

Glacier Vault Lock

• Glacier Vault Lock : Worm(Write Once Read Many) 모델 적용을 위해 활용, 한번 Glacier Vault에 Object를 넣으면 수정/삭제가 불가하도록 lock을 걸어버림 (관리자나 그 누구도 삭제를 못함) -> 규정준수나 데이터 보존에 유용
  
  
  

• Glacier에 Vault lock policy 설정 -> 더이상 정책을 변경할 수 없도록 해당 정책을 lock
  
  
  

S3 Object Lock

• 특징

1. Bucket 전체 대상의 lock이 아닌 Bucket 내 Object에 개별적으로 lock 가능
2. 특정 Object의 특정 version이 특정 시간동안 삭제되는 것을 막을 수 있음
3. Object Lock 활성화를 위해서 Versioning 활성화 필요
4. Worm(Write Once Read Many) 모델 적용
5. 법적 보존 모드 설정을 통해 모든 Object를 무기한으로 보존 가능 -> s3:PutObjectLegalHold IAM 권한을 가진 사용자는 법적 보존 모드 설정 및 삭제 가능
   
   
   

• Retention mode

1. Compliance mode
   • Glacier Vault Lock과 유사
   • 사용자 그 누구도 수정/삭제 불가
   • Retention mode도 변경 불가
2. Governance mode
   • 좀 더 유연성이 필요할 때 사용
   • 대부분의 사용자가 수정/삭제 불가
   • IAM을 통해 권한을 부여받은 사용자는 Object의 보존기간을 변경하거나 바로 삭제할 수 있음

• 두 가지 모드 모두 Object 보존기간 설정 필요
  
  
  

S3 Access Points

• 사용자와 데이터가 많아질 수록 Bucket 정책 등 관리가 까다로워짐 -> Access Points 활용 -> S3 Bucket에 접근하기 위한 다양한 방법 정의

• 특정 S3 Bucket prefix에 대한 Access Points를 생성하고, 해당 point에 prefix에 맞는 Bucket policy 설정 (용도에 따라 단일 Access points에 다수의 prefix를 연결하는 policy 설정 등 가능)
  
  
  

• 특징

1. 각 Access Points는 각각 특정 DNS를 가짐
2. Access Point는 public 인터넷이나 private VPC에 연결될 수 있음

• private VPC -> S3 Access point : VPC에 endpoint를 생성하면 VPC 내부의 EC2 인스턴스는 해당 endpoint에 정의되어 있는 VPC policy에 맞게 S3 Access point로 접근하게 되고, 해당 Access point의 정책에 맞게 Bucket내 데이터에 접근할 수 있게된다. -> 결론적으로 VPC endpoint policy, S3 Access point policy, Bucket policy 세 가지 보안 정책 설정이 필요함

S3 Object Lambda

• S3 Object Lambda : S3 Bucket에 호출하여 Object를 받기 전에 해당 Object를 수정하려는 경우에 사용
  
  
  

• 특징

1. S3 Access point 사용 필요
2. S3 Bucket 외의 Access point를 생성하여 Lambda function에 연결될 수 있도록 설정 -> S3 Lambda Access point를 생성하여 특정 application으로 Lambda의 처리 결과본 전달 -> 결과적으로 특정 application은 Lambda access point를 통해 Lambda를 호출하여 S3 Access point를 통해 S3 객체를 가져오고, 해당 객체를 Lambda function이 수정하여 다시 Lambda access point를 통해 application으로 전달
3. Object 수정본을 위한 Bucket을 생성하여 별도의 버전을 관리할 필요 없음