EC2(Elastic Compute Cloud)

IaaS 서비스 입니다. EC2는 아래의 서비스들을 포함하는 의미로도 정의할 수 있습니다.

• EC2(Virtual machine)
• EBS(Virtual storage drive)
• ELB(Load Balancer)
• ASG(auto-scaling group)

EC2의 결정조건

• OS
• CPU
• RAM
• Storage Space(Network 기반인지 하드웨어 기반인지)
• Network card(public IP, speed)
• Firewall 규칙(security group)
• bootstrap script(첫번째 launch시 설정내용)

EC2 User Data(Bootstrap Script)
update나 software 설치, 파일설치 등 처음 인스턴스를 생성할 때 입력해줄 스크립트
root 권한을 가진 채로 실행

EC2 인스턴스 타입

m5.2xlarge라는 인스턴스 타입은 아래와 같은 의미를 가집니다.

• m : instance class
• 5 : generation
• 2xlarge : instance class 내에서 size

Instance Family

1. General Purpose
compute, memory, networking의 밸런스가 잘 맞는 인스턴스(t2.micro 등)
2. Compute Optimized
컴퓨팅 성능(batch process, media, ml, gaming)이 보장되어야 하는 인스턴스(c로 시작)
3. Memory Optimized
메모리 성능(DB)이 필요한 인스턴스(r, x로 시작)
4. Storage Optimized
r/w가 잦고 대용량 데이터셋 처리가 필요한 인스턴스(i, d로 시작)

Security Group

Firewall 규칙에 대해서 그룹 단위로 정의할 수 있습니다.

• Allow Rule만 포함
• IP나 다른 Security Group에 의해 참조될 수 있음
• 여러 인스턴스에 붙일 수 있음
• SSH 액세스마다 1개의 Security Group을 가지는 것을 권장함

  Timeout 발생 시 대부분은 Security Group의 에러입니다.
  Connection Refused는 application error입니다.

자주 쓰는 Port

21: FTP-file share에 파일 업로드
22: SFTP-SSH로 FTP
3389: RDP-윈도우 인스턴스 로그인(리눅스의 22같은 논리)

SSH

암호키 기반으로 서비스에 접근할 수 있는 방식

• Mac, Linux, Windows 10이상 지원(10이하는 Putty 써야함)
• Amazon Linux OS에 대해서는 Instance Connect를 통한 웹 접근을 지원함
• SSH로 접근하기 위해 Key의 권한은 400으로 되어야함
• ssh -i keyname.pem ec2-user@ip-addr

EC2 인스턴스 구매 옵션

• On Demand: 초단위 가격 책정
• Reserved(1 & 3 years) => 인스턴스 타입, OS 등을 예약하여 사용. AWS Marketplace에서 판매가 가능하고, OS나 테넌시를 바꿀 수 있는 Convertible Reserved도 존재

  DB처럼 steady state에 유용합니다.

• Savings Plans(1 & 3 years) => Instance Family(t3, m5등)과 Region이 고정됨. 일정 금액까지는 고정액이고, 그 뒤로는 On Demand 요금으로 부과
• Spot Instances => 초기 설정한 가격이 초과되면 바로 인스턴스가 삭제됨.

  작은 workloads나 failure가 상관없는 batch job에 쓰임

• Capacity Reservations => AZ에 일정 용량 예약. 인스턴스가 실행중이 아니여도 charge됨
• Dedicated Hosts => 전체 물리 서버를 예약하는 방식으로, 가장 비쌈.

  보안 규정이 심하거나 서버 설정이 자주 변경되면 안되는 환경에서 필요

• Dedicated Instances => 인스턴스가 할당된 물리서버를 점유하지만, 어떤 물리서버에 배치할 지 정하는 것은 AWS가 담당함.
  

AMI(Amazon Machine Image)

EC2 인스턴스의 커스터마이징으로, region specific하게 만들어지지만, 다른 region으로 copy가 가능합니다.

AMI 생성 방법

1. EC2를 생성하고 Customize를 합니다.
2. Instance를 stop합니다.(Snapshot 위해)
3. AMI를 Build합니다. (이때, EBS Snapshot도 자동생성이 됩니다.)
4. 만들어진 AMI로 새 인스턴스를 만듭니다.

