Network > Load Balancer > 개요

NHN Cloud는 로드 밸런서를 제공합니다. 로드 밸런서를 이용하면,

  • 인스턴스 하나로 처리하기 힘든 부하를 여러 대의 인스턴스로 분산하여 처리량을 늘릴 수 있습니다.
  • 장애가 발생했거나 점검 중인 인스턴스를 자동으로 서비스에서 제외시켜 가용성을 높일 수 있습니다.

로드 밸런싱 방식

로드 밸런서는 총 세 가지 로드 밸런싱 방식을 지원합니다.

  • Round Robin (순차 선택): 트래픽을 전달할 인스턴스를 순차적으로 선택하는 가장 기본적이고 대중적인 로드 밸런싱 방식입니다. 모든 멤버 인스턴스들이 같은 요청에 대해서 동일한 응답을 하는 경우에 사용할 수 있는 방식입니다.

  • Least Connections (최소 연결 우선 선택): 현재 TCP 연결 수가 가장 작은 인스턴스를 선택하는 방식입니다. 즉, TCP 연결 수를 기준으로 하여 인스턴스들의 부하 상태를 파악하고 멤버 중 가장 부하가 적은 인스턴스로 보내 가능한 균등하게 요청이 처리될 수 있도록 합니다. 요청에 따른 처리 부하가 변동이 심할 때 적용한다면, 특정 인스턴스에 부하가 집중되는 상황을 방지할 수 있습니다.

  • Source IP (원본 IP 기준 선택): 요청자의 원본 IP를 해싱하여 처리할 인스턴스를 선택하는 방식 입니다. 이 방식을 사용하는 경우, 동일한 IP에서 들어오는 요청은 항상 같은 인스턴스로 전달됩니다. 한 사용자의 요청을 매번 동일한 인스턴스에서 처리하고자 할 때 사용하면 유용합니다.

지원 프로토콜

로드 밸런서는 아래와 같은 프로토콜을 지원합니다.

  • TCP
  • HTTP
  • HTTPS
  • TERMINATED_HTTPS

위의 프로토콜 중 TERMINATED_HTTPS 프로토콜은 HTTPS 트래픽을 수신하여 멤버 인스턴스에게는 HTTP 트래픽으로 전달하는 방식입니다. TERMINATED_HTTPS 프로토콜을 사용하는 경우 최종 사용자와 로드 밸런서 사이에서는 HTTPS로 통신함으로써 높은 보안성을 확보하고, 서버에게는 HTTP 트래픽을 넘겨줌으로써 복호화에 드는 CPU 부하를 줄일 수 있습니다.

[참고] TERMINATED_HTTPS 프로토콜을 사용하기 위해서는 인증서와 개인 키를 로드 밸런서에 등록해야 합니다. 이 때 등록하는 개인 키는 반드시 비밀번호가 제거되어야 올바르게 동작합니다.

로드 밸런서 SSL/TLS 버전

  • TERMINATED_HTTPS 프로토콜을 사용하는 로드 밸런서를 생성할 때 클라이언트와 로드 밸런서 간 통신에 사용하는 SSL/TLS(Secure Socket Layer/Transport Layer Security) 버전을 선택할 수 있습니다.
  • SSL/TLS 프로토콜 버전이 낮으면 보안 결함이 있을 수 있고 암호화 스위트(Cipher Suite)를 구성하는 암호 알고리즘의 보안성도 낮기 때문에, 클라이언트가 지원하는 SSL/TLS 버전 중 가장 높은 버전을 선택하는 것이 좋습니다.

SSL/TLS 버전

SSL/TLS 버전 중 하나를 선택해 로드 밸런서를 생성합니다. 생성된 로드 밸런서는 아래와 같이 선택한 버전과 선택한 버전의 상위 버전만 사용하여 클라이언트와 통신합니다.

