Load Balancing

Load Balancing은 시스템으로 유입되는 대량의 트래픽을 다수의 서버로 분산시켜 안정적인 서비스 운영을 지원합니다. 카카오 i 클라우드의 Load Balancing은 하드웨어 기반으로 초당 100만 이상의 커넥션에도 대응할 수 있도록 구성되어 있습니다. 사용자는 Load Balancing의 성능에 대한 고려 없이 사용자의 서비스에만 집중할 수 있습니다. Load Balancing 서비스는 크게 Load Balancer와 Target Group 리소스로 구성됩니다.

스케일 아웃

Load Balancing은 스케일 아웃(Scale-out, 수평 확장)을 통해 대규모 트래픽에 대응하고, Health Check를 기반으로 정상적인 서버에만 트래픽을 분배해 시스템의 가용성을 향상시킵니다. 사용자는 트래픽이 증가할 때 인스턴스 타입을 더 높은 사양으로 변경해 대응하는 스케일 업(Scale-up, 수직 확장) 전략을 선택할 수 있습니다. 하지만 스케일 업 전략은 인스턴스의 최대 사양이 정해져 있어 보다 더 높은 사양으로 변경하는데 한계가 있습니다. 또한, 사양 변경 시점에 일시적으로 인스턴스가 정지된다는 단점이 있습니다. 반면, 스케일 아웃(Scale-out, 수평 확장) 전략은 인스턴스의 사양이 아닌 수를 늘리는 전략으로 인스턴스의 최대 사양과 관계 없이 증가하는 트래픽에 효율적으로 대응할 수 있습니다. 이러한 스케일 아웃 전략은 Load Balancing을 통해 구현할 수 있습니다.

Load Balancing은 다수의 인스턴스의 상단에 위치해 각 인스턴스로 트래픽이 분산되도록 구성됩니다. 카카오 i 클라우드 콘솔에서는 Load Balancer를 생성하고 연결된 Target Group에 인스턴스를 추가하는 것만으로 간편하게 스케일 아웃을 구현할 수 있습니다. 스케일 아웃 구현에 대한 자세한 설명은 Application Load Balancer 또는 Network Load Balancer 가이드를 참고하시기 바랍니다.

안내
오토스케일링은 메트릭 및 스케줄을 기반으로 사용자의 개입 없이 자동으로 스케일 아웃을 구현할 수 있는 기능입니다. 오토스케일링은 추후 지원 예정입니다.

접근 권한

프로젝트에 등록된 멤버는 프로젝트 내 생성된 모든 Load Balancer에 대한 접근 권한을 갖습니다. 프로젝트의 멤버를 추가하거나 제외해 생성된 Load Balancer에 대한 접근 권한을 관리할 수 있습니다.

안내
프로젝트 멤버 관리에 대한 자세한 설명은 IAM > 역할 관리하기를 참고하시기 바랍니다.

Load Balancer

Load Balancer는 트래픽을 받아 분산시키는 역할을 수행합니다. 트래픽이 유입되는 포트인 Listener를 정의하고, Listener와 Target Group을 연결하면 유입된 트래픽을 설정된 Target으로 분산시킬 수 있습니다. 사용 목적에 따라 Application Load Balancer와 Network Load Balancer를 선택할 수 있습니다.

Application Load Balancer(ALB)는 OSI 7계층인 애플리케이션 계층에서 트래픽을 처리합니다. ALB의 Listener는 HTTP, HTTPS 프로토콜을 선택할 수 있으며, 하나의 기본 Target Group을 연결합니다. 각 Listener에는 기본 Target Group 이외에도 L7규칙을 추가하여 규칙에 따른 라우팅을 설정할 수 있습니다. Network Load Balancer(NLB)는 OSI 4계층인 네트워크 계층에서 트래픽을 처리합니다. NLB의 Listener는 TCP, UDP 프로토콜을 선택할 수 있으며, 하나의 기본 Target Group을 연결합니다. Listener로 유입된 트래픽은 모두 기본 Target Group으로 라우팅됩니다. Target Group 내에서 각각의 Target에 트래픽을 전달하는 알고리즘은 Target Group 단위에서 설정할 수 있습니다.

표 ALB와 NLB 비교

	ALB	NLB
프로토콜	HTTP, HTTPS	TCP, UDP
계층	L7	L4
보안정책	HTTPS 프로토콜만 적용	X
인증서	HTTPS 프로토콜만 적용	X
L7 규칙/조건	O	X
Public IP 할당	O	O
Sticky Session	HTTP 프로토콜만 적용	O
HTTP 헤더 정책(X-Forward-For)	O	X
연결 유휴 제한	O	O

네트워크와 Public IP

