[AWS] 로드 밸런싱 (Amazon ELB)

sookyoung.k·2024년 11월 17일

GSC신촌 aws 교보DTS 글로벌소프트웨어캠퍼스 내맘대로TIL챌린지 클라우드교육

🌿 교보DTS TIL

목록 보기

29/40

* 로드 밸런싱 = 부하 분산
👉 다수의 서버에 트래픽을 분산시키는 기능

✔ 고가용성 - 서비스/시스템이 지속적으로 작동 가능하게 함
✔ 내결함성 - 시스템 일부가 작동하지 않더라도 전체는 계속 작동하도록 함

🚗 Amazon ELB

Amazon Elastic Load Balancing, AWS에서 제공하는 로드 밸런싱
👉 수신 네트워크 트래픽을 EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수 등 여러 대상에 분산

구성

로드 밸런서 👉 트래픽을 대상 그룹의 인스턴스로 분산시키는 애
대상 그룹(타겟 그룹) 👉 분산할 대상의 집합을 정의
리스너 👉 포트/프로토콜 설정

* 상태 점검 - 대상 그룹 내에 등록된 각 대상의 상태를 지속적으로 확인한다!

🌿 ALB

Application Load Balancer, AWS에서 제공하는 L7 로드 밸런서

* Application Load Balancer

HTTP/HTTPS 같은 웹 애플리케이션 프로토콜 지원
URL 경로 기반, 호스트 기반, 쿼리 문자열 기반 등 다양한 라우팅 기능 제공
대상 그룹 단위로 트래픽 분산 (리스너 규칙 구성)

트래픽 분산 프로세스: 콘텐츠 기반 라우팅 매커니즘
👉 균일한 요청 배포를 위해 라운드 로빈 및 고정 세션을 사용

ALB는 리스너 규칙에 정의된 URL 경로 또는 HTTP 헤더 조건을 기반으로 요요청 속성 및 경로를 확인한다

🌿 NLB

Network Load Balancer, AWS에서 제공하는 L4 로드 밸런서

* Network Load Balancer

TCP, UDP, TLS 프로토콜 지원
대규모 트래픽 처리 가능 (클라이언트-로드밸런서 연결을 TCP 레벨에서 유지하기 때문에) 👉 높은 처리량 (초당 수백만 개의 연결)
빠른 응답 시간 (L4 로드 밸런싱 알고리즘)
높은 가용성 (신속한 장애 복구)
IP 주소 보존 👉 일관된 액세스를 위해 고정 IP 할당 (탄력적 IP주소 지원)

트래픽 분산 프로세스: 연결 기반 라우팅에 중점
👉 일관된 해싱 사용, 고정 IP를 사용하기 때문에 클라이언트가 일관성을 위해 동일한 IP 주소에 연결할 수 있따

대기시간이 매우 짧은 라우팅 가능

🌿 GWLB

GateWay Load Balancer, 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서

* Amazon Gateway Load Balancer

주로 방화벽 및 위협 탐지 시스템, 타사 가상 네트워크 어플라이언스로 트래픽 라우팅하는 데 사용
L3에서 작동

🌿 CLB

Classic Load Balancer, L4, L7 모두에서 작동하는 로드 밸런서

가장 초기에 출시된 로드 밸런서
TCP, HTTP/HTTPS 애플리케이션에 대한 기본 로드 밸런싱은 제공하나 고급 라우팅 기능 X

🚜 로드 밸런싱 구성 실습

실습했던 부분을 그냥 따라만 했던 경향이 있었던 것 같아서, 다시 한 번 절차를 톺아보고 단계 하나하나 어떤 의미가 있는지 생각해보는 글을 적어보려고 한다! 약간... 내가 이해한대로 야매로 적는 거겠지만 그래도 그런대로 나중에 의미가 있겠지...!

🛜 네트워크 구성

실습에 앞서서 가장 먼저 해야 하는 것은 바로 네트워크를 만드는 일이다! AWS 클라우드 내에 가상 네트워크를 만들어본다.

1. VPC 생성

가장 먼저 VPC를 생성해준다. 생성 버튼을 누르면 간단하게 끝나는 작업이지만! 몇몇 설정에서 '이건 왜 이렇게 하는거지?'에 대해서 찾아보고 공부해봤다.

생성할 리소스는 VPC 등을 택할 것이고, 여기에서 서브넷 등을 설정해줄 것이다. 이름은 적당히 지어주고, CIDR 블록도 기본값인 10.0.0.0/16으로 설정한다.
가용 영역(AZ)는 1개를 선택하고, 가용 영역은 ap-northeast-2를 선택한다.

