캐시(1) - 캐시와 CDN 캐시

안녕하세요. 좋은 하루입니다. 오늘은 비오기전에 나는 냄새가 나네요. 바람도 많이불고, 춥지는 않지만 반팔만 입고 다니기엔 서늘한 날씨 같네요. 저번 시간에는 API에 대해서 학습을 했습니다. 이번 시간에는 캐시에 대해 알아볼 예정입니다. 아마 3편으로 짧게 학습하고 웹 보안 지식에 대해 학습할 것 같습니다. 그럼 시작하겠습니다.

---

캐시라는 말은 컴퓨터를 이용하는 사용자라면 한번 쯤 들어보셨을 겁니다.

브라우저 캐시를 삭제한다거나, 캐시 메모리라는 표현을 들어본 경험도 있을 것입니다.

 

그렇다면 캐시란 무엇일까요?

 

캐시(Cache)

캐시는 자주 사용되거나 다시 사용될 가능성이 높은 데이터를 더 빠르게 접근할 수 있는 위치에 임시로 저장해두는 방식입니다.

컴퓨터 구조엣는 CPU가 메모리에 매번 접근하는 비용을 줄이기 위해 캐시 메모리를 사용합니다.

자주 사용하는 명령어나 데이터를 CPU 가까이 저장해두면 필요할 때 더 빠르게 가져올 수 있기 때문입니다.

 

하지만 캐시는 하드웨어에서만 사용되는 개념은 아닙니다.

웹 서비스에서도 캐시는 매우 중요한 역할을 합니다.

이미지, CSS, JavaScript 파일, API 응답, DB 조회 결과처럼 반복적으로 사용되는 데이터를 매번 새로 요청하거나 계산하지 않고 저장해두면 응답 속도를 줄이고 부하를 낮출 수 있습니다.

 

이번 글에서는 하드웨어 캐시를 깊게 다루기보다 웹 서비스 관점에서 캐시가 왜 필요한지 살펴보도록 합시다.

 

하드웨어 캐시, 캐시 메모리에 대한 자세한 설명을 원하시는 분들은 아래 글을 참조해주시면 좋겠습니다.

컴퓨터의 구조 - 메모리

 

 

웹 캐시(Web Cache)

앞서 살펴본 하드웨어 캐시는 CPU가 자주 사용하는 데이터를 더 빠르게 접근하기 위한 구조였습니다.

웹에서도 같은 원리가 사용됩니다.

 

웹 캐시는 웹 서비스에서 자주 요청되거나 다시 사용될 가능성이 높은 데이터를 더 빠르게 접근할 수 있는 위치에 임시로 저장해두는 방식입니다.

이미지, HTML, CSS, JavaScript 파일과 같은 정적 리소스뿐 아니라 API 응답, DB 조회 결과처럼 반복적으로 사용되는 데이터도 캐싱 대상이 될 수 있습니다.

 

예를 들어 사용자가 같은 이미지를 여러번 요청할 때마다 원본 서버에서 이미지를 다시 내려주는 것은 비효율적입니다.

이때 이미지 파일을 브라우저,CDN 서버, 프록시 서버 등에 저장해두면 이후 요청에서는 원본 서버까지 가지 않고 저장된 데이터를 재사용할 수 있습니다.

 

즉, 웹 캐시의 핵심은 "같은 데이터를 매번 새로 가져오지 않고, 가까운 곳에 저장해뒀다가 재사용하는 것"입니다.

이를 통해 응답 속도를 줄이고 서버와 데이터베이스의 부하를 낮출 수 있습니다.

 

웹 캐시의 장단점

캐시는 반복적으로 사용되는 데이터를 빠르게 재사용할 수 있도록 도와주지만 원본 데이터가 변경되었는데 캐시 데이터가 갱신되지 않으면 오래된 데이터를 전달할 수 있고, 민감한 데이터가 잘못 저장되면 보안 문제가 발생할 수도 있습니다. 따라서 캐시는 성능 개선 효과와 함께 주의할 점도 함께 이해해야 합니다.

 

장점

1. 응답 속도를 줄일 수 있습니다.
   • 이미 저장된 데이터를 재사용하기 때문에 매번 원본 서버나 데이터베이스에 접근하지 않아도 됩니다.
2. 서버 부하를 줄일 수 있습니다.
   • 반복 요청을 캐시가 대신 처리하면 원본 서버가 직접 처리해야 하는 요청 수가 줄어듭니다. 
