Cloud_AWS ELB 서비스 & ALB/NLB 이용한 로드밸런싱 실습

AWS ELB(Elastic Load Balancing) 서비스

부하분산이란?

부하 분산은 서버가 클라이언트의 요청을 처리하는 과정에서 발생하는 과부하를, 동일한 기능을 수행하는 여러 서버에 분산시켜 처리하는 기술이다. 이를 통해 서비스의 안정성을 높이고, 장애 발생 시에도 유연하게 대처할 수 있다.

부하 분산을 통해 달성할 수 있는 주요 목표는 다음과 같다:

• 고가용성 (High Availability):
  시스템이나 서비스가 지속적으로 작동할 수 있도록 보장하는 기능으로, 하나의 서버에 장애가 발생하더라도 다른 서버가 그 역할을 대신하여 서비스가 중단되지 않도록 한다.
• 내결함성 (Fault Tolerance):
  시스템의 일부 구성 요소에 문제가 생겨도 전체 시스템은 정상적으로 운영되도록 하는 기능이다. 이를 통해 장애가 발생하더라도 서비스의 연속성을 유지할 수 있다.

이와 같이 부하 분산은 로드밸런싱이라고도 불리며, 이를 수행하는 장비나 소프트웨어를 로드 밸런서라고 합니다. 로드 밸런서는 클라이언트의 요청을 여러 서버에 효율적으로 분산시켜 전체 시스템의 부하를 관리하고, 안정적이고 신뢰할 수 있는 서비스 제공에 기여한다.

---

Amazon ELB 기능

• 트래픽 분산: EC2 인스턴스로 유입되는 트래픽을 자동으로 분산 처리해, 트래픽 급증 시에도 안정적인 서비스를 제공
• 실시간 모니터링: AWS CloudWatch를 통해 로그와 메트릭을 실시간으로 모니터링
• 오토 스케일링 연동: 트래픽 변화에 따라 인스턴스를 자동으로 추가하거나 제거하여 서비스 가용성을 유지
• 보안 강화: SSL 암호화를 지원하여 애플리케이션의 보안을 강화

---

Amazon ELB 구성 요소

ELB는 세 가지 요소로 구성되어 있다.

1. 로드 밸런서
   • 클라이언트의 요청을 받아 여러 대의 EC2 인스턴스, IP 주소, 람다 등으로 분산
   • 애플리케이션 서버로 요청을 전달하고 응답을 다시 클라이언트에 반환하여 서비스의 가용성을 유지
2. 대상 그룹
   • 로드 밸런서가 요청을 분산할 대상(예: EC2 인스턴스)의 집합을 정의
   • 정적 또는 동적으로 구성할 수 있으며, 라우팅 규칙에 따라 요청을 처리할 그룹을 선택
   • 주기적으로 대상의 상태를 확인하여 장애가 있는 인스턴스는 자동으로 제외하고 정상 인스턴스에만 요청을 전달
3. 리스너
   • 로드 밸런서에서 사용할 포트와 프로토콜을 설정
   • 클라이언트 요청을 수신하고, 해당 요청을 처리할 대상 그룹을 선택하여 라우팅하는 역할

---

Amazon ELB 동작 방식

 

ELB의 동작 방식은 다음과 같이 정리할 수 있다:

1. 클라이언트 요청 수신
   • 로드 밸런서는 리스너를 통해 클라이언트의 요청을 받고, 클라이언트와 연결을 유지
2. 대상 그룹 선택
   • 요청을 처리할 대상을 인스턴스, IP 주소, 람다 함수, ALB 등으로 구성된 대상 그룹 중에서 선택
3. 트래픽 분산
   • 대상 그룹 내에서 요청을 처리할 대상을 선정하여 트래픽을 분산
   • 각 대상의 가용성을 모니터링하여, 장애가 있는 대상은 자동으로 제외
4. 응답 반환
   • 대상에서 처리된 응답은 로드 밸런서를 거쳐 클라이언트에게 전달되며, 클라이언트는 마치 직접 대상에게 응답을 받은 것처럼 인식

* 인터넷 경계 로드 밸런서: 외부에서 직접 로드 밸런서에 접근 방식

* 내부 로드 밸런서: 외부의 접근이 차단된 격리된 네트워크(내부 서버 전용)에서 로드 밸런서를 사용하는 방식

---

Amazon ELB 교차 영역 로드 밸런싱

ELB는 여러 가용 영역에서 로드 밸런서 노드를 운영하며, 각 노드는 해당 가용 영역 내의 대상 그룹으로 트래픽을 분산시킨다. 대상 그룹에 등록된 인스턴스가 여러 가용 영역에 걸쳐 있을 경우, 로드 밸런서는 기본적으로 각 가용 영역 내 인스턴스에 동일한 비율로 트래픽을 보내게 된다. 이로 인해 한 가용 영역에 인스턴스 수가 적으면 해당 인스턴스에 트래픽이 몰려 불균형이 발생할 수 있다.

