AWS DVA-C02
…쉬운 앞부분 생략…
[요금정책 및 인스턴스 종류]
•
인스턴스의 종류에는 스팟 인스턴스, 예약 인스턴스, 전용 호스트가 있다.
EBS Volume
[EBS Volume] - USB Stick이라고 생각하면 편하다.
•
EBS 볼륨은 연결된 EC2가 사라져도 남아있고 다른 EC2에 연결될 수 있어 데이터의 영속성을 지킬 수 있다.
•
다만 동일한 region 내에서만 사용이 가능하다.D
•
CCP레벨의 EBS 볼륨은 하나의 인스턴스에만 연결 할 수 있다.
•
2개 이상의 EBS 볼륨이 하나의 인스턴스에는 연결 될 수 있다.
•
종료 시 삭제 옵션(Delete on Termination) 을 주의해야한다.
[EBS Snapshots]
•
특정 region(us-east-1a)에 있는 볼륨을 스냅샷을 통해 다른 region(us-east-1b)으로 복원(restore)할 수 있다.
•
EBS Snapshot Archive는 최대 75% 저렴하지만 복원하는데 24~72시간 정도가 걸린다.
•
EBS Snapshot을 휴지통에 보관할 수 있고 하루에서 1년까지 설정가능하다.
•
Fast Snapshot Restore를 통해 큰 용량의 볼륨을 빠르게 복원가능하지만 비용이 많이 발생한다.
AMI(Amazon Machine Image)
•
OS나 시스템이 포함된 이미지를 뜻한다. 대표적으로 aws에서 제공하는 Amazon Linux 2가 있다.
•
사용자 정의 AMI도 생성 가능하며, 공급업체에서 유료로 제공하는 경우도 있다.
EC2 Instance Store
•
EBS 볼륨에 비해 높은 I/O 처리 성능을 가지고 있다.
•
장애가 발생하거나 EC2를 종료할 때 데이터가 소실될 가능성이 있어 장기적인 보관에는 적합하지 않고 버퍼나 캐시 등을 보관하기 좋다.
•
데이터의 장기보관이 필요한 경우 복제 또는 백업이 필요하다.
EBS Volume Types
종류 | 용도 | IOPS(Input/Output Operations Per Second) | 용량 |
gp2 | 범용, General Purpose | 1gb 당 3iops, 최대 16000 iops | 굉장히 많이 |
gp3 | 범용, General Purpose | 16000 iops | 굉장히 많이 |
io1 | SSD, 높은 성능, 미션 크리티컬, 저지연, 고처리 작업 | 32000 iops ( Nitro EC2는 64000 iops ) | 4-16tb |
io2 | SSD, 높은 성능, 미션 크리티컬, 저지연, 고처리 작업 | 최대 256,000 | 4-64tb |
st1 | 부팅 볼륨 X, 처리량 최적화 HDD, 빅 데이터, 데이터웨어하우징, 로그 처리에 적합 | 500mb/s, 최대 500iops | 최대 16TB |
sc1 | COLD HDD, 가능한 가장 낮은 비용이 필요할 때, 로그 저장 용도 | 250mb/s, 최대 250iops | |
인스턴스 스토어 | 데이터를 잃을 수 있지만 복제, 백업 시나리오를 통해 복구 가능, 성능이 중요한 경우 최고의 성능을 제공 |
EFS (Elastic File System)
•
네트워크 파일 시스템으로 여러 인스턴스에 연결될 수 있다. 서로 다른 region에 위치해도 연결 할 수 있다는 점이 EFS의 가장 큰 장점이다.
•
EFS는 파일 시스템이 자동으로 확장되며 사용중인 볼륨에 대해서만 비용을 지불한다.
•
내부적으로 NFS 프로토콜(2049 port)을 사용하며, 권한 제어를 위해 보안그룹이 필요하다.
•
워크로드를 예측할 수 없을 때 사용, 개발만 하고 싶거나 비용이 걱정된다면 ONE ZONE으로 한다.
ELB(Elastic Load Balance) + ASG
•
로드밸런서의 유형
Classic Load Balancer - 2009 - HTTP, HTTPS, TCP, SSL
Application Load Balancer - 2016 - HTTP, HTTPS, WebSocket
Network Load Balancer - 2017 - TCP, TLS, UDP
Gateway Load Balancer - 2020
•
로드밸런서 별 보안그룹을 설정 할 수 있다. 기본적으로 HTTP, HTTPS에 대해서 any allow 하고있다.
[ALB] 400ms - HTTP, HTTPS 를 위함
•
포트매핑 기능이 있어 ECS 인스턴스의 동적 포트 리다이렉션이 가능하다.
•
대상 그룹을 EC2 뿐 아니라 ECS Task, 람다 함수가 될 수 있다.
•
리스너 규칙을 통해 서버로의 통신을 막거나, 대상 그룹의 부하 상태를 확인하며 자동으로 로드밸런싱을 한다.
[NLB] 100ms - HTTP, HTTPS, TCP, UDP, TLS 를 위함, 높은 성능, 고정 IP
•
초저지연 시간을 유지하면서 초당 수백만 건의 요청을 처리해야 할때
•
1개 혹은 서로 다른 2개, 3개의 IP로만 액세스 가능하다의 경우 사용
•
각 가용영역마다 고정 IP가 할당된다.
[GLB]
•
보안을 위한, 네트워크 트래픽 분석용도
•
GENEVE 프로토콜을 사용 6081, L4 계층
[Sticky Session]
•
하나의 클라이언트가 ALB를 통해 여러 인스턴스와 통신할 경우, 여러 요청을 하게되면 요청이 ALB에 의해 분산되어 들어가게됨
•
이러한 현상을 막기 위해 Sticky Session을 활성화 시킬 수 있다.
•
서버 부하에 불균형성을 가져올 수 있습니다.
•
Application-based Cookies는 Customer cookie와 Application cookie로 나뉨 AWSALB, AWSALBAPP, AWSALBBTG는 사용하면 안된다. (ELB에서 사용중)
•
Duration-based Cookies
[Cross-zone Load Balancing]
•
각 타입의 로드밸런서는 교차영역 밸런싱을 적용 할 수 있는데, 예를 들어 az 1번 영역에 2개의 ec2 인스턴스가, 2번 영역에는 8개가 있다면, 교차영역 밸런싱을 적용하게되면 각 ec2 인스턴스는 10%씩 균등하게 트래픽을 받게된다.
•
기본적으로 로드밸런서는 교차영역 밸런싱이 설정되어 있지 않는데. 따라서 로드밸런서는 같은 az에 속해있는 ec2에만 균등하게 트래픽을 보낼 수 있다. 이 교차영역 밸런싱을 하게 되는 경우 비용이 더 발생하므로 주의가 필요하다.
[SSL 인증서]
•
로드밸런서는 X.509 인증서를 사용한다.
•
AWS에서는 ACM(Amazon Credential Manager)를 통해 SSL인증서를 관리 할 수 있다.
[Server Name indication]
•
하나의 웹 서버에 여러 SSL 인증서를 로드해 웹 서버가 여러 웹사이트를 지원하게 만드는 방법
•
ALB와 NLB, Cloud Front에서 작동하며 CLB는 작동하지 않음
[Connection Draining]
•
CLB의 경우 Connection Draining, ALB, NLB의 경우는 Deregistration Delay(등록취소 지연) 라고 한다.
[Auto Scailing Group]
•
스케일링을 통해 인스턴스 추가/삭제가 발생할 때마다 기본 5분의 쿨다운 시간을 가지며, 이 시간동안에는 추가 인스턴스를 개시하거나 종료하지 않습니다.
•
오토스케일링 정책의 종류
1.
단순 스케일링 정책
2.
단계 스케일링 정책
3.
스케쥴 스케일링 정책
4.
대상 추적 정책
RDS - Storage Auto Scaling
•
RDS 오토 스케일링을 사용하면 용량이 부족할 때 자동으로 스케일 업 해주는 기능이 있다
•
할당된 저장공간의 10%미만이 남고, 5분 이상 지속 됐을 때 마지막 수정 이후 6시간이 지났을 경우 저장공간을 자동으로 수정할 수 있음
•
예측 할 수 없는 업무량을 가진 애플리케이션에 유용하다.
[읽기 전용 복제본과 다중 AZ]
•
읽기 전용 복제본 RDS는 SELECT구문만 허용
•
데이터가 이동할 때 비용이 발생, 동일한 region에 있는 경우에는 비용이 발생하지 않지만, 서로 다른 region에 위치한 경우 예를 들어 메인 RDS가 us-east-1a에 위치해있고, 복제본 RDS가 eu-west-1b에 위치했을 때는 데이터가 여러 리전을 넘나 들어야하기 때문에 비용이 발생
•
다중 AZ는 보통 재해 복구를 위해 사용, 마스터 RDS는 대기중인 스탠바이 인스턴스 RDS에 모든 데이터를 이전할 때 하나의 DNS Name을 가지고 있고, 이는 높은 가용성을 갖고 있어 다중 AZ라고 한다.
•
스케일링에 사용되는 개념이 아니며 오로지 마스터 데이터베이스의 장애에 대한 대비책으로서 사용된다.
•
동기식 복제본인 읽기전용 복제본 또한 다중 AZ로 설정가능
•
단일 AZ에서 다중 AZ로 전환할 때 데이터베이스의 다운타임은 없다.
•
다중 AZ 설정 시 동작방식은 아래와 같이 진행됨
1.
기본 데이터베이스의 RDS가 자동으로 스냅샷을 생성
2.
이 스냅샷은 새로운 스탠바이 데이터베이스에 복원됨
3.
복원이 완료되면 두 데이터베이스 간 동기화가 설정됨
Route 53
[레코드타입]
•
A - IPv4
•
AAAA - IPv6
•
CNAME - 호스트 이름을 다른 호스트이름과 매핑 ( A나 AAAA 레코드가 될 수 있음 )
VPC ( Virtual Private Cloud ) - 사설 네트워크
•
보통 region이 2개 일 때 2개의 다른 VPC를 가지게 된다.
•
논리적인 구조의 VPC 내엔 서브넷이 있고 네트워크를 분할하게 해줌.
•
서브넷은 가용 영역 수준(az) 에서 정의됩니다.
•
인터넷 게이트웨이는 공용 서브넷에 있는 인스턴스를 인터넷에 연결하게 해줌
•
NAT 게이트웨이와 인터페이스는 사설 네트워크와 인스턴스를 연결해준다.
[NACL(Network ACL)]
•
서브넷 레벨에서 트래픽을 제어(Allow/Deny) 규칙을 설정 할 수 있고
•
IP로만 설정 할 수 있다.
[VPC Flow Logs] * 중요 *
이렇게 흘러가는 트래픽을 확인 할 수 있는게 VPC Flow Logs,
허용 트래픽과 거부 트래픽에 대한 모든 정보가 있다.
ELB, ElastiCache, RDS 등 모두 VPC 흐름에 나타난다.
흐름 로그 데이터는 Amazon S3와 Cloud Watch Logs, Kinesis Data Firehose 등 많은 곳에 보낼 수 있다.
[VPC Peering]
•
여러 VPC를 하나의 네트워크에 속해 있는 것처럼 연결하고 싶을 때 사용
•
VPC를 연결하기 위해서는 정의된 IP범위가 겹치지 않아야한다 (충돌 우려)
•
VPC는 각각 연결되어야 한다. 예를 들어 VPC A와 VPC B가 연결되었고, VPC A와 VPC C를 연결했다고 했을 때
VPC A와 VPC C가 자동으로 연결되지 않는다.
[VPC Endpoints]
•
기본적으로 AWS 서비스들은 public network를 사용하고 있다 ( 즉 공개되고 있다 )
•
private network를 사용하려면 VPC 엔드포인트 사용해야한다.
•
VPC 엔드포인트를 사용하면, 공개되지 않은 VPC를 VPC 엔드포인트 게이트웨이(또는 VPC 엔드포인트 인터페이스 = ENI) 를 통해 EC2 인스턴스와 인터넷을 통하지 않고 통신 할 수 있게 된다.
•
온프레미스 환경의 사무실에서 VPC와 통신을 할 땐 아래와 같은 방법을 쓴다.
◦
Site to Site VPN ( 공개된 인터넷을 사용하여 암호화 통신 )
◦
Direct Connect (DX) ( 공개되지 않은 연결, 설정에 오랜 시간이 걸리기도 한다. )
3계층 아키텍처
LAMP Stack on EC2
Linux, Apache, MySQL, PHP를 얘기함
CloudFront
CloudFront
•
CloudFront란 콘텐츠 전송 네트워크 (CDN)
•
웹사이트의 컨텐츠를 캐시처리하여 읽기 성능을 높여 지연시간이 줄고 사용자 경험을 높임
•
전세계에 216개의 지점이 있고 이를 엣지 로케이션이라 한다.
•
컨텐츠를 전세계로 분할하여 DDOS를 방지하고 있다.
CloudFront - origin
•
S3 버킷은 CloudFront를 사용해 엣지에 파일을 분산/캐싱하는 역할을 한다.
•
S3 버킷에 대해서 CloudFront만 액세스 할 수 있도록 Origin Access Control(OAC)가 OAI를 대체하고 있다.
•
CloudFront를 통해 데이터를 S3 버키승로 전송하여 데이터를 업로드하는 것을 인그레스라고 한다.
•
사용자 지정 오리진을 아래와 같이 설정 할 수 있다.
◦
ALB
◦
EC2
◦
S3 Website ( 버킷을 Static S3 Website로 설정 )
클라우드 프론트 시나리오
1.
최초로 사용자가 접속을 시도합니다.
2.
CloudFront는 사용자가 요청한 컨텐츠가 캐시에 없다면 Orgin에 컨텐츠를 요청합니다.
3.
해당 컨텐츠를 사용자가 다시 요청하게 된다면 이미 캐시되어있으므로 Origin에 요청할필요가 없게됩니다.
CloudFront와 비슷한 서비스로는 S3 Cross Region Replication이 있다.
두 서비스의 다른 점은
CloudFront는 CDN으로 전 세계 모든 곳에 콘텐츠를 캐시 처리하는 반면
S3 리전간 복제는 특정 리전에 전체 버킷을 복제합니다.
###############################################################
CloudFront Caching
###############################################################
•
캐시는 각 엣지 로케이션의 수만큼 생성된다.
•
기본적으로 캐시 키는 hostname + url 로 이뤄진다. (파라미터를 제외한)
## CloudFront 캐시 정책은?
•
HTTP 헤더 - None - whiltelist
•
쿠키 None - whiltelist - include all-except - all
•
쿼리 스트링 None - whiltelist - include all-except - all
•
TTL 설정을 통해 캐시에 보관할 기간을 0초에서 1년까지 저장
## 캐시 정책 설정