지오 유효성 검사

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

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

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

GitLab 업그레이드

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

2020년 7월

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

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

  • 설명: 다중 노드 Geo 주 사이트에서 repmgr에서 Patroni로 전환을 테스트했습니다. orchestrator tool을 사용하여 repmgr이 관리하는 3개의 데이터베이스 노드로 된 Geo 설치를 배포했습니다. 이 접근 방식으로 Patroni 및 PostgreSQL 11로 Geo 설치 확인 문제에 대한 해결책을 찾을 수도 있었습니다.
  • 결과: 부분적으로 성공했습니다. 주 사이트에서 Patroni를 활성화하고 부 사이트에서 데이터베이스 복제를 설정했습니다. 그러나 Patroni가 두 번째 사이트의 복제 슬롯을 Patroni가 재시작될 때마다 삭제하는 문제가 발견되었습니다. 또한 Patroni가 클러스터에서 새 리더를 선택하면 부 사이트가 새 리더를 자동으로 따르지 못하는 문제가 있습니다. 이러한 문제가 해결되지 않는 한, 공식적으로 Geo 설치에 Patroni를 지원하고 추천할 수 없습니다.
  • 추후 작업/이슈:

2020년 6월

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

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

2020년 2월

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

  • 설명: 다중 노드 구성에서 GitLab 12.7.5에서 최신 GitLab 12.8 패키지로 업그레이드를 시험했습니다.
  • 결과: 루핑 파이프라인을 실행하지 않아 다운타임을 모니터링하지 못하여 부분적으로 성공했습니다.

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 설치 검증:

  • 설명: GitLab 14.1에서 PostgreSQL 13을 옵트인 버전으로 사용할 수 있게 되었으며, PostgreSQL 13이 활성화된 상태에서 Geo로 GitLab의 신설을 테스트했습니다.
  • 결과: GitLab Environment Toolkit을 사용하여 Geo와 PostgreSQL 13이 활성화된 환경을 성공적으로 구축했고, 환경에서 Geo QA 테스트를 실패 없이 수행했습니다.

2020년 9월

Geo 설치에 대한 PostgreSQL 12 업그레이드 확인:

  • 설명: GitLab 13.3에서 PostgreSQL 12가 옵트인 버전으로 사용할 수 있게 되었으며, 기존의 Geo 설치를 PostgreSQL 11에서 12로 업그레이드하는 테스트를 수행했으며, PostgreSQL 12를 지원하기 위한 수정 사항이 적용된 후에는 새로운 GitLab의 설치를 재테스트했습니다. 이러한 테스트는 GitLab 13.4의 nightly build를 사용하여 진행했습니다.
  • 결과: 기본 및 보조의 단일 데이터베이스 노드와 함께 Geo 배치에 대한 테스트가 성공적으로 완료되었습니다. 그러나 Geo 주 서버의 repmgr 및 Patroni에서 알려진 문제점이 발견되었습니다. 이슈가 해결될 때까지 기본에서 데이터베이스 클러스터와 함께 PostgreSQL 12를 사용하는 것은 권장하지 않습니다.
  • PostgreSQL 클러스터에 대한 알려진 이슈:

2020년 8월

PostgreSQL 12로 Geo 설치 확인:

2020년 4월

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

PostgreSQL 11로 Geo 설치 확인:

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

2019년 9월

