[Server #1] 내가 이해하는 Cache(캐시) <시작>

Restful API 에 대해 이해하고, DB query 를 통해 실질적인 API 를 구현할 수 있게 되었을 때 필자의 개발멘토는 필자에게 아래와 같이 이야기해주었다.


“이제는 속도와 비용을 고민해야한다”

그리고 나서, 약 30분간 캐시(Cache)라는 것은 무엇이고, 핵심 개념인 “Hit ratio”가 왜 중요한지, 그리고 그것과 관련해서 검토/연구해야 하는 기술이 무엇인지에 대해 설명해주었다.

결론은 단순했다.

클라이언트로부터 요청이 왔을 때 raw 데이터가 저장된 DB 로부터 Select 쿼리를 통해 데이터를 뽑고, 가공해서 제공할 것인가, 아니면 다른 방법을 사용해서 더 빠르게 유저에게 데이터를 전달할 것인가에 대한 고민이었다.


얼마전 하나의 API 를 개발하는 과정에서 AWS CDN 서비스인 Cloudfront 를 적용하면서 어떻게 하면 더 빠르게, 그리고 더 싸게 클라이언트에게 데이터를 전달할 수는 있을까라는 고민을 시작하게 되었다.

그리고 “캐시"라는 개념을 가지고 서비스를 구성하고 있는 아키텍처 전반을 검토해보기 시작했다.

“내가 이해한” 캐시(Cache) 개념이 적용되고 있는 부분은 아래와 같았다.

  1. Cloudfront 에서 Cache Server 의 역할을 해주고 있다?
  2. API Gateway 자체에서도 Cache 설정이 있다?
  3. C# 프로젝트가 올라간 IIS(웹서버)에서 cache 설정이 있다?(NginX 처럼)
  4. RDS 의 DB엔진(MySQL InnoDB)에서 쿼리가 cache 를 타고 있다?
  5. Client 에 전달한 정적인 파일의 응답 헤더(response header)의 캐시 설정(Cache-Control)을 통해 최대수명(max-age), 혹은 만료일(Expires) 설정을 통해 Client Cache(브라우저 캐시) 를 구현하고 있다?

추가로

  1. Memcached 혹은 Redis 를 활용해서 DB call 이 있을 때 RDS 보다 더 빠르게 데이터를 제공할 수 있다?(AWS Elasticache)

NginX(웹서버)에 캐시서버 역할 부여하기(config 설정): 출처 링크

물론 캐시가 만능은 아닐 것이다. 비용도 비용이지만, 제대로 사용하지 못하면, 최신으로 업데이트 되지 않은 “틀린” 데이터를 클라이언트에게 제공할 수도 있고 비용이 최적화되지 않을 수도 있다. 때문에 앞으로, 위에서 적은 요소들에 대해서 하나씩 정리해보려고 한다.

0.1 초의 싸움이다.

어떻게든 DB 에 직접 쿼리를 때리지 않도록 (서비스의 장애가 대부분 DB 에서 일어나니까) 좋은 서비스, 아키텍처를 고민해보아야겠다.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.