Load Balancer를 VPC 기반 사용자 네트워크에 배포하고, Public IP를 연결해 외부에 공개할 수 있습니다. Load Balancer는 Load Balancer가 배포된 서브넷의 대역에서 하나의 Private IP를 할당받습니다. 네트워크 내부의 다른 자원은 Load Balancer에 할당된 Private IP를 통해 Load Balancer에 접근할 수 있습니다. 사용자가 Public IP를 Load Balancer에 연결하면 인터넷에 공개할 수 있으며, Public IP 주소를 통해 외부에서 접근할 수 있습니다. Public IP 연결 해제 시, 인터넷 접근은 차단되며 Load Balancer가 배포된 네트워크 내부에서만 Private IP를 통해 접근할 수 있습니다.

상태

Load Balancer는 두 가지의 상태 정보를 확인할 수 있습니다. 리소스가 정상적으로 생성되었는지 또는 수정이나 삭제가 진행중인지를 알려주는 Provisioning 상태와, 생성된 리소스가 사용 가능한 상태인지를 알려주는 Operating 상태입니다. 두 가지의 상태 모두 하위 리소스의 상태를 조합하여 표시됩니다. 상위 리소스의 생성, 수정, 삭제가 진행되는 중에는 하위 리소스의 작업이 불가능합니다. 즉, Load Balancer의 생성, 수정, 삭제가 진행중인 경우에는 Listener와 Target Group의 정보를 변경하거나 삭제할 수 없습니다.

표 Load Balancer Provisioning 상태

상태	정의
Active	Load Balancer Provisioning 성공
Error	Load Balancer Provisioning 실패
Creating	Load Balancer가 생성 진행중
Updating	Load Balancer가 수정 진행중이거나 하위 리소스의 생성/수정/삭제가 진행중 - Load Balancer의 하위 리소스: Listener, L7규칙/조건, Target Group, Target, Health Check
Deleting	Load Balancer가 삭제 진행중

표 Load Balancer Operating 상태

상태	정의
Online	Load Balancer가 정상적으로 동작
Offline	관리상 비활성화된 상태
Error	Load Balancer가 에러 상태이거나 하위 리소스 중 일부가 에러 상태 - Load Balancer의 하위 리소스: Listener, L7규칙/조건, Target Group, Target, Health Check

Listener

Listener는 트래픽이 유입되는 포트입니다. 하나의 Load Balancer에 여러 개의 Listener를 추가할 수 있으며, 각각의 Listener는 하나의 기본 Target Group과 연결됩니다. ALB의 Listener(HTTP, HTTPS)에는 L7규칙과 조건을 추가하여 트래픽을 세밀하게 분산시킬 수 있습니다. HTTPS Listener의 경우 SSL 인증서를 적용해 암호화된 트래픽을 해독합니다.

상태

Listener는 두 가지의 상태 정보를 확인할 수 있습니다. 리소스가 정상적으로 생성되었는지 또는 수정이나 삭제가 진행중인지를 알려주는 Provisioning 상태와, 생성된 리소스가 사용 가능한 상태인지를 알려주는 Operating 상태입니다. 두 가지의 상태 모두 하위 리소스의 상태를 조합하여 표시됩니다. 상위 리소스의 생성, 수정, 삭제가 진행되는 중에는 하위 리소스의 작업이 불가능합니다. 즉, Load Balancer의 생성, 수정, 삭제가 진행중인 경우에는 Listener와 Target Group의 정보를 변경하거나 삭제할 수 없습니다.

표 Listener Provisioning 상태

상태	정의
Active	Listener Provisioning 성공
Error	Listener Provisioning 실패
Creating	Listener가 생성 진행중
Updating	Listener가 수정 진행중이거나 하위 리소스의 생성/수정/삭제가 진행중 - Listener의 하위 리소스: (해당 Listener와 연결된) L7규칙/조건, Target Group, Target, Health Check
Deleting	Listener가 삭제 진행중

표 Listener Operating 상태

상태	정의
Online	Listener가 정상적으로 동작
Offline	관리상 비활성화된 상태
Error	Listener가 에러 상태이거나 하위 리소스 중 일부가 에러 상태 - Listener의 하위 리소스: (해당 Listener와 연결된) L7규칙/조건, Target Group, Target, Health Check

Listener 프로토콜

Listener의 프로토콜은 Load Balancer와 클라이언트가 통신하는 규칙 체계를 의미합니다. 사용자는 HTTP, HTTPS, TCP, UDP 중 하나의 프로토콜을 선택할 수 있습니다. Listener로 유입된 트래픽은 기본 Target Group으로 분산됩니다. Listener의 프로토콜에 따라 기본 Target Group으로 설정할 수 있는 Target Group이 제한됩니다.

표 Listener 프로토콜과 Target Group 프로토콜 조합

Load Balancer	Listener 프로토콜	Target Group 프로토콜
ALB	HTTP	HTTP, PROXY
	HTTPS	HTTP
	미선택	HTTP, PROXY
NLB	TCP	HTTP, HTTPS, TCP, PROXY
	UDP	UDP
	미선택	HTTP, HTTPS, TCP, PROXY, UDP

