아하 REST API 서버 개발 (10)
👋 정말 오랜만이호우!!! 요즘 저희 서비스 홍보하느라 아주 바쁜 나날을 보내고 있습니다.
어느새 강좌에 재미를 들렸는지… 그 바쁜 와중에도 여러분께 어떤 내용을 전달드릴까 고민하고, 기다리시진 않을까 걱정 했답니다.
여러분도 많이 기다리셨죠?
기분이 좋아서 잡담을 좀 길게 해봤습니다. 자 오늘은 많은 분들이 초반에 놓치고 시작하는 Cache 에 대해서 강의를 해볼까 합니다.
Cache
가끔씩 보면 초반 Cache 설계의 중요성을 잘 모르시는 분들이 계십니다.
나중에 트래픽 커지면 하면 돼
아닙니다. 정말 큰 경기도 오산입니다.
트래픽이 커진다는 것은 서비스 활성화에 가속도가 붙는다는 것이고 서비스 실행 속도는 항상 O(1) 보다 같거나 크기 때문에 그만큼 사용하는 리소스와 I/O 는 빨리 증가하게 됩니다.
그렇기 때문에 Cache 설계는 서비스가 아직 여유가 있을때 최대한 빡세게 해두셔야 나중이 편합니다. (공부랑 비슷합니다….응?)
사실 수백만 명이 사용할 정도로 서비스가 커지게 되면 오만데다 Cache 를 적용해도 모자를 판이지만 언제나 그렇듯이 처음에는 선택과 집중이 굉장히 중요하기 때문에, DB I/O 의 부하. 그 중에서도 직접 DB 에 read 하는 부하만 줄여주어도 굉장한 도움이 됩니다.
Redis
효율적인 Cache 를 운영하기 위해서, 여러가지 모듈을 사용하실 수 있는데 제가 사용해 본 결과 Redis 가 가장 사용하기도 쉽고 좋았습니다.
그리고 Redis 는 in memory database 로서, read 의 성능이 O(1) 을 보장받습니다.
다른 대안으로 Memcached 같은 것들도 추천드리니 역시 편하고 익숙하신 것을 사용하시면 될 것 같습니다.
Redis 를 사용하시기 위해서는 일단 Redis 를 설치하셔야 하는데 자세한 설치 방법을 모르시는 분들은 하기 링크를 통해 설치 후 강좌를 따라와 주시기 바랍니다.
Windows : https://hwigyeom.ntils.com/entry/Windows-%EC%97%90-Redis-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0-1
Mac : https://swiftymind.tistory.com/62
Linux : https://redis.io/topics/quickstart
설치를 하셨으면 express 에서 redis 에 접근할 수 있게 모듈을 설치해주셔야 합니다.
npm install redis bluebirdUser Cache
저번 강좌에 작성하신 src/middlewares/jwt.middleware.js 를 찬찬히 살펴봐 봅시다.
12 라인과 22라인을 보시게 되면 요청 헤더에 token 정보가 있고, token 이 유효하면 무조건 DB 에 select 쿼리를 요청합니다.
자 이 부분이 나중에 사용자가 수만명이 된다면 어떤일이 벌어질까요?
설령 그 요청이 사용자의 정보가 필요하지 않은데도 불구하고 모든 유효한 token 이 담긴 요청에 대해 DB 에 사용자 정보를 요청하게 되고 서버에 쓸데없는 부하를 주게 됩니다.
Cache 는 이런 부분에 적용하면 아주 큰 효과를 발휘합니다.
사용자를 캐싱 하는 방법을 한번 배워보도록 합시다.
src/caches/user.cache.js
자 이런식으로 작성하게 되면 현재 User Repository 를 사용하고 있는 모든 곳에 User Cache 를 대체할 수 있게 됩니다.
자 그럼 User Repository 를 사용하고 있는곳을 수정해 볼까요?
src/controllers/v1/auth.controller.js
src/models/user.model.js
src/middlewares/jwt.middleware.js
우리가 현재 작업한 것은 다른것이 아니고 고작 기존에 있던 userRepo 를 userCache 로 변경하였을 뿐이란 걸 기억하세요!
자 그럼 제대로 동작하는지 지금까지 작성한 test 를 한번 돌려볼까요?
npm test
이야~ 제대로 됐습니다!!! 자 그럼 마지막으로 실제로 Cache 가 잘 저장이 되고 있는지를 확인해봐야겠군요.
저는 Medis 라고 하는 Redis GUI 툴을 사용해서 조회해 보았습니다.
사실 간단히 userRepo -> userCache 변경한 것으로 굉장히 순조롭게 진행된것 같지만. 이것은 우리가 미리 CRUD 레이어와 controller 레이어를 분리 하였기에 가능한 것입니다.
만약 이런 레이어 분리 없이 모든 user model 에 대한 처리를 그때마다 models.User.find 로 처리했다면 수정사항이 정말 한 두 군데가 아니었을 것이란걸 아시겠죠?
이래서 코드의 유지 보수를 위해서는 처음부터 소스 구조의 설계를 잘 해야 하는 것입니다.
자 오늘은 어려운 주제를 이야기했습니다.
제 강의가 너무 빠르다고 느끼시는 분들은 밑의 소스를 받아보시고 천천히 제 설명을 끝까지 따라가며 이전 소스와 어떻게 변경 되었는지 복습하시면 이해가 가실 것입니다.
그래도 이해를 못하시겠다면 댓글, 페북 메시지 등으로 기탄없이 문의 주시면 아는 한도 내에서 잘 설명 드리도록 하겠습니다.
그럼 오늘도 즐거운 코딩하세요!