그렇다면 가용 영역이 무엇일까?!
👉🏻 Availability Zone, AWS 리전 내의 물리적으로 분리된 데이터 센터를 말한다.

각 가용 영역은 독립적인 전력, 냉각, 네트워킹을 갖추고 있다. (다른 영역에 영향 X)

왜 우리는 가용 영역을 선택하는가?
👉🏻 고가용성, 재해 복구, 지연 시간 최소화를 위해서 선택한다.

여러 가용 영역을 사용하면 한 가용 영역에 장애가 발생한다고 해도 서비스를 계속해서 제공할 수 있다.
또한 한 가용 영역에 문제가 생겨도 다른 가용 영역에서 서비스를 계속할 수 있다.
그리고 사용자와 가까운 가용 영역을 선택하여서 지연 시간을 줄일 수 있다.

가용 영역을 선택한 후 퍼블릭 서브넷 수를 1개 선택한 뒤, CIDR 블록을 10.0.10.0/24로 설정한다. 프라이빗 서브넷은 만들지 않는다.

로드밸런서 실습에 왜 서브넷을 여러 개 만들어서 사용하는 것일까?
👉🏻 고가용성 보장
- ALB는 가용성을 높이기 위해 최소 두 개 이상의 가용 영역에 서브넷을 지정해야 한다.
👉🏻 트래픽 분산
- 여러 가용 영역에 서브넷을 두면 로드 밸런서가 트래픽을 여러 가용 영역에 분산시킬 수 있다.
👉🏻 장애 대응
- 한 가용 영역에 문제가 생겨도 다른 가용 영역의 서브넷을 통해 서비스를 계속 할 수 있다.
👉🏻 로드 밸런서 노드 생성
- 각 가용 영역의 서브넷에 로드 밸런서 노드가 생성된다. 이 노드들이 실제로 트래픽을 처리하고 분산시킨다.
👉🏻 크로스-존 로드 밸런싱
- 여러 가용 영역에 서브넷을 두면 크로스-존 로드 밸런싱이 가능해진다. 모든 가용 영역의 대상에 균등하게 트래픽을 분산시키는 기능을 말한다.

VPC와 서브넷 이름이 좀 복잡~하게 되어있을 텐데, 이를 원래 의도했던 네이밍으로 바꾸어준다.

2. 서브넷 생성

또 다른 서브넷을 만들어 줄 것이다. 이는 위에서도 언급했지만 고가용성을 확보하기 위함이다. 생성한 서브넷이 위치한 가용영역 A외에 다른 가용 영역인 C에 서브넷을 생성할 것이다.

서브넷 생성 버튼을 눌러 생성을 시작한다.
VPC는 방금 생성한 VPC를 선택한다.
서브넷 이름과 가용 영역(다른 가용 영역에 만드는 것이 중요 포인트), CIDR 블록 설정(10.0.20.0/24) 세팅을 해주고 이름을 지어주는 것으로 간단하게 마무리!

3. 라우팅 테이블 편집

그 다음으로 할 일은 라우팅 테이블을 설정하는 것이다. 하지만 한 가지 짚고 넘어갈 점... 라우팅 테이블이 뭐고 왜 필요한 것일까...?! 알고 넘어가는 것이 좋을 것 같았다... 절차를 전부 이해할 순 없겠지만 ㅠㅠ

라우팅 테이블이란?
👉🏻 네트워크 트래픽의 방향을 결정하는 중요한 구성 요소

트래픽을 제어한다 (네트워크 패킷이 어디로 가야 할지 결정)

서브넷 연결 (각 서브넷은 하나의 라우팅 테이블과 연결되어야 한다 → 이를 통해 서브넷 트래픽 흐름 제어)

인터넷 접근 제어 (인터넷 게이트웨이로의 경로를 정의하여 퍼블릭 서브넷의 인터넷 접근을 가능하게 한다)

내부 통신 관리 (VPC 내부의 다른 서브넷이나 다른 AWS 서비스의 경로를 정의)

보안 강화

라우팅 테이블의 존재 이유

네트워크 분리

서로 다른 목적의 리소스를 논리적으로 분리할 수 있다

예를 들어 서브넷 A는 퍼블릭 서브넷으로, 서브넷 C는 프라이빗 서브넷으로 사용하는 등 분리가 가능하다

유연한 네트워크 구성

다양한 네트워크 토폴로지 구현

트래픽 최적화

특정 트래픽을 특정 경로로 유도하여 네트워크 성능 최적화

아직 완전히 감을 잡은 것은 아니지만, 라우팅 테이블이 있어야 통신이 가능해지는 것 같다. 그럼 라우팅 테이블 세팅 절차를 알아보자!

