AWS 다중 서버 환경 구성

Contents

• Introduction

• AWS Auto Scaling 그룹

  • 자원 사용량 기준 자동 조정
  • 시간 기준 자동 조정
• AWS Auto Scaling 구성 개요

• Auto Scaling 그룹 생성

  • Create AMI Image
  • Create Launch Template
  • Create Auto Scaling Group
  • Scale-up 테스트

• Elastic Load Balancer를 이용한 트래픽 분산

  • 대상 그룹
  • Health Check

  • Auto Scaling Group, Target Group, ELB 구성

    • ELB 설정 및 생성
• 장애 조치 아키텍쳐 구성
• Review
• Resource

Introduction

Intro to Cloud Computing, Server Arichtecture, Configuring Linux Web Server란 글을 쓰며, 기본적인 운영 서버 구성 및 클라우드 컴퓨팅의 기초적 개념들에 대해 알아봤습니다.

Intro to Cloud Computing 글에서 EC2에 IAM Role을 적용해 인스턴스 초기 실행 시 nginx를 설치 후 정적 페이지를 S3에서 가져와 대체 후 배포해 보았습니다.

Configuring Linux Web Server에서는 직접 가상 컴퓨터에 Ubuntu를 설치 후 서버를 구축해 보았습니다.

실제 대부분의 운영 환경에서는 많은 트래픽과 서버 장애에 대비해서 한 대의 서버 인스턴스가 아닌 여러 대의 서버 인스턴스로 서비스를 합니다.

이번 글을 통해 위 그림의 Auto Scaling Group에 해당하는 부분에 대해 알아보고자 합니다. Auto Scaling Group은 AWS에서 제공하는 자동 다중 서버 서비스입니다. 이 서비스를 이용해 늘어난 트래픽 감당을 위해 서버의 수를 늘려 대응하는(scale-out) 다중 서버 환경에 대해 알아보겠습니다. 또한, 장애로 한 대의 서버가 정지 돼도 다른 서버들이 이를 대신할 수 있도록 하는 방법에 대해서도 알아보도록 할게요.

AWS Auto Scaling 그룹

Auto Scaling 그룹은 같은 사양, 같은 환경을 가진 똑같은 EC2 인스턴스 그룹입니다. AWS의 이 서비스는 인스턴스의 수를 특정 조건에 따라 자동으로 늘리고 줄여줍니다. 때문에, 실시간 트래픽 등의 변수를 반영해 안정적으로 서비스를 운영할 수 있고 비용도 절감할 수 있습니다.

자원 사용량 기준

Auto Scaling 그룹은 자원 사용량을 기준으로 자동 조정할 수 있도록 설정이 가능합니다. 예로, 평균 CPU 사용량이 10분 동안 90% 이상을 넘으면 인스턴스 1대를 더 추가하도록 설정할 수 있습니다.

시간 기준 자동 조정

자원 사용량 외에 시간으로도 조정 정책을 설정할 수 있습니다. 이커머스와 같이 자정에 사람들이 몰리는 서비스는 특정 시간대에 서버를 늘려야 하는 작업이 필요할 수 있습니다. Auto Scaling 그룹을 사용해 특정 시간 기준으로 인스턴스의 수를 늘리도록 설정할 수 있습니다.

AWS Auto Scaling 구성 개요

Auto Scaling 그룹 생성을 위해 우선 자동으로 생성할 EC2 인스턴스를 미리 선정해야 합니다. 선정한 EC2 인스턴스의 스냅샷을 생성해 AMI를 만듭니다. 생성한 AMI를 이용해 인스턴스를 띄울 때의 환경(사양, 보안그룹, 네트워크 설정)을 시작 템플릿에 미리 정의해 둡니다. 그리고 마지막으로 이 시작 템플릿을 이용해 Auto Scaling Group을 생성합니다.

Auto Scaling 그룹 생성

