Geo 유효성 검사 테스트
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
Offering: GitLab Self-Managed
요약
Geo 팀은 일반적인 배포 구성에서 수동 테스트 및 유효성 검사를 수행하여 GitLab 마이너 버전 간 업그레이드 및 주요 PostgreSQL 데이터베이스 버전 업그레이드 시 Geo가 정상 작동하는지 확인합니다. 이 섹션에는 유효성 검사 테스트의 기록과 관련 이슈 링크가 포함되어 있습니다.
Geo 팀은 일반적인 배포 구성에서 수동 테스트 및 유효성 검사를 수행하여 GitLab 마이너 버전 간 업그레이드 및 주요 PostgreSQL 데이터베이스 버전 업그레이드 시 Geo가 정상 작동하는지 확인합니다.
이 섹션에는 유효성 검사 테스트의 기록과 관련 이슈 링크가 포함되어 있습니다.
GitLab 업그레이드#
다음은 수행한 GitLab 업그레이드 유효성 검사 테스트입니다.
2020년 7월#
- 설명: 멀티 노드 구성에서 GitLab 12.10.12에서 13.0.10 패키지로 업그레이드를 테스트했습니다. 멀티 노드 Geo 배포를 위한 제로 다운타임 업그레이드 프로세스/지침 수정 이슈의 일부로, 루핑 파이프라인, HAProxy 통계 대시보드, 두 노드의 준비 상태를 기록하는 스크립트를 사용하여 다운타임을 모니터링했습니다.
- 결과: 기본 및 보조 사이트 업그레이드 중 다운타임이 관찰되어 부분적으로 성공했습니다.
- 후속 이슈/액션:
Geo 기본 사이트에서 repmgr에서 Patroni로 전환:
- 설명: 멀티 노드 Geo 기본 사이트에서 repmgr에서 Patroni로의 전환을 테스트했습니다. 오케스트레이터 도구를 사용하여 repmgr로 관리되는 3개의 데이터베이스 노드가 있는 Geo 설치를 배포했습니다. 이 방법으로 Patroni 및 PostgreSQL 11을 사용한 Geo 설치 검증을 위한 관련 이슈도 처리할 수 있었습니다.
- 결과: 부분적으로 성공했습니다. 기본 사이트에서 Patroni를 활성화하고 보조 사이트에서 데이터베이스 복제를 설정했습니다. 그러나 Patroni가 재시작될 때마다 보조 사이트의 복제 슬롯을 삭제한다는 것을 발견했습니다. 또 다른 문제는 Patroni가 클러스터에서 새 리더를 선출할 때 보조 사이트가 새 리더를 자동으로 따르지 못한다는 것입니다. 이러한 문제가 해결될 때까지 Geo 설치에 Patroni를 공식적으로 지원하고 권장할 수 없습니다.
- 후속 이슈/액션:
2020년 6월#
- 설명: 멀티 노드 구성에서 GitLab 12.9.10에서 12.10.12 패키지로 업그레이드를 테스트했습니다. 루핑 파이프라인과 HAProxy 통계 대시보드를 사용하여 다운타임을 모니터링했습니다.
- 결과: 기본 및 보조 사이트 업그레이드 중 다운타임이 관찰되어 부분적으로 성공했습니다.
- 후속 이슈/액션:
- 설명: 멀티 노드 구성에서 GitLab 12.8.1에서 12.9.10 패키지로 업그레이드를 테스트했습니다.
- 결과: 데모 중 루핑 파이프라인을 실행하지 않아 제로 다운타임을 검증하지 못하여 부분적으로 성공했습니다.
- 후속 이슈:
2020년 2월#
- 설명: 멀티 노드 구성에서 GitLab 12.7.5에서 최신 GitLab 12.8 패키지로 업그레이드를 테스트했습니다.
- 결과: 데모 중 루핑 파이프라인을 실행하지 않아 다운타임을 모니터링하지 못하여 부분적으로 성공했습니다.
2020년 1월#
- 설명: 멀티 노드 구성에서 GitLab 12.6.x에서 최신 GitLab 12.7 패키지로 업그레이드를 테스트했습니다.
- 결과: 업그레이드 테스트 성공.
- 후속 이슈:
- 설명: 멀티 노드 구성에서 GitLab 12.5.7에서 GitLab 12.6.6으로 업그레이드를 테스트했습니다.
- 결과: 업그레이드 테스트 성공.
- 후속 이슈: 제로 다운타임 업그레이드 설명서를 업데이트하여 배포 노드가 사용 중이지 않음을 확인.
- 설명: 멀티 노드 구성에서 GitLab 12.4.x에서 최신 GitLab 12.5 패키지로 업그레이드를 테스트했습니다.
- 결과: 업그레이드 테스트 성공.
- 후속 이슈:
2019년 10월#
- 설명: 멀티 노드 구성에서 GitLab 12.3.5에서 GitLab 12.4.1로 업그레이드를 테스트했습니다.
- 결과: 업그레이드 테스트 성공.
- 설명: GitLab 12.2.8에서 GitLab 12.3.5로 업그레이드를 테스트했습니다.
- 결과: 업그레이드 테스트 성공.
- 설명: GitLab 12.1.9에서 GitLab 12.2.8로 업그레이드를 테스트했습니다.
- 결과: 가능한 구성 문제로 인해 부분적으로 성공했습니다.
PostgreSQL 업그레이드#
다음은 수행한 PostgreSQL 업그레이드 유효성 검사 테스트입니다.
2021년 9월#
- 설명: 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를 지원하기 위한 수정이 이루어진 후 Geo를 사용한 GitLab 새로 설치도 재테스트했습니다. 이 테스트는 GitLab 13.4의 야간 빌드를 사용하여 수행되었습니다.
- 결과: 기본 및 보조에 단일 데이터베이스 노드가 있는 Geo 배포의 경우 테스트가 성공했습니다. Geo 기본의 repmgr 및 Patroni 관리 PostgreSQL 클러스터에서 알려진 문제가 발생했습니다. 문제가 해결될 때까지 기본에 데이터베이스 클러스터가 있는 PostgreSQL 12 사용은 권장되지 않습니다.
- PostgreSQL 클러스터에 대한 알려진 문제:
2020년 8월#
- 설명: GitLab 13.3에서 PostgreSQL 12를 선택적 버전으로 제공하기 전에, PostgreSQL 12가 활성화되고 Geo가 설치된 GitLab 13.3의 새로운 설치를 테스트했습니다.
- 결과:
recovery.conf파일이 PostgreSQL 12에서 더 이상 지원되지 않기 때문에 Geo 보조 설정에 수동 개입이 필요했습니다. 적절한 변경이 Linux 패키지에 적용되고 검증될 때까지 PostgreSQL 12로 Geo를 배포하는 것을 권장하지 않습니다. - 후속 이슈:
2020년 4월#
Geo 설치를 위한 PostgreSQL 11 업그레이드 절차:
- 설명: GitLab 12.10에서 PostgreSQL 11을 PostgreSQL의 기본 버전으로 만들기 전에, GitLab 12.9의 Geo 배포에서 PostgreSQL 11로 업그레이드하는 것을 테스트했습니다.
- 결과: 부분적으로 성공했습니다. 별도의 추적 데이터베이스가 있는 멀티 노드 구성에서 문제가 발견되었으며 Geo가 활성화된 경우 자동 업그레이드를 허용하는 것에 대한 우려가 제기되었습니다.
- 후속 이슈:
- 설명: GitLab 12.10에서 PostgreSQL 11을 PostgreSQL의 기본 버전으로 만들기 전에, PostgreSQL 11이 설치된 Geo를 사용한 GitLab 12.9의 새 설치를 테스트했습니다.
- 결과: 설치 테스트 성공.
2019년 9월#
Geo를 위한 PostgreSQL 10.0 업그레이드 테스트 및 검증:
- 설명: 12.0 릴리스와 함께 GitLab은 PostgreSQL 10.0으로의 업그레이드를 요구했습니다. GitLab 12.1.8까지의 다양한 업그레이드 시나리오를 테스트했습니다.
- 결과: 업그레이드 시 여러 문제가 발견되었으며 후속 이슈에서 처리되었습니다.
- 후속 이슈:
오브젝트 스토리지 복제 테스트#
다음은 수행한 추가 유효성 검사 테스트입니다.
2022년 4월#
AWS 기반 오브젝트 스토리지를 사용한 오브젝트 스토리지 복제 검증:
- 설명: AWS 기반 오브젝트 스토리지 복제와 GitLab 기반 오브젝트 스토리지 복제를 사용할 때 단일 이미지가 기본 오브젝트 스토리지 위치에서 보조로 복제되는 데 걸리는 평균 시간을 테스트했습니다. 60초 동안 매초 기본 사이트의 프로젝트에 1MB 이미지를 업로드하는 방식으로 테스트했습니다. 그런 다음 보조 사이트에서 이미지가 사용 가능해질 때까지의 시간을 측정했습니다. Ruby 스크립트를 사용하여 달성했습니다.
- 결과: AWS 관리 복제를 사용하면 사이트 간 이미지 복제 평균 시간은 약 49초이며, 사이트가 동일한 지역에 있을 때와 더 멀리 있을 때(유럽에서 미국) 동일합니다. 동일 지역에서 Geo 관리 복제를 사용하면 복제 평균 시간이 5초에 불과했지만, 교차 지역 복제 시 평균 시간은 33초로 증가했습니다.
GCP 기반 오브젝트 스토리지를 사용한 오브젝트 스토리지 복제 검증:
- 설명: GCP 기반 오브젝트 스토리지 복제와 GitLab 기반 오브젝트 스토리지 복제를 사용할 때 단일 이미지가 기본 오브젝트 스토리지 위치에서 보조로 복제되는 데 걸리는 평균 시간을 테스트했습니다. 60초 동안 매초 기본 사이트의 프로젝트에 1MB 이미지를 업로드하는 방식으로 테스트했습니다. 그런 다음 보조 사이트에서 이미지가 사용 가능해질 때까지의 시간을 측정했습니다. Ruby 스크립트를 사용하여 달성했습니다.
- 결과: GCP는 다른 클라우드 제공업체와 다르게 복제를 처리합니다. GCP에서는 멀티, 듀얼 또는 단일 지역 기반의 단일 버킷을 생성하는 프로세스입니다. 이는 버킷이 선택한 옵션에 따라 지역의 복제본을 자동으로 저장함을 의미합니다. 멀티 지역을 사용하더라도 미국, 유럽 또는 아시아와 같은 옵션으로 단일 대륙 내에서만 복제됩니다. 현재 GCP 기반 복제를 사용하여 대륙 간에 오브젝트를 복제하는 방법이 없는 것 같습니다. Geo 관리 복제의 경우 동일 지역에서 복제하는 평균 시간은 6초이고 교차 지역 복제 시 9초로 증가했습니다.
2022년 1월#
Azure 기반 오브젝트 스토리지를 사용한 오브젝트 스토리지 복제 검증:
- 설명: Azure 기반 오브젝트 스토리지 복제와 GitLab 기반 오브젝트 스토리지 복제를 사용할 때 단일 이미지가 기본 오브젝트 스토리지 위치에서 보조로 복제되는 데 걸리는 평균 시간을 테스트했습니다. 60초 동안 매초 기본 사이트의 프로젝트에 1MB 이미지를 업로드하는 방식으로 테스트했습니다. 그런 다음 보조 사이트에서 이미지가 사용 가능해질 때까지의 시간을 측정했습니다. Ruby 스크립트를 사용하여 달성했습니다.
- 결과: Azure 기반 복제를 사용하면 기본 오브젝트 스토리지에서 보조로 이미지가 복제되는 평균 시간은 40초이며, 가장 긴 복제 시간은 70초이고 가장 빠른 시간은 11초였습니다. GitLab 기반 복제를 사용하면 복제 완료 평균 시간은 5초이며, 가장 긴 복제 시간은 10초이고 가장 빠른 시간은 3초였습니다.
- 후속 이슈:
2021년 5월#
오브젝트 스토리지 복제가 활성화된 상태에서 장애 복구 테스트:
- 설명: 테스트 당시 Geo의 오브젝트 스토리지 복제 기능은 베타 단계였습니다. 오브젝트 스토리지 복제가 의도한 대로 작동하고 장애 복구 후 새 기본에 데이터가 있는지 테스트했습니다.
- 결과: 테스트 성공. 오브젝트 스토리지의 데이터가 복제되었으며 장애 복구 후에도 존재했습니다.
- 후속 이슈:
기타 테스트#
2020년 8월#
- 설명: 기본 및 보조 Geo 사이트 모두에 Gitaly 클러스터가 구성된 Geo 배포를 테스트했습니다. 기본 Geo 사이트에서 자동 Gitaly 클러스터 장애 복구를 트리거하고 엔드투엔드 Geo 테스트를 실행했습니다. 그런 다음 보조 Geo 사이트에서 Gitaly 클러스터 장애 복구를 트리거하고 엔드투엔드 Geo 테스트를 다시 실행했습니다.
- 결과: 기본 사이트의 Gitaly 클러스터 장애 복구 전후 및 보조 사이트의 Gitaly 클러스터 장애 복구 전후 엔드투엔드 테스트 성공.