3. 데이터베이스 접근 횟수를 줄일 수 있습니다.
   • 자주 조회되지만 자주 변경되지 않는 데이터를 캐싱하면 같은 요청마다 DB를 다시 조회하지 않아도 됩닏.
4. 네트워크 비용을 줄일 수 있습니다.
   • 이미지, CSS, JavaScript, 동영상 같은 정적 리소스를 캐싱하면 원본 서버에서 매번 파일을 전송하지 않아도 됩니다.

단점

1. 오래된 데이터가 전달될 수 있습니다.
   • 원본 데이터가 변경되었는데 캐시가 갱신되지 않으면 사용자는 최신 데이터가 아닌 이전 데이터를 볼 수 있습니다.
2. 캐시 무효화가 어렵습니다.
   • 캐시를 언제 삭제하고 갱신할지 정해야 하며, 이 기준이 적절하지 않으면 성능 문제나 데이터 불일치 문제가 발생할 수 있습니다.
3. 민감한 데이터는 캐싱하면 위험할 수 있습니다.
   • 개인정보, 인증 토큰, 결제 정보처럼 사용자별로 다르거나 노출되면 안되는 데이터는 캐싱 대상에서 제외해야 합니다.
4. 저장 공간을 사용합니다.
   • 캐시는 데이터를 임시로 저장하므로 메모리나 디스크 공간을 사용하면 과도하게 쌓이면 관리 비용이 증가할 수 있습니다.

이처럼 캐시는 성능 개선에 도움을 주지만, 저장 위치와 대상에 따라 고려해야할 점이 달라집니다. 그렇다면 웹 서비스에서는 캐시가 어떤 위치에서 사용될까요?

 

웹 캐시의 동작 방식

웹 캐시는 하나의 위치에서만 동작하는 것이 아닌 브라우저, CDN, 서버 내부 등 여러 계층에서 순차적으로 확인될 수 있습니다.

위 그림은  웹 캐시가 여러 계층에서 어떻게 도작하는지를 나타낸 것입니다.

동작 과정

1. 사용자의 요청이 들어오면 먼저 브라우저 캐시를 확인합니다.
   • 브라우저에 필요한 데이터나 리소스가 저장되어 있다면 요청하지 않고 캐시된 데이터를 바로 사용합니다. 예를 들어 이미지, CSS, JavaScript 파일 등이 브라우저에 저장되어 있다면 다시 다운로드하지 않고 재사용할 수 있습니다.
2. 브라우저 캐시에 데이터가 없다면 CDN 캐시를 확인합니다.
   • CDN에 요청한 리소스가 저장되어 있다면 원본 서버까지 요청하지 않고 CDN이 사용자에게 응답합니다. 이 경우 사용자는 가까운 CDN 서버에서 리소스를 전달받을 수 있습니다.
3. CDN 캐시에도 데이터가 없다면 서버 사이드 캐시를 확인합니다.
   • 요청이 원본 서버까지 전달되면 서버는 먼저 Redis와 같은 서버 사이드 캐시에 필요한 데이터가 있는지 확인할 수 있습니다. 서버 사이드 캐시에 데이터가 있다면 DB를 조회하지 않고 캐시된 데이터를 반환합니다.
4. 서버 사이드 캐시에도 데이터가 없다면 DB를 조회합니다.
   • 브라우저, CDN, 서버 사이드 캐시 어디에도 필요한 데이터가 없다면 최종적으로 DB를 조회합니다. 이 경우에는 캐시를 사용할 수 없기 때문에 원본 데이터를 직접 가져오는 과정이 필요합니다.
5. DB에서 조회한 결과를 캐시에 저장합니다.
   • DB에서 가져온 결과는 이후 같은 요청이 들어왔을 때 더 빠르게 응답할 수 있도록 캐시에 저장할 수 있습니다. 이를 통해 다음 요청부터는 DB까지 접근하지 않고 캐시 데이터를 재사용할 수 있습니다.
6. 사용자에게 응답합니다.
   • 각 단계에서 캐시된 데이터를 찾았다면 해당 데이터를 바로 사용자에게 응답하고, 캐시에 데이터가 없어서 DB를 조회한 경우에는 조회 결과를 저장한 뒤 사용자에게 응답합니다.

 

