내보내기(0) 인쇄
모두 확장

Azure 캐시의 연결 이해 및 관리

업데이트 날짜: 2010년 7월

note참고
응용 프로그램에 대한 올바른 Azure 캐시 제품 선택에 대한 자세한 지침은 내게 적합한 Azure 캐시 기능를 참조하세요.

Microsoft Azure 캐시를 사용하는 응용 프로그램은 대상 캐시에 대한 연결이 열리는 방법을 이해해야 합니다. 각 공유 캐싱 기능에서는 동일한 캐시에 동시에 열릴 수 있는 연결 수의 제한을 다르게 설정할 수 있으므로 이 개념은 Microsoft Azure 공유 캐싱에서 특히 중요합니다. 자세한 내용은 Azure 공유 캐싱 FAQ를 참조하세요.

캐시는 자체 배포의 가상 시스템에서 실행되므로 역할의 역할 내 캐시에는 연결 할당량이 없습니다. 그러나 리소스를 만드는 데 비용이 많이 들 수 있기 때문에 이 전용 시나리오 또는 같은 위치에 배치된 시나리오에서도 연결은 중요한 리소스가 됩니다. 연결을 공유하면 성능을 향상시킬 수 있습니다.

이 항목에서는 연결 관리와 관련된 다음 영역에 대해 다룹니다.

연결이 관리되는 방식은 연결 풀링이 사용하도록 설정되었는지 여부에 따라 다릅니다. 다음 섹션에서는 가능한 두 가지 시나리오와 각 시나리오의 연결 계정에 대한 영향을 설명합니다.

SDK의 2011년 11월 릴리스부터 캐싱에는 연결을 풀링하는 기능이 포함되었습니다. 연결 풀링을 구성할 때는 단일 응용 프로그램 인스턴스에 대해 동일 연결 풀을 공유합니다. 공유되는 연결 수는 maxConnectionsToServer 구성 설정을 통해 결정되며 기본값은 1입니다. 다음 예제에서는 응용 프로그램 구성 파일에서 이 설정을 2로 변경하는 방법에 대해 설명합니다.

  <dataCacheClient maxConnectionsToServer="2">

각 응용 프로그램 인스턴스는 작성되는 DataCacheFactory 개체 수에 관계없이 maxConnectionsToServer로 지정되는 연결을 공유합니다. 따라서 연결 풀링 사용 시의 총 연결 수를 구하는 수식은 maxConnectionsToServer 값 x 해당 역할의 실행 중인 인스턴스 수입니다.

위 예제에서는 단일 캐시 클라이언트 구성을 사용하는 것으로 가정합니다. 이번에는 명명된 dataCacheClient 섹션 두 개가 포함된 다음 공유 캐싱 구성 파일을 살펴보겠습니다.

<dataCacheClients>
  <dataCacheClient name="default" maxConnectionsToServer="2">
    <hosts>
      <host name="ExampleCache.cache.windows.net" cachePort="22233" />
    </hosts>
    <!-- Other Sections -->
  </dataCacheClient>

  <dataCacheClient name="SslEndpoint" maxConnectionsToServer="3">
    <hosts>
      <host name="ExampleCache.cache.windows.net" cachePort="22243" />
    </hosts>
    <!-- Other Sections -->
  </dataCacheClient>
</dataCacheClients>

이 예제에서는 응용 프로그램이 DataCacheFactory 인스턴스를 여러 개 만들 수 있으며, 인스턴스 중 일부는 "default" 구성을 사용하고 나머지는 "SSlEndpoint" 구성을 사용합니다. 연결 풀은 단일 구성과 관련되므로 두 구성이 같은 캐시(ExampleCache)를 가리키더라도 이 캐시에서 사용 가능한 총 연결 수는 해당 maxConnectionsToServer 값의 합계인 5입니다.

역할에서 호스팅되는 역할 내 캐시를 사용하는 경우, 응용 프로그램 구성 파일에서도 연결 풀링이 항상 기본적으로 사용되는 것은 아닙니다. 이는 역할 기반 역할 내 캐시의 알려진 문제입니다. 역할 기반 역할 내 캐시에 연결 풀링이 사용되도록 설정하려면 useLegacyProtocol을 명시적으로 false로 설정해야 합니다. 다음 구성 섹션에는 역할 내 캐시를 호스팅하는 WebRole1이라는 역할에서 이 설정이 사용되는 예제를 설명합니다.

