☰

구성

tag-icon • tag-icon google-cloud-platform load-balancing google-compute-engine google gcp
구성

나는지역 인스턴스 그룹포트 8000에서 2개의 인스턴스가 제공되고 자동 확장이 활성화되지 않습니다.

이 인스턴스 그룹은글로벌 외부 애플리케이션 로드 밸런서.

인스턴스의 웹 서버는 Flask를 실행 중이며 각 요청을 처리하는 데 1초가 걸립니다.

@app.route("/", methods=["GET"])
def main() -> Response:
    sleep(1)
    response = jsonify(
        success=True,
        hostname=gethostname(),
    )
    response.status_code = 200
    response.headers["Access-Control-Allow-Origin"] = "*"
    return response

전역 로드 밸런서 공용 IP를 눌러 동작을 확인할 수 있습니다. 즉, 응답을 받는 데 1초가 걸립니다.

인스턴스가 2개이므로 동시에 2개의 요청을 실행하는 경우 각 요청은 항상 동일한 인스턴스로 이동하여 대기열에 대기하는 대신 다른 인스턴스로 이동하게 될 것으로 예상됩니다.

  • 요청 하나에 1초가 소요됩니다.
  • 다른 요청에는 2초가 소요됩니다.

나는 , 및 Locality load balancing policy를 변경하려고 시도했지만 항상 동일한 동작을 얻습니다.Round-RobinLeast-RequestRandom

Locality load balancing policy어떤 백엔드가 선택될 것인지에 대해서만 올바르게 이해하고 있습니까 ? 그렇다면 백엔드(예: 인스턴스 그룹) 내부에서 로드 밸런싱 정책을 어떻게 구성합니까?

감사해요

구성

인스턴스 그룹

  • 지역
  • 목표 분포 형태: 짝수
  • [x] 인스턴스 재배포 허용
  • 자동 확장 사용: 최소 2, 최대 2
  • 자동 확장 신호: HTTP 부하 분산 100%
  • 초기화 기간: 60초
  • 건강 체크:
    • 경로: /건강
    • 프로토콜: HTTP
    • 포트: 8000
    • 간격: 30초
    • 시간 초과: 30초
    • 정상 기준: 1
    • 비정상 임계값: 10

로드 밸런서

  • 프런트엔드:
    • 프로토콜: HTTP
    • IP: xxxx
    • 네트워크 등급: 프리미엄
    • HTTP 연결 유지 시간 초과: 610초
  • 라우팅 규칙: 모두 일치하지 않음
  • 백엔드 서비스:
    • 엔드포인트 프로토콜: HTTP
    • 명명된 포트: web
    • 시간 초과: 300초
    • Cloud CDN: 사용 중지됨
    • 로깅: 활성화됨(샘플링 속도: 1)
    • 세션 선호도: 없음
    • 연결 드레이닝 시간 초과: 300초
    • 교통 정책:
      • 지역 부하 분산 정책: 라운드 로빈
      • 이상치 감지: 비활성화됨
    • 백엔드 보안 정책: 없음
    • 엣지 보안 정책: 없음
    • 신원 인식 프록시: 비활성화됨
  • 균형 모드: 최대. RPS: 1(인스턴스당)
  • 용량: 100%

시험

siege \
    --concurrent 1 \
    --time 60s \
    "http://x.x.x.x"

노드가 2개인 경우:

  • concurrent=1: 평균 1.02초
  • concurrent=2: 평균 1.66초
  • concurrent=4: 평균 3.35초
  • concurrent=8: 평균 5.54초

노드가 4개인 경우:

  • concurrent=1: 평균 1.02초
  • concurrent=2: 평균 1.18초
  • concurrent=4: 평균 2.70초
  • concurrent=8: 평균 3.83초
  • concurrent=16: 평균 7.26초

노드가 8개인 경우:

  • concurrent=2: 평균 1.20초
  • concurrent=4: 평균 1.85초
  • concurrent=16: 평균 4.40초
  • concurrent=64: 평균 14.06초
  • concurrent=128: 평균 19.04초

예상되는 동작

나는 다음과 같은 결과를 가정했을 것이다:

  • 노드 2개:
    • concurrent=1: 1 초
    • concurrent=2: 1 초
    • concurrent=4: ~2초
    • concurrent=8: ~4초
  • 노드 4개:
    • concurrent=1: 1 초
    • concurrent=2: 1 초
    • concurrent=4: 1 초
    • concurrent=8: ~2초
    • concurrent=16: ~4초

업데이트 1

a로 전환 Classic proxy network load balancer하고 100개의 요청을 보내는 경우:

  • 56 vm0으로 이동
  • 44 vm1로 이동

대신 HTTP LB의 경우:

  • 99 vm0으로 이동
  • 1 vm1로 이동

답변1

기반글로벌 외부 애플리케이션 로드 밸런서GFE(Google 프런트 엔드)는 요청을 수신할 수 있는 용량이 있는 백엔드 인스턴스를 추정합니다. 공유된 링크를 스캔하면 트래픽 분포에 대해 자세히 알아볼 수 있습니다.

라운드 로빈이 작동하지 않는다고 생각되면 다음을 사용하는 것이 좋습니다.밸런싱 모드여기서 개념 또는 구성은 트래픽을 균등하게 분배하는 것입니다.

나도 이걸 찾았어링크균형 모드를 사용하면 도움이 될 수 있는 stackoverflow의 질문입니다.

관련 정보