InfoGrab DocsInfoGrab Docs

데이터베이스 로드 밸런싱

데이터베이스 로드 밸런싱에 대해 설명합니다.

데이터베이스 로드 밸런싱을 사용하면 읽기 쿼리가 여러 PostgreSQL 노드로 분산되어 성능이 향상되고 기본 데이터베이스의 부하가 줄어듭니다. 쓰기 작업은 항상 기본 노드에서 실행됩니다. GitLab 이 쿼리 라우팅을 자동으로 처리하므로 외부 로드 밸런서가 필요하지 않습니다. 요구 사항 # 데이터베이스 로드 밸런싱을 활성화하려면 다음 조건을 충족해야 합니다. PostgreSQL에 기본 노드를 복제하는 보조 노드가 하나 이상 있어야 합니다. 각 노드는 동일한 포트와 동일한 자격 증명으로 접근할 수 있어야 합니다. 외부 데이터베이스 서비스에는 db_load_balancing 구성만 있으면 됩니다. 연결 풀링은 규모가 커질 때 연결 수를 관리하는 데 도움이 되지만, 적절한 방식은 공급자에 따라 다르며 이 가이드의 범위를 벗어납니다. 연결 관리 지침은 연결 풀링 을 참고합니다. Note AWS RDS Proxy 는 GitLab과 함께 사용하도록 검증되지 않았습니다. Linux 패키지 설치에서는 데이터베이스 로드 밸런싱을 활성화하기 전에 다중 노드 HA PostgreSQL을 구성해야 합니다. 자세한 내용은 다중 노드 구성 을 참고합니다. 복제본 수 # 복제본 수에는 제한이 없습니다. 실무에서는 세 개로 시작하는 경우가 많으며, 특히 가용 영역 세 곳에 분산된 환경에서 그렇습니다. Consul과 Redis Sentinel을 비롯한 여러 GitLab 구성 요소는 쿼럼에 의존하며 홀수 개의 노드를 요구합니다. 데이터베이스 복제본 수를 이 패턴에 맞추면 아키텍처가 더 일관되고 재해 복구 범위가 넓어지며, 단일 가용 영역 장애의 영향이 줄어듭니다. 규모가 작은 환경은 복제본 두 개로 시작한 뒤 부하가 늘면 추가할 수 있습니다. 규모별 지침은 레퍼런스 아키텍처 문서 를 참고합니다. 데이터베이스 로드 밸런싱 구성 # 데이터베이스 로드 밸런싱은 다음 두 가지 방식 중 하나로 구성할 수 있습니다. 호스트 : PostgreSQL 호스트의 정적 목록입니다. 구성이 더 단순하며 대부분의 환경에 적합합니다. 서비스 디스커버리 : PostgreSQL 호스트 목록을 반환하는 DNS 레코드입니다. Consul을 사용하는 Linux 패키지 HA 구성처럼 복제본 목록이 동적으로 바뀔 때 사용합니다. 호스트 # 호스트 목록에 기본 노드를 포함할지는 선택 사항입니다. 포함하면 복제본과 함께 읽기 쿼리 대상이 되어 보조 노드의 전체 부하가 줄어듭니다. 기본 노드가 이미 지속적으로 높은 부하를 받고 있다면, 목록에서 빼서 쓰기 처리 용량을 확보합니다. 기본 노드는 이 목록에 포함되는지와 무관하게 언제나 쓰기 쿼리를 처리합니다. 호스트 목록을 구성하려면 분산 대상 환경의 모든 GitLab Rails 및 Sidekiq 노드에서 다음 단계를 수행합니다. /etc/gitlab/gitlab.rb 파일을 편집합니다. gitlab_rails['db_load_balancing'] 에 분산할 데이터베이스 호스트 배열을 만듭니다. 예를 들어 PostgreSQL 이 primary.example.com