영업: 1-800-867-1380

Azure 캐시의 Memcached 래퍼

업데이트 날짜: 2014년 9월

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

Memcache란 데이터베이스에 대한 부담을 없앰으로써 대형 웹 응용 프로그램의 속도를 향상시키는 데 사용되는 분산형 메모리 내 캐싱 솔루션입니다. Memcache는 대규모 인터넷 웹 사이트에서 대부분 사용되고 있으며 혁신적인 방법으로 다른 기술과 통합되어 있습니다.

Azure에서는 Memcache 프로토콜을 지원하므로 기존 Memcache가 구현되어 있는 사용자가 Azure로 손쉽게 마이그레이션할 수 있습니다. 응용 프로그램에서 Memcache를 이미 사용하는 경우 이 코드를 새 코드로 대체할 필요가 없습니다.

Azure 캐싱을 Memcache로 실행하면 예컨대 작업자 역할에서 Memcache 자체만 실행하는 것보다 더 효율적입니다. 그 이유는 Azure 캐싱에서 점진적 종료, HA(고가용성), 로컬 캐싱(클라이언트 심), 알림(클라이언트 심), 데이터 일관성 및 클라이언트에 투명하게 실행되는 편리한 확장/축소 등의 부가 기능을 제공하기 때문입니다. 예를 들어 Memcache가 포함된 Azure 캐싱의 서버 해시 방법 및 파티션 관리 기능을 사용하면 부하 분산 작업에 도움이 되고 데이터 일관성을 유지할 수 있습니다.

Azure 캐싱은 Memcache 유선 프로토콜을 지원합니다. 이 프로토콜에는 두 가지 버전, 즉 이진 버전과 텍스트 버전이 있습니다.

Azure 캐싱은 이 프로토콜과 자체 유선 프로토콜을 지원합니다. Memcache 클라이언트는 Azure와 호환되어야 합니다. Azure 캐싱은 다른 Memcache의 구현을 지원하는 거의 모든 API를 지원합니다.

따라서 사용자가 Memcache 응용 프로그램을 Azure로 가져오면 Memcache가 구현된 Azure에서 응용 프로그램을 가리켜 응용 프로그램을 추가로 수정하지 않고 있는 그대로 사용합니다.

Memcache는 두 가지 개발자 환경, 즉 “서버 게이트웨이” 사용 환경과 “클라이언트 심” 사용 환경을 지원합니다.

구현, 배포 및 개념 파악 측면에서 볼 때 서버 게이트웨이는 간단하지만 아래 자세히 설명되어 있는 몇 가지 중요한 선택 사항도 포함하고 있습니다.

서버 게이트웨이를 사용하는 경우 서버 캐시 클러스터는 Memcache 소켓에서 수신 대기합니다. 즉 소켓을 열고 Memcache 프로토콜에서 패킷을 수신 대기합니다. 변환 계층이 없습니다(아래 설명 참조).

이 기능을 설정하려면 캐시 클러스터에서 내부 끝점을 추가로 열고 이름을 지정한 다음 Memcache 포트로 만듭니다. 이 포트에 바인딩되는 모든 트래픽은 Memcache 프로토콜을 통해 받게 됩니다.

하지만 서버 게이트웨이를 사용하면 클라이언트 심 시나리오를 사용했을 때와 비교해 고성능이 필요한 시나리오에서 성능이 저하됩니다. 그 이유는 Memcache 구현의 해싱 구현 방식이 Azure 캐싱의 해싱 구현 방식과 다르기 때문입니다. Memcache 구현의 해싱 방법은 캐시 클라이언트에 따라 결정됩니다. Azure에서는 캐시 서버가 해시를 생성합니다. Azure 캐시 동작에서는 캐시 서버가 해시 동작을 지정할 수 있습니다. 이를 통해 서버에서 부하를 분산하고 확장 및 축소하며 데이터 손실이 발생하지 않도록 하는 등의 작업을 수행할 수 있습니다.

Azure에서 항목을 캐시하면 이 항목의 키에 따라 해시가 생성됩니다. Azure에서는 이 해시를 사용하여 캐시된 항목을 캐시 클러스터의 어떤 서버에 포함할지 결정합니다. 결과적으로 Azure 서버 게이트웨이는 키를 다시 해시한 후 이 항목을 캐시 클러스터의 대상 서버로 라우팅해야 합니다. 이 작업에서는 네트워크 홉이 추가로 발생되므로 성능이 저하됩니다.

Memcache 클라이언트 심은 캐시에 액세스하는 클라이언트에 설치됩니다. 이는 일반적으로 자체 응용 프로그램이 있는 Azure 역할입니다. 클라이언트 심은 로컬 캐시를 지원합니다.

