Geo 유효성 검사

Tier: Premium, Ultimate Offering: Self-managed

Geo 팀은 일반적인 배포 구성에 대한 매뉴얼 테스트 및 유효성 검사를 수행하여, GitLab의 소규모 버전 및 주요 PostgreSQL 데이터베이스 버전 간 업그레이드 시 Geo가 작동하는지 확인합니다.

이 섹션에는 유효성 검사 테스트 일지와 관련된 이슈로의 링크가 포함되어 있습니다.

GitLab 업그레이드

다음은 우리가 수행한 GitLab 업그레이드 유효성 검사 테스트입니다.

2020년 7월

Geo 다중 노드 설치 업그레이드:

Geo 기본 사이트에서 repmgr에서 Patroni로 전환:

  • 설명: 다중 노드 Geo 기본 사이트에서 repmgr에서 Patroni로 전환하는 테스트를 수행했습니다. 오케스트레이터 도구를 사용하여 repmgr에 의해 관리되는 3개의 데이터베이스 노드로 Geo 설치를 배포했습니다. 이 방법으로 우리는 또한 Patroni 및 PostgreSQL 11로 Geo 설치 확인와 관련된 이슈에 대한 처리를 할 수 있었습니다.
  • 결과: 부분적으로 성공했습니다. 우리는 기본 사이트에서 Patroni를 활성화하고, 보조 사이트에서 데이터베이스 복제를 설정했습니다. 그러나 Patroni가 보조 사이트의 복제 슬롯을 Patroni를 다시 시작할 때마다 삭제하는 것을 발견했습니다. 또 다른 문제는 Patroni가 클러스터에서 새 리더를 선출할 때 보조 사이트가 자동으로 새 리더를 따르지 못하는 것입니다. 이러한 문제가 해결될 때까지, Geo 설치에서 Patroni를 공식적으로 지원하고 권장할 수 없습니다.
  • 후속 이슈/작업:

2020년 6월

Geo 다중 노드 설치 업그레이드:

  • 설명: 다중 노드 구성에서 GitLab 12.9.10에서 12.10.12 패키지로 업그레이드 테스트를 수행했습니다. 루프 파이프라인 및 HAProxy 상태 대시보드를 사용하여 다운타임을 모니터링했습니다.
  • 결과: 기본 및 보조 사이트의 업그레이드 중에 다운타임이 관측되어 부분적으로 성공했습니다.
  • 후속 이슈/작업:

Geo 다중 노드 설치 업그레이드:

  • 설명: 다중 노드 구성에서 GitLab 12.8.1에서 12.9.10 패키지로 업그레이드 테스트를 수행했습니다.
  • 결과: 루프 파이프라인을 실행하지 않아 제로 다운타임을 유효성 검사하는 동안 부분적으로 성공했습니다.
  • 후속 이슈:

2020년 2월

Geo 다중 노드 설치 업그레이드:

  • 설명: 다중 노드 구성에서 GitLab 12.7.5에서 최신 GitLab 12.8 패키지로 업그레이드 테스트를 수행했습니다.
  • 결과: 루프 파이프라인을 실행하지 않아 제로 다운타임을 유효성 검사하는 동안 부분적으로 성공했습니다.

2020년 1월

Geo 다중 노드 설치 업그레이드:

Geo 다중 노드 설치 업그레이드:

Geo 다중 노드 설치 업그레이드:

2019년 10월

Geo 다중 노드 설치 업그레이드:

  • 설명: GitLab 12.3.5에서 12.4.1로의 업그레이드를 다중 노드 구성에서 테스트했습니다.
  • 결과: 업그레이드 테스트 성공.

Geo 다중 노드 설치 업그레이드:

  • 설명: GitLab 12.2.8에서 12.3.5로의 업그레이드를 테스트했습니다.
  • 결과: 업그레이드 테스트 성공.

