보조 사이트용 Geo프록시

Tier: Premium, Ultimate Offering: Self-Managed

다음과 같은 목적으로 Geo 프록시를 사용합니다:

  • 보조 사이트가 주 사이트로 프록시하여 읽기-쓰기 트래픽을 제공합니다.
  • 읽기 전용 작업이 로컬 사이트로 직접 전달되어 복제된 데이터 유형을 비 선택적으로 가속화합니다.

활성화되면 보조 사이트의 사용자는 주 사이트의 UI에 액세스하는 것과 같은 방식으로 WebUI를 사용할 수 있습니다. 이는 보조 사이트의 전반적인 사용자 경험을 크게 향상시킵니다.

보조 프록시를 사용하면 보조 Geo 사이트로의 웹 요청은 직접적으로 주 사이트로 프록시되며 읽기-쓰기 사이트로 작동하는 것처럼 보입니다.

프록시는 gitlab-workhorse 컴포넌트에 의해 수행됩니다. 보통 Geo 보조 사이트의 Rails 애플리케이션에 보내는 트래픽은 대신 주 Geo 사이트의 내부 URL로 프록시됩니다.

주요 판매 요약 지원 사례:

  • 모든 Geo 사이트를 단일 URL 뒤에 배치하는 경우
  • 쓰기 액세스에 대해 걱정하지 않고 지리적으로 트래픽을 로드 밸런싱하는 경우
note
보조 사이트용 Geo 프록시는 Git push 작업용 Geo 프록시/리디렉팅과 별도입니다.

개요는 다음을 참조하세요: 지리적 로드 밸런서 및 AWS Route53를 사용한 보조 프록시.

Geo 사이트용 단일 URL 설정

보조 사이트는 투명하게 읽기-쓰기 트래픽을 제공할 수 있습니다. 요청은 주 Geo 사이트 또는 Geo 프록시를 사용하는 보조 Geo 사이트 중 하나에 도달할 수 있는 단일 외부 URL을 사용할 수 있습니다.

트래픽을 두 사이트로 전송하는 외부 URL 구성

Location-aware public URL 단계를 따라서 주 Geo 사이트를 포함한 모든 Geo 사이트에서 사용하는 단일 URL을 만듭니다.

모든 Geo 사이트가 동일한 외부 URL을 사용하도록 Geo 사이트 업데이트

  1. Geo 사이트에서 각각의 노드(Rails를 실행하는 노드)에 SSH **로 로그인하여 external_url을 해당 단일 URL로 변경합니다: 

    sudo editor /etc/gitlab/gitlab.rb

  2. URL이 이미 설정된 것과 다른 경우 업데이트된 노드를 다시 구성하여 변경 내용이 적용되도록합니다: 

    gitlab-ctl reconfigure

  3. 보조 Geo 사이트에 설정된 새로운 외부 URL과 일치하도록 주요 데이터베이스를 반영해야 합니다.

    주 사이트의 Geo 관리 페이지에서 보조 프록시를 사용하는 각 Geo 보조 사이트를 편집하여 URL 필드를 단일 URL로 설정합니다. 또한 주 사이트도 이 URL을 사용하고 있는지 확인합니다.

Kubernetes에서 주 사이트와 동일한 도메인을 사용할 수 있습니다(global.hosts.domain).

제한 사항

  • 보조 프록시가 사용될 때 비동기 Geo 복제는 가속화된 데이터 유형에 대해 예기치 않은 문제를 일으킬 수 있습니다. 예를 들어, 복제 지연이 읽기-쓰기 일관성을 손상할 수 있다고 발견되었습니다. 복제 지연이 충분히 높으면 이로 인해 보조에서의 Git 읽기가 오래된 데이터를 수신하여 스테일 데이터를 받을 수 있습니다.

  • Rails 요청이 프록시되지 않으므로 기타 서비스에는 항상 기별된 URL을 사용해야 할 수 있습니다. 이러한 서비스에는 다음이 포함됩니다:

  • 통합된 URL을 사용하는 경우 동일한 도메인을 통해 2 개의 IP에 모두 도달할 수 있을 때만 Let’s Encrypt가 인증서를 생성할 수 있습니다. Let’s Encrypt를 사용하여 TLS 인증서를 사용하려면 매뉴얼으로 도메인을 Geo 사이트 중 하나로 지시하여 인증서를 생성하고 다른 모든 사이트로 복사해야합니다.

  • 보조 Geo 사이트를 사용하여 러너를 가속화하는 것은 실험적이며 제품용으로 권장되지 않습니다. 보조 프록시 러너의 단계를 따라 구성 및 테스트할 수 있습니다. 일반적으로 사용 가능한 상태를 확인하려면 epic 9779에서 진행 상황을 추적할 수 있습니다.

  • 보조 프록시가 별도 URL과 함께 사용될 때, SAML을 사용하여 보조 사이트로 로그인하는 경우에는 SAML ID 공급자(IdP)가 여러 콜백 URL로 구성되는 것만 지원됩니다.

