EC2 Instance 내부에서 "http://169.254.169.254/latest"로 접근하여 EC2 Instance의 Meta 정보들 확인 가능
다음의 정보들 확인 가능
Instance-IP
Local-IPv4
IAM
ETC…
4. EC2 Instance Storage
EC2 Instance 저장소
4.1. EBS (Elastic Volume Service)
Network 기반 Volume Storage
하나의 EBS Volume은 동시에 하나의 EC2 Instance에만 Attach 가능
예외 적으로 io1, io2 Volume은 동시에 여러개의 EC2 Instance에 Attach 가능 (Multi Attach)
EBS Volume은 AZ에 종족되며, 동일한 AZ에 위치한 EC2 Instance에만 Attach 가능
4.1.1. EBS Snapshot
EBS의 특정 상태를 저장
EBS는 생성된 Snapshot 상태로 복구 가능
Detach하지 않더라도 Snapshot 동작이 가능하지만 권장되지 않음
EBS Snapshot을 기반으로 AMI를 생성 가능
EBS Snapshot 상태를 갖는 EC2 Instance 생성은 불가능하며, 반드시 EC2 Snapshot을 기반으로 AMI를 생성하고 생성한 AMI를 이용하여 EC2 Instance를 생성해야함
4.1.2. EBS Volume Type
gp2, gp3 : General Purpose SSD, Boot Volume으로 이용 가능
io1, io2 : Highest-performance SSD, Boot Volume으로 이용 가능, Multi Attach 가능
st : Low cost HDD
sc : Lowest cost HDD
4.1.3. EBS Encription
EBS 생성시 Encription 설정 가능
Encription 설정시 자동으로 암호화, 복호화 실행
Encription Overhead는 낮은편
4.2. AMI (Amazon Machine Image)
EC2 Instance의 Booting Image
EC2 Instance Snapshot
EC2 Instance를 원하는 상태로 설정한 이후에 AMI 생성 기능을 통해서 AMI 생성
AMI를 생성하면서 Snapshot 생성도 가능
하나의 AMI에 다수의 EBS Volume 포함 가능
4.3. EC2 Instance Store
물리 Disk 기반 Volume Storage
EBS보다 빠른 성능을 갖지만 Data는 언제든지 소실될 수 있음
Cache와 같이 빠르지만 임시로 Data를 저장하는 경우에 활용
다음의 경우에는 Data가 소실되지 않음
EC2 Instance Reboot
다음의 경우에는 Data가 소실됨
EC2 Instance 중지, 종료, Hibernate 될때
물리 Disk 장애시
4.4. EFS
NFS Server
NFSv4.1 Protocol 이용
File System 크기는 자동으로 증가하며, 사용 용량에 따라서 비용 발생
Linux에만 이용 가능
Muti AZ, Single AZ 설정 가능
4.4.1. EFS Storage Class
Storage Tiers
Standard : 표준
Infrequent Access : Data 저장에는 적은 비용을 지불하지만, 저장된 Data 이용시 비용 발생
5. ELB (Elastic Load Balancer)
Load 분산
장애(EC2 Instance, AZ, Network)시 고가용성 제거
User App의 단일 Endpoint 제공
SSL Terminiation 제공
Sticky Session 제공
Managed Load Balancer
AWS에서 동작 보장 (Upgrade, Maintenance, HA 보장)
약간의 설정 Options들 제공
5.1. CLB (Classic Load Balancer)
Deprecated
L4, L7 Load Balancer
TCP + TCP Health Check, HTTP, HTTPS + HTTP Health Check 지원
Cross-Zone Load Balancing
Default Disable, 설정으로 Enable 가능
추가 비용 발생 X
SSL 지원 X
5.2. ALB (Application Load Balancer)
L7 Load Balancer
HTTP/1.1, HTTP/2, WebSocket 지원
Less Latency : 400ms
Redirect 지원
Routing 정책
URL에 존재하는 Path 기반
URL에 존재하는 Hostname 기반
Quert String, Header 기반
ALB Target Group Type
EC2 Instance
ECS Task
Lambda Function
고정된 Hostname을 갖음
XXX.region.elb.amazonaws.com
Cross-Zone Load Balancing
항상 Enable 상태이며 Disable 불가능
추가 비용 발생 X
App Server가 받는 Packet의 Src IP는 ALB IP이기 때문에 App Server는 Packet의 Src IP를 통해서 Client IP를 알 수 없음
X-Forwarded-For Header를 통해서 App Server에게 Client IP를 App Server에게 전달
X-Forwarded-Port Header를 통해서 Client의 Port를 App Server에게 전달
X-Forwarded-Proto Header를 통해서 Client의 Protocol을 App Server에게 전달
5.3. NLB (Network Load Balancer)
L4 Load Balancer
TCP, UDP 지원
Less Latency : 100ms
NLB Target Groups
EC2 Instnace
Private IP Address
ALB
Cross-Zone Load Balancing
Default Disable, 설정으로 Enable 가능
추가 비용 발생
5.4. GWLB (Gateway Load Balancer)
L3 Load Balancer
Packet을 App Server에 전달하기 전에 가로체어 Firewall, 침입 탐지같은 동작을 수행하는 Third Party Network Virtual Appliance에게 전송하는 역할 수행
GWLB Target Group
EC2 Instance
Private IP Address
5.5. Sticky Session (Session Affinity)
동일한 Client는 언제나 LB 뒤에 존재하는 동일한 App Server에 접속하도록 하는 기법
CLB, ALB에서 이용 가능
Cookie 정보를 활용하여 CLB, ALB는 Packet을 어느 App에 전달할지 결정
Cookie 종류
Application-based Cookie
Custom Cookie
TODO
Application Cookie
AWSALBAPP 이름의 Cookie 이름 이용
Duration-based Cookie
TODO
5.6. SSL
SSL Termination 지원
SNI (Server Name Indication) 지원
ALB, NLB에서만 이용 가능하며 CLB에서는 제공하지 않음
인증서는 ACM (AWS Certificate Manager)에서 관리
5.7. Connection Draining
CLB에서는 Connection Draining, ALB/NLB에서는 Deregistration Delay라교 명칭
DRAINING 상태에 존재하는 Target (EC2 Instance)은 기존의 TCP Connection은 유지되지만, 신규 TCP Connection은 생성되지 않음
Draining Timeout을 0초로 설정할 경우 Connection Draining 기능 Disable
5.8. ASG (Auto Scaling Group)
Scale-out, Scale-in 가능
EC2 Instnace 개수를 Minimum, Disred, Maximum 3가지 관점에서 설정 가능
CloudWatch 기반의 Metric 정보를 바탕으로 Auto Scale-out, Scale-in 수행
EC2 Instnace가 장애시 자동 복구
5.8.1. ASG Launch Template
AGS를 쉽게 생성할 수 있는 Template 제공
Luanch Template에는 다음의 정보들이 포함
AMI + Instance Type
EC2 User Data, EBS Volume
Security Group
SSH Key Pair
IAM Roles for EC2 Instance
Network + Subnet Info
Load Balancer Info
5.8.2. Auto Scailing Policy
Target Tracking Scailing
AGS Group의 다음의 Metric들이 유지되도록 Scailing 수행
ASG Group에 평균 CPU 사용량
ASG Group의 평균 Inbound Traffic (All EC2 Network Interface)
ASG Group의 평균 Outbound Traffic (All EC2 Network Interface)
ASG Group의 평균 초당 Request
Simple Scailing
CloudWatch Alarm 기반 정책
Metric이 특정 값을 도달하면 EC2 Instance 추가, 삭제 수행
Ex) ASG Group 평균 CPU 사용률이 70% 이상이면 EC2 Instnace 5개 추가, 40% 미만이면 5개 감소
Step Scailing
CloudWatch Alarm 기반 정책
Metric이 구간에 따라서 EC2 Instance 추가, 삭제 수행
Ex) ASG Group 평균 CPU 사용률이 70% 이상일 경우 EC2 Instance 10개 추가, 60% 이상일 경우 5개 추가, 40% 미만이면 5개 감소, 30% 미만일 경우 10개 감소
Predictive Scailing
다음의 과거의 Metric을 기반으료 예측하여 Scaling 수행
ASG Group에 평균 CPU 사용량
ASG Group의 평균 Inbound Traffic
SG Group의 평균 Outbound Traffic
ASG Group의 평균 초당 Request
Custom Metric 기반으로 예측
Scheduled Action
시간대에 따른 Scaleing 수행
5.8.3. Scailing Cooldown
Scailing 수행후 다음 Scailing을 수행하기 전까지의 대기 시간
Cooldown 기간동안에는 EC2 Instance를 증가시키거나 감소시키지 않음
6. RDS
Managed RDB
자동 Provisiong, OS Patch 제공
Continuous Backup, Restore 제공
Monitoring Dashboards 제공
Read Replica 쉽게 구성 가능
Multi AZ 쉽게 구성 가능
Scailing 쉽게 가능
다음의 RDB 이용가능
Postgres
MySQL
MariaDB
Oracle
Microsoft SQL Server
Aurora
6.1. Storage Auto Scaling
RDS Storage 부족시 자동으로 Storage Size 증가 시킴
Maximum Stroage Threshold 설정을 통해서 최대 Storage Size 설정 필요
다음의 조건을 충족시 Storage Auto Scailing 수행
남은 Storage 용량이 10% 미만이고, 5분 이상 지속될 경우
마지막 Scale Up 수행후 6시간 이후
6.2. Read Replica
Read 전용 RDS Instance
Master RDS Instance와 비동기 Replication 수행
Master RDS Instance와 동일 AZ, Cross AZ, Cross Region으로 구성 가능
동일 AZ, Cross AZ 구성시 Network 비용 발생 X
Cross Region 구성시 Network 비용 발생
Read Replica RDS Instance는 Master RDS Instance로 승격 가능
장애 Recovery를 위한 RDS Instance로 이용 가능
비동기 Replication을 수행하기 때문에 Data Loss 발생 가능
6.3. Multi-AZ
장애 Recovery를 위한 Standby RDS Instance를 다른 AZ에 생성
Standby RDS Instance와 Master RDS Instance와 동기 Replication 수행
동기 Replication을 수행하기 때문에 Data Loss 발생 X
Master RDS Instance와 Standby RDS Instance는 동일한 DNS Record를 이용
Master RDS Instance 장애시 DNS Record IP가 Standby RDS Instance로 변경
Application의 DB 재설정 불필요
Multi-AZ 설정은 동적으로 가능
Mutli-AZ 설정시 Master RDS Instance Down 불필요
Standby RDS Instance는 Snapshot을 기반으로 생성한 다음 Master RDS Instance와의 Data 동기를 수행
6.4. Encryption
Master RDS Instance, Read Replica RDS Instance는 AWS KMS 기반 AES-256 암호화 가능
Master RDS Instance가 암호화하지 않으면 Read Replica RDS Instance도 암호화 되지 않음
Snapshot도 Master RDS Instance가 암호화를 수행해야 암호화 수행
암호화 되지 않은 Snapshot은 암호화 가능
암호화 되지 않은 RDS Instance를 암호화 하는 방법
Snapshot 생성
생성한 Snapshot을 암호화
암호화된 Snapshot을 바탕으로 RDS Instance 생성
App을 새로 생성된 RDS Instance를 이용하도록 설정 & 기존 RDS Instance 삭제
Client, RDS Instance 사이는 SSL을 이용한 암호화 수행
6.5. Network & Access Management
일반적으로 Private Subnet에 할당
Security Group을 활용하여 보안성 향상
기존의 IP/Password 기반 인증 가능
IAM 기반 인증 가능
RDS Service를 통해서 Token 획득이후 RDS Instance에 접근
6.6. Aurora
AWS Cloud Optimized RDS
MySQL, Progres와 호환
Storage의 크기는 10GB로 시작하여 최대 128TB 까지 자동으로 증가
하나의 Master Instance + 최대 15 Read Replica Instance를 갖을 수 있음
Master만 Read/Write 수행 가능
Read Replica는 부하에 따라서 Auto Scaling 수행
Read Replica는 Cross Region 지원
빠른 Failover (30초 미만)
일반 RDS보다 20%정도 더 높은 비용 청구
6.6.1. Storage HA
3개의 AZ에 6개의 복제본으로 구성
Write를 수행하기 위해서 4개의 복제본이 필요
Read를 수행하기 위해서 3개의 복제본이 필요
장애시 Self Healing을 통해서 데이터 복제
6.6.2. Endpoint
Writer Endpoint
Master Instance를 가리키는 DNS Record
Reader Endpoint
Read Replica Instance들을 가리키는 DNS Reocrd
Read Replica가 Auto Scaling 되면 자동으로 Read Endpoint에 추가/제거 수행
Custom Endpoint
사용자 설정을 통해 일부 Read Replica Instnace들만 가리키는 DNS Record
Data 분석을 위해서 성능이 좋은 Read Replica Instance만 이용할 경우 활용
6.6.3. Serverless
Client는 Proxy Server (Proxy Fleet)를 통해서 Aurora Instance에 접근
필요에 따라서 자동으로 Aurora Instance를 초기화 하고 Auto Scaling 수행
간혈적으로 DB를 이용하는 경우에 유리
초당 사용시간에 따라서 비용 청구
6.6.4. Multi-Master
다수의 Master Instance가 존재하며 모든 Master Node는 Read/Write 동작 수행
일부 Master Instance가 장애로 동작하지 않더라도, 동작중인 Master Instance를 통해서 지속적인 Write 동작 수행 가능
다수의 Master Instance 중에서 Write 동작을 수행할 Instance 선택은 Client에서 수행
Aurora에서는 Master Instance Load Balancing 기능 제공 X
6.6.5. Global Aurora
Disaster 복구를 위한 Cross Region Read Replica
Primary Region (Read/Write), Secondary Region (Read Only) 존재
Primary Region과 Secondary Region은 비동기로 복제되며 복제 시간은 최대 1초
최대 5개의 Secondary Region 설정 가능
Primary Region 장애시 Secondary Region이 Primary Region으로 승격 가능
6.6.6. Aurora Machine Learning
AWS ML Service와 연동하여 SQL Query를 통해서 ML 기반 예측 정보를 가져올 수 있음
Ex) 침입 탐지, 광고 Target, 상품 추천
7. ElasticCache
Managed Redis, Memcached
AWS IAM 기반 인증 기능 제공 X
7.1. Redis
Mutli-AZ를 활용한 Auto-Failover 지원
Read Replica를 활용한 Read Scaling 및 HA 제공
AOF (Append Only File)를 활용한 Data 지속성 제공
Backup & Restore 기능 제공
Single-Thread Architecture
다양한 Data Type 존재
ID/Password 기반의 인증 이용
7.2. Memcached
HA 제공 X
Data 지속성 제공 X
Backup & Restore 기능 제공 X
Multi-Thread Architecture
String 단일 Data Type 제공
SASL 기반 인증
7.3. ElasticCache Pattern
Lazy Loading
읽은 Data를 Cache에 저장
Cache에 저장된 Data는 유효하지 않을 확률이 존재
Write Through
Data를 저장할때 Cache에도 같이 저장
Cache에 저장된 Data는 유효
Session Store
Session 정보를 저장
TTL 기능을 활용
8. Route 53
Managed DNS
8.1. Hosted Zones
Public Hosted Zone : Public Network
Private Hosted Zone : VPC Private Network
8.2. CNAME vs Alias
CNAME
Non-Root Domain 지정 가능
Ex) ssup2.com (Root Domain) 불가능
Root Domain 지정 불가능
Ex) blog.ssup2.com (Non-root Domain) 가능
Alias
DNS Procotol에서 제공되지 않는 AWS 내부 Protocol
DNS Client시에는 Query Response시 A 또는 AAAA Record로 응답
Non-Root, Root Domain 둘다 지정 가능
일부 AWS Resource를 대상으로만 설정 가능
Supported Alias Target
Elastic Load Balancer
CloudFront Distributions
API Gateway
Elastic Beanstalk environments
S3 Websites
VPC Interface Endpoints
Global Accelerator
Route 53 record in the same hosted zone
Not supported Alias Target
EC2 DNS record
RDS DNS record
8.3. Routing Policy
Simple
DNS Record에 Mapping되어 있는 모든 IP Address 반환
Health Check 이용 불가
Weighted
DNS Record에 Mapping되어 있는 각 IP Address에 가중치를 부여하며, 가중치의 비율에 따라서 반환되는 IP Address의 비율을 결정
Health Check 이용 가능
Latency Based
Client의 위치에 따라서 Latency가 가장 적은 IP Address 반환
Health Check 이용 가능
Failover
Active-Passive 기반 정책
Health Check가 동작한다면 Primary로 지정된 IP Address 반환, Health Check가 실패한다면 Secondary로 지정된 IP Address 반환
Geolocation
Client의 위치에 따라서 설정된 IP Address 반환
Client가 설정된 위치가 이나라면 Default IP Address 반환
Health Check 이용 가능
Geoproximity
Client의 위치와 Bias 값에 의해서 특정 IP Address를 더 편향되게 많이 반환 할수 있도록 설정 가능
Bias 값이 큰 IP Address일수록 더 멀리 떨어져 있는 Client가 이용할 확률이 증가
Muti-Value Answer
Health Check를 통해서 응답하는 모든 IP Address 반환
최대 8개의 IP Address만 반환
8.4. Health Check
L4, L7 Health Check 지원
Health Check Target
Endpoint : App의 Endpoint Health Check 수행
Other Health Check (Calculated Health Check) : 다수의 다른 Endpoint의 Health Check 결과들을 논리 조합(AND, OR, NOT)하여 Health Check 결과를 판단
CloudWatch : Route53은 Public Network에 존재하기 때문에 Private VPC 내부에 존재하는 Endpoint를 Health Check 수행 불가능. 이 경우 Private VPC 내부의 Endpoint를 감시하는 Cloud Watch를 설정하고, Route53은 이 Cloud Watch를 대상으로 Health Check를 수행