【한글자막】 AWS Certified Solutions Architect Professional | Udemy

2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 3: AWS 시작하기

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 4: IAM 및 AWS CLI

2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초

2023.01.10 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 6: EC2 - 솔루션스 아키텍트 어소시에이트 레벨

2023.01.11 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 7: EC2 인스턴스 스토리지

2023.01.13 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 8: 고가용성 및 스케일링성: ELB 및 ASG

2023.01.13 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 9: AWS 기초 : RDS + Aurora + ElastiCache

 


99. DNS 란 무엇일까요? 

What is DNS? 

호스트 네임을 IP로 변환 한다. 

www.google.com  -> 172.217.18.36 

인터넷의 중추 

계층적 이름 구조이다. (DNS uses hieracrchical naming structure) 

.com

 

example.com

 

www.example.com  

DNS Terminologies 

Domain Registrar 

도메인을 등록하는 곳 

DNS 레코드

A, AAAA, CNAME, NS 등 있다. 

Zone File

모든 DNS Record를 포함한다 .

Name 서버

DNS 쿼리를 실제로 해결하는 서버

Top Level Domain (TLD) : com, us, in ,gov, org ....

Second Level Domain( SLD) : amazon.com, google.com

FQDN (Fully Qualified Domain Name) 

 

How DNS Works

webserver www.example.com에  에 접속한다고 가정하자.

1. 클라이언트에서 해당 주소를 DNS resolver에 물어본다. ( 보통 통신사에서 운영 ).

2. DNS resolver 가 dns root server에 물어본다.

3. 그리고 TLD 서버에 물어본다. 

4. Route53 같은 SLD 에 물어본다. 

5. ip 주소를 받으면 클라이언트에서 웹서버로 바로 접속한다 .

 


100. Amazon Route 53 개요

Amazon Route 53 

고가용성, 확장성을 갖춘 , 완전히 관리가되며 권한이 있는 DNS 이다 .

권한이 있다는건? -> DNS 레코드를 업데이트 할 수 있다. 

DNS에 대한 완전히 제어가 가능하다. 

Route53 역시 도메인 이름 레지스트로 도메인 이름을 myrealcode.com 으로 등록한다. 

 

Route53의 리소스 관련 상태를 확인할 수 있다. 

100%SLA 가용성을 제공하는 유일한 aws 서비스이다 .

53은 전통적인 DNS 포트이다 .

 

Route 53 - Records 

레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의한다. 

각 레코드는 도메인이나 example.com 과 같은 서브도메인 이름과 같은 정보를 포함한다. 

 

예를 들어 A 나 AAAA가 있다 

레코드의 값은 123.456.789.123 인데 라우팅 정책은 Route53이 쿼리에 응답하는 방식이다.

TTL은 DNS 리졸버에서 레코드가 캐싱되는 시간이다. 

반드시 알아야하는것 

A /AAAA/ CNAME/ NS

 

고급

CAA/DS / MX/ NAPTR/ PTR/ SOA/ TXT/ SPF / SRV

 

Route 53 - Record Types 

A - map to IPv4 

AAAA - map to IPv6 

CNAME - maps a hostname to another hostname

A, AAAA 가 되어야한다.

Route 53 에서 DNS 이름 공간 또는 Zone Apex의 상위 노드에 대한 CNAMES 를 생성할 수 없다.

example.com 에 CNAME 을 만들 수 없지만 www.example.com  에 대한 CNAME은 만들 수 있따.

 

NS - Name Servers for the Hosted Zone

호스팅 존의 네임서버이다. 

서버의 DNS 이름 또느 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답 할 수 있다.

또한 트래픽이 도메인으로 라우팅 되는 방식을 제어한다. 

 

Route 53 - Hosted Zones 

호스팅 존은 레코드의 컨테이너이다.  

도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다. 

 

호스팅 존의 종류

퍼블릭 호스팅 존 - 인터넷에서 어떻게 라우트 되어야하는지에 대한 정보를 담고 있다. application1.mypublicdomain.com

프라이빗 호스팅 존- VPC 에서 사용가능 application1.company.internal

 

AWS 에서 만드는 어떤 호스팅 존이든 월에 50 센트를 지불해야한다. 

 

Route 53 - Public vs Private Hosted Zones

 

 

 

프라이빗 호스팅 존은 프라이빗 IP 를 알려준다.  VPC 에서만 작동한다 .

 

 


101. Route 53- 도메인 등록 실습

새 도메인 등록 - Amazon Route 53

 

새 도메인 등록 - Amazon Route 53

등록자 연락처는 이메일의 지시 사항에 따라 이메일을 받았다는 사실을 확인해야 합니다. 그렇지 않으면 ICANN에서 요구할 경우 도메인 이름이 일시 중지해야 합니다. 도메인이 일시 중지되면 인

docs.aws.amazon.com


102. Route 53 - 첫번째 기록 생성

도메인에 레코드를 추가해본다.

 

.xxx.test.com 

이런식으로 하고 ip 주소는 123.123.123.123 으로 연결한다. 레코드 타입은 A 

xxx.test.com 을 입력하면 페이지가 안나온다 

123.123.123.123. 은 없기 때문?   

 

하지만 cloudshell에서 nslookup으로 xxx.test.com 

을 검색하면 ip주소가 123.123.123.123 으로 연결되는 것을 확인할 수 있다.

또는 dig 명령어로 많은 정보를 확인할 수 있다. 


103. Route 53 -EC2 설정 

EC2 생성 

각 다른 리전에 인스턴스 3개를 만들고 애플리케이션 로드 밸런서를 하나 만든다 .

ssh, http 트패릭 허용 (로드밸런서는 다른 리전의 인스턴스도 연결해주는 구나)

 

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
echo "<h1>Hello World from $(hostname -f) in AZ $EC2_AVAIL_ZONE </h1>" > /var/www/html/index.html

사용자 데이터 스크립트 

$EC2_AVAIL_ZONE 

명령을 통해 가용영역 정보도 띄운다 .

 

로드 밸런서 생성

ALB 를 생성한다. 

 

대상 그룹을 생성한다. 

 

ALB 정보에서 DNS 이름을 복사해서 프로비저닝 됐는지 확인 

ALB에서 인스턴스 하나늘 가리키게 된다.


104. Route 53 - TTL

클라이언트가 DNS route 53과 웹 서버에 접속한다고 가능하자. 

myapp.example.com 에서 DNS 요청을 보내면 DNS 로부터 회신을 받는데

A 레코드 IP 주소 그리고 TTL 을 받는다. 

 

TTL이 300초라면 클라이언트가 요청 결과를 300초 동안 캐싱하게 한다. 

300초 안에 똑같은 검색을 하면 route 53에 쿼리할 필요없이 바로 웹서버에 접속한다. 

 

TTL 을 설정함으로써 DNS 서버의 부담을 줄일 수 있다. 

 

High TTL  - ex 24 hour

길게 잡으면 트래픽량을 줄일 수 있다.

너무 길면 오래된 데이터를 갖게된다. 

 

Low TTL - ex 60sec

트래픽이 증가한다. -> 고비용

레코드를 최신으로 유지할 수 있다.

레코드를 변경하기 쉽다. 

 

TTL을 콘솔에서 다루는 법

레코드를 생성한다. 

TTL을 설정  120 초

EC2 - 1 에 연결하고

등록한 도메인으로 접속한다. 

 

그리고 cloudshell에서 ns lookup 과 dig 명령어로 TTL 이 뜨는 것을 볼 수 있다.

클라이언트에서 접속했기 때문에 115초~ 이런식으로 TTL 이 뜬다 

 

그 사이에 레코드에서 다른 EC2 -2 에 연결한다.

120초 내라면 변경된 EC2 -2 에 연결되는 것이 아니라 캐싱 시간 때문에 EC2 -1 으로 연결된다 .

 


105. Route 53 CNAME vs Alias

CNAME vs Alias 

AWS Resources ( Load Balancer , CloudFront) 등 호스트 이름이 노출된다.

보유한 도메인에 호스트 이름을 매핑하려고 할 것이다. 

 

myapp.mydomain.com 에 로드 밸런서를 매핑하는 경우 두가지 옵션이 있다.

 

CNAME 

호스트 네임을 다른 호스트 네임으로 전환한다.

app.mydomain.com -> blabla.anything.com 

루트 도메인 이름이 아닌 경우에만 가능하다.

Only for Non Root Domain

그냥 mydomain.com을 anything.com 으로 연결 시키는 것은 불가능하다. 

 

Alias

호스트 네임을 특정 AWS 리소스로 향하도록 할  수 있다.

app.mydomain.com 이 blabla.amazonaws.com 을 향할 수 있게한다.

별칭 레코드는 루트 및 비루트 도메인에서 모두 작동한다. 

works for Root Domain and Non Root Domain 

비용은 무료이다. 

자체적으로 상태 확인이 가능하다. native health check

 

Route 53 - Alias Records 

호스트 네임을 aws 리소스만 향하게 한다. 

DNS의 확장 기능으로 시중의 모든 DNS 에서 사용가능하다. 

리소스 IP의 변화를 자동적으로 인식한다. 

ALB에서 IP 가 바뀌면 별칭 레코드는 이걸 바롤 인식한다. 

 CNAME 과 달리 별칭 레코드는 ZONE APEX 라는 DNS 네임스페이스의 상위노드로 사용될 수 있다. 

example.com 에도 별칭레코드를 사용할 수 있다.

 

AWS리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA이다. 

리소스는 IPv4 또느 IPv6이다.

별칭 레코드는 TTL 설정 불가 

 

Route 53 - Alias Records Targets

 

ELB, CloudFront, API Gateway, Elastic Beanstalk, S3 Websites, VPC Interface Endpoints

Global Accelerator , Route 53 Record 

등 별칭 레코드의 대상으로 지정할 수 있다. 

단 EC2의 DNS 이름에 대해서는 별칭 레코드를 설정할 수 없다. 

 


106. 라우팅 정책 - 단순 

Route 53 - Routing Policies 

라우팅 정책은 route 53이 dns 쿼리에 응답하는 것을 돕는다. 

라우팅

  • 여기서 라우팅은 로드밸런서가 트래픽을 백엔드 EC2 인스턴스로 라우팅하는 것과 다르다.
  • DNS does not route any traffic, it noly responds to the DNS queries
  • DNS는 트래픽을 라우팅하지 않는다. 트래픽은 dns를 통과하지 않는다. DNS는 쿼리에만 응답하게 된다. 

DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드포인트로 변환하는 것을 돕느다. 

Route 53 라우팅 정책 

단순, 가중치 기반, 장애 조치 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접

Routing Policies - Simple 

기존에 우리가 사용해 왔던 방식이다.

일반적으로 트래픽을 단일 리소스로 보내는 방식이다.

클라이언트가  foo.example.com 으로 가고자 한다면 Route 53 이 iP 주소를 알려준다. a 레코드 주소 

 

동일한 레코드에 여러 개의 값을 지정하는 것도 가능하다. 

이렇게 DNS 에 의해 다중 값을 받는 경우에는 클라이언트 쪽에서 그중 하나를 고른다 .

alias 기능이 켜져있으면 오직 하나의 aws 리소스에만 접근할 수 있다. 

헬스 체크 기능을 사용할 수 없다.


107. 라우팅 정책 - 가중치 

Routing Policies - Weighted

 

가중치 기반 라우팅 정책

정책을 사용하면, 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능하다.

Control the % of the requests that go to each specific resource

Route 53 이 있고 EC2 인스턴스가 세 개 있는데 70, 20 , 10 의 각각 다른 가중치를 할당 받는다. 

 

Amazon Route 53 에서 오는 DNS 응답의 70% 가 첫 번째 EC2 로 리다이렉팅 된다는 것을 의미한다.

20 퍼센트는 두 번쨰로 , 10퍼센트는 세 번째 인스턴스로 간다. 

 

한 DNS 이름 하에 있는 다른 레코들과 비교했을 떄 해당 레코드로 트래픽을 얼마나 보낼지를 나타내는 값이다.

 

상태확인과 관련 될 수 있다. ( can be associated with health checks ) 

 

사용처

서로 다른 지역들에 걸쳐 로드 밸런싱을 할때 

적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우

가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다.

모든 가중치를 0으로 하면 모든 레코드에 동등하게 보내진다.


 

새로운 레코드를 만든다 .

가중치 정책

레코드 id로 식별하기


108. 라우팅 정책 - 대기 시간

Routing Policies - Latency- based 

지연 시간 기반 라우팅 정책 

지연 시간이 가장 짧은 ,즉 가장 가까운 리소스로 리다이렉팅을 하는 정책이다.

Redirect to the resource that has the least latency close to us

 

지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책이다. 

 

지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다. 

Latency is based on traffic between users and AWS Regions

유저가 독일에 있고 미국에 있는 리소스의 지연시간이 가장 짧다면, 해당 유저는 미국 리전으로 리다이렉팅 될 것이다. 

 

상태 확인과 연결이 가능하다.


 

정책을 레이턴시Latency로 지정한다.

인스턴스의 ip를 입력하고 리전 위치도 입력해야한다. 

가장 가까운 인스턴스로만 연결된다. 

 


109.  Route 53 - 상태 확인 

Route 53 - Health Checks

공용 리소스에 대한 상태를 확

인하는 방법이다.

지연 시간 기반 레코드로 연결되면 가장 가까운 리전의 ELB로만 연결될 것이다 .

 

만약 ELB가 마비된다면 다른 리전은 ELB로 연결해야 할 것이다. 

 

상태 체크를 통해 DNS 장애 조치를 자동화할 수 있다. 

1. 엔드포인트에 대한 상태체크 

( 애플리케이션, 서버, 다른 aws 리소스)

2. 다른 상태 확인을 모니터링하는 상태 확인도 있다. 

(계산된 상태 체크 ) Calculated Health Checks

3.CloudWatch 를 통해 상태 확인 

CloudWatch의 지표에서 확인 가능하다 .

 

Health Checks are intergrated with CW metrics

 

Health Checks - Monitor an Endpoint

15개의 글로벌 상태 확인이 엔드포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정한다. 

  •  간격을 설정할 수 있다. 30~10초 (물론 10초 , 주기적으로 하면 비용이 더 든다.)
  • 프로토콜 지원 :HTTP, HTTPS, TCP 를 지원한다. 
  • 18 % 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route53도 이를 정상이라고 간주한다. 
  • 상태 확인에서  사용될 위치도 선택할 수 있다.

2xx, 3xxx 코드를 받아야만 통과가 된다. 

 

텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 바이트를 확인한다. 

 

상태 확인의 작동이 가능하려면 상태 확인이 여러분의 애플리케이션 밸런서나 엔드 포인트에 접근이 가능해야한다.

따라서 Route53 의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야한다. 

 

Calculated Health Checks

계산된 상태 확인으로 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능이다. 

Route 53 을 보면 EC2 인스턴스가 세 개 있고 상태 확인을 세 개 생성할 수 있다.

하위 상태를 바탕으로 상위 상태 확인을 정의할 수 있다.

 

상태 확인을 합치기 위한 조건은 OR, AND or NOT 이다 

하위 상태 확인을 256개까지 모니터링할 수 있다. 

 

상위 상태 확인이 통과하기 위해 몇 개의 상태를 통과해야 하는 지도 지정할 수 있다.

 

Usage: 

상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 관리 유지하도록 하는 경우 

perform maintenance to your website without causing all health checks to fail

 

Health Checks - Private Hosted Zones 

 

route 53의 상태 확인은 공용 웹에 있다. (VPC 외부에 있음) 

개인 엔드 포인트에 접근하는 것은 불가능하다.

 

CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 문제를 해결할 수 있다. 

개인 서브넷 안에 있는 EC2 인스턴스를 모니터링한다. 

메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 된다. 

alarm 상태가 되면 상태 확인은 자동으로 비정상이 된다. 

경보 상태가 되면 Health checks 가 통과하지 못하도록 하게 한다. 


110. Route 53 - 상태 확인 실습 

상태 확인 인스턴스 생성 

엔드포인트 지정 - ec2 연결 

상태 확인 관련 옵션 지정

( 상태 확인 3개 만든다. ) 

 

ec2 로 가서 보안 규칙을 일부러 변경한다.

 

상태확인에서 unhealthy로 변경된다. 

 

Amazon Route 53 상태 확인 생성 및 DNS 장애 조치 구성 - Amazon Route 53

 


111. 라우팅 정책 - 장애 조치 

Routing Policies - Failover ( Active-Passive)

route 53에서 주 인스턴스에 상태체크를 보냈는데 실패를 응답 받으면 보조 인스턴스로 연결함으로써 장애 조치를 한다. 

보조 인스턴스에도 상태체크를 할 수 있지만 안할 수도 있다. 

클라이언트가 접속하면 route 53는 보조 인스턴스로 응답을 한다.


장애 조치 정책을 설정하면 프라이머리, 세컨더리 레코드를 지정해야한다. 

 

마찬가지로 보안그룹의 포트를 제거하여 접속 오류를 만든다. 

장애가 생겼기 때문에 장애 조치로 연결한 세컨더리 레코드로 연결된다. 