이 심은 변환 계층으로, Memcache 클라이언트 호출을 Azure 캐싱 API로 변환합니다. 심은 Memcache 프로토콜 처리기와 Azure 캐싱 클라이언트의 두 부분으로 구성됩니다. 변환 계층인 심은 Azure 캐싱 API에 대한 Get/Put 호출이 만들어지는 클라이언트 자체에 설치됩니다.

Memcache 클라이언트가 localhost를 Memcache 서버로 가리키면, Azure의 캐시 서버 대신 심의 로컬 인스턴스에서 Put 작업이 처음 처리됩니다. 그런 다음 심은 캐시 클러스터에서 올바른 대상 서버를 확인하고 Put 작업을 Azure로 리디렉션합니다.

따라서 서버 게이트웨이 시나리오에서 추가로 네트워크 홉이 발생되지 않습니다. 하지만 이 심을 구해서 응용 프로그램에 설치해야 하는 번거로움이 있습니다.

캐싱에는 같은 위치에 배치된 캐싱 역할과 전용 캐시 역할의 두 가지 토폴로지가 있습니다.

캐시 클러스터를 전용 캐시 작업자 역할에 배포할 경우 캐시 클라이언트의 Memcache 심을 사용합니다. 이 방식을 사용하면 성능이 향상되고 자동 검색 코드가 실행되지 않습니다.

같은 위치에 배치된 캐싱을 사용하고 캐시 클라이언트가 동일한 역할에서 호스팅되는 경우에는 Memcache 서버 게이트웨이를 사용합니다. 클라이언트 심을 사용할 때는 추가적인 계층 처리 작업과 리디렉션이 포함되는데, 동일한 역할 내에서 캐시를 액세스할 때는 이러한 작업이 필요하지 않습니다. 리디렉션을 추가하면 불필요한 오버헤드가 늘어납니다.

서버 게이트웨이나 클라이언트 심을 사용하기 위한 프로그래밍 모델은 없습니다. 구성 설정만 변경하면 됩니다. 하지만 클라이언트 심의 경우 설치 작업도 필요합니다.

서버 게이트웨이나 클라이언트 심을 사용하는 일은 프로그래밍 모델 작업이라기보다 배포 작업에 휠씬 더 가깝습니다. 동일한 Get 또는 Put API를 계속 호출하는 프로그래머에게는 응용 프로그램이 약간 다르게 유선화된 것일 뿐입니다. 이제 원래의 캐싱 서버에서 응용 프로그램을 가리키는 대신 서버 게이트웨이나 클라이언트 심에서 가리키게 됩니다.

마지막으로, 표준 Memcache 구현 시 동일한 프로토콜을 사용하기 때문에 서버 게이트웨이와 클라이언트 심은 사용될 Memcache 클라이언트 라이브러리의 영향을 받지 않습니다. 캐시 서버는 Memcache 클라이언트 구현 자체가 아니라 표준 Memcache 프로토콜을 따르는 데이터 패킷과 관련되어 있습니다.

  1. 캐시 서버를 호스팅할 역할에서 역할 속성의 캐싱 탭으로 이동합니다.

  2. “캐싱 사용” 확인란을 선택합니다. 그러면 csdef에 입력 끝점과 importModule 요소, 기타 csdef/cscfg 설정이 추가됩니다. 그런 다음 배포 시 끝점 탭에서 "memcache_default"라는 입력 끝점을 수동으로 추가합니다.

  3. 이제 이 클러스터를 가리키도록 클라이언트를 구성해야 합니다. 같은 위치에 배치된 캐싱 서버 게이트웨이를 사용하거나 전용 캐싱 클라이언트 심을 사용하는 경우 응용 프로그램이 “localhost_thisrolename”을 가리키도록 하기만 하면 됩니다. 자동 검색은 필요하지 않습니다.

  1. Memcache 클라이언트가 있는 역할에서 역할 이름을 마우스 오른쪽 단추로 클릭하고 “라이브러리 패키지 참조 추가”를 선택하여 NuGet 창을 시작합니다.

  2. "Azure 캐싱 Memcache 심"을 검색합니다. 이 NuGet 패키지를 설치합니다.

  3. 이 패키지는 시작 작업을 만들고 memcache_default의 내부 끝점을 추가해 11211에 매핑하며 해당 dataCacheClients 섹션을 App.config 및 web.config에 추가합니다. 이 설정은 내부 끝점 탭에서 변경할 수 있습니다.

  4. App.config 또는 Web.config의 autoDiscovery 요소에 역할 이름을 입력합니다.

  5. 그러면 클라이언트가 이 심을 "가리키도록" 구성되어야 합니다. Memcache 클라이언트 구성을 편집하여 서버를 “localhost”로 설정합니다. 올바른 포트 번호도 설정해야 합니다.

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft