1.9 AWS Optimization

AWS에서 최적화 살펴보기

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• 가용성을 정의합니다.
• 고가용성 애플리케이션 인프라를 설계합니다.
• 애플리케이션을 확장하는 방법을 설명합니다.

메모

이 모듈은 여기에 설명된 AWS 제품, 서비스 및 기능을 소유, 지원 및 유지 관리하는 Amazon Web Services(AWS)와 협력하여 제작되었습니다. AWS 제품, 서비스 및 기능의 사용에는 AWS에서 유지 관리하는 개인 정보 보호 정책 및 서비스 계약이 적용됩니다.

이 모듈을 완료하기 전에 AWS에서 모니터링을 완료했는지 확인하십시오 . 여기에서 수행하는 작업은 그곳에서 배운 개념을 기반으로 합니다. Monitoring on AWS에서 지표와 대시보드를 사용하여 Amazon CloudWatch로 다음 질문에 답했습니다.

• 애플리케이션에 성능 또는 가용성 문제가 있는지 어떻게 알 수 있습니까?
• Amazon Elastic Compute Cloud(EC2) 인스턴스의 용량이 부족하면 어떻게 됩니까?
• 내 애플리케이션이 다운되면 알림을 받게 됩니까?

대답해야 할 질문이 하나 더 있습니다. 이러한 가용성, 용량 및 연결 가능성 문제를 방지하려면 어떻게 해야 합니까? 

이러한 문제에 대한 다양한 솔루션이 있으며 이것이 이 모듈에서 배우는 내용입니다. 먼저 전체 가용 영역을 사용할 수 없는 경우에도 웹 사이트의 가용성을 유지하는 방법을 배웁니다. 그런 다음 확장성 문제를 해결하는 다양한 방법에 대해 알아봅니다.

가용성이란 무엇입니까?

고양이 사진 애플리케이션 사용자는 사진을 업로드하거나 다운로드할 때마다 앱을 사용할 수 있기를 기대합니다. 시스템의 가용성은 일반적으로 특정 연도의 가동 시간 백분율 또는 9의 숫자로 표시됩니다. 아래에서 연간 가동 중지 시간을 기준으로 한 가용성 백분율 목록과 9 단위 표기법을 볼 수 있습니다.

가용성(%)다운타임(연간)

90%("원 나인")	36.53일
99%("2개의 9")	3.65일
99.9%("나인 3개")	8.77시간
99.95%("나인 3.5")	4.38시간
99.99%("포 9")	52.60분
99.995%("나인 4.5")	26.30분
99.999%("파이브나인")	5.26분

가용성을 높이려면 중복성이 필요합니다. 이는 일반적으로 더 많은 인프라, 즉 더 많은 데이터 센터, 더 많은 서버, 더 많은 데이터베이스, 더 많은 데이터 복제를 의미합니다. 이 인프라를 더 추가하면 더 높은 비용이 든다는 것을 상상할 수 있습니다. 

여기에서 가용성과 비용 사이의 균형을 유지합니다. 고객은 애플리케이션을 항상 사용할 수 있기를 원하지만 수익 측면에서 중복성을 추가하는 것이 더 이상 실행 가능하지 않은 선을 그어야 합니다. 여기에서 서비스 수준 계약을 설정할 수 있습니다.

9의 숫자는 시스템 설계 방식을 지시하고 보증 수준을 제공하는 데 사용할 수 있습니다. 예를 들어 고양이 사진 응용 프로그램에서 사용자에게 가용성 번호를 다시 제공하여 고양이 사진을 저장하는 플랫폼에 대한 신뢰를 높이고 고양이 사진이 안전하고 사용 가능하다는 확신을 줄 수 있습니다. 

애플리케이션 가용성 향상

현재 고양이 사진 애플리케이션에는 Amazon Simple Storage Service(S3)의 사진을 제공하는 데 사용되는 EC2 인스턴스와 데이터베이스로 사용되는 다중 AZ Amazon Relational Database Service(RDS) 클러스터가 하나만 있습니다. 해당 단일 인스턴스는 애플리케이션의 단일 실패 지점입니다. 

데이터베이스는 가용 영역에 걸쳐 데이터를 복제하는 다중 AZ RDS 클러스터에 배포되었기 때문에 현재 고가용성입니다. 하나가 실패하면 두 번째 복사본으로 장애 조치할 수 있습니다. 고양이 사진은 3개의 가용 영역에 걸쳐 복제되는 Amazon S3 Standard에 저장되어 99.99999%의 가용성을 제공하도록 설계되었기 때문에 고가용성입니다. 

그러나 데이터베이스와 S3의 가용성이 높더라도 단일 인스턴스를 사용할 수 없게 되면 고객이 연결할 방법이 없습니다. 응용 프로그램의 가용성을 평가할 때 모든 구성 요소가 포함되어야 하며 추가 리소스를 추가하는 것이 예산 측면에서 합리적인지 판단해야 합니다. 이 단일 실패 지점 문제를 해결하는 한 가지 방법은 서버를 하나 더 추가하는 것입니다.

두 번째 가용 영역 사용

해당 서버의 물리적 위치가 중요합니다. 운영 체제 또는 응용 프로그램 수준에서 소프트웨어 문제가 있는 것 외에도 하드웨어 문제가 있을 수 있습니다. 물리적 서버, 랙, 데이터 센터 또는 가상 머신을 호스팅하는 가용 영역에 있을 수 있습니다. 물리적 위치 문제를 해결하는 쉬운 방법은 다른 가용 영역에 두 번째 EC2 인스턴스를 배포하는 것입니다. 

