Azure Microservices 및 App Services 개발 NCache
녹화된 웨비나
론 후세인과 아담 J. 켈러
최대 부하에서 실행되도록 Azure 클라우드 앱의 성능과 확장성을 최적화합니다. 빠르고 확장 가능한 공통 데이터 리포지토리를 사용하여 데이터 또는 세션 손실 없이 Azure 서비스 애플리케이션 환경을 개선하세요.
이 웨비나는 Azure Microservices 및 App Services를 클라우드의 .NET 분산 캐시와 통합하는 방법을 보여줍니다.
우리는 다음을 다룰 것입니다:
- Azure Microservices 및 App Services 소개
- NuGet 패키지 사용 NCache 클라이언트 애플리케이션 리소스
- 유튜브 영상을 만드는 것은 NCache Azure 서비스의 API 호출
- Azure에서 분산 캐시 생성 및 배포
- Azure 서비스에 캐시 사용
- Azure Microservices 및 App Services를 실행하는 캐시 모니터링
오늘 선택한 주제는 NCache Azure 서비스 내부의 주요 분산 캐싱 시스템입니다. 오늘 저의 주요 초점은 Azure 마이크로서비스가 될 것입니다. 마이크로 서비스의 아키텍처 세부 사항에 대해 이야기하겠습니다. 마이크로 서비스에 분산 캐시가 필요한 이유와 제한 사항에 대한 몇 가지 세부 사항에 대해 설명한 다음 웹 애플리케이션에 분산 캐싱 시스템이 필요할 수 있는 앱 서비스 Microsoft Azure 웹 애플리케이션 서비스 프로젝트에 대해서도 설명하겠습니다. 데이터 처리, 세션, 출력 캐싱. 그런 종류의 기능을 강조하겠습니다. 오늘 다룰 주요 의제인 이 웨비나의 실습 부분은 배포 아키텍처에 중점을 둘 것입니다. 분산 캐시가 배포되는 방식과 애플리케이션이 캐시에 연결해야 하는 정확도.
Azure 마이크로서비스 및 앱 서비스
먼저 Azure 마이크로 서비스 및 앱 서비스에 대한 몇 가지 소개 세부 정보에 대해 이야기하겠습니다.
마이크로서비스란 무엇입니까?
마이크로서비스란 무엇입니까? 그래서 이것은 우리가 요즘 많이 듣는 아주 흔한 용어입니다. Microsoft Azure에서 제공하는 플랫폼입니다. 일부 AWS가 있고 일부 타사 공급자도 있습니다. 일반적으로 Java에서 매우 인기 있는 플랫폼이기도 한 Akka.NET이라는 이름을 지정한 다음 .NET에도 적용했습니다. 마이크로서비스는 고객의 비즈니스 시나리오를 캡슐화하는 플랫폼이며 고객이 애플리케이션 내에서 겪고 있는 특정 문제를 처리합니다. 따라서 소규모 엔지니어링 팀에서 개발할 수 있습니다. 모든 프로그래밍 언어로 작성할 수 있습니다.
stateful일 수 있고 stateless일 수 있지만 애플리케이션 내에서 독립적인 것입니다. 따라서 독립적으로 버전 지정, 구현, 배포할 수 있으며 마이크로 서비스 아키텍처의 장점은 독립적으로 확장할 수 있다는 것입니다. 전체 애플리케이션을 확장할 필요가 없습니다. 애플리케이션 내에서 이러한 특성을 충족하는 부분이라면 마이크로서비스로 구현할 수 있습니다. 애플리케이션에서 이를 마이크로서비스 리소스로 사용할 수 있으며 전체 애플리케이션 확장성에 대해 걱정할 필요 없이 이 특정 부분을 확장할 수 있습니다. 따라서 애플리케이션 내의 다양한 세그먼트에 대해 보다 세분화된 접근 방식을 제공합니다.
마이크로 서비스가 잘 정의된 인터페이스 프로토콜이며 다른 마이크로 서비스와도 상호 작용한다는 두 가지 공통점을 강조했습니다. 그런 다음 Microsoft Azure에서 얻을 수 있는 고유한 이름을 가지며 오류 발생 시 일관성을 유지하고 사용할 수 있어야 합니다. 이것이 마이크로서비스의 또 다른 중요한 특성입니다. 이것은 Microsoft MSDN 웹 사이트에서 복사한 것입니다. 따라서 모두가 마이크로서비스가 무엇인지 알고 있다고 확신합니다. 따라서 이것은 마이크로서비스에 대한 몇 가지 기본 세부 정보를 다루어야 합니다. 알겠죠?
마이크로소프트 애저 서비스 패브릭
다음은 애플리케이션 유형에 상태 저장 또는 비저장일 수 있는 서비스 유형이 있는 다이어그램입니다. 이미 다뤘습니다.
자체 마이크로서비스를 가질 수 있는 또 다른 애플리케이션 유형이 있으며 구성을 위해 코드에 대해 일부 백엔드 데이터 소스와 통신할 수 있습니다. 웹 서비스를 호출할 수 있습니다. 또한 액세스해야 하는 일부 데이터가 있을 수 있습니다. 그러면 이러한 데이터가 포함됩니다. 이것은 마이크로서비스가 어떻게 아키텍처되는지에 대한 아이디어일 뿐입니다. 여러 애플리케이션이 있을 수 있고 각 애플리케이션에는 여러 마이크로서비스가 있을 수 있으며, 이는 다시 서버 클러스터, 인스턴스 클러스터입니다. 마이크로 서비스 내에 파티션이 있을 수 있습니다. 이는 주로 상태 저장 마이크로 서비스입니다. 여러 마이크로 서비스가 있는 경우 상태 저장 또는 상태 비저장 마이크로 서비스를 선택할 수 있습니다.
상태 저장 마이크로 서비스인 경우 데이터 파티션이 있고 다른 파티션의 복제본이 있습니다. 따라서 파티션이 다운되면 자동으로 백업을 사용할 수 있게 됩니다. 따라서 이것은 Microsoft Azure의 일부이며 마이크로서비스 아키텍처의 일반적인 부분이기도 하며 Amazon이 제공하는 Akka.NET도 같은 종류의 질문 형식을 가지고 있습니다. 따라서 마이크로 서비스는 기본적으로 아키텍처 내에서 자체적으로 상태를 제공하는 것입니다. 따라서 다음과 같은 분산 캐싱이 정확히 필요한 부분을 강조하겠습니다. NCache. 분산 캐시가 필요하고 몇 가지 병목 현상이 있는 이유는 분산 캐시가 이 웨비나의 일부로 해결하는 데 도움이 될 몇 가지 문제입니다.
Azure Web App Services 소개
그런 다음 Azure 웹 응용 프로그램 서비스에 대해서도 이야기하겠습니다. Microsoft Azure에서 웹 애플리케이션을 배포하는 것이 더 쉽습니다.
전체 VM이 없어도 됩니다. 실제로 DevOps 시간, 필요한 전문 지식의 양, 소요 시간을 줄여줍니다. 관리되는 것입니다. 따라서 Microsoft Azure에 배포된 인스턴스 기반 애플리케이션을 얻을 수 있습니다. 애플리케이션을 위한 완전히 격리된 전용 환경입니다. 확장할 수 있습니다. 여러 애플리케이션을 호스팅할 수 있습니다. 모바일 앱, 웹 또는 함수 앱이 될 수 있습니다. 이 시점에서 필요한 것은 Microsoft Azure 웹 앱 서비스 모델을 사용하여 사용할 수 있습니다.
그리고 확장성이 뛰어납니다. 이미 격리가 보장된다고 언급했습니다. 보안 네트워크 액세스를 얻을 수 있으며 높은 메모리 사용률과 필요한 기타 리소스도 사용할 수 있습니다. 그리고 이것은 대부분의 배포가 실제로 수행하는 전환입니다. 전체 VM이 웹 형식으로 애플리케이션을 호스팅하거나 전체 VM을 관리해야 하는 웹 가든 시나리오 대신 인스턴스 기반 접근 방식을 사용할 수 있습니다. 여기서 서비스 기반 응용 프로그램을 배포할 수 있으며 데이터베이스 호출을 사용할 수 있는 세션을 사용할 수 있는 일반적인 MVC 응용 프로그램이 될 수 있습니다. 따라서 모든 종류의 일반 MVC 웹 응용 프로그램 관련 개념이지만 배포가 약간 다를 뿐입니다.
분산 캐싱
이제 Azure 마이크로서비스와 Azure 웹 애플리케이션 서비스를 정의했습니다. 맞죠? 따라서 Microsoft Azure의 마이크로 서비스는 서비스 패브릭 프로젝트인 반면 웹 앱 서비스는 앱 서비스 프로젝트입니다. 따라서 이에 대한 세부 사항을 강조하고 분산 캐시에서 사용하기 위해 필요한 네트워킹 부분에 대해 이야기하겠습니다.
메모리 내 분산 캐시란 무엇입니까?
먼저 일반적으로 분산 캐싱 개념에 대해 이야기하겠습니다.
분산 캐시란 무엇입니까? 분산 캐시는 메모리용으로 함께 풀링되는 저렴한 캐싱 서비스 클러스터이며, 계산 능력을 위한 리소스와 그 다음 저장 능력, 분산 캐시의 경우 주 저장소를 나타내는 메모리입니다. 따라서 모든 메모리 리소스를 논리적 용량으로 풀링합니다.
그런 다음 모든 캐시 서버에서 캐시 업데이트를 동기화할 수 있습니다. 예를 들어, 주어진 서버에 적용된 모든 업데이트는 모든 캐싱 서버에 적용됩니다. 따라서 분산 캐시는 논리적 용량으로 함께 결합되는 저렴한 여러 캐시 서버의 클러스터입니다. Microsoft Azure에 여러 서버가 있으며 VM이 될 것입니다. 그래서, NCache 가상 머신에 배포됩니다. 이것은 현재 배포 옵션입니다. NCache docker에서도 배포할 수 있습니다. 이것은 또 다른 배포 옵션입니다. 따라서 VM에서 실행되는 캐시 서버는 Microsoft Azure 내에서 별도의 리소스로 처리되며 이는 일반적인 배포입니다. NCache 서버 측 구성이 관련됩니다.
분산 캐시의 다음 특징은 모든 캐싱 서버에서 모든 캐시 업데이트를 동기화해야 한다는 것입니다. 2 3 4 캐싱 서버가 있을 수 있으며 데이터에 대한 일관된 보기가 있어야 합니다. 데이터는 연결된 모든 애플리케이션에 대해 동일한 상태로 표시되어야 합니다.
그리고 용량이 증가함에 따라 메모리 및 트랜잭션에 대해 선형으로 확장되어야 할 수 있습니다. 더 많은 스토리지가 필요하고 더 많은 캐싱 서버를 도입하기만 하면 선형적으로 확장되어야 합니다. 그리고 .. 그런 다음 복제는 데이터를 복제해야 하는 또 다른 부분입니다. 서버가 다운되면 추가되는 모든 데이터는 자동으로 복제되어야 합니다. 복제는 작업에 따라 수행되어야 하며 서버가 다운된 경우 데이터를 사용할 수 있어야 합니다.
이것이 분산 캐시의 몇 가지 일반적인 특성입니다.
데이터 스토리지는 확장성 병목 현상입니다.
일반적으로 애플리케이션은 일부 백엔드 데이터 소스와 통신할 수 있는 앱 서비스, 마이크로서비스입니다. Microsoft Azure에서는 동일한 V net 또는 cross V net에 있을 수 있지만 여전히 데이터베이스 서버와 통신하는 후속 서버 인스턴스를 가질 수 있습니다.
따라서 속도가 느리고 확장성이 좋지 않을 수 있습니다. 따라서 Microsoft Azure에서도 분산 캐싱 계층을 도입하는 것이 더 합리적입니다. 그리고 마이크로서비스 인앱 서비스와 관련된 사용 사례에 대해서도 이야기하겠습니다.
NCache 전개
이것은 일반적인 배포입니다. NCache.
따라서 Microsoft Azure에는 수평으로 확장되는 VM이 있습니다. 가상 네트워크를 만들고 VM을 만든 다음 설치할 수 있습니다. NCache 해당 VM에서 사용하거나 Azure 또는 AWS 이미지를 사용합니다. 말하자면 애플리케이션은 마이크로서비스, API 앱, 다른 VM에 있는 일반적인 IIS 호스팅 앱을 연결할 수 있습니다. 이것이 일반적인 배포에 대한 일반적인 아이디어입니다. NCache 마이크로 서비스 및 Azure 앱 서비스 배포로 이동하면 이 내용을 다시 살펴보겠습니다. 클라우드에서는 약간 변경됩니다. 그래서 우리는 그것에 대해 이야기 할 것입니다.
세 가지 일반적인 용도 NCache
좋아요! 이것은 이 웨비나에서 가장 중요한 슬라이드입니다. Microsoft Azure 서비스에서 분산 캐시를 정확히 어디에 사용하는지 강조하고 싶습니다. 맞나요? 따라서 일반적으로 웹 애플리케이션, 웹 서비스, 백엔드 애플리케이션, 윈도우 서비스에 대해 이야기합니다. 이러한 서비스는 중앙 집중식 소스에서 데이터에 액세스해야 하고 매우 빠른 저장소가 필요합니다. 그래서 일반적인 사용 사례입니다. Microsoft Azure에는 이미 확장성이 뛰어난 플랫폼이 있습니다. 애플리케이션은 선형으로 확장할 수 있으며 웹 양식 및 웹 가든에서도 마찬가지입니다.
따라서 Microsoft Azure 내에서 서비스용으로 사용할 수 있는 몇 가지 중요한 사용 사례를 나열했습니다.
앱 데이터 캐싱우선 데이터 캐싱에 사용할 수 있으며 이는 Microsoft Azure 마이크로 서비스 및 앱 서비스에 적용됩니다. 상태 비저장 서비스가 있다면 그렇지 않습니까? 상태 저장 서비스에는 자체 파티셔닝 세트가 필요하고 복제본도 있어야 하지만 상태 비저장에는 복제본이 없기 때문입니다. 따라서 한 가지 중요한 측면은 상태 비저장 애플리케이션이 있지만 여전히 데이터 안정성을 원한다는 것입니다. 그렇죠? 따라서 이 경우 분산 캐시에 데이터를 넣을 수 있습니다. 분산 캐시는 설계상 복제 측면과 고가용성 측면을 다룰 수 있습니다. 따라서 상태 비저장 마이크로 서비스에서도 데이터를 사용할 수 있습니다.
그리고 다음 이점은 마이크로서비스 또는 앱 서비스 내에 있을 수도 있습니다. 웹 애플리케이션이 있는 경우 SQL 서버와 같은 백엔드 데이터 소스와 통신할 수 있습니다. 따라서 SQL 서버가 느립니다. 엄청난 트랜잭션 부하를 처리할 수 있는 것이 아닙니다. 이에 대한 응답으로 분산 캐시는 선형으로 확장되고 논리적 용량으로 결합되는 여러 서버를 가질 수 있습니다. 그렇죠? 따라서 즉시 더 많은 서버를 추가할 수 있습니다. 그리고 Microsoft Azure에서는 이를 매우 간단하게 관리할 수 있습니다. 새 VM을 생성할 수 있으며 캐싱 서버를 더 추가함에 따라 용량을 두 배로 늘릴 수 있습니다. 따라서 데이터 캐싱 사용 사례는 무엇보다도 메모리에 있습니다. 따라서 용량 데이터베이스에서 매우 빠르며 Microsoft SQL 서버와 비교하여 Microsoft Azure에서도 매우 확장 가능한 플랫폼입니다. 따라서 Microsoft Azure 앱 서비스와 Microsoft의 사용 사례에서 얻을 수 있는 두 가지 이점입니다. 소개만 하면 된다 NCache API를 호출하고 키 값 쌍에 데이터를 계속 추가합니다.
ASP.NET 특정 캐싱두 번째 사용 사례는 Microsoft 웹 앱 서비스에만 해당됩니다. ASP.NET 특정 캐싱에 관한 것입니다. 따라서 앱 서비스가 있으면 다음을 사용할 수 있습니다. NCache, 앱 서비스가 말하는 위치 NCache 세션 및 출력 캐싱 데이터용. 이 사용 사례는 ASP.NET 앱 서비스에도 적용되므로 개체 캐싱 API를 사용할 수도 있습니다. 따라서 세션 상태는 일반적으로 고정 세션 부하 분산이 필요하거나 데이터베이스의 일부일 수 있는 동일한 앱 서비스 인스턴스의 일부가 됩니다. 어느 쪽이든 고정 세션인 경우 기본 옵션인 고정 로드 밸런싱이 있어야 하는 곳으로 제한됩니다. 그리고 데이터베이스 측에서는 다시 느려지고 단일 실패 지점이기도 합니다.
앱 서비스를 사용하여 NCache 세션 제공자로서 무엇보다도 확장성이 매우 뛰어납니다. 매우 빠르며 단일 실패 지점이 없습니다. 세션은 서버 간에 복제되므로 ASP.NET 응용 프로그램에 분산 캐시 사용을 고려해야 하는 위치에 있습니다. 그리고 이것은 다중 사이트 배포도 될 수 있으며 이것은 하나의 사이트에 배포된 하나의 응용 프로그램이 동일한 사이트의 캐싱 서버와 통신하고 대화할 수 있는 기능이 있는 곳에서 오늘 다룰 계획입니다. 사이트 전반에 걸쳐 캐싱 서버에도 적용됩니다. 그리고 Azure 내부에서 어떤 구성이 필요한지 강조하겠습니다. 그러나 Azure에서는 불가능합니다. NCache Microsoft Azure 내의 분산 캐싱 제품.
두 번째 사용 사례는 출력 캐싱에 관한 것입니다. 맞습니까? 따라서 앱 서비스로 배포된 웹 애플리케이션 내에서 앱 서비스 내에서 정적 페이지를 사용할 수 있습니다. 정적 페이지가 있는 경우 해당 페이지의 내용을 캐시합니다. 전체 페이지 출력을 캐시할 수 있으며 다음에 동일한 페이지에 액세스해야 할 때 해당 페이지 출력을 사용할 수 있습니다. 이것이 또 다른 이점입니다. 이것은 ASP.NET 성능을 최적화하는 XNUMX가지 다른 방법에 대해 설명하는 일반적인 ASP.NET 성능 및 확장성 웨비나에서 다루는 것입니다. 따라서 웹 애플리케이션이 앱 서비스로 배포되는 Microsoft Azure 앱 서비스에도 동일한 개념이 적용됩니다.
Pub/Sub 및 런타임 데이터 공유이제 세 번째로 중요한 사용 사례이며 마이크로서비스와 관련하여 가장 중요한 부분입니다. 앱 서비스에도 적용되지만. 귀하의 앱 서비스는 데이터 공유가 필요할 수 있습니다. 하나의 애플리케이션 서비스가 다른 애플리케이션 서비스와 통신하거나 두 개의 서로 다른 애플리케이션 간에 공유되는 데이터일 수 있습니다. 따라서 본질적으로 다르지만 동일한 데이터에 의존하는 웹 애플리케이션이 있습니다. 보고 응용 프로그램이 있을 수 있고 그 소비자가 있을 수 있거나 제품 카탈로그 측면에서 생산자가 있을 수 있으며 이에 의존해야 하는 다른 응용 프로그램이 있을 수 있습니다. 첫 번째 응용 프로그램을 기반으로 일부 보고서를 생성해야 합니다. . 따라서 해당 사용 사례에서는 애플리케이션이 다른 애플리케이션 간에 데이터를 공유해야 합니다. 따라서 데이터베이스를 사용하여 데이터를 공유할 수 있는 방법은 없지만 속도가 느리고 어떤 경우에는 단일 실패 지점이기도 합니다. 분산 캐시는 애플리케이션이 클라이언트-서버 모델에서 연결할 수 있기 때문에 더 합리적입니다. 여러 응용 프로그램이 동일한 계층의 동일한 캐싱 계층에 연결할 수 있으며 그런 다음 동일한 캐시 리소스를 사용하고 동일한 데이터에 액세스할 수 있으며 이를 켤 수 있습니다.
Azure 마이크로서비스에서는 이를 다른 수준으로 끌어올려야 합니다. Azure 마이크로 서비스에서는 클러스터링되어 있고 이미 언급했지만 상태 저장 및 상태 비저장이 될 수 있습니다. 그렇죠? 요구 사항이 있을 수 있으며 이것은 귀하의 마이크로 서비스가 마이크로 서비스와 상호 작용해야 할 수도 있다고 제가 언급한 것입니다. 맞습니까? 따라서 설계상 마이크로서비스 아키텍처에서는 서비스 인스턴스가 서로 상호 작용해야 할 수 있고 그런 다음 서로 데이터를 공유해야 할 수 있습니다. 그리고 이것은 마이크로서비스 플랫폼에 관한 한 매우 핵심적인 요구 사항입니다. 여러 애플리케이션 인스턴스가 서로 데이터를 공유하기만 하면 됩니다. 하나의 마이크로 서비스가 일부 데이터를 보내고 다른 마이크로 서비스 인스턴스에서 사용할 수 있습니다. 상태 저장이거나 여러 애플리케이션이 동일한 라인에서 상호 작용할 수 있지만 두 개의 마이크로 서비스 내에서 이것은 반드시 있어야 하는 것이므로 많은 제XNUMX자 공급자가 데이터 공유 및 pub/sub 모델을 제공하는 것의 일부로 제공하는 것이 맞습니까?
따라서 Microsoft Azure에서 한 응용 프로그램이 저장소와 통신하는 위치에서 데이터 공유를 처리해야 하는 요구 사항이 있고 다른 응용 프로그램, 다른 마이크로 서비스 인스턴스에 필요한 데이터가 있는 경우 이를 처리할 플랫폼이 필요하고 NCache 데이터가 중앙 집중식으로 제공되는 플랫폼을 제공합니다. 매우 빠른 저장소입니다. 그 외에도 여러 마이크로 서비스 인스턴스 다른 서비스 또는 동일한 서비스의 인스턴스가 이 캐시에 연결할 수 있으며 그런 다음 캐시에서 데이터 공유 기능을 사용할 수 있습니다. 따라서 데이터를 중앙에서 더 빠르게 사용할 수 있습니다.
그런 다음 주제 기반 게시/구독 모델이 있습니다. 메시징 플랫폼이 있습니다. 따라서 메시지를 보낼 수 있습니다. 데이터 기반 메시지이거나 생산자 응용 프로그램과 캐시에 데이터를 보낸 다음 해당 메시지가 모든 수신자에게 전송되는 마이크로 서비스의 인스턴스인 응용 프로그램 기반 메시지 또는 주제 기반 메시지일 수 있습니다. 이 가입자 측에서. 그리고 유사하게 가입자도 경우에 따라 생산자가 될 수 있습니다. 따라서 여러 Azure 마이크로 서비스 인스턴스 간에 게시/구독 메시징을 사용할 수 있습니다. 여러 인스턴스 간의 이벤트 기반 데이터 공유도 가능합니다. 그리고 그 위에 이벤트 알림과 지속적인 쿼리 시스템이 있습니다. 이것은 SQL 명령일 수 있으며 이를 기반으로 데이터 기반 메시지를 얻을 수 있는 데이터 세트를 다시 정의할 수 있습니다. 따라서 Microsoft Azure Microservices 내부에서 Microsoft Azure 분산 캐시 사용을 고려하는 사용 사례입니다.
NCache MS Azure의 배포 시나리오
그런 다음 Azure 웹 응용 프로그램 서비스에 대해서도 이야기하겠습니다. Microsoft Azure에서 웹 애플리케이션을 배포하는 것이 더 쉽습니다.
괜찮은. 이제 두 종류의 시나리오가 있습니다. 따라서 동일한 리소스 그룹 내 또는 동일한 가상 네트워크 내 단일 사이트의 단일 지역에 모든 것을 배포하는 것이 바람직합니다. 맞습니까? 그래서, 나는 이미 그것에 대해 논의했습니다 NCache 애플리케이션은 Microsoft Azure의 VM에 배포되지만 애플리케이션은 해당 VM에 액세스하는 VM이 될 수 있습니다. NCache 또는 Azure 서비스일 수 있으며 오늘은 Azure 서비스에 중점을 둘 것입니다. VM 사례는 VM을 생성하고 iAS로 이동하여 거기에서 애플리케이션을 호스팅한 다음 애플리케이션을 NCache 사용 NCache API 또는 세션 저장소 공급자. 그러나 서비스와 관련하여 몇 가지 네트워킹 구성을 수행해야 합니다. 따라서 귀하의 서비스가 NCache.
따라서 Azure 서비스 및 NCache 동일한 사이트의 동일한 지역에 배포됩니다. 따라서 Azure 서비스를 배포할 때 동일한 리소스 그룹과 동일한 가상 네트워크에도 연결해야 합니다. 따라서 권장되는 접근 방식입니다. 중개자가 필요하지 않습니다. 여러 홉이 없어도 속도가 느려지지 않습니다. 이것이 우리 사이트에 권장되는 시나리오입니다.
두 번째 시나리오는 여러 사이트가 있을 수 있는 매우 유효한 시나리오이기도 합니다. 여전히 캐시와 애플리케이션, 마이크로서비스 앱 서비스가 항상 서로 연결할 수 있어야 하는 동일한 지역에 있어야 하는 것이 좋습니다. 부터 NCache TCP-IP 프로토콜입니다. 따라서 모든 통신에 IP 주소와 포트를 사용하며 이것이 TCP-IP 포트입니다. 따라서 애플리케이션이 가까이에 있는 방식으로 배포해야 합니다. 서로 조합하여 배포됩니다. 그들은 근처에 있으며 사용 가능한 다른 홉이 아닙니다. 따라서 응용 프로그램이 있는 동일한 사이트에 캐시를 배포하는 것이 좋지만 다중 사이트 기능을 사용하는 시나리오가 있을 수 있습니다. 애플리케이션이 다른 사이트의 캐시와 통신해야 하거나 캐시가 서로 통신해야 하는 경우. 따라서 사이트 간 통신이 필요합니다. NCache 뿐만 아니라.
이것이 제가 이 두 가지 시나리오를 다룰 의제입니다. 시나리오 1은 모든 것이 애플리케이션에 더 가까운 싱글에 있는 것이 좋습니다. 시나리오 XNUMX는 여러 사이트가 있고 사이트 XNUMX의 애플리케이션이 사이트 XNUMX의 캐싱 서버와 통신하거나 캐싱 서버일 수 있다는 것입니다. 예를 들어 WAN 복제 기능의 경우 사이트 XNUMX과 사이트 XNUMX 캐시 사이에 브리지가 있을 수 있습니다.
시나리오 1: Azure 서비스 및 NCache (권장)
따라서 Azure 서비스에 대한 단일 사이트 배포에서는 이에 대한 몇 가지 세부 단계를 다루겠습니다. 응용 프로그램 개발, 소개하는 방법에 대해 이야기하겠습니다. NCache 애플리케이션 내부에서 호출하고 이에 대한 서비스 프로젝트를 참조 예제로 사용할 것입니다. 괜찮은. 따라서 이것은 이 웨비나에서 다루려고 하는 모든 세부 사항을 포함해야 하는 다이어그램입니다.
나는 이미 그것을 언급했다 NCache 서버는 Microsoft Azure의 VM이 됩니다. 권리? 따라서 이러한 VM을 지원하는 가상 네트워크를 관리한 다음 NCache 이들에 설치한 다음 앱 서비스로 배포되는 웹 애플리케이션을 설치해야 합니다. API 앱일 수도 있고 마이크로 서비스 앱일 수도 있습니다. 그렇죠? 모두 서비스 인스턴스입니다. 기본 VM이 아닙니다. 따라서 설치할 수 없다는 의미이기도 합니다. NCache 이러한 리소스에서 이를 애플리케이션 리소스의 일부로 포함해야 합니다. 따라서 강조할 NuGet 패키지가 있습니다. 괜찮은! 따라서 웹 앱이 있고 API 앱이 있으며 마이크로 서비스 및 기타 앱도 있을 수 있습니다.
따라서 이것은 애플리케이션과 VMS를 호스팅하는 동일한 Azure 가상 네트워크가 있는 일반적인 단일 사이트 배포입니다. NCache. 그리고 이 분야에서 우리가 실제로 하고 있는 것은 웹 애플리케이션과 서비스 앱 및 NCache 서비스. 이것이 전체 네트워킹의 모습입니다. 실제로 서비스 프로젝트를 사용할 동일한 가상 네트워크의 일부입니다. 우리는 소개합니다 NCache 그 안에 리소스가 있으면 다음을 위한 서버 측 리소스를 생성합니다. NCache. 따라서 VM이 가동되어 실행되고 나면 간단히 애플리케이션으로 돌아가 애플리케이션을 NCache VM이 존재합니다. 따라서 단일 사이트가 되고 캐싱 서비스와 동일한 가상 네트워크를 사용하게 됩니다.
이제 이러한 단계를 살펴보겠습니다.
괜찮은! 첫 번째 단계는 NCache 서버 측에서 설정을 준비하고 이는 실제로 Azure 가상 머신을 설정하는 것을 의미합니다. NCache 이 단계는 단일 사이트 배포이든 다중 사이트 배포이든 모든 종류의 배포에 공통입니다. 단일 사이트 배포의 경우 다음이 필요합니다. NCache 서버가 설정되고 VM이 된 다음 NCache 에 설치됩니다. 그럼 빠르게 Azure Portal로 안내해 드리겠습니다. 맞죠? 그리고 리소스 그룹으로 이동하면 리소스 그룹을 생성한 것이므로 정렬만 하면 됩니다. 내 첫 번째 리소스 그룹은 데모 리소스 그룹 XNUMX입니다. 맞죠? 그리고 여기에 모든 종류의 VM이 있습니다. 예를 들어 데모 VM XNUMX이 있고 데모 VM XNUMX도 있습니다. 사실 동일한 가상 네트워크를 사용했습니다. 이 두 데모 머신 모두에 동일한 가상 네트워크를 사용했습니다.
빨리 보여드리죠.. 바로 여기로 가져오겠습니다. 괜찮은! 서유럽에 배포된 데모 VM 1이 있고 데모 VM 2가 있고 데모 VM v-net 10.4.0.4이 있습니다. 그렇죠? 그것을 클릭하면 이것의 데모 VM 10.4.0.5과 데모 VM XNUMX 부분을 볼 수 있으며 이들은 IP 주소 XNUMX 및 XNUMX입니다. 그래서, 그것은 우리의 두 가지를 나타냅니다. NCache VM과 이 환경으로 빠르게 안내해 드리겠습니다.
그래서 내가 실제로 한 것은 VM을 만든 것입니다. 빈 2012 또는 2016 이미지가 수행할 수 있는 작업을 수행한 다음 Alachisoft 웹 사이트 및 필요한 모든 것, 특별한 설치 프로그램이 없습니다. NCache. 기존 설치 프로그램을 사용하기만 하면 됩니다. 다운로드 페이지로 이동하여 30일 평가판을 다운로드하십시오. NCache 우리 웹 사이트에서 그리고 당신이 그것을 완료하면 내가 설치했습니다 NCache 데모 VM 1과 데모 VM 2에서. 그리고 데모 V 넷 캐시도 만들었습니다. 캐시 생성 단계는 매우 간단합니다. 데모 캐시로 이동하여 캐싱 토폴로지를 비동기화하고 데모 VM 1을 지정한 다음 데모 VM 2가 IP를 있는 그대로 선택해야 한다고 생각합니다. 네, 그렇습니다. 따라서 이러한 서버는 서로 통신할 수 있습니다.
내가 취한 추가 단계 중 하나는 프레젠테이션으로 돌아가면 다음을 설정하는 데 필요한 단계입니다. NCache 마이크로소프트 애저용 서비스. Azure 가상 네트워크를 만드시죠? 그것은 당신의 환경에 이미 있을 수 있는 것입니다. 그런 다음 해당 Azure 가상 네트워크에서 VM을 만듭니다. 따라서 전용 VM 세트를 가질 수 있습니다. NCache; 서버 XNUMX 서버 XNUMX 서버 XNUMX. 그런 다음 동일한 서브넷을 유지해야 합니다. 그것은 우리가 추천하고 당신이 설치하는 것입니다 NCache 모든 VM에서. 그런 다음 다른 한 가지는 NCache 통신용 포트. 두 가지 종류의 포트, 두 가지 종류의 네트워크 고려 사항이 있어야 합니다. 하나는 내부 방화벽을 비활성화한 다음 이러한 VM이 있는 네트워크에 네트워크 보안 그룹이 있어야 한다는 것입니다.
예를 들어 데모 VM 하나의 네트워크 보안 그룹에서는 이러한 포트가 이미 열려 있을 것입니다. 그렇죠? 그래서 빨리 보여드리면 NCache 포트, 우리에게 필요한 것은 포트 9800과 48250입니다. 이것은 인바운드 및 아웃바운드 통신을 위한 것입니다. 9800 및 48250 따라서 사용하려는 모든 응용 프로그램이 NCache, 포트 9800을 사용하는 이 캐싱 서버에 연결할 수 있고 관리를 시도하는 모든 애플리케이션에 연결할 수 있습니다. 예를 들어 이를 관리하려고 하고 가상 네트워크를 가로지르는 다른 VM이 있을 수 있지만 이는 동일한 리소스 그룹에서 이러한 네트워크 보안 그룹을 사용하면 이러한 포트에서 이 통신을 수행할 수 있습니다. 그게 다야. 그것이 당신이 가져야 할 고려 사항입니다.
캐싱 서버 자체에서 방화벽을 해제했습니다. 그리고 이 포트가 열려 있고 방금 캐시를 만들었고 통계를 볼 수 있습니다. 이 컴퓨터에서 스트레스 테스트 도구 응용 프로그램을 직접 실행할 수 있으며 빠르게 할 수 있습니다. 약간의 지연이 있으므로 양해해 주십시오. 그리고 스트레스를 시뮬레이션할 수도 있습니다. 그래서 우리는 V net one 캐시를 유감스럽게 생각하고 이 두 캐싱 서버에서 활동을 실행하고 시뮬레이션합니다. 따라서 서버 측 설정에 관한 한 쉽습니다. 이제 응용 프로그램으로 돌아가서 살펴봐야 합니다. 응! 거기 당신이 간다. 그래서, 우리는 활동을 하고 있습니다. 그래서, 우리는 좋습니다. 이만 닫겠습니다.
단일 사이트 배포를 위한 2단계: 환경에 Azure 서비스 배포다음으로 가상 머신을 구성했으므로 캐시 클러스터도 생성했습니다. 다음으로 이 캐시 클러스터와 통신할 수 있는 웹 애플리케이션이 필요합니다. 맞죠? 자, 여기 내 프레젠테이션으로 빨리 돌아가겠습니다. 그렇죠?
따라서 응용 프로그램의 관점에서 실제로 필요한 것은 응용 프로그램 간의 지점 간 네트워크 구성이 필요하다는 것입니다. NCache. 그래서 우선, 나는 이미 그것을 했습니까? 그것을 강조하기 위해. 이제 리소스 그룹으로 돌아가면 데모 리소스 그룹 1이 있습니다. 따라서 데모 가상 네트워크 게이트웨이가 있는 것입니다. 우리는 이것에 대한 게이트웨이를 만들었습니다. 맞죠? 그리고 사이트에 대한 지점이 있습니다. 이것은 우리의 캐싱 서비스를 위한 기본 네트워크인 데모 v-net을 사용하는 가상 네트워크 게이트웨이입니다. 여기로 돌아와서 이 다이어그램을 보면 실제로 가상 네트워크 게이트웨이를 사용합니다. 이 게이트웨이는 이 가상 네트워크의 일부입니다. 그러면 곧 배포할 내 응용 프로그램은 지점 대 사이트를 갖게 될 것입니다. 이것은 동일한 가상 네트워크에 연결되도록 이것 사이에서 진행되는 통신입니다. 이것이 Microsoft Azure의 요구 사항입니다. 앱 서비스가 가상 네트워크(예: VM)에 있는 리소스와 통신하려면 지점 간 설정이 필요합니다.
그래서, 바로 여기로 돌아옵니다. 따라서 데모 리소스 그룹이 있습니다. point to site를 보여주더라도 바로 여기로 와야 합니다. point site-to-site 구성을 보여주면 이 IP가 우리 앱 서비스의 일반 IP입니다. 따라서 앱 서비스가 배포되면 이를 클릭한 다음 해당 가상 네트워크에 연결합니다.
그래서, 나는 나의 프로젝트로 돌아올 것이다. 나는 그것을 더 일찍 보여주지 않았다고 생각한다. 그러나 이것은 서비스 앱인 샘플 애플리케이션이다. 무엇이 필요한지 보여드리겠습니다. 따라서 마우스 오른쪽 버튼을 클릭하면 Microsoft Azure에 사용할 수 있는 NuGet 패키지가 있습니다.
예를 들어, 우리는 Alachisoft.NCache.SDK. 이것들은 우리와 함께 개인적으로 사용할 수 있습니다. 맞습니까? 이들은 귀하의 애플리케이션에 모든 NCache 의 설치가 없기 때문에 리소스를 가리킵니다. NCache 클라이언트 측에서. 전형적인 NCache 배포는 클라이언트가 설치되어 있고 서버가 설치되어 있다는 것입니다. 그래서, 그것을 덮는 것, 맞습니까? 그러나 서비스의 경우에는 인스턴스입니다. 따라서 기본 VM에 액세스할 수 없습니다. 따라서 이 경우 NuGet 패키지가 필요합니다. 따라서 모든 리소스가 응용 프로그램 내부에서 필요한 부분으로 만들어집니다. 그래서 이것은 내가 이미 설치한 누가 패키지입니다. 실제로 모든 것을 추가한 것은 NCache 클라이언트 사이트 라이브러리, 맞죠? 그래서, 그것은 또한 몇 가지 구성을 추가했습니다. 그래서 우리는 client.ncconf를 가지고 있습니다. 이것은 모든 캐시에 연결하는 기본 파일입니다.
예를 들어, 이름인 V net one 캐시에 연결하기 위한 설정이 이미 있고 여기에 연결할 내부 IP 주소도 있습니다. 다음으로 이 애플리케이션을 게시하면 이 애플리케이션이 VM 10.4.0.4의 경우 10.4.0.5, VM XNUMX의 경우 XNUMX에 액세스할 수 있어야 합니다. 따라서 이 공용 IP가 내 애플리케이션에 액세스할 수 있는 지점 간 통신이 있는지 확인해야 합니다. 그래야만 이 캐시와 연결할 수 있습니다.
따라서 응용 프로그램으로 돌아가서 일부 캐시 호출을 보여주고 있습니다. 따라서 이 MVC 프로젝트 내에는 이 캐시 인스턴스가 있는 주 컨트롤러가 있고 캐시 인스턴스를 사용하고 있습니다. 캐시를 초기화합니다. 이 방법으로 바로 가도록 하겠습니다. 그래서 이것은 초기화된 방법이며, NCache.initializeCache를 호출한 다음 항목을 추가하기 위해 cache.insert를 호출하고 해당 항목을 삭제하기 위해 Cache.delete를 호출하고 항목을 다시 가져오기 위해 cache.get을 호출한 다음 일부 부하 테스트를 수행했는지 확실하지 않은 경우 그렇습니다! 따라서 실제로 항목을 로드하는 또 다른 메서드 로드 테스트가 있습니다. 캐시에 천 개의 항목이 로드된 다음 해당 항목도 검색됩니다. 따라서 이것은 우리의 응용 프로그램과 관련하여 주요 논리를 처리해야 합니다.
제가 보여드릴 몇 가지 견해가 있습니다. 따라서 삭제, 가져오기, 인덱싱 및 로드 테스트도 있으며 이들은 단순히 애플리케이션을 통해 호출됩니다. 그래서 제가 할 일은 이것들이 기본이 되는 것입니다 NCache 전화. 그래서 다음에 할 일은 이것을 Microsoft Azure에 배포하는 것입니다. 여기에서 이미 모든 리소스 그룹과 네트워킹 부분을 설정했습니다. 그러나 실제로 필요한 것은 Microsoft Azure 앱인 경우 구독을 기반으로 웹 앱 이름을 새로 만들기만 하면 됩니다. 잠시만 기다려 봅시다. 그래서 구독을 선택합니다. 가세요. 그래서 자동으로 Visual Studio 엔터프라이즈를 선택한 다음 리소스 그룹을 선택했는데 데모 리소스 그룹 XNUMX개를 사용할 계획입니다. 그래서 단일 사이트 배포를 사용하고 있습니다. 따라서 동일한 리소스 그룹의 일부이며 서비스 계획을 선택한 다음 생성을 선택합니다. 여기에 새로 추가할 수도 있습니다. 그래서 위치도 서유럽인거죠? 여기에서 확인을 선택한 다음 만들기를 선택하면 자동으로 시작됩니다.
이후로, 나는 이미 이것을 했습니다. 그래서 다음에 할 일은 웹 구성으로 이동하여 V net cache one을 사용하고 있고 client.ncconf 내부에 V net one 캐시가 있는지 확인하는 것입니다. 따라서 이 응용 프로그램은 동일한 사이트에 배포됩니다. 동일한 리소스 그룹이 끝나면 내 리소스 그룹의 일부인 가상 네트워크에 연결하겠습니다. NCache 서버 VM.
Microsoft Azure로 돌아가서 잠시 후 리소스 그룹 XNUMX로 이동하면 이 애플리케이션이 어딘가에 있어야 합니다. 저기요! 그것을 클릭한 다음 이 애플리케이션이 배포된 후 네트워킹 부분을 클릭하면 맞습니까? 그래서, 맞아! 그래서 네트워킹으로 이동하여 클릭하면 이미 데모 v-net에 연결되어 있지 않습니까? 나는 이미 이것을 했어, 그렇지? 따라서 귀하의 경우 가상 네트워크 게이트웨이에 대한 사이트 연결을 가리키고 나면 하나의 데모 리소스 그룹이 있는 것입니다. 맞습니까? 다시 가져와, 바로 여기. 그래서 가상 네트워크를 생성한 후 point to site를 생성하면 이 앱 서비스 IP가 노출되는데, 앱 서비스를 배포한 후 가상 네트워크에 연결해야 하는 것 아닌가요? 그래서, 이것은 바로 여기에 필요한 추가 단계입니다. 그래서 내 응용 프로그램이로드되기를 바랍니다. 기다려요 응!
이제 서버 쪽에서 내용을 지우고 항목만 삽입하겠습니다. 캐시에 성공적으로 추가되었습니다. 그리고, 당신은 그것에 하나의 항목을 볼 수 있습니다. 나는 그것을 빨리 얻을 것입니다. 카운터를 보여드릴 수 없어 죄송합니다만 실제로 실제로 검색한 다음 삭제할 수 있습니다. 그렇죠? 따라서 동일한 가상 네트워크의 일부이기 때문에 비교할 때 훨씬 빠릅니다.
이제 몇 가지 부하 테스트를 시뮬레이션하고 수천 개의 항목을 추가하면 몇 가지 활동이 표시되어야 합니다. 저기, 그렇지? 따라서 초당 요청 수와 해당 항목이 추가되고 있으며 여기에서 약 600개 항목을 볼 수 있고 여기에 약 400개 항목을 볼 수 있으며 해당 항목을 검색하지 않습니다. 따라서 이는 마이크로서비스든, 앱 서비스든, API 앱이든, 서비스 모델에 배포된 모든 애플리케이션이든 서비스의 일반적인 배포입니다. NuGet 패키지를 도입하고 사이트 간 연결 지점을 생성하기만 하면 됩니다. NCache 네트워크 게이트웨이와 애플리케이션 인스턴스를 통해 VM을 VM에 연결할 수 있습니다. 따라서 이들은 모두 Microsoft Azure 네트워킹 구성이며 NCache TCP-IP 채널에 노출될 개인 IP 주소만 있으면 됩니다. 그게 우리에게 필요한 전부입니다.
시나리오 2: Azure 서비스 및 NCache
그래서 다음에는 사용 가능한 시간이 적기 때문에 지난 10분 동안 다중 사이트 시나리오도 다룰 것입니다. 구성은 거의 비슷합니다.
하나의 Azure 가상 네트워크 또는 하나의 사이트에 배포된 웹 앱 또는 Microsoft 서비스 또는 앱 서비스가 있습니다. NCache VM 또는 다른 사이트가 있고 이를 위해 우리가 정말로 필요한 것은 여기에는 로컬 네트워크 게이트웨이이고 여기에는 가상 네트워크 게이트웨이가 있고 그런 다음 이 둘 사이에 사이트 간 연결이 필요합니다. 다시 말하지만, 이들은 사이트 간 연결을 사용하여 양측이 서로 연결할 수 있도록 하는 모든 Microsoft Azure 설정입니다. NCache 이를 활용하고 내부 IP가 양쪽에 매핑됩니다. 그래서, 당신의 NCache 서버 내부 IP는 애플리케이션 서비스 가상 네트워크에 매핑되고 그 반대도 마찬가지입니다.
이를 위해 구성을 빠르게 보여 드리겠습니다. 리소스 그룹으로 돌아가면 데모 리소스 그룹 3가 있습니다. 맞습니까? 그래서, 그것은 또 다른 가상 네트워크입니다. 그리고 바로 여기에 데모 v-net 4가 있습니다. 이 가상 네트워크에도 데모 VM 10과 데모 VM 4.0.4라는 두 개의 상자가 있습니다. 그래서 바로 여기 이 환경은 XNUMX. XNUMX이고 다른 가상 네트워크입니다. 다른 사이트로 다른 가상 네트워크의 비유를 사용하고 있습니다. 그러나 교차 사이트일 수도 있고 Microsoft Azure의 다른 지역에 있는 다른 데이터 센터일 수도 있습니다.
다중 사이트 배포 단계: 환경에 Azure 서비스 배포따라서 실제로 필요한 것은 이미 설명한 것과 동일한 설정을 유지하는 것입니다.
VM 부분을 동일한 가상 네트워크 동일한 서브넷에 유지하고 캐시를 만들고 해당 캐시를 시작하면 이제 애플리케이션이 교차 사이트인 캐시에 연결해야 합니다. 이를 위해서는 현장 간 커뮤니케이션이 필요합니다. 그리고 여기 이 데모 리소스 그룹으로 다시 돌아와서 데모 가상 네트워크와 데모 가상 네트워크 게이트웨이가 있으므로 가상 네트워크 게이트웨이 2, 그렇죠? 두 번째 사이트의 게이트웨이입니다. 따라서 연결로 이동하면 데모 2 사이트 간 연결이 있습니다. 따라서 데모 2 로컬 네트워크 게이트웨이에 대한 사이트 간 연결이 있습니다. 그래서, 그것은 내가 구성한 것입니다. 그렇죠? 따라서 내 가상 네트워크 XNUMX이 사이트에 있는 가상 네트워크 XNUMX에 연결할 수 있습니다. 이것이 바로 우리가 한 일입니다.
빨리 보여드릴게요 NCache 여기에서 아무것도 변경되지 않는 응용 프로그램입니다. 캐시 이름만 변경하면 스택의 일부로 가지고 있는 캐싱 서버에 연결할 IP 주소가 있어야 합니다. 따라서 V-net을 캐시에 연결하고 동일한 응용 프로그램을 사용하여 연결할 것입니다. 한 번만 더 게시하면 됩니다. 여전히 데모 리소스 그룹 3에 게시합니다. 반면 가상 머신은 데모 리소스 그룹 1에 있습니다. 그리고 이것은 바로 여기 VM 2입니다. 여기에는 두 개의 캐싱 서버가 있습니다. 따라서 사이트 간 연결이 이미 구성된 상태를 유지하면서 이것을 한 번만 더 게시하겠습니다. 이것을 게시하면 동일한 응용 프로그램이 이제 네트워크를 통해 가상 네트워크 XNUMX에서 가상 네트워크 XNUMX로 사이트를 가로질러 이동하고 여기에 연결할 수 있습니다. 그래서, 출판되기를 기다렸다가 바로 여기로 돌아와서 네트워킹 부분을 한 번 더 보여드리겠습니다.
따라서 실제로 필요한 것은 가상 머신에 대해 동일한 설정, 동일한 가상 네트워크, 동일한 서브넷 유지, VMS 생성, 설치 NCache 방화벽을 비활성화하고 네트워크 보안 그룹을 설정하여 NCache 포트가 열려 있으면 서비스로 응용 프로그램 간에 사이트 간 연결이 필요합니다. NCache 서비스. 따라서 앱 서비스가 연결된 가상 네트워크가 이미 있는 경우 가상 네트워크 1이 이제 가상 네트워크 2와 통신할 수 있는지 확인한 다음 교차 사이트가 있는지 확인하면 됩니다. 마이크로소프트 애저에서도. 그래서 출판에 성공했습니다. 이랬던 것 같아요. 문을 닫고 항목을 삽입하도록 할게요. 알겠죠? 그리고 거기에 항목이 추가되었는지 봅시다. 그래서 이제 아이템이 추가되었습니다. 그래서 지금은 한 사이트에서 다른 사이트로 여러 사이트에 대해 이야기하고 있습니다. 그런 다음 이 항목을 가져오면 바로 검색될 것입니다. 삭제하면 이 항목이 내 데모 VM 3에서 사라지고 항목이 없습니다. 마찬가지로 동일한 환경을 사용하기 시작하는 부하 테스트를 시뮬레이트하지만 일부 활동은 시뮬레이트할 뿐입니다. 그것.
이제 내 사이트 2인 앱 서비스가 사이트 XNUMX 캐시 서비스와 통신하고 있습니다. 그들은 사이트를 가로 질러 가고 있습니다. 일부가 될 수 있는 WAN 복제 또는 WAN 대기 시간이 있기 때문에 권장되지 않는 시나리오입니다. 따라서 모든 것을 동일한 사이트에 유지하는 것이 좋지만 예를 들어 배너 응용 프로그램 기능을 기반으로 하는 다중 사이트 세션 기능을 기반으로 하는 시나리오가 있을 수 있습니다. NCache. Azure와 통신하는 온-프레미스 애플리케이션 또는 한 프레미스와 통신하는 Azure 애플리케이션이 그 반대일 수 있습니다. 이것이 요구 사항이며 이제 로드 테스트도 완료되어 성공적으로 실행되었습니다.
따라서 Azure 배포를 다룹니다.
.NET용 분산 캐싱 옵션
이 시점에서 언급하고 싶은 몇 가지 사항은 Redis 비교도.
우리는 Azure에 대해 이야기하고 있습니다. 그래서, 우리는 확실히 이야기 할 것입니다 Redis. 따라서 당사 웹 사이트에서 사용할 수 있습니다. NCache 100% .NET입니다. c-sharp로 개발되었습니다. .NET 및 Java에 대해 완전히 지원됩니다. 이에 비해, Redis 무대 뒤에서는 Linux에 있으므로 VMS를 제어할 수 없습니다. 에 NCache VMS를 완전히 제어할 수 있습니다. 서버 측 코드를 실행할 수 있습니다 NCache Microsoft 버전의 Windows 버전뿐만 아니라 Redis 안정적으로 알고 있는 것이 아닙니다. 뒤에서 사용하고 서비스 모델로 제공하는 Linux 버전입니다. 그리고, NCache Docker에서도 사용할 수 있습니다. 사용할 계획이라면 NCache 서버 측 Dockers 컨테이너에서 이를 사용할 수 있습니다.
그런 다음 배포 옵션과 관련된 몇 가지 세부 사항에 대해서도 설명하겠습니다. 당신은 그냥 설치 NCache 서버 부분에 대해서는 당사 측에서 Azure 릴리스를 제공합니다. 서버 전용 릴리스이므로 애플리케이션에 다음 기능을 갖추도록 하려면 NuGet 패키지가 필요합니다. NCache 이는 지원팀이나 영업팀에서도 확인할 수 있는 사항입니다. 따라서 공개적으로 사용할 수 없는 것입니다. 이는 의도적이지만 당사에 요청하기만 하면 Azure 및 NuGet 패키지에 대한 릴리스를 제공할 것이며 그 후에는 단일 사이트 설정 또는 다중 사이트 설정이 필요한 네트워킹 부분일 뿐입니다. 일반적으로 단일 사이트를 권장하며 이 경우 지점 간 통신이 필요하고 다중 사이트에서는 사이트 간 통신이 필요합니다.
이상으로 프레젠테이션을 마칩니다.