최대 연결 수

max connections 구성을 사용하여 제공된 프론트 엔드 가상 포트의 최대 동시 연결 수를 제한하십시오. 값을 구성하지 않으면 시스템은 2000개의 동시 연결이라는 기본값을 사용합니다. 지정된 프론트 엔드 가상 포트 또는 모든 프론트 엔드 가상 포트의 시스템 전체에 대한 최대 동시 연결 수는 15000입니다.

세션 연결 유지

기본적으로, ALB는 수신된 요청을 구성된 로드 밸런싱 방법에 따라 백엔드 서버로 전달합니다. 세션 고정을 활성화하여 클라이언트가 세션 내내 동일한 백엔드 서버에 연결된 상태를 유지하도록 할 수 있습니다. 자세한 내용은 애플리케이션 로드 밸런서의 세션 지속성 업데이트를 참조하십시오.

HTTP 유지

HTTP keep alive 를 사용하면 HTTP 클라이언트와 서버가 단일 TCP 연결을 통해 여러 요청-응답 쌍을 교환할 수 있습니다. 이는 후속 요청의 지연 시간을 줄이고, 네트워크 오버헤드를 최소화하며, 전반적인 효율성을 향상시킵니다.

Application Load Balancer for VPC 는 소비자 및 백엔드 서버 모두에서 활성화된 경우 HTTP keep alive 를 지원합니다. 소비자가 지원할 경우 HTTP keep alive, ALB는 여러 요청을 위해 연결을 열어둡니다. ALB는 백엔드 서버와의 서버 측 애플리케이션 레이어( HTTP ) 연결을 재사용하여 연결 오버헤드를 최소화하려고 시도합니다.

HTTP keep alive 연결의 클라이언트 측과 백엔드 서버 측 모두에서 활성화되어야 합니다.

TCP 유지

TCP keep alive 는 전송 계층의 메커니즘( TCP )으로, 연결의 다른 쪽 끝이 여전히 연결 가능한지 확인하기 위해 주기적으로 작은 패킷(연결 유지 프로브라고 함)을 전송하여 유휴 연결을 오래 유지하는 데 도움이 됩니다.

Application Load Balancer for VPC 지원 TCP 계속 살아있음. 이 설정을 사용하면 로드 밸런서가 5초마다 TCP keep alive 패킷을 소비자 및 백엔드 서버에 모두 전송합니다. 연결이 지정된 시간(연결 유지 시간이라고 하며 기본값은 2시간) 동안 유휴 상태가 되면 TCP 스택에서 연결 유지 프로브를 보냅니다. 피어가 응답하면 연결이 유지됩니다. 여러 번의 탐색 후에도 응답이 없으면 연결이 끊어진 것으로 간주되어 종료됩니다.

TCP 는 호스트가 살아있음을 알리기 위해 피어에게 보내는 데이터가 없는 소켓 수준 패킷입니다. 따라서 네트워크 레벨이 아닌 네트워크 계층에서만 표시됩니다. 이 설정은 특정 비활성 기간 후에 연결을 삭제하는 정책이 있을 수 있는 중간 프록시 또는 방화벽을 통해 TCP의 연결이 끊어지지 않도록 방지하는 데 도움이 됩니다.

연결 제한시간

ALB에 사용되는 제한시간 값은 다음과 같습니다. 현재 다음 표의 클라이언트 측 및 서버 측 유휴 제한시간 값만 사용자 정의할 수 있습니다.

일반 클라이언트 IP 주소 유지(HTTP/HTTPS 전용)

Application Load Balancer for VPC는 역방향 프록시로 작동하여 클라이언트의 수신 트래픽을 종료시킵니다. 로드 밸런서는 자체 IP 주소를 사용하여 백엔드 서버 인스턴스에 대한 별도의 연결을 설정합니다. 백엔드 서버(프론트 엔드 HTTP 또는 HTTPS 연결에 대한)를 사용하는 HTTP 연결의 경우 로드 밸런서는 X-Forwarded-For HTTP 헤더 내에 기존의 클라이언트 IP 주소를 포함하여 이를 유지합니다. TCP 연결의 경우 기존의 클라이언트 IP 정보가 유지되지 않습니다.

일반 클라이언트 프로토콜 유지(HTTP/HTTPS 전용)

ALB는 X-Forwarded-Proto HTTP 헤더 내부에 포함하여 프론트 엔드 HTTP 및 HTTPS 연결을 위해 클라이언트가 사용하는 원래 프로토콜을 보존합니다. TCP 프로토콜이 사용되는 경우 ALB가 7계층 트래픽을 확인하지 않으므로, 이는 TCP 프로토콜에 적용되지 않습니다.

개인용 로드 밸런서 적용 사용