SSL/TLS 버전 설정 로드 밸런서가 사용하는 SSL/TLS 버전
SSLv3 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
TLSv1.0 TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
TLSv1.0_2016 TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
TLSv1.1 TLSv1.1, TLSv1.2, TLSv1.3
TLSv1.2 TLSv1.2, TLSv1.3
TLSv1.3 TLSv1.3

SSL/TLS 버전별 암호화 스위트

  • 클라이언트와 로드 밸런서 간 키 교환, 인증서 검증, 메시지 암호화, 메시지 무결성 검사 등 HTTPS 통신을 위해 사용되는 암호 알고리즘의 묶음을 암호화 스위트라고 합니다.
  • SSL/TLS 버전에 따라 사용되는 암호화 스위트는 아래와 같습니다.
  • 높은 버전의 TLS 버전을 선택하면 보안성이 낮은 알고리즘을 사용하는 암호화 스위트가 사용되지 않습니다.
SSL/TLS 버전 설정 사용되는 암호화 스위트 비고
SSLv3 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA
RC4-MD5
TLSv1.0 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA
RC4-MD5 제외
TLSv1.0_2016 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA 제외
TLSv1.1 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
AES256-SHA
AES128-SHA
상동
TLSv1.2 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
AES256-SHA
AES128-SHA 제외
TLSv1.3 TLS-AES-128-GCM-SHA256
TLS-AES-256-GCM-SHA384
TLS-CHACHA20-POLY1305-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-SHA256 제외

로드 밸런서 생성

로드 밸런서는 VPC서브넷에 생성됩니다. 로드 밸런서는 생성 시 지정된 서브넷으로부터 IP를 할당받아 자신의 IP로 사용합니다. 지정된 서브넷과 같은 VPC에 속한 인스턴스를 멤버로 등록해 유입된 트래픽을 분배합니다. 해당 VPC 및 이 VPC의 피어링 연결 VPC에 속한 인스턴스도 멤버로 추가할 수 있습니다. 이외 인스턴스는 멤버로 추가할 수 없습니다.

로드 밸런서로 유입되어 처리될 트래픽은 리스너에서 정의합니다. 리스너 별로 트래픽을 수신할 포트와 프로토콜을 정의하여, 하나의 로드 밸런서로 다양한 트래픽을 처리하도록 구성할 수 있습니다. 일반적으로 웹 서버에는 HTTP 트래픽을 수신할 80 포트 리스너와 HTTPS 트래픽을 수신할 443 포트 리스너를 설정하여 사용합니다. 하나의 로드 밸런서에 여러개의 리스너를 등록할 수 있습니다.

[주의] 로드 밸런서에서 동일한 수신 포트를 가지는 리스너를 중복해서 생성할 수 없습니다.

로드 밸런서 프록시 모드

로드 밸런서는 프록시 모드로 동작합니다. 따라서 클라이언트는 요청을 보내기 위해 로드 밸런서와 연결을 맺고, 로드 밸런서는 인스턴스 서버와 연결을 맺습니다. 멤버 인스턴스 서버 입장에서는 세션의 원본(Source) IP가 로드 밸런서의 IP로 보이게 됩니다. 서버에서 클라이언트의 IP를 확인하려면 로드 밸런서가 추가한 X-Forwarded-For 헤더의 정보를 참고하거나(HTTP/TERMINATED_HTTPS 프로토콜) Proxy Protocol을 사용하여야 합니다(TCP/HTTPS 프로토콜).

[참고] 프록시 모드
로드 밸런서가 프록시 모드로 동작하는 경우 클라이언트가 요청하는 포트와 서버측에서 서비스 하는 포트를 다르게 서비스할 수 있습니다. 또, TERMINATED_HTTPS와 같이 서버 부하를 덜어주는 기능도 제공할 수 있으며, 클라이언트에게 전송되는 트래픽량도 통계 형태로 제공할 수 있게 됩니다. (통계 기능 추가 예정)


[참고] X-Forwarded-For 헤더
HTTP 비표준 헤더로서, 서버가 클라이언트의 IP를 확인하기 위해 사용합니다. 로드 밸런서을 통해 들어오는 HTTP 요청은 X-Forwarded-For 키를 포함합니다. 그 값은 클라이언트의 IP 입니다.

