장애 조치

Bigtable 클러스터가 응답하지 않을 경우 복제본이 있으면 수신 트래픽을 같은 인스턴스의 다른 클러스터로 장애 조치할 수 있습니다. 장애 조치는 애플리케이션이 사용하는 앱 프로필과 앱 프로필 구성 방식에 따라 수동 또는 자동으로 수행될 수 있습니다.

이 페이지에서는 복제를 사용하는 인스턴스에서의 수동 및 자동 장애 조치 작동 방법을 설명합니다. 장애 조치를 완료하는 방법을 알아보려면 장애 조치 관리를 참조하세요.

이 페이지를 읽기 전에 Bigtable 복제 개요를 숙지해야 합니다. 사용 가능한 라우팅 옵션도 숙지해야 합니다.

수동 장애 조치

앱 프로필에서 단일 클러스터 라우팅을 사용하여 모든 요청을 하나의 클러스터에 전달하는 경우 다른 클러스터로 장애 조치를 시작할 시기를 직접 판단해야 합니다.

다음과 같은 경우 다른 클러스터로 장애 조치하는 것이 유익합니다.

  • 클러스터가 일시적 시스템 오류를 많이 반환하기 시작합니다.
  • 많은 요청이 시간 초과되기 시작합니다.
  • 평균 응답 지연 시간이 허용되지 않는 수준으로 늘어납니다.

위와 같은 문제 상황의 원인은 여러 가지일 수 있기 때문에 다른 클러스터로 장애 조치해도 근본적인 문제가 해결되지 않을 수 있습니다. 장애 조치 전후에 인스턴스를 모니터링하여 측정 항목이 개선되었는지 확인합니다.

수동 장애 조치를 완료하는 방법에 대한 자세한 내용은 수동 장애 조치 완료하기를 참조하세요.

자동 장애 조치

앱 프로필에서 멀티 클러스터 라우팅을 사용하는 경우 Bigtable에서 자동으로 장애 조치를 처리합니다. 가장 가까운 클러스터에서 요청을 처리할 수 없는 경우 Bigtable이 트래픽을 사용 가능한 가장 가까운 클러스터로 라우팅합니다.

아주 짧은 시간 동안 클러스터를 사용할 수 없는 경우에도 자동 장애 조치가 발생할 수 있습니다. 예를 들어 Bigtable이 요청을 한 클러스터로 라우팅했는데 해당 클러스터의 응답 속도가 너무 느리거나 일시적인 오류가 반환되면 Bigtable은 일반적으로 다른 클러스터에서 해당 요청을 다시 시도합니다.

멀티 클러스터 라우팅을 사용하는 경우 기한이 있는 요청을 보내면 Bigtable은 기한을 맞추는 데 필요한 경우 자동으로 장애 조치를 취합니다. 요청 기한이 다가오지만 초기 클러스터가 응답을 보내지 않은 경우 Bigtable은 다음으로 가까운 클러스터로 요청을 다시 라우팅합니다.

Bigtable은 복제가 완료되기 전에 장애 조치로 인해 발생할 수 있는 모든 데이터 충돌을 처리하기 위해 내부 마지막 쓰기 성공 알고리즘을 사용합니다. 자세한 내용은 충돌 해결 방법을 참조하세요.

멀티 클러스터 라우팅과 함께 복제를 사용하여 애플리케이션의 고가용성(HA)을 확보하려면 클라이언트 서버 또는 VM이 2개 이상의 Google Cloud 리전 내나 근처에 있어야 합니다. 이 권장사항은 Google Cloud에서 애플리케이션 서버를 호스팅하지 않는 경우에도 적용됩니다. 데이터가 애플리케이션 서버와 가장 가까운 Google Cloud 리전을 통해 Google Cloud 네트워크에 들어오기 때문입니다. 다른 요청과 마찬가지로 장애 조치는 거리가 짧을 수록 더 빠르게 완료됩니다.

많은 자동 장애 조치가 매우 짧은 시간 동안 수행되어 사용자가 알아차리지 못합니다. 일정 기간 동안 자동으로 경로가 변경된 요청 수를 보려면 Google Cloud Console에서 자동 장애 조치 그래프를 확인하면 됩니다. 인스턴스 목록을 열고 인스턴스 이름을 클릭한 후 모니터링을 클릭하면 됩니다.

다음 단계