AWS | [실습] 고가용성 환경 만들기

모듈 9 - 가이드 랩: 고가용성 환경 만들기

실습 개요 및 목표

중요한 비즈니스 시스템은 고가용성 애플리케이션으로 배포되어야 합니다. 즉, 일부 구성 요소에서 장애가 발생하더라도 애플리케이션이 계속 작동해야 합니다. Amazon Web Services(AWS)에서 고가용성을 실현하려면 여러 가용 영역에서 서비스를 실행하는 것이 좋습니다.

로드 밸런서와 같은 여러 AWS 서비스는 본질적으로 가용성이 높습니다. 또한 많은 AWS 서비스는 여러 가용 영역에 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 배포하는 등, 고가용성으로 구성할 수도 있습니다.

이 실습에서는 단일 EC2 인스턴스에서 실행되는 애플리케이션으로 시작한 다음, 이를 고가용성 애플리케이션으로 바꿉니다.

이 실습을 마치면 다음을 수행할 수 있습니다.

• 제공된 Virtual Private Cloud(VPC) 검사
• Application Load Balancer 생성
• Auto Scaling 그룹 생성
• 애플리케이션 고가용성 테스트

 

이 실습이 끝나면 아키텍처는 다음 예와 같습니다.

작업 1: VPC 검사

이 실습은 AWS CloudFormation을 통해 배포된 환경에서 시작합니다. 이 환경에는 다음이 포함되어 있습니다.

• VPC
• 2개의 가용 영역에 있는 퍼블릭 및 프라이빗 서브넷
• 퍼블릭 서브넷에 연결된 인터넷 게이트웨이(표시되어 있지 않음)
• 퍼블릭 서브넷 중 하나의 NAT(Network Address Translation) 게이트웨이
• 프라이빗 서브넷 중 하나에 있는 Amazon Relational Database Service(Amazon RDS) 인스턴스

 

 

Your VPCs를 선택한다. 여기에서 사용자가 생성한 Lab VPC에 대한 정보에 액세스할 수 있다.

CIDR 열의 값은 10.0.0.0/16. 즉, 이 VPC에는 10.0.x.x로 시작하는 모든 IP 주소가 포함된다는 의미이다.

 

서브넷을 선택하면 Public Subnet 1:에 대한 정보에 액세스할 수 있다. 

• VPC 열에 이 서브넷이 Lab VPC 내부에 존재하는 것으로 표시됩니다.
• IPv4 CIDR 열의 값은 10.0.0.0/24입니다. 즉, 이 서브넷에는 10.0.0.0에서 10.0.0.255 사이의 256개 IP 주소가 포함되어 있습니다. 이 주소 중 5개는 예약되어 사용할 수 없습니다.
• Availability Zone 열에 이 서브넷이 상주하는 가용 영역이 나열됩니다.

 

페이지 하단에서 Route Table 탭을 클릭하면 서브넷의 라우팅에 대한 세부 정보가 포함되어 있다.

- 첫 번째 항목은 VPC의 Classless Inter-Domain Routing(CIDR) 범위 내로 전송되는 트래픽(*10.0.0.0/16*)이 VPC (*local*) 내에서 라우팅되도록 지정
- 두 번째 항목은 인터넷으로 전송되는 모든 트래픽(*0.0.0.0/0*)이 인터넷 게이트웨이(*igw-*)로 라우팅되도록 지정합니다. 이 설정은 서브넷을 *퍼블릭 서브넷*으로 만듦

 

인터넷 게이트웨이는 이미 Lab VPC에 연결되어 있음

 

보안 그룹은 데이터베이스로 들어오는 트래픽을 제어한다.

페이지 하단에서 Inbound rules 탭을 선택

이러한 규칙은 VPC(10.0.0.0/16)의 모든 위치에서 인바운드 MySQL 또는 Aurora 트래픽(포트 3306)을 허용합니다. 나중에 애플리케이션 서버의 트래픽만 허용하도록 이 설정을 수정

 

 

태스크 2: Application Load Balancer 생성

고가용성 애플리케이션을 구축하려면 모범 사례로서 여러 가용 영역에서 리소스를 시작하는 것이 좋습니다. 가용 영역은 동일한 리전에 있는 물리적으로 분리된 데이터 센터(또는 데이터 센터 그룹)입니다. 여러 가용 영역에서 애플리케이션을 실행하면 데이터 센터에 장애가 발생할 경우 더 높은 가용성을 제공할 수 있습니다.

애플리케이션이 여러 애플리케이션 서버에서 실행되므로 이러한 서버 간에 트래픽을 분산할 방법이 필요합니다. 로드 밸런서를 사용하여 이를 구현할 수 있습니다. 또한 이 로드 밸런서는 인스턴스에 대한 상태 확인을 수행하고 정상적인 인스턴스에만 요청을 보냅니다.

 

 

 

