woongs dogfoot

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

AWS RDS

• RDS : 관계형 데이터베이스
• AWS RDS : AWS RDS 인스턴스에 DB를 생성할 수 있고, 올려진 DB는 AWS에 의해 관리됨
• RDS Type

1. Postgres
2. MySQL
3. MariaDB
4. Oracle
5. Microsoft SQL Server
6. Aurora
   
   
   

• EC2가 아닌 RDS에 DB서비스를 배포하는 이유

1. DB 프로비저닝과 기본 운영체제 패치가 자동화 되어 있음
2. 지속적으로 백업 생성 -> 특정 시점으로 복원 가능
3. 대시보드에서 성능 모니터링 가능
4. 읽기 전용 복제본을 활용하여 읽기 성능을 개선할 수 있음
5. 재해 복구 목적으로 다중 AZ 설정 가능
6. 수직 확장 및 읽기 전용 복제본 생성을 통한 수평 확장 가능
7. 파일 스토리지는 EBS에 구성 -> RDS와 연결될 Storage를 의미
8. EC2 인스턴스에 DB를 배포할 때 설정할 모든 것들을 AWS에서 제공
   
   
   

• SSH로 접근할 수 없다는 단점이 있음

• RDS는 EC2기반 -> RDS 생성 시, EC2 설정처럼 CPU, RAM 등 스펙을 설정할 수 있음

• RDS는 DB서버이고, 실제 데이터 저장은 EC2의 EBS에 저장됨 (RDS도 EC2 기반이기 때문)

• Connectivity 설정을 이용하면 Security Group 설정이나 VPC 등 세부적인 네트워크 설정을 자동으로 해주기 때문에 별도 설정 필요 없이 EC2와 연결할 수 있음 (EC2 외의 다른 컴퓨터에서 접근할 경우, 세부 네트워크 설정 필요)
  
  
  

• Storage Auto Scaling : DB에 데이터가 많이 쌓이면 공간이 부족해질 수 있는데, RDS가 이를 감지해서 자동으로 스토리지(EBS) 용량을 확장해줌

1. 스토리지(EBS) 용량 확장을 위해 DB 다운이 필요하지 않음
2. 최대 스토리지 임계값을 설정해야 함 (확장 최대값)
3. 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정
4. 스토리지 부족 상태가 5분 이상 지속되면 스토리지를 자동으로 수정
5. 지난 수정으로부터 6시간이 지났을 경우에 스토리지를 자동으로 수정
6. workload를 예측할 수 없는 application에 유용함
   
   
   

RDS Read Replicas for real scalability (RDS 읽기 전용 복제본)

• 특징

1. 최대 15개까지 생성
2. 동일 가용영역, 여러 가용영역, 여러 Region에 걸쳐 생성될 수 있음
3. Main RDS와 비동기식 복제가 진행됨 -> Main RDS에 write하고 읽기전용 RDS를 읽을 경우, 일관적인 데이터 수집 가능
4. DB로 승격 가능 -> 자체적인 생애 주기를 가짐
   
   
   

• Use Case : 특정 application의 DB에 대한 데이터 분석이 필요한 경우, Main RDS에 직접 접근하여 데이터를 추출하면 application이 느려질 수 있음 -> 읽기전용 Replica를 생성하여 데이터 분석용으로 제공하면 application에 대한 영향도를 없앨 수 있음
  
  
  

• Network Cost

1. 특정 가용영역에서 다른 가용영역으로 데이터가 이동할 때 비용 발생 -> 관리형 서비스는 예외 (RDS 읽기 전용 복제본은 관리형 서비스) -> 다른 가용영역이나 동일 region내에 읽기전용 복제본이 있을 경우, 비용이 발생하지 않음
2. RDS 읽기 전용 복제본이 다른 Region에 존재하는 경우, 네트워크에 대한 데이터 복제 비용 발생
   
   
   

• RDS Multi AZ (Disaster Recovery)

1. Master DB의 모든 변화를 동기적으로 RDS standby 인스턴스에 복제 (RDS standby 인스턴스는 다른 가용영역에 생성)
2. Master DB에 문제가 발생할 때, standby RDS에 자동으로 장애 조치가 수행됨 (standby가 임시적으로 master가 됨) -> 하나의 RDS DNS를 갖고있기 때문에 가능 (RDS DNS는 DB의 엔드포인트가 됨)
3. standby RDS는 오직 장애에 대비한 대기 목적만 수행 (평시에는 사용 불가)
4. standby RDS로 읽기전용 복제본을 생성할 수도 있음