X-Forwarded-For 헤더는 로드 밸런서의 프로토콜을 HTTP/TERMINATED_HTTPS로 설정했을 때만 활성화됩니다.


[참고] 프록시 프로토콜 (Proxy Protocol)
로드 밸런서에서 TCP 사용시 클라이언트 측의 IP 정보를 전송하기 위한 프로토콜 입니다. 사람이 이해하기 쉽도록 US-ASCII 포맷의 텍스트 한 줄로 표현되어 있습니다. TCP 연결이 맺어지면 최초 한번 전송되고, 수신측에서 모두 수신하기 전까지 다른 데이터 전송은 지연됩니다.

프록시 프로토콜은 크게 6개의 항목으로 구분됩니다. 각각의 항목은 공백 문자로 구분됩니다. 마지막 문자는 반드시 Carrige Return (\r) + Line Feed (\n)로 끝나야 합니다. PROXY INET_PROTCOL CLIENT_IP PROXY_IP CLIENT_PORT PROXY_PORT\r\n

약어 ASCII HEX 설명
PROXY "PROXY" 0x50 0x52 0x4F 0x58 0x59 프록시 프로토콜임을 알려주기 위한 지시자
INET_PROTOCL "TCP4" 또는 "TCP6" 0x54 0x43 0x50 0x34 또는 0x54 0x43 0x50 0x36 사용 중인 INET 프로토콜 형식
CLIENT_IP 예) "192.168.100.101"
또는 "fe80::a159:b1f3:c346:5975"
0xC0 0xA8 0x64 0x65 출발지 주소 IP
PROXY_IP 예) "192.168.100.102"
또는 "fe80::a159:b1f3:c346:5976"
0xC0 0xA8 0x64 0x66 목적지 주소 IP
CLIENT_PORT 예) "43179" 0xA8 0xAB 출발지 포트
PROXY_PORT 예) "80" 0x80 목적지 포트

프록시 프로토콜의 예제는 다음과 같습니다.

  • "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n": TCP/IPv4
  • "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n": TCP/IPv6
  • "PROXY UNKNOWN\r\n": 알 수 없는 연결

TCP 또는 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 프록시 프로토콜을 설정하여 클라이언트의 IP를 확인할 수 있습니다. 이 경우 서버에서도 위와 같은 프록시 프로토콜을 인식하는 기능을 가지고 있어야 합니다.

세션 연결 제한

로드 밸런서는 QoS 보장을 위해 리스너별로 동시에 유지 가능한 연결 수를 제한하고 있습니다. 만약 지정된 연결 제한 값을 초과하는 요청이 들어오면, 로드 밸런서 내부의 큐에 누적되어 앞선 요청들이 완료된 후에 처리됩니다. 또한 큐가 가득 차거나 서버/클라이언트 측의 타임아웃에 걸려 요청이 강제 중단될 수 있습니다. 이 경우 클라이언트 측은 예상하지 못한 응답 지연을 겪을 수 있습니다.

[참고] 일반 로드 밸런서의 세션 연결 제한 수치의 최대값은 60,000 개, 전용 로드 밸런서의 경우 480,000 개, 물리 Basic 로드밸런서의 경우 1,000,000 개, 물리 Premium 로드밸런서의 경우 3,000,000 개입니다.

세션 지속성