Services 메뉴에서 EC2를 선택

 

 

Application Load Balancer에서 Create를 선택하고 Name에 Inventory-LB를 입력한다. Availability Zones 섹션으로 스크롤한 다음 VPC에서 Lab VPC를 선택한다. 이제 로드 밸런서에서 사용할 서브넷을 지정합니다. 이 로드 밸런서는 퍼블릭 로드 밸런서가 되므로 두 퍼블릭 서브넷을 모두 선택해준다.

 

이제 로드 밸런서에서 사용할 서브넷을 지정합니다. 이 로드 밸런서는 퍼블릭 로드 밸런서가 되므로 두 퍼블릭 서브넷을 모두 선택한다.

1. 첫 번째 가용 영역을 선택한 다음 표시되는 퍼블릭 서브넷을 선택
2. 두 번째 가용 영역을 선택한 다음 표시되는 퍼블릭 서브넷을 선택

 

 

태스크 3: Auto Scaling 그룹 생성

Amazon EC2 Auto Scaling은 사용자 정의 정책, 일정 및 상태 확인 결과에 따라 Amazon EC2 인스턴스를 자동으로 시작하거나 종료하도록 설계된 서비스입니다. 또한 여러 가용 영역에 인스턴스를 자동으로 배포하여 애플리케이션의 가용성을 높입니다.

이 태스크에서는 프라이빗 서브넷에 EC2 인스턴스를 배포하는 Auto Scaling 그룹을 생성합니다. 이는 애플리케이션 배포를 위한 보안 모범 사례입니다. 프라이빗 서브넷의 인스턴스는 인터넷에서 액세스할 수 없습니다. 대신 사용자가 로드 밸런서로 요청을 전송하여 프라이빗 서브넷의 EC2 인스턴스로 요청을 전달합니다.

 

 

Auto Scaling용 AMI 생성

기존 Web Server 1에서 AMI를 생성한다. 이렇게 하면 부팅 디스크의 콘텐츠가 저장되므로 동일한 콘텐츠를 사용하여 새 인스턴스를 시작할 수 있다.

 

AWS Management Console의 Services 메뉴에서 EC2를 클릭하고 Web Server 1를 선택

Actions 메뉴에서 Image > Create Image를 클릭하고 다음을 구성한다

• Image name: Web Server AMI
• Image description: Lab AMI for Web Server

 

 

시작 구성 및 Auto Scaling 그룹 생성

먼저 Amazon EC2 Auto Scaling이 시작해야 하는 인스턴스 유형을 정의하는 시작 구성을 생성합니다. 인터페이스는 EC2 인스턴스를 시작할 때와 유사합니다. 하지만 인스턴스를 시작하는 대신 나중에 사용할 수 있도록 구성을 저장합니다 .

 

 

Launch configuration name: Inventory-LC

Amazon machine image (AMI) Web Server AMI 

Instance type: t3.micro 

 

추가 구성

IAM instance profile: Inventory-App-Role

Monitoring: CloudWatch 내에서 EC2 인스턴스 세부 모니터링 활성화

이렇게 하면 Auto Scaling이 사용률 변화에 신속하게 대응할 수 있다.

Advanced details. User data에서 다음 스크립트를 복사

#!/bin/bash
# Install Apache Web Server and PHP
yum install -y httpd mysql
amazon-linux-extras install -y php7.2
# Download Lab files
wget https://aws-tc-largeobjects.s3-us-west-2.amazonaws.com/ILT-TF-200-ACACAD-20-EN/mod9-guided/scripts/inventory-app.zip
unzip inventory-app.zip -d /var/www/html/
# Download and install the AWS SDK for PHP
wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip
unzip aws -d /var/www/html
# Turn on web server
chkconfig httpd on
service httpd start

Security groups : Select an existing security group: Inventory-App

Key pair (login) : Proceed without a key pair 선택

Launch configurations 테이블에서 Inventory-LC를 선택

Actions 버튼에서 Create Auto Scaling group을 선택

Auto Scaling 그룹 이름 입력: Inventory-ASG

 

Network 

VPC: Lab VPC

Subnet: Private Subnet 1 및 Private Subnet 2 선택

이렇게 하면 두 가용 영역의 프라이빗 서브넷에서 EC2 인스턴스가 시작

 

Load balancing:  Enable load balancing

Application Load Balancer 또는 Network Load Balancer를 선택

Choose a target group for your load balancer: Inventory-App

 

-> 새 EC2 인스턴스를 이전에 생성한 Inventory-App 대상 그룹의 일부로 등록하도록 Auto Scaling 그룹에 지시. 로드 밸런서는 이 대상 그룹에 있는 인스턴스로 트래픽을 전송

 

Health checks

