ALB와 NLB를 통한 로드밸런싱 실습에서 vi 편집기를 통해 Apache의 기본 로그 설정 정보를 수정하는 실습이 진행됩니다.(p188)

 

실습에선 "EC2 Instance A"→"ALB"→" EC2 Instance B" 경로를 통해 인스턴스 B에 접속합니다. 

 

그러나 인스턴스 B의 접속 로그를 확인해보면 출발지 로그에 ALB의 사설 IP 정보만 보여진다는 것을 확인할 수 있습니다.

 

접속 로그를 확인하는 방법은 로그 확인 대상이 되는 EC2 Instance B의 SSH 터미널에서 아래 명령어를 입력합니다.

tail -f /var/log/httpd/access_log |grep -v "ELB-HealthChecker/2.0"

 

 

이후 EC2 Instance A에서 ALB를 통해 EC2 Instance B에 접속해보면 ALB의 사설 IP만 나오고 EC2 Instance A의 IP는 찍히지 않는다는 것을 확인할 수  있습니다.

 

책에서는 출발지 IP 주소를 보존하는 것이 꼭 옳은 것만은 아니라고 합니다. 그치만 출발지 IP, 즉 클라이언트의 IP를 알 수 없다면 로그 분석이나 보안(특정 IP 차단) 등에 어려움이 있을 수 있습니다.

 

그래서 출발지 IP를 보존할 수 있는 방법이 필요한데 

이는 HTTP 헤더에 X-Forwarded-For(XFF) 필드 추가를 통해 해결할 수 있습니다.

 


 

방법은 다음과 같습니다.

 

실습을 진행할 EC2 instance의 세션이 연결된 SSH 터미널에서 아래 명령어를 통해 vi 편집기로 Apache 파일을 엽니다.

vi /etc/http/conf/httpd.conf

 

 

그리고 196번째 줄로 이동합니다. 이때 이동은 방향키로 이동할 수 있고, 명령 모드(최초 진입 시 명령 모드임)에서 아래 명령어를 입력하여 이동할 수도 있습니다.

:196

 

 

196번째 줄에서 문자를 입력하기 위해 명령 모드에서 입력 모드로 변경합니다. 아래 명령어를 입력하여 모드를 변경할 수 있습니다.

i

 

 

이후 방향키를 통해 입력 위치로 커서 이동 후 필드 정보를 입력합니다. 실습에선 다음 정보를 입력했습니다.

%{X-Forwarded-For}i

 

 

입력이 완료됐다면 입력 모드에서 다시 명령 모드로 변경합니다.ESC 키를 눌러 입력 모드에서 명령 모드로 전환할 수 있습니다.

 

 

그리고 vi 편집기를 종료합니다. vi 편집기는 명령 모드에서 아래 명령어를 입력하면 종료할 수 있습니다.

:wq

 

 

설정 변경을 완료했다면 파일을 갱신할 수 있도록 합니다. 실습에선 서버 종료 없이 conf 설정 파일만 갱신하면 됐으므로 SSH 터미널에서 아래 명령어를 입력했습니다.

systemctl reload httpd

 

 

이후 최초에 진행했던 방식으로 다시 EC2 Instance B의 SSH 터미널에서 접속 로그를 확인하고 EC2 Instance A를 통해 EC2 Instance B에 접속해봅니다.

 

ALB와 NLB를 이용한 로드 밸런싱 구성하기 실습에서 HTTP 헤더 기반 라우팅 실습이 진행됩니다.(p169)

 

ALB에선 http 헤더를 기반으로 분기 처리를 할 수 있는데

실습에선 android와 iphone일 때는 서버가 아닌 503 코드를 반환하도록 하는 설정이 진행됩니다.

 

책에서는 헤더 값을 iPhone과 Android로만 등록하는데 이렇게 하더라도 너무나 잘(?) 들어가집니다..

 

어떻게 해야할까요?

 

너무 간단한데요.

*를 활용하면 됩니다.

(  AWS강의실 단톡방에도 여쭤봤는데 답을 얻지 못해서 현업에 계신 형한테 물어봤었는데..믓쟁이★)

 

저 놈을 애스터리스크라고 하는 것 같더군요.

 

구글 검색

 

헤더 값에 

iPhone
Android

가 아닌 에스터리스크를 앞뒤로 추가해서 아래처럼 설정하면 됩니다.

*iPhone*
*Android*

로드밸런싱: 트래픽 분산 처리

AWS의 로드 밸런싱 서비스: ELB(Elastic Load Balancing)

"트래픽을 ELB가 받아 다수의 대상으로 로드 밸런싱하여 전달"


ELB 구성요소

  • 로드 밸런서
    • 트래픽 분산하는 애
    • Client 요청을 받아 대상 그룹(여러 EC2 인스턴스나 IP주소, 람다 등)에 전달하거나, 대상 그룹이 응답한 정보를 Client에게 반환함
    • ELB 생성하면 가용 영역별로 로드 밸런서 노드가 가용영역 안에 생성됨
  • 대상 그룹
    • 로드 밸런서가 분산할 대상의 집합
    • 로드 밸런서는 라우팅 규칙에 따라 대상 그룹 내 Client의 요청을 받을 애를 선택함
    • 정기 점검으로 대상그룹의 건강상태를 체크하고, 정상 작동하는 애한테만 트래픽(Client 요청) 전달함
      • Health Check: 건강상태 체크
      • Monitoring: 처리 가능한 애 감독
  • 리스너
    • 로드 밸런서에서 사용할 포트와 프로토콜 설정하는 구성 요소
    • 로드 밸런서에 연결된 프로토콜과 포트를 기반으로 요청을 검사하고 적절한 요청만 골라 대상 그룹에 전달하는 역할 수행
    • 로드밸런서당 최소 1개에서 최대 10개 가능
    • 대상 그룹의 라우팅 정의
    • 리스너 규칙(Rule)
      • 트래픽 분배를 위한 라우팅 규칙
      • 규칙과 규칙 충족했을 경우 수행할 액션 정의

