Azure AI 검색의 안정성

  • 아티클

Azure에서 안정성이란 서비스 중단이나 성능 저하가 발생할 경우 복원력과 가용성을 의미합니다. Azure AI 검색에서는 단일 서비스 내에서 또는 별도의 지역에 있는 여러 검색 서비스를 통해 안정성을 얻을 수 있습니다.

  • 단일 검색 서비스를 배포하고 고가용성을 위해 스케일 업합니다. 여러 복제본을 추가하여 더 높은 인덱싱 및 쿼리 워크로드를 처리할 수 있습니다. 검색 서비스가 가용성 영역을 지원하는 경우 복제본은 추가적인 복원력을 위해 다양한 물리적 데이터 센터에 자동으로 프로비전됩니다.

  • 여러 지리적 지역에 여러 검색 서비스를 배포합니다. 모든 검색 워크로드는 단일 지역에서 실행되는 단일 서비스 내에 완전히 포함되지만 다중 서비스 시나리오에서는 콘텐츠가 모든 서비스에서 동일하도록 동기화하는 옵션이 있습니다. 또한 부하 분산 솔루션을 설정하여 요청을 재배포하거나 서비스 중단이 있는 경우 장애 조치(failover)할 수 있습니다.

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

고가용성

Azure AI 검색에서 복제본은 인덱스의 복사본입니다. 검색 서비스는 최소 1개의 복제본으로 시작되며 최대 12개의 복제본을 보유할 수 있습니다. Azure AI 검색은 복제본 추가를 통해 한 복제본에 대해 컴퓨터 다시 부팅 및 유지 관리를 수행할 수 있습니다. 반면 쿼리 실행은 다른 복제본에서 계속됩니다.

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

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

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

시스템에는 복제본 상태 및 파티션 무결성을 모니터링하기 위한 내부 메커니즘이 있습니다. 복제본과 파티션의 특정 조합을 프로비전하는 경우 시스템은 서비스에 대한 용량 수준을 보장합니다.

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

가용성 영역 지원

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

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

필수 조건

  • 서비스 계층은 표준 이상이어야 합니다.
  • 서비스 지역은 사용 가능한 영역(다음 섹션에 나열됨)이 있는 지역에 있어야 합니다.
  • 구성에는 여러 복제본이 포함되어야 합니다. 두 개는 읽기 전용 쿼리 워크로드용이고 세 개는 인덱싱을 포함하는 읽기-쓰기 워크로드용입니다.

지원되는 지역

가용성 영역에 대한 지원은 인프라 및 스토리지에 따라 달라집니다. 현재 2023년 10월에 발표된 두 영역에는 스토리지가 부족하며 Azure AI 검색에 대한 가용성 영역을 제공하지 않습니다.

  • 이스라엘 중부
  • 이탈리아 북부

그렇지 않은 경우 Azure AI 검색에 대한 가용성 영역은 다음 지역에서 지원됩니다.

지역 롤아웃
오스트레일리아 동부 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 AI 검색 Service Level Agreement(서비스 수준 약정)의 조건을 변경하지 않습니다. 그러나 쿼리 고가용성을 위해서는 3개 이상의 복제본이 필요합니다.

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

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

  • BCDR(비즈니스 연속성 및 재해 복구) 요구 사항(Azure AI 검색은 가동 중단이 발생한 경우 즉각적인 장애 조치(failover)를 제공하지 않음).

  • 전 세계적으로 분산된 애플리케이션에 대한 빠른 성능. 쿼리 및 인덱싱 요청이 전 세계에서 오는 경우 호스트 데이터 센터에 가장 가까운 사용자가 더 빠른 성능을 경험하게 됩니다. 이러한 사용자와 가까운 지역에 더 많은 서비스를 만들면 모든 사용자의 성능을 균등화할 수 있습니다.

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

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

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

Cross-tab of services by region

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

팁

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

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

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

두 옵션 중 하나를 구성하려면 지역 및 인덱싱 전략에 맞게 수정된 azure-search-multiple-region 리포지토리의 샘플 Bicep 스크립트를 사용하는 것이 좋습니다.

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

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

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

