Heap 캐시 vs Offheap 캐시 - 캐시 히트인데 왜 느릴까?

배경

얼마 전 업무에서 캐시를 적용했는데도 성능이 나아지지 않는 이상한 상황을 겪었다.

캐시 히트는 정상이었다. 근데 느렸다.

 

문제는 8500개짜리 Map을 캐시에서 꺼내는 로직에 있었다. getDataMap()은 분명 캐시에서 응답하고 있었는데, 요청이 몰릴 때마다 성능 저하가 반복됐다.

@Cacheable(value = "dataCache", key = "'dataMap'")
public Map<String, String> getDataMap() {
    return dataRepository.findAll();
}

 

 

원인을 파고들다 보니 내가 캐시 설정 파일에서 무심코 <offheap>을 쓰고 있었다는 걸 알게 됐다.

<cache alias="dataCache">
    <resources>
        <offheap unit="MB">50</offheap>
    </resources>
</cache>

 

그리고 그때 처음으로 제대로 이해했다. Heap 캐시와 Offheap 캐시는 동작 방식 자체가 다르다는 걸.

이 글은 그 과정에서 정리한 내용이다.

 

 

 

---

Heap과 Offheap의 차이

JVM 메모리 구조

두 캐시를 이해하려면 JVM의 메모리 구조를 먼저 봐야 한다.

┌─────────────────────────────────────────────┐
│                  JVM Process                │
│                                             │
│  ┌─────────────────┐   ┌─────────────────┐  │
│  │   Heap 영역      │   │  Offheap 영역   │  │
│  │  (GC 관리 대상)  │   │  (GC 관리 외부) │  │
│  │                 │   │                 │  │
│  │  Java가 생성한   │   │  Ehcache가      │  │
│  │  모든 객체       │   │  직접 관리하는  │  │
│  │                 │   │  네이티브 메모리 │  │
│  └─────────────────┘   └─────────────────┘  │
└─────────────────────────────────────────────┘

• Heap: new HashMap() 같이 Java가 생성하는 모든 객체가 올라가는 공간. GC가 관리한다.
• Offheap: JVM 외부의 네이티브 메모리. GC의 관리 범위 밖이다.

 

 

 

Heap 캐시의 동작 방식

요청 → Ehcache → HashMap 객체 참조(주소) 반환 → 끝

 

Heap 캐시는 객체를 Heap에 그대로 올려두고, 캐시 히트 시 메모리 주소만 전달한다. 복사도, 변환도 없다.

그냥 "거기 있어" 하고 주소를 가리키는 것과 같다.

 

 

 

Offheap 캐시의 동작 방식

Offheap은 다르다.

[저장 시]
HashMap 객체 → 직렬화 → [바이트 배열] → Offheap 메모리 저장

[조회 시]
Offheap 메모리 → [바이트 배열] → 역직렬화 → 새 HashMap 객체 생성

 

캐시 히트가 일어날 때마다 역직렬화가 발생한다. 이 부분이 핵심이다.

 

 

 

왜 Offheap은 직렬화가 필요할까?

JVM Heap의 Java 객체는 단순한 바이트 덩어리가 아니다.

HashMap 객체 (JVM Heap 내부)

┌──────────────────────────────────┐
│  Object Header                   │  ← 클래스 메타데이터 포인터
│  (class pointer, hash, lock...)  │     GC 정보, 동기화 락 등
├──────────────────────────────────┤
│  table (Entry[] 참조)            │  → 다른 객체를 가리키는
│  size: 8500                      │    메모리 주소(참조)
└──────────────────────────────────┘
              ↓
    ┌─────────────────┐
    │  Entry 객체들    │
    │  key → "item1"  │
    │  val → "100"    │
    └─────────────────┘

 

객체들이 메모리 주소(참조) 로 서로 연결된 그래프 구조다.

이 구조를 Offheap으로 그대로 가져갈 수 없는 이유가 세 가지 있다.

 

 

 

이유 1 — 참조(포인터)는 JVM Heap 안에서만 유효하다

