다음을 통해 공유

Azure Cosmos DB SDK를 사용하여 복원력 있는 애플리케이션 디자인

  • 아티클

적용 대상: NoSQL

SDK를 통해 Azure Cosmos DB와 상호 작용하는 클라이언트 애플리케이션을 작성할 때 몇 가지 핵심 기본 사항을 이해하는 것이 중요합니다. 이 문서는 이러한 기본 사항을 이해하고 탄력적인 애플리케이션을 설계할 수 있도록 하는 디자인 가이드입니다.

개요

이 문서에서 설명하는 개념에 대한 동영상 개요는 다음을 참조하세요.

연결 모드

Azure Cosmos DB SDK는 두 가지 연결 모드로 서비스에 연결할 수 있습니다. .NET 및 Java SDK는 게이트웨이 및 직접 모드 모두에서 서비스에 연결할 수 있지만 나머지는 게이트웨이 모드에서만 연결할 수 있습니다. 게이트웨이 모드는 HTTP 프로토콜을 사용하고 직접 모드는 일반적으로 TCP 프로토콜을 사용합니다.

게이트웨이 모드는 SDK가 사용하도록 구성된 모드에 관계없이 항상 계정, 컨테이너 및 라우팅 정보와 같은 메타데이터를 가져오는 데 사용됩니다. 이 정보는 메모리에 캐시되며 서비스 복제본에 연결하는 데 사용됩니다.

요약하자면 게이트웨이 모드의 SDK의 경우 HTTP 트래픽을 예상할 수 있는 반면 직접 모드의 SDK의 경우 다양한 상황(예: 초기화, 메타데이터 가져오기 또는 라우팅 정보)에서 HTTP와 TCP 트래픽의 조합을 기대할 수 있습니다.

클라이언트 인스턴스 및 연결

연결 모드에 관계없이 애플리케이션당 계정별로 SDK 클라이언트의 Singleton 인스턴스를 유지 관리하는 것이 중요합니다. HTTP 및 TCP 연결은 클라이언트 인스턴스로 범위가 지정됩니다. 대부분의 컴퓨팅 환경은 동시에 열 수 있는 연결 수에 제한이 있으며 이러한 제한에 도달하면 연결에 영향을 미칩니다.

분산 애플리케이션 및 네트워크

분산 애플리케이션을 설계할 때 세 가지 주요 구성 요소가 있습니다.

  • 애플리케이션과 애플리케이션이 실행되는 환경.
  • 애플리케이션과 Azure Cosmos DB 서비스 엔드포인트 사이의 모든 구성 요소를 포함하는 네트워크.
  • Azure Cosmos DB 서비스 엔드포인트.

오류가 발생하면 종종 이 세 가지 영역 중 하나에 속하며 시스템의 분산 특성으로 인해 이러한 구성 요소에 대해 100% 가용성을 기대하는 것은 비현실적이라는 점을 이해하는 것이 중요합니다.

Azure Cosmos DB에는 포괄적인 가용성 SLA 집합이 있지만 어느 것도 100%는 아닙니다. 애플리케이션을 서비스 엔드포인트에 연결하는 네트워크 구성 요소에는 일시적인 하드웨어 문제가 있고 패킷이 손실될 수 있습니다. 애플리케이션이 실행되는 컴퓨팅 환경에서도 작업에 영향을 미치는 CPU 급증이 있을 수 있습니다. 이러한 실패 조건은 SDK의 작동에 영향을 미칠 수 있으며 일반적으로 특정 코드의 오류로 나타납니다.

애플리케이션은 SDK에서 제공하는 응답에 대해 다시 시도 정책을 구현하여 이러한 구성 요소 전반에 걸쳐 잠재적인 실패의 특정 수준을 회복해야 합니다.

내 애플리케이션이 오류 발생 시 다시 시도해야 하나요?

간단하게 말하면 그렇습니다. 그러나 모든 오류가 다시 시도할 수 있는 것은 아니며 일부 오류 또는 상태 코드는 일시적이지 않습니다. 아래 표에 자세히 설명되어 있습니다.