112. 라우팅 정책 - 지리적 위치

Routing Policies - Geolocation

지연 시간 기반 (latency-based) 정책과 다르다.

사용자의 실제 위치를 기반으로 한다. 

사용자가 특정 대륙이나 국가 혹은 더 정확하게 미국의 경우에는 어떤 주에 있는지 지정하는 것이며 가장 정확한 위치가 선택되어 그 IP로 라우팅 되는 것이다. 

 

일치하는 위치가 없는 경우에는 기본 레코드를 생성해야한다. 

Should create a "Default" record ( in case there's no match on locaton) 

 

Usage

콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화가 있다.

 

독일 유저가 독일어 버전의 앱을 포함한 IP로 접속되로고 독일의 지리 레코드를 정의하고

프랑스의 경우 프랑스어 버전의 앱을 가진 IP로 가야한다.

그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야한다. 


라우팅 정책 geolocation 으로 설정 

 

타임아웃 오류가 뜬다면 보안그룹을 확인하자 .

vpn을 통해 검증하기 


113. 라우팅 정책 - 지리적 근접성

Geoproximity Routing Policy

지리적 위치랑 차이점 주의하자.

 

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 한다. 

편향값을 사용해 특정 위치를 기반으로 리소를 더 많은 트래픽을 이동하는 것이다. 

 

지리적 위치를 변경하려면 편향값을 지정해야한다.

특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 된다. 

To change the size of the geographic region, specify bias values:

  • to expand (1 to 99) - more traffic to the resouce
  • to shrink( -1 to -99) - less traffic to the resource

 

Resouces can be

  • AWS resources (특정 리전)
  • Non-AWS resources ( 특정 위도 , 경도를 지정하여 aws 가 위치를 파악하도록 해야한다)

편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용한다. 

you must use route 53 traffic flow (advanced) to use this feature

편향성이 0이면 유저는 가까운 리전으로 연결된다. 

편향성을 지정하면 유저의 트래픽을 특정 리전으로 옮길 수 있다.

 

지리 근접 라우팅은 편향을 증가시켜 

한 리전에서 다른 리전으로 트래픽을 보낼 때 유용한다.


114. 라우팅 정책 - 다중 값

Routing Policies - Multi-Value

다양한 리소스로 라우팅할때 사용된다.

 

Route 53 다중 값과 리소스를 반환한다. 

 

상태 체크를 하는데 통과된 리소스만 반환한다. 

return only values for healthy resources

 

각가의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다. 

up to 8 healyh recoreds are returned for each Multi-Value query

 

ELB와 유사해 보이지만 ELB를 대체할 수는 없다. 

Multi-Value is not a substitute for having an ELB

 

단순 라우팅 정책은 상태 체크를 하지 않기 때문에 응답 받은 리소스 중에 비정상이 포함될 가능성이 있다.

상태 체크를 한다는 점

3개의 응답을 얻는다. 


115. 타사 도메인 및 Route 53

Domain Registar vs. DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있다. 

 

매년 비용을 지불해야한다.

Route 53에서 도메인을 구매할 때는 Amazon 레지스트라를 이용했다. 

GoDaddy에서 도메인을 구매하고 route53으로 관리 할 수도 있다. 

도메인 구매와 dns 서비스를 다른 곳에서 할 수 있다.

Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 오른쪽 부분에서 이름 서버를 찾는다.

해당 이름 서버는 godaddy 에서 수정해야한다.

 

godaddy에서 사용하는 네임서버에 관한 쿼리에 응답하면 네임서버가 route 53의 네임서버를 가리키게 된다.

그러면 route 53의 콘솔에서 직접 전체 dns 레코드를 관리할 수 있다.

 

3rd Party Registrar with Amazon Route 53 

 1. 3파티에서 도메인을 구매하고 네임서버를 등록한다. 

2. route 53에 호스팅 존을 생성한다. 

3. 3파티 웹사이트에서 네임서버 레코드를 수정한다. route 53의 네임 서버를 사용하기위해! 

 

도메인 레지스트라와 dns service는 다르다 .

 

그러나 대부분의 도메인 레지스트라는 dns 기능을 지원한다.


116. Route 53 - 섹션 정리 

 

실습에 사용한 인스턴스 제거 

도메인 제거


Route 53 퀴즈 

1. 여러분은 Amazon Route 53 Registrar를 위해 mycoolcompany.com를 구매했으며, 이 도메인이 Elastic Load Balancer인 my-elb-1234567890.us-west-2.elb.amazonaws.com를 가리키게끔 하려 합니다. 이런 경우, 다음 중 어떤 Route 53 레코드 유형을 사용해야 할까요?

 

2.새로운 Elastic Beanstalk 환경을 배포한 상태에서, 5%의 프로덕션 트래픽을 이 새로운 환경으로 다이렉트하려 합니다. 이를 통해 CloudWatch 지표를 모니터링하여, 새로운 환경에 있는 버그를 제거할 수 있게 됩니다. 이런 작업을 위해서는 다음 중 어떤 Route 53 레코드 유형을 사용해야 할까요?

가중치 기반 라우팅 정책을 사용하면 가중치(예: 백분율)를 기반으로 트래픽의 일부를 리다이렉트할 수 있습니다. 트래픽의 일부를 애플리케이션의 새로운 버전으로 보내는 방식은 흔히 사용되는 방식입니다.

 

트래픽을 분산 시키는 것을 목적이라면 가중치 기반, 지리적 근접성을 라우팅 정책으로 한다. 

 

3. Route 53 레코드의 myapp.mydomain.com 값이 새로운 Elastic Load Balancer를 가리키도록 업데이트를 했는데도 불구하고, 사용자들은 여전히 기존의 ELB로 리다이렉트 되고 있는 상태입니다. 이런 경우, 가능성이 있는 원인은 무엇일까요?

각 DNS 레코드는 클라이언트들이 이러한 값들을 캐시할 기간을 지정하고 DNS 요청으로 DNS 리졸버에 과부하를 일으키지 않도록 지시하는 TTL(타임 투 리브)을 갖습니다. TTL 값은 값을 캐시해야 하는 기간과 DNS 리졸버로 들어가야 하는 요청의 수 사이의 균형을 유지할 수 있도록 설정되어야 합니다.

 

4. 두 AWS 리전, us-west-1  eu-west-2에 호스팅 된 애플리케이션이 있습니다. 애플리케이션 서버의 사용자에 대한 응답 시간을 최소화하여, 사용자들에게 최상의 사용자 경험을 제공하려 합니다. 이 경우, 다음 중 어떤 Route 53 라우팅 정책을 사용해야 할까요?

지연 시간 라우팅 정책은 사용자와 AWS 리전 사이에서 발생하는 지연 시간을 평가하여 지연 시간(예: 응답 시간)을 최소화할 수 있는 DNS 응답을 수신할 수 있게 해줍니다.

 

5. 프랑스를 제외한 국가에 있는 사람들이 여러분의 웹사이트로 액세스해서는 안 된다는 법적 요구 사항이 있습니다. 이 경우, 다음 중 어떤 Route 53 라우팅 정책을 사용해야 할까요?

 

6. GoDaddy를 위해 도메인을 구매했으며, Route 53을 DNS 서비스 제공자로 사용하려 합니다. 이를 위해서는 어떤 작업을 수행해야 할까요?

공용 호스팅 영역은 인터넷을 통해 웹사이트로 요청을 보내는 사람들이 사용할 것을 전재하고 있습니다. 마지막으로, NS 레코드는 타사 Registrar에 업데이트되어야 합니다.

 

7. 다음 중 유효한 Route 53 상태 확인이 아닌 것을 고르세요.

 

【한글자막】 AWS Certified Solutions Architect Professional | Udemy

2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 3: AWS 시작하기

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 4: IAM 및 AWS CLI

2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초

2023.01.10 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 6: EC2 - 솔루션스 아키텍트 어소시에이트 레벨

2023.01.11 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 7: EC2 인스턴스 스토리지

2023.01.13 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 8: 고가용성 및 스케일링성: ELB 및 ASG

 


85. Amazon RDS 개요

Amazon RDS Overview 

RDS - Relational Database Service 관계형 데이터베이스 서비스이다. 

SQL 을 사용하는 DB를 위한 완전관리형 DB  서비스이다. 

여러 DB 엔진을 지원한다. 

Postgres, MySql, MariaDB, Oracle, Microsofts SQL Server, Aurora


Advantage over using RDS versus deploying DB on EC2  - EC2에 DB를 설치하여 사용하는 것과 비교하여...

RDS 는 완전 관리형 서비스

데이터베이스 프로비저닝과 기본 운영체제 패치가 완전 자동화되어 있다..

지속적인인 백업 생성 -> 타임스탬프를 이용하여 특정 시점으로 복원 가능

모니터링 - 데이터베이스의 성능을 모니터링할 수 있다.

읽기 전용 복제본 ( Read replicas)  생성- 읽기 성능을 높일 수 있다.

다중 AZ for DR (Disaster Recovery) 

유지 관리 기간에 업그레이드 가능

인스턴스 확장, 축소 가능 ( vertical or horizontal)

파일 스토리지는 EBS에 구성된다. ( gp2, io1 ) 

 

단점으로 RDS 인스턴스에 SSH 액세스 불가 

RDS - Storage Auto Scaling 

RDS DB 인스턴스를 자동으로 확장해준다. 

 

RDS가 db 스토리지 용량이 부족하다고 감지하면 용량을 확장한다.

수동조작을 피하게 해준다 ?

따라서 최대 스토리지 임계값을 정해줘야한다. 

스토리지 부족 상태가 5분 이상 지속되거나 지난 수정으로부터 6시간이 지났을 경우 오토스케일링이 활성화 되어 있다면 스토리지가 자동 확장 된다. 

 

워크로드를 예측할 수 없는 애플리케이션에서 굉장히 유용하고 모든 RDS 데이터베이스 엔진에서 지원되는 기능이다. 

 

MariaDB, MySQL , PostgreSQL, SQL Server, Oracle 다 지원된다. 

 


86. RDS 읽기 전용 복제본과 다중 AZ

RDS 읽기 전용 복제본과 다중 AZ의 차이를 이해하고 사용 사례를 제대로 아는 것이 중요하다. 

RDS Read Replicas for read scalability 

RDS DB 인스턴스는 읽기, 쓰기를 담당한다. 

하지만 주된 인스턴스가 요청이 너무 많은 경우 감당할 수 없기 때문에

읽기 전용 인스턴스를 스케일링 해야한다.

 

읽기 전용 복제본은 최대 5개 까지 생성가능

동일한 가용영역 또는 여러 가용영역,리전을 걸쳐 생성이 가능하다.

기억해야할 세 가지 옵션이 있다..?

 

복제본과 db 인스턴스간에 비동기식 복제(async replication)가 발생한다.

비동기식-> 읽기가 일관적으로 유지됨을 의미한다. 

가령 애플리케이션에서 데이터를 복제하기 전 읽기 전용 복제본을 읽어들이면 모든 데이터를 얻을 수 있다는 것이죠

 

읽기 전용본을 db 로 승격시킬 수 있다. ( Replicas can be promoted to their own DB)

그 이후에는 복제 매커니즘을 완전히 탈피한다. 

 

읽기 전용 복제본을 사용하려는 경우에는 화면 상단의 주요 애플리케이션에 있는 모든 연결을 업데이트해야 하며 이를 통해서 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있다. 

Application must update the connection string to leverage read replicas 

-> 읽기 복제본을 사용하려면 애플리케이션에서 연결을 업데이트 해야한다.

 

RDS Read Replicas - Use Cases

프로덕션 앱에서 사용하는 DB 가 있다고 가정하자.

개발 팀에서 DB 를 활용해야한다.

서비스 중인 DB를 사용하면 수정 문제나 성능 문제가 발생한다. 

 

이때 인스턴스의 replica를 하나 생성한다. 

 

개발팀에선 안정적으로 db를 사용할 수 있다. 

 

읽기 복제본에서는 오직 SELECT 명령문만 사용할 수 있다. 

db를 변경하는 insert, update,delete 문은 사용할 수 없다. 

 

RDS Read Replicas - Network Cost

aws 서비스 특징으로 az에서 다른 az로 데이터가 전송될 때 비용이 든다. 

하지만 보통 관리형 서비스에서는 az 데이터 전송에 따른 비용이 없다. 

 

읽기 전용본이 같은 리전의 다른 az 일 경우 전송비가 없다.

하지만 읽기 전용본이 다른 리전일 경우 전송비가 존재한다.

 

RDS Muli AZ (Disaster Recovery) 

다중 az는 주로 재해 복구용으로 사용된다. 

마스터 db를  동기식으로 스탠바이 db로 복제한다. 

 

하나의 DNS 이름을 갖는다.  마스터에 문제가 생길 때 장애 조치가 수행된다. 

 

az, 네트워크 에 문제가 생겼을때 스탠바이가 마스터로 승격된다. 

 

이 과정이 자동으로 이루어진다. 

 

스케일링에 사용되지 않는다 .

 

장애에 대한 예비용일 뿐이다 . 그 누구도 읽기 /쓰기 할 수 없다. 

 

그렇다면 재해복구용으로 읽기 전용 복제본을 사용할 수 있지 않을까? 

-> 가능하다. 원하는 경우에 읽기 전용 복제본을 dr 용으로 쓸 수 있다. 

 

RDS- From Single-AZ to Multi-AZ 

시험에 자주 나오는 문제로 단일 az 를 다중 az 로 변환할 수 있는지 묻는 문제가 나온다. 

가능하다!

특징

1. Zero downtime

단일 az에서 다중 az로 전환하는 과정에 db를 중지할 필요가 없다. 

2. 단순 클릭으로 ( Just click on "modify" for the database)

쉽게 활성화 할 수 있다.

 

단일 az를 다중 az로 활성화 시키는 과정

1. 마스터로부터 스냅샷 생성

2. 스냅샷으로부터 스탠바이 생성

3. 두 인스턴스간의 동기화 작업 실행


87. Amazon RDS 실습

MySQL 데이터베이스를 생성하는 방법 – Amazon Web Services

 

MySQL 데이터베이스를 생성하는 방법 – Amazon Web Services

Network & Security Public accessibility: Yes를 선택합니다. 이렇게 하면 데이터베이스 인스턴스에 대한 IP 주소가 할당되므로 사용자 디바이스에서 데이터베이스에 직접 연결할 수 있습니다. Availability zon

aws.amazon.com

 

아마존 사이트에 친절하게 설명이 잘되어있다.

필요할때 참고하자.

 

실습내용에선 SQL Electron을 사용하였다. 

 

포트는 3306


88. RDS Custom for Oracle 과 Microsoft SQL Server 

RDS Custom 

RDS 에서는 기저 운영 체제나 사용자 지정 기능에 액세스 할 수 없다. 

그러나 RDS Custom 에서는 가능하다. 

 

Oracle, Microsoft SQL Server  에서 가능하다. 

RDS는 자동화, 운영 , 확장 할 수 있다. 

 

Custom 의 경우

기저 os 및 데이터베이스에 접근할 수 있다.

내부설정 구성, 패치 적용, 네이티브 기능 활성화가 가능하며

SSH 또는 SSM 세션 관리자를 사용해서 RDS 뒤에 있는 기저 EC2 인스턴스에 액세스 할 수 있다. 

 

custom을 사용하려면 RDS가 수시로 자동화 , 유지관리 또는 스케일링과 같은 작업을 수행하지 않도록 자동화를 꺼두는 것이 좋다. 

De-activate Automation Mode to perform your customization, better to take a DB snapshot before

RDS vs RDS Custom

RDS: db와 OS 모두 aws 가 관리한다.

RDS Custom: OS와 DB에 대한 완전 액세스가 가능하다. 

 

=> RDS도 결국 ec2 인스턴스에서 돌아가는 서비스이다. 

RDS를 돌리기 위한 ec2 인스턴스의 os, db 엔진 패치 등을 aws가 관리한다. 

RDS Custom을 이용하면 rds 가 돌아가는 ec2 인스턴스의 os, db 엔진 등 수동 조작이 가능하다.


89. Amazon Aurora 개요

Amazon Aurora

Aurora는 AWS 고유의 기술이다.

Postgres 그리고 MySQL  과 호환된다. 

클라우드 최적화 Cloud Optimized 

mysql 보다 5배 postgres 보다 3배 향상된 성능을 보인다. 

aurora 스토리지는 자동으로 확장한다.

10GB에서 시작하지만 데이터베이스에 더 많은 데이터를 넣을수록 자동으로 128TB 까지 커진다 .

mysql의 읽기 복제본이 5개 까지인 것에 비해 15개의 읽기복제본을 갖는다 .

장애 조치에 즉각이다 Failover in Aurora is instantaneous. It's HA native

비용은 RDS에 비해 20% 정도 높지만 스케일링 측면에서 훨씬 더 효율적이다. 

 

Aurora High Availbility and Read Scaling

3개의 가용영역에 걸쳐 6개의 복제본을 생성한다.

쓰기 작업 -> 4개만 필요 (한 az 가 다운 되어도 사용에 문제가 없음.)

읽기 작업 -> 6개의 복사본 중 3개만 필요

자동 복구 기능 - p2p 식

스트라이프 형식으로 작동함

 

az는 다중 az 와 유사하다. 

쓰기를 받는 인스턴스는 1개 뿐이다.

aurora 에도 마스터가 존재하고 여기서 쓰기를 받는다. 

마스터가 작동하지 않으면 30초 이내로 장애 조치가 시작된다.( failover 가 빠름) 

 

마스터 외에 읽기 복제본을 15개를 둘 수 있고

마스터에 문제가 생기면 읽기 복제본을 마스터로 승격할 수 있다. (rds에서 읽기 복제본이 아니라 다중 az를 마스터로 승격 시켰음.) 

이 복제본들은 리전 간 복제를 지원한다. 

마스터는 하나, 복제본은 여럿 

작은 블록 단위로 자가 복구 또는 확장 

 

Aurora DB Cluster

모든 인스턴스들은 스토리지 볼륨을 공유하고 있다. 

읽기 전용 복사본에 대한 오토 스케일링 설정이 가능하다. 

 

엔드포인트 

라이터 엔드포인트 : 쓰기 작업이 가능한 마스터 인스턴스로 연결

리더 엔드포인트 : 로드 밸런싱과 연결하여 읽기 전용 인스턴스로 연결해준다. 

 

Aurora의 기능 

자동 장애조치

백업 및 복구

격리 보안, 

산업 규정 준수

버튼식 스케일링

제로 다운타임 패치

고급 모니터링

통상 유지 관리 

백트랙 backtrack: 백업에 의존하지 않고 원하는 시점으로 복구하는 기능 


90. Amazon Aurora 실습

DB 클러스터 생성 및 Aurora MySQL DB 클러스터의 데이터베이스에 연결 - Amazon Aurora

 

DB 클러스터 생성 및 Aurora MySQL DB 클러스터의 데이터베이스에 연결 - Amazon Aurora

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

오토 스케일링과 관련하여 정책을 추가할 수 있다. 

 

 


91. Aurora Replicas - Auto Scaling 

Aurora Replicas - Auto Scaling 

오토 스케일링에서 읽기 레플리카가 확장된다.

이때 리더 엔드포인트도 마찬가지로 확장된다. 

 

Aurora - Custome Endpoints 사용자 지정 엔드포인트

읽기 전용 인스턴스를 확장할때 

용량이 더 큰 인스턴스가 있는 상황이다. 

용량이 더 크고 성능이 좋으므로 해당 인스턴스는 더 높은 수준의 워크로드를 처리할 수 있다. 

해당 워크로드만 처리하기 위해 사용자 엔드포인트로 진입하게 한다. 

 

읽기 인스턴스의 워크로드를 분리 시킴.

=> 인스턴스 타입이 다를 경우 특정 엔드포인트로 분리할 수 있다.

 

Aurora Serverless 

 

자동화된 데이터베이스 인스턴스와 실제 사용을 기반으로 자동 스케일을 가능하게 해준다. 

비정기적, 간헐적, 예측 불허한 워크로드에 유용

용량 계획을 세울 필요가 없다. 

 

클라이언트는 aurora 관리 하위 프록시 플릿과 소통하다. 

백엔드에서 워크로드에 기반해 서버리스 방식으로 여러 Aurora 인스턴스가 생성된다. 

각 aurora 인스턴스에 대해 매 초당 비용을 지불하게 된다. 

따라서 용량을 미리 확보할 필요가 없다. 

=> 서버리스로 완전 자동화 

 

Aurora Multi-Master

라이터 노드에 대한 즉각적이 장애 조치로 라이터 노드에 높은 가용성을 갖추고자 할 때 사용한다. 

이 경우 Aurora 클러스터의 모든 노드에서 읽기 및 쓰기가 가능하다.

 

기존에는 노드를 마스터 노드로 승격했다면 

multi master에서는 말그대로 모든 노드에서 쓰기가 가능하다. 

 

Global Aurora

aurora 리전 간 복제본은 재해 복구에 많은 도움이 되며 간단하게 생성이 가능하다. 

 

하지만 최근에는 Aurora Global Database 를 사용하는 것이 권장된다. 

모든 쓰기 및 읽기가 진행되는 하나의 기본 리전이 있다.

복제 지연이 1초 미만인 보조 읽기 전용 리전을 다섯 개까지 설정할 수 있다.

각 보조 지역마다 읽기 전용 복제본을 16개까지 생성 가능하다. 

이렇게 하면 세계 각지에 있는 읽기 전용 복제본의 지연 시간을 단축할 수 있다.

재해 복구 목적으로 다른 지역을 승격하는데 필요한 RTO (Recovery Time Objective) 는 1분 미만이다. 

 

다른 리전으로 복구하는데 1분도 걸리지 않는다는 뜻이다.

 

시험에서 리전에 걸쳐 데이터를 복제하는데 걸리는 시간이 평균 1초 미만이다~ 이런 문제가 나온다면 Global Aurora 이다.

 

Aurora Machine Learning

Aurora는 AWS 내의 머신 러닝 서비스와 통합을 지원한다 .

 

ML 기반 예측을 SQL 인터페이스로 애플리케이션에 적용하는 것

 

SageMaker : 백엔드에서 어떤 머신 러닝 모델이라도 사용할 수 있게 해주는 SageMaker

Amazon Comprehed : 감정 분석에 사용.

 

반드시 ml 경험을 알 필요없다. 

 

활용 예시로는 감지 맞춤 광고, 감정 분석 , 제품 추천등이 있으며 모두 Aurora 내에서 가능하다. 

 

아키텍처 개념

애플리케이션에서 SQL 쿼리를 aurora에게 넘김.

aurora에서 연결된 머신 러닝 서비스로 데이터를 전송 

응답을 받고 aurora는 애플리케이션에 결과를 반환한다.


92. RDS & Aurora - 백업과 모니터링 

RDS Backups

Automated backups: 

자동으로 매일 데이터베이스 유지 관리 시간에 데이터베이스 전체를 백업한다.

5분마다 트랜잭션 로그도 백업된다. -> 가장 최신 백업이 5분 전이다. 

자동 백업 보유 기간은 1일에서 35일까지로 설정할 수 있다.

비활성화 할려면 0일로 수정한다.

 

Manual DB Snapshots

수동으로 트리거해야한다. 

수동 백업은 원하는 만큼 오래 보유할 수 있다.

 

자동 백업은 기간이 지나면 사라지지만 수동으로 만든 DB 스냅샷은 원하는 기간동안 보유 가능하다.

 

비용 절감팁!

RDS 데이터베이스를 매달 2시간만 사용할 예정이다.

데이터베이스를 정지하게되어도 스토리지 비용을 계속 지불해야한다.

 

그 대신 2시간 사용 후에 스냅샷을 만들고 원본 데이터베이스를 삭제한다는 방법이 있다.

스냅샷 비용은 RDS 데이터베이스 스토리지 보다 저렴하다.

데이터베이스를 다시 사용할 때 스냅샷을 복원해서 사용하면 된다. 

 

Aurora Backups

Automated backups

백업본을 1~35일까지 분량까지 보유할 수 있다.

RDS 와 다르게 Aurora는 비활성화가 불가능하다. 

지정 시간 복구 기능이 있다.  (point-in-time)

 

Manual DB Snapshots

수동 DB 스냅샷을 만들 수 있다.

보유 기간은 원하는 만큼 지정할 수 있다. 

 

RDS & Aurora Restore options

복원 기능으로 RDS 및 Aurora 백업 또는 스냅샷이다.

스냅샷으로부터 복원하여 새로운 DB를 만들 수 있다. 

 

S3로부터 MySQL DB 복원하기

온프레미스 db의 백업을 만들어서 s3에 저장

s3로부터 RDS db 만들기 

 

 

S3로부터  Aurora Cluster 복원하기

온프레미스 db 백업본을 Percona XtraBackup 소프트웨어를 이용하여 만든다.

백업 데이터를 S3에 저장 

S3 로부터 aurora cluster 생성

 

Aurora Database Cloning

Aurora Cluster 를 기반으로 복제본을 생성한다.

스냅샷&복구보다 빠르다. 

 

프로덕션 db에 영향을 끼치지 않고 스테이징 db를 만드는데 좋다. 

 


93. RDS Security

RDS & Aurora Security 

RDS 및 Aurora 데이터베이스에 저장된 데이터를 암호화할 수 있다. 

이는 데이터가 볼륨에 암화화된다는 뜻이다. 

 

KMS를 사용해 마스터와 모든 복제본의 암호화가 이루어지며

이는 데이터베이스를 처음 실행할 때 정의된다. 

 

만약 마스터 db가 암호화되지 않는다면 읽기 전용 복제본도 암호화 될 수 없다.

 

암호화 되지 않은 데이터베이스를 암호화 하려면 

스냅샷을 뜬 다음에 암호화된 데이터 베이스로 생성해야한다. 

 

데이터 전송 중 암호화 

클라이언트와 db 간의 전송 중 데이터 암호화가 있다. 

RDS, Aurora는 기본적으로 전송 중 데이터 암호화 기능을 갖추고 있음.

AWS의 TLS 루트 인증서를 사용한다. 

사용자 이름, 패스워드등 전통적인 조합을 사용할 수 있음.

 

IAM 역할

IAM 역할을 사용해서 데이터 베이스에 접속할 수 있음.

보안 그룹

데이터베이스에 대한 네트워크 액세스를 통제할 수도 있다. 

No SSH

rds custom을 제외하고는 RDS, Aurora 는 SSH 액세스가 없다. 

Audit Log

CloudWatch 로 감사 로그를 보낼 수 있다. 


94. RDS Proxy

Amazon RDS Proxy

프록시가 하나의 풀에 연결을 모아 RDS 데이터베이스 인스턴스로 연결한다.

 

1. 완전 관리형 데이터베이스

2. 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있다.

3. 데이터베이스 성능을 개선할 수 있다. 데이터베이스의 리소스 부하를 줄이고 개방된 연결을 최소화 한다. ( timeouts 을 최소화 한다. ) 

4.서버리스로 오토 스케일링 가능하며 다중 az를 지원한다. 고가용성

5. RDS Proxy 를 사용함으로써 RDS,Aurora의 장애 조치 시간을 66% 까지 줄일 수 있다. 

6. MySQL, PostgreSQL, MariaDB 용 RDS를 지원하며 MySQL, PostgreSQL 용 Aurora를 지원한다.

7. 애플리케이션 코드를 변경하지 않아도 된다. RDS, Aurora DB에 바로 연결하는 대신 RDS 프록시에 연결하기만 하면 된다.

8. 데이터베이스에 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS에 접근하게 할 수 있다. 

9. RDS 프록시는 절대 퍼블릭 액세스가 불가능하다. vpc 내에서만 접근할 수 있다.

10. 람다함수와 호환이 좋다 .

 

결론: RDS Proxy 가 다 처리해준다. 

 


95. ElastiCache 개요 

Amazon ElastiCache Overview

1. RDS 와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있다.

2. 일래스틱 캐시는 레디스 또는 맴키스트와 같은 캐시 기술을 관리할 수 있도록 한다.

3. 캐시는 높은 성능낮은 지연 시간을 가진 인 메모리 데이터베이스이다.

4. 읽기 집약적인(read intensive workloads) 워크로드의 부하를 줄이는데 도움이 된다 .

5. 애플리케이션을 stateless 하게 만드는데 도움이된다. 

6. AWS 가 운영 체제, 패치, 최적화와 설정, 구성,모니터링,장애 회복 그리고 백업등의 유지 보수를 진행한다. 

7. 일래스틱 캐시를 사용하기 위해 애플리케이션 코드를 변경해야한다 .

 

ElastiCache Solutin Architecture - DB Cache

애플리케이션, amazon ElastiCache, RDS 가 있다.

 

애플리케이션이 일래스틱 캐시를 쿼리한다. 

쿼리가 이미 생성되었는지 일래스틱 캐시에 저장됐는지 확인 하는 것이 캐시 히트 (cache hit) 고 

이는 일래스틱 캐시에서 바로 응답을 얻어서  쿼리하기 위해 데이터베이스로 이동하는 동선을 줄여준다 .

 

캐시 미스( cache miss) 의 경우에는 데이터베이스에서 데이터를 가져온다.

데이터를 캐시에 다시 기록하여 다음에 같은 쿼리가 오면 캐시 히트를 얻도록 한다.

 

이를 통해서 RDS 데이터베이스에서 부하를 줄이는데 도움을 준다. 

 

데이터를 캐시에 저장하기 때문에 캐시 무효화 전략( invalidation strategy)이 있어야 하며 가장 최근 데이터만 사용하는지 확인해야한다.

Cache must have an invalidation strategy to make sure only the most current data is used in there.

ElastiCache Solutin Architecture - User Session Store

다른 아키텍처는 사용자 세션을 저장해 애플리케이션을 stateless 로 만드는 것이다 .

 

사용자가 애플리케이션의 모든 계정에 로그인하면

애플리케이션이 일래스틱 캐시에 세션 데이터를 기록하는 것이다. 

 

사용자가 다른 애플리케이션의 다른 인스턴스로 리디렉션 되면 애플리케이션을 일래스틱 캐시에서 직접 세션 캐시를 검색할 수 있다.  -> 사용자는 계속 로그인한 상태로 한 번 더 로그인 할 필요가 없다. 

사용자의 세션 데이터를 일래스틱 캐시에 기록해서 애플리케이션을 무상태로 만드는 것이다 .

The instance retrieves the data and the user is already logged in.

 

ElastiCache - Redis vs Memcached 

레디스: 

다중 az, 장애 극복 및 읽기복제본 

고가용성 

백업과 기능 복원 기능

 

memcached:

데이터 분할에 다중 노드를 사용  sharding 

가용성이 높지 않고 복제도 발생하지 않음

지속적인 캐시가 아님

백업과 복원 기능도 없음. 

단순 분산 캐시


96. ElastiCache 실습

레디스 데이터베이스 만들기 

 

 

Amazon ElastiCache for Redis 시작하기 - Amazon ElastiCache for Redis


 

97. 솔루션 설계자를 위한 ElastiCache

ElastiCache - Cache Security 

1. 일래스틱 캐시의 모든 캐시는 IAM 인증을 지원하지 않는다. 

aws api 수준 보안에서만 사용된다. (캐시 생성, 캐시 삭제 같은 종류의 작업)

 

2. 레디스 인증

레디스 인증을 하려면 레디스 auth를 사용하여 레디스 클러스터를 생성할 때 비밀 번호나 토큰을 설정할 수 있다.

캐시에 들어갈 때 비밀 번호를 사용할 수 있다.

이는 캐시에 사용할 수 있는 보안 그룹에 대한 추가적인 수준의 보안이다. 

데이터 전송중 SSL 보안을 지원한다. 

 

3. 멤캐시트의 경우 

좀 더 높은 수준인 SASL 기반 인증을 지원한다. 

 

Patterns for ElastiCache 

일래스틱 캐시에는 데이터를 불러오는 세가지 패턴이 존재한다 .

 

1. 레이지 로딩 Lazy Loading

모든 읽기 데이터가 캐시되고 데이터가 캐시에서 부실해질 수 있다.

 

2. 라이트 스루 Write Through 

데이터베이스에 기록될 때마다 캐시에 데이터를 추가하거나 업데이트 하는 것이다 .

 

3. 세션 저장소 Session Store

캐시를 세션 저장소로 쓸 수 있다.  TTL (Time To Live) 속성으로 세션을 만료 시킬 수 있음.

 

 

ElastiCache - Redis Use case

시험!! 

게이밍 리더보드 

레디스에는 고유성과 요소 순서를 모두 보장하는 정렬된 집합(Sorted Set)이라는 기능이 있다.

요소가 추가될 때마다 실시간으로 순위가 매겨진 다음 올바른 순서로 추가된다 .


98. 친숙한 포트 목록

아래는 한 번 이상은 확인하는 게 좋은 표준 포트의 목록입니다. 외울 필요는 없습니다(시험에 나오지 않을 거예요). 하지만 중요한 포트(HTTPS - 443번 포트)와 데이터베이스 포트(PostgreSQL - 5432번 포트)를 구분할 수는 있어야 합니다.

중요한 포트:

  • FTP: 21
  • SSH: 22
  • SFTP: 22 (SSH와 같음)
  • HTTP: 80
  • HTTPS: 443

vs RDS 데이터베이스 포트:

  • PostgreSQL: 5432
  • MySQL: 3306
  • Oracle RDS: 1521
  • MSSQL Server: 1433
  • MariaDB: 3306 (MySQL과 같음)
  • Aurora: 5432 (PostgreSQL와 호환될 경우) 또는 3306 (MySQL과 호환될 경우)

 

스트레스받으면서 외우지 마세요. 표준 포트 목록은 오늘 한 번 확인하고 시험 전에 한 번 더 읽어보기만 해도 시험에서는 문제없을 거예요. :)