즉,  웹 캐시는 동작하는 위치와 저장 대상에 따라 여러 종류로 나눌 수 있습니다.

 

웹 캐시 종류

종류	저장 위치	주요 캐싱 대상
브라우저 캐시	사용자 브라우저	HTML, CSS, JS, 이미지, 폰트
DNS 캐시	브라우저, OS, DNS 서버	도메인과 IP 주소 매핑 결과
CDN 캐시	CDN 엣지 서버	이미지, CSS, JS, 동영상
서버 사이드 캐시	애플리케이션 서버, Redis 등	DB 조회 결과, API 응답, 세션
프록시 캐시	클라이언트와 서버 사이의 프록시 서버	요청/응답 데이터

 

다양한 웹 캐시 중에서도 정적 리소스 전달과 가장 밀접한 CDN 캐시를 중심으로 살펴보겠습니다.

 

CDN(Content Delivery Networks)

CDN은 이미지, CSS, JavaScript, 동영상과 같은 정적 리소스를 사용자와 가까운 서버에서 전달하기 위한 분산 서버 네트워크입니다.

기존에는 사용자의 요청이 원본 서버(Origin Server)까지 직접 도달해야 했지만, CDN을 사용하면 여러 지역에 분산된 서벅 원본 서버의 콘텐츠를 대신 전달할 수 있습니다.

 

즉, CDN은 하나의 중앙 서버가 모든 요청을 처리하는 방식이 아닌 여러 지역에 분산된 서버가 사용자와 가까운 위치에서 콘텐츠를 제공하도록 돕는 구조라고 볼 수 있습니다.

위 그림은 CDN이 없는 경우와 CDN이 있는 경우를 나타낸 것입니다.

왼쪽 그림처럼 CDN이 없는 경우에는 모든 사용자의 요청이 하나의 원본 서버로 직접 전달됩니다. 이 경우 사용자가 많아질수록 원본 서버에 요청이 집중되고, 서버와 사용자의 거리가 멀수록 응답 속도도 느려질 수 있습니다.

반면 오른쪽 그림처럼 CDN을 사용하면 여러 지역에 분산된 서버가 원본 서버의 콘텐츠를 대신 전달할 수 있습니다. 사용자는 자신과 가까운 CDN 서버에서 리소스를 전달받을 수 있기 때문에 더 빠르게 응답받을 수 있으며, 원본 서버가 직접 처리해야 하는 요청 수도 줄어들게 됩니다.

즉, CDN은 콘텐츠를 사용자와 더 가까운 위치에서 제공함으로써 응답 속도를 개선하고, 서버 부하를 분산시키는 역할을 합니다.

 

CDN이 필요한 이유

1. 사용자와 가까운 서버에서 콘텐츠를 제공할 수 있습니다.
   • 사용자는 원본 서버가 아닌 가까운 CDN 서버에서 리소스를 전달받을 수 있기 때문에 응답 시간이 줄어듭니다.
2. 원본 서버의 부하를 줄일 수 있습니다.
   • 이미지, CSS, JavaScript, 동영상과 같은 정적 리소스를 CDN이 대신 제공하면 원본 서버는 모든 요청을 직접 처리하지 않아도 됩니다.
3. 대규모 트래픽에 더 유연하게 대응할 수 있습니다.
   • 특정 시점에 많은 사용자가 동시에 접속하더라도 요청이 여러 CDN 서버로 분산되므로 서비스 안정성을 높일 수 있습니다.
4. 전 세계 사용자에게 일관된 성능을 제공할 수 있습니다.
   • 서비스 사용자가 여러 지역에 분산되어 있더라도 각 지역에 가까운 CDN 서버를 통해 콘텐츠를 전달할 수 있습니다.

 

그렇다면 CDN 서버는 단순히 콘텐츠를 중계만 하는 것일까요?

실제로 CDN은 원본 서버의 리소스를 사용자와 가까운 서버에 저장해두고, 이후 동일한 요청이 들어왔을 때 저장된 리소스를 재사용할 수 있습니다. 이러한 방식이 바로 CDN 캐시입니다.

 

CDN 캐시

CDN 캐시는 원본 서버의 리소스를 CDN 엣지 서버에 저장해두고, 동일한 요청이 들어왔을 때 원본 서버 대신 CDN 서버가 응답하는 방식입니다.

