공부하기싫어
article thumbnail

#AWS Certified Developer Associate

 

 

 

57. 고가용성 및 확장성 (High Avilabilty & Scalability for EC2)

확장성과 고가용성은 연관된 개념이지만 서로 다름

 

수직 확장성 - 인스턴스의 크기를 확장하는 것을 의미함

수평 확장성(탄력성-Elasticity) - 애플리케이션에서 인스턴스나 시스템의 수를 늘리는 것을 의미함

 

고가용성(High Avilabilty)

- 고가용성의 목표는 데이터센터에서의 손실에서 살아남는 것

- 둘 이상의 시스템으로 구성

- 하나의 센터가 멈춰도 계속 작동이 가능하게끔 하는 것

 

ec2에서 스케일 아웃(scale out) 은 인스턴스 수를 늘리는 것을 의미

스케일 인(scale in)은 인스턴스 수를 줄이는 것을 의미

 

 

58. 일래스틱 로드 밸런싱(ELB) 개요

로드 밸런싱

- 서버 혹은 서버셋이로,  트래픽을 백엔드나 다운스트림 EC2 인스턴스 또는 서버들로 전달하는 역할을 함

- 트래픽 부하를 다수의 다운스트림 인스턴스로 분산하기 위해 사용

- ELB 권장 (자체 로드밸런서 개발보다 저렴) (다수의 AWS 서비스들과 통합되어있음)

- ELB 는 4가지 버전이 있는데 되도록이면 최근에 나온 버전을 사용하는 것이 좋다

- 보안그룹은 ELB 에 설정하며 EC2는 ELB의 보안그룹을 상속받는것이 일반적이다.

 

 

59. Classic Load Balncer (CLB)

TCP (layer 4) , HTTP & HTTPS (layer 7)

 

 

60. 실습이 포함된 Classic Load Balncer (CLB)

옛날버전은 걍 강의만 보고 넘어감

 

 

61. Application Load Balaner (ALB)

layer 7  전용 로드 밸런서 - HTTP

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

다수 머신은 대상 그룹(Target groups)이라는 그룹으로 묶이게 됨

HTTP/2 와 WebSocket 지원

서로 다른 타겟그룹에 라우팅 가능

- url 경로에 따른 라우팅 (example.com/user & example.com/posts)

- url 호스트이름에 따른 라우팅 (one.example.com & other.example.com)

- 쿼리 혹은 헤더에 다른 라우팅 (example.com/users?id=123&other=false)

Docker 와 Amazon EC2 에 가장 적합한 로드 밸런서

ALB는 다수의 대상 그룹에 라우트 할 수 있다.

 ALB 의 상태 확인은 대상 그룹(target groups)레벨에서 이루어진다.

 

 

 

62. Application Load Balaner (ALB) 실습

ELB type

로드밸런서 생성을 누르면 이렇게 설명도 나와있다.

 

basic configuration

이름은 demoALB

internet-facing 이 퍼블릭 internal 이 프라이빗이라고 나와있는데 웹서비스를 구현할 꺼니까 위에껄로 하고

ipv4 로 선택해줬다

 

network mapping

vpc 는 하나밖에없어서 선택해줬고 매핑은 내 생성한 인스턴스 가용영역을 똑같이 선택해줬다 (2개)

 

target groups 생성

target groups을 만들어서 적용해주려고 한다

대상 그룹에는 인스턴스, ip, lambda funciton, alb 등을 정의할 수 있는것 같다.

 

고급 상태 확인 설정 페이지

healthy threshold(정상 임계값) 는 3번 체크해서 정상이면 정상값을 반환

unhealthy threshold(비정상 임계값) 은 2번 연속 비정상이면 연결불가 반환

timeout 은 4초

interval 초 마다 모든 등록 대상에 상태 확인 요청을 전송함

 

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/target-group-health-checks.html

 

대상 그룹에 대한 상태 확인 - Elastic Load Balancing

대상 그룹에 대한 상태 확인 Application Load Balancer는 등록된 대상으로 요청을 주기적으로 전송하여 상태를 확인합니다. 이러한 테스트를 바로 상태 확인이라고 합니다. 각각의 교차 영역 노드는

docs.aws.amazon.com

상태 확인 설정

