캐싱이란?

캐싱은 키-값 데이터를 임시 메모리(예: 비관계형 구조적 쿼리 언어 (NoSQL) 데이터베이스)에 저장하는 방식입니다. 이렇게 하면 애플리케이션이 기존 스토리지보다 더 빠르게 데이터를 가져올 수 있습니다. 클라우드 스토리지 아키텍처에서는 요청이 네트워크를 거쳐 공유 서비스에 닿는 경우가 많기 때문에, 캐싱을 사용하면 응답 시간을 낮추고 반복 작업을 줄일 수 있습니다.

대부분의 시스템은 전체 데이터 집합을 위한 내구성 있는 “정보 소스”(즉, 데이터베이스)를 유지하고, 자주 읽는 일시적인 하위 집합은 캐시에 보관합니다. 요청이 들어오면 앱은 먼저 캐시를 확인하며, 데이터가 있으면 백 엔드를 다시 쿼리하지 않고 빠르게 반환합니다. 개발자는 처리된 데이터도 캐시하고 재사용하여 표준 쿼리보다 더 빠르게 요청을 처리합니다. 대상은 관계형 데이터베이스, SQL 데이터베이스 또는 오픈 소스 PostgreSQL 데이터베이스입니다.

1. 자주 읽는 데이터 캐시

적절한 대상은 자주 읽히고 거의 변경되지 않는 데이터이며, 제품 및 가격 정보나 생성 비용이 큰 공유 정적 리소스를 예로 들 수 있습니다.

2. 반복되는 작업의 결과 캐시

작업이 데이터를 변환하거나 복잡한 계산을 수행하는 경우 결과를 캐시해 다음 요청에서 다시 계산하지 않아도 됩니다.

3. 필요한 경우 캐시 계층 사용

개발자는 다단계 캐시(“캐시 계층”)를 사용하여 필요에 따라 별도의 캐시에 다양한 형식의 데이터를 저장합니다. 하나 이상의 캐시 계층을 추가하면 데이터 계층의 처리량과 지연 시간이 개선될 수 있습니다.

4. 응답성이 좋은 앱을 위해 세션 상태를 가까이 유지

메모리 내 저장소는 사용자 입력, 장바구니 항목, 개인 설정 같은 대량의 세션 데이터를 짧은 기간 보관하는 데 자주 사용됩니다. 상태 저장 앱의 경우 팀은 앱을 상태 비저장으로 유지할 수 있도록 세션 상태도 캐시에 저장합니다.

캐싱은 몇 가지 구체적인 방식으로 성능을 개선할 수 있습니다.

• 메모리 내 캐시에서 데이터를 읽으면 디스크 기반 저장소에서 데이터에 액세스하는 것보다 빠릅니다.
• 쿼리 수가 줄면 부하를 줄이고 데이터베이스 인프라를 확장해야 하는 필요성도 낮출 수 있으며, 이를 통해 비용도 줄어들 수 있습니다.
• 캐시 계층은 처리량과 대기 시간을 개선할 수 있고, 메모리 내 캐시는 사용량이 급증할 때 발생하는 대기 시간을 완화하는 데 도움이 됩니다.
• 캐시 인스턴스 하나가 초당 수백만 건의 요청을 처리할 수 있어, 많은 데이터베이스보다 더 높은 처리량을 제공합니다.

많은 클라우드 설계에서 캐시는 기본 데이터 저장소(예: 데이터베이스) 옆에 배치됩니다. 기본 저장소는 클라우드 서버에 있는 완전하고 내구성 있는 데이터 집합을 보관합니다. 반면 캐시는 더 작고 임시적인 하위 집합을 보관해 읽기 속도를 높입니다.

일반적인 구성은 독립형 캐시 계층이나 앱 또는 데이터베이스 계층 안에 있는 캐시이며, 빠른 읽기가 필요한 위치를 기준으로 선택합니다.

일부 시스템은 수요에 따라 서로 다른 종류의 데이터를 다른 캐시에 저장하기 위해 다중 계층 캐싱, 즉 “캐시 계층”을 사용합니다. 하나 이상의 캐시 계층을 추가하면 데이터 계층의 처리량과 대기 시간을 개선하고, 백 엔드 부하를 줄여 전체 비용도 낮출 수 있습니다.

팀은 일반적으로 몇 가지 범주에 해당하는 데이터를 캐시합니다.

