선형 확장성을 위한 캐싱 토폴로지

NCache 데이터 일관성과 신뢰성을 유지하면서 선형 확장성을 가능하게 하는 다양한 캐싱 토폴로지를 제공합니다. 이것의 목표는 수십 또는 수백 개의 캐시 서버로 구성된 초대형 캐시 클러스터에 이르기까지 매우 작은 XNUMX-서버 캐시로 실행되는 애플리케이션의 요구 사항을 해결하는 것입니다. 캐싱 토폴로지는 기본적으로 여러 캐시 서버에 걸쳐 있는 클러스터된 캐시의 데이터 저장, 데이터 복제 및 클라이언트 연결 전략입니다.

다음은 주요 캐싱 토폴로지입니다. NCache 제공 :

1. 파티션된 캐시
2. 파티션 복제본 캐시
3. 복제된 캐시
4. 미러링된 캐시 (2노드 액티브/패시브)
5. 클라이언트 캐시 (InProc 속도, 클러스터 캐시에 연결된 로컬 캐시)

참조 데이터와 거래 데이터

참조 데이터는 자주 변경되지 않는 데이터이며 계속해서 도달하고 가끔 업데이트하기 위해 캐시합니다. 반면 트랜잭션 데이터는 매우 자주 변경되는 데이터이며 읽을 때마다 업데이트할 수 있습니다.

가격이 자주 변경되지 않는 제품 카탈로그를 캐싱하는 것이 참조 데이터입니다. 한편, ASP.NET Core 세션 저장소는 몇 초마다 발생할 수 있는 모든 웹 요청에 대해 세션을 읽고 업데이트하기 때문에 트랜잭션 사용으로 간주됩니다.

초기에는 자주 변경되는 데이터가 오래되고 데이터베이스의 최신 데이터와 동기화되지 않기 때문에 캐시가 주로 참조 데이터용으로 좋은 것으로 간주되었습니다. 하지만, NCache 이제 캐시가 캐시된 데이터를 데이터베이스와 동기화된 상태로 유지할 수 있는 매우 강력한 기능을 제공합니다.

모든 캐싱 토폴로지는 참조 데이터에 적합하지만 일부 캐싱 토폴로지만 특히 트랜잭션 데이터에 더 좋습니다. 어떤 토폴로지가 가장 적합한지 파악하기 위해 수행할 읽기와 쓰기의 수를 결정해야 합니다. 또한 일부 캐싱 토폴로지는 업데이트를 위해 특별히 확장되지 않으므로 이를 염두에 두십시오.

다음은 읽기 대 쓰기에 미치는 영향과 함께 캐싱 토폴로지 목록입니다.

1. 분할된 캐시(복제 없음): 아주 좋아요. 읽기 및 쓰기 모두에 대해 초고속이며 서버를 추가하여 선형적으로 확장됩니다. 가장 빠른 토폴로지이지만 데이터를 복제하지 않으므로 캐시 서버가 다운되면 데이터가 손실됩니다.
2. 파티션 복제본 캐시 (가장 인기있는): 아주 좋아요. 읽기 및 쓰기 모두에 대해 초고속이며 서버를 추가하여 선형적으로 확장됩니다. 두 번째로 빠른 토폴로지이지만 선형 확장성을 손상시키지 않으면서 안정성을 위해 데이터를 복제합니다. 속도/확장성 및 데이터 안정성의 최상의 조합.
3. 복제된 캐시: 소규모 환경에 매우 적합. 읽기를 위해 매우 빠르고 선형적으로 확장 가능합니다. 2노드 클러스터의 쓰기 속도는 어느 정도 빠르지만 모든 캐시 서버에서 쓰기가 동기식으로 수행되기 때문에 서버를 추가해도 확장되지 않습니다.
4. 미러링된 캐시: 소규모 환경에 매우 적합. 읽기를 위한 초고속. 쓰기는 2노드 능동/수동의 경우 복제된 캐시보다 빠릅니다. 그러나 이 이상으로 확장되지 않습니다.
5. 클라이언트 캐시: 읽기 집약적인 사용에 매우 좋습니다. 모든 캐싱 토폴로지와 함께. 분산 캐시로 InProc 속도를 달성할 수 있습니다.

파티션된 캐시

Partitioned Cache는 읽기 및 쓰기 모두에 대해 가장 빠르고 확장 가능한 캐싱 토폴로지입니다. 더 큰 캐시 클러스터를 위한 것이며 최대 로드에서도 읽기 및 쓰기 성능이 매우 우수합니다. 그러나 데이터를 복제하지 않으므로 캐시 서버가 다운되면 데이터가 손실됩니다.