JVM Heap                     Offheap (Native Memory)
┌──────────────┐             ┌──────────────────────┐
│  HashMap     │             │                      │
│  table → 0x4A2F ──────────→│ 0x4A2F ???           │
│              │             │ (이 주소가 여기선      │
└──────────────┘             │  아무 의미가 없음)     │
                             └──────────────────────┘

 

 

 

이유 2 — GC가 객체를 이동시킨다

GC 실행 전          GC 실행 후 (메모리 압축)
HashMap: 0x4A2F  →  HashMap: 0x1B3C  (주소가 바뀜!)

 

Offheap에 주소를 저장해뒀다가 GC 후에 꺼내면 엉뚱한 곳을 가리키게 된다.

 

 

 

이유 3 — Object Header는 JVM 전용 구조다

Object Header에는 클래스 정보 포인터, GC 마킹 비트, 동기화 락 정보가 담겨 있는데, JVM 외부에서는 해석이 불가능하다.

그래서 직렬화로 "주소 없는 순수 데이터"로 변환해서 저장하는 것이다.

 

직렬화 = 참조 그래프를 끊고 → 평탄한 바이트 배열로

HashMap { "item1"→"100", "item2"→"200" }
  (참조로 연결된 객체 그래프)
          ↓ 직렬화
[타입정보 | "item1" | "100" | "item2" | "200" | ...]
  (자기완결적인 순수 바이트 배열)
          ↓ Offheap 저장 가능

 

역직렬화 시에는 이 바이트 배열을 읽어 JVM Heap에 새 객체를 새로 생성한다.

 

 

 

정리 — 캐시 히트라도 Offheap은 항상 역직렬화한다

내 케이스에서 문제가 됐던 이유가 바로 이거다.

[Offheap 캐시 조회 시]
Offheap 메모리 → [바이트 배열] → 역직렬화 → 새 HashMap 객체 생성
                                    ↑ 히트마다 이 비용 반복 발생

processRequest()는 요청마다 호출된다. 8500개짜리 Map을 요청마다 역직렬화하면 당연히 느리다.

 

 

 

Heap vs Offheap 선택 기준

	Heap 유리	Offheap 유리
객체 크기	작을 때 (~수 MB 이하)	매우 클 때 (수백 MB~GB)
조회 빈도	높을 때	낮을 때
GC 상황	Stop-the-world 문제 없을 때	GC 부담이 심할 때
Heap 메모리	여유 있을 때	부족할 때

 

내 케이스는 약 300KB짜리 Map, 고빈도 조회 → Heap이 적합한 상황이었다.

 

 

 

---

자바 스프링에서의 구현

Ehcache 설정에서 <offheap>을 <heap>으로 바꾸는 것만으로 해결됐다.

 

<cache alias="dataCache">
    <key-type>java.lang.String</key-type>
    <value-type>java.util.HashMap</value-type>
    <expiry>
        <ttl unit="hours">1</ttl>
    </expiry>
    <resources>
        <heap unit="entries">1</heap>
    </resources>
</cache>

unit="entries"는 바이트 크기가 아닌 키-값 쌍의 개수로 용량을 제한하는 단위다. 캐시 키가 고정 문자열 하나뿐이라 엔트리가 항상 1개 → entries = 1로 설정했다.

 

@Cacheable(value = "dataCache", key = "'dataMap'")
//                                     ↑ 항상 고정 → 엔트리 1개
public Map<String, String> getDataMap() {
    return dataRepository.findAll();
}

 

이걸로 캐시 히트 시 역직렬화 없이 바로 객체 참조를 반환하게 됐고, 성능 이슈가 해결됐다.

 

 

 

---

마무리

"캐시 히트 = 빠름"이라고만 생각하고 있었는데, Offheap의 경우 히트 시에도 역직렬화 비용이 매번 발생한다는 걸 처음으로 제대로 이해한 계기였다.

 

설정 파일 한 줄(<offheap> → <heap>)만 바꿨는데 성능이 개선됐다. 그 한 줄의 의미를 몰랐던 게 문제였다.

 

캐시를 선택할 때는 객체 크기와 조회 빈도를 기준으로 생각해야겠다는 교훈을 얻었다.