Wells Fargo SF Bay Area 기술

스케일링 .NET Core 최고의 성능을 위한 앱 및 마이크로서비스

.NET, Java 및 Node.js의 경우

이크발 칸
사장 및 기술 전도사

오늘날의 서버 애플리케이션은 많은 트랜잭션을 매우 빠르게 처리해야 합니다. 이들 중 다수는 매일 수백만 명의 사용자에게 서비스를 제공하는 웹 애플리케이션입니다. 다른 것들은 수백만 개의 모바일 앱이나 사물 인터넷(IoT) 스마트 장치를 제공하는 마이크로서비스입니다.

이러한 애플리케이션의 대부분은 이제 배포, 확장 및 관리를 단순화하고 자동화하기 위해 Kubernetes와 같은 컨테이너에 배포되고 있습니다. 그리고 선택 가능한 배포 환경이 온프레미스에서 AWS, Azure, Google Cloud 등과 같은 주요 클라우드로 이동했습니다.

데이터 스토리지 및 데이터베이스와 관련된 성능 병목 현상을 제거하고 마이크로서비스 애플리케이션의 여러 부분 간의 통신을 제거하여 오늘날의 극한 성능 요구 사항을 충족하는 애플리케이션을 개발하는 방법을 알아보세요.

살펴보기

Wells Fargo의 중요한 그룹인 San Francisco Bay Area Technology Group과 대화할 수 있는 기회를 주신 Mike에게 진심으로 감사드리며 Jason에게도 감사드립니다. Mike가 말했듯이 저는 다음 회사에서 일합니다. Alachisoft 제가 마이크와 제이슨에게 설명했던 Alachi라는 단어는 일종의 향신료 이름인 카다몬인 Elaichi인 힌디어 단어 Ellachi에서 파생된 것입니다. 그래서 우리는 몇 년 전에 회사 이름을 정하고 뭔가 독특한 것을 생각해 내고 싶었습니다. Alachisoft.

우리 제품은 실제로 NCache. 그러니까, 난 이 얘기는 안 할 거야. NCache. 오늘의 강연은 '웹 애플리케이션과 마이크로서비스를 최고의 성능으로 확장하는 방법'에 관한 것입니다. Java, .NET에서 이러한 애플리케이션을 개발하는 경우 .NET Core 또는 Node.js라면 올바른 이야기를 하신 것입니다.

확장성이란 무엇입니까?

그럼, 실제 이야기를 시작하기 전에 몇 가지 정의를 이해해 보도록 하겠습니다. 첫 번째는 확장성이란 무엇입니까? 확장성은 실제로 높은 애플리케이션 성능을 의미하지만 부하가 최고조에 달할 때 발생합니다. 따라서 애플리케이션이 단 5명의 사용자로 초고속 성능을 발휘하는 경우 5000명, 50,000명 또는 500,000명의 사용자가 있는 속도에서 동일한 초고속 성능을 갖지 않는 한 실제로 확장성이 없습니다. 귀하의 응용 프로그램이 확장 가능한 것보다 그렇게 할 수 있다면 분명히 우리는 많은 응용 프로그램이 확장 가능하기를 원하며 이에 대해 자세히 설명하겠습니다.

선형 확장성이란 무엇입니까?

다음 정의는 '선형 확장성이란 무엇인가?'입니다. 이는 애플리케이션 아키텍처 및 배포 용어에 가깝습니다. 애플리케이션이 올바르게 설계되면 선형적으로 확장 가능합니다. 즉, 초당 트랜잭션 용량을 늘려야 한다면 처리할 수 있는 사용자 수는 얼마나 됩니까? 얼마나 많은 애플리케이션 요청을 처리할 수 있나요? 이를 늘리려면 더 많은 서버를 추가하면 되며, 추가하는 모든 서버는 선형 방식으로 초당 트랜잭션 용량을 증가시킵니다.

따라서 막힘도 없고 병목 현상도 없습니다. 분명히 읽기 대 쓰기 곡선은 다르지만 둘 다 선형입니다. 그렇게 할 수 있다면 애플리케이션은 선형적으로 확장 가능하며 이는 우리가 확실히 원하는 것입니다.

비선형 확장성이란 무엇입니까?

이는 우리가 원하지 않는 것이며 병목 현상이 발생하는 방식으로 애플리케이션을 설계한 경우입니다. 따라서 애플리케이션의 로드를 늘리고 상자를 더 추가하면 무언가 포기하기 시작하고 애플리케이션이 시작됩니다. 속도를 늦추려면 실제로 때로는 충돌이 발생하기도 합니다.

따라서 우리는 애플리케이션이 비선형적으로 확장 가능하도록 설계되는 것을 원하지 않습니다.

누가 확장성을 필요로 합니까?

자, 이제 확장성이 무엇을 의미하는지 이해했으므로 다음으로 이해해야 할 것은 누가 확장성을 필요로 하는가입니다. 확장성이 필요한 애플리케이션은 무엇입니까?

웹 앱
가장 일반적인 애플리케이션은 웹 애플리케이션입니다. 이는 Wells Fargo와 같은 은행이나 Citi 그룹, Bank of America, Barclays 및 Bank of Tokyo와 같이 우리가 협력하는 다른 은행을 위한 것입니다. 이것들은 고객 지향 애플리케이션입니다. Wellsfargo.com은 소비자 금융 및 중소기업을 위한 것이며 이러한 웹 애플리케이션은 속도 저하 없이 많은 사용자를 처리할 수 있어야 합니다. 따라서 이러한 애플리케이션이 극한의 부하에서도 초고속 성능을 발휘하는 것이 매우 중요합니다.
웹 서비스 / 웹 API
두 번째는 웹 서비스, 웹 API 애플리케이션입니다. 이는 일반적으로 많은 모바일 애플리케이션이나 특정 작업을 수행하기 위해 호출하는 기타 애플리케이션에 서비스를 제공하기 위해 존재합니다. 예를 들어 Wells Fargo에 소비자 금융용 모바일 애플리케이션이 있고 해당 모바일 애플리케이션이 일부 백엔드와 통신해야 하며 오늘날의 백엔드는 웹 서비스일 가능성이 가장 높습니다. 분명히, 저는 그것을 모르지만 우리가 협력하는 다른 많은 은행들이 웹 서비스가 이 모바일 애플리케이션 요청을 처리하는 상황을 겪고 있기 때문에 그럴 것이라고 가정하고 있습니다. 그리고 그들은 똑같은 감도를 가지고 있습니다. 속도를 늦추지 않고 많은 부하를 처리할 수 있어야 합니다.
마이크로 서비스
마이크로서비스는 요즘 매우 뜨거운 유행어입니다. 이에 대해 조금 더 이야기해 보겠습니다. 하지만 본질적으로 마이크로서비스는 웹 서비스를 더 나은 새로운 방식으로 재설계하고 있다는 것입니다. 지금 이 순간에는 그렇게 말해보세요.
서버 앱
네 번째 유형의 애플리케이션은 보유하고 있는 다른 서버 앱입니다. 서버 앱이 일괄 처리를 수행하고 있을 수도 있습니다. 이는 실시간 트랜잭션을 처리할 수도 있지만 다른 범주에 속합니다. 그러나 초당 트랜잭션 처리량 요구 사항도 동일합니다.

따라서 이 네 가지 유형의 애플리케이션 중 하나를 개발하는 경우. 몇 가지 다른 방법도 있습니다. 예를 들어 실시간 기계 학습과 AI를 수행하고 있을 수 있지만 이 강연에서는 이에 대해 다루지 않겠습니다. 시간이 충분하지 않습니다. 하지만 이 네 가지 애플리케이션이 있다면 반드시 확장성이 필요하다고 가정해 보겠습니다. 그리고, 이것이 그들을 다룰 이야기입니다. 기술에 관한 한, 웹 애플리케이션은 일반적으로 Java 또는 ASP.NET, ASP로 개발됩니다..NET Core는 ASP.NET 및 Node.js의 새 버전이며 다른 세 가지 유형은 모두 Java 또는 .NET/입니다..NET Core, 마이크로서비스는 Java 또는 .NET Core 왜냐하면 그것은 새로운 기술이기 때문이다.

