230415 Today I Learned
실전 프로젝트 3주차. 오늘은 네이버 코테를 치고 끝나자마자 바로 프로젝트 중간발표를 했다. 오늘 TIL에는 발표를 하면서 알게된 캐시 전략에 대해 정리해보려 한다.
MySQL DB 생성시 에러
- 문제 : ERROR 1049 (42000): Unknown database db이름 에러 발생
MySQL 저장 경로를 바꾸고 DB 새로 생성시 계속 뜨는 에러다. - 해결 :
Create Database DB이름을 MySQL 워크벤치에서 쿼리를 날린다.
캐시 전략
-
캐시는 메모리를 사용하기 때문에 DB보다 훨씬 빠르게 데이터를 응답할 수 있다. 하지만 메모리의 용량은 DB보다 작기 때문에 모든 데이터를 메모리에 올려놓을 수 없다.
따러서 어떤 종류의 데이터를 얼만큼, 얼마동안 캐시에 저장할지에 대한 전략이 필요하다. -
cache hit : 캐시에 데이터가 있을 경우 바로 가져온다. 응답속도가 빠르다.
-
cache miss : 캐시에 데이터가 없을 경우 DB에서 가져온다. 응답속도가 느리다.
읽기 전략
Look Aside
: 서버가 캐시를 먼저 조회하고 cache miss시 DB를 조회
-
데이터를 찾을 때 캐시에 저장된 데이터가 있는지 우선적으로 확인한다. 없으면 DB 조회
-
캐시와 DB가 분리되어 원하는 데이터만 별도로 캐시에 저장한다.
-
캐시에 장애가 생기더라도 DB에서 데이터를 가져오면 된다.
-
반복적인 읽기가 많은 호출에 적합하다.
-
일반적으로 사용되는 사용되는 기본 전략이다. 데이터 정합성 문제가 발생할 수 있다.
Read Through
: 서버가 캐시에서만 데이터를 조회하고 cache miss시 캐시가 DB에 데이터를 조회해 자체 업데이트
-
캐시에서만 데이터를 읽어온다. DB에 접근을 최소화 한다.
-
데이터 동기화를 캐시 제공자나 라이브러리에 위임한다.
-
캐시에 장애가 생기면 서비스 이용에 차질이 생길 수 있다.
-
데이터 동기화가 상시로 이루어져 정합성 문제는 없다. 다만 look aside보다 느리다
쓰기 전략
Write Back(Write Behind)
: 데이터를 저장할 때 캐시에 먼저 저장해서 모았다가 특정 시점에 DB에 쓰기를 한다.
-
캐시와 DB를 비동기상태로 유지하다가 일정 주기로 한번에 DB에 쓴다.
-
쓰기 쿼리가 줄고 부하가 줄어든다. write가 빈번할 때 쓰면 좋다.
-
다만 DB에 쓰기전에 캐시에 오류가 발생하면 데이터가 영구 소실된다.
Write Through
: 데이터를 캐시에 저장할 다음 바로 DB에 저장한다(모으지 않고 바로바로)
-
DB 동기화 과정을 캐시에 위임한다
-
캐시와 DB가 항상 동기화 되어있어 캐시의 데이터는 항상 최신이다.
-
데이터 일관성을 유지할 수 있어 안정적이다.
-
하지만 매 요청마다 두 번의 Write 가 발생해 성능은 떨어진다.
위의 두 패턴은 모두 자주 사용하지 않는 데이터가 저장될 수 있어 TTL로 expire을 정해야한다.
Write Around
: 모든 데이터를 DB에 저장하고 cache miss가 발생했을때만 DB와 캐시에 데이터를 저장한다.
-
위의 방법보다 빠르다.
-
하지만 cache miss가 일어났을때만 동기화가 진행되기때문에 그전 까진 정합성 문제가 있다.
-
따라서 DB에 수정이 있을 때 마다 캐시를 삭제하거나 변경해야 하며 캐시의 expire를 짧게 조절해야 한다.
캐시 유의사항
-
자주 사용되면서 자주 변경되지 않는 데이터를 캐싱해야 한다.
-
항상 데이터의 유실이나 정합성이 깨질 수 있는 점을 고려해야 한다.
-
중요한 정보, 민감한 정보는 저장하지 않는 것이 좋다.
