NCache 아키텍처
오늘은 에 대해 이야기해보겠습니다. NCache 건축물. NCache .NET 및 Java 애플리케이션을 위한 메모리 내 분산 저장소입니다. 매우 빠르고 확장성이 뛰어납니다. 또한 트랜잭션이 많은 서버 애플리케이션에서 이를 사용하여 애플리케이션 성능과 확장성을 높일 수 있습니다.
일반적인 용도 NCache
분산 캐시
두 가지 일반적인 방법 NCache 사용. 첫 번째는 분산 캐시 비용이 많이 드는 데이터베이스 이동을 줄이기 위해 애플리케이션 데이터를 캐시하는 경우, 두 번째는 메시징 및 스트림 플랫폼. 건축에 들어가기 전에 이 두 가지에 대해 간단히 살펴보겠습니다.
-
앱 데이터 캐싱
따라서 분산 캐시에서 애플리케이션 데이터 캐싱은 NCache API는 일반적으로 애플리케이션 데이터를 캐시하기 때문에 캐시가 데이터베이스보다 훨씬 빠르기 때문에 데이터베이스에 자주 이동할 필요가 없습니다. 또한 메모리에 있기 때문에 확장성이 뛰어나고 빠릅니다. 애플리케이션과 가까워서 속도가 빠르고 분산되어 있어 확장성이 뛰어납니다. 그리고 .NET 애플리케이션이 있고 EF Core를 사용하는 경우 다음을 사용할 수 있습니다. NCache EF Core를 통해서도, NHibernate와 EF 6도 통해서 말이죠. Java 애플리케이션이 있는 경우 다음을 사용할 수 있습니다. NCache 최대 절전 모드 두 번째 수준 캐시로 사용됩니다. 또한 Spring 캐시로 사용하거나 JCache에 대해 프로그래밍할 수도 있습니다. -
웹 앱 캐싱
분산 캐시 사용의 두 번째 부분은 웹 애플리케이션이 있는 경우 세션 NCache 그런 다음 NCache 이러한 세션을 여러 서버에 복제하므로 하나라도 있는 경우 NCache 서버가 다운되면 데이터가 손실되지 않지만 이러한 세션은 분산 저장소이고 매우 빠르기 때문에 다시 확장 가능합니다. .NET, Java, Nodejs 등의 모든 언어에서 사용할 수 있는 다중 사이트 세션 기능도 있습니다. 예를 들어 .NET 6, ASP용 세션 외에도.NET Core 응용 프로그램은 자신의 응답 캐시 입력 NCache 그리고 그들은 또한 NCache 로 SignalR용 백플레인. SignalR은 웹 앱이 클라이언트에 이벤트를 보내야 하는 라이브 웹 애플리케이션용입니다. 그리고 .NET 4.8을 사용하는 경우 세션 상태를 저장할 수도 있습니다. 상태 보기, 출력 캐시, 그리고 SignalR도 있습니다.
NCache 미션 크리티컬 앱용
무엇인지 빠르게 보여드리겠습니다 NCache 처럼 보입니다. 미션 크리티컬 애플리케이션을 위한 분산 캐시의 역할은 다음과 같습니다. 미션 크리티컬이라는 단어를 사용하는 이유는 대부분의 경우 고객이 사용하기 때문입니다. NCache 고객을 대면하는 매우 민감한 애플리케이션에서는 비즈니스에 매우 중요합니다. 그래서, NCache 이 경우에는 매우 중요한 인프라의 일부입니다.
그리고 앞서 말했듯이 이것들은 트랜잭션이 많은 서버 애플리케이션입니다. 이것은 웹 애플리케이션입니다. 이는 마이크로서비스, 웹 API 또는 기타 서버 애플리케이션입니다. 물론 .NET, Java, Node.js 또는 Python을 사용할 수 있습니다. 그리고 이러한 애플리케이션은 SQL Server, Oracle, Db2, MySQL 또는 기타 관계형 데이터베이스로 데이터베이스에 액세스하려고 하거나 레거시 메인프레임 데이터에 액세스하거나 NoSQL database Mongo DB, Cosmos DB, Cassandra 등이 있습니다. 이러한 상황에서, NCache 다음을 통해 분산 캐시가 됩니다. NCache 두 개 이상의 서버를 별도의 캐싱 계층으로 사용합니다. 별도의 캐싱 계층을 가질 필요는 없지만 애플리케이션은 다음과 같은 상자에서 실행될 수 있습니다. NCache 완벽하게 작동하지만 더 널리 사용되는 배포 아키텍처는 별도의 캐싱 계층을 갖는 것입니다. 이는 사용하기 더 깔끔한 방법입니다. NCache.
따라서 2서버 캐시 클러스터로 시작한다고 가정해 보겠습니다. NCache 무리, NCache 이러한 모든 서버의 메모리, CPU, 네트워크 카드 리소스를 하나의 논리적 용량으로 풀링하고 애플리케이션을 통해 더 많은 트랜잭션 로드를 서버에 집중한다고 가정해 보겠습니다. NCache 이 두 서버의 용량은 최대로 충분하므로 쉽게 세 번째 서버, 네 번째 서버, 다섯 번째 서버 등을 추가할 수 있습니다. NCache 결코 병목 현상이 되지 않습니다. 이것은 데이터베이스로는 할 수 없는 일입니다. 데이터베이스는 확장되지 않습니다. NoSQL 확장성은 있지만 대부분의 경우 사람들은 다양한 비즈니스 이유로 관계형 데이터베이스를 사용해야 하며 레거시 메인프레임도 가지고 있다는 사실을 발견했습니다. 그래서 데이터 저장 계층은 확장되지 않기 때문에 NCache 최대한 많은 데이터를 캐시할 수 있어 애플리케이션 확장에 도움이 됩니다. 일반적인 목표는 데이터를 찾는 데 필요한 시간의 약 80%를 확보하는 것입니다. NCache 데이터베이스로 이동하는 대신. 그 비율을 달성할 수 있다면 데이터베이스의 부담이 줄어들고 애플리케이션이 확장될 것입니다.
메시징 및 스트림
두 번째 일반적인 사용 사례 또는 사용 NCache 이를 통해 서로 통신할 수 있는 여러 애플리케이션을 가질 수 있는 메시징 및 스트림 플랫폼으로 사용하는 것입니다. 게시/구독 메시징를 통해 연속 쿼리및 NCache 기반 이벤트. 그것이 어떤 모습인지 보여드리겠습니다. 예를 들어 실시간 메시징이나 스트림 처리를 많이 수행해야 하는 트랜잭션이 많은 서버 애플리케이션이 있는 경우 다음을 사용할 수 있습니다. NCache. 이제 같은 NCache 분산 캐시였던 것이 이제 메시징 및 스트림 플랫폼이 되었습니다. 다시 말하지만 이는 메모리 내 분산 저장소입니다. 선형적으로 확장됩니다. 여러 서버에 걸쳐 메시지를 복제합니다. 사실은, NCache 또한 지속성이 있습니다.
따라서 이를 통해 다양한 애플리케이션을 가질 수 있습니다. 예를 들어 Pub/Sub 메시징은 매우 널리 사용되는 방식이자 방법론이며 분리된 방식으로 서로 통신할 수 있는 여러 게시자와 여러 구독자가 있는 패러다임입니다. 분리됨은 게시자가 구독자가 누구인지 알지 못하고 특정 주제에 대한 메시지를 게시하고 이러한 구독자가 해당 메시지를 얻을 수 있음을 의미합니다. 연속 쿼리도 같은 방식입니다. 이것이 두 가지 일반적인 방법입니다. NCache 사용.
.NET 대 Java 애플리케이션
이제 방법에 대해 이야기합시다. NCache .NET과 Java 애플리케이션을 모두 처리합니다. NCache 매우 흥미로운 네이티브 멀티플랫폼 기능이 있습니다. 이에 대해 설명하겠습니다.
.NET 에디션
NCache .NET과 Java 모두에 대한 기본 솔루션을 제공하려고 합니다. 즉, .NET 애플리케이션이 있으면 전체 애플리케이션 스택이 .NET을 경험하므로 .NET 외에는 아무것도 사용하지 않는다는 의미입니다. 예를 들어, NCache 애플리케이션이 애플리케이션에서 사용할 네이티브 .NET 클라이언트가 있습니다. 이는 애플리케이션 서버에서 실행되며 NCache 100% 'C Sharp'(C#)으로 개발했습니다.
마찬가지로, .NET에서 작성한 Read-through, Write-through, Right-behind, Loader/Refresher와 같은 서버 측 코드가 있는 경우 NCache 자체 .NET CLR 프로세스에서 해당 코드를 실행합니다. 방법을 보여드리겠습니다. 그리고 저는 이 도표를 앞뒤로 다시 볼 것입니다. 예를 들어, 여기 NCache 아키텍처에는 Windows 또는 Linux에서 실행될 수 있는 .NET 애플리케이션이 있습니다. 네이티브가 있습니다 NCache .NET 클라이언트. 그리고 이것은 NCache .NET Edition인 클러스터 NCache 무리. 즉, 서버측 코드도 .NET이라는 의미입니다.
이제 방법은 NCache 이 아키텍처는 다중 플랫폼 기본 지원을 매우 강력하게 만드는 이유는 캐시 프로세스, 관리 프로세스가 있고 서버 측 코드 프로세스와 별개라는 것입니다. 그리고 매우 고성능 RPC가 있습니다. 이는 메모리 내 RPC입니다. NCache 용도, 그 NCache 매우 빠른 자체 독점 RPC를 개발했습니다. 이것이 바로 캐시가 서버 측 코드와 통신하는 방식입니다. 예를 들어, 읽기 처리기를 호출해야 하는 경우 읽기 처리기는 이 .NET CLR 프로세스 내에서 실행되어 데이터베이스로 이동하여 데이터를 가져온 다음 이를 캐시로 전달합니다. Write-through, Loader 및 Refresher에서도 마찬가지입니다. 따라서 애플리케이션의 전체 경험은 .NET입니다.
자바 에디션
자, Java 측면으로 전환해 보겠습니다. 다시 말하지만, 동일한 방식으로 Java 서버 측 코드가 있습니다. NCache 애플리케이션 서버에서 실행되고 .NET과 동일한 방식으로 실행되는 100% Java 클라이언트가 있습니다. 다음은 자바 에디션입니다. Linux나 Windows, Docker, Kubernetes에서 실행될 가능성이 가장 높은 Java 애플리케이션이 있다고 가정해 보겠습니다. 따라서 해당 애플리케이션에는 NCache 제가 여기서 말한 대로 Java 클라이언트는 100% 기본 Java이며 이 Java 클라이언트는 기본적으로 .NET 클라이언트와 동일합니다. 그것은 또한 NCache 다음을 사용하여 .NET 클라이언트와 동일한 방식으로 클러스터링합니다. NCache자신의 독점 소켓 프로토콜과 NCache 서버는 서버 측 Java 코드가 자체 JVM에서 실행되도록 설계되었습니다.
따라서 수행할 모든 개발, 테스트 및 디버깅은 모두 기본 JVM 프로세스에서 수행됩니다. 그리고 이 캐시 프로세스는 Oracle이나 Db2 또는 심지어 SQL Server 데이터베이스로 들어가서 데이터를 가져와 캐시 프로세스에 제공하는 Read-through 핸들러를 호출합니다. 이번에도 동일한 고성능 인메모리 RPC가 사용됩니다. 따라서 자체 기본 프로세스에 .NET 및 Java 코드를 캡슐화하는 아키텍처를 가짐으로써 NCache Java와 .NET 모두에 대한 기본 스택을 제공할 수 있습니다.
그리고 Java 애플리케이션의 경우에는 Windows나 Mac OS에서 개발을 수행하고 싶을 수도 있습니다. NCache 완전히 지원하거나 Linux까지 지원하면 .NET 사용자보다 Docker 및 Kubernetes를 사용할 가능성이 더 높습니다. NCache Docker 이미지를 제공하고 Kubernetes, Azure AKS, AWS EKS, Google GKE 또는 Red Hat OpenShift에 대한 전체 지원도 제공합니다. 매우 원활한 방식으로 사용할 수 있습니다.
그래서, NCache 매우 독특합니다. 이는 기본 .NET 경험과 동시에 기본 Java 경험을 제공합니다. 따라서 Java 상점이라면 Java가 아닌 제품을 사용하고 있다는 느낌이 들지 않으며, .NET 상점이 아닌 경우에는 .NET이 아닌 제품을 사용하고 있다는 느낌이 들지 않습니다. NET 제품입니다. 그게 바로 아름다움이야 NCache 그것이 설계된 방식.
동적 클러스터
좋아, 이제 들어가 보자 동적 클러스터링 부분의 NCache 고가용성을 위한 아키텍처입니다. 그리고 잠시만요. 알겠습니다. 첫 번째 부분은 동적 클러스터입니다. 클러스터라는 단어를 사용할 때 다른 운영 체제 수준 클러스터인 Kubernetes 클러스터를 의미하는 것은 아닙니다. 이것은 NCache의 자체 TCP 기반 클러스터입니다. 그리고 이 클러스터에는 PXNUMXP 아키텍처가 있습니다. PXNUMXP가 의미하는 바는 주인도 없고 노예도 없다는 것입니다. 마스터/슬레이브의 문제는 마스터가 다운되면 슬레이브가 작동하지 않거나 제한되는 반면, 피어 투 피어 아키텍처에서는 모든 노드가 동등하게 능력을 발휘한다는 것입니다. 분명히 가장 오래된 노드인 클러스터 코디네이터 노드가 있으며, 해당 노드가 다운되면 다음으로 오래된 노드가 자동으로 클러스터 코디네이터로 선택됩니다. 클러스터 코디네이터는 클러스터 멤버십을 수행합니다. 이는 배포 맵, 클러스터 상태 및 그 중 일부를 살펴볼 기타 여러 가지 사항을 관리합니다.
동적 클러스터링은 캐시나 애플리케이션을 중지하지 않고도 런타임 시 클러스터에 서버를 추가하거나 제거할 수 있음을 의미합니다. 중단이 없습니다. 그리고 예를 들어 클러스터에 새 서버를 추가하면 클러스터 멤버십이 런타임 시 명백하게 업데이트되고 해당 런타임 정보가 클라이언트에 전파됩니다. 이에 대해서는 다음 슬라이드에서 좀 더 자세히 설명하겠습니다.
클러스터 연결 장애 조치 기능도 있습니다. 따라서 이는 소켓이기 때문에 클러스터 서버는 일반적으로 서로 매우 가까운 동일한 서브넷에 있지만 항상 그런 것은 아닙니다. 우리는 다른 지역에 서버를 배포한 고객이 있으며 대부분의 경우 다음을 권장하지만 완벽하게 작동합니다. NCache 서버는 서로 상당히 가까워야 합니다. 그러나 여전히 연결 실패가 발생할 수 있습니다. 그렇다면 NCache 재시도 논리가 있고 시간 초과가 있습니다. 하트비트 논리가 있는데, 그 모든 것은 그것이 모두 동적인지 확인하는 것입니다.
동적 클라이언트 및 동적 구성
동적 클라이언트 연결
동적 아키텍처의 또 다른 부분은 동적 클라이언트입니다. 따라서 이와 마찬가지로 클러스터에는 런타임에 서버를 추가하거나 제거할 수 있는 기능이 있었고 런타임에 클라이언트를 추가하거나 제거할 수도 있었습니다. 클라이언트는 무엇을 의미합니까? 클라이언트는 NCache 애플리케이션 서버, 웹 서버에서 실행되는 클라이언트는 애플리케이션이 통신하는 부분입니다. 따라서 런타임에 클라이언트를 추가할 수 있고 중지하지 않고도 런타임에 클라이언트를 제거할 수 있습니다. NCache, 캐시 또는 애플리케이션을 중단 없이 사용할 수 있습니다. 이것이 첫 번째 부분입니다.
동적 구성
두 번째 부분은 동적 구성입니다. 따라서 마지막 슬라이드에서 언급했듯이 클러스터에 서버를 추가하면 클러스터 구성원이 변경됩니다. 글쎄, 그것은 연결된 모든 기존 클라이언트에 전파되므로 이제 연결해야 할 새 서버가 있다는 것을 알게 됩니다. 따라서 캐싱 토폴로지를 기반으로 선택하면 해당 서버에도 연결할 수 있습니다. 또한 토폴로지에 따라 배포 맵이 있을 수 있습니다. 분산 맵은 분할된 캐시 및 분할된 복제본 캐시에 더 적합합니다. 그러나 서버를 추가하면 업데이트되고 런타임에 전파됩니다. 그리고 다른 구성 변경 사항도 많이 있습니다. 수행할 수 있고 런타임에 전파되는 핫 적용 기능이 있습니다. 이것이 두 번째 부분입니다.
클라이언트 연결 장애 조치
세 번째 부분은 클러스터 연결 장애 조치와 동일한 방식의 클라이언트 연결 장애 조치가 있다는 것입니다. 그러나 클라이언트가 항상 클러스터 서버에 매우 가깝지 않을 수 있으므로 실제로는 이것이 훨씬 더 필요합니다. 그리고 그 사이에 일부 라우터나 방화벽이 있을 수도 있습니다. 따라서 클라이언트와 클러스터 간의 연결이 끊어질 가능성이 더 높습니다. 그래서, NCache 상당히 지능적인 재시도 기능과 시간 초과 기능이 있습니다. 연결이 끊어지더라도 클라이언트가 연결을 유지하도록 하는 연결 유지 기능도 있습니다. NCache 무리.
스플릿 브레인 감지 및 복구
역동적인 측면의 또 다른 중요한 주제 NCache 아키텍처는 분할 두뇌(Split Brain)입니다. Split Brain은 클러스터에서 발생할 수 있는 현상입니다.
연결 끊김 시 분할 브레인 발생
그리고 분할 브레인은 1개의 서버로 구성된 건강한 클러스터가 있는 경우 이러한 서버 중 일부 간의 연결이 어떤 이유로 끊어지고 네트워크 연결이 있을 때 언제든지 연결이 끊어질 때 분할 브레인이 발생한다고 가정해 보겠습니다. 그리고 우리는 그것을 항상 봅니다. 그래서 그런 일이 발생하면 하위 클러스터가 형성됩니다. 이 경우 분할 2, 분할 3, 분할 XNUMX이 있다고 가정해 보겠습니다. 각 하위 클러스터는 자신이 생존자라고 생각합니다. 따라서 자체 클러스터 코디네이터를 생성하여 독립 클러스터가 됩니다.
분할 뇌 감지
그러나 이러한 모든 분할은 이전에 건강한 클러스터의 일부였으며 이러한 서버가 자발적으로 떠나지 않았으며 원활한 방식으로 떠나지 않았다는 것을 기억합니다. 당신은 '노드 탈퇴'를 하지 않았습니다. NCache 대신 관리 도구가 연결이 끊어졌습니다. 따라서 그들은 네트워크 연결이 복원되었는지 확인하기 위해 계속해서 이러한 서버를 찾을 것입니다. 그리고 대부분의 경우 XNUMX분, XNUMX분, XNUMX분, XNUMX시간 후에 연결이 복원될 가능성이 높습니다.
스플릿 브레인 복구
그런 일이 발생하면 분할 브레인 복구(Split Brain Recovery)가 수행됩니다. 그리고 이러한 분할이 병합되는 곳입니다. 이러한 하위 클러스터는 가장 큰 것에서 가장 작은 것까지 반복적인 방식으로 병합되며, 이들이 독립 클러스터가 되었기 때문에 분명히 일부 데이터 손실이 있으며 이제 일부 데이터가 손실되어야 합니다. 하지만 이는 모두 사용자가 지정한 규칙에 따라 자동으로 수행됩니다.
분할 브레인에 대한 자세한 내용은 별도의 문서를 참조하세요. 비디오 하지만 이런 종류의 내용은 개요를 제공합니다. 이는 귀하의 NCache 클러스터는 건강하게 유지되며 분할 뇌가 발생할 때마다 복구할 수 있습니다.
캐싱 토폴로지
알았어 이제 들어가보자 캐싱 토폴로지. 캐싱 토폴로지는 기본적으로 데이터 저장, 복제 전략 및 클라이언트 연결 전략입니다. 네 가지 토폴로지가 있는데, 하나는 분할된 캐시, 분할 복제본, 복제된 캐시, 미러링된 캐시입니다. Partitioned Cache를 사용해 보겠습니다.
파티션된 캐시
파티션된 캐시 기본적으로 전체 캐시가 파티션으로 나누어져 있으며 모든 서버에는 하나의 파티션이 있습니다. 그리고 버킷이라는 개념이 있습니다. 따라서 모든 파티션에는 버킷이 있습니다. 전체 캐시에 대해 총 100개의 버킷이 있습니다. 따라서 파티션 수에 따라 해당 버킷이 균등하게 나누어집니다.
그리고 이러한 파티션은 런타임에 생성되는데 이것이 여기서 중요한 부분입니다. 따라서 서버를 추가하면 파티션이 생성됩니다. 하나의 서버로 시작하고 파티션이 하나만 있고 100개의 버킷이 모두 해당 파티션에 있다고 가정해 보겠습니다. 런타임에 두 번째 서버를 추가하면 이전 슬라이드에서 언급한 클러스터 멤버십 정보가 업데이트될 뿐만 아니라 배포 맵도 업데이트됩니다. 분산 맵은 기본적으로 어떤 파티션에 어떤 버킷이 포함되어 있는지를 나타내는 맵입니다. 따라서 두 번째 파티션을 추가하면 이제 분산 맵이 변경된다고 가정해 보겠습니다. 분포 맵은 실제로 버킷에 매핑되는 해시 맵입니다. 해시 맵 값의 범위는 버킷입니다. 그리고 이는 추가한 데이터의 양에 따라 변경되지 않으며, 서버 수, 파티션 수를 변경하거나 데이터 재조정을 수행하는 경우에만 변경됩니다. 따라서 파티션은 동적입니다.
동적 데이터 밸런싱
두 번째 부분은 동적 데이터 밸런싱이 있다는 것입니다. 따라서 이것은 모두 해시 맵 기반이기 때문에 사용한 키 유형에 따라 일부 버킷이 다른 버킷보다 더 많은 데이터를 얻을 가능성이 매우 높습니다. 그리고 일부 파티션은 거의 가득 차고 다른 파티션은 거의 비어 있게 됩니다. 그리고 그런 일이 발생하면 NCache 임계값을 설정할 수 있는 기능이 있습니다. 파티션이 80% 이상 차면 20%, 10%, 5%를 제거한다고 가정해 보겠습니다. 제거하는 것이 아니라 동적으로 균형을 맞추는 것을 의미합니다. 따라서 데이터 밸런싱이란 파티션 1에서 해당 버킷을 가져와 다른 파티션에 복사하거나 다른 파티션으로 이동하는 것을 의미합니다. 따라서 데이터 밸런싱은 데이터와 모든 파티션이 상당히 균일하도록 보장합니다.
클라이언트가 모든 파티션에 연결
분할된 캐시에서는 모든 클라이언트가 모든 파티션 또는 모든 서버에 연결됩니다. 그렇게 하는 이유는 한 번의 호출로 원하는 항목에 직접 액세스하기를 원하기 때문입니다. 예를 들어 하나의 서버에만 연결되어 있고 항목 번호 3을 원했다면 서버 1과 통신하고 서버 1은 서버 2로 이동하여 항목을 가져옵니다. 그리고 이는 클라이언트가 데이터가 있는 곳으로 직접 이동할 수 있는 것처럼 최적화되지 않은 XNUMX홉 작업입니다. 그리고 클라이언트는 분포 맵을 통해 이를 알고 있습니다. 그렇기 때문에 클라이언트가 데이터가 어디에 있는지 알 수 있도록 배포 맵이 생성되어 거기에서 직접 가져올 수 있습니다.
따라서 분할된 캐시에는 복제가 없습니다. 따라서 서버가 다운되면 해당 데이터가 손실됩니다. 조금 있다가 이야기할 'Persistence'를 사용하는 것 외에는 방법이 없습니다. 그러면 Partitioned Cache에서도 데이터가 손실되지 않습니다.
파티션 복제본 캐시
파티션 복제본(동적)
다음 토폴로지는 파티션-복제본 캐시입니다. 그런데 이것은 두 세계의 장점을 모두 제공하기 때문에 가장 인기 있는 토폴로지입니다. 확장성인 파티셔닝을 제공합니다. 그리고 고가용성인 복제 기능도 제공합니다. 따라서 데이터 손실이 없습니다. 예를 들어 Partitioned Cache와 방식이 동일합니다. 모든 것이 동일하지만 이제 모든 파티션에는 다른 서버에 복제본이 있습니다. 따라서 파티션 1은 서버 1에 있고 해당 복제본은 Replica 2이라고 하며, 이 경우 서버 XNUMX에 있다고 가정해 보겠습니다. 따라서 파티션이 동적으로 생성된 것과 마찬가지로 복제본도 런타임에 생성됩니다. 추가되거나 제거됩니다. 그리고 그들은 분명히 항상 다른 서버에 있습니다.
다른 부분은 모든 복제본이 수동적이라는 것입니다. 수동적이란 클라이언트가 직접 대화하지 않는다는 의미입니다. 클라이언트는 이것이 파티션과만 통신하고 파티션이 복제본을 업데이트한다는 것을 의미합니다. 따라서 파티션에서 무언가를 업데이트할 때마다 파티션은 복제본에서 이를 업데이트합니다. 그리고 해당 업데이트는 기본적으로 비동기식입니다. 비동기식이므로 속도가 더 빨라질 수 있습니다. 우선 클라이언트는 해당 복제가 발생할 때까지 기다릴 필요가 없으며, 두 번째로 대량 복제를 수행할 수 있습니다. 따라서 수백 또는 수천 개의 업데이트를 결합하여 한 번에 이동하거나 복제본으로 푸시할 수 있습니다. 왜냐하면 이 네트워크 여행의 비용은 데이터를 결합하는 것보다 훨씬 빠르거나 비용이 많이 들기 때문입니다.
비동기/동기 복제
그러나 비동기 복제는 분명히 항상 일관성이 있는 것은 아닙니다. 결과적으로 일관성이 있어 95%~99%의 경우에 충분하며, 매우 민감한 데이터를 다루는 경우는 1~5% 정도입니다. 따라서 비동기 복제를 원하지 않고 동기 복제를 원합니다. 따라서 동기화 복제라는 기능을 켤 수 있으며, 그렇게 하면 클라이언트가 파티션의 항목을 업데이트할 때마다 해당 작업은 파티션이 먼저 복제본을 업데이트할 때까지 완료되지 않습니다. 따라서 해당 복제가 실패하면 작업이 실패합니다. 따라서 작업이 성공하면 복제도 성공한 것입니다. 그래서 이것은 이것의 매우 중요한 특징입니다.
그리고 마지막으로 분할된 토폴로지, 분할된 캐시 토폴로지와 마찬가지로 복제본에도 동적 데이터 밸런싱이 있습니다. 따라서 파티션이 동적으로 데이터 밸런싱되면 복제본은 항상 파티션의 동일한 복사본이기 때문에 복제본은 이를 일치해야 합니다. 따라서 데이터 밸런싱도 거치게 됩니다.
동적 파티셔닝
이제 동적 분할이 실제로 어떻게 발생하는지 빠르게 살펴보겠습니다. 따라서 두 개의 서버 클러스터가 있고 그 안에 6개의 항목이 있고 세 번째 서버를 추가하려는 경우 이는 또 다른 사용 사례이기 때문에 아직 더 많은 데이터를 추가하지 않습니다. 이것이 바로 데이터의 방식입니다. 다른 노드를 추가하면 다른 파티션으로 이동됩니다.
노드를 추가한다고 가정해 보겠습니다. 이제 세 번째 서버가 생겼습니다. 따라서 파티션 3이 생성되고 파티션 3은 이제 파티션 1과 파티션 2에서 데이터를 가져옵니다. 따라서 파티션 1에서 일부 데이터를 가져오고 파티션 2에서 항목 3를 가져옵니다. 그리고 파티션 1이 됩니다.
이제 파티션 3이 되었기 때문에 복제본은 다른 서버에 있어야 하므로 서버 1에 배치된다고 가정해 보겠습니다. 따라서 서버 1에는 복제본 2가 있었는데 복제본 3으로 변환된 다음 복제본 2가 이동됩니다. 예를 들어 이제 복제본 3에는 3, 3, 4 대신 4, 5가 포함되고 복제본 6에는 2, 5이 포함됩니다. 이 모든 작업은 애플리케이션에서 확인하지 않고도 런타임에 동적으로 수행됩니다. 어떤 방해라도.
서버가 다운되면 동일한 일이 발생합니다. 예를 들어 세 개의 파티션이 있다고 가정해 보겠습니다. NCache 클러스터와 서버 3이 다운되면 사용자가 다운시키거나 다운되자마자 파티션 3을 더 이상 사용할 수 없기 때문에 복제본 3이 색상을 변경한 것을 볼 수 있듯이 활성화됩니다. 보통 말씀드린 대로 레플리카는 활성화되지 않죠? 파티션만 활성화되지만 이제는 파티션이 됩니다. 그러나 동일한 상자에 두 개의 파티션이 있고 복제본이 없기 때문에 일시적일 뿐입니다.
이제 이것은 파티션 1과 병합됩니다. 예를 들어 항목 3은 파티션 1로 이동하고 항목 4는 파티션 2로 이동하며 상황은 여기와 같으며 이 복제본 3은 이제 복제본 2가 됩니다. 런타임 시에도 동일한 일이 발생합니다. 동적 파티셔닝은 매우 유연하고 동적입니다. 이러한 역동성은 고가용성을 추가합니다. NCache.
유지 관리 모드
동적 파티셔닝은 매우 유용하고 강력하지만 다시 파티셔닝을 원하지 않는 경우가 있는데 그 중 하나가 예약된 유지 관리입니다. 운영 체제 패치를 수행 중이고 해당 패치로 인해 서버가 XNUMX분 또는 XNUMX분 동안 중단될 것이라고 가정해 보겠습니다. 아시다시피 전체 캐시 클러스터에는 수십 기가바이트의 데이터가 있을 수 있습니다. 따라서 해당 XNUMX분 동안만 다시 분할하고 해당 노드를 백업할 때 다시 분할하고 싶지는 않을 것입니다. 따라서 일정 관리 기능을 활성화할 수 있습니다. NCache 이 경우 이 노드를 종료할 때 다시 관리 도구를 통해 이를 종료해야 하며, 이 복제본이 활성화되지만 다시 분할되지는 않습니다.
따라서 파티션 1은 복제본 3, 파티션 2는 복제본 1로 두 개의 서버 구성으로 유지되며, 이 복제본 3은 실제로 파티션 3이므로 활성화되어 작동한다는 의미입니다. 분명히 파티션 1이 여기에 백업되어 있기 때문에 고가용성이 아닙니다. 파티션 2에는 백업이 없고 복제본 3에는 백업이 없습니다. 하지만 이는 5, 10분 동안만 필요하기 때문에 일시적일 뿐입니다. 따라서 이 서버가 다시 작동하면 이전 상태로 돌아가고 다시 파티션이 될 때 다시 복제본이 됩니다. 이것이 바로 예약 유지 관리 기능이 NCache 작동합니다.
복제된 캐시
다음 토폴로지는 복제된 캐시. 이 토폴로지에서는 모든 서버가 캐시의 전체 복사본을 갖고 있고 모든 서버가 활성 상태인 두 개 이상의 서버를 가질 수 있습니다. 이는 모든 서버에 클라이언트가 연결되어 있음을 의미합니다. 그러나 여기에서는 모든 클라이언트가 하나의 서버에만 연결됩니다. 왜냐하면 해당 서버에는 전체 캐시가 있기 때문입니다. 따라서 파티션이나 파티션 복제본과 같은 두 개의 서버에 연결할 필요가 없습니다.
이 토폴로지에서는 전체 캐시가 바로 거기에 있기 때문에 모든 읽기가 매우 빠르지만 업데이트는 동기식으로 수행되어야 합니다. 둘 다 활성 서버이므로 동일한 항목이 여기와 여기에서 동시에 업데이트될 수 있으며 데이터 무결성 문제가 발생하고 싶지 않을 것입니다. 따라서 인덱싱 체계, 인덱스, 실제로 발행된 일련 번호와 같은 동기식 방식으로 수행되며 모든 항목이 동일한 순서로 업데이트됩니다. 따라서 업데이트가 항상 올바른 방식으로 수행될 수 있습니다. 그러나 비용은 동기식 업데이트가 항목 1을 업데이트하는 클라이언트가 있는 경우 이 서버가 항목 2에 항목 1을 업데이트하도록 알린다는 것을 의미합니다. 두 서버 모두 항목 1을 성공적으로 업데이트한 경우에만 업데이트가 성공하고 제어가 이루어집니다. 돌아갑니다. 즉, 파티션이나 파티션 복제본 토폴로지만큼 빠르지는 않지만 업데이트가 성공하면 작업이 항상 모든 서버에 수행된다는 의미로 작업이 보장됩니다.
이 토폴로지는 읽기 집약적인 작업에 적합합니다. XNUMX개 서버 클러스터의 경우 쓰기 속도도 상당히 빠르며, 파티션 복제본만큼 빠르지는 않지만 대부분의 상황에서는 상당히 빠릅니다. 그러나 더 많은 서버를 추가하면 업데이트 성능이 저하됩니다. 실제로 더 많은 서버를 동기적으로 업데이트해야 하기 때문에 속도가 느려집니다. 따라서 이 토폴로지는 고유한 용도가 있으므로 이를 유지하는 것입니다. 많은 고객이 특별한 상황에서 이를 사용합니다.
미러링된 캐시
네 번째 토폴로지는 미러링된 캐시. 이것은 다시 매우 구체적인 토폴로지입니다. 2노드 토폴로지 전용입니다. 활성 노드와 수동 노드가 있습니다. 다시 말하지만, 활성 노드에는 전체 캐시가 있고 캐시 복사본이 수동 노드에 있습니다. 모든 클라이언트는 활성 노드에 연결되고 모든 항목에 대해 활성 노드를 업데이트하며 업데이트는 수동 노드에 비동기식으로 미러링되거나 복제됩니다. 그리고 비동기식은 Partition Replica와 마찬가지로 매우 빠르다는 것을 의미합니다.
이 토폴로지에서는 활성 노드가 다운되면 수동 노드가 자동으로 활성 노드가 되고 모든 클라이언트가 자동으로 수동 또는 새 활성 노드로 이동합니다. 그리고 그렇게 하면 가동 중지 시간도 없고 중단도 없으며 이를 자동 장애 조치 지원이라고 합니다. 이것이 바로 제가 의미하는 바입니다. 그리고 활성 노드가 다시 활성화되면 분명히 동일한 일이 반대 방향으로 발생합니다.
따라서 미러 토폴로지는 특수한 경우에도 매우 유용합니다. 이 두 서버 이상으로 확장할 수는 없지만 모든 클라이언트가 여기에 연결되어 다른 상자에 복제할 수 있다는 사실 때문에 자체 용도가 있습니다. 예를 들어 재해 복구 상황의 경우에 이것이 사용될 수 있다는 뜻입니다.
실시간 지속성
또 다른 매우 강력한 기능은 NCache 불렀다. 실시간 지속성. 라이브 지속성은 파티션 및 파티션 복제본 토폴로지에만 사용할 수 있으며 실시간입니다. 즉, 런타임에 캐시를 업데이트하면 지속성 저장소도 즉시 업데이트됩니다. 영구 저장소에 대한 업데이트는 비동기식입니다. 따라서 애플리케이션 성능을 방해하지 않거나 NCache 성능. 이것이 바로 애플리케이션이 매우 빠르게 유지될 수 있는 방법입니다. 지속성은 버킷 수준에서 수행됩니다. 따라서 한 저장소에 보관되는 전체 캐시를 나타내는 100개의 버킷이 있습니다. NoSQL 문서 저장소. 파일 기반 저장소이므로 서버 기반 저장소는 아닙니다. 그것은 아니다 NoSQL database 서버, 그건 NoSQL 문서 저장소 NCache 사용합니다. 모든 서버에 공통된 공통 위치에서 사용할 수 있습니다. NCache 클러스터로 구성되어 모두 동일한 영구 저장소에 의존할 수 있습니다.
이것의 이점 중 일부와 이 기능이 제공되는 이유는 무엇보다도 지속하는 것이 무엇이든 전체 캐시를 지속할 수 있고 전체 캐시가 항상 지속된다는 것입니다. 캐시에서 업데이트하는 내용은 몇 밀리초의 차이만 있으면 영구 저장소에도 보관된다고 말할 수 있습니다. 따라서 이를 가져와 다른 캐시에 다시 로드할 수 있습니다. 또는 모든 서버가 다운된 경우 언제든지 영구 저장소에서 다시 시작할 수 있습니다. 아주 적은 양의 데이터를 제외하고는 어떤 데이터도 손실되지 않습니다. 또는 한 환경에서 다른 환경으로 캐시를 가져오고 싶을 수도 있습니다. 쉽게 그렇게 할 수 있습니다.
또 다른 이점은 실제로 파티션 및 파티션 복제본 토폴로지에 더 많은 고가용성을 추가한다는 것입니다. 음, 파티션 토폴로지에 대해서는 여기서 다루겠습니다. 그러니까 앞서 언급한 Partitioned Cache에는 복제 기능이 없기 때문에 어떤 파티션이나 서버가 다운되면 해당 파티션을 잃게 되는 것 아닌가요? 글쎄, 당신이 끈기를 가지고 있다면 그렇지 않습니다. 왜냐하면 해당 데이터의 복사본도 이러한 버킷에 보관되기 때문입니다. 따라서 이 서버가 메모리의 버킷을 다시 할당하지만 분명히 다른 서버에 데이터가 없는 경우 해당 서버는 이것이 지속성 저장소에 데이터가 있는 빈 버킷이라는 것을 알고 있으므로 지속성에서 해당 데이터를 다시 로드합니다. 가게.
따라서 Partitioned-Cache를 사용하더라도 서버가 다운되더라도 데이터가 손실되지 않는 방법입니다. 또한 Partitioned-Cache와 마찬가지로 Partition Replica와 동일한 이점을 누릴 수 있습니다.
여기서 얻을 수 있는 이점은 더 많은 메모리를 사용할 수 있다는 것입니다. 여기서는 할당할 필요가 없지만 지속성 저장소를 할당해야 하는 복제본에 더 많은 메모리를 할당해야 하기 때문에 캐시에 더 많은 데이터를 저장할 수 있습니다. 이것이 바로 Partitioned Cache의 이점입니다. Partition-Replica에도 이점이 있습니다. 그리고 이것이 이미 고가용성을 제공하고 있지만 한 서버가 특정 시점에 다운되는 경우에만 높은 성능이 발생한다면, 예를 들어 두 서버가 지속성 없이 동시에 다운된다면 흥미로운 점입니다. Partition-Replica에서는 데이터가 손실됩니다. 왜냐하면 모든 파티션에는 복사본이 하나만 있고 두 대의 서버가 다운되면 감당할 수 있는 것보다 더 많은 서버를 잃게 되기 때문입니다. 지속성을 사용하면 아무런 문제가 없습니다. 지속성 저장소에서 해당 데이터를 모두 다시 로드하면 됩니다.
분명히 두 경우 모두 지속성 저장소에서 데이터를 로드할 때마다 XNUMX개의 서버가 있었고 이제는 XNUMX개의 서버가 있다는 점을 명심해야 합니다. 글쎄, 데이터 가치가 너무 커서 두 서버에 맞지 않을 수 있습니다. 이는 처리해야 할 또 다른 문제일 수 있습니다. 나머지 두 서버에 세 서버를 모두 수용할 수 있도록 충분한 메모리가 있는지 확인하는 것입니다. 서버. 이것이 유일한 제한 사항입니다. 그렇지 않으면 지속성은 Partitioned 캐시와 Partition-Replica 캐시 모두에 실제로 가치를 추가합니다.
클라이언트 캐시
좋아요, 또 다른 매우 중요한 기능은 NCache 불렀다. 클라이언트 캐시. 분산 매장 환경에서 InProc 속도를 제공합니다. 예를 들어, 분산된 NCache 클러스터, 애플리케이션이 여기에서 실행되고 있습니다. 이는 일반적으로 데이터베이스 위에 있는 캐시이거나 수행 중인 다른 모든 작업입니다. 클라이언트 캐시는 일반적으로 분산 캐시 시나리오가 있을 때 사용되며 클라이언트 캐시는 데이터베이스 위에 있는 캐시입니다. 이 캐시 클러스터는 애플리케이션과 매우 가까이 위치합니다. 이는 애플리케이션 서버 또는 NCache 클라이언트 상자. 또한 귀하의 선호도에 따라 InProc 또는 OutProc이 될 수도 있습니다. InProc 캐시는 실제로 힙에 역직렬화된 개체 형식으로 데이터를 유지하기 때문에 매우 빠릅니다. 따라서 해당 개체를 힙에 두는 것과 같습니다. 그보다 더 빨라질 수 있습니다.
따라서 InProc 캐시는 매우 빠르지만 동시에 동기화된다는 점이 장점입니다. NCache 무리. 그리고 동기화되는 방식은 클러스터가 알고 있는 클라이언트 캐시에 보관되는 모든 것입니다. 따라서 이 클라이언트 캐시에 보관된 항목이 클러스터의 다른 클라이언트에서 업데이트되면 클러스터는 클라이언트 캐시에 가서 자체적으로 업데이트하도록 알립니다. 그러면 해당 클라이언트 캐시가 비동기적으로 자체 업데이트됩니다. 분명히 몇 밀리초의 지연이 있지만 제가 말했듯이 최종 일관성은 대부분의 경우 모델이며 일반적으로 99%의 경우에 허용됩니다.
그게 받아들일 수 없다면 NCache ... 그리고 낙관적 동기화는 기본적으로 몇 밀리초의 지연이 있고 기술적으로 오래된 데이터가 있는 상황이 있을 수 있습니다. 이는 제가 99%의 경우에 말했듯이 괜찮습니다. 그러나 문제가 있고 데이터가 매우 민감하지만 여전히 클라이언트 캐시를 사용하고 싶다면 비관적 동기화 기능을 사용하여 애플리케이션이 클라이언트 캐시에서 무엇이든 가져오기 전에 클라이언트 캐시를 가져오도록 할 수 있습니다. 캐시는 해당 데이터의 최신 버전이 있는지 확인하기 위해서만 확인합니다. 이는 데이터 자체를 가져오는 것보다 호출 속도가 더 빠릅니다. NCache 그런 다음 여러 버전 정보를 유지합니다. 그런 다음 해당 데이터의 최신 버전이 있으면 클라이언트 캐시가 이를 가져오고, 그렇지 않은 경우 클라이언트 캐시에서 해당 데이터를 다시 제공합니다.
코드 변경 없이 사용할 수 있는 클라이언트 캐시입니다. 환경에 연결하기만 하면 되며 읽기 집약적인 상황에 적합합니다. 훨씬 더 많은 읽기 작업을 수행하는 경우 최소 5:1, 10:1이 이상적이지만 1:1인 경우 웹 세션의 경우 클라이언트 캐시는 실제로 전혀 도움이 되지 않습니다. 사실 전혀 권장되지 않습니다.
WAN 복제
다중 영역/다중 지역
알겠습니다. 또 다른 부분은 NCache 어디입니까? NCache 하지 WAN 복제 애플리케이션의 다중 영역 또는 다중 지역 배포를 처리합니다. 예를 들어 DR을 위해 서로 다른 두 사이트에 애플리케이션을 배포할 수 있습니다. 재해 복구의 경우 하나는 활성이고 다른 하나는 수동입니다. 그리고 이 애플리케이션이 있습니다. NCache 그걸로 실행 중이고 여기에 실행되지 않는 애플리케이션이 있습니다. 그러나 이 사이트가 다운되더라도 즉시 부하를 감당할 수 있는지 확인하고 싶을 것입니다. 그래서 다리를 놓을 수 있습니다. 브리지는 2노드 클러스터 자체로, 브리지와 동일한 상자에 있을 수 있습니다. NCache 메인일 수도 있고, 별도의 전용일 수도 있습니다. 이는 귀하에게 달려 있습니다. 그런 다음 이 캐시에서 업데이트하는 모든 내용은 WAN을 통해 다른 캐시로 비동기식으로 복제됩니다. 그래서 그것은 능동-수동입니다.
활성-활성으로도 동일한 작업을 수행할 수 있습니다. 이 사이트도 활성화되어 있는 상황에서 두 사이트가 서로 업데이트할 수 있는 활성-활성을 사용하여 동일한 작업을 수행할 수 있다고 가정해 보겠습니다. 그러면 갈등이 해결될 수도 있고, 일어날 수도 있는 상황도 있을 수 있습니다. 그리고 충돌이 의미하는 것은 동일한 항목, 동일한 키가 두 사이트에서 동시에 업데이트된다는 것입니다. 그런 일이 발생하면 기본적으로 브리지는 '마지막 업데이트 우선' 논리를 적용합니다. 따라서 업데이트가 더 늦은 타임스탬프를 갖는 쪽이 승리합니다. 그러나 예를 들어 원하는 경우 브리지가 호출할 .NET 또는 Java 코드인 충돌 해결 및 충돌 해결 핸들러를 제공할 수도 있으며, 이는 데이터 또는 개체의 복사본을 모두 해당 해결 핸들러에 전달합니다. 그런 다음 콘텐츠를 분석하여 어느 것이 더 정확한지 결정할 수 있습니다. 그런 다음 이 업데이트가 승리하면 해당 업데이트가 두 사이트 모두에 적용됩니다. 그것이 양쪽 모두에 적용되는 한 충돌은 없습니다.
XNUMXD덴탈의 NCache Active-Active, Active-Passive 또는 이들의 조합으로 XNUMX개 이상의 사이트를 제공할 수 있습니다. 예를 들어 활성이 하나 이상 필요하지만 모두 수동이거나 모두 활성이거나 활성 또는 수동의 조합일 수 있습니다. 그리고 같은 방식으로 둘 이상의 활성이 있는 경우 충돌 해결이 될 수 있습니다.
컨테이너(Docker 및 Kubernetes)
마지막으로 컨테이너는 Docker와 Kubernetes의 인기가 매우 높아졌습니다. 그래서, NCache .NET 및 Windows 측보다 Java 및 Linux 측에서 더 인기가 있기 때문에 분명히 지원하지만 시간이 지나면 상황이 바뀔 것이라고 확신합니다. 그래서 어느 쪽이든, NCache 두 환경 모두에서 완벽하게 처리할 수 있습니다. 예를 들어, 여기 전형적인 예가 있습니다. Kubernetes 배포 NCache.
여기에 NCache 전개. 있다 NCache 자체 검색 서비스가 있습니다. 이는 확장 가능한 포드이며 Kubernetes 클러스터 내에 애플리케이션이 있습니다. NCache 클라이언트이며 이는 Azure, AKS, AWS, EKS, Google GKE 또는 Red Hat OpenShift일 수 있습니다. Red Hat OpenShift는 일반적으로 AWS, Azure 또는 Google과 같은 다른 클라우드이거나 다른 클라우드일 수도 있지만 NCache 모두 지원합니다. 그리고 이 Pod는 Kubernetes에서 더 일반적인 경우인 Linux일 수 있습니다. NCache 완벽하게 잘 작동합니다. 그리고 애플리케이션은 Linux 또는 Windows일 수도 있습니다. 따라서 Linux 또는 Windows, Linux 또는 Windows가 될 수 있습니다.
Docker/Kubernetes(다중 영역)
WAN 복제가 시작되는 것과 같은 방식으로 원하는 경우 클라우드로 인해 여러 가용성 영역을 가질 수 있다고 가정해 보겠습니다. 다중 영역 Kubernetes를 수행하고 싶었습니다.
따라서 우리가 권장하는 방법은 하나의 Kubernetes 클러스터를 만들고 두 개의 Kubernetes 클러스터를 갖는 것입니다. NCache 배포에서는 활성-활성 또는 활성-수동일 수 있습니다. 그러면 다리는 여기에 완전히 놓일 수도 있고 완전히 여기에 있을 수도 있습니다. 또는 한 부분은 이 영역에 있고 다른 부분은 해당 영역에 있는 브리지 분할을 가질 수도 있으며 그런 다음 복제가 비동기식으로 발생합니다.
내 생각엔 오늘 주제가 거의 다 다루어진 것 같아요. 저희 웹사이트에 오셔서 한 번 살펴보실 것을 적극 권장합니다. NCache 운동장 이는 브라우저에서 실시간 실행 복사본을 사용하는 매우 빠르고 쉬운 방법입니다. NCache, 2노드를 얻을 수도 있습니다. NCache 설치 작업 없이 모든 도구를 클러스터링할 수 있습니다. 아니면 준비가 되었다면 여기로 와서 등록 및 다운로드 중 NCache Enterprise .NET Edition의 경우 또는 NCache Enterprise 자바 에디션용. 앞서 말했듯이 Linux용 .tar.gz인 .msi를 얻거나 Docker를 얻을 수도 있습니다. Docker 이미지를 가져올 수 있습니다. NCache. 이것이 내 프레젠테이션의 끝입니다. 매우 감사합니다.