캐시 읽기와 쓰기 전략

대부분 Cache-Aside 를 씁니다. 쓰기 경로가 단순하고 캐시 장애에 강합니다.

Write-Through 가 나은 경우는 쓰고 바로 읽는 패턴이 확실할 때입니다. 방금 쓴 값을 곧 조회하는 화면이면 첫 미스를 없앨 수 있습니다.

흔한 실수: Write-Through 를 정합성이 더 좋은 방식으로 답하는 것. 캐시와 DB 를 함께 쓰는 것은 원자적이지 않아서, 한쪽만 성공하는 창이 여전히 남습니다.

동시 쓰기에서 순서가 뒤바뀔 수 있기 때문입니다. 삭제는 여러 번 해도 결과가 같습니다.

요청 X 가 값을 10으로, Y 가 20으로 바꾸고 Y 가 나중이라고 해봅시다.

삭제가 순서에 둔감하다는 것이 핵심입니다.

그리고 안 읽힐 값을 미리 채우지 않는 이점도 있습니다. 갱신은 잦고 조회는 드문 데이터라면 갱신마다 캐시를 채우는 것이 낭비입니다.

흔한 실수: 삭제가 완벽하다고 보는 것. 조회가 DB 에서 옛 값을 읽은 뒤 삭제가 끼어들고, 그 다음 조회가 옛 값을 캐시에 채우는 좁은 창이 남습니다. 만료 시간을 함께 두어 수렴시킵니다.

캐시에만 쓰고 DB 반영을 미루는 방식이라, 캐시가 죽으면 아직 안 내려간 쓰기가 사라집니다.

그래서 실무에서는 잃어도 되는 값에만 씁니다. 게시글 조회수를 캐시에서 올리고 주기적으로 DB 에 반영하는 식입니다. 잔액이나 주문에는 쓰지 않습니다.

흔한 실수: 쓰기 성능만 보고 도입하는 것. 얻는 것은 쓰기 지연 감소이고 내주는 것은 지속성입니다. 그 데이터를 잃어도 되는지가 판단 기준입니다.

DB 로 계속 동작해야 하고, 동시에 DB 가 쓸려나가지 않게 막아야 합니다.

세 번째가 실제 장애의 관건입니다. 히트율 90%로 돌던 서비스가 캐시를 잃으면 DB 부하가 10배가 되어, 캐시 장애가 DB 장애로 번집니다.

흔한 실수: 캐시 조회 실패를 예외로 던져 요청을 실패시키는 것. 캐시는 없어도 동작해야 하는 계층입니다. 그리고 타임아웃을 길게 두면 캐시가 느릴 때 전체 응답이 그만큼 느려집니다.