Azure Database for MySQL - 유연한 서버의 고가용성 개념

Azure Database for MySQL 유연한 서버를 사용하면 자동 장애 조치(failover)로 고가용성을 구성할 수 있습니다. 고가용성 솔루션은 커밋된 데이터가 오류로 인해 손실되지 않고 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 디자인되었습니다. 고가용성이 구성되면 유연한 서버가 대기 복제본을 자동으로 프로비전하고 관리합니다. 주 복제본과 보조 복제본 모두에 대해 프로비저닝된 컴퓨팅 및 스토리지에 대한 요금이 청구됩니다. 다음 두 가지의 고가용성 아키텍처 모델이 있습니다.

• 영역 중복 HA. 이 옵션은 여러 가용성 영역에서 인프라의 완전한 격리/중복도를 얻기 위해 선호됩니다. 최고 수준의 가용성을 제공하지만 영역 간에 애플리케이션 중복도를 구성해야 합니다. 영역 중복 HA는 가용성 영역에서 발생하는 모든 인프라 장애에 대해 최고 수준의 가용성을 확보하고 가용성 영역 간의 대기 시간을 허용하려는 경우 선호됩니다. 서버를 만들 때에만 사용할 수 있습니다. 영역 중복 HA는 지역에서 여러 가용성 영역을 지원하고 영역 중복 프리미엄 파일 공유를 사용할 수 있는 Azure 지역의 하위 집합에서 사용할 수 있습니다.

• 동일 영역 HA. 이 옵션은 기본 서버와 대기 서버가 동일한 가용성 영역에 있어 네트워크 대기 시간이 짧은 인프라 중복도에 선호됩니다. 영역 간에 애플리케이션 중복도를 구성하지 않아도 고가용성을 제공합니다. 동일 영역 HA는 네트워크 대기 시간이 가장 짧은 단일 가용성 영역 내에서 최고 수준의 가용성을 확보하려는 경우 선호됩니다. 동일 영역 HA는 Azure Database for MySQL 유연한 서버를 사용할 수 있는 모든 Azure 지역에서 사용 가능합니다.

영역 중복 HA 아키텍처

영역 중복 HA를 사용하여 서버를 배포하면 다음의 두 가지 서버가 만들어집니다.

• 하나의 가용성 영역에 있는 주 서버
• 동일한 Azure 지역의 다른 가용성 영역에 있는 주 서버와 구성(컴퓨팅 계층, 컴퓨팅 크기, 스토리지 크기, 네트워크 구성)이 동일한 대기 복제본 서버

기본 복제본과 대기 복제본의 가용성 영역을 선택할 수 있습니다. 대기 데이터베이스 서버와 대기 애플리케이션을 동일한 영역에 배치하면 대기 시간이 줄어듭니다. 또한 재해 복구 상황 및 ‘영역 축소’ 시나리오에 더욱 잘 대비할 수 있습니다.

데이터 및 로그 파일은 ZRS(영역 중복 스토리지)에서 호스트됩니다. 대기 서버는 스토리지 수준 복제로 보호되는 주 서버의 스토리지 계정에서 로그 파일을 지속적으로 읽고 재생합니다.

장애 조치(failover)가 있는 경우:

• 대기 복제본이 활성화됩니다.
• 기본 서버의 이진 로그 파일이 대기 서버에 계속 적용되어 기본 서버에서 마지막으로 커밋된 트랜잭션을 온라인 상태로 만듭니다.

주 서버를 사용할 수 없는 경우에도 ZRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 현재 대기 복제본 서버가 주 서버의 역할을 합니다. 클라이언트가 다시 연결될 때 클라이언트 연결이 새로운 주 서버로 전달되도록 DNS가 업데이트됩니다. 장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명하며 사용자의 작업이 필요하지 않습니다. 그런 다음 HA 솔루션은 가능한 경우 이전 주 서버를 다시 가져와 대기 서버로 배치합니다.

데이터베이스 서버 이름은 애플리케이션을 주 서버에 연결하는 데 사용됩니다. 대기 복제본 정보는 직접 액세스에 노출되지 않습니다. 로그 파일이 주 서버의 ZRS에서 플러시되면 커밋과 쓰기가 승인됩니다. ZRS 스토리지에 사용되는 동기화 복제 기술 덕분에 애플리케이션 쓰기 및 커밋에 대해 5~10% 늘어난 대기 시간을 예측할 수 있습니다.

스냅샷과 로그 백업 모두, 자동 백업은 주 데이터베이스 서버의 영역 중복 스토리지에서 수행됩니다.