기본 동작

Listener로 수신된 트래픽을 처리하는 기본 방식으로 Listener의 기본 동작은 Forward로 고정됩니다. 하나의 Target Group을 선택할 수 있으며 선택한 Target Group은 기본 Target Group으로 동작합니다.

L7 규칙 및 조건

L7 규칙은 ALB의 Listener(HTTP, HTTPS)에서만 사용되는 7계층 Load Balancing 설정입니다. Listener마다 하나 이상의 규칙을 추가할 수 있으며, 규칙의 순서를 변경할 수 있습니다. 각 규칙의 동작 방식을 선택하고 여러 개의 조건을 추가해 세밀한 라우팅을 구성 가능합니다. 조건은 URL경로, 도메인 이름 등 HTTP 요청에서 사용되는 정보를 기반으로 설정합니다. 트래픽이 유입되면 규칙 내의 조건에 맞는지 TRUE 또는 FALSE로 판별하고 모든 조건이 TRUE인 경우 해당 규칙의 동작이 수행됩니다.

L7 규칙

규칙의 동작 방식은 Forward, Redirect To URL, Redirect Prefix 중 하나를 선택할 수 있습니다. Forward를 선택하는 경우 하나의 Target Group을 필수로 연결해야 합니다. 이 때, 연결 가능한 Target Group은 Listener와 Target Group 프로토콜 관계와 동일합니다. 또한 다른 Load Balancer에 연결된 Target Group은 선택할 수 없습니다. Redirect To URL과 Redirect Prefix 선택 시, 프로토콜과 URL, 응답 코드를 설정할 수 있습니다. 한 규칙 내에서 서로 다른 조건 유형은 ‘AND’로 연산하지만, 동일한 조건 유형은 ‘OR’로 연산하여 최종적으로 TRUE인지를 판단합니다. TRUE로 판단되었을 때 설정한 동작이 수행됩니다.

표 L7 규칙 동작 방식

규칙 동작 방식	설명
Forward	Target Group으로 전달
Redirect To URL	URL로 전달
Redirect Prefix	접두사 URL로 전달

L7 조건

조건은 Host-Header, Path, HTTP-Header, Cookie, File Type 중 하나의 유형을 선택해 추가할 수 있습니다. 하나의 규칙 내에 여러 개의 조건을 추가할 수 있으며, 같은 유형의 조건도 추가 가능합니다. 각 조건은 유형과 비교 타입을 선택할 수 있고 선택한 값에 따라 키나 값을 입력합니다.

표 L7 조건 유형

조건 유형	설명
Host-Header	URI 호스트 이름과 조건의 값과 비교
Path	URI의 경로 부분을 조건의 값과 비교
HTTP-Header	URI 헤더에서 키에 정의된 헤더를 찾아 조건의 값과 비교
Cookie	URI 헤더에서 키에 정의된 쿠키를 찾아 조건의 값과 비교
File Type	URI의 끝에 있는 파일 유형을 조건의 값과 비교(예: “txt”, “jpg” 등)

표 L7 조건 비교 방식

비교 방식	설명
일치 / 일치하지 않음	키의 값 혹은 키가 없을 경우 값이 문자열과 일치하거나 일치하지 않음
포함 / 포함하지 않음	문자열이 값을 포함하거나 포함하지 않음
시작 값 / 시작하지 않음	문자열이 값으로 시작하거나 시작하지 않음
마지막 값 / 끝나지 않음	문자열이 값으로 끝나거나 끝나지 않음

표 조건 유형에 따른 비교 방식 및 입력 항목

조건 유형	비교 방식	입력 항목
Host-Header	모두 가능	값
Path	모두 가능	값
HTTP-Header	모두 가능	키, 값
Cookie	모두 가능	키, 값
File Type	‘일치 / 일치하지 않음’만 가능	값

타임아웃

Load Balancer와 클라이언트, Load Balancer와 Target과의 연결 제한 시간을 설정합니다. 설정한 시간을 초과할 때까지 데이터의 전달이 이루어지지 않으면 연결이 종료됩니다.

대용량 파일 업로드와 같이 시간이 오래 걸리는 작업을 수행하는 경우, 제한 시간 내에 1바이트 이상의 데이터 전송이 이루어지고 있는지 확인하거나 허용 시간을 늘려야 합니다. 시간은 1초에서 최대 4000초까지 설정할 수 있습니다. 타임아웃 시간을 길게 설정하는 경우, 클라이언트의 연결 상태가 해당 시간만큼 유지되기 때문에 최대 커넥션 설정값을 반드시 고려해야 합니다.

표 타임아웃 설정 항목

구분	설명
Idle Timeout	Load Balancer 연결이 유휴 상태(데이터를 주고 받지 않는 상태)일 때 허용하는 시간 -기본값: 50초 -해당 시간이 지나면 연결 종료

Listener HTTP 헤더 정책 설정