다음 표에 설명된 대로 대상 그룹의 대상에 대한 상태 확인을 구성합니다. 테이블에 사용되는 설정 이름은 API에 사용되는 이름입니다. 로드 밸런서는 지정된 포트, 프로토콜 및 ping 경로를 사용하여 HealthCheckIntervalSeconds 초마다 모든 등록 대상에 상태 확인 요청을 전송합니다. 각 상태 확인 요청은 독립적이며 결과는 전체 간격 동안 지속됩니다. 대상이 응답하는 데 걸리는 시간은 다음 상태 확인 요청의 간격에 영향을 미치지 않습니다. 상태 확인이 UnhealthyThresholdCount 연속 실패를 초과하면 로드 밸런서는 대상을 서비스에서 제외합니다. 상태 확인이 HealthyThresholdCount 연속 성공을 초과하면 로드 밸런서는 대상을 다시 서비스합니다

 

타겟 그룹 추가

만든 타겟 그룹을 추가해줌

3개 인스턴스 중 2개만 추가함

 

summary

요약 확인 후 로드밸런서 만들어주고 프리비저닝 기다림

 

작동 확인

같은 주소로 접근해도 로드밸런서가 트래픽을 분배해주는 모습

 

second target group

두번째 타겟 그룹을 만듬

아까 선택한 2개 말고 다른 하나를 선택해서 넣어줬음

 

리스너 규칙 추가

새로 만든 타겟 그룹을 추가하기 위해 리스너 규칙을 추가해줌

규칙+1
규칙+2

if 경로가 /test 로 들어오면 second-target-group 인스턴스로 연결하도록 하고

if 경로가/constant 로 들어오면 return fixed response 로 404 를 반환하도록 하고 저장했다

 

작동 확인

/constant 경로로 들어온 브라우저에서는 constant error response 를 보여주고

/test 경로로 들어온 브라우저는 not found 인데 이것은 인스턴스에서 /test 유형의 쿼리에 응답하도록 설정하지 않았기 때문임 여튼 second-target-group 으로 접근한다는거

 

(07.12 끝)

 

(07.16 시작)

 

63. Network Load Balancer (NLB)

layer 4 - TCP나 UDP 기반의 트래픽을 인스턴스로 전달하는 것

초당 수백만건의 요청 처리 가능 - 매우 고성능

ALB보다 지연시간이 짧다

다른 로드밸런서와 차이점

- 외부의 가용영역당 1개의 고정 IP를 노출함

- 특정 IP를 화이트리스트에 추가할 때 유용

- ELB or ALB 는 고정IP가 없고 고정 호스트 이름이 있다.

NLB는 고성능 기능이기 때문에 AWS프리티어에서는 사용불가 - 비용 지불해야함

타겟그룹

- EC2 instances

- IP Addresses - 프라이빗 ip 여야함

- Application Load Balancer

 

 

64. Network Load Balancer (NLB) 실습

NLB는 유료 서비스이기 때문에 그냥 강의 보기만 했음

 

 

65. 게이트웨이 로드밸런서 (GWLB)

가장 최신의 로드밸런서

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

layer3single enrty/exit for all traffic대상그룹 (3rd party security Virtual Appliances)- EC2 instances- ip address - must be private ips

 

 

66. ELB - Stiky Seccion (Session Affinity)

고정세션 혹은 세션 밀접성

클라이언트가 ELB(or ALB, CLB)를 통해 EC2 Instance로 접속할 때 한개의 인스턴스로만 접속하도록 하는 고정 세션

쿠키

- 클라이언트에서 로드밸런서로 요청의 일부로서 전송되는 것

- 고정성 + 만료 기간을 가짐

- 쿠키가 만료되면 클라이언트가 다른 EC2 Instance 로 리디렉션 됨

 

애플리케이션 기반 쿠키

기간 기반 쿠키

 

Stickiness

Load balancer generated cookie 로 로드밸런서에서 제공하는 쿠키를 사용할 수 있고

Application-based cookie 로 쿠키 이름을 지정해서 사용할 수 있다.

 

쿠키 기록

이제 새로고침해도 접속되는 인스턴스가 달라지지 않고

개발자 도구에서 쿠키 정보가  AWSALB 인것을 확인할 수 있다

 

 

 

67. ELB - Cross-Zone Load Balancing

교차 영역 로드 밸런싱

Application Load Balancer

- 교차 영역 로드 밸런싱이 항상 활성화 되어있음 (비활성 시킬 수 없음)

- AZ간 데이터 이동에 비용이 없음 (보통 데이터가 한 가용 영역에서 다른 가용역역으로 이동하면 비용이 발생함)

Network Load Balanver

 - 기본적으로 교차 영역 로드 밸런싱이 비활성화 되어있음 ( 활성화에 비용을 지불해야 함 )

