번들된 PgBouncer 서비스 사용하기

Tier: Free, Premium, Ultimate Offering: Self-Managed
note
PgBouncer는 gitlab-ee 패키지에 번들되어 있지만 무료로 사용할 수 있습니다. 지원을 받으려면 프리미엄 구독이 필요합니다.

PgBouncer는 장애 조치 시 서버 간 데이터베이스 연결을 신속하게 마이그레이션하는 데 사용됩니다. 또한, 자원 사용량을 줄이면서 응답 시간을 단축하기 위해 장애 허용 설정이 아닌 환경에서 연결을 풀하는 데 사용할 수 있습니다.

GitLab 프리미엄에는 /etc/gitlab/gitlab.rb를 통해 관리할 수 있는 PgBouncer의 번들 버전이 포함되어 있습니다.

PgBouncer를 장애 허용 GitLab 설치의 일부로 사용하기

이 내용은 새 위치로 이동되었습니다.

PgBouncer를 장애 허용되지 않은 GitLab 설치의 일부로 사용하기

  1. gitlab-ctl pg-password-md5 pgbouncer 명령으로 PGBOUNCER_USER_PASSWORD_HASH를 생성합니다.

  2. gitlab-ctl pg-password-md5 gitlab 명령으로 SQL_USER_PASSWORD_HASH를 생성합니다. 나중에 평문 SQL_USER_PASSWORD를 입력합니다.

  3. 데이터베이스 노드에서 /etc/gitlab/gitlab.rb에 다음이 설정되어 있는지 확인합니다. 

    postgresql['pgbouncer_user_password'] = 'PGBOUNCER_USER_PASSWORD_HASH'
postgresql['sql_user_password'] = 'SQL_USER_PASSWORD_HASH'
postgresql['listen_address'] = 'XX.XX.XX.Y' # XX.XX.XX.Y는 postgresql이 수신해야 하는 노드의 IP 주소입니다.
postgresql['md5_auth_cidr_addresses'] = %w(AA.AA.AA.B/32) # AA.AA.AA.B가 pgbouncer 노드의 IP 주소인 경우입니다.

  4. gitlab-ctl reconfigure 명령을 실행합니다.

    note
    데이터베이스가 이미 실행 중인 경우 gitlab-ctl restart postgresql 명령으로 reconfigure 후에 다시 시작해야 합니다.

  5. PgBouncer를 실행하는 노드에서 /etc/gitlab/gitlab.rb에 다음이 설정되어 있는지 확인합니다. 

    pgbouncer['enable'] = true
pgbouncer['databases'] = {
  gitlabhq_production: {
    host: 'DATABASE_HOST',
    user: 'pgbouncer',
    password: 'PGBOUNCER_USER_PASSWORD_HASH'
  }
}

    각 데이터베이스에 대해 추가 구성 매개변수를 전달할 수 있습니다. 

    pgbouncer['databases'] = {
  gitlabhq_production: {
     ...
     pool_mode: 'transaction'
  }
}

    이러한 매개변수를 사용할 때 주의하세요. 매개변수의 전체 목록은 PgBouncer 문서를 참조하세요.

  6. gitlab-ctl reconfigure 명령을 실행합니다.

  7. Puma를 실행하는 노드에서 /etc/gitlab/gitlab.rb에 다음이 설정되어 있는지 확인합니다. 

    gitlab_rails['db_host'] = 'PGBOUNCER_HOST'
gitlab_rails['db_port'] = '6432'
gitlab_rails['db_password'] = 'SQL_USER_PASSWORD'

  8. gitlab-ctl reconfigure 명령을 실행합니다.

  9. 이 시점에서 인스턴스가 데이터베이스에 PgBouncer를 통해 연결해야 합니다. 문제가 발생하는 경우 문제 해결 섹션을 참조하세요.

백업

PgBouncer 연결을 통해 GitLab을 백업하거나 복원하지 마세요. GitLab 장애를 유발합니다.

이와 관련한 자세한 내용 및 백업 재구성 방법에 대해 더 알아보세요.

모니터링 활성화

모니터링을 활성화하려면 모든 PgBouncer 서버에서 활성화해야 합니다.

  1. /etc/gitlab/gitlab.rb을 생성/편집하고 다음 구성을 추가합니다. 

    # 프로메테우스를 위한 서비스 디스커버리 활성화
consul['enable'] = true
consul['monitoring_service_discovery'] =  true

# 자리 표시자 치환
# Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z
# 위와 같이 콘술 서버 노드 주소로 대체하세요
consul['configuration'] = {
   retry_join: %w(Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z),
}

# 수집기가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

  2. 구성을 컴파일하려면 sudo gitlab-ctl reconfigure를 실행하세요.

관리 콘솔

Linux 패키지 설치에서는 PgBouncer 관리 콘솔에 자동으로 연결하는 명령이 제공됩니다. 자세한 지침은 PgBouncer 설명서를 참조하십시오.

세션을 시작하려면 다음을 실행하고 pgbouncer 사용자의 암호를 제공하십시오. 

sudo gitlab-ctl pgb-console

인스턴스에 대한 기본 정보를 얻으려면: 

pgbouncer=# show databases; show clients; show servers;

PgBouncer 우회 절차

Linux 패키지 설치

일부 데이터베이스 변경은 PgBouncer를 통하지 않고 직접 수행해야 합니다.