X-Forwarded-For header는 HTTP 프록시나 Load Balancer를 통해 웹 서버에 접속하는 클라이언트의 Source IP 주소를 식별할 수 있는 정보입니다. ALB Listener에서만 설정할 수 있습니다. 클라이언트의 정보를 Source IP를 확인하기 위해 X-Forwarded-For 요청 헤더가 사용됩니다. X-Forwarded-For header 처리 옵션으로 보존과 처리 중 선택 가능하며, X-Forwarded-Port 전송과 X-Forward-Proto 전송의 사용 여부를 설정할 수 있습니다.

표 X-Forwarded 설정 항목

구분	설명
X-Forwarded-For header 처리	- 추가(Append): HTTP요청의 X-Forward-For 헤더에 Client IP 주소(마지막 홉)를 추가 - 보존(Preserve): HTTP 요청의 X-Forward-For 헤더를 보존
X-Forwarded-Port 전송	HTTP의 헤더에 클라이언트 요청의 포트를 보존하여 Target에 전송
X-Forwarde-Proto 전송	HTTP 헤더에 클라이언트 요청의 원래 프로토콜을 보존하여 Target에 전송(http→http, https→https)

최대 커넥션

Listener에서 연결을 유지할 수 있는 최댓값을 제한할 수 있습니다. 이는 서비스 품질을 유지하기 위해 사용하며, 초기 생성 시에는 최대 커넥션 제한 ‘미사용’으로 설정됩니다. 사용 설정 시에는 1이상 2,147,483,647 이하의 값을 입력할 수 있습니다.

SSL 인증서

HTTPS Listener를 사용하는 경우, Load Balancer에 최소한 한개 이상의 SSL 인증서를 설정해야 합니다. Load Balancer는 등록된 인증서를 기반으로 SSL Handshake와 암호화 및 복호화를 처리합니다. 인증서는 계정 단위로 관리되며, 계정이 소유한 인증서 중에서 선택할 수 있습니다. 등록한 인증서가 없거나 기존에 보유한 인증서를 등록하여 사용하고 싶은 경우, 새 인증서 추가 기능을 사용할 수 있습니다. 새 인증서를 등록하기 위해서는 PEM 인코딩된 프라이빗 키, 본문, 체인 값이 필요합니다.

표 인증서 관리

구분	설명
SSL 기본 인증서	HTTPS Listener 생성 시 처음 지정한 인증서로, 사용자가 SNI 프로토콜을 사용하지 않고 호스트 이름을 지정하여 연결한 경우 기본적으로 사용되는 인증서 - 기본 인증서는 Listener에서 해제 불가하며, 설정한 기본 인증서를 해제하려면 다른 인증서를 등록하여 교체
SSL 추가 인증서	기본 인증서가 아닌 추가 인증서를 Listener당 5개까지 등록 가능
SSL 인증서 등록 및 보관	Load Balancer 만들기 또는 Listener 추가 팝업창의 HTTPS Listener 생성 과정에서 인증서를 등록하거나, HTTPS 인증서 생성 후 Listener 상세 화면에서 인증서 등록 가능 - PEM 형식의 인증서 프라이빗 키, 인증서 본문, 인증서 체인을 입력하면, 해당 정보들은 PKCS12 포맷으로 변환하여 별도의 암호화 스토리지에 보관됨 - 보관된 인증서는 HTTPS Listener에 인증서를 설정할 때 목록에서 확인
SSL 인증서 해제	Listener 상세 화면에서 Listener에 설정된 인증서 해제 - 기본 인증서는 해제할 수 없으며 HTTPS Listener는 최소 1개 이상의 인증서 지정 필요
SSL 인증서 삭제	Listener 상세 화면에서 보관된 인증서 삭제

보안 정책

SSL 인증서 설정과 더불어 최소 지원 TLS 버전을 설정할 수 있습니다. HTTPS Listener에서만 설정 가능하며, 클라이언트가 보안 연결을 설정하는 데 도움을 줍니다. 제공하는 TLS Ciphers Suite 정책 중 한 가지를 선택하여 적용합니다. TLS Ciphers Suite란 클라이언트와 Load Balancer 사이의 HTTPS 통신을 위해 사용되는 보안 정책의 묶음입니다. 지원하는 TLS 프토토콜 버전 및 Ciphers Suite 목록은 달라질 수 있습니다.

표 보안 정책 최소 TLS 버전

