탐색 건너뛰기

캐싱이란?

개발자 및 IT 전문가는 캐싱을 사용하여 임시 메모리 내 키-값 데이터를 기존 데이터 스토리지에 저장된 데이터보다 더 빠르고 적은 간단하게 저장하고 액세스합니다. 캐시는 RAM(랜덤 액세스 메모리)를 사용한 컴퓨터 캐싱, 콘텐츠 배달 네트워크의 네트워크 캐싱, 웹 멀티미디어 데이터용 웹 캐시 또는 클라우드 애플리케이션을 보다 탄력적으로 만드는 데 도움이 되는 클라우드 캐시와 같은 여러 기술이 있는 여러 시나리오에서 유용합니다. 개발자는 종종 애플리케이션을 설계하여 처리된 데이터를 캐시한 후 표준 데이터베이스 질의보다 더 빠르게 요청을 처리할 수 있도록 용도를 변경합니다.

캐싱을 사용하여 데이터베이스 비용을 절감하고, 대부분의 데이터베이스가 제공할 수 있는 것보다 높은 처리량과 짧은 대기 시간을 제공하며, 클라우드 및 웹 애플리케이션의 성능을 향상시킬 수 있습니다.

데이터베이스에 대한 캐싱은 어떻게 작동하나요?

개발자는 데이터베이스 또는 애플리케이션 내에 배치하거나 독립 실행형 계층으로 설정할 수 있는 데이터베이스 캐시를 사용하여 주 데이터베이스를 보완할 수 있습니다. 일반적으로 지속형 완전한 대용량 데이터 세트를 저장하기 위해 기존 데이터베이스에 의존하지만 신속한 검색을 위해 캐시를 사용하여 데이터의 임시 하위 세트를 저장합니다.

MySQL 또는 MariaDB와 같은 관계형 데이터베이스뿐만 아니라 NoSQL 데이터베이스를 포함한 모든 유형의 데이터 저장소에 캐싱을 사용할 수 있습니다. 캐싱은 Azure Database for PostgreSQL, Azure SQL Database 또는 Azure SQL Managed Instance와 같은 많은 특정 데이터 플랫폼에서도 잘 작동합니다. 데이터 아키텍처를 구성하기 전에 요구 사항을 가장 잘 충족하는 데이터 저장소 유형을 조사하는 것이 좋습니다. 예를 들어 PostgreSQL을 사용하여 관계형 데이터 저장소와 비정형 데이터 저장소를 결합하기 전에 PostgreSQL이 무엇인지 이해하려고 할 수 있습니다.

캐시 계층의 이점과 Redis란?

개발자는 캐시 계층이라는 다단계 캐시를 사용하여 요구에 따라 서로 다른 유형의 데이터를 별도의 캐시에 저장합니다. 캐시 계층 또는 여러 계층을 추가하면 데이터 계층의 처리량과 대기 시간 성능을 크게 향상시킬 수 있습니다.

Redis는 고성능 캐시 계층 및 기타 데이터 저장소를 구축하는 데 사용되는 널리 사용되는 오픈 소스 메모리 내 데이터 구조입니다. 최근 연구에 따르면 Azure Cache for Redis를 샘플 애플리케이션에 추가하면 데이터 처리량이 800% 이상 증가하고 대기 시간 성능이 1,000% 이상 향상되었습니다1.

캐시는 또한 데이터 계층의 TCO(총 소유 비용)을 절감할 수 있습니다. 캐시를 사용하여 가장 일반적인 쿼리를 처리하고 데이터베이스 로드를 줄이면 데이터베이스 인스턴스를 과도하게 프로비저닝할 필요성을 줄여 비용을 크게 절감하고 TCO를 낮출 수 있습니다.

캐싱 유형

캐싱 전략은 애플리케이션에서 데이터를 읽고 쓰는 방법에 따라 달라집니다. 애플리케이션이 쓰기 집약적이거나 데이터를 한 번 쓰고 자주 읽습니까? 반환되는 데이터가 항상 고유합니까? 서로 다른 데이터 액세스 패턴이 캐시를 구성하는 방법에 영향을 미칩니다. 일반적인 캐싱 유형에는 캐시 보관, read-through/동시 기록, 쓰기 숨김/쓰기 저장 등이 있습니다.

캐시 보관

읽기 작업량이 많은 애플리케이션의 경우 개발자는 종종 캐시 보관(cache-aside) 프로그래밍 패턴(또는 side-cache)을 사용합니다. 애플리케이션 외부에서 사이드 캐시를 찾습니다. 데이터를 쿼리 및 검색하기 위해 캐시에 연결하거나, 데이터가 캐시에 없는 경우 데이터베이스와 직접 연결할 수 있습니다. 애플리케이션은 데이터를 검색할 때 이후 쿼리를 위해 데이터를 캐시에 복사합니다.

