Geo 유효성 검사

Tier: Premium, Ultimate Offering: 셀프매니지먼트

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

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

GitLab 업그레이드

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

2020년 7월

Geo 멀티 노드 설치 업그레이드:

Geo 프라이머리 사이트에서 repmgr에서 Patroni로 전환:

  • 설명: 멀티 노드 Geo 프라이머리 사이트에서 repmgr에서 Patroni로 전환을 테스트했습니다. orchestrator 툴을 사용하여 repmgr로 관리되는 3개의 데이터베이스 노드를 가진 Geo 설치를 배포했습니다. 이를 통해 Patroni 및 PostgreSQL 11로 Geo 설치를 확인하는 관련된 이슈도 해결할 수 있었습니다.
  • 결과: 부분적으로 성공. 프라이머리 사이트에서 Patroni를 활성화하고 보조 사이트에서 데이터베이스 복제를 설정했습니다. 그러나 Patroni가 재시작될 때마다 보조 사이트의 복제 슬롯이 삭제된다는 문제점을 발견했습니다. 또한, Patroni가 클러스터에서 새 리더를 선출할 때 보조 사이트가 새 리더를 자동으로 따르지 못한다는 문제도 있었습니다. 이러한 문제가 해결될 때까지는 Geo 설치에 대한 Patroni의 공식 지원 및 추천이 불가능합니다.
  • 후속 이슈/작업:

2020년 6월

Geo 멀티 노드 설치 업그레이드:

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

Geo 멀티 노드 설치 업그레이드:

  • 설명: 멀티 노드 구성에서 GitLab 12.8.1에서 12.9.10 패키지로 업그레이드를 테스트했습니다.
  • 결과: 데모 중 제로 다운타임을 검증하기 위해 looping 파이프라인을 실행하지 않았기 때문에 부분적으로 성공하였습니다.
  • 후속 이슈:

2020년 2월

Geo 멀티 노드 설치 업그레이드:

  • 설명: 멀티 노드 구성에서 GitLab 12.7.5에서 최신 GitLab 12.8 패키지로 업그레이드를 테스트했습니다.
  • 결과: 데모 중 looping 파이프라인을 실행하지 않았기 때문에 부분적으로 성공하였습니다.

2020년 1월

Geo 멀티 노드 설치 업그레이드:

Geo 멀티 노드 설치 업그레이드:

Geo 멀티 노드 설치 업그레이드:

2019년 10월

Geo 멀티 노드 설치 업그레이드:

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

Geo 멀티 노드 설치 업그레이드:

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

Geo 멀티 노드 설치 업그레이드:

  • 설명: 멀티 노드 구성에서 GitLab 12.1.9에서 GitLab 12.2.8로 업그레이드를 테스트했습니다.
  • 결과: 잠재적인 잘못된 구성 문제로 부분적으로 성공하였습니다.

PostgreSQL 업그레이드

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

2021년 9월

PostgreSQL 13으로 Geo 설치 확인:

  • 설명: PostgreSQL 13을 GitLab 14.1에서 선택 가능한 버전으로 제공하기로 되어, PostgreSQL 13을 활성화한 상태에서 GitLab을 Geo와 함께 새로 설치하는 테스트를 진행했습니다.
  • 결과: GitLab 환경 도구킷을 사용하여 Geo 및 PostgreSQL 13을 사용하는 환경을 성공적으로 구축하고, 환경에서 Geo QA 테스트를 실패 없이 수행했습니다.

2020년 9월

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

  • 설명: PostgreSQL 12가 GitLab 13.3에서 선택 가능한 버전으로 제공하기로 되어, 기존의 Geo 설치에서 PostgreSQL 11에서 12로의 업그레이드를 테스트했습니다. 또한 PostgreSQL 12를 지원하기 위한 수정 사항이 적용된 후에 새로운 Geo 설치를 재테스트했습니다. 이러한 테스트는 GitLab 13.4의 nightly 빌드를 사용하여 진행되었습니다.
  • 결과: 기본 및 보조 데이터베이스 노드에서의 Geo 배포에 대한 테스트는 성공적이었습니다. 그러나 Geo 본 서버의 repmgr 및 Patroni 관리형 PostgreSQL 클러스터에서 알려진 문제가 발견되었습니다. 본 서버에서의 데이터베이스 클러스터와 PostgreSQL 12를 사용하는 것은 문제가 해결될 때까지 권장되지 않습니다.
  • PostgreSQL 클러스터에 대한 알려진 문제:

2020년 8월

PostgreSQL 12로 Geo 설치 확인:

2020년 4월

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

PostgreSQL 11로 Geo 설치 확인:

  • 설명: PostgreSQL 11을 GitLab 12.9에서 기본 버전으로 만들기 전에, GitLab 12.9에서 Geo가 설치된 상태로 PostgreSQL 11을 사용하여 새로운 설치를 테스트했습니다.
  • 결과: 설치 테스트는 성공적이었습니다.

2019년 9월

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

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

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

2022년 4월

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

  • 설명: AWS 기반 객체 리포지터리 복제 및 GitLab 기반 객체 리포지터리 복제를 사용하여 기본 객체 리포지터리 위치에서 보조 위치로 단일 이미지가 복제되는 평균 시간을 테스트했습니다. 이는 60초 동안 주기적으로 주요 사이트에서 프로젝트에 1MB 이미지를 업로드하여 테스트되었습니다. 그 후 보조 위치에서 이미지를 사용할 수 있는 시간을 메트릭했습니다. 이는 루비 스크립트를 통해 달성되었습니다.
  • 결과: AWS 관리 복제를 사용하면 사이트 간 이미지 복제에 대한 평균 시간은 약 49초가 소요되며, 이는 동일 지역 또는 더 먼 지역(유럽에서 미국까지) 간의 사이트에도 동일합니다. 동일 지역에서 Geo 관리 복제를 사용하는 경우, 복제에 소요된 평균 시간은 단 5초이고, 교차 지역 복제의 경우 평균 시간은 33초로 늘어납니다.

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

  • 설명: GCP 기반 객체 리포지터리 복제 및 GitLab 기반 객체 리포지터리 복제를 사용하여 기본 객체 리포지터리 위치에서 보조 위치로 단일 이미지가 복제되는 평균 시간을 테스트했습니다. 이는 60초 동안 주기적으로 주요 사이트에서 프로젝트에 1MB 이미지를 업로드하여 테스트되었습니다. 그 후 보조 위치에서 이미지를 사용할 수 있는 시간을 메트릭했습니다. 이는 루비 스크립트를 통해 달성되었습니다.
  • 결과: 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 사이트와 보조 Geo 사이트에 모두 Gitaly 클러스터를 구성한 Geo 배포를 테스트했습니다. 주 Geo 사이트에서 Gitaly 클러스터 자동 장애 조치를 트리거하고 엔드투엔드 Geo 테스트를 실행했습니다. 그런 다음 보조 Geo 사이트에서 Gitaly 클러스터 장애 조치를 트리거하고 엔드투엔드 Geo 테스트를 다시 실행했습니다.
  • 결과: 주 사이트에서 Gitaly 클러스터 장애 조치 전후 및 보조 사이트에서 Gitaly 클러스터 장애 조치 전후에 대한 엔드투엔드 테스트는 모두 성공적으로 완료되었습니다.