woongs dogfoot

Moving between Storage Classes

• 수동으로 Object의 Storage Class를 옮길 수 있지만, LifeCycle Rules에 의해 자동으로도 옮겨질 수 있음

LifeCycle Rules

• Transition Actions : 다른 Storage class로 이전하기 위한 Object 설정 (ex. 생성 60일 후에 Standard class로 이동)

• Expiration Actions : 객체 삭제를 위한 Object 설정 (ex. 일정 만료기간이 지나면 Object 삭제, 특정 버전 삭제, 로그 삭제, 불완전한 객체 삭제 등)

• 특정 경로나 Tag로 Object를 제한할 수 있음 (tag ex. 특정 부서의 object 등)
  
  
  

• Scenario 1

• Scenario 2

• Storage Class Analysis : 매일 S3 Bucket의 상태를 확인하여 Storage class 추천 및 통계를 담은 report를 생성
  • Standard 및 Standard IA는 호환되지 않음
  • report 확인까지 24~48시간 소요될 수 있음
  • report를 통해 합리적인 lifecycle rules를 설정할 수 있음

Requester Pays

• As-Is : S3 Bucket 소유자가 스토리지 및 데이터 전송에 대한 비용 모두 지불
• To-Be (Requester Pays) : S3 Bucket 소유자는 스토리지 비용을, 데이터 요청자가 데이터 전송 비용을 지불 -> 데이터를 다른 사용자 계정과 공유할 때 유용 (요청자가 익명이면 안됨, AWS 인증 필요)

Event Notifications

• Event : 객체 생성/삭제/복구, 복제 등과 같은 작업 (ex. S3 자체적 자동으로 image 썸네일 생성 등)

• Event Notifications는 filtering이 가능 (ex. *.jpg object의 이벤트만 알림으로 받고 싶다 등)

• Event Notifications의 대상은 설정 가능 (ex. SNS, SQS, Lambda Function 등)

• 알림은 몇 초면 전송되나 간혹 몇 분이 걸리는 경우도 있음

• properties - Event Notifications 에서 설정 가능
  
  
  

• IAM Permissions : 알림을 전송하기 위해 IAM 권한(SNS, SQS 등)이 있어야 함 -> S3 IAM Role을 사용하는 것이 아닌 Target Resource Policy에 정의함 -> 우리와 같은 사용자가 S3 Bucket에 접근할 때, S3 Bucket 정책에 기반하는 것과 비슷하다고 보면 됨 -> 보통 target이 policy 설정

• ex) S3 Event Notification을 SNS 토픽에 전송하기 위해 SNS Resource Policy를 할당해야 함 (SNS 토픽에 첨부하는 IAM Policy)

• Amazon EventBridge : S3의 모든 event Notification이 EventBridge로 전송됨 -> EventBridge에 설정된 규칙을 기반으로 다른 AWS 서비스에 Event 전송 -> 직접 Event Notification를 전송하는 것보다 다양한 filtering 옵션 등과 같은 기능을 활용할 수 있음

S3 Performance

• Amazon S3는 요청이 많으면 자동으로 확장됨 (지연시간 : 100~200ms)

• Amazon S3는 prefix 및 초당 3500개의 PUT/COPY/POST/DELETE 요청과 5500개의 GET/HEAD 요청을 지원 -> 고성능

• prefix 수에 제한이 없음 (prefix는 object의 path라 보면 됨) -> 4개의 prefix에 요청을 분산하면 초당 22000개의 GET/HEAD요청 처리 가능
  
  
  

• 최적화 방법

1. Multi-Part upload : 100MB넘는 파일 권장, 5GB넘는 파일은 필수 -> upload 병렬화 -> 전송속도 증가
2. Transfer Acceleration : 파일을 AWS 엣지 로케이션으로 전송, 데이터를 target region의 Bucket에 저장 -> 빠른 AWS 네트워크 활용을 통해 전송속도 증가
   • Multi-Part upload와 동시 사용 가능

3. Byte-Range Fetchs
   • 파일의 특정 바이트 범위를 가져와 GET 요청 병렬화 -> 실패의 경우 재시도 (복원력 높음) -> 다운로드 속도 증가
   • 파일의 첫 50바이트가 헤더라는 등 파일의 정보를 안다면, 파일에 대한 바이트 요청 범위를 설정할 수 있음

Select

• 파일 검색 시, 검색 후 필터링 하면 불필요하게 많은 데이터를 검색하게 됨 -> Select 기능 사용
• Select : SQL을 활용한 서버측 필터링 기능 -> 필요한 데이터만 필터링하여 조회 가능
• 데이터 검색 및 필터링에 드는 CPU 비용 절약 가능
• 적은 양의 데이터 전송에 따른 데이터 전송 속도 증가
  
  
  

S3 Batch Operations

• S3 Batch Operations : 단일 요청으로 S3 Object에서 대량 작업 수행
  
  
  

• Use cases

  1. 한 번에 많은 S3 Object의 메타데이터와 property 수정 가능
  2. S3 Bucket간 Object 복제 가능
  3. 암호화되지 않은 모든 Object를 암호화
  4. ACL(권한), tag 수정
  5. S3 Glacier에서 많은 object 복구
  6. Lambda 함수를 호출하여 S3 Batch Operations의 모든 객체에서 사용자 지정 작업 수행
     
     
     

