Azure Cognitive Search의 안정성

  • 아티클

Azure에서 안정성이란 서비스 중단이나 성능 저하가 발생할 경우 복원력과 가용성을 유지하는 것을 의미합니다. Cognitive Search에서 안정성은 다음과 같은 경우에 달성됩니다.

  • 가용성 영역 지원과 쌍을 이루는 여러 복제본을 사용하도록 서비스를 구성합니다.

  • 여러 지리적 지역에 여러 서비스를 배포합니다.

모든 검색 워크로드는 단일 지리적 지역에서 실행되는 단일 서비스 내에 완전히 포함됩니다. 서비스의 다른 가용성 영역에서 자동으로 실행되는 여러 복제본을 구성할 수 있습니다. 이 기능은 고가용성을 달성하는 방법입니다.

지역 수준에서 비즈니스 연속성 및 재해 복구를 위해 동일한 구성 및 콘텐츠를 갖는 여러 검색 서비스로 구성된 지역 간 토폴로지를 포함하는 전략을 개발해야 합니다. 사용자 지정 스크립트 또는 코드는 갑자기 사용할 수 없게 되면 대체 검색 서비스에 “장애 조치(failover)” 메커니즘을 제공합니다.

고가용성

Cognitive Search 복제본은 인덱스의 복제본입니다. 검색 서비스는 하나 이상의 복제본이 설치되며 최대 12개의 복제본을 가질 수 있습니다. Azure Cognitive Search는 복제본 추가를 통해 한 복제본에 대해 컴퓨터 다시 부팅 및 유지 관리를 수행할 수 있습니다. 반면 쿼리 실행은 다른 복제본에서 계속됩니다.

각 개별 검색 서비스에 대해 Microsoft는 다음 조건을 충족하는 구성에 대해 최소 99.9%의 가용성을 보장합니다.

  • 읽기 전용 작업(쿼리)의 고가용성을 위한 복제본 두 개

  • 읽기/쓰기 작업(쿼리 및 인덱싱)의 고가용성을 위한 복제본 세 개 이상

무료 계층에 대해서는 SLA가 제공되지 않습니다. 자세한 내용은 Azure Cognitive Search에 대한 SLA를 참조하세요.

가용성 영역 지원

가용성 영역은 동일한 지역 안에서 고가용성을 제공하기 위해 지역의 데이터 센터를 개별 실제 위치 그룹으로 구분하는 Azure 플랫폼 기능입니다. Cognitive Search에 대해 가용성 영역을 사용하는 경우 개별 복제본은 영역 할당 단위입니다. 검색 서비스는 한 지역 안에서 실행되며 해당 복제본은 다른 영역에서 실행됩니다.

검색 서비스에 두 개 이상의 복제본을 추가하여 Azure Cognitive Search에서 가용성 영역을 활용할 수 있습니다. 각 복제본은 지역 내의 다른 가용성 영역에 배치됩니다. 가용성 영역보다 많은 복제본이 있는 경우 복제본은 가용성 영역 전체에 최대한 균등하게 분산됩니다. 가용성 영역을 제공하는 지역에서 검색 서비스를 생성한 다음 여러 복제본을 사용하도록 서비스를 구성하는 것 외에는 사용자가 수행해야 하는 특정 작업이 없습니다.

사전 요구 사항

언급한 바와 같이 고가용성을 위해서는 복제본이 여러 개 있어야 합니다. 두 개는 읽기 전용 쿼리 워크로드용이고 세 개는 인덱싱을 포함하는 읽기-쓰기 워크로드용입니다.

서비스는 가용성 영역을 지원하는 지역 내에서 배포되어야 합니다. Azure Cognitive Search는 현재 다음 지역 중 하나에서 표준 계층 또는 이상에 대한 가용성 영역을 지원합니다.

지역 롤아웃
오스트레일리아 동부 2021년 1월 30일 이상
브라질 남부 2021년 5월 2일 이상
캐나다 중부 2021년 1월 30일 이상
인도 중부 2022년 1월 20일 이상
미국 중부 2020년 12월 4일 이상
중국 북부 3 2022년 9월 7일 이상
동아시아 2022년 1월 13일 이상
미국 동부 2021년 1월 27일 이상
미국 동부 2 2021년 1월 30일 이상
프랑스 중부 2020년 10월 23일 이상
독일 중서부 2021년 5월 3일 이상
일본 동부 2021년 1월 30일 이상
한국 중부 2022년 1월 20일 이상
북유럽 2021년 1월 28일 이상
노르웨이 동부 2022년 1월 20일 이상
카타르 중부 2022년 8월 25일 이상
남아프리카 북부 2022년 9월 7일 이상
미국 중남부 2021년 4월 30일 이상
동남아시아 2021년 1월 31일 이상
스웨덴 중부 2022년 1월 21일 이상
스위스 북부 2022년 9월 7일 이상
아랍에미리트 북부 2022년 9월 9일 이상
영국 남부 2021년 1월 30일 이상
US Gov 버지니아 2021년 4월 30일 이상
서유럽 2021년 1월 29일 이상
미국 서부 2 2021년 1월 30일 이상
미국 서부 3 2021년 6월 2일 이상

