aws 고가용성 환경 생성 (Arch-4)

핵심 비즈니스 시스템은 고가용성 애플리케이션으로 배포해야 한다. 그래야 일부 구성 요소에 장애가 발생해도 정상적으로 운영될 수 있다. AWS에서 고가용성을 달성하려면 여러 가용 영역에서 서비스를 실행하는 것이 좋다. 많은 AWS 서비스가 로드 밸런서처럼 본질적으로 고가용성이거나 여러 가용 영역에서 Amazon EC2 인스턴스를 배포하는 것처럼 고가용성으로 구성할 수 있다. 그림은 2개의 가용 영역에 퍼블릭 및 프라이빗 섭브넷이 있다. 인터넷 게이트웨이는 퍼블릭 서브넷에 연결된다. NAT 게이트웨이는 퍼블릭 서브넷 중 하나에 있음 Amazon RDS 인스턴스는 프라이빗 서브넷 중 하나에 있다.

이미 생성된 VPC의 구성을 검토하겠다. Services에서 VPC를 클릭한다.

왼쪽 탐색 창의 Filter by VPC에서 Select a VPC 상자를 클릭하고 Lab VPC를 선택한다. 그러면 콘솔이 Lab VPC에 연결된 리소스만 표시하도록 제한한다.

왼쪽 탐색 창에서 Your VPCs를 클릭하고 사용자가 생성한 Lab VPC를 볼 수 있다. CIDR 열에 10.0.0.0/20값을 볼 수 있다. 이는 해당 VPC가 10.0.0.0~ 10.0.15.255사이에 IP 4096개를 포함한다는 것이다.

탐색 창에서 Subnets를 클릭하면 Public Subnet 1을 볼 수 있다. IPv4 CIDR열에서 10.0.0.0/24값을 볼 수 있다. 이는 해당 서브넷이 10.0.0.0 10.0.0.255사이의 IP 256개를 포함한다는 뜻이다. 가용 영역열에서 이 서브넷이 존재하는 가용 영역을 볼 수 있다. Public Subnet 1을 클릭한다.

페이지 하단에 세부정보를 표시한다.

Route Table 탭을 클릭한다. 여기에서 이 서브넷의 라우팅에 대한 세부 정보를 볼 수 있다. 첫번째 항복은 VPC의 CIDR 범위(10.0.0.0/20) 내를 목적지로 하는 트래픽이 VPC 내에서 라우팅되도록 지정한다. 두번째 항목은 인터넷(0.0.0.0/0)으로 향하는 트래픽이 인터넷 게이트웨이로 라우팅되도록 지정한다.

NACL 탭을 클릭한다. 여기에서 서브넷과 연결된 네트워크ACL을 볼 수 있다.

왼쪽 탐색 창에서 Internet Gateways를 클릭한다. (이미 실습 VPC와 연결 됨)

Inventory DB를 선택한다. 이는 데이터베이스 수신 트래픽을 제어하는데 사용되는 보안 그룹이다. 아래 세부내용을 확인하겠다.

Inbound 규칙 탭을 클릭한다. 이는 VPC 내 어디에서나 인바운드 MySQL/Aurora 트래픽을 허용한다. 나중에 어플리케이션 서버의 트래픽만 허용하도록 이를 수정한다.

아웃바운드규칙 탭을 클릭한다.(기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용!)

Application Load Balancer을 생성하겠다. 고가용성 애플리케이션을 구축하려면 여러 가용 영역에서 리소스를 시작하는 것이 좋다. 가용 영역은 동일 리전 내에서 물리적으로 분리된 데이터 센터이다. 여러 가용 영역에서 애플리케이션을 실행하면 데이터 센터에서 장애가 발생한 경우에 뛰어난 가용성을 제공한다. 여러 애플리케이션 서버에서 애플리케이션이 실행되는 것을 고려하면 해당 서버 간에 트래픽을 분산할 수 있는 방법이 필요하다. 이는 인스턴스 상태를 확인하여 정상인 인스턴스에만 요청을 전송하는 로드 밸런서를 사용하여 달성할 수 있다.

서비스 메뉴에서 EC2를 클릭한다.

탐색 창에서 로드 밸런서를 클릭한 후 로드 밸런서를 생성하겠다.

여러 유형의 로드 밸런서가 표시된다. 애플리케이션이기 떄문에 API에서 생성하겠다.

이름을 Inventory-LB를 입력하겠다.

