번들된 PgBouncer 서비스 사용하기

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

PgBouncer는 장애 조치 시나리오에서 서버간 데이터베이스 연결을 원활하게 마이그레이션하는 데 사용됩니다. 또한, 비 장애 허용 설정에서 연결을 풀링하여 응답 시간을 단축하고 리소스 사용량을 줄일 수 있습니다.

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

장애 허용 GitLab 설치 일부로서의 PgBouncer

이 콘텐츠는 새 위치로 이동되었습니다.

비-장애 허용 GitLab 설치 일부로서의 PgBouncer

  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을 실행하여 다시 시작해야 합니다.

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

    pgbouncer['enable'] = true
pgbouncer['databases'] = {
  gitlabhq_production: {
    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 서버 노드의 주소로 교체
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;
        name         |   host    | port |      database       | force_user | pool_size | ...
---------------------+-----------+------+---------------------+------------+-----------+---

PgBouncer 우회 절차

Linux 패키지 설치

일부 데이터베이스 변경 사항은 PgBouncer를 통해 직접 수행해야 합니다.

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

  1. 주(primary) 노드를 찾으려면 데이터베이스 노드에서 다음을 실행합니다: 

    sudo gitlab-ctl patroni members

  2. 작업을 수행하는 응용 프로그램 노드의 /etc/gitlab/gitlab.rb를 편집하고, 데이터베이스 primary의 호스트 및 포트로 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 컨테이너에서 수행됩니다.
  • 마이그레이션 작업은 migrations 컨테이너에서 수행됩니다.

각 서브차트에서 PostgreSQL 포트를 재정의하여 이러한 작업을 실행하고 PostgreSQL에 직접 연결할 수 있어야합니다:

세밀한 조정

PgBouncer의 기본 설정은 대부분의 설치에 적합합니다. 특정 경우에는 데이터베이스에서 메모리 고갈을 일으킬 수 있는 리소스 및 성능과 관련된 변수를 변경하고 처리량을 늘리거나 제한해야 할 수 있습니다.

Linux 패키지 설치의 경우 및 해당 기본값은 아래와 같습니다. 관련 문서는 공식 PgBouncer 문서에서 찾을 수 있습니다:

  • 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의 제한을 설정할 때는 sporadically만 데이터베이스에 액세스하기 때문에 puma를 무시할 수 있습니다.

문제 해결

PgBouncer를 통해 연결하는 중 문제가 발생하는 경우 항상 로그를 확인할 곳은 다음과 같습니다: 

sudo gitlab-ctl tail pgbouncer

추가로, 관리 콘솔에서 show databases의 결과를 확인할 수 있습니다. 결과에서 gitlabhq_production 데이터베이스의 host 필드에 값이 표시될 것으로 예상됩니다. 또한, current_connections는 1보다 커야합니다.

메시지: LOG: invalid CIDR mask in address

해당 문제의 권장 해결 방법은 Geo 문서에 있습니다.

메시지: LOG: invalid IP mask "md5": Name or service not known

해당 문제의 권장 해결 방법은 Geo 문서에 있습니다.