<dataCacheClients>
  <tracing sinkType="DiagnosticSink" traceLevel="Error" />
  <dataCacheClient name="default" useLegacyProtocol="false" >
    <autoDiscover isEnabled="true" identifier="WebRole1" />
  </dataCacheClient>
</dataCacheClients>

이 예제에서는 useLegacyProtocolfalse로 설정되어 있어 연결 풀링을 사용할 수 있습니다. 그렇지 않으면 역할 기반 역할 내 캐시의 연결 풀링이 기본적으로 사용하도록 설정되지 않습니다.

note참고
응용 프로그램 구성 파일을 사용할 때는 최신 SDK에서 연결 풀링이 자동으로 사용하도록 설정됩니다. 프로그래밍 방식으로 DataCacheFactoryConfiguration을 구성하는 경우 연결 풀링이 기본적으로 사용하도록 설정되지 않을 수 있으며 일부 동작이 연결 풀링을 사용하지 않도록 설정할 수 있습니다. 이 항목의 프로그래밍 방식 연결 풀링 구성 섹션을 참조하세요.

연결 풀링이 사용하지 않도록 설정되어 있으면 각 DataCacheFactory 개체에서 하나의 연결을 사용합니다. 열려 있는 연결 수를 제어하는 동시에 최상의 성능을 얻으려면 DataCacheFactory 인스턴스를 초기화하고 저장하는 것이 중요합니다.

연결 풀링을 사용하지 않으면 캐시에 필요한 연결 수가 다음 수식에 의해 정의됩니다.

[DataCacheFactory instances] * [MaxConnectionsToServer setting] * [Azure role instance count]

maxConnectionsToServer는 기본적으로 1입니다. 여러 스레드에서 DataCacheFactory 개체를 공유하는 경우에는 성능을 개선하기 위해 이 설정을 늘릴 수 있습니다. 예를 들어 maxConnectionsToServer2일 경우 각 DataCacheFactory 개체는 두 개의 연결을 사용합니다.

이 시나리오에서는 여러 개의 활성 DataCacheFactory 개체가 각각 maxConnectionsToServer로 지정되는 수의 연결을 사용합니다. 예를 들어 이 값이 2이고 DataCacheFactory 인스턴스가 2개 있으면 총 4개의 연결이 사용됩니다. 이 역할 인스턴스 3개를 실행 중인 경우에는 총 연결 수가 12개로 늘어납니다.

이전에는 위에서 설명한 동작이 기본 동작이었습니다. 그러나 최신 SDK에서는 응용 프로그램 구성 파일을 사용하는 경우 연결 풀링이 기본적으로 사용하도록 설정됩니다. 구성 파일에서 연결 풀링을 사용하지 않도록 설정하려면 connectionPool 특성을 false로 설정합니다. 다음 구성 파일에서 이 설정을 설명합니다.

  <dataCacheClient connectionPool="false">

캐시 클라이언트를 프로그래밍 방식으로 구성하는 경우에는 연결 풀링이 기본적으로 사용되지 않습니다. 프로그래밍 방식 구성과 연결 풀링에 대한 자세한 내용은 다음 섹션인 프로그래밍 방식 연결 풀링 구성을 참조하세요.

캐시 구성 파일 설정을 사용하지 않고 캐시 클라이언트를 프로그래밍 방식으로 구성하면 연결 풀링이 기본적으로 사용하도록 설정되지 않습니다. 이 경우 특수한 단계를 수행하여 코드를 통해 연결 풀링을 사용하도록 설정해야 합니다.

  1. DataCacheFactoryConfiguration 개체를 만들고 Servers, SecurityProperties 등의 표준 설정을 구성합니다.

  2. 정적 메서드 DataCacheFactoryConfiguration. CreateNamedConfiguration을 호출합니다. 이 메서드는 새 구성 이름, 이전에 만든 DataCacheFactoryConfiguration 개체, 그리고 연결 풀링이 사용하도록 설정되어 있는지(true) 아니면 사용하지 않도록 설정되어 있는지(false)를 나타내는 부울 플래그를 전달합니다.

  3. DataCacheFactoryConfiguration 개체를 만듭니다. 이 개체는 연결 풀링이 사용하도록 설정된 새 구성 이름을 생성자에 전달합니다. 새 구성 이름은 이전 단계에서 지정한 이름입니다.

  4. 위의 구성을 사용하는 DataCacheFactory 개체를 만듭니다.

DataCacheFactoryConfiguration Config = new DataCacheFactoryConfiguration();

// Configure the DataCacheFactoryConfiguration with appropriate settings for your cache here:
// ...