동일 영역 HA 아키텍처

동일 영역 HA를 사용하여 서버를 배포하면 동일한 영역에 두 개의 서버가 만들어집니다.

• 주 서버
• 주 서버와 구성(컴퓨팅 계층, 컴퓨팅 크기, 스토리지 크기 및 네트워크 구성)이 동일한 대기 복제본 서버

대기 서버는 별도의 가상 머신(컴퓨팅)을 사용하여 인프라 중복도를 제공합니다. 이러한 중복도는 공동 배치로 인한 애플리케이션과 데이터베이스 서버 간의 장애 조치(failover) 시간 및 네트워크 대기 시간을 줄여 줍니다.

데이터 및 로그 파일은 LRS(로컬 중복 스토리지)에서 호스트됩니다. 대기 서버는 스토리지 수준 복제로 보호되는 주 서버의 스토리지 계정에서 로그 파일을 지속적으로 읽고 재생합니다.

장애 조치(failover)가 있는 경우:

• 대기 복제본이 활성화됩니다.
• 기본 서버의 이진 로그 파일이 대기 서버에 계속 적용되어 기본 서버에서 마지막으로 커밋된 트랜잭션을 온라인 상태로 만듭니다.

기본 서버를 사용할 수 없는 경우에도 LRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 현재 대기 복제본이 주 서버의 역할을 합니다. DNS는 클라이언트가 다시 연결될 때 새로운 주 서버로 연결을 리디렉션하도록 업데이트됩니다. 장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명하며 사용자의 작업이 필요하지 않습니다. 그런 다음 HA 솔루션은 가능한 경우 이전 주 서버를 다시 가져와 대기 서버로 배치합니다.

데이터베이스 서버 이름은 애플리케이션을 주 서버에 연결하는 데 사용됩니다. 대기 복제본 정보는 직접 액세스에 노출되지 않습니다. 주 서버의 LRS에서 로그 파일이 플러시되면 커밋과 쓰기가 승인됩니다. 주 복제본과 대기 복제본이 동일한 영역에 있기 때문에 복제 지연 시간이 줄어들고 애플리케이션 서버와 데이터베이스 서버 간의 대기 시간이 줄어듭니다. 특정 가용성 영역에 대해 종속 인프라가 다운되면 동일 영역 설정에서 고가용성을 제공하지 않습니다. 해당 가용성 영역에 대해 모든 종속 서비스가 다시 온라인 상태가 될 때까지 가동 중지 시간이 있습니다.

스냅샷과 로그 백업 모두, 자동 백업은 주 데이터베이스 서버의 로컬 중복 스토리지에서 수행됩니다.

장애 조치(failover) 프로세스

Azure Database for MySQL의 장애 조치(failover) 프로세스 중에 시스템은 자동으로 주 서버에서 대기 복제본으로 전환하여 연속성을 보장하고 가동 중지 시간을 최소화합니다. 오류가 감지되면 대기 복제본이 새 주 서버로 승격됩니다. 원래 주 서버의 이진 로그 파일은 대기 복제본에 적용되어 마지막으로 커밋된 트랜잭션과 동기화되므로 데이터가 손실되지 않습니다. 이 원활한 전환은 데이터베이스 서비스의 고가용성 및 안정성을 유지하는 데 도움이 됩니다.

계획됨: 강제 장애 조치(failover)

Azure Database for MySQL 유연한 서버 강제 장애 조치(failover)를 사용하면 장애 조치(failover)를 수동으로 강제 적용할 수 있습니다. 이 기능을 사용하면 애플리케이션 시나리오로 기능을 테스트할 수 있으며 중단에 대비할 수 있습니다.

강제 장애 조치(failover)는 DNS 레코드를 업데이트하여 동일한 데이터베이스 서버 이름을 가진 주 서버가 되도록 대기 복제본을 활성화하는 장애 조치(failover)를 트리거합니다. 원래 주 서버가 다시 시작되고 대기 복제본으로 전환됩니다. 클라이언트 연결이 끊어지고 작업을 재개하려면 다시 연결해야 합니다.

전체 장애 조치(failover) 시간은 현재 워크로드 및 마지막 검사점에 따라 달라집니다. 일반적으로 60~120초가 소요될 것으로 예상됩니다.

계획되지 않음: 자동 장애 조치(failover)