EC2를 실행시키는 방법

• Public AMI
• own AMI
• AWS Marketplace AMI

EBS

Network Drive로(Physical Drive X) AZ에 종속적입니다. 따라서 같은 AZ에 있는 인스턴스에만 부착이 가능하고, 하나의 Volume은 1개의 인스턴스에만 붙을 수 있습니다.

Instance가 terminate되어도 data를 유지할 수 있는 USB Stick과 같습니다. 단, Root Volume은 기본적으로 Instance를 삭제 시 같이 삭제되도록 설정되어 있습니다.

Volume의 용량은 미리 지정해야 합니다(Provisioned Capacity)

EBS Snapshot

Volume의 특정 시점 Backup으로 AZ에 독립적입니다.

EBS Snapshot Features

• Snapshot Archive: 싸지만 24~72시간 가량 restore 시간이 걸림
• Recycle Bin: 휴지통으로 보냄(retension은 1일~1년 설정가능)
• Fast Restore: Latency가 없도록 하지만 비쌈

EC2 Instance Store

인스턴스 내에서 직접 파일시스템을 파티셔닝 하는 과정입니다. 이는 EBS가 Network Based이기 때문에 성능 제약을 해결하고자 사용합니다.

Disk에 저장하는 방식인데 하드웨어가 Fail이거나, 인스턴스를 Stop했을 때 데이터를 잃어버릴 수 가능성이 존재합니다. 이때의 백업 responsibility는 사용자에게 있습니다.

Buffer, Cache, scratch data를 저장하고자 할 때 유용합니다. 특히 IOPS가 10만 이상의 큰 성능을 요구한다면 io나 gp Volume으로는 불가능하기 때문에 Instance Store를 택해야 합니다.

EBS Volume Types

Volume의 종류는 size, throughput, IOPS(I/O per sec)에 따라 구분됨

• gp2/3 : General Purpose, SSD(1GB - 16TB)
• io1/2 : High Performance, SSD => IOPS는 64000정도
• st1 : Low cost, Frequently Accessed, HDD
• sc1 : Lowest cost, not frequent, HDD

  이때 Boot Volume으로는 gp와 io로만 가능

gp2/3 VS io1/2

io1이나 io2는 아래의 시점에서 장점이 있습니다.
1. sustained IOPS
2. database worklaoad
3. multi EBS attach

EBS Multi Attach
기본적으로 EBS는 Multi Attach가 불가능하지만 io 타입에 대해서는 가능합니다. 단, 여전히 같은 AZ 안에서만 가능합니다.

• 여러 인스턴스가 하나의 volume에 대해 r/w full access가짐
• 최대 16개까지 가능
• 여러 앱이 concurrent write가 필요할 때
• 단, File System은 cluster-aware이어야함(XFS, EX4 불가능)

EFS(Elastic File System)

여러 EC2나 Lambda에 걸쳐 올릴 수 있는 Network File System입니다. 여러 AZ에 걸쳐 사용이 가능하고 Security Group으로 감싸진 EFS를 통해 서로 통신할 수 있습니다.

• 장점: 고가용성, 확장성(사용량에 따라 자동으로 확장됨)
• 단점: Linux Based AMI만 가능, 비쌈

EFS Performance

Performance Mode

• General Purpose
• Max I/O: 짧은 지연시간 보장

Throughput Mode

• Elastic(권장): Unpredictable workload시 좋음 -> 이땐 Performance mode가 general purpose로 고정
• Provisioned: throughput을 예상할 수 있을 때
• Bursting: Storage의 양에 따라 scale이 되기를 원할 때
  

Storage Classes

• Standard: SSD 사용
• Infrequent Access(IA): Cost-Optimized(분기별로 몇번씩만 이용할 때)
• Archive: 1년에 몇번만 이용할 때

  LifeCycle 설정 시 일정기간 지나면 더 싼 storage로 내릴 수 있음

File System Type

• Standard(Regional): multi AZ에서 가능(prod용)
• One Zone: 한곳에서 가능(dev용)

EBS vs EFS

