AWS CCP 자격증 - 5 (ELB, ASG)

클라우드의 확장성, 고가용성

 

애플리케이션을 스케일링 한다는 말은 인스턴스 혹은 컴퓨팅 파워를 늘리는 것을 말합니다.

 

클라우드의 확장성에는 두 종류가 있습니다.

 

수직 확장성이 있고 수평 확장성이 있는데 탄력성이라고도 합니다.

 

수직확장성 (Vertical Scalability), Scale Up

수직 확장성이란 인스턴스의 크기를 증가할 수 있다는 뜻입니다.

 

 

AWS에서 예를들어, 애플리케이션에서 t2.micro 에서 실행되고 있고 이 애플리케이션을 수직 확장 하려면 

애플리케이션을 t2.large에서 실행하면 됩니다.

 

수직 확장성은 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용합니다.

데이터베이스의 성능을 높이기 위해 데이터베이스의 크기를 늘리는 것입니다.

 

하지만 보통 수직 확장성에는 수직 화장에 한계가 있습니다. (하드웨어의 한계)

 

수평 확장성 (Horizontal Scalability), Scale Out

수평 확장성은 EC2 인스턴스의 크기를 늘리는 대신,

애플리케이션을 위한 인스턴스 또는 시스템의 숫자를 늘리는 것입니다.

 

수직 확장성의 물리적인 문제를 해결하는것이 바로 수평확장성입니다. (규모를 늘리는 것)

 

물리적으로 cpu를 여러개 부착하는것이 현실에서는 불가능하지만, 클라우드 환경에서는 가능합니다. 

AWS나 웹 애플리케이션에서는 이것이 매우 흔한일입니다.

 

즉, 웹 애플리케이션이나 현대적인 애플리케이션이라면 수평 확장성을 염두에 두고 설계해야 합니다.

고가용성

 

고가용성은 애플리케이션과 시스템을 AWS의 가용영역 최소 두 군데에서 실행하는 것을 의미합니다.

 

EC2 인스턴스를 만들 때, 가용영역을 두 개를 지정하면 Auto Scaling을 통해 인스턴스를 만들 때

가용영역을 번갈아 50% 비중으로 인스턴스를 만들기 때문에 하나의 가용영역에 문제가 생겨도

상대적으로 영향을 덜 받을 수 있게 됩니다.

 

시험에는 이렇게 출제 됩니다

확장성인지 탄력성인지 민첩성인지 고르는 것

공식적인 정의를 요약하면

확장성 : 하드웨어를 더 강하게 하거나(수직 확장) 노드를 추가 (수평 확장)하여 더 큰 부하를 수용할 수 있는 능력

탄력성 : 시스템이 확장 가능해지면서 탄력성은 시스템이 부하에 따라 확장될 수 있도록 일부 "자동 확장(auto-scaling)"

민첩성 : 개발자가 해당 리소스를 사용할 수 있도록 하는 시간을 몇 주에서 몇 분으로 단축

 

AWS에서 더 탄력적으로 할 수 있도록 하는 첫 번째 서비스

 

Elastic Load Balancing 

로드 밸런서는 인터넷 트래픽을 다운스트림의 여러 서버(EC2 인스턴스)로 전달하는 서버

 

 

사용자가 많아질수록 여러 EC2 인스턴스에 걸쳐 부하를 더 많이 분산시키므로 백엔드를 더 잘 스케일링 할 수 있다.

 

로드 밸런서의 사용목적

• 여러 다운스트림 인스턴스에 로드 분산
• 다운스트림 인스턴스의 장애를 원할하게 처리
• 인스턴스에 대한 정기적인 상태 확인
• 장애가 있는 인스턴스에는 로드 밸런서가 트래픽을 보내지 않는다(EC2의 인스턴스의 장애를 숨김)
• 여러 가용 영역에서 사용할 수 있어 가용성이 높음

 

왜 탄력적 로드 밸런서(Elastic Load Balancing )를 사용할까?

ELB는 관리형 로드 밸런스이므로 AWS가 작동을 보장한다.

또한 AWS가 ELB의 업그레이드와 유지 보수, 고가용성을 모두 책임진다.

 

개발자는 해당 로브 밸런서의 동작에 관해 몇 가지를 구성하는게 끝입니다.

 

자체 로드 밸런서를 EC2에서 설정하는 경우 비용이 확실히 덜 들지만