• 파라미터 : 객체 list, 수행할 작업 -> 객체 list는 S3 Inventory 기능을 활용하여 가져옴

• S3 Inventory : S3 Select를 활용하여 적절히 객체를 filtering하여 전달해줌

• Why? Batch Operations
  1. retry 관리 가능
  2. 진행상황 추적 및 작업완료 알림 가능
  3. 보고서 생성 가능
     
     
     

S3 Storage Lens

• Storage Lens : 스토리지 이해/분석/최적화 하는 데 도움이 되는 서비스 -> 이상징후, 비용효율성 등 감지하여 전체 AWS조직을 보호 (30일 사용량 및 활용 메트릭 제공)

• 데이터 수집 범위

  1. AWS 조직
  2. AWS 특정 계정
  3. regions
  4. buckets
  5. prefixs
     
     
     

• 특징

1. Custom Dashboard 제작 가능
2. csv or parquet 형식으로 사용량과 메트릭에 관한 report를 S3 Bucket을 통해 받아볼 수 있음
3. use cases
   1. 가장 빠르게 성장하거나 사용하지 않는 bucket이나 prefix 식별 (storage 관점)
   2. multi-part 업로드에 실패한 객체가 있는 bucket이 무엇인지? (storage 관점)
   3. 어떤 object를 더 저렴한 storage class로 옮길 수 있는지? (비용 관점)
   4. 데이터 보호 사례를 따르지 않는 bucket 식별 (데이터 보호 관점)
   5. Bucket이 어떤 object에 대한 소유권 설정을 하고있는지? (Bucket 소유권 관점)

• Defualt Dashboard

1. 무료 및 고급 지표에 대한 요약된 인사이트와 트렌드 확인 가능
2. Multi-Region, Multi-Account의 모든 데이터 확인 가능
3. Amazon S3에 의해 사전 구성
4. 삭제는 불가하지만 비활성화는 가능

• Metrics

1. Summary Metrics : S3 Storage에 관한 insight
   • StorageBytes : Storage 및 Object의 크기를 파악 (모든 버전 포함 -> 실제로 차지하는 용량, 불완전한 multi-part object도 포함)
   • ObjectCount : Storage의 Object 수 파악
2. Cost-Optimization Metrics : 비용에 관한 insight
   • NonCurrentVersionStorageBytes, IncompleteMultipartUploadStorageBytes, etc...
3. Data-Protection Metrics : 데이터 보호에 관한 insight
   • VersioningEnableBucketCount : 버전관리 활성화 Bucket 수
   • MFADeleteEnableBucketCount, SSEKMSEnableBucketCount, CrossRegionReplicationRuleCount, etc...
4. Access-management Metrics : S3 Bucket 소유권에 관한 insight
   • ObjectOwnershipBucketOwnerEnforcedBucketCount, etc...
5. Event Metrics : S3 Event Notifications에 관한 insight
   • EventNotificationEnabledBucketCount : Event Notification이 구성된 Bucket의 수
6. Performance Metrics : Transfer Acceleration에 관한 insight
   • TransferAccelerationEnabledBucketCount : Transfer Acceleration이 활성화된 Bucket의 수
7. Activity Metircs
   • AllRequests, GetRequests, PutRequests, ListRequests, BytesDownloaded, etc...
8. Detailed Status Code Metrics : HTTP 상태 코드에 관한 insight
   • 200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount, etc...
     
     
     

• 무료 metric vs 유료 metric

Amazon S3

• Use Cases

1. 백업과 스토리지로 활용 (ex. 파일, 디스크, 재해복구 등)
2. 아카이브 용도로 활용 -> 검색 용이
3. Hybrid Cloud Storage -> 온프레미스 스토리지가 있는 상태에서 클라우드로 서비스를 확장
4. application, file, image 등 미디어를 호스팅할 수 있음
5. 다량의 데이터를 저장하고 빅데이터 분석 수행
6. 정적 웹사이트 호스팅
   
   
   

• S3 Buckets

1. 파일(=객체) 저장 용도
2. 상위 레벨 디렉토리로 표시
3. 계정 안에 생성되고, 모든 region의 고유한 이름이 있어야 함 (전역 서비스로 착각x -> 특정 region 국한 서비스)
4. region 수준 정의
5. Name convention
   • 대문자(x)
   • 밑줄(x)
   • 길이 3~63
   • ip(x)
   • 소문자나 숫자로 시작
   • 접두사 제한 (ex. xn--, -s3alias 등)
   • 문자, 숫자, 하이픈 사용
6. 인터넷망에서 bucket내부 object에 접근하기 위해서 public 설정 필요 (default는 amazon credential을 활용하여 private하게 접근)
   
   
   

• S3 Objects

1. body는 본문의 내용 (file 등)
2. Object당 최대 크기는 5TB
3. 크기가 5GB 이상이라면, multi-part로 업로드하여 여러 부분으로 나누어 업로드
4. key-value 형태의 메타데이터 존재 (object에 관한 부가정보)
5. tags (유니코드 최대 10개 key-value쌍), 보안과 lifecycle에 유용
6. Version ID를 갖기도 함
   
   
   

