통합 캐시 사용

  • 10분

통합 캐시 사용

통합 캐시 활성화는 두 가지 기본 단계로 이루어집니다.

  • Azure Cosmos DB for NoSQL 계정에서 전용 게이트웨이 만들기
  • 요청에 대한 게이트웨이를 사용하도록 SDK 코드 업데이트

전용 게이트웨이 만들기

먼저 계정에 전용 게이트웨이를 프로비전해야 합니다. 이 작업은 포털 및 전용 게이트웨이 창을 사용하여 수행할 수 있습니다.

Azure Cosmos DB 블레이드에서 열린 전용 게이트웨이 탐색

프로비전 프로세스의 일환으로 게이트웨이 인스턴스와 SKU의 수를 구성하라는 메시지가 표시됩니다. 이러한 설정은 노드 수와 각 게이트웨이 노드에 대한 컴퓨팅 및 메모리 크기를 결정합니다. 캐시해야 하는 데이터 양이 증가하므로 노드 및 SKU의 수를 나중에 수정할 수 있습니다.

SKU 및 노드 수에 대한 전용 게이트웨이 구성 옵션

새 게이트웨이가 프로비전되면 게이트웨이에 대한 엔드포인트를 가져올 수 있습니다.

참고 항목

게이트웨이 엔드포인트는 Azure Cosmos DB for NoSQL 클라이언트와 함께 사용되는 일반적인 엔드포인트와 다릅니다.

.NET SDK 코드 업데이트

.NET SDK 클라이언트에서 통합 캐시를 사용하려면 다음 세 가지 사항을 충족하는지 확인해야 합니다.

  • 클라이언트는 일반적인 엔드포인트 대신 전용 게이트웨이 엔드포인트를 사용합니다
  • 클라이언트가 기본 직접 연결 모드 대신 게이트웨이 모드를 사용하도록 구성됨
  • 클라이언트의 일관성 수준을 세션 또는 최종 수준으로 설정해야 합니다.

먼저 엔드포인트가 전용 게이트웨이의 엔드포인트로 설정되어 있는지 확인합니다. 일반적으로 Azure Cosmos DB for NoSQL 엔드포인트는 <cosmos-account-name>.documents.azure.com 형식입니다. 전용 게이트웨이의 경우 엔드포인트는 <cosmos-account-name>.sqlx.cosmos.azure.com의 구조에 속합니다.

계정 키를 사용하는 대신 인증에 관리 ID 를 사용하도록 SDK를 구성합니다. 업데이트된 코드는 다음과 같습니다.

using Azure.Identity;
using Microsoft.Azure.Cosmos;

string endpoint = "https://<cosmos-account-name>.sqlx.cosmos.azure.com/";

CosmosClientOptions options = new()
{
    ConnectionMode = ConnectionMode.Gateway,
    ConsistencyLevel = ConsistencyLevel.Session // or ConsistencyLevel.Eventual
};

// Use DefaultAzureCredential to authenticate with managed identity.
CosmosClient client = new(endpoint, new DefaultAzureCredential(), options);

참고 항목

애플리케이션에 관리 ID가 사용하도록 설정되어 있고 관리 ID에 Azure Cosmos DB 계정에 대한 Cosmos DB 기본 제공 데이터 기여자 역할이 부여되었는지 확인합니다.

지점 읽기 작업 구성

통합 캐시를 사용하도록 지점 읽기 작업을 구성하려면 ItemRequestOptions 형식의 개체를 만들어야 합니다. 이 개체에서는 ConsistencyLevel 속성을 ConsistencyLevel.Session 또는 ConsistencyLevel.Eventual 로 수동으로 설정할 수 있습니다. 그런 다음 ReadItemAsync 메서드 호출에서 옵션 변수를 사용할 수 있습니다.

string id = "9DB28F2B-ADC8-40A2-A677-B0AAFC32CAC8";
PartitionKey partitionKey = new("56400CF3-446D-4C3F-B9B2-68286DA3BB99");

ItemRequestOptions requestOptions = new()
{
    ConsistencyLevel = ConsistencyLevel.Session
};

ItemResponse<Product> response = await container.ReadItemAsync<Product>(id, partitionKey, requestOptions: requestOptions);

RU 사용량을 관찰하려면 응답 변수의 RequestCharge 속성을 사용합니다. 이 읽기 작업의 첫 번째 호출은 예상 요청 단위 수를 사용합니다. 이 예제에서는 포인트 리딩 작업에 대한 하나의 RU가 됩니다. 이후 요청은 만료될 때까지 캐시에서 데이터를 끌어올 수 있으므로 요청 단위를 사용하지 않습니다.

Console.WriteLine($"Request charge:\t{response.RequestCharge:0.00} RU/s");

쿼리 구성

통합 캐시를 사용하도록 쿼리를 구성하려면 QueryRequestOptions 형식의 개체를 만듭니다. 이 개체에서는 일관성 수준도 수동으로 변경해야 합니다. 그런 다음 옵션 변수를 GetItemQueryIterator 메서드 호출에 전달합니다.

string sql = "SELECT * FROM products";
QueryDefinition query = new(sql);

QueryRequestOptions queryOptions = new()
{
    ConsistencyLevel = ConsistencyLevel.Eventual
};

FeedIterator<Product> iterator = container.GetItemQueryIterator<Product>(query, requestOptions: queryOptions);

결과의 각 페이지와 연결된 각 FeedResponse 개체의 RequestCharge 속성을 가져오면 RU 사용량을 확인할 수도 있습니다. 요청 요금을 집계하는 경우 전체 쿼리에 대한 총 요청 요금이 청구됩니다. 포인트 리딩과 마찬가지로 첫 번째 쿼리에서는 일반적인 요청 단위 수를 사용합니다. 모든 추가 쿼리는 데이터가 캐시에서 만료될 때까지 요청 단위를 사용하지 않습니다.

double totalRequestCharge = 0;
while(iterator.HasMoreResults)
{
    FeedResponse<Product> response = await iterator.ReadNextAsync();
    totalRequestCharge += response.RequestCharge;
    Console.WriteLine($"Request charge:\t\t{response.RequestCharge:0.00} RU/s");
}

Console.WriteLine($"Total request charge:\t{totalRequestCharge:0.00} RU/s");