가용성 영역은 Azure Cognitive Search Service Level Agreement(서비스 수준 약정)에 영향을 미치지 않습니다. 그러나 쿼리 고가용성을 위해서는 3개 이상의 복제본이 필요합니다.

별도의 지역에 있는 여러 서비스

운영 요구 사항에 다음이 포함된 경우 서비스 중복도가 필요합니다.

  • BCDR(비즈니스 연속성 및 재해 복구)(Cognitive Search는 가동 중단 시 즉각적인 장애 조치(failover)를 제공하지 않음).

  • 전 세계 이용 가능 여부. 쿼리 및 인덱싱 요청이 전 세계에서 오는 경우 호스트 데이터 센터에 가장 가까운 사용자가 더 빠른 성능을 갖습니다. 이러한 사용자와 가까운 지역에 추가 서비스를 만들면 모든 사용자의 성능을 균등화할 수 있습니다.

검색 서비스가 두 개 또는 더 필요한 경우 다른 지역에서 생성하면 연속성 및 복구에 대한 애플리케이션 요구 사항을 충족할 수 있을 뿐만 아니라 글로벌 사용자 기반에 대한 더 빠른 응답 시간을 얻을 수 있습니다.

Azure Cognitive Search는 지리적 영역에 걸쳐 검색 인덱스를 자동으로 복제하는 방법을 제공하지 않지만, 이 프로세스를 간단히 구현하고 관리할 수 있는 몇 가지 기술이 있습니다. 이러한 기술은 다음 일부 섹션에 간단히 설명되어 있습니다.

검색 서비스 집합을 지리적으로 분산시키는 이유는 둘 이상의 지역에서 둘 이상의 인덱스를 사용할 수 있게 지원하여, 대기 시간이 최소인 Azure Cognitive Search 서비스로 사용자를 라우팅하기 위해서입니다.

지역별 서비스 크로스탭

여러 서비스를 만들고 데이터 동기화 전략을 설계하여 이 아키텍처를 구현할 수 있습니다. 필요에 따라 라우팅 요청에 Azure Traffic Manager와 같은 리소스를 포함할 수 있습니다.

팁

여러 지역에 여러 검색 서비스를 배포하는 데 대한 도움말은 완전히 구성된 다중 지역 검색 솔루션을 배포하는 GitHub의 이 Bicep 샘플을 참조하세요. 이 샘플에서는 Traffic Manager를 사용하여 인덱스 동기화 및 요청 리디렉션에 대한 두 가지 옵션을 제공합니다.

여러 서비스에서 데이터를 동기화합니다.

두 개 이상의 배포 검색 서비스를 동기화 상태로 유지하기 위한 두 가지 옵션이 있습니다.

옵션 1: 여러 서비스에서 콘텐츠를 업데이트하는 데 인덱서 사용

한 서비스에서 이미 인덱서를 사용하는 경우 두 번째 서비스에 대해 두 번째 인덱서를 구성하여, 같은 데이터 원본 개체를 통해 같은 위치에서 데이터를 끌어올 수 있습니다. 각 지역의 서비스마다 고유한 인덱서 및 대상 인덱스가 있으나(검색 인덱스는 공유되지 않으므로 데이터가 중복됨) 각 인덱서는 동일한 데이터 원본을 참조합니다.

아키텍처의 형태를 간략히 시각적으로 표현하면 다음과 같습니다.

분산 인덱서 및 서비스 조합을 포함하는 단일 데이터 원본

옵션 2: 여러 서비스에서 콘텐츠 업데이트를 푸시하는 데 REST API 사용

Azure Cognitive Search REST API를 사용하여 검색 인덱스에서 콘텐츠를 푸시하는 경우 업데이트가 필요할 때마다 모든 검색 서비스에 변경 내용을 푸시하여 여러 검색 서비스를 동기화된 상태로 유지할 수 있습니다. 코드에서 한 검색 서비스에 대한 업데이트는 실패하고, 다른 검색 서비스에 대한 업데이트는 성공하는 사례를 처리해야 합니다.

Azure Traffic Manager를 사용하여 요청 조정