상태 코드 다시 시도를 추가해야 함 SDK 재시도 설명
400 아니요 아니요 잘못된 요청
401 아니요 아니요 권한 없음
403 선택 사항 아니요 Forbidden
404 아니요 아니요 리소스를 찾을 수 없습니다
408 예 예 요청 시간이 초과되었습니다
409 아니요 아니요 충돌 실패는 쓰기 작업에서 리소스에 제공된 ID(ID 및 파티션 키)가 기존 리소스에 의해 사용되거나 고유 키 제약 조건을 위반한 경우입니다.
410 예 예 사라진 예외(SLA를 위반해서는 안 되는 일시적인 오류)
412 아니요 아니요 필수 조건 실패는 작업이 서버에서 사용 가능한 버전과 다른 eTag를 지정한 경우입니다. 낙관적 동시성 오류입니다. 리소스의 최신 버전을 확인하고 요청의 eTag를 업데이트한 후에 요청을 다시 시도해야 합니다.
413 아니요 아니요 요청 엔터티가 너무 큼
429 예 예 429에서 다시 시도하는 것이 안전합니다. HTTP 429 문제 해결 가이드를 검토합니다.
449 예 예 쓰기 작업에서만 발생하는 일시적인 오류이며 다시 시도하는 것이 안전합니다. 이는 너무 많은 동시 작업이 Azure Cosmos DB에서 동일한 개체를 업데이트하려고 하는 디자인 문제를 나타낼 수 있습니다.
500 아니요 아니요 예기치 않은 서비스 오류로 인해 작업이 실패했습니다. Azure 지원 문제를 제출하여 지원팀에 문의하세요.
503 예 예 서비스를 사용할 수 없음

위의 표에서 두 번째 열에 예로 표시된 모든 상태 코드는 애플리케이션에서 어느 정도의 다시 시도 범위를 가져야 합니다.

HTTP 403

Azure Cosmos DB SDK는 일반적으로 HTTP 403 오류에 대해 다시 시도하지 않지만 애플리케이션이 대응하기로 결정할 수 있는 HTTP 403과 관련된 특정 오류가 있습니다. 예를 들어, 파티션 키가 가득 찼습니다라는 오류가 표시되면 일부 비즈니스 규칙에 따라 작성하려는 문서의 파티션 키를 변경하기로 결정할 수 있습니다.

HTTP 429

Azure Cosmos DB SDK는 클라이언트 구성에 따라 기본적으로 HTTP 429 오류를 다시 시도하고 서비스의 응답 x-ms-retry-after-ms 헤더를 준수하며 지정된 시간을 기다린 후 다시 시도합니다.

SDK 다시 시도를 초과하면 오류가 애플리케이션에 반환됩니다. 이상적으로는 응답에서 x-ms-retry-after-ms 헤더를 검사하여 요청을 다시 시도하기 전에 대기할 시간을 결정하는 힌트로 사용할 수 있습니다. 또 다른 대안은 지수 백오프 알고리즘 또는 HTTP 429에서 다시 시도를 확장하도록 클라이언트를 구성하는 것입니다.

HTTP 449

Azure Cosmos DB SDK는 대부분의 시나리오를 수용하기 위해 고정된 기간 동안 증분 백오프를 사용하여 HTTP 449에서 다시 시도합니다.

자동 SDK 다시 시도를 초과하면 오류가 애플리케이션에 반환됩니다. HTTP 449 오류는 안전하게 다시 시도할 수 있습니다. 쓰기 작업의 동시성이 높기 때문에 고정 간격 후에 동일한 수준의 동시성을 반복하지 않도록 임의 백오프 알고리즘을 사용하는 것이 좋습니다.

네트워크 시간 초과 및 연결 실패는 가장 일반적인 오류 중 하나입니다. Azure Cosmos DB SDK는 자체적으로 탄력적이며 다시 시도가 가능한 경우 HTTP 및 TCP 프로토콜에서 시간 초과 및 연결 문제를 다시 시도합니다.

  • 읽기 작업의 경우 SDK는 시간 초과 또는 연결 관련 오류를 다시 시도합니다.
  • 쓰기 작업의 경우 SDK는 이러한 작업이 멱등성이 아니기 때문에 다시 시도하지 않습니다. 응답을 기다리는 동안 시간 초과가 발생하면 요청이 서비스에 도달했는지 알 수 없습니다.

계정에 사용 가능한 지역이 여러 개인 경우 SDK는 지역 간 다시 시도도 시도합니다.