• ELB
• Health check grace period: 90
• Additional settings:
• Enable group metrics collection within CloudWatch

Group Size

• Desired capacity: 2
• Minimum capacity: 2
• Maximum capacity: 2

Scaling policies: None -> 고가용성을 보장하기 위해 항상 두 개의 인스턴스를 유지

tags : Key: Name / Value: Inventory-App

 

 

 

 

태스크 4: 보안 그룹 업데이트

배포한 애플리케이션은 3티어 아키텍처입니다. 이제 보안 그룹을 구성하여 다음 계층을 적용합니다.

 

로드 밸런서 보안 그룹

로드 밸런서를 생성할 때 이미 Load Balancer security group을 구성했습니다. 이 보안 그룹은 모든 수신 HTTP 및 HTTPS 트래픽을 허용합니다.

로드 밸런서가 수신 요청을 대상 그룹으로 전달하도록 구성되었습니다. Auto Scaling이 새 인스턴스를 시작할 때 자동으로 해당 인스턴스를 대상 그룹에 추가합니다.

 

애플리케이션 보안 그룹

애플리케이션 보안 그룹은 실습 설정의 일부로 제공되었습니다. 이제 로드 밸런서로부터 수신되는 트래픽만 허용하도록 구성합니다.

 

 

왼쪽 탐색 창에서 Security Groups 선택 -> Inventory-App ->Inbound rules 탭을 선택

보안 그룹이 현재 비어 있음. 이제 로드 밸런서로부터 수신되는 HTTP 트래픽을 수락하는 규칙을 추가함. HTTP를 통해 HTTPS 요청을 전달하도록 로드 밸런서가 구성되었으므로, HTTPS 트래픽을 구성할 필요가 없다. 이 방법은 보안을 로드 밸런서로 오프로드하여 개별 애플리케이션 서버에서 요구되는 작업량을 줄일 수 있다.

 

Edit inbound rules 페이지에서 Add rule을 선택하고 다음 설정을 구성

 

Type: HTTP

Source:

Custom 옆에 있는 검색 상자 클릭

현재 내용 삭제, sg 입력

표시되는 목록에서 Inventory-LB 선택

Description: Traffic from load balancer

Save rules 선택

 

 

-> 애플리케이션 서버가 로드 밸런서로부터 트래픽을 수신할 수 있음. 여기에는 로드 밸런서가 자동으로 작동하는지 확인하는 상태 확인도 포함됨

 

 

 

데이터베이스 보안 그룹

이제 애플리케이션 서버에서 수신되는 트래픽만 허용하도록 Database security group을 구성합니다.

 

 

기존 규칙은 포트 3306(MySQL에서 사용됨)에서 VPC 내에 있는 모든 IP 주소의 트래픽을 허용한다. 좋은 규칙이지만 보안상 제한이 더 강화될 수 있음

Inventory-DB를 선택. Inbound rules 탭에서 Edit inbound rules를 선택하고 다음 설정을 구성

• Custom 옆에 있는 검색 상자 클릭
• 현재 내용 삭제
• sg 입력
• 표시되는 목록에서 Inventory-App을 선택합니다.
• Description: Traffic from application servers
• Save rules를 선택

 

3-티어 보안이 구성됨! 티어에 있는 각 요소는 상위 티어로부터 수신되는 트래픽만 허용한다. 프라이빗 서브넷을 사용하면 인터넷과 애플리케이션 리소스 사이에 두 가지 보안 장벽이 구축된다. 이 아키텍처는 여러 보안 계층을 적용하는 모범 사례를 따르게 된다.

 

 

태스크 5: 애플리케이션 테스트 -> unhealthy 상태라 실습불가

이제 애플리케이션을 테스트할 준비가 되었습니다.

이 태스크에서는 웹 애플리케이션이 실행 중인지 확인합니다. 또한 고가용성 여부를 테스트합니다.

 

 

 

태스크 6: 고가용성 테스트

애플리케이션이 고가용성으로 구성되었습니다. EC2 인스턴스 중 하나를 종료하면 애플리케이션의 고가용성을 증명할 수 있습니다. 웹 애플리케이션 인스턴스 중 하나를 중지하여 장애를 시뮬레이션해보고자 한다.

 

Inventory-App 인스턴스 중 하나를 선택한 뒤, Actions, Instance State > Terminate (강제 종료)

잠시 후에, 로드 밸런서 상태 확인이 인스턴스가 응답하지 않는 것을 감지합니다. 로드 밸런서가 모든 요청을 나머지 인스턴스에 자동으로 라우팅합니다.

1. 웹 브라우저에 있는 웹 애플리케이션 탭으로 돌아가서 페이지를 여러 번 다시 로드합니다.