그것은 또한 운영 체제와 응용 프로그램의 문제를 해결할 것입니다. 그러나 인스턴스가 두 개 이상 있으면 새로운 문제가 발생합니다. 

복제, 리디렉션 및 고가용성 관리

복제 프로세스 생성

첫 번째 과제는 인스턴스 간에 구성 파일, 소프트웨어 패치 및 애플리케이션 자체를 복제하는 프로세스를 생성해야 한다는 것입니다. 가장 좋은 방법은 가능한 곳에서 자동화하는 것입니다.

고객 리디렉션 주소

두 번째 과제는 서버에 요청을 보내는 컴퓨터인 클라이언트가 다른 서버에 대해 알도록 하는 방법입니다. 여기에서 사용할 수 있는 다양한 도구가 있습니다. 가장 일반적인 것은 클라이언트가 사용 가능한 모든 서버의 IP 주소를 가리키는 하나의 레코드를 사용하는 DNS(Domain Name System)를 사용하는 것입니다. 그러나 해당 IP 주소 목록을 업데이트하고 클라이언트가 이러한 변경을 인식하는 데 걸리는 시간(때로는 전파라고도 함)이 일반적으로 이 방법이 항상 사용되지 않는 이유입니다. 

또 다른 옵션은 상태 확인을 처리하고 각 서버에 로드를 분산하는 로드 밸런서를 사용하는 것입니다. 클라이언트와 서버 사이에 있는 로드 밸런서는 전파 시간 문제를 방지합니다. 로드 밸런서에 대해서는 나중에 논의합니다.

고가용성 유형 이해

둘 이상의 서버가 있을 때 해결해야 할 마지막 과제는 활성-수동 시스템 또는 활성-활성 시스템 중 하나가 필요한 가용성 유형입니다. 

• 능동-수동: 능동-수동 시스템에서는 한 번에 두 인스턴스 중 하나만 사용할 수 있습니다. 이 방법의 한 가지 장점은 클라이언트 세션에 대한 데이터가 서버에 저장되는 상태 저장 응용 프로그램의 경우 고객이 항상 세션이 저장된 동일한 서버로 전송되기 때문에 문제가 없다는 것입니다.
• Active-Active: Active -Passive의 단점이자 Active-Active 시스템이 빛나는 곳은 확장성입니다. 두 서버를 모두 사용할 수 있게 하면 두 번째 서버가 응용 프로그램에 약간의 부하를 줄 수 있으므로 전체 시스템이 더 많은 부하를 받을 수 있습니다. 그러나 애플리케이션이 스테이트풀(Stateful)인 경우 고객의 세션을 두 서버에서 모두 사용할 수 없는 경우 문제가 발생합니다. 상태 비저장 애플리케이션은 활성-활성 시스템에서 더 잘 작동합니다.

확장성 향상

서버를 하나 더 추가하여 가용성과 연결 가능성이 향상되었습니다. 그러나 용량 문제가 있는 경우 전체 시스템을 다시 사용할 수 없게 될 수 있습니다. 액티브-패시브 및 액티브-액티브라는 두 가지 유형의 시스템에서 로드 문제를 살펴보겠습니다.

수직 스케일링

단일 활성-수동 시스템에 너무 많은 요청이 전송되면 활성 서버를 사용할 수 없게 되고 수동 서버로 장애 조치되기를 바랍니다. 그러나 이것은 아무것도 해결하지 못합니다. 

능동-수동을 사용하면 수직 확장이 필요합니다. 이것은 서버의 크기를 증가시키는 것을 의미합니다. EC2 인스턴스의 경우 더 큰 유형이나 다른 인스턴스 유형을 선택합니다. 이는 인스턴스가 중지된 상태일 때만 수행할 수 있습니다. 

이 시나리오에서는 다음 단계가 발생합니다. 

1. 수동 인스턴스를 중지합니다. 트래픽을 사용하지 않으므로 애플리케이션에 영향을 미치지 않습니다.
2. 인스턴스 크기 또는 유형을 변경한 다음 인스턴스를 다시 시작하십시오.
3. 트래픽을 수동 인스턴스로 이동하여 활성으로 전환합니다.
4. 마지막 단계는 두 인스턴스가 일치해야 하므로 중지하고 크기를 변경한 다음 이전 활성 인스턴스를 시작하는 것입니다.

요청량이 줄어들면 동일한 작업을 수행해야 합니다. 관련된 단계가 많지는 않지만 실제로 수행해야 할 수동 작업이 많습니다. 또 다른 단점은 서버가 특정 한계까지만 수직으로 확장할 수 있다는 것입니다.

한도에 도달하면 유일한 옵션은 또 다른 활성-수동 시스템을 만들고 요청과 기능을 시스템 간에 분할하는 것입니다. 이를 위해서는 대규모 애플리케이션 재작성이 필요할 수 있습니다.

이것이 액티브-액티브 시스템이 도움이 될 수 있는 곳입니다. 요청이 너무 많은 경우 서버를 추가하여 이 시스템을 수평으로 확장할 수 있습니다. 

수평적 스케일링

위에서 언급했듯이 응용 프로그램이 활성-활성 시스템에서 작동하려면 서버에 클라이언트 세션을 저장하지 않고 이미 상태 비저장으로 생성됩니다. 즉, 서버가 2개 또는 4개가 있으면 애플리케이션을 변경할 필요가 없습니다. 필요할 때 더 많은 인스턴스를 만들고 트래픽이 감소하면 인스턴스를 종료하는 문제일 뿐입니다. Amazon EC2 Auto Scaling 서비스는 Amazon CloudWatch의 지표를 기반으로 EC2 인스턴스를 자동으로 생성 및 제거하여 해당 작업을 처리할 수 있습니다. 