마이크로서비스 소개

마이크로서비스가 어떤 모습인지 모르는 분들을 위해 마이크로서비스에 대한 간략한 아키텍처 보기를 제공하고 싶었습니다. 그리고 그렇게 하시는 분들은 그냥 참아주세요. 따라서 마이크로서비스가 인기를 얻고 있는 이유는 모놀리식 애플리케이션을 바이트 크기의 마이크로서비스로 분해할 수 있고 모든 마이크로서비스가 다른 마이크로서비스와 분리될 수 있기 때문입니다. 그리고, 그 디커플링은 그들이 서로를 부르지 않는다는 것을 의미합니다. 그들은 일반적으로 논리적인 데이터베이스를 가지고 있습니다. 물리적 데이터베이스를 분리할 필요는 없지만, 적어도 논리적으로는 대개 자체 데이터베이스를 갖고 있습니다. 일부 마이크로서비스는 다음을 사용할 수 있습니다. NoSQL database, MongoDB 또는 다른 것. 그 중 일부는 관계형 데이터베이스, SQL Server, Oracle, DB2를 사용합니다. 그 중 일부는 레거시 메인프레임 데이터로 이동될 수 있습니다.

따라서 디커플링을 위해서는 일종의 이벤트 버스를 통해 서로 대화해야 합니다. 이것이 바로 오른쪽에 있는 파이프입니다. 또한 API 게이트웨이를 통해 모바일 애플리케이션, 단일 페이지 웹 애플리케이션 또는 Java, .NET 또는 Node.js의 표준 MVC 웹 애플리케이션에서 호출됩니다. 이는 마이크로서비스가 무엇인지에 대한 좋은 시각입니다. 그리고 전통적으로 다른 애플리케이션에서 발생했던 것과 동일한 확장성 문제가 어떻게 발생하는지 살펴보겠습니다.

앱 배포 환경

제가 이야기할 내용에 대한 맥락을 설명하고 싶었기 때문에 빠르게 다루고 싶었던 또 다른 사항은 우리가 수년에 걸쳐 해결해야 했던 다양한 유형의 배포 환경입니다. 저는 15년 넘게 이 일을 해왔고 가장 오랫동안 이 일을 온프레미스 데이터센터에서 완벽하게 제어할 수 있었습니다. 지금도 우리와 협력하는 많은 은행은 여전히 자체 데이터 센터를 운영하고 있습니다. 그러나 거의 모든 사람이 클라우드로 전환하고 있거나 최소한 클라우드로 전환할 계획을 갖고 있습니다. 일부 중소기업은 퍼블릭 클라우드로 전환합니다. 특히 많은 대기업, 특히 금융 서비스와 은행은 일반적으로 프라이빗 클라우드 배포를 선호합니다. 실제로 우리와 협력하는 일부 은행에서는 Pivotal Cloud Foundry 또는 Red Hat Open Stack 유형의 프레임워크에서 프라이빗 클라우드를 선호합니다. 이를 통해 프라이빗 클라우드 환경을 완벽하게 제어할 수 있습니다. 프라이빗 클라우드가 존재합니다. 공용 클라우드 내부에 임대 공간으로 존재하든, 현재 보유하고 있는 데이터 센터 위에 있든, 아니면 다른 무엇이든 자유를 제공합니다. 그러나 어느 쪽이든 그들은 클라우드로 가고 있습니다.

Kubernetes는 나중에 다루겠지만 마이크로서비스와 마찬가지로 실제로 또 다른 전문 용어가 되고 있습니다. 왜냐하면 이는 Dev Ops를 단순화하는 매우 강력한 기술이기 때문입니다. 또한 환경 이식성을 제공합니다. 따라서 한 번 수행하는 작업은 모든 환경에서 작동합니다. 온프레미스에 있든, 클라우드에 있든, 동일한 배포 환경이 작동합니다. 그리고 Kubernetes에서도 우리와 협력하는 많은 은행이 Tanzu Kubernetes 또는 Red Hat OpenShift와 같은 클라우드 플랫폼 중립적인 제품을 선호하고 있습니다. 따라서 나중에 우리가 이야기하고 있는 확장성 주제의 일부로 이러한 개념을 살펴보겠습니다.

확장성 문제

자, 그럼 우리가 이야기했던 실제 문제로 돌아가 보겠습니다. 즉, 우리가 해결해야 할 확장성 문제가 있습니까? 예, 그렇습니다. 그러나 애플리케이션 계층에는 없습니다. 애플리케이션 아키텍처에는 없습니다. 병목 현상이 발생하는 것은 데이터 저장소에 있습니다. 그리고 데이터 스토리지라는 단어는 관계형 데이터베이스나 메인프레임 레거시 데이터베이스 또는 데이터를 의미합니다. NoSQL database즉, 동일한 유형의 병목 현상이 없으며 점점 더 많이 사용되고 있습니다. 그러나 안타깝게도 이러한 전체 확장성 문제에 대한 답이 될 수는 없습니다.

확장성 병목 현상

이 그림을 보면 관계형 데이터베이스와 레거시 메인프레임이 병목 현상을 일으키는 이유는 애플리케이션 계층과 달리 더 많은 서버를 추가할 수 있기 때문이라는 것을 알 수 있습니다. 다중 서버 부하 분산 환경에 배포되는 웹 앱이 있고 동일한 방식의 웹 서비스와 마이크로서비스도 있다고 가정해 보겠습니다.

다시 한번 말하지만, 지금은 그들의 환경에 대해 이야기하는 것이 아니라 여러 서버가 있다는 논리적 분석을 제공하는 것뿐입니다. 따라서 더 많은 서버를 추가할 수 있다는 것은 애플리케이션 계층이 병목 현상을 일으키지 않는다는 것을 의미합니다. 그러나 해당 계층의 크기가 커지면 데이터 스토리지의 병목 현상이 점점 더 심해집니다. 그리고 비록 NoSQL 병목 현상이 발생하지 않지만 모든 문제에 대한 답이 아닌 이유는 다음과 같습니다. NoSQL 데이터를 관계형 및 메인프레임에서 멀리 이동해야 합니다. 이상적인 세상에서는 큰 문제가 아니더라도 큰 문제입니다. 대부분의 기업은 관계형에서 완전히 벗어날 수 없습니다. 그들은 메인프레임에서 완전히 벗어날 수 없습니다. 그들은 사용할 수 있습니다 NoSQL 일부 데이터의 조합이 NoSQL database 하지만 많은 데이터가 관계형 데이터베이스와 메인프레임에 계속 남아 있어야 합니다. 그리고 이것이 사실이라면, 우리가 생각해 내야 하는 확장성 솔루션이 무엇이든 성공할 수 없다는 의미입니다. NoSQL database. 가 아닌 다른 것이어야 합니다. NoSQL database. 관계형 데이터베이스 및 레거시 메인프레임 데이터베이스와 함께 작동해야 합니다.

마이크로서비스 병목 현상

제가 아키텍처를 보여드린 것처럼 마이크로서비스는 내장된 확장성을 제공하지 않습니다. 심지어 웹 서비스나 웹 애플리케이션과 동일한 성능 병목 현상이 발생합니다. 그들이 사용하지 않는 한 NoSQL database물론 그들은 그렇게 하지 않을 것이지만 레거시 데이터를 위해 메인프레임과 대화해야 하고 그들 중 다수는 계속해서 관계형 데이터베이스와 대화할 것입니다. 그리고 서로 통신하기 위해 존재하는 이벤트 버스로 인해 추가적인 병목 현상이 발생할 가능성이 있습니다.

트랜잭션 환경이 매우 높은 경우 이벤트 버스도 병목 현상이 될 수 있습니다. 이벤트 버스에 적합한 솔루션을 마련하지 못한 경우.

확장성 솔루션