캐시 보관(side-cache)을 사용하여 애플리케이션 성능을 개선하고 캐시와 데이터 저장소 간의 일관성을 유지하며 캐시의 데이터가 오래되지 않도록 할 수 있습니다.

Read-through/동시 기록 캐시

Read-through 캐시는 최신 상태를 유지하는 반면, write-through 캐싱은 애플리케이션이 데이터를 캐시에 기록한 다음 데이터베이스에 기록합니다. 두 캐시는 모두 데이터베이스와 일렬로 배치되며, 애플리케이션은 이를 주 데이터 저장소로 취급합니다.

Read-through 캐시를 사용하면 동일한 데이터가 계속해서 요청되지만 캐시 자체는 더 복잡해지는 애플리케이션을 간소화할 수 있으며, 2단계 동시 기록 프로세스는 대기 시간을 발생시킬 수 있습니다. 개발자는 이 두 가지를 쌍으로 구성하여 캐시와 데이터베이스 간의 데이터 일관성을 보장하고, 동시 기록 캐시 대기 시간을 줄이고, read-through 캐시를 쉽게 업데이트할 수 있도록 지원합니다.

개발자는 read-through/동시 기록 캐싱을 통해 애플리케이션 코드를 단순화하고 캐시 스케일링 성능을 높이며 데이터베이스 로드를 최소화할 수 있습니다.

쓰기 숨김/쓰기 저장 캐시

이 시나리오에서 애플리케이션은 데이터를 캐시에 기록하며, 캐시는 데이터를 백그라운드로 데이터베이스에 다시 씁니다. 쓰기 숨김(write-back) 캐시(Write-behind 캐시라고도 함)는 쓰기 집약적인 워크로드에 가장 적합하며, 애플리케이션이 다음 작업으로 이동하기 전에 쓰기가 완료될 때까지 기다릴 필요가 없으므로 쓰기 성능이 향상됩니다.

분산 캐시와 세션 저장소 비교

종종 분산 캐시를 세션 저장소와 혼동하지만 요구사항과 목적이 다릅니다. 개발자는 분산 캐시를 사용하여 데이터베이스를 보완하는 대신 웹앱과 같은 세션 지향 애플리케이션의 프로필, 메시지 및 기타 사용자 데이터에 대한 사용자 계층의 임시 데이터 저장소인 세션 저장소를 구현합니다.

세션 저장소란?

세션 지향 애플리케이션은 사용자가 애플리케이션에 로그인하는 동안 수행한 작업을 추적합니다. 사용자가 로그아웃할 때 해당 데이터를 세션 저장소에 보관하면 세션 관리가 향상되고 비용이 절감되며 애플리케이션 성능이 향상됩니다.

세션 저장소를 사용하는 것은 데이터베이스 캐싱과 어떻게 다른가요?

세션 저장소에서 데이터는 서로 다른 사용자 간에 공유되지 않지만 캐싱을 사용하면 서로 다른 사용자가 동일한 캐시에 액세스할 수 있습니다. 개발자는 데이터베이스 또는 스토리지 인스턴스의 성능을 향상시키기 위해 캐싱을 사용하는 반면, 세션 저장소를 사용하여 메모리 내 저장소에 데이터를 기록함으로써 애플리케이션 성능을 향상시켜 데이터베이스에 액세스할 필요가 없습니다.

세션 저장소에 기록된 데이터는 일반적으로 수명이 짧은 반면, 기본 데이터베이스로 캐시된 데이터는 일반적으로 훨씬 더 오래 지속됩니다. 세션 저장소는 트랜잭션 데이터가 손실되지 않고 사용자의 참여를 유지하기 위해 복제, 고가용성 및 데이터 내구성이 필요합니다. 한편, 캐시 보관(side-cache)의 데이터가 손실되는 경우 영구 데이터베이스에는 항상 해당 데이터의 복사본이 있습니다.

캐싱의 이점

향상된 애플리케이션 성능

메모리 내 캐시에서 데이터를 읽는 것이 디스크 기반 데이터 저장소의 데이터에 액세스하는 것보다 훨씬 빠릅니다. 또한 데이터에 대한 액세스 속도가 빨라짐에 따라 전반적인 애플리케이션 환경이 크게 개선됩니다.

데이터베이스 사용량 및 비용 감소

캐싱은 데이터베이스 쿼리 수를 줄이고, 데이터베이스 인프라를 스케일링할 필요성을 제한하고 처리량을 줄여 성능을 향상시키며, 비용을 절감합니다.

스케일링 가능하고 예측 가능한 성능

