보조 사이트는 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다. 몇 가지 주요 예외를 제외한 모든 작업을 기본 사이트로 투명하게 프록시합니다.

이 동작으로 다음과 같은 사용 사례를 구현할 수 있습니다.

• 모든 Geo 사이트를 단일 URL 뒤에 두어, 사용자가 어느 사이트에 접속하든 일관되고 끊김 없는 전체 기능의 경험을 제공합니다. 사용자는 여러 GitLab URL을 번갈아 쓸 필요가 없습니다.
• 쓰기 액세스를 걱정하지 않고 트래픽을 지리적으로 분산합니다.

개요는 보조 사이트를 위한 Geo 프록시를 참고합니다.

알려진 문제는 Geo 문서의 프록시 관련 항목을 참고합니다.

Geo 사이트용 통합 URL 설정#

보조 사이트는 읽기·쓰기 트래픽을 투명하게 처리할 수 있습니다. 따라서 단일 외부 URL을 사용해 요청이 기본 Geo 사이트나 보조 Geo 사이트 어느 쪽으로든 도달하게 할 수 있습니다. 이렇게 하면 사용자가 어느 사이트에 접속하든 일관되고 끊김 없는 전체 기능의 경험을 제공합니다. 사용자는 여러 URL을 번갈아 쓸 필요도, 사이트가 여러 개라는 사실을 알 필요도 없습니다.

Geo 사이트로 트래픽을 라우팅하는 방법은 다음과 같습니다.

• Geo 위치 인식 DNS. 기본 사이트든 보조 사이트든 가장 가까운 Geo 사이트로 트래픽을 라우팅합니다. 예시는 위치 인식 DNS 구성을 참고합니다.
• 라운드 로빈 DNS.
• 로드 밸런서. 인증 실패와 교차 사이트 요청 오류를 막으려면 고정 세션을 사용해야 합니다. DNS 라우팅은 본래 고정적이므로 이 제약이 없습니다.

위치 인식 DNS 구성#

기본 사이트든 보조 사이트든 가장 가까운 Geo 사이트로 트래픽을 라우팅하려면 다음 예시를 따릅니다.

사전 요구 사항#

이 예시에서는 요청을 다음과 같이 자동으로 전달하는 gitlab.example.com 서브도메인을 만듭니다.

• 유럽에서 온 요청은 보조 사이트로 전달합니다.
• 그 외 지역에서 온 요청은 기본 사이트로 전달합니다.

이 예시에는 다음이 필요합니다.

• 동작 중인 Geo 기본 사이트와 보조 사이트. Geo 설정 안내를 참고합니다.
• 도메인을 관리하는 DNS 영역. 다음 안내는 AWS Route53과 GCP cloud DNS를 사용하지만 Cloudflare 같은 다른 서비스도 사용할 수 있습니다.

AWS Route53#

이 예시에서는 Route53 설정을 위해 도메인을 관리하는 Route53 호스팅 영역을 사용합니다.

Route53 호스팅 영역에서는 트래픽 정책으로 다양한 라우팅 구성을 설정할 수 있습니다. 트래픽 정책을 만드는 방법은 다음과 같습니다.

1. Route53 대시보드로 이동해 Traffic policies를 선택합니다.

2. Create traffic policy를 선택합니다.

3. Policy Name 필드에 Single Git Host를 입력하고 Next를 선택합니다.

4. DNS type은 A: IP Address in IPv4 format으로 둡니다.

5. Connect to를 선택한 다음 Geolocation rule을 선택합니다.

6. 첫 번째 Location은 다음과 같이 설정합니다.

   1. Default로 둡니다.
   2. Connect to를 선택한 다음 New endpoint를 선택합니다.
   3. Type으로 value를 선택하고 <your primary IP address>를 입력합니다.

7. 두 번째 Location은 다음과 같이 설정합니다.

   1. Europe를 선택합니다.
   2. Connect to를 선택한 다음 New endpoint를 선택합니다.
   3. Type으로 value를 선택하고 <your secondary IP address>를 입력합니다.

   

8. Create traffic policy를 선택합니다.

9. Policy record DNS name에 gitlab을 입력합니다.

   

10. Create policy records를 선택합니다.

이제 gitlab.example.com 같은 단일 호스트가 설정되었으며, 이 호스트는 지리적 위치에 따라 Geo 사이트로 트래픽을 분산합니다.

GCP#

이 예시에서는 도메인을 관리하는 GCP Cloud DNS 영역을 만듭니다.

Geo 기반 레코드 집합을 만들 때, 트래픽의 출발 지역이 어떤 정책 항목과도 정확히 일치하지 않으면 GCP는 출발 리전에 가장 가까운 항목을 적용합니다. Geo 기반 레코드 집합을 만드는 방법은 다음과 같습니다.