능동-수동 시스템에 비해 능동-능동 시스템을 사용하면 더 많은 이점이 있음을 알 수 있습니다. 상태 비저장이 되도록 애플리케이션을 수정하면 확장성이 가능합니다.

마무리

가용성은 가동 중지 시간의 관점에서 측정될 수 있으며 그런 다음 서비스 수준 계약에 연결될 수 있습니다. 고양이 사진 애플리케이션을 EC2 인스턴스 계층에서 고가용성으로 만들기 위해 다른 EC2 인스턴스가 추가되었습니다. 그러나 가용성은 실패뿐만 아니라 부하에 관한 것이기도 합니다. 

수직이 아닌 수평으로 쉽게 확장할 수 있도록 상태 비저장 방식으로 애플리케이션을 생성하는 것이 중요한 곳입니다. 다음 단원에서는 Amazon EC2 Auto Scaling을 사용하여 고양이 사진 애플리케이션을 수평으로 자동 확장하는 방법을 알아봅니다.

 

Quiz

1. What defines the availability for AWS services?

A.A money-back guarantee

B.Availability percentage

C.VPCs in all Availability Zones

D.The value of Trust outlined in a business plan

 

2. What are the two ways that an application can be scaled?

A.Vertically and horizontally

B.Diagonally and vertically

C.Horizontally and diagonally

D.Independently and vertically

 

Amazon EC2 Auto Scaling 알아보기

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• 수동 확장과 자동 확장을 구분합니다.
• Amazon EC2 Auto Scaling의 기능과 특징을 설명합니다.

이전 단원에서 능동-능동 시스템이 능동-수동 시스템보다 더 많은 이점이 있음을 배웠습니다. 그러나 고양이 사진 응용 프로그램의 사용량이 다양하고 점심과 저녁 시간에 트래픽이 많고 밤에는 트래픽이 거의 없는 경우 어떻게 될까요? 이 단원에서는 Amazon EC2 Auto Scaling 서비스로 이 문제를 해결합니다.

기존 확장과 Auto Scaling 구분

확장에 대한 기존 접근 방식을 사용하면 최대 트래픽을 처리하기에 충분한 서버를 구입하고 프로비저닝합니다. 그러나 이것은 야간에 트래픽보다 더 많은 용량이 있음을 의미합니다. 이것은 또한 당신이 돈을 낭비하고 있다는 것을 의미합니다. 밤이나 트래픽이 적은 시간에 이러한 서버를 끄면 전기만 절약됩니다. 

클라우드는 종량제 모델로 다르게 작동합니다. 사용하지 않는 서비스, 특히 온디맨드에 대해 비용을 지불하는 EC2 인스턴스를 끄는 것이 중요합니다. 예측된 시간에 수동으로 서버를 추가 및 제거할 수 있습니다. 그러나 트래픽이 비정상적으로 급증하면 이 솔루션은 오버프로비저닝으로 리소스를 낭비하거나 언더프로비저닝으로 인해 고객을 잃게 됩니다.

여기서 필요한 것은 사용자가 정의한 조건에 따라 EC2 인스턴스를 자동으로 추가 및 제거하는 도구입니다. 이것이 바로 EC2 Auto Scaling 서비스가 하는 일입니다.

Amazon EC2 Auto Scaling 사용

EC2 Auto Scaling 서비스는 가장 낮은 비용으로 안정적이고 예측 가능한 성능을 유지하기 위해 용량을 추가하거나 제거합니다. 애플리케이션이 사용하는 것과 정확히 일치하도록 용량을 조정하면 애플리케이션에 필요한 만큼만 비용을 지불하면 됩니다. 

그리고 꾸준히 사용하는 애플리케이션에서도 EC2 Auto Scaling은 차량 관리에 도움이 될 수 있습니다. EC2 인스턴스에 문제가 있는 경우 EC2 Auto Scaling이 해당 인스턴스를 자동으로 교체할 수 있습니다. 즉, EC2 Auto Scaling은 인프라를 확장하고 고가용성을 보장하는 데 도움이 됩니다. 

EC2 Auto Scaling 구성 요소 구성

EC2 Auto Scaling에는 세 가지 주요 구성 요소가 있습니다.

• 시작 템플릿 또는 구성: 어떤 리소스가 자동으로 확장되어야 합니까?
• EC2 Auto Scaling Group: 리소스를 어디에 배포해야 합니까?
• 조정 정책: 리소스를 언제 추가하거나 제거해야 합니까?

시작 템플릿에 대해 알아보기

EC2 인스턴스를 생성하려면 Amazon 머신 이미지(AMI) ID, 인스턴스 유형, 보안 그룹, 추가 Amazon Elastic Block Store(EBS) 볼륨 등 여러 파라미터가 필요합니다. 이 모든 정보는 확장이 필요할 때 EC2 Auto Scaling에서 사용자를 대신하여 EC2 인스턴스를 생성하는 데에도 필요합니다. 이 정보는 시작 템플릿에 저장됩니다. 

시작 템플릿을 사용하여 EC2 인스턴스를 수동으로 시작할 수 있습니다. EC2 Auto Scaling과 함께 사용할 수도 있습니다. 또한 버전 관리를 지원하므로 문제가 있는 경우 빠르게 롤백하거나 시작 템플릿의 기본 버전을 지정할 수 있습니다. 이렇게 하면 새 버전을 반복하는 동안 필요한 변경을 수행할 때까지 다른 사용자가 기본 버전을 사용하여 EC2 인스턴스를 계속 시작할 수 있습니다.