단일 캐시 인스턴스는 초당 수백만 개의 요청을 처리할 수 있으므로 데이터베이스가 따라올 수 없는 수준의 처리량과 스케일링 성능을 제공합니다. 또한 캐싱은 애플리케이션 및 데이터 저장소를 스케일링 아웃하거나 스케일링 업할 때 필요한 유연성을 제공합니다. 그러면 애플리케이션에서 백 엔드 데이터베이스의 부하를 늘리지 않고 동일한 파일에 동시에 액세스할 수 있습니다. 또한 애플리케이션의 사용량이 급증하고 처리량이 높은 경우 메모리 내 캐시를 사용하면 대기 시간을 줄일 수 있습니다.

캐싱은 어떤 용도로 사용되나요?

출력 캐싱

출력 캐싱은 서버가 렌더링을 위해 브라우저에 보내는 HTML 및 클라이언트 스크립트와 같은 페이지의 전체 소스 코드를 저장하여 웹 페이지 성능을 향상시키는 데 도움이 됩니다. 사용자가 페이지를 볼 때마다 서버는 애플리케이션의 메모리에 출력 코드를 캐시합니다. 이렇게 하면애플리케이션은 페이지 코드를 실행하거나 다른 서버와 통신하지 않고도 요청을 처리할 수 있습니다.

데이터 캐싱 및 데이터베이스 캐싱

데이터베이스 속도와 처리량은 전체 애플리케이션 성능의 주요 요인이 될 수 있습니다. 데이터베이스 캐싱은 가격 책정 또는 인벤토리 데이터와 같이 자주 변경되지 않는 데이터에 대한 빈번한 호출에 사용됩니다. 웹 사이트 및 애플리케이션의 로딩 속도를 높이는 동시에 백엔드 데이터베이스의 처리량을 늘리고 데이터 검색 대기 시간을 단축할 수 있습니다.

사용자 세션 데이터 저장

애플리케이션 사용자는 짧은 기간 동안 저장해야 하는 데이터를 생성하는 경우가 많습니다. Redis와 같은 메모리 내 데이터 저장소는 스토리지나 데이터베이스보다 저렴한 비용으로 사용자 입력, 쇼핑 카트 항목 또는 개인 설정 기본 설정과 같은 대량의 세션 데이터를 효율적이고 안정적으로 저장하는 데 적합합니다.

메시지 브로커 및 게시/구독 아키텍처

클라우드 애플리케이션은 종종 서비스 간에 데이터를 교환해야 하며 캐싱을 사용하여 게시/구독 또는 메시지 브로커 아키텍처를 구현하여 대기 시간을 줄이고 데이터 관리를 가속화할 수 있습니다.

애플리케이션 및 API

브라우저와 마찬가지로 애플리케이션은 중요한 파일과 데이터를 저장하여 필요할 때 해당 정보를 신속하게 다시 로드합니다. 캐시된 API 응답은 애플리케이션 서버 및 데이터베이스에 대한 요규 사항이나 로드를 제거하여 응답 시간을 단축하고 성능을 향상합니다.

1성능 클레임은 2020년 10월 Microsoft가 의뢰하고 GigaOm이 수행한 연구의 데이터를 기반으로 합니다. 이 연구에서는 Azure Cache for Redis를 캐싱 솔루션으로 구현한 경우와 구현하지 않은 경우의 Azure 데이터베이스를 사용한 테스트 애플리케이션의 성능을 비교했습니다. Azure SQL Database와 Azure Database for PostgreSQL은 연구에서 데이터베이스 요소로 사용되었습니다. Azure SQL Database의 2 vCore Gen5 범용 인스턴스와 Azure Database for PostgreSQL의 2 vCore 범용 인스턴스는 Redis용 Azure의 6기가바이트 P1 프리미엄 인스턴스와 함께 사용되었습니다. 이러한 결과를 Azure SQL Database의 8, 16, 24 및 32 vCore Gen 5 범용 인스턴스와 Azure Cache for Redis가 없는 Azure Database for PostgreSQL의 8, 16, 24 및 32 vCore 범용 인스턴스와 비교했습니다. 벤치마크 데이터는 GigaOm 웹 애플리케이션 데이터베이스 부하 테스트에서 가져옵니다. 증가하는 HTTP 요청으로 인해 제한되는 공통 웹 애플리케이션 및 백엔드 데이터베이스를 시뮬레이션합니다. 실제 결과는 구성 및 지역에 따라 다를 수 있습니다. 전체 연구를 참조하세요.

완전 관리형 Redis 서비스를 사용하여 애플리케이션에 민첩한 캐싱 계층 추가: Azure Cache for Redis를 시작하는 방법에 대해 알아보세요.

고성능 애플리케이션에 대해 유연한 파일 기반 캐싱을 실행하려면 Azure HPC Cache를 읽어보세요.

무엇을 도와 드릴까요?