다행히도 이에 대한 해결책이 있는데, 바로 인메모리 분산 캐시입니다. 그리고, 그 이유에 대해 알아보겠습니다. 하지만 몇 가지 주장을 해보겠습니다. 솔루션인 이유는 매우 빠르기 때문입니다. 선형 확장성과 고가용성을 제공합니다. 이것이 확장성 문제에 대한 솔루션인 세 가지 이유입니다. 그리고 Wells Fargo와 같은 대기업에서는 실제로 여러 애플리케이션에서 데이터 공유 플랫폼으로 사용할 수 있는 인메모리 분산 캐시를 사용하면 얻을 수 있는 추가 이점도 있습니다. 이에 대해 좀 더 자세히 설명하겠지만 이는 일종의 부가적인 이점이거나 이것을 사용하는 데 따른 부수적인 이점과 같습니다. 가장 큰 이유는 확장성입니다.

메모리 내 분산 캐시

그렇다면 인메모리 분산 캐시는 어떻게 이 답을 제공할까요? 그 문제에 대한 해결책은 무엇입니까? 솔루션인 이유는 인메모리 분산 캐시가 우선 메모리에 있기 때문에 매우 빠르기 때문입니다. 인 메모리는 심지어보다 빠릅니다. NoSQL database에스. 그리고 두 번째로 배포됩니다. 메모리 내 분산 캐시는 실제로 여러 개의 저비용 캐시 서버 모음입니다. 그리고 각 캐시 서버는 데이터베이스 형태의 서버가 아닙니다. 이는 웹 서버와 비슷하며 코어는 4~8개, 때로는 그 이상입니다. 16~32GB RAM. 각 애플리케이션에 대해 원하는 만큼 이를 확보하고 이를 애플리케이션을 위한 초고속 및 확장성이 뛰어난 인프라로 생성하세요. 웹 앱, 웹 서비스, 마이크로 서비스 및 데이터베이스와 함께 여기에 표시되는 애플리케이션 계층이 있으면 관계형인지 레거시인지 또는 데이터베이스인지에 관계없이 NoSQL. 조차 NoSQL, 내가 말했듯이 메모리 내 분산 캐시만큼 빠르지는 않습니다.

그렇다면 메모리 내 분산 캐시는 어떤 역할을 할까요? 이는 이러한 캐시 서버의 클러스터를 생성하고 해당 클러스터는 이러한 모든 캐시 서버의 메모리, CPU 및 네트워크 카드 용량까지 함께 풀링합니다. 애플리케이션 계층과 마찬가지로 NoSQL database, 비록 그보다 훨씬 더 쉽지만 NoSQL database, 트랜잭션 용량이 증가함에 따라 캐시 서버를 계속 추가하면 됩니다. 이제 갑자기 중복이 생겼고, 게다가 메모리에 있기 때문에 스마트한 방식으로 데이터 복제를 제공해야 합니다. 캐시 서버가 하나라도 있는지 확인하기 위해 잠시 살펴보겠습니다. 다운되어도 데이터는 손실되지 않습니다. 그렇지 않으면 메모리 내 저장소는 가치가 없기 때문입니다. 서버 하나가 다운되어 기가바이트, 기가바이트의 데이터가 손실된다면 그다지 매력적인 솔루션이 아니기 때문입니다. 따라서 인메모리 분산 캐시는 데이터를 분산할 뿐만 아니라 성능 저하 없이 스마트한 방식으로 복제합니다. 그리고 확장성.

따라서 인프라의 일부로 인메모리 분산 캐시를 보유함으로써 이제 갑자기 병목 현상을 제거할 수 있는 능력이 생겼고, 데이터 읽기의 80%가 분산 캐시로 이동하게 됩니다. 데이터베이스가 여전히 마스터 데이터 원본이기 때문에 20%는 실제 데이터베이스에 전달됩니다. 따라서 해당 데이터에 대한 모든 업데이트는 레거시 메인프레임의 관계형 데이터베이스 또는 NoSQL. 그러나 때로는 읽기 또는 쓰기 트래픽의 80%, 90% 이상이 분산 캐시로 제한될 수 있습니다. 그리고 갑자기 애플리케이션에서 더 이상 병목 현상이 느껴지지 않습니다.

따라서 이는 이제 애플리케이션을 확장할 수 있으려면 인메모리 분산 캐시가 있어야 하는 필수 애플리케이션 아키텍처 패턴과 같습니다.

분산 캐시 확장성

이것들은 약간이다. 확장성 벤치마크 수 NCache여기서는 4~5개의 노드만으로 초당 2만 개의 작업을 수행할 수 있음을 알 수 있습니다. 그리고 선형 규모이므로 4백만으로 가려면 노드를 5개 더 추가하면 됩니다. 그리고 아시다시피 초당 2만 개의 작업은 매우 높은 트랜잭션 로드입니다. 즉, 대부분의 애플리케이션이 해당 로드를 유지할 수 있다면 애플리케이션의 90%가 해당 유형의 로드 내에서 만족할 것입니다. 어쩌면 일부는 그렇지 않을 수도 있고 더 많은 것이 필요할 수도 있습니다. 그리고 더 많은 서버가 필요할 경우 서버를 더 추가하면 됩니다.

분산 캐시의 일반적인 사용

따라서 지금쯤이면 인메모리 분산 캐시가 애플리케이션 아키텍처 측면에서 훌륭한 아이디어라는 점을 확신하게 되셨기를 바랍니다. 그렇다면 그 다음 또는 그 후에 마음에 떠오르는 첫 번째 질문은 애플리케이션 개발자로서 이를 어떻게 활용합니까?입니다. 왜냐하면 이것들은 모두 애플리케이션에 관한 것이기 때문입니다. 분산 캐시를 활용하려면 어떻게 해야 합니까?

앱 데이터 캐싱
따라서 분산 캐시를 사용할 수 있는 세 가지 일반적인 방법이 있습니다. 첫 번째는 앱 데이터 캐싱. 이것이 제가 방금 이야기한 가장 일반적인 방법입니다. 즉, 데이터베이스에서 읽는 데이터가 무엇이든 캐시에 보관하므로 다음번에는 캐시에서 읽기만 하면 됩니다. 매우 간단합니다. 그리고 무엇을 업데이트하든 캐시와 데이터베이스가 모두 업데이트됩니다.

이제 즉시 이해해야 할 한 가지는 애플리케이션 데이터 캐싱에는 존재하는 고유한 문제가 있다는 것입니다. 즉, 이제 데이터가 두 위치에 존재한다는 것입니다. 하나는 마스터 데이터베이스이고 관계형 데이터베이스일 수도 있고 NoSQL 또는 레거시 메인프레임이고 그 중 하나는 캐시입니다. 따라서 가장 먼저 잘못될 수 있는 것은 캐시가 오래될 수 있다는 것입니다. 따라서 데이터를 업데이트했는데, 캐시와 통신하지 않는 애플리케이션이 있고 데이터베이스의 데이터를 업데이트하면 갑자기 캐시에 오래된 데이터가 생기고 오래된 데이터는 정말 나빠집니다. 오래된 데이터가 매우 나쁘다는 사실은 은행이 누구보다 잘 알고 있을 것입니다. 일부 오래된 데이터는 괜찮지만 오래된 데이터가 많으면 매우 나쁩니다. 따라서 이것이 바로 대부분의 사람들이 캐싱에 대해 생각할 때 무작정 반응하는 이유입니다. 저는 읽기 전용 데이터만 캐시할 것이며 절대 변경되지 않습니다. 또는 적어도 내 애플리케이션의 수명 동안 또는 기타 다른 방식으로 캐시할 것입니다. , 아주 오랜 시간이 지나도 변하지 않을 것입니다. 음, 그것이 전체 데이터의 약 10%, 15%에 불과하다면. 10%, 15%만 캐시하려는 경우 실제로 분산 캐시를 활용하지 못하는 것입니다. 5초마다 변경되는 데이터를 캐시할 수 있어야 합니다. 아니면 그보다 더 빨리. 왜냐하면 그 5~10초 동안이라도 10번은 읽을 수 있기 때문입니다. 그리고 여기에 애플리케이션이 매일 처리하는 수백만 개의 트랜잭션을 곱하면 데이터베이스에 대한 많은 이동을 절약하고 확장성을 얻을 수 있습니다.