세 가지 방법 중 하나로 시작 템플릿을 만들 수 있습니다. 

• 템플릿을 생성하는 가장 빠른 방법은 기존 EC2 인스턴스를 사용하는 것입니다. 모든 설정이 이미 정의되어 있습니다.
• 또 다른 옵션은 이미 존재하는 템플릿 또는 이전 버전의 시작 템플릿에서 템플릿을 만드는 것입니다.
• 마지막 옵션은 처음부터 템플릿을 만드는 것입니다. AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 스토리지 및 리소스 태그 옵션을 정의해야 합니다.

메모

Amazon EC2 Auto Scaling이 확장해야 하는 것을 정의하는 또 다른 방법은 시작 구성 을 사용하는 것 입니다. 시작 템플릿과 유사하지만 이전에 생성된 시작 구성을 템플릿으로 사용하여 버전 관리를 허용하지 않습니다. 또한 이미 존재하는 EC2 인스턴스에서 생성하는 것도 허용하지 않습니다. 이러한 이유로 Amazon EC2에서 최신 기능을 사용하려면 시작 구성 대신 시작 템플릿을 사용하십시오.

EC2 Auto Scaling 그룹 알아보기

EC2 Auto Scaling에 필요한 다음 구성 요소는 EC2 Auto Scaling Group(ASG)입니다. ASG를 사용하면 EC2 Auto Scaling이 리소스를 배포하는 위치를 정의할 수 있습니다. 여기에서 EC2 인스턴스를 시작해야 하는 Amazon Virtual Private Cloud(VPC) 및 서브넷을 지정합니다. 

EC2 Auto Scaling은 서브넷 전체에 EC2 인스턴스 생성을 처리하므로 서로 다른 가용 영역에 있는 서브넷을 두 개 이상 선택하는 것이 중요합니다.

ASG를 사용하면 EC2 인스턴스에 대한 구매 유형을 지정할 수도 있습니다. 온디맨드 전용, 스팟 전용 또는 둘의 조합을 사용할 수 있으므로 최소한의 관리 오버헤드로 스팟 인스턴스를 활용할 수 있습니다.

EC2 Auto Scaling이 시작해야 하는 인스턴스 수를 지정하기 위해 그룹 크기에 대해 구성할 세 가지 용량 설정이 있습니다. 

• 최소: 인스턴스 양을 낮추는 임계값에 도달한 경우에도 ASG에서 실행되는 최소 인스턴스 수입니다.
• 최대: 새 인스턴스 추가 임계값에 도달한 경우에도 ASG에서 실행되는 최대 인스턴스 수입니다.
• 원하는 용량: ASG에 있어야 하는 인스턴스의 양입니다. 이 숫자는 최소값 또는 최대값 이내이거나 같을 수 있습니다. EC2 Auto Scaling은 원하는 용량 수와 일치하도록 인스턴스를 자동으로 추가하거나 제거합니다.

EC2 Auto Scaling은 트래픽이 최소화되어 EC2 인스턴스를 제거할 때 최소 용량에 도달할 때까지 EC2 인스턴스를 계속 제거합니다. 애플리케이션에 따라 고가용성을 보장하려면 최소 2개를 사용하는 것이 좋지만 애플리케이션에 항상 필요한 최소한의 EC2 인스턴스 수를 알고 있습니다. 해당 한도에 도달하면 EC2 Auto Scaling에 인스턴스를 제거하라는 지시가 있더라도 최소값을 유지하기 위해 제거하지 않습니다.

반면 트래픽이 계속 증가하면 EC2 Auto Scaling은 EC2 인스턴스를 계속 추가합니다. 이는 애플리케이션 비용도 계속 증가할 것임을 의미합니다. 그렇기 때문에 예산을 초과하지 않도록 최대 금액을 설정하는 것이 중요합니다.

원하는 용량은 그룹이 생성될 때 EC2 Auto Scaling이 생성하는 EC2 인스턴스의 양입니다. 그 수가 줄어들면 EC2 Auto Scaling은 기본적으로 가장 오래된 인스턴스를 제거합니다. 그 수가 증가하면 EC2 Auto Scaling은 시작 템플릿을 사용하여 새 인스턴스를 생성합니다.

EC2 Auto Scaling으로 가용성 보장

최소, 최대 및 원하는 용량에 대해 다른 숫자를 사용하여 용량을 동적으로 조정하는 데 사용됩니다. 그러나 플릿 관리에 EC2 Auto Scaling을 사용하려는 경우 3가지 설정을 동일한 수(예: 4)로 구성할 수 있습니다. EC2 Auto Scaling은 EC2 인스턴스가 비정상 상태가 되면 이를 교체하여 항상 4개의 EC2 인스턴스를 사용할 수 있도록 합니다. 이렇게 하면 애플리케이션의 고가용성이 보장됩니다.

조정 정책으로 자동화 활성화

기본적으로 ASG는 원하는 초기 용량으로 유지됩니다. 원하는 용량을 수동으로 변경할 수 있지만 cat 애플리케이션은 트래픽을 기반으로 동적으로 확장하는 이점이 있습니다. 여기에서 확장 정책이 도움이 됩니다.

AWS 모니터링 모듈에서는 Amazon CloudWatch 지표 및 경보에 대해 배웠습니다. 지표 를 사용 하여 CPU 백분율과 같은 EC2 인스턴스의 다양한 속성에 대한 정보를 유지합니다. 당신은 사용 경보 임계 값에 도달하면 액션을 지정할 수 있습니다. 메트릭 및 경보는 조정 정책이 조치를 취해야 할 시기를 알기 위해 사용하는 것입니다. 예를 들어 전체 EC2 인스턴스 집합에서 CPU 사용률이 70%를 초과하면 조정 정책을 트리거하여 EC2 인스턴스를 추가하라는 경보를 설정합니다.