1. Network Services > Cloud DNS를 선택합니다.
2. 도메인에 구성된 영역을 선택합니다.
3. Add Record Set을 선택합니다.
4. 위치 인식 공개 URL의 DNS 이름을 입력합니다. 예를 들면 gitlab.example.com 입니다.
5. Routing Policy로 Geo-Based를 선택합니다.
6. Add Managed RRData를 선택합니다.
   1. Source Region으로 us-central1을 선택합니다.
   2. <primary IP address>를 입력합니다.
   3. Done을 선택합니다.
7. Add Managed RRData를 선택합니다.
   1. Source Region으로 europe-west1을 선택합니다.
   2. <secondary IP address>를 입력합니다.
   3. Done을 선택합니다.
8. Create를 선택합니다.

이제 gitlab.example.com 같은 단일 호스트가 설정되었으며, 이 호스트는 위치 인식 URL로 Geo 사이트에 트래픽을 분산합니다.

모든 사이트가 같은 외부 URL을 사용하도록 구성#

단일 URL에서 모든 Geo 사이트로 라우팅을 설정한 뒤, 사이트가 서로 다른 URL을 사용한다면 다음 단계를 따릅니다.

1. 각 GitLab 사이트에서 Rails(Puma, Sidekiq, Log-Cursor)를 실행하는 노드마다 SSH로 접속해 external_url을 단일 URL로 설정합니다.

   sudo -e /etc/gitlab/gitlab.rb
   

2. 변경 사항을 적용하려면 업데이트한 노드를 재구성합니다.

   sudo gitlab-ctl reconfigure
   

3. 보조 Geo 사이트에 설정한 새 외부 URL과 일치하도록 기본 데이터베이스에도 이 변경이 반영되어야 합니다.

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

   사이트끼리 통신할 수 있도록 Internal URL 필드가 사이트마다 고유한지 확인합니다.

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

보조 Geo 사이트용 별도 URL 설정#

사이트마다 서로 다른 외부 URL을 사용할 수 있습니다. 이를 통해 특정 사용자 집단에 특정 사이트를 제공할 수 있습니다. 또는 사용자가 사용할 사이트를 직접 고르게 할 수도 있지만, 그 선택에 따르는 영향을 사용자가 이해하고 있어야 합니다.

보조 Geo 사이트를 기본 사이트와 다른 외부 URL로 구성#

보조 사이트가 기본 사이트와 동일한 외부 URL을 사용하고 있는데 다른 URL을 사용하도록 바꾸려면 다음 단계를 따릅니다.

1. 보조 사이트에서 Rails(Puma, Sidekiq, Log-Cursor)를 실행하는 노드마다 SSH로 접속해 external_url을 보조 사이트에 사용할 URL로 설정합니다.

   sudo -e /etc/gitlab/gitlab.rb
   

2. 변경 사항을 적용하려면 업데이트한 노드를 재구성합니다.

   sudo gitlab-ctl reconfigure
   

3. 보조 Geo 사이트에 설정한 새 외부 URL과 일치하도록 기본 데이터베이스에도 이 변경이 반영되어야 합니다.

   기본 사이트의 Geo 관리 페이지에서 대상 보조 사이트를 편집해 URL 필드를 사용할 URL로 설정합니다.

   사이트끼리 통신할 수 있도록 Internal URL 필드가 사이트마다 고유한지 확인합니다. 사용할 URL 이 이 사이트에만 쓰인다면 Internal URL 필드를 비워 둘 수 있습니다. 저장하면 외부 URL 이 기본값으로 사용됩니다.

기본 Geo 사이트가 중단된 경우 보조 사이트의 동작#

웹 트래픽이 기본 사이트로 프록시된다는 점을 고려하면, 기본 사이트에 접근할 수 없을 때 보조 사이트의 동작은 다음과 같이 달라집니다.

• UI 및 API 트래픽은 프록시되므로 기본 사이트와 동일한 오류를 반환합니다(기본 사이트에 아예 접근할 수 없으면 실패합니다).
• 접속한 보조 사이트에서 완전히 최신 상태인 리포지터리는 HTTP(S) 또는 SSH 인증을 포함해 Git 읽기 작업이 정상적으로 동작합니다. 다만 GitLab Runner가 수행하는 Git 읽기는 실패합니다.
• 보조 사이트로 복제되지 않은 리포지터리의 Git 작업은 프록시되므로 기본 사이트와 동일한 오류를 반환합니다.
• 모든 Git 쓰기 작업은 프록시되므로 기본 사이트와 동일한 오류를 반환합니다.

보조 Geo 사이트가 가속하는 기능#

