1. 로드 밸런싱
- 네트워크 트래픽을 여러 서버로 분산시키는 기술
- 하나의 서버에 부하가 집중되는 것을 방지 ⇒ 애플리케이션의 가용성과 성능 높일 수 있음!
1-1. 로드 밸런싱 필요성
- 트래픽 분산
- 사용자가 많은 애플리케이션 ⇒ 모든 요청이 단일 서버로 들어오면 해당 서버가 과부하 ⇒ 성능 저하
- 로드 밸런서는 트래픽을 여러 서버로 분산시켜 이 문제를 해결 가능
- 고가용성
- 서버 중 하나가 장애가 발생하더라도 로드 밸런서는 자동으로 다른 서버로 트래픽을 우회시킴 ⇒ 서비스의 지속성 유지
- 장애 조치(Failover)
- 특정 서버에 장애 발생 ⇒ 이를 감지하고 자동으로 다른 서버로 요청 전환 ⇒ 서비스 중단을 최소화할 수 있음
- 스케일링
- 사용자가 증가함 ⇒ 서버 추가, 수평 확장 해야할 때 ⇒ 로드 밸런서는 새로운 서버를 쉽게 통합하여 트래픽을 분산시킴
- 성능 향상
- 각 서버의 상태를 모니터링 ⇒ 가장 적절한 서버에 요청 전달 ⇒ 응답 시간 단축 + 사용자 경험 개선 가능
1-2. AWS ELB
- ELB (Elastic Load Balancing)
- AWS가 제공하는 로드 밸런싱 서비스임
- 트래픽 변화 감지
- 트래픽 증가 ⇒ 로드 밸런서 수를 자동으로 증가
- 트래픽 감소 ⇒ 로드 밸런서 수를 자동으로 감소
- 주기적인 health check
- ELB와 연결된 서버들의 상태를 주기적으로 체크
- 장애 발생 or 부하 집중 ⇒ 다른 서버로 요청 전송함
- 다양한 종류
- Application Load Balancer (ALB)
- HTTP 및 HTTPS 트래픽 처리
- URL 기반 라우팅, 웹소켓 지원, HTTP/2 지원
- 마이크로서비스 아키텍처 or 웹 애플리케이션에 적합함
- Network Load Balancer (NLB)
- TCP 및 UDP 트래픽 처리 ⇒ 고속의 성능 제공
- 수백만 개의 요청을 초당 처리 가능
- 실시간 데이터 처리 또는 대량의 트래픽을 요구하는 애플리케이션에 적합함
- Gateway Load Balancer (GLB)
- 가상 어플라이언스 (ex. 방화벽, IDS/IPS) 의 배포와 관리를 용이하게 함
- 트래픽을 자동으로 가상 어플라이언스로 전달
- 보안 및 네트워크 서비스를 제공하는 경우에 유용함
- Application Load Balancer (ALB)
1-3. ELB 구성 요소
- 로드 밸런서 (Load Balancer)
- ELB의 핵심 컴포넌트
- 클라이언트 요청 수신 → 리스너로 전달 → (리스너가 대상 그룹을 선택하면) → 대상 그룹 내 서버들의 헬스 체크 진행 → 트래픽을 적절한 서버로 전달
- 헬스 체크 (Health Check)
- 로드 밸런서가 각 대상의 상태를 확인하는 방법
- 설정한 주기마다 각 대상(서버)으로 요청을 보냄 ⇒ 정상 응답을 받지 못하는 경우, 해당 대상을 비활성화함
- 위의 과정으로 트래픽이 정상 상태의 대상으로만 전달되도록 할 수 있음
- 리스너 (Listener)
- 로드 밸런서가 수신하는 요청의 프로토콜과 포트 정의
- HTTP, HTTPS, TCP, UDP 등 다양한 프로토콜 지원
- 요청을 적절한 대상 그룹으로 라우팅 하는 규칙(리스너 규칙) 설정 가능
- 리스너 규칙 (Linstener Rules)
- 리스너가 수신한 요청을 어떤 대상 그룹으로 라우팅할 지를 결정하는 조건 설정
- 대상 그룹 (Target Group)
- 로드 밸런서가 트래픽을 분산시킬 대상으로 설정하는 서버들의 집합
1-4. ELB 동작 과정
- 클라이언트 요청: 사용자가 웹 브라우저나 애플리케이션을 통해 로드 밸런서의 DNS 이름 또는 IP 주소로 요청 보냄
- 로드 밸런서 수신: ELB가 클라이언트의 요청을 수신함
- 로드 밸런서는 설정된 리스너를 통해 요청을 처리
- 리스너 규칙 적용: 로드 밸런서는 요청의 프로토콜과 포트에 따라 리스너 규칙을 확인함
- 요청의 URL 경로, 헤더, 메소드 등을 기준으로 어떤 대상 그룹으로 라우팅할지를 결정.
- 헬스 체크 수행: 로드 밸런서는 각 대상 그룹의 인스턴스에 대해 헬스 체크를 수행하여 정상 상태인지 확인함
- 비정상 상태인 인스턴스는 요청에서 제외
- 대상 선택: 헬스 체크를 통과한 대상 인스턴스 중에서 로드 밸런서는 부하 분산 알고리즘(ex. 라운드 로빈, 최소 연결 등)에 따라 최적의 인스턴스를 선택함
- 요청 전달: 선택된 대상 인스턴스에 클라이언트의 요청을 전달함
- 이 때, 로드 밸런서는 클라이언트와 인스턴스 간의 트래픽을 처리함
- 응답 수신 및 전달: 대상 인스턴스가 클라이언트의 요청을 처리하고 응답을 생성함 → 로드 밸런서는 이 응답을 다시 클라이언트에게 전달함
- 모니터링 및 로그 기록: ELB는 트래픽 패턴, 응답 시간, 오류 등의 데이터를 모니터링하고, 필요 시 로그를 기록하여 성능을 분석함
2. AWS ELB 사용하기
2-1. 예시 상황 설명
- 구조 설명
- Client VPC
- CLIENT-Public-Subnet
- ClientEC2
- CLIENT-Public-Subnet
- Server VPC
- SERVER-Public-Subnet-1
- SERVER-EC2-1
- SERVER-EC2-2
- SERVER-Public-Subnet-2
- SERVER-EC2-3
- SERVER-EC2-4
- SERVER-EC2-5
- SERVER-Public-Subnet-1
- Client VPC
- foo, bar 디렉토리 설명
- foo 디렉토리
- 서버: SERVER-EC2-1
- 위치: /var/www/html/foo
- 이 디렉토리 내부에 index.html 파일이 생성됨
- 파일의 내용은 "foo page in SERVER-EC2-1"임. 이는 SERVER-EC2-1에 접속했을 때 보여지는 웹 페이지의 내용임
- bar 디렉토리
- 서버: SERVER-EC2-3
- 위치: /var/www/html/bar
- 이 디렉토리 내부에 index.html 파일이 생성됨
- 파일의 내용은 "bar page in SERVER-EC2-3"임. 이는 SERVER-EC2-3에 접속했을 때 보여지는 웹 페이지의 내용임
- foo 디렉토리
2-2. ALB
2-2-1. 대상 그룹 생성
- 검색창에 EC2 검색 → 클릭
- 왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭
- 인스턴스 선택 → 대상 그룹 이름 입력 → SERVER-VPC 선택 → 다음 클릭
- 모든 인스턴스 선택 → 아래에 보류 중인 것으로 포함 클릭
- 모든 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭
- 대상 그룹 생성 완료 확인
2-2-2. ALB 생성
- 왼쪽의 로드밸런서 클릭 → 로드 밸런서 생성 클릭
- Application Load Balancer 탭의 생성 클릭
- 로드 밸런서 이름 입력 → SERVER-VPC 선택 → 가용 영역 모두 체크 → 보안 그룹 선택 → (리스너 및 라우팅에서) 다음으로 전달: 이전에 생성한 대상 그룹 선택 → 로드 밸런서 생성 클릭
- 시간이 지나고 새로고침 클릭 → 상태가 (프로비저닝 중) ⇒ (활성) 으로 변경됨을 확인
2-2-3. ALB 동작 확인
- 왼쪽의 인스턴스 클릭 → CLIENT-EC2 체크 → 퍼블릭 IPv4 복사
- 터미널 실행 → ssh로 CLIENT-EC2 인스턴스 접속
ssh -i PEM키 이름.pem 인스턴스 계정이름@퍼블릭IPv4
# 예시
ssh -i myPemKey.pem ec2-user@3.36.69.141
- AWS에서 왼쪽의 로드 밸런서 클릭 → 생성한 로드 밸런서 체크 → DNS 이름 복사
- ALB의 DNS 이름을 환경 변수로 등록
Test_ALB=test-ALB-1447934206.ap-northeast-2.elb.amazonaws.com
# 확인
echo $Test_ALB
- ALB에 연결된 A 레코드 확인
dig $Test_ALB
⇒ ALB에 연결된 A 레코드가 2개임!
⇒ A 레코드 2개 = 퍼블릭 IP 2개 = 서브넷 1, 2에 각각 존재하는 ENI에 할당된 퍼블릭 IP
- ALB 도메인으로 100번 접근
for i in {1..100}; do curl $Test_ALB --silent ; done | sort | uniq -c | sort -n
⇒ 1 ~ 5의 서버로 요청이 분산되어 전달됨을 확인 가능!
ALB : 교차 영역 로드 밸런싱이 기본적으로 활성화됨
⇒ 서브넷 (가용 영역 당 하나) 내 인스턴스 수가 달라도 대상 그룹내에서 고르게 부하 분산해줌!
2-3. ALB 경로 기반 라우팅
2-3-1. ALB 경로 기반 라우팅 설정
- 왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭
- 인스턴스 선택 → 대상 그룹 이름 입력 → SERVER-VPC 선택 → 다음 클릭
- SERVER-EC2-1, SERVER-EC2-2 체크 → 아래에 보류 중인 것으로 포함 클릭
- 체크한 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭
- 동일한 작업 반복 *(이때, 인스턴스는 SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5를 체크함!)
- 왼쪽에서 로드밸런서 클릭 → test-ALB 체크 → 리스너 및 규칙 탭 클릭 → HTTP:80 체크 → 규칙 관리 클릭 → 규칙 추가 클릭
- 규칙 이름 입력 → 다음 클릭
- 조건 추가 클릭 → 규칙 조건 유형: 경로 선택 → 경로에 “/foo/*” 입력 → 확인 클릭 → 다음 클릭
- 대상 그룹으로 전달 선택 → 대상 그룹 (test-Foo-target-group) 선택 → 다음 클릭
- 우선 순위 1 입력 → 다음 클릭
- 생성 클릭
- 동일한 과정 진행 (규칙을 1개 더 생성함)
- 규칙 이름 : test_Bar
- 경로 : /bar/*
- 대상 그룹 : test-Bar-target-group 선택
- 우선 순위 : 2
2-3-2. ALB 경로 기반 라우팅 동작 확인
- foo 경로에 대한 경로 기반 라우팅 테스트
for i in {1..100}; do curl $Test_ALB/foo/ --silent ; done | sort | uniq -c | sort -n
⇒ foo 경로로 요청함 → 우선 순위 1 규칙인 경로 기반 라우팅이 먼저 이루어짐 → SERVER EC2-1, SERVER EC2-2로만 라우팅됨 → 우선순위 마지막 규칙에 따라 균등하게 부하 분산됨
- bar 경로에 대한 경로 기반 라우팅 테스트
for i in {1..100}; do curl $Test_ALB/bar/ --silent ; done | sort | uniq -c | sort -n
⇒ bar 경로로 요청함 → 우선 순위 2 규칙인 경로 기반 라우팅이 먼저 이루어짐 → SERVER EC2-3, SERVER EC2-4, SERVER EC2-5로만 라우팅됨 → 우선순위 마지막 규칙에 따라 균등하게 부하 분산됨
2-4. NLB
2-4-1. 대상 그룹 생성
- 왼쪽의 대상 그룹 클릭 → 대상 그룹 생성 클릭
- 인스턴스 선택 → 대상 그룹 이름 입력 → 프로토콜: UDP 선택 → 포트: 161 입력 → SERVER-VPC 선택
- 상태 검사 프로토콜: HTTP 선택 → 고급 상태 검사 설정 탭 열기 → 상태 검사 포트 : 재정의 선택 → 80 입력 → 다음 클릭
- 모든 인스턴스 선택 → 아래에 보류 중인 것으로 포함 클릭
- 모든 인스턴스가 대상으로 추가됨을 확인 → 대상 그룹 생성 클릭
2-4-2. NLB 생성
- 왼쪽에서 로드밸런서 클릭 → 로드 밸런서 생성 클릭
- Network Load Balancer 탭의 생성 클릭
- 로드 밸런서 이름 입력 → SERVER-VPC 선택 → 가용 영역 모두 체크 → 보안 그룹 선택 → 프로토콜: UDP 선택 → 포트: 161 입력 → 다음으로 전달: 생성한 대상 그룹 선택 → 로드 밸런서 생성 클릭
- 시간이 지나고 새로고침 클릭 → 상태가 (프로비저닝 중) ⇒ (활성) 으로 변경됨을 확인
2-4-3. NLB 동작 확인
- DNS 이름 복사
- 터미널 실행 → ssh로 CLIENT-EC2 인스턴스 접속
- NLB의 DNS 이름을 환경 변수로 등록
Test_NLB=test-NLB-edf781ea8ff75454.elb.ap-northeast-2.amazonaws.com
# 확인
echo $Test_NLB
- NLB에 연결된 A 레코드 확인
dig $Test_NLB
⇒ NLB에 연결된 A 레코드가 2개임!
⇒ A 레코드 2개 = 퍼블릭 IP 2개 = 서브넷 1, 2에 각각 존재하는 ENI에 할당된 퍼블릭 IP
- NLB 도메인으로 100번 접근
for i in {1..100}; do snmpget -v2c -c public $Test_NLB 1.3.6.1.2.1.1.5.0; done | sort | uniq -c | sort -n
⇒ 서브넷 1 (SERVER-EC2-1, SERVER-EC2-2) : 23 + 27 = 50
⇒ 서브넷 2 (SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5) : 15 + 14 + 21 = 50
⇒ 가용 영역을 기준으로 고르게 분산함! (NLB는 교차 영역 로드 밸런싱이 기본적으로 비활성화 상태이므로)
2-5. NLB 교차 영역 로드 밸런싱
2-5-1. NLB 교차 영역 로드 밸런싱 활성화
- 왼쪽의 로드밸런서 클릭 → 생성한 NLB 체크 → 속성 탭 클릭 → 편집 클릭
- 교차 영역 로드 밸런싱 활성화 체크 → 변경 내용 저장 클릭
- 속성 탭의 교차 영역 로드 밸런싱 값이 켬 으로 변환됨을 확인
2-5-2. NLB 교차 영역 로드 밸런싱 동작 확인
- NLB 도메인으로 100번 접근
for i in {1..100}; do snmpget -v2c -c public $Test_NLB 1.3.6.1.2.1.1.5.0; done | sort | uniq -c | sort -n
⇒ 서브넷 1 (SERVER-EC2-1, SERVER-EC2-2) : 20 + 21 = 41
⇒ 서브넷 2 (SERVER-EC2-3, SERVER-EC2-4, SERVER-EC2-5) : 22 + 17 + 20 = 59
⇒ 모든 인스턴스에 고르게 분산됨! (가용 영역 내 인스턴스의 수가 불균등하더라도 각 인스턴스는 균등한 부하를 부여받음!)
'DevOps' 카테고리의 다른 글
| [DevOps] AWS EC2 인스턴스에 Spring 애플리케이션 배포하기 / + 백그라운드에서 배포 방법 (nohup, tmux, (리눅스) systemd 서비스 파일) (0) | 2024.11.06 |
|---|