사용자 정보를 유지할 필요가 있거나 한 클라이언트의 요청이 특정 서버에게만 전달되어야 하는 서비스를 위해 로드 밸런서의 세션 지속성 기능을 이용할 수 있습니다. 클라이언트의 요청을 처리한 서버가 계속 그 클라이언트의 요청을 처리하게 하는 설정입니다. 로드 밸런싱 방식을 SOURCE IP로 선택한 경우 클라이언트의 IP를 기반으로 서버를 결정하기 때문에 세션 지속성이 제공됩니다. 로드 밸런싱 방식을 ROUND ROBIN이나 LEAST CONNECTION을 사용하는 경우 다음과 같은 세션 지속성 기능을 사용할 수 있습니다.

  • No Session Persistence (세션 유지 안함): 세션 유지를 하지 않는 방식입니다.

  • Source IP (원본 IP에 의한 세션 관리): 요청자의 원본 IP를 기준으로 세션을 유지하는 방식입니다. 이를 위해 최초 요청시 로드 밸런싱 방식에 의해 선택된 인스턴스와 원본 IP 사이의 맵핑 테이블을 내부적으로 보관합니다. 이후 같은 원본 IP를 가진 요청이 들어오면 맵핑 테이블을 확인하여 첫 요청에 응답한 인스턴스로 전달하게 됩니다. 로드 밸런서는 최대 10000개의 원본 IP에 대한 맵핑을 저장할 수 있습니다. TCP 프로토콜 리스너에서 세션을 유지하도록 설정하고 싶다면, 이 방식을 사용해야 합니다.

  • APP Cookie (응용에 의한 세션 관리): 서버측에서 내려주는 명시적인 쿠키 설정을 통해 세션을 유지하는 방식입니다. 최초 요청시 서버는 자신에게 설정된 쿠키 값를 설정하도록 HTTP의 Set-Cookie 헤더를 통해 전달해야 합니다. 이 때, 로드 밸런서는 서버 응답 중 지정된 쿠키가 있는지 검사하여, 쿠키가 있다면 내부적으로 쿠키와 서버 ID간의 맵핑을 유지하게 됩니다. 이후 클라이언트가 Cookie 헤더에 특정 서버를 가리키는 쿠키를 넣어서 보내면 로드 밸런서가 쿠키에 대응하는 서버로 요청을 전달합니다. 로드 밸런서에서는 쿠키-서버 ID간의 맵핑이 3시간 동안 사용되지 않으면 자동으로 삭제됩니다.

  • HTTP Cookie (로드 밸런서에 의한 세션 관리): APP Cookie 방식과 유사하지만 로드 밸런서에서 자동적으로 설정해주는 쿠키를 통해 세션을 유지하는 방식입니다. 로드 밸런서는 서버의 응답에 SRV란 쿠키를 추가하여 전송하게 됩니다. 이 때 SRV 쿠키의 값은 서버별 고유 아이디입니다. 클라이언트가 SRV를 쿠키에 넣어서 보내면 처음에 응답한 서버로 요청이 전달됩니다.

[참고] 로드 밸런서에 TCP 세션 연결 유지시간을 설정할 수 있습니다. Keepalive timeout 값을 설정하여 클라이언트와 로드 밸런서, 로드 밸런서와 서버간 세션 유지 시간을 조정할 수 있습니다.

유효하지 않은 요청 차단

HTTP 요청 헤더에 유효하지 않은 문자가 포함된 경우 이를 차단하는 기능입니다. 서버의 취약점을 노린 해커의 공격이나, 버그가 있는 브라우저를 통해서 유효하지 않은 문자가 포함된 HTTP 요청 헤더가 유입될 수 있습니다. 기능이 활성화되면 로드 밸런서는 유효하지 않은 문자가 포함된 HTTP 요청을 차단해 인스턴스에 전달되는 것을 막으며, 400 응답 코드(bad request)를 클라이언트에 전송합니다.

인스턴스 상태 확인

NHN Cloud 로드 밸런서는 멤버로 등록된 인스턴스들이 정상적으로 동작하는지 확인하기 위해 주기적으로 상태 확인을 시도합니다. 상태 확인은 지정된 프로토콜에 따라 정해진 응답이 오는지를 확인함으로써 이뤄집니다. 만약 지정된 횟수나 시간 내에 정상 응답이 오지않는다면 비정상 인스턴스로 간주하여, 부하 분산의 대상에서 제외합니다. 이 기능을 통해 예기치 못한 장애나 점검에도 중단 없이 서비스를 제공할 수 있습니다.