주로 영향을 받는 작업은 데이터베이스 복원과 데이터베이스 마이그레이션을 사용한 GitLab 업그레이드입니다.

  1. 주 데이터베이스 노드에서 다음을 실행하여 기본 노드를 찾습니다: 

    sudo gitlab-ctl patroni members

  2. 작업을 수행하는 응용프로그램 노드의 /etc/gitlab/gitlab.rb를 편집하고, 데이터베이스 주요 호스트 및 포트로 gitlab_rails['db_host'] 및 gitlab_rails['db_port']를 업데이트합니다.

  3. 다시 구성을 실행합니다: 

    sudo gitlab-ctl reconfigure

위 작업이나 절차를 수행한 후에는 PgBouncer를 사용하도록 전환합니다:

  1. /etc/gitlab/gitlab.rb을 다시 PgBouncer를 가리키도록 변경합니다.

  2. 다시 구성을 실행합니다: 

    sudo gitlab-ctl reconfigure

Helm 차트 설치

고가용성 배포는 Linux 패키지 기반과 동일한 이유로 PgBouncer를 우회해야 합니다. Helm 차트 설치의 경우:

  • 데이터베이스 백업 및 복원 작업은 toolbox 컨테이너에서 수행됩니다.
  • 마이그레이션 작업은 마이그레이션 컨테이너에서 수행됩니다.

각 서브차트에서 PostgreSQL 포트를 재정의해야 합니다. 이렇게 하면 이러한 작업이 직접적으로 PostgreSQL에 연결되어 실행될 수 있습니다:

세밀한 조정

PgBouncer의 기본 설정은 대부분의 설치에 적합합니다. 특정 경우에는 성능별 및 리소스별 변수를 변경하여 처리량을 증가시키거나 데이터베이스에서 메모리 고갈을 유발할 수 있는 리소스 이용을 제한하고 싶을 수 있습니다.

이러한 매개변수와 관련된 설명은 공식 PgBouncer 문서에서 찾을 수 있습니다. 아래는 Linux 패키지 설치의 가장 관련성 있는 기본값과 해당 기본값 목록입니다:

  • pgbouncer['max_client_conn'] (기본값: 2048, 서버 파일 기술자 제한에 따라 다름) 이것은 PgBouncer의 “프론트엔드” 풀로, Rails에서 PgBouncer로의 연결을 나타냅니다.
  • pgbouncer['default_pool_size'] (기본값: 100) 이것은 PgBouncer의 “백엔드” 풀로, PgBouncer에서 데이터베이스로의 연결을 나타냅니다.

default_pool_size에 대한 이상적인 숫자는 데이터베이스 풀 크기를 정의하는 데 충분해야 합니다. 아래에 나열된 각 서비스는 다음과 같은 공식을 사용하여 데이터베이스 풀 크기를 정의합니다:

  • puma : max_threads + headroom (기본값 14)
    • max_threads는 gitlab['puma']['max_threads']를 통해 구성됩니다 (기본값: 4)
    • headroom는 DB_POOL_HEADROOM 환경 변수를 통해 구성할 수 있습니다 (기본값은 10입니다)
  • sidekiq : max_concurrency + 1 + headroom (기본값: 31)
    • max_concurrency는 sidekiq['max_concurrency']를 통해 구성됩니다 (기본값: 20)
    • headroom는 DB_POOL_HEADROOM 환경 변수를 통해 구성할 수 있습니다 (기본값은 10입니다)
  • geo-logcursor: 1+headroom (기본값: 11)
    • headroom는 DB_POOL_HEADROOM 환경 변수를 통해 구성할 수 있습니다 (기본값은 10입니다)

default_pool_size를 계산하려면 puma, sidekiq 및 geo-logcursor의 인스턴스 수를 각각 위에 나열된 대로 소비하는 연결 수로 곱합니다. 합계가 제안된 default_pool_size입니다.

내부 로드 밸런서로 두 개 이상의 PgBouncer를 사용하는 경우, 인스턴스 수로 default_pool_size를 나눌 수 있어 균일하게 분산된 부하를 보장할 수도 있습니다.

pgbouncer['max_client_conn']은 PgBouncer가 수락할 수 있는 연결의 하드 제한입니다. 이것을 변경할 필요가 거의 없습니다. 해당 제한에 도달하는 경우 내부 로드 밸런서가 있는 추가 PgBouncer를 추가하는 것을 고려해볼 수 있습니다.

Geo 추적 데이터베이스를 가리키는 PgBouncer의 제한을 설정할 때, 일시적으로 해당 데이터베이스에만 액세스하는 것이기 때문에 일반적으로 puma를 고려하지 않아도 될 것입니다.

문제 해결

PgBouncer를 통해 연결하는 동안 어떠한 문제가 발생하는 경우, 항상 로그를 확인하는 것이 가장 중요합니다: 

sudo gitlab-ctl tail pgbouncer

추가로, 관리 콘솔에서 show databases의 출력을 확인할 수 있습니다. 출력에서는 gitlabhq_production 데이터베이스의 host 필드에 값을 예상하고, current_connections이 1보다 커야 합니다.

메시지: LOG: 주소에서 유효하지 않은 CIDR 마스크

제안된 해결 방법은 Geo 문서에서 확인하세요.

메시지: LOG: "md5"에서 유효하지 않은 IP 마스크: 이름 또는 서비스를 알 수 없음

제안된 해결 방법은 Geo 문서에서 확인하세요.