EBS	EFS
한개의 인스턴스만 사용가능	여러 인스턴스가 공유가능
AZ에 묶여있다(io제외)	여러 AZ에서 사용가능
Snapshot을 찍어 AZ를 옮길 수 있다
Backup에 I/O를 하기때문에 트래픽이 많을 때 하면안됨
	Linux 인스턴스만 가능
	비싸다

ELB(Elastic Load Balancer)

트래픽을 여러 서버로 Forwarding하는 역할을 합니다. ELB의 운영과 기능은 AWS에서 관리하기 때문에 사용자는 손쉽게 서비스를 이용할 수 있습니다.

• 단일 DNS를 통해 어플리케이션에 접근할 수 있도록 함
• Healthcheck, failure 감지 가능
• HTTPS 기능 제공(X.509기반)
• 여러 AZ에 걸친 고가용성 제공
• Cookies를 통한 Stickiness로 특정 사용자가 계속 동일한 서버에 접속되도록 유도함
• Private Traffic과 Public Traffic을 분리함
• ELB에 따라 Public으로도, Private으로 사용할 수 있음

  Healthcheck는 보통 특정 Port의 특정 Route에 요청을 보냈을 때 응답이 정상적으로 오는지 확인함으로써 인스턴스의 생존 여부를 확인합니다.
  ex) HTTP :4567/health

ELB Types

• ALB(Application Load Balancer) : L7에서 동작하는 HTTP, HTTPS, Websocket
• NLB(Network Load Balancer) : UDP, TCP, TLS
• GLB(Gateway Load Balancer) : L3 수준에서 동작 => 보안 관련 처리를 해야할 때 유용함

ALB

ALB의 특징

• HealthCheck로 HTTP, HTTPS를 지원합니다.
• Route나 Domain, Query String 등으로 로드밸런싱 할 수 있으므로 MSA 구조나 컨테이너 기반 어플리케이션에 좋습니다.
• ALB를 통해 Client-Application 간 통신을 주고받을 때, 어플리케이션으로 보내지는 요청의 Host는 ALB의 Private IP가 됩니다. 따라서 Client의 IP를 알기 위해서는 X-Forwarded-For 헤더를 통해 확인해야 합니다.

ALB의 Target Group

• EC2(HTTP)
• ECS(HTTP)
• Lambda
• Private IPs

권장되는 Security Group 설정

1. Load Balancer의 Inbound는 80, 443으로 제한합니다.
2. ELB와 연결될 EC2는 80(HTTP)로 제한하는데, 이때 Source는 ELB의 Security Group으로 제한합니다.

NLB

NLB의 특징

• AZ마다 고정된 static IP를 할당시킬 수 있습니다.(EIP로도 지정가능) 따라서 whitelist를 지정할 때 유용합니다.
• Free Tier에서 지원하지 않습니다.
• HealthCheck로 HTTP, HTTPS와 더불어 TCP, TLS도 지원합니다.
• 수백만 개의 요청을 처리할 때 유용합니다.

NLB의 Target Group

• EC2 Instances
• Private IPs
• ALB

GWLB

제3의 가상 머신 이미지를 통과시켜서 어플리케이션에 접근시키고자 할 때 사용할 수 있습니다.

GWLB의 특징

• Firewall, Packet Inspection 등을 방지할 수 있습니다.
• Transparent Network Gateway(모든 트래픽이 거쳐가는 통로) + Load Balancer의 기능을 가지고 있습니다.
• GENEVE 프로토콜(6081)을 사용하고 있습니다.

GWLB의 Target Group

• EC2 Instances
• Private IPs

Sticky Session(Session Affinity)

동일한 사용자의 요청은 이전과 동일한 인스턴스로 보내질 수 있도록 하는 기능입니다. Cookie를 이용하여 stickiness를 제공(만료가 존재)하는데, 이렇게 하는 이유는 session을 잃지 않도록 하기 위해서입니다.

Cookie Names

Application-Based Cookies

1. Custom Cookie
   • Custom attribute도 추가 가능
   • AWSALB, AWSALBAPP, AWSALBTG와 같은 예약된 쿠키명은 사용 불가
   • Target에 의해 생성됨
