API 캐싱

최근 면접을 보면서 API 캐싱에 대한 질문을 받았는데, 질문이 스프링에서는 API 캐싱을 어떻게 하냐는 질문이 였다. 순간 이해가 안되서 API캐싱이라는게 어떤 언어 기반의 프레임워크에서도 지원을 하는지를 고민하다가

인덱싱에 대한 언급을 해 요지 파악을 못한 부분이 있었는데 이에 복기겸 정리해본다.

 

일단 API 캐싱이던 할아버지 캐싱이던 캐쉬를 둘 위치를 정해둬야하는데, 캐시라는게 결국 어떤 데이터를

실제 처리하는 서비스 로직 이전에 달아서 같은 요청이 있는 경우 처리하지않고 주는 걸 의미하는데

이때부터 머리가 아파진다.

 

먼저 4가지 위치에서 할수 있는데, 프론트 , 인프라 , 백엔드, db에서 사용할 수 있다.

 

프론트라면

HTTP 헤더 기반: Cache-Control, ETag, Last-Modified 등을 활용해 브라우저나 앱이 응답을 재활용.

쓰는데 60초간 같은 요청이 들어오면 이전 정보를 줘서 처리하는거다.

물론, 실시간성이 보장되어야하는 경우는 이를 활용하지않고 정적인 데이터들을 사용하는것이 기조이다.

 

인프라에서 캐싱을 한다면 프록시나 게이트웨이에서 처리하는데, 물론 프록시서버가 게이트웨이로 쓰는 경우가 대다수 이기 때문에 함께 정리해본다면

대표적으로 쓰는 Nginx같은 서버라면 서버의 특정 URL - 엔드포인트에 TTL을 걸어서 특정 시간내에 같은 요청이 들어오게 되면 동일한 정보를 주는 방법도 가능하다.

 

백엔드라면 보통 서버를 지칭하는데 여기서는 redis같은 인메모리 DB를 사용해서, 처리하는 방법도 있다.

 

DB에서는 쿼리 결과를 redis DB에다가 함께 조회될때 넣어두고, 먼저 redis를 조회시키는 방법으로 쓴다.

근데 이게 머리가 아픈게, 시간으로 걸 경우에는 얼마나 시간을 걸어야할지 사용자가 동작하여 변경점이 발생한 경우 이를 처리하는 방향도 함께 고민해야해서 상당히 까다롭다.

 

다음 프로젝트 부터는 미리 이런점을 고려해서, 발주처측에 요청해서 협의를 봐둬야겠다는 생각이 들었고,

B2C서비스는 처음 해보다 보니 정말 까다롭고 어렵다는 생각이 든다.