보안 정책 최소 TLS 버전	TLSv1.0	TLSv1.1	TLSv1.2
TLS 프로토콜
TLSv1.0	v
TLSv1.1	v	v
TLSv1.2	v	v	v
Cipher Suite
ECDHE-RSA-AES128-GCM-SHA256			v
ECDHE_RSA_AES128_CBC_SHA
(ECDHE-RSA-AES128-SHA)	v	v	v
ECDHE-RSA-AES128-SHA256			v
ECDHE-RSA-AES256-GCM-SHA384			v
ECDHE_RSA_AES256_CBC_SHA
(ECDHE-RSA-AES256-SHA)	v	v	v
ECDHE-RSA-AES256-SHA384			v
AES128-GCM-SHA256			v
AES128-SHA	v	v	v
AES128-SHA256			v
AES256-GCM-SHA384			v
AES256-SHA	v	v	v
AES256-SHA256			v
CAMELLIA128-SHA	v	v	v
CAMELLIA256-SHA	v	v	v
DHE-RSA-AES128-GCM-SHA256			v
DHE-RSA-AES128-SHA	v	v	v
DHE-RSA-AES128-SHA256			v
DHE-RSA-AES256-GCM-SHA384			v
DHE-RSA-AES256-SHA	v	v	v
DHE-RSA-AES256-SHA256			v
DHE-RSA-CAMELLIA128-SHA	v	v	v
DHE-RSA-CAMELLIA256-SHA	v	v	v
ECDHE_ECDSA_AES128_SHA	v	v	v

Target Group

Target Group은 Target의 묶음을 의미합니다. Target은 인스턴스, IP 주소와 같은 리소스로 Load Balancer에 유입된 트래픽이 분산되는 대상입니다. Listener에서 수신한 트래픽은 각 Listener에서 설정한 조건에 따라 Target Group으로 라우팅됩니다. Target Group에는 Health Check 설정을 적용할 수 있으며, Target Group에 포함된 모든 Target에 대하여 상태를 확인합니다.

Target Group 프로토콜과 라우팅 구성

Target Group은 프로토콜을 지정할 수 있고 Target 단위로 포트를 지정할 수 있습니다. 카카오 i 클라우드에서는 HTTP, HTTPS, TCP, UDP, PROXY 프로토콜을 지원하며 연결하려는 Load Balancer 또는 Listener에 따라 Target Group 프로토콜 선택이 제한됩니다.

Application Load Balancer(ALB)의 HTTP Listener에는 HTTP, PROXY Target Group을, HTTPS Listener는 HTTP Target Group을 연결할 수 있습니다. Network Load Balancer(NLB)의 TCP Listener에는 HTTP, HTTPS, TCP, PROXY Target Group을, UDP Listener에는 UDP Target Group을 연결할 수 있습니다. Listener를 선택하지 않고 Target Group을 생성하는 경우 각각의 Load Balancer 타입에 가능한 프로토콜만 선택 가능합니다. Listener를 선택하지 않고 생성한 후에 Listener에 연결하는 경우, 동일한 규칙에 의해서만 연결할 수 있습니다. 하나의 Target Group은 동일한 Load Balancer의 여러 Listener나 L7규칙에 연결될 수 있으나, 두 개 이상의 Load Balancer와는 연결할 수 없습니다.

표 Listener 프로토콜과 Target Group 프로토콜 조합

Load Balancer	Listener 프로토콜	Target Group 프로토콜
ALB	HTTP	HTTP, PROXY
	HTTPS	HTTP
	미선택	HTTP, PROXY
NLB	TCP	HTTP, HTTPS, TCP, PROXY
	UDP	UDP
	미선택	HTTP, HTTPS, TCP, PROXY, UDP

안내
Target은 Load Balancer와 동일한 네트워크에 배포된 인스턴스로 제한됩니다.

Health Check

Load Balancer는 Target의 상태를 확인하기 위해 일정 주기로 Health Check를 수행합니다. Target Group에 Health Check 설정을 적용해 Target Group에 연결된 자원의 상태를 확인하고 장애가 발생한 서버를 트래픽 분배 대상에서 제외할 수 있습니다.

Target Group을 생성할 때 Health Check 사용 여부를 선택할 수 있습니다. Health Check를 사용하지 않는 경우에는 Target의 Operating 상태가 No Monitor로 표시됩니다. 이 때, Target Group의 Operating 상태는 Online이므로 정상적으로 라우팅이 동작합니다. Health Check를 사용으로 설정하면, Health Check 타입과 체크 주기, 타임아웃 시간, 상태 전환 기준(성공, 실패)을 설정할 수 있습니다. 타입으로 HTTP를 선택하는 경우에는 HTTP 메서드, 버전, 상태 코드, 체크 경로 등을 추가로 설정할 수 있습니다. 제공되는 기본값을 수정하여 사용자 환경에 맞게 조정 가능합니다. Health Check가 이루어지는 Target의 모니터 포트는 기본적으로 Target의 포트와 동일하지만, Target의 모니터 포트 설정에서 포트를 변경할 수 있습니다.

Target Group의 프로토콜에 따라 적용 가능한 Health Check 타입은 다음과 같습니다.

표 Target Group 프로토콜과 Health Check 타입 조합

Target Group 프로토콜	Health Check 타입
HTTP	HTTP, PING
HTTPS	HTTPS, PING
TCP	PING, TCP
UDP	TCP, HTTP
PROXY	PING, TCP