가용 영역 섹션으로 스크롤하여 다음을 수행한다. VPC는 Lab VPC를 선택한다. 로드 밸런서가 사용해야 하는 서브넷을 지정해야 한다. 서로 다른 가용 영역에서의 Public Subnet의 로드 밸런서를 적용할 것이므로 Public Subnet 1, 2를 각각 선택한다.

개선된 보안성을 위해 HTTPS를 사용하라는 경고 메시지가 출력된다.(실습에서는 필요X)

이제 모든 수신 HTTP및 HTTPS트래픽을 허용하는 보안 그룹을 생성한다. 이름과 설명을 입력한 후 규칙을 추가한다. HTTP, HTTPS를 Anywhere로 설정한다. 이 설정을 통해 로드 밸런서에서 모든 수신 HTTP, HTTPS 요청을 수락한다.

Target Group은 로드 밸런서로 들어오는 트래픽을 보낼 위치를 정의한다. 애플리케이션 로드 밸런서는 수신 요청 URL을 기반으로 여러 대상 그룹에 트래픽을 보낼 수 있다. 예를 들어, 다른 서버로 모바일 앱의 요청을 보낼 수 있다. 웹 애플리케이션은 하나의 대상 그룹만 사용한다. 이름을 Inventory-App으로 하겠다.

밑에 부분에 고급 상태 확인 설정을 확장한다. 애플리케이션 로드 밸런서는 모든 인스턴스에서 Health Checks를 자동으로 수행하여 요청에 응답하는지 확인한다. 기본 설정이 권장되지만 실습에서 사용할 떄 더 빠르게 설정한다. Healthy threshold :2, Interval : 10으로 설정하였다. 즉 상태 확인은 10초마다 수행되고 인스턴스가 한 행에서 두 번 올바르게 응답하는 경우 정상으로 간주하겠다는 뜻이다.

타겟은 로드 밸런서의 요청에 응답하게 될 개별 인스턴스이다. 아직 웹 애플리케이션 인스턴스가 없기 떄문에 이 단계는 건너 뛴다. NEXT 클릭!

설정 검토하고 로드밸런서를 생성한다. 로드 밸런서가 백그라운드에서 프로비저닝 된다.

Auto Scaling 그룹을 생성하여야 한다. Amazon EC2 Auto Scailing은 사용자가 정의한 정책, 일정 및 상태 확인에 따라 자동으로 Amazon EC2 인스턴스를 시작하거나 종료하도록 설계된 웹 서비스이다. 또한 여러 가용 영역에 인스턴스를 자동으로 분산하여 고가용성 애플리케이션을 생성할 수 있다. 프라이빗 서브넷에 Amazon EC2인스턴스를 배포하는 Auto Scaling 그룹을 생성한다. 프라이븟 서브넷의 인스턴스는 인터넷에서 엑세스할 수 없기 떄문에 애플리케이션을 배포하기 위한 모범 사례 보안이다. 대신 사용자가 로드밸런스에서 요청을 보내면 해당 요청을 프라이빗 서브넷에 있는 Amazon EC2 인스턴스에 전달한다.

탐색 창에서 Auto Scailing Groups를 클릭한다.

오토 스케일링 그룹 생성을 클릭한 후 시작하기를 선택한다.

먼저 Auto Scailng에서 시작해야 하는 인스턴스 유형을 정의하는 시작 구성을 생성한다. 이 인터페이스는 Amazon EC2 인스턴스를 시작하는 것과 비슷하지만 인스턴스를 시작한다기 보다는 나중에 사용하기 위해 구성을 저장하는 것뿐이다.

AMI는 LINUX 이미지 LIUNX 2 AMI 선택한다.

인스턴스 유형은 t2.micro 선택한다.

이름과 IAM 역할을 입력해준다.

고급 세부 정보 아래 User Data에 실행 값을 입력하여 준다. (앱, 웹 설치 활성화)

#!/bin/bash

# Install Apache Web Server and PHP

yum install -y httpd mysql

amazon-linux-extras install -y php7.2

# 실습 파일 다운로드

wget https://us-west-2-tcprod.s3.amazonaws.com/courses/ILT-TF-100-ARCHIT/v6.3.4/lab-2-webapp/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

스토리지는 기본 설정 사용하겠다.

기존에 있던 보안 그룹은 Inventory-APP을 선택한다.

인스턴스에 연결할 수 없다는 경고 메시지가 표시된다. 인스턴스에 연결하지 않을 것이므로 무시해도 된다. 모든 구성은 사용자 데이터 스크립트를 통해 완료된다.         