2. Application Cookie
   • Load Balancer에 의해 생성됨
   • AWSALBAPP이란 이름 사용

Duration-Based Cookies

• AWSALB라는 이름 사용
• Load Balancer에 의해 Duration이 관리됨

Cross-Zone Load Balancing

Cross-Zone LB를 지원하면, 특정 AZ에 더 많은 인스턴스가 존재하는 것과 무관하게 모든 인스턴스에 대해 1/N만큼씩 로드밸런싱을 진행하게 됩니다.

만약 Cross-Zone을 지원하지 않았다면, AZ를 기준으로 로드밸런싱이 진행되고, 해당 AZ에 인스턴스 수가 적다면 자주, 많다면 조금씩만 할당받게 됩니다.

Cross-Zone은 ALB에 대해서만 기본값으로 켜져 있습니다. 그 외의 LB에 대해서는 비용이 부과됩니다.

SNI(Server Name Indication)

하나의 웹 서버에서 여러 host를 다룰 때 어떤 인증서를 가져올지 결정할 수 없습니다. 이 문제를 해결하기 위해 클라이언트에서 SSL의 헤더 부분에 host명을 명시하도록 하는 SNI가 등장합니다.

AWS 서비스 중에는 ALB, NLB, Cloudfront만 지원합니다.

Connection Draining(Deregistration Delay)

Deregister이거나 unhealty인 인스턴스에 대해서 이미 보내졌던 pre-flight만 받고 종료할 수 있도록 더이상 해당 인스턴스에 요청을 보내지 않는 기능을 의미합니다.

Deregistration Delay가 0이면 해당 기능을 사용하지 않는다는 의미입니다.

ELB의 HealthCheck를 활성화하면 이를 지원합니다.

ASG(Auto Scaling Group)

어플리케이션은 운영 단계에서 확장을 할 수도 축소를 할 수도 있습니다. ASG를 통해 특정 상황에서 EC2 인스턴스 수를 늘리거나 줄여 대응할 수 있습니다.

Cooldown
Scaling이 한번 진행되고 나면 기본적으로 300초 간 cooldown 상태가 됩니다. 설정한 시간이 지나야 다음 scaling을 진행할 수 있습니다.

장점

• Max와 Min을 지정하고, 해당 범위 내에서만 인스턴스 수가 조절되는 것을 보장
• 새로운 인스턴스를 ELB에 자동으로 등록
• Unhealthy와 같은 상황에서 recreate를 자동으로 실행
• 무료

ASG + CloudWatch
CloudWatch로 Metric을 모니터링한 후, ASG를 통해 Scale In/Out을 할 수 있다.

ASG 설정 내용

1. Launch Template

   • AMI + Instance Type
   • EC2 User Data
   • EBS Volumes
   • Security Groups
   • SSH Key Pairs
   • EC2 IAM Roles
   • VPC + Subnet Information
   • Load Balancer Information

2. Min/Max/Initial Capacity

3. Scaling Policy

Scaling Policy

• Target Tracking Scaling
  • ex) CPU 사용량을 60% 미만으로 하고싶다.
  • 가장 간단한 방식
• Simple Scaling
  • CloudWatch를 이용해 측정하고, 얼만큼 인스턴스 수를 조정할지 직접 설정
• Step Scaling
  • Simple Scaling에서 여러 step을 둘 수 있는 점에서 차이가 있음
• Scheduled Action
  • 서비스가 붐비는 시간대를 예측할 수 있다면 해당 시간에만 인스턴스를 늘리도록 설정
• Predictive Scaling
  • 예측해서 미리 scaling을 진행함

Metrics

• CPU Utilization
• RequestCountPerTarget
• Average Network In/Out

ASG Instance Refresh

Launch Template이 변경되었을 때 모든 인스턴스를 업데이트할 필요가 생기면 이 기능을 사용하는 것이 좋습니다. 또는 인스턴스가 Unhealthy할 때 인스턴스를 삭제시키면서 새로 생성할 수도 있습니다.

이때 Minimum Healthy Percentage를 설정하여, 몇 개의 인스턴스만 끄고 새로 생성하는 방식을 채택합니다.