메인 콘텐츠로 건너뛰기
블로그 데이터베이스 MySQL 및 MariaDB에 대한 갈레라 데이터베이스 참조 아키텍처

MySQL 및 MariaDB용 Galera 데이터베이스 레퍼런스 아키텍처

MySQL 헤더 이미지에 대한 갈레라 데이터베이스

응용 프로그램을 개발하기 전에 계획을 세우는 것이 좋습니다. 먼저 기본 비즈니스 목표를 정의하고, 요구 사항을 수집하고, 잠재적인 기술 스택을 평가하고, 통합을 이해하는 것으로 시작합니다. 프로세스가 끝나면 인프라구성 요소를 구현하기 위한 청사진 역할을 하고 해당 구성 요소 간에 데이터가 흐르는 방식을 정의하는 앱 참조 아키텍처의 개요가 있어야 합니다.

이 예제에서는 MySQL 및 MariaDB에 대한 Galera를 사용하여 데이터베이스 디자인을 검토하고 있습니다. 데이터베이스는 많은 응용 프로그램의 미션 크리티컬 구성 요소입니다. 이 귀중한 자산은 워크로드를 살리기 위해 중복성에 의존합니다. 단일 실패 지점은 비즈니스 운영, 가동 시간 계약 및 전체 사용자 경험에 부정적인 영향을 미칠 수 있습니다. 

참조 아키텍처를 가이드로 사용하여 비즈니스성장에 따라 가동 중지 시간 없이 가로로 확장되는 복원력 있는 데이터베이스 및 응용 프로그램 배포를 빌드할 수 있습니다.

참조 아키텍처란 무엇입니까?

참조 아키텍처는 솔루션을 구현하기 위한 일반적인 설계 원칙과 업계 모범 사례를 통합하는 재사용 가능한 기술 다이어그램입니다. 매우 추상화된 클라우드 참조 아키텍처는 다양한 컴퓨팅 인스턴스, 로드 밸런저, 스토리지, 소프트웨어 정의 네트워크 간의 연결을 묘사합니다.

데이터베이스 및 참조 아키텍처

주요 목표는 중복성을 추가하고 데이터베이스가 단일 실패 지점이 되는 것을 방지하는 것입니다. 응용 프로그램 및 워크로드 제약 조건에 따라 이 목표를 달성하는 방법에는 여러 가지가 있습니다. 예를 들어 응용 프로그램은 기본 보조 복제 모델에서 읽기 및 쓰기를 분할하여 더 잘 수행할 수 있습니다. 쓰기 작업을 확장해야 하려면 여러 프라이머리가 있는 전략이 필요합니다.

다른 고려 사항에는 데이터 볼륨, ACID 규정 준수, 장애 조치/선거 프로세스(수동 또는 자동), 예상 클라이언트 연결 수 및 선택한 데이터베이스 기술이 포함됩니다. 이러한 고려 사항은 데이터베이스 솔루션을 형성하고 참조 아키텍처에서 이러한 조각이 함께 작동하는 방식에 대한 더 큰 그림을 형성합니다.

갈레라 사용 시기

Galera는 관리가 간단하고 단일 클라우드 공급자에 의존하지 않는 무료 오픈 소스 고가용성 데이터베이스 솔루션입니다. 데이터베이스 기술이 MySQL이거나 MariaDB 또는 Percona와 같은 포크 중 하나인 경우 Galera를 내구성 있고 휴대용 솔루션으로 추천합니다.

갈레라 클러스터 의 장점

  • 노드 오류 - 노드 오류가 발생할 경우 기본 구성 요소를 선출하기 위해 가중치쿼 을 호출하여 분할 뇌 상태를 방지합니다.
  • 다중 주, 활성 활성 클러스터 - 클러스터의 모든 노드를 읽고 씁니다.
  • 데이터 일관성 – ACID 규정 준수를 보장하기 위해 인증 기반 동기 복제를 사용합니다.
  • 자동 노드 프로비저닝 – 실패한 노드가 복구되거나 새 노드가 클러스터에 가입하면 상태 스냅숏 전송(SST) 또는 증분 상태 전송(IST)을 사용하여 기본 구성 요소의 상태와 자동으로 동기화됩니다.

갈레라 클러스터 제한 사항

  • 마이삼 지원 없음- InnoDB 엔진만 지원합니다. 시스템 테이블을 비롯한 다른 테이블 형식에 대한 쓰기는 복제되지 않습니다.
  • 테이블 서식- 기본 키가 없는 테이블을 삭제하거나 적절하게 복제할 수 없습니다.
  • 로직 고려 사항- 명시적 테이블 잠금을 사용하지 않으려면 응용 프로그램 논리를 다시 작성해야 할 수 있습니다.
  • 확장성 작성- 모든 노드는 커밋하기 전에 쓸 수 있음을 증명해야 하므로 클러스터가 커지면 쓰기 성능이 저하됩니다. 클러스터 크기를 쿼럼과 최적의 쓰기 성능을 충분히 유지할 수 있도록 세 개의 노드로 유지하는 것이 좋습니다.

