TIL) 캐시 사용과 고민

캐시를 사용과 주의사항Permalink

컴퓨터 자원의 비대칭성Permalink

컴퓨터 자원의 비대칭성이란 컴퓨터 자원들이 가진 용량, 속도, 가격 면에서 균형이 맞지 않고 차이가 크다는 것을 의미합니다.

CPU 레지스터, CPU 캐시, RAM, SSD , HDD 순으로 용량은 내려가고 속도와 가격은 올라가게 됩니다.

캐시와 연관지어 보면 메모리 계층 구조의 속도와 비용의 차이를 말합니다.

• 빠를 수록: 비쌈, 용량 적음 ( 레지스터 > 캐시 > RAM)

• 느릴 수록: 저렴함, 용량 많음 ( 디스크 > 네트워크)

한 줄 요약

컴퓨터 자원은 용량, 가격, 크기의 균형이 맞지 않는 것을 컴퓨터 자원의 비대칭성이라고 한다.

캐시의 목적Permalink

캐시는 컴퓨터 자원의 비대칭성을 해결하기 위해 존재합니다.

캐시는 빠른 자원(캐시 메모리,RAM)과 느린 자원(디스크, 네트워크)의 속도 차이를 메우기 위해 존재합니다.

자주 쓰이는 데이터를 빠른 곳에 미리 저장해서 느린 자원에 접근하는 횟수를 줄이는 겁니다.

생각Permalink

데이터베이스는 디스크에 자료를 구조화하여 저장합니다.

클라이언트(서버)가 데이터베이스(외부 서버)에 요청하여 정보를 조회하려면 디스크에서 정보를 읽어 조합한 다음 그 결과를 데이터베이스 서버 메모리에 올리고 클라이언트에게 전달합니다.

데이터베이스에 접근할 수 있는 사용자의 인원 수가 정해져 있기 때문에 정보를 읽는게 오래 걸린다면 누적으로 접근하려는 사용자가 쌓이게 됩니다.

이러면 사용자는 응답을 받지 않고 대기하게 되며 데이터베이스에 부하가 커지게 됩니다.

이런 부하를 방지하고 자주 조회되는 정보를 빠르게 하여 접근하려는 사용자를 대기하지 않게 하고 데이터베이스 서버 부하를 줄일 수 있습니다.

고려사항Permalink

1. 캐시 미스율이 높은 경우 사용을 재검토할 수있어야합니다.

   캐시 미스율이 높다면 캐시 도입의 이점이 떨어지고 오히려 오버헤드만 늘어납니다

   • 왜 미스가 잦은지 원인을 분석할 수 있어야합니다.
   • 데이터 변경 빈도, 키 설계, 트래픽 패턴과 언제 캐시를 꺼야하는지(히트율을 근거로) 데이터를 확인해야합니다.

2. 캐시 미스로 성능 저하 시 대안을 설계해야합니다.

   캐시 레이턴시와 DB 레이턴시를 비교해야 합니다 Cache RTT + DB RTT > DB RTT

   폴백 전략(Fallback Strategy)이 필요할 수 있습니다.

3. 메모리 용량 제한으로 캐시 크기를 관리해야합니다.

4. 캐시 무효화 정책을 선택해야합니다.

5. JVM 공유 메모리 모니터링과 대응이 필요합니다.

   단일 서버에서 메모리를 캐시와 애플리케이션 서버가 공유하는 경우 서버가 죽지 않도록 대응해야합니다.

구현 방법Permalink

로컬 캐시Permalink

• @Cacheable
• Caffeine

단일 인스턴스에서 사용할 캐시를 적용할때 사용되는 방법입니다.

스프링에서는 기본적으로 ConcurrentMapCache을 사용합니다.

여러 메소드가 동시에 접근해서 수정하고 조회하다보니 동시성 문제를 제어하기 위해서 입니다.

• ConcurrentMapCache

  메모리 제한이나 자동적인 eviction 정책이 없으므로, 캐시 데이터가 누적되면 메모리 사용량 증가에 위험이 있습니다.

• Caffeine

  내부에서 메모리 사용량을 관리하며, 캐시 크기를 자동으로 데이터 무효화를 하기에 메모리 최적화에 유리합니다.

  고정된 메모리 환경이나 성능에 주의해야하는 서비스는 Caffeine이 적합하다고 생각됩니다.

간단하고 테스트를 위한 목적으로라면 기본 제공되는 ConcurrentMapCache이 적합할 수 있습니다.

실무 고민Permalink

현재 데이터베이스에서 주소 체계를 저장하여 사용자가 주소를 입력해야하는 경우 DB에서 Like 방식으로 조회를 하고 있습니다.

주소 체계는 한번 정해지면 수정사항이 일년에 한번이나 두 번정도로 크게 변동되는 일이 없습니다.

캐시 도입을 고민하는 이유는 캐시를 사용하지 않아도 응답 시간이 100~200ms로 괜찮고 DB 부하가 없다면, 굳이 캐시로 메모리 용량을 늘릴 필요가 있을까 싶었습니다.

상황 분석Permalink

현재 조건

• 데이터: 주소 체계 2만 개 (약 20,000건).

• 응답 시간: 캐시 없이 100~200ms.

• DB 상태: 부하 없음 (QPS나 CPU 사용률이 낮은 상태로 추정).

• 목적: 캐시로 메모리에 올려서 속도 개선 또는 DB 부하 감소.

캐시의 목적

1. 속도 개선: DB 조회(100ms) -> 캐시(0.1ms ~ 1ms)로 비대칭성 해결
2. DB 부하 감소 : 쿼리 호출 줄여 안정성 확보.
3. 확장성/비용 : 트래픽 증가를 대비할 수 있다. 클라우드 비용이 절감된다.

데이커 크기 추정

• 주소 데이터(예:{city: "서울", district: "강남구", neighborhood: "역삼동", code: "12345"})
• JSON 직렬화 시 약 200~500 바이트 가정.
• 약 2만건 * 500바이트 = 약 10MB

메로리 사용량: 10MB는 지금 서버에서 작은편

추가로 알아봐야하는 상황Permalink

지금 애플리케이션 서버의 메모리 사용량과 데이터베이서 서버의 메모리 사용량을 확인해야합니다.