Geo 유효성 검사 테스트
GitLab v19.5Tier: 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 패키지로 업그레이드하는 과정을 테스트했습니다.
- 결과: 데모 중 루핑 파이프라인을 실행하지 않아 제로 다운타임을 검증하지 못했으므로 부분적으로 성공했습니다.
- 후속 이슈:
- Puma에 배포 노드를 포함하는 방식 명확화
- 12.9.10으로 업그레이드한 후 MR 생성 실패 조사 오탐으로 종료되었습니다.
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 신규 설치를 테스트했습니다.
- 결과: PostgreSQL 12에서는
recovery.conf파일이 더 이상 지원되지 않아 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 사이트와 보조 Geo 사이트 모두에 Gitaly 클러스터를 구성한 Geo 배포를 테스트했습니다. 기본 Geo 사이트에서 자동 Gitaly 클러스터 장애 조치를 트리거하고 엔드투엔드 Geo 테스트를 실행했습니다. 이어서 보조 Geo 사이트에서 Gitaly 클러스터 장애 조치를 트리거하고 엔드투엔드 Geo 테스트를 다시 실행했습니다.
- 결과: 기본 사이트의 Gitaly 클러스터 장애 조치 전후, 그리고 보조 사이트의 Gitaly 클러스터 장애 조치 전후 모두 엔드투엔드 테스트에 성공했습니다.