계획되지 않은 서비스 가동 중지 시간은 소프트웨어 버그 또는 인프라 결함(예: 컴퓨팅, 네트워크 또는 스토리지 오류 또는 데이터베이스 가용성에 영향을 미치는 정전)로 인해 발생할 수 있습니다. 데이터베이스를 사용할 수 없게 되면 대기 복제본에 대한 복제가 중단되고 대기 복제본이 주 데이터베이스로 활성화됩니다. DNS가 업데이트되고 클라이언트가 데이터베이스 서버에 다시 연결되어 작업을 다시 시작합니다.

전체 장애 조치(failover) 시간은 60~120초 사이가 될 것으로 예상됩니다. 그러나 장애 조치(failover) 시 대용량 트랜잭션, 복구 시간 등 주 데이터베이스 서버의 작업에 따라 장애 조치(failover)가 더 오래 걸릴 수 있습니다.

HA 지원 서버에서 자동 장애 조치(failover) 검색이 작동하는 방식

주 서버와 보조 서버에는 두 개의 네트워크 엔드포인트가 있습니다.

• 고객 엔드포인트: 고객이 이 엔드포인트를 사용하여 인스턴스에서 쿼리를 연결하고 실행합니다.
• 관리 엔드포인트: 관리 구성 요소에 대한 서비스 통신 및 백 엔드 스토리지에 연결하기 위해 내부적으로 사용됩니다.

상태 모니터 구성 요소는 다음 검사를 지속적으로 수행합니다.

• 모니터는 노드 관리 네트워크 엔드포인트에 ping합니다. 이 검사가 연속적으로 두 번 실패하면 자동 장애 조치(failover) 작업이 트리거됩니다. 노드와 같은 시나리오는 OS 문제로 인해 사용할 수 없거나 응답하지 않습니다. 관리 구성 요소와 노드 간의 네트워킹 문제 등은 이 상태 검사를 통해 해결됩니다.
• 또한 모니터는 인스턴스에서 간단한 쿼리를 실행합니다. 쿼리가 실행되지 않으면 자동 장애 조치(failover)가 트리거됩니다. MySQL 디먼 충돌/중지/중단, 백 엔드 스토리지 문제 등과 같은 시나리오는 이 상태 검사를 통해 해결됩니다.

고가용성 모니터링

포털의 서버 고가용성 창에 있는 고가용성 상태를 사용하여 서버의 HA 구성 상태를 확인할 수 있습니다.

아래 메트릭을 사용하여 HA 서버의 상태를 모니터링할 수도 있습니다.

제한 사항

고가용성을 사용할 때 유의해야 할 몇 가지 고려 사항은 다음과 같습니다.

• 영역 중복 고가용성은 유연한 서버를 만들 때에만 설정할 수 있습니다.
• 버스트 가능 컴퓨팅 계층에서는 고가용성이 지원되지 않습니다.
• 고정적인 매개 변수 변경 내용을 선택하기 위해 주 데이터베이스 서버를 다시 시작하면 대기 복제본도 다시 시작됩니다.
• HA 솔루션은 GTID를 사용하므로 GTID 모드가 켜집니다. 워크로드에 GTID를 사용한 복제에 대한 제한 또는 한계가 있는지 확인합니다.

상태 검사

Azure Database for MySQL에 대한 HA(고가용성)를 구성할 때 상태 검사는 데이터베이스의 안정성과 성능을 유지하는 데 중요한 역할을 합니다. 이러한 검사는 주 복제본과 대기 복제본의 상태 및 상태를 지속적으로 모니터링하여 문제가 즉시 검색되는지 확인합니다. 상태 검사는 서버 응답성, 복제 지연 시간 및 리소스 사용률과 같은 다양한 메트릭을 추적하여 장애 조치 프로세스를 원활하게 실행하여 가동 중지 시간을 최소화하고 데이터 손실을 방지하는 데 도움이 됩니다. 올바르게 구성된 상태 검사는 데이터베이스 설정에서 원하는 수준의 가용성 및 복원력을 달성하는 데 필수적입니다.

상태 모니터링

"사용자는 Azure Portal을 통해 HA 설정의 상태를 모니터링할 수 있습니다. 관찰할 주요 메트릭은 다음과 같습니다.

• 서버 응답성: 주 서버에 연결할 수 있는지 여부를 나타냅니다.
• 복제 지연 시간: 주 복제본과 대기 복제본 간의 지연을 측정하여 데이터 일관성을 보장합니다.
• 리소스 사용률: 병목 현상을 방지하기 위해 CPU, 메모리 및 스토리지 사용량을 모니터링합니다."

질문과 대답(FAQ)

• 동일한 영역 및 영역 중복 HA 지원 유연한 서버에 대한 SLA는 무엇인가요?

  Azure Database for MySQL 유연한 서버에 대한 SLA 정보는 Azure Database for MySQL용 SLA에서 찾을 수 있습니다.