주 Geo 사이트가 다운된 경우 보조 사이트의 동작

주 Geo 사이트가 액세스할 수 없는 경우 보조 사이트의 동작은 다음과 같습니다:

  • UI 및 API 트래픽은 프록시되므로 주 사이트와 동일한 오류를 반환합니다 (또는 주 사이트에 액세스할 수 없는 경우 실패함) 그렇기 때문에 프록시됩니다.
  • 특정 보조 사이트에 이미 존재하는 리포지터리의 경우, Git 읽기 작업은 여전히 예상대로 작동합니다. HTTP(s) 또는 SSH를 통한 인증을 포함하여
  • 보조 사이트에서 복제되지 않은 리포지터리에 대한 Git 작업은 주 사이트와 동일한 오류를 반환합니다. 그렇기 때문에 프록시됩니다.
  • 모든 Git 쓰기 작업은 주 사이트와 동일한 오류를 반환합니다. 그렇기 때문에 프록시됩니다.

보조 Geo 사이트에서 가속화되는 기능

보조 Geo 사이트로 보낸 대부분의 HTTP 트래픽은 주 Geo 사이트로 프록시될 수 있습니다. 이 구조를 통해 보조 Geo 사이트는 쓰기 요청을 지원할 수 있습니다. 특정 읽기 요청은 근처의 지리적 위치를 통해 대역폭과 대기 시간을 개선하기 위해 보조 사이트에서 로컬로 처리됩니다. 모든 쓰기 요청은 주 사이트로 프록시됩니다.

다음 표는 현재 Geo 보조 사이트 작업 프록시를 통해 테스트 된 컴포넌트를 자세히 설명하고 있습니다. 모든 데이터 유형을 다루지는 않습니다.

이 맥락에서 가속화된 읽기는 보조 사이트에서 제공되는 읽기 요청을 나타냅니다. 해당 데이터가 보조 사이트의 컴포넌트에 대해 최신 상태인지 확인된 경우에 해당합니다. 보조 사이트의 데이터가 오래되었다고 판단되면 요청이 주 사이트로 전달됩니다. 아래 표에 나열되지 않은 컴포넌트에 대한 읽기 요청은 항상 자동으로 주 사이트로 전달됩니다.

기능 / 컴포넌트 가속화된 읽기? 비고
프로젝트, 위키, 디자인 리포지터리(웹 UI 사용) 아니요  
프로젝트, 위키 리포지터리(Git 사용) 네 Git 읽기는 로컬 보조 사이트에서 처리되지만 푸시는 주 사이트로 프록시됩니다. 선택적 동기화 또는 로컬로 존재하지 않는 리포지터리의 경우 “찾을 수 없음” 오류가 발생합니다.
프로젝트, 개인 스니펫(웹 UI 사용) 아니요  
프로젝트, 개인 스니펫(Git 사용) 네 Git 읽기는 로컬 보조 사이트에서 처리되지만 푸시는 주 사이트로 프록시됩니다. 선택적 동기화 또는 로컬로 존재하지 않는 리포지터리의 경우 “찾을 수 없음” 오류가 발생합니다.
그룹 위키 리포지터리(Git 사용) 아니요  
그룹 위키 리포지터리(Git 사용) 네 Git 읽기는 로컬 보조 사이트에서 처리되지만 푸시는 주 사이트로 프록시됩니다. 선택적 동기화 또는 로컬로 존재하지 않는 리포지터리의 경우 “찾을 수 없음” 오류가 발생합니다.
사용자 업로드(Git 사용) 아니요  
LFS 객체(웹 UI 사용) 아니요  
LFS 객체 (Git 사용) 네  
Pages 아니요 페이지는 동일한 URL을 사용할 수 있지만 별도로 구성되어야하며 프록시되지 않습니다.
고급 검색(웹 UI 사용) 아니요  
컨테이너 레지스트리 아니요 컨테이너 레지스트리는 재해 복구 시나리오에만 권장됩니다. 보조 사이트의 컨테이너 레지스트리가 최신 상태가 아닌 경우 읽기 요청은 오래된 데이터로 제공되므로 요청이 주 사이트로 전달되지 않습니다. 컨테이너 레지스트리 가속화가 계획되어 있습니다. issue에서 관심을 나타내거나 GitLab 대표에게 요청하여 표시하십시오.
의존성 프록시 아니요 Geo 보조 사이트의 의존성 프록시로의 읽기 요청은 항상 주 사이트로 프록시됩니다.