기존에 있는 키페어를 사용하며 시작 구성을 생성한다. 만일 Launch Configuration을 만들지 않고 직접 Auto Scailing 그룹 생성 구성 화면으로 바로 이동하게 되면 Launch Configuration에서 what to launch(시작할 항목)을 정의하는 동안 Auto Scaling group에서 리소스를 시작할 위치를 정의한다.

오토 스케일링 그룹이름을 설정한다. 그룹 크기는 인스턴스 2개로 설정했다. 네트워크는 실습 VPC인 Lab VPC로 설정한다. Subnet은 프라이빗 서브넷 1과 프라이빗 서브넷 2를 선택한다.

고급 세부 정보 확장해서 로드 밸런싱을 선택하고 타겟 그룹은 Inventory-APP을 선택한다. 그러면 오토 스케일링 그룹에서 앞서 만든 Inventory 보안 그룹의 일부로 새 EC2 인스턴스를 등록하라는 메시지가 표시된다. 로드 밸런서가 이 대상 그룹에 있는 인스턴스로 트래픽을 전송한다.

실습에서는 항상 2개의 인스턴스를 유지하여 높은 가용성을 보장한다. 애플리케이션이 다양한 트래픽 부하를 수신할 것으로 예상되는 경우 인스턴스를 시작/종료할 시기를 정의하는 스케일링 정책을 생성할 수 있다. 하지만 실습의 인벤토리 애플리케이션에선 필요하지 않다.

알람은 구성하지 않겠다.

태그를 구성하겠다. 그러면 오토스케일링 그룹에 이름으로 태그가 지정되고 오토 스케일링 그룹에서 시작한 EC2 인스턴스에도 나타난다. 그러면 어떤 애플리케이션에 어떤 Amazon EC2 인스턴스에 연결되어 있는지 더 쉽게 식별할 수 있다.

검토한 후 오토스케일링 그룹을 생성한다.

Desired(필요한) 수량은 인스턴스 2개이며, 오토 스케일링에서 2개의 인스턴스를 시작하여 원하는 수량에 도달하려고 시도한다. Min 및 Max(최대) 역시 2로 설정되어 있으므로 장애가 발생하는 경우에도 오토 스케일링에서 항상 2개의 인스턴스를 제공하려고 시도한다. 애플리케이션이 2개의 가용영역에서 실행되며 오토 스케일링이 인스턴스 또는 가용 영역에서 장애가 발생하는 경우에도 해당 구성을 유지한다. ( 인스턴스가 2개로 올라올려면 시간이 좀 걸린다 새로고침을 통하여 업데이트하여 확인!)

배포한 어플리케이션은 3티어 아키텍처이다. 이제 보안 그룹을 구성하여 다음 계층을 적용한다. (그림 참고!)

로드 밸런서를 생성할 떄 이미 Load Balancer security group(로드 밸런서 보안 그룹)을 구성했다. 모든 수신 HTTP 및 HTTPS 트래픽을 허용한다. 로드 밸런서는 들어오는 요청을 타겟 그룹으로 전달하도록 구성되어있다. 오토 스케일링이 새로운 인스턴스를 시작하면 해당 인스턴스를 대상 그룹에 자동으로 추가한다. 애플리케이션 보안 그룹은 로드밸런스에서 수신되는 트래픽만 허용하도록 구성한다.

왼쪽 탐색창에서 Security Groups(보안 그룹)를 클릭한다.

Inventory-APP을 선택한다.

페이지 하단부에 있는 인바운드 탭을 클릭한다. 보안그룹은 현재 비어 있다. 이제 로드 밸런서에서 수신되는 HTTP 트래픽을 허용하는 규칙을 추가한다. 로드 밸런서는 HTTP를 통해 HTTPS 요청을 전달하도록 구성되었기 때문에 HTTPS 트래픽을 구성할 필요가 없다. 편집을 클릭한다. 애플리케이션 서버가 로드밸런스 트래픽을 수신해야 한다.

TYPE을 HTTP로 설정하고 source을 sg-를 입력하여서 Inventory-LB를 선택한다.

이제 애플리케이션 서버에서 수신되는 트래픽만 허용! Inventory-DB를 선택한다.

인바운드 탭에서 Edit를 클릭하고 다음을 구성한다.