• 고가용성(HA) 서버 요금은 어떻게 청구되나요? HA에서 사용하는 서버에는 주 복제본과 보조 복제본이 있습니다. 보조 복제본은 동일 영역 또는 영역 중복에 있을 수 있습니다. 주 복제본과 보조 복제본 모두에 대해 프로비저닝된 컴퓨팅 및 스토리지에 대한 요금이 청구됩니다. 예를 들어 4개의 컴퓨팅 vCore와 512GB의 프로비저닝된 스토리지를 갖춘 주 복제본이 있는 경우, 보조 복제본에도 4개의 vCore와 512GB의 프로비저닝된 스토리지가 있습니다. 영역 중복 HA 서버에서는 8개의 vCore와 1,024GB의 스토리지에 대해 요금이 청구됩니다. 백업 스토리지 볼륨에 따라 백업 스토리지에 대한 요금이 청구될 수도 있습니다.

• 읽기 또는 쓰기 작업에 대기 복제본을 사용할 수 있나요?
  대기 서버는 읽기 또는 쓰기 작업에 사용할 수 없습니다. 또한 빠른 장애 조치(failover)를 사용할 수 있는 수동 대기 상태입니다.

• 장애 조치(failover)가 발생하면 데이터가 손실되나요?
  주 서버를 사용할 수 없는 경우에도 ZRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 주 서버의 역할을 수행합니다.
  

• 장애 조치(failover) 후에 작업을 수행해야 하나요?
  장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명합니다. 아무 작업도 수행할 필요가 없습니다. 애플리케이션은 연결에 대한 다시 시도 논리를 사용해야 합니다.
  

• 대기 복제본에 특정 영역을 선택하지 않으면 어떻게 되나요? 나중에 영역을 변경할 수 있나요?
  영역을 선택하지 않으면 영역이 임의로 선택됩니다. 주 서버에서 사용되는 서버가 됩니다. 나중에 영역을 변경하려면 고가용성 창에서 고가용성을 사용 안 함으로 설정한 후 영역 중복으로 다시 설정하고 영역을 선택하면 됩니다.
  

• 주 복제본과 대기 복제본 간의 복제는 동기식인가요?
  주 복제본과 대기 복제본 간의 복제는 MySQL의 일부 동기 모드와 유사합니다. 트랜잭션이 커밋된 경우 반드시 대기에 커밋되지는 않습니다. 그러나 주 복제본을 사용할 수 없는 경우 대기 복제본은 주 복제본의 데이터 변경 사항을 모두 복제하여 데이터가 손실되지 않도록 합니다.
  

• 계획되지 않은 모든 오류가 발생하는 경우 대기 복제본에 대한 장애 조치(failover)가 있나요?
  데이터베이스 충돌 또는 노드 오류가 발생하면 유연한 서버 VM이 동일한 노드에서 다시 시작됩니다. 동시에 자동 장애 조치(failover)가 트리거됩니다. 장애 조치(failover)가 완료되기 전에 유연한 서버 VM이 다시 시작되면 장애 조치(failover) 작업이 취소됩니다. 주 복제본으로 사용할 서버의 결정은 먼저 완료되는 프로세스에 따라 달라집니다.
  

• HA를 사용할 때 성능에 영향을 주나요?
  영역 중복 HA의 경우 가용성 영역에서 읽기 워크로드에 대한 주요 성능 영향은 없지만 쓰기 쿼리 대기 시간이 최대 40% 감소할 수 있습니다. 쓰기 대기 시간의 증가는 가용성 영역 전체에서 동기 복제로 인해 발생합니다. 쓰기 대기 시간 영향은 일반적으로 동일한 영역 HA에 비해 영역 중복 HA에서 두 번입니다. 동일 영역 HA는 주 복제본과 대기 복제본이 동일한 영역에 있으므로 복제 지연 시간이 길어지고 결과적으로 동기 쓰기 지연 시간이 줄어듭니다. 요약하자면, 쓰기 대기 시간이 가용성에 비해 더 중요한 경우 동일한 영역 HA를 선택할 수 있지만, 쓰기 대기 시간 감소로 데이터의 가용성 및 복원력이 더 중요한 경우 영역 중복 HA를 선택해야 합니다. HA 설정에서 대기 시간 감소의 정확한 영향을 측정하려면 워크로드에 대한 성능 테스트를 수행하여 정보에 입각한 결정을 내리는 것이 좋습니다.
  