로드 밸런서는 상태 확인 프로토콜로서 TCP, HTTP, HTTPS를 지원합니다. 정밀한 상태 확인을 위해 각각의 프로토콜 사용 시 상태 확인 방법을 다양하게 설정할 수 있습니다.

로드 밸런서 통계 기능

로드 밸런서가 처리한 네트워크 플로 관련 여러 가지 통계 지표들을 차트를 통해 확인할 수 있습니다. NHN Cloud 로드 밸런서 통계 기능의 특징은 다음과 같습니다.

  • 로드 밸런서별, 리스너별 통계 차트를 제공합니다.
  • 1시간, 24시간, 1주, 1달, 지정 기간 등으로 기간을 분류하여 볼 수 있습니다.
  • 로드 밸런서를 기준으로 클라이언트 통계량과 인스턴스 통계량이 서로 다른 차트로 제공됩니다.
  • 인스턴스 통계량은 멤버 인스턴스별로 구분하여 볼 수 있고, 취합한 결과만을 볼 수도 있습니다. (인스턴스별로 보기: ON/OFF)

제공되는 차트는 다음과 같습니다.

통계 지표명
(차트명)
구분 단위 설명
클라이언트 세션 개수 클라이언트 ea 로드 밸런서가 클라이언트와 연결 중인 세션수
클라이언트 세션 CPS 클라이언트 cps
(connections per second)
클라이언트와 1초 동안 새로 연결한 세션수
세션 CPS 인스턴스 cps
(connections per second)
인스턴스와 1초 동안 새로 연결한 세션수
트래픽 In 인스턴스 bps
(bits per second)
로드 밸런서가 인스턴스에 보낸 트래픽양
트래픽 Out 인스턴스 bps
(bits per second)
인스턴스가 로드 밸런서에게 보낸 트래픽양
로드 밸런싱 제외 개수 인스턴스 ea 상태 확인(health check) 실패로 인해 로드 밸런싱 대상에서 제외된 횟수

[참고] 제약 사항 및 참고 사항

  • 현재 사용 중인 로드 밸런서, 리스너, 멤버에 대해서만 통계 차트가 제공됩니다. 로드 밸런서 자원을 삭제하는 경우 해당 자원의 과거 통계 데이터는 제공되지 않습니다.
  • 단위가 ea인 차트에서 설정한 기간에 따라 수치의 의미가 달라질 수 있습니다. 수치의 의미는 개별 차트 상단 물음표에 마우스를 올리면 확인할 수 있습니다.
  • 트래픽 In, 트래픽 Out 등 네트워크 사용량과 관련된 지표에서 차트에 표현되는 수치는 L2, L3, L4 헤더의 크기가 제외된 페이로드 전송 크기를 단위 시간으로 나눈 데이터입니다. 따라서 차트에 표현되는 수치는 과금 데이터와 무관합니다.
  • 통계 데이터는 최대 1년 동안 제공됩니다.

로드 밸런서 IP 접근제어 기능

로드 밸런서로 유입되는 패킷을 제어하려면 IP 접근제어 기능을 이용할 수 있습니다. 이 기능은 보안 그룹과 구분되는 기능으로써 차이점은 다음과 같습니다.

[참고] 보안 그룹과 로드 밸런서 IP 접근제어 기능 비교

구분 보안 그룹 로드 밸런서 IP 접근제어 비고
제어 대상 인스턴스 로드 밸런서
설정 대상 IP, 포트 설정 IP 만 설정 로드 밸런서에 설정된 포트 이외의 트래픽은 기본적으로 차단
제어 트래픽 유입/유출 트래픽
선택 가능
유입 트래픽만 제어 대상
접근 제어 타입 허용 정책만 설정 허용 또는 차단 정책 선택 가능