개인용 로드 밸런서 적용은 공용 로드 밸런서가 작성되지 않도록 합니다. 이렇게 하면 인터넷이 아닌 클라이언트 또는 사용자 네트워크 환경 내의 클라이언트만 로드 밸런서에 액세스할 수 있습니다. 사용 가능한 경우, 모든 ALB에서 유동 IP 작성을 방지하기 위해 계정을 제한합니다.

개인용 로드 밸런서 적용을 구현하려면 IBM 지원 센터 케이스를 열고 유동 IP 작성을 제한하기 위해 계정을 변경해야 할 필요성을 참조하십시오. IBM이 해당 변경을 처리한 후에는 더 이상 공용 로드 밸런서를 작성할 수 없습니다.

개인용 로드 밸런서 적용은 사용으로 설정된 경우 모든 지역에 적용됩니다.

HTTPS 리스너에 연결하는 클라이언트에 대한 HTTP/2 지원

Application Load Balancer for VPC 는 ALPN(애플리케이션 계층 프로토콜 협상)을 사용하여 HTTPS 리스너에 연결하는 클라이언트와 협상하며 HTTP 및 HTTPS 프로토콜을 모두 지원합니다.

백엔드 풀 경우 아직 HTTP/2 프로토콜이 지원되지 않습니다. 그러나 HTTP 및 HTTPS 프로토콜은 지원됩니다.

압축(HTTP/HTTPS 전용)

HTTP/HTTPS 압축을 사용하는 경우 gzip을 사용하여 사용자에게 전송되는 데이터를 압축할 수 있습니다.

전송된 데이터를 ALB로 압축하려면 요청 헤더에 Accept-Encoding: gzip이(가) 포함되어야 하며 해당 MIME 유형은 text/html, text/plain 또는 text/xml이어야 합니다.

프록시 프로토콜 사용

TCP, HTTP 및 HTTPS 리스너 및 백엔드 풀에 대해 프록시 프로토콜을 사용할 수 있습니다. 유스 케이스는 다음과 같습니다.

유스 케이스 1: 클라이언트가 로드 밸런서에 직접 연결됨

ALB가 클라이언트로부터 트래픽을 직접 수신하는 경우, 해당 리스너의 백엔드 풀에 대한 프록시 프로토콜을 사용하도록 설정하면 로드 밸런서가 해당 백엔드 풀로 전송되는 TCP 패킷에 프록시 프로토콜 헤더를 첨부하도록 구성합니다.

해당 풀의 모든 백엔드 멤버는 작업할 데이터 경로의 프록시 프로토콜을 지원해야 합니다. 이 설정을 활성화하면 프록시 프로토콜 헤더의 버전(버전 1 또는 버전 2)을 선택할 수 있습니다. 이 설정은 지정되지 않은 경우 기본적으로 비활성화됩니다. 이 설정을 사용하면 백엔드 서버는 로드 밸런서가 프록시 프로토콜 헤더에 설정하는 클라이언트 IP 및 포트 정보를 얻을 수 있습니다.

유스 케이스 2: 클라이언트는 프록시 또는 프록시 체인에 연결한 다음 프록시 프로토콜을 사용하여 로드 밸런서에 연결

Application Load Balancer for VPC가 프록시 프로토콜을 사용하는 프록시(또는 프록시 체인)에서 트래픽을 수신하는 경우 리스너는 프록시 프로토콜 헤더에 포함된 원본 클라이언트 정보를 구문 분석할 수 있도록 프록시 프로토콜을 활성화해야 합니다. 이 설정은 지정되지 않은 경우 기본적으로 비활성화됩니다. 로드 밸런서는 프록시 프로토콜 헤더의 버전을 감지하고 올바르게 구문 분석할 수 있으므로 트래픽을 ALB로 보내는 데 사용되는 프록시 프로토콜 버전을 지정할 필요가 없습니다.

프론트 엔드 리스너에 프록시 프로토콜을 사용하는 경우, 이 프론트 엔드 포트로 들어오는 모든 트래픽은 프록시 프로토콜 트래픽이 됩니다. 연결에 적절한 프록시 프로토콜 헤더가 포함되지 않은 경우 연결이 설정되지 않습니다. 이 클라이언트 정보를 백 엔드 서버 풀로 전달하려면 풀에 대해 프록시 프로토콜을 사용하도록 설정해야 합니다. 유스 케이스 1과 유사하게 백엔드 서버가 사용하도록 구성된 프록시 프로토콜 버전에 따라 버전 1 또는 버전 2를 선택해야 합니다. 이 정보를 처리할 수 없는 경우 이 클라이언트 정보를 백엔드 서버로 전달하지 않도록 선택할 수도 있으며 이 정보는 로드 밸런서 자체에서 삭제됩니다.