Cloud Load Balancing은 애플리케이션의 여러 인스턴스에 사용자 트래픽을 분산하는 메커니즘을 제공합니다. 이를 위해 애플리케이션 간에 로드를 분산하고 최종 사용자에게 최적의 애플리케이션 성능을 제공합니다. 이 페이지에서는 부하 분산기가 애플리케이션에 최적화되도록 하는 몇 가지 권장사항에 대해 설명합니다. 최적 성능을 보장하기 위해서는 애플리케이션의 트래픽 패턴을 벤치마킹하는 것이 좋습니다.
클라이언트와 가깝게 백엔드 배치
사용자 또는 클라이언트 애플리케이션이 워크로드에 가까울수록 그 사이의 네트워크 지연 시간이 낮아집니다. 따라서 사용자 트래픽이 Google 프런트엔드에 도달할 것으로 예상되는 위치와 가장 가까운 리전에 부하 분산기 백엔드를 만듭니다. 세계 여러 지역의 클라이언트에 대해 지연 시간을 최소화하기 위해서는 여러 리전에서 백엔드를 실행해야 하는 경우가 많습니다.
자세한 내용은 다음 항목을 참조하세요.
Cloud CDN을 사용하여 캐싱 사용 설정
Cloud CDN 및 캐싱을 기본 전역 외부 애플리케이션 부하 분산기 구성의 일부로 설정합니다. 자세한 내용은 Cloud CDN을 참조하세요.
Cloud CDN을 사용하도록 설정하면 응답이 캐시되기 전에 몇 분 정도 걸릴 수 있습니다. Cloud CDN은 캐시 가능한 콘텐츠가 있는 응답만 캐시합니다. URL에 대한 응답이 캐시되지 않는 경우, 해당 URL에 대해 반환되는 응답 헤더를 확인하고 백엔드의 캐시 가능성 구성 방법을 확인합니다. 자세한 내용은 Cloud CDN 문제 해결을 참조하세요.
전달 규칙 프로토콜 선택
전역 외부 애플리케이션 부하 분산기 및 기본 애플리케이션 부하 분산기의 경우 IETF QUIC를 기반으로 빌드된 인터넷 프로토콜인 HTTP/3을 사용하는 것이 좋습니다. HTTP/3은 모든 주요 브라우저,Android Cronet, iOS에서 기본적으로 사용 설정됩니다. 애플리케이션에 HTTP/3을 사용하려면 UDP 트래픽이 네트워크에서 차단 또는 비율 제한되었는지 그리고 HTTP/3이 이전에 전역 외부 애플리케이션 부하 분산기에서 사용 중지되지 않았는지 확인합니다. 이전 브라우저 또는 네트워킹 라이브러리와 같이 아직 HTTP/3을 지원하지 않는 클라이언트는 영향을 받지 않습니다. 자세한 내용은 HTTP/3 QUIC를 참조하세요.
리전 외부 애플리케이션 부하 분산기의 경우, HTTP/1.1, HTTPS, HTTP/2가 지원됩니다. HTTPS 및 HTTP/2 모두 TLS를 설정하려면 일부 초기 오버헤드가 필요합니다.
백엔드 서비스 프로토콜 선택
선택한 백엔드 프로토콜(HTTP, HTTPS, HTTP/2)은 애플리케이션 지연 시간 및 애플리케이션에 사용 가능한 네트워크 대역폭에 영향을 줍니다. 예를 들어 부하 분산기 및 백엔드 인스턴스 사이에 HTTP/2를 사용하려면 인스턴스에 대해 HTTP(S)보다 훨씬 많은 TCP 연결이 필요할 수 있습니다. HTTP(S)와의 연결 수를 줄이는 최적화 방법인 연결 풀링은 HTTP/2에서 사용할 수 없습니다. 따라서 백엔드 연결이 더 자주 수행되기 때문에 백엔드 지연 시간이 길어질 수 있습니다.
백엔드 서비스 프로토콜은 또한 트래픽이 전송 중 암호화되는 방법에 영향을 줍니다. 외부 HTTP(S) 부하 분산기의 경우 Google Cloud VPC 네트워크 내에 존재하는 백엔드로 이동하는 모든 트래픽이 자동으로 암호화됩니다. 이를 자동 네트워크 수준 암호화라고 합니다. 하지만 자동 네트워크 수준 암호화는 인스턴스 그룹 및 영역별 NEG 백엔드와의 통신에만 사용할 수 있습니다. 다른 모든 백엔드 유형의 경우, HTTPS 및 HTTP/2와 같은 보안 프로토콜 옵션을 사용하여 백엔드 서비스와 통신을 암호화하는 것이 좋습니다. 자세한 내용은 부하 분산기에서 백엔드로의 암호화를 참조하세요.
권장 연결 기간
네트워크 조건이 바뀌고 부하에 따라 백엔드 집합이 변경될 수 있습니다. 단일 서비스에 많은 트래픽을 발생시키는 애플리케이션의 경우 장기 실행 연결이 항상 최적의 설정은 아닙니다. 백엔드에 대해 단일 연결을 무제한으로 사용하는 대신 새 요청에 새 연결이 사용된 후 최대 연결 수명 시간(예: 10~20분 사이) 또는 최대 요청 수(예: 1000~2000개 요청 사이)를 선택하는 것이 좋습니다. 이를 사용하는 모든 활성 요청이 완료되면 이전 연결이 종료됩니다.
이렇게 해서 클라이언트 애플리케이션이 부하 분산기 프록시 및 클라이언트를 지원하는 데 필요한 네트워크 재최적화를 비롯하여 백엔드 집합의 변경사항 이점을 활용할 수 있습니다.
분산 모드 선택 기준
더 나은 성능을 위해 가장 응답성이 높은 백엔드를 기준으로 새 요청마다 백엔드 그룹을 선택할 수 있습니다. 이렇게 하려면 RATE 분산 모드를 사용하면 됩니다. 여기에서는 최근 요청 중 평균 지연 시간이 가장 낮은 백엔드 그룹 또는 HTTP/2와 HTTP/3의 경우 미결 요청 수가 가장 적은 백엔드 그룹이 선택됩니다.
UTILIZATION 분산 모드는 인스턴스 그룹 백엔드에만 적용되고 인스턴스 그룹의 VM 인스턴스 활용률에 따라 트래픽을 분산합니다.
세션 어피니티 구성
일부 경우에는 최소한 짧은 기간 동안 동일한 백엔드가 동일한 최종 사용자의 요청 또는 동일한 최종 사용자와 연관된 요청을 처리하는 것이 좋을 수 있습니다. 이는 백엔드 서비스에 구성된 설정인 세션 어피니티를 사용하여 구성할 수 있습니다. 세션 어피니티는 클라이언트에서 부하 분산기의 백엔드로의 새 연결 분산을 제어합니다. 세션 어피니티를 사용하여 동일한 백엔드가 동일한 사용자 계정 또는 동일한 문서와 관련된 것과 같이 동일한 리소스의 요청을 처리하도록 보장할 수 있습니다.
세션 어피니티는 백엔드별 기준이 아닌 전체 백엔드 서비스 리소스에 대해 지정됩니다. 하지만 URL 맵은 여러 백엔드 서비스를 가리킬 수 있습니다. 따라서 부하 분산기에 대해 세션 어피니티 유형을 하나만 사용할 필요가 없습니다. 애플리케이션에 따라 서로 다른 세션 어피니티 설정에 서로 다른 백엔드 서비스를 사용할 수 있습니다. 예를 들어 애플리케이션의 일부가 여러 사용자에게 정적 콘텐츠를 제공하는 경우에는 세션 어피니티의 이점을 활용하기 어렵습니다. 대신 캐시된 응답을 제공하도록 Cloud CDN 지원 백엔드 서비스를 사용해야 합니다.
자세한 내용은 세션 어피니티를 참조하세요.