페이지 하단에 표시된 가용 영역이 그대로 유지되는 것을 확인할 수 있습니다. 인스턴스에서 장애가 발생하더라도 애플리케이션을 계속 사용할 수 있다. 몇 분 후 Amazon EC2 Auto Scaling에서도 인스턴스 오류가 발생합니다. 두 개의 인스턴스를 계속 실행하도록 구성했으므로, Amazon EC2 Auto Scaling이 자동으로 교체 인스턴스를 시작한다. 

 

 

 

 

선택적 태스크 1: 데이터베이스를 고가용성으로 만들기

이 태스크는 선택 사항입니다. 실습 시간이 남아 있는 경우 이 태스크를 수행할 수 있습니다.

이제 이 애플리케이션 아키텍처는 고가용성입니다. 하지만 Amazon RDS 데이터베이스는 하나의 데이터베이스 인스턴스에서만 작동합니다.

이 선택적 태스크에서는 데이터베이스를 여러 데이터 센터(가용 영역)에서 실행하도록 변환하여 데이터베이스를 여러 가용 영역(다중 AZ 배포)에서 실행하여 고가용성으로 만들어보겠습니다. 

 

 

Modify 선택 -> Multi-AZ deployment에서 Yes 선택 

 

이 옵션은 데이터베이스가 여러 인스턴스에 분산된다는 것을 의미하지 않습니다. 대신, 하나의 인스턴스가 모든 요청을 처리하는 기본 인스턴스가 됩니다. 다른 인스턴스는 대기 인스턴스로 시작되며, 이 인스턴스는 기본 인스턴스에 장애가 발생할 경우 대신 실행됩니다. 애플리케이션은 데이터베이스에 대해 동일한 DNS 이름을 계속 사용합니다. 단, 연결은 자동으로 현재 활성 데이터베이스 서버로 리디렉션됩니다. 속성을 변경하여 EC2 인스턴스를 확장할 수 있으며, 이 방법으로 RDS 데이터베이스를 확장할 수도 있습니다. 이제 데이터베이스를 확장합니다.

DB instance class에서 db.t3.small을 선택 -> 인스턴스 크기 두배가됨

Allocated storage에 10 입력

 

 

 

 

 

 

여기는 실습을 못했다....

선택적 태스크 2: 고가용성 NAT 게이트웨이 구성

이 태스크는 선택 사항입니다. 실습 시간이 남아 있는 경우 이 태스크를 수행할 수 있습니다.

애플리케이션 서버는 프라이빗 서브넷에서 실행됩니다. 서버가 인터넷에 액세스해야 하는 경우(예: 데이터를 다운로드하기 위해) 요청은 NAT(네트워크 주소 변환) 게이트웨이를 통해 리디렉션되어야 합니다. 이 NAT 게이트웨이는 퍼블릭 서브넷에 있어야 합니다.

현재 아키텍처의 경우 퍼블릭 서브넷 1에 NAT 게이트웨이가 하나만 있습니다. 따라서 가용 영역 1에서 장애가 발생하면 애플리케이션 서버가 인터넷과 통신할 수 없습니다.

이 선택적 태스크에서는 다른 가용 영역에서 다른 NAT 게이트웨이를 실행하여 NAT 게이트웨이를 고가용성으로 만듭니다. 결과적으로 아키텍처도 고가용성이 됩니다.

 

 

Services 메뉴에서 VPC를 선택 -> 왼쪽 탐색 창에서 NAT Gateways를 선택

기존 NAT 게이트웨이가 표시됩니다. 이제 다른 가용 영역에 사용할 NAT 게이트웨이를 생성함

 

 

Create NAT gateway를 선택하고 다음 설정을 구성

• Name tag: Private Route Table 2
• VPC: Lab VPC
• Create를 선택한 후 Close를 선택

Private Route Table 2를 선택하고 유일하게 선택한 라우팅 테이블인지 확인

Routes 탭을 선택

 

현재, 단일 경로가 모든 트래픽을 _locally_로 리디렉션합니다.

이제 새 NAT 게이트웨이를 통해 인터넷 바운드 트래픽을 전송할 경로를 추가합니다.

 

Edit routes를 선택한 후 다음 설정을 구성합니다.

• Add route를 선택합니다.
• Destination: 0.0.0.0/0

• Target: NAT Gateway를 선택한 다음 NATGateway1 항목이 아닌 nat- 항목 선택(이 지침 위의 Details 버튼 아래에 있음)

• Save routes를 선택한 후 Close를 선택합니다.
• 이 지침 위에 있는 Details 버튼 아래에 나열된 NAT 게이트웨이는 퍼블릭 서브넷 1용입니다. 지금은 다른 NAT 게이트웨이를 사용하도록 경로 테이블을 구성하는 중입니다.

 

 

Subnet Associations 탭을 선택 -> Edit subnet associations를 클릭 -> Private Subnet 2를 선택 -> Save를 선택