시간 초과 및 연결 오류의 특성으로 인해 서비스 측에서 발생하는 오류만 다루므로 계정 메트릭에 표시되지 않을 수 있습니다.

애플리케이션에 이러한 시나리오에 대한 자체 다시 시도 정책이 있고 쓰기 시간 초과를 해결하는 방법을 고려하는 것이 좋습니다. 예를 들어 만들기 시간 제한에서 다시 시도하면 이전 요청이 서비스에 도달한 경우 HTTP 409(충돌)가 발생할 수 있지만, 그렇지 않으면 성공합니다.

언어별 구현 세부 정보

언어에 대한 자세한 구현 정보는 다음을 참조하세요.

다시 시도가 대기 시간에 영향을 주나요?

클라이언트 관점에서 다시 시도는 작업의 엔드투엔드 대기 시간에 영향을 줍니다. 애플리케이션 P99 대기 시간이 영향을 받는 경우 발생하는 다시 시도와 이를 해결하는 방법을 이해하는 것이 중요합니다.

Azure Cosmos DB SDK는 어떤 다시 시도가 발생하는지 식별할 수 있도록 하는 자세한 정보를 로그 및 진단에 제공합니다. 자세한 내용은 .NET SDK 진단을 수집하는 방법 및 Java SDK 진단을 수집하는 방법을 참조하세요.

재시도 대기 시간을 완화하려면 어떻게 해야 하나요?

상황에 따라 대부분의 경우 SDK는 로컬 지역, 쓰기 지역(단일 지역 쓰기 시나리오) 또는 기본 지역 목록의 첫 번째 지역으로 요청을 라우팅합니다. 이 우선 순위 지정은 주로 가장 가깝거나 가장 최적의 데이터 센터에 연결하여 정상 시나리오에서 대기 시간을 최소화합니다.

그러나 이 우선 순위는 오류가 발생할 요청이 지정된 오류 시나리오에 대해 항상 특정 지역에서 먼저 시도된다는 것을 의미합니다. 이 시나리오에서 다른 지역으로의 장애 조치(failover)가 선호되는 경우 일반적으로 SDK 수준이 아닌 인프라(트래픽 관리자) 계층에서 처리됩니다. 인프라의 적절한 설정 및 구성을 통해 지역 가동 중단 시 트래픽이 효율적으로 라우팅되도록 할 수 있으므로 중단 시나리오에서 지역 간 재시도와 함께 발생할 수 있는 대기 시간을 완화할 수 있습니다. 인프라 수준 장애 조치(failover)를 설정하는 방법에 대한 자세한 내용은 Azure Traffic Manager 설명서를 참조하세요. 일부 SDK는 SDK 수준에서 직접 유사한 장애 조치(failover) 전략 구현을 지원합니다. 예를 들어 Java SDK의 고가용성을 참조하세요.

지역 가동 중단은 어떤가요?

Azure Cosmos DB SDK는 지역별 가용성을 다루며 다른 계정 지역에서 다시 시도를 수행할 수 있습니다. 다른 지역과 관련된 시나리오를 이해하려면 다중 지역 환경 다시 시도 시나리오 및 구성 문서를 참조하세요.

고객 지원에 연락해야 하는 경우

고객 지원에 문의하기 전에 다음 단계를 따릅니다.

  • 성공한 작업과 비교하여 영향을 받는 작업의 양으로 측정된 영향은 무엇인가요? 서비스 SLA 내에 있나요?
  • P99 대기 시간이 영향을 받나요?
  • 내 애플리케이션에서 다시 시도해야 하는 오류 코드와 관련된 오류가 있으며 애플리케이션에서 이러한 다시 시도를 처리하나요?
  • 오류가 모든 애플리케이션 인스턴스 또는 하위 집합에만 영향을 주나요? 문제가 인스턴스의 하위 집합으로 축소되면 일반적으로 해당 인스턴스와 관련된 문제입니다.
  • 위 표의 관련 문제 해결 문서를 검토하여 애플리케이션 환경의 문제를 배제했나요?

모든 애플리케이션 인스턴스가 영향을 받거나 영향을 받는 작업의 비율이 서비스 SLA를 벗어나거나 자체 애플리케이션 SLA 및 P99에 영향을 미치는 경우 고객 지원에 문의합니다.

다음 단계