보안 그룹 설정과 로드 밸런서 IP 접근제어 설정은 서로 영향을 미치지 않습니다. 따라서, 인스턴스로 유입 및 유출되는 트래픽을 제어하려면 보안 그룹을 사용하고, 로드 밸런서에 유입되는 트래픽을 제어하려면 IP 접근제어 기능을 사용해야 합니다.

IP 접근제어 기능을 이용하려면 다음 사항을 설정해야 합니다.

IP 접근제어 그룹

  • 한 프로젝트에 최대 10개의 그룹을 생성할 수 있습니다.
  • 그룹 속성은 이름, 메모, 접근제어타입입니다.
  • 접근제어 타입 속성은 '허용(Allow)'와 '차단(Deny)' 중 하나를 설정할 수 있습니다.
  • 접근제어 그룹에 제어를 원하는 IP 접근제어 대상을 추가할 수 있습니다.
  • IP 접근제어 그룹을 삭제하면 그룹 내의 모든 IP 접근제어 대상이 삭제되고, 이 접근제어 그룹이 적용되었던 모든 로드 밸런서에서 그 IP를 제어하지 않습니다.

IP 접근제어 타입

  • '허용(Allow)': 그룹에 속한 IP 의 접근은 허용하고, 그 외의 모든 IP의 접근을 차단합니다.
  • '차단(Deny)': 그룹에 속한 IP 의 접근은 차단하고, 그 외의 모든 IP의 접근을 허용합니다.

    [주의] '허용' 타입의 접근제어 그룹을 로드 밸런서에 적용하려면 로드 밸런서의 멤버 인스턴스 IP를 접근제어 대상에 추가해야 합니다.

IP 접근제어 대상

  • 한 프로젝트에 최대 1,000개의 접근제어 대상을 생성할 수 있습니다.
  • 접근제어 대상은 메모, IP 주소 등의 속성을 갖습니다.
  • 하나의 접근제어 대상은 IP 주소 또는 CIDR 형식의 IP 주소 범위를 가질 수 있습니다. CIDR 형식의 IP 주소 범위를 입력하면 해당 네트워크 내의 모든 대역이 접근제어 대상에 포함됩니다.

[참고] NHN Cloud Security Monitoring 서비스를 이용하면 위협이 되는 원격지 IP를 알아낼 수 있습니다.

IP 접근제어 타입을 '차단'으로 설정한 IP 접근제어 그룹을 생성하고, 발견된 위협 원격지 IP를 접근제어 대상에 추가하면 시스템의 보안성을 높일 수 있습니다.

IP 접근제어 그룹 적용

  • 한 접근제어 그룹은 여러 로드 밸런서에 적용할 수 있습니다.
  • 한 로드 밸런서에 여러 접근제어 그룹을 적용할 수 있습니다. 단, 바인딩되는 그룹들의 접근제어타입이 동일해야 합니다.
  • IP 접근제어 그룹을 적용하지 않은 로드 밸런서는 모든 IP의 접근을 허용합니다.

[참고]

  • 로드 밸런서와 IP 접근제어 변경 시 동작
    • 로드 밸런서를 삭제하면 접근제어 바인딩이 삭제됩니다. 접근제어 그룹은 삭제되지 않습니다.
    • 접근제어 그룹을 삭제하면, 해당 내역이 그룹과 바인딩된 모든 로드 밸런서에 반영됩니다.
    • 접근제어 그룹 내의 접근제어 대상을 추가하거나 삭제하면, 그룹과 바인딩된 모든 로드 밸런서에 해당 내역이 반영됩니다.

과금

로드 밸런서 과금 정책은 크게 두 가지로 나눌 수 있습니다.

  • 로드 밸런서 사용 요금: ACTIVE 상태인 로드 밸런서가 사용된 기간만큼 요금이 청구됩니다. 이용 요금에 대한 자세한 사항은 로드 밸런서 타입별 요금을 참고하시기 바랍니다.
  • 로드 밸런서 트래픽 요금: 로드 밸런서에서 나가는 트래픽 볼륨만큼 프로젝트 전체 트래픽에 더해져 함께 청구됩니다.
TOP