Auto Scaling 그룹 관련 개념을 살펴보았고, 이제 AWS에서 직접 Auto Scaling Group을 생성해 보겠습니다. Auto Scaling 그룹은 공식 문서 AWS EC2 Auto Scaling 사용 설명서를 참고해 생성할 수 있습니다.

1. AMI 이지미 생성

여기서는 그룹 생성 방법을 간략하게 살펴볼게요. 우선 스냅숏 생섯을 안전하게 하기 위해 생성할 EC2 인스턴스를 중지 시킵니다. 그리고 해당 인스턴스 우클릭 후 이미지 생성을 클릭합니다. 아래 화면에서 이미지로 만들 서버가 사용할 디스크 종류 및 용량을 선택할 수 있습니다.

이미지 이름 및 설정 후 이미지를 생성합니다.

2. 시작 템플릿 생성

시작 템플릿은 Auto Scaling 그룹이 인스턴스 생성 시 관련 설정에 대한 사항을 미리 정의해 두는 것입니다. 그래서, 일반적으로 사양, 보안그룹, 네트워크 등과 같이 EC2 생성 시 설정하는 작업들과 비슷한 작업을 하게 됩니다.

위 사진은 시작 템플릿 생성 시 앞에서 생성한 AMI 이미지를 추가한 예시입니다. 기본적으로 템플릿 이름, AMI ID, 인스턴스 타입, 보안그룹, key-pair 등의 설정을 지정해 줍니다. 해당 사항들을 설정 후 시작 템플릿을 생성합니다.

3. Auto Scaling Group 생성

기존의 EC2 인스턴스를 이용해 AMI Image를 생성하고, 이를 이용해 시작 템플릿을 만들었습니다. 이제 Auto-Scaling Group을 생성하면 됩니다. 우선 그룹 명과 시작 템플릿을 설정해 줍니다.

서브넷을 통해 인스턴스들을 어떤 네트워크 망에 띄울지 설정할 수 있습니다. 여기서는 ap-northeast-2a, ap-northeast-2c를 기본값으로 설정했습니다. 생성한 인스턴스의 반은 서울 리전 a 가용 영역에, 나머지 반은 서울 리전 c 가용 영역에 생성하게 됩니다.

다음으로 Auto scaling 그룹의 사이즈 및 scaling policy를 설정해 줍니다. 여기서는 Auto Scaling 그룹 내에서 CPU 사용률 80% 기준으로 인스턴스의 수가 최소 1대에서 최대 2대까지 자동으로 변하도록 설정했습니다.

설정을 마치고 그룹 생성을 하면 아래와 같이 Auto Scaling Group이 생성된 것을 확인할 수 있습니다.

Scale Up 테스트

Auto Scaling Group 생성을 마쳤습니다. 이제 해당 그룹 인스턴스에 접속 해 CPU 사용률을 높여 설정한 Scaling Policy에 맞게 인스턴스가 scale-up 하는지 확인해 보도록 하겠습니다. CPU 사용량을 높이기 위해 stress 애플리케이션을 사용하겠습니다.

stress를 사용해 원하는 CPU의 수를 원하는 시간만큼 100% 사용하게 할 수 있습니다. 저는 EC2에 ubuntu가 설치 돼 있으므로 아래와 같이 설치 후 stress를 실행시켰습니다.

이 상태로 5 ~ 10분 가량 기다려 보면 인스턴스 한 대가 자동으로 추가된 것을 확인할 수 있습니다.

Auto Scaling 그룹 생성 시 여러 설정이 필요한 것 같아 보이지만, 서버 증강 시 사람이 할 일을 미리 설정해 대신하게 하는 편리한 프로그램입니다.

Auto Scaling 그룹 없이 직접 서버를 추가하려면, 위에서 한 작업, AMI 생성, 인트턴스 타입, 보안그룹, 네트워크 설정 등의 작업을 하며 진행해야 합니다. 이 과정을 시작 템플릿에 저장하고 Auto Scaling 그룹이 사용할 수 있게 한 것입니다.