표 Health Check 타입

Health Check 타입	설명
PING	Target에 패킷을 전송하고 Target이 보낸 응답을 확인(ICMP Ping)
HTTP	설정한 경로로 패킷을 전송하고 응답을 확인
HTTPS	인증서를 사용하는 Target을 대상으로 HTTP와 동일한 방식으로 응답을 확인
TCP	TCP 프로토콜 포트를 이용하여 Target의 상태를 확인

Target

Target은 Target Group으로 전달된 트래픽이 분산되는 대상입니다. Target Group이 연결된 Load Balancer와 동일한 가용 영역에 있으면서 같은 VPC에 있는 인스턴스를 선택할 수 있습니다. Target 등록 시에는 포트 번호를 함께 지정하며, 한 Target Group 내에서는 동일한 인스턴스와 포트 조합을 중복해서 등록할 수 없습니다. 이 때 인스턴스와 포트 조합을 판단하는 기준은 인스턴스의 기본 네트워크 인터페이스의 Primary IP(Private)입니다. 사용하지 않는 Target은 연결을 해제할 수 있습니다. 연결 해제 시 라우팅 대상에서만 해제되며 인스턴스에는 영향을 미치지 않습니다.

상태

Target은 두 가지의 상태 정보를 확인할 수 있습니다. 리소스가 정상적으로 생성되었는지 또는 수정이나 삭제가 진행중인지를 알려주는 Provisioning 상태와, 생성된 리소스가 사용 가능한 상태인지를 알려주는 Operating 상태입니다. 두 가지의 상태 모두 하위 리소스의 상태를 조합하여 표시됩니다.

Target의 상태를 확인하기 위해서는 Health Check 설정을 적용해야 하며, Health Check를 설정하지 않는 경우 ‘No Monitor’ 상태로 표시됩니다. Health Check 설정 적용 시, Target Group에 등록된 모든 Target에 대하여 주기적으로 Health Check를 수행합니다. 각각의 Target 상태는 Target Group 상세에서 확인할 수 있으며, 정상 상태가 아닌 Target은 트래픽 분산 대상에서 자동으로 제외됩니다. 이후 다시 정상 상태로 판단되면 트래픽을 라우팅합니다.

표 Target의 Provisioning 상태

상태	정의
Active	Target Provisioning 성공
Error	Target Provisioning 실패
Creating	Target 생성 진행중
Updating	Target 수정 진행중
Deleting	Target 삭제 진행중

표 Target의 Operating 상태

상태	정의
Healthy	Target이 정상적으로 동작함
Draining	Target의 가중치가 0으로 입력된 상태
Offline	Target Group에 인스턴스를 추가하여 Health Check를 기다리는 중
No Monitor	Health Check를 사용하지 않음
Unhealthy	Health Check에 응답하지 않거나 상태 확인에 실패
Invalid	Target으로 등록된 인스턴스가 삭제됨

Security Group

Load Balancer가 정상적으로 동작하기 위해서는 Health Check 포트 IP가 통신할 수 있도록 정책을 구성해야 합니다. Target Group Health Check IP 조회를 참고하여 해당 IP를 Target으로 추가한 인스턴스의 보안그룹 인바운드 정책으로 추가하시기 바랍니다.

안내
Health Check 타입을 Ping으로 사용 시, 같은 방법으로 ICMP 포트를 인바운드 정책으로 설정해야 합니다.

알고리즘

Target Group의 알고리즘은 Target에 트래픽을 라우팅하는 방식입니다. 일반적으로 각 Target에 순차적으로 트래픽을 전달하는 Round Robin 방식을 사용합니다. 옵션으로 제공하는 Least Connections을 선택하면 연결된 세션이 가장 적은 Target에 트래픽을 전달하여 모든 Target의 부하 상태를 균등하게 유지할 수 있습니다.

• Round Robin: Target Group 내의 Target에 순차적으로 트래픽을 전달하므로 모든 Target이 동일한 서비스를 제공하는 경우에 적합함
• Least Connections: 커넥션이 가장 적은 Target에 트래픽을 전달하므로 Target의 부하 상태를 균등하게 유지할 수 있음

Sticky Session

기본적으로 알고리즘에 따라 Target으로 라우팅되지만, Sticky Session을 사용하면 동일한 클라이언트의 요청은 동일한 Target과 연결됩니다. 서비스 이용 시 연속되는 경험을 제공하기 위하여 사용할 수 있습니다. 카카오 i 클라우드에서는 HTTP Cookie, App Cookie, Source IP 방식을 제공합니다. Listener와 Target Group의 프로토콜 조합에 따라 설정 가능한 타입이 다르며, 설정한 타입에 따라 추가 입력이 필요한 항목이 있습니다.

표 Sticky Session 방식