“중요한 포트”와 “RDS 데이터베이스 포트”를 구분할 줄만 알면 됩니다.


Quiz 6 : RDS, Aurora & ElasiCache 퀴즈 

1. 아마존 RDS가 지원하지 않는 데이터베이스를 고르세요.

RDS는 MySQL, PostgreSQL, MariaDB, Oracle, MS SQL Server, Amazon Aurora를 지원합니다.

 

2. 한 가용 영역에 재해 상황이 발생하더라도 반드시 MySQL 데이터베이스을 사용할 수 있도록 만들기 위한 새로운 솔루션을 계획하고 있습니다. 무엇을 사용해야 할까요?

다중 AZ는 전체 AZ가 차단되었을 경우의 재해 복구를 계획하는 데에 도움이 됩니다. 전체 AWS 리전이 차단될 경우에 대비해 계획을 세울 때에는, AWS 리전에 걸친 백업과 복제본을 사용해야 합니다.

 

3. RDS 데이터베이스가 웹사이트에서 들어오는 요청량을 처리하는 데에 어려움을 겪고 있습니다. 백만 명의 사용자들은 대부분 뉴스를 읽고 있으며, 뉴스가 자주 포스팅되는 편은 아닙니다. 이 문제를 해결하기 위해 사용해서는 안 되는 솔루션은 무엇인가요?