조정 정책에는 단순, 단계 및 대상 추적 조정의 세 가지 유형이 있습니다.

단순 확장 정책

간단한 확장 정책을 통해 위에 설명된 것을 정확히 수행할 수 있습니다. CloudWatch 경보를 사용하고 경보가 트리거될 때 수행할 작업을 지정합니다. 추가 또는 제거할 EC2 인스턴스의 수 또는 원하는 용량을 설정할 특정 수일 수 있습니다. EC2 인스턴스의 양을 사용하는 대신 그룹의 백분율을 지정할 수 있습니다. 그러면 그룹이 더 빨리 확장되거나 축소됩니다. 

이 조정 정책이 트리거되면 다른 조치를 취하기 전에 휴지 기간을 기다립니다. EC2 인스턴스가 시작되는 데 시간이 걸리고 EC2 인스턴스가 부팅되는 동안 CloudWatch 경보가 계속 트리거될 수 있으므로 이는 중요합니다. 

예를 들어 모든 인스턴스의 CPU 사용률이 65%를 초과하는 경우 EC2 인스턴스를 추가하기로 결정할 수 있습니다. 새 EC2 인스턴스가 트래픽을 수락할 때까지 인스턴스를 더 추가하고 싶지 않습니다. 

그러나 CPU 사용률이 이제 ASG 전체에서 85% 이상이라면 어떻게 됩니까? 여기서 하나의 인스턴스만 추가하는 것은 올바른 이동이 아닐 수 있습니다. 대신 조정 정책에 다른 단계를 추가할 수 있습니다. 불행히도 간단한 확장 정책은 도움이 되지 않습니다.

단계 확장 정책

여기에서 단계 조정 정책이 도움이 됩니다. 단계 조정 정책은 조정 활동 또는 상태 확인 교체가 진행되는 동안에도 추가 경보에 대응합니다. 위의 예와 유사하게 CPU 사용률이 85%인 경우 인스턴스 2개를 추가하고 95%인 경우 인스턴스 4개를 더 추가하기로 결정합니다.

CloudWatch 경보를 기반으로 인스턴스를 추가 및 제거할 시점을 결정하는 것은 어려운 작업처럼 보일 수 있습니다. 이것이 세 번째 유형의 조정 정책인 대상 추적이 존재하는 이유입니다.

대상 추적 확장 정책

애플리케이션이 평균 CPU 사용률, 평균 네트워크 사용률(in 또는 out) 또는 요청 수를 기반으로 확장되는 경우 이 확장 정책 유형을 사용할 것입니다. 추적할 대상 값만 제공하면 필요한 CloudWatch 경보가 자동으로 생성됩니다.

마무리

이 단원에서는 EC2 Auto Scaling을 사용한 자동 조정의 이점에 대해 배웠습니다. 이 서비스는 확장할 대상을 알기 위한 시작 템플릿, 확장 시점을 정의하는 확장 정책, EC2 인스턴스를 시작할 위치를 결정하는 ASG라는 세 가지 구성 요소로 구성됩니다.

고양이 사진 애플리케이션에 EC2 Auto Scaling을 추가하는 것은 고가용성과 확장성을 위해 중요합니다. 그러나 새로 생성된 모든 인스턴스에 트래픽을 가져오는 방법이 궁금할 수 있습니다. 다음 단원에서는 EC2 Auto Scaling을 Elastic Load Balancing 서비스와 통합하여 이 문제를 해결하는 방법을 배웁니다. 

 

Quiz

1. What are the three components of EC2 Auto Scaling?

A.Scaling policies, launch configuration, EC2 Auto Scaling group

B.Launch template, target tracking scaling, EC2 Auto Scaling group

C.Security group, instance type, Key pair

D.AMI ID, instance type, storage

 

2. Which of the following statements is true with regard to launch configurations and launch templates?

A.Launch configurations can be versioned, and one of those versions can be selected as the default.

B.A new launch configuration can be created from an existing one.

C.Launch templates support versioning, allowing you to quickly roll back if there is an issue.

D.Launch templates can be automatically created from an AMI.

 

 

Amazon Elastic Load Balancing으로 트래픽 라우팅

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• 로드밸런서의 기능을 설명하시오.
• Elastic Load Balancing(ELB)과 Amazon EC2 Auto Scaling 간의 통합을 설명합니다.
• 상태 확인 설정 모범 사례를 따릅니다.

이전 단원에서는 고양이 사진 앱의 트래픽을 처리하기 위해 둘 이상의 서버가 있는 이점과 자동 확장 방법에 대해 배웠습니다. 이러한 모든 인스턴스에 대한 트래픽을 어떻게 확보합니까? 고객이 새 항목을 추가하거나 다른 항목을 제거하는 경우를 어떻게 알 수 있습니까? 

이 모든 작업은 로드 밸런서를 사용하여 수행됩니다.

로드 밸런서란?

부하 분산은 리소스 집합에 작업을 분산하는 프로세스를 나타냅니다. 고양이 사진 애플리케이션의 경우 리소스는 애플리케이션을 처리하는 EC2 인스턴스이고 작업은 전송되는 다양한 요청입니다. 이제 로드 밸런서를 사용하여 모든 서버에 요청을 분산할 때입니다. 