로드 밸런싱 불균형 예시

 

위 그림처럼 기본 로드 밸런싱은 여러 가용 영역에 트래픽을 분산하지만, 각 영역 내 인스턴스 수가 불균형하면 효율성이 떨어질 수 있다. 이를 개선하기 위해 도입된 것이 ELB 교차 영역 로드 밸런싱(cross-zone load balancing)이다.

ELB 교차 영역 로드 밸런싱 활성화 예시

• 균일한 트래픽 분산:
  여러 가용 영역에 분산된 EC2 인스턴스나 컨테이너 등 대상을 대상으로, 대상 그룹에 속한 자원을 기준으로 균일하게 로드 밸런싱을 수행
• 불균형 보정:
  가용 영역별 인스턴스 수가 불균형한 경우에도 트래픽 비중을 보정하여 효율성 up
• 서비스 별 기본 설정:
  ALB는 기본적으로 교차 영역 로드 밸런싱이 활성화되어 있으나, NLB는 기본적으로 비활성화
• 주의사항:
  이 기능을 사용할 때 가용 영역 간 통신 비용이 발생

---

Amazon ELB 종류

1. Classic Load Balancer (CLB)

• 출시 시점: ELB 초기 출시 제품으로, 레거시 옵션에 해당함.
• 지원 계층:
  • 4계층: TCP, SSL/TLS 암호화 프로토콜 지원
  • 7계층: HTTP/HTTPS 지원
• 특징:
  • 외부 네트워크와 통신할 때 CLB는 고정 IP 대신 DNS 이름을 통해 접근함.
  • CLB와 백엔드의 통신은 IP 기반으로 관리되며, EC2 인스턴스의 IP가 변경되면 자동 갱신 기능이 부족하여 수동으로 등록/갱신하거나 경우에 따라 새로 생성해야 함.
• 주의 사항:
  • CLB는 너무 올드한 서비스이고 더 나은게 많음. 쓰지마셈.

2. Application Load Balancer (ALB)

• 지원 계층: 7계층
• 지원 프로토콜: HTTP, HTTPS
• 주요 기능:
  • 대상 그룹(Target Group) 기반 분산: EC2 인스턴스, Lambda 함수, 컨테이너, 또는 IP 주소로 트래픽을 라우팅
  • 고급 라우팅 기능:
    • 경로 기반 라우팅: URL 경로에 따라 요청 분산
    • 호스트 기반 라우팅: 호스트 이름에 따라 요청 분산
    • 쿼리 문자열 기반 라우팅: URL 쿼리 문자열에 따라 요청 분산
  • HTTP 해더 확인을 통해 고급 라우팅 기능을 수행함으로써, 트래픽을 효율적으로 대상 그룹에 로드 밸런싱함.
  • 클라이언트가 보내는 트래픽을 ALB가 로드 밸런싱해서 서버에 전달할 때 클라이언트의 출발지 IP 주소를 자신의 프라이빗 IP 주소로 변경해서 전달

    

    ALB는 클라이언트 출발지 IP 주소를 자신의 프라이빗 IP 주소로 변경해서 서버에 전달

• 추가 기능:
  • 오토스케일링과 연계해 확장성 있는 애플리케이션 구성 가능
  • 대상 그룹 내 인스턴스에 대해 상태 검사를 수행, 장애 발생 시 자동 장애 조치
  • Amazon CloudWatch Logs와 통합되어 로그 및 지표 데이터를 수집, 모니터링 및 분석 가능

 

3. Network Load Balancer (NLB)

• 지원 계층: 4계층
• 지원 프로토콜: TCP, UDP, TLS
• 주요 기능:
  • 클라이언트와의 연결을 TCP 레벨에서 유지하여 초당 연결 수, 처리량, 대역폭 등 높은 성능 제공
  • 고정 IP 주소를 유지할 수 있어 방화벽 설정 등 네트워크 제어가 필요한 서비스에 적합
  • 대상 그룹을 EC2 인스턴스뿐만 아니라 특정 IP 주소 기반으로도 구성 가능 (예: 온프레미스 서버로 트래픽 전달)
  • ALB와 다르게 클라이언트가 보내는 트래픽을 NLB가 로드 밸런싱해서 서버에 전달할 때, 클라이언트의 출발지 IP 주소를 보존한 채로 전달
• 추가 기능:
  • Amazon CloudWatch Logs와 통합되어 모니터링 및 로그 분석 가능

4. Gateway Load Balancer (GWLB)