• Single-AZ to Multi-AZ

1. 다운타임이 없음 (DB 중지 필요x)
2. DB 설정에서 Multi-AZ 활성화 시, 다른 가용영역에 Standby DB가 자동으로 생성됨
3. 내부적으로 발생하는 일
   • RDS의 Snapshot 생성
   • 생성된 Snapshot은 새롭게 생성된 Standby DB에 복원됨
   • Main-Standby간 동기화가 설정됨
     
     
     

RDS Custom

• RDS에서는 운영체제 및 데이터베이스 관리자 권한 기능에 접근하지 못함 -> RDS Custom에서는 가능 (Oracle, Microsoft SQL Server)
• SSH 활용 접근
• Custom 기능
  1. Configure Settings
  2. Install Patches
  3. Enable Native Features
     
     
     

Amazon Aurora

• 특징

1. postgres 및 MySQL 호환 (해당 DB의 드라이버만 사용 가능) - Aurora MySQL, Aurora P ostgreSQL
2. AWS 고유 기능
3. 클라우도 최적화 (MySQL보다 5배 높은 성능, Postgres보다 3배 높은 성능)
4. Storage 자동 확장 (10GB, up to 120TB)
5. 기본적으로 클라우드 네이티브 환경이므로 빠른 장애 조치 (its HA native)
6. 비용은 RDS에 비해 20% 높음
7. BackTrack : 특정 시점으로 데이터 복원하는 기능 (백업에 의존하지 않고 다른 기능 활용)
   
   
   

• High Availability

1. 3개 가용영역에 걸쳐 6개의 데이터 사본 저장 (AZ하나가 비정상이어도 괜찮음)
2. 일부 데이터에 문제가 있을 경우, P2P 복제를 통한 자가복구 과정이 있음
3. 단일 볼륨이 아닌 수백 개의 볼륨을 활용 (AWS에서 관리)
4. RDS의 multi-AZ와 유사
5. master DB가 작동하지 않으면 30초 이내로 자동 장애복구 진행 (작은 블록 단위로 자가복구, master DB 변경 등)
6. master DB에 문제가 생기면 읽기 전용 DB중 하나가 master가 될 수 있음
7. region간 복제 지원
8. 읽기 전용 복제본은 15개까지 가능, 복제 속도도 상대적으로 빠름 (MySQL은 5개까지)

• Aurora DB Cluster

1. master가 바뀌거나 장애조치를 대비하여 writer Endpoint 제공 (DNS로 항상 master를 가리킴)
2. 읽기 전용 DB의 자동 Scaling이 진행됨 (적절한 인스턴스 수 유지, CPU사용량/인스턴스 평균 연결 수 기반)
3. Reader Endpoint (인스턴스 전용 Endpoint와 다른 개념)
   • connection load balancing : 모든 읽기전용 인스턴스와 자동 연결
   • client가 Reader Endpoint로 요청 시, 다중 읽기전용 인스턴스 중 하나로 자동 연결
   • load balancing은 connection 레벨에서 진행됨
4. 크기가 큰 global Aurora 인스턴스인 경우, Aurora Cluster내에 다른 region을 추가할 수 있음

• Aurora Auto Scaling

• Custom Endpoints
  : db.r3.large, db.r5.2xlarge 두 종류의 읽기전용 Aurora 존재 -> Aurora 인스턴스 일부를 Custom Endpoint로 정의 -> Custom Endpoint에는 성능이 더 좋은 db.r5.2xlarge 인스턴스를 연결하여 application 단에서 해당 Custom Endpoint에는 많은 연산이 필요한 쿼리를 날릴 수 있도록 할 수 있음 -> custom endpoint를 만들기 시작하면 reader endpoint를 사용할 것이 아닌 남은 인스턴스를 연결한 Custom Endpoint를 생성해줘야 함.

• Serverless (다시 봐야함)
  : 간헐적이고 예측 불가능한 업무량에 대응 -> capacity planning 불필요 -> 초당 비용을 지불하는 것이 효율적

• Global Aurora

1. 리전간 읽기전용 복제 가능 (읽기/쓰기 가능 primary region, 최대 5개 읽기 전용 secondary region, 보조 region당 최대 16개 읽기 전용 인스턴스) -> global한 읽기 요청에 대한 응답 지연 감소에 도움됨
2. 특정 region에 장애가 생겼을 경우, 다른 region으로 primary region전환 재해복구 (복구시간 1분 이내)
3. 특정 region에서 다른 region으로 데이터 복제 시, 1초 이하의 시간 소요

