NCache 아키텍처
녹화된 쇼
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)
오늘 웨비나는 다음을 기반으로 합니다. NCache 아키텍처자, 이제 분산 캐싱에 대한 개요와 .NET 및 .NET Core에서 병목 현상을 해결하는 방법에 대해 살펴보겠습니다. 일반적인 사용 사례, 분산 캐시 아키텍처, 클러스터링 세부 정보는 물론, .NET 및 .NET Core뿐만 아니라 분산 캐싱과 관련하여 여러분이 가질 수 있는 모든 질문에 대한 답변도 다룰 예정입니다. NCache하지만 일반적인 캐싱에 대해서는 다루지 않겠습니다. 이 웨비나 진행 중 언제든지 GoToWebinar 질문 탭에서 질문을 입력하실 수 있으니, 편하신 시간에 질문 탭을 확인해 주세요. 질문을 작성하시면 프레젠테이션 중에 Ron이나 제가 답변해 드릴 수 있도록 해당 질문을 다시 올려드리겠습니다. 세션 마지막에 다른 질문들을 검토할 수 있는 짧은 시간이 있지만, 즐거운 시간을 보내시길 바랍니다.
그럼, 더 이상 미루지 말고 론에게 넘겨드리고 시작하겠습니다. 아주 좋아요, 고마워요, 잭. 자, 여러분, 잭이 방금 말씀드렸듯이 오늘의 주제는 NCache 아키텍처. 이 웨비나에서는 자세한 내용을 다루겠습니다. NCache 클러스터링 작동, 선택할 수 있는 가장 일반적인 토폴로지는 무엇이며 주요 이점 중 하나는 무엇입니까? NCache 애플리케이션 사용 사례 측면에서. 해당 사용 사례는 무엇이며, 어떻게 최대한 활용할 수 있습니까? NCache 서버 애플리케이션 내에서요?
그럼, 여러분 모두 제 화면을 볼 수 있기를 바랍니다. 빠른 확인이 되면 바로 시작하겠습니다. 네, 괜찮으시다면 모두 잘 되실 것 같아요. 자, 이제 시작하겠습니다. 네, 잘 보이네요. 완벽하네요. 좋아요, 그럼 바로 시작해 볼까요?
확장성 문제
좋습니다. 그럼 먼저 무엇을 정의해 볼까요? NCache 입니까? 그러기 위해서는 확장성 문제가 무엇인지 정의하고 그 다음에 어떻게 해야 합니까? NCache 확장성 문제를 해결할 수 있습니다. 따라서 애플리케이션이 배포된 일반적인 서버 아키텍처에서는 일반적으로 두 개 이상의 인스턴스 또는 두 개 이상의 서버가 사용됩니다. 애플리케이션이 배포되었는지 여부는 중요하지 않습니다. 따라서 애플리케이션 계층은 매우 확장성이 뛰어나다고 말할 수 있습니다.
애플리케이션 계층에 원하는 수의 서버를 추가할 수 있습니다. 여러 애플리케이션 서버 또는 웹 서버가 동일한 애플리케이션을 호스팅하는 웹 폼이나 앱 폼을 구축할 수 있지만, 이들은 팀으로 작동하며 요청 부하를 서로 분배합니다. 또한, 마이크로서비스 아키텍처와 같은 최신 아키텍처를 사용하면 더 많은 컴퓨팅이나 요청 처리 용량이 필요한 애플리케이션 서비스를 개별적으로 확장할 수 있습니다.
앱 계층은 확장성이 매우 뛰어납니다. 선형적으로 확장 가능합니다. 성장할수록 점점 더 많은 요청 부하를 처리할 수 있습니다. 이 문제는 관계형 데이터베이스와 같은 데이터베이스를 다룰 때 발생합니다. 이러한 모든 애플리케이션은 확장성 수준과 관계없이 항상 백엔드 데이터베이스와 통신해야 합니다. 백엔드 데이터베이스와 통신할 때는 일반적으로 단일 소스가 사용됩니다. 확장성이 좋지 않습니다. 스토리지에는 매우 유용하며 많은 디스크 리소스를 확보할 수 있습니다. 따라서 스토리지 이점을 얻을 수 있습니다. 하지만 애플리케이션에 막대한 트랜잭션 부하가 발생하고 이것이 데이터베이스 트랜잭션 부하로 변환되면 데이터베이스가 과부하되는 경향이 있습니다. 이것이 애플리케이션이 요청 처리에 어려움을 겪는 주요 문제입니다. 확장성이 떨어지고 최종 사용자 경험도 저하됩니다.
NoSQL 데이터베이스는 이러한 문제를 어느 정도 해결해 줍니다. SQL 데이터베이스를 사용할 수도 있지만, 그러려면 애플리케이션 아키텍처를 완전히 재설계하여 관계형 데이터베이스 사용을 중단하고 NoSQL 데이터베이스를 사용하도록 해야 하는데, 이는 상당한 규모의 프로젝트입니다. 따라서 NoSQL이 확장성 문제에 대한 항상 해결책이 되는 것은 아닙니다.
해결 방법 : NCache 분산 캐시
그렇다면 이런 상황이 발생했을 때 어떻게 해야 할까요? 해결책은 매우 간단합니다. 다음과 같은 메모리 내 분산 캐시를 사용하면 됩니다. NCache. 무엇보다도, 인메모리 방식이므로 애플리케이션 성능이 향상된다는 것이 가장 큰 장점입니다. 관계형 데이터베이스에 비해 매우 빠릅니다. 그리고 가장 큰 장점은 선형 확장이 가능하다는 것입니다. 일반적으로 단일 소스인 데이터베이스 서버와는 다릅니다. NCache 여러 서버에 상주할 수 있습니다. 이를 통해 다음을 생성할 수 있습니다. 캐시 클러스터 여러 서버에서 실행할 수 있습니다. 아시다시피, 요구 사항이나 필요 사항이 증가하여 애플리케이션 계층에서 처리해야 할 요청 처리 용량이 더 많아지면 캐시 클러스터에 런타임에 서버를 추가할 수 있습니다.
좋은 점 NCache 관계형 데이터베이스나 백엔드 데이터베이스에 추가로 사용한다는 점입니다. 기존 데이터 소스를 대체하는 것이 아닙니다. 기존 데이터 소스를 보완하여 애플리케이션 성능을 향상시키고, 애플리케이션의 요청 처리 용량을 늘릴 수 있습니다. 또한 애플리케이션 규모가 커짐에 따라 캐시 클러스터의 서버 수를 늘릴 수 있습니다. 캐시 클러스터는 클러스터 내 서버들이 하나의 팀처럼 작동하기 때문입니다. 각 서버는 요청 부하를 분산하여 선형 확장성을 제공합니다. 즉, NCache 선형적으로 확장 가능한 모델이며 사용하기 매우 쉽습니다. 배포 아키텍처의 작동 방식을 살펴보겠습니다. 일반적으로 대규모 프로덕션 환경에서는 다음과 같습니다. NCache 다음과 같이 보일 것입니다.
여러 대의 서버가 있을 겁니다. 이 서버들은 Windows나 Linux 서비스일 수 있으며, 다음과 같은 방식으로 설계되었습니다. NCache 애플리케이션과 데이터베이스 사이에 위치합니다. 예를 들어, 두세 개로 시작할 수 있습니다. NCache 서버를 추가하면 최대 4~5개까지 확장할 수 있습니다. NCache 서버와 다양한 종류의 애플리케이션, 예를 들어 ASP.NET 또는 ASP.NET Core 웹 앱, .NET 또는 .NET Core 서비스, .NET/.NET Core 서버 앱 등이 있습니다. 심지어 Java나 Node.js 애플리케이션도 포함될 수 있습니다. 따라서 이러한 애플리케이션들도 분산 캐싱의 이점을 누릴 수 있습니다.
NCache 이 프로그램 자체는 .NET/.NET Core로 작성되었으며 Windows와 Linux 시스템 모두에서 실행됩니다. 마찬가지로, 여러분의 애플리케이션도 어떤 플랫폼에서든 문제없이 작동할 것입니다. 일반적으로, 저희는 다음과 같은 환경을 권장합니다. NCache 전용 설정 서버에서 호스팅하는 NCache, 그래서 당신은 자원의 전담적 성격을 가지고 있습니다 NCache. 그리고 애플리케이션 서버는 별도의 계층에 있습니다. 따라서 애플리케이션에 전용 리소스를 할당할 수 있습니다. 하지만 소규모 구성의 경우 다른 배포 옵션도 있습니다. NCache 동일한 상자에 앉아 있고 애플리케이션도 실행 중입니다. 따라서 이는 항상 가능합니다. NCache. 하지만 앞서 논의한 대로 다이어그램에 표시된 것처럼 별도의 캐시 계층을 사용하는 것이 좋습니다. 그리고 NCache 애플리케이션과 데이터베이스 사이에 위치합니다. 여기서 핵심은 애플리케이션 내에서 가장 자주 사용하는 데이터를 캐시한다는 것입니다. 참조 데이터일 수도 있고 트랜잭션 데이터일 수도 있습니다. "참조"는 읽기 집약적인 데이터를 의미하고, "트랜잭션"은 읽기와 쓰기 집약적인 데이터를 의미합니다. 캐시할 데이터를 파악하면 해당 데이터를 "작업 세트"라고 부를 수 있습니다. 처음으로 데이터베이스에서 해당 데이터를 검색하여 데이터베이스 내부에 추가할 수 있습니다. NCache 그리고, 이후의 통화는 다음을 통해 처리될 수 있습니다. NCache 단, 데이터베이스로의 값비싼 이동을 줄일 수 있습니다. 이는 일반적으로 "캐시-어사이드" 패턴이라고 불리는데, 변경 사항이 캐시에 전파된 후 데이터베이스에도 전파됩니다. 캐시에 없는 데이터베이스는 항상 데이터베이스에서 가져와서 데이터베이스에 보관합니다. NCache 하지만 항상 캐시를 먼저 확인합니다. 따라서 캐시에서 데이터를 찾으면 데이터베이스로 갈 필요 없이 바로 그 지점에서 돌아오면 됩니다.
읽기/쓰기
이에 대한 대안적인 접근 방식은 "읽기-통과" 또는 "쓰기-통과"를 사용하는 것인데, 여기서는 점선으로 표시했습니다. NCache 이를 자동화하는 기능이 있는데, "캐시-스루(cache-through)" 옵션을 제공하는데, 읽기에는 "읽기-스루(read-through)", 쓰기에는 "쓰기-스루(write-through)"라고 합니다. 이 기능은 항상 캐시를 주 소스로 사용하고, 캐시에 읽기-스루 및 쓰기-스루 핸들러를 구현하여 백엔드 데이터 소스 업데이트를 담당하는 방식으로 작동합니다. 따라서 어떤 읽기 작업을 수행하든 데이터가 없으면 제공자에 따라 데이터베이스로 원활하게 전송되어 애플리케이션에서 데이터를 검색하고, 앱으로 반환하여 내부에 저장합니다. NCache업데이트의 경우, 애플리케이션에서 호출한 모델에 따라 캐시와 데이터베이스가 동기 또는 비동기 방식으로 업데이트됩니다.
따라서 읽기, 쓰기 및 캐싱 패턴에 대한 자세한 내용을 공유하겠지만, 고수준 배포 그림을 제공하기 위해 다음과 같이 볼 수 있습니다. NCache 여러 애플리케이션이나 애플리케이션 양식이 서버 형태로 배포되어 연결할 수 있습니다. NCache 그러면 분산 캐싱을 활용할 수 있는데, 이를 통해 메모리 접근이 애플리케이션 성능을 향상시킵니다. 또한, 캐시 계층에 여러 서버를 배치하면 선형 확장성을 확보할 수 있습니다. 이 내용이 명확하게 전달되었기를 바랍니다. 궁금한 점이 있으면 언제든지 알려주세요. 다행히 현재는 없는 것 같으니, 계속 진행해 주세요. 아주 좋습니다.
NCache 확장성 수치
그럼 다음으로는 이것에 대해 이야기하겠습니다. NCache의 확장성 수치입니다. 방금 언급했듯이 NCache 애플리케이션의 확장성 문제를 해결할 수 있습니다. 따라서 NCache 자체적으로 선형 확장 가능합니다. 애플리케이션 계층이 확장 가능하다는 점, 즉 선형 확장 모델을 통해 데이터베이스 병목 현상을 해결한다는 점을 고려했을 때, 참고할 만한 몇 가지 수치를 알려드리겠습니다. 이는 QA 환경에서 수행한 벤치마크 테스트입니다. CPU와 RAM 사용량이 많은 서버를 사용하여 부하가 높은 환경에서도 충분히 활용할 수 있도록 확장했습니다. 처음에는 서버 한 대로 시작해서 두 대의 서버로 애플리케이션 부하를 계속 늘렸습니다. 한 대의 서버가 CPU와 RAM 용량이 최대치에 도달하자마자, 바로 그 시점에 서버를 하나 더 추가했습니다.
이것이 경험칙입니다. 기존 캐시 서버를 계속 사용할 수 있는 경우 두 개로 시작하세요. NCache 서버, 그리고 두 서버의 하드웨어 용량이 최대치에 도달하는 것을 볼 때, CPU가 최대치에 도달하거나 RAM이 최대치에 도달하면, 이제 확장해야 하고 캐시 클러스터에 세 번째 서버를 추가해야 한다는 선택을 하는 지점입니다. 이것은 우리가 평균 1킬로바이트 객체 크기로 수행한 것과 정확히 같습니다. 우리는 애플리케이션 부하를 계속 늘리고 서버 수를 계속 늘렸습니다. 주어진 서버 세트가 최대치에 도달할 때까지 말입니다. 그리고 이것은 터치 앤 고 데이터가 아니었습니다. 실제 애플리케이션 데이터였지만 QA 랩에서 시뮬레이션한 것이었습니다. 따라서 두 대의 서버, 2, 1, XNUMX, 최대 XNUMX대의 서버로 평균 XNUMX킬로바이트 객체 크기로 초당 XNUMX만 개의 요청을 처리할 수 있었습니다.
즉, 캐시에 일관되게 적용된 읽기 및 쓰기의 조합이었습니다. 결과적으로 초당 2만 건의 요청 처리량을 달성했습니다. 동시에 성능 저하 없이 달성했습니다. 처리량은 단순히 초당 많은 요청을 처리하는 것만을 의미하는 것이 아니라, 개별 요청의 지연 시간도 유지되어야 하며 매우 빨라야 합니다. 이에 대한 비디오 데모와 백서는 웹사이트(여기를 보아라). 그리고, 그것도 검토할 수 있는 부분입니다.
분산 캐시의 일반적인 사용
좋습니다. 몇 가지 일반적인 사용 사례에 대해 이야기해 보겠습니다. NCache.
-
앱 데이터 캐싱
가장 중요한 사용 사례는 애플리케이션 데이터 캐싱입니다. 앱 데이터 캐싱. 이제 이 데이터는 백엔드 데이터베이스에서 전송됩니다. 데이터베이스는 디스크 기반이기 때문에 일반적으로 속도가 느리다는 점은 이미 확인했습니다. 반면 RAM은 더 빠른 데이터 소스입니다. 또 다른 문제는 트래픽이 많을 때 데이터베이스가 과부하되는 경향이 있다는 것입니다. 트랜잭션 부하가 많고 서버가 하나뿐인 경우, 애플리케이션 측에서 필요한 성능을 제공하지 못할 것으로 예상됩니다. 따라서 애플리케이션 데이터를 애플리케이션 내부에 캐시하는 것이 매우 합리적입니다. NCache. 매우 간단합니다. 사용하면 됩니다. NCache API를 사용하면 캐시를 호출하기만 하면 됩니다. 캐시 초기화 API를 호출하여 캐시에 연결합니다. 캐시에 연결되면 '캐시.추가, 캐시.업데이트, 캐시.제거'또는'캐시.가져오기캐시에서 데이터를 검색하는 방법입니다. 마지막 부분에서 몇 가지 예를 보여드리겠습니다. 하지만 여기서 중요한 점은 참조 데이터든 트랜잭션 데이터든, 두 번 이상 읽을 것 같은 데이터는 무엇이든 상관없다는 것입니다. 참조 데이터의 경우, NCache 변경 사항을 검색하기 위해 데이터베이스로 돌아갈 필요가 없으므로 많은 가치가 추가됩니다.
분산 캐시의 일반적인 사용 그렇다면 캐시에 있는 데이터는 더 오랜 시간 동안 사용할 수 있습니다. 그리고 데이터를 사용하는 동안 NCache백엔드 데이터베이스까지 갈 필요가 없습니다. 이렇게 하면 애플리케이션 성능이 향상되고 확장성도 확보됩니다. NCache 비교적 확장 가능합니다.
따라서 모든 참조 데이터를 캐시하는 것은 매우 직관적이지만, 트랜잭션 데이터의 일부 또는 대부분도 캐시하는 것이 좋습니다. 저희 경험상 두 번 이상 읽는 데이터는 두세 번 읽더라도 캐시하는 것이 좋습니다. 데이터베이스에서 변경되고 그 변경 후 두세 번 이상 읽는 경우에도 백엔드 데이터베이스로 이동할 필요가 없도록 해당 데이터를 캐시하는 것이 매우 합리적입니다. 또한, 저희는 다음과 같은 기능을 내장하고 있습니다. NCache 데이터베이스와 100% 동기화를 제공할 수도 있습니다. 이 부분도 항상 고려해 볼 만한 부분입니다.
론, 저는 간단한 질문을 받았습니다. 주로 다음과 같은 내용이었습니다.
항상 네트워크를 통해 클러스터 캐시에 접속해야 하나요? 네트워크 문제로 인해 애플리케이션이 작동하지 않을까 봐 걱정됩니다. 일부 데이터를 로컬에 보관할 방법이 있을까요?알겠습니다. 일반적으로 기본 배포는 다음과 같이 권장됩니다. NCache 별도의 상자에, 그리고 신청서를 별도의 상자에 넣는 거죠? 그래서, NCache TCP 프로토콜 기반이므로 네트워크 호출입니다. "클라이언트 캐시"라는 기능이 있는데, 이는 애플리케이션 서버에 있는 로컬 캐시입니다. 경우에 따라 더 많은 작업이 필요하고 네트워크로 인한 지연 시간을 원치 않는 경우, "in-proc"으로 설정하여 애플리케이션 프로세스 내부에 위치시킬 수 있습니다. 이 경우, 데이터 하위 집합이 자동으로 클라이언트 캐시로 전송됩니다. 따라서 프로세스 간 통신이 절약되고 네트워크 통신이나 네트워크 오버헤드도 줄어듭니다. 이 기능은 토폴로지 설명에서 다루겠습니다. 좀 더 자세히 설명하겠지만, 간단히 설명하자면 클라이언트 캐시의 작동 방식은 다음과 같습니다. 애플리케이션이 있는 서버에 있는 캐시입니다. 클라이언트 캐시를 활성화하면 네트워크 연결이 자주 필요하지 않습니다. 코드 변경 없이도 작동합니다. 그럼, 질문에 대한 답이 되었기를 바랍니다. 다른 질문이 있으면 알려주세요. 네, 좋은 말씀이네요. 론, 그만하세요. 아주 좋아요.
-
ASP.NET 및 ASP.NET Core 캐싱
다음 사용 사례 NCache 웹 애플리케이션에서 사용자 데이터를 캐싱해야 하는 경우가 종종 있죠? 보통 ASP.NET이나 ASP.NET Core 세션 상태를 사용하는데, 이 데이터는 일시적인 데이터이기 때문에 데이터베이스에 저장해서는 안 됩니다. 사용자가 입력하고 애플리케이션 내에서 활성화되어 있는 동안만 유지되는 데이터입니다. 경우에 따라 기록 보존을 위해 데이터베이스에 저장할 수도 있지만, 대부분의 경우 이 데이터는 사용자에게 속한 데이터입니다.
Microsoft ASP.NET 또는 ASP.NET Core 세션을 사용하는 방법에는 몇 가지가 있습니다. 상태 서버, 인프로세스, 데이터베이스 서버 등이 있는데, 각각의 방법에는 문제가 있습니다. 예를 들어, 인프로세스 방식은 단일 장애 지점이 될 수 있으며, 스티키 세션 로드 밸런싱을 사용해야 합니다. ASP.NET 상태 서버 역시 단일 장애 지점이 될 수 있고 확장성이 떨어집니다. 데이터베이스는 백업이 가능하기 때문에 단일 장애 지점은 아니지만, 경우에 따라 단일 장애 지점이 될 수도 있습니다. 또한 속도가 느리고 확장성이 부족합니다. 그렇다면 어떻게 해야 할까요? 다시 한번, 다른 방법을 고려해 보세요. NCache ASP.NET 및 ASP.NET Core 세션 상태 캐싱을 위한 솔루션입니다. 저희 제공업체를 플러그인 방식으로 연결하기만 하면 됩니다. 코드 변경이 필요 없는 옵션이며, 플러그인하는 즉시 효과가 나타납니다. NCache 귀하의 애플리케이션 내부에서 NCache 기본 세션 저장소가 됩니다. RAM 기반이라 속도가 매우 빠르다는 것이 핵심입니다. 여러 대의 서버가 있어서 확장성이 매우 뛰어납니다. 그리고 NCache, 프레젠테이션을 진행하고 토폴로지를 다루면 이해하실 수 있을 것입니다. NCache 복제를 통해 백업을 수행합니다. 세션 데이터는 사용자 데이터잖아요? 어떤 상황에서도 잃어버리고 싶지 않은 데이터입니다. 데이터가 손실되면 사용자와 비즈니스에 영향을 미치기 때문입니다. 따라서 복제를 통해 데이터도 백업됩니다.
분산 캐시의 일반적인 사용 그럼, 여러분이 얻는 이점을 나열해 보죠. 우선, 메모리 내 접근 덕분에 애플리케이션 성능이 향상됩니다. 세션 캐싱을 위해 애플리케이션을 지원하는 여러 서버가 있으므로 확장성이 매우 뛰어납니다. 게다가 고가용성 및 데이터 안정성 기능이 내장되어 있습니다. 따라서 어떤 경우에도 세션 데이터 손실이나 애플리케이션 다운타임이 발생하지 않습니다. NCache 서버가 다운됩니다. 더 이상 고정 세션 로드 밸런싱을 사용할 필요가 없습니다. NCache 공유 엔티티입니다. 요청은 모든 웹 서버로 전송될 수 있으며 항상 다음에서 데이터를 찾을 수 있습니다. NCache 저희 프로토콜을 기반으로 합니다. 즉, 이 모든 것이 코드 변경 없이 가능합니다.
또 다른 활용 사례로, ASP.NET 웹 폼을 사용하는 경우 뷰 상태를 번들로 묶을 수 있습니다. 뷰 상태를 캐시하는 곳이기도 합니다. 뷰 상태는 무거워지고 많은 대역폭을 소모합니다. 요청 및 응답 패킷의 일부가 되어 항상 브라우저로 다시 전송됩니다. 실제로 브라우저에서 사용되는 경우는 거의 없지만, 클라이언트 측 브라우저에 저장됩니다. 그리고 포스트백을 하면 뷰 상태가 서버 측으로 다시 전송됩니다. 따라서 NCache, 서버 측에서 뷰 상태를 캐시할 수 있으므로 페이로드에 더 이상 무거운 뷰 상태가 첨부되지 않습니다. 이렇게 하면 성능이 향상됩니다. 뷰 상태는 항상 브라우저 측에 저장되지만 필요한 서버 측에 보관하면 전반적인 애플리케이션 동작이 향상됩니다. 실제 요청 및 응답 패킷에 더 이상 무거운 뷰 상태가 첨부되지 않으므로 더 이상 대역폭을 소모하지 않습니다. 또한 뷰 상태가 서버 측에 저장되므로 매우 안전하며, 그 위에 암호화 및 보안 기능을 설정할 수 있습니다. 또한 코드를 변경하지 않고도 사용할 수 있는 옵션입니다. 하지만 레거시 웹 폼에만 적용됩니다. 따라서 ASP.NET 웹 폼 애플리케이션이 있는 경우 뷰 상태 캐싱도 고려해 보는 것이 좋습니다.
그리고 ASP.NET 및 ASP.NET Core의 응답 캐싱 기능이 있습니다. 정적 페이지 또는 페이지 내에서 정적인 부분의 출력을 캐싱하는 것을 고려해야 합니다. ASP.NET Core에서는 응답 캐싱 옵션을 제공하며, 이 옵션은 코드 변경 없이 사용할 수 있습니다. 또한 ASP.NET 및 ASP.NET Core에는 SignalR 백플레인도 있습니다. 웹 폼에서 SignalR을 사용하려면 백플레인이 필수적입니다. 파일 시스템이나 데이터베이스와 같은 일반적인 백플레인은 방금 논의한 확장성 및 성능 문제를 야기할 수 있습니다. NCache매우 빠르고 확장성이 뛰어나며 안정적입니다. 왜냐하면 백그라운드에서 매우 안정적인 메시징 시스템을 사용하기 때문입니다. 따라서 이러한 기능들을 ASP.NET 또는 ASP.NET Core 애플리케이션에서 활용할 수 있습니다.
-
게시/구독 메시징
좋아요. 다음으로 넘어가도 될 것 같아요. 네. 좋아요, 그럼 다음으로 Pub-Sub 메시징에 대해 다루겠습니다. 보시다시피, NCache 애플리케이션 간에 이미 공유되고 있죠. 따라서 데이터 요구 사항에 사용할 수 있는 엔티티입니다. 데이터를 추가하거나 검색할 수 있습니다. 이를 통해 성능과 확장성 이점을 얻을 수 있습니다. NCache. 다음을 사용하여 이 사용 사례를 확장할 수 있습니다. NCache 메시징 플랫폼으로도 사용할 수 있습니다. 그래서, NCache 메시징은 매우 강력합니다 NCache여러 애플리케이션이 서로 메시징 요구 사항이나 앱 조정 요구 사항을 처리할 수 있는 비동기식 이벤트 기반 메커니즘입니다. 여러 애플리케이션이 서로 통신해야 하는 경우, 통신을 구축하는 것이 어렵습니다. 따라서 중앙 집중식 엔터티에 의존해야 합니다. NCache 해당 엔터티입니다. 메시징 지원을 통해 한 애플리케이션에서 데이터나 메시지를 추가할 수 있는 옵션을 제공할 수 있습니다. NCache그리고 그 메시지는 반대편의 모든 구독자에게 전파될 수 있습니다. 즉, 그 메시지가 필요한 다른 애플리케이션에게 전파될 수 있습니다.
분산 캐시의 일반적인 사용 마찬가지로, 이는 데이터 기반 메시지일 수도 있습니다. 예를 들어, 데이터가 추가, 업데이트 또는 삭제되면 알림을 받습니다. 이는 사용자 지정 애플리케이션 메시지이거나 데이터 기반 메시지일 수 있으며, 내부적으로 데이터가 채워지는 모든 영역을 포괄합니다. NCache 다른 애플리케이션에서도 이를 인식하도록 하려면, 이를 통해 메시징 요구 사항을 충족할 수 있습니다. 또는 한 애플리케이션이 다른 애플리케이션과 통신해야 하는 맞춤형 메시징이나 애플리케이션 기반 메시징을 사용할 수도 있습니다. 이 역시 메모리 내 확장 가능 모델을 기반으로 합니다. 안정적인 복제 옵션도 제공합니다. 토픽 개념과 메시지 브로커 개념이 있는 기존의 Pub-Sub 메시징 플랫폼을 기반으로 하며, 여러 애플리케이션이 여기에 연결됩니다. 따라서 게시자 애플리케이션과 구독자 애플리케이션을 정의할 수 있습니다. 게시자 애플리케이션은 메시지를 게시합니다. NCache 그러면 모든 구독자에게 전송됩니다. 그리고 구독자도 자신의 메시지를 보낼 수 있습니다. NCache 서로 다른 애플리케이션 간의 통신 플랫폼 역할을 합니다.
-
전체 텍스트 검색(분산형 Lucene)
마지막으로, 전체 텍스트 검색이라는 또 다른 사용 사례가 있습니다. 따라서 애플리케이션이 있고 전체 텍스트 검색 요구 사항을 충족해야 하는 경우 NCache, Lucine.NET 기반의 전체 텍스트 검색 기능을 사용해 보세요.
아시다시피, Lucene API는 일반적으로 독립형입니다. 그렇죠, 여러분이라면 여러 서버로 확장할 수 있습니다. NCache 메모리 내부에 인덱스를 로드할 수 있는 기능도 제공합니다. 따라서 NCache 디스크 기반 인덱스를 사용하지만, 여러 서버를 통해 스토리지 및 요청 처리 용량을 확장할 수 있습니다. 디스크 기반이기는 하지만 데이터베이스에 단일 소스를 사용하는 것보다는 여전히 더 좋습니다. 트랜잭션 부하가 많은 경우 각 서버가 자체 인덱스 요청 세트를 담당하기 때문입니다. 따라서 확장성이 뛰어나고 안정성도 매우 높습니다. 지원 저장소이기 때문에 씬 인덱스와 관련하여 지속성 자체가 중요한 기능입니다. NCache. 내부에 저장하는 모든 데이터 NCache 디스크에도 저장할 수 있으며, 일부 데이터베이스 공급자에 따라 일부 데이터베이스에도 저장할 수 있습니다. 하지만 Lucene은 NCache RAM에 비해 디스크를 사용하는 이유는 사용 사례의 특성상 데이터가 영구적으로 유지되어야 하기 때문입니다.
분산 캐시의 일반적인 사용
잭, 넘어가기 전에 질문이 올라온 것 같아요. 네. 질문은 기본적으로 DB라고 말씀하신 것에서 시작됐어요. 그래서, 질문 중에… 다 끝내실 때까지 기다리려고 했는데, 질문은 기본적으로 묻고 있는 거예요. 혹시 질문에 대해 자세히 설명해 주실 수 있을까요?
안녕 론, NCache 데이터 게시 목적에도 적합한데, 데이터베이스의 데이터를 백그라운드 프로세스로 동기화하는 옵션을 사용하여 메모리 캐시에 데이터를 저장해야 하는 요구 사항이 있는 경우 어떻게 해야 할까요? NCache 기본적으로 메모리 캐시와 데이터베이스 간의 동기화 메커니즘을 처리하나요?
네, 아주 좋은 질문입니다. 고급 사례의 경우, 이는 항상 필수 요건이 될 수 있습니다. 이는 두 가지 방식으로 작동합니다. 하나는 애플리케이션이 이제 다음에서 들어오는 데이터를 사용하고 있다는 것입니다. NCache하지만 데이터는 데이터베이스에 존재합니다. 따라서 이 두 가지 서로 다른 소스는 읽기와 쓰기 목적으로 동기화되어야 합니다. 이제 연결된 애플리케이션이 NCache 그리고 데이터베이스는 내부 데이터를 변경하는 역할을 하는 유일한 애플리케이션입니다. NCache 데이터베이스의 경우, 이제 read-through와 write-through를 사용하는 것이 좋습니다. 네, 이는 요구 사항에 따라 비동기 또는 동기 방식으로 수행될 수 있습니다. 따라서 실제로 발생하는 일은 NCache 캐시에 존재하지 않고 캐시되도록 하려면 자동으로 read-through를 호출하여 코드를 기반으로 백엔드 데이터베이스에서 데이터를 읽습니다. 마찬가지로, 데이터베이스에서 데이터가 들어오고 해당 데이터를 데이터베이스에서 업데이트해야 하는 경우, 캐시에서 데이터를 업데이트하는 즉시 write-through를 사용합니다. write-through는 write-behind 방식으로도 사용할 수 있는데, 이는 데이터가 캐시 내부에서 업데이트되어야 함을 의미합니다. NCache 데이터베이스에서 write-through 핸들러를 사용하여 비동기 호출을 수행할 수 있습니다. 비동기 호출을 원할 경우 write-behind를 사용하여 백그라운드에서 수행할 수 있습니다. 하지만 다시 말씀드리자면, NCache 그리고 귀하의 애플리케이션이 이에 대한 책임을 져야 합니다. NCache 귀하의 코드를 호출하고 귀하의 애플리케이션이 해당 코드를 호출합니다.
또 다른 상황은 다른 애플리케이션이 데이터베이스의 데이터를 직접 변경하고 있는데 애플리케이션이 이를 인식하지 못하는 경우입니다. 이 경우, 실제로는 데이터베이스 동기화 기능을 사용해야 합니다. 사용자 지정 종속성을 설정해야 합니다. SQL Server에는 체인 알림 기능이 있습니다. 데이터베이스 종속성도 있습니다. 따라서 데이터베이스의 모든 변경 사항을 자동으로 감지하는 동기화 기능이 많이 있습니다. NCache 자동으로. 그리고 다시 읽기 기능을 사용할 수 있으며 내부에서 데이터를 다시 로드할 수 있습니다. NCache 또한. 그래서 요약하자면, NCache 알다시피, 두 가지 상황을 모두 처리할 수 있습니다. 즉, 애플리케이션이 내부에서 무언가를 변경하는 유일한 엔터티인 경우입니다. NCache 그리고 데이터베이스, 또는 캐싱을 사용하는 애플리케이션의 범위 밖에서 데이터베이스를 변경할 수 있는 상황입니다.
따라서 두 시나리오 모두 다루어지고 NCache 이런 경우에는 100 동기화 옵션을 제공합니다. 메모리 캐시에 대해 말씀하시는 거라면, 일반적으로 ASP.NET에서도 메모리 캐시를 지원하죠! 하지만 NCache 메모리 캐시로 쓰려고요. 질문에는 이미 답변드렸습니다. 혹시 더 궁금한 점이 있으시면 알려주세요. 그럼 이어서 답변해 드리겠습니다.
간단했기를 바랍니다. 지금까지 몇 가지 사용 사례를 살펴보았습니다. 다시 말씀드리지만, 이러한 사용 사례에는 다양한 기능이 있습니다. 어떤 종류의 애플리케이션이든, 애플리케이션 내의 특정 요구 사항이든 객체 캐싱 및 세션 캐싱 기능을 사용하여 완벽하게 처리할 수 있습니다.
잠깐 질문 하나 드릴게요, 론.
MySQL 데이터베이스처럼 캐시에 있는 데이터에 접근할 수 있는 방법이 있나요? 캐시 데이터에 SQL 쿼리를 실행하고 싶은데, 가능할까요?
확실한. NCache 우선 SQL 검색과 LINQ 쿼리를 지원합니다. 따라서 간단히 연결할 수 있는 애플리케이션을 작성할 수 있다면 NCache, 그런 다음 기준 기반 검색을 실행합니다. 이는 기준 기반 검색을 작성하는 간편한 옵션입니다. 예를 들어, 제품.가격 10보다 크고 100보다 작습니다. 또는 카테고리별로 모든 제품을 찾을 수 있고, 지역별로 고객을 찾을 수도 있습니다. 따라서 SQL 기반 검색이나 LINQ 기반 검색을 사용할 수 있습니다. NCache 캐시에서 데이터를 가져올 수 있습니다. 그게 한 가지 방법이에요.
또 다른 옵션은 LINQ Pad 통합입니다. 애플리케이션 개발 과정 없이 데이터를 시각화하고 싶다면 LINQ Pad를 사용하면 됩니다. LINQ 쿼리를 실행하고, LINQ 쿼리를 실행하여 데이터를 시각화할 수 있습니다.
그리고 곧 출시될 릴리스에서는 세 번째 옵션으로 데이터 분석 도구를 제공합니다. 자동화된 모니터링 도구를 통해 캐시에 저장된 데이터를 모니터링할 수 있습니다. 또한 GUI에서 기준 기반 검색 옵션을 제공하는데, 이는 현재 개발 단계에 있는 기능입니다. 요구 사항과 개발 작업이 모두 완료되었습니다. 다음 릴리스에 포함될 것으로 예상합니다.
정말 기대되네요. 완벽해요. 네. 아주 좋아요. 이제 괜찮은 것 같아요, 론. 흥미로운 질문들이 많아서 몇 개는 마지막에 남겨두겠지만, 네, 계속해 볼까요? 물론이죠.
자가 치유 동적 클러스터
그럼, 다음에는 동적 캐시 클러스터에 대해 다루겠습니다. 아시다시피, 이에 대한 모든 세부 사항을 말씀드리겠습니다. NCache TCP/IP 기반 캐시 클러스터링 프로토콜을 사용합니다. 자체 구현한 캐시 클러스터링이며, 타사 또는 Windows 클러스터링 기능을 사용하지 않습니다. 100% 독자적인 프로토콜입니다. .NET 및 .NET Core로 작성되었기 때문에 TCP 소켓 또한 .NET 및 .NET Core 기반이므로 매우 편리합니다. 100% P2P 아키텍처를 채택하여 단일 장애 지점이 없습니다. 런타임에 서버를 추가하거나 제거할 수 있으며, 캐시나 연결된 클라이언트 애플리케이션을 중지할 필요가 없습니다. 따라서 실행 중인 캐시 클러스터를 동적으로 변경할 수 있습니다. NCache 그런 문제는 발생하지 않습니다. 서버를 추가하면 클라이언트는 런타임에 알림을 받게 되므로, 해당 서버가 더 이상 존재하지 않는다는 것을 자동으로 인식하고 캐시 클러스터의 일부로 간주하여 추가된 서버를 사용하기 시작하고 클러스터가 자동으로 조정됩니다. 마찬가지로, 서버를 제거하면 다른 서버들이 해당 서버가 완전히 사라졌음을 감지합니다. 클라이언트에게 알리면 클라이언트는 손실된 서버 사용을 중단합니다. 클라이언트 측에도 연결 장애 조치 지원 기능이 내장되어 있어, 서버가 다운되더라도 클러스터가 클라이언트에게 이를 인지시키고 연결을 장애 조치하여 남은 서버를 사용할 수 있도록 합니다.
따라서 어떤 경우든 클러스터의 모든 변경 사항은 클라이언트에 전파됩니다. 클라이언트는 지능적이어서 캐시 클러스터의 상태를 항상 파악합니다. 따라서 복제 지원 기능이 내장되어 있어 다운타임이나 데이터 손실이 발생하지 않습니다. NCache 가용성이 높고 복제 기능을 통해 안정성도 매우 뛰어납니다. 애플리케이션 중단 없이 애플리케이션 측에서 100% 가동 시간을 보장하므로 계속 사용할 수 있습니다. NCache.
캐싱 토폴로지
다음으로 캐싱 토폴로지에 대해 설명하겠습니다. 제가 다루고 싶었던 주요 부분입니다. 네 가지 옵션 중에서 선택할 수 있습니다. 첫 번째 옵션은 소규모 구성을 위한 것입니다. 이 옵션은 캐시 구성 방법을 결정합니다.
미러링된 캐시
미러링된 캐시 토폴로지를 사용하여 캐시를 구성하는 옵션이 있는데, 작동 방식은 최대 두 대의 서버만 사용한다는 것입니다. 두 서버 중 하나는 모든 클라이언트가 연결되는 액티브 서버 역할을 합니다. 다른 서버는 백업 역할을 하는 패시브 서버 역할을 하며, 백업은 다음 방식으로 수행됩니다. NCache이 토폴로지는 구성만 하면 자동으로 아키텍처를 따릅니다. 기본적으로 이것이 활성인지 수동인지 정의할 필요가 없습니다. NCache 자동으로. 하지만 이렇게 하면 실제로 모든 클라이언트 애플리케이션이 액티브 서버에 연결되고, 거기서 데이터를 읽고 쓰게 됩니다. 액티브 서버에 있는 모든 데이터는 비동기 미러링 옵션을 통해 패시브 서버에 백업됩니다. 따라서 클라이언트가 액티브 서버를 업데이트하고 반환하므로 클라이언트 애플리케이션 측에서 복제 비용이 발생하지 않습니다. 클라이언트 애플리케이션은 매우 빠르게 작동합니다. 이면에서, NCache 백업을 업데이트해야 합니다. 백업이 존재하는 데에는 중요한 이유가 있습니다. 서버 1이 다운되면 백업 서버는 자동으로 활성 서버로 업데이트되고, 클라이언트는 연결을 장애 조치하여 새로 활성화된 이전 백업 서버를 사용하기 시작합니다. 이제 첫 번째 서버가 다시 연결되면 캐시 클러스터에 이미 활성 노드가 있으므로 활성 노드가 아닌 백업 노드로 다시 연결됩니다. 이 모든 작업은 애플리케이션에서 원활하게 수행됩니다. 서버가 추가되거나 손실될 때 사용자가 개입할 필요가 없습니다.
이 토폴로지는 읽기와 쓰기 모두에 매우 적합합니다. 따라서 참조용으로도 좋고, 트랜잭션 데이터에도 좋지만, 최대 두 대의 서버만 사용할 수 있고, 그 중 특정 시점에 활성화된 서버는 단 하나뿐이기 때문에 용량 문제가 있습니다. 따라서 안정적인 데이터, 즉 캐싱을 필요로 하는 소규모 구성의 경우 이 토폴로지가 하나의 옵션이 될 수 있습니다.
복제된 캐시
이어서 두 번째 옵션은 복제 캐시입니다. 이 역시 소규모 구성에 적합합니다. 모든 서버가 활성화되어 있는 방식으로 작동합니다. 보시다시피 서버 1과 서버 2가 모두 활성화되어 있습니다. 클라이언트는 여러 서버에 분산되어 있습니다. 따라서 그림과 같이 클라이언트가 2개라면, 그중 일부는 서버 2에 연결되고 나머지는 서버 XNUMX에 연결됩니다. 네, 이 세 개는 서버 XNUMX에 연결되고 나머지는 서버 XNUMX에 연결됩니다.
이는 자동으로 수행됩니다. 연결 밸런싱은 내부에 내장되어 있습니다. NCache. 모든 서버는 활성화되어 있지만 각 서버에는 캐시 사본이 있습니다. 따라서 서버 1에 있는 데이터는 서버 2에 사본이 있으며 이 사본은 동기화 업데이트를 통해 유지됩니다. 따라서 한 서버에서 수행하는 모든 업데이트는 동기화 호출에서 다른 서버에 적용되어야 하며, 이는 클라이언트가 전체 작업이 완료될 때까지 기다려야 한다는 것을 의미합니다. 어느 서버에서든 작업이 실패하면 전체 작업이 롤백됩니다. 이것이 모든 서버에서 100% 동기화된 사본을 얻는 방법입니다. 이는 안정성 측면에서 매우 좋지만, 읽기 집약적인 사용 사례가 있는 경우 데이터 사본이 더 많거나 다른 서버에서 더 많은 사본이 있기 때문에 서버가 많을수록 요청을 처리할 서버가 더 많아 읽기 용량이 증가합니다. 하지만 방금 알아차렸듯이 동기화 업데이트가 있으므로 모든 쓰기 작업은 모든 서버에 적용되어야 합니다. 따라서 쓰기 용량이 작은 구성에 적합합니다. 서버가 1~XNUMX대인 경우 동일한 작업을 XNUMX~XNUMX회 반복해야 하므로 성능 향상에 부정적인 영향을 미칠 수 있습니다. 따라서 이 토폴로지는 소규모 구성의 참조 데이터 시나리오에 더 권장됩니다. 읽기 확장성은 뛰어나지만 쓰기 확장성은 낮지만 안정성이 매우 뛰어납니다. 고가용성과 데이터 안정성을 제공하는데, 예를 들어 서버 XNUMX이 손실되는 경우와 같이 서버 중 하나가 손실되더라도 애플리케이션이 장애 조치를 수행하고 이미 사용 가능한 캐시 사본을 가지고 있는 서버를 선택하기 때문에 데이터 손실이나 다운타임이 발생하지 않습니다.
분할 캐시 및 파티션 복제 캐시
다음 옵션은 분할 캐시를 사용하여 캐시를 구성하는 것입니다. 분할 캐시와 분할 복제 캐시는 가장 널리 사용되는 토폴로지입니다. 분할 캐시를 사용하면 사용 가능한 서버 노드에 데이터를 분산할 수 있습니다. 예를 들어, 두 대의 서버가 있고 데이터가 있는 경우, 데이터의 절반은 서버 1에, 나머지 절반은 서버 2에 저장됩니다. 데이터 분산 또한 NCache애플리케이션에서 직접 처리하는 것이 아니라, 런타임에 애플리케이션에서 자동으로 처리합니다. 지능형 분산 맵과 해시 알고리즘이 있어 어떤 데이터가 어떤 서버로 전송될지 결정합니다.
따라서 이를 기반으로 캐시 클러스터의 모든 서버에 데이터를 균등하게 분배하는 애플리케이션이 됩니다. 이제 데이터가 균등하게 분배되므로 요청 부하도 균등하게 분배됩니다. 따라서 서버 수에 따라 더 많은 읽기 및 쓰기 용량을 얻을 수 있습니다. 서버가 두 대인 경우 두 대의 서버가 팀으로 작동합니다. 그리고 두 대에서 세 대로 성장하면 읽기 및 쓰기 요청을 처리하는 서버가 더 많아집니다. 따라서 읽기 및 쓰기에 대한 확장성이 향상됩니다. 따라서 선형 확장 방식으로 서버를 더 추가하면 확장성이 향상됩니다. 서버를 추가하면 데이터가 분산되므로 메모리 리소스도 풀링되어 모든 서버의 스토리지를 함께 풀링합니다. 따라서 서버가 두 대인 경우 두 대의 서버 용량을 갖게 됩니다. 세 번째 또는 네 번째 서버를 추가하면 해당 서버 수만큼 용량이 증가합니다. 따라서 전체 용량이 풀링되므로 캐시 클러스터에 서버를 더 추가할수록 선형적으로 증가합니다.
읽기, 쓰기 모두 매우 뛰어나며, 참조 및 트랜잭션 데이터 모두에 대해 확장성이 매우 뛰어납니다. 이 토폴로지의 유일한 단점은 백업이 없다는 것입니다. 서버에 장애가 발생하면 해당 파티션도 손실됩니다. 따라서 이러한 상황이 발생하면 백엔드 데이터베이스에서 해당 데이터를 구성할 방법이 필요합니다. 따라서 고성능을 달성하는 것이 주요 목표이고, 성능 중심 애플리케이션이며, 일반적으로 그렇듯이 데이터베이스를 다시 사용할 여력이 있다면, NCache 높은 가용성과 데이터 안정성을 위해 이 토폴로지는 다른 모든 토폴로지와 비교했을 때 최고의 성능을 제공합니다.
하지만 높은 가용성이 필요하고 데이터 안정성 요구 사항도 제공해야 하는 경우 NCache더 나은 토폴로지인 복제본 캐시 파티션(Partition of Replica cache)을 사용하고 있습니다. 전체 아키텍처는 복제본을 강화하여 분할된 것과 같습니다. 각 서버는 데이터 파티션을 가지고 있지만, 각 서버는 두 개의 파티션을 유지합니다. 클라이언트가 연결된 활성 데이터 파티션과 다른 서버의 백업 파티션입니다. 서버 1은 활성 상태이고 백업은 서버 2에 있으며, 서버 2는 활성 상태이고 백업은 서버 1에 있습니다. 또한, 동기 또는 비동기 백업 옵션을 선택할 수 있습니다. 복제본 캐시 파티션을 비동기로 선택하면 클라이언트는 활성 파티션을 업데이트하고 클라이언트에서 완료된 작업을 반환합니다. NCache 백업 파티션을 백그라운드에서 업데이트합니다. 동기화를 선택하면 클라이언트 애플리케이션이 활성 및 백업 파티션을 트랜잭션 작업으로 업데이트합니다. 어느 쪽이든, 동기화는 확실히 더 안정적이고 비동기는 더 빠릅니다. 하지만 어느 쪽이든, NCache 데이터 안정성을 처리할 수 있어서 서버가 다운되더라도 백업 토폴로지가 활성화되어 데이터 손실이나 애플리케이션 다운타임이 발생하지 않습니다. 그렇죠.
3대의 서버로 구성된 이 토폴로지를 간략하게 보여드리겠습니다. 읽기 성능과 쓰기 성능 모두 뛰어나고, 읽기와 쓰기 모두 선형 확장성을 제공합니다. 여기에 더해 확장성, 고가용성, 데이터 안정성이라는 이점도 얻을 수 있습니다. 서버가 다운되더라도 데이터 손실이나 애플리케이션 다운타임은 발생하지 않습니다.
Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
이해가 되셨기를 바랍니다. 이제 데모 환경으로 이동하여 캐싱 토폴로지를 구성하는 방법을 간략하게 보여드리고, 캐시 클러스터를 빠르게 테스트하는 방법도 알려드리겠습니다. 궁금한 점이 있으시면 언제든지 문의해 주세요. 저희가 보여드리는 모든 내용은 귀사의 특정 사용 사례에 맞춰 귀사의 환경에서 직접 진행하는 기술 지원 세션 및 지원 세션을 통해 확인하실 수 있습니다. 웨비나 이후에도 저희 팀이 함께 논의하는 모든 내용을 귀사와 함께 논의하여 귀사의 사용 사례를 보여드릴 수 있기를 바랍니다.
질문이라면, 마지막에 딱 들어왔던 질문이 하나 있어요. 그중 하나가 여러분이 가장 좋아하는 질문 중 하나예요.
애플리케이션 캐싱에 Hazelcast를 사용하는 것에 대해 많은 논의가 있었습니다. NCache Hazelcast는 그렇지 않은가요?
좋아요. 우선, 이건 토론에 가깝습니다. NCache 실제로 .NET 및 .NET Core로 작성되었으므로 선호되는 플랫폼입니다. NCache Windows입니다. 좋은 점은 NCache .NET뿐 아니라 Windows와 Linux에서도 실행된다는 점입니다. 따라서 플랫폼과 호환성이 지원됩니다. NCache 제공하는 다른 제품은 그런 기능을 제공하지 않습니다. 자, 이것이 첫 번째 부분인데, 사용하려는 플랫폼을 고려한다면 더 선호되는 선택입니다. 또 다른 차이점은, 저희 제품을 확인해 보시기를 권장한다는 것입니다. 비교 페이지, 거기에서도 아주 좋은 자료를 찾을 수 있을 겁니다. 하지만 간단히 요약하자면, NCache 객체 캐싱 지원에는 다른 제품에는 전혀 없는 많은 기능이 있습니다. 예를 들어, SQL 검색의 경우, 저희는 내부에 정교한 기능 세트를 제공합니다. NCache캐시 로더와 캐시 리프레셔가 있습니다. 이는 완전히 고유한 기능입니다. NCache저희의 읽기/쓰기 핸들러는 서버 측에서 .NET 및 .NET Core 코드를 실행할 수 있는 기능을 갖추고 있으며, 이는 완전히 독창적인 기능입니다. NCache, 그리고 목록은 계속 이어집니다. 그렇죠. 서버 측에서 사용자 정의할 수 있는 기능 중 일부는 다음과 같습니다. 이 기능은 NCache 그리고 애플리케이션 측면에서 보면 다른 제품에는 없는 기능들이 많습니다. 따라서 저희 비교 페이지를 확인해 보시기를 권장합니다. 기능별 비교가 게시되어 있으며, 이를 통해 더 자세한 정보를 얻을 수 있습니다.
이것은 확실히 우리가 가장 좋아하는 질문 라인입니다. 웨비나이든 기술 솔루션이든 Hazlecast일 수도 있고 Scala일 수도 있고 Redis, 하지만 정말 고마워요, 론. 네, 이제 괜찮을 것 같아요. 계속하세요. 물론이죠.
새로운 클러스터형 캐시 생성
그럼, 새로운 클러스터형 캐시를 만들어서 제품에 대한 간단한 데모를 보여드리겠습니다. 이름을 '테스트 캐시'라고 하겠습니다. 좋아요, 이 부분을 여기로 옮기겠습니다. 조금만 기다려 주세요. 알겠습니다.
네 가지 캐싱 토폴로지를 설명드렸습니다. 비동기 복제 옵션에서 가장 권장되는 방식인 복제본 분할 캐시를 사용하겠습니다. 이 모든 기본값을 그대로 유지하겠습니다.
이어서 GUI 도구를 사용하여 캐시를 구성하는 것이 얼마나 쉬운지 보여드리겠습니다. 이 예제는 웹 관리자이지만, PowerShell cmdlet을 사용하여 모든 작업을 수행할 수 있으며, 필요한 경우 이 배포를 자동화할 수도 있습니다. 서버 1을 추가하겠습니다. NCache 설치되었습니다. 그런 다음 서버 2를 추가합니다. 따라서 두 개의 상자가 NCache 2GB 크기로 설정할 예정입니다. 제 아이디어는 각각 2GB 캐시 용량을 사용하는 2노드 캐시 클러스터를 만드는 것입니다. 즉, 2대의 서버로 총 XNUMXGB가 됩니다. NCache 이미 설치되어 있습니다. 그런 다음, 제 컴퓨터를 사용하여 이 캐시 클러스터에 연결하겠습니다.
TCP 매개변수입니다. 이 포트는 설정 후 지정해야 합니다. 기본값을 유지하거나 방화벽의 영향을 받지 않는 다른 포트를 지정하세요.
암호화와 압축을 설정해야 하는 경우 이 화면이 표시됩니다. 그대로 두겠습니다. 다음을 선택하세요. 캐시가 가득 차면 제거를 선택할 수 있습니다. 한 가지 옵션은 캐시에서 쓰기 작업을 전혀 처리하지 않도록 하는 것입니다. '캐시가 가득 찼습니다'라는 오류가 발생합니다. 다른 옵션은 제거를 설정하고 이러한 알고리즘에 따라 런타임에 캐시에서 일부 항목을 제거하는 것입니다. 즉, 우선순위와 사용량에 따라 가장 최근에 사용되지 않았거나 자주 사용되지 않은 항목을 제거할 수 있으며, 항목의 5%가 캐시에서 제거됩니다. 이 캐시를 완료 시 자동으로 시작하도록 설정하여 서버가 재부팅될 때마다 또는 NCache 서버를 다시 시작하면 중지된 캐시를 다시 시작할 수 있습니다.
'마침'을 선택하면 됩니다. 캐시 클러스터 설정은 이렇게 간단합니다. 잠시 후, 이 캐시가 시작되는 또 다른 뷰가 표시되고, 그 뷰에서 모니터링 및 관리 세부 정보를 보여드리겠습니다. 캐시 구성에 대한 더 자세한 동영상이 준비되어 있으니, 궁금한 점이 있으시면 지금 바로 알려주세요. 아니면 그 동영상들을 참고하셔도 됩니다.
모니터 클러스터를 선택하면 캐시를 전체적으로 모니터링할 수 있는 대시보드가 열립니다. 완전히 연결된 캐시 클러스터, 요청 처리량 카운터, 지연 시간 카운터, 그리고 추가, 페치, 업데이트 카운터도 표시됩니다. 마찬가지로 CPU 및 메모리 사용량과 캐시 가득 참 상황도 표시됩니다.
클라이언트용 대시보드와 보고서 뷰도 있는데, 여기서 서버 측과 클라이언트 측 대시보드를 볼 수 있습니다. 현재 연결된 애플리케이션은 없지만, 이 테스트 스트레스 버튼을 사용하여 부하를 시뮬레이션할 수 있습니다. 테스트 스트레스 버튼을 호출하여 캐시 클러스터에서 더미 부하나 특정 활동을 시작할 수 있습니다. 그러면 클라이언트 하나가 연결된 것을 볼 수 있습니다. 이 토폴로지에서는 데이터가 분산되어야 합니다. 따라서 일부 데이터는 서버 1에, 다른 데이터는 서버 2에 전송됩니다. 따라서 이 클라이언트는 두 서버를 균등하게 사용하고 있습니다. 보시다시피 두 서버 모두에 요청이 들어오고 있으며, 두 서버의 캐시 크기가 증가하고 있습니다.
두 서버 모두 활성 및 백업 파티션이 표시됩니다. 지연 시간 카운터를 간단히 보여드리면, 제 운영 측면에서는 밀리초 미만, 심지어 마이크로초 단위의 지연 시간입니다. 클라이언트 대시보드에서 이러한 클라이언트 측 통계를 볼 수 있고, 마찬가지로 서버 측 통계를 보여주는 보고서도 있습니다.
론, 질문이 있어요. 사실 몇 가지 질문이 들어왔는데, 그중 하나는 다음과 같습니다.
추방에 대한 권장 사항은 무엇인가요? 그리고 만약 추방이 가능하다면, 잠시만 기다려 주세요. 추방을 해제할 경우, 캐시 크기를 늘리거나 줄일 수 있을까요?
물론입니다. 아시다시피, 축출은 사용 사례에 따라 설정해야 합니다. 데이터가 축출을 감당할 수 있는 것이라면 말이죠. 축출 자체가 캐시가 가득 차면 일부 데이터를 제거합니다. 이상적인 상황은 축출을 할 필요가 없고 캐시가 용량 내에 있는 것입니다. 캐시가 가득 차는 일이 없도록 충분한 크기나 메모리를 캐시에 할당합니다. 하지만 꽉 차는 경우가 발생하면, 아시다시피, 가득 차는 지점에 도달합니다. 이 경우, 백엔드 데이터베이스에서 언제든지 재구성할 수 있는 데이터라면 축출을 켜는 것이 좋습니다. 예를 들어 ASP.NET 세션의 경우, 축출을 켜지 않는 것이 좋습니다. 새 사용자를 위한 공간을 확보하기 위해 일부 사용자를 제거하게 되고, 모든 사용자는 중요한 데이터를 가지고 있기 때문입니다. 따라서 어떤 상황에서도 데이터를 잃어버리고 싶지 않을 것입니다. 따라서 이러한 시나리오에서는 캐시 크기를 늘리는 것이 좋습니다. 캐싱 크기를 충분히 크게 계획하고, 캐싱이 가득 찰 경우를 대비해 계획하십시오. NCache 런타임에 캐시 크기를 변경할 수 있습니다. 이 설정을 편집하고, 그에 따라 캐시 크기를 늘리고 실행 중인 캐시에 저장할 수 있습니다. 따라서 이 기능은 매우 유용하며, 런타임에 캐시 크기가 증가합니다.
다른 질문이 있으신가요? 답변이 된 것 같습니다. 데모를 완료하실 수 있도록 몇 가지 질문을 마지막에 남겨두겠습니다. 네. 데모 환경으로 돌아가서, 클라이언트를 추가할 수 있습니다. 예를 들어, 제 서버를 클라이언트로 추가할 수 있습니다. 이 샘플 애플리케이션은 제 서버에서 실행할 수 있습니다. 예를 들어, GitHub에서도 다운로드할 수 있으니 검색해 보세요. NCache GitHub에서 몇 가지 샘플을 볼 수 있는데, 저는 거기에서 샘플 중 하나를 추출했습니다. 따라서 애플리케이션에 실제로 해야 할 일은 NuGet 패키지를 포함하는 것입니다. Alachisoft.NCache.SDK, 그리고 만약 당신이 관심이 있다면 앱 데이터 캐싱이것이 여러분이 고려해야 할 샘플입니다. 그리고 이를 기반으로 추가하면 애플리케이션 내부에 몇 가지 리소스를 포함할 수 있습니다.
여기에는 이미 다음과 같은 일부 라이브러리가 포함됩니다. NCache, 이 새로운 NuGet 패키지의 일부로. 그런 다음 다음을 사용하여 이 참조를 포함합니다. Alachisoft.NCache.고객. 또한 추가 런타임 캐싱, 맞아요. 그리고 그걸 기반으로 캐시 핸들을 정의할 수 있고, 그 안에는 여러 메서드가 있습니다. 예를 들어 캐시를 초기화하는 방법을 보여드리겠습니다. 실제로 이 안으로 들어가 봅시다. 참아주세요. 제가 좀 어려워요. 어쨌든, 어떤 이유에서인지 실제로 이 안으로 들어갈 수가 없네요. 상자 자체에 문제가 있는 것 같아요. 어쨌든 API는 꽤 직관적입니다. 파워포인트에서 보여드리겠습니다. 이 샘플은 실제로 그것을 사용하고 있는데, 코드로 들어갈 수 없어서 보여드릴 수 없습니다. 제가 코드를 실행할 수 없게 되어 있거든요.
그래서 이것은 캐시 핸들이고 이것은 내가 보여주고 싶었던 코드 조각입니다. 캐시매니저.겟캐시 캐시에 연결할 수 있습니다. 그런 다음 호출할 수 있습니다. 캐시.가져오기 캐시에서 실제로 데이터를 가져오려면 다음과 같이 호출할 수 있습니다. 캐시.추가 or 캐시.AddAsync 캐시에 모든 레코드를 추가하고 upsert에서와 마찬가지로 삽입할 수 있습니다. 즉, 캐시에 데이터를 추가하고 업데이트할 수 있으며 마찬가지로 호출할 수 있습니다. 캐시.제거.
그래서 이건 견본 다운로드하고 캐시에 대해 실행할 수 있는 것이 있습니다. 애플리케이션 쪽에서 캐시를 가리키기만 하면 됩니다. 다양한 구성이 있습니다. 캐시 이름과 IP를 직접 지정하거나, 이 NuGet 패키지에 포함된 client.ncconf 파일을 사용할 수 있습니다. 간단히 몇 가지 리소스를 보여드리면, 실제로 많은 파일이 추가되어 있고, 바로 이 파일이 캐시에 연결할 수 있도록 해주는 파일입니다. 즉, 이미 'democache'에 연결할 수 있습니다. 실행하면 캐시에 대해 몇 가지 작업을 수행하고 캐싱 작업을 시작합니다.
마찬가지로, 몇 가지 더 많은 옵션을 제공할 또 다른 샘플이 있습니다. 예를 들어, 다음과 같은 질문이 있었습니다. 내부 검색 NCache네, 맞아요. 바로 여기 이 샘플을 사용해 보시는 걸 추천합니다. SQL 검색용입니다. GitHub에서 다운로드한 샘플인데, 검색을 사용하고, 샘플 데이터를 가지고 있고, SQL을 사용하여 검색을 호출합니다. 그리고 바로 여기에 여러 기능이 있는데, 같은 줄에 있습니다. 샘플은 매우 직관적입니다. 항목을 삽입한 다음 이름 태그를 사용하여 쿼리할 수 있고, 정의된 인덱스나 프로젝션을 사용하여 쿼리할 수도 있습니다.
불행히도 환경 문제로 인해 이러한 방법을 자세히 설명할 수는 없지만 이것들은 사용에 대한 좋은 참고점이 될 것입니다. NCache 애플리케이션 내에서 캐싱을 사용해야 하는 애플리케이션이나 애플리케이션 내에서 검색을 사용하는 사례가 있는 애플리케이션에서 사용할 수 있습니다.
클라이언트 캐시
또 다른 질문이 있었습니다. 클라이언트 캐시따라서 이 토폴로지는 코드 변경 없이 사용할 수 있는 옵션입니다. 데이터베이스에서 캐시하는 모든 데이터는 NCache클라이언트 캐시를 사용하여 추가로 캐싱할 수 있습니다. 이는 다른 캐시 위에 캐시를 얹는 방식입니다. 코드 변경 없이 작동합니다. 클러스터형 캐시와 동기화된 캐시이므로 데이터 일관성 문제가 없습니다. 동기화는 다음을 통해 수행됩니다. NCache한 클라이언트 캐시에서 수행된 모든 업데이트는 클러스터형 캐시로 필수적으로 전파되고, 이후 다른 클라이언트 캐시로 전파되며, 캐시에서 모든 동기화를 관리합니다. 쓰기 작업이 많지 않은 참조 데이터 시나리오에서는 이 옵션을 선택하는 것이 매우 권장됩니다.
WAN 복제
마찬가지로, NCache 또한이있는 WAN 복제액티브-패시브 및 액티브-액티브 토폴로지를 제공합니다. 따라서 브리지 캐시를 통해 전체 캐시 데이터를 한 데이터 센터에서 다른 데이터 센터로 복제할 수 있습니다. 브리지 자체는 액티브/패시브 서버에 백업되므로 소스 캐시와 대상 캐시가 있습니다. 재해 복구(DR) 시나리오나 동서 간 마이그레이션을 위해 한 데이터 센터에서 다른 데이터 센터로 단방향 복제 또는 동서 간 데이터 마이그레이션을 수행할 수 있습니다. 또는 한 애플리케이션의 데이터를 대상 애플리케이션에서 사용해야 하는 경우에도 사용할 수 있습니다. 따라서 한 데이터 센터에서 다른 데이터 센터로 전체 캐시 데이터를 전송할 수 있습니다.
다른 옵션은 액티브-액티브입니다. 이 경우 두 사이트 모두 활성화되어 사이트 1은 사이트 2로 데이터를 전송하고 사이트 2는 사이트 1로 데이터를 전송합니다. 이 옵션 역시 코드 변경 없이 사용할 수 있습니다. 단지 설정만 하면 됩니다. 브리지를 설정하면 두 캐시를 서로 연결하고 NCache 인수하여 해당 캐시 간에 데이터 복제를 시작합니다.
그리고 이는 멀티 액티브-액티브 토폴로지에도 확장되므로, 두 개의 사이트만 있을 필요는 없고, 세 개, 네 개 또는 다섯 개의 사이트가 서로 데이터를 전송하는 형태가 될 수도 있습니다. 즉, NCache모든 사이트의 데이터를 동시에 동기화할 수 있는 기능입니다. 참고로, 이 기능은 비동기 방식으로 수행되므로 복제 비용이 애플리케이션이나 사용자 측에서 발생하지 않습니다. 애플리케이션에서 직접 수행됩니다. 클라이언트 애플리케이션이 여기와 여기에 연결되어 있기 때문에 WAN 복제로 인한 성능 저하가 발생하지 않습니다. 이 기능은 백그라운드에서 자동으로 수행됩니다. NCache질문이 있으면 알려주세요. 이쯤에서 프레젠테이션과 기능 소개를 마치겠습니다. 잭, 질문이 있으면 알려주세요.
네, 몇 가지 질문이 있습니다. 그리고 여러분, 아시다시피, 여러분의 인내심에 감사드립니다. 프레젠테이션 내내 궁금하셨던 다른 질문들이 있다면, 지금이 질문하기에 좋은 시기입니다. 자, 그럼 하나부터 시작해 볼까요?
캐시가 정상적으로 작동하는지 어떻게 확인하시나요? 알림 등을 받을 수 있나요? 문제가 있는지 어떻게 알 수 있나요?
물론입니다. 우리는 가지고 있습니다 모니터링 및 관리 도구. 따라서 한 가지 방법은 시각적으로 클러스터 상태를 확인하는 것입니다. CPU 사용량, RAM 사용량 등을 확인할 수 있습니다. 기준선을 알고 있다면 애플리케이션에서 얼마나 많은 요청을 생성하고 있는지, 그리고 일반적인 사용률은 얼마인지 알 수 있습니다. NCache 이러한 카운터를 기반으로 모니터링 및 관리 대시보드를 사용하여 시각적으로 확인할 수 있습니다. 또한, 캐시 시작, 중지, 노드 조인/탈퇴, 캐시 크기 초과, 클러스터 스플릿 브레인(split brain)과 같은 비정상 상태 등 모든 상황에 대한 알림을 제공합니다. 이러한 알림은 Windows 이벤트 로그에 기록됩니다. 또한, 이메일 알림을 설정할 수도 있습니다. NCache, 그리고 이메일도 생성할 수 있습니다. 따라서 이는 사전 예방적 모니터링과 일부 알림을 제공하는 기능입니다. NCache어디로 NCache 알림을 받고 그에 따라 조치를 취할 수 있습니다. 또한, perfmon 카운터 로그와 캐시 로그 형태로 기록된 과거 데이터를 활용할 수 있습니다. 문제가 무엇인지 몰랐지만 몇 가지 문제가 발견된 경우를 대비하여 NCache, 우리는 와서 참여할 수 있고 검토할 수 있습니다. NCache 로그를 분석하고, 그 경우 캐시 상태를 평가합니다. 따라서 이와 관련하여 우리가 살펴볼 수 있는 방법은 많습니다.
좋은 생각입니다. 또 다른 질문은 다음과 같습니다.
최신 .NET 버전은 무엇입니까? NCache 현재 클라이언트를 지원하고 있나요?
알겠습니다. 일반적으로 저희는 최신 .NET 프레임워크 버전인 .NET Core를 사용합니다. 현재 .NET 6이 지원되며, 이는 필수 요구 사항입니다. NCache.NET 6이 필수로 필요합니다. NCache 서버는 상관없지만, 여러분의 애플리케이션은 .NET 프레임워크라면 어떤 버전이든 사용할 수 있습니다. 3.5부터 4.0, 4.5, 심지어 4.7, 4.8까지 모두 지원합니다. .NET 또는 .NET Core 프레임워크 중 어떤 것이든 사용할 수 있습니다. 서버 측에서만 제한이 있을 뿐입니다. 예를 들어 .NET 7과 같은 새로운 프레임워크와의 호환성 테스트가 완료되면, 저희 QA 랩에서 테스트를 진행하고 있습니다. 테스트가 완료되면 공식적인 지원을 제공할 예정입니다.
훌륭하네요. 또 다른 질문은 다음과 같습니다.
캐시 서버 간에 클러스터링된 캐시의 안전한 양은 얼마라고 생각하시나요? 캐시 서버 간에 클러스터링된 캐시를 15개 정도 만들 수 있을까요?
좋아요. 우선, NCache 구성할 수 있는 캐시 수에 제한을 두지 않습니다. 사실, 제 데모 환경을 보시면 캐시가 두 개 구성되어 있습니다. 따라서 필요한 만큼 생성할 수 있습니다. 하지만 프로덕션 환경에서는 일반적으로 10~XNUMX개의 캐시를 초과하지 않도록 권장하는 기술적 권장 사항이나 용량 관련 권장 사항이 있습니다. 각 캐시는 별도의 캐시 클러스터이기 때문입니다. 실제로 저장, 클러스터링, 통신을 위한 모든 리소스를 소모하게 되며, 클러스터 관리 오버헤드도 발생합니다. 따라서 캐시 수가 증가함에 따라 해당 환경 또는 해당 환경 내에서 용량 문제가 발생합니다. 따라서 가능하면 XNUMX~XNUMX개 이내로 유지하는 것이 좋습니다. 여러 개의 캐시가 필요한 경우에는 최대 XNUMX개까지 확장할 수 있습니다. 하지만 말씀드렸듯이 이는 권장 사항일 뿐입니다. 이를 강제하는 실제 제한은 없습니다. 이는 저희 측에서 일반적으로 권장하는 사항입니다.
좋아요. 세션이 끝났고, 도커에 다른 작업도 있는 것 같으니, 하나만 더 말씀드리겠습니다.
수 NCache DR 복제를 제공합니까?
네, 그렇습니다. 방금 말씀드린 WAN 복제 기능, 즉 마지막 토폴로지는 재해 복구(DR)를 지원합니다. 활성 사이트의 데이터를 다른 사이트로 전송할 수 있으므로 재해 복구 사이트는 완전히 백업됩니다. 애플리케이션 쪽에서 스위치만 켜면 됩니다. 모든 데이터가 이미 백업되어 있으므로, 한 데이터 센터가 완전히 중단되거나 유지 관리를 위해 직접 다운되어야 하는 상황에서도 데이터 손실이 발생하지 않습니다.
좋습니다. 최대한 많은 내용을 다루었다고 생각합니다. 여러분, 이 세션 외에도 저희가 가능하다는 점을 알려드리겠습니다. 이미 사용 중이시라면, 기존 구성을 검토하는 데 있어 함께 협력할 수 있어 매우 기쁩니다. NCache. 처음이시라면 NCache, 우리는 귀하에게 시험판을 설정하고 이것이 귀하의 통합 애플리케이션에서 어떻게 작동하는지 안내해 줄 핸드홀딩 세션을 제공하게 되어 기쁩니다. 그러나 무엇보다도 질문이 있을 때 언제든지 연락할 수 있다는 것을 알아두십시오. NCache제품 사용에 대한 도움이 필요하시거나 도움이 필요하신 경우 언제든지 문의해 주세요. 앞으로 새로운 기능과 새 버전이 많이 출시될 예정이니, 계속 지켜봐 주시면 곧 더 많은 웨비나를 준비하겠습니다.
론에게 박수를 보냅니다. 오늘 세션에 시간을 내주셔서 정말 감사합니다. 다음 세션도 기대됩니다. 모두 감사합니다. 잭, 고맙습니다. 물론이죠. 좋습니다, 여러분. 모두 좋은 하루 보내시고 다음 웨비나에서 뵙기를 기대하겠습니다. 그리고 한 가지 덧붙이자면, 이 웨비나가 끝나면 웨비나 녹화본을 웹사이트에 업로드할 예정입니다. 혹시 질문에 대한 답변을 받지 못하셨거나, 저희가 말씀드린 내용을 다시 살펴보고 싶으시다면, 언제든지 웹사이트에 다시 오셔서 녹화된 웨비나를 확인해 주세요.
좋아요. 그럼 모두에게 인사드려요. 좋은 하루 보내세요. 고마워요, 여러분. 안녕히 계세요.