기존의 Custom을 지우고 sg-입력하여서 Inventory-APP을 선택한다. 이제 애플리케이션 서버에서 들어오는 트래픽만 허용함으로써 3티어 보안이 구성되었으며 티어에 있는 각 요소는 위 티어의 트래픽만 허용한다. 또한 프라이빗 서브넷을 사용한다는 것은 인터넷과 사용자의 애플리케이션 리소스 사이에 두 가지 보안 장벽이 있음을 의미한다. 이는 다중 보안 계층을 적용하는 모범 사례와 일치한다.

이제 애플리케이션을 테스트해야한다. 웹 애플리케이션이 실행 중인지 고가용성인지 확인해야하는 테스트를 한다.

탐색 창에서 Target Groups를 클릭한다.

Inventory-APP 인스턴스 그룹이 표시된다.

페이지 하단부에 있는 Targets탭을 클릭한다.

등록된 타겟이 2개가 표시되어야 한다. Status열에는 인스턴스에 대해 수행된 로드 밸런서 상태 확인 결과가 표시된다. 두 인스턴스의 상태가 healthy로 나타나야 한다.

탐색 창에서 로드밸런스를 클릭한다. 창 하단부에 있는 Description탭에서 DNS Name을 클립보드에 복사한다. DNS 이름은 inventory-LB~~~~~~과 유사하고 옆에 파일 두 장있는 모양을 누르면 저절로 복사가 된다.

새 웹 브라우저 탭을 열고 클립보드에 복사한 DNS 이름을 붙여 넣고 ENTER키를 누른다. 로드 밸런스가 Amazon EC2 인스턴스 중 하나로 사용자의 요청을 전달했다. 인스턴스 ID와 가용 영역이 웹 페이지 하단에 표시된다. 가용 영역 2b에 있는 인스턴스가 동작했다.

웹 브라우저를 새로고침해서 페이지를 다시 로드 했다. Instance ID와 가용 영역이 바뀌었다. 두 개의 인스턴스가 로드 밸런스로 동작함을 확인할 수 있다. 인터넷에 연결된 공용 서브넷에 있는 로드밸런서에 요청을 보냈다. 로드 밸런서는 공용 서브넷에 있는 Amazon EC2 인스턴스 중 하나를 선택했고 이 곳으로 요청을 전달했다. 그 후 Amazon EC2 인스턴스는 로드 밸런서의 웹 페이지로 반환 되었고, 이를 사용자의 웹 브라우저로 반환!!!!

애플리케이션은 고가용성이 되도록 구성되었다. 탐색 창에서 인스턴스를 클릭한다.

고가용성을 테스트하려면 인스턴스 중 아무거나 하나를 종료하여서 입증하겠다. 한 인스턴스를 선택하여서 Actions에 인스턴스 상태 -> 종료를 클릭한다.

인스턴스가 종료되었음을 확인할 수 있다.

웹 페이지를 새로고침해도 동일한 페이지만이 나타남을 확인할 수 있다.

몇 분 후에 오토 스케일링도 인스턴스 장애를 확인한다. 오토 스케일링은 2개의 인스턴스를 실행하도록 구성되었기 때문에 오토 스케일링이 자동으로 대체 인스턴스를 시작한다. 종료된 인스턴스 외에 새 인스턴스가 하나 생성됨을 확인할 수 있었다. 이를 통해 현재 사용자의 애플리케이션이 다시 고가용성 상태를 유지함을 확인할 수 있었다.

다시 두 애플리케이션 서버가 작동함을 확인할 수 있다.

Stop 상태도 궁금하여 인스턴스 하나를 stop시켜보았다. 그 결과 인스턴스가 stop되어도 2개를 유지하기 위해 인스턴스가 하나 더 생겨남을 확인할 수 있다.

Stop된 인스턴스를 다시 start하면 어떻게 될까 궁금했다. 생성된 인스턴스가 사라지나 어떻게 두 인스턴스를 유지하나 궁금했다. 인스턴스를 start했다. 그렇게 하면 stop하고 start한 인스턴스가 강제로 종료된다. 그렇게 두 인스턴스를 유지함으로써 고가용성으로 애플리케이션 서버를 작동시킴을 확인할 수 있었다. Desire, min, max값이 모두 2로 설정하여서 무조건 인스턴스를 2개로 유지한다.

데이터베이스를 고가용성으로 만들어보겠다. 어플리케이션 아키텍처는 고가용성이다. 하지만 Amazon RDS 데이터베이스는 여전히 하나의 데이터베이스 인스턴스에서만 작동하고 있다. 과제에서는 데이터베이스를 여러 가용 영역에서 실행하여 고가용성을 만들겠다.

서비스에서 RDS를 클릭한다.