먼저 로드 밸런서가 모든 트래픽을 가져와 알고리즘을 기반으로 백엔드 서버로 리디렉션하도록 설정해야 합니다. 가장 널리 사용되는 알고리즘은 트래픽을 각 서버에 차례로 보내는 라운드 로빈입니다.

고양이 사진 애플리케이션에 대한 일반적인 요청은 클라이언트의 브라우저에서 시작됩니다. 로드 밸런서로 전송됩니다. 그런 다음 고양이 사진 애플리케이션을 호스팅하는 EC2 인스턴스 중 하나로 전송됩니다. 반환 트래픽은 로드 밸런서를 통해 다시 클라이언트 브라우저로 돌아갑니다. 따라서 로드 밸런서는 트래픽 경로에 직접 있습니다.

EC2 인스턴스에 자체 소프트웨어 로드 밸런싱 솔루션을 설치할 수 있지만 AWS는 Elastic Load Balancing(ELB)이라는 서비스를 제공합니다.

Elastic Load Balancing의 기능 알기

ELB 서비스는 자체 솔루션을 사용하여 로드 밸런싱을 수행하는 것보다 관리하거나 운영할 필요가 없다는 큰 이점을 제공합니다. 컨테이너, IP 주소 및 AWS Lambda 기능은 물론 EC2 인스턴스 전반에 수신 애플리케이션 트래픽을 분산할 수 있습니다.

• ELB가 IP 주소로 로드 밸런싱할 수 있다는 사실은 온프레미스 서버로 로드 밸런싱하는 하이브리드 모드에서도 작동할 수 있음을 의미합니다.
• ELB는 고가용성을 관리하므로 사용자가 그것에 대해 생각할 필요가 없습니다. 확인해야 하는 유일한 옵션은 로드 밸런서가 여러 가용 영역에 배포되는 것입니다.
• 확장성 면에서 ELB는 트래픽에 따라 자동으로 확장되므로 걱정할 필요가 없습니다. 들어오는 트래픽을 처리하고 백엔드 애플리케이션으로 보냅니다.

ELB와 EC2 Auto Scaling 통합

ELB 서비스는 EC2 Auto Scaling과 원활하게 통합됩니다. 새 EC2 인스턴스가 EC2 Auto Scaling 그룹에 추가되거나 제거되는 즉시 ELB에 알림이 전송됩니다. 그러나 새 EC2 인스턴스로 트래픽을 보내기 전에 해당 EC2 인스턴스에서 실행 중인 애플리케이션을 사용할 수 있는지 확인해야 합니다.

이 유효성 검사는 ELB의 상태 확인 기능을 통해 수행됩니다. 모니터링은 트래픽을 정상적인 EC2 인스턴스로만 라우팅해야 하므로 로드 밸런서의 중요한 부분입니다. 이것이 ELB가 두 가지 유형의 상태 확인을 지원하는 이유입니다. 

• TCP를 사용하여 백엔드 EC2 인스턴스에 대한 연결을 설정하고 해당 연결이 성공하면 인스턴스를 사용 가능한 것으로 표시합니다.
• 지정한 웹 페이지에 HTTP 또는 HTTPS 요청을 하고 HTTP 응답 코드가 반환되는지 확인합니다.

올바른 상태 확인 정의

시간을 들여 적절한 상태 확인을 정의하는 것이 중요합니다. 애플리케이션의 포트가 열려 있는지 확인하는 것만으로 애플리케이션이 작동하는 것은 아닙니다. 또한 단순히 애플리케이션의 홈 페이지를 호출하는 것이 올바른 방법이라는 의미도 아닙니다. 

고양이 사진 응용 프로그램은 로컬 저장소, 데이터베이스 및 S3에 따라 다릅니다. 상태 확인은 이러한 모든 요소의 유효성을 검사해야 합니다. 이를 수행하는 한 가지 방법은 로컬 스토리지가 작동하는지 테스트하는 "/monitor"와 같은 모니터링 웹 페이지를 만들고 데이터베이스를 호출하여 연결하고 데이터를 가져올 수 있는지 확인하고 S3를 호출하는 것입니다. 그런 다음 로드 밸런서의 상태 확인을 "/monitor" 페이지로 지정합니다.

새 EC2 인스턴스의 가용성을 확인한 후 로드 밸런서는 트래픽을 보내기 시작합니다. ELB는 EC2 인스턴스가 더 이상 작동하지 않는다고 판단하면 해당 인스턴스로의 트래픽 전송을 중지하고 EC2 Auto Scaling에 알립니다. EC2 Auto Scaling의 책임은 그룹에서 이를 제거하고 새 EC2 인스턴스로 교체하는 것입니다. 트래픽은 상태 확인을 통과한 경우에만 새 인스턴스로 보냅니다.

EC2 Auto Scaling이 확장 정책으로 인해 축소 작업을 수행해야 하는 경우 EC2 인스턴스가 종료될 것임을 ELB에 알립니다. ELB는 EC2 Auto Scaling이 해당 인스턴스에 대한 모든 연결이 종료될 때까지 EC2 인스턴스를 종료하는 것을 방지하면서 새로운 연결은 방지할 수 있습니다. 이 기능을 연결 드레이닝 이라고 합니다 .

ELB 사용법 배우기

ELB 서비스는 세 가지 주요 구성 요소로 구성됩니다. 