다음은 파티션된 캐시의 몇 가지 특징입니다.

1. 동적 파티션: 캐시는 런타임에 파티션으로 나뉘며 각 캐시 서버에는 하나의 파티션이 있습니다. 모든 파티션에 균등하게 분산되는 클러스터형 캐시당 총 1000개의 버킷이 있습니다. 캐시 서버를 추가/제거하면 런타임에 파티션이 생성/삭제됩니다. 파티션에 대한 버킷 할당은 데이터가 캐시에 추가될 때 변경되지 않습니다. 대신 파티션이 추가 또는 삭제되거나 데이터 밸런싱이 발생할 때만 변경됩니다(아래 참조).
2. 분포 지도: 캐시 클러스터는 어떤 버킷이 어떤 파티션에 존재하는지에 대한 정보가 포함된 분포 맵을 생성합니다. 분배 맵은 파티션이 추가 또는 삭제될 때마다 또는 데이터 밸런싱이 발생할 때마다 업데이트됩니다(아래 참조). 배포 맵은 모든 서버와 클라이언트에 전파됩니다. 클라이언트는 이것을 사용하여 특정 캐시 항목을 읽거나 쓰기 위해 통신할 캐시 서버를 파악합니다.
3. 동적 데이터 밸런싱: 모든 버킷은 실제로 키에 대한 Hashing 알고리즘을 기반으로 데이터가 저장되는 HashMap 버킷이기 때문에 사용된 키에 따라 일부 버킷에는 다른 버킷보다 더 많은 데이터가 있을 수 있습니다. 이 불균형이 구성 가능한 임계값을 초과하면 NCache 이 부하의 균형을 맞추기 위해 자동으로 버킷을 이동합니다.
4. 클라이언트는 모든 파티션에 연결: 클라이언트는 모든 캐시 서버에 연결하여 서버에서 한 번의 요청으로 데이터를 직접 읽거나 쓸 수 있습니다. 클라이언트와 캐시 서버의 연결이 끊어지면 다른 서버 중 하나에 액세스할 수 없는 서버에 있는 캐시된 항목을 읽거나 쓰도록 요청합니다. 그리고 그 서버는 클라이언트가 그것을 달성하도록 도와줍니다.

파티션 복제본 캐시

참고: 분할 캐시에 언급된 모든 내용은 여기에서도 마찬가지입니다.

처럼 파티션된 캐시, Partition-Replica Cache는 읽기와 쓰기 모두에 대해 매우 빠르고 선형적으로 확장 가능한 캐싱 토폴로지입니다. 더 큰 캐시 클러스터를 위한 것이며 최대 로드에서도 읽기 및 쓰기 성능이 매우 우수합니다. 또한 Partition-Replica Cache도 데이터를 복제하므로 캐시 서버가 다운되어도 데이터 손실이 없습니다.

파티션 복제본 캐시는 가장 인기 있는 캐싱 토폴로지 성능/선형 확장성 및 데이터 안정성의 두 가지 장점을 모두 제공하기 때문입니다.

다음은 Partition-Replica Cache의 몇 가지 특징입니다.

1. 동적 파티션: 동일 파티션된 캐시.
2. 동적 복제본: 런타임에 파티션이 생성되거나 삭제되면 해당 복제본도 생성되거나 삭제됩니다. 복제본은 항상 다른 캐시 서버에 있으며 파티션에는 복제본이 하나만 있습니다.
3. 비동기 복제: 기본적으로 파티션에서 복제본으로의 복제는 비동기식입니다. 이것은 클라이언트가 파티션의 모든 데이터를 추가, 업데이트 또는 삭제할 수 있고 이러한 모든 작업이 대기열에 추가됨을 의미합니다. 그런 다음 Replica에서 BULK로 복제됩니다. 이렇게 하면 성능이 향상되지만 파티션이 진행되고 모든 업데이트가 복제본에 복제되지 않은 경우 데이터가 약간 손실될 위험이 있습니다. 그러나 대부분의 상황에서 이것은 완벽합니다.
4. 동기화 복제: 데이터가 매우 민감하고(예: 재무 데이터) 오래된 데이터를 가질 여유가 없는 경우 구성에서 "동기화 복제" 옵션을 선택할 수 있습니다. 이 옵션을 선택하면 완료된 것으로 간주될 때까지 모든 쓰기 작업이 파티션과 복제본 모두에서 동기적으로 수행됩니다. 이렇게 하면 복제본에서 작업이 실패하면 파티션에서도 실패합니다. 또한 캐시의 모든 데이터(파티션 및 복제본 모두)가 항상 일관성이 있음을 보장할 수 있습니다. 그러나 이것은 비동기 복제보다 느리기 때문에 성능에 영향을 미칩니다.
5. 분포 지도: 동일 파티션된 캐시.
6. 동적 데이터 밸런싱(파티션 및 복제본): 동일 파티션된 캐시. 그러나 Partition-Replica Cache에서는 파티션이 데이터 밸런싱될 때 복제본에서도 데이터 밸런싱이 발생합니다.
7. 클라이언트는 모든 파티션에 연결: 동일 파티션된 캐시. 또한 Partition-Replica Cache에서 클라이언트는 복제본이 아닌 파티션과만 통신합니다. 이는 복제본이 수동적이며 데이터를 복제할 때 파티션만 복제본과 통신하기 때문입니다.