보조 Geo 사이트로 전달되는 대부분의 HTTP 트래픽은 기본 Geo 사이트로 프록시됩니다. 이 아키텍처 덕분에 보조 Geo 사이트도 쓰기 요청을 지원하고 쓰기 후 읽기 문제를 피할 수 있습니다. 일부 읽기 요청은 지연 시간과 인근 대역폭을 개선하기 위해 보조 사이트가 직접 처리합니다.

다음 표는 Geo 보조 사이트의 Workhorse 프록시를 통해 테스트한 구성 요소를 정리한 것입니다. 모든 데이터 유형을 다루지는 않습니다.

여기서 가속 읽기란 보조 사이트의 해당 구성 요소 데이터가 최신 상태일 때 보조 사이트가 직접 처리하는 읽기 요청을 뜻합니다. 보조 사이트의 데이터가 오래된 것으로 판단되면 요청은 기본 사이트로 전달됩니다. 아래 표에 없는 구성 요소의 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

특정 기능의 가속을 요청하려면 에픽 8239에 이미 이슈가 있는지 확인하고, 추천하거나 댓글을 남겨 관심을 표시하거나 GitLab 담당자에게 대신 요청합니다. 해당하는 이슈가 없다면 새로 만들고 에픽에 언급합니다.

보조 사이트 HTTP 프록시 비활성화#

보조 사이트가 통합 URL을 사용할 때, 즉 기본 사이트와 동일한 external_url로 구성되어 있을 때 보조 사이트 HTTP 프록시는 기본적으로 활성화됩니다. 이 경우 프록시를 비활성화하면 라우팅에 따라 같은 URL에서 전혀 다른 동작이 제공되므로 대체로 도움이 되지 않습니다. 보조 Geo 사이트에서 HTTP 프록시를 비활성화하면 해당 사이트는 읽기 전용 모드로 동작하며, 유의해야 할 중요한 제약이 몇 가지 있습니다.

보조 사이트 프록시를 비활성화할 때의 동작#

프록시 기능 플래그를 비활성화하면 전반적으로 다음과 같은 영향이 있습니다.

HTTP 및 Git 요청#

• 보조 사이트는 HTTP 요청을 기본 사이트로 프록시하지 않습니다. 대신 자체적으로 처리하려 하거나 실패합니다.
• Git 요청은 대체로 성공합니다. Git 푸시는 기본 사이트로 리디렉션되거나 프록시됩니다.
• Git 요청 외에 데이터를 쓸 수 있는 HTTP 요청은 실패합니다. 읽기 요청은 대체로 성공합니다.

GEO_SECONDARY_PROXY 환경 변수를 사용하는 대신 기능 플래그를 사용해야 합니다.

GitLab 15.1 부터는 통합 URL을 사용하지 않는 보조 사이트에서도 HTTP 프록시가 기본적으로 활성화됩니다.

서비스 약관 동의#

프록시가 비활성화되면 보조 사이트에만 접속하는 사용자는 서비스 약관이나 기타 법적 합의에 제대로 동의할 수 없습니다. 이로 인해 다음 문제가 발생합니다.

• 동의 기록 부재: 직원이 보조 사이트에만 로그인하는 경우 약관 메시지가 표시되더라도, 보조 사이트 프록시가 비활성화된 상태에서는 약관 동의를 포함한 쓰기 작업이 프록시되지 않으므로 동의 사실이 기본 데이터베이스에 기록되지 않습니다.
• 법적 준수 문제: 직원이 보조 사이트만 통해 GitLab 서비스를 사용하면 약관 동의를 확인할 수 있는 기록이 없으므로, 조직이 필요한 법적 근거를 확보하지 못할 수 있습니다.

해결 방법으로, 약관에 제대로 동의하려면 기본 사이트에 최소 한 번은 접속해야 합니다. 기본 사이트에서 동의한 뒤에는 이 정보가 일반적인 Geo 동기화를 통해 보조 사이트로 복제됩니다.

모든 보조 사이트에서 프록시 비활성화#

모든 보조 사이트에서 프록시를 비활성화해야 한다면 기능 플래그를 비활성화하는 것이 가장 간단합니다.

변경을 되돌려 보조 사이트 프록시를 다시 활성화하는 방법은 다음과 같습니다.

사이트별 보조 사이트 HTTP 프록시 비활성화#

보조 사이트가 여러 개라면 다음 단계에 따라 보조 사이트마다 HTTP 프록시를 개별적으로 비활성화할 수 있습니다.

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

보조 사이트 Git 프록시 비활성화#

다음 항목의 전달은 비활성화할 수 없습니다.

• SSH 상의 Git 푸시
• 보조 사이트의 Git 리포지터리가 최신 상태가 아닐 때의 SSH 상의 Git 풀
• HTTP 상의 Git 푸시
• 보조 사이트의 Git 리포지터리가 최신 상태가 아닐 때의 HTTP 상의 Git 풀