시험 문제를 읽을 때는 주의하시기 바랍니다. 이 문제에서는, 이런 문제점을 해결하기 위해 사용해서는 "안 되는" 솔루션이 무엇인지 묻고 있습니다. ElastiCache와 RDS 읽기 전용 복제본은 읽기 스케일링에 도움이 됩니다.

4. RDS 데이터베이스에 읽기 전용 복제본을 설정해 두었지만, 소셜 미디어 포스트를 업데이트할 시 업데이트가 바로 이루어지지 않는다는 점에 대해 사용자들이 불만을 토로하고 있습니다. 이 경우, 가능성이 있는 원인은 무엇일까요?

5.다음 RDS(Aurora 아님) 기능들 중, 사용 시 SQL 연결 문자열을 변경하지 않아도 되는 것은 무엇인가요?

다중 AZ는 활성화 상태의 데이터베이스 종류와 상관 없이 동일한 연결 문자열을 유지합니다.

 

6. 이 애플리케이션은 Application Load Balancer가 관리하는 오토 스케일링 그룹에서 관리 중인 EC2 인스턴스 플릿에서 실행되고 있습니다. 사용자들이 계속 재로그인을 해야 하는 상황이지만, 일부 EC2 인스턴스에 과부하를 일으킬 수도 있다는 생각에 고정 세션은 활성화하지 않으려 합니다. 어떻게 해야 할까요?

세션 데이터를 ElastiCache에 저장하는 방법은 서로 다른 EC2 인스턴스들이 필요 시 사용자의 상태를 회수할 수 있게끔 하기 위해 흔히 사용됩니다.

 

7. 현재 어떤 분석 애플리케이션이 주요 프로덕션 RDS 데이터베이스에 대한 쿼리를 수행하고 있습니다. 이러한 쿼리들은 언제든 실행되어, RDS 데이터베이스의 성능을 낮추고 사용자 경험에 영향을 미치게 됩니다. 사용자 경험을 증진시키기 위해서는 어떻게 해야 할까요?

읽기 전용 복제본을 설정하면 분석 애플리케이션이 쿼리를 수행할 수는 있으나, 이 쿼리들이 주요 프로덕션 RDS 데이터베이스에는 영향을 미치지 않게 되므로 도움이 됩니다.

8. 주 AWS 리전에 재해가 발생했을 때에 대비하여 다른 AWS 리전에 데이터베이스의 복제본을 만들어 두려 합니다. 이런 작업을 쉽게 구현하기 위해서는 어떤 데이터베이스의 사용을 추천할 수 있을까요?

 

 

 

다중 AZ는 AWS 리전 수준의 재해가 발생할 경우에는 도움이 되지 않습니다. 다중 AZ는 AZ 수준의 재해 발생 시에는 도움이 됩니다.

Aurora 글로벌 데이터베이스를 사용하면 최대 5개의 2차 리전까지 Aurora 복제본을 가질 수 있습니다.

9. 사용자들이 연결되었을 때, 비밀번호를 입력하도록 하여 ElastiCache Redis 클러스터의 보안을 높이기 위해서는 어떻게 해야 할까요?

10. 리전에 정전이 발생하더라도 데이터베이스가 다른 AWS 리전에서 빠르게 워크로드 읽기와 쓰기 작업을 수행할 수 있게끔 RDS PostgreSQL 데이터베이스의 재해 복구 전략을 생성하려 합니다. DR 데이터베이스의 고가용성은 보장되어야 합니다. 어떤 방법을 추천할 수 있을까요?

11. 여러분이 근무 중인 기업은 RDS MySQL 5.6을 데이터베이스로 사용하는 프로덕션 Node.js 애플리케이션을 가지고 있습니다. Java로 프로그래밍된 새로운 애플리케이션은 정기적인 대시보드 생성을 위해 많은 양의 분석 워크로드를 수행할 예정입니다. 이 경우, 주요 애플리케이션에 발생하는 지장을 최소화하기 위해 구현할 수 있는 방법 중 가장 비용 효율적인 솔루션은 무엇인가요?

 

12.MySQL 데이터베이스를 온프레미스에서 RDS로 이전해 둔 상태입니다. 여러 애플리케이션과 개발자들이 이 데이터베이스와 상호작용을 하고 있습니다. 각 개발자들은 기업의 AWS 계정 내에 IAM 사용자를 가지고 있습니다. 각 개발자들을 위해 DB 사용자를 생성하는 대신, 이들에게 MySQL RDS DB 인스턴스로의 액세스를 부여하기 위해서는 어떤 접근법을 취해야 할까요?

IAM 데이터베이스 인증

13.다음 중 RDS 읽기 전용 복제본과 다중 AZ로의 복제 작업을 적절하게 묘사한 설명은 무엇인가요?

14.암호화되지 않은 RDS DB 인스턴스를 암호화하는 방법은 무엇인가요?

15. RDS 데이터베이스를 위해 최대 ............개의 읽기 전용 복제본을 가질 수 있습니다.

 RDS 읽기 전용 복제본을 5개까지 가질 수 있다.

16.다음 중 IA웹 서버 M 데이터베이스 인증을 지원하지 않는 RDS 데이터베이스 기술은 무엇인가요?

 

 

17. 암호화되지 않은 RDS DB 인스턴스가 있는 상태에서 읽기 전용 복제본을 생성하려 합니다. RDS 읽기 전용 복제본이 암호화되도록 구성할 수 있을까요?

암호화되지 않은 RDS DB 인스턴스로는 암호화된 읽기 전용 복제본을 생성할 수 없습니다.

18. 프로덕션에서 실행 중인 한 애플리케이션이 Aurora 클러스터를 데이터베이스로 사용하고 있습니다. 여러분의 개발 팀은 필요할 경우 많은 양의 워크로드를 수행할 수 있는, 스케일이 축소된 애플리케이션에서 애플리케이션의 버전을 실행하려 합니다. 애플리케이션은 대부분의 시간 동안 사용되지 않습니다. CIO는 여러분에게 팀을 도와 비용을 최소화하는 동시에 이를 달성해 줄 것을 요청했습니다. 어떤 방법을 사용해야 할까요?

 

19. 하나의 Aurora DB 클러스터는 몇 개의 Aurora 읽기 전용 복제본을 가질 수 있을까요?

20. Amazon Aurora는 .......................... 데이터베이스를 모두 지원합니다.

 

21. 여러분은 게임 개발 업체에서 솔루션 아키텍트로 근무하고 있습니다. 하나의 게임에서, 실시간 점수를 기반으로 플레이어들의 랭킹을 매겨야 합니다. 여러분의 상사가 게임 리더보드 생성을 위해 효율적이고 고가용적인 솔루션을 설계해 구현해 줄 것을 요청했습니다. 무엇을 사용해야 할까요?

 

【한글자막】 AWS Certified Solutions Architect Professional | Udemy

2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 3: AWS 시작하기

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 4: IAM 및 AWS CLI

2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초

2023.01.10 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 6: EC2 - 솔루션스 아키텍트 어소시에이트 레벨

2023.01.11 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 7: EC2 인스턴스 스토리지

 


69. 고가용성 및 스케일링성

Scalability & High Availability 

확장성은 애플리케이션 시스템이 조정을 통해 더 많은 양을 처리할 수 있음을 의미

 

확장성의 두가지 종류

1.  수직 확장성- 인스턴스의 크기를 확장

2.  수평 확장성- 탄력성이라고 불림

 

확장성과 고가용은 다른 개념이다

 

Vertical Scalability

ex 신입 전산원은 1분에 전화 5통 소화 가능하지만

경력직은 1분에 전화 10통을  소화한다. 

-> 더 빠르고 능숙함.

 

t2.micro -> t2.large 로 교체

 

언제?사용

데이터베이스와 같이 분산되지 않은 시스템에 유용하다. 

RDS, ElasticCache 등에서 사요ㅇ

하위 인스터스의 유형을 업그레이드해 수직적으로 확장할 수 있는 시스템이다. 

 

일반적으로 확장할 수 있는 정도에는 한계가 있다.

 

Horizontal Scalability

ex) 전산원을 늘리는 것 

 

수평 확장을 했다는 것은 분배 시스템이 있다는 것을 의미

 

현대 애플리케이션은 대부분 분배 시스템으로 이루어져 있다.

 

ec2에서 매우 쉽다. 

 

High  Availability

고가용성이란 애플리케이션 또는 시스템을 적어도 둘 이상의 aws의 az 나 데이터 센터에서 가동 중이라는 것을 의미한다.

고가용성의 목표는 데이터 센터에서의 손실에서 살아남는 것으로 센터 하나가 멈춰도 계속 작동이 가능하게 끔하는 것

 

예를 들어 뉴욕에도 콜센터가 있고 샌프란시스코에도 콜센터가 있다.

뉴욕 지사에 문제가 생길 경우 샌프란시스코에서 처리를 해줄 수 있다. 

 

RDS 다중 az를 갖추고 있다면 수동형 고가용성(수평형 확장)을 확보한 것이다. 

활성형 고가용성 ( 수직적 확장)

 

High Availability Scalability For EC2 

현재 가장 작은 인스턴스는 t2.nano 0.5 gb 램에 1v cpu 이고

가장 큰 인스턴스는 u-t12tb1.metal로 12.3 tb 램을 갖춘 450vCpus 가 있다. 

 

수평확장 은 스케일 아웃 스케일 인

스케일 아웃: 인스턴스 수를 늘림

스케일 인 : 인스턴스 수를 줄임

 

다른 스케일링 그룹이나 로드 밸런서에도 사용한다. 

 

고가용성은 같은 애플리케이션의 동일 인스턴스를 다수의 AZ 에 걸쳐 실행하는 경우를 의미한다. 

 

다중 AZ 가 활성화된 자동 스케일러 그룹이나 로드밸런서에도 사용된다. 

 


70. Elastic Load Balancing  (ELB) 개요

what is load balancing? 

로드 밸런서는 서버 혹은 서버셋으로 트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 한다. 

 

ELB는 첫번째 유저는 첫번째 인스턴스

두번째 유저는 두번째 인스터스로 ... 연결한다

유조들은 자신들이 백엔드 인스턴스 중 어떤 것에 연결되어 있는지 알 수 없다. 

 

자신들이 ELB 에 연결되면 한 엔드 포인트에 연결이 된다는 것만 안다.

 

Why use a load balancer?

1. 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서이다. 

2. 단일 액세스 지저 (DNS) 를 노출한다.

3. 다운스트림 인스턴스의 장애를 원활히 처리할 수 있다.

4. LB가 상태확인 메커니즘으로 어떤 인스턴스로 트래픽을 보낼 수 없는지 확인해준다. 

5. SSL 종료도 할 수 있으므로 웹사이트에 암호화된 HTTPS 트래픽을 가질 수 있다.

6. 쿠키로 고정도를 강화할 수 있고 

7.여러 az에 걸쳐 고가용성 확보도 가능하며

8. 공용 트래픽과 사설 트래픽을 분리할 수 있다.

 

ELB는 완전 관리형 로드 밸런서이다 .

aws 가 관리하며 어떤 경우에도 작동할 것을 보장한다. 

업그레이드와 유지 관리 및 고가용성을 책임지며 로드 밸런서의 작동 방식을 수정할 수 있게끔 일부 구성 놉(knobs)도 제공한다. 

 

자체 로드 밸런서를 마련하는 것보다 저렴하고 확장성도 용이하다.

 

다수의 aws 서비스와 통합되어 있다. (뛰어난 확장성)

ECS, ACM, CloudWatch, Route 53 , WAF Global Accelerator 등

 

ELB 를 쓰는것이 무조건 이득이다. 

 

Health Checks 상태 확인

상태 확인은 ELB가 EC2 인스턴스의 작동이 올바르게 되고 있는지의 여부를 확인하기 위해 사용된다.

상태 체크를 통해 해당 인스턴스로 트래픽을 보낼지 말지 여부를 정한다. 

상태 확인은 포트라우트에서 이루어진다. 

 

예를 들어 HTTP 프로토콜, 포트는 4567 엔트포인트는 /health 가 있다.

HTTP 상태코드 200으로 응답하지 않는다면 인스턴스 상태가 좋지 않다고 기록된다.

그리고 ELB는 그쪽으로 트래픽을 보내지 않게 된다 .

 

Types of load balancer on AWS

4개의 관리형 로드 밸런서가 있다.

 

1세대

v1, 2009년

CLB 라고 불림 classic

http, https, tcp ,ssl , secure tcp 를 지원

권장하지 않음.

사용이 가능하긴하마.

 

애플리케이션 로드밸런서 V2

v2, 2016

HTTP, HTTPS, websocket

 

네트워크 로드 밸런서

v2 , 2017

TCP, TLS (secure TCP), UDP 

 

게이트웨이 로드밸런서

GWLB, 2020 

3계층과 ip 프로토콜에서 작동 

 

웬만해선 최신형 LB를 사용하자!

 

일부 로드 밸런서들은 내부에 설정 될 수 있어 네트워크에 개인적 접근이 가능하고

웹사이트와 공공(public) 애플리케이션 모두에 사용이 가능한 외부 (private)공공 로드 밸런서도 있다.

 

Load Balancer Security Groups

 

1. LB의 SG는 ...

[SGforLB]

http, tcp, 80, 0.0.0.0/0 

https, tcp, 443, 0.0.0.0/0 

이라면 해당 LB와 연결되는 인스턴스의 sg는

 

2. 인스턴스의 SG는

http, tcp, 80 , SGforLB

 

인스턴스의 소스는 SGforLB가 된다. -> elb에서만 접근할 수 있다. 

 

강화된 보안 매커니즘이다. SG가 연동된다!

 


71. Classic Load Balancer (CLB 공지) 

Note: About the Classic Load Balancer (CLB)

 

The Classic Load Balancer is deprecated at AWS and will soon not be available in the AWS Console.

The exam also has removed any references to it, so we will not cover it in depth in the course, nor the hands-on

 

 

Happy learning!

 

classic loadbalancer는 시험에 나오지 않는다.!

72,73 은 clb 관련된 내용이라서 건너 뛰겠습니다. 


74. Application Load Balancer (ALB) 개요

Application Load Balancer (v2)

애플리케이션 로드 밸런서는 7계층이다.

머신 간 다수의 HTTP 애플리케이션의 라우팅에 사용된다.

이러한 머신들은 대상 그룹이라는 그룹으로 묶이게 된다. 

 

동일 EC2 인스턴스 상의 여러 애플리케이션에 부하를 분산한다. 

(컨테이너와 ECS를 사용하게 된다.)

 

HTTP/2, WebSocket을 지원하며 리다이렉트도 지원하므로 

HTTP에서 HTTPS 로 트래픽을 자동 리다이렉트 하려는 경우

로드밸러서 레벨에서 가능하다.

 

경로 라우팅을 지원

Routing tables to different target groups: 대상 그룹에 따른 라우팅으로

1. URL 대상 경로에 기반한 라우팅이 가능하다.

example.com/users & example.com/posts

 

2.host name에 기반한 라우팅

one.example.com & other.example.com

 

3. Query String, Headers 에 기반한 라우팅

example.com/users?id=123&order=false 

 

애플리케이션 로드 밸런서의 약자로 ALB

 

마이크로 서비스, 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서

Docker ,ECS 와 가장 적합한 LB 

포트 매핑 port mapping 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.

 

CLB 에서 구현하려면 다수의 LB가 필요하지만 ALB는 하나만으로 다수의 애플리케이션을 처리할 수 있다.

 

Application Load Balancer (v2) HTTP Based Traffic

외부 ALB 가 있고  뒤에 EC2 인스턴스로 구성된 대상그룹이 2개 있다. 

Route/user 는 1번째 인스턴스로 라우팅 되고

Route/search 는 2번째 인스턴스로 라우팅 된다. 

 