복제된 캐시

복제된 캐시는 두 개 이상의 캐시 서버에 복제를 통해 데이터 안정성을 제공합니다. 읽기에 대해 매우 빠르고 확장 가능합니다. 그러나 쓰기는 클러스터의 모든 서버와 동기화되기 때문에 확장되지 않습니다. 2노드 클러스터의 경우 쓰기가 데이터베이스보다 빠르지만 데이터베이스만큼 빠르지는 않습니다. 파티션 복제본 캐시. 3개 이상의 서버 클러스터의 경우 쓰기 성능이 저하되어 결국에는 매력적이지 않게 됩니다.

다음은 복제된 캐시의 몇 가지 특징입니다.

1. 동적 복제 노드: 캐시 또는 애플리케이션을 중지하지 않고 런타임 시 기존 캐시에 캐시 서버를 추가하거나 제거할 수 있습니다. 새로 추가된 서버는 전체 캐시의 복사본(Replica)을 자신에게 만듭니다. 그리고 제거된 서버는 클러스터 구성원을 업데이트하고 모든 클라이언트는 다른 서버로 이동합니다.
2. 각 노드의 전체 캐시: 전체 캐시가 클러스터의 모든 서버에 복사됩니다.
3. 읽기 확장 가능: 더 많은 서버를 추가하면 읽기가 매우 빠르고 확장 가능합니다. 그러나 새로 추가된 서버는 전체 캐시의 또 다른 복사본이기 때문에 더 많은 서버를 추가해도 캐시 크기가 증가하지 않습니다.
4. 쓰기는 동기식입니다.us: 쓰기는 2노드 클러스터의 경우 매우 빠르고 데이터베이스보다 빠릅니다. 그러나 쓰기는 동기식이므로 모든 캐시 서버가 동기식으로 업데이트될 때까지 각 쓰기 작업이 완료되지 않습니다. 이로 인해 쓰기는 다른 토폴로지만큼 빠르지 않으며 클러스터 크기를 2노드 이상으로 늘리면 성능이 저하됩니다.
5. 클라이언트는 하나의 서버에만 연결: 각 캐시 클라이언트는 캐시 서버에서 결정한 부하 분산 알고리즘을 기반으로 클러스터의 한 서버에만 연결합니다. 이 캐시 서버가 다운되면 클라이언트는 목록의 다음 서버에 연결합니다. 로드 밸런싱을 사용하지 않으려면 캐시 구성 파일에서 연결할 서버를 수동으로 지정할 수도 있습니다.

미러링된 캐시

미러드 캐시는 소규모 환경을 위한 2노드 액티브/패시브 캐시 클러스터입니다. Active Node에서 Passive Node로의 비동기 복제/미러링을 통해 데이터 신뢰성을 제공합니다. 읽기와 쓰기 모두 매우 빠릅니다(실제로 쓰기는 복제된 캐시) 그러나 이 2노드 능동/수동 클러스터 이상으로 확장되지 않습니다.

다음은 Mirrored Cache의 몇 가지 특징입니다.

1. 활성 서버 1개 및 수동 서버 1개: 미러링 캐시에는 두 개의 서버만 있습니다. 하나는 활성이고 다른 하나는 수동입니다. 둘 다 전체 캐시의 복사본을 가지고 있습니다. 액티브 서버가 다운되면 패시브 서버가 자동으로 액티브가 됩니다. 그리고 이전에 다운된 Active Server가 다시 올라오면 런타임에 관리 도구를 통해 이 지정을 변경하지 않는 한 Passive Server로 처리됩니다.
2. 장애 조치를 지원하는 클라이언트 연결: 각 캐시 클라이언트는 읽기 및 쓰기 작업을 수행하기 위해 클러스터의 활성 서버에만 연결합니다. 이 Active Server가 다운되면 모든 클라이언트는 자동으로 Active가 된 Passive Server에 연결합니다. 이 장애 조치 지원은 서버가 다운된 경우에도 미러 캐시가 항상 작동하여 실행되도록 합니다.
3. 비동기 미러링: Active Server에서 수행된 모든 쓰기는 Passive Server에 비동기식으로 미러링/복제됩니다. 이렇게 하면 능동 서버가 다운되어 수동 서버가 능동이 되어야 하는 경우 수동 서버가 항상 최신 데이터와 동기화됩니다. 비동기 미러링은 또한 여러 쓰기가 수동 서버에서 BULK 작업으로 수행되기 때문에 더 빠른 성능을 의미합니다.

