AWS 스터디4 (로드밸런서)

로드밸런서?

로드밸런서는 서버에 가해지는 부하를 분산 시켜주는 장치 혹은 기술을 말합니다.

그럼 이 기술이 왜 필요할까요?

현대의 모든 정보는 인터넷을 통해 연결되어 있습니다. 이러한 정보는 보다 많은 트래픽의 증가로 이어졌습니다. 이러한 트래픽 증가는 서버하나가 감당하기엔 너무 많은 양이였습니다. 이러한 트래픽을 효과적으로 분산시켜 클라이언트가 요청하는 정보를 일관성있게 제공하기 위해 로드 밸런서를 이용하게 된 것입니다.

부하분산 종류에는 크게 2가지가 있습니다. SLB와 FWLB가 그것입니다.

SLB(서버부하분산) Server Load Balancing
FWLB(방화벽부하분산) FireWall Load Balancing

로드밸런서는 어떻게 부하를 분산시킬까요?
로드밸런서는 가상 IP(VIP)주소를 갖게 됩니다. 이 가상 IP 주소 하나로만 트래픽을 받게 됩니다. 그리고 이 주소가 각 서버의 실제 IP주소(리얼IP) 와 연결 됩니다. 즉 하나의 가상 IP로 들어온 트래픽을 각각의 서버로 나눠주기 역할을 로드밸런서가 하는 것이죠.

로드밸런서의 이러한 트래픽 분산 대처능력은 크게 두가지가 있습니다.

Scale-up과 Scale-out 입니다

Scale-up : Server가 더 높은 퍼포먼스를 제공하게 끔 하드웨어 성능을 높이는 방법입니다
Scale-out : Server의 갯수를 증가 시켜 트래픽을 분산시키는 방법입니다

부하 분산에는 크게 L4 와 L7 로드밸런서를 가장 많이 사용합니다. L4 로드밸런서부터 포트를 이용해서 분산하는 것이 가능하기 때문입니다. 따라서 서버마다포트 번호를 부여하여 다수 서버 프로그램을 운영하기 위해선 L4 이상을 사용해야 합니다.

L4로드밸런서는 네트워크계층 이나 트랜스 포트 계층의 정보를 이용합니다. IP, MAC주소, 전송 프로토콜 등에 따라 트래픽 나누기가 가능합니다
L7로드밸런서는 어플리케이션 계층에서 이용되기 때문에, HTTP, 쿠키등을 이용하여 분산하는 것이 가능합니다.

헬스 체크?
우리가 건강에 문제가 없는지 건강검진을 받는 것처럼 로드밸런서도 정상적으로 부하분산이 제대로 이루어지고 있는지 확인할 필요가 있습니다. 이렇게 주기적인 건강검진을 하는 작업을 헬스 체크라고 합니다. 헬스 체크를 통해 비정상적인 서버는 서비스 그룹에서 제외 시켜 트래픽을 보내지 않습니다.

헬스 체크 방법
헬스 체크를 하는 방법은 다음과 같습니다

• ICMP

  핑으로 확인하는 방법입니다

• TCP서비스

  TCP의 3-way handshaking을 이용한 방법입니다

• HTTP 상태코드

  TCP의 3-way handshaking 후 HTTP 정상 상태코드(200)을 확인합니다

• 문자열 확인(콘텐츠 확인)

  서버로 문자열 요청후 정상적으로 응답했는지를 확인합니다

로드 밸런싱 알고리즘?

로드밸런서는 다양한 알고리즘을 통해 트래픽 분산을 시행합니다. 알고리즘의 종류는 다음과 같습니다.

• 라운드로빈 방식(Round Robin Method)
• 가중 라운드로빈 방식(Weighted Round Robin Method)
• IP 해시 방식(IP Hash Method)
• 최소 연결 방식(Least Connection Method)
• 최소 리스폰타임(Least Response Time Method)

라운드로빈 방식(Round Robin Method)

서버에 들어온 요청을 순서대로 돌아가며 배정합니다. 각 서버의 성능이 비슷하거나 동일하고 연결(세션)이 오랫동안 지속되지 않는 경우에 사용하기 적합합니다.