URL 에서 사용되는 라우팅을 기반으로해 각 대상 그룹을 지능적으로 라우팅한다. (ALB의 역할) 

 

대상 그룹이란? target group?

EC2 가 될 수도 있다. (ASG 도 대상 그룹이 될 수 있다.)

ECS 작업이 될 수도 있다.

람다함수도 가능하지만 잘안쓰임. HTTP 요청이 JSON  이벤트로 변환된다. 

 

IP 주소 앞에 ALB를 둘 수 있지만 무조건 사설 네트워크 여야한다

ALB는 여러개의 대상 그룹으로 라우팅 할 수 있으며 

상태 확인 (health check)는 대상 그룹 레벨에서 이루어진다. ?

 

Application Load Balancer( v2) Query String/ Parameters Routing

 

첫번째 대상 그룹은 EC2 

두번째 대상 그룹은 온프레미스라고 하자

대상 그룹이 존재하기 위해서는 , 등록을 위해서는 서버의 사설 IP 가 대상 그룹에게 지정되어야한다.

-> 대상그룹 2를 쓰고 싶으면 사설 IP를 등록해야한다.

쿼리 내용을 기반으로 다른 대상 그룹을 연결 시키는 예시이다. 

 

Application Load balancer (v2) Good to know 

로드 밸런서를 사용하는 경우에도 고정 호스트 이름이 부여된다.

애플리케이션 서버는 클라이언트의 IP를 직접 보지 못한다.

클라이언트의 실제 IP는 X-Forwarded-For 라고 불리는 헤더에 삽입된다.

X-Forwarded-Port 를 사용하는 포트와  X-Forwarded-Proto 에 의해 사용되는 프로토콜을 얻는다.

즉 클라이언트의 IP인 12.34.56.78 가 로드밸런서와 직접 통신해 연결 종료라는 기능을 수행한다.

 

로드밸런서가 EC2 인스턴스와 통신할 때에는 사설 IP인 로드밸런서 IP를 사용해 EC2 에 들어가게 된다. 

EC2 인스턴스가 클라이언트의 IP를 알기 위해서는 HTTP 요청에 있는 추가 헤더인 X-Forwarded-port, proto를 확인해야한다. (간접적으로 확인)

 


75. Application Load Balancer (ALB) 실습 Part 1

ALB 생성하기

HTTP, HTTPS를 고르자 

 

1단계 : Load Balancer 구성

DemoALB

인터넷 경계

IPv4

 

 

가용 영역 선택 

가용 영역당 1개의 서브넷만 지정할 수 있다.

리스너 구성

 

2단계는 보안 설정 구성인데

뒤에 가서 하자.

3단계 : 보안 그룹 구성

 

 

4단계: 라우팅 구성

새 대상 그룹을 만든다. my-first-target-group

상태 검사 옵션 값은 위와 같이 한다. 

 

5단계: 대상 등록

 

대상 그룹에 등록할 인스턴스가 없기 때문에 생성하러 가자 

 

인스턴스 등록 

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

3개 만들기 , 같은 서브넷으로 만든다. 

 

대상 그룹에 인스턴스 2개만 추가하자. 

 

ALB 체크하기

생성된 DNS 로 접속해보자

 

인스턴스 의 보안그룹은 22port 만 열려있다. 사용자 데이터 스크립트는 잘 실행되었다.

계속 타임 아웃이 뜨길래 보안그룹 문제라고 생각했다.

 

alb의 보안그룹은 80번 포트로 모든 소스에 열려있다.

 

인스턴스의 보안그룹은 22번 포트로 모든 소스에 열려있다.

alb에서 인스턴스로 들어갈려면 80번 포트를 열고 alb의 sg를 소스로 하는 인바운드 규칙을 추가한다. 

 

 

 

launch-wizard 의 보안 그룹

하나의 주소로 두개의 인스턴스에 접속 가능하다. 

 

또다른 대상 그룹 생성하기 

아무 인스턴스나 등록해서 second-target-group 을 생성했다. 

리스너 설정하기

demo alb로 이동한다. 규치 보기/편집으로 간다 ( 현재 DemoELB는 first-target-group 으로 연결된다.)

만약 /test 경로를 입력하면 second-target-group으로 연결되게 한다. 

/constant 에 연결하면 고정 에러 페이지가 나오게 한다. 

 

여러가지 다른 방식으로 응답하게 설정했다.

test 로 접속하면 두번째 대상 그룹 화면이 떠야하는데 오류가 뜬다.

EC2 인스턴스가 /test 유형의 쿼리에 응답하도록 구성되지 않았기 때문이다. 

 

 

 

 

정리

리스너 삭제

대상 그룹 두번째 삭제

첫번째 대상그룹에 나머지 인스턴스 추가 


76. Network Load Balancer (NLB) 개요 

Network Load Balancer (v2)

네트워크 로드 밸런서는 L4 로드 밸런서이미로 TCP, UDP 트래픽을 다룰 수 있다.

HTTP를 다루는 L7보다 하위 계층이다.

네트워크 로드 밸런서의 성능은 매우 높다.

초당 수백만 건의 요청을 처리할 수 있다.

애플리케이션 로드 밸런서에 비해 지연 시간도 짧다.

ALB는 400밀리초지만 NLB는 100 밀리 초이다. 

가용 영역별로 하나의 고정 IP를 갖는다. NLB has one static IP per AZ, and supports assigning Elastic IP

탄력적 IP 주소를 각 AZ에 할당할 수 있다. 

 

여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다. 

 

1~3개의 ip로만 액세스할 수 있는 애플리케이션을 만들라는 문제가 나오면 네트워크 로드 밸런서를 옵션으로 고려하자!

고성능, TCP, UDP는 다 네트워크 로드 밸런서의 키워드이다. 

 

NLB는 프리티어에 포함되지 않는다. 

 

Network Load Balancer (v2) TCP (Layer 4 ) Based Traffic

대상 그룹을 생성하면 NLB 가 대상그룹을 리다이렉트한다. 

 

백엔드, 프론트엔드 모두 TCP 트래픽을 사용하거나

백엔드에서는 HTTP를 , 프론트엔드에서는 TCP 를 사용할 수 있다. 

 

Network Load Balancer - Target Groups 대상 그룹 유형

EC2 인스턴스 - 네트워크 로드밸런서가 TCP 또는 UDP 트래픽을 EC2 인스턴스로 리다이렉트 할 수 있다.

IP 주소 - IP주소는 반드시 하드코딩 되어야하고 프라이빗 IP여야한다. 주로 온프레미스가 대상이된다. 

ALB - NLB는 고정된 IP를 가지고 ALB는 HTTP 유형의 트래픽을 처리할 수 있다.

 

상태 체크는 TCP, HTTP, HTTPS 프로토콜을 지원한다. (시험에 나온다.)

 


77. Gateway Load Balancer (GWLB) 개요

GWLB는 배포 및 확장과 aws의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.

 

 

GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다. 

IDPS 나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다. 

 

alb에서 애플리케이션으로 이동할 때 모든 트래픽을 검사하게 할려면 ? 

 

유저와 어플리케이션 사이에 GWLB를 둔다. + 타사 가상 어플라이언스 배포

GWLB를 생성하면 이면에서는 VPC 에서 RT (라우팅 테이블) 이 업데이트 된다.

RT 가 업데이트 되었으므로 사용자의 모든 트래픽은 GWLB를 통과하고 -> 타사 가상 어플라이언스 -> GWLB -> 애플리케이션 순으로 트래픽이 이동한다. 

 

방화벽이나 침입 탐지와 같은 것이다 .

 

원리는 

GWLB는 IP 패킷의 네트워크 계층인 L3 이다. 

 

기능 

1. 투명한 네트워크 게이트웨이 ( 하나의 출입문 역할) 

2. 로드 밸런서 

 

6081 번 포트의 GENEVE 프로토콜 

Gateway Load balancer - Target Groups

1. EC2 - 타사 어플라이언스 

2. IP 주소 - 이 경우 개인 (private)IP 여야한다. 자체 네트워크나 자체 데이터 센터에서 이런 가상 어플라이언스를 실행하면 IP로 수동 등록할 수 있다. 

 


78. Elastic Load Balancer - 스티키 세션(Sticky Sessions)

It is possible to implement stickiness so that the sam client is always redirected to the same instance behind a a load balancer

로드 밸런서에서 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다. 

 

클라이언트의 요청에 대한 응답을 동일한 인스턴스가 담당하도록 LB 에 조정하는 일

 

clb, alb 에서 가능하다. 

 client1 의 요청은  1번 ec2 에서 고정하고 

다른 client의 요청은 다른 ec2에서 기억하고 응답한다. 

 

쿠키: 클라이언트에서 로드 밸런서로 요청의 일부로 전송된다. 

고정성과 만료 기간도 있다.

쿠키가 만료되었을시 다른 EC2 인스턴스로 리디렉션 된다

 

고정성을 활성화하면 백엔드 EC2 인스턴스 부하에 불균형을 초래할 수 있다.( 응답한 놈만 응답하기 때문에) 

 

Sticky sessions - cookie Names

고정 세션에는 애플리케이션 기반 쿠키와 기간 기반의 쿠키가 있다. 

 

애플리케이션 기반 쿠키

 

사용자 정의- 사용자 정의 쿠키로 애플리케이션에서 생성된다. 

애플리케이션에 필요한 모든 사용자 정의 속성을 포함할 수 있다. 

쿠키 이름은 각 대상 그룹별로 개별적으로 지정해야하는데 

AWSALB, AWSALBAPP, or AWSABLTG 등의 이름을 사용할 수 없다.

 

애플리케이션 쿠키 

로드밸런서가 생성하며 쿠키이름은 AWSALBAPP 이다 .

 

기간 기반 쿠기 Duration-based Cookies

로드밸런서가 생성하는 쿠키이다. 

쿠키이름은 AWSALB for ALB, AWSELB for CLB 이다.

 

실습- 쿠키 이용하기 

위에서 생성한 ALB 의 주소로 접속하면

매번 다른 인스턴스로 접속한다.

 

고정 세션 활성화 하기

원래 옵션이 더 많은데

일단 진행

계속 똑같은 인스턴스만 응답

AWSALB 쿠키가 생겼으므로 세션기반 쿠키

 

고정성 삭제하고 마무리 

 


79. Elastic Load Balancer - 크로스존 로드밸런싱( Cross Zone Load Balancing)

교차 영역 로드 밸런싱에 관해 알아보자

 

교차 영역 로드 밸런싱을 하면 모든 인스턴스에 고르개 트래픽을 분산 시킨다. 

로드밸런서로는 50 ,50 씩 분배하지만 

모든 인스턴스를 묶어서 10개니까 10%씩 고르게 분산 시킨다 .

 

 

교차 영역 로드 밸런싱을 꺼버리면 로드밸런서 50, 50 씩 트래픽을 가져가고 

로드 밸런서 기준으로 분배한다.

특정 인스턴스에만 부하가 걸린다. 

 

ALB 에서는 교차 영역 로드 밸런싱이 늘 활성화 되어있고 비활성화할 수 없다.

 

보통 데이터가 한 가용 영역에서 다른 가용 영역으로 이동하면 비용을 지불해야한다.

하지만 활성화되어 비활성화할 수 없으니 ALB에서 AZ간 데이터 전송에 관한 비용이 업삳. 

 

NLB는 교차 영역 로드 밸런싱이 비활성화되어 있기 때문에 az 간 데이터 이동에 대한 비용을 지불해야한다. 

 

CLB 는 비활성화가 디폴트 이지만 활성화 후 az 간 데이터 전송은 무료이다. 

 


80. Elastic Load Balancer( ELB) - 연결 트레이닝

연결 드레이닝 - Connection Draining

CLB - 연결 드레이닝

ALB, NLB- 등록 취소 지연 이라고 불린다.

 

인스턴스가 등록 취소, 혹은 비정상 상태에 있을 때 인스턴스에 어느 정도의 시간을 주어 

인-플라이트 요청(in-flight request), 즉 활성 요청을 완료할 수 있도록 하는 기능이다. 

ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않는다. 

1초에 3600초 까지 지연시간을 설정할 수 있다. 

지연 시간을 0으로 설정하면  이 기능을 비활성화 할 수 있다. 

짧은 요청의 경우에는 낮은 값으로 설정한다. 

1초보다 적은 아주 짧은 요청인 경우에는 연결 드레이닝 파라미터를 30초 정도로 설정한다.

 

요청 시간이 매우 긴 요청은 높은 값을 지정한다. 


81.  Auto Scailing Group (ASG) 개요

What's an Auto Scaling Group? 

웹사이트 방문자가 갈수록 많아지면서 워크로드가 바뀔 수 있다. 

AWS 에서 EC2 인스턴스 생성 API 호출을 통해서 서버를 빠르게 생성하고 종료할 수 있다.

ASG는 해당 작업을 자동화한다.

 

ASG의 목적

Scale out - EC2 인스턴스를 늘리는 것 

Scale in - EC2 인스턴스를 줄인다. 

최소, 최대 인스턴스 수를 보장한다. 

 

로드 밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다. 

인스턴스에 문제가 생기면 종료하고 새로운 인스턴스를 실행한다. 

 

ASG 는 무료이다. 실행되는 ec2 인스턴스는 유료 

 

Auto Scaling Group in AWS 

minimum size : 최소

actual Size/ Desired capacity : 희망

Maximum size : 최대 

 

Auto Scaling Group in AWS With Load Balancer

ASG는 LB와 좋은 조합이다. 

사용자 -> ELB -> ASG -> EC2 

ELB에서 EC2 instance 상태 체크가 가능하다.

 

상태에 문제가 있으면 종료 시키고 새로운 인스턴스를 생성하거나,

ELB가 트래픽을 ASG의 인스턴스로 분배한다. 

 

Auto Scaling Group Attributes

ASG 에서 인스턴스를 추가할때 탬플릿을 기반으로 생성한다. 

탬플릿에는 AMI, 인스턴스 타입, 사용자 데이터 ,EBS 볼륨, 보안 그룹, SSH key pair, IAM Roles for your EC2 Instances

Network + Subnets Information

Load balancer Information 

등 다양한 정보를 가진다. 

 

asg에서 최소, 최대, 초기 용량을 정해야한다. 

스케일링 정책도 정해야한다 .

 

Auto Scaling - CloudWatch Alarms & Scaling 

클라우드 워치 알람을 이용하여 asg의 스케일링을 이용할 수 있다.

metric 지표에 의해 경보를 울린다. ( average CPU, or a custom metric) 

경보에 따라 인스턴스를 늘리거나 줄인다. 


82. Auto Scaling Group ( ASG 실습) 

오토 스케일링 그룹을 생성해보자! 

 

1. 기존의 인스턴스 삭제 

모두 종료 

 

2. ASG 생성하기 

DemoASG 로 

2-1 시작 템플릿 생성

 

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

 

2-2 인스턴스 시작 옵션 선택

가용 영역은 3개 선택

시작 탬플릿 재정의에 여러 옵션을 덮어쓰기 할 수 있으나 패스한다.

 

2-3 고급 옵션 구성

기존 로드밸런서에 연결한다.

이미 생성했던 DemoALB 에 연결한다 .

ELB 에서도 상태 확인을 한다. 

2-4 그룹 크기 및 크기 조정 정책 구성

 

asg의 크기를 정한다. 

 

2-5 생성완료

생성 완료 되었다. 

 

3. ASG 확인하기 

최소 를 1로 했기 때문에 인스턴스가 작동한다.

DemoASG 인스턴스가 생성되었다. 

asg 설정에서 ELB 를 선택했고 해당 ELB는 first-target-group 에 연결되어있고

해당 그룹은 DemoASG 인스턴스와 연결되어있다. 

alb에 접속할 수 있다. 

 

3-1 그룹 크기 변경해보자

2,2,4 로 변경했다..

인스턴스가 두개나 실행된다 .

 

인스턴스 2개에 접속한다. 

 

마지막으로 크기를 1,1,1 로 변경한다. 


83. Auto Scaling Groups - Dynamic Scaling Policies

동적 확장 정책의 종류

1. 대상 추적 스케일링

가장 쉽다.

기본 기준선을 세우고 상시 가용 가능하도록한다.

ex) asg 평균 cpu 사용률이 40% 가 유지되게 한다. 

 

2. 단순과 단계 스케일링

좀 복ㄱ잡하다 

CloudWatch 경보를 설정하고 다음과 가팅

전체 ASG 에 대한 CPU 사용률이 70%를 초고하는 경우 용량을 두 유닛 추가하도록 설정한다.

~~ 30% 이하로 떨어지면 유닛 하나를 제거한다. 

등의 설정을 할 수 있다.

 

단 CloudWatch 경보를 설정할 때에는 한 번에 추가할 유닛의 수와 한번에 제거할 유닛의 수를 단계별로 설정할 필요가 있다. 

 

3. 예약된 작업 reserved Scaling

나와 있는 사용 패턴을 바탕으로 스케일링을 예상하는 것.