탐색 창에서 Database를 클릭한다.

생성된 DB inventory-db를 클릭한 후 Modify(변경)을 클릭한다.

Multi-AZ deployment에서 YES를 선택한다. DB 인스턴스 클래스는 db.t2.small을 설정한다. 그러면 인스턴스 크기가 두배로 늘어난다. 스토리지 유형은 프로비저닝된 IOPS를 선택한다. Provisioned IOPS에 숫자를 넣어준다. Allocated storage에 200 입력(db 할당 공간을 두배로 늘린다.) 그 후 Continue를 클릭한다.

Multi-AZ deployment는 여러 데이터 센터에서 실행하도록 데이터베이스를 변환하는 데 필요한 유일한 단계이다. 이는 데이터베이스가 여러 인스턴스에 분산된다는 뜻이 아니다. 정확히 말하면 모든 요청을 처리하는 하나의 인스턴스는 Master이다. 또 다른 인스턴스가 Secondary 인스턴스로 시작되는데, 마스터에 장애가 발생할 경우 이를 대신한다. 애플리케이션은 데이터베이스와 동일한 DNS이름을 계속 사용하지만 연결은 현재 활성 상태인 데이터베이스 서버로 자동 리디렉션 한다. 속성을 변경하여 Amazon EC2 인스턴스를 확장할 수 있는 것과 마찬가지로 Amazon RDS 데이터베이스도 확장할 수 있다.

수정 예약에서 즉시 적용을 선택한 후 인스턴스 수정 클릭한다.

변경사항이 적용되는 동안 데이터베이스는 수정 중 상태가 됩니다.

고가용성 NAT 게이트웨이 애플리케이션 서버는 프라이빗 서브넷에서 실행되고 있다. 인터넷에 엑세스해야 하는 경우 요청은 퍼블릭 서브넷에 있는 NAT 게이트웨이를 통해 리디렉션 되어야 한다. 현재 아키텍처에는 Public Subnet 1에 NAT 게이트웨이 하나만 있다. 즉 가용 영역 1에서 장애가 발생한 경우 애플리케이션 서버가 인터넷과 통신할 수 없다. 이런 문제가 발생한 경우 다른 가용 영역에 있는 또 다른 NAT 게이트웨이를 시작하여 NAT 게이트웨이를 고가용성으로 만들게 된다. 최종 아키텍처는 고가용성이 된다.

서비스에서 VPC를 클릭한 후 탐색 창에서 NAT 게이트웨이를 클릭하면 기존 NAT게이트웨이가 표시된다. 다른 가용 영역에도 생성하기 위해 NAT 게이트웨이 생성 클릭한다.

오른쪽에 생성하므로 Subnet : PublicSubnet2로 생성한다. Create New EIP 클릭한 후 NAT 게이트웨이를 생성한다.

라우팅 테이블 편집을 클릭한 후 라우팅 테이블을 생성한다.

(이제 트래픽을 새 NAT 게이트웨이로 리디렉션하는 새 라우팅 테이블을 생성한다.)

Private Route Table 2이름 태그를 입력하고 VPC를 설정한 후 생성한다.

생성한 프라이빗 라우팅 테이블2를 선택한다.

Routes 탭을 클릭한다. 현재는 모든 트래픽을 로컬로 보내는 하나의 라우팅이 있다. 이제 새 NAT 게이트웨이를 통해 인터넷 바운드 트래픽을 보내는 라우팅을 추가한다. 경로편집을 진행한다.

Add routes를 통해 목적지를 0.0.0.0/0으로 설정하고 Target은 NAT Gateway를 선택하고 이 지침 왼쪽에 나와 있지 않은 nat-항목을 선택한다. (기존의 것 X) 경로 저장한다. 다른 NAT 게이트웨이를 사용할 라우팅 테이블을 구성하고 있다.

서브넷 연결 탭을 클릭한 후 서브넷 연결 편집을 클릭한다.

프라이빗 서브넷 2를 선택하고 저장한다.

그렇게 되면 이제 프라이빗 서브넷 2의 인터넷 바운드 트래픽을 동일한 가용 영역에 있는 NAT 게이트웨이로 보낸다. 사용자의 NAT 게이트웨이는 고가용성이 되었다. 한 AZ의 장애가 다른 AZ에 있는 트래픽에 영향을 미치지 않는다. (혹시나 모를 앱 서버의 아웃바운딩을 위해 미리 만들어 둔다.) NAT 게이트웨이가 없다고 서비스가 중단되거나 그러지는 않는다.