// Set the MaxConnectionsToServer to control the size of the connection pool
Config.MaxConnectionsToServer = 3;

// Create a named configuration from this configuration and enable connection pooling
DataCacheFactoryConfiguration.CreateNamedConfiguration("MyConfigWithConnectionPooling", Config, true);

// Create a DataCacheFactoryConfiguration using the new named configuration that enabled connection pooling
DataCacheFactoryConfiguration ConfigWithPooling = new DataCacheFactoryConfiguration("MyConfigWithConnectionPooling");

// Use this new named configuration in the call to DataCacheFactory
DataCacheFactory factory = new DataCacheFactory(ConfigWithPooling);

DataCacheFactoryConfiguration 개체를 만들 때 응용 프로그램 구성 파일의 설정에서 구성을 초기화할 수도 있습니다. 이 방식은 구성 파일과 코드를 모두 사용하여 캐시 클라이언트를 구성하는 조합 방식입니다. 생성자가 비어 있으면 "기본" 구성 섹션을 읽습니다. 문자열이 생성자로 전달되면 명명된 해당 dataCacheClient 섹션이 적용됩니다. 이 시나리오에서는 CreateNamedConfiguration을 호출하는 대신 구성 파일에서 연결 풀링을 사용하도록 설정하여 이 작업을 수행할 수 있습니다.

Warning경고
응용 프로그램 구성 파일에서 DataCacheFactoryConfiguration을 초기화하면 해당 구성에 적용된 변경 내용으로 인해 연결 풀링이 사용하지 않도록 설정될 수 있습니다. 이러한 설정으로는 server, security, compression, maxConnectionsToServer 및 transport 속성이 있습니다. 이 경우 위에서 설명한 대로 CreateNamedConfiguration 메서드를 사용하여 연결 풀링이 사용하도록 설정된 수정된 구성을 기준으로 새 구성을 만들어야 합니다.

역할에서 역할 내 캐시를 사용하도록 설정하면 클라이언트 및 서버의 기본적인 실제 리소스 외에 연결 시 다른 할당량 제한이 적용되지 않습니다. 그러나 연결 풀링을 사용해 연결을 보다 쉽게 다시 사용하고 관리함으로써 성능을 향상시키는 것이 좋습니다.

연결 풀링을 사용하도록 설정하는 경우 기본 maxConnectionsToServer 값인 1이 응용 프로그램에 적합한지 분석해야 합니다. 여러 스레드에서 DataCacheFactory 개체를 사용하는 경우에는 풀의 연결 수를 2개 이상으로 늘리면 성능을 향상시킬 수 있습니다. 물론 연결 수를 늘리는 경우에는 해당 코드를 실행할 역할 인스턴스 수를 기준으로 하는 총 연결 요구 사항에 어떤 영향을 주는지를 계산해야 합니다.

앞에서 설명한 것처럼 개별 명명된 구성은 자체 연결 풀을 사용합니다. 캐시에 대한 총 연결 수를 계산할 때는 이 점을 반드시 이해해야 합니다.

응용 프로그램 구성 파일 설정을 사용할 때와 캐시 클라이언트에 대한 프로그래밍 방식 구성을 사용할 때의 기본 연결 풀링 차이를 파악해야 합니다. 이러한 차이에 대한 설명은 이 항목의 이전 섹션에 나와 있습니다. 프로그래밍 구성은 복잡하기 때문에 구성 파일(app.config 또는 web.config)을 통해 캐시를 구성하여 연결 풀링을 사용하는 것이 더 쉽습니다.

이전 SDK 버전을 사용하는 경우 또는 연결 풀링을 수동으로 사용하지 않도록 설정하는 경우에도 코드에서 최소한의 DataCacheFactory 개체를 만들어 저장하고 다시 사용해야 합니다. 그러면 각 캐시 작업에 대해 새 연결을 설정하지 않아도 되므로 성능이 향상됩니다. 또한 연결 수를 더 효율적으로 관리할 수 있습니다. 마찬가지로 여러 스레드에서 동일한 DataCacheFactory 개체를 공유하는 경우에는 maxConnectionsToServer 값을 늘리면 성능을 향상시킬 수 있습니다. 연결 풀링을 사용하지 않도록 설정하는 경우에는 활성 DataCacheFactory 개체 수, maxConnectionsToServer 설정 및 역할 인스턴스 수를 세심하게 모니터링해야 합니다. 이러한 모든 요인을 통해 사용되는 활성 연결 수가 결정됩니다.

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2014 Microsoft