• 자주 읽는 데이터(특히 변경이 적은 데이터): 제품 또는 가격 정보와 생성 비용이 큰 공유 정적 리소스입니다.
• 반복되는 계산: 작업이 데이터를 변환하거나 복잡한 계산을 수행하는 경우입니다. 결과를 캐시하면 이후 요청에서 같은 작업을 다시 수행하지 않아도 됩니다.
• 세션 상태: 상태 저장 앱의 세션 상태입니다. 세션 상태를 캐시에 저장하면 앱 계층을 상태 비저장으로 유지하는 데 도움이 됩니다.

앱이 캐시에서 읽고 쓰는 표준 방법에는 여러 가지가 있습니다. 가장 일반적인 패턴과 실제 의미를 살펴보세요.

• 캐시 배제: 필요할 때 데이터 저장소에서 데이터를 불러옵니다.
• Read-through: 캐시에서 읽고, 필요하면 캐시가 데이터 저장소에서 가져옵니다.
• Write-through: 캐시에 기록하고, 캐시가 데이터 저장소와 동기적으로 다시 동기화합니다.
• 쓰기 저장(write-behind): 캐시에 기록하고, 나중에 데이터를 묶어서 데이터 저장소에 다시 씁니다.
• Write-around: 데이터 저장소에 기록하고 캐시에서 읽으며, 캐시는 필요할 때 업데이트됩니다.

캐시 계층을 사용하면 백 엔드 저장소를 반복해서 조회하는 대신 캐시에서 일반적인 요청을 처리할 수 있어 처리량과 대기 시간이 개선됩니다. 이렇게 하면 먼저 데이터베이스에 도달하는 요청 수가 줄어들기 때문에 데이터베이스 인프라를 확장해야 하는 필요성도 낮아질 수 있습니다.

사용량이 급증하는 앱에서는 메모리 내 캐시가 자주 요청되는 데이터를 사용 위치 가까이에 두어 대기 시간을 줄이는 데 도움이 됩니다.

워크플로를 선택할 때는 다음 내용을 시작점으로 삼으세요.

• 앱이 무엇을 저장할지, 언제 새로 고칠지 직접 결정할 수 있다면 캐시 배제를 우선 고려합니다.
• 데이터 저장소에서 ‘필요한 경우’에 캐시가 직접 가져오게 하려면 read-through를 우선 고려합니다.
• 쓰기 동작이 중요하고 재동기화 방식을 명확하게 정하고 싶다면 write-through 또는 쓰기 저장을 고려합니다.

메모리 내 캐시에서 읽는 것이 디스크 기반 데이터 저장소에서 읽는 것보다 빠르기 때문에 캐싱은 애플리케이션 성능을 개선합니다. 캐시에서 처리되는 요청이 늘어나면 시스템은 백 엔드 데이터베이스로 보내는 쿼리를 줄일 수 있어 데이터베이스 인프라를 확장해야 하는 필요성과 관련 비용을 낮출 수 있습니다.

캐싱으로 자주 얻는 이점

• 자주 읽는 데이터가 더 빠른 계층에서 제공되므로 일반적인 읽기 작업의 대기 시간이 줄어듭니다.
• 캐싱을 적용하면 데이터베이스 쿼리 수가 줄고 데이터베이스 인스턴스를 과도하게 확보해야 하는 부담도 줄어들기 때문에 데이터베이스 부하와 비용이 감소합니다.
• 캐시는 많은 데이터베이스보다 훨씬 높은 요청량을 처리할 수 있기 때문에 처리량이 더 예측 가능해집니다.
• 메모리 내 캐시가 높은 처리량이 발생하는 동안 대기 시간을 줄이기 때문에 트래픽 급증도 더 원활하게 처리할 수 있습니다.

캐싱은 반복 작업을 줄이는 데 도움이 됩니다. 반복해서 읽는 데이터 또는 생성 비용이 큰 데이터는 한 번 저장해 두고 다시 사용할 수 있습니다. 작업에 복잡한 계산이나 데이터 변환이 포함되어 있다면 결과를 캐싱해 이후 요청에서 반복 계산을 줄일 수 있습니다.

‘좋은 캐시’에 적합한 일반적인 대상

• 변경이 드문 데이터(예: 제품 정보 및 가격 정보)
• 생성 비용이 큰 공유 정적 리소스
• 반복해서 계산되는 작업의 결과

웹 사이트: 페이지 로드가 더 빨라지고 왕복 횟수가 줄어듦

많은 사이트는 페이지 출력 결과를 캐시합니다. 예를 들어 HTML과 클라이언트 스크립트를 캐시해 두면 서버가 페이지 코드를 매번 다시 실행하는 대신 캐시된 출력을 반환할 수 있습니다. 캐싱은 웹 캐시와 CDN(콘텐츠 전송 네트워크) 같은 네트워크 캐싱을 통해 웹 멀티미디어 시나리오도 지원합니다.