예를 들어 금요일 오후 5시에 큰 이벤트가 예정되어 있으니 여러 사람들이 애플리케이션을 사용하는 데에 대비해 여러분의 ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10까지 늘린다. 

 

4. 예측 스케일링 Predictive Scaling

예측 스케일링을 통해서 AWS 내 오토 스케일링 서비스를 활용하여 지속적으로 예측을 생성할 수 있다. 

로드를 보고서 다음 스케일링을 예측한다. 

시간에 걸쳐 과거 로드를 분석하고 예측이 생성된다.

해당 예측을 기반으로 사전에 스케일링 작업이 예약된다. 

 

Good Metrics to scale one

지표로 삶기 좋은 항목 

1. CPU 사용량

2. 요청 회수

3. 네트워크 입출력 ( 네트워크 과부하)

4. cloudWatch 에서 별도 지표를 직접 설정

 

Auto Scaling Groups - Scaling Cooldowns

스케일링 휴지 (Scaling cooldown)

- 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적으로 5분 혹은 300초의 휴지 기간을 갖는다. 

 

휴지 기간에는 ASG가 추가 인스턴스를 추가 또는 종료할 수 없다.

 

이는 지표를 활용하여 새로운 인스턴스가 안정화될 수 있도록 하며 어떤 새로운 지표의 양상을 살펴보기 위함이다. 

 

따라서 스케일링 작업이 발생할 때에 기본으로 설정한 휴지가 있는지 확인해야한다. 

 

조언: 즉시 사용이 가능한 AMI 를 이용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다. 


84.  Auto Scaling Group (ASG) - 스케일링 정책 실습 

동적 크기 조정 정책만 실행할 것이다.

 

(예측 크기 조정 정책은 머신 러닝으로 1주일 이상 돌려야한다. )

 

동적 크기 조정 정책 생성

대상 추적 크기 조정, 단계 크기 조정, 단순 크기 조정이 있다. 

단계를 여러 조건을 단계 단계 지정할 수 있고

단순 크기 조정은 1개

여기서는 대상 추적 크기 조정만 할거다.

생성되었다. 

 

asg 크기를 1,1,3으로 변경

현재 하나만 인스턴스 실행중 

EC2 스트레스 테스트 하기 

인스턴스에 접속해서 해당 명령을 해보자

sudo amazon-linux-extras install epel -y
sudo yum install stress -y

다 설치해주자

stress -c 4 명령어를 하면 CPU 의 모든 코어를 100% 쓸 때까지 과부하를 준다 .

자세히 보면 점으로 CPU 사용률이 증가한 것을 볼 수 있다.

작업 기록을 보면 대상 추적 알람이 실행되고 capa 를 늘렸다 .

 

인스턴스를 종료 하거나 재부팅 하면 명령어가 초기화 되니까 cpu 사용률이 낮아진다. 


Quiz 5: 고가용성 & 확장성 퀴즈

 

1. EC2 인스턴스를r4.large에서 r4.4xlarge로 확장하는 것은 .....................(이)라고 합니다.

 

2. EC2 인스턴스의 수를 스케일링하는 오토 스케일링 그룹을 실행하는 것은 .....................(이)라고 합니다.

 

3. Elastic Load Balancer는 .......................(을)를 제공합니다.

AWS에서 관리하는 기반 인프라가 변경되었다고 하더라도, AWS가 정적 엔드 포인트를 사용해 로드 밸런스로 액세스할 수 있기를 원하는 이유입니다.

 

4. Elastic Load Balancer가 관리하는 10개의 EC2 인스턴스 상에서 웹사이트를 실행 중입니다. 웹사이트의 사용자들은 웹사이트에서 다른 페이지로 이동할 대마다 새로 인증을 해야한다는 점에 대해 불만을 토로하고 있습니다. 하지만 여러분의 기기와 하나의 EC2 인스턴스를 지닌 개발 환경에서는 아무 문제 없이 작동을 하고 있기 때문에 곤혹스러운 상황입니다. 무엇이 원인일까요?

ELB 고정 세션 기능은 동일한 클라이언트에 대한 트래픽이 항상 동일한 대상으로 리다이렉트되도록 해줍니다(예: EC2 인스턴스) 이는 클라이언트들이 세션 데이터를 소실하지 않게 해줍니다.

 

5. Application Load Balancer를 사용해 EC2 인스턴스에서 호스팅된 웹사이트의 트래픽을 분배하고 있습니다. 그런데 여러분의 웹사이트가 Application Load Balancer의 IP 주소인 사설 IPv4 주소에서 들어오는 트래픽만을 확인하고 있는 것으로 나타났습니다. 이런 경우, 웹사이트로 연결된 클라이언트들의 IP 주소를 받으려면 어떻게 해야 할까요?

 

Application Load Balancer를 사용하여 EC2 인스턴스에 트래픽을 배분하는 경우, 요청을 받게 되는 IP 주소는 ALB의 사설 IP 주소가 됩니다. 클라이언트의 IP 주소를 받기 위해, ALB는 클라이언트의 IP 주소를 포함하고 있는 X-Forwarded-For라는 헤더를 추가합니다.

6. Elastic Load Balancer가 관리하는 한 세트의 EC2 인스턴스 상에 애플리케이션을 호스팅했습니다. 일주일 후, 사용자들은 가끔씩 애플리케이션이 작동하지 않는다며 호소하기 시작했습니다. 문제점을 조사한 결과, 일부 EC2 인스턴스가 이따금 충돌한다는 문제점이 발견되었습니다. 사용자들이 충돌하는 EC2 인스턴스에 연결되지 않도록 보호하기 위해서는 어떻게 해야 할까요?

 

 

ELB 상태 확인을 활성화하면, ELB가 비정상(충돌) EC2 인스턴스로는 트래픽을 보내지 않게 됩니다.

 

7. 어떤 기업에서 솔루션 아키텍트로 근무하고 있는 여러분은 1초에 수백만 개의 요청을 받게 될 고성능의, 그리고 지연 시간이 적은 애플리케이션을 위한 아키텍처를 설계해달라는 요청을 받았습니다. 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요?

Network Load Balancer는 애플리케이션이 필요로 할 경우 가장 높은 성능과 가장 낮은 지연 시간을 제공합니다.

8. Application Load Balancer가 지원하지 않는 프로토콜을 고르세요.

 

9.Application Load Balancer는 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다. 이때 확인할 내용으로 사용할 수 없는 것을 고르세요

ALB는 URL 경로, 호스트 이름, HTTP 헤더 및 쿼리 문자열을 기반으로 트래픽을 다른 대상 그룹으로 라우팅할 수 있습니다.

10. Application Load Balancer의 대상 그룹에 등록된 대상이 될 수 없는 것을 고르세요.

 

11. 규정 준수를 위해, 고정된 정적 IP 주소를 최종 사용자에게 노출하여 사용자들이 안정적이고, 규제 기관의 승인을 받은 방화벽 규칙을 작성할 수 있도록 하려 합니다. 이런 경우, 다음 중 어떤 종류의 Elastic Load Balancer를 사용해야 할까요?

Network Load Balancer는 AZ 당 하나의 정적 IP 주소를 가지며, 여기에 탄력적 IP 주소를 연결할 수 있습니다. Application Load Balancer와 Classic Load Balancer를 정적 DNS 이름으로 사용할 수 있습니다.

 

12. Application Load Balancer 내에 사용자 지정 애플리케이션 기반 쿠키를 생성하려 합니다. 다음 중 쿠키의 이름으로 사용 가능한 것은 무엇인가요?

다음의 쿠키 이름은 ELB가 선점하고 있습니다(AWSALB, AWSALBAPP, AWSALBTG).

13. us-east-1에 있는 한 세트의 EC2 인스턴스에 트래픽을 배분하는 Network Load Balancer가 있습니다. us-east-1b AZ에 2개의 EC2 인스턴스, us-east-1e AZ에는 5개의 EC2 인스턴스가 있습니다. 여러분은 us-east-1b AZ에 있는 EC2 인스턴스의 CPU 사용률이 더 높다는 것을 발견했습니다. 조사를 거친 결과, 두 개의 AZ에 걸쳐 분배된 트래픽의 양은 동일한 것으로 나타났습니다. 이 경우, 어떻게 문제를 해결해야 할까요?

영역간 로드 밸런싱을 활성화하면, ELB가 모든 AZ에 있는 등록된 EC2 인스턴스 전체에 동등하게 분배됩니다.

 

14. 다음 중 하나의 리스너로 다수의 SSL 인증서를 가져올 수 있도록 해주는 Application Load Balancer와 Network Load Balancer의 기능은 무엇인가요?

 

15. 다음과 같은 호스트 이름을 기반으로, 트래픽을 3개의 대상 그룹으로 리다이렉팅하도록 구성된 Application Load Balancer가 있습니다: users.example.com, api.external.example.com, checkout.example.com. 이 각각의 호스트 이름에 HTTPS를 구성하려 합니다. 이런 작업을 위해서는 ALB를 어떻게 구성해야 할까요?

서버 이름 표식(SNI)을 사용하면 동일한 리스너 상에 있는, 자체 SSL 인증서를 가진 다수의 HTTPS 애플리케이션을 노출시킬 수 있습니다. 더 많은 정보는 여기를 참고하세요: https://aws.amazon.com/blogs/aws/new-application-load-balancer-sni/

 

Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI | Amazon Web Services

Today we’re launching support for multiple TLS/SSL certificates on Application Load Balancers (ALB) using Server Name Indication (SNI). You can now host multiple TLS secured applications, each with its own TLS certificate, behind a single load balancer.

aws.amazon.com

 

16. 원하는 용량과 최대 용량을 모두 3으로 구성한 오토 스케일링 그룹에 의해 관리되고 있는, 한 세트의 EC2 인스턴스에 호스팅된 애플리케이션이 있습니다. 또한, CPU 사용률이 60%에 이르면 ASG를 스케일 아웃하도록 구성된 CloudWatch 경보도 생성해 뒀습니다. 해당 애플리케이션은 현재 갑자기 많은 양의 트래픽을 전송 받아 80% CPU 사용률에서 실행되고 있는 상태입니다. 이런 경우, 무슨 일이 일어나게 될까요?

오토 스케일링 그룹은 스케일 아웃 시, (구성된) 최대 용량을 넘어설 수 없습니다.

17. Application Load Balancer가 관리하는 오토 스케일링 그룹이 있습니다. ASG가 ALB 상태 확인을 사용하도록 구성을 해둔 상태인데, EC2 인스턴스가 비정상인 것으로 보고되었습니다. EC2 인스턴스에는 무슨 일이 일어나게 될까요?

오토 스케일링 그룹이 EC2 상태 확인(기본 설정)이 아닌 Application Load Balancer의 상태 확인을 기반으로 EC2 인스턴스의 상태를 판단하도록 구성할 수 있습니다. EC2 인스턴스가 ALB의 상태 확인에 실패할 경우, 이는 비정상인 것으로 표시되어 종료되며 ASG는 새로운 EC2 인스턴스를 실행합니다.

 

18. 여러분의 상사가 애플리케이션이 데이터베이스로 보내는 분당 요청 수를 기반으로 오토 스케일링 그룹을 스케일링하라고 요청했습니다. 어떻게 해야 할까요?

 

백엔드-데이터베이스 연결에는 ‘분당 요청'에 해당하는 CloudWatch 지표가 존재하지 않습니다. CloudWatch 경보를 생성하려면 CloudWatch 사용자 지정 지표를 먼저 생성해야 합니다.

19. 오토 스케일링 그룹 (ASG)에서 관리하는 EC2 인스턴스 플릿이 호스팅하는 웹 애플리케이션이 있습니다. 여러분은 애플리케이션 로드 밸런서 (ALB)를 통해 이 애플리케이션을 노출하고 있습니다. EC2 인스턴스와 ALB는 모두 다음 CIDR 192.168.0.0/18을 사용하여 VPC에 배포됩니다. ALB만 포트 80에서 액세스할 수 있도록 EC2 인스턴스의 보안 그룹을 구성하려면 어떻게 해야 할까요?

ALB만이 EC2 인스턴스로 액세스할 수 있게 할 수 있는 가장 안전한 방법입니다. 규칙에서 보안 그룹을 참조하는 것은 매우 강력한 규칙으로, 이 내용을 바탕으로 많은 시험 문제가 출제됩니다. 그러니 이에 관련된 내용은 반드시 숙지하도록 하세요!

20. eu-west-2 리전에서 실행되는 오토 스케일링 구성이 있는데, 두 개의 가용 영역인 eu-west-2a  eu-west-2b 를 생성하도록 설정되어 있습니다. 현재 eu-west-2a에는 3개의 EC2 인스턴스가 실행 중이며, eu-west-2b에는 4개의 EC2 인스턴스가 실행 중입니다. ASG는 스케일 인을 하려 합니다. 이들 중 어떤 EC2 인스턴스가 종료되게 될까요?

 

오토 스케일링 그룹의 기본 종료 정책을 반드시 기억해두세요. 이 정책은 우선 AZ에 걸친 밸런싱을 시도하며, 실행 구성이 오래된 순으로 종료합니다.

 

실행 템플릿이 제일 오래된 순으로 종료한다! 

 

21. 애플리케이션은 Application Load Balancer와 오토 스케일링 그룹과 함께 배포됩니다. 현재 ASG를 수동으로 스케일링하고 있는 상태에서, EC2 인스턴스로의 평균 연결의 수를 1,000회 정도로 유지하기 위한 스케일링 정책을 정의하려 합니다. 이 중에서 어떤 스케일링 정책을 사용해야 할까요?

 

 

22. 오토 스케일링 그룹이 관리하는 EC2 인스턴스에 호스팅된 애플리케이션으로 들어오는 트래픽이 급격하게 증가하여, ASG가 스케일 아웃되고 새로운 EC2 인스턴스가 실행되게 되었습니다. 트래픽은 계속해서 증가하지만, ASG는 5분이 지나기 전까지는 새로운 EC2 인스턴스를 곧바로 실행하지 않습니다. 이런 경우, 가능성이 있는 원인은 무엇일까요?

 

오토 스케일링 그룹에는 각 스케일링 조치 이후 냉각 기간을 갖습니다. ASG는 냉각 기간 동안 EC2 인스턴스를 실행하거나 종료하지 않습니다. 이를 통해 지표들을 안정화시킬 수 있는 기간을 갖습니다. 냉각 기간의 기본 값은 300초(5분)입니다.

 

 

23. 지난 달, 어느 기업이 보유한 오토 스케일링 그룹 내의 무작위 EC2 인스턴스가 갑자기 충돌을 일으켰습니다. ASG가 비정상 EC2 인스턴스를 종료하고 이를 새로운 EC2 인스턴스로 대체하고 있는 관계로, EC2 인스턴스가 충돌하게 된 원인을 찾을 수 없는 상태입니다. 이 문제를 해결하고 ASG가 비정상 인스턴스를 종료하는 것을 막기 위해서는 어떤 문제 해결 조치를 취해야 할까요?

asg 수명 주기 후크? Amazon EC2 Auto Scaling 수명 주기 후크 - Amazon EC2 Auto Scaling

 

Amazon EC2 Auto Scaling 수명 주기 후크 - Amazon EC2 Auto Scaling

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

Amazon EC2 Auto Scaling은 오토 스케일링에 수명 주기 후크를 추가할 수 있는 기능을 제공합니다. 이러한 후크를 사용하면 Auto Scaling 인스턴스 수명 주기의 이벤트를 인식하는 솔루션을 생성한 다음 해당 수명 주기 이벤트가 발생할 때 인스턴스에 대한 사용자 정의 작업을 수행할 수 있습니다. 수명 주기 후크는 인스턴스가 다음 상태로 전환되기 전에 작업이 완료될 때까지 대기할 지정된 시간(기본적으로 1시간)을 제공합니다.

 

 


【한글자막】 AWS Certified Solutions Architect Professional | Udemy

2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 3: AWS 시작하기

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 4: IAM 및 AWS CLI

2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초

2023.01.10 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 6: EC2 - 솔루션스 아키텍트 어소시에이트 레벨


55. EBS 개요

EBS 볼륨이란? 

1. An EBS (Elastic Block Store) volume is a network drive you can attach to your instances while they run

인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브이다.

2. It allows your instances to persist data, even after their termination

인스턴스가 종료된 후에도 데이터를 보관한다

3. They can only be mounted to one instance at a time( at the CCP level)

한번에 하나의 인스턴스에만 마운트 될 수 있다.

4. They are bound to a specific availability zone 

한 az 에 종속되어져있다. 

5. 하나의 네트워크 USB 스틱이라고 생각하자

6. 프리티어 30GB 무료

 

특징

It's a network drive (i.e not a physical drive) 

네트워크 드라이브이다. ( 물리적으로 연결되는 것은 아니다.) 

네트워크로 상호작용하기 때문에 레이턴시가 존재한다. 

 

It's locked to an Availability Zone( AZ)

az에 종속되어 있기 때문에 인스턴스 연결할때 확인하자.

만약 볼륨을 옮기고 싶다면 스냅샷을 활용하자 

 

Have a provisioned capacity ( size in GBs, and IOPS)