결국에는 유지 보수, 통합, 운영체제 업그레이드 처리 등 훨씬 더 많은 작업을 하게됩니다.

 

AWS에서 3가지 종류의 로드 밸런서를 제공합니다

 

• Application Load Balancer (HTTP, HTTPS 전용 트래픽) - Layer 7
• Network Load Balancer (초고성능, TCP, UDP만 허용) - Layer 4
• Gateway Load Balancer - Layer 3

Application Load Balancer

HTTP / HTTPS / gRPC protocols (Layer 7)

HTTP 라우팅 기능

정적 DNS (정적 URL)

사용자가 방금 언급한 프로토콜 중(HTTP/HTTPS/gRPC) 하나에서

로드 밸런서에 액세스하면 로드 밸런서는 트래픽을 다운스트림 EC2 인스턴스로 라우팅합니다.

 

Network Load Balancer

TCP / UDP protocols (Layer4)

초고성능이 필요할 때 사용

탄력적 IP를 통한 정적IP

 

Gateway Load Balancer

IP 패킷 자체에서 GEBEVE protocol 사용 (Layer3)

EC2 인스턴스에서 관리하는 방화벽으로 트래픽을 경로화

보안, 침입 감지 방화벽 등의 용도로 사용 (네트워크 트래픽 분석용)

GWLB는 트래픽 부하를 EC2 인스턴스에서 실행하는 가상 어플라이언스에 분산하여 트래픽을 분석하거나 방화벽 작업을 실행합니다. 그 후 트래픽은 다시 GWLB로 전송되고 그 다음 애플리케이션으로 전달됩니다.

 

GWLB는 위 같은 작업을 진행할 수 있도록 중간에 있습니다.

 

 

로드 밸런서 실습

만들 때 인스턴스는 2개로 만들어줍니다.

 

나머지는 기본 사항으로 진행합니다.

사용자 데이터만 추가!

 

 

생성된 인스턴스의 퍼블릭 ip를 복사해서 주소창에 검색하면

172-31-x-x 로 ip 뒷부분만 변경되어 보여집니다.

 

여기서 하나의 URL만 이 두 EC2 인스턴스에 액세스하고 둘 사이에 부하를 분산하도록 해보겠습니다.

 

이를 위해서 로드 밸런서를 사용해야합니다.

 

 

이 예시에서는 ALB만 살펴보겠습니다.

스키마는 인터넷 연결이도 주소 유형은 IPv4입니다.

네트워크 매핑의 경우 로드 밸런서를 배포할 위치와 가용 영역 수를 결정해야 합니다.

 

이제 로드 밸런서에 보안 그룹을 할당해야 하는데,

새 보안 그룹을 만들어 보겠습니다. (HTTP만 할당하기 위해)

 

생성된 보안그룹을 선택합니다.

 

아래 리스너 및 라우팅이 있는데 

포트 80의 HTTP에서 대상 그룹으로 트래픽을 라우팅해야 합니다.

 

대상 그룹을 생성해줍니다. 

 

대상그룹 생성의 마지막 단계로 로드밸런싱을 연결할 인스턴스를 선택합니다 대상 그룹 생성을 완료하고,

다시 로드 밸런서 생성단계로 와서

대상 그룹을 방금 만든 demo-tg-alb로 설정하고 로드 밸런서 생성을 마무리합니다.

 

로드 밸런서 유형은 애플리케이션이고

가용영역은 4개를 만들었습니다.

프로토콜은 HTTP/HTTPS/gRPC

 

로드 밸런서를 생성하고, 

DNS 이름을 복사해서 새 탭에 붙여 넣으면

 

새로 고치면 대상이 변경 ( 로드 밸런서를 통해 다른 EC2 인스턴스로 실행 ) 됩니다.

즉 로드 밸런싱이 아주 잘 되고있습니다.

 

대상 그룹에 가서 살펴보면

 

 

상태가 둘다 Healthy 인데, 대상 그룹을 통한 ALB가 트래픽을 두 대상에 모두 차례로 잘 보내고 있다는 의미입니다.

여기서 My first Instance를 선택하고 중지해보면

 

대상 그룹에도 변화가 있습니다.

 

중지를 시켜놨기 때문에 로드 밸런서의 리소스 맵에도 지금 하나의 대상은 사용되지 않고 있다고 나옵니다.

이로인해 로드 밸런서 덕분에 대상이 언제 정상인지, 비정상인지 알 수 있습니다.

