2019년 12월 12일 ObjectRocket.com/blog에서 최초 게시
연말연시가 다가오고 있으며 이번 시즌은 Rackspace ObjectRocket 역사에서 중요한 이정표의 1주년을 기념합니다. 2019년 휴가 시즌에 맞춰 고가용성을 도입했습니다. (HA) ObjectRocket PostgreSQL® 서비스. ObjectRocket에서 제공하는 모든 데이터 저장소는 프로덕션 워크로드용으로 구축되어 모든 고객에게 HA가 필요합니다.
HA가 왜 중요한가요?
HA라는 용어가 HA가 왜 중요한지 간단히 살펴보겠습니다. 무엇보다도 HA의 세 가지 주요 이점은 다음과 같습니다.
- 다운타임 0 또는 대폭 감소
- 데이터 손실 방지
- 데이터베이스 성능 향상
데이터 저장소와 사용 가능한 여러 기술에서 HA를 구현하는 몇 가지 방법이 있습니다. 그러나 거의 모든 HA 솔루션의 핵심 구성 요소는 데이터 복제본입니다. 즉, 하나의 데이터 세트 또는 데이터베이스만 표시되지만 배후에는 해당 데이터의 정확한 복제본(사본)이 하나 이상 있습니다. 기본 데이터베이스인 경우 기본 , 대부분의 복제 구성표에서 하드웨어 오류, 소프트웨어 오류 또는 손상과 같은 문제가 발생하면 복제본이 마스터를 대체할 수 있습니다. 마지막 요점은 대부분의 HA 시스템의 두 번째 주요 구성 요소인 자동화된 장애 조치 메커니즘(다른 체계에서는 승격 또는 선택)을 다룹니다. 복제는 데이터의 여러 사용 가능한 정상 복사본을 보장합니다. 그러나 다음을 수행할 준비도 되어 있어야 합니다.
- 기본에서 예기치 않은 문제를 감지합니다.
- 기본으로 승격할 적절한 복제본을 선택하십시오.
- 고장난 기본 복제본을 복구하고 새 복제본을 생성합니다(승격한 복제본을 대체하기 위해).
때로는 두 번째 구성 요소와 결합되는 마지막 구성 요소는 요청을 올바른 노드로 라우팅하는 장치입니다. 데이터 쓰기를 위해 애플리케이션을 기본(모범 사례)으로 지정하고 해당 기본이 실패하면 애플리케이션은 새로 승격된 기본을 가리키지 않습니다. 이 문제를 해결하는 방법은 여러 가지가 있지만 가장 널리 사용되는 방법은 프록시 또는 로드 밸런서를 사용하는 것입니다. 애플리케이션이 프록시 또는 로드 밸런서를 가리키도록 하면 애플리케이션이 데이터베이스를 직접 가리키지 않고 트래픽을 보낼 올바른 위치를 결정합니다. 서버.
이 모든 것을 하나로 묶기 위해 자동 장애 조치 시스템과 프록시/로드 밸런서는 장애 조치가 발생할 때 함께 작동합니다. 새 마스터를 승격하면 프록시 또는 로드 밸런서가 트래픽을 새 마스터로 보냅니다. 애플리케이션에서 변경되는 사항은 없으며 프로모션 중 응답이 일시적으로 표시되지 않는 것 외에 애플리케이션은 프로모션이 발생했음을 알 필요도 없습니다. 이것은 기본 구성 요소를 다루는 프로세스의 상위 수준 개요입니다. 이제 솔루션의 각 구성 요소에 사용하는 기술에 대해 알아보겠습니다.
우리가 사용하는 기술
이제 주요 구성 요소를 검토했으므로 이전 구성 요소 각각을 제공하는 방법에 대해 자세히 알아보겠습니다.
복제
Postgres는 기본적으로 많은 복제 체계를 지원합니다. 현재 하나 또는 두 개의 복제본을 구성할 수 있지만 향후 옵션을 확장할 예정입니다. 복제의 또 다른 좋은 점은 동기식 개념입니다. 및 비동기 복제. 동기 복제를 사용하면 기본이 쓰기가 완료된 것으로 간주하기 전에 기본이 각 복제본에서 쓰기가 완료되었는지 확인하기를 기다립니다. 비동기식에서 기본은 복제본에 대한 쓰기를 실행하지만 애플리케이션 또는 클라이언트 쓰기를 확인하기 전에 완료를 확인하지 않습니다. 우리가 사용하는 솔루션을 통해 비동기 및 동기 복제를 모두 지원할 수 있습니다. 기본적으로 동기 복제를 활성화하고 기본 및 최소 하나의 복제본에 미리 쓰기 로그(WAL)에 쓰기가 기록되었는지 확인하도록 환경에서 복제를 구성합니다. 트랜잭션 또는 세션별로 설정을 변경할 수 있습니다.
장애 조치 및 승격
장애 조치 및 승격 기능을 제공하는 여러 오픈 소스 및 타사 도구가 있지만 우리는 Patroni를 선택했습니다. 다음과 같은 우수한 특성 때문에:
- 네이티브 Kubernetes® 지원: 우리는 Kubernetes를 기반으로 하는 새로운 플랫폼을 기반으로 하므로 다른 상태 또는 합의 메커니즘이 필요 없이 Kubernetes에 플러그인하는 도구를 채택할 수 있습니다. 이 옵션이 핵심입니다.
- 활발한 개발 및 커뮤니티: Patroni 주변의 커뮤니티는 매우 활동적이며 기능이 성장함에 따라 협업하고 자체 추가 사항에 기여할 수 있습니다. 또한 회의 대화 및 문서에서 Zalando의 운영자 예제에 이르기까지 많은 리소스가 있습니다. , 기술을 배우는 데 도움이 됩니다.
- 간단한 아키텍처: 사용 가능한 다른 많은 도구에는 로드 밸런싱 및 기본 승격을 처리하기 위해 Postgres 인스턴스 외부의 전용 리소스가 필요합니다. Patroni는 Postgres를 둘러싸고 기본 Kubernetes 구성 요소를 사용하여 다른 기능을 처리하므로 HA에 추가 리소스를 할당하지 않았습니다.
마일리지는 다를 수 있지만 Patroni는 우리 환경에 맞게 구성하고 유지 관리하기가 매우 쉽다는 것을 알았습니다. 기본적으로 Patroni가 노드가 속한 HA 그룹을 알려주면 나머지는 알아서 처리합니다. 복제를 구성하고, 실패한 기본 서버를 감지하고, 복제본을 승격하고, 새 복제본을 생성하고, 프로세스의 마지막 부분에서 Kubernetes와도 작동합니다.
요청 라우팅
마지막으로 Patroni와 서비스라고 하는 기본 Kubernetes 구성 , 퍼즐의 마지막 조각을 나타냅니다. Kubernetes의 서비스는 컨테이너 그룹(포드)의 레이블을 기반으로 트래픽을 라우팅하는 프록시처럼 작동합니다. Patroni는 activeprimary에 마스터라는 레이블을 지정합니다. 레이블이 지정되고 Kubernetes는 마스터 레이블이 있는 팟(Pod)으로만 데이터베이스 트래픽 라우팅을 처리합니다. 높은 수준의 설명을 기억하지만 실제로는 그렇게 작동합니다. 이 프로세스는 데이터베이스 읽기 요청을 복제본으로 라우팅하는 보조 포트를 제공하도록 확장될 수도 있습니다(기본 로드를 줄이기 위해).
현재 사용 중인 기술에 대한 간략한 설명이지만 더 자세한 내용을 듣고 싶다면 알려주십시오. 우리는 고객과 상점에 대해 이야기하는 것을 좋아합니다.
지금 사용해 보세요!
인스턴스 만들기 Mission Control의 화면 2단계 아래에 인스턴스 사용자 지정이라는 섹션이 있습니다. . 여기에서 상자를 클릭하여 화살표를 녹색으로 바꾸면 PostgreSQL 인스턴스의 HA 복제본이 추가됩니다. 오른쪽 상단의 줄임표(…)를 클릭하여 복제본 수(1개 또는 2개)를 선택할 수도 있습니다.
기본적으로 2개의 복제본을 사용하는 것이 좋으므로 정전 중에도 중복이 있지만 하나만 선택할 수 있습니다.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 영업 채팅을 클릭할 수도 있습니다. 지금 채팅하고 대화를 시작하세요.