Geo 프록시 비활성화

기본적으로 Geo 보조 사이트는 주 사이트와 동일한 external_url을 사용할 때 보조 프록시가 기본으로 활성화됩니다. 이는 라우팅에 따라 동일한 URL에서 완전히 다른 동작이 제공되므로 이 경우에 프록시를 비활성화하는 것은 도움이 되지 않을 수 있습니다.

GitLab 15.1에서는 보조 사이트에서 통합된 URL을 사용하지 않더라도 보조 프록시가 기본적으로 활성화됩니다. 보조 사이트에서 프록시를 비활성화해야 하는 경우에는 분리된 URL로 Geo 프록시 사용의 피처 플래그를 비활성화하는 것이 훨씬 쉽습니다. 그러나 여러 개의 보조 사이트가 있는 경우에는 이 섹션의 지침을 사용하여 사이트별로 보조 프록시를 비활성화할 수 있습니다.

또한 gitlab-workhorse 서비스는 10초마다 /api/v4/geo/proxy를 폴링합니다. GitLab 15.2 이상에서는 Geo가 비활성화되지 않은 경우에는 한 번만 폴링됩니다. GitLab 15.2 이전에는 보조 프록시를 비활성화하여 이 폴링을 중지할 수 있습니다.

동일한 Geo 사이트의 각각의 보조 프록시를 개별적으로 비활성화하려면 Linux 패키지 설치에서 다음 단계를 따릅니다:

  1. 보조 Geo 사이트의 각 애플리케이션 노드(사용자 트래픽을 직접 제공)에 SSH로 연결하고 다음 환경 변수를 추가합니다: 

    sudo editor /etc/gitlab/gitlab.rb

    gitlab_workhorse['env'] = {
  "GEO_SECONDARY_PROXY" => "0"
}

  2. 변경 내용을 적용하려면 업데이트된 노드를 다시 구성합니다: 

    gitlab-ctl reconfigure

Kubernetes에서는 --set gitlab.webservice.extraEnv.GEO_SECONDARY_PROXY="0"를 사용하거나 값 파일에서 다음을 지정할 수 있습니다: 

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

분리된 URL로 Geo 프록시 사용

note
이 섹션에서 설명하는 피처 플래그는 향후 릴리스에서 폐기되고 제거될 예정입니다. 읽기 전용 Geo 보조 사이트 지원이 issue 366810에서 제안되었습니다. 해당 issue에서 사용 사례를 공유하고 표시할 수 있습니다.

분리된 URL로 Geo 프록시는 GitLab 15.1부터 기본으로 활성화되어 있습니다. 이를 통해 URL이 다르더라도 보조 사이트가 주 사이트로 작업을 프록시할 수 있습니다.

문제가 발생하는 경우 geo_secondary_proxy_separate_urls 피처 플래그를 비활성화하여 해당 기능을 비활성화할 수 있습니다.

  1. 기본 Geo 사이트에서 Rails를 실행하는 하나의 노드에 SSH로 연결하고 다음을 실행합니다: 

    sudo gitlab-rails runner "Feature.disable(:geo_secondary_proxy_separate_urls)"

  2. 보조 Geo 사이트에서 Rails를 실행하는 모든 노드에서 Puma를 다시 시작합니다: 

    sudo gitlab-ctl restart puma

Kubernetes에서는 툴박스 파드에서 동일한 명령을 실행할 수 있습니다. 자세한 내용은 Kubernetes Cheat Sheet를 참조하십시오.