먼저 서브넷 메뉴에서 서브넷 C를 선택하여 라우팅 테이블 연결을 편집한다.
라우팅 테이블 ID에서 기본 라우팅 테이블이 아닌 다른 라우팅 테이블을 선택한다. 이 때 인터넷으로 향하는 경로 (Igw, 인터넷게이트웨이)가 있는지 확인을 해주어야 한다!

왜... 서브넷 C만 라우팅 테이블의 설정을 바꾼걸까?... 나름대로 이해를 하고 집에 왔다고 생각했는데 다시 까먹음 ㅠ

4. 보안 그룹 생성

보안 그룹은 인스턴스에 대한 인바운드, 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 한다.

보안그룹을 생성하기를 누른 후 VPC는 우리가 생성한 VPC를 선택해준다.
인바운드 규칙으로는 SSH-MyIP, HTTP-MyIP을 부여해준다.

🖥️ 웹 서버 생성

이제 웹 서버를 생성해줄 것이다!

5. 웹 서버 인스턴스 생성

인스턴스 시작을 눌러 webserver1이라 이름을 붙여준다. 애플리케이션 및 OS 선택은 Amazon Linux를 택했다. 다른 설정은 크게 건드린 것이 없으며 키페어도 이전에 실습에서 사용했던 pem을 사용했다.
네트워크 설정을 편집해줄 것이다. VPC에는 우리가 생성한 VPC를, 서브넷은 A를, 퍼블릭 IP 자동할당을 활성화해준다.
보안그룹은 기존 보안그룹을 선택하여 위에서 생성한 보안 그룹을 택한다.
아래에 있는 고급 세부 정보를 펼쳐서 스크롤을 아래로 쭉 내리면 사용자 데이터를 입력할 수 있는 TEXTAREA가 있다. 아래 내용을 복붙해준다.

#!/bin/sh
        
# Install a LAMP stack
sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
sudo yum -y install httpd php-mbstring
sudo yum -y install git
        
# Start the web server
sudo chkconfig httpd on
sudo systemctl start httpd
        