Classic Load Balancer

 - 기본적으로 비활성화 되어 있다.

 - 활성화 하면 가용 영역간 데이터 전송에 비용이 발생하지 않는다.

 

 

 

68. ELB - SSL 인증서

SSL(Secure Socket Layer) - 연결을 암호화 하는데 사용됨

TLS(Transport Layer Security) - SSL의 최신 버전

 

Server Name Indication (SNI)(서버이름명시)

- SNI를 사용하면 다수의 SSL 인증서를 발급해 단일 웹서버가 여러 개의 웹 사이트를 제공하도록 하는 문제를 해결해줌

- 최신 프로토콜-모든 클라이언트가 이를 지원하지는 않음

- ALB, NLB 에서 작동함, CLB 에서는 작동하지 않음

- 서로 다른 SSL 인증서를 사용하여 다른 웹사이트로 연결되는 다수의 대상 그룹(타겟그룹) 을 가질 수 있음

 

Classic Load Balancer (v1)

 - 1개의 SSL 인증서 지원

- 여러 SSL 인증서가 있는 다중 호스트 이름이 필요한 경우 다수의 클래식 로드밸런서를 이용하는 것이 바람직함

- SNI 지원 안함

Application Load Balanver (v2)

 - 다중 SSL 인증서를 가진 다수의 리스너를 지원

 - SNI 사용

Network Load Balanver (v2)

- 다중 SSL 인증서를 가진 다수의 리스너를 지원

- SNI 사용

 

ALB 에서의 리스너 추가

 

SSL 인증서를 사용하는 리스너를 추가할 수 있다.

올바른 인증서를 아직 만들지 않아서 실제로 리스너를 실제로 추가하지는 않음

 

 

 

69. ELB - 연결 드레이닝

Connection Draining - CLB 사용 시

Deregistration Delay - ALB & NLB 사용시 - 등록 취소 지연

인스턴스가 등록취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느정도 시간을 주어 활성 요청을 완료할 수 있도록 하는 기능

만약 인스턴스의 연결이 드레이닝 되면 ELB는 등록 취소 중인 EC2 인스턴스로 새로운 요청을 보내지 않음

 

 

(07.16 끝)

 

(7.17 시작)

 

70. 오토 스케일링 그룹 (ASG) 개요

Auto Scaling Group

- scale out (add EC2 instance) to match an increased load

- scale in (remove EC2 instance) to match a decreased load

- 최소-최대 숫자의 가동 기기 수를 정할 수 있음

- 자동으로 로드밸런서에 새 인스턴스를 추가해줌

- ASG 는 인스턴스에 문제가 생길 경우 해당 인스턴스를 삭제하고 새 인스턴스를 생성해 낸다

- ASG 는 재시작이 필요없다.

 

 

71. 오토 스케일링 그룹 (ASG) 실습

ASG 생성

이름을 입력해주고

시작템플릿을 생성해준다

 

시작템플릿 생성

인스턴스 만드는 과정과 같다.

ami는 aws 리눅스 2

ebs - 8gb

기본 vpc

t2.micro

보안그룹은 이전에 만들었던 wizard-1

그리고 사용자 데이터에

#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo system start httpd
sudo system enable httpd
sudo chmod 777 /var/www/html
sudo echo "<h1>Hello World from $(hostname -f)</h1>" > /var/www/html/index.html

 

를 붙여넣기 해줬다.

 

적용한 모습

두번째로 인스턴스 시작 옵션을 선택할 수 있는데

네트워크 정의 다음에 인스턴스 구매 옵션을 설정할 수 있다

인스턴스 유형 선택
구매옵션 , 할당 전략

 

강의보다 더 자세히 나와있는걸로 봐서 새로 추가된 항목들인가보다

 

고급옵션 구성

3번째로 로드밸런싱을 선택해줘야 하는데

굳이 안선택해도 되지만 안정성을 위해 해주는게 좋다

로드밸런서를 연결하려면 무조건 기존에 만든 로드밸런서에 연결해야 한다.

 

그룹 크기 선택

4번째로 그룹 크기 선택이다.

기대용량 - 최소용량 - 최대용량을 설정할 수 있다.

강의에서는 나중에 한다고 한다

스케일링 정책 (크기 조정 정책) 은 일단 없음으로 넘긴다

 

알람 추가

5번째로 알람을 추가할 수 있다.

지금 당장 알람은 필요 없으니 다음으로 넘기고

태그와 검토도 넘겨서 create 해줌

 

근데 오류 뜸

서브넷을 잘못했나본데 좀 찾아봐야할듯

리전 변경