따라서 이 문제를 해결하지 않는 분산 캐시는 캐시가 오래되어서는 안 되며 항상 신선해야 한다는 이 과제를 건너뛰면 완전히 사용하지 못하게 될 것입니다. 따라서 가장 먼저 명심해야 할 사항은 다음과 같습니다.
웹 앱별 캐싱
두 번째 사용 사례는 웹 애플리케이션입니다. 그리고 웹 애플리케이션의 가장 일반적인 용도는 세션. Java, ASP.NET, ASP 보유 여부.NET Core 또는 Node.js를 사용하는 경우 모두 빠르고 확장 가능한 저장소에 세션을 저장하려고 합니다. 그리고 분산 캐시는 다른 어떤 것보다 훨씬 더 나은 저장소입니다. Java든 .NET이든 Node.js가 아니든 마찬가지입니다. 그리고 페이지가 있는 것과 같은 다른 것들이 있습니다. 출력 캐싱. 라이브 웹 애플리케이션도 있습니다. .NET의 경우 이를 호출합니다. 시그널R, 분산 캐시를 플랫폼으로 사용하여 이벤트를 공유할 수 있습니다.

그러나 웹 애플리케이션이 앱 데이터 캐싱이 아닌 경우 웹 애플리케이션이 해당 데이터를 분산 캐시에 저장할 때 해결해야 할 다른 유형의 문제가 있습니다. 즉, 이제 해당 데이터의 복사본이 있는 데이터베이스가 없습니다. 캐시는 마스터 저장소입니다. 그리고 캐시가 마스터 저장소라는 것은 캐시 서버가 다운되면 해당 데이터가 손실된다는 것을 의미합니다. 이는 허용되지 않습니다. 단지 캐시 서버나 웹 서버가 다운되었기 때문에 사용자 세션을 잃고 싶지는 않을 것입니다. 고가용성을 원한다면 캐시에 해당 데이터를 여러 서버에 지능적으로 복제하는 기능이 있어야 합니다. 따라서 캐시 서버가 다운되더라도 해당 데이터가 손실되지 않습니다. 그러니까 그게 중요한 부분이에요. 앱 데이터 캐싱에는 다른 문제가 있습니다. 웹 애플리케이션별 캐싱에는 다른 문제가 있습니다.
게시/구독 메시징, CQ 및 이벤트
세 번째 사용 사례는 사용할 수 있다는 것인데, 이는 많은 사람들이 전혀 모르는 것입니다. 분산 캐시를 다음과 같은 용도로 사용할 수 있다는 것입니다. 게시/구독 메시징 플랫폼과 이벤트. 우리는 이야기를 나눴고 마이크로서비스라도 Pub/Sub를 수행해야 한다는 점을 보여 드리겠습니다. 따라서 분산 캐시를 애플리케이션 데이터 캐싱에 사용하는 것 외에 Pub/Sub 메시징 플랫폼으로 사용하는 경우 Pub/Sub 메시징이 병목 현상을 일으키지 않습니다.

다양한 메시징 기능을 갖춘 다른 메시징 제품도 많이 있습니다. 분산 캐시는 이러한 모든 기능과 일치하지 않지만 분산 캐시의 기능은 이 마이크로서비스 또는 웹 애플리케이션 환경 내에서 공유되어야 하는 메시지에 대해 매우 빠른 인메모리 메시징 플랫폼을 생성한다는 것입니다. 따라서 몇 시간 동안 해당 메시지를 보관할 필요가 없는 훨씬 간단한 환경입니다. 아마도 앞으로 몇 밀리초 내에 공유되어야 할 것입니다. 그러나 트랜잭션 활동이 너무 많아 진정한 메모리 내 분산 아키텍처가 없으면 메시징 플랫폼 자체가 병목 현상을 겪게 됩니다. 따라서 이제 데이터 저장소에 병목 현상이 발생하는 것 외에도 메시징 플랫폼에도 병목 현상이 발생합니다. 그러니 명심하세요. 그리고 메시징 플랫폼에는 웹 애플리케이션 특정 캐싱과 동일한 문제가 있습니다. 즉, 일반적으로 메시지로 보관되는 것이 무엇이든 데이터베이스에 백업 복사본이 없다는 것입니다. 글쎄, 그것은 데이터베이스에 이미 존재하는 일부 데이터의 변환된 버전일 수 있으며 이를 다시 만들 수는 있지만 원하지 않을 수도 있습니다. 따라서 해당 데이터를 잃고 싶지 않고 해당 메시지를 잃고 싶지도 않습니다. 따라서 좋은 분산 캐시는 빠르고 확장 가능해야 할 뿐만 아니라 웹 특정 캐싱뿐만 아니라 Pub/Sub 메시징을 위한 지능형 복제도 제공해야 합니다.

Kubernetes 및 분산 캐싱

웹 애플리케이션과 마이크로서비스를 모두 실행하고 분산 캐시를 사용하는 Kubernetes 환경을 구축하는 방법은 다음과 같습니다. 따라서 이 녹색 영역은 Kubernetes 클러스터입니다. 그리고 Kubernetes에는 클러스터라는 개념이 있습니다. 각 클러스터 내에는 여러 배포가 있습니다. 따라서 이 세 개의 상자 직사각형은 각각 배포입니다. 따라서 웹 앱 배포, 두 개의 마이크로서비스 배포, 분산 캐시 배포, 마이크로 서비스용 API 게이트웨이가 있습니다.

Kubernetes의 작동 방식에 대해 자세히 설명하지는 않겠지만 기본적으로 이와 같은 환경에서는 마이크로서비스가 애플리케이션 데이터 캐싱과 Pub/Sub 메시징 모두에 분산 캐시를 사용합니다. 반면 웹 애플리케이션은 애플리케이션 데이터 캐싱 및 웹 세션에 분산 캐시를 사용합니다.

대부분의 웹 애플리케이션에는 게시/구독 메시징 왜냐하면 Pub/Sub 메시징이 서로 통신하려면 일반적으로 일종의 안정적인 서버 프로세스가 필요하기 때문입니다. 그러나 어쨌든 그들 중 일부는 그럴 수도 있지만 대부분은 그렇지 않습니다. 하지만 애플리케이션 데이터 캐싱을 위해 마련한 것과 동일한 캐싱 인프라를 웹 세션에 사용할 수 있고 Pub/Sub 메시징에도 사용할 수 있습니다. 이 경우 보시다시피 Pod로서의 Docker 인스턴스입니다. . Windows 또는 Linux 상자일 수 있으며, 원하는 방식에 대한 선호도에 따라 달라집니다. 요즘 대부분의 은행은 모든 것을 Linux로 옮기고 있으며 심지어 .NET Core 리눅스를 지원하기 때문이죠. 이제 Linux에서는 .NET 및 Java 애플리케이션은 물론 Node.js도 사용할 수 있습니다.

따라서 이는 서비스 및 웹 애플리케이션과 분산 캐시 호스팅 모두를 위한 Kubernetes 환경의 모습입니다. 여기서 제가 지적하고 싶은 것 중 하나는 쿠버네티스에 살기 위한 분산 캐시는 쿠버네티스와 호환되어야 한다는 것입니다. Kubernetes Operator라고 부르는 기능을 구현해야 합니다. NCache 가지고 있습니다. 따라서 어떤 분산 캐시를 보든 Kubernetes와 호환되는지 확인하세요.

앱 데이터 캐싱 개요(API)

그래서 이것은 나의 유일한 코딩 슬라이드입니다. 나는 이것보다 더 이상 코딩을 다루지 않을 것입니다. 이것의 전체적인 아이디어는 애플리케이션 데이터 캐싱이 개발 중인 모든 애플리케이션이 활용해야 하는 분산 캐시의 주요 사용 사례라는 것입니다. 그것이 웹 애플리케이션이든, 웹 서비스이든, 마이크로서비스이든 상관없습니다. 그리고 이것이 분산 캐시가 가지고 있는 매우 간단한 API라는 것을 알 수 있습니다.

캐시 연결

