제로 다운타임으로 멀티 노드 인스턴스 업그레이드

멀티 노드 Linux 패키지 기반 인스턴스를 제로 다운타임으로 업그레이드하는 방법을 설명합니다.

멀티 노드 GitLab 환경을 제로 다운타임으로 업그레이드하는 과정은 업그레이드 순서 에 따라 각 노드를 순차적으로 거치는 방식으로 진행됩니다. 로드 밸런서와 HA 메커니즘이 각 노드가 다운되는 상황을 그에 맞게 처리합니다. 제로 다운타임 업그레이드를 시작하기 전에 다운타임 옵션을 검토합니다 . 시작하기 전에 # 업그레이드 과정에서 제로 다운타임을 달성하는 것은 분산 애플리케이션이라면 어디서든 특히 어려운 일입니다. 이 문서 는 당사의 HA 참조 아키텍처 를 대상으로 주어진 그대로 테스트되었으며, 실질적으로 관측 가능한 다운타임 없이 완료되었습니다. 다만 구체적인 시스템 구성에 따라 결과는 달라질 수 있다는 점에 유의합니다. 추가적인 확신을 얻기 위해 일부 고객은 특정 로드 밸런서나 인프라 기능을 사용해 노드를 수동으로 드레인하는 등의 추가 기법으로 성공을 거두기도 했습니다. 이러한 기법은 기반 인프라 기능에 크게 좌우됩니다. 추가 정보가 필요하면 GitLab 담당자 또는 지원 팀 에 문의합니다. 요구 사항 # 제로 다운타임 업그레이드 프로세스를 수행하려면 Linux 패키지로 구축된 멀티 노드 GitLab 환경에 다음과 같이 로드 밸런싱과 사용 가능한 HA 메커니즘이 구성되어 있어야 합니다. GitLab 애플리케이션 노드용 외부 로드 밸런서가 구성되어 있고, readiness ( /-/readiness ) 엔드포인트에 대한 상태 확인이 활성화되어 있어야 합니다. PgBouncer와 Praefect 컴포넌트용 내부 로드 밸런서가 구성되어 있고 TCP 상태 확인이 활성화되어 있어야 합니다. Consul, Postgres, Redis 컴포넌트가 있다면 HA 메커니즘이 구성되어 있어야 합니다. 이 컴포넌트 중 HA 방식으로 배포되지 않은 것이 있다면 다운타임을 두고 별도로 업그레이드해야 합니다. 데이터베이스의 경우 Linux 패키지는 기본 GitLab 데이터베이스에 한해서만 HA를 지원합니다 . Praefect 데이터베이스 와 같은 다른 데이터베이스의 경우 HA를 달성하고 다운타임을 피하려면 서드 파티 데이터베이스 솔루션이 필요합니다. 제로 다운타임 업그레이드를 수행하려면 다음을 지켜야 합니다. 마이너 릴리스를 한 번에 하나씩만 업그레이드합니다. 즉 16.1 에서 16.2 로 이동하며, 16.3 으로 바로 이동하지 않습니다. 릴리스를 건너뛰면 데이터베이스 수정 사항이 잘못된 순서로 실행되어 데이터베이스 스키마가 손상된 상태로 남을 수 있습니다 . 배포 후 마이그레이션(post-deployment migrations)을 사용합니다. 고려 사항 # 제로 다운타임 업그레이드를 고려할 때는 다음 사항에 유의합니다. 대부분의 경우 패치 릴리스가 최신 버전이 아니더라도 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어 16.3.3 이 릴리스된 이후라도 16.3.2 에서 16.4.1 로 업그레이드하는 것은 안전해야 합니다. 업그레이드 경로 에 해당하는 버전별 업그레이드 노트 를 확인하고 필요한 업그레이드 정지 지점이 있는지 확인해야 합니다