가중 라운드로빈 방식(Weighted Round Robin Method)

각 서버마다 가중치를 정하고, 가중치가 높은 서버에 트래픽 요청을 우선적으로 배치합니다.
서버마다 트래픽 처리 성능이 상이할 경우 사용하기 적합합니다.

IP 해시 방식(IP Hash Method)

클라이언트 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방법입니다. Hash값을 이용하여 분배 하기 때문에 항상 동일 서버로의 연결이 보장됩니다.

최소 연결 방식(Least Connection Method)

요청이 들어온 순간 가장 적게 연결된 서버에 우선적으로 트래픽을 분배 합니다. 세션이 길어지거나 서버에 분배된 트래픽들이 일정하지 않을 때 적합합니다.

최소 리스폰타임(Least Response Time Method)

응답시간(요청 후 응답받을 때까지 걸린 시간)을 고려하여 트래픽을 분배합니다. 짧은 응답시간의 서버에 트래픽을 우선 분배 합니다.

로드 밸런서 구성 방식

로드밸런서 구성 방식은 크게 2가지로 나눠집니다.
원암(One-Arm)구성 과 인라인(Inline)구성 입니다. 이 두 구성을 나누는 기준은 서버로 가는 트래픽이 모두 로드밸런서를 경유하는지, 경유하지 않아도 되는지의 따른 트래픽 흐름입니다.

• 원암 구성
  로드 밸런서가 중간 스위치 옆에 연결되는 구성입니다. 원암은 부하분산이 필요한 트래픽만 로드 밸런서를 경유하고 그렇지 않는 트래픽은 로드밸런서를 경유하지 않고 통신할 수 있습니다. LACP와 같은 다수 인터페이스로 스위치 연결된 경우도 이와 같습니다. NAT를 사용하지 않고 DSR 모드를 사용하게 되면 이와같이 구성할 수 있습니다.

  LACP : 단일 스위치의 물리 포트를 여러개를 하나의 논리 포트로 만들어 대역폭을 늘립니다

• 인라인 구성
  로드 밸런서가 서버로 가는 경로상에 연결되는 구성입니다. 인라인은 모든 트래픽이 로드밸런서를 통과해야만 합니다

로드 밸런서 동작 모드

로드 밸런서 모드는 트랜스패런트(브릿지), 라우티드, DSR등이 있습니다.

• 트랜스패런트
  원암과 인라인 모두 사용 가능한 모드 입니다. 원암의 경우 Source NAT가 필요합니다.
  L4로 전달된 목적지 IP주소를 리얼서버 IP 주소로 변조하고 MAC 주소를 변조해서 목적지를 찾아가는 방식입니다.
  요청시
  사용자 > L4 > 로드밸런서(IP/MAC변경) > 서버
  응답시
  실서버 > 로드밸런서(IP변경) > 사용자(출발지 MAC주소는 변경되지 않음)

Source NAT : 패킷의 소스주소를 변경하는 것을 말하며 외부로 나가는 패킷의 Source IP를 G/W의 Public IP로 바꿉니다. DNAT과 반대되는 개념입니다.DNAT의 대표적인 것이 LoadBalancer 입니다

• 라우티드 모드
  로드 밸런서 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성입니다.
  원암과 인라인 모두 사용가능한 모드입니다. 작동 방식은 트랜스 패런트 모드와 동일하지만 출발지의 MAC주소도 변경되는것이 특징입니다.

• DSR모드
  로드 밸런서를 통해 서버로 요청이 들어온후 로드밸런서를 통하지 않고 서버가 사용자에게 직접 응답하는 것이 특징입니다. DSR모드는 로드 밸런서를 경유하지 않음으로 원암으로 구성해야합니다.

AWS의 경우 4가지 종류의 로드 밸런서 유형을 제공합니다

• Application Load Balancer
• Network Load Balancer
• Classic Load Balancer
• Gateway Load Balancer

이중 Classic Load Balancer 는 다른 Balancer들과 다르게 로드 밸런서에 인스턴스를 등록합니다