ICache cache = CacheManager.GetCache(“myDistributedCache”);
cache.Dispose();

데이터를 가져 오는 중

Employee employee = cache.Get<Employee>("Employee:1000"); 
bool isPresent = cache.Contains("Employee:1000");

데이터 쓰기

cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

캐시 핸들이 있고, 캐시.Get, 캐시.포함을 수행합니다. 일반적으로 문자열인 키가 있고, 값을 반환받으면 값은 개체, .NET 개체, Java 개체, JSON 문서일 수 있습니다. Node.js는 분명히 JSON에서 작동합니다. 그러나 .NET 및 Java 애플리케이션이 해당 개체나 데이터를 JSON으로 저장하도록 할 수도 있습니다. 그리고 실제로 이를 데이터 공유 플랫폼으로 사용할 수도 있습니다. 예를 들어 Java 고객 객체인 고객 객체를 저장하는 Java 애플리케이션이 있기 때문입니다. 분산 캐시에 저장되면 다음과 같이 해보자. NCache JSON 문서로 변환된 다음 Node.js나 .NET 애플리케이션 또는 .NET Core 애플리케이션이 그것을 가져오려고 하면 그것을 얻습니다… .NET Core 애플리케이션은 이를 .NET 고객 개체 또는 JSON 문서로 가져오고 Node.js는 어쨌든 JSON 문서를 가져옵니다. 따라서 단순함이 존재합니다. 가져오기, 추가, 삽입, 제거는 최대한 간단합니다. 따라서 분산 캐시를 사용하면 학습 곡선이 매우 빠릅니다.

앱 데이터 캐싱의 기능

분산 캐시를 사용하려는 경우 가장 큰 사용 사례는 앱 데이터 캐싱이기 때문에 앱 데이터 캐싱의 몇 가지 핵심 영역을 빠르게 살펴보겠습니다. 그리고, 꼭 알아두셔야 할 점은 무엇인가요? 첫 번째는 제가 언급한 것처럼 두 개의 데이터 복사본이 데이터베이스에 있고 다른 하나는 캐시에 있는데 어떻게 캐시를 최신 상태로 유지합니까?

만료(절대 및 슬라이딩)
첫 번째는 다음과 같은 기능입니다. 만료 거의 모든 분산 캐시에는 하나의 기능이 있으며 일반적으로 절대 만료. 어떤 사람들은 이를 TTL 또는 TTL(Time to Live) 만료라고 부릅니다. 다른 만료일은 다음과 같습니다. 슬라이딩 만료 이는 앱 데이터 캐싱을 위한 것이 아니며, 특정 시간 동안 아무도 개체를 사용하지 않을 경우 개체를 만료하려는 상황의 세션 유형에 더 적합합니다. 그러나 절대 만료는 내가 캐싱하고 있는 이 데이터가 다음 24분 동안이나 다음 XNUMX시간 또는 XNUMX시간 동안 변경되지 않을 것임을 알고 있다는 것을 캐시에 말하는 것입니다. 데이터의 성격이 무엇이든 지정할 수 있습니다. 그리고 해당 시간이 지나면 캐시가 자동으로 만료됩니다. 따라서 애플리케이션은 이를 추가하고 계속 진행할 수 있습니다. 애플리케이션은 모든 데이터를 추적하는 것에 대해 걱정할 필요가 없습니다. 따라서 이는 모든 캐시가 가져야 하는 최소값이며 대부분이 캐시를 갖고 있습니다. 그러나 만료의 문제 또는 제한은 정보에 기초한 추측만을 하고 있다는 것입니다. 어떤 경우에는 데이터가 자주 변경되지 않기 때문에 괜찮지만 앞서 언급했듯이 실제 이점은 트랜잭션 데이터를 캐싱하는 것입니다. 따라서 거래 데이터에서 더 정확한 정보를 원합니다.
데이터베이스와 캐시 동기화
분산 캐시가 가져야 할 또 다른 특징은 데이터베이스를 어느 정도 인식해야 캐시된 데이터와 자체적으로 동기화할 수 있다는 것입니다. 해당 데이터, 데이터베이스의 해당 데이터가 변경되면 캐시는 캐시에서 해당 항목을 자동으로 제거하여 다음에 애플리케이션이 해당 항목을 원할 때 캐시에서 해당 항목을 찾지 못하고 강제로 데이터베이스에서 가져오거나 캐시가 복사본을 다시 로드하도록 해야 합니다. 그것. 그리고 다시 로드는 제가 이야기할 또 다른 기능을 통해서만 가능합니다. 연속 읽기 및 연속 쓰기. 그러나 캐시를 데이터베이스와 동기화할 수 있다면.

따라서 동기화할 수 있는 방법에는 두 가지가 있습니다. 하나는 이벤트 기반입니다. 따라서 요즘 대부분의 데이터베이스에는 데이터 변경 이벤트가 있습니다. SQL Server에는 있고, Oracle에는 있고, MongoDB, Cosmos DB에는 모두 있습니다. Cosmos DB는 변경 피드라고 부르고, MongoDB는 변경 스트림이라고 부르고, SQL Server는 SQL 종속성, Oracle이라고 부르고, 데이터베이스 알림 등이라고 부릅니다.

