보조 사이트용 지오 프록시 설정

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

지오 프록시를 사용하여 다음과 같은 작업을 수행할 수 있습니다:

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

활성화되면 보조 사이트 사용자는 주 사이트 UI에 접근하는 것처럼 WebUI를 사용할 수 있습니다. 이로 인해 보조 사이트의 전반적인 사용자 경험이 크게 개선됩니다.

보조 프록시를 통해 보조 지오 사이트로의 웹 요청이 직접 주 사이트로 프록시되어 읽기-쓰기 사이트로 작동하는 것처럼 보입니다.

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

보조 프록시 사용 사례는 다음과 같습니다:

  • 모든 지오 사이트가 하나의 URL 뒤에 있는 경우
  • 쓰기 액세스에 대해 걱정할 필요없이 지리적으로 트래픽을 로드 밸런싱하는 경우

참고: 보조 사이트용 지오 프록시는 Git 푸시 작업을 위한 지오 프록시/리디렉션과 별도입니다.

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

지오 사이트를 위한 통합 URL 설정

보조 사이트는 투명하게 읽기-쓰기 트래픽을 제공할 수 있습니다. 주 요청은 주 지오 사이트 또는 지오 프록시를 사용하는 모든 보조 지오 사이트로 전달될 수 있는 단일 외부 URL을 사용할 수 있습니다.

트래픽을 양쪽 사이트로 전송하기 위한 외부 URL 구성

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

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

  1. Geo 사이트에서 각 노드(Rails(Puma, Sidekiq, Log-Cursor)를 실행 중인)에 SSH로 연결하고 external_url을 해당 단일 URL로 변경합니다: 

    sudo editor /etc/gitlab/gitlab.rb

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

    gitlab-ctl reconfigure

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

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

쿠버네티스에서는 기본 사이트와 동일한 도메인을 global.hosts.domain 아래에서 사용할 수 있습니다.

별도 URL을 사용한 지오 프록시

  • 별도 URL의 경우 기본으로 활성화됨 in GitLab 15.1.

참고: 이 섹션에서 설명하는 기능 플래그는 향후 릴리스에서 사용되지 않게되며 제거될 예정입니다. 읽기 전용 지오 보조 사이트 지원은 issue 366810에서 제안되었습니다. 해당 이슈에서 사용 사례에 대해 표시하고 의견을 나눌 수 있습니다.

문제가 발생하면 이 기능을 비활성화하려면 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

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

제한사항

  • 보조 프록시를 사용하는 경우 비동기 Geo 복제는 지연된 상태로 Geo 보조에 복제될 수 있는 가속화된 데이터 유형에 대해 예기치 않은 문제를 일으킬 수 있습니다.

    예를 들어, 복제 지연이 읽기 후 쓰기 불일치를 발생시킬 수 있다는 잠재적인 문제를 발견했습니다. 복제 지연이 충분히 높으면 보조에 도달할 때 Git 읽기가 오래된 데이터를 수신할 수 있습니다.

  • 비-Rails 요청은 프록시로 전달되지 않으므로 다른 서비스는 항상 요청이 기본 위치로 전송되도록 별도의 통합되지 않은 URL을 사용해야 할 수 있습니다. 이러한 서비스로는 다음이 포함됩니다:

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

  • 보조 Geo 사이트를 사용하여 러너를 가속화하는 것은 실험적이며 프로덕션에 권장되지 않습니다. 보조 프록시 러너의 단계에 따라 구성하고 테스트할 수 있습니다. 일반 사용 가능성에 대한 진행 상황은 이슈 9779에서 추적할 수 있습니다.

  • 별도의 URL과 함께 보조 프록시를 사용하는 경우, 프록시 사용을 활성화한 별도의 URL에서 SAML을 사용한 보조 사이트에 로그인은 SAML ID 피드를 허용하는 경우에만 지원됩니다. 애플리케이션이 여러 콜백 URL로 구성될 수 있도록 허용하는 경우에만 지원됩니다.

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

기본 사이트로의 웹 트래픽이 프록시로 전송되므로 기본 사이트에 액세스할 수 없는 경우 보조 사이트의 동작이 다르게 됩니다:

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

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

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

다음 표는 현재 Geo 보조 사이트 Workhorse 프록시를 통해 테스트된 구성 요소를 상세하게 설명합니다. 모든 데이터 유형을 다루지는 않습니다.

이 맥락에서 가속된 읽기는 보조 사이트에 로컬로 처리되는 읽기 요청을 참조하며 해당 보조 사이트의 구성 요소에 대해 데이터가 최신 상태인 경우에만 제공됩니다. 보조 사이트에서 데이터가 오래된 것으로 판명된 경우 요청은 기본 사이트로 전달됩니다. 아래 표에 나열되지 않은 구성 요소에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

기능 / 구성 요소 가속된 읽기? 주석
프로젝트, 위키, 디자인 저장소(웹 UI 사용) 아니요  
프로젝트, 위키 저장소(Git 사용) 예 Git 읽기는 로컬 보조 사이트에서 제공되지만 푸시는 기본으로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 저장소가 없는 경우 “찾을 수 없음” 오류가 발생합니다.
프로젝트, 개인 스니펫(웹 UI 사용) 아니요  
프로젝트, 개인 스니펫(Git 사용) 예 Git 읽기는 로컬 보조 사이트에서 제공되지만 푸시는 기본으로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 저장소가 없는 경우 “찾을 수 없음” 오류가 발생합니다.
그룹 위키 저장소(웹 UI 사용) 아니요  
그룹 위키 저장소(Git 사용) 예 Git 읽기는 로컬 보조 사이트에서 제공되지만 푸시는 기본으로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 저장소가 없는 경우 “찾을 수 없음” 오류가 발생합니다.
사용자 업로드 아니요  
LFS 객체(웹 UI 사용) 아니요  
LFS 객체(Git 사용) 예  
페이지 아니요 페이지는 동일한 URL을 사용할 수 있지만(접근 제어 없이), 별도로 구성되어 프록시되지 않습니다.
고급 검색(웹 UI 사용) 아니요  
컨테이너 레지스트리 아니요 컨테이너 레지스트리는 재해 복구 시나리오에만 권장됩니다. 보조 사이트의 컨테이너 레지스트리가 최신 상태가 아닌 경우 읽기 요청은 이전 데이터로 제공됩니다. 컨테이너 레지스트리의 가속화는 계획 중이며 관심을 표시하거나 이슈에 대해 GitLab 대표에 요청하세요.
의존성 프록시 아니요 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"