보조 사이트를 위한 Geo 프록시

Tier: Premium, Ultimate Offering: Self-managed

Geo 프록시 사용 방법:

  • 보조 사이트가 주 사이트로 프록시를 통해 읽기-쓰기 트래픽을 제공합니다.
  • 읽기 전용 작업을 로컬 사이트로 리다이렉트하여 복제된 데이터 타입을 선택적으로 가속화합니다.

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

보조 프록시를 사용하면 보조 Geo 사이트로의 웹 요청이 직접 주 사이트로 프록시되어 읽기-쓰기 사이트처럼 작동합니다.

프록시는 gitlab-workhorse 구성요소에 의해 수행됩니다. 보통 Geo 보조 사이트의 Rails 애플리케이션으로 보내는 트래픽은 주 Geo 사이트의 내부 URL로 프록시됩니다.

다음과 같이 사용 사례를 위해 보조 프록시를 사용합니다:

  • 모든 Geo 사이트를 단일 URL 뒤에 두기
  • 쓰기 액세스를 걱정하지 않고 지리적으로 트래픽을 로드 밸런싱
note
보조 사이트의 Geo 프록시는 Git 푸시 작업을 위한 Geo 프록시/리다이렉팅과 별도입니다.

개요는 다음을 참조하세요: Geo그래픽 로드 밸런서 및 AWS Route53을 사용한 보조 프록시 설정.

Geo 사이트를 위한 통합 URL 설정

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

모든 사이트에 트래픽을 보내기 위해 외부 URL 구성

위치 인식 공개 URL 단계를 따라 기본 포함한 모든 Geo 사이트에서 사용되는 단일 URL을 생성하세요.

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

  1. Geo 사이트에서 각 노드에 SSH하여 external_url을 해당 단일 URL로 변경합니다(푸마, 사이드킥, 로그-커서를 실행하는 각 노드): 

    sudo editor /etc/gitlab/gitlab.rb

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

    gitlab-ctl reconfigure

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

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

Kubernetes에서 주 사이트와 같은 도메인을 global.hosts.domain으로 사용할 수 있습니다.

별도의 URL을 사용한 Geo 프록시

  • 별도 URL의 경우 기본값으로 활성화됩니다(GitLab 15.1)..
note
이 섹션에서 설명된 피처 플래그는 향후 릴리스에서 사용되지 않을 것으로 예상되며 삭제될 예정입니다. 읽기 전용 Geo 보조 사이트에 대한 지원은 이슈 366810에 제안되었습니다. 해당 이슈에서 사용 사례를 공유하고 투표할 수 있습니다.

문제가 발생하는 경우 이 기능을 비활성화하려면 geo_secondary_proxy_separate_urls 피처 플래그를 비활성화하세요.

  1. 기본 Geo 사이트의 레일스를 실행 중인 노드 중 하나에 SSH하여 다음을 실행합니다: 

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

  2. 보조 Geo 사이트의 모든 노드에서 Puma를 다시 시작합니다: 

    sudo gitlab-ctl restart puma

Kubernetes에서 도구 상자 파드에서 동일한 명령을 실행할 수 있습니다. 자세한 내용은 Kubernetes 치트 시트를 참조하세요.

제약 사항

  • 보조 프록시를 사용할 때 비동기 Geo 복제는 지연이 발생할 수 있는 가속화된 데이터 유형에 예기치 않은 문제를 일으킬 수 있습니다.

    예를 들어, 복제된 지연으로 인해 읽기 후 쓰기 불일치가 발생할 수 있음을 발견했습니다. 복제 지연이 충분히 크면, 이는 보조 사이트에 액세스할 때 Git 읽기가 오래된 데이터를 수신하는 결과로 이어질 수 있습니다.

  • 레일스 요청 이외의 요청은 프록시되지 않으므로 다른 서비스는 항상 주 사이트로 요청을 보내기 위해 단일이 아닌 별도의 URL을 사용해야 합니다. 이러한 서비스에는 다음이 포함됩니다:

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

  • 보조 Geo 사이트를 사용하여 러너를 가속화하는 것은 실험적이며 프로덕션에 권장되지 않습니다. 러너를 설정하고 테스트할 수 있지만 일반적으로 사용 가능한 상태로 진행 사항은 epic 9779에서 추적할 수 있습니다.

  • 별도의 URL을 사용하는 경우, SAML을 사용하여 보조 사이트에 로그인은 SAML 식별 공급자(IdP)가 여러 콜백 URL로 구성된 응용 프로그램을 허용하는 경우에만 지원됩니다.

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

기본 사이트로 웹 트래픽을 프록시하는 것을 고려할 때, 기본 사이트에 접근할 수 없는 경우 보조 사이트의 동작이 다릅니다.

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

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

보조 Geo 사이트로 전송된 대부분의 HTTP 트래픽은 기본 Geo 사이트로 프록시될 수 있습니다. 이 구조를 통해 보조 Geo 사이트는 쓰기 요청을 지원할 수 있습니다. 일부 읽기 요청은 지역적으로 처리되어 개선된 대역폭과 지연 시간을 제공합니다. 모든 쓰기 요청은 기본 사이트로 프록시됩니다.

다음 표는 현재 Geo 보조 사이트 Workhorse 프록시를 통해 테스트된 컴포넌트를 자세히 나타냅니다. 모든 데이터 유형을 다루지 않습니다.

이 맥락에서 가속화된 읽기는 보조 사이트에서 제공되는 읽기 요청을 가리킵니다. 보조 사이트의 컴포넌트의 데이터가 최신인 경우 보조 사이트에서 서비스되며, 데이터가 오래된 경우 요청은 기본 사이트로 전달됩니다. 아래 표에 나열되지 않은 컴포넌트에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

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

Geo 프록시 사용 중지

통합 URL을 사용하는 경우(즉, 기본 사이트와 동일한 external_url을 사용하는 경우), 보조 사이트에서는 기본적으로 보조 프록시 사용이 활성화됩니다. 이 경우 프록시 사용을 비활성화하는 것은 라우팅에 따라 동일한 URL에서 완전히 다른 동작이 제공되므로 도움이 되지 않는 경향이 있습니다.

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

또한, gitlab-workhorse 서비스는 10초마다 /api/v4/geo/proxy를 폴링합니다. GitLab 15.2 이후에는 Geo가 비활성화되어 있으면 한 번만 폴링됩니다. GitLab 15.2 이전에 보조 프록시 사용을 비활성화함으로써 이 폴링을 중지할 수 있습니다.

Linux 패키지 설치에서 각 Geo 사이트에서 보조 프록시 사용을 비활성화하려면 다음 단계를 따르세요:

  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"를 사용하거나 values 파일에서 다음을 지정할 수 있습니다: 

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"