Azure Traffic Manager를 사용하면 여러 지역에 위치한 웹 사이트로 요청을 라우팅할 수 있습니다. 그러면 이러한 요청은 여러 검색 서비스를 통해 처리될 수 있습니다. Traffic Manager의 장점 중 하나는 Azure Cognitive Search를 검색하여 가용성을 확인하고 서비스가 중단된 경우 사용자를 대체 검색 서비스로 라우팅할 수 있다는 것입니다. 또한 Azure 웹 사이트를 통해 검색 요청을 라우팅하는 경우 Azure Traffic Manager를 사용하면 웹 사이트가 작동하지만 검색이 작동하지 않는 사례의 부하를 분산할 수 있습니다. Traffic Manager를 사용하는 아키텍처의 예는 다음과 같습니다.

지역별 서비스 크로스탭(중앙 Traffic Manager 포함)

데이터 상주

여러 지리적 지역에 여러 검색 서비스를 배포하면 콘텐츠가 선택한 지역에 저장됩니다.

Azure Cognitive Search는 사용자의 권한 부여 없이 데이터를 지정된 지역 외부에 저장하지 않습니다. 특히 보강 캐시, 디버그 세션, 지식 저장소와 같은 기능은 Azure Storage 리소스에 씁니다. 스토리지 계정은 사용자가 제공하는 계정이며 모든 지역에 있을 수 있습니다.

스토리지 계정과 검색 서비스가 모두 동일한 지역에 있는 경우 검색과 스토리지 간의 네트워크 트래픽은 개인 IP 주소를 사용하고 Microsoft 백본 네트워크를 통해 수행됩니다. 개인 IP 주소가 사용되므로 네트워크 보안을 위해 IP 방화벽 또는 프라이빗 엔드포인트를 구성할 수 없습니다. 대신 두 서비스가 동일한 지역에 있는 경우 신뢰할 수 있는 서비스 예외를 대안으로 사용합니다.

재해 복구 및 서비스 중단

SLA(서비스 수준 계약)에 설명된 대로 Microsoft는 Azure Cognitive Search 서비스 인스턴스가 둘 이상의 복제본으로 구성된 경우 인덱스 쿼리 요청에 대해 높은 수준의 가용성을 보장하고, Azure Cognitive Search 서비스 인스턴스가 세 개 이상의 복제본으로 구성된 경우 인덱스 업데이트 요청을 보장합니다. 그러나 재해 복구를 위한 기본 제공 메커니즘은 없습니다. Microsoft의 통제 범위를 벗어나는 치명적인 오류가 발생하더라도 지속적인 서비스가 필요한 경우 다른 지역에서 두 번째 서비스를 프로비전하고 모든 서비스에서 인덱스가 완전히 중복되도록 지리적 복제 전략을 구현하는 것이 좋습니다.

인덱서를 사용하여 인덱스를 채우고 새로 고치는 고객은 동일한 데이터 원본에서 데이터를 검색하는 지역별 인덱서를 통해 재해 복구를 처리할 수 있습니다. 인덱서를 실행하는 서로 다른 지역의 두 서비스는 동일한 데이터 소스에서 인덱싱하여 지리적 중복을 적용할 수 있습니다. 지역 중복 데이터 원본에서 인덱싱하는 경우에는 Azure Cognitive Search 인덱서가 주 복제본에서만 증분 인덱싱을 수행할 수 있습니다(새 문서, 수정된 문서 또는 삭제된 문서에서 업데이트 병합). 장애 조치(failover) 이벤트에서 인덱서를 새로운 주 복제본으로 리디렉션하세요.

인덱서를 사용하지 않는 경우 애플리케이션 코드를 사용하여 개체 및 데이터를 여러 서비스에 동시에 푸시합니다. 자세한 내용은 여러 서비스 간에 데이터를 동기화된 상태로 유지를 참조하세요.

백업 및 복원 대안

Azure Cognitive Search는 기본 데이터 스토리지 솔루션이 아니므로 Microsoft는 셀프 서비스 백업 및 복원에 대한 공식적인 메커니즘을 제공하지 않습니다. 그러나 이 Azure Cognitive Search .NET 샘플 리포지토리의 index-backup-restore 샘플 코드를 사용하여 인덱스 정의와 스냅샷을 일련의 JSON 파일에 백업하고 필요한 경우 이러한 파일을 사용하여 인덱스를 복원할 수 있습니다. 이 도구는 서비스 계층 간에 인덱스를 이동할 수도 있습니다.

그렇지 않으면 인덱스를 만들고 채우는 데 사용되는 애플리케이션 코드는 인덱스를 실수로 삭제하는 경우에 사실상 복원 옵션으로 사용됩니다. 인덱스를 다시 작성하려면 삭제(있다고 가정)하고, 서비스에서 인덱스를 다시 만들고, 기본 데이터 저장소에서 데이터를 검색하여 다시 로드합니다.

다음 단계