• HA 서버를 유지 관리하려면 어떻게 해야 하나요?
  컴퓨팅 크기 조정 및 부 버전 업그레이드와 같은 계획된 이벤트는 원래 대기 인스턴스에서 먼저 발생한 다음 계획된 장애 조치(failover) 작업을 트리거한 다음 원래 주 인스턴스에서 작동합니다. 유연한 서버와 마찬가지로 HA 서버에 예약된 유지 관리 기간을 설정할 수 있습니다. 가동 중지 시간은 HA가 사용되지 않는 경우 Azure Database for MySQL 유연한 서버 인스턴스의 가동 중지 시간과 동일합니다.
  

• HA 서버의 PITR(특정 시점 복원)을 수행할 수 있나요?
  HA가 사용하도록 설정된 Azure Database for MySQL 유연한 서버 인스턴스에 대해 HA가 사용하지 않도록 설정된 새로운 Azure Database for MySQL 유연한 서버 인스턴스에 대해 PITR을 수행할 수 있습니다. 원본 서버가 영역 중복 HA에서 만들어진 경우, 나중에 복원된 서버에서 영역 중복 HA 또는 동일 영역 HA를 사용할 수 있습니다. 원본 서버가 동일 영역 HA에서 만들어진 경우, 복원된 서버에서만 동일 영역을 사용할 수 있습니다.
  

• App Service 격리서버를 만든 후 서버에서 HA를 사용하도록 설정할 수 있나요?
  서버를 만들 때 영역 중복 HA를 사용하도록 설정해야 합니다. 서버를 만든 후에는 동일 영역 HA를 사용할 수 있습니다. 동일한 영역 HA를 사용하도록 설정하기 전에 서버 매개 변수가 enforce_gtid_consistency" 및 "gtid_mode" 가 ON으로 설정되어 있는지 확인합니다.
  

• 서버를 만든 후 서버에서 HA를 사용하지 않을 수 있나요?
  서버를 만든 후 서버에서 HA를 사용하지 않도록 설정할 수 있습니다. 청구가 즉시 중지됩니다.
  

• 가동 중지 시간을 완화하려면 어떻게 해야 하나요?
  HA를 사용하지 않는 경우에도 애플리케이션의 가동 중지 시간을 완화할 수 있어야 합니다. 예약된 패치, 부 버전 업그레이드 또는 컴퓨팅 크기 조정처럼 고객이 시작한 작업 등의 서비스 가동 중지 시간은 예약된 유지 관리 기간에 수행할 수 있습니다. Azure에서 시작된 유지 관리 작업에 대한 애플리케이션 영향을 완화하려면, 애플리케이션에 미치는 영향을 최소화하는 요일 및 시간에 예약하면 됩니다.
  

• HA 사용 서버에서 읽기 복제본을 사용할 수 있나요?
  예, 읽기 복제본은 HA 서버에서 지원되지 않습니다.
  

• HA 서버에서 입력 데이터 복제를 사용할 수 있나요?
  HA(고가용성) 지원 서버에 대한 입력 데이터 복제 지원은 GTID 기반 복제를 통해서만 제공됩니다. GTID를 사용한 복제를 위한 저장 프로시저는 모든 HA 지원 서버에서 이름 mysql.az_replication_with_gtid로 사용할 수 있습니다.

• 가동 중지 시간을 줄이기 위해 서버를 다시 시작하거나 스케일 업 또는 다운하는 동안 대기 서버로 장애 조치(failover)할 수 있나요?
  현재 Azure Database for MySQL 유연한 서버는 계획된 장애 조치(failover)를 활용하여 크기 조정/축소를 포함한 HA 작업을 최적화하고 유지 관리를 계획하여 가동 중지 시간을 줄였습니다. 이러한 작업이 시작되면 원래 대기 인스턴스에서 먼저 작동한 다음 계획된 장애 조치(failover) 작업을 트리거한 다음 원래 주 인스턴스에서 작동합니다.
  

• 서버의 가용성 모드(영역 중복 HA/동일 영역)를 변경할 수 있나요?
  영역 중복 HA 모드를 사용하는 서버를 만드는 경우 영역 중복 HA에서 동일 영역으로, 또 그 반대로 변경할 수 있습니다. 가용성 모드를 변경하려면, 고가용성 창에서 고가용성을 사용 안 함으로 설정한 다음 영역 중복 또는 동일 영역으로 다시 설정하고 고가용성 모드를 선택하면 됩니다.
  

관련 콘텐츠

• 비즈니스 연속성
• 영역 중복 고가용성
• 백업 및 복구