앞서 CDN은 사용자와 가까운 서버에서 콘텐츠를 전달하기 위한 분산 네트워크라고 설명했습니다. CDN 캐시는 이 CDN 서버가 단순히 콘텐츠를 전달하는 것에서 끝나지 않고, 원본 서버에서 가져온 리소스를 일정 시간 동안 저장해두었다가 이후 요청에서 재사용하는 구조입니다.

예를 들어 사용자가 웹 사이트의 로고 이미지나 CSS 파일을 요청했다고 가정해보겠습니다. 해당 리소스가 CDN 서버에 이미 저장되어 있다면, 요청은 원본 서버까지 전달되지 않고 CDN 서버에서 바로 응답됩니다. 이 경우 사용자는 더 가까운 서버에서 리소스를 전달받을 수 있기 때문에 응답 속도가 줄어듭니다.

반대로 CDN 서버에 해당 리소스가 없다면, CDN은 원본 서버로 요청을 보내 리소스를 가져옵니다. 이후 가져온 리소스를 CDN 서버에 저장하고 사용자에게 응답합니다. 이렇게 저장된 리소스는 이후 동일한 요청이 들어왔을 때 다시 사용할 수 있습니다.

이처럼 CDN 캐시는 사용자의 요청이 원본 서버까지 도달하는 횟수를 줄이고, 정적 리소스를 더 빠르게 전달할 수 있도록 도와줍니다. 특히 이미지, CSS, JavaScript, 폰트, 동영상처럼 여러 사용자가 반복적으로 요청하고 자주 변경되지 않는 리소스에 효과적입니다.

 

CDN 캐시의 작동원리

위 그림은 사용자가 이미지 리소스를 요청했을 때 CDN이 어떻게 동작하는지를 나타낸 것입니다.

 

1. 사용자가 이미지 리소스를 요청합니다.
   • 사용자는 'images.mydomain.com/logo.png'와 같은 주소로 이미지 파일을 요청합니다. 이때 사용자는 원본 서버의 실제위치를 직접 할 필요가 없습니다.
2. DNS는 해당 도메인이 CDN으로 연결되도록 안내합니다.
   • 요청한 도메인은 DNS 설정을 통해 CDN 주소와 연결됩니다. 일반적으로 CNAME 설정을 통해 'images.mydomain.com'이 CDN에서 제공하는 도메인으로 연결됩니다.
3. CDN에 리소스가 없으면 원본 서버에서 가져옵니다.
   • CDN 서버에 'logo.png' 파일이 이미 캐시되어 있다면 바로 사용자에게 응답할 수 있습니다.
   • 하지만 CDN에 해당 파일이 없다면 원본 서버로 요청을 보내 리소스를 가져옵니다. 이를 Cache Miss 상황이라고 볼 수 있습니다.
4. CDN은 가져온 리소스를 저장하고 사용자에게 응답합니다.
   • CDN은 원본 서버에서 가져온 'logo.png' 파일을 자신의 캐시에 저장한 뒤 사용자에게 응답합니다.
   • 이후 다른 사용자와 같은 이미지를 요청하면 원본 서버까지 다시 가지 않고 CDN에 저장된 파일을 바로 응답할 수 있습니다.

 

즉, CDN 캐시는 처음 요청에서는 원본 서버에서 리소스를 가져와야 할 수 있지만, 이후 동일한 요청부터는 CDN 서버에 저장된 리소스를 재사용할 수 있습니다. 이를 통해 원본 서버의 요청 수를 줄이고, 사용자에게 더 빠르게 정적 리소스를 전달할 수 있습니다.

 

CDN 캐시에 적합한 리소스

CDN 캐시는 모든 데이터를 저장하는 데 적합한 것은 아닙니다. CDN 캐시는 여러 사용자가 반복적으로 요청하고, 자주 변경되지 않으며, 사용자마다 응답 내용이 달라지지 않는 리소스에 적합합니다.

 

대표적인 예로 이미지, CSS 파일, JavaScript 파일, 폰트 파일, 동영상, 다운로드 파일 등이 있습니다. 이러한 리소스는 한 번 배포되면 일정 시간 동안 동일하게 사용되는 경우가 많고, 여러 사용자가 공통으로 요청하는 경우가 많습니다.

 