트래픽 흐름도

1) Client가 ELB 도메인 주소로 요청 전달

2) 도메인 해석 후 알맞는 가용 영역의 로드 밸런서 노드로 트래픽 전달

3) 로드밸런서가 대상 그룹 중 선택하여 요청 전달

4) 역순으로 Client에게 응답 반환


불균형 로드 밸런싱 문제

  • 교차 영역 로드 밸런싱 없을 경우, 가용영역 간 트래픽 분산 비중이 동일. 이로 인해 가용영역 내 대상 그룹의 크기가 다를 경우 부하 불균형 문제 발생
    • 예를 들어, A 가용영역에 트래픽 100, B 가용영역에 트래픽 100
    • A 가용영역에 인스턴스 개수는 10인대, B 가용영역에 인스턴스 개수는 40이라면?
    • A 가용영역의 인스턴스 당 부하는 10이지만 B 가용영역의 인스턴스 당 부하는 2.5
  • 교차 영역 로드 밸런싱 있을 경우,  대상 그룹 크기에 맞게 트래픽 분산
    • 그렇게 되면, A 가용영역, B 가용영역 인스턴스 부하가 4
  • ALB에는 활성화 기본이지만 NLB에선 비활성화
  • 교차 영역 로드 밸런싱 사용 시 가용 영역 간 통신 비용 발생

ELB 종류

  • CLB
    • 현재 레거시 서비스로 분류됨
    • 서버 주소 변경 시 새로 생성 필요
    • 포트나 헤더 같은 데이터 수정 불가
  • ALB
    • L7 로드 밸런서
      • HTTP/HTTPS 프로토콜 지원
      • HTTP 헤더 정보 기반 라우팅  기능 제공
        • URL 경로 기반 요청 분산, 호스트 이름 기반 요청 분산, URL 쿼리 문자열 기반 요청 분산
    • IP주소가 항상 변동되기에 Client는 ELB의 DNS Name를 이용
    • 대상 그룹 상태 검사 및 문제 발생 시 장애 조치
    • 대상 그룹 유형: IP, 인스턴스, Lambda, 컨테이너 등
    • 모니터링
      • CloudWatch → 트래픽이 ELB 통과 시 시스템 정상 작동 측정
        • 정상 범위 이탈 시 이메일 알림 보내기 가능
      • 액세스 로그 → Load Balancer에 보낸 요청 캡처 및 S3 저장 가능
      • 요청 추적 → HTTP 요청 추적 가능
      • CloudTrail → ELB API에 대한 요청 정보 캡처 및 S3 저장 가능
    • 보안그룹 사용
    • 주로 웹 애플리케이션을 위한 로드밸런서로 사용
    • SSL 인증서 게시하여 SSL Offload 실시 가능
      • 개별 인스턴스에서 SSL 증명서 설정할 필요 없고 ELB에서만 관리하여 운영 부담 감소
      • 통신 암호화/복호화를 개별 인스턴스에서 수행할 필요 없어 부하 감소
    • Public Subnet에 위치해야함
  • NLB
    • L4 로드 밸런서
      • TCP/UDP/TLS 프로토콜 지원
    • 대규모 트래픽 처리
      • 높은 처리량: 초당 수백만 개 연결 처리
      • 빠른 응답
      • 높은 가용성
    • Elastic IP를 Static IP로 사용해 Client는 고정된 IP 주소를 사용해도 되고, DNS Name을 사용해도 됨
    • 대상 그룹 유형: IP, 인스턴스, ALB, Lambda, 컨테이너
    • 모니터링
      • CloudWatch → 트래픽이 ELB 통과 시 시스템 정상 작동 측정
        • 정상 범위 이탈 시 이메일 알림 보내기 가능
      • VPC 흐름 로그 → VPC 출입 트래픽 정보 캡처
      • 액세스 로그 → Load Balancer에 보낸 TLS 요청 캡처 및 S3 저장 가능
      • CloudTrail → ELB API에 대한 요청 정보 캡처 및 S3 저장 가능
      •  
    • 보안그룹 사용
    • 주로 게임서버, VoIP 서비스, 미디어 스트리밍 등으로 사용
  • GWLB
    • 네트워크 트래픽을 서드파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서
    • 인스턴스로 트래픽 보내기 전에 트래픽 검사/분석/인증/로깅하는 작업 수행

 

출처

 

Application Load Balancer 모니터링 - Elastic Load Balancing

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

Network Load Balancer 모니터링 - Elastic Load Balancing

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

☁️ ELB(Elastic Load Balancer) 구성 & 사용법 가이드

ELB (Elastic Load Balancer) 이란 ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(

inpa.tistory.com

책) 길벗출판사 『AWS 교과서』

'AWS' 카테고리의 다른 글

AWS C03 합격 기록  (0) 2024.02.09
SAA-C03 시험용 정리  (1) 2024.02.09
AWS 데이터베이스 서비스(Amazon RDS, Aurora, DynamoDB, Elasticache)  (0) 2024.01.06
EBS Volume 유형  (0) 2023.12.30
AWS Glue  (0) 2023.12.29

+ Recent posts