• 리스너: 클라이언트가 리스너에 연결합니다. 이것을 종종 클라이언트 측이라고 합니다. 리스너를 정의하려면 로드 밸런서 유형에 따라 프로토콜과 함께 포트를 제공해야 합니다. 단일 로드 밸런서에 대해 많은 리스너가 있을 수 있습니다.
• 대상 그룹: 백엔드 서버 또는 서버 측이 하나 이상의 대상 그룹에 정의됩니다. 여기에서 EC2 인스턴스, AWS Lambda 함수 또는 IP 주소와 같이 트래픽을 전달하려는 백엔드 유형을 정의합니다. 또한 각 대상 그룹에 대해 상태 확인을 정의해야 합니다.
• 규칙: 대상 그룹을 수신기에 연결하려면 규칙을 사용해야 합니다. 규칙은 클라이언트의 소스 IP 주소가 될 수 있는 조건과 트래픽을 보낼 대상 그룹을 결정하는 조건으로 구성됩니다.

다음 단원에서 이 모든 것이 어떻게 결합되는지 알아보십시오.

마무리

이 단원에서는 로드 밸런싱 기술과 ELB 서비스 사용의 이점에 대해 배웠습니다. 이러한 기능 중 하나는 백엔드 인프라를 자동으로 확장하는 EC2 Auto Scaling 서비스와의 통합입니다. 

다음 단원에서는 다양한 유형의 ELB 기능과 고양이 사진 응용 프로그램에 적합한 ELB를 선택하는 방법에 대해 알아봅니다.

 

Quiz

1. True or false: Once a new EC2 instance is created within an EC2 Auto Scaling group connected to ELB, the load balancer directs traffic to it right away.

A.True

B.False

 

2. Elastic Load Balancing includes which of these features?

A.Automatic scaling

B.AI for categorizing cat photos

C.Integration with Auto Scaling

D.A and B

E.A and C

 

로드 밸런서 유형 알아보기

학습 목표

이 단원을 완료하면 다음을 수행할 수 있습니다.

• Elastic Load Balancing 로드 밸런서의 유형을 구분합니다.
• Application Load Balancer와 Network Load Balancer의 기능을 설명합니다.
• 애플리케이션에 따라 올바른 로드 밸런서 유형을 선택하십시오.

이전 단원에서 배웠듯이 ELB 서비스를 사용하는 것이 고양이 사진 애플리케이션에 사용되는 EC2 Auto Scaling 그룹으로 트래픽 균형을 조정하는 가장 쉬운 방법입니다. 그러나 이제 고양이 사진 앱에 적합한 유형의 로드 밸런서를 선택해야 합니다. 그러기 위해서는 ELB의 종류를 구분하는 특징을 이해해야 합니다.

애플리케이션 로드 밸런서

다음은 ALB(Application Load Balancer)의 몇 가지 주요 기능입니다.

ALB는 요청 데이터를 기반으로 트래픽을 라우팅합니다. URL 경로(/업로드) 및 호스트, HTTP 헤더 및 메서드, 클라이언트의 소스 IP 주소와 같은 HTTP 프로토콜을 기반으로 라우팅 결정을 내립니다. 이를 통해 대상 그룹에 대한 세분화된 라우팅이 가능합니다.

클라이언트에게 직접 응답을 보냅니다. ALB에는 사용자 정의 HTML 페이지와 같은 고정 응답으로 클라이언트에 직접 응답할 수 있는 기능이 있습니다. 또한 특정 웹사이트로 리디렉션하거나 요청을 HTTP에서 HTTPS로 리디렉션하여 백엔드 서버에서 해당 작업을 제거해야 할 때 유용한 클라이언트로 리디렉션을 보내는 기능이 있습니다.

ALB는 TLS 오프로딩을 지원합니다. HTTPS와 백엔드 서버의 작업 저장에 대해 말하면 ALB는 HTTPS 트래픽을 이해합니다. ALB를 통해 HTTPS 트래픽을 전달할 수 있도록 IAM(Identity and Access Management) 또는 ACM(AWS Certificate Manager) 서비스를 통해 인증서를 가져오거나 ACM을 사용하여 무료로 인증서를 생성하여 SSL 인증서를 제공합니다. 이렇게 하면 클라이언트와 ALB 간의 트래픽이 암호화됩니다.

사용자를 인증합니다. 보안 주제에서 ALB는 사용자가 로드 밸런서를 통과하도록 허용되기 전에 사용자를 인증하는 기능이 있습니다. ALB는 OpenID Connect 프로토콜을 사용하고 다른 AWS 서비스와 통합하여 SAML, LDAP, Microsoft AD 등과 같은 더 많은 프로토콜을 지원합니다. 

안전한 트래픽. 트래픽이 로드 밸런서에 도달하지 못하도록 하려면 지원되는 IP 주소 범위를 지정하도록 보안 그룹을 구성합니다. 

ALB는 라운드 로빈 라우팅 알고리즘을 사용합니다. ALB는 각 서버가 일반적으로 동일한 수의 요청을 수신하도록 합니다. 이 유형의 라우팅은 대부분의 응용 프로그램에서 작동합니다.

ALB는 미해결 요청 라우팅 알고리즘을 사용합니다. 백엔드에 대한 요청이 다른 요청보다 훨씬 더 많은 CPU 시간을 필요로 하는 복잡성이 다양한 경우에는 미해결 요청 알고리즘이 더 적합합니다. 또한 대상이 처리 기능이 다양한 경우 사용할 올바른 라우팅 알고리즘입니다. 미해결 요청은 요청이 백엔드 서버로 전송되고 응답이 아직 수신되지 않은 경우입니다.

예를 들어 대상 그룹의 EC2 인스턴스가 동일한 크기가 아닌 경우 라운드 로빈 라우팅 알고리즘을 사용하여 각 서버에 동일한 수의 요청이 전송되면 한 서버의 CPU 사용률이 다른 서버보다 높습니다. 동일한 서버에 더 많은 미해결 요청도 있을 것입니다. 최소 미해결 요청 라우팅 알고리즘을 사용하면 대상 간에 동일한 사용이 보장됩니다.

