NCache 아키텍처
녹화된 쇼
론 후세인(Ron Hussain)과 잭 칸(Zack Khan)
오늘 웨비나는 다음을 기반으로 합니다. NCache 아키텍처. 이제 분산 캐싱에 대한 개요와 이를 통해 .NET 및 .NET Core. 우리는 분산 캐시 아키텍처, 클러스터링 세부 사항뿐만 아니라 일반적인 사용 사례를 다룰 것입니다. NCache, 그러나 일반적으로 캐싱. 이제 이 웨비나 전체에서 언제든지 GoToWebinar 질문 탭에 질문 옵션이 있으므로 질문 탭을 편리하게 살펴보시기 바랍니다. 그리고 귀하께서 질문을 작성하시면 프레젠테이션 중에 제가 이를 언급하여 Ron이나 제가 답변해 드릴 수 있습니다. 또한 이 세션이 끝날 때 다른 질문을 처리할 수 있도록 약간의 시간이 있지만 즐거운 시간을 보내길 기대합니다.
그러니 더 이상 고민하지 않고 Ron에게 넘겨주고 진행하겠습니다. 아주 좋아요, 고마워요, 잭. 자, 방금 Zack이 언급했듯이 여러분, 오늘의 주제는 NCache 건축학. 이번 웨비나에서는 NCache 클러스터링이 작동하는지, 선택할 수 있는 가장 일반적인 토폴로지는 무엇인지, 그리고 클러스터링의 주요 이점 중 하나는 무엇입니까? NCache 애플리케이션 사용 사례 측면에서. 이러한 사용 사례는 무엇이며, 이를 최대한 활용할 수 있는 방법은 무엇입니까? NCache 귀하의 서버 애플리케이션 내에서?
그래서 모두가 내 화면을 볼 수 있기를 바랍니다. 이에 대한 빠른 확인을 받을 수 있으면 이 작업을 신속하게 시작하겠습니다. 네, 가능하다면 우리 모두 괜찮을 것 같아요. 내 생각에는 거기 있는 것 같다. 응, 괜찮아 보이는데. 완벽한. 좋아요, 그럼 빨리 시작해 보겠습니다.
확장성 문제
좋습니다. 우선 무엇인지 정의해 보겠습니다. NCache 이다? 그러기 위해서는 확장성 문제가 무엇인지, 그리고 어떻게 해야 할지 정의해야 합니다. NCache 확장성 문제를 해결할 수 있습니다. 따라서 애플리케이션을 배포한 일반적인 서버 아키텍처에서는 해당 애플리케이션이 배포되었는지 여부에 관계없이 일반적으로 둘 이상의 인스턴스 또는 서버입니다. 따라서 애플리케이션 계층은 확장성이 매우 뛰어난 계층이라고 해도 과언이 아닙니다.
애플리케이션 계층에 서버를 원하는 만큼 추가할 수 있습니다. 여러 애플리케이션 서버 또는 웹 서버가 동일한 애플리케이션을 호스팅하지만 팀으로 작업하고 요청 로드를 서로 나누는 경우 웹 양식, 앱 양식을 구성할 수 있습니다. 그리고 마이크로서비스 아키텍처를 포함한 새로운 아키텍처로 나아가는 경우 더 많은 계산이나 더 많은 요청 처리 용량이 필요한 애플리케이션 서비스, 마이크로서비스를 개별적으로 확장할 수 있습니다.
따라서 앱 계층은 확장성이 뛰어납니다. 선형적으로 확장 가능합니다. 규모가 커짐에 따라 점점 더 많은 요청 로드를 처리할 수 있습니다. 관계형 데이터베이스와 같은 데이터베이스를 다룰 때 문제가 발생합니다. 이러한 모든 애플리케이션은 확장성 수준에 관계없이 항상 백엔드 데이터베이스와 통신해야 하기 때문입니다. 그리고 백엔드 데이터베이스와 통신할 때 이는 일반적으로 단일 소스입니다. 그리고 확장성이 별로 좋지 않습니다. 보관하기에 매우 좋습니다. 많은 디스크 리소스를 가질 수 있습니다. 따라서 스토리지 이점을 얻을 수 있습니다. 그러나 애플리케이션에 막대한 트랜잭션 로드가 있고 이것이 데이터베이스 트랜잭션 로드로 변환되면 데이터베이스가 다운되는 경향이 있습니다. 그리고 이것이 애플리케이션이 요청 처리에 어려움을 겪는 주요 문제입니다. 확장성이 없으며 최종 사용자 경험도 손상됩니다.
NoSQL database이 문제는 어느 정도 해결되었습니다. SQL 데이터베이스를 사용할 수 있지만 이를 위해서는 관계형 데이터베이스 사용을 중단하고 SQL 데이터베이스 사용을 시작하는 방식으로 애플리케이션을 재구성해야 합니다. NoSQL database 그리고 그것은 큰 프로젝트입니다. 그래서, NoSQL 항상 확장성 문제에 대한 해결책은 아닙니다.
해결 방법 : NCache 분산 캐시
그렇다면 이제 우리는 이것을 어떻게 해야 할까요? 해결책은 매우 간단합니다. 다음과 같이 메모리 내 분산 캐시가 있어야 합니다. NCache. 우선, 이는 인메모리이므로 얻을 수 있는 가장 큰 이점은 애플리케이션의 성능이 향상된다는 것입니다. 관계형 데이터베이스에 비해 속도가 매우 빠릅니다. 그리고 가장 큰 이점은 선형적으로 확장 가능하다는 것입니다. 일반적으로 단일 소스인 데이터베이스 서버와는 다릅니다. NCache 여러 서버에 상주할 수 있습니다. 이를 통해 캐시 클러스터 여러 상자에서 실행할 수 있습니다. 그리고 아시다시피 애플리케이션 계층에서 처리해야 하는 요청 처리 용량이 더 많아야 하는 요구 사항이나 요구 사항이 증가하면 런타임에 캐시 클러스터에 더 많은 서버를 추가할 수 있습니다.
좋은 점 NCache 관계형 데이터베이스와 함께 사용한다는 것입니다. 또는 백엔드 데이터베이스는 기존 데이터 소스를 대체하지 않습니다. 이는 애플리케이션의 성능을 향상시킬 수 있는 방식으로 기존 데이터 소스를 보완하는 것입니다. 애플리케이션의 요청 처리 용량을 늘릴 수 있습니다. 그리고 애플리케이션이 성장함에 따라 언제든지 캐시 클러스터의 서버 수를 늘릴 수 있습니다. 이는 클러스터의 서버이므로 팀으로 작동하기 때문입니다. 결과적으로 선형 확장성을 제공하는 방식으로 요청 로드를 서로 나눌 수 있습니다. 그래서, NCache 선형적으로 확장 가능한 모델이며 사용이 매우 쉽습니다. 배포 아키텍처가 어떻게 작동하는지 이야기해 보겠습니다. 따라서 일반적으로 대규모 프로덕션 환경에서는 다음과 같은 방법을 사용합니다. NCache 다음과 같이 보일 것입니다.
당신은 많은 서버를 갖게 될 것입니다. 이는 다음과 같은 방식으로 설계된 Windows 또는 Linux 서비스일 수 있습니다. NCache 애플리케이션과 데이터베이스 사이에 위치합니다. 예를 들어 XNUMX~XNUMX개로 시작할 수 있습니다. NCache 서버를 최대 XNUMX~XNUMX개까지 늘릴 수 있습니다. 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 이를 자동화할 수 있는 기능이 있습니다. 여기서는 "캐시 통과" 옵션을 제공하며 읽기의 경우 "읽기", 쓰기의 경우 "쓰기"라고 합니다. 이는 항상 캐시를 기본 소스로 사용하고 캐시에 연속 읽기 핸들러를 구현하여 백엔드 데이터 소스 업데이트를 담당하는 방식으로 작동합니다. 따라서 어떤 읽기 작업을 수행하든 데이터가 존재하지 않으면 공급자를 기반으로 데이터베이스로 원활하게 이동하여 애플리케이션을 위해 검색하고 앱으로 돌아와서 내부에 저장합니다. NCache. 업데이트의 경우 애플리케이션에서 호출한 모델에 따라 동기화 또는 비동기 방식으로 데이터베이스뿐만 아니라 캐시도 업데이트합니다.
따라서 연속 읽기, 연속 쓰기 및 캐싱 패턴에 대한 자세한 내용을 공유하겠습니다. 하지만 개략적인 배포 그림을 제공하기 위해 다음과 같이 표시됩니다. NCache 여러 응용 프로그램이나 응용 프로그램 양식을 연결할 수 있는 서버 형태로 배포됩니다. NCache 그런 다음 메모리 액세스에서 애플리케이션 성능이 향상되는 분산 캐싱을 활용할 수 있습니다. 또한 캐시 계층에 여러 서버를 보유하면 선형 확장성을 제공할 수 있습니다. 나는 그것이 분명했기를 바랍니다. 질문이 있으면 알려주세요. 뭐, 다행히 지금은 아무 것도 없는 것 같으니 편하게 계속해 주세요. 매우 좋은.
NCache 확장성 수치
그럼 다음 이야기를 할게요 NCache의 확장성 수치입니다. 우리는 방금 그것을 언급했습니다 NCache 애플리케이션의 확장성 문제를 해결할 수 있습니다. 그래서, NCache 그 자체는 선형적으로 확장 가능합니다. 따라서 확장 가능한 애플리케이션 계층을 사용하면 선형 확장 가능한 모델을 통해 데이터베이스 병목 현상을 해결하므로 참고할 수 있는 몇 가지 수치는 다음과 같습니다. 이는 QA 환경에서 수행한 벤치마크 테스트입니다. CPU와 RAM 사용량이 많은 서버를 사용하여 실제로 확장하고 부하가 높은 상황에서 사용할 수 있었습니다. 우리는 한 대의 서버로 시작했고 두 대의 서버로 애플리케이션 로드를 계속 늘렸습니다. 서버 세트의 CPU 및 RAM 용량이 최대에 도달하자마자 다른 서버를 추가하게 되었습니다.
이것이 바로 엄지손가락의 법칙입니다. 기존 캐시 서버를 계속 사용할 수 있는 경우 두 개로 시작하세요. NCache 그리고 이 두 서버의 하드웨어 용량이 최대치에 달하고 있는 것을 볼 때, CPU가 최대치에 도달하거나 RAM이 최대치에 도달하고 있는 경우, 이제 확장해야 하는지 선택해야 하며 캐시 클러스터에 세 번째 서버를 추가해야 합니다. 이것이 바로 우리가 평균 1KB의 개체 크기로 수행한 작업입니다. 우리는 계속해서 애플리케이션 로드를 늘리고 서버 수를 늘렸습니다. 주어진 서버 세트가 최대가 될 때까지. 그리고 이것은 터치 앤 고 데이터가 아니었습니다. 실제 애플리케이션 데이터였지만 QA 랩에서 시뮬레이션되었습니다. 따라서 2개의 서버, 1개, XNUMX개, XNUMX개, 최대 XNUMX개의 서버를 사용하여 평균 XNUMXKB 개체 크기로 초당 XNUMX만 개의 요청을 처리할 수 있었습니다.
따라서 캐시에 일관되게 적용되는 읽기와 쓰기의 조합이었습니다. 따라서 전체적으로 초당 2만 요청의 처리량이 달성되었습니다. 동시에 성능 저하 없이 말이죠. 따라서 처리량은 단순히 초당 요청 수가 많은 것이 아닙니다. 하지만 개별 요청 대기 시간도 유지되어야 하며 매우 빨라야 합니다. 이에 대한 비디오 데모와 백서가 당사 웹사이트(여기를 보아라). 그리고 그것은 당신도 검토할 수 있는 것입니다.
분산 캐시의 일반적인 사용
좋습니다. 일반적인 사용 사례에 대해 이야기해 보겠습니다. NCache.
-
앱 데이터 캐싱
최고의 사용 사례는 애플리케이션 데이터를 캐싱하는 것입니다. 앱 데이터 캐싱. 이제 이것은 백엔드 데이터베이스에서 나오는 데이터입니다. 우리는 데이터베이스가 디스크 기반이기 때문에 일반적으로 느리다는 것을 이미 확인했습니다. 그에 비해 RAM은 더 빠른 소스입니다. 또 다른 문제는 트래픽이 많아지면 데이터베이스가 다운되는 경향이 있다는 것입니다. 트랜잭션 로드가 많고 서버가 하나라면 애플리케이션 측에서 필요한 성능을 제공하지 못할 것으로 예상됩니다. 따라서 다음을 사용하여 애플리케이션 내부에 애플리케이션 데이터를 캐시하는 것이 좋습니다. NCache. 매우 간단합니다. 너는 사용한다 NCache API를 사용하면 간단히 캐시를 호출할 수 있습니다. 캐시 초기화 API를 호출하여 캐시에 연결합니다. 일단 캐시에 연결되면 '캐시.추가, 캐시.업데이트, 캐시.제거'또는'캐시.가져오기' 캐시에서 데이터를 검색합니다. 그럼 마지막으로 몇 가지 예시를 보여드리겠습니다. 그러나 여기서의 아이디어는 참조 데이터이든 트랜잭션 데이터이든 두 번 이상 읽을 것이라고 생각하는 데이터가 무엇이든 상관없다는 것입니다. 참고자료의 경우, NCache 변경 사항을 검색하기 위해 데이터베이스로 돌아갈 필요가 없기 때문에 많은 가치를 추가할 것입니다.
분산 캐시의 일반적인 사용 그렇군요. 캐시에 있는 데이터를 더 오랜 기간 동안 사용할 수 있게 됩니다. 그리고 다음의 데이터를 사용하는 동안 NCache, 백엔드 데이터베이스로 이동할 필요가 없습니다. 그러면 애플리케이션의 성능이 향상됩니다. 그리고 확장성을 제공합니다. NCache 비교하면 확장 가능합니다.
따라서 모든 참조 데이터를 캐시하는 것은 매우 직관적이지만 트랜잭션 데이터의 일부 또는 대부분도 캐시하는 것이 좋습니다. 경험상 두 번 이상 읽은 데이터는 두세 번 읽게 되는 데이터라도 캐싱하는 것이 좋습니다. 데이터베이스에서 변경된 경우라도 변경 후에 한 번 이상(두세 번) 읽는 경우 해당 데이터를 캐시하는 것이 합리적이므로 캐시할 필요가 없습니다. 백엔드 데이터베이스로 이동합니다. 그리고 우리는 내장된 기능을 가지고 있습니다. NCache 데이터베이스와의 100% 동기화도 가능합니다. 이는 여러분도 항상 고려할 수 있는 사항입니다.
Ron, 나는 주로 다음과 같은 간단한 질문을 받았습니다.
항상 네트워크를 통해 클러스터된 캐시로 이동해야 합니까? 네트워크 문제로 인해 응용 프로그램이 작동하지 않을까 두렵습니다. 내 데이터 중 일부를 로컬에서 유지 관리할 수 있는 방법이 있나요?좋습니다. 일반적으로 기본 배포에서는 다음을 수행하는 것이 좋습니다. NCache 별도의 상자에, 신청서를 별도의 상자에 담으시죠? 그래서 언제쯤 NCache TCP 프로토콜을 기반으로 하므로 네트워크 호출입니다. 응용 프로그램 상자에 있는 로컬 캐시인 "클라이언트 캐시"라는 기능이 있습니다. 그리고 어떤 경우에는 더 많은 수행자가 정말로 필요하고 네트워크로 인해 발생하는 어떤 종류의 대기 시간도 원하지 않는 경우 "in-proc"으로 만들 수도 있습니다. 즉, 애플리케이션 프로세스 내에 위치하게 됩니다. 따라서 그런 일이 발생하면 데이터의 하위 집합이 자동으로 클라이언트 캐시 내부로 가져옵니다. 따라서 프로세스 간 통신이 저장됩니다. 그러면 네트워크 통신이나 네트워크 오버헤드도 절약됩니다. 따라서 우리에게는 기능이 있습니다. 이에 대해서는 토폴로지로 이동한 후에 다루겠습니다. 그래서 좀 더 자세한 내용을 공유하겠지만 간략한 개요만 설명하자면 클라이언트 캐시가 작동하는 방식은 다음과 같습니다. 이는 애플리케이션이 있는 동일한 상자에 있는 캐시입니다. 그리고 여기서 아이디어는 클라이언트 캐시가 활성화된 경우 빈번한 네트워크 이동이 필요하지 않다는 것입니다. 그리고 이는 코드 변경 없이 작동합니다. 그래서 그 질문에 대한 답변이 되기를 바랍니다. 더 궁금한 점이 있으면 알려주시기 바랍니다. 네, 좋은 것 같아요. 론, 이거 가져가세요. 매우 좋은.
-
ASP.NET 및 ASP.NET Core 캐싱
다음 사용 사례는 NCache 웹 애플리케이션에 있습니다. 사용자 데이터를 캐싱하는 데 몇 가지 요구 사항이 있다는 사실을 알고 계시나요? 일반적으로 ASP.NET 또는 ASP입니다..NET Core 세션 상태. 이제 이 데이터는 임시 데이터이기 때문에 데이터베이스에 속하지 않습니다. 이는 사용자가 구성하는 데이터이며 해당 사용자가 활성 상태인 동안 애플리케이션 범위에 유지됩니다. 어떤 경우에는 기록 관점에서 데이터베이스에 보관할 수도 있지만 대부분의 경우 데이터는 사용자에게 속합니다.
따라서 Microsoft ASP.NET 또는 ASP.NET Core 세션. 상태 서버를 사용할 수 있는 몇 가지 옵션이 있습니다. 프로세스 내에서 사용할 수 있습니다. 데이터베이스 서버를 사용할 수 있습니다. 이러한 모든 옵션에는 문제가 있습니다. 예를 들어 in-proc은 단일 실패 지점입니다. 고정 세션 로드 밸런싱을 사용해야 합니다. ASP.NET State Server는 역시 단일 실패 지점이며 확장이 불가능합니다. 데이터베이스는 옵션이며 백업할 수 있으므로 단일 실패 지점이 아니지만 경우에 따라 단일 실패 지점이 될 수 있지만 속도가 느리고 확장성이 없습니다. 그렇다면 우리는 여기서 무엇을 해야 할까요? 다시 한 번 사용을 고려해보세요. 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 Backplane. 왜냐하면 웹 양식에서 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에 비해 디스크를 사용합니다. 사용 사례의 특성상 데이터가 지속되어야 하기 때문입니다.
분산 캐시의 일반적인 사용
내가 Zack으로 이동하기 전에; 질문이 게시된 것 같습니다. 응. 그래서 기본적으로 DB를 기본적으로 말하는 것에서 질문이 들어왔습니다. 그래서, 당신이 그것을 끝낼 때까지 기다리고 싶었지만 기본적으로 질문은 묻고 있습니다. 혹시, 질문에 대해 좀 더 자세히 설명해 주실 수 있나요?
안녕하세요 론입니다 NCache 또한 백그라운드 프로세스로 데이터베이스의 데이터를 동기화하는 옵션과 함께 데이터 인 메모리 캐시를 저장해야 하는 요구 사항과 함께 데이터 게시 목적에도 적합합니까? 그리고 할 수 있다 NCache 기본적으로 메모리 캐시와 데이터베이스 간의 동기화 메커니즘을 처리합니까?
네, 아주 좋은 질문입니다. 고급 사례의 경우 이는 항상 요구 사항이 될 수 있습니다. 그것은 두 가지 방식으로 작동합니다. 하나는 귀하의 애플리케이션이 현재 다음에서 오는 데이터를 사용하고 있다는 것입니다. NCache, 그러나 데이터가 데이터베이스에 존재합니다. 따라서 이들은 읽기 및 쓰기 목적으로 동기화되어야 하는 두 가지 다른 소스입니다. 이제 연결된 애플리케이션이 NCache 데이터베이스는 내부 데이터 변경을 담당하는 유일한 애플리케이션입니다. NCache 이제 데이터베이스에서는 연속 읽기 및 연속 쓰기를 사용하는 것이 좋습니다. 그리고 그렇습니다. 이는 요구 사항에 따라 비동기식 또는 동기화 방식으로 수행될 수 있습니다. 따라서 실제로 일어날 일은 다음과 같습니다. NCache 캐시에 존재하지 않는데 캐시되도록 하려면 자동으로 연속 읽기를 호출하고 코드를 기반으로 백엔드 데이터베이스에서 읽습니다. 마찬가지로, 데이터가 데이터베이스에서 오고 다시 해당 데이터를 데이터베이스에서 업데이트해야 하는 경우 캐시에서 데이터를 업데이트하자마자 연속 쓰기를 사용하게 됩니다. 이제 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% PXNUMXP 아키텍처이므로 단일 실패 지점이 없습니다. 런타임 시 서버를 추가하거나 제거할 수 있습니다. 캐시나 캐시에 연결된 클라이언트 애플리케이션을 중지할 필요가 없습니다. 따라서 실행 중인 캐시 클러스터를 동적으로 변경할 수 있으며, NCache 그것에 대해 어떤 문제도주지 않을 것입니다. 서버를 추가하면 클라이언트는 런타임에 알림을 받게 되므로 이 서버가 더 이상 캐시 클러스터의 일부가 아니라는 사실을 자동으로 알게 됩니다. 따라서 추가 서버를 사용하기 시작하면 클러스터가 자동으로 조정됩니다. 마찬가지로, 서버를 제거하면 다른 서버에서 이 서버가 완전히 사라진 것을 감지합니다. 클라이언트에게 알리고 클라이언트는 손실된 서버 사용을 중지합니다. 클라이언트 측에도 구축된 연결 장애 조치 지원이 있으므로 서버가 다운되면 클러스터가 클라이언트가 이를 인식하도록 보장하고 연결을 장애 조치하고 살아남은 서버를 사용하기 시작합니다. 서버.
따라서 어떠한 경우에도 클러스터의 모든 변경 사항이 클라이언트에 전파됩니다. 클라이언트는 지능적이므로 항상 캐시 클러스터의 상태를 알고 있습니다. 따라서 복제 지원도 내장되어 있으므로 가동 중지 시간이나 데이터 손실이 발생하지 않습니다. 그래서, NCache 가용성이 높을 뿐만 아니라 복제를 통해 매우 안정적입니다. 애플리케이션 중단 없이 애플리케이션 종료 시 100% 가동 시간을 보장하므로 계속해서 사용할 수 있습니다. NCache.
캐싱 토폴로지
다음으로 캐싱 토폴로지에 대해 설명하겠습니다. 이것이 제가 다루고 싶었던 주요 부분입니다. 선택할 수 있는 옵션은 네 가지가 있습니다. 첫 번째 옵션은 다시 소규모 구성을 위한 것입니다. 이는 캐시를 구성하는 방법을 나타냅니다.
미러링된 캐시
따라서 미러링된 캐시 토폴로지를 사용하여 캐시를 구성하는 옵션이 있으며 작동 방식은 최대 XNUMX개의 서버만 사용하는 것입니다. 해당 서버 중 하나는 모든 클라이언트가 연결되는 활성 서버 역할을 합니다. 다른 서버는 백업 역할을 하는 수동 서버 역할을 하며 백업은 다음에 의해 수행됩니다. NCache. 이 토폴로지는 일단 구성하면 자동으로 아키텍처를 따릅니다. 기본적으로 이것이 활성이 되거나 수동이 되는지 정의할 필요는 없습니다. NCache 자동으로. 하지만 일단 그렇게 하면 실제로 일어날 일은 모든 클라이언트 응용 프로그램이 활성 서버에 연결되고 그곳에서 데이터를 읽고 쓰는 것입니다. 활성 서버에 있는 모든 데이터는 비동기 미러링 옵션을 통해 수동 서버에 백업됩니다. 따라서 클라이언트는 활성 상태를 업데이트하고 반환하므로 클라이언트 애플리케이션 측에서 복제 비용이 발생하지 않습니다. 클라이언트 응용 프로그램은 매우 빠릅니다. 무대 뒤에서, NCache 백업을 업데이트해야 합니다. 그리고 백업이 존재하는 중요한 이유는 서버 하나가 다운되면 백업 서버가 자동으로 활성 서버로 업데이트되고 클라이언트가 연결을 장애 조치하고 새로 활성화된 이전 백업 서버를 사용하기 시작한다는 것입니다. 그리고 이제 첫 번째 서버가 다시 들어오고, 캐시 클러스터에 이미 활성 노드가 있으므로 활성 노드가 아닌 백업 노드로 다시 참여하게 됩니다. 그리고 이 모든 작업이 애플리케이션에서 원활하게 수행됩니다. 서버가 추가되거나 서버가 손실될 때 개입할 필요가 없습니다.
이 토폴로지는 쓰기뿐만 아니라 읽기에도 매우 좋습니다. 따라서 참조용으로는 좋고 트랜잭션 데이터용으로는 좋지만 최대 XNUMX개의 서버만 있고 해당 두 서버 중 특정 시점에 단 하나의 서버만 활성화되므로 용량 문제가 있습니다. 따라서 신뢰할 수 있는 데이터를 사용하는 소규모 구성의 경우 캐싱이 옵션 중 하나일 수 있습니다.
복제된 캐시
계속해서 두 번째 옵션은 복제된 캐시입니다. 이는 더 작은 구성을 위한 것입니다. 이는 서버 1과 서버 2가 모두 활성화되어 있는 것을 볼 수 있듯이 모든 서버가 활성화되는 방식으로 작동합니다. 클라이언트는 서로 다른 서버로 나누어져 있으므로 다이어그램에 표시된 것처럼 2개의 클라이언트가 있는 경우 일부는 서버 2에 연결되고 일부는 서버 XNUMX에 연결됩니다. 그렇습니다. 이 세 개는 서버 XNUMX에 연결되고 이들은 서버 XNUMX에 연결됩니다. 서버 XNUMX.
이 작업은 자동으로 수행됩니다. 연결 균형 조정은 내부에 내장된 것입니다. NCache. 모든 서버가 활성화되어 있지만 각 서버에는 캐시 복사본이 있습니다. 따라서 서버 1에 있는 데이터가 무엇이든 복사본은 서버 2에 있으며 이 복사본은 동기화 업데이트를 통해 유지 관리됩니다. 따라서 한 서버에서 수행하는 업데이트가 무엇이든 해당 업데이트는 동기화 호출을 통해 다른 서버에 적용되어야 하며, 이는 클라이언트가 전체 작업이 완료될 때까지 대기한다는 의미입니다. 서버에서 작업이 실패하면 전체 작업이 롤백됩니다. 이것이 바로 우리가 모든 서버에서 100% 동기화된 복사본을 달성하는 방법입니다. 이는 안정성 측면에서 매우 좋지만 읽기 집약적 사용 사례의 경우 더 많은 데이터 사본이 있거나 다른 서버의 사본이 더 많기 때문에 서버가 많을수록 읽기 용량이 증가합니다. 요청을 처리할 서버가 더 많기 때문입니다. 그러나 동기화 업데이트가 있다는 것을 방금 확인하셨듯이 모든 쓰기 작업은 모든 서버에 적용되어야 합니다. 따라서 쓰기 용량을 위한 소규모 구성에 적합합니다. 서버가 1~XNUMX개 있는 경우 동일한 작업을 XNUMX~XNUMX회 적용해야 하므로 상승 성능에 부정적인 영향을 미칠 수 있습니다. 따라서 이 토폴로지는 참조 데이터 시나리오, 소규모 구성에 더 권장됩니다. 읽기 확장성은 뛰어나고 쓰기 확장성은 크지 않지만 매우 안정적입니다. 서버 XNUMX이 손실되는 경우와 같이 서버가 손실되는 경우 이러한 애플리케이션이 장애 조치를 수행하고 남은 서버를 선택하기 시작하며 캐시 복사본이 있으므로 데이터 손실이나 가동 중지 시간이 없으므로 고가용성과 데이터 안정성을 제공합니다. 이미 사용 가능합니다.
분할된 캐시 및 분할 복제본 캐시
다음 옵션은 분할된 캐시를 사용하여 캐시를 구성할 수 있다는 것입니다. 이제 분할된 분할 복제는 가장 널리 사용되는 토폴로지입니다. 분할된 캐시를 사용하면 사용 가능한 서버 노드 간에 데이터를 배포할 수 있습니다. 예를 들어, 두 개의 서버가 있고 일부 데이터가 있는 경우 데이터의 절반은 서버 1로 이동하고 데이터의 절반은 서버 2로 이동합니다. 데이터 배포도 다음 작업의 일부입니다. NCache. 이는 애플리케이션이 수행하는 작업이 아니며 런타임 시 애플리케이션에 의해 자동으로 수행됩니다. 지능형 배포 맵과 해시 알고리즘이 있으며 이는 어떤 데이터가 어떤 서버로 이동할 것인지를 결정합니다.
따라서 이를 기반으로 귀하의 애플리케이션은 캐시 클러스터의 모든 서버에 데이터를 균등하게 배포하는 애플리케이션입니다. 이제 데이터가 균등하게 분산되므로 요청 로드도 균등하게 분산됩니다. 따라서 이는 서버 수에 따라 더 많은 읽기 및 쓰기 용량을 제공합니다. 두 대의 서버가 있는 경우 두 대의 서버가 팀으로 작업하게 됩니다. 그리고 XNUMX대에서 XNUMX대로 성장하면 읽기 및 쓰기 요청을 처리하는 서버가 더 많아집니다. 따라서 읽기 및 쓰기에 대한 확장성이 향상됩니다. 따라서 선형적으로 확장 가능한 방식으로 서버를 더 추가하면 확장성이 더 높아집니다. 서버를 더 추가하면 메모리 리소스도 풀링됩니다. 데이터가 분산되어 모든 서버의 스토리지를 함께 풀링하게 되기 때문입니다. 따라서 두 대의 서버가 있는 경우 두 대의 서버 용량을 갖게 됩니다. 세 번째나 네 번째 서버를 추가하면 그만큼 서버 용량이 늘어나게 됩니다. 따라서 전체 용량이 풀링되므로 캐시 클러스터에 서버를 더 추가하면 선형적으로 증가합니다.
읽기에 매우 좋고 쓰기에 매우 좋으며 참조 및 트랜잭션 데이터에 매우 확장성이 뛰어납니다. 이 토폴로지의 유일한 단점은 백업이 없다는 것입니다. 서버가 손실되면 해당 파티션도 손실됩니다. 따라서 그런 일이 발생하면 백엔드 데이터베이스에서 해당 데이터를 구성할 수 있는 방법이 있어야 합니다. 따라서 주요 목표가 고성능을 달성하는 것이라면, 성능 중심 애플리케이션이고 데이터베이스로 돌아갈 여유가 있다면(일반적인 경우) 데이터베이스에 의존하지 않는 것입니다. NCache 고가용성 및 데이터 안정성을 위해 이는 다른 모든 토폴로지에 비해 최고의 성능을 제공할 것입니다.
그러나 고가용성이 필요하고 알고 있는 경우 데이터 안정성 요구 사항도 충족해야 합니다. NCache, 저는 복제본 캐시 파티션이라는 더 나은 토폴로지를 가지고 있습니다. 이제 전체 아키텍처는 복제본의 향상으로 분할된 것과 똑같습니다. 여기서 각 서버에는 데이터 파티션이 있지만 모든 서버는 두 개의 파티션을 유지합니다. 클라이언트가 연결된 활성 데이터 파티션과 다른 서버의 백업 파티션. 서버 1이 활성 상태이고 해당 백업이 2에 있고 서버 2가 활성 상태이고 백업이 1에 있습니다. 그리고 동기화 또는 비동기 백업 옵션을 선택할 수 있습니다. 비동기식 복제본 파티션을 선택하면 클라이언트는 활성 파티션을 업데이트하고 클라이언트에서 해당 작업이 완료된 다음 반환됩니다. NCache 뒤에서 백업 파티션을 업데이트합니다. 동기화를 선택하면 클라이언트 애플리케이션이 활성 및 백업을 트랜잭션 작업으로 업데이트합니다. 어느 쪽이든, 동기화가 확실히 더 안정적이고 비동기가 더 빠릅니다. 하지만 어느 쪽이든, NCache 서버가 다운되면 백업 토폴로지가 활성화되고 데이터 손실이나 애플리케이션 가동 중지 시간이 표시되지 않는 방식으로 데이터 신뢰성을 처리할 수 있습니다. 오른쪽.
그럼 이제 3개의 서버로 구성된 이 토폴로지를 빠르게 보여드리겠습니다. 따라서 우리는 읽기에 대한 고성능, 쓰기에 대한 고성능, 읽기 및 쓰기에 대한 선형 확장성의 모든 이점을 얻습니다. 그 외에도 우리는 확장성, 고가용성 및 데이터 안정성 이점을 얻습니다. 서버가 다운되더라도 데이터 손실이나 애플리케이션 가동 중지 시간은 발생하지 않습니다.
Rescale과 함께 비즈니스를 가속화하는 방법에 대해 알아보세요.
나는 그것이 분명하기를 바랍니다. 이제 데모 환경으로 이동하여 이러한 캐싱 토폴로지를 구성하는 방법을 빠르게 보여주고 캐시 클러스터를 빠르게 테스트하는 방법도 보여드리겠습니다. 그동안 궁금한 점이 있으면 알려주시기 바랍니다. 우리가 보여드리는 모든 내용은 귀하의 특정 사용 사례에 대해 귀하의 환경에서 직접 세션 및 기술 지원 세션을 통해 귀하와 함께 할 수도 있다는 점을 간단히 알려드립니다. 따라서 여기서 논의하는 모든 내용은 웨비나 이후에도 팀으로서 귀하와 함께 만나서 그것이 귀하에게 어떻게 도움이 될지 보여줄 수 있어서 기쁠 것입니다.
질문에 관한 한, 마지막에 딱 맞는 질문이 있습니다. 그 중 하나는 당신이 가장 좋아하는 것 중 하나입니다.
애플리케이션 캐싱을 위해 Hazelcast를 사용하는 것에 관해 많은 논의가 있었습니다. 무엇을 NCache Hazelcast는 그렇지 않다고 제공하나요?
좋아요. 우선, 그것은 논쟁에 가깝습니다. NCache 실제로는 .NET으로 작성되었으며 .NET Core, 따라서 선호되는 플랫폼 NCache 윈도우다. 좋은 점은 NCache .NET은 물론 Windows와 Linux에서도 실행된다는 점입니다. 따라서 플랫폼 및 호환성 지원은 NCache 제공하지만 이를 달성할 수 있는 다른 제품은 없습니다. 이것이 첫 번째 부분입니다. 사용하려는 플랫폼을 고려하고 있다면 더 선호되는 선택입니다. 또 다른 차이점은 모든 사람들이 우리 회사를 찾아보라고 권하고 싶습니다. 비교 페이지, 거기에서도 아주 좋은 자료를 찾을 수 있을 거예요. 하지만 이를 빠르게 요약하자면, NCache 객체 캐싱 지원에는 다른 제품에는 전혀 없는 많은 기능이 있습니다. 예를 들어, SQL 검색에는 내부에서 사용할 수 있는 정교한 기능 세트가 있습니다. NCache. 캐시 로더와 캐시 리프레셔가 있습니다. 이는 완전히 고유한 기능입니다. NCache. .NET을 실행할 수 있는 기능을 갖춘 읽기 및 쓰기 처리기 .NET Core 서버측 코드는 완전히 독특한 기능입니다. NCache, 목록이 계속됩니다. 따라서 서버 측에서 사용자 정의할 수 있는 기능 중 일부는 다음과 같습니다. 해당 항목은 다음에서만 사용할 수 있습니다. NCache 그리고 애플리케이션 관점에서 보면 다른 제품에는 없는 기능이 많이 있습니다. 따라서 모든 사람들이 비교 페이지를 확인하도록 권장합니다. 몇 가지 비교, 기능별 비교가 게시되어 있으며 이에 대한 자세한 정보를 제공합니다.
이것은 확실히 우리가 가장 좋아하는 질문입니다. 웨비나든 기술 솔루션이든, Hazlecast일 수도 있고, Scala일 수도 있고, 그럴 수도 있습니다. Redis하지만 정말 고마워요, 론. 응, 이제 가도 좋을 것 같아. 계속 해주십시오. 확신하는.
새 클러스터형 캐시 만들기
따라서 새로운 클러스터 캐시를 생성하여 제품에 대한 간단한 데모를 제공하겠습니다. 이름을 테스트 캐시로 지정하겠습니다. 좋아요, 이 부분을 여기로 옮기겠습니다. 참아주세요. 좋아요.
그래서 우리는 네 가지 캐싱 토폴로지를 설명했습니다. 저는 복제본 캐시 파티션을 사용하겠습니다. 왜냐하면 이것이 비동기 복제 옵션이 있는 가장 권장되는 방법이기 때문입니다. 이 모든 기본값을 유지하겠습니다.
계속해서 GUI 도구를 사용하여 캐시를 구성하는 것이 얼마나 쉬운지 보여드리겠습니다. 이것은 웹 관리자이지만 PowerShell cmdlet을 사용하여 모든 것을 달성할 수 있으며 요구 사항이 있는 경우 이 배포도 자동화할 수 있습니다. 서버 XNUMX을 추가하겠습니다. NCache 설치되어 있습니다. 그런 다음 서버 2를 추가하겠습니다. 따라서 내 2개의 상자에는 NCache 2기가 규모로 설정될 예정입니다. 따라서 여기서 제 생각은 각각 2GB의 캐시 크기를 사용하여 2노드 캐시 클러스터를 만드는 것입니다. 따라서 2개의 서버로 총 XNUMX개의 공연이 이루어집니다. NCache 이미 설치되어 있습니다. 그런 다음 상자를 사용하여 이 캐시 클러스터에 연결하겠습니다.
TCP 매개변수. 일단 설정해야 하는 포트입니다. 기본값을 유지하거나 방화벽이 해당 포트에 영향을 주지 않는 포트를 지정하세요.
암호화 및 압축을 설정해야 하는 경우 이 화면입니다. 그냥 그대로 두겠습니다. 다음을 선택하세요. 퇴거는 캐시가 가득 차면 선택할 수 있는 것입니다. 한 가지 옵션은 캐시가 쓰기 작업을 전혀 수행하지 않는다는 것입니다. '캐시가 가득 찼습니다'라는 오류가 발생합니다. 다른 옵션은 제거를 설정하고 이러한 알고리즘을 기반으로 런타임 시 캐시에서 일부 항목을 제거하는 것입니다. 따라서 우선순위, 사용량에 따라 가장 최근에 사용되었거나 자주 사용된 항목이 제거될 수 있으며 해당 항목의 XNUMX%가 캐시에서 제거됩니다. 완료 시 이 캐시를 시작하고 자동 시작하므로 서버가 재부팅되거나 NCache 서버가 다시 시작되면 중지된 캐시를 다시 시작할 수 있습니다.
저는 마무리를 선택하겠습니다. 그게 전부입니다. 이것이 캐시 클러스터를 설정하는 것이 얼마나 쉬운지입니다. 잠시 후 이 캐시가 시작되는 또 다른 보기가 표시될 것입니다. 그런 다음 거기에서 몇 가지 모니터링 및 관리 세부 정보를 보여 드리겠습니다. 캐시 구성에 대한 더 자세한 비디오가 있으므로 질문이 있는 경우 지금 알려주십시오. 그렇지 않으면 해당 비디오도 참고할 수 있습니다.
모니터 클러스터를 선택하면 다른 대시보드가 열리고 캐시를 완전히 모니터링할 수 있습니다. 완전히 연결된 캐시 클러스터, 요청 처리량 카운터, 대기 시간 카운터가 표시되고 추가, 가져오기, 업데이트 카운터도 표시됩니다. 마찬가지로 CPU와 메모리 사용량, 캐시가 가득 찬 상황도 표시됩니다.
또한 클라이언트용 대시보드와 서버 측 및 클라이언트 측 대시보드를 볼 수 있는 보고서 보기도 있습니다. 현재 연결된 애플리케이션은 없지만 이 스트레스 테스트 버튼을 사용하여 일부 부하를 시뮬레이션할 수 있는 방법이 있습니다. 따라서 이 test-stress를 호출하여 캐시 클러스터에서 더미 로드나 일부 활동을 시작할 수 있습니다. 그렇게 하면 바로 하나의 클라이언트가 연결된 것을 볼 수 있으며 이 토폴로지에서는 내 데이터가 배포되어야 합니다. 따라서 일부 데이터는 서버 1에, 일부는 2에 저장됩니다. 따라서 이 클라이언트는 두 서버를 균등하게 사용하고 있습니다. 보시다시피 요청이 두 서버 모두에 들어오고 있으며 두 서버 모두에서 캐시 크기가 커지고 있습니다.
두 서버 모두에 활성 및 백업 파티션도 표시됩니다. 그리고 대기 시간 카운터를 빠르게 보여드리면 제 작업에 관한 한 밀리초 미만의 대기 시간, 심지어 마이크로초의 대기 시간입니다. 그리고 이러한 클라이언트 측 통계를 보여주는 클라이언트 대시보드를 볼 수 있고, 마찬가지로 서버 측 통계를 보여주는 보고서도 있습니다.
Ron 질문이 있습니다. 실제로 몇 가지 질문이 접수되었습니다. 그 중 하나는 다음과 같습니다.
퇴거에 대한 귀하의 권고는 무엇입니까? 그리고 최소한 퇴거를 보류하고 다음 퇴거를 보류하는 경우 퇴거가 꺼진 경우 캐시 크기를 늘리거나 줄일 수 있습니까?
확신하는. 따라서 퇴거는 사용 사례에 따라 설정해야 하는 것입니다. 데이터가 제거될 수 있는 것이라면 그렇습니다. 캐시가 가득 차면 제거 자체에서 일부 데이터가 제거됩니다. 이상적인 상황은 그렇게 할 필요가 없고 캐시가 용량 내에 있다는 것입니다. 따라서 캐시에 충분한 크기나 메모리를 제공하여 캐시가 가득 차는 일이 없도록 합니다. 하지만 그런 경우에는 가득 차는 지점에 이르게 됩니다. 이 경우 데이터가 백엔드 데이터베이스에서 항상 재구성할 수 있는 것이라면 제거를 활성화하는 것이 좋습니다. 예를 들어 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 시나리오 또는 한 데이터 센터에서 다른 데이터 센터로의 데이터 마이그레이션이 있습니다. 동쪽에서 서쪽으로 마이그레이션하거나, 하나의 애플리케이션에서 데이터가 필요하고 이를 대상 애플리케이션에서 사용해야 하는 상황에 적합합니다. 따라서 전체 캐시 데이터를 한 데이터 센터에서 다른 데이터 센터로 전송할 수 있습니다.
다른 옵션은 활성-활성입니다. 여기에서는 두 사이트가 모두 활성화되어 있으므로 사이트 XNUMX은 사이트 XNUMX로 데이터를 전송하고 사이트 XNUMX는 사이트 XNUMX로 데이터를 전송합니다. 다시 말하지만 코드 변경 옵션이 없습니다. 단지 구성일 뿐입니다. 브리지를 설정하면 두 개의 캐시를 함께 연결하고 NCache 인계받아 해당 캐시 간의 데이터 복제를 시작합니다.
또한 이는 다중 활성-활성 토폴로지로도 확장되므로 사이트가 XNUMX개만 있을 필요가 없으며 모든 사이트가 서로 데이터를 전송하는 XNUMX개, XNUMX개 또는 XNUMX개의 사이트가 될 수 있습니다. 그래서, NCache실제로 모든 사이트의 데이터를 한 번에 동기화하는 기능입니다. 그런데 이 작업은 비동기식으로 수행되므로 복제 비용이 애플리케이션 측이나 사용자 측에서 다시 발생하지 않습니다. 신청서에서 완료되었습니다. Y여기뿐만 아니라 여기에도 클라이언트 애플리케이션이 연결되어 있습니다. 이 WAN 복제로 인해 성능 저하가 발생하지 않습니다. 그것은 뒤에서 이루어졌습니다. NCache. 질문이 있으면 알려주세요. 이제 프레젠테이션과 기능 세트를 마무리하겠습니다. 잭, 궁금한 점이 있으면 알려주세요.
네, 커플이 있어요. 그리고 여러분, 아시다시피 여러분의 인내심에 진심으로 감사드립니다. 따라서 프레젠테이션 내내 궁금했던 점이 있다면 다른 질문도 던져볼 수 있는 좋은 시간입니다. 그럼 하나부터 시작해 보겠습니다.
캐시가 정상 상태로 실행되고 있는지 어떻게 확인하나요? 어떤 종류의 알림 등을 받나요? 문제가 있는지 어떻게 알 수 있나요?
확신하는. 우리는 모니터링 및 관리 도구. 따라서 시각적으로 검사하여 클러스터 상태를 확인할 수 있습니다. CPU 사용량, RAM 사용량을 확인하세요. 기준선을 알고 있다면 애플리케이션이 생성하는 요청 수와 요청의 양, 그리고 일반적인 활용도는 얼마인지 알 수 있습니다. NCache 이러한 카운터를 기반으로 모니터링 및 관리 대시보드를 사용하여 시각적으로 검사할 수 있습니다. 그런 다음 캐시 시작, 캐시 중지, 노드 조인, 탈퇴, 캐시 크기가 가득 차거나 클러스터가 비정상 상태(예: 분할 브레인)가 되는 등 모든 상황에 대한 경고가 있습니다. Windows 이벤트 로그에 로그인합니다. 그런 다음 다음에서 이메일 알림을 설정할 수도 있습니다. NCache, 귀하에게 이메일을 생성할 수도 있습니다. 따라서 이는 사전 예방적인 모니터링이 될 것이며 일부는 경고를 받을 것입니다. NCache어디로 NCache 경고를 보내고 이에 따라 조치를 취할 수 있습니다. 그리고 성능 카운터 로그와 캐시 로그 형식으로 캡처된 기록 데이터가 있습니다. 무엇이 잘못되었는지 몰랐고 다음과 같은 몇 가지 문제가 발견된 상황의 경우 NCache, 우리는 와서 참여하고 검토할 수 있습니다. NCache 이 경우에는 로그를 기록하고 캐시 상태를 평가합니다. 따라서 이와 관련하여 우리가 탐색할 수 있는 방법이 많이 있습니다.
좋은 것 같아요. 또 다른 질문은 다음과 같습니다.
최신 .NET 버전은 무엇입니까? NCache 현재 클라이언트를 지원합니까?
좋아요. 일반적으로 우리는 최신 정보를 사용하는 경향이 있습니다. .NET framework 번역, .NET Core. .NET 6이 현재 지원됩니다. NCache. .NET 6이 필수로 있어야 합니다. NCache 서버. 하지만 귀하의 애플리케이션은 어느 곳에나 있을 수 있습니다. .NET framework, 제 생각엔 3.5부터 4.0, 4.5, 심지어 4.7, 4.8 정도 될 것 같아요. 귀하의 응용 프로그램은 .NET 또는 .NET Core 뼈대. 이는 서버 측의 제한일 뿐입니다. 그리고 새로운 프레임워크 호환성(예: .NET 7)이 테스트되자마자 이미 QA 랩에서 테스트하고 있습니다. 따라서 일단 승인이 나면 이에 대한 공식 지원도 발표할 것입니다.
아주 멋진. 또 다른 질문은 다음과 같습니다.
내 캐시 서버 사이에 클러스터링된 캐시의 안전한 양은 얼마라고 생각하시나요? 내 캐시 서버 간에 15개의 클러스터 캐시를 만들 수 있나요?
좋아요. 가장 먼저, NCache 구성할 수 있는 캐시 수에 제한을 적용하지 않습니다. 실제로 제 데모 환경을 보면 캐시가 두 개 구성되어 있습니다. 따라서 필요한 만큼 만들 수 있습니다. 그러나 일반적으로 프로덕션 환경에서 10~XNUMX개의 캐시를 초과하지 않도록 권장하는 기술 권장 사항이나 용량 관련 권장 사항이 있습니다. 모든 캐시는 별도의 캐시 클러스터이기 때문입니다. 실제로 스토리지, 클러스터링, 통신을 위해 모든 리소스를 소비하게 되며 클러스터 관리 오버헤드도 있습니다. 따라서 캐시 수가 증가함에 따라 실제로 해당 환경 또는 해당 환경 내에서 용량 문제가 발생하게 됩니다. 따라서 가능하다면 XNUMX~XNUMX분 이내에 유지하는 것이 좋습니다. 캐시를 여러개 보유해야 하는 상황에서는 최대 XNUMX개까지 확장할 수 있습니다. 하지만 말씀드린 대로 또 권장 사항입니다. 이를 시행하는 실제 제한은 없습니다. 이는 우리 측의 일반적인 권장 사항입니다.
좋아요. 한 가지만 더 던져보겠습니다. 이제 세션이 끝났고, 사람들이 Docker에 다른 작업을 갖고 있다는 것도 알고 있습니다.
수 NCache DR 복제를 제공하시겠습니까?
네, 그렇습니다. 방금 논의한 WAN 복제 기능인 마지막 토폴로지는 DR, 재해 복구를 포괄합니다. 사이트는 활성 사이트의 데이터와 함께 전송될 수 있으므로 DR 사이트가 완전히 백업됩니다. 응용 프로그램 끝에서 스위치를 만들기만 하면 됩니다. 모든 데이터는 이미 백업되어 있기 때문에 하나의 데이터 센터가 완전히 다운되거나 유지 관리를 위해 직접 내려야 하는 경우에도 데이터 손실이 없습니다.
괜찮은. 나는 우리가 할 수 있는 한 많은 것을 못 박았다고 생각한다. 신사 숙녀 여러분, 이 세션 외에도 우리는 참석할 수 있다는 점을 알아두시기 바랍니다. 귀하가 이미 NCache. 당신이 처음이라면 NCache, 시험판을 설정하고 통합 애플리케이션에서 이것이 어떻게 작동하는지 안내할 수 있는 직접 세션을 제공하게 되어 기쁘게 생각합니다. 그러나 무엇보다도 문제가 있는 경우 언제든지 문의할 수 있다는 점을 알아두시기 바랍니다. 어떤 질문이라도 NCache, 또는 제품을 사용하면서 도움이 필요한 경우에도 마찬가지입니다. 앞으로 많은 새로운 내용이 나올 예정이며 새 버전도 출시될 예정입니다. 계속 관심을 갖고 더 많은 웹 세미나를 곧 준비할 예정입니다.
론에게 박수를 보냅니다. 오늘 세션에 시간을 내주셔서 정말 감사하고 다음 세션도 기대됩니다. 감사합니다, 여러분. 고마워요, 잭. 물론. 좋아요, 여러분. 모두 즐거운 하루 보내시고, 다음 웨비나에서 뵙기를 기대하겠습니다. 그리고 주의할 점은 이 웨비나가 끝난 후 모든 작업이 완료되고 정리된 후 웨비나 녹화본이 웹사이트에 업로드된다는 점입니다. 따라서 질문에 대한 답변을 얻을 기회가 없으셨다면, 저희가 언급한 내용을 다시 확인하고 싶으시면 언제든지 저희 웹사이트를 다시 방문해 다음 내용을 확인해 주시기 바랍니다. 녹화된 웹 세미나.
그럼요. 모두에게 경의를 표합니다. 당신은 좋은 것을 가지고 있습니다. 감사합니다. 안녕.