번들로 제공되는 PgBouncer 서비스 사용하기

Tier: Free, Premium, Ultimate Offering: Self-managed
note
PgBouncer는 gitlab-ee 패키지에 포함되어 있지만 자유롭게 사용할 수 있습니다.
지원 받으려면 프리미엄 구독이 필요합니다.

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

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

장애 내성이 있는 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: '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 파일을 생성하거나 편집하고 다음 구성을 추가합니다:

    # Prometheus를 위한 서비스 검색 활성화
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 | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-----------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | 127.0.0.1 | 5432 | gitlabhq_production |            |       100 |            5 |           |               0 |                   1
 pgbouncer           |           | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)

 type |   user    |      database       | state  |   addr    | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link
| remote_pid | tls
------+-----------+---------------------+--------+-----------+-------+------------+------------+---------------------+---------------------+-----------+------
+------------+-----
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44590 | 127.0.0.1  |       6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12444c0 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44592 | 127.0.0.1  |       6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x12447c0 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44594 | 127.0.0.1  |       6432 | 2018-04-24 22:13:10 | 2018-04-24 22:17:10 | 0x1244940 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44706 | 127.0.0.1  |       6432 | 2018-04-24 22:14:22 | 2018-04-24 22:16:31 | 0x1244ac0 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44708 | 127.0.0.1  |       6432 | 2018-04-24 22:14:22 | 2018-04-24 22:15:15 | 0x1244c40 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44794 | 127.0.0.1  |       6432 | 2018-04-24 22:15:15 | 2018-04-24 22:15:15 | 0x1244dc0 |
|          0 |
 C    | gitlab    | gitlabhq_production | active | 127.0.0.1 | 44798 | 127.0.0.1  |       6432 | 2018-04-24 22:15:15 | 2018-04-24 22:16:31 | 0x1244f40 |
|          0 |
 C    | pgbouncer | pgbouncer           | active | 127.0.0.1 | 44660 | 127.0.0.1  |       6432 | 2018-04-24 22:13:51 | 2018-04-24 22:17:12 | 0x1244640 |
|          0 |
(8 rows)

 type |  user  |      database       | state |   addr    | port | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | rem
ote_pid | tls
------+--------+---------------------+-------+-----------+------+------------+------------+---------------------+---------------------+-----------+------+----
--------+-----
 S    | gitlab | gitlabhq_production | idle  | 127.0.0.1 | 5432 | 127.0.0.1  |      35646 | 2018-04-24 22:15:15 | 2018-04-24 22:17:10 | 0x124dca0 |      |
  19980 |
(1 row)

PgBouncer 우회 절차

리눅스 패키지 설치

일부 데이터베이스 변경은 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 차트 설치

고가용성 배포 역시 리눅스 패키지 기반 배포와 같은 이유로 PgBouncer를 우회해야 합니다.

Helm 차트 설치의 경우:

  • 데이터베이스 백업 및 복원 작업은 툴박스 컨테이너에 의해 수행됩니다.

  • 마이그레이션 작업은 마이그레이션 컨테이너에 의해 수행됩니다.

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

미세 조정

PgBouncer의 기본 설정은 대다수의 설치에 적합합니다.

특정 경우에는 가능한 처리량을 늘리거나 데이터베이스에서 메모리 소진을 유발할 수 있는 리소스 사용을 제한하기 위해 성능 및 리소스 관련 변수를 변경하고 싶을 수 있습니다.

매개변수와 해당 문서는 공식 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 Tracking Database를 가리키는 PgBouncer의 한계를 설정할 때, 그 데이터베이스에 간헐적으로만 접근하기 때문에 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 문서를 참조하세요.