ALB에는 고정 세션이 있습니다. 애플리케이션이 스테이트풀(Stateful)이기 때문에 동일한 백엔드 서버로 요청을 보내야 하는 경우 고정 세션 기능을 사용합니다. 이 기능은 HTTP 쿠키를 사용하여 연결에서 트래픽을 보낼 서버를 기억합니다.

마지막으로 ALB는 특히 HTTP 및 HTTPS 트래픽용입니다. 애플리케이션이 다른 프로토콜을 사용하는 경우 NLB(Network Load Balancer)를 고려하십시오.

네트워크 로드 밸런서

다음은 NLB(Network Load Balancer)의 몇 가지 주요 기능입니다.

Network Load Balancer는 TCP, UDP 및 TLS 프로토콜을 지원합니다. HTTPS는 TCP와 TLS를 프로토콜로 사용합니다. 그러나 NLB는 연결 계층에서 작동하므로 HTTPS 요청이 무엇인지 이해하지 못합니다. 즉, 해당 프로토콜을 기반으로 하는 라우팅 규칙, 인증 및 미해결 요청 라우팅 알고리즘과 같이 HTTP 및 HTTPS 프로토콜을 이해하는 데 필요한 위에서 설명한 모든 기능을 NLB에서 사용할 수 없습니다.

NLB는 흐름 해시 라우팅 알고리즘을 사용합니다. 알고리즘은 다음을 기반으로 합니다.

• 프로토콜
• 소스 IP 주소 및 소스 포트
• 대상 IP 주소 및 대상 포트
• TCP 시퀀스 번호

이러한 매개변수가 모두 같으면 패킷이 정확히 동일한 대상으로 전송됩니다. 다음 패킷에서 이들 중 하나라도 다르면 요청이 다른 대상으로 전송될 수 있습니다.

NLB에는 고정 세션이 있습니다. ALB와 달리 이러한 세션은 쿠키 대신 클라이언트의 소스 IP 주소를 기반으로 합니다. 

NLB는 TLS 오프로딩을 지원합니다. NLB는 TLS 프로토콜을 이해합니다. 또한 ALB가 작동하는 방식과 유사한 백엔드 서버에서 TLS를 오프로드할 수 있습니다.

NLB는 초당 수백만 개의 요청을 처리합니다. ALB도 이 수의 요청을 지원할 수 있지만 해당 수에 도달하려면 확장해야 합니다. 시간이 걸립니다. NLB는 이 양의 요청을 즉시 처리할 수 있습니다.

NLB는 고정 및 탄력적 IP 주소를 지원합니다. 애플리케이션 클라이언트가 DNS를 사용하는 대신 로드 밸런서 IP 주소로 직접 요청을 보내야 하는 상황이 있습니다. 예를 들어, 애플리케이션이 DNS를 사용할 수 없거나 연결 클라이언트에 IP 주소를 기반으로 하는 방화벽 규칙이 필요한 경우에 유용합니다. 이 경우 NLB가 사용하기에 적합한 유형의 로드 밸런서입니다.

NLP는 소스 IP 주소를 유지합니다. NLB는 트래픽을 백엔드로 보낼 때 클라이언트의 소스 IP 주소를 유지합니다. ALB를 사용하면 요청의 소스 IP 주소를 보면 로드 밸런서의 IP 주소를 찾을 수 있습니다. NLB를 사용하는 동안 클라이언트의 실제 IP 주소가 표시되며, 이는 경우에 따라 백엔드 애플리케이션에 필요합니다. 

ELB 유형 중에서 선택

ELB 서비스 유형 중에서 선택하는 것은 애플리케이션에 필요한 기능을 결정하여 수행됩니다. 아래에서 이 단원과 이전 단원에서 배운 주요 기능 목록을 찾을 수 있습니다. 

특징애플리케이션 로드 밸런서네트워크 로드 밸런서

프로토콜	HTTP, HTTPS	TCP, UDP, TLS
연결 드레이닝(등록 취소 지연)	✔
IP 주소를 대상으로	✔	✔
고정 IP 및 탄력적 IP 주소		✔
소스 IP 주소 유지		✔
소스 IP 주소, 경로, 호스트, HTTP 헤더, HTTP 메서드 및 쿼리 문자열을 기반으로 하는 라우팅	✔
리디렉션	✔
고정 응답	✔
사용자 인증	✔

마무리

이 단원에서는 Application Load Balancer와 Network Load Balancer에 대해 배웠습니다. 올바른 유형의 로드 밸런서를 선택하려면 애플리케이션의 요구 사항을 이해해야 합니다. 고양이 사진 애플리케이션의 경우 HTTP 및 HTTPS 프로토콜을 사용합니다. 

여기서 올바른 옵션은 고정 IP와 같이 Network Load Balancer가 제공하는 기능이 절대적으로 필요하지 않은 한 Application Load Balancer를 사용하는 것입니다. 또한 DNS를 사용하여 애플리케이션에 도달하는 데 제약이 없으므로 ALB를 사용해야 합니다.

 

Quiz

1. Which of the following ELB load balancer types should be used for an application requiring to choose target groups with a rule based on the domain of a website?

A.Classic Load Balancer

B.Application Load Balancer

C.Network Load Balancer

D.Target Load Balancer

 

2. A website requires TLS to be offloaded at the load balancer level and the use of Elastic IP addresses. Which of the following ELB load balancer types should be used?

A.Classic Load Balancer

B.Application Load Balancer

C.Network Load Balancer

D.Target Load Balancer