Application Load Balnacer

특징은 다음과 같습니다

• 어플리케이션 계층(OSI Layer 7)에서 라우팅 결정을 내립니다
• 경로 기반 라우팅을 지원하며, 클러스터의 각 컨테이너 인스턴스 상 1개 이상의 포트 요청 라우팅 할 수 있습니다

  경로기반라우팅은 HTTP 요청 URL 주소를 바탕으로 라우팅 해주는 것을 말합니다

• 동적 호스트 포트 매핑을 지원합니다

  서버 포트 기준 호스트 포트를 지정 범위내에 선택하여 연결 시킵니다

Network Load Balancer

특징은 다음과 같습니다

• 전송 계층(OSI Layer 4)에서 라우팅 결정을 내립니다
• 해시 라우팅 알고리즘 흐름에 따라 대상을 선택합니다

  서버의 소스 및 대상 IP 주소를 사용하여 고유한 해시 키를 생성하는 알고리즘으로 키는 클라이언트를 특정 서버에 할당하는 데 사용됩니다

• 리스너 구성에 지정된 포트에서 선택대상에 대한 TCP연결을 시도합니다

  TCP는 신뢰성 높은 전송 프로토콜입니다

• 헤더를 수정하지 않고 요청전달합니다

  헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적 정보를 전송할 수 있게 해줍니다

• 동적 호스트 포트 매핑을 지원합니다

Gateway Load Balancer

특징은 다음과 같습니다

• 네트워크 계층(OSI Layer 3)에서 작동합니다
• 방화벽, 침입 탐지 방지 시스템, 패킷 검사등을 관리할 수 있습니다
• 어플라이언스 확장하며 트래픽 분산이가능합니다
• 게이트웨이 Load Balancer 엔드포인트를 사용하여 VPC 경계 전체에서 트래픽을 교환합니다

Classic Load Balancer

특징은 다음과 같습니다

• 전송 계층(OSI Layer 4)과 어플리케이션 계층(OSI Layer 7)에서 라우팅 결정을 내립니다

로드밸런서를 생성해보자!

이론을 알았으니 직접 로드밸런서를 생성해봐요! 이번해 볼 작업은 EC2인스턴스 2개를 띄우고 각 EC2 인스턴스에 NGNIX를 설치 한 후 로드밸런서로 연결, 후에 로드밸런서의 VIP로 접속했을시 각 인스턴스의 access.log를 확인하여 분산 접속 되었는지 확인해보는 작업으로 로드밸런서가 제대로 연결되었는지 확인해보겠습니다.

로드밸런서를 생성하기전에 EC2 를 먼저 생성해야 합니다 !

다음과 같이 확인 해볼 EC2를 생성해줍니다. 생성시 외부 접속이 가능하게 하기 위해 퍼블릭 IP 자동할당을 지정해 줍니다. 이는 인스턴스 생성시 외부 IP를 통해 해당 인스턴스에 접속했을시 NGINX 인덱스 페이지가 나타나는지 확인하기 위함입니다.

NGINX는 80번 포트를 통해 통신함으로 보안 규칙에 80번 포트연결을 열어줍니다

위와 같은 방법으로 같은 인스턴스 하나를 더 생성시켜줍니다

이제 인스턴스에 NGINX를 설치해보겠습니다. EC2인스턴스를 클릭하고 연결를 눌러 EC2 콘솔창으로 들어갑니다.

들어간 후 콘솔창에

sudo yum update

를 입력하여 yum을 업데이트 시켜줍니다. 해당 명령어를 입력하면
이런식으로 업데이트가 설치됨을 확인할 수 있습니다. 중간에 옵션을 물어보는 문구가 있는데 y 를 눌러 계속 진행합니다

yum업데이트가 완료되면 이제 NGINX를 설치해보겠습니다.

sudo amazon-linux-extras install -y nginx1

를 입력하여 NGINX를 설치해줍니다

설치가 시작되면 이와 같은 화면이 보이게됩니다. 후에 설치가 완료되면 다음 명령어를 입력하여 NGINX를 실행시켜줍니다

sudo service nginx start