단일 실패 지점 제거

응용 프로그램 소프트웨어와 데이터베이스가 향후 스케일에 대비하여 다른 계산 인스턴스로 분리된 기존 LEMP 스택의 예를 살펴보겠습니다. 이러한 설정은 다음과 같이 보일 수 있습니다.

다이어그램: 애플리케이션 서버와 MySQL 데이터베이스 서버는 VLAN 를 사용하여 안전하게 연결됩니다.

우려의 분리는 모범 사례이며 확장성을 지원하는 데 확실히 도움이 됩니다. 그러나 중복성이 부족하면 데이터베이스와 응용 프로그램 서버모두 단일 오류 지점이 됩니다. 이러한 단일 실패 지점을 제거하고 전체 참조 아키텍처를 빌드하기 위해 이 구조를 개선할 수 있습니다.

VLAN 및 클라우드 방화벽을 사용한 간단한 Galera 클러스터 설정

Galera 클러스터는 데이터베이스 계층을 3개의 노드로 늘리고 노드 간에 동기 복제를 수행합니다. 리노드 VLAN 를 사용하여 공용 및 공유 사설 네트워크에서 복제 트래픽을 격리하고 Cloud Firewall 를 사용하여 VLAN 외부로부터의 액세스를 제한할 수 있습니다. Galera 노드는 유동 IP 주소를 공유하므로 한 노드가 실패하면 다른 노드가 모르는 애플리케이션 서버에 대한 요청을 대신 처리할 수 있습니다.

다이어그램: 애플리케이션 서버는 프로덕션 데이터베이스에 동기식 복제를 제공하는 MySQL Galera 데이터베이스 클러스터에 연결되는 플로팅 IP를 가리킵니다. 모든 구성 요소는 VLAN.

이제 데이터베이스 계층을 사용할 수 있습니다. 다음으로 집중해야 할 점은 응용 프로그램 서버를 해결하는 것입니다. 이 프로세스는 상태 비수 응용 프로그램에 대해 간단하지만 상태 상태인 앱에 대해 추가 고려를 수행해야 합니다. 상태를 유지하는 방법에 따라 유니슨 또는 글루스터와 같은 도구를 사용하여 코드를 리팩터링하거나 파일 복제를 구현해야 할 수 있습니다. 이 예제에서는 임시 세션 파일을 제외하고 응용 프로그램 상태가 데이터베이스에 의해 유지 관리된다고 가정합니다.

로드 밸런싱 및 응용 프로그램 복제

부하 분산은 애플리케이션에 고가용성과 수평적 확장성을 제공하지만 단일 로드 밸런서 인스턴스는 단일 장애 지점을 생성하기도 합니다. 이중화는 이 구현에서 여전히 중요한 구성 요소입니다. Linode NodeBalancers 는 세션 고착화, 상태 모니터링, 클라이언트 요청을 백엔드 애플리케이션 노드 집합에 배포할 수 있는 고가용성, 즉시 사용 가능한 솔루션을 제공합니다.

다이어그램: 로드 밸런서가 두 애플리케이션 서버 간에 트래픽을 분산하며, 두 서버는 모두 프로덕션 데이터베이스용 Galera 클러스터에 연결됩니다. 세 개의 복제가 표시됩니다. 모든 구성 요소는 동일한 VLAN 에 포함되어 있습니다.

하나의 응용 프로그램 서버가 다운되면 NodeBalancer는 트래픽을 정상 노드로만 지시하기 시작합니다. 비정상 노드가 복구되는 즉시 이전과 마찬가지로 연결 균형 조정이 재개됩니다. 이를 통해 가동 중지 시간 없이 응용 프로그램 서버를 쉽게 추가, 제거 또는 업데이트할 수 있으며 Galera에서 제공하는 활성 활성 솔루션으로 인해 모든 응용 프로그램 노드가 모든 데이터베이스 노드에 읽기/쓰기할 수 있습니다.

Linode의 솔루션 엔지니어링 팀은 이와 같은 프레임워크, 가이드 및 도구를 공유하여 모범 사례를 염두에 둔 앱을 개발합니다. Galera 클러스터에서 제공하는 고가용성 혜택에 대해 자세히 읽어보십시오 . Linode에서 이 건물을 시작할 준비가 된 경우, 설정 가이드를 확인하세요. 마리아DB 와 갈레리아 클러스터, Debian그리고 Ubuntu.


내용

댓글 남기기

이메일 주소는 게시되지 않습니다. 필수 필드가 표시됩니다 *