AWS 소규모 아키텍트 (3) - Load Balancing과 AMI

Load Balancing에 대한 자세한 정보를 알고싶다면

AWS 소규모 아키텍트 (1) - AWS Service 톺아보기

EC2 제작 방법에 대해 알고싶다면

AWS 소규모 아키텍트 (2) - EC2 제작, EC2 Service

Elastic Load Balancing

우리는 하나의 EC2를 제작했습니다. 다시 말해 하나의 인스턴스를 제작한것이지요. 우리는 이를 서버로 이용할 것입니다.
그러나 정말 소규모의 아키텍트에서는 상관없지만, 어떤 이유로 인해 갑자기 트래픽이 증가하여 많은 사람들이 찾게 되는 것을 알게 되면 우리는 서버를 증설해야합니다.

마치, 수강신청을 하기 위해 9시가 되면 트래픽이 몰려 서버가 다운되는 현상을 방지하기 위함입니다. 따라서 트래픽 관리에 대한 부분은 모든 사용자가 불편함없게 서버를 사용할 수 있도록 도와주는 필수 요소입니다.

Load Balancing이란 예를 들어 A, B, C 서버가 각 100개의 트래픽을 담당할 수 있다고 할 때에 A(100), B(100), C(50) 이라고 하면 A와 B는 포화상태가 되어 더 이상 받을 수 없는 상태가 되어버립니다. 이 때에는 당연히 트래픽이 오게 되면 C서버에 보내야 하게 되겠지요. 이 뿐만 아니라 포화상태가 아니더라도, 하나의 서버가 바쁘게 되면 원활한 다른 서버에 일을 실어주어야 합니다. 이러한 모든 일들을 관장하는 녀석이 바로 Load Balancer입니다.

Elastic Load Balancing (ELB)

하지만 서버를 1대 마련해놓은 상태에서 자동으로 서버가 증설되어 그 서버에 로드 밸런싱 하는 것은 아닙니다.

이미 구현되어 있는 서버안에서 모든 일이 이루어지게 됩니다. 즉, 우리는 그 서버들을 묶는 과정이 필요합니다. 그것을 바로 대상 그룹(target group)이라고 합니다.

우리는 이러한 Load Balancing을 위해 대상 그룹에 서버를 마련해놓아야 합니다. 즉, 위의 상황에서는 A, B, C가 대상 그룹에 속해있겠지요. 그러면 대상 그룹에 서버를 마련해보겠습니다.

 

들어가기 앞서

먼저 우리가 만든 인스턴스에는 정말 아무것도 다운되어 있지 않은 상태입니다. 오직 접속 테스트만 해본 것입니다.

로드 밸런서가 정말 수행 중인지에 대해 알아보려면 우리는 주소로 입력할 ip를 보면 될 것입니다. 예를 들어 A서버의 아이피가 1.1.1.1 이고 B서버의 아이피가 2.2.2.2라면, 로드밸런서에 의해 번갈아가면서 아이피가 출력되는 것을 보아야합니다.

따라서 서버는 실행되어야 하고, 온전히 실행 중인지에 대해 테스트를 해보기 위해 nginx를 서버에 설치하겠습니다. 또한 이를 AMI로 복제하여 여러 대의 nginx가 다운되어 있는 서버를 제작할 것입니다.

 

 

nginx 설치

1편의 마지막에서 우리는 EC2에 접속을 완료 후에 종료했습니다. 접속한 후에 다음 3가지의 명령어를 입력합니다.

sudo apt update
sudo apt install nginx
sudo systemctl start nginx

 

중간에 다음과 같은 명령어가 나오면 y를 입력해주세요

Do you want to continue? [Y/n] y

 

다음 사진이 나와도 건드리지말고 Enter만 눌러주세요

 

인바운드 규칙 편집

\우리는 인바운드 규칙 편집에 대해 2편에서 다루었습니다. 인바운드 규칙이란 외부에서(현재 우리) 인스턴스(현재 test-instance)에 접속할 때 인스턴스가 그 트래픽을 송신하는 규칙입니다.

EC2 만드는 방법에서 네트워크 보안 규칙에서 ssh에 대해 체크를 했지만 만약 http에 대해 체크하지 않았다면 위의 사진처럼 ssh으로만 접속이 가능합니다. 우리가 지금까지 ssh로 접속할 수 있었던 이유도 인바운드 규칙에서 ssh 포트가 열려있었기 때문입니다.

nginx서버는 기본적으로 http으로 만들어집니다. 그렇기 때문에 우리는 인바운드 규칙에 http 포트를 추가하는 순서가 필요합니다.
위의 사진에서 보안 그룹 아래에 있는 sg-0c ... 를 클릭해서 들어갑니다.

 

인바운드 규칙 편집에 들어갑니다.

 

인바운드 규칙을 추가하여 http으로 전체 ipv4에서 받도록 하겠습니다.

 