그리고 지금도 

이 홈페이지는 작동하지만 다른 인스턴스가 잠시 중단 되었기에 이 ip주소 하나만 계속 반복되며 출력됩니다.

-> 로드 밸런서 덕분에 하나의 인스턴스가 중단/장애가 일어나도 여전히 실행은 됩니다.

 

이제 로드 밸런서를 통해서 애플맄이션의 로드를 분산할 수 있습니다.

 

그런데 어떻게 백엔드에서 자동으로 이 서버들을 만들 수 있을까?

 

이를 위해서는 오토 스케일링 그룹(ASG)가 필요합니다.

 

그 이유는 현실에서의 웹사이트 로드는 시간에 따라 다르기 때문입니다.

예를들어, 쇼핑하는 사용자가 있을 때 낮 시간에 쇼핑을 하고 밤에는 쇼핑을 하지 않을 가능성이 큽니다.

낮 시간에 로드가 더 많고 밤시간에는 적은 것을 예측할 수 있습니다.

 

클라우드에서는 매우 빠르게 서버를 만들고 없앨 수 있는 특성이 있습니다.

 

오토 스케일링 그룹의 목적은 스케일 아웃 하는 것입니다.

즉, 늘어난 로드에 맞춰 EC2 인스턴스를 늘리고 줄어든 로드에 맞춰 EC2 인스턴스를 줄입니다.

 

이를 통해서 어느 시점이든 실행하는 머신 숫자를 최소, 최대로 보장할 수 있습니다.

Auto Scaling Group

 

• 현실에서는 웹 사이트 및 애플리케이션의 로드가 변경될 수 있다.
• 클라우드에서는 매우 빠르게 서버를 생성하고 제거할 수 있다.
• 항상 최적의 용량으로 실행하여 가격 절약 (탄력성)

Auto Scaling Group (ASG)의 목표

• 증가하는 부하에 맞춰 EC2 인스턴스를 Scale out (인스턴스 추가)
• 감소하는 부하에 맞춰 EC2 인스턴스를 Scale in (인스턴스 제거)
• 실행 중인 기계의 최소 및 최대 수를 확보
• 로드 밸런서에 자동으로 새로운 인스턴스 등록
• 비정상 인스턴스 교체

 

 

Auto Scaling Group 실습

오토 스케일링 그룹 실습을 위해 생성된 인스턴스를 지우고 시작합니다.

종료가 완료된 후 Auto Scaling 그룹을 생성합니다.

이름은 DemoASG로 했고

시작 템플릿을 선택해야하는데 없기 때문에 새로 생성합니다

이 템플릿은 ASG에 EC2 인스턴스를 어떻게 생성할지 알려주는 데 사용됩니다.

그래서 EC2 인스턴스를 생성할 때와 매우 유사합니다.

시작 템플릿이 생성되었습니다 (DemoLaunchTemplate) 

시작 템플릿을 고르면 앞으로 일어날 일, 보유하게 될 인스턴스 유형, 보안 그룹 등을 설명합니다.

다음을 눌러 진행합니다.

 

이제 인스턴스를 시작할 위치를 선택하고, 여러 가용 영역과 서브넷을 선택할 수 있습니다.

모두 선택합니다.

 

다음은 로드 밸런서를 선택해야합니다. 아까 만들었던 demo-tg-alb에 연결하도록 하겠습니다.

생성된 모든 인스턴스가 ALB의 데모 대상 그룹 내에 등록되어야 한다고 ASG에 알리게 됩니다.

따라서 모든 인스턴스는 대상 그룹에 속하게 되고 로드 밸런서는 트래픽을 대상그룹에 있는 인스턴스로 보낼 수 있습니다.

 

로드 밸런싱에 대한 옵션을 구성하면,

ASG의 스케일링 범위를 설정합니다.

그룹 크기의 원하는 용량에 2를 지정하여 EC2 인스턴스 두 개에 로드 밸런싱을 적용할 수 있습니다.

 

최소 용량은 1로하고 최대 용량은 4로 하며 최대 4개의 인스턴스 까지 늘릴 수 있게 만듭니다.

하지만 여기서  중요한 것은 초기에 원하는 용량을 설정하는 것 입니다. (실제 보유하게될 용량이니까)

 

 

알림 추가는 필요 없습니다. (간단하게 실습만 할거니까)

 