Geo 다중 노드 설치 업그레이드:

  • 설명: GitLab 12.1.9에서 12.2.8로의 업그레이드를 테스트했습니다.
  • 결과: 가능한 잘못된 구성 문제로 부분적인 성공.

PostgreSQL 업그레이드

다음은 우리가 수행한 PostgreSQL 업그레이드 유효성 검사 테스트입니다.

2021년 9월

PostgreSQL 13으로 Geo 설치 확인:

  • 설명: GitLab 14.1에서 PostgreSQL 13이 옵트인 버전으로 제공될 때, PostgreSQL 13이 활성화된 상태에서 Geo로 GitLab의 신설을 테스트했습니다.
  • 결과: GitLab Environment Toolkit을 사용하여 Geo와 PostgreSQL 13이 들어간 환경을 성공적으로 구성하고, 환경에서 Geo QA 테스트를 수행하여 실패 없이 완료했습니다.

2020년 9월

Geo 설치를 위한 PostgreSQL 12 업그레이드 확인:

  • 설명: PostgreSQL 12가 GitLab 13.3에서 옵트인 버전으로 제공되기 전에, 기존의 Geo 설치를 PostgreSQL 11에서 12로 업그레이드하고, PostgreSQL 12를 지원하도록 수정된 후의 신설도 테스트했습니다. 이러한 테스트는 GitLab 13.4의 nightly build를 사용하여 수행했습니다.
  • 결과: 주 노드와 보조 노드에서 단일 데이터베이스 노드로 Geo 배포에 대한 시험은 성공했습니다. 그러나 Geo 주 노드의 repmgr 및 Patroni 관리형 PostgreSQL 클러스터에서 알려진 문제가 발생했습니다. 이슈가 해결될 때까지 주 노드에서 데이터베이스 클러스터와 함께 PostgreSQL 12를 사용하는 것은 권장되지 않습니다.
  • PostgreSQL 클러스터에 대한 알려진 문제:

2020년 8월

Geo 설치를 위한 PostgreSQL 12 확인:

2020년 4월

Geo 설치를 위한 PostgreSQL 11 업그레이드 절차:

Geo 설치를 위한 PostgreSQL 11 확인:

  • 설명: PostgreSQL 11을 GitLab 12.10의 기본 버전으로 만들기 전에, Geo를 설치한 GitLab 12.9의 신설을 테스트했습니다.
  • 결과: 설치 테스트 성공.

2019년 9월

Geo를 위한 PostgreSQL 10.0 업그레이드 테스트 및 확인:

객체 리포지터리 복제 테스트

다음은 우리가 수행한 추가 유효성 검사 테스트입니다.

2022년 4월

AWS 기반 객체 리포지터리를 사용하여 객체 리포지터리 복제 유효성 검사:

  • 설명: AWS 기반 객체 리포지터리 복제 및 GitLab 기반 객체 리포지터리 복제를 사용할 때 주 리포지터리 위치에서 보조 리포지터리로 단일 이미지가 복제되는 평균 소요 시간을 테스트했습니다. 이를 위해 1MB 이미지를 60초 동안 매 초 프로젝트에 업로드하여 테스트했습니다. 이미지가 보조 사이트에서 사용 가능해질 때까지 걸린 시간을 메트릭했습니다. 이를 루비 스크립트를 사용하여 테스트했습니다.
  • 결과: AWS 관리 복제를 사용할 때 사이트 간 이미지 복제에 소요된 평균 시간은 약 49초입니다. 이는 사이트가 같은 지역에 있을 때와 (유럽에서 미국으로) 더 멀리 떨어져 있을 때에도 동일합니다. 동일 지역에서 Geo 관리 복제를 사용할 때 복제에 소요된 평균 시간은 5초이지만, 교차 지역 복제의 경우 평균 시간은 33초로 증가했습니다.