Sticky Session	정의
HTTP Cookie	Load Balancer가 임의로 생성한 쿠키를 사용해 연결 - Stickiness Duration 추가 설정
App Cookie	사용자가 구체적으로 명시한 쿠키 이름을 사용해 연결 - Stickiness Duration, Cookie name 추가 설정
Source IP	클라이언트의 IP를 기준으로 연결 - Sticky IP-netmask 추가 설정

표 Listener와 Target Group 프로토콜 조합에 따라 설정 가능한 타입

Listener-Target Group 프로토콜	Sticky Session
HTTP-HTTP	HTTP Cookie, App cookie
TCP-TCP	Source IP
UDP-UDP	Source IP

가중치

사용자 환경에 따라 Target별로 서로 다른 가중치를 부여할 수 있습니다. Target Group 생성 시에는 모든 Target이 동일한 가중치를 갖습니다. Target Group 생성 후 가중치 설정 화면에서 1 이상 256 이하의 정수를 입력하면 가중치 환산 계산식에 의하여 환산값이 표시됩니다. 그리고 환산된 값의 비율로 트래픽이 분배됩니다.

• 가중치 환산 = (가중치/256)*100 (소숫점 첫째자리 올림)

가중치를 0으로 변경하면, Target의 상태는 Draining로 나타나지만 해당 Target에 연결된 세션은 세션이 종료될 때까지 유지됩니다. 그러므로 Target Group에서 특정 Target을 제외하고 싶은 경우, 즉시 연결을 해제하는 것보다 가중치를 0으로 변경 후 해제하는 것이 좋습니다. 서비스를 이용중인 사용자의 연결이 강제로 종료되지 않기 때문에 안정적인 서비스 운영에 도움이 됩니다.

모니터 포트

모니터 포트란 Health Check가 이루어지는 Target의 포트입니다. 기본적으로 Target의 트래픽 포트와 동일하게 설정되어 있습니다. 사용자의 설정에 따라 다른 포트로 변경도 가능합니다. 그러나 Health Check 결과와 실제 서비스 가능 여부가 다를 수 있으므로 권장하지 않습니다.

표 Target 포트와 모니터 포트 설정에 따른 케이스

모니터 포트 설정	Target Health Check 결과	Target의 실제 서비스 상태	Load Balancing 작동 여부	설명
Target 포트와 동일	Healthy	Healthy	O
	Unhealthy	Unhealthy	X
Target 포트와 다름	Healthy	Healthy	O
	Healthy	Unhealthy	O	서버가 정상적인 서비스를 제공하지 못하지만, Health Check 결과 Healthy로 판단되어 요청을 전달하는 상태 → 클라이언트는 서비스를 이용할 수 없음
	Unhealthy	Healthy	X	서버가 정상적인 서비스를 제공함에도 불구하고, Health Check 결과 Unhealthy로 판단되어 요청을 전달하지 않는 상태 → 다른 서버의 처리량이 증가해 장애가 발생해도 대응하기 어려움
	Unhealthy	Unhealthy	X

---

Deprecated Load Balancer

2023년 5월 31일 이전에 생성된 Load Balancer를 Deprecated 타입으로 정의합니다. 5월 31일부터는 해당 타입의 Load Balancer를 생성할 수 없습니다. 사용 목적에 따라 Application Load Balancer(ALB) 또는 Network Load Balancer(NLB)를 선택하여 사용해 주세요.

Deprecated Load Balancer는 L4, L7 레이어에서 작동하며 HTTP, HTTPS, TCP, UDP 프로토콜을 지원합니다.

Listener 프로토콜

Deprecated Load Balancer는 ALB, NLB와 달리 하나의 Load Balancer에 4가지 프로토콜(HTTP, HTTPS, TCP, UDP )을 모두 지원합니다. 각 Listener에 연결 가능한 Target Group의 프로토콜은 다음과 같습니다.

표 Listener 프로토콜과 Target Group 프로토콜 조합

Load Balancer	Listener 프로토콜	Target Group 프로토콜
Deprecated Load Balancer	HTTP	HTTP, PROXY
	HTTPS	HTTP
	TCP	HTTP, HTTPS, TCP, PROXY
	UDP	UDP

Listener HTTP 헤더 정책 설정

Deprecated Load Balancer에서는 HTTP, HTTPS Listener에 HTTP 헤더 정책을 설정할 수 있으며, 지원하는 정책은 다음과 같습니다.

표 Deprecated Load Balancer의 HTTP 헤더 정책

구분	설명
X-Forwarded-For	클라이언트가 Load Balancer와의 연결에 사용한 IP 확인
X-Forwarded-Port	클라이언트가 Load Balancer와의 연결에 사용한 포트 확인

L7 정책/규칙

Deprecated Load Balancer에서는 L7 정책을 추가하고 L7 규칙을 설정할 수 있습니다.