따라서 분산 캐시가 데이터베이스의 이러한 기능을 활용하면 캐시된 항목과 데이터베이스 레코드 세트 간에 일종의 관계를 생성할 수 있습니다. 따라서 해당 데이터가 변경되면 데이터베이스는 분산 캐시에 이 데이터가 변경되었음을 알리므로 해당 데이터의 사본을 관리하시기 바랍니다. 따라서 캐시를 제거하거나 데이터베이스에서 다시 로드할 수 있으며 데이터베이스에 기능으로 이벤트가 없으면 폴링을 다른 메커니즘으로 사용할 수 있습니다.
관계형 데이터 처리
세 번째로 하고 싶은 일은 관계형 데이터를 캐싱하는 경우 일대다, 일대일 관계와 관련된 데이터 무결성 문제가 있다는 것입니다. 따라서 캐시에 이 항목, 이 고객 개체가 있고 이 주문 개체가 있다고 말할 수 있다면 둘은 서로 관련되어 있습니다. 따라서 애플리케이션이 고객 개체를 제거하면 캐시는 자동으로 모든 주문을 제거합니다. 따라서 그렇게 하면 캐시에 매달린 참조라고 부르는 것이 없습니다. 그렇게 할 수 있다면 캐시는 다시 항상 최신 상태가 될 것입니다.
SQL 쿼리
따라서 이러한 기능을 사용하면 캐시에 최소한 처음 두 가지 기능이 있으면 모든 유형의 데이터를 캐시에 넣을 수 있다는 확신을 갖게 됩니다. 그리고 일단 확신이 생기면 캐시에 많은 데이터를 넣기 시작할 것입니다. 그리고 캐시에 많은 양의 데이터를 넣으면 또 다른 문제가 발생합니다. 이제 키를 기반으로 데이터를 찾는 것만으로는 충분하지 않습니다. 따라서 데이터베이스에서 찾을 수 있는 것처럼 데이터(SQL 쿼리)를 찾을 수 있기를 원합니다. .NET의 경우, .NET Core LINQ도 있습니다. 즉, 객체 속성을 기반으로 데이터를 검색할 수 있다면. 도시가 샌프란시스코인 고객 개체를 모두 나에게 줘라고 말할 수 있습니다. 그러면 데이터베이스처럼 작동합니다. 검색할 수 있는 참조 데이터도 있습니다. 검색할 수 있는 조회 데이터가 많이 있습니다. 그래서 데이터를 검색할 수 있게 된다면 이제 캐시가 더욱 친숙해집니다. 점점 더 많은 데이터를 찾을 수 있기 때문에 더 많은 데이터를 캐싱할 수 있다는 자신감을 갖게 됩니다. 왜냐하면 SQL 쿼리를 수행할 수 없으면 애플리케이션이 갑자기 매우 복잡해지기 때문입니다. 저장한 모든 키를 추적해야 합니다.
그룹, 태그, 명명된 태그
또 다른 측면은 동일한 관계에 있으며 관련 데이터를 그룹화하여 한 번에 가져올 수 있기를 원한다는 것입니다. 따라서 다양한 분산 캐시는 그룹, 태그 및 이름 태그 개념을 제공하여 이 하나의 태그와 일치하는 모든 것을 얻을 수 있습니다. 아니면 캐시에서 모두 삭제하거나 캐시에서 가져오세요. 따라서 키 외에 데이터를 빠르게 찾는 능력은 점점 더 많은 데이터를 캐시하기 시작하면 매우 중요해집니다.
Read-through 및 Write-through
이것이 바로 제가 말했던 기능, 연속 읽기, 연속 쓰기 기능입니다. 이 기능의 중요성은... 먼저 이것이 무엇인지 설명하겠습니다. 따라서 분산 캐시가 있을 때 이 기능이 없으면 애플리케이션이 모든 데이터를 읽고 이를 캐시에 저장하고 데이터베이스도 업데이트합니다. 그러나 캐시를 여러 애플리케이션과 점점 더 관련되게 만들면 이제 캐시는… 캐시가 더 자급자족할 수 있으면 스스로 관리할 수 있게 되어 애플리케이션이 단순화됩니다. 그런 다음 해당 캐시를 마스터 데이터 소스가 무엇이든 메모리 내 표현으로 처리하는 여러 응용 프로그램이 있습니다. 제가 말했듯이 메인프레임, 관계형 또는 NoSQL. 따라서 그들은 이 메모리 내 분산 캐시를 키 값 저장소로 사용합니다. 이는 매우 간단하고 매우 간단하며 모두 메모리에 있으므로 매우 빠르며 분산 캐시는 데이터를 읽을 수 없는 경우 데이터를 읽을 수 있습니다. -through는 분산 캐시에 등록되는 코드입니다. 따라서 분산 캐시는 코드를 호출하여 데이터베이스로 이동하여 해당 항목을 읽습니다. 따라서 캐시를 수행한다고 가정해 보겠습니다. 특정 키를 가져오고 해당 항목이 캐시에 없으면 캐시는 읽기를 호출하여 데이터베이스에서 해당 항목을 가져옵니다.
후기 쓰기
같은 방법으로 캐시를 사용하여 캐시의 데이터를 업데이트할 뿐만 아니라 데이터베이스에서도 캐시를 업데이트할 수 있습니다. 그리고 write-behind는 캐시 업데이트가 동기적으로 발생하지만 데이터베이스 업데이트는 비동기적으로 발생하는 고급 버전입니다.
캐시 로더/리프레셔
캐시 로더와 새로 고침은 캐시를 준비할 수 있는 또 다른 방법입니다. 캐시를 시작하면 항상 가지고 있을 모든 데이터로 캐시를 채웁니다. 따라서 이렇게 하면 매번 read-through를 호출할 필요가 없습니다. 따라서 수백만 개의 개체로 해당 캐시를 로드하면 캐시 새로 고침은 사용자가 지정한 비즈니스 규칙에 따라 해당 데이터의 특정 하위 집합을 주기적으로 업데이트할 수 있는 또 다른 기능입니다. 비즈니스 논리에 따라 이벤트 기반일 수도 있고, 시간 기반일 수도 있습니다. 알겠습니다. 가서 마스터 데이터 원본에서 최신 데이터 복사본을 가져오라고 말할 수 있습니다.

이제 이러한 많은 상황에서 데이터가 비즈니스에 그다지 중요하지 않은 경우 너무 늦거나 너무 지연되지 않는다면 오래된 복사본을 가지고 있어도 괜찮은 시나리오가 있습니다. 하지만 이 세 가지 기능, 즉 연속 읽기, 연속 쓰기 및 캐시 로더/새로 고침 기능을 모두 갖추면 갑자기 매우 스마트한 캐시를 갖게 됩니다. 여러 데이터 소스에 들어가서 로드할 수 있으며 이미 언급한 것처럼 애플리케이션 내뿐만 아니라 여러 애플리케이션에서 자체적으로 사용할 수 있습니다.

앞서 언급했듯이 여러 응용 프로그램이 있다는 것은 부수적인 이점입니다. 인메모리 분산 캐시 사용의 추가적인 이점. 그럼 그게 무슨 뜻인가요? 이는 이제 분산 캐시가 여러 애플리케이션에 걸쳐 공통 인프라가 된다는 것을 의미합니다. 따라서 애플리케이션이 서로 데이터를 공유해야 하는 경우 서로 호출하거나 데이터베이스로 이동하는 대신 매우 빠르고 확장성이 뛰어난 메모리에 있는 매우 이해하기 쉬운 키 값 저장소에 저장하면 됩니다. 그리고 내가 언급한 모든 기능(읽기, 쓰기, 캐시 로더, 새로 고침, 기타 모든 SQL 검색) 때문에 이 모든 기능은 데이터베이스와 유사하지만 마스터 데이터 소스는 아닙니다.

따라서 데이터 공유 플랫폼에서는 캐시가 마스터가 아닙니다. 다른 마스터의 복사본일 뿐이지만 공유 목적으로만 사용됩니다. 그리고 요즘에는 많은 기업이 하나의 공통 보기, 하나의 공통 기능을 갖기 위해 여러 애플리케이션을 통합하는 데 많은 노력을 기울이고 있다는 것을 알고 있습니다.

우리가 대화한 많은 은행이 여러 애플리케이션에서 고객 여정을 이해하기를 원한다는 것을 알고 있습니다. 그렇다면 해당 애플리케이션은 어떻게 서로 통신합니까? 서로 데이터를 공유할 수 있는 중심점은 무엇입니까? 메모리에 있는 내용이어야 합니다. 메모리에 없으면 또 다른 병목 현상이 발생합니다. 그리고 인메모리의 장점은 언제든지 다시 시작할 수 있고 데이터 손실이 없다는 것입니다. 왜냐하면 마스터 데이터 소스에서 데이터를 다시 로드하기 때문입니다. 그러나 자체적으로 사용할 수 있게 됩니다. 그리고 중복되기 때문에 여러 서버에 복제됩니다. 분산 캐시가 완전히 손실될 확률은 매우 낮습니다. 그리고 실제로 여러 지역, 여러 데이터 센터, 샌프란시스코, 뉴욕 등에 걸쳐 동일한 캐시를 유지할 수 있는 몇 가지 다른 기능을 살펴보겠습니다. 그리고 그런 식으로 재해 복구 상황이 발생하면 몇 년 전 여러분이 상당히 큰 폐쇄에 직면했다는 뉴스를 본 적이 있습니다. 그런 상황에서는 진정한 재해 복구가 필요합니다. 따라서 모든 것이 여러 지역에 걸쳐 복제되어야 합니다. 그리고 데이터 공유 목적으로 분산 캐시를 사용하는 경우 해당 분산 캐시도 여러 가지 이유로 복제되어야 합니다. 이에 대해 설명하겠습니다. 그러나 이는 특히 Wells Fargo와 같은 대기업이 여러 애플리케이션을 통합하는 데 있어 매우 중요한 부가적인 이점입니다. 그리고 다시 말하지만, 여러분은 큰 회사이기 때문에 이 중 여러 개를 가질 수 있습니다. 회사 전체에 대해 마스터가 한 명도 없을 수도 있고 그럴 수도 있기 때문입니다. 또는 회사의 특정 부분에 데이터를 공유하기 위해 이러한 장치가 여러 개 있을 수도 있습니다.

분산 캐시 아키텍처

이제 분산 캐시를 사용할 수 있는 모든 방법에 대해 이야기했습니다. 아키텍처 측면에서 좋은 분산 캐시에서 무엇을 기대할 수 있습니까?

고 가용성

첫 번째는 고가용성입니다. 분산 캐시가 라이브 프로덕션 환경에서 사용되고 있기 때문에 이것이 진정한 고가용성을 제공하지 않는다면 매우 회의적이어야 하며 고가용성은 분산 캐시가 생성하는 클러스터에 피어가 있어야 함을 의미합니다. 투 피어 아키텍처. PXNUMXP 아키텍처가 없고 마스터 슬레이브가 있는 경우 마스터가 죽으면 슬레이브는 읽기 전용이 되거나 작동할 수 없게 됩니다. 따라서 런타임에 서버를 추가하거나 제거하는 기능은 매우 중요합니다.