클라이언트 캐시(InProc 속도)

클라이언트 캐시는 웹/앱 서버에 로컬이며 애플리케이션과 매우 가깝고 분산 캐시(모든 캐싱 토폴로지)에서 읽고 있는 데이터를 캐시할 수 있습니다. 이것을 "캐시 위의 캐시"로 볼 수 있으며 애플리케이션 성능과 확장성을 훨씬 더 크게 향상시킵니다. InProc 모드에서 Client Cache를 사용하면 InProc 속도를 얻을 수 있습니다.

애플리케이션에 로컬인 동안 클라이언트 캐시는 독립 실행형이 아닙니다. 대신 항상 클러스터된 캐시와 동기화됩니다. 이렇게 하면 클라이언트 캐시의 데이터가 오래되지 않습니다.

다음은 Mirrored Cache의 몇 가지 특징입니다.

1. 읽기 집중 사례에 적합: 클라이언트 캐시는 읽기 횟수가 쓰기 횟수보다 몇 배 많은 읽기 집약적인 사용 사례가 있는 경우에만 좋습니다. 쓰기 횟수가 읽기 횟수와 같으면 쓰기 작업에 두 곳에서 업데이트가 포함되기 때문에 클라이언트 캐시가 실제로 더 느립니다.
2. 로컬 캐시와 같은 더 빠른 속도(InProc / OutProc): 클라이언트 캐시는 애플리케이션 프로세스 내부(InProc 모드) 또는 웹/앱 서버의 로컬(OutProc 모드)에 있습니다. 두 경우 모두 클러스터형 캐시에서 이 데이터를 가져오는 것과 비교하여 애플리케이션 성능을 크게 향상시킵니다. InProc 모드를 사용하면 분산 캐시와 일치시킬 수 없는 "InProc 속도"를 제공하는 "응용 프로그램 힙"에 개체를 캐시할 수 있습니다.
3. 독립 실행형 캐시 아님: 클라이언트 캐시는 로컬 캐시일 수 있지만 독립 실행형 캐시는 아닙니다. 대신 클러스터된 캐시와 동기화된 상태를 유지합니다. 이것이 의미하는 바는 다른 클라이언트가 클라이언트 캐시에 있는 클러스터형 캐시의 데이터를 업데이트하는 경우 클러스터형 캐시가 해당 데이터의 최신 복사본으로 자체 업데이트하도록 클라이언트 캐시에 알린다는 것입니다. 그리고 이것은 비동기식이지만 즉시 수행됩니다.
4. 낙관적/비관적 동기화: 기본적으로 클라이언트 캐시는 낙관적 동기화를 사용합니다. NCache 클라이언트는 클라이언트 캐시에 있는 모든 데이터가 최신 복사본이라고 가정합니다. 클라이언트 캐시에 데이터가 없으면 클라이언트는 클러스터된 캐시에서 데이터를 가져와 클라이언트 캐시에 넣은 다음 클라이언트 응용 프로그램에 반환합니다. 비관적 동기화는 캐시 클라이언트가 먼저 클러스터된 캐시에 최신 버전의 캐시된 항목이 있는지 확인하는 것을 의미합니다. 그렇다면 클라이언트는 이를 가져와 클라이언트 캐시에 넣은 다음 클라이언트 응용 프로그램에 반환합니다. 그렇지 않으면 클라이언트 캐시에 있는 모든 것을 반환합니다.
5. 코드 변경이 없는 플러그인: 클라이언트 캐시의 가장 좋은 점은 애플리케이션에 코드 변경이 포함되지 않는다는 것입니다. 대신 구성 변경을 통해 연결하기만 하면 됩니다. 그리고, NCache 백그라운드에서 클라이언트 API는 클라이언트 캐시 사용에 대해 무엇을 해야 하는지 알고 있습니다.

다음에 무엇을할지?

• NCache 세부 정보
• 다운로드 NCache
• 판 비교