Scale-up을 위한 자원 사용량에 대한 기준도 기준값을 설정해 사람이 모니터링 하지 않아도 기준에 맞춰 조정되도록 작업을 해 둔 것입니다.

Elastic Load Balancer를 이용한 트래픽 분산

ELB는 로드 밸런서가 관리하는 서버에게 요청을 골고루 전달해 주는 AWS의 서비스 입니다. 클라우드 서비스를 이용하지 않으면 L4 스위치와같은 장비를 직접 구매해 관리해야 합니다. AWS를 통해서 특정 인스턴스 또는 Auto Scaling 그룹에 요청을 전달하도록 설정할 수 있습니다.

AWS 로드 밸러서도 그 자체로 서버이지만 AWS에서 내부적으로 관리를 하기 때문에 직접 SSH로 접속할 수는 없습니다. 로드 밸런서는 너무 많은 요청을 처리하고 있거나 동작하고 있지 않는 서버에는 요청을 보내지 않습니다.

대상 그룹

대상 그룹(Target Group)은 로드 밸런서가 요청을 전달할 서버 그룹이라 생각할 수 있습니다. 대상 그룹에는 인스턴스나 Auto Scaling Group을 포함할 수 있습니다. 로드 밸런서에서 요청한 포트에 따라 다양한 대상 그룹이나 인스턴스로 요청을 전달할 수 있습니다.

예로, 80번이나 443번 포트로 요청이 온 경우 A 대상 그룹으로 전달하고, 3000번 포트로 온 요청은 B 대상 그룹으로 전달할 수 있습니다.

Health Check

로드 밸런서는 정삭적으로 작동하고 있는 서버에만 요청을 전달합니다. 서버가 정상적으로 작동하는지 확인을 하기 위해 로드 밸런서는 서버의 상태를 주기적으로 확인합니다.

예로, 상태 확인 경로를 GET /health 요청에 HTTP 상태 코드 200으로 응답하도록 설정하면, 각 서버의 GET /health로 서버 상태를 주기적으로 확인합니다.

서버의 정상/비정상 상태를 판단하기 위해 검사 주기를 설정할 수도 있고, 연속된 응답 횟수를 기준으로 판단할 수 있도록 설정할 수도 있습니다.

만약, 애플리케이션까지 안 가고 nginx 서버와 같은 웹 서버만 작동해도 정상이라고 판다해도 된다면 nginx에서 상태 코드 200을 응답하도록 처리를 할 수도 있습니다.

Auto Scaling Group, Target Group, ELB 구성

그럼 Auto Scaling Group의 여러 서버를 대상으로 요청을 전달할 수 있도록 대상 그룹과 ELB를 설정해 보도록 하겠습니다. 앞서 생성한 Auto Scaling Group을 대상 그룹으로 등록하고 로드 밸런서가 받은 요청을 그룹 내 서버로 전달하는 환경을 구성하고자 합니다.

ELB 설정 및 생성

HTTP, HTTPS 요청을 받을 것이기에 EC2 서비스에서 Application Load Balancer를 생성합니다. 첫 화면에서 로드 밸런서의 이름, 프로토콜과 포트, 가용 역역을 설정할 수 있습니다. HTTP 80 포트가 기본 설정이기에 그대로 진행하고, 가용 영역을 ap-northeast-2a, ap-northeast-2c로 지정해 주었습니다.

보안 그룹 설정까지 하고 다음으로 넘어가면, 로드 밸런서가 클라이언트로부터 받은 요청을 전달할 대상 그룹을 설정하는 화면이 나옵니다. 아직 대상 그룹을 생성하지 않았기 때문에 새로운 대상 그룹을 선택합니다.

상태 검사 경로를 /health로 추가해 주어서, 로드 밸런서가 health check를 주기적으로 할 수 있도록 합니다.