HTTP/HTTPS 프로토콜의 Listener를 생성한 경우 L7(Layer 7) Load Balancing을 위한 정책과 규칙을 설정할 수 있도록 지원합니다. L7 규칙은 참 또는 거짓으로 평가되는 간단한 논리 테스트이며, L7 정책은 L7 규칙의 모음입니다. 정책과 연결된 모든 규칙이 일치하는 경우 ‘액션’에 정의된 작업이 수행됩니다.

표 정책 추가

구분	설명
규칙	L7 정책 생성 시점에는 기본 규칙이 적용되며, L7 정책 생성 후 규칙 추가 가능 -기본 규칙은 모든 요청에 대해 L7 정책에 설정된 액션을 수행하는 규칙을 의미
우선순위	L7 정책의 우선순위로, 숫자가 낮을수록 높은 우선순위를 가짐
액션	L7 정책 액션 - Target Group으로 전달: 요청이 L7 정책과 연결된 Target Group으로 전달됨 - URL로 리디렉션: 요청이 정의된 URL로 HTTP 리디렉션으로 전송됨 ㄴ 리디렉션할 URL의 프로토콜(HTTP/HTTPS)을 선택 후, 프로토콜을 제외한 URL을 입력(예: www.example.com) ㄴ 리디렉션 상태 응답코드도 함께 지정 가능(예: 302- Found: 임시적인 URL 리다이렉션 시 사용)
Target Group	Target Group 선택

표 규칙 추가

구분	설명
규칙 타입	L7 규칙 타입 - Host name: 요청의 HTTP/1.1 호스트 이름과 규칙의 값과 비교(예: www.kakaoicloud.com) - Path: HTTP URI의 경로 부분을 규칙의 값과 비교 - Header: 키에 정의된 헤더를 찾아 규칙의 값과 비교 - File type: URI의 마지막 부분을 규칙의 값과 비교(예: “txt”, “jpg” 등) - Cookie: 규칙의 키에 정의된 대로 명명된 쿠키를 찾아 규칙의 값과 비교
비교 타입	비교 타입에 정의된 대로 비교를 수행하며, 모두 참인 경우 L7 정책의 액션 수행 - 키/값과 일치(Eqaul to): 키의 값 혹은 키가 없을 경우 값이 문자열과 일치 - 값을 포함(Contains): 문자열이 값을 포함함 - 값으로 시작(Starts with): 문자열이 값으로 시작 - 값으로 끝(Ends with): 문자열이 값으로 끝남
키	키 입력
값	값 입력

안내
- Application Load Balancer의 L7 규칙과 Deprecated Load Balancer의 L7 정책은 동일한 의미입니다.
- Application Load Balancer의 L7 조건과 Deprecated Load Balancer의 L7 규칙은 동일한 의미입니다.

SSL 인증서

표 인증서 관리

구분	설명
SSL 기본 인증서	HTTPS Listener 생성 시 처음 지정한 인증서로, 사용자가 SNI 프로토콜을 사용하지 않고 호스트 이름을 지정하여 연결한 경우 기본적으로 사용되는 인증서 - 기본 인증서는 Listener에서 해제 불가하며, 설정한 기본 인증서를 해제하려면 다른 인증서를 등록하여 교체
SSL 추가 인증서	Listener 생성 후 SSL 설정 메뉴에서 등록 - 추가 인증서는 Listener당 5개까지 등록 가능
SSL 인증서 등록 및 보관	Load Balancer 만들기 또는 Listener 만들기의 HTTPS Listener 생성 과정에서 인증서를 등록하거나, HTTPS 인증서 생성 후 SSL 설정하기를 통해 인증서 등록 가능 - PEM 형식의 인증서 프라이빗 키, 인증서 본문, 인증서 체인을 입력하면, 해당 정보들은 PKCS12 포맷으로 변환하여 별도의 암호화 스토리지에 보관됨
SSL 인증서 해제	SSL 설정하기를 통해 Listener에 설정된 인증서를 해제 - 기본 인증서는 해제할 수 없으며 HTTPS Listener는 최소 1개 이상의 인증서 지정 필요
SSL 인증서 삭제	Load Balancer 만들기, Listener 만들기의 HTTPS Listener 생성 화면에서 SSL인증서 삭제 링크를 통해 삭제할 수 있으며, SSL 설정 하기 화면에서 삭제 링크를 통해 인증서 삭제 가능

사용 가이드

안내
카카오 i 클라우드의 Load Balancing 서비스에 대한 자세한 사용 가이드는 아래를 를 참고하시기 바랍니다.

표 Load Balancing 사용 가이드

문서	설명
Application Load Balancer	Application Load Balancer를 설정하는 방법을 설명합니다.
Network Load Balancer	Network Load Balancer를 설정하는 방법을 설명합니다.
Deprecated Load Balancer	2023년 5월 31일 이전에 생성된 Load Balancer입니다. 5월 31일부터 생성이 제한됩니다. Deprecated Load Balancer를 설정하는 방법을 설명합니다.