Azure Table Storage 는 구조화된 NoSQL 데이터를 클라우드에 저장하는 서비스입니다. 각 엔터티가 키를 통해 액세스되고 특성 집합을 포함하는 스키마 없는 저장소를 제공합니다. 단일 테이블에는 다양한 속성 집합을 가진 엔터티가 포함될 수 있으며 속성은 다양한 데이터 유형으로 구성될 수 있습니다.
Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.
이 문서에서는 일시적인 오류, 가용성 영역 중단 및 지역 중단을 포함하여 다양한 잠재적인 중단 및 문제에 대해 Table Storage를 복원하는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법을 설명하고 SLA(Table Storage 서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.
비고
Table Storage는 Azure Storage 플랫폼의 일부입니다. Table Storage의 일부 기능은 여러 Azure Storage 서비스에서 공통적으로 사용됩니다. 이 문서에서는 Azure Storage 또는 Storage 를 사용하여 이러한 일반적인 기능을 참조합니다.
안정성을 위한 프로덕션 배포 권장 사항
프로덕션 환경의 경우 다음 작업을 수행합니다.
Table Storage 리소스가 포함된 스토리지 계정에 대해 ZRS(영역 중복 스토리지)를 사용하도록 설정합니다. ZRS는 주 지역의 여러 가용성 영역에 동기식으로 데이터를 복제하여 더 높은 가용성을 제공합니다. 이 복제는 가용성 영역 오류로부터 보호합니다.
지역 중단에 대한 복원력이 필요하고 스토리지 계정의 주 지역이 쌍을 이루는 경우 GRS(지역 중복 스토리지)가 쌍을 이루는 지역에 비동기적으로 데이터를 복제하도록 설정하는 것이 좋습니다. 지원되는 지역에서는 지역 중복과 영역 중복을 GZRS(지역 영역 중복 스토리지)를 사용하여 결합할 수 있습니다.
대규모 프로덕션 워크로드의 경우 또는 높은 복원력 요구 사항이 있는 경우 Azure Cosmos DB for Table을 사용하는 것이 좋습니다. Azure Cosmos DB for Table은 Table Storage용으로 작성된 애플리케이션과 호환됩니다. 낮은 대기 시간의 읽기 및 쓰기 작업을 대규모로 지원하고 유연한 일관성 모델을 사용하여 여러 지역에 강력한 글로벌 배포를 제공합니다. 또한 애플리케이션의 복원력과 성능을 향상시키는 기본 제공 백업 및 기타 기능을 제공합니다.
안정성 아키텍처 개요
Table Storage는 Azure Storage 플랫폼 인프라 내에서 분산 NoSQL 데이터베이스로 작동합니다. 서비스는 테이블 데이터의 여러 복사본을 통해 중복성을 제공하며 특정 중복 모델은 스토리지 계정 구성에 따라 달라집니다.
LRS(로컬 중복 스토리지) 는 스토리지 계정 내의 데이터를 선택한 주 지역에 있는 하나 이상의 Azure 가용성 영역에 복제합니다. 기본 가용성 영역을 선택할 수 있는 옵션은 없지만 Azure는 부하 분산을 개선하기 위해 영역 간에 LRS 계정을 이동하거나 확장할 수 있습니다. 데이터가 영역에 분산된다는 보장은 없습니다. 가용성 영역에 대한 자세한 내용은 가용성 영역이란?을 참조하세요.
ZRS(영역 중복 스토리지), GRS(지역 중복 스토리지), GZRS(지역 영역 중복 스토리지)는 추가적인 보호 기능을 제공합니다. 이 문서에서는 이러한 옵션에 대해 자세히 설명합니다.
일시적인 오류에 대한 복원력
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.
Table Storage 클라이언트 라이브러리 및 SDK에는 네트워크 시간 제한, 임시 서비스 사용 불가(HTTP 503), 제한 응답(HTTP 429) 및 파티션 서버 오버로드 조건과 같은 일반적인 일시적 오류를 자동으로 처리하는 기본 제공 재시도 정책이 포함되어 있습니다. 애플리케이션이 이러한 일시적인 조건을 겪는 경우 클라이언트 라이브러리는 지수 백오프 전략을 사용하여 작업을 자동으로 다시 시도합니다.
Table Storage를 사용할 때 일시적 오류를 효과적으로 관리하려면 다음 작업을 수행합니다.
일시적인 속도 저하에 대한 응답성과 복원력의 균형을 맞추기 위해 Table Storage 클라이언트에서 적절한 시간 제한을 구성합니다. Azure Storage 클라이언트 라이브러리의 기본 시간 제한은 일반적으로 대부분의 시나리오에 적합합니다.
특히 애플리케이션에서 HTTP 503 서버 사용 중 또는 HTTP 500 작업 시간 제한 오류가 발생하는 경우 재시도 정책에 대해 지수 백오프를 구현합니다. Table Storage는 개별 파티션이 많이 사용되거나 스토리지 계정 한도에 접근할 때 요청을 제한할 수 있습니다.
대규모 애플리케이션에서 파티션 인식 다시 시도 논리를 설계합니다. 파티션 인식 다시 시도 논리는 Table Storage에서 분할된 아키텍처를 고려하고 여러 파티션에 작업을 분산하여 개별 파티션 서버에서 제한이 발생할 가능성을 줄이는 고급 방법입니다.
Table Storage 아키텍처와 복원력 있는 대규모 애플리케이션을 설계하는 방법에 대한 자세한 내용은 Table Storage의 성능 및 확장성 체크리스트를 참조하세요.
가용성 영역 오류에 대한 복원력
가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.
Table Storage는 ZRS 구성으로 배포하는 경우 영역 중복성을 갖습니다. LRS(로컬 중복 스토리지)와 달리 ZRS는 Azure가 여러 가용성 영역에서 테이블 데이터를 동기적으로 복제하도록 보장합니다. 이 구성을 사용하면 전체 가용성 영역을 사용할 수 없게 되더라도 테이블에 계속 액세스할 수 있습니다. 모든 쓰기 작업은 서비스가 쓰기를 완료하기 전에 여러 영역에서 확인되어야 하므로 강력한 일관성이 보장됩니다.
영역 중복은 스토리지 계정 수준에서 사용하도록 설정되며 해당 계정 내의 모든 Table Storage 리소스에 적용됩니다. 해당 설정은 전체 스토리지 계정에 적용되므로 개별 엔터티를 다른 중복도 수준에 맞게 구성할 수 없습니다. 가용성 영역에 중단이 발생하면 Azure Storage는 사용자나 사용자의 애플리케이션이 개입하지 않아도 자동으로 요청을 정상적인 영역으로 라우팅합니다.
요구 사항
- 지역 지원:가용성 영역을 지원하는 모든 지역에서 영역 중복 Azure Storage 계정을 배포할 수 있습니다.
- 스토리지 계정 유형: Table Storage에 ZRS를 사용하도록 설정하려면 표준 범용 v2 스토리지 계정을 사용해야 합니다. 프리미엄 스토리지 계정은 Table Storage를 지원하지 않습니다.
비용
ZRS(영역 중복 스토리지)를 사용하도록 설정하면 추가적인 복제 및 스토리지 오버헤드로 인해 LRS(로컬 중복 스토리지)와 다른 요금이 부과됩니다.
자세한 가격 책정 정보는 Table Storage 가격 책정을 참조하세요.
가용성 영역 지원 구성
영역 중복 스토리지 계정 및 테이블을 만듭니다.
스토리지 계정 만들기 ZRS, GZRS 또는 RA-GZRS(읽기 액세스 지역 중복 스토리지)를 중복 옵션으로 선택해야 합니다.
복제 형식을 변경합니다. 기존 스토리지 계정을 ZRS(영역 중복 스토리지)로 변경하는 방법과 구성 옵션 및 요구 사항에 대해 알아보려면 스토리지 계정 복제 방식 변경을 참조하세요.
영역 중복을 사용하지 않도록 설정합니다. 동일한 중복도 구성 변경 프로세스를 사용하여 ZRS 계정을 LRS(로컬 중복 스토리지)와 같은 비구역 구성으로 다시 변환합니다.
모든 영역이 정상인 경우의 동작
이 섹션에서는 Table Storage 계정이 영역 중복을 위해 구성되고 모든 가용성 영역이 작동할 때 예상되는 상황을 설명합니다.
영역 간 트래픽 라우팅: ZRS(영역 중복 스토리지)를 갖춘 Azure Storage는 여러 가용성 영역의 스토리지 클러스터에 요청을 자동으로 분산합니다. 트래픽 배포는 애플리케이션에 투명하며 클라이언트 쪽 구성이 필요하지 않습니다.
영역 간 데이터 복제: ZRS에 대한 모든 쓰기 작업은 해당 지역 내의 모든 가용성 영역에 동기식으로 복제됩니다. 데이터를 업로드하거나 수정하는 경우 모든 가용성 영역에서 데이터가 성공적으로 복제될 때까지 작업이 완료된 것으로 간주되지 않습니다. 이 동기 복제는 영역 오류 발생 시 강력한 일관성과 데이터 손실이 없도록 합니다.
영역 오류 중 동작
가용성 영역을 사용할 수 없게 되면 Table Storage는 다음과 같은 동작으로 응답하여 장애 조치(failover) 프로세스를 자동으로 처리합니다.
검색 및 응답: Microsoft는 자동으로 영역 오류를 감지하고 복구 프로세스를 시작합니다. ZRS(영역 중복 스토리지) 계정의 경우 고객 조치가 필요하지 않습니다.
영역을 사용할 수 없게 되면 Azure는 DNS(Domain Name System) 재포인팅과 같은 네트워킹 업데이트를 수행합니다.
- 알림: 영역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나 Azure Resource Health 를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다. 또한 Azure Service Health를 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 진행 중인 요청은 복구 프로세스 중에 삭제될 수 있으므로 다시 시도해야 합니다. 애플리케이션은 이러한 임시 중단을 처리하기 위해 재시도 논리를 구현 해야 합니다.
예상 데이터 손실: 쓰기 작업이 완료되기 전에 여러 영역에서 데이터가 동기적으로 복제되므로 영역 오류 중에 데이터가 손실되지 않습니다.
예상 가동 중지 시간: 자동 복구 중에 트래픽이 정상 영역으로 리디렉션되면서 일반적으로 몇 초 정도의 짧은 가동 중지 시간이 발생할 수 있습니다. ZRS용 애플리케이션을 설계할 때는 지수 백오프를 사용한 다시 시도 정책 구현을 포함하여 임시 오류 처리에 대한 사례를 따릅니다.
- 트래픽 다시 라우팅: 영역을 사용할 수 없게 되면 Azure는 요청이 나머지 정상 가용성 영역으로 전달되도록 DNS(Domain Name System) 다시 지정과 같은 네트워킹 업데이트를 수행합니다. 서비스는 정상 영역을 사용하여 전체 기능을 유지 관리하며 고객의 개입이 필요하지 않습니다.
영역 복구
실패한 가용성 영역이 복구되면 Azure Storage는 모든 가용성 영역에서 정상 작업을 자동으로 복원합니다. 이 서비스는 중단 기간 동안 발생한 모든 작업을 동기화하여 데이터 일관성을 자동으로 보장합니다.
영역 오류 테스트
ZRS(영역 중복 스토리지)를 사용하면 Azure Storage에서 복제, 트래픽 라우팅, 영역 다운 응답을 자동으로 관리합니다. 이 기능은 완전히 관리되므로 가용성 영역 오류 프로세스를 시작하거나 유효성을 검사할 필요가 없습니다.
지역 전체 오류에 대한 복원력
Azure Blob Storage, Azure Files, Azure Table Storage, Azure Queue Storage를 포함한 Azure Storage는 다양한 요구 사항에 맞춰 광범위한 지역 중복 및 장애 조치(failover) 기능을 제공합니다.
중요합니다
GRS(지역 중복 스토리지)는 Azure 쌍 지역 내에서만 작동합니다. 스토리지 계정의 지역이 페어링되지 않은 경우 복원력을 위해 사용자 지정 다중 지역 솔루션을 사용하는 것이 좋습니다.
페어링된 지역에 대한 지리 중복 스토리지
Azure Storage는 쌍으로 구성된 지역에서 여러 형식의 GRS를 제공합니다. 어떤 형식의 GRS를 사용하든 보조 지역의 데이터는 항상 LRS(로컬 중복 스토리지)를 사용하여 복제됩니다. 이러한 방식은 보조 지역 내의 하드웨어 오류로부터 보호 기능을 제공합니다.
GRS는 주 지역에서 중단이 발생할 경우 Azure 페어링 지역에 대한 계획된 장애 조치(failover) 및 계획되지 않은 장애 조치(failover)를 지원합니다. GRS는 주 지역에서 쌍을 이루는 지역으로 데이터를 비동기적으로 복제합니다.
GZRS(지역 영역 중복 스토리지)는 주 지역의 여러 가용성 영역과 쌍을 이루는 지역에 데이터를 복제합니다.
지리적 중복 스토리지
- RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)는 GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지)를 확장하여 보조 엔드포인트에 대한 읽기 액세스이라는 이점을 제공합니다. 이러한 옵션은 고가용성 비즈니스에 중요한 애플리케이션을 위해 설계된 애플리케이션에 이상적입니다. 주 엔드포인트에서 중단이 발생하는 드문 경우 보조 지역에 대한 읽기 액세스를 위해 구성된 애플리케이션은 계속 작동할 수 있습니다.
장애 조치(failover) 형식
Azure Storage는 다양한 시나리오에 대해 세 가지 형식의 장애 조치(failover)를 지원합니다.
고객 관리 계획되지 않은 장애 조치(failover): 주 지역에서 지역 전체 스토리지 장애가 발생하는 경우 복구를 시작하는 것은 고객의 책임입니다.
고객 관리형 계획된 장애 조치(failover): 솔루션의 다른 부분에 주 지역에서 오류가 발생한 경우 복구를 시작할 책임이 있으며 전체 솔루션을 보조 지역으로 전환해야 합니다. 스토리지가 주 지역에서 계속 작동하지만 규정 준수 및 감사 요구 사항을 보장하기 위해 설계된 재해 복구 훈련과 같이 전체 솔루션을 보조 지역으로 장애 조치해야 하는 경우 계획된 장애 조치(failover)를 사용합니다.
Microsoft 관리 장애 조치(failover): 예외적인 상황에서 Microsoft는 지역의 모든 GRS(지역 중복 스토리지) 계정에 대한 장애 조치(failover)를 시작할 수 있습니다. 그러나 Microsoft에서 관리하는 장애 조치(failover)는 최후의 수단이며 장기간 중단된 후에만 수행될 것으로 예상됩니다. Microsoft 관리 장애 조치(failover)에 의존해서는 안 됩니다.
GRS 계정은 이러한 장애 조치(failover) 형식을 사용할 수 있습니다. 미리 장애 조치 유형을 사용하기 위해 스토리지 계정을 구성할 필요가 없습니다.
요구 사항
지역 지원: Azure Storage 지역 중복 구성은 Azure 쌍을 이루는 지역을 사용하여 보조 지역으로 복제를 수행합니다. 보조 지역은 주 지역 선택에 따라 자동으로 결정되며 사용자 지정이 불가능합니다. Azure 쌍을 이루는 지역의 전체 목록은 Azure 지역 목록을 참조하세요.
스토리지 계정의 지역이 페어링되지 않은 경우 복원력을 위해 사용자 지정 다중 지역 솔루션을 사용하는 것이 좋습니다.
- 스토리지 계정 유형: 지리적 중복 스토리지 (GRS) 및 고객이 시작한 장애 조치 및 장애 복구는 범용 v2 Azure Storage 계정을 지원하는 모든 Azure 페어리전에서 사용할 수 있습니다.
고려 사항
다중 지역 Table Storage를 구현하는 경우 다음과 같은 중요한 요소를 고려합니다.
비동기 복제 지연: 보조 지역에 대한 데이터 복제는 비동기적입니다. 즉, 데이터가 주 지역에 기록되는 시점과 보조 지역에서 데이터를 사용할 수 있게 되는 시점 사이에 대기 시간이 발생합니다. 이러한 지연으로 인해 최근 데이터가 복제되기 전에 주 지역에 장애가 발생하면 잠재적으로 데이터 손실이 발생할 수 있습니다. 데이터 손실은 RPO(복구 지점 목표)로 측정됩니다. 복제 지연은 15분 이내로 예상할 수 있지만, 이는 예상 비용일 뿐 보장되지는 않습니다.
스토리지 계정에 계획되지 않은 장애 조치(failover)가 발생한 경우 얼마나 많은 데이터가 손실될 수 있는지 파악하려면 마지막 동기화 시간 속성을 확인합니다.
보조 지역 액세스: GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지) 구성을 사용하면 장애 조치(failover)가 발생할 때까지 보조 지역에 읽기 작업을 수행할 수 없습니다.
RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지) 구성은 일반 작업 중에 보조 지역에 대한 읽기 액세스을 제공하지만 비동기 복제 지연으로 인해 약간 오래된 데이터를 반환할 수 있습니다.
- 기능 제한 사항: 일부 Azure Storage 기능은 GRS(지역 중복 스토리지) 또는 고객 관리 장애 조치(failover)를 사용할 때 지원되지 않거나 제한 사항이 있습니다. 지역 중복을 구현하기 전에 기능 호환성을 검토합니다.
비용
다중 지역 Azure Storage 계정 구성에서는 보조 지역에서 지역 간 복제 및 저장에 대한 추가 비용이 발생합니다. Azure 지역 간 데이터 전송은 표준 지역 간 대역폭 요금에 따라 청구됩니다.
자세한 가격 책정 정보는 Table Storage 가격 책정을 참조하세요.
다중 지역 지원 구성
- 새로운 GRS(지역 중복 스토리지) 계정을 만듭니다. GRS 계정을 만들려면 스토리지 계정 만들기를 참조하고 계정 만드는 동안 GRS, RA-GRS(읽기 액세스 지역 중복 스토리지), GZRS(지역 영역 중복 스토리지) 또는 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 선택합니다.
기존 스토리지 계정에서 지역 중복을 사용하도록 설정합니다. 기존 스토리지 계정을 GRS(지역 중복 스토리지)로 변환하려면 스토리지 계정 복제 방법 변경을 참조하세요.
경고
지역 중복을 위해 계정을 다시 구성한 후, 새로운 주 지역에 있는 기존 데이터가 새로운 보조 지역에 완전히 복사되기까지 상당한 시간이 걸릴 수 있습니다.
중대한 데이터 손실을 방지하려면 계획되지 않은 장애 조치(failover)를 시작하기 전에 마지막 동기화 시간 속성 값을 확인합니다. 잠재적인 데이터 손실을 평가하려면 마지막 동기화 시간을 데이터가 새 주 지역에 기록된 마지막 시간과 비교합니다.
지역 중복성을 사용하지 않도록 설정합니다. 동일한 중복도 구성 변경 프로세스를 사용하여 GRS 계정을 LRS(로컬 중복 스토리지) 또는 ZRS(영역 중복 스토리지)와 같은 단일 지역 구성으로 다시 변환합니다.
모든 지역이 정상인 경우의 동작
이 섹션에서는 스토리지 계정이 지역 중복성을 위해 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.
지역 간 트래픽 라우팅: Azure Storage는 모든 쓰기 작업과 대부분의 읽기 작업이 주 지역으로 전달되는 활성-수동 방식을 사용합니다.
RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지) 구성의 경우, 애플리케이션은 선택적으로 보조 엔드포인트에 액세스하여 보조 지역에서 읽을 수 있습니다. 이 방식에는 명시적인 애플리케이션 구성이 필요하며 자동이 아닙니다. 또한 비동기 복제 지연으로 인해 보조 지역의 데이터가 약간 오래된 것일 수 있습니다.
지역 간 데이터 복제: 쓰기 작업은 다음과 같이 구성된 중복도 형식을 사용하여 먼저 주 지역에 커밋됩니다.
- GRS(지역 중복 스토리지) 및 RA-GRS에 대한 LRS(로컬 중복 스토리지)
- GZRS(지역 영역 중복 스토리지) 및 RA-GZRS에 대한 ZRS(영역 중복 스토리지)
주 지역에서 성공적으로 완료되면 데이터는 LRS를 사용하여 보조 지역에 비동기식으로 복제되어 저장됩니다.
지역 간 복제는 비동기적 특성을 가지고 있기 때문에 일반적으로 데이터가 주 지역에 기록되는 시점과 보조 지역에서 해당 데이터를 사용할 수 있게 되는 시점 사이에 지연 기간이 발생합니다. 마지막 동기화 시간 속성을 사용하여 복제 시간을 모니터링할 수 있습니다.
지역 오류 중 동작
이 섹션에서는 스토리지 계정이 지역 중복성을 위해 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.
고객 관리 장애 조치(failover)(계획되지 않음): 주 지역의 스토리지를 사용할 수 없는 경우 계획되지 않은 장애 조치를 사용합니다.
검색 및 응답: 주 지역에서 스토리지 계정을 사용할 수 없는 경우 고객 관리형 계획되지 않은 장애 조치(failover)를 시작하는 것이 좋습니다. 이 결정을 내리려면 다음 요소를 고려합니다.
Azure Resource Health에서 주 지역의 스토리지 계정에 액세스하는 데 문제가 표시되는지 여부
Microsoft에서 다른 지역으로 장애 조치(failover)를 수행하도록 권장하는지 여부
경고
계획되지 않은 장애 조치(failover) 로 인해 데이터가 손실될 수 있습니다. 고객 관리 장애 조치(failover)를 시작하기 전에 서비스 복원이 데이터 손실 위험을 정당화하는지 여부를 결정합니다.
알림: 지역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나:
Azure Resource Health를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다.
Azure Service Health를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 장애 조치(failover) 프로세스 중에 읽기 및 쓰기 모두에 대해 기본 및 보조 스토리지 계정 엔드포인트를 일시적으로 사용할 수 없게 됩니다. 활성 요청이 삭제될 수 있으며 장애 조치(failover)가 완료된 후 클라이언트 애플리케이션을 다시 시도해야 합니다.
예상되는 데이터 손실: 계획되지 않은 장애 조치(failover) 중에 비동기 복제 지연으로 인해 데이터 손실이 흔히 발생하며, 이는 최근 쓰기가 복제되지 않을 수 있음을 의미합니다. 마지막 동기화 시간 속성을 확인하면 계획되지 않은 장애 조치(failover) 중에 얼마나 많은 데이터가 손실될 수 있는지 파악할 수 있습니다. 예상 데이터 손실을 RPO(복구 지점 목표)라고도 합니다. 일반적으로 RPO가 15분 미만일 것으로 예상할 수 있지만 해당 시간이 보장되지는 않습니다.
예상 가동 중지 시간: 예상 가동 중지 시간의 양을 RTO(복구 시간 목표)라고도 합니다. 고객 관리 장애 조치(failover)는 일반적으로 계정 크기 및 복잡성에 따라 60분 이내에 완료됩니다.
트래픽 경로 변경: 장애 조치(failover)가 완료되면 Azure는 애플리케이션을 다시 구성할 필요가 없도록 스토리지 계정 엔드포인트를 자동으로 업데이트합니다. 애플리케이션이 DNS(Domain Name System) 항목을 캐시에 보관하는 경우 애플리케이션이 새로운 주 지역으로 트래픽을 전송하도록 캐시를 지워야 할 수도 있습니다.
장애 조치(failover) 후 구성: 계획되지 않은 장애 조치(failover)가 완료된 후 대상 지역의 스토리지 계정은 LRS(로컬 중복 스토리지) 계층을 사용합니다. 다시 지리적으로 복제해야 하는 경우 GRS(지역 중복 스토리지)를 다시 사용하도록 설정하고 데이터가 새 보조 지역으로 복제될 때까지 기다려야 합니다.
고객 관리 장애 조치를 시작하는 방법에 대한 자세한 내용은 고객 관리(계획되지 않은) 장애 조치(failover) 작동 방식 및 스토리지 계정 장애 조치(failover) 시작을 참조하세요.
고객 관리 장애 조치(failover)(계획됨): 스토리지가 주 지역에서 계속 작동하지만 다른 이유로 전체 솔루션을 보조 지역으로 장애 조치해야 하는 경우 계획된 장애 조치를 사용합니다. 예를 들어 다른 Azure 서비스에 문제가 발생할 수 있으며 전체 솔루션에 보조 지역을 사용하도록 전환해야 합니다. 또는 계획된 장애 조치를 사용하여 규정 준수 및 감사 목적으로 DR(재해 복구) 훈련을 수행할 수 있습니다.
검색 및 응답: 장애 조치(failover)를 결정할 책임이 있습니다. 스토리지 계정이 정상이더라도 지역 간에 장애 조치(failover)가 필요한 경우 일반적으로 이 결정을 내립니다. 예를 들어 주요 지역에서 복구할 수 없는 다른 애플리케이션 구성 요소의 주요 중단이 있는 경우 장애 조치(failover)를 트리거할 수 있습니다.
알림: 지역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나:
Azure Resource Health를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다.
Azure Service Health를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 장애 조치(failover) 프로세스 중에 읽기 및 쓰기 모두에 대해 기본 및 보조 스토리지 계정 엔드포인트를 일시적으로 사용할 수 없게 됩니다. 활성 요청이 삭제될 수 있으며 장애 조치(failover)가 완료된 후 클라이언트 애플리케이션을 다시 시도해야 합니다.
예상 데이터 손실: 모든 데이터가 동기화된 후에만 장애 조치(failover) 프로세스가 완료되므로 데이터 손실이 발생하지 않으므로 RPO가 0이 됩니다.
예상 가동 중지 시간: 장애 조치(failover)는 일반적으로 60분 이내에 완료됩니다. 즉, 예상 RTO는 계정 크기 및 복잡성에 따라 60분입니다. 장애 조치(failover) 프로세스 중에 읽기 및 쓰기 모두에 대해 기본 및 보조 스토리지 계정 엔드포인트를 일시적으로 사용할 수 없게 됩니다.
트래픽 경로 변경: 장애 조치(failover)가 완료되면 Azure는 애플리케이션을 다시 구성할 필요가 없도록 스토리지 계정 엔드포인트를 자동으로 업데이트합니다. 애플리케이션이 DNS 항목을 캐시한 상태로 유지하는 경우 애플리케이션이 새로운 주 지역으로 트래픽을 전송하도록 캐시를 지워야 할 수도 있습니다.
장애 조치(failover) 후 구성: 계획된 장애 조치(failover)가 완료되면 대상 지역의 스토리지 계정은 계속해서 지리적으로 복제되고 GRS 계층에 유지됩니다.
고객 관리 장애 조치를 시작하는 방법에 대한 자세한 내용은 고객 관리(계획된) 장애 조치(failover) 작동 방식 및 스토리지 계정 장애 조치(failover) 시작을 참조하세요.
Microsoft에서 관리하는 장애 조치(failover): Microsoft에서 주 지역을 영구적으로 복구할 수 없다고 판단하는 대규모 재해가 발생하는 드문 경우 보조 지역에 대한 자동 장애 조치(failover)가 시작될 수 있습니다. Microsoft는 전체 프로세스를 처리하며 고객 작업이 필요하지 않습니다. 장애 조치(failover)가 발생하기 전에 경과되는 시간은 재해의 심각도 및 상황을 평가하는 데 필요한 시간에 따라 달라집니다.
알림: 지역이 다운된 경우 Microsoft는 자동으로 알리지 않습니다. 그러나:
Azure Resource Health를 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고를 설정하여 문제를 알릴 수 있습니다.
Azure Service Health를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
중요합니다
고객이 관리하는 장애 조치 옵션을 사용하여 재해 복구 계획을 개발, 테스트 및 구현합니다. 극단적인 상황에서만 사용될 수 있는 Microsoft 관리 장애 조치(failover)에 의존하지 마세요. Microsoft에서 관리하는 장애 조치(failover)는 전체 지역에 대해 시작될 가능성이 높습니다. 개별 스토리지 계정, 구독 또는 고객에 대해 시작할 수 없습니다. 장애 조치는 서로 다른 Azure 서비스에 대해 각기 다른 시간에 발생할 수 있습니다. 고객 관리 장애 조치(failover)를 사용하는 것이 좋습니다.
지역 복구
장애 복구 프로세스는 Microsoft에서 관리하는 장애 조치(failover) 시나리오와 고객에서 관리하는 장애 조치 시나리오 간에 상당한 차이가 있습니다.
고객 관리 장애 조치(failover)(계획되지 않음): 계획되지 않은 장애 조치 후 스토리지 계정은 LRS(로컬 중복 스토리지)로 구성됩니다. 장애 복구를 수행하려면 GRS(지역 중복 스토리지) 관계를 다시 설정하고 데이터가 복제될 때까지 기다려야 합니다.
고객 관리 장애 조치(failover)(계획됨): 계획된 장애 조치 후 스토리지 계정은 지리적으로 복제된 상태로 유지됩니다. 원래 주 지역으로 장애 복구하기 위해 다른 고객 관리 장애 조치(failover)를 시작할 수 있습니다. 동일한 페일오버 고려 사항이 적용됩니다.
Microsoft 관리 장애 조치(failover): Microsoft에서 장애 조치를 시작하면 주 지역에서 심각한 재해가 발생했을 가능성이 있으며 주 지역을 복구하지 못할 수도 있습니다. 모든 일정이나 복구 계획은 지역 재해와 복구 활동의 범위에 따라 달라집니다. 자세한 내용은 Azure Service Health 통신을 모니터링해야 합니다.
지역 오류 테스트
재해 복구 절차를 테스트하기 위해 지역적 장애를 시뮬레이션할 수 있습니다.
계획된 장애 조치(failover) 테스트: GRS(지역 중복 스토리지) 계정의 경우 유지 관리 기간 동안 계획된 장애 조치 작업을 수행하여 전체 장애 조치 및 장애 복구 프로세스를 테스트할 수 있습니다. 계획된 장애 조치(failover)에는 데이터 손실이 필요하지 않지만 장애 조치와 장애 복구 중에 가동 중지 시간이 발생합니다.
보조 엔드포인트 테스트: RA-GRS(읽기 액세스 지역 중복 스토리지) 및 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지) 구성의 경우 애플리케이션이 보조 지역에서 데이터를 성공적으로 읽을 수 있는지 확인하기 위해 2차 엔드포인트에 대한 읽기 작업을 정기적으로 테스트합니다.
복원력을 위한 사용자 지정 다중 지역 솔루션
Azure Storage의 지역 간 장애 조치(failover) 기능은 다음과 같은 이유로 적합하지 않을 수 있습니다.
스토리지 계정은 비페어링 지역에 있습니다.
기본 제공 장애 조치(failover) 옵션이 제공하는 복구 시간 또는 데이터 손실로 인해 비즈니스 가동 시간 목표가 충족되지 않습니다.
주 지역의 쌍이 아닌 지역으로 장애 조치(failover)를 취해야 합니다.
지역 간에 활성/활성 구성이 필요합니다.
이 섹션에서는 고려해야 할 몇 가지 방법에 대한 개략적인 개요를 제공합니다. Azure Storage에 대한 다중 지역 배포 토폴로지의 포괄적인 개요는 이 문서의 범위를 벗어납니다.
비고
Table Storage를 사용하도록 빌드된 애플리케이션의 경우 Azure Cosmos DB for Table를 사용하는 것이 좋습니다. Azure Cosmos DB for Table는 쌍을 이루지 않는 지역에 대한 지원을 포함하여 고급 다중 지역 요구 사항을 지원합니다. 또한 Table Storage용으로 빌드된 애플리케이션과의 호환성을 위해 설계되었습니다.
각 지역에서 별도의 스토리지 계정을 사용하여 여러 지역에 Azure Storage를 배포할 수 있습니다. 이러한 방식은 영역 선택에 있어 유연성을 제공하고, 쌍이 아닌 지역을 사용할 수 있는 기능과 복제 타이밍 및 데이터 일관성에 대한 보다 세부적인 제어 기능을 제공합니다. 여러 지역에 걸쳐 여러 스토리지 계정을 구현하는 경우 지역 간 데이터 복제를 구성하고, 부하 분산 및 장애 조치(failover) 정책을 구현하고, 지역 간 데이터 일관성을 보장해야 합니다.
Table Storage의 경우 다중 계정 접근 방식을 사용하려면 데이터 배포를 관리하고, 충돌 해결을 포함한 여러 지역의 테이블 간 동기화를 처리하고, 사용자 지정 장애 조치(failover) 논리를 구현해야 합니다.
백업 및 복원
Table Storage는 PITR(특정 시점 복원)과 같은 기존 백업 기능을 제공하지 않습니다. 하지만 테이블 데이터에 대해 사용자 지정 백업 전략을 구현할 수 있습니다.
기본 제공 백업 기능이 필요한 경우 주기적 백업과 지속적인 백업을 모두 지원하는 Azure Cosmos DB for Table로 전환하는 것이 좋습니다. 자세한 내용은 Azure Cosmos DB의 온라인 백업 및 주문형 데이터 복원을 참조하세요.
Table Storage에서 데이터 백업이 필요한 시나리오의 경우 다음 방법을 고려합니다.
Azure Data Factory를 사용하여 내보냅니다. Table Storage용 Azure Data Factory 커넥터를 사용하여 엔터티를 다른 위치로 내보냅니다. 예를 들어 Azure Blob Storage에 저장된 JSON 파일에 각 엔터티를 백업할 수 있습니다.
애플리케이션 수준 백업을 수행합니다. 애플리케이션 내에서 사용자 지정 백업 논리를 구현하여 더 강력한 백업 및 복원 기능을 위해 중요한 테이블 엔터티를 Azure SQL Database 또는 Azure Cosmos DB와 같은 다른 스토리지 서비스로 내보냅니다.
Table Storage에 대한 백업 전략을 설계할 때 데이터의 분할된 특성을 고려하고 백업 프로세스가 여러 파티션을 병렬로 처리하여 큰 테이블을 효율적으로 처리할 수 있는지 확인합니다.
대부분의 솔루션의 경우 백업에만 의존해서는 안 됩니다. 대신 이 가이드에 설명된 다른 기능을 사용하여 복원력 요구 사항을 지원합니다. 그러나 백업은 다른 방법이 사용하지 않는 일부 위험으로부터 보호합니다. 자세한 내용은 중복도, 복제 및 백업이란?을 참조하세요.
서비스 수준 약정
Azure Storage에 대한 SLA(서비스 수준 계약)는 서비스의 예상 가용성 및 해당 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 사용자가 적용할 수 있는 가용성 SLA는 스토리지 계층과 사용하는 복제 형식에 따라 달라집니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.