• S3 Object key

1. 모든 Object는 key를 가짐
2. key는 파일(object)의 전체 경로
   • s3://my-bucket/my_file.txt -> key : my_file.txt, 상위디렉토리 : s3://my-bucket/
   • s3://my-bucket/my_folder1/another_folder/my_file.txt -> key : my_folder1/another_folder/my_file.txt
   • key = 접두사 + file(object) name
3. 디렉토리의 개념은 없음 (디렉토리처럼 보이지만, 핵심은 key)
   
   
   

Security

1. 사용자 기반

• IAM 정책 : 특정 사용자(동일 계정의 IAM User(?))에게 특정 S3 API 호출 허용
• IAM Role : 특정 EC2 인스턴스에게 특정 S3 API 호출 허용
  
  
  

2. 리소스 기반

• S3 Bucket 정책 : S3 console에서 할당 가능, 특정 사용자에게 bucket 접근을 허용 (교차계정, 다른 계정의 IAM User)
• Object ACL (Object Access Control List) : 가장 세밀한 권한
• Bucket ACL (Bucket Access Control List) : Object 보다 덜 세밀한 권한
  
  
  

3. 암호화

• 암호키를 사용하여 S3 object 암호화
  
  
  

=> S3 Object에 접근할 수 있는 경우는 위에서 언급된 사용자 기반 IAM 권한을 얻거나, 리소스 기반 정책이 허용할 경우

• S3 Bucket Policies

1. JSON기반의 정책
   • Resource : 정책이 적용되는 bucket과 object 명시
   • Effect : Allow/Deny 선택
   • Action : 정책에서 명시할 작업(API)
   • Principal : 해당 정책을 적용할 대상(사용자)

• Public Access : S3 Bucket Policy

• Cross-Account Access : S3 Bucket Policy

• User Access : IAM permissions

• EC2 Access : IAM Roles

• Block Public Access

1. 기업 데이터 유출을 방지하기 위한 추가 보안 계층
2. Bucket 생성 시, 설정
3. Bucket Policy를 통해 Public Access를 허용하더라도 해당 설정이 활성화되어 있으면, public 접근 불가
4. 잘못된 Bucket Policy 설정으로 인한 유출사고 방지
5. public Bucket Policy 설정 시에만 비활성화해야 함
   
   
   

Website

• S3를 활용하여 정적 웹사이트 hosting 가능
• S3 Bucket 설정 중, properties - static website hosting 설정에서 활성화 필요
• index.html 파일 업로드 필요
• S3 Bucket에 대한 권한 허용 필요
  
  
  

Versioning

• S3에서 File의 버전 관리 가능
• Bucket 설정에서 활성화 필요 (properties - bucket versioning)
• 동일한 key를 upload하고 파일을 덮어쓰는 경우 버전 2, 버전 3... 생성
• 의도치 않은 File 삭제 방지 -> versioning이 활성화되어 있는 상태에서 파일을 삭제할 경우, 삭제마커가 추가되어 삭제가 versioning됨 -> 복구 가능
• 파일 버전을 삭제한 경우, 파일이 삭제되는 것이 아닌 해당 버전만 삭제
• 이전 버전으로 roll-back 가능
• 유의1 : 버전 관리가 적용되지 않은 모든 파일은 null 버전을 갖게됨
• 유의2 : 버전 관리를 중단해도 이전 버전을 삭제하진 않음

Replication

• management - Replication rules 에서 복제설정
• source bucket, destination bucket 둘다 Versioning 활성화 필요
• S3에 알맞는 IAM Role 할당(Bucket에 대한 읽기/쓰기 권한) 필요
• 복제는 비동기식으로 진행 (background 진행)
• 서로 다른 AWS 계정간 사용 가능
• 복제를 활성화한 후, 새로 추가되는 object만 복제 대상이 됨
• 기존 object 복제를 위해 S3 Batch 복제를 활용해야 함 (기존 object, 복제실패 object 복제)
• 삭제작업 복제를 위해 삭제마커(version)도 복제하면 됨 (설정에서 가능, Delete marker replication 활성화)
• version삭제는 복제 불가
• chaining 복제 불가 (bucket 1 -> bucket 2 -> bucket 3 (x))
  
  
  

1. CRR (교차 리전 복제)

• source bucket과 destination bucket의 region이 다름
• region간 지연시간 감소를 위해 사용
• AWS 계정간 복제를 위해 사용
  
  
  

2. SRR (같은 리전 복제)

• source bucket과 destination bucket의 region이 동일
• 다수 S3 Bucket간 통합
• 개발환경과 운영환경 실시간 동기화
  
  
  

Storage Classes

• 객체 생성 시, class 선택가능 (properties - storage class)

• 수동으로 수정도 가능

• S3 Lifecyle 설정을 통해 기간에 따른 class간 객체이동 자동화도 가능 (management - lifecycle rules)
  
  
  

• Durability (내구성) : S3로 인해 객체가 손실되는 횟수, 모든 class에서 동일

• Availability (가용성) : 서비스가 얼마나 용이하게 제공되는지, class에 따라 다름 (ex. 99.99% : 1년에 53분 동안 서비스 사용 불가)
  
  
  