미리 볼륨의 성능을 지정해야한다. 

물론 이후에 용량을 늘릴 수도 있다 .

 

EBS Volume - Example

EC2 에 하나 연결하거나

한 EC2에 EBS 여러개 연결해도 된다. 

EBS 가 꼭 인스턴스에 연결될 필요도 없다. 

 

EBS - Delete on Termination attribute

delete on termination 옵션이 있다. 

default 로 root ebs volume 은 인스턴스 종료시 삭제 옵션이 체크되어있다.

해당 옵션을 잘 사용하면된다. 

 

 


56. EBS 실습

EBS 볼륨 생성하기

인스턴스의 스토리지 탭에 볼륨에 대한 정보가 있다.

볼륨 페이지로 이동하게 된다. 

여기서 볼륨 생성을 할 수 있다. 

똑같은 가용영역으로 2GIB 짜리 볼륨을 하나 생성한다. 

볼륨을 인스턴스에 연결한다. 

 

해당 인스턴스를 종료해보자!

 

루트 볼륨이 삭제된다. 


57. EBS 스냅샷 개요

EBS Snapshots

 

특정 시점의 EBS 볼륨 백업을 만들 수 있다. 

강제 사항은 아니지만 웬만해선 사용하자

원래 EBS 볼륨은 같은 az에만 장착할 수 있다.

하지만 스냅샷을 옮기는 식으로 하면 다른 az의 인스턴스에 ebs를 연결할 수 있다.

 

EBS snapshot 기능

1. EBS snapshot Archive

최대 75% 까지 저렴한 아카이브 티어로 스냅샷을 옮길 수 있는 기능이다.

스냅샷을 아카이브 티어로 옮기면 아카이브를 복원하는 데 24시간에서 최대 72 시간이 걸린다. 

즉시 복원되지 않는다. 

 

2. Recycle Bin for EBS Snapshots

EBS 스냅샷을 삭제하는 경우 영구 삭제하는 대신에 휴지통에 넣을 수 있다. 

실수로 삭제하는 경우에 휴지통에서 복원할 수 있다. 

휴지통에 보관되는 기간은 1일에서 1년 사이로 설정할 수 있다.

 

3. Fast Snapshot Restore (FSR) 

빠른 스냅샷 복원이다.

스냅샷을 완전 초기화해 첫 사용에서의 지연 시간을 없애는 기능이다.

스냅샷이 아주 크고 EBS 볼륨 또는 EC2 인스턴스를 빠르게 초기화해야 할 때 특히 유용하다. 

하지만 비용이 많이 든다 .

 


58. EBS 스냅샷 실습 

스냅샷 생성하기 

지난 시간에 만든 EBS 볼륨

ebs 볼륨을 선택한 다음 스냅샷을 생성할 수 있다.

스냅샷을 만든다 .

생성된 스냅샷 확인

스냅샷 복사

 

방금 찍어낸 스냅샷을 다른 리전으로 복사할 수 있다. 

 

EBS 만들기 ( 다른 az로 )

용량 크기를 2gb 에 맞춰준다 .

 

ebs(az 1 ) -> snapshot -> ebs (az2) 

로 스냅샷을 이용하여 EBS의 데이터를 다른 az,리전에서도 똑같이 사용할 수 있다.

 


59. AMI 개요

AMI Overview 

Amazon Machine Image

customization of an EC2 instance

사용자 지정 EC2 인스턴스를 나타낸다.

 

소프트웨어 구성, 운영 체제 , 모니터링 등 

AMI 를 생성하면 부팅과 구성에 시간이 단축된다. 

 

AMI 를 통해서 사전에 패키징 된다. 

 

AMI를 자체적으로 구성하고 다른 리전에 복사해서 사용할 수 있다 

 

EC2 실행하기

public ami : amazon 에서 제공한다.

own AMI: 직접 생성한 AMI

An AWS Marketplace AMI: 다른 사람이 만든것 

 

AMI Process (from an EC2 Instance) 

ami 생성 과정

1.  EC2 생성 및 실행하기

2. 인스턴스 중지 ( 데이터 무결성을 위하여, for data integrity)

3. AMI 생성하기 ( EBS 스냅샷도 생성된다..)

4. 다른 EC2 인스턴스에서 ami 실행

 


60. AMI 실습

인스턴스 생성

#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

위의 사용자 데이터와 종료시 삭제 옵션을 예로하고 키페어 설정 80, 22  포트를 인바운드로 여는 sg 설정

 

처음에 인스턴스를 실행하고 바로 공용 ip 로 접속하면 안뜬다. 연결오류 + 부트스트랩 작업을 완료하지 않았기 때문에 

-> ami 를 이용하면 더 빠르다. (20~30 초 가량 소요되는 부트스트랩 타임이 사라진다.)

 

AMI 이미지 생성

인스턴스를 선택하고 이미지를 생성한다. 

이미지를 생성한다 .

 

AMI 로 인스턴스 생성 

방금 생성한 이미지를 이용하여 인스턴스를 생성한다.

#!/bin/bash
echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

(사용자데이터에서 )기존 ami 에서 업데이트를 했기 때문에 html 페이지 만드는 코드 한줄만 있으면 된다 .

 

바로 인덱스 페이지로 간다.

 


61. EC2 인스턴스 스토어 

EC2 Instance Store

EBS volumes are network drives with good but "limited" performance

EBS는 네트워크 드라이브이기 때문에 태생적으로 제한된 성능을 보인다. 

 

만약 높은 성능을 사용하고 싶다면 EC2 Instance Store를  사용해야한다. 

특징

뛰어나 입출력

중단되면 데이터가 사라진다. (ephemeral : 임시의)

버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠에 유리함

리스크 존재 

백업에 유의하자! 

입출력 성능에 따른 옵션이 존재한다.


62. EBS 볼륨 유형

6가지 EBS 볼륨 유형

gp2/ gp3  (ssd) : 다양한 워크로드에 대해 가격과 성능의 절충안

io 1 /io 2 (ssd) : 최고 성능, 미션 크리티컬이자 지연 시간이 낮고 대용량 워크로드 

st 1 (hdd) : 잦은 접근 처리량 많음 (저비용)

sc 1 (hdd) : 낮은 접근 처리량 많음( 저비용) 

 

EBS 볼륨은 크기, 처리량, iops 에 정의됨.

 

IOPS는 초당 I/O 작업 수

 

gp2/gp3, io1/io2 만이 부팅 볼륨으로 사용될 수 있다.

루트 OS 가 실행될 위치 

 

Genral Purpose SSD

가장 비용 효율적이다 .

시스템 부팅 볼륨에서 가상데스크톱, 개발, 테스트 환경에서 사용할 수 있다. 

 

크기는 1GB 에서 16TB 까지 다양하다. 

gp3:

Baseline of 3000 IOPS and throughput of 125 MiB/s

Can increase IOPS up to 16,000 and throught up to 1000MiB/s independently (연결되어있지 않음)

gp2:

최대 3,000IOPS

처리량과 볼륨이 연결되면 최대 IOPS는 16,000

3 IOPS per GB |  5,334 GB we are at the max IOPS 

1기가당 3IOPS 이므로  최대 5,334GB 이다. 

 

Provisioned IOPS (PIOPS) SSD 

높은 IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션

16,000IOPS 이상을 요하는 애플리케이션에 적합.

 

일반적인 데이터베이스 워크로드에 알맞다. 

 

io 1/2 4GiB ~ 16 TiB

nitro EC2 인스턴스에 경우 최대 64,000 iops 까지 가능 

아니면 최대 32,000 IOPS 까지 지원

Can increase PIOPS independently from storage size 

또한 io1/io2를 이용하면 gp3 볼륨처럼 프로비저닝된 IOPS를

스토리지 크기와 독자적으로 증가시킬 수 있습니다.

io2 이용 장점은 io1 과 동일한 비용으로 내구성과 기가 당 IOPS 의 수가 더 높다. 

 

io2 Block Express ( 4GiB ~ 64 TiB)

좀더 고성능이다.

지연 시간이 밀리 초이다. 

MAX PIOPS: 256,000 with an IOPS:GIB ratio of 1,000:1

 

EBS 다중 연결 지원

 

Hard Disk Drives (HDD)

부팅 볼륨이 될 수 없다. 

125 MiB to 16 TiB

 

st1 

처리량 최적화 HDD 

빅 데이터나 데이터 웨어 하우징 로그 처리에 적합함.

최대 처리량은 초당 500MB 그리고 최대 IOPS는 500

 

sc1

아카이브 데이터용으로 접근 빈도가 낮은 데이터에 적합

최저 비용으로 데이터를 저장할 때에 사용

최처리량은 초당 250MB

최대 IOPS 도 250 

 


63. EBS 다중 연결

한 EBS를 최대 16개의 인스턴스에 연결 할 수 있다.

물론 같은 AZ 여야한다

 

각각의 인스턴스는 고성능 볼륨에 대한 읽기 및 쓰기 권한을 전부 갖는다.

동시에 읽고 쓸 수 있다는 뜻이다. 

 

애플리케이션 가용성을 높이기 위해 Teradata 처럼 클러스터링된 Linux 애플리케이션에서 사용하거나 애플리케이션이

동시 쓰기 작업을 관리해야 할 때 사용한다. 

 

다중 연결을 실행할려면 반드시 클러스터 인식 파일 시스템을 이용해야한다.

(Not XFS, EX4  와 같은 파일 시스템과 다르다. ) 

 


64. EBS 암호화

암호화된 EBS 볼륨을 만들때 :

1. 저장 데이터가 볼륨 내부에 암호화되고

2. 인스턴스와 볼륨 간에 데이터 전송시에도 암호화

3. 스냅샷 생성시 암호화

4. 스냅샷으로 볼륨 생성시에도 암호화 


암호화가 동시다발적으로 일어난다. 

 

암호화 및 복호화 매커니즘은 보이지 않게 처리된다. (아무것도 안해도 된다.) 

 

지연시간에 거의 영향 없음.

 

KMS 에서 암호화 키를 생성해 AES-256 암호화 표준을 갖춘다.

 

암호화된 스냅샷으로부터 볼륨을 만들면 볼륨도 암호화가 되어있다. 

 

EBS 볼륨을 암호화하거나 푸는 법

1. EBS 스냅샷 생성

2. 스냅샷 복제시 암호화 기능 사용

3. 복제된 스냅샷으로부터 ebs 볼륨 생성 ( 마찬가지로 암호화됨)

4. 암호화된 볼륨을 인스턴스에 연결할 수 있다. 

 

EBS  암호화 실습

1. 암호화되지 않은 EBS 생성

암호화 하지 않은 볼륨을 생성한다. 

 

암호화되지 않음.

2. 암호화되지 않은 스냅샷 생성

3. 스냅샷으로부터 복사 ( 암호화 ok)

위에서 만든 스냅샷으로부터 복사한다. 

암호화 옵션 체크 

kms 키 도 체크 

4. 암호화된 스냅샷으로부터 볼륨 생성

암호화된 스냅샷으로부터 볼륨을 생성하니 암호화 옵션이 자동으로 켜져있다.

생성된 볼륨은 암호화 되어있다.

스냅샷으로부터 바로 암호화된 볼륨 생성하기

암호화되지 않은 스냅샷으로부터 볼륨을 생성할때 

암호화 옵션을 키면 시간이 단축된다. 

 


65. Amazon EFS - Elastic File System

EFS 개념

EFS는 관리형 NFS 네트워크 파일 시스템이다. 

EC2 에 마운트 될 수 있다.

여러 가용 영역에 있을 수 있다.

가용성이 높고 확장성도 높다. 

가격도 비싸다. gp2 EBS 볼륨의 3배정도이다. 

사용량만큼 지불하므로 미리 용량을 프로비저닝 하지 않아도 된다. 

보안그룹이 EFS를 둘러싼다.

여러 가용영역이 존재하는데 EFS를 통해 같은 네트워크 파일 시스템에 동시에 연결할 수 있다.

 

EFS 특징

사용처 : 콘텐츠 관리, 웹 서버, 데이터 공유 WordPress

NFSv4.1 프로토콜 이용

EFS에 대한 액세스를 제어하기 위해서는 보안 그룹을 설정해야한다. 

 

리눅스 기반이다. (windows 불가)

KMS 로 암호화 되며

 

POSIX 시스템을 사용한다(리눅스 표준) 파일 api를 가진다. 

 

미리 용량을 계획하지 않아도 된다. 자동으로 확장되고 사용량에 따라 요금을 지불한다.

EFS 에서 사용한 GB당 데이터 비용을 지불한다. 

 

EFS 성능과 스토리지 클래스

EFS Scale 

  • 수천 개의 NFS 클라이언트에서 EFS 에 동시 액세스할 수 있게 확장되며 처리량은 초당 10GB
  • 용량을 미리 프로비저닝하지 않아도 네트워크 파일 시스템이 PB 규모로 확장된다. 

다양한 성능 모드

  • 범용모드: 지연 시간에 민감한 웹 서버 ,CMS 와 같은 사용 사례
  • 최대 I/O : 지연 시간, 처리량 병렬 처리 성능이 향상됨( 빅데이터, 미디어 작업)

처리량 모드 throughout mode

  •  버스팅 모드: 사용 공간이 많을수록 버스팅 용량과 처리량이 늘어난다. ( 1 TB = 50MiB/s + burst of up to 100MiB/s)
  • 프로비저닝 모드에서는 스토리지 상관없이 처리량을 설정(고정)할 수 있음.ex: 1GiB/s for 1 TB 스토리지 

EFS - Storage Classes 

Storage Tiers  

일정 기간 후에 파일을 다른 계층으로 옮기는 기능 

액세스가 비번한 파일은 standard 계층에 저장한다. 

 

EFS-IA 계층을 사용하면 파일을 검색할 경우 검색에 대한 비용이 발생한다.

하지만 파일을 저장하는 비용이 낮다. 

 

EFS-IA 를 활성화하려면 수명 주기 정책을 사용해야한다. 

예를 들면 standard 계층에서 60일 이상 액세스 하지 않은 파일이 있다면 

EFS-IA 로 옮겨진다. 비용이 낮아짐. 

 

가용성 및 내구성 옵션

standard: 다중 az 지원, 프로덕션에 좋음

one zone: 하나의 az, 개발, 백업용으로 좋음.  EFS - IA 스토리지 계층과 호환

최대 90%의 비용 절감  가능 

 


66. Amazon EFS 실습

1. EFS 생성

사용자 지정으로 EFS를 생성해보자 !

스토리지 클래스에서 스탠다드는 multi az , one zone 은 단일 az 

IA로 전환에서 주기를 설정할 수 있다.

성능 설정에 처리량 모드 

성능 모드를 지정할 수 있다.

네트워크 액세스 설정 -> 보안 그룹 미리 만들기  

보안 그룹을 하나 미리 만들자.

 

그리고 그냥 생성한다.

 

2. 인스턴스 생성 & 연결

서브넷을 고르고

스토리지에서 파일 볼륨을 추가한다.

 

다른 이름으로 하나 더 생성한다. 

가용영역만 다르게 

 

 

3. 확인

efs 콘솔 네트워크에 보면 efs가 보안그룹을 자동으로 생성한 것을 볼 수 있다.

 

새로 만들어진 보안그룹은 해당 인스턴스의 보안그룹을 소스로 한다. ( 연결된 인스턴스에서는 EFS 접속할 수 있다.) 

 

인스턴스 a

파일을 생성하고 

 

인스턴스 b

확인된다. 

 


67. EBS 와 EFS 비교

EBS

한번에 하나의 인스턴스와 연결

단일 az 

gp2:  디스크 사이즈가 증가하면 IO 가 증가. 

io1: IO 가 독립적으로 증가 

 

다른 az 로 옮길려면....? 

스냅샷을 뜨고 다른 az 로 복사 

스냅샷이나 백업을 뜰때는 ebs 볼륨 내의 IO를 전부 사용하게 되니 인스턴스가 EBS를 사용 중이 아닐 때에만 실행

 

인스턴스가 종료될시 루트 볼륨이 삭제되는 옵션도 있음. 

 

EFS

무수히 많은 인스턴스와 연결 가능 

다중 az 지원 

EFS Mount Target을 사용해 특정 AZ 에서 EC2 인스턴스들과 EFS 드라이브를 연결

워드 프레스 같은 웹 사이트 파일을 공유할 때 사용 

오직 리눅스 파일 시스템 을 지원 

EBS 보다 비쌈 

EFS -IA 로 비용 절감 가능 

EBS, EFS , 인스턴스 스토어는 같이 외워라! 

 


68. EBS 및 EFS - 섹션 정리

efs

인스턴스

보안그룹

ebs 

스냅샷 

 

다 삭제해주자 

 


Quiz 4 : EC2 데이터 관리 퀴즈

1. us-east-1a에서의 EC2 인스턴스를 종료하여, 이 인스턴스에 연결된 EBS 볼륨을 사용할 수 있게 되었습니다. 팀원이 us-east-1b의 EC2 인스턴스에 이 볼륨을 연결하려 했으나, 연결이 불가능한 상태입니다. 이 경우, 가능성이 있는 원인은 무엇일까요?