Single data source with distributed indexer and service combinations

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

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

쿼리 요청 리디렉션 또는 장애 조치(failover)

요청 수준에서 중복성이 필요한 경우 Azure는 여러 가지 부하 분산 옵션을 제공합니다.

  • Azure Traffic Manager는 여러 검색 서비스의 지원을 받는 여러 지역에 위치한 웹사이트로 요청을 라우팅하는 데 사용됩니다.
  • Application Gateway는 애플리케이션 계층에서 한 지역의 서버 간 부하 분산에 사용됩니다.
  • Azure Front Door는 웹 트래픽의 글로벌 라우팅을 최적화하고 전역 장애 조치(failover)를 제공하는 데 사용됩니다.

부하 분산 옵션을 평가할 때 유의해야 할 몇 가지 사항은 다음과 같습니다.

  • 검색은 클라이언트의 쿼리 및 인덱싱 요청을 수락하는 백 엔드 서비스입니다.

  • 클라이언트에서 검색 서비스로의 요청은 인증되어야 합니다. 검색 작업에 액세스하려면 호출자에게 역할 기반 권한이 있거나 요청에 대한 API 키를 제공해야 합니다.

  • 서비스 엔드포인트는 기본적으로 공용 인터넷 연결을 통해 연결됩니다. 가상 네트워크 내에서 시작되는 클라이언트 연결에 대한 프라이빗 엔드포인트를 설정하는 경우 Application Gateway를 사용합니다.

  • Azure AI 검색은 <your-search-service-name>.search.windows.net 엔드포인트로 전달된 요청을 수락합니다. 호스트 헤더에 다른 DNS 이름(예: CNAME)을 사용하여 동일한 엔드포인트에 도달하면 요청이 거부됩니다.

Azure AI 검색은 기본 엔드포인트가 실패할 경우 요청 리디렉션에 Azure Traffic Manager를 사용하는 다중 지역 배포 샘플을 제공합니다. 이 솔루션은 동일한 지역의 검색 서비스만 호출하는 검색 지원 클라이언트로 라우팅할 때 유용합니다.

Azure Traffic Manager는 특정 라우팅 방법(예: 우선 순위, 성능 또는 지리적 위치)을 기반으로 여러 엔드포인트 간에 네트워크 트래픽을 라우팅하는 데 주로 사용됩니다. DNS 수준에서 작동하여 들어오는 요청을 적절한 엔드포인트로 전달합니다. Traffic Manager가 서비스하는 엔드포인트가 요청을 거부하기 시작하면 트래픽이 다른 엔드포인트로 라우팅됩니다.

Traffic Manager는 Azure AI 검색에 직접 연결하기 위한 엔드포인트를 제공하지 않으므로 Traffic Manager 바로 뒤에 검색 서비스를 배치할 수 없습니다. 대신 요청이 Traffic Manager로, 검색 지원 웹 클라이언트로, 마지막으로 백 엔드의 검색 서비스로 흐른다고 가정합니다. 클라이언트와 서비스는 동일한 지역에 있습니다. 검색 서비스가 중단되면 검색 클라이언트가 실패하기 시작하고 Traffic Manager가 나머지 클라이언트로 리디렉션됩니다.

Search apps connecting through Azure Traffic Manager

다중 지역 배포의 데이터 상주 정보

다양한 지역에 여러 검색 서비스를 배포하면 콘텐츠는 각 검색 서비스에 대해 선택한 지역에 저장됩니다.

Azure AI 검색은 사용자의 권한 부여 없이 데이터를 지정된 지역 외부에 저장하지 않습니다. 권한 부여는 Azure Storage 리소스에 쓰는 기능(보강 캐시, 디버그 세션, 지식 저장소)을 사용하는 경우 암시적으로 이루어집니다. 모든 경우에 스토리지 계정은 사용자가 선택한 지역에서 제공하는 계정입니다.

참고 항목

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

서비스 중단 및 재해 이벤트 정보

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

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

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

백업 및 복원 대안

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

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

다음 단계