정상 실행되면 이 명령어를 통해 활성화 됨을 확인할 수 있습니다

systemctl status nginx

NGINX설치 완료 후 실행까지 했습니다. 이제 access.log파일을 불러 실시간으로 해당 인스턴스의 NGINX에 접속 기록을 확인해보겠습니다. 먼저 NGINX 로그 파일이 어디있는지 알아야 합니다.
루트 최상단으로 이동하여

find -name nginx

를 입력하여 nginx log폴더를 찾아봅니다

sudo tail -f /var/log/nginx/access.log

tail 명령어를 사용하여 access.log에 쌓인 기록을 호출해 보도록 하겠습니다. 이제 해당 인스턴스의 NGINX에 접속 되면 해당 로그를 통해 확인할 수 있습니다!

위와 같은 방법으로 생성했던 또다른 인스턴스에도 NGINX를 설치해 줍니다

빠른 설치를 위해 여태까지 썼던 명령어를 모아 놓았습니다.

sudo yum update
sudo amazon-linux-extras install -y nginx1
sudo service nginx start
sudo tail -f /var/log/nginx/access.log

NGINX 가 정상 설치 및 실행이 되었다면. 인스턴스의
퍼블릭 Ipv4 주소:80을 인터넷 주소창에 치게되면 인덱스 페이지를 확인할 수 있습니다.
위의 인스턴스를 예시로 들면 13.124.72.30:80 으로 치면 되겠습니다

또한 인스턴스 콘솔 창에는 이와 같이 접속한 환경에 대한 기록이 잡히게 됩니다

이제 로드밸런서를 생성해 보겠습니다 !

EC2대시 보드 아래에 로드밸런서 항목으로 들어갑니다.
Load Balancer생성을 클릭합니다

저는 Application Load Balancer로 생성하겠습니다

저는 미리 생성한 VPC를 통해 로드밸런서를 생성하겠습니다. 로드밸런서로 연결할 서브넷을 지정해 줄 수 있습니다.

따로 리스너 설정없이 간단한 확인을 할 것임으로 넘어가줍니다

보안그룹을 설정합니다. NGINX는 80번 포트가 열려있어야 외부통신이 가능함으로 해당 보안 규칙을 추가해 주겠습니다

인스턴스 대상으로 연결시킬 것이기 때문에 다음과 같이 설정하고 넘어갑니다

아까 생성했던 인스턴스를 대상으로 등록 시켜줍니다(로드밸런서를 연결할 인스턴스를 지정해줍니다)

설정한 값이 제대로 되었는지 확인해봅니다

로드밸런서 설정이 완료되었습니다!

이제 대상 그룹에 들어가 라우팅할 인스턴스를 설정해주어야 합니다
왼쪽의 메뉴에서 대상그룹으로 들어가 아까 로드밸런서 설정시 생성한 라우팅 이름을 클릭합니다

Register targets를 눌러 아까 생성했던 인스턴스를 추가해줍니다

정상 추가가 완료된다면 아래와같은 화면에 뜹니다

이제 모든 작업을 완료하였습니다. 우리가 구성한 로드밸런서가 정상적으로 작동하는지 확인해보겠습니다

확인하는 방법은 간단합니다. 로드밸런서 DNS주소로 접속하여 콘솔창에서 우리가 위에서 접속했을시 생겼던 로그가 남는지 확인하면 됩니다.

우리가 생성했던 로드밸런서를 선택하고 아래창에 보면 기본 구성 아래에 DNS 이름이 있습니다. 이 주소를 복사하여 주소창에 붙여 넣기 해봅니다

주소창에 이와 같이 붙여 넣으시면 됩니다. (저같은 경우 깜빡잊고 화면 캡처를 못해서 로드밸런서를 다시만들었기 때문에 DNS이름이 다릅니다.)

아까 만들었던 인스턴스 콘솔창 2개를 띄어놓고 해당 주소로 접속후 새로고침을 눌러주면 각 인스턴스 콘솔창에 access.log가 올라가는것을 확인할 수 있습니다. 이렇게요!!

이상으로 포스팅을 마치겠습니다!