예를 들어 웹 사이트의 로고 이미지나 공통 CSS 파일은 여러 페이지에서 반복적으로 사용됩니다. 이런 파일을 CDN에 캐싱해두면 사용자가 페이지를 이동할 때마다 원본 서버에서 다시 다운로드하지 않아도 됩니다. CDN 서버가 저장해둔 리소스를 대신 응답할 수 있기 때문에 페이지 로딩 속도를 줄이고, 원본 서버의 트래픽도 낮출 수 있습니다.

 

특히 이미지나 동영상처럼 파일 크기가 큰 리소스는 CDN 캐시의 효과가 더 크게 나타날 수 있습니다. 원본 서버가 매번 대용량 파일을 전송하지 않아도 되므로 네트워크 비용과 서버 부하를 줄이는 데 도움이 됩니다.

 

반면 사용자마다 결과가 달라지는 데이터는 CDN 캐시에 적합하지 않습니다.

 

예를 들어 마이페이지 정보, 장바구니 정보, 주문 내역, 결제 정보, 인증 토큰처럼 개인별로 달라지거나 민감한 데이터는 여러 사용자에게 공통으로 제공되면 안됩니다. 이러한 데이터는 CDN 캐시 대상에서 제외해야 합니다.

 

CDN캐시 사용 시 주의점

CDN 캐시는 정적 리소스를 빠르게 전달하는 데 효과적이지만, 캐시에 저장된 데이터가 항상 최신 상태라는 보장은 없습니다. 따라서 CDN 캐시를 사용할 때는 어떤 데이터를 얼마나 오래 저장할지, 변경된 데이터를 어떻게 반영할지 함께 고려해야 합니다.

 

1.  변경된 파일이 바로 반영되지 않을 수 있습니다.

예를 들어 'main.js' 파일을 수정했는데 CDN 서버에 이전 버전의 'main.js'가 남아 있다면, 사용자는 한동안 수정 전 JavaScript 파일을 전달받을 수 있습니다. 이 경우 실제 배포는 되었지만 사용자 화면에는 변경 사항이 바로 보이지 않는 문제가 발생할 수 있습니다.

 

2. TTL 설정이 필요합니다.

TTL(Time To Live)은 캐시된 데이터를 얼마 동안 유효한 데이터로 볼지 정하는 시간입니다. TTL이 너무 길면 오래된 데이터가 계속 제공될 수 있고, 너무 짧으면 캐시를 자주 갱신해야 하므로 CDN 효과가 줄어들 수 있습니다. 따라서 리소스의 변경 빈도에 맞게 적절한 TTL을 설정해야 합니다.

 

3. 캐시 무효화 전략이 필요합니다.

이미 CDN에 저장된 파일을 더 이상 사용하면 안되는 경우에는 캐시를 삭제하거나 갱신해야 합니다. 이를 캐시 무효호라고 합니다.

예를 들어 잘못된 이미지가 배포되었거나, 보안상 더 이상 제공되면 안되는 파일이 캐싱된 경우에는 CDN에 남아 있는 캐시를 무효화해야 합니다.

 

4. 파일명 버전 관리가 필요할 수 있습니다.

정적 리소스를 안정적으로 갱신하기 위해 파일명에 버전이나 해시 값을 붙이는 방식이 자주 사용됩니다. 예를 들어 'main.js' 대신 'main.a3f91c.js'처럼 파일명을 변경하면 CDN은 이를 기존 파일과 다른 새로운 리소스로 인식합니다. 이렇게 하면 이전 캐시와 충졸하지 않고 변경된 파일을 사용자에게 전달할 수 있습니다.

 

5. 민감한 데이터는 CDN에 캐싱하지 않아야 합니다.

CDN 캐시는 여러 사용자에게 공통으로 제공되는 리소스를 빠르게 전달하는데 적합합니다. 따라서 개인정보, 인증 정보, 결제 정보, 사용자별 API 응답처럼 외부에 노출되면 안되거나 사용자마다 달라지는 데이터는 CDN 캐시 대상에서 제외해야 합니다.

 

즉, CDN 캐시는 "빠르게 전달해도 되는 공통 리소스"에 사용해야 효과적이지만 사용자마다 달라지거나 즉시 최신 상태가 보장되어야하는 데이터에는 신중하게 적용해야 합니다.

---

오늘은 캐시와 CDN 캐시에 대해서 학습해보았습니다. 설명하고자 하는 내용이 많다보니 길어졌네요. 다음 시간에는 서버 사이드 캐시: Redis에 대해서 설명하도록 하겠습니다. 수고하셨습니다.