• Aurora Machine Learning
  : Aurora활용 Machine Learning 예측 기능을 application에 추가할 수 있음
  
  
  

1. Supported Service
   • SageMaker : 어떤 종류의 기계학습 모델이라도 사용할 수 있게 해줌
   • Comprehend : 감정 분석
2. Use case
   • 이상행위 탐지
   • 광고 타겟팅
   • 감정 분석
   • 상품 추천
   • etc...

RDS Backups

• 매일 자동으로 백업 수행 (during backup window)
• 5분마다 트랜잭션 로그 백업
• 백업 보존기간은 0~35일 사이로 설정 가능
• 수동 DB Snapshots => 원하는 기간동안 백업 유지 => 비용절감으로 사용할 수 있음 (ex. 한달에 두시간만 사용하는 DB를 Snapshot으로 백업해 둔 후, 원본 DB는 완전히 내려서 비용 절감)
  
  
  

Aurora Backups

• 자동화된 백업 (1~35일) => 비활성화 불가
• 해당 기간의 어느 시점으로든 백업 가능
• 수동 DB Snapshot은 RDS Backups과 동일
  
  
  

RDS/Aurora Restore Options

• 자동화된 백업이나 수동 snapshot으로 DB 복원 가능
• S3에서 MySQL로 복원 가능 (ex. 온프레미스의 DB를 S3에 백업 -> S3에서 RDS로 DB 복원 -> 온프레미스에서 RDS이동 가능)
• 온프레미스->Aurora로 복원을 위해서는 외부적으로 Percona XtraBackup 소프트웨어 사용 필요 -> 해당 소프트웨어로 온프레미스 DB의 백업파일을 S3로 보낼 수 있음
  
  
  

Aurora DB Cloning

• 기존 DB cluster -> 새로운 Aurora DB cluster 생성 가능
• Use case : 운영환경의 데이터로 테스트를 진행하고 싶을 때 활용 가능 (운영환경 데이터를 개발환경 DB에 이동) -> 운영환경 Aurora DB 복제 (Snapshot 생성 후, 복원하는 것보다 훨씬 빠름 -> copy-on-write 프로토콜 사용하기 때문)
• 일반 DB 복제는 원본과 복사본이 같은 스토리지를 공유 -> Aurora DB Cloning은 스토리지까지 복제하는데 RDS에 비해 빠르기까지 함
  
  
  

RDS Security

• DB가 처음 실행될 때, 원본과 복사본이 AWS KMS를 활용하여 모두 암호화됨
• 원본 DB가 암호화되지 않았다면, 복사본도 암호화할 수 없음
• 암호화 type
  1. in-flight encryption : TLS 인증서 필요, client와 DB간의 전송 중 데이터 암호화
  2. IAM Authentication : username/password 대신에 IAM Role을 활용하여 DB에 접근할 수 있음
  3. Security Groups : DB에 대한 네트워크 접근 통제 가능 (방화벽과 유사)
  4. RDS/Aurora에 SSH 접근 불가 (AWS에서 관리하기 때문, RDS 커스텀 서비스를 사용한다면 예외)
  5. 감사 log : 시간에 따라 어떤 쿼리가 생성되고 있는지 확인 가능 (로그의 장기간 보관을 위해서는 CloudWatch 서비스 활용 필요)
     
     
     

RDS Proxy

• 완전 관리형 RDS DB Proxy 배포 가능
• Why proxy?
  1. application이 DB내에서 connection pool을 생성하고 타 app과 공유할 수 있음 (proxy가 하나의 pool에 연결을 모음) -> RDS로의 직접 연결을 줄일 수 있음 -> 연결이 많은 경우 CPU, RAM과 같은 컴퓨팅 리소스에 부담이 생길 수 있음
  2. DB로의 private 접근
  3. DB timeout 최소화