그 다음 인스턴스 정보에 있는 퍼블릭 IPv4 주소를 chrome창에 입력해주시기 바랍니다.

 

그러면 다음과 같은 화면이 나타나게 됩니다.

인바운드 규칙이 http가 있었다면 건드리지 않으셔도 됩니다!
ssh만 존재했다고 하면 http를 추가해주시기 바랍니다.

 

우리는 이를 통해 인스턴스 안에서 nginx를 설치했습니다! 하지만 이는 하나의 인스턴스에서 nginx를 설치한 것이며, 우리는 이와같은 행동을 반복해야 합니다. 서버에 접속하여 nginx 설치하고, 다른 서버도 만들고 nginx 설치하고..

현재는 세 줄의 명령어로 nginx를 설치했지만, 나중에 프로젝트의 규모가 거대해지면서 초기 세팅이 많은 시간이 소모될 때 이 방법은 매우 비효율 적이라는 것을 압니다. 따라서, 이 곳에서 나타나는 개념이 바로 Image입니다.

Image는 하나의 백업이라고 생각하시면 됩니다. (실제로 백업과 개념은 다릅니다.) 컴퓨터를 지키기 위해 많은 데이터나 정보들을 백업시키고, 문제가 발생했을 때 다시 백업본으로 돌아가는 것처럼, 이미지로 만들어 놓으면 우리가 구축한 환경에 대해 언제든 접근이 가능합니다. 즉, 지금 만들어놓은 인스턴스를 이미지로 제작해두어 놓고, 그곳에서부터 인스턴스를 생성하게 되면 많은 시간을 절약할 수 있습니다.

AMI

AMI는 Amazon Machine Images의 약어입니다.

우리가 인스턴스를 만들었던 그 곳으로 가봅시다.

 

 

이미지 제작

다음 화면에서 인스턴스에 우클릭을 하고 '이미지 및 템플릿' -> '이미지 생성'에 들어갑니다.

 

별 다른 설정을 하지않아도 이미지를 제작할 수 있습니다. 다음과 같이 설정한 후에이미지 생성을 누르고, 사이드 메뉴에서 AMI를 찾아 클릭합니다.

 

AMI 클릭

 

이미지 상태가 사용가능이 될 때 우클릭을 통해 AMI로 인스턴스 시작을 누를 수 있습니다.

 

혹여 http 트래픽 허용이 체크되어있지 않다고 하면 꼭 체크해주시기 바랍니다. 위의 과정에서 인바운드 규칙 편집을 직접적으로 만들어 주지 않아도 되는 과정입니다.

 

다음과 같이 3개의 인스턴스 환경이 만들어졌습니다.

다음은 이 3개가 바로 하나의 로드 밸런서에 의해 통제될 것이라는 것을 알려야 합니다. 즉, 이 3가지 인스턴스는 현재 nginx가 각 다운되어있는 상태이며, 하나의 로드 밸런서에 의해 nginx에 접근하는 길도 달라진다는 것을 의미합니다.

 

 

대상 그룹 설정

사이드메뉴에서 로드 밸런싱 아래 '대상 그룹'을 선택하고 Create target group을 선택하여 대상 그룹을 선택하겠습니다.

instance를 클릭하고, Target group name을 입력합니다. 이 그룹 이름은 3개의 인스턴스를 하나로 묶을 그룹 명을 의미합니다.

아래에는 프로토콜이 존재합니다. 80으로 지정하겠습니다.

여기서 80으로 지정하는 이유는 무엇일까요?

각 서버에 들어갈 때에 우리는 3.15.121.15 와 같은 방식의 ip를 그냥 입력해서 접속했습니다. 어떠한 포트의 정보도 없지요. 그러나 항상 생략되는 것이 있습니다. 그것이 바로 80번 포트입니다. 3.15.121.15 를 입력했다면 그것은 사실상 3.15.121.15:80을 입력한 것입니다. 그렇기 때문에 우리가 nginx 서버를 구현하고 그 안에 별다른 포트를 집어넣지 않아도 nginx의 기본 포트가 80이기 때문에 가능했던 것입니다.

앞으로 이 3개의 인스턴스는 로드밸런서에 의해 접속될 포트입니다. 하지만 로드밸런서는 이 대상 그룹에서 어느 포트로 연결해야 할지 알지못합니다. 따라서 각 인스턴스에 접속할 포트를 하나로 묶어 이를 통칭하는 것이며, 각 서버는 nginx에 의해 80번 포트로 구현되어있기 때문에 이 대상 그룹은 80번 포트로 지정됩니다.

위의 사진 중 프로토콜을 입력하는 이유가 바로 그것입니다!

 

나머지는 위와 같이 설정해주세요

 

 

다음으로는 Health checks를 입력합니다. 헬스체크는 로드밸런서에 의해 서버로 연결될 때 주기적으로 로드밸런서는 각 서버의 상태를 확인합니다. 즉, 주기적으로 요청을 보내 상태를 테스트한다는 것입니다.