GCP 기반 객체 리포지터리를 사용하여 객체 리포지터리 복제 유효성 검사:

  • 설명: GCP 기반 객체 리포지터리 복제 및 GitLab 기반 객체 리포지터리 복제를 사용할 때 주 리포지터리 위치에서 보조 리포지터리로 단일 이미지가 복제되는 평균 소요 시간을 테스트했습니다. 이를 위해 1MB 이미지를 60초 동안 매 초 프로젝트에 업로드하여 테스트했습니다. 이미지가 보조 사이트에서 사용 가능해질 때까지 걸린 시간을 메트릭했습니다. 이를 루비 스크립트를 사용하여 테스트했습니다.
  • 결과: GCP는 다른 클라우드 제공업체들과는 다르게 복제를 처리합니다. GCP에서는 옵션에 따라 단일 지역, 이중 지역 또는 단일 지역을 기반으로 하는 단일 버킷을 생성하는 프로세스입니다. 이는 버킷이 선택한 옵션을 기반으로 지역에 복제본을 자동으로 저장한다는 것을 의미합니다. 멀티 지역을 사용하더라도 이는 대륙 내에서만 복제되며, 옵션은 미국, 유럽 또는 아시아입니다. 현재로서 GCP 기반 복제를 사용하여 대륙 간 객체를 복제하는 방법은 없는 것처럼 보입니다. 같은 지역에서 Geo 관리 복제를 사용할 때 평균 복제 시간은 6초이며, 교차 지역 복제의 경우 9초로 증가했습니다.

2022년 1월

Azure 기반 객체 리포지터리를 사용하여 객체 리포지터리 복제 유효성 검사:

  • 설명: Azure 기반 객체 리포지터리 복제 및 GitLab 기반 객체 리포지터리 복제를 사용할 때 주 리포지터리 위치에서 보조 리포지터리로 단일 이미지가 복제되는 평균 소요 시간을 테스트했습니다. 이를 위해 1MB 이미지를 60초 동안 매 초 프로젝트에 업로드하여 테스트했습니다. 이미지가 보조 사이트에서 사용 가능해질 때까지 걸린 시간을 메트릭했습니다. 이를 루비 스크립트를 사용하여 테스트했습니다.
  • 결과: Azure 기반 복제를 사용할 때 주 리포지터리에서 보조 리포지터리로 이미지가 복제되는 평균 시간은 40초이고, 가장 긴 복제 시간은 70초, 가장 짧은 시간은 11초로 기록되었습니다. GitLab 기반 복제를 사용할 때 복제가 완료되는데 소요된 시간은 평균 5초이고, 가장 긴 복제 시간은 10초, 가장 짧은 시간은 3초로 기록되었습니다.
  • 후속 이슈:

2021년 5월

객체 리포지터리 복제 활성화 상태에서 장애 조치 테스트:

  • 설명: 테스트 당시 Geo의 객체 리포지터리 복제 기능이 베타 상태였습니다. 객체 리포지터리 복제가 의도한 대로 작동하고 장애 조치 후 새로운 기본 사이트에 데이터가 있는지 테스트했습니다.
  • 결과: 테스트는 성공적이었습니다. 객체 리포지터리의 데이터가 복제되었으며 장애 조치 후에도 데이터가 존재했습니다.
  • 후속 이슈:

다른 테스트

2020년 8월

Geo 배포에서 Gitaly 클러스터 테스트:

  • 설명: 기본 및 보조 Geo 사이트 모두에 Gitaly 클러스터가 구성된 Geo 배포를 테스트했습니다. 기본 Geo 사이트에서 Gitaly 클러스터 자동 장애 조치를 트리거하고, 엔드투엔드 Geo 테스트를 실행했습니다. 그런 다음 보조 Geo 사이트에서 Gitaly 클러스터 장애 조치를 트리거하고, 엔드투엔드 Geo 테스트를 다시 실행했습니다.
  • 결과: 기본 사이트 및 보조 사이트에서 Gitaly 클러스터 장애 조치 전후의 성공적인 엔드투엔드 테스트입니다.