프로젝트18. 파일로 캐싱 레디스로 캐싱 웹서버로 캐싱 CDN으로 캐싱

제 프로젝트는 사용자가 특정 차트를 고르면, 코스피 코스닥 전 종목의 과거(10년) 차트들을 모두 탐색하여 가장 유사한 차트 10개 정도를 골라 사용자에게 보여주는 것이 목표입니다.

 

비슷한 차트 검색기

 

비슷한 차트 검색기

 

---

 

캐싱에 진심인 남자

웹 프로젝트를 진행하며 항상 걱정해 오던 부분이 있습니다. 메모리 누수와 응답 시간입니다.

 

특히 응답 시간보다 걱정되었던 것이 메모리 누수인데, 파이썬으로 차트 이미지를 그리면 원인을 알 수 없는 메모리 누수가 발생하더군요. 물론 WSGI인 Gunicorn이 메모리 관리를 자동으로 해주어 누수가 발생하면 자동으로 프로세스를 종료해 줍니다. 하지만 이러면 응답 시간이 약간 늦어지죠.

 

또한 보통 사용자가 요청을 하면 Mysql에 저장된 주가 데이터를 조회해야 하는데, 이 데이터가 600만 개가 넘어 특정 주식의 주가 데이터 조회가 시간이 꽤 걸립니다.

 

그리고 저는 AWS EC2 인스턴스를 꽤 저렴한 걸 사용 중이기에 성능이 그리 좋지 않습니다.

 

어쨌든 여러 이유로 제 서버의 CPU에게 최대한 일을 시켜서는 안 됩니다. 이를 위해서는 최대한 캐싱을 활용해야 했습니다.

 

이번 포스팅에서는 제가 캐싱을 한 방법들에 대해 작성해 보겠습니다.

 

---

1. 파일로 만들어 스토리지에 캐싱

제 웹페이지는 여러 종류의 차트 이미지가 있습니다. 어떤 차트 이미지는 상호작용이 가능한 html div로 바꾸어 응답합니다. 차트에 마우스를 올리면 상세 정보 박스가 띄워집니다. 하지만 이런 이미지를 만드는 과정이 자원 소모가 꽤 심하더군요.

 

그래서 첫 번째로 요청된 요청된 차트 이미지는 파일로 저장하고, 이후 두 번째 응답부터는 이미지를 만들지 않고 파일로 저장되어 있는 이미지를 바로 반환하기 때문에 빠르게 응답할 수 있습니다.

 

---

2. 메모리 DB인 레디스로 캐싱

이미지 이외에 문자열이나 다른 자료구조 데이터 등도 최대한 메모리 DB인 레디스로 관리하였습니다. 물론 RAM도 그리 넉넉하지 않았기에 적용할 수 있는 한도 내에서 최대한 많이 레디스에 데이터를 저장합니다.

 

레디스 역시도 첫 응답은 직접 Mysql에서 데이터를 받아온 후 레디스에 저장하고, 두 번째 응답부터는 레디스에서 데이터를 가져옵니다. 이 역시도 응답시간이 매우 짧아지더군요.

 

---

3. 웹서버인 Nginx로 캐싱

웹서버도 정적 콘텐츠를 캐싱한다고 알고 있었습니다. 하지만 동적 콘텐츠라 하더라도 변경이 자주 일어나지 않으면 충분히 캐싱으로 응답 시간을 줄일 수 있습니다.

 

다행히 제 웹페이지는 콘텐츠 변경이 드물기 때문에 Nginx로 엄청난 응답 속도 향상을 맛볼 수 있었습니다.

 

앞서 설명했듯이 이미지는 파일로 캐싱하고, 이미지 외의 데이터는 레디스로 캐싱합니다. 하지만 이미지 외의 데이터가 캐싱되어 있어도 이미지 파일이 캐싱되어있지 않으면 응답이 느렸었습니다. 하지만 웹서버는 페이지의 모든 것을 캐싱해 놓더군요. 응답시간이 1초도 걸리지 않는 것 같습니다.

 

---

4. CDN 캐싱

CloudFlare를 사용하여 전세계에 캐시 서버를 두어 CDN 캐시를 적용합니다. 다행히 무료더군요.

 

 

 

 

5. 웹 브라우저 캐싱

이건 제가 직접 한 것은 아니지만, 웹 브라우저도 응답을 어느 정도 캐싱하는 것으로 알고 있습니다. 정확히 테스트는 하지 않았지만, 아마 이 부분도 응답시간을 꽤 줄여줄 것 같습니다.

 

---

결론

프로젝트 초기에 아무것도 없던 시절에는 모든 요청이 웹 애플리케이션으로 바로 갔기 때문에 메모리 누수가 나서 서버가 터지기도 하고 난리였습니다. 하지만 지금은 제 소중한 애플리케이션 서버를 최소 5개 이상의 방어막이 감싸고 있는 느낌입니다.

 

캐싱은 운영체제부터 시작해서 모든 IT관련 기술들에 빠지지 않는 중요한 요소라고 생각합니다.