• Classes

1. Standard - General Purpose

   • 가용성 : 99.99%
   • 자주 access하는 데이터를 위해 사용
   • 지연시간이 짧고 처리량이 높음
   • 두 개의 기능장애를 동시에 버틸 수 있음
   • use cases : 빅데이터 분석, mobile/game application, 배포 등

2. Standard - Infrequent Access (IA)

   • 가용성 : 99.9%
   • 자주 access하진 않지만, 빠른 접근이 필요할 때 사용
   • General Purpose보다 비용이 저렴 (검색 비용 발생)
   • use cases : 재해복구, 백업 등

3. One Zone - Infrequent Access

   • 가용성 : 99.5%
   • 단일 AZ 내에서 높은 내구성 (99.999999999%)
   • AZ가 파괴된 경우, 데이터를 잃게 됨
   • use cases : 온프레미스 데이터 2차 백업, 재생성 가능한 데이터 저장 등

4. Glacier

   • Glacier = cold storage, 아키이빙과 백업을 위한 저비용 객체 스토리지

   • 스토리지 및 검색 비용 부과
     1) Instant Retrieval

     • 밀리초 단위 검색
     • 분기에 한번 access하는 데이터에 적합
     • 최소 보관 기간은 90일

     2) Flexible Retrieval

     • Expedited : 1~5분 내에 데이터 수집 가능
     • Standard : 3~5시간 내에 데이터 수집 가능
     • Bulk : 5~12시간 내에 데이터 수집 가능 (free)
     • 최소 보관 기간은 90일

     3) Deep Archive

     • Standard : 데이터 수집까지 12시간 소요
     • Bulk : 데이터 수집까지 48시간 소요
     • 비용이 가장 저렴
     • 최소 보관 기간은 180일
     • 장기간 저장에 적합

5. Intelligent Tiering

   • 사용 패턴에 따라 access tier간 객체 이동
   • 월별 모니터링 비용과 객체 이동(tiering) 비용 발생, 검색 비용은 없음
   • FrequentAccess : default
   • InfrequentAccess : 30일 동안 access하지 않는 object전용
   • ArchiveInstantAccess : 90일 동안 access하지 않는 object전용
   • ArchiveAccess : 90일부터 700일 이상 access하지 않는 object전용, 객체 자동이동은 optional
   • DeepArchiveAccess : 180일부터 700일 이상 access하지 않는 object전용, 객체 자동이동은 optional
     
     
     

• Storage classes 성능 비교

• Storage classes Price

Case 1. WhatIsTheTime.com

• 요구사항

1. 사람들에게 시간을 알려줌
2. No DB
3. downtime 제거를 위한 수직 및 수평적 scaling 필요
   
   
   

• 구현

1. EC2 인스턴스 재시작을 위한 고정IP 할당 (Elastic IP) 👉EC2-(2) 글 참고
2. 트래픽 증가로 인한 대용량 부하처리를 위한 upscaling (t2.micro -> m5.large) 👉EC2-(1) 글 참고
3. 더 큰 트래픽 처리를 위한 scale out
4. scale out에 따라 다수의 인스턴스가 생성되고, 해당 인스턴스들에 접근하려면 각각의 Elastic IP를 알아야 함
   -> Elastic IP 제거(region당 다섯개의 고정ip 할당 가능) 후 Route53 추가 (url : api.whatisthetime.com)
   -> A type의 Route53의 도메인으로부터 여러 인스턴스들의 ip들을 받음 👉Route53 글 참고
5. 인스턴스 한 개가 삭제되는 등 문제가 생기면, 자동 재생성이 안될 뿐더러 TTL시간동안 해당 인스턴스로 계속 접근할 것이기 때문에 VOC발생
   -> public EC2 인스턴스들을 동일 가용영역의 private EC2로 전환, public Load Balancer 추가 (health check 기능 내장, 문제의 인스턴스로 트래픽 전달x), Load Balancer - EC2간 보안그룹 규칙을 추가하여 트래픽 제어 👉LoadBalancer 글 참고
   -> Load Balancer는 ip가 계속 바뀌기 때문에 Rout53 A record를 alias record로 전환 👉Route53 글 참고
6. auto-scaling 기능 추가, private EC2 인스턴스를 ASG (Auto Scaling Group)으로 묶음
   -> 트래픽에 따라 자동 scale in/out이 진행되고, 오류로 인해 인스턴스가 내려가도 자동으로 재생성 해줌 👉ASG 글 참고
7. 가용성을 위한 multi-AZ 추가, 각각의 가용영역(AZ)당 1개의 ELB(Elastic Load Balancer)를 추가, ASG 또한 가용영역당 1개씩 추가
   -> 천재지변 등에 의해 특정 가용영역 전반에 문제가 생길 경우, multi-az로 다중화되어 있어 서비스 영향도 없음
8. application 비용 절감 plan 활용 가능, 용량에 따라 비용이 절감될 수 있도록 reserved instances 활용 (극단적 비용절감을 위해 spot instance 활용도 고려될 수 있음) 👉EC2-(1) 글 참고
   
   
   

