Redis vs NCache
녹화된 웨비나
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)
NCache 는 높은 트랜잭션 처리량을 가진 .NET, .NET Core 및 Java 애플리케이션에서 매우 인기 있는 네이티브 .NET 오픈 소스 분산 캐시입니다. Redis 에 의해 개발 된 Redis Labs이며 현재 Azure의 Microsoft에서 사용하고 있습니다. 이 웨비나에서 방법을 알아보세요. NCache Redis 서로 비교하십시오. 이 웨비나의 목표는 특히 기능, 성능, 확장성, 고가용성, 데이터 안정성 및 관리와 같은 정성적 측면에서 두 제품을 더 쉽고 빠르게 비교하는 작업을 수행하는 것입니다.
이 웨비나에서 다루는 내용은 다음과 같습니다.
- 성능 및 확장성
- 캐시 탄력성(고가용성)
- 캐시 토폴로지
- SQL 및 LINQ 캐시 검색
- 타사 통합(EF, EF Core, NHibernate 등)
오늘은 매우 유사하지만 여러 면에서 다른 두 제품을 비교하는 주제를 다루겠습니다. NCache 당사의 주요 .NET 및 .NET Core 애플리케이션용 분산 캐싱 제품인 를 소개하고, 기능적인 측면에서 와 비교해 보겠습니다. Redis. 자, 여기서 다룰 내용이 많습니다. 플랫폼과 기술 스택부터 시작하여 많은 기술적 세부 사항을 살펴보겠습니다. 그런 다음 클러스터링에 대해 이야기해 보겠습니다. 캐시 클러스터링 측면에서 이 두 제품을 어떻게 비교하는지, 그리고 이 제품들을 사용함으로써 얻을 수 있는 이점은 무엇인지, 그리고 비교했을 때 어떤 점이 다른지 알아보겠습니다. NCache 더 나은 것을 말씀드린 다음 다양한 기능에 대해 말씀드리겠습니다. 기능별 비교 이러한 제품을 사용할 수 있는 다양한 사용 사례와 기능 비교 관점에서 두 제품을 비교하는 방법에 대해 알아보겠습니다.
이 웨비나에서는 다음을 선택했습니다. NCache 엔터프라이즈 5.0.2는 다음과 같습니다. Redis 우려되는 경우 Azure에 주로 집중할 것입니다. Redis. 오픈소스입니다 Redis 4.0.1.4. 하지만 다음에 대한 세부 정보도 알려드리겠습니다. Redis 오픈 소스 프로젝트뿐만 아니라, Redis 상업적인 변형인 실험실 Redis. 그래서 우리는 비교할 것입니다 NCache 이러한 모든 풍미가 있지만 우리의 주요 초점은 Microsoft Azure가 될 것입니다. Redis, 호스팅된 모델 Redis Microsoft Azure에서 얻을 수 있는 것입니다.
확장성 문제
그럼, 시작하기에 앞서 이 두 제품에 대한 기본적인 소개부터 짚고 넘어가겠습니다. 그렇다면 분산 캐싱 솔루션이 정확히 왜 필요한 걸까요?
따라서 그 후에는 여러 제품을 비교해 볼 수 있습니다. 일반적으로 애플리케이션 내에서 발생하는 문제는 확장성 및 성능 문제입니다. 애플리케이션에 많은 데이터 로드가 발생할 수 있으며, 애플리케이션 계층은 확장성이 뛰어나지만 언제든지 웹 팜을 생성하고 애플리케이션 계층에 리소스를 추가할 수 있습니다. 하지만 모든 애플리케이션 인스턴스가 백엔드 데이터 소스와 통신해야 합니다. 그리고 이러한 데이터 소스와 통신해야 할 때 성능 문제가 발생합니다. 데이터베이스, 특히 관계형 데이터베이스는 트랜잭션 로드 처리 속도가 느리기 때문입니다.
이러한 데이터베이스는 성능 문제를 야기하며, 확장 측면에서도 마찬가지입니다. 예를 들어, 많은 요청 처리 용량이나 관련 요구 사항이 필요하고 애플리케이션에서 많은 사용자 부하가 발생하는 경우, 데이터베이스는 이러한 극심한 트랜잭션 부하를 처리할 수 있도록 설계되지 않았습니다. 많은 데이터를 저장할 수 있는 저장소에는 적합하지만, 해당 데이터에 트랜잭션 부하가 발생하는 경우에는 데이터베이스가 적합하지 않습니다. 데이터베이스가 과부하될 수 있으며, 속도가 느려지고 최종 사용자 경험이 저하될 수 있습니다.
따라서 성능에 영향을 미칠 수 있으며 애플리케이션 아키텍처 내에서 용량을 늘릴 수 없습니다.
솔루션: 메모리 내 분산 캐시(NCache)
해결책은 매우 간단합니다. 다음과 같은 메모리 내 분산 캐싱 시스템을 사용하면 됩니다. NCache 메모리에 저장되기 때문에 매우 빠릅니다. 따라서 관계형 데이터베이스나 파일 시스템, 또는 메모리 기반이 아닌 다른 데이터 소스와 비교했을 때, 디스크에서 데이터를 가져오는 경우와 메모리에 데이터를 저장하는 경우를 비교하면 매우 빠릅니다. 따라서 가장 먼저 얻을 수 있는 이점은 매우 빠른 성능을 얻을 수 있다는 것입니다. NCache.
두 번째 장점은 캐시 클러스터라는 점입니다. 단일 소스가 아닙니다. 처음에는 서버 하나로 시작할 수 있지만, 일반적으로 최소 두 대의 서버를 구성하고 캐시 클러스터를 생성하는 것을 권장합니다. 캐시 클러스터를 생성하자마자 모든 서버에 부하를 분산하고 런타임에 서버를 계속 추가하면 성능이 향상될 것입니다.
따라서 용량을 확장할 수 있습니다. 즉, 서버를 추가하여 런타임에 용량을 늘릴 수 있으며, 백엔드 관계형 데이터베이스와 함께 사용할 수도 있습니다. 기존 관계형 데이터베이스를 대체하는 것은 아니며, 향후 몇 가지 사용 사례에 대해 살펴보겠습니다.
분산 캐시 배포(NCache)
일반적인 배포 예는 다음과 같습니다.
내가 사용하고 있습니다 NCache 지금은 예시로만 설명하지만 이 프레젠테이션에서는 앞으로 어떻게 비교될지 알아보겠습니다. Redis 배치되고 어떻게 NCache 배포되는 제품과 이러한 제품 내에서 이용 가능한 유연성은 무엇입니까?
그래서 NCache매우 유연합니다. Windows와 Linux 환경에 모두 배포할 수 있습니다. 온프레미스 환경뿐만 아니라 클라우드 환경에서도 지원됩니다. Azure와 AWS 마켓플레이스에서도 사용할 수 있습니다. 따라서 미리 구성된 이미지를 바로 받을 수 있습니다. NCache 지금 바로 시작하세요. Windows와 Linux용 Docker 컨테이너가 제공되며, 필요한 모든 플랫폼에서 사용할 수 있습니다.
일반적으로 온프레미스 또는 클라우드에 호스팅되는 애플리케이션은 앱 서비스, 클라우드 서비스, 마이크로서비스, Azure 웹사이트 등 어떤 애플리케이션이든 클라이언트-서버 모델로 연결할 수 있으며, 애플리케이션과 백엔드 데이터베이스 사이에 위치합니다. 이것이 일반적인 사용 모델입니다. 여기서 핵심은 데이터를 내부에 저장한다는 것입니다. NCache 결과적으로 백엔드 데이터베이스로의 값비싼 이동을 줄일 수 있습니다. 데이터베이스로의 이동을 최대한 줄이고, 데이터베이스에 접속해야 할 때마다 항상 데이터베이스로 이동하여 데이터를 가져와 캐시에 저장하면 다음에 해당 데이터가 있을 때 데이터베이스로 다시 접속할 필요가 없습니다. 결과적으로 애플리케이션 성능과 전반적인 확장성이 향상됩니다. 메모리 내 접근이 가능해 성능이 향상되기 때문입니다. 여러 대의 서버가 요청을 호스팅하고 처리합니다. 따라서 상대적으로 확장성이 뛰어납니다. 또한, 고가용성 및 데이터 안정성 기능도 내장되어 있습니다. NCache 실험 계획안.
NCache 애플리케이션이 실행되는 동일한 시스템에 호스팅될 수 있습니다. 또는 별도의 계층일 수도 있습니다. 클라우드에서는 별도의 전용 캐시 계층을 사용하고 애플리케이션 인스턴스가 해당 계층에서 실행되는 것이 선호됩니다. 하지만 두 모델 모두 다음과 같은 측면에서 지원됩니다. NCache 걱정이다.
확장성 수치입니다. 최근 AWS 랩에서 이러한 테스트를 수행했습니다. 읽기 및 쓰기 요청 부하를 시뮬레이션하면서 부하를 계속 증가시켰고, 특정 시점 이후 서버가 최대치에 도달하는 것을 확인했을 때 캐시 클러스터의 서버 수를 늘렸습니다. 그 결과, 서버 수를 2대에서 3대로, 그리고 3대에서 4대로 늘렸고, 단 2대만으로 초당 5만 건의 요청 처리량을 달성할 수 있었습니다. NCache 서버도 아니고, 터치 앤 고(touch-and-go) 데이터도 아닙니다. 실제 애플리케이션 데이터였지만, AWS 랩에서 애플리케이션 내부에서 시뮬레이션한 것입니다. 지연 시간 요소도 매우 최적화되어 있었습니다. 이 모든 것을 마이크로초 단위의 지연 시간 내에 달성할 수 있었습니다. 따라서 이 모든 부하를 처리할 수 있었음에도 불구하고 개별 요청 성능은 저하되지 않았습니다.
일반적인 사용 사례: 분산 캐시
일부 사용 사례는 다음과 같습니다. Redis 또한 그러나 나는 그것에 대해 이야기 할 것이다 NCache 비교할 것이다.
앱 데이터 캐싱
일반적으로 백엔드 데이터베이스에서 가져오는 거의 모든 것을 캐시하고 데이터베이스에 데이터가 존재하는 경우, 이제 캐시하려고 합니다. 이렇게 하면 데이터베이스로의 값비싼 이동을 줄일 수 있고, 데이터베이스가 느리고 트랜잭션 부하 처리 측면에서 최적화되지 않았다는 것을 이미 확인했습니다. 이 라인에는 많은 데이터베이스 동기화 기능이 있지만, 여기서는 간단히 연결하면 됩니다. NCache 그리고 기본적으로 API를 사용하여 연결을 만들고 데이터 호출을 수행합니다. NCache따라서 거의 모든 것을 캐싱할 수 있습니다. 도메인 객체, 컬렉션, 데이터 세트, 이미지 등 모든 종류의 애플리케이션 관련 데이터를 데이터 캐싱 모델을 사용하여 캐싱할 수 있습니다.
ASP.NET / ASP.NET Core 캐싱
다음으로 ASP.NET 및 ASP.NET Core 전용 캐싱이 있습니다. 이는 ASP.NET 또는 ASP.NET Core 세션 상태 캐싱에 사용할 수 있는 기술적인 사용 사례입니다. ASP.NET 또는 ASP.NET Core SignalR 백플레인에도 사용할 수 있습니다. NCache 백플레인으로 플러그인할 수 있습니다. ASP.NET Core의 경우 응답 캐싱에도 사용할 수 있습니다. IDistributedCache 인터페이스와 세션을 통해 작동합니다. IDistributedCache 인터페이스, 이 두 가지 기능도 지원됩니다. NCache 레거시 애플리케이션의 경우 뷰 상태 및 출력 캐싱에도 사용할 수 있습니다. 론에게 간단한 질문을 던지고 싶습니다.
우리는 들어왔고, 질문은 다음과 같습니다. NCache Azure는 서버리스 프로그래밍 모델을 지원하나요?
물론입니다. Azure 배포 측면에서는 애플리케이션을 서버에 배포할 수도 있고, 애플리케이션 측면에서는 서버리스 애플리케이션일 수도 있습니다. NuGet 패키지를 애플리케이션에 포함하기만 하면 해당 애플리케이션은 NCache 필요할 때마다 전화를 걸 수 있습니다. 설치가 필요하지도 않습니다. NCache 또는 애플리케이션 리소스와 관련하여 서버를 설정해야 합니다. 하지만, NCache 서버 측 배포 자체가 다음과 같은 이유로 관련됩니다. NCache 데이터 소스이므로 애플리케이션이 연결하고 데이터를 검색하고 추가하는 VM 또는 VM 세트가 있어야 합니다.
그래서 서버에서, NCache 캐시 서버 관점에서 소스로서 필요한 것 NCache 서버는 있지만 애플리케이션 측면에서는 서버리스로 운영해도 아무런 문제가 없습니다. 마이크로서비스 아키텍처도 마찬가지입니다. 마이크로서비스는 매우 흔한 예입니다. 마이크로서비스는 여러 종류가 있습니다. Azure 함수는 단순히 실행만 하고 많은 데이터를 처리하며, 그 데이터는 다음에서 가져올 수 있습니다. NCache. 그래서 당신은 치료합니다 NCache 데이터 소스로. 반면, 애플리케이션은 서버리스일 수 있으며 NCache 해당 모델과 완벽하게 호환됩니다.
Pub/Sub 메시징 및 이벤트
그 다음에는 또 다른 사용 사례가 있습니다. 게시/구독 메시징 마이크로서비스를 중심으로 진행되는데, 이는 서버리스 애플리케이션에 메시징을 사용할 수 있는 인상적인 사용 사례 중 하나이기 때문입니다. 마이크로서비스는 느슨하게 결합된 서버리스 애플리케이션이며, 이들 간의 통신을 구축하는 것은 큰 과제입니다. 따라서 이벤트 기반 비동기 이벤트 전파 메커니즘을 활용할 수 있는 Pub/Sub 메시징 플랫폼을 사용할 수 있습니다. 여러 애플리케이션이 메시지를 게시할 수 있습니다. NCache 구독자는 해당 메시지를 받을 수 있습니다.
비동기 이벤트 기반 메커니즘을 기반으로 하므로 게시자 애플리케이션은 확인이나 메시지 전달을 기다릴 필요가 없으며, 마찬가지로 구독자도 메시지를 기다리거나 폴링할 필요가 없습니다. 알림이 발생하면 콜백을 통해 알림을 받습니다. 따라서 매우 유연하며, 이는 다음과 같은 용도로 사용할 수 있습니다. NCache 귀하의 애플리케이션을 위한 Pub/Sub 메시징 플랫폼으로 활용하세요.
NCache 연혁
좀 더 자세한 내용을 설명한 다음 차이점에 대해 이야기하겠습니다. NCache Redis. NCache 2005년에 출시되었습니다. 현재 15년 넘게 시장에 출시되었습니다. 현재 버전은 NCache 5.0, 15번째 버전입니다. 고객 수가 정말 많습니다. NCache 오픈 소스 버전으로도 제공됩니다. 저희 웹사이트와 GitHub 저장소에서 다운로드하실 수 있습니다.
일부 NCache 고객
저희 고객 중 일부입니다. 자세한 목록도 확인하실 수 있습니다.
플랫폼 및 기술
다음으로 우리는 어떻게 할 것인지에 대해 이야기하겠습니다. NCache 와 비교 Redis 첫 번째 세그먼트는 기술 전반에 대한 소개를 기반으로 합니다. 분산 캐싱 기술에 대한 정보를 제공합니다. 이제 분산 캐싱이 어떻게 작동하는지 직접 살펴보겠습니다. NCache 와 비교 Redis 그리고 제가 공식화한 몇 가지 세그먼트가 있습니다.
그래서 우리가 정의한 첫 번째 섹션은 플랫폼과 기술이며 처음에 우리가 타겟팅하고 있다고 언급했습니다. NCache 5.0.2. 그래서, NCache 5.0 SP2는 메인 버전입니다. NCache 사이트 및 Redis 관점에서 우리는 Azure를 사용할 것입니다 Redis 비교를 위해 오픈 소스에 대해서도 이야기해 보겠습니다. Redis 그 일부로 실험실. 이러한 세부 사항의 대부분은 다양한 맛에 공통적입니다. Redis.
네이티브 .NET 캐시
Azure 배경을 가지고 있다면 제품을 선택할 때 가장 중요한 것은 플랫폼과의 호환성입니다.
그래서, NCache 이 제품 자체는 100% .NET으로 작성되었습니다. 애플리케이션 측면에서 보면 네이티브 .NET 또는 .NET Core 제품입니다. 즉, 기본적으로 .NET으로 작성되었고 주로 .NET 애플리케이션용으로 개발되었으며 Windows Server 2016, 2019, 심지어 2012에도 배포할 수 있습니다. 유일한 필수 조건은 다음과 같습니다. NCache .NET 프레임워크인지, 아니면 .NET Core인지에 따라 다릅니다. 반면에, RedisC++로 작성되었습니다. NCache .NET으로 작성되었습니다. 100% 개발되었으며, 실제로 C#이 주요 기술 언어로 사용되고 있고, 100% 네이티브 .NET 및 .NET Core입니다. Redis C++ Linux 기반 솔루션입니다.
Windows 관점에서, Windows 기반 경험이 있고 .NET으로 작성된 애플리케이션을 사용하는 경우, 동일한 기술 스택을 사용하기 위해 .NET으로 작성된 제품을 사용하는 것이 자연스러운 선택입니다. 애플리케이션 개발 스택에 많은 변형이 있을 필요는 없습니다. 즉, 이 두 제품의 차이점 중 하나는 바로 이 부분입니다.
두 번째 측면은 Windows 대 Linux이며 그 다음에 무엇이 사용 가능한지 알 수 있습니다. NCache 그리고 무엇이 사용 가능한지 Redis 측면. Windows, 관점에서 NCache Windows 배포가 권장되지만, .NET Core 서버 릴리스를 통해 Linux 배포판도 사용할 수 있습니다. 따라서 Windows 2012, 2016, 2019와 완벽하게 호환됩니다. Windows용 Docker 이미지도 제공됩니다. NCache. 따라서 Docker 이미지를 다운로드하고 Windows 이미지를 회전시키면 됩니다. NCache 필요에 따라 운영 환경에서 완벽하게 지원합니다. 이는 저희 측에서 제공하는 공식 지원입니다. Redis Microsoft Azure에서도 Redis Linux에서 호스팅됩니다. 선호되는 접근 방식, 선호되는 배포 모델은 Linux입니다. RedisWindows 버전은 타사 프로젝트입니다. Microsoft Open Tech에서 포팅 버전을 출시했습니다. 공식적인 지원은 제공되지 않습니다. Redis 프로젝트 자체는 보류되었습니다. 버그가 많고 불안정하며 Azure도 마찬가지입니다. Redis앞서 논의한 바와 같이 Linux 버전을 사용하며 이것의 큰 문제는 공식적인 지원이 없다는 것입니다. Redis의 제조업체 Redis 또는 오픈 소스 프로젝트를 사용하고 자신의 건물에 배포하려는 관점에서 보면 많은 문제가 발생할 것입니다.
이와 관련하여 또 다른 측면을 강조하고 싶습니다. NCache 온프레미스에서 마이그레이션하고 Azure에서 사용하려는 경우, 동일한 소프트웨어가 그대로 작동합니다. 따라서 마이그레이션 후 변경 사항이 필요하지 않습니다. NCache 온프레미스에서 Azure로. 마찬가지로 클라우드 공급업체 내에서도 다음을 사용할 계획이라면 NCache Azure에서는 필요한 경우 AWS로 마이그레이션할 수 있습니다. 모든 플랫폼에서 동일한 소프트웨어를 사용할 수 있기 때문입니다. 하지만 Redis 걱정되는 Azure Redis 백엔드 배포 측면에서는 Linux에 배포되는 호스팅 모델이지만, 온프레미스에서는 동일한 버전을 사용할 수 없습니다. 따라서 오픈 소스를 사용해야 합니다. Redis 또는 타사 공급업체를 이용해야 합니다. 심지어 완전히 다른 제품인 상업용 버전을 사용해야 할 수도 있습니다.
그래서 여기서 제가 강조하고 싶은 주요 사항은 다음과 같습니다. Redis 오픈 소스 또는 일부 상용 버전인 온프레미스와 비교 Redis Azure 또는 Redis AWS에서는 Elastic Cache를 사용합니다. 이 둘은 완전히 별개의 제품입니다. 따라서 전환이 필요하고 많은 변화가 있습니다. Redis 일부 변경 없이 한 환경에서 다른 환경으로 전환할 수 있습니다. 일부 기능 세트가 누락되었고, 일부 API가 다릅니다. 이러한 제품 간의 배포 모델이 완전히 변경되었습니다. 따라서 계속 사용하면 변경 사항이 없습니다. NCache Windows 또는 Linux에서 온프레미스로 마이그레이션하고 Azure로 이동하려는 경우 정확히 동일한 제품이고 이제 Azure에서 AWS로 변경하고 클라우드 공급업체를 변경하려는 경우 더 유연합니다. Redis. 그래서, NCache 훨씬 더 유연합니다.
리눅스 지원, NCache 완벽하게 호환되며 공식적으로 지원됩니다. 성능도 테스트되었으며 Linux 성능은 동등 수준으로 매우 빠릅니다. NCache Windows에서 사용 가능합니다. Docker 이미지도 제공됩니다. 프로덕션 환경에서 완벽하게 지원되며, 완벽하게 통합된 모니터링 및 관리 도구도 제공합니다. 웹 관리 및 모니터링 도구 어디서든 액세스할 수 있습니다. 따라서 Linux 배포도 Windows 배포를 배포하고 관리하고 모니터링하는 것처럼 관리하고 모니터링할 수 있습니다. NCache. Linux도 지원됩니다. Redis. 따라서 생산 지원은 다음에서 가능합니다. Redis 랩.아주르 Redis Linux 버전에서도 호스팅됩니다. 즉, 공급업체에서 직접 지원합니다.
플랫폼 다음으로 중요한 두 번째 요소는 바로 .NET 및 .NET Core 기술 스택입니다. 공식 클라이언트를 제공하고 있으며, 이를 구현하여 완벽하게 지원합니다. 필요한 기능이 있다면 언제든지 문의해 주세요. NCache 모든 환경에서 호환됩니다. 따라서 온프레미스, Azure 또는 AWS 환경을 선택하더라도 동일한 기능을 사용할 수 있습니다. NCache 그리고 클라이언트는 모든 분야에서 사용 가능합니다. 또한, 변경 사항이 있는 경우, 프로젝트와 관련된 모든 것을 소유하고 있기 때문에 공식적으로 해당 변경 사항을 제공할 것입니다. Redis 서드파티입니다. 따라서 언어마다 지원이 다르고, 각 언어에서 제공되는 지원도 각기 다른 벤더에서 제공됩니다. 따라서 기능 세트에 차이가 있을 수 있고, 출시 주기에도 차이가 있을 수 있습니다. 따라서 기술적인 측면에서, 그리고 고객 요구 사항 측면에서는 서드파티 클라이언트에 의존해야 합니다.
그래서 저는 몇 가지 측면을 강조하고 싶습니다. NCache .NET 및 .NET Core 네이티브 제품입니다. NCache Windows와 Linux에서 완벽하게 지원됩니다. Redis Windows에서는 그다지 안정적이지 않습니다. 타사 포팅 버전이고 Linux 지원도 제공되므로 Linux 지원에 의존해야 합니다. Redis 걱정됩니다. Microsoft 기술 분야 출신이라면 이 부분에는 반드시 의지해야 합니다.
캐시 성능 및 확장성
두 번째 측면은 캐시 성능입니다. 이 또한 매우 중요한 측면입니다.
두 제품 모두 매우 빠르며 이것이 여기서의 주요 이점입니다. NCache Redis이러한 제품을 선택하는 주된 이유는 성능 향상 측면입니다. 데이터베이스가 느리고 확장성이 떨어진다는 점은 이미 확인했습니다. 이러한 제품은 상대적으로 빠르고 확장성이 뛰어납니다. 따라서 어떤 장점도 깎아내리지 않겠습니다. Redis. Windows 버전만은 안정적이지 않고 성능 문제가 있지만 Linux 버전이 있으면 매우 빠르고 확장 가능하며 매우 빠릅니다. NCache 또한 매우 빠르고 확장성이 뛰어납니다. 저희는 자체적으로 구현한 TCP/IP 기반 클러스터링 프로토콜을 보유하고 있는데, 최적화가 잘 되어 있고 성능도 매우 견고합니다.
그러나 여기에도 몇 가지 차이점이 있습니다. NCache 저희는 다양한 성능 개선 기능을 제공합니다. 최근에는 웨비나도 진행했는데, 여기서는 6가지 성능 개선 방법을 다루었습니다. NCache 성능. 설정하면 NCache 기본적으로 매우 뛰어난 성능을 제공하지만, 사용 사례에 따라 다양한 기능을 활성화하여 성능을 더욱 향상시킬 수 있습니다. 그러한 기능 중 하나가 클라이언트 캐시입니다.
NCache: 클라이언트 캐시(캐시 근처)
클라이언트 캐시는 고유한 기능입니다. NCache. Redis 이 기능이 없습니다.
클라이언트 측 로컬 캐시로, 서버리스 애플리케이션에서도 사용 가능하며 애플리케이션 프로세스 내에 InProc 복사본을 저장할 수 있습니다. 서버 기반 애플리케이션의 경우 프로세스 외부 클라이언트 캐시를 사용할 수 있습니다. 이 캐시는 네트워크를 통해 캐시 클러스터로 이동하는 데 드는 비용이 많이 드는 작업을 줄여줍니다. 이 캐시는 이미 백엔드 데이터 소스로 이동하는 데 드는 비용을 절감하고 있었습니다. 이제 캐시를 중간에 두고 캐시에 100개의 항목이 있다고 가정하고 애플리케이션 측에서 10개의 항목을 입력하면 해당 10개의 항목이 자동으로 클라이언트 캐시로 다시 전송됩니다. 그러면 다음에 애플리케이션이 해당 데이터를 애플리케이션에 더 가까운 곳에서 찾을 수 있으므로 네트워크 이동 비용이 줄어듭니다.
그리고 이것은 동기화된 클라이언트 캐시입니다. 동기화는 다음에 의해 관리됩니다. NCache. 변경 사항이 있는 경우 클라이언트 캐시 마스터 복사본이기 때문에 서버 캐시에 많이 전파됩니다. 이는 데이터의 하위 집합이며, 변경 사항은 다른 클라이언트 캐시에도 전파됩니다. 참조 데이터 시나리오가 있는 경우, 읽기 후 쓰기가 많은 경우, 클라이언트 캐시를 활성화하는 것이 좋습니다. 데이터베이스를 대상으로 실행되는 캐시보다 훨씬 뛰어난 성능을 얻을 수 있습니다.
최근 저희는 고객사 중 한 곳, 특히 규모가 큰 고객사와 POC(실증 분석)를 진행했습니다. 기본 구성으로 약 46초가 소요되는 워크플로를 구축하고 있었는데, NCache 호출 및 데이터 검색이었습니다. 주로 읽기 집약적인 사용 사례였습니다. 클라이언트 캐시를 프로세스 외부에서 활성화했는데, 두 가지 방식이 있습니다. 프로세스 외부에서 실행하는 방식, 즉 애플리케이션에서 별도의 캐시 프로세스를 실행하는 방식과 클라이언트 캐시가 애플리케이션 프로세스 내부에서 실행되는 InProc를 사용하는 방식입니다. InProc는 직렬화나 프로세스 간 통신 오버헤드가 없습니다. 따라서 매우 빠릅니다. OutProc와 비교해도 더 빠릅니다. 해당 고객의 경우 워크플로 시작에 약 46초가 걸렸습니다. 그런 다음 프로세스 외부 클라이언트 캐시를 활성화하여 3~4초로 줄였고, 다시 InProc 클라이언트 캐시를 활성화하여 이 모든 작업을 400~500밀리초 안에 완료할 수 있었습니다. 46초에서 400~500밀리초로 단축된 것이 바로 이러한 개선 사항이며, 이 기능은 다른 제품이나 다른 버전에서는 전혀 사용할 수 없습니다. Redis를 포함한 Redis 오픈 소스 프로젝트 및 Azure를 포함한 랩 Redis.
클라이언트 캐시를 사용하여 성능을 조정할 수 있으며, 코드 변경 없이 바로 사용할 수 있습니다. 설정만 켜 주시면 됩니다.
대량 작업은 양쪽에서 지원되지만 NCache 저희의 대량 작업은 전체 캐시 클러스터에서 작동합니다. 즉, 서버가 10대이고 데이터가 완전히 분산되어 있는 경우, 대량 호출을 통해 모든 서버에서 데이터를 가져와 통합된 결과를 가져옵니다. 즉, 이러한 모든 작업이 서로 결합되어 결과를 도출하고, 결과적으로 완전한 결과를 얻게 됩니다. 반면 Redis 대량 작업은 샤드 수준에서 이루어집니다. 따라서 주어진 샤드의 데이터를 처리해야 합니다. 이것이 한계입니다. 예를 들어 캐시 클러스터에 여러 노드가 있고 사용 가능한 마스터 샤드가 있다면, 주어진 샤드에서 대량 작업을 수행할 수 있습니다.
네, 그게 한계입니다. 그렇지 않으면, 이 기능은 개별 요청을 여러 번 주고받는 대신 큰 요청을 보내 모든 데이터를 한 번에 받아 성능을 입증할 수 있는 좋은 성능 향상 기능입니다.
직렬화는 또 다른 기능이며 대부분의 시간을 데이터 직렬화 및 역직렬화에 소비하게 되므로 또 다른 측면이 있습니다. NCache 뿐만 아니라 Redis. 기본적으로 두 제품 모두 직렬화 및 역직렬화를 수행하지만 NCache 직렬화 및 역직렬화 오버헤드를 개선할 방법이 있습니다. 빠르고 복잡한 직렬화를 사용하면 일반적으로 애플리케이션에 걸리는 직렬화 시간을 최적화할 수 있습니다. 객체가 복잡해지면 코드를 변경하지 않고도 객체를 컴팩트 유형으로 정의할 수 있습니다. NCache 이를 통해 런타임에 컴팩트한 직렬화가 실행되고 직렬화 및 역직렬화 오버헤드도 개선됩니다.
마지막으로, 압축 기능도 있습니다. 압축은 클라이언트 측에서 수행됩니다. 일반적으로 2MB, 3MB 또는 500KB와 같이 더 큰 객체를 처리하는 경우 더 큰 객체입니다. 따라서 일반적으로 작은 객체를 처리하는 것이 좋지만, 더 큰 객체가 있는 경우 네트워크 사용량이 많아 성능이 저하됩니다. NCache 압축을 켤 수 있습니다. 이는 코드 변경이 필요 없는 옵션으로, Redis 캐시에 항목을 추가하는 동안 자동으로 압축합니다. 따라서 더 작은 객체가 추가되어 애플리케이션과 캐시 간에 전송되고, 애플리케이션 측에서도 동일한 작은 객체가 다시 검색됩니다. 더 작은 페이로드를 처리하면 애플리케이션 성능이 향상됩니다. 따라서 압축을 활성화하면 전반적인 애플리케이션 성능이 향상됩니다.
따라서 100KB보다 큰 객체의 경우 압축을 켜고 임계값을 설정하여 더 큰 객체만 압축하고 더 작은 객체는 그대로 두는 것이 좋습니다.
따라서 이러한 모든 성능 개선 기능, 클라이언트 캐시, 대량 작업, 컴팩트 직렬화, 압축은 사용할 수 없거나 Redis예를 들어, 클라이언트 캐시를 사용할 수 없습니다. 대량 작업은 가능하지만 제한적입니다. 직렬화 최적화 옵션이 없고 압축도 사용할 수 없습니다. 따라서 이 부분에서 두 가지의 명확한 차이점이 나타납니다. NCache Redis어디로 NCache 성능 중심 기능이 많이 내장된 완벽한 패키지입니다.
고 가용성
다음 세그먼트는 고가용성이며 여기서 엄청난 기능 세트 차이가 나타납니다. NCache Redis고가용성은 이러한 요소들을 비교할 수 있는 또 다른 측면입니다. 미션 크리티컬 애플리케이션의 경우, 소스가 필요하다는 점에서 매우 중요한 측면입니다. 이제 일반적으로 데이터베이스에 있는 데이터를 가져오고, 데이터베이스 내에서 일종의 미러링이나 백업을 수행하게 될 것입니다. 맞습니까?
분산 캐시 제품으로 데이터를 이동하면 성능이 향상될 뿐만 아니라 확장성도 뛰어나지만, 고가용성이 매우 중요합니다. 미션 크리티컬 애플리케이션의 경우, 어떠한 다운타임도 용납될 수 없습니다. 다운타임은 비즈니스와 사용자 경험에 영향을 미칠 수 있기 때문입니다. 따라서 비용 부담이 큽니다. 따라서 애플리케이션이 데이터가 있는 캐시에서 항상 응답을 받을 수 있도록 하는 것이 매우 중요합니다. 따라서 기능상의 큰 차이점이 있습니다.
캐시 클러스터
NCache 100% 피어투피어 아키텍처의 캐시 클러스터입니다.
그것은 역동적이고 자체 치유적이며, 그것이 어떻게 작동하는지 말씀드리겠습니다. 그러나 비교해보면 Redis 마스터/슬레이브를 사용합니다. 따라서 피어 투 피어 아키텍처를 사용합니다. NCache 서버를 자동으로 추가 및 제거할 수 있으며, 애플리케이션과 원활하게 연동됩니다. 필요한 만큼 서버를 추가할 수 있습니다. 예를 들어, 두 대의 서버로 시작했다가 세 번째 서버를 추가하려는 경우, 즉시 추가할 수 있습니다. 캐시나 해당 캐시에 연결된 클라이언트 애플리케이션을 중단할 필요가 없습니다. 원활한 사용자 경험을 보장합니다. 따라서 고가용성 및 데이터 안정성 기능을 통해 애플리케이션은 다운타임이나 데이터 손실 없이 계속 작동할 수 있습니다. Redis 새 샤드를 자동으로 추가할 수 없습니다. 자동 데이터 리밸런싱 기능이 없기 때문입니다. 이것이 바로 캐시 클러스터의 동적 특성의 핵심입니다. NCache새로운 서버를 추가하면 자동으로 데이터의 균형을 재조정합니다.
두 가지 시나리오가 있습니다. 하나는 용량을 늘리고 확장성을 높이기 위해 새 서버를 추가하는 경우이고, 다른 하나는 기존 서버를 중단하는 경우입니다.
그럼, 먼저 노드 추가 시나리오를 살펴보겠습니다. 새 노드가 조인됩니다. NCache, 귀하의 데이터는 자동으로 배포됩니다.
예를 들어, 서버가 2대에서 3대로 늘어나고 2대를 더 추가하면, 기존 데이터는 6개 항목으로 전송되고, 새로운 서버를 추가하면 기존 데이터는 새로 추가된 서버로 분산됩니다. 즉, 해당 서버는 기존 서버의 데이터 일부를 가져오고, 이 작업은 자동으로 수행됩니다. 이는 본질적으로 동적입니다. 따라서 자동으로 데이터가 재분배됩니다. Redis, 이는 데이터의 수동 재조정이며 Azure에 해당합니다. Redis Azure에는 다양한 계층이 있습니다. 기본, 중간, 그리고 고급 계층이 있습니다. 클러스터링은 고급 계층에서만 적용되며, 이 역시 비용이 많이 들고, 최소 3대의 서버가 필요하다는 제약이 있습니다.
와 NCache 단 두 대의 서버만으로도 클러스터링을 완벽하게 구축하고 실행할 수 있으며, 여기에 새 서버를 추가하면 수동으로 데이터를 재조정해야 합니다. 이는 큰 문제입니다. 따라서 애플리케이션과 용량 추가 계획 시점에 제약이 있을 수 있습니다. 반면, NCache 런타임에 이 작업을 수행할 수 있으며, 필요에 따라 서버를 추가할 수도 있습니다.
두 번째 측면은 서버가 다운되는 것입니다. 그래서 우리는 Redis 마스터와 슬레이브 개념이 있습니다. 마스터는 슬레이브에 데이터를 복제합니다. 슬레이브 샤드가 있습니다. 따라서 마스터는 데이터를 복제해야 하며, 이는 동기 또는 비동기 방식으로 이루어질 수 있습니다. Redis슬레이브 샤드가 다운되면 마스터 샤드 자체가 중단되고 클러스터를 사용할 수 없게 됩니다. 따라서 이는 심각한 문제이며 항상 발생할 수 있습니다. 오픈 소스 또는 Redis 실험실 배치 Redis. 이 경우, 마스터 샤드의 슬레이브 서버였던 서버가 다운되면 클러스터 자체를 사용할 수 없게 됩니다. 따라서 이러한 상황에서 복구하려면 직접 개입하여 수동으로 조치를 취해야 합니다. 반면, NCache 자동으로 작동합니다. 즉, 어떤 서버든 다운될 수 있고, 살아남은 노드는 활성 상태이거나 백업 상태일 수 있습니다.
예를 들어, 이 서버가 다운되고, 이 서버는 활성 파티션이며 백업 파티션도 있다고 가정해 보겠습니다. 이 서버 전체가 다운되면 백업 파티션이 활성 파티션을 활성화합니다. 백업 파티션이 활성 파티션으로 활성화되면 모든 데이터를 활성 노드에서 가져오고, 연결 장애 조치 기능이 내장되어 있습니다. 서버가 다운되는 모든 클라이언트는 런타임에 이를 감지하고 활성 노드로 장애 조치를 취합니다. 여기서 이 개념을 다시 한번 강조하고 싶습니다. Redis 최소 3개의 서버가 필요합니다. 이것이 다수결 원칙의 개념입니다. 클러스터 코디네이터는 선거에서 이겨야 합니다. 하지만 다음과 같은 경우는 그렇지 않습니다. NCache. 단 2개의 노드만으로도 완벽하게 작동하는 캐시 클러스터를 시작할 수 있으며, 완벽한 고가용성 기능을 제공합니다. 서버가 다운되더라도 살아남은 노드는 문제 없이 완벽하게 작동할 수 있지만, Redis.
동적 구성. 런타임에 클러스터 구성을 변경할 수 있으며, 여기에는 새 서버 추가, 서버 제거 또는 캐시 클러스터의 일부 설정 변경이 포함됩니다. 이는 전체 충돌 클러스터를 중지하지 않고 런타임에 적용할 수 있는 기능입니다. 반면, Redis제한적입니다. 수동으로 적용해야 하는 구성이 많고 사용 가능한 클러스터 상태 이벤트도 많습니다. NCache 구독할 수 있는 측면입니다. 모니터링 및 관리 도구를 사용할 수 있습니다. 반면, Redis 해당 기능이 없습니다.
이건 아주 중요한 개념입니다. 간단히 요약해 드리겠습니다. 서버 추가 및 제거 Redis 많은 문제가 발생할 수 있습니다. 데이터 추가 시 자동으로 리밸런싱되지 않기 때문입니다. 즉, 100% P2P(피어 투 피어) 아키텍처가 아닙니다. 캐시 클러스터의 용량이 제한됩니다. 마찬가지로, 슬레이브 샤드가 다운되면 클러스터 자체를 사용할 수 없게 됩니다. 분산 문제가 발생하여 이제 수동으로 관리해야 하기 때문입니다. 장애 조치(failover)도 수동으로 해야 하죠? 따라서 서버가 다운되면 수동으로 장애 조치를 수행하고 생존 노드를 사용해야 합니다. 새 서버를 추가하면 새로 추가된 서버로 수동으로 전환해야 합니다.
자, 이게 바로 여러분이 겪게 될 모든 제약입니다. 아시다시피, 이런 종류의 프로덕션 배포를 사용하다가 용량을 늘리거나 유지 관리를 위해 서버를 다운해야 하는 상황을 보게 된다면 정말 놀라실 겁니다. 이런 제품에서는 매우 어려울 겁니다. Redis. 이므로, NCache 원활한 환경을 제공합니다. 아무 영향 없이 서버를 즉시 추가하거나 제거할 수 있습니다.
동적 파티션/샤드
클러스터 내부의 또 다른 개념은 자가 치유 메커니즘입니다.
NCache 동적 파티션이 있습니다. 서버를 추가하면 데이터가 재분배되고, 런타임에 새로운 파티션이 생성됩니다. 마찬가지로, 서버를 다운시키면 클러스터가 백업을 제공하고, 2개에서 3개로 다운시키면 자체 복구하여 정상적인 2노드 캐시 클러스터를 구성합니다. 안정성 측면에서도 마찬가지입니다. 복제 파티션이 있으며, 이는 다음에서도 사용할 수 있습니다. Redis 슬레이브 형태로 사용되지만 높은 가용성은 복제에 따라 달라집니다. Redis 슬레이브 샤드를 구성하지 않으면 고가용성을 확보할 수 없습니다. 따라서 슬레이브 샤드를 사용 가능하게 설정해야 합니다. 반면, NCache, 우리는 토폴로지를 가지고 있습니다.
예를 들어, 마스터 샤드와 마스터 파티션이 있는 분할 캐시가 있습니다. 이 서버에 장애가 발생하더라도 클라이언트가 이를 감지하고 장애 조치를 취하여 생존 노드를 사용하기 때문에 고가용성을 유지할 수 있습니다. 데이터 손실이 발생할 수 있으며, 이는 Redis 복제가 없어서 데이터 손실이 발생하지만 가용성은 여전히 높습니다. 그리고 여기에 복제 지원까지 추가된 향상된 기능도 있습니다. 서버가 다운되면 서버 백업을 사용할 수 있을 뿐만 아니라 클라이언트도 자동으로 장애 조치됩니다. 따라서 Redis 제한적입니다. 고가용성은 복제에 따라 달라집니다. 복제가 활성화되어 있지 않으면 고가용성을 확보할 수 없으며, 이 또한 제한 요소입니다.
그리고 수동 개입이 필요하지 않은 자체 치유 메커니즘이 있습니다.
서버 3대로 시작한다면, 서버 하나를 다운시키고 활성 파티션인 마스터를 사용하다가 다른 서버의 슬레이브도 잃게 됩니다. 이 경우 서버 3의 백업이 서버 1에 있었기 때문에, 이 기능이 활성화됩니다. 런타임에 활성 파티션에 조인됩니다. 별도의 개입이 필요하지 않습니다. 수동 작업이 필요하며, 이후 서버 2의 파티션이 서버 1에 정상적인 파티션을 구성합니다. 따라서 클러스터는 자동으로 복구되는데, 이것이 바로 동적 특성입니다. NCache 비교해서 Redis. 어디에 Redis샤드는 런타임에 재조정될 수 없습니다. 슬레이브 샤드가 다운되면 클러스터가 중지됩니다. 데이터 재분배는 동적이지 않습니다. 고가용성은 복제에 의존하지만, NCache. NCache 복제 없이도 높은 가용성을 제공합니다.
그래서, 당신이 얻는 이 모든 혜택은 NCache, 이러한 기능이 완전히 누락되었거나 제한되어 있기 때문에 제품이 훨씬 더 우수해집니다. Redis 그리고 이것은 Azure에도 해당됩니다. Redis. 이것은 오픈 소스에도 해당됩니다. 왜냐하면 이것들은 매우 유사한 제품이기 때문입니다. Redis 실험실 Redis 제공도 합니다.
NCache Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
이제 실제 제품이 어떻게 작동하는지 보여드리는 데 시간을 할애하여 귀하에게 통찰력을 제공하려고 합니다. NCache 구성되었습니다. 여기가 데모 환경입니다. 제가 직접 작업해 봤습니다. 새 캐시를 생성하겠습니다. 이 웹 관리 도구는 다음과 같이 설치됩니다. NCache직렬화 모드는 바이너리 또는 JSON일 수 있습니다. 전적으로 여러분의 선택에 달려 있습니다. 캐시 이름만 지정하고, 캐시 클러스터를 생성하고, 클라이언트 애플리케이션을 연결하고, 모니터링하고 관리하는 방법을 보여드리겠습니다.
따라서 이 웨비나의 주요 초점은 다음과 같으므로 모든 것을 간단하게 설명하겠습니다. NCache 대 Redis, 모든 세부 사항은 간단하게 설명하겠습니다. 분할된 복제본이 가장 권장하는 토폴로지입니다. 활성 서버와 백업 서버 간의 비동기 복제입니다. 따라서 동기화를 선택할 수 있습니다. 비동기가 더 빠르므로 이 토폴로지를 선택하겠습니다. 캐시 클러스터의 크기입니다. 그런 다음 다음 서버 노드를 지정합니다. NCache 이미 설치되어 있습니다. TCP 포트. NCache TCP/IP 기반 통신 프로토콜입니다. 따라서 모든 것을 간단하게 설명하겠습니다. 여기서는 캐시가 가득 차도록 '제거' 기능을 활성화하겠습니다. 그러면 캐시에서 일부 항목이 자동으로 제거되어 새 항목을 위한 공간이 확보됩니다. 이 캐시를 시작하고 종료합니다. 서비스 시작 시 자동으로 시작되므로 서버가 재부팅될 때마다 자동으로 캐시 클러스터에 가입됩니다. 이렇게 캐시 클러스터를 구성하고 사용하는 것이 얼마나 간단한지, 다음에 보여드리겠습니다.
클라우드 지원(Azure 및 AWS)
저희의 관리형 서비스 모델이 곧 출시될 예정입니다. 다음 릴리스는 이 부분에 집중될 것 같은데, 아마 2~3주 후에 출시될 것 같습니다. 따라서 완전 관리형 서비스를 제공할 예정입니다. NCache Azure와 AWS 모두에서 서비스 모델로서 소프트웨어를 제공합니다.
현재는 VM 모델로 운영됩니다. 온프레미스 환경이라면 물리적 서버나 VM 서버를 사용할 수 있습니다. Azure를 선택하시는 경우, 마켓플레이스를 통해 VM을 설정하거나, VM을 설정한 후 직접 설치하실 수 있습니다. NCache 웹사이트에서 소프트웨어를 다운로드하여 사용할 수 있습니다. 또한 컨테이너화된 환경도 제공합니다. Docker 이미지가 있으며 Azure Kubernetes Service, EKS(Elastic Kubernetes Service) 및 OpenShift Kubernetes 플랫폼 등 모든 플랫폼에서 완벽하게 지원됩니다. NCache 이미 해당 플랫폼에 완벽하게 통합되어 완벽하게 지원됩니다. 관리 기능은 곧 출시될 예정입니다. 따라서 2~3주 후에는 완전히 이용 가능할 것입니다.
그래서 저는 여러분에게 통계 창을 보여드릴 것입니다. 이것은 perfmon 카운터이고 그런데 이러한 모니터링 옵션은 다음에 사용 가능합니다. NCache, 측면에서 NCache Windows에서도 Linux 환경에서도 그렇죠?
스트레스 테스트 도구를 실행해 보겠습니다. 다른 캐시에 대해 이미 실행 중인 도구가 있는 것 같습니다. 그래서 하나 더 실행해 보겠습니다. 그러면 캐시 클러스터에 대한 더미 부하를 시뮬레이션할 수 있습니다. 이름만 지정하면 구성 파일을 사용하여 서버를 자동으로 검색하고 연결합니다.
클러스터 상태가 완전히 연결되었고, 처리량을 보여주는 초당 요청 수, 캐시 작업당 평균 마이크로초 단위 지연 시간, 추가, 페치, 업데이트, 삭제, 캐시 크기, CPU, 메모리 등이 표시됩니다. 따라서 중앙 집중식 모니터링 뷰를 얻을 수 있습니다. 이 도구를 사용할 수 있으며, Windows perfmon도 사용할 수 있습니다.
Linux 기반 서버에는 맞춤형 모니터링이 제공됩니다. 따라서 Linux 서버에도 저희 모니터링 도구를 직접 사용하실 수 있으며, 타사 도구를 사용하여 모니터링하실 수도 있습니다. NCache 캐시 생성 과정을 간략하게 살펴보았습니다. 모니터링 및 관리 측면도 살펴보았습니다.
자, 다시 돌아오겠습니다. 몇 가지 세부 사항을 논의했으니, 다음으로는 클라우드 제공/클라우드 지원에 대해 이야기해 보겠습니다. Redis 자체적으로 비관리형 캐시를 선택할 수도 있고, 관리형 캐시를 선택할 수도 있으며, 호스팅 서비스도 이용할 수 있습니다. 관리형 옵션은 타사 공급업체에서 제공하며, 호스팅형 옵션은 Azure에서 제공합니다. Redis, 오픈 소스 변형을 가질 수 있는 곳 Redis Microsoft에서 맞춤 설정하여 호스팅 모델로 사용할 수 있습니다. 반면, NCache 캐시 서버 모델과 VM 모델이 있습니다. 컨테이너 접근 방식에 대해서는 이미 논의했습니다. Windows는 물론 Linux 컨테이너와도 완벽하게 호환됩니다. Windows 컨테이너용 Azure Service Fabric에 대한 비디오 데모와 마이크로서비스 아키텍처 세부 정보가 있습니다. Linux 컨테이너를 사용하는 Azure Kubernetes Service도 있습니다. EKS(Elastic Kubernetes Service)도 있고, Kubernetes를 통해 Red Hat OpenShift 컨테이너도 개발했던 것 같습니다.
자, 지금까지 컨테이너 배포 옵션을 살펴보았는데, 모두 유연하고 플랫폼에 구애받지 않습니다. 따라서 어떤 종류의 컨테이너화된 플랫폼에도 문제없이 배포할 수 있습니다. 관리형 서비스도 곧 출시될 예정인데, 이미 논의했듯이요. NCache 관리 서비스가 있었지만 그건 다음 버전에서 구현될 거예요.
VM 모델을 사용하는 것의 중요한 측면 중 하나는 서비스 대신 VM에 연결해야 하지만 모든 것을 제어할 수 있다는 것입니다. 서버 측 코드를 실행할 수도 있는데, 이에 대해서는 다음에 다루겠지만 가장 중요한 측면은 성능입니다. 이미 VM 모델 내에 다양한 성능 기능이 있다는 점을 언급했습니다. NCache, 누락된 RedisAzure를 선택하는 경우 RedisAzure 인프라에 연결해야 합니다. 즉, 이러한 VM은 별도의 가상 네트워크에서 실행됩니다. 이들은 근처에 위치하지만 다시 말해 멀리 떨어져 있습니다. Microsoft Azure에 있는 자체 가상 네트워크와는 다르며, 모든 애플리케이션이 배포되는 네트워크와는 다릅니다.
와 NCache 당신은 우리를 선택할 수 있습니다 NCache 애플리케이션 가상 네트워크와 동일한 가상 네트워크에 배포합니다. 예를 들어, 앱 서비스, Azure 웹사이트, Azure 마이크로서비스는 Azure 가상 네트워크에서 실행됩니다. Azure VM을 동일한 가상 네트워크에 배포하여 애플리케이션 성능을 향상시킬 수 있습니다. 저희 랩에서 자체 테스트를 진행한 결과, NCache SaaS 모델보다 4~5배 더 빠릅니다. Redis Microsoft Azure에서 일반적으로 제공되는 기능입니다. 제가 강조하고 싶은 매우 중요한 측면입니다.
더불어 VM에 대한 제어 권한도 대폭 확대됩니다. 캐시 시작, 크기 증가, 전체 용량 확보 등 모든 제어 권한을 확보할 수 있습니다. 요청 단위, 크기 제한, 사용량 제한이 없으며, 이에 따른 비용도 발생하지 않습니다. 자체 라이선스를 사용할 수 있으며, 영구 라이선스나 구독 라이선스를 통해 라이선스 관리가 매우 유연하게 가능합니다. 또한, 서버 측 코드를 실행할 수 있습니다. NCache 서버입니다. 이를 완벽하게 관리하고 최적화할 수 있습니다. 읽기-통과(read-through), 쓰기-통과(write-through), 쓰기-비하인드(write-behind), 캐시 로더, 그리고 MapReduce, Aggregator, Entry processors와 같은 일부 컴퓨팅 그리드 기능 등 다양한 인터페이스를 작성할 수 있습니다. 이는 다음을 통해서만 가능합니다. NCache. 이러한 모든 제공 사항을 사용할 수 있는 호스팅 모델인 SaaS 모델도 있지만 이는 다음과 같은 경우에는 해당되지 않습니다. Redis. 이것이 바로 우리의 플랫폼입니다.
캐시를 최신 상태로 유지
다음 세그먼트, 15분 동안은 기능 수준 비교에 대해 말씀드리겠습니다. 이를 위해 몇 가지 세그먼트를 정의해 두었습니다. 캐시를 최신 상태로 유지해야 하는 경우를 대비해서 시작하겠습니다. 캐시를 최신 상태로 유지하는 것이 매우 중요합니다. 백엔드 데이터 소스와 애플리케이션 사용 사례에 따라 캐시를 최신 상태로 유지하는 방법에 대한 별도의 웨비나가 있을 예정입니다.
그래서, 비교해보면 Redis, 알잖아, NCache 이쪽에도 많은 특징이 있습니다.
절대적이고 변동 가능한 시간 기반 만료가 있지만, 이에 대한 자동 재로드 메커니즘도 제공합니다. Redis 재로드 메커니즘 없이 절대 만료 및 슬라이딩 만료만 지원합니다. 재로드를 위해 서버 측 코드인 읽기-스루 핸들러라는 인터페이스를 구현할 수 있습니다. 다시 말해, 이는 다음과 같은 이유로 가능합니다. NCache VM에 대한 전체 액세스 권한을 부여할 수 있습니다. NCache 호스팅됩니다. 따라서 서버 측 코드를 그 위에 배포할 수 있습니다. NCache 사용 NCache 이를 뒷받침할 수 있는 컴퓨팅 능력.
캐시를 데이터베이스와 동기화할 수 있습니다. NCache 데이터베이스 동기화에 매우 강력합니다. SQL 종속성이 있고, DB만 호환되는 DB 종속성이 있습니다. .NET CLR 저장 프로시저도 있습니다. 이러한 모든 기능을 통해 캐시를 데이터베이스와 동기화할 수 있습니다. 여기서 중요한 점은 데이터베이스에 변경 사항이 발생하여 데이터베이스의 레코드가 변경되고 해당 레코드가 캐시된 경우, 두 소스가 동기화되지 않을 수 있다는 것입니다. 따라서 NCache데이터베이스에 변경 사항이 있는 경우 해당 데이터를 자동으로 무효화하거나 다시 로드할 수 있습니다. NCache 런타임에. 이것은 고유한 기능입니다. NCache다른 제품에는 이 기능이 없습니다. 따라서 백엔드 데이터베이스와 완벽하게 동기화된 캐시를 사용할 수 있으며, 이는 관계형 데이터베이스뿐만 아니라 비관계형 데이터 소스에도 적용됩니다.
파일 종속성은 항목을 파일에 종속시키는 또 다른 기능입니다. 파일 내용이 변경되면 항목이 자동으로 제거되거나 다시 로드됩니다. 사용자 지정 종속성은 어떤 소스든 사용할 수 있습니다. NoSQL 데이터베이스, 파일 시스템, 관계형 데이터베이스, 커넥터, 웹 서비스 등 무엇이든 가능합니다. 따라서 유연한 요구 사항에 따라 항목의 유효성을 검사할 수 있습니다. Cosmos DB를 사용한 구현 사례를 제공했으며, 동기화 기능도 구현했습니다. NCache Cosmos DB를 사용하는 경우 NCache Cosmos DB와 함께 사용자 정의 종속성을 사용할 수 있으며, 이에 관해 웨비나도 진행한 적이 있는 것 같습니다.
관계형 데이터 처리. 관계형 데이터에는 관계가 있습니다. 캐시의 항목은 키-값 쌍이므로 서로 다른 항목 간의 관계를 만들 수 있는데, 이는 캐시에서 사용할 수 없는 기능입니다. Redis 측면. 따라서 항목을 각각의 장점에 따라 처리해야 합니다. 반면, NCache 일대일, 일대다 또는 다대다 그룹으로 항목을 결합할 수 있습니다. 부모 항목은 변경 사항을 적용받으며, 필요에 따라 자식 항목은 자동으로 무효화되거나 다시 로드될 수 있습니다.
데이터 그룹화, SQL 및 LINQ 검색
또 다른 측면은 데이터 그룹화 및 검색입니다. NCache 매우 강력하다 & Redis 아무런 기능도 없습니다. 그리고 이는 Azure에도 해당됩니다. Redis 어차피 매우 제한적이긴 하지만요. 오픈 소스 Redis 약간 앞서 있지만 기능 면에서는 여전히 제한적입니다. 심지어 Redis Lab은 상용 버전입니다. Redis이러한 기능이 갖춰져 있지 않습니다.
SQL 검색이 가능합니다. 다음 항목 내에서 검색이 가능합니다. NCache 객체 속성을 기반으로 합니다. 객체는 캐시에 추가됩니다. 속성에 대한 인덱스를 정의할 수 있습니다. 예를 들어, 제품은 ID, 가격, 카테고리에 대한 인덱스를 가질 수 있으며, 이제 이러한 속성을 사용하여 해당 제품을 검색할 수 있습니다. 일반적인 예로는 제품 dot category가 특정 값이거나 제품 dot price가 10보다 크고 제품 dot price가 100보다 작은 경우 제품을 선택하는 것입니다. NCache 모든 서버의 모든 항목에 대해 메모리 내 검색을 실행하고 결과를 통합하여 결과 집합을 반환합니다. 따라서 더 이상 키를 다룰 필요가 없습니다. 조건에 따라 데이터를 검색합니다.
LINQ 검색도 사용할 수 있습니다. .NET 및 .NET Core 앱을 지원합니다. LINQ 검색을 사용하시는 경우, LINQ 검색을 실행할 수 있습니다. NCache 또한. 그래서 그것은 독특한 기능입니다 NCache 어디에 Redis 지원이 없습니다. Redis 모든 맛 Redis, 이 지원이 없습니다.
그룹이나 하위 그룹을 만들 수 있습니다. 논리적으로 컬렉션을 만들 수도 있습니다. NCache. 사용할 수 없습니다 Redis 그리고 해당 그룹을 기준으로 데이터를 검색, 업데이트, 제거할 수 있습니다.
태그와 명명된 태그는 속성을 지정할 수 있습니다. 예를 들어, 상품에 키워드를 추가할 수 있습니다. 일반적인 예로 모든 고객에게 고객 태그를 지정할 수 있습니다. 주문 태그가 있는 모든 주문과 특정 고객의 주문에는 고객 ID를 태그로 지정할 수 있습니다. 주문이 필요할 때는 "태그로 가져오기"라고 말하고 주문을 태그로 제공하면 모든 주문을 가져올 수 있습니다. 특정 고객의 주문이 필요할 때는 "모든 태그로 가져오기" 또는 "태그로 가져오기"라고 말하고 고객 ID를 제공하면 해당 고객 ID에 대한 모든 주문을 가져올 수 있습니다. 이처럼 태그와 명명된 태그를 사용하면 유연하게 활용할 수 있습니다. NCache. Redis 이를 지원하지 않습니다.
서버 측 .NET 코드
캐시-어사이드 패턴은 일반적으로 캐시에서 데이터를 먼저 확인하고, 캐시에 데이터가 있으면 반환하고, 캐시에서 데이터를 찾지 못하면 애플리케이션의 백엔드 데이터베이스로 가서 해당 데이터를 가져와 캐시에 저장하는 방식입니다. 즉, null 값이 있으면 null 값을 검색한 후 데이터베이스로 이동합니다. Read-Thru 핸들러를 사용하면 이 과정을 자동화할 수 있습니다. Read-Thru는 서버에서 실행되는 서버 측 코드입니다. NCache 서버입니다. 저희 관리형 서비스에도 이 기능이 있습니다. 따라서 모든 데이터 소스에 연결할 수 있는 이 인터페이스를 구현합니다. 웹 서비스, 관계형 데이터 소스 또는 비관계형 데이터 소스일 수 있으며, 캐시에서 null이 발견되는 즉시 호출되는 여러 메서드가 있습니다.
따라서 Cache.Get 메서드를 호출하고 Read-Thru 플래그를 활성화합니다. 항목이 캐시에 없으면 호출이 Read-Thru 핸들러로 전달되고, 결과적으로 해당 핸들러 코드를 통해 백엔드 데이터베이스에서 데이터를 가져옵니다. 사용자 코드는 다음에서 실행됩니다. NCache 서버 측에서 원활하게 진행할 수 있습니다. NCache 필요한 데이터를 얻으세요.
Write-through는 이와 반대이며 또한 지원됩니다. Redis 캐시에서 무언가를 업데이트할 수 있는 기능이 없고, 이제 데이터베이스를 업데이트하려는 경우, 쓰기-스루(write-through) 핸들러를 호출하여 데이터베이스를 업데이트할 수 있습니다. 이 쓰기-스루 핸들러를 구현하고 등록하면 됩니다. NCache 백엔드 데이터베이스를 업데이트하도록 호출하고, write-behind는 그 반대입니다. 캐시에 대한 모든 업데이트는 클라이언트 애플리케이션에서 반환됩니다. NCache 백엔드 데이터베이스를 백그라운드에서 비동기적으로 업데이트합니다. 따라서 NCache 데이터베이스에 대한 쓰기 작업의 성능도 향상시킬 수 있습니다. 이는 다음과 같은 경우에는 불가능합니다. Redis 서버 측 코드를 실행할 수 없는 경우 다른 어떤 제품도 사용할 수 없습니다. 이것은 순수 네이티브 .NET 및 .NET Core 클래스 라이브러리이며, 이를 구현하고 읽기/쓰기 인터페이스로 등록할 수 있습니다. NCache.
캐시 로더는 또 다른 기능입니다. 인터페이스를 구현하고 등록하여 캐시를 미리 채울 수 있습니다. NCache. 따라서 캐시를 다시 시작할 때마다 중요한 데이터 중 일부가 자동으로 로드됩니다. NCache 모든 서버에서 동시에 실행됩니다. 정말 빠르죠. 모든 데이터를 미리 입력해 두면 다시 데이터베이스에 접속할 필요가 없습니다. 미리 로드해 놓았기 때문에 언제든 원하는 데이터를 찾을 수 있습니다.
사용자 정의 종속성, 엔트리 프로세서는 다시 한번 고유한 기능입니다. NCache 그리고 이러한 기능을 사용할 수 없는 주된 이유는 다음과 같습니다. 우선, Redis 이러한 기능이 없으므로 Azure에서는 모듈이 지원되지 않습니다. Redis 또는 오픈 소스에서도 Redis. 서버 측에서는 Azure를 사용하여 코드를 작성할 수 없습니다. Redis. 주로 기본 VM에 액세스할 수 없기 때문이며 이것이 제가 앞서 언급한 주요 이유입니다. NCache 현재 VM 모델에서는 배포 위치, 제어 방법, 관리 방법에 대한 모든 권한을 갖습니다. 즉, 모든 권한을 갖습니다. 블랙박스가 아닙니다. Redis 이다.
다중 데이터 센터를 위한 WAN 복제
몇 가지 세부 사항을 더 설명한 후 결론을 내리겠습니다. WAN 복제는 또 다른 측면입니다.
Active-Passive는 다음에서 지원됩니다. Redis전체 데이터 센터를 전송할 수 있으며, 한 데이터 센터에서 다른 데이터 센터로 캐시를 전송할 수 있습니다. NCache액티브-패시브 방식이 있습니다. 즉, 한 데이터 센터에서 다른 데이터 센터로 단방향으로 데이터를 전송하는 방식입니다. 또한 액티브-액티브 방식도 있는데, 이는 매우 시급하고 중요한 사용 사례로, 두 사이트 모두 활성화되어 있어야 하는 경우에 유용합니다. 예를 들어, 사이트 1의 업데이트가 사이트 2에 적용되고, 반대로 사이트 2의 업데이트가 사이트 1에 적용되어야 하는 경우입니다. 따라서 이 기능은 지원되지 않습니다. Redis 측면. 해당 기능이 없으므로 활성-활성 사이트를 실행할 수 없습니다. Redis. 과 NCache 이는 두 사이트의 데이터가 모두 업데이트되는 앱 데이터 캐싱 사용 사례에 해당하며, 다중 사이트 세션을 통해서도 가능합니다. 따라서 이는 또 다른 공간입니다. NCache 확실한 승자입니다.
캐시 토폴로지
그다음 몇 가지 세부 사항입니다. 캐싱 토폴로지입니다. 우리는 캐싱 토폴로지 목록이 매우 방대합니다. Redis.
따라서 다양한 사용 사례에 따라 미러링, 복제, 분할 및 분할 복제가 있으며 이미 논의되었으며 이에 대해 논의했습니다. NCache 클러스터링은 일반적으로 더 좋으며 우리는 더 많은 옵션을 가지고 있습니다. Redis 제공합니다.
GUI 도구 - 캐시 관리 및 모니터링
GUI 도구도 있습니다. 비교해 보겠습니다. 관리자, 모니터.
PowerShell 도구, 덤프 및 리로드 도구, 완벽한 관리 및 모니터링 기능이 내장되어 있습니다. Redis 그 측면에서도 제한이 있으며 그 일부로 몇 가지 세부 사항을 보여드렸으며 이는 Windows와 Linux 배포에도 해당됩니다. NCache.
ASP.NET 특정 기능
ASP.NET 특정 캐싱 기능.
세션 관련 기능으로는 멀티사이트 세션이 있으며, ASP.NET과 ASP.NET Core 간의 세션 공유 기능이 곧 제공될 예정입니다. 멀티사이트 ASP.NET 및 ASP.NET Core 세션을 사용할 수 있습니다. 뷰 상태 및 출력 캐싱 기능도 제공됩니다. Redis 세션만 있는데, 이는 다음과 비교하면 매우 기본적입니다. NCache. 세션 잠금, 세션 공유는 다음의 일부입니다. NCache출력 캐싱은 양쪽 끝에서 모두 지원되며, 추가적으로 SignalR 백플레인과 ASP.NET Core 응답 캐싱도 제공합니다. 따라서 웹 관련 캐싱 요구 사항을 충족하는 완벽한 기능 세트를 갖추고 있습니다. 자세한 기능 목록은 별도로 검토해 보시기 바랍니다.
이벤트를 통한 런타임 데이터 공유
그리고 Pub/Sub 메시징이 있습니다.
우리는 항목 수준 이벤트를 보유하고 있으며 기준 기반 이벤트 알림 시스템도 보유하고 있습니다. 이는 기존 시스템과 비교했을 때 훨씬 더 우수합니다. RedisPub/Sub 메시징에 대한 별도의 웨비나가 있습니다. 질문이 있으시면 꼭 다시 확인해 보시기 바랍니다. 그럼 이쯤에서 마무리하겠습니다.
타사 통합
마지막으로, 타사 통합입니다.
NHibernate와 Entity Framework도 있습니다. AppFabric 래퍼를 사용할 수 있습니다. Memcached 래퍼를 사용할 수 있습니다. 따라서 해당 제품에서 전환하는 경우 원활하게 전환할 수 있습니다. NCache 비교해서 Redis.
보안 및 암호화
몇 가지 세부 사항 보안 암호화 그리고 우리는 이미 정해진 시간에 맞춰 가고 있다고 생각해요.
맺음말
자, 이제 마무리하기에 좋은 시점입니다. 자, 가장 중요한 것은 여러분이 원하실 때 언제든지 www.alachisoft.com에 접속하셔서 기업용 버전을 다운로드하실 수 있다는 것입니다. NCache 귀사의 환경에서 어떻게 작동하는지 직접 보여드리겠습니다. 웹사이트에 바로 접속하셔서 Enterprise 30일 무료 체험판을 이용해 보시기 바랍니다. 데모 예약도 환영합니다. 또한, 웨비나 녹화본도 제공해 드릴 예정입니다. 웨비나 녹화본이 발송되면 이메일과 소셜 미디어를 통해 확인해 주세요. 오늘 질문에 답변드리지 못하셨거나, 더 많은 질문이 있으시고, 곧 답변드릴 예정이시라면 이메일로 문의해 주세요. support@alachisoft.com.
기술적인 질문이 있으면 답변을 드릴 수 있으며, 계속 진행하고 지원하는 데 관심이 있는 경우 NCache 당신의 환경에서만 연락할 수 있습니다 sales@alachisoft.com 뿐만 아니라.