• RDS Proxy는 완전히 서버리스
• Auto Scaling이 가능하여 용량 관리가 불필요하고 가용성이 높음 (multi-AZ)
• 장애 조치 시간을 최대 66%까지 줄일 수 있음 (How?) -> main RDS 인스턴스에 app들 을 모두 연결하고 장애조치를 모두 처리하게 하는 것이 아닌, 장애 조치에 무관한 app들은 proxy에 연결 -> app코드를 모두 수정하지 않아도 되고, 장애조치가 끝난 후 proxy에 연결만 하면 되어서 장애조치 시간이 감소됨
• EC2 인스턴스간 connection pool을 공유하기 때문에 연결 시간을 아낄 수 있음
• MySQL, PostgreSQL, MariaDB용 RDS/MySQL, PostgreSQL용 Aurora 지원
• DB에 IAM 인증을 강제함 -> IAM인증을 통해서만 DB 인스턴스에 접근할 수 있음
• RDS Proxy는 public에서 접근할 수 없음 (VPC내에서만 접근 가능)
• Lambda Functions : RDS Proxy와 사용하기 좋음 (Lambda는 여러 개가 생성되고 사라지는 속도가 매우 빠름 -> RDS 인스턴스에 직접 접근하면 연결에 timeout 발생 가능성이 높아짐) -> Lambda Function이 RDS Proxy를 overload함 -> RDS 인스턴스로의 직접 연결이 줄어듦
  
  
  

ElasticCache

• RDS가 관계형 DB를 관리하는 방식과 동일

• 캐싱기술인 Redis나 Memcached를 관리

• 캐시를 이용하면 매번 DB에 접근하지 않아도 빠른 데이터 조회 가능

• application의 상태 또한 저장하여 관리할 수 있음

• AWS가 서비스를 관리 (OS패치, 최적화, 설정, 구성, 모니터링, 장애복구, 백업 등)

• 캐싱서비스 사용 = application 코드 변경 (DB가 아닌 캐시를 쿼리하도록)

• 캐시 무효화전략(=캐시삭제) 필요 (가장 최신 데이터만 사용되어야 하기 때문)
  
  
  

• Architecture

1. application -> cache에 사전 쿼리 이력이 있는지 확인 (있다면 cache hit라고 부름)
2. 쿼리 이력이 있다면(cache hit), 쿼리에 대한 응답을 캐시저장소로부터 받아옴
3. 쿼리 이력이 없다면(cache miss), DB에 쿼리를 날려 데이터를 가져옴
4. 해당 쿼리와 응답을 캐시저장소에 저장

• 사용자 세션(상태) 저장 Architecture

1. 사용자가 어떤 application에 로그인하면, application은 세션데이터를 캐시저장소에 write
2. 사용자가 app의 다른 인스턴스로 redirect되면, 해당 app은 요청 사용자에 맞는 세션데이터를 캐시저장소로부터 조회해 옴 (사용자 로그인 유지) => app이 직접 세션을 저장할 필요가 없기 때문에 상태 비저장 app 구현 가능
   
   
   

• Redis vs Memcached

1. Redis (장점, 데이터 내구성/가용성)
   • 자동 장애 조치 기능이 있는 Multi-AZ
   • 읽기 복제본 가능 (RDS와 매우 유사)
   • AOF(?)를 이용한 데이터 지속성
   • 백업 및 복원 기능
   • keyword : set, sorted set 지원(?)
2. Memcached (분산되어 있는 순수 캐시)
   • 데이터 분할(paritioning)을 위해 멀티 노드 활용 (sharding)
   • 고가용성x, 복제x, 영구 캐시x
   • 백업x, 복원x
   • 멀티스레드 아키텍처
     
     
     

Cache Security

1. Redis

• Redis만 IAM 인증 지원 (나머지는 username/password)
• Redis AUTH : Redis 인증을 위한 password와 token 생성 -> 캐시에 추가 보안 제공, Redis 보안그룹에 해당 pwd와 토큰을 인증해야 함
• SSL 전송중 암호화 지원
  
  
  

2. Memcached

• SASL 기반 인증 제공
  
  
  

ElasticCache 패턴

1. Lazy Loading : 모든 read 데이터 캐싱 -> 조회 지연 발생
2. Write Through : DB에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트
3. Session Store : 세션 유지시간을 사용하여 만료 시 캐시 데이터 삭제
   
   
   

• Redis Use Case : Gaming Leader Board (아래 기능 활용)
• Redis Sorted Sets : 고유성과 순서를 보장 (요소가 추가될 때마다 실시간으로 순위를 매김)

Auto Scaling Group (ASG)

• Auto Scaling Group (ASG) : 트래픽의 변동에 따라 자동으로 AWS API를 호출하여 EC2 인스턴스를 늘리거나 줄여주는 기능 (자동 Scale out/in)
  
  
  