EBS 볼륨은 특정 AZ에 맞춰 생성됩니다. EBS 스냅샷을 활용하면 다른 AZ 간의 이전이 가능합니다.

 

2. 루트 볼륨 유형과 데이터 저장을 위한 기타 EBS 볼륨 유형, 두 개의 EBS 볼륨으로 EC2 인스턴스를 실행했습니다. EC2 인스턴스는 한 달 후에 종료할 예정입니다. 각 EBS 볼륨에 기본적으로 나타날 행위 특성은 무엇일까요?

루트 볼륨의 경우, ‘종료 시 삭제' 속성이 기본으로 활성화되어 있기 때문에, 기본적으로 삭제되게 됩니다. 기타 EBS 볼륨 유형의 경우, ‘종료 시 삭제' 속성이 기본적으로 비활성화되어 있으므로 삭제되지 않습니다. 

 

루트 볼륨은 종료 시 삭제가 기본!!!

3. 노스버지니아 리전 us-east-1에서 AMI를 사용하면 어떤 AWS 리전에 있는 EC2 인스턴스라도 실행할 수 있습니다

 

AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있습니다. 다른 AWS 리전에서 AMI를 사용해 EC2 인스턴스를 실행하는 것은 불가능하지만, 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 생성하는 것은 가능합니다.

 

ami는 특정 aws 리전에 종속. 사용할려면 복사해서 사용!

 

4. 다음 중, EC2 인스턴스를 생성할 때 부팅 볼륨으로 사용할 수 있는 EBS 볼륨 유형은 무엇인가요?

EC2 인스턴스를 생성할 때, 부팅 볼륨으로는 다음의 EBS 볼륨 유형만을 사용할 수 있습니다: gp2, gp3, io1, io2, Magnetic(표준)

 

5. EBS 다중 연결이란 무엇일까요?

EBS 다중 연결을 사용하면, 동일한 EBS 볼륨을 동일 AZ 상에 있는 다수의 EC2 인스턴스에 연결할 수 있습니다. 각 EC2 인스턴스는 완전한 읽기/쓰기 권한을 갖게 됩니다.

 

6. EC2 인스턴스에 연결되어 있는, 암호화되지 않은 EBS 볼륨을 암호화하려 합니다. 어떻게 해야 할까요?

7. 대량의 데이터 세트를 처리하는, 다수의 AZ에 걸친 EC2 인스턴스 플릿이 있습니다. 동일한 데이터가 NFS 드라이브로서 모든 EC2 인스턴스에서 액세스할 수 있게 만들기 위해서는 어떤 방법을 추천할 수 있을까요?

 

EFS는 네트워크 파일 시스템(NFS)으로 여러 AZ 상에 있는 EC2 인스턴스에 동일한 파일 시스템을 마운트할 수 있게 해줍니다.

8. EC2 인스턴스에 호스팅된 애플리케이션에 고성능 로컬 캐시를 포함시키려 합니다. EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황입니다. 이런 경우, 솔루션 아키텍트로서 어떤 스토리지 메커니즘을 추천할 수 있을까요?

EC2 인스턴스 스토어는 최적의 디스크 I/O 성능을 제공합니다.

 

9. 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있습니다. 어떤 방법을 추천할 수 있을까요?

(EBS io1/2 최대 25,600 IOPS)

EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실이라는 문제가 있습니다 (문제 없이 다시 시작할 수 있음). 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있다는 것입니다. 또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있습니다. 이 사용 사례에서는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 합니다.

 

【한글자막】 AWS Certified Solutions Architect Professional | Udemy

2023.01.06 - [DevOps/aws] - Udemy | AWS Certified Solutions Architect Associate 강의 | Section1~2

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 3: AWS 시작하기

2023.01.06 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 4: IAM 및 AWS CLI

2023.01.09 - [DevOps/aws] - AWS Certified Solutions Architect Associate 강의 Udemy | Section 5: EC2 기초


46. 프라이빗 vs 퍼블릭 vs 탄력적 IP

Private vs Public IP ( IPv4) 

 

IPv4 : 32비트 

IPv6 : 128 비트

 

IPv4는 여전히 가장 인기있는 포멧이다. 

IPv6는 주로 IoT 에 사용된다. 

 

IPv4는 37 억개의 서로 다른 주소를 제공한다. 

[0-255].[0-255].[0-255].[0-255]

 

Private vs Public IP (IPv4) Example 

 

퍼블릭 IP를 가지는 서버는 서로 통신할 수 있다. 

사설 네트워크에는 기본적으로 사설 IP 범위가 있는데 사설 IP는 매우 구체적으로 정의되지만

사설 네트워크 내의 모든 컴퓨터가 사설 IP를 사용하여 서로 통신할 수 있음을 의미한다. 

 

Fundamental Differences

Public IP:

  • internet에서 유니크한 값이다. 
  • 지리적 위치를 쉽게 찾을 수 있다.

Private IP:

  • 사설 네트워크 안에서만 식별된다. 안에서만 고유한 값을 갖는다.
  • 별개의 사설 네트워크들이 같은 IP 를 가져도 된다. 
  • 기기가 사설 네트워크에 있을때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결된다.
  • 지정된 범위의 IP 만 사설 IP로 사용될 수 있다. 

Elastic IPs

Ec2 인스턴스 켤때마다 public ip 가 초기화된다. 

 

EIP 는 공용 IPv4 로서 삭제하지 않는 한 계속 가지고 있게 된다.

한번에 한 인스턴스에만 첨부가능하다. 

 

사용을 지양한다..

 

임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋다. 

 

로드 밸런서를 사용해서 공용 IP를 전혀 사용하지 않게 할 수도 있다. 

 

우리가 EC2 에 접근할때 사설 IP를 사용할 수 없다. -> 같은 VPN을 쓰지 않기 때문이다. 

 


47. 프라이빗 vs 퍼블릭 vs 탄력적 IP 실습 

인스턴스 껐다 키면 IPv4 변경되었다. 

 

탄력적 IP 생성하고 연결하는 작업

 

탄력적 EIP 는 사용하지 않으면 요금을 내야한다. 

 

마지막에 eip release 하자 .

 


48. EC2 배치 그룹

Placement Groups

Sometimes you want control over the EC2 Instance placement strategy

EC2 인스턴스가 AWS 인프라에 배치되는 방식을 제어하고자 할때 쓴다. 

 

배치그룹을 사용하기 위해서 전략을 사용한다 

 

when you create a placement group, you specify one of the following strategies for the group:

배치 전략으로 다음과 같이 사용할 수 있다. 

 

Cluster

동일한 az 에 배치하기 때문에 로우 레이턴시를 가지지만 리스크하다.

장점: 뛰어난 네트워크 ( 10Gbps bandwitdh between instances) 

단점: 랙에 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다. 

사용처: 빠르게 수행되어야하는 빅데이터 작업

로우 레이턴시를 가져야하는 경우 

 

spread - 분산

분산해서 인스턴스를 배치한다. 

장점: 여러 Az 에 걸쳐 있다.

실패위험이 적다.

단점: 배치 그룹당 최대 7개의 인스턴스로 개수의 제한이 있다. 

사용처: 가용성을 극대화하고 위험을 줄여야 하는 애플리케이션,

인스턴스 오류를 서로 격리해야하는 크리티컬 애플리케이션

 

가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다 

partition - 분할

여러 파티션에 인스턴스를 분할한다. 

다양한 하드웨어 랙 세트에 의존한다.

인스턴스는 분산되어 있지만 다른 실패로부터 격리되지 않았다.

다양한 az 에 걸쳐있을 수 있다. 

한 az에 최대 7개의 파티션을 이용 가능하다. 

설정으로 최대 100개의 인스턴스를 이용 가능하다. 

파티션은 분리되어있다.

메타데이터 서비스를 이용하여 인스턴스가 어떤 파티션을 갖는지 확인할 수 있다.

 

hadoop, cassandra, Kafka 같은 애플리케이션을 실행할 수 있다. 

 


 

49. EC2 배치 그룹 - 실습

EC2 -> 네트워크 및 보안 -> 배치 그룹
배치 그룹 생성

옵션도 클러스터, 분산, 파티션이 존재한다.

 

배치그룹을 생성했다면 

ec2 인스턴스를 만들때 고급 옵션에서 배치 그룹을 선택할 수 있다. 


50. ENI( 탄력적 네트워크 인터페이스 ) - 개요 

VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타낸다. 

 

ENI는 EC2 인스턴스가 네트워크에 엑세스 할 수 있게 해준다. 

ENI 는 주요 사설 IPv4 와 하나 이상의 보조 IPv4 를 가질 수 있다.

 

가용영역에 EC2 인스턴스가 있다고 가정하자

기본 ENI 인 Eth0 에 연결되어 EC2 인스턴스 네트워크 연결을 제공한다. 

 

ENI는 특정 az 에 바인딩 된다. 

 

ENI 를 독립적으로 생성하거나 이동시킬 수 있다. 

 

 

 

 


51. ENI ( 탄력적 네트워크 인터페이스 ) - 실습

 

 

 

인스턴스를 만들면 ENI 가 자동으로 생성된다.

네트워크 인터페이스 탭에서 따로 확인할 수 있다. 

 

네트워크 인터페이스 생성을 통해서 eni를 생성할 수 있고

eni를 인스턴스에 연결할 수 있다. 

 

eni의 연결을 변경함으로써 쉽게 트래픽을 통제할 수 있다. 


 

52. ENI - 추가 읽기 자료

ENI 관련 안내 사항

아직 ENI에 대한 내용이 명확히 이해되지 않는 분이 계실 수도 있습니다.

걱정하지 마세요. 이 내용은 AWS에서도 심화 개념으로 숙달하는 데 시간이 걸릴 수 있어요.

ENI에 대해 더 배우고 싶다면, 이 블로그 글을 읽는 게 도움이 될 거예요. https://aws.amazon.com/blogs/aws/new-elastic-network-interfaces-in-the-virtual-private-cloud/

 

도움이 되기를 바랍니다. 여전히 이해가 안 되더라도 너무 걱정하지 마세요. 강의를 진행하는 데 아무런 문제가 없을 거예요. 계속해서 강의를 시청하고, 강의가 마무리될 때쯤에 다시 시청해보세요.

즐공하세요!


53. EC2 Hibernate 모드 

EC2 Hibernate

인스턴스가 stop, terminate 되었을때

Stop - the data on disk (EBS) is kept intact in the next start

정지 되면 EBS 디스크에 데이터가 보관된다. 

Terminate - any EBS volumes (root) also set-up to be destroyed is lost 

인스턴스를 종료했을때 루트 볼륨이 삭제되게 했다면 인스턴스도 삭제된다. 

 

On start, the following happens: 

first start: the OS boots & the EC2 User Data script is run

OS 가 부팅 되고 사용자 데이터 스크립트가 실행된다. 

Following starts: the OS boots up

OS 가 부트 업된다. (부팅완료된다)

Then your application starts, caches get warmed up, and tha can take time! 

애플리케이션이 실행되고 캐시도 구성되기 시작하므로 과정이 끝날 때까지 시간이 다소 걸린다. 

 

=> 인스턴스를 단순 정지, 실행 하면 시간이 걸린다. 

 

Introuducing EC2 Hibernate:

  • The in-memory (RAM) state is preserved
  • The instance boot is much faster!( the OS is not stopped / restarted)
  • Under the hood: the RAM state is written to a file in the root EBS Volume
  • The root EBS volume must be encrypted

인스턴스가 절전 모드가 되면 RAM 에 있던 인 메모리 상태는 그대로 보존된다.

-> 인스턴스 부팅이 더 빨라진다. (운영체제를 완전히 종료하지 않고 잠시 중단 했으니까!)

절전 모드가 되고 백그라운드에서 RAM에 기록되었던 인 메모리 상태는 루트 경로의 EBS 볼륨에 기록되기 때문에 루트 EBS 볼륨을  1. 암호화해야하고 2. 볼륨 용량도 RAM 을 저장하기에 충분해야한다. 

1. 실행중 

인스턴스가 있다고 가정하자.

인스턴스 RAM에 데이터가 있다.

 

2. 중지중 ( 절전)

인스턴스 RAM 의 내용을 EBS 볼륨에 덤프한다. 

3. 중지완료(절전)

인스턴스를 중지하면 인스턴스가 사라지지만 EBS 볼륨은 남아있다.

 

4.실행중

인스턴스를 다시 실행하면 EBS 디스크에서 RAM을 불러와 EC2 인스턴스 메모리로 가져간다.

 

이렇게 하면 EC2 인스턴스를 중지한 적이 없는 것처럼 된다.

 

Use case

오래 실행되는 프로세스를 갖고 있고 중지하지 않을 때

RAM 상태를 저장하고 싶을 때

빠르게 재부팅을 하고 싶을 때

서비스 최기화가 시간을 많이 잡아먹어 서비스가 중단 없이 인스턴스를 절전 모드로 전환하고 싶을 때

 

EC2 Hibernate - Good to know 

지원하는 인스턴스 패밀리

인스턴스 RAM Size - 인스턴스 RAM 사이즈는 150GB 보다 작다.

인스턴스 사이즈 - bare metal instances 에는 지원하지 않는다.

베어메탈은 가상화를 위한 하이퍼 바이저os 가 없다.

 AMI- 특정 ami 만 지원

RootVolume - EBS를 사용해야하며, 암호화되어야한다. 인스턴스 스토어에는 안된다. 

온디맨드, 예약, 스팟 등의 인스턴스에서도 절전 가능하다.

 

60일을 초과해서 절전할 수 없다.


54. EC2 Hibernate 실습 

EC2 생성

인스턴스를 시작하자 ( 이전과 동일함) 

최대 절전 중지 방식을 활성화한다.

RAM 보다 EBS 볼륨이 커야한다고 한다.

t2 micro 는 1GIB

ebs 볼륨의 암호화 옵션과 KMS 옵션을 켠다 . 크기 8GIB 로 충분하다. 

 

절전 확인해보기

uptime 명령어로 얼만큼 인스턴스가 켜졌는지 확인하다. 

1:12분 정도 켜졌다. 

최대 절전 후 다시 실행

uptime 하면 시간이 이어진다 .

 

이번에 인스턴스를 중지하고 다시 켜보자

 

uptime 이 초기화된다. 

 

최대절전모드에 대해 실습해보았다! 


EC2 SAA 레벨 퀴즈

1. NodeJS 애플리케이션을 호스트하게 될 EC2 인스턴스를 실행했습니다. 모든 필수 소프트웨어를 설치하고 애플리케이션을 구성한 후, 액세스를 위해 EC2 인스턴스 공용 IPv4를 기록해 두었습니다. 그 다음, 실행을 중단하고 애플리케이션 구성을 완료하기 위해 EC2 인스턴스를 다시 시작했습니다. 그러나 재시작 후, EC2 인스턴스에 액세스할 수 없었으며 EC2 인스턴스 공용 IPv4가 변경된 것을 알게 되었습니다. 이 경우, EC2 인스턴스에 고정적인 공용 IPv4를 할당하려면 어떻게 해야 할까요?

탄력적 IP는 여러분이 원하는 기간만큼 소유할 수 있는 공용 IPv4로, 한 번에 하나의 EC2 인스턴스에만 연결할 수 있습니다.

 

2. 스팟 플릿은 한 세트의 스팟 인스턴스로, 선택적 ..............입니다.

스팟 플릿은 한 세트의 스팟 인스턴스로, 선택적 온디맨드 인스턴스입니다. 이를 사용하면 가장 낮은 가격의 스팟 인스턴스를 자동으로 요청할 수 있습니다.

 

3. EC2 인스턴스 플릿에서 대규모의 데이터 분석을 수행하는 애플리케이션이 있습니다. 여러분은 EC2 인스턴스들이 서로 소통하면서도 가장 높은 수준의 네트워킹 성능을 유지했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요?

클러스터 배치 그룹을 사용하면 EC2 인스턴스들이 나란히 위치하게 되어 고성능의 컴퓨팅 및 네크워킹 성능을 제공하게 됩니다.

 

4. EC2 인스턴스 플릿에 호스팅된 중요 애플리케이션이 있습니다. 이 애플리케이션에서 AZ 실패가 일어난 경우, 최대 가용성을 달성했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요?

분산 배치를 통해서 가용성을 높인다. 

 

5. 탄력적 네트워크 인터페이스(ENI)는 다른 AZ에 있는 EC2 인스턴스와 연결될 수 있습니다.

탄력적 네트워크 인터페이스(ENIs)는 특정 AZ로 국한됩니다. 다른 AZ에 있는 EC2 인스턴스에 ENI를 연결할 수는 없습니다.

 

6. EC2 절전 모드와 관련된 내용 중, 옳지 않은 설명을 고르세요.

 

EC2 절전 모드를 활성화하기 위해서는 EC2 인스턴스 루트 볼륨 유형이 EBS 볼륨이어야만 하며, 민감한 내용을 보호할 수 있도록 암호화되어야 합니다.

+ Recent posts