# Install the web pages for our lab
if [ ! -f /var/www/html/aws-boarding-pass-webapp.tar.gz ]; then
    cd /var/www/html
    wget -O 'techcamp-webapp-2024.zip' 'https://ws-assets-prod-iad-r-icn-ced060f0d38bc0b0.s3.ap-northeast-2.amazonaws.com/600420b7-5c4c-498f-9b80-bc7798963ba3/techcamp-webapp-2024.zip'
    unzip techcamp-webapp-2024.zip
    sudo mv techcamp-webapp-2024/* .
    sudo rm -rf techcamp-webapp-2024
    sudo rm -rf techcamp-webapp-2024.zip
fi
        
# Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
    cd /var/www/html
    sudo mkdir vendor
    cd vendor
    sudo wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
    sudo unzip aws.zip
fi
        
# Update existing packages
sudo yum -y update

이 정체모를 스크립트의 정체는...?!
👉🏻 EC2 인스턴스가 시작될 때 자동으로 실행되는 사용자 데이터 스크립트다.

LAMP 스택 설치 (Linux, Apache, MariaDB(MySQL), PHP를 설치) - 웹 서버와 데이터베이스 환경 구축

웹 서버 시작 (Apache 웹 서버 시작하고 부팅 시 자동 실행되도록 설정)

웹 애플리케이션 설치 (techcamp-webapp-2024를 다운로드 후 설치) - AWS 실습을 위함

AWS SDK for PHP 설치 (PHP에서 AWS 서비스를 사용할 수 있게 해주는 SDK 설치)

패키지 업데이트

결론적으로 이는 EC2가 생성되자마자 웹 서버 환경을 자동으로 구성하여, 별도의 수동 설정 없이도 웹 애플리케이션을 즉시 실행할 수 있게 해주는 스크립트이다

인스턴스가 만들어진 후 상태 검사에 통과하여 '실행중'이 된다면! 세부 정보에서 IPv4 퍼블릭 IP 값을 복사하여 웹 브라우저에 붙여 넣는다. 그러면 welcome to the AWS IMD 페이지가 나온다...

나와야 하는데! 난 안나옴 ㅋ It works! 라는 문구만 화면에 뜰 뿐... 그렇다면 이것이 실패냐?! 반은 실패고 반은 성공이다.
이 문구가 나왔다는 것은 Apache 웹 서버가 정상적으로 설치되었다는 것을 의미한다. 하지만 예상한 웹 애플리케이션이 나오지 않는 것 뿐이다. 이것에 대한 해결은 다른 글에서 작성해보도록 하겠다! (~~왜냐면 집 노트북에서 현재 인스턴스 주소로 접속이 안됨 ㄷㄷ~~)

6. AMI 생성

AMI(Amazon Machine Imgae)?
👉🏻 EC2 인스턴스의 스냅샷 또는 템플릿, 인스턴스를 설정하고 부팅하는 데 필요한 모든 정보를 포함한다

'Image'라는 단어에서 부터 느껴지지만 도커 이미지처럼 손쉽게 이미지 기반으로 동일한 인스턴스를 생성할 수 있게 해주는 것 같다!

위에서 인스턴스를 정상적으로 새엇ㅇ했다면, 이를 기반으로 이미지를 생성할 수 있다. 인스턴스의 '작업 > 이미지 및 템플릿 > 이미지 생성' 이 순서로 들어간 화면에서 이미지 이름을 지정한 후 생성해주면 된다. 아주 간단!

7. AMI 기반 인스턴스 생성

AMI 메뉴에서 상태 변경이 완료되면 'AMI로 인스턴스 시작' 버튼을 누른다. 중요한 점은 네트워크 설정에서 편집을 누른 후 서브넷 C을 선택해 다른 서브넷에서 생성을 해주는 것이다! (로드밸런서 실습을 할 거니깐...!) 그렇게 인스턴스를 생성하고 잘 작동되는지 확인만 해주면 됨.

🚌 로드 밸런서 생성

이제 마지막으로! 로드 밸런서 설정!!

8. 로드 밸런서 생성

로드밸런서 메뉴에서 로드밸런서 생성 버튼을 눌러 생성을 시작한다.
우리는 어플리케이션 로드 밸런서를 선택할 것이기 때문에 ALB 유형을 선택해준다.
이름을 설정한 후, 앞서 생성한 VPC를 선택한 후, 항목에서 public subnet A와 public subnet C를 선택한다.
👉🏻 로드 밸런서에서 트래픽을 라우팅할 VPC와 가용 영역을 지정하는 작업
보안 그룹에서 새 보안 그룹을 생성한다. VPC를 우리가 생성한 VPC로 바꿔주고, 인바운드 규칙으로 HTTP - MyIP 를 설정하여 생성을 마친다. 그리고 우리가 방금 생성한 보안 그룹을 로드 밸런서의 보안 그룹으로 지정한다.
리스너 및 라우팅 메뉴에서! 대상 그룹을 생성해준다!! 대상 유형은 인스턴스로, 프로토콜은 HTTP로 선택한다. VPC에는 당연히 우리가 만든 VPC를 지정한다.
대상 등록에는 우리가 앞서 생성한 인스턴스 2개를 '아래에 보류 중인 것으로 포함' 버튼을 통해 대상으로 등록해준다.
대상 그룹 생성이 끝나면, 이전 화면으로 돌아와 다시 리스터 및 라우팅에서 대상 그룹으로 지정한다. 이후 로드 밸런서 생성 버튼을 통해 로드 밸런서를 생성한다!
그리고! 웹 서버가 로드 밸런서의 트래픽만 받을 수 있도록 하기 위해 인스턴스에 지정했던 보안 그룹을 수정해준다.
기존의 HTTP 인바운드 규칙을 삭제한 후, 새로운 규칙을 생성한다. 로드 밸런서의 트래픽만 받을 수 있도록! 소스 부분에서 사용자 지정을 클릭한 후, 우리가 만들었던 로드밸런서 보안 규칙을 선택한다. 편집이 끝나면 규칙 저장 버튼을 통해 보안 규칙을 업데이트 해준다.
로드 밸런서 메뉴로 돌아와 상태가 'active'하게 바뀌면, 아래 설명에서 'DNS 이름'을 복사하여 웹 브라우저에 붙여넣는다. 그러면 완성!

👉🏻 새로고침을 하면 InstanceID와 Availability Zone 값이 변한다. (라운드 로빈 알고리즘을 따름) 이를 통해 로드밸런서가 트래픽을 인스턴스 두 개에 각각 나누어서 잘 전달하고 있음을 확인할 수 있다!

느낀점

실습을 하면서는 그럭저럭 이해가 된다고 생각했던 것들이, 하나하나 파고들려고 보니 생각보다 궁금한 것들이 많았다. 아직 모르는게 참 많은 ^^... 그래도 공부해갈 맛은 나는 것 같다. 쿠버네티스 할 때보다 훨씬 선녀같네... 아직 복습 진도가 많이 늦지만, 차근차근 지식을 쌓아나가봐야겠다.

본 포스팅은 글로벌소프트웨어캠퍼스와 교보DTS가 함께 진행하는 챌린지입니다.

sookyoung.k

영차영차 😎

이전 포스트

[AWS] VPC

다음 포스트