우리는 어떤 경로도 없이 바로 '/'위에 nginx를 배치했기 때문에 health check를 분별할 수 있는 상태확인 경로는 /입니다. 

즉, 위와 같이 입력하고 넘어가주세요.

 

마지막으로 3개의 인스턴스를 모두 로드밸런서에 넣은 후에 다음으로 넘어가주세요.

 

 

로드 밸런서 생성

다음으로는 사이드메뉴에서 로드밸런서를 클릭하고 로드 밸런서 생성을 클릭하도록 하겠습니다.

 

우리는 Applcation Load Balancer를 이용합니다.

 

그러다 우리는 보안 그룹을 마주치게 됩니다.

EC2 생성할 때에도 인바운드 규칙, 아웃바운드 규칙을 이야기했습니다. 이 로드 밸런서도 보안 규칙에 의거하여 실행되기 때문에 우리는 보안 규칙을 제작해주어야 합니다. 하지만 따로 제작할 필요는 없어보이는군요, 이전에 ssh와 http을 열어둔 EC2를 제작하셨더라면 아마 보안 그룹에 그 두 개의 프로토콜로 인바운드 규칙이 정의되어 있는 보안 그룹이 존재할테니까요.

 

다음으로는 이 로드밸런서가 어떠한 타겟 그룹과 연관을 가질 것인지에 대한 선택이 나옵니다.

여기서 80번 포트가 또 나오기 시작합니다. 80번 포트가 무엇이기에 이렇게 자주 등장하는 걸까요?

그러나 우리는 앞으로 그 서버에 직접적으로 접근하지 않습니다. 로드 밸런서의 프로토콜로 접속할 것이고, 로드 밸런서가 간접적으로 그 서버에 연결시켜주는 방식으로 진행할 것이기 때문입니다. 그렇다면 로드 밸런서에도 접근할 포트가 필요로 하게 됩니다. 그것이 바로 여기에서 입력하는 80번 포트입니다.

만약 81번포트로 입력했다면? 이후에 로드밸런서에 생성되는 DNS에 마지막에 :81을 붙여야 할겁니다. 가령 naver.com:81 과 같은 방식으로 접근해야한다는 말이죠. 그렇기 때문에 우리는 생략할 수 있는 80번으로 지정해보도록 하겠습니다.

이후 설정은 모두 default로 놔두시고 로드밸런서를 제작해봅시다.

 

다음과 같이 로드밸런서가 제작되었습니다. 상태는 프로비저닝 중이라고 나와있으며 이것이 완료되면 바로 테스트해볼 수 있습니다.

 

다음과 같이 DNS이름이 나오는데 이 주소가 바로 로드 밸런서의 주소가 되며, 이것이 바로 알아서 트래픽을 분기시켜주는 기능을 수행하는 것입니다.

 

다음과 같이 확인할 수 있습니다. 그러나 로드 밸런서가 직접적으로 움직이는건지는 확인할 수가 없습니다.

다 동일한 화면이라 번갈아가면서 수행하고 있는 것인지에 대해 의문이 생기기 때문에 각 nginx의 index.html을 바꾸어 보았습니다. 직접 하지 않으셔도 됩니다. 각 index.html에는 자신의 아이피가 무엇인지 작성했습니다.

 

다음과 같이 어떤 랜덤한 방식이 아닌, 새로고침할 때마다 다음과 같은 순서로 등장하게 되었습니다. 이는 로드밸런서의 내부 알고리즘에 의해 결정되는 것이니 이해하지 않으셔도 됩니다.

 

이로써 로드밸런서를 구현해보았습니다. 입력해야 하는 포트도 여러 개 있었고 아직 다루어보지 않은 VPC나 서브넷의 개념도 있었습니다.

완벽히 따라한다면 문제될 것은 없지만, 각 순서에 따라 보안 규칙이 달라질 수도 있고 그에 따라서 로드밸런서가 이루어지지 않을 수도 있습니다. 꼭 한번 다시 살펴보시면서 빠진 것은 없는지 확인해주시기 바랍니다.

 

마지막으로 한번 사용한 인스턴스 + 로드밸런서 및 AMI, 보안그룹 등은 제거해주세요! 이후 테스트해볼 때에 헷갈릴 수도 있고, 특히나 인스턴스의 경우에는 과금의 위험이 있습니다. 무료로 750시간이 달마다 주어지며, 예를 들어 3개의 인스턴스가 켜져있는 상황이라고 하면 일주일만 방치해도 24 x 7 x 3 = 504시간의 시간이 소요됩니다. 인스턴스 뿐만 아니라 사용한 모든 서비스는 종료하는 것이 가장 안전합니다. 따라서 테스트가 종료되면 인스턴스도 함께 종료하는 습관을 길러주세요.(실제 개발할때도 그런 습관 가지시면 안돼요! 우리는 프리티어라구요!)