• 용도:
  • 서드파티 보안장비(예를 3들어 외부 업체이자 고급 방화벽 서비스인 FortiGate)과 연동해 네트워크 트래픽을 보호하고 부하를 분산
  • 즉, 외부 보안 업체의 보안 장비를 AWS에서 사용함과 동시에 트래픽에 대한 보안 처리를 효율적으로 하기 위해 만들어진 로드 밸런싱 서비스
• 작동 방식:
  1. 클라이언트 트래픽을 GWLB가 받아 서드파티 보안 장비로 전달
  2. 보안 장비가 트래픽을 검사한 후 정상 트래픽만 GWLB를 통해 원래 목적지로 전달
• 지원 프로토콜: TCP 및 UDP
• 특징:
  • 다수의 서드파티 보안 어플라이언스를 손쉽게 배포, 확장 및 관리할 수 있음
  • VPC 내 애플리케이션의 가용성과 확장성을 향상시킴
    • 가용성 향상:
      여러 보안 장비(예: 방화벽)가 있을 때, GWLB가 트래픽을 이 장비들에 고르게 분산. 만약 어떤 장비에 문제가 생겨도 다른 장비가 대신 트래픽을 처리할 수 있으므로, 서비스가 중단되지 않고 계속 운영
    • 확장성 향상:
      트래픽이 많아지면 GWLB가 자동으로 더 많은 보안 장비를 추가해 부하를 분산. 이를 통해 애플리케이션이 늘어나는 트래픽을 원활하게 처리할 수 있어, 서비스 확장 쉬워짐

---

AWS CloudFormation 서비스 소개

CloudFormation이란?

• AWS CloudFormation은 IaC(Infrastructure as Code) 기반으로 AWS 인프라를 자동으로 생성하고 관리하는 서비스
• VPC, EC2 같은 리소스를 수동으로 생성하면 시간이 오래 걸리고, 설정 실수가 발생할 수 있는데 이를 해결함
• CloudFormation을 사용하면 코드(YAML 또는 JSON) 기반으로 인프라를 선언하고 자동화할 수 있어, 빠르고 정확하게 환경을 구축 가능

CloudFormation의 용어 개념

템플릿 (Template)	JSON 또는 YAML 형식으로 작성된 인프라 정의 파일
스택 (Stack)	CloudFormation을 통해 생성된 AWS 리소스들의 집합
리소스 (Resources)	CloudFormation이 생성하는 AWS 리소스 (EC2, RDS, S3 등)
파라미터 (Parameters)	템플릿에서 값을 동적으로 설정할 수 있도록 하는 변수
이벤트 (Events)	스택 생성, 업데이트, 삭제 중 발생하는 이벤트 로그

 

CloudFormation의 장점

• 인프라 자동화: 코드 기반으로 AWS 리소스를 관리하여 운영 비용 절감
• 재사용 가능: 동일한 인프라를 여러 환경(dev/staging/prod)에 쉽게 배포 가능
• 버전 관리 & 롤백: 변경 사항을 추적하고 문제가 발생하면 이전 버전으로 복원 가능
• 종속성 관리: 리소스 간 관계를 정의하여 자동으로 올바른 순서대로 생성

CloudFormation 동작 순서

1. CloudFormation 템플릿(JSON/YAML) 작성 – 배포할 AWS 인프라 정의
2. AWS CloudFormation에 템플릿 업로드
3. 스택(Stack) 생성 – 템플릿을 기반으로 AWS 리소스가 자동 프로비저닝
4. 스택 업데이트 및 모니터링 – 변경 사항을 적용하고 이벤트 로그 확인
5. 스택 삭제 – 스택과 관련된 모든 AWS 리소스가 삭제됨

CloudFormation을 사용하면 AWS 인프라를 코드로 관리(IaC)할 수 있으며,

인프라 자동화, 재사용성, 변경 관리 등의 이점을 얻을 수 있다.
또한 CI/CD 파이프라인과 통합하여 지속적 배포 환경을 구축하는 데 활용할 수도 있다.

---

ALB/NLB 이용한 로드밸런싱 실습

실습 목표 아키텍처

 

실습 단계

1. 실습을 위한 기본 인프라를 CloudFormation으로 배포
2. 기본 인프라 환경 검증
3. ALB 생성 후 동작 과정 확인
4. ALB 경로 기반 라우팅 기능을 이용한 로드 밸런싱 방법을 구성하고 확인
5. ALB의 User-Agent를 활용한 로드 밸런싱 방법을 구성하고 확인
6. NLB를 생성하고 교차 영역 로드 밸런싱 기능 여부를 동작 과정을 거쳐 확인
7. 실습 자원들 삭제 > <

 

실습 1단계 (CloudFormation을 활용해 인프라 배포)

책에서 제공하는 URL을 바탕으로 CloudFormation을 이용해 스택을 생성

