Cache Coherence란? 여러 CPU 코어가 같은 데이터를 볼 때 값이 서로 달라지지 않게 하는 원리 쉽게 이해하기
Cache Coherence는 여러 CPU Core Cache에 같은 Memory 데이터가 있을 때 모순된 값을 쓰지 않도록 일관성을 유지하는 원리입니다. Invalidation·MESI·False Sharing·Atomic까지 초보 기준으로 정리합니다.
Core가 하나면 Cache에 값을 바꿔도 다른 Core의 예전 사본을 크게 걱정하지 않아도 됩니다. Core가 여러 개면 같은 `x`를 각자 Cache에 둘 수 있습니다. Core 1이 `x=20`으로 바꿨는데 Core 2 Cache에 `x=10`이 남으면 같은 데이터를 서로 다르게 봅니다. 이처럼 여러 Core Cache의 같은 Memory 데이터가 모순되지 않도록 일관성을 유지하는 원리를 Cache Coherence(캐시 일관성)라고 합니다. 직원마다 가격표 사본이 있을 때 한 명이 수정하면 다른 사본도 「더 이상 최신이 아님」을 알려야 하는 것과 비슷합니다.
Memory x=10 → Core1 Cache x=10 · Core2 Cache x=10 Core1: x=20 → Core2의 오래된 사본을 그대로 두면 안 됨
왜 Core마다 Cache인가 · Invalidation
Memory는 상대적으로 느려 각 Core 가까이에 L1/L2를 둡니다. 성능에는 유리하지만 같은 주소의 복사본이 여러 개 생깁니다. Write가 나면 다른 Cache의 오래된 값을 Invalid로 표시하는 Cache Invalidation이 대표적입니다. Core 2가 다시 읽으면 최신을 가져옵니다. 웹·Redis Invalidation과 아이디어는 비슷하지만 CPU Hardware Cache 계층입니다. 보통 Cache Line 단위로 관리됩니다.
False Sharing · Ping-Pong · MESI
서로 다른 변수 `x`·`y`가 같은 Cache Line에 있으면 Core마다 다른 변수를 수정해도 Line 상태가 오가며 Traffic이 늘 수 있습니다. 이것이 False Sharing입니다. 같은 Line의 수정 권한이 Core 사이를 반복 이동하면 Cache Line Ping-Pong입니다. Shared Counter 하나에 64 Core가 몰리면 `+1` 연산보다 Coherence가 비쌀 수 있습니다. 이는 Resource Contention입니다. 대표 Protocol 모델 MESI(Modified·Exclusive·Shared·Invalid)는 Line마다 누가 가졌고 수정했는지 관리한다는 정도로 이해하면 됩니다. 읽기만 Shared면 비교적 단순하고, Write가 문제입니다.
Read-Only Config → Shared 복사 유리 Hot Write: Counter / Lock / Queue Head → Coherence↑ Sharded Counter: Core별 누적 후 합산
Atomic · Lock · Interconnect · Scalability
Atomic은 값이 깨지지 않게 하지만 한 변수에 Core가 몰리면 Coherence Contention은 남을 수 있습니다. Lock·Spin도 Shared Memory 상태 경쟁으로 Traffic을 늘릴 수 있습니다. Coherence Message는 Interconnect를 탑니다. Core·Shared Write가 늘면 Scalability가 꺾일 수 있습니다. Worker별 Local Data·Thread Local·Batch 반영으로 공유 빈도를 줄입니다. NUMA에서는 Cross-Socket Coherence 비용이 더 클 수 있습니다. Padding으로 False Sharing을 줄일 수 있지만 Memory 효율은 줄어듭니다. Bulkhead처럼 상태를 분리하는 설계와도 맞닿습니다.
Coherence ≠ Consistency · 언제 보나
Cache Coherence는 같은 위치 `x`의 복사본 일관성입니다. Memory Consistency는 `data`·`ready`처럼 여러 연산이 다른 Core에서 어떤 순서로 보이는가입니다. Coherence만으로 멀티스레드 동기화가 끝나지 않습니다. Atomic·Lock 등 언어 규칙을 따릅니다. Protocol 구현은 Hardware 영역입니다. 일반 홈페이지는 우선순위가 낮고, 게임·DB·저지연·Runtime에서 중요합니다. Thread를 늘려도 처리량이 안 늘고 Shared Counter·Lock에 몰리면 측정·Benchmark로 확인합니다. Redis Key Hotspot도 「공유 상태 경쟁」 구조는 비슷하지만 계층이 다릅니다. DB Consistency·브라우저 Cache와도 다릅니다. SEO 전용 개념은 아닙니다. Write-Back·Dirty Line·Snooping·Directory·Bandwidth는 고성능 맥락에서 참고합니다. Immutable·Message Passing은 Shared Mutable Write를 줄이는 방향입니다. Context Switch만 줄여도 해결되지 않는 Shared Write Hotspot이 있을 수 있습니다.
자주 묻는 질문
Cache Coherence란?
여러 Core Cache에 같은 Memory 데이터가 있을 때 모순된 값을 쓰지 않도록 일관성을 유지하는 원리입니다.
읽기만 해도 문제인가?
읽기만 Shared면 비교적 단순합니다. Write가 발생할 때 일관성 관리가 중요해집니다.
MESI란?
Modified·Exclusive·Shared·Invalid로 Cache Line 상태를 설명하는 대표 Protocol 모델입니다.
False Sharing이란?
다른 변수를 수정해도 같은 Cache Line 때문에 불필요한 Coherence Traffic이 나는 현상입니다.
Atomic이면 Coherence가 없나?
아닙니다. 정확성은 보장하지만 Hot Atomic 변수에 Core가 몰리면 Contention은 남을 수 있습니다.
Memory Consistency와 같나?
아닙니다. Coherence는 같은 위치의 복사본, Consistency는 여러 Memory 연산의 관찰 순서를 다룹니다.
정리
Cache Coherence = 여러 Core Cache가 같은 데이터의 최신 상태를 맞추는 원리입니다. Write → 다른 Cache Invalid/갱신 → 최신 유지. Shared Write가 많으면 Coherence·Interconnect Traffic이 늘고 확장성이 나빠질 수 있어 공유 상태를 줄이는 것이 중요합니다. 그런데 Coherence가 `x`의 최신 값을 맞춰줘도 `data=100` 다음 `ready=true`처럼 여러 연산이 다른 Core에서 어떤 순서로 보이는지는 별도 규칙이 필요합니다. 현대 CPU·Compiler는 성능을 위해 Memory 순서를 최적화할 수 있습니다. 이처럼 여러 Core·Thread에서 Memory 읽기·쓰기가 어떤 순서로 관찰되는지를 정의하는 규칙을 Memory Consistency Model(메모리 일관성 모델)이라고 합니다.