Geo를 위한 PostgreSQL 10.0 업그레이드 검증:

  • 설명: 12.0 릴리스에서 GitLab이 PostgreSQL 10.0으로 업그레이드가 필요했습니다. 우리는 GitLab 12.1.8까지 다양한 업그레이드 시나리오를 테스트했습니다.
  • 결과: 업그레이드 중에 여러 문제를 발견했으며, 해당 문제는 후속 이슈에서 해결되었습니다.
  • 후속 이슈:
    • gitlab-ctl reconfigure가 다중 노드 Geo 설정의 Redis 노드에서 실패합니다(https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4706).
    • 12.0.9에서 12.1.9로의 Geo 다중 노드 업그레이드가 PostgreSQL을 업그레이드하지 않음(https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4705).
    • 12.1.9로 업그레이드 후 다중 노드 설정의 앱 서버에서 외래 테이블 갱신 실패(https://gitlab.com/gitlab-org/gitlab/-/issues/32119)

객체 저장소 복제 테스트

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

2022년 4월

AWS 기반 객체 저장소 사용하여 객체 저장소 복제 유효성 검사:

  • 설명: AWS 기반 객체 저장소 복제와 GitLab 기반 객체 저장소 복제 사용 시 기본 객체 저장소 위치에서 보조 위치로 단일 이미지가 복제되는 평균 시간을 테스트했습니다. 프로젝트에 1MB 이미지를 60초에 한 번씩 기본 사이트에 업로드하여 테스트했습니다. 그런 다음 보조 사이트에서 이미지를 사용 가능할 때까지 시간을 측정했습니다. 이 과정은 Ruby Script를 사용하여 테스트되었습니다.
  • 결과: AWS 관리 복제를 사용할 때 사이트간 이미지 복제에 대한 평균 시간은 약 49초이며, 이는 사이트가 같은 지역에 있는 경우나 멀리 떨어져 있는 경우 (유럽에서 미국으로)에도 동일합니다. 동일한 지역에서 Geo 관리 복제를 사용하면 복제에 소요되는 평균 시간은 단 5초이지만, 대륙 간 복제의 경우 평균 시간은 33초로 증가했습니다.

GCP 기반 객체 저장소 사용하여 객체 저장소 복제 유효성 검사:

  • 설명: GCP 기반 객체 저장소 복제와 GitLab 기반 객체 저장소 복제 사용 시 기본 객체 저장소 위치에서 보조 위치로 단일 이미지가 복제되는 평균 시간을 테스트했습니다. 프로젝트에 1MB 이미지를 60초에 한 번씩 기본 사이트에 업로드하여 테스트했습니다. 그런 다음 보조 사이트에서 이미지를 사용 가능할 때까지 시간을 측정했습니다. 이 과정은 Ruby Script를 사용하여 테스트되었습니다.
  • 결과: GCP는 다른 클라우드 제공업체와 다르게 복제를 처리합니다. GCP에서는 단일 버킷을 생성하여 다중, 이중 또는 단일 지역 기반 버킷을 만드는 프로세스입니다. 이는 선택한 옵션에 따라 버킷이 자동으로 복제본을 해당 지역에 저장한다는 것을 의미합니다. 멀티 리전을 사용해도 대륙에서만 복제하기 때문에 옵션은 미주, 유럽 또는 아시아입니다. 현재까지 GCP 기반 복제를 사용하여 대륙 간에 객체를 복제하는 방법은 없는 것으로 보입니다. 동일 지역에서 Geo 관리 복제를 사용하면 복제에 소요되는 평균 시간은 6초이고, 대륙 간 복제의 경우 이 수치는 9초로 증가했습니다.

2022년 1월

Azure 기반 객체 저장소 사용하여 객체 저장소 복제 유효성 검사:

  • 설명: Azure 기반 객체 저장소 복제와 GitLab 기반 객체 저장소 복제 사용 시 기본 객체 저장소 위치에서 보조 위치로 단일 이미지가 복제되는 평균 시간을 테스트했습니다. 프로젝트에 1MB 이미지를 60초에 한 번씩 기본 사이트에 업로드하여 테스트했습니다. 그런 다음 보조 사이트에서 이미지를 사용 가능할 때까지 시간을 측정했습니다. 이 과정은 Ruby Script를 사용하여 테스트되었습니다.
  • 결과: 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 클러스터 장애 조치 전후 및 보조 사이트에서 Gitaly 클러스터 장애 조치 전후에 대한 엔드 투 엔드 테스트가 모두 성공적으로 수행되었습니다.