• Architecture 설계 시, 비용/성능/신뢰성/보안/운영효율 등을 고려해야 함
  
  
  

Case 2. MyClothes.com

• 요구사항

1. 온라인으로 옷을 삼
2. 장바구니 기능이 있음
3. 수백 명의 동시접속자가 있음
4. 확장 가능 및 수평 확장성 유지
5. application app teer를 최대한 무상태로 유지 (장바구니 기능이라는 상태가 존재하지만 쉽게 확장가능해야 함 -> 사용자가 장바구니 데이터를 잃으면 안됨)
6. 주소 등과 같은 사용자 정보를 효과적으로 DB에 보관
   
   
   

• 구현

1. WhatIsTheTime.com과 같은 동일 아키텍처 (Route53 -> Multi-AZ -> ELB -> ASG -> EC2)
2. 장바구니 기능 구현
   A. ELB Stickiness 활성화 👉LoadBalancer 글 참고

    -> ELB가 cookie를 활용하여 동일 사용자의 접근은 이전 접근했던 EC2로 redirect 시켜 줌, 사용자로 하여금 만료기간동안 EC2 세션이 유지됨
    -> EC2 인스턴스가 내려가면 장바구니 데이터와 같은 데이터들이 삭제됨

   B. 쿠키를 활용하여 사용자측에서 장바구니 내용 저장

    -> Load Balancer에 접속할 때마다 EC2 인스턴스는 cookie를 통해 장바구니 데이터를 알 수 있음
    -> HTTP 요청이 무거워짐
    -> cookie가 노출됨에 따른 보안 위험 존재 (EC2 인스턴스가 사용자 cookie를 검증해야 함)

   C. 서버 세션 기능 활용, 사용자는 쿠키를 통해 Session_id 전송

    -> 장바구니에 데이터 저장이 필요할 때, ElastiCache 클러스터에 저장 👉[ElastiCache](https://woongsdogfoot.tistory.com/47) 글 참고
    -> 사용자가 전송하는 Session_id는 ElastiCache 저장소의 id가 됨
    -> 다른 EC2로 접근해도 동일 Session_id를 전송받아 ElastiCache에 접근하기 때문에 데이터 유지 가능
    -> 고성능의 조회성능
    -> 대안으로 DynamoDB도 활용 가능

3. 사용자 정보를 DB 저장, Amazon RDS(DB인스턴스) 활용 (장기적인 저장) 👉RDS 글 참고
   -> Multi-AZ 무상태 솔루션 효과
4. RDS 읽기 성능 향상 👉RDS/ElastiCache 글 참고
   A. write용도의 RDS Master에서 Read Replicas(읽기전용 RDS) 복제

    -> Read Replicas 확장 가능

   B. ElastiCache 활용

    -> RDS 조회 전, ElastiCache에 먼저 요청하여 데이터가 있는지 확인 (Cache Storage는 조회성능이 좋음)
    -> RDS 상의 트래픽 감소

5. 재해 예방, EC2의 Multi-AZ 뿐만 아니라 RDS도 복제본을 생성하여 재해 예방 (ElastiCache의 경우에도 Redis의 경우, Multi-AZ 가능)
6. 보안 그룹 설정, ELB는 모든요청을 수용할 수 있어야 함(HTTP/HTTPS, 0.0.0.0/0), EC2는 ELB로부터 오는 트래픽만 받아야 함, ElastiCache/RDS는 EC2 보안 그룹으로부터 오는 트래픽만 받아야 함
   
   
   

Case 3. MyWordPress.com

• 요구사항

1. 완전 확장가능한 웹사이트
2. 업로드한 그림이 표시
3. 사용자 데이터, 블로그 내용 등 MySQL DB에 저장
4. Global 확장
   
   
   

• 구현

1. WhatIsTheTime.com과 같은 동일 아키텍처 (Route53 -> Multi-AZ -> ELB -> ASG -> EC2)
2. Aurora 추가 👉Aurora 글 참고
   -> Multi-AZ, Read Replicas, Global DB 등 가능
3. 이미지 저장 기능 추가
   -> image는 Amazon EBS Volume에 저장되도록 설정
4. Multi-AZ, 다중 인스턴스의 경우, 각 EC2당 EBS에 image가 따로 저장되는 문제 발생
   -> EFS(NFS) 추가 👉EFS
   -> Multi-AZ 연결을 위해 각 AZ에 ENI(Elastic Network Interface) 생성 (ENI는 EFS에 접근하는 모든 EC2에서 사용 가능)
   -> EC2에 요청으로 들어온 image는 각 ENI를 통해 EFS에 전송되어 저장됨
   
   
   

Application 설치 및 배포 in AWS

• AWS를 활용한 빠르고 효율적인 배포 방법

1. EC2 : Golden AMI 활용 -> 이미 설치된 상태에서 바로 배포 -> 빠른 배포 가능
2. EC2 : Bootstrap using User Data -> User가 구성한 스크립트를 EC2 실행 시에 진행하도록 함 -> 동적 설정이 필요할 때 활용
3. EC2 : Hybrid -> Golden AMI + Bootstrap using User Data -> Elastic Beanstalk
4. RDS : snapshot 활용 -> 복구 및 빠른 설치 가능
5. EBS : snapshot 활용 -> 데이터 복구 가능
   
   
   

Beanstalk

• 배경

1. 관리해야할 인스턴스가 다양하고 많음 (ELB, ASG, EC2, RDS 등, scale out)
2. 인프라 관리가 까다로움
3. 대량 인스턴스의 코드 배포가 어려움
4. 모든 인스턴스의 설정이 필요함
5. scaling 관점 고민 필요
   
   
   

• Beanstalk : 개발자 입장에서 application을 쉽게 AWS에 배포할 수 있도록 해주는 tool (기존 컴포넌트 재사용 방식) -> 개발자에게 application architecture가 하나의 인터페이스 번들로 제공됨 (웹사이트 배포 및 운영에 필요한 인스턴스들을 번들로 제공)
  
  
  

• 기능 (개발자는 application의 코드만 신경쓰면 됨)

1. capacity provisioning
2. load balancing
3. scaling
4. application health monitoring
5. instance configuration
6. etc...
   
   
   

• 특징

1. 무료 (Beanstalk이 활용하는 인스턴스의 비용은 유료)
2. 다양한 프로그래밍 언어 지원 (Custom 플랫폼 생성도 가능)
3. Beanstalk에서 생성하려는 인스턴스들을 배후에서 CloudFormation이 생성 (architecture를 그림으로도 볼 수 있음)
   
   
   

• 구성

1. Application : Beanstalk component 모음 (environments, versions, configurations, etc...)
2. Application Versions : application code의 버전
3. Environment : 사용되는 AWS 자원 모음
   • Tiers : Web Server, Worker 두 가지 Tier로 나뉨 (각각의 architecture)
   • Web Server Tier와 Worker Tier를 하나로 합쳐서 활용할 수도 있음
   • dev, test, prod 등 다양한 환경을 지원
     
     
     

• Web Tier (ELB + ASG)
• Worker Tier (Worker환경(?) 중심, EC2에 직접 접근하는 client가 없고 EC2간 SQS Queue를 활용)

• process

• Deployment Modes (dev vs prod)
  : prod환경은 dev환경과 달리 고가용성에 초점

DNS (Domain Name System)

• DNS : 친숙한 hostname을 서버의 ip로 변환해주는 시스템 (www.google.com -> 172.217.18.36)
• Domain Registrar : Domain name 등록 (ex. Amazon Route53 등)
• Domain Records : ex. A, AAAA, CNAME, NS 등
• Zone File : hostname과 IP를 일치시키는 방법 (모든 DNS records를 포함)
• Name Server : DNS 쿼리를 실제로 처리하는 서버
• TLD (Top Level Domain) : .com, .us, .in, .gov, .org 등
• SLD (Second Level Domain : amazon.com, google.com 등
  
  
  

• DNS 동작 과정

1. Domain Name DNS서버에 등록 (example.com)
2. Local DNS 서버에 요청 Domain Name이 있는지 쿼리 (일반적으로 회사에서 할당하고 관리 or 인터넷 서비스 제공자(ISP)에 동적으로 할당)
3. Local DNS 서버에 없는 Domain Name이라면, ICANN에 의해 관리되는 DNS서버의 root에 질의 (알 수 없는 도메인 or Name Server Record인 .com만 알고있다고 응답 -> .com은 IP 1.2.3.4로 가보라고 응답 -> 답을 좀 더 좁혀 나감)
4. IP 1.2.3.4에 있고 IANA에 의해 관리되는 TLD DNS Server에 쿼리 (record가 뭔지 몰라 IP가 뭔지 바로 응답은 못해주지만, example.com이 등록되어 있는 경우, example.com에 해당하는 서버로 안내함 (5.6.7.8)
5. IP 5.6.7.8에 있고 Amazon Route53과 같은 Domain Registrar에 의해 관리되는 SLD DNS Server에 쿼리 (record를 알고있어 해당하는 IP인 9.10.11.12를 응답)
6. Local DNS Server는 해당 응답을 받게되어 캐시에 저장함
7. 브라우저 또한 해당 응답을 Local DNS Server를 통해 받게되어 캐시에 저장함

Route 53 개요

• Route53 : 고가용성 및 확장성을 갖춘, 사용자가 직접 DNS record를 업데이트할 수 있는 DNS (DNS 제어 가능)
  
  
  

• 특징

1. Domain Registrar로써 특정 ip에 매핑되는 Domain Name을 등록
2. Route53 리스소 관련 상태확인 가능
3. 100% SLA 가용성 제공
4. why? Route53 : 53포트는 DNS서버에 사용되는 전통적인 DNS 포트
5. Domain Record는 Domain Name이나 Subdomain Name과 같은 정보를 포함 (ex. example.com)
   
   
   

• Domain Record 포함 정보

1. Domain Name
2. Record Type (ex. A or AAAA or CNAME or NS / 고급 : CAA or DS or MX 등)
3. Value (ex. 123.456.789.123)
4. Routing Policy : Route53이 쿼리에 응답하는 방식
5. TTL : Record가 캐싱되는 시간 (amount of time)
   
   
   

• Record Type

1. A : hostname과 IPv4 IP를 매핑
2. AAAA : hostname과 IPv6 IP를 매핑
3. CNAME : hostname를 다른 hostname과 매핑 (다른 hostname은 record type이 A or AAAA가 될 수 있음)
   • DNS Name Space or Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없음 (ex. example.com(상위노드)에 대한 CNAME을 만들 수는 없지만, www.example.com에 대한 CNAME을 만들 수는 있음)
4. NS : Hosted Zone의 Name Servers, DNS Name 또는 IP주소로 Hosted Zone에 대한 DNS쿼리에 응답할 수 있음
   • 트래픽이 도메인으로 라우팅 되는 방식을 제어
     
     
     

• Hosted Zone : Record의 컨테이너, 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의

1. public Hosted Zone
   • ex. application1.mypublicdomain.com이 public domain이라면, public Hosted Zone을 생성할 수 있음
   • application1.mypublicdomain.com의 IP를 알 수 있음
   • application2.mypublicdomain.com은 application1.mypublicdomain.com과 같은 Hosted Zone에 속하므로 동일 Hosted Zone에서 IP를 알 수 있음 (application1, application2는 동일 ip를 응답으로 받게 됨)
2. private Hosted Zone : 공개되지 않는 도메인 이름을 지원
   • VPC (Virtual Private Cloud) 만이 해당 도메인을 관리할 수 있음
   • ex. application1.company.internal -> 사내망에서만 접근할 수 있는 URL도 해당
     
     
     

• public Hosted Zone vs private Hosted Zone
  : public은 사용자 누구나 접근할 수 있음, private는 VPC와 같은 private 네트워크 내에서만 접근할 수 있음

TTL (Time To Live)

• TTL : DNS서버로부터 응답으로 받는 값 -> 받은 client는 해당 값 동안 record 데이터를 캐싱 (TTL시간 동안 DNS에 같은 요청을 보낼 경우, 캐싱된 값을 활용하게 됨) -> Domain에 대한 ip를 변경해도 TTL시간 내에서는 즉각적인 변경이 안됨
  
  
  

• TTL값에 따른 Case

1. Higt TTL : DNS서버로의 트래픽 down, 이미 만료된 record값 전송 가능성 up
2. Low TTL : DNS서버로의 트래픽 up (비용 상승), 새로 갱신된 record값을 전송할 수 있음
   
   
   

CNAME vs Alias

• CNAME/Alias : AWS 자원을 사용할 때, 해당 AWS의 hostname이 노출됨 -> 해당 hostname으로의 mapping이 필요할 때 사용 (ex. lb1-1234.us-east-2.elb.amazonaws.com hostname을 myapp.mydomain.com hostname에 매핑, ALB hostname을 특정 custom hostname으로 매핑)
  
  
  

• CNAME vs Alias

1. CNAME
   • root domain에는 매핑이 안됨 -> mydomain.com (x), myapp.mydomain.com (o)
2. Alias
   • Route53 한정
   • hostname이 특정 AWS 리소스로 향하게 할 수 있음 (ex. app.mydomain.com -> blabla.amazonaws.com) -> root domain 제약이 없음 -> 실제로는 인스턴스의 ip에 매핑(?)
   • Free
   • 자체적인 health check 가능
   • AWS 리소스에만 매핑
   • record는 A 또는 AAAA
   • TTL을 설정할 수 없음 (Route53에 의해 자동 설정) -> target ip변화를 인식할 수 있음
   • Target : ELB(Elastic Load Balancer), Amazon CloudFront, API Gateway, Elastic Beanstalk, S3 Websites (buckets (x)), VPC Interface Endpoints, Global Accelerator, Route53 Record (same Hosted name) -> EC2는 불가
     
     
     

• Alias Records

Routing Policies

• DNS Routing Policies : DNS가 요청으로 들어온 host Name을 어떤 인스턴스로 어떻게 매핑해야하는 지에 대한 정책
  
  
  

• Routing Policies types

1. Simple
   • 트래픽을 단일 리소스로 보내는 방식
   • 여러개의 ip를 매핑할 수도 있는데, 해당 경우에는 client가 받은 ip중 무작위로 하나를 선택하게 됨 (캐싱이 갱신되어야 ip가 바뀜)
   • health check 불가
2. Weighted
   • 요청 트래픽의 일부를 특정 리소스로 보냄 (가중치에 맞게 DNS서버가 client로 ip응답을 보내줌)
   • 트래픽의 비율에 맞게 ip를 응답으로 주기 때문에 응답으로 주는 ip에 해당하는 인스턴스로의 트래픽 비율은 DNS 라우팅 정책의 가중치의 비율과 동일함
   • 전체 가중치의 합이 100일 필요는 없음
   • DNS record들은 동일한 name과 type을 가져야함 -> health check와도 연관됨
   • use case : 다른 region에 대한 트래픽 분산, 적은 양의 트래픽을 통한 신규 인스턴스의 테스트 등
   • 가중치가 0일 경우, 트래픽을 보내지 않게됨 -> 모든 레코드의 가중치가 0일 경우, 모든 레코드에 대한 트래픽이 균등해짐

3. Failover
   • primary 인스턴스의 상태가 비정상일 경우, secondary 인스턴스로의 장애조치 -> client는 정상으로 판단되는 인스턴스의 ip를 자동으로 받아볼 수 있음
   • primary 비정상 판단 시, primary failover record -> secondary failover record로 자동전환

4. Latency based
   • 지연시간이 가장 짧은 가장 가까운 리소스로 redirect해주는 방식
   • 지연시간에 민감한 case에 효과적
   • 지연시간 : 가장 가까운 AWS region에 연결하기까지의 걸리는 시간 -> health check와도 연관됨
   • record등록 시, region도 선택해줘야함 -> ip로는 어떤 region인지 식별 불가

5. Geolocation
   • 사용자 실제 위치 기반 (지연시간과 유사하지만 다름)
   • 해당 도메인에 접근할 수 있는 지역을 사전 지정 (대륙/국가 단위)
   • 일치하는 위치가 없는 경우, 사전 생성되어 있는 default record로 라우팅됨
   • Use case : 특정 언어로된 웹사이트에 특정 언어권 지역의 사용자만 접근할 수 있도록 설정

6. Multi-Value Answer

   • 트래픽을 다중 리소스로 라우팅할 때 활용 -> 다중 값/리소스 반환
   • 반환되는 값은 health checker에 의해 정상으로 판단된 값 (최대 8개 반환) -> client측면의 load balancing
   • 다중값을 반환하는 Simple방식과의 차이점은 Simple방식은 health check와 관련되어있지 않음

7. Geoproximity (using Route53 Traffic Flow Feature)

   • 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅해주는 방식
   • 편향값(bias)를 기반으로 특정 지역의 리소스로 트래픽을 전환함
   • 특정 리소스에 더 많은 트래픽을 보내기 위해 편향값(bias)을 증가시켜 확장해야 함
   • 트래픽을 줄이기 위해 편향값을 음수로 줄여야 함
   • 리소스의 위치 판단
     • AWS 리소스의 경우 region으로 계산
     • 온프레미스의 경우 위도-경도 값을 지정해줘야 함
   • 편향값 활용을 위해 고급 Route53 트래픽 플로우 활용

8. IP-Based
   • IP주소기반 라우팅 방식
   • CIDR(IP주소) 목록 정의 필요 (이후 CIDR에 endpoints 매핑)
   • use case : 특정 업체가 특정 IP대역을 활용한다는 것을 알고있다면, 특정 업체만의 서비스를 제공하기 위해 활용될 수 있음

health checks

• health checks : pubcli resources에 대한 상태 확인 방법 -> DNS의 장애조치 자동화
  
  
  

• health check types

1. public endpoints 모니터링
   • application, server etc...
   • ip, hostname 지정 가능
   • 특정 인스턴스에 대한 전세계 15개 region에서온 health check에 응답함 -> region별 임계값을 비교한 후 정상/비정상 판단
   • Interval은 10/30s 선택 가능
   • HTTP/HTTPS/TCP 등 프로토콜 지원
   • global region의 18% 이상이 정상이라고 판단한다면 Route53에서도 해당 인스턴스를 정상으로 간주
   • 상태확인은 2xx/3xx 응답만 성공으로 간주
   • 텍스트 기반 응답의 경우, 처음 5120bytes를 읽고 정상/비정상 판단
   • 상태확인이 가능하려면 상태확인이 필요한 인스턴스에 접근이 가능해야 함 (route53의 ip주소범위에 대한 권한을 허용해야 함)

2. Calculated Health Check
   • 하위 health check 값을 확인하고 최종 계산하여 정상/비정상 판단
   • 하위 health check값 계산 방법은 OR/AND/NOT이 있음
   • 하위 health check는 256개까지 생성 가능
   • 하위 health check 통과 갯수를 지정할 수 있음
   • 몇몇의 하위 health check 상태와 관계없이 상위 health check로 웹사이트를 유지하려는 경우 활용됨

3. Privated Hosted Zones
   • Route53의 health checker는 모두 VPC 외부에 있음 -> VPC 내부의 인스턴스에 접근 불가
   • Route53이 CloudWatch를 통해 VPC 내부 health check 가능
   • CloudWatch가 metic에 침해되는 경우, 알람을 발생시키고 Route53이 이를 인지하여 비정상 판단하는 방식

Domain Registrar vs DNS Service

• Domain Registrar : Domain이름을 등록하는 서비스, 이에 따른 비용지불 필요
• Amazon Route53이 아닌 다른 Domain Registrar활용 가능 (ex. GoDaddy, Amazon Registrar, Google Domain 등)
• Domain Registrar를 이용한다면 DNS 레코드 관리를 위한 DNS 서비스 제공 (Route53 이용 시, DNS 레코드 관리를 위한 Route53 Hosted Zone을 가짐)
• 도메인을 타사(ex. GoDaddy 등)에서 구매하고 해당 도메인을 Route53에 등록한다면, Route53에서 DNS 서비스 이용 가능
  1. Route53 public Hosted Zone 생성
  2. 타사 custom nameservers를 Route53 public Hosted Zone 세부정보의 Name Server로 변경 -> 사용자가 도메인으로 쿼리를 하면 타사 도메인은 Route53의 name server를 가리키게 되고, 해당 name server의 정책을 따르게 됨
• 결론 : Domain Registrar != DNS Service