태그 추가도 넘어가겠습니다.

 

마지막 검토 단계에서 지금까지 설정한 사항들은 검토할 수 있습니다.

 

 

 

지금 ASG를 이용해서 EC2 인스턴스를 2개를 초기로 만들었습니다.

작업 기록에 2개의 새로운 EC2 인스턴스가 생성된 걸 볼 수 있고 

인스턴스 상태가 Healthy인 것을 확인할 수 있습니다.

 

대상 그룹도 보면 

 

\

ASG로 생성된 EC2 인스턴스가 생성되있는것을 볼 수 있습니다.

 

이제 아까 처럼 로드 밸런서로 이동하여 DNS 이름을 복사하여 새 탭에서 열면 

새로 고침을 할 때 마다 두 인스턴스에서 모두 Hello World를 얻게 됩니다.

아까와 다른점이라면, 

ASG에 안에 인스턴스를 종료시키면, ASG는 이를 감지하고 새로운 EC2 인스턴스를 실행하여 초기에 설정했던 원하는 용량 2를 맞춘다는 것 입니다.

 

자동으로 다시 하나를 만들었습니다. 대단해....

 

오토 스케일링 그룹의 원리를 살펴봤으니 오토 스케일링 그룹에 관한 다양한 스케일링 전략을 살펴보겠습니다.

Auto Scaling Group - 확장 전략

Manual Scaling (수동 스케일링) - AGS의 사이즈를 수동으로 업데이트

 

 

Dynamic Scaling (자동 스케일링) - 변화하는 수요에 대응

• Simple / Step Scaling
  ex) CPU 사용률이 70%를 넘기면 CloudWatch 알람이 울리고 unit 2개 추가
  ex) CPU 사용률이 30% 미만이면 CloudWatch 알람이 울리고 ASG에 있는 용량에서 1개 유닛 제거-> 트리거를 정의한 다음에 유닛을 얼마나 추가하고 삭제할지 정의하기 때문에 단순/단계 스케일링
• Target Trcking Scaling(대상 추적 스케일링)
  ex) ASG가 자동적으로 스케일을 조정하여 목표치 40%에 머물도록 함
• Scheduled Scaling(예약 스케일링)
  ex) 금요일 오후 5시에 축구 경기 전 사람들이 스포츠 배팅을 하는 것을 알면 최소 용량을 오후 5시에 ASG에 있는 EC2 인스턴스를 10개로 늘린다.
• Predictive Scaling(예측 스케일링)
  - 과거 트래픽 패턴을 확인하여 그 기반으로 머신러닝을 통해 미래 트래픽을 예측
  - 사전에 적절한 수의 EC2 인스턴스를 자동으로 프로비저닝
  - 로드에 예측 가능한 시간 기반 패턴이 있을 때 유

 

 

지금 생성되어 있는 인스턴스를 삭제해도 Auto Scaling Group이 자꾸 인스턴스를 재생성하기 때문에

인스턴스를 삭제하려면 Auto Scaling Group를 삭제해야합니다.

그 다음 삭제 해야하는 것은 로드 밸런서입니다. (ALB만든것삭제)

 

하지만 대상그룹은 삭제하지 않아도 됩니다. 비용이 들지 않으며 ASG와 LB를 삭제했기 때문에 그룹이 비어있음

 

정리

고가용성과 수직적, 수평적일 수 있는

확장성, 탄력성,클라우드의 민첩성 개념을 알아봤습니다.

 

고가용성 : 여러 가용 영역에 걸쳐 애플리케이션을 보유하고 있다는 의미

수직 확장 : 인스턴스의 크기를 늘리는것

수평 확장 : 인스턴스의 수를 늘리는 것

탄력성 : 수요에 따라 확장 및 축소 할 수 있는 기능

민첩성 : 리소스를 매우 빠르게 생성 및 삭제할 수 있어 작업을 더 신속하게 할 수 있도록 지원하는 클라우드개념

 

Elastic Load Balancers (ELB)

• 백엔드 EC2 인스턴스 전체에 트래픽 분산
• health check 지원
• 3개 타입 존재: Application (HTTP - L7), NetWork (TCP - L4), GateWay(L3)

Auto Scaling Groups (AGS)

• 응용 프로그램에서 탄력성을 구현하게 해주는 그룹
• 시스템의 수요에 따라 EC2 인스턴스를 확장하고 비정상을 교체
• ELB와 통합