웹 사이트에서의 일반적인 사용 사례

• 반복 조회를 위해 전체 페이지 출력을 캐시합니다.
• 네트워크/CDN 캐싱을 통해 정적 자산을 캐시합니다.

앱과 API: 공유 데이터의 읽기 속도 향상

앱은 빠르게 가져오기 위해 임시 데이터의 일부를 캐시에 저장하는 경우가 많고, 기본 데이터베이스는 완전하고 영구적인 데이터 집합을 보관합니다. 처리된 데이터를 캐싱하고 다시 사용하면 일반적인 데이터베이스 쿼리보다 더 빠르게 요청을 처리할 수 있습니다.

일반적인 앱 패턴

• 가격 정보처럼 자주 읽는 참조 데이터를 캐시해 반복적인 데이터베이스 호출을 줄입니다.
• 계산 결과를 캐시해 비용이 큰 작업을 반복하지 않도록 합니다.

서버 및 서비스: 읽기 확장과 트래픽 급증 완화

팀은 처리량과 지연 시간을 개선하기 위해 하나 이상의 캐시 계층을 추가하는 경우가 많습니다. 이렇게 하면 일반적인 쿼리를 캐시에서 제공하고 데이터베이스 부하를 줄일 수 있습니다. 사용량이 급증하고 처리량 수요가 늘어날 때 메모리 내 캐시가 도움이 될 수 있으며, 이러한 기간의 대기 시간을 줄여 줍니다.

가장 큰 도움이 되는 영역

• 같은 키가 자주 요청되는 읽기 비중이 높은 엔드포인트
• 주기적으로 트래픽이 급증하는 시스템

비즈니스 시스템: 세션 상태와 공유 운영 데이터

캐싱은 짧게 유지되는 많은 양의 세션 데이터(예: 사용자 입력 또는 개인 설정)를 메모리 내 저장소에 보관하는 데 자주 사용됩니다. 일부 팀은 상태 저장 앱이 앱 계층을 상태 비저장으로 유지할 수 있도록 세션 상태를 캐시에 저장하기도 합니다. 운영 시스템에서는 제품 정보와 가격 정보처럼 변경이 드문 데이터가 일반적인 캐싱 대상입니다.

비즈니스 워크로드에 맞춰 볼 수 있는 예

• 웹 및 모바일 앱의 세션 데이터(짧은 수명, 대용량)
• 자주 읽는 운영 참조 데이터(가격, 공유 리소스)

브라우저 캐시는 사용자 디바이스에 정적 리소스의 복사본을 저장합니다. 따라서 다시 방문할 때 파일을 다시 다운로드하지 않고도 해당 파일을 다시 사용할 수 있습니다.

일반 사용 예

• 이미지, CSS 파일, JavaScript 파일 같은 정적 사이트 자산입니다.
• 이미 가져온 리소스에 대해 원본 서버와의 왕복 횟수를 줄입니다.

서버 쪽 캐싱은 최종 사용자의 디바이스가 아니라 원격에서 실행되는 비즈니스 서비스를 처리하는 프로세스에서 이루어집니다. 서버 쪽 캐시는 보통 한 앱 인스턴스에만 국한된 비공개 캐시이거나, 여러 앱 인스턴스가 함께 사용하는 공유 캐시입니다.

일반 사용 예

• 단일 프로세스 안에 있는 비공개 메모리 내 캐시로, 적은 양의 정적 데이터를 저장하는 데 적합합니다.
• 공유 캐시 서비스를 사용하면 여러 앱 인스턴스가 같은 캐시 값을 읽을 수 있어 인스턴스 간에 ‘서로 다른 버전’이 생기는 일을 막을 수 있습니다.
• 자주 읽히지만 수정은 드문 데이터로, 제품 및 가격 참조 데이터를 예로 들 수 있습니다.

CDN은 사용자와 가까운 에지 서버에 콘텐츠를 캐시하므로 요청이 항상 원본까지 다시 이동할 필요가 없습니다. 브라우저 캐시(한 사용자)와 달리 CDN 캐시는 공유되므로 한 사용자의 요청이 나중에 다른 사용자가 받게 될 콘텐츠를 채울 수 있습니다.

일반 사용 예

• 원본 요청을 줄이기 위해 에지 위치에서 캐시 가능 콘텐츠를 공유 방식으로 제공합니다.
• 사용자 가까이에서 제공할 때 이점이 있는 정적 리소스입니다. 브라우저가 캐시하는 것과 같은 유형의 자산이지만, 여러 사용자가 함께 사용합니다.