선형 확장 성

두 번째는 선형 확장성이며 이는 데이터 분할을 통해 제공됩니다. 다음 슬라이드로 가서 그것에 대해 이야기하겠습니다. 따라서 분할에는 두 가지 방법이 있습니다. 하나는 복제 없이 분할하는 것이고, 두 번째는 복제를 사용하여 분할하는 것입니다. 따라서 앞서 언급한 것처럼 분산 캐시는 중복성과 스마트 복제를 제공합니다.

그 스마트 복제란 무엇입니까? 스마트 복제는 모든 데이터가... 데이터가 분할되고 모든 파티션이 다른 서버에 백업되며 모든 것이 동적임을 의미합니다. 그래서 자가치유가 되는 것입니다. 따라서 새 서버를 추가하면 새 파티션이 생성되고 새 복제본이 생성되며 데이터의 균형이 자동으로 조정됩니다.

여기 예가 있습니다. 두 개의 서버 캐시 클러스터로 시작했고 트랜잭션 로드가 증가하고 있기 때문에 세 번째 클러스터를 추가하고 싶다고 가정해 보겠습니다. 세 번째 서버를 추가하자마자 자동으로 세 번째 파티션이 생성됩니다. 이제 세 개의 파티션이 생겼습니다. 그래서 복제본도 다시 조정해야 합니다. 동적으로 또는 자동으로 발생하는 모든 것입니다.

그리고 같은 방식으로, 당신이 그것을 원하거나 어떤 이유로 한 서버가 다운되었다고 가정해 봅시다. 서버 3이 다운되고 파티션 3도 다운되었다고 가정해 보겠습니다. 파티션 3이 다운되자마자 복제본 3이 활성화됩니다. 이제 두 개의 서버와 세 개의 파티션이 있는 예외적인 상황이 발생했습니다. 따라서 이제 자동으로 두 개의 파티션과 두 개의 복제본으로 다시 병합되어야 합니다. 이 모든 작업은 사람의 개입 없이 자동으로 수행되어야 합니다. 사람의 개입이 필요한 경우 가용성이 실제로 높지는 않습니다. NoSQL databases, 영구 스토리지에 많은 데이터를 처리해야 하는 데이터베이스이기 때문에 이러한 동적 재분할을 제공하지 않습니다. 그리고, 한동안은 괜찮아요 NoSQL database. 하지만 메모리 내 저장소에는 적합하지 않습니다. 인메모리 저장소는 서버 수 측면에서 훨씬 더 빠르고 더 민첩하게 이동해야 합니다.

WAN 복제

여러 사이트가 있는 경우의 고가용성은 다음과 같습니다. 따라서 샌프란시스코에서 사이트 1에 분산 캐시가 있고 사이트 2를 갖고 싶다면 활성-수동 또는 활성-활성을 가질 수 있습니다. 예전에는 액티브-패시브가 더 많이 보였지만 이제는 클라우드 때문에 거의 모든 사람이 액티브-액티브로 전환하고 있습니다. 인프라를 구축하는 것이 훨씬 쉽습니다. 따라서 사람들은 활성 활성 사이트를 가지고 있습니다.

Active-Active 챌린지에서는 양측이 동일한 데이터를 업데이트할 수 있으므로 분산 캐시에 충돌 해결 기능이 내장되어 있어야 합니다. NCache 그러나 진정한 고가용성을 얻으려면 하나의 데이터 센터를 넘어 여러 데이터 센터로 이동해야 한다는 점을 알아야 합니다.

많은 상황에서 두 개의 데이터 센터로는 충분하지 않을 수 있으므로 세 개 이상의 데이터 센터가 있는 경우에도 여전히 동일한 활성-활성 복제 기능이 필요합니다. 따라서 한 데이터 센터가 다운되면 다른 두 데이터 센터가 로드를 인계할 수 있어야 하며, 그런 다음 해당 데이터 센터를 백업하고 다시 연결할 수 있어야 하며 사용자에게 중단이 발생해서는 안 됩니다.

분산 캐시를 사용하여 해당 목표를 달성할 수 있다면 사람 없이 동적으로 모든 것이 가능합니다. 물론 데이터 센터 백업을 가져오려면 사람의 개입이 필요합니다. 그러나 고가용성이 정말로 높으려면 데이터 센터가 다운될 때 사람의 개입이 없어야 합니다. XNUMX분이라도 늦어지면 용납되지 않습니다.

그게 내 얘기의 끝이야. 시간이 조금 남을 수 있도록 최대한 빨리 진행하려고 노력했습니다. 나는 단지 여러분에게 몇 가지 요약적인 생각을 주려고 합니다. 제가 강조하고 싶었던 가장 중요한 점은 개발 중인 모든 애플리케이션에 제가 이야기한 세 가지 사용 사례에 대해 인메모리 분산 캐시가 있어야 한다는 것입니다. 그리고 이상적으로는 여러 애플리케이션 간의 데이터 공유에도 사용해야 합니다. 그리고 어느 쪽이든 동일한 애플리케이션 내에서도 재해 복구가 가능하도록 여러 사이트를 보유하도록 노력해야 합니다.

그리고 저는 15년의 경험을 바탕으로 이에 대해 이야기하고 있습니다. 우리는 이것을 해왔습니다. NCache 15년 넘게 시장에 진출해 왔으며 많은 은행과 협력해 왔습니다. 우리는 전통적으로 .NET 상점이었지만 NCache 이제 .NET, Java 및 Node.js를 완벽하게 지원합니다. .NET, Java 및 Node.js의 클라이언트 측 및 서버 측 코드는 모두 클라이언트 API일 뿐입니다. 이것이 내 이야기의 끝입니다.

고마워요, 이크발. Wells Fargo가 현대화 과정을 진행하면서 이 프레젠테이션이 얼마나 시의적절하고 적절했는지는 아무리 강조해도 지나치지 않습니다. 고마워요. 팀, 궁금한 점이 있으면 알려드리겠습니다. 채팅을 통해 질문해 주세요. Iqbal에 대한 일련의 질문이 있습니다. 질문이 많은 팀이 있습니다. 이 프레젠테이션과 비디오를 볼 수 있습니까? 대답은 '그렇다'입니다. 프레젠테이션이 끝난 후 요청 시 제공될 예정입니다. 링크를 보내드리겠습니다. 그래서 Iqbal 씨, 여기에 들어온 질문 중 일부가 있습니다.

분산 캐시는 민감한 데이터를 어떻게 처리합니까? 마찬가지로 투명한 암호화가 문제입니다.

네, 시간이 없어서 그것에 대해 자세히 설명할 수는 없지만 그것도 매우 중요한 측면입니다. 같은 제품 NCache예를 들어 다음을 제공합니다. 보안 여러 수준에서. 인증, 승인, 보안이 있습니다. 암호화가 있습니다. 따라서 여러 암호화 알고리즘이 있습니다. 일부는 128비트, 일부는 256비트 암호화입니다. TLS, 전송 보안이 있습니다. 따라서 Wells Fargo와 같은 은행의 캐시는 보안을 제공해야 하며, 이것이 바로 우리가 은행과 협력하는 이유입니다. 이것이 우리가 오랫동안 사용해 왔던 기능입니다. 따라서 데이터를 암호화할 수 있습니다. 그리고 다시 말하지만, 이 모든 것이 자동으로 이루어집니다. 이를 수행하는 데 프로그래밍이 필요하지 않습니다. 이것은 단지 구성일 뿐입니다. 그러나 분산 캐시는 이러한 다양한 기능을 통해 보안을 해결해야 합니다.

다음 질문은, 오라클 캐시 객체와 메모리 등 데이터베이스를 갖고 있는 것과 오라클 앞에 또 다른 메모리 캐시를 갖는 것과 어떤 차이가 있느냐는 것입니다. 기본적으로 oracle에 더 많은 메모리를 할당해도 같은 결과를 얻을 수 있나요?