이것저것 해봤는데

결국 서울 리전이 아니라 도쿄 리전에서 동일하게 환경 바꿔놓고 하니까 된다...

기능 별로 안열려있는 서울 말고 앞으로 도쿄에서 해야겠다 ㅅㅂ

 

ASG activity history

ASG 작업기록에서 새로 인스턴스가 생성된 것을 확인

 

로드밸런스 대상 그룹

대상그룹(target group) 에서 새로 인스턴스가 등록되어있는 것을 확인

 

인스턴스

인스턴스 창에서 새로 인스턴스가 만들어진것을 확인

 

수동 스케일링

auto scaling 그룹에 들어가서 직접 그룹 크기를 스케일링 할 수 있다.

 

2로 증가

 

activity history 확인

activity history 에 새로 인스턴스가 추가된다는 내용

원인 칸에서 자세한 내용까지 확인 가능

 

대상그룹

대상그룹에서도 healty check 를 둘다 통과한 모습

 

 

 

72. 오토 스케일링 그룹 (ASG) - 스케일링 정책

 

  • Dynamic Scaling Policies (동적 스케일링 정책)

 - Target Tracking Scaling (대상 추적 스케일링)

가장 쉽고 간단한 설정

ex : 오토 스케일링 그룹의 평균 cpu 사용률을 추적하여 이 수치가 40%대에 머무를 수 있도록 할 때 사용

 - Simple / Step Scaling (단순/단계 스케일링)

CloudWatch 알람을 설정하고

ex: 만약 cpu 사용률이 70%가 넘어간다면 2개 유닛이 추가

ex : 만약 cpu 사용률이 30% 이하가 된다면 1개 유닛 제거

 - Scheduled Actions (예약 작업)

이미 나와있는 사용 패턴을 바탕으로 스케일링을 예상

 

 

  • Predictive Scaling (예측 스케일링)

예측을 생성하여 로드를 보고 다음 스케일링을 예측

시간에 걸쳐 과거 로드를 분석하여 예측이 생성되고 예측에 기반해 사전에 스케일링 작업이 예약됨

머신러닝 기반 손쉬운 ASB 오토 스케일링 기술

 

 

CPU 사용률 : average cpu

RequestCountPerTargt : to make sure - 대상별 요청수

평균 네트워크 입출력량 (Average Network In / Out)

any custom metric (that you push using cloudwatch)

 

 

  • Scaling Cooldowns (스케일링 휴지)

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

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

- 새로운 인스턴스가 안정화 될 수 있도록 함

- 새로운 지표의 양상을 살펴보기 위함

 

 

 

 

72. 오토 스케일링 그룹 (ASG) - 스케일링 정책 실습

auto scaling policies

(7.17 끝 - 조금 남았는데 넘 배고파서 집감)

 

(7.19 시작)

대상 추적 크기 조정

Target tracking scaling

이걸로 실습해볼거다

 

단계 크기 조정

step scaling

단계별로 scale out - in 할 수 있다

 

단순 크기 조정

Simple scaling

알람이 울리면 작업을 수행하는 단순 크기 조정

 

 

대상 추적 크기 조정 (target tracing scaling) 을 하기 위해서 ASG 의 필요 용량을 1, 최소용량 1, 최대용량을 3으로 수정하고

EC2 로 접속해서 stress 를 주었다

 

nstall Stress Utility on Amazon Linux 2
  1. Login into EC2 instance.
  2. You have to enable EPEL repo in Linux 2 AMI: sudo amazon-linux-extras install epel -y.
  3. Now, try to install stress: sudo yum install stress -y.

 

stress -c 4

4개의 cpu 유닛을 활용함에 따라 cpu 사용률이 100%가 됨

 

자동 증가

cpu 사용량이 올라갔기 때문에 2개의 인스턴스가 생겼었다가

트래픽이 안정화 된 후 다시 만들었던 2개 인스턴스를 자동으로 삭제한 로그

(명령어를 실행했었다가 은행가야해서 잠시 덮었는데 인스턴스 연결을 끊으면 stress 명령어 실행이 끝나서 인스턴스가 자동으로 줄어든 것 같다)

 

 

cloudwatch

cloudwatch 의 alarm 을 보면 ASG 에서 사용된 알람을 볼 수 있다

alarmhigh 로 스케일 아웃 시에 인스턴스를 추가하고

alarmlow 로 스케일 인 시 인스턴스를 삭제한다.

 

이후 퀴즈 풀고 끝!

생각보다 분량이 너무 많았던 섹션 ㄷㄷ