캐싱은 클라우드 컴퓨팅 패턴에만 해당하는 것이 아니며, 하드웨어와 메모리 계층에서도 사용됩니다.

CPU 캐시는 프로세서 가까이 또는 프로세서 위에 있는 작고 빠른 메모리 영역으로, 자주 사용하는 데이터와 명령의 복사본을 저장해 주 메모리를 기다리는 시간을 줄여 줍니다.

메모리(메모리 내) 캐시는 가장 간단한 소프트웨어 캐시 유형입니다. 단일 프로세스의 주소 공간에 유지되는 메모리 내 저장소이며, 해당 프로세스가 직접 액세스합니다.

일반 사용 예

• CPU 캐시: 주 메모리를 자주 오가지 않고 같은 명령과 데이터를 반복해서 액세스하는 방식입니다.
• 메모리 내 캐시: 실행 중인 한 서비스 안에서 비교적 정적인 데이터를 소량 빠르게 읽는 방식입니다.

분산 캐시는 여러 서버에 걸쳐 있어 캐시 용량과 트랜잭션 처리 역량을 한 대의 머신보다 더 크게 확장할 수 있습니다. 많은 공유 캐시 서비스는 서버 클러스터를 사용하고 캐시된 데이터를 클러스터 전체에 분산합니다. 캐시 확장은 서버를 더 추가하는 것만큼 간단할 수 있습니다. 일부 분산 설계는 캐시를 계층화하기도 합니다. 한 계층에서 미스가 발생하면 상위 공급자에서 가져온 뒤, 다음 요청을 위해 결과를 로컬에 저장합니다.

일반 사용 예

• 여러 앱 인스턴스와 머신을 위한 공유 캐시 계층입니다.
• 단일 호스트를 넘어서는 캐시 용량과 처리량이 필요한 워크로드입니다.
• 미스가 발생하면 상위 계층에서 가져온 뒤, 이후 요청을 위해 로컬 복사본을 유지하는 계층형 캐시 설정입니다.

캐싱은 자주 액세스하는 데이터를 사용하는 위치 가까이에 두어 응답 시간을 개선하고 시스템이 더 많은 동시 요청을 처리하도록 도와줍니다. 또한 원본 데이터 저장소의 경합도 줄일 수 있는데, 예를 들어 데이터베이스 연결 수가 제한적일 때 유용합니다.

분산 애플리케이션에서는 캐싱이 클라이언트 쪽(예: 브라우저) 및 서버 쪽(예: 애플리케이션 또는 공유 캐시 서비스)의 여러 위치에서 일어나는 경우가 많습니다.

작게 시작하고 가장 확실한 효과를 주는 데이터에 집중하세요.

• 읽기 비중이 높고 가져오는 속도가 느리며 자주 바뀌지 않는 데이터를 캐시하세요(예: 참조 데이터).
• 데이터를 언제 캐시에 넣을지 결정하세요.
  • 첫 요청이 온 뒤 필요할 때 저장하세요. 그러면 실제로 사용되는 것만 보관하게 됩니다.
  • 초기에 요청될 것을 알고 있다면 시작할 때 일부 항목을 미리 채워 넣으세요. 다만 원본 저장소에 걸리는 시작 부하도 함께 살펴보세요.
• 관리할 수 있는 패턴을 선택하세요. 캐시 배제 패턴은 널리 사용됩니다. 이 패턴의 지침은 만료, 제거, 일관성이 결과에 어떤 영향을 주는지 보여줍니다.

캐시는 보통 기본 저장소의 데이터 복사본을 보관하므로 최신성에 주의해야 합니다.

• 만료 정책을 사용해 데이터가 캐시에 머무를 수 있는 시간을 제한한 뒤 새로 고치세요.
• 캐시가 가득 찰 때의 제거 동작도 확인하세요. 많은 시스템은 기본적으로 가장 오래 사용하지 않은 항목을 제거합니다.
• 캐시를 중요한 데이터의 유일한 저장 위치로 취급하지 마세요. 시스템이 캐시를 사용할 수 없을 때도 계속 동작할 수 있도록 원본 데이터는 영구 스토리지에 유지하세요.
• 캐시에 연결할 수 없을 때는 원본 데이터 저장소로 돌아가는 대체 경로를 준비하고, 읽기가 발생할 때 다시 채우세요.

캐싱은 단일 서비스부터 분산 앱, 에지 전송까지 다양한 아키텍처에 잘 맞기 때문에 최신 시스템의 핵심 구성 요소입니다. 관리형 메모리 내 캐시 클라우드 공급자를 찾고 있다면 Azure를 살펴보세요.