• 특징

1. 매개변수를 통해 EC2 인스턴스의 최대/최소/희망 갯수를 조절할 수 있음
2. ASG를 Load Balancer와 연결할 경우, ASG내의 인스턴스가 추가될 때 자동으로 Load Balancer와 연결됨
3. ASG내 특정 인스턴스의 상태가 비정상일 경우, 해당 인스턴스를 종료하고 새로운 인스턴스를 생성함 (희망갯수 유지)
4. ASG is free
5. scale out/in 시, 희망갯수는 최대/최소 갯수 내에서 설정됨
6. ELB가 비정상이라고 판단하는 인스턴스가 ASG내에 있을 경우, ASG는 해당 인스턴스를 자동으로 종료하고 새로운 인스턴스를 생성
7. Launch Template : EC2 인스턴스를 시작하는 방법에 대한 정보가 포함되어 있음
   • AMI
   • Instance Type
   • EC2 User Data
   • EBS Volumes
   • Security Groups
   • SSH key pair
   • IAM Roles for your EC2 Instances
   • Network + Subnets Information
   • Load Balancer Information
   • etc...
8. Scaling 정책 정의 필요
   • CloudWatch : 모니터링 지표(metric, CPU사용량 등)을 기반으로 Alarm을 울리는 기능 -> CloudWatch Alarm 기반으로 scale out/in을 수행할 수 있음 -> Alarm기반 Scaling 정책
     
     
     

• Capacity

• Load Balancer + ASG is good

• Dynamic Scaling Policies

1. Target Tracking Scaling
   • CloudWatch를 생성할 수 있음
   • case : EC2 인스턴스의 CPU사용량을 추적하여 수치가 40%에 머무를 수 있도록 조정 (기준치 설정 필요)
2. Simple/Step Scaling
   • 기생성된 CloudWatch 활용
   • case 1 : CloudWatch Alarm을 설정하고 전체 ASG의 CPU사용량이 70%를 초과하는 경우, 인스턴스 두개 추가
   • case 2 : CloudWatch Alarm을 설정하고 전체 ASG의 CPU사용량이 30%를 미달하는 경우, 인스턴스 한개 삭제
   • CloudWatch 설정 시, 인스턴스를 몇개 추가하고 삭제할 것인지에 대한 설정 필요
   • Step Scaling : 다수의 경보 값을 기준으로 여러 Scaling Step을 진행하도록 할 수 있음
     
     
     

• Scheduled Actions

  • 사용자 트래픽 증감의 예측이 가능할 때
  • case : 금요일 오후 5시에 큰 이벤트가 예정되어 있으니 많은 사람들의 사용을 대비하여 ASG의 최소용량을 매주 금요일 오후 5시마다 자동으로 10으로 늘려줌 -> Scaling 작업을 예약
    
    
    

• Predictive Scaling

  • AWS내 Auto Scaling 서비스를 활용하여 지속적으로 트래픽 이력을 생성
  • 머신러닝 기반
  • 생성된 트래픽 이력을 보고 다음 트래픽을 예측하여 Scaling 진행 -> 자동 Scaling 작업 예약
    
    
    

• Scaling을 위한 Metics

1. CPU 사용량
2. 타겟당 요청 수 (Request Count per Target)
3. 평균 네트워크 입출력량 (Average Network In/Out) -> 네트워크에 연결되어 있는 상태에서 네트워크 병목을 방지를 위함
4. Any Custom Metrics (CloudWatch 활용)
   
   
   

• Request Count per Target

• Scaling Cooldown : 스케일링 작업이 끝날 때마다 기본적으로 5분 or 300초의 Cooldown 시간을 갖는 기능

1. 인스턴스의 안정적인 생성과 새롭게 기록되는 지표(metric)들의 양상을 정확하게 확인하기 위함
2. Cooldown 시간 동안에는 ASG가 인스턴스를 생성하거나 종료시킬 수 없음
3. 인스턴스 구성 시간을 단축시킬 수 있는 AMI를 활용하여 인스턴스를 보다 빠르게 생성하여 요청을 받을 수 있는 상태로 만드는 것이 좋음 -> 별도 cooldown 시간을 단축시킬 수 있음 -> ASG상의 더 많은 Scaling 작업을 진행할 수 있음
   
   
   

• stress amazone linux2 설치를 통해 임의로 인스턴스의 CPU사용량을 늘릴 수 있음