키워드는 '분산'인 것 같아요. 분산되지 않은 모든 것은 빠르지만 확장 가능하지는 않습니다. 이것이 바로 제가 첫 번째 슬라이드에서 확장성이라는 단어를 정의한 이유입니다. 배포로 1박스에서 10박스, 50박스로 갈 수 있나요? 일부 고객은 150개 이상의 애플리케이션 서버로 구성된 애플리케이션 서버 팜을 보유하고 있습니다. 그리고 아시다시피, 우리는 ... State Street Bank도 우리의 또 다른 고객이기 때문에 단일 데이터베이스 서버의 메모리 내 캐싱이 이를 처리할 수 있는 방법이 전혀 없습니다. 예, 이는 Oracle, SQL Server 등을 빠르게 만드는 데 매우 중요한 기능이지만 확장 가능하지는 않습니다. 확장성은 배포를 통해서만 달성될 수 있습니다.

어떻게 NCache 에 비해 성능 Redis, 일관성 및 기타 시장 제품. 그리고 또 다른 질문은 로드맵에 Scala나 Python과 같은 추가 프로그래밍 언어를 지원할 계획이 있습니까?입니다. 사실 두 번째 질문에 먼저 답해 보겠습니다. 네, 우리는 Scala와 Python을 많이 지원할 예정입니다. 사실 우리는 올해도 그렇게 할 예정입니다. 우리는 지난 거의 10년 동안 Java를 지원해 왔습니다. 이용하시는 고객님들 대부분이 NCache, 대기업이라면 Java와 .NET 모두에 사용합니다. 하지만 .NET 관점에서 구매할 수도 있습니다. 그래서, 그게 첫 번째입니다.

두 번째 질문은, 어떻게 하느냐는 것이었습니다. NCache 성능 비교 Redis 다른 사람? 내 말은, 그들은 모두 빠르다는 것입니다. 나는 누구도 나쁘게 보이게 만들지 않을 것이며 여러분이 스스로 비교해야 한다고 생각하지만 그들은 모두 빠릅니다. 제 생각에 제가 경고하고 싶은 유일한 것은 일부 플레이어가 벤치마크 수행에 대해 잘못된 인상을 준다는 것입니다. 예를 들어, 우리가 제공하는 벤치마크에는 완전한 왕복 여행이 포함됩니다. 따라서 삽입 작업이 애플리케이션에 다시 반환되지 않는 한 캐시.Get 또는 캐시.삽입을 수행하는 경우 작업이 완료되지 않습니다. 그러나 다른 벤더 중 일부는 실제로 우리보다 훨씬 더 큰 벤치마크를 보여 주지만 불이라고 부르는 일을 할 것입니다. 그러니 걱정하지 않고 보내기만 한다면 분명 더 많은 일을 할 수 있을 것입니다. 그리고 실제로 Java 측에서는 Hazelcast와 Redis 연구실들은 정확히 같은 지점에서 서로를 추적해 왔습니다. 그래서 저는 그것에만 맡기겠습니다.

PCI 데이터를 캐시 공간의 민감한 데이터에 다시 사용하는 것과 관련된 다른 은행 및 기타 규정 준수 문제와 협력했습니다. 그곳에서 규정 준수 문제가 발생했나요?

실제로는 그렇지 않습니다. 우선 우리는 데이터 수준에서 다양한 보안 기능 암호화를 모두 제공한다는 사실을 의미합니다. 왜냐하면 데이터를 캐시하기 전과 전송 수준에서도 암호화할 수 있기 때문입니다. 또한 서버 측에서 인증 및 권한 부여가 이루어지며 이것이 캐시 서버 측입니다. 그리고 제 생각에는 이것이 충분하다고 생각합니다. 그리고 무엇보다도 보안된 데이터 센터 내에서 캐시가 실행됩니다. 캐시는 외부 엔터티가 액세스할 수 있는 것이 아닙니다. 따라서 이 모든 것을 내부에서 캐시가 실행된다는 사실과 결합하면 우리는 아무것도 갖고 있지 않았습니다. 예를 들어 Citi Group과 Bank of America 및 Barclays는 캐시를 사용하고 있습니다. NCache 지금까지 XNUMX년 넘게 아무런 문제가 없었습니다.

메인프레임 데이터베이스에서는 어떻게 작동합니까?

내 생각에 메인프레임은... 예를 들어, 아마도 여러분은... 현재 웹 서비스를 갖고 있고 애플리케이션이 메인프레임에 액세스할 수 있도록 일부 마이크로서비스를 개발할 것입니다. 메인프레임은 메인프레임에서 데이터를 가져오는 데 비용이 많이 드는 또 다른 경우입니다. 속도 측면에서나 때로는 메인프레임이 외부에서 호스팅되는 경우 트랜잭션당 또는 여행당 기준으로 비용을 지불해야 할 수도 있습니다. 따라서 앞서 말했듯이 Kubernetes 또는 마이크로서비스 계층 내에서 해당 데이터를 더 많이 캐시하고 메인프레임으로의 이동 횟수를 줄일 수 있다면 성능이 향상될 뿐만 아니라 많은 비용도 절약할 수 있습니다.

노드를 추가하고 제거할 때 인메모리 분산 캐시 전체에서 데이터의 일관성과 가용성이 어떻게 보장됩니까?

그렇다면 적어도 나는 그것에 대해 이야기할 수 있다. NCache 그 NCache 노드를 추가하거나 제거할 때 수행 중인 모든 업데이트, 수행 중인 모든 변경 사항이 상태 전송을 수행한다는 사실과 함께 완료되도록 보장합니다. 예를 들어 파티셔닝 등을 이동하고 있다고 가정해 보겠습니다. NCache 노드가 추가되고 상태 전송(상태 전송이라고 함)을 확인하면서 모든 업데이트가 올바르게 적용되었는지 확인해야 한다는 것을 알고 있습니다. 이는 한 파티션에서 다른 파티션으로 데이터를 이동하기 위한 데이터 밸런싱입니다. 도 계속 일어나고 있어요. 그래서, NCache 그것을 보장합니다.

그림에서 본 것처럼 자체 데이터베이스와 함께 마이크로서비스를 배포할 때 어떻게 고객에게 옴니채널 경험을 제공할 수 있습니까?

따라서 분산 데이터베이스 부분에서는 배심원단이 해당 데이터베이스가 어떻게 분산될 것인지에 대해 판단하지 않는다고 생각합니다. 해당 데이터베이스가 어떻게 분할될 예정인지. 제가 강연에서 말했듯이, 적어도 이론적으로는 모든 마이크로 서비스가 자체 논리적 데이터베이스를 가질 수 있기 때문입니다. 비록 물리적으로 동일한 데이터베이스 서버에 상주하더라도 말이죠. 각 마이크로 서비스마다 하나씩, 100개의 서로 다른 데이터베이스 서버. 일부 통합된 데이터베이스 서버를 갖게 될 것입니다. 분리가 있다는 사실은 아마도 다음과 같이 좀 더 유연성을 제공할 것입니다. NoSQL 그러나 배심원단은 관계형 데이터베이스의 한계를 얼마나 극복할 수 있는지에 대해 아직 판단하지 않았습니다. 내 예측은 여러분이 동일한 관계형 데이터베이스 서버를 사용하게 될 것이라는 것입니다. 논리적 분리가 있을 수도 있고 없을 수도 있습니다. 별도의 스키마가 있거나 동일한 스키마가 있을 수 있습니다. 다른 테이블과 통신하고 있지만 데이터베이스 서버는 여전히 동일합니다. 따라서 이는 웹 서비스에서도 다루고 있는 것과 동일한 문제이며 마이크로서비스에서도 다루게 될 것입니다. 시간이 부족하다고 생각합니다. 정말 감사합니다. 이것은 매우 흥미로웠습니다. 질문이 계속해서 쏟아져 들어오고 있지만 분명히 모든 질문에 답할 수는 없습니다. 그럼 그걸로 당신에게 다시 넘겨 드리겠습니다.