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환경과 달리 고가용성에 초점