다음을 클릭하면 대상 등록 화면이 나옵니다. 우리는 인스턴스 말고 앞서 생성한 Auto Scaling Group을 등록해, 새 인스턴스가 생성될 때마다 자동으로 대상 그룹에 추가하려고 하니, 해당 화면에서는 인스턴스를 등록하지 않고 다음으로 넘어가 로드 밸런서를 생성합니다.

Auto Scaling Group을 대상 그룹에 등록

생성한 로드 밸런서의 대상 그룹에 Auto Scaling Group을 등록하기 위해, Auto Scaling 그룹 메뉴로 이동합니다. 해당 Auto Scaling Group의 세부 정보(Details) 탭에서 대상 그룹을 등록해 줍니다.

등록 후 다시 로브 밸런싱 메뉴의 해당 대상 그룹에서 대상(Targets)를 확인해 보면 위 Auto Scaling Group의 인스턴스가 등록된 것을 확인할 수 있습니다.

로드 밸런서가 요청을 Auto Scaling Group의 서버로 잘 전달하는지 확인을 해 보려면, 등록한 로드 밸런서의 DNS 주소로 접속해 보면 확인할 수 있습니다.

ELB 주소로 브라우저에서 접속해 요청이 잘 처리되는 것을 아래와 같이 확인할 수 있습니다.

장애 조치 아키텍쳐 구성

운영 서버의 일부에 장애가 발생했을 때 전체 시스템이 죽는 것이 아니라 예비 시스템이 즉시 요청을 대신할 수 있도록 조치를 취해야 합니다. 서버에 장애가 발생할 가능성은 다양하기 때문에 운영 서버는 2대 이상 띄워서 장애 조치가 가능하도록 해야 합니다.

위에서 살펴본 Auto Scaling Group과 로드 밸런서로 장애 조치를 구현할 수 있습니다. 로드 밸런서는 장애가 발생한 서버 인스턴스에는 클라이언트의 요청을 전달하지 않는 기능이 있습니다.

두 대의 서버로 운영을 하다 한 서버에 장애가 나는 경우 로드 밸런서가 정상적인 서버에만 요청을 보내는지 확인해 보려 합니다.

로드 밸런서 대상 그룹의 상태 검사(Health Check) 설정 페이지에서 Health Check 관련 아래 항목들을 설정할 수 있습니다.

테스트를 떠 빠르게 확인해 보려면 위 기본 설정의 값을 더 낮게 조정할 수도 있습니다.

그리고 Auto Scaling Group의 목표 용량(Desired Capacity)와 최소 용량(Minimum Capacity)를 모두 2로 수정해 인스턴스가 한 대 더 생성되도록 합니다.

각 인스턴스로 들어오는 요청 확인을 위해 nginx의 access.log를 실시간으로 확인해 보도록 합니다. 각 인스턴스에 SSH로 접속 후 /var/log/nginx 폴더로 이동 후 실시간 로그를 확인합니다.

tail -f access.log

그리고 장애 상황을 임의로 발생시키기 위해 두 대 중 한대의 nginx 서버를 강제로 종료시킵니다.

sudo service nginx stop

이후 로드 밸런서 DNS 주소로 접속하면 아래와 같이 에러 화면을 볼 수 있습니다.

하지만 몇 초 뒤 다시 접속해 보면 정상 작동하는 서버에서 다시 정상적으로 응답을 받습니다.

Review

이 글을 작성하며 Auto Scaling Group과 Elastic Load Balancer를 이용해 다중 서버 환경을 구성하는 방법에 대해 알아봤습니다. 로브 밸런서라는 레이어를 서버 앞에 둠으로써 단일 서버 환경에서는 할 수 없었던 스케일 아웃을 할 수 있었습니다. Auto Scaling 그룹을 요청에 따라 서버 수를 자동적으로 관리해 주기 때문에 비용 절감과 안정적인 서버 운영에 좋은 장치로 활용할 수 있습니다.

Resource

• Amazon EC2 Auto Scaling