VPC	ELB-VPC	CIDR: 10.40.0.0/16, 인터넷 게이트웨이: ELBIGW, 2개 공용 서브넷
	My-VPC	CIDR: 20.40.0.0/16, 인터넷 게이트웨이: MyIGW, 1개 공용 서브넷
서브넷	ELB-Public-SN1/2	ELBVPC에 속함, 각각 10.40.1.0/24, 10.40.2.0/24
	My-Public-SN	MyVPC에 속함, CIDR: 20.40.1.0/24
라우팅	ELB/MY-PublicRT	각 VPC의 라우트 테이블, 기본 경로(0.0.0.0/0)를 IGW와 연결
보안 그룹	ELB-SG	ELBVPC 내: HTTP, SNMP, SSH, ICMP 허용
	My-SG	MyVPC 내: SSH 및 ICMP 허용
EC2 인스턴스	SERVER-1/2/3	ELBVPC에 배포, 웹 서버 (HTTP, SNMP 서비스) 실행
	MyEC2	MyVPC에 배포, SSH 접근 및 기본 유틸리티(예: net-snmp-utils, tcpdump) 설치

• 책에서 나온 URL 인프라 스택 코드를 정리해보았다.

 

실습 2단계 (기본 인프라 환경 검증)

MyEC2 인스턴스와 SEVER-1 웹 서비스 연결 확인

* curl 명령어는 웹 서버 내용을 가지고 오는 명령이다. 웹 서버와의 통신이나 API 테스트 등에 활용된다.

SERVER-2,3 웹 서비스도 My 인스턴스와 연결 확인

SERVER 1,2,3의 SNMP 서비스 연결 확인 / 위 해당 명령어는 사용자가 장비 설정에 사용한 장비 이름으로 만약 사용자가 장비 이름을 설정하지 않으면 NULL 값을 출력한다.

 

 

실습 3단계 (ALB 생성하고 동작 확인)

대상 그룹을 생성하고 ALB 로드 밸런서를 생성하여 대상 그룹과 ALB를 연결함

 

• ALB를 통해 MyEC2에서 웹 서버인 SERVER1,2,3으로 접근할 때 인스턴스로 직접 HTTP 접근하지 않고,                ALB 도메인 주소로 접근하게 만들었다.

반복분을 통해 90번 각 웹 서버에 접근한 결과, ALB 서비스가 교차영역 로드 밸런싱 기능을 통해 각 서버에 약 30개씩 골고루 트래픽을 분산시켰다.

 

 

실습 4단계 (ALB 경로 기반 라우틴 기능 구성 및 확인)

로드밸런싱 서비스에서 경로 기반 라우팅 기능이 필요한 예시

 

* /dev/index.html 파일은 SERVER1에만 존재하므로, /dev 폴더 접근 요청을 하였을때 ALB가 잘못된 서버에 분산시켰을

경우 오류 메시지가 뜸

dev 파일을 요청할 경우 SERVER-1로, mgt 파일을 요청할 경우 SERVER-2,3으로 가도록 ALB 리스너 규칙 생성

dev 파일을 5번 요청하였을 때 경로 기반 라우팅 기능으로 인해, 5번 모두 dev 파일을 갖고 있는 SERVER -1에 해당 요청 트래픽을 잘 전달함

 

 

실습 5단계 (ALB의 User-Agent 활용 로드 밸런싱 구성 및 확인)

아이폰으로 ALB 도메인 주소에 접속해도 서버와 통신 가능

• HTTP 프로토콜 헤더에서 User-Agent 정보를 확인 할 수 있다. 이러한 정보 확인을 이용하여 특정 장치의 접근을      차단 하는 로드 밸런싱 규칙을 생성 할 수 있다.

• 

  iPhone과 Andoroid에서 접근 불가능 하도록 HTTP 해더를 검사하는 User-Agent 규칙 생성

휴대폰에서 ALB 도메인 주소로 접근할 경우 접근 거부 DENY 문자가 생성

 

 

실습 6단계 (NLB를 생성 후 교차 영역 로드 밸런싱 동작 확인)

NLB 대상 그룹과 NLB 로드 밸런서 생성 후 연결

snmp 프로토콜 60번 요청을 NLB 밸런서로 전송해보면 ALB 밸런서와 다르게 교차 형식이 아닌 기본 라운드 로빈 방식으로 로드 밸런싱 되는것이 확인

NLB 로드 밸런서 속성에 들어가서 교차 영역 로드 밸런싱을 활성화

NLB 로드 밸런서도 교차 영역 형식으로 로드 밸런싱이 진행 됨

 

 

실습 7단계 (자원들 삭제)

• 목표 아키텍처 구성 달성 > < 자원들 삭제 ~