Trace Id is missing
주 콘텐츠로 건너뛰기

캐싱이란?

개발자와 IT 전문가는 캐싱을 사용하여 기존 데이터 스토리지에 저장된 데이터보다 빠르고 적은 노력으로 키-값 데이터를 임시 메모리에 저장하고 키-값 데이터에 액세스합니다. 캐시는 RAM(Random Access Memory)을 사용하는 컴퓨터 캐싱, 콘텐츠 배달 네트워크에서의 네트워크 캐싱, 웹 멀티미디어 데이터의 웹 캐시 또는 클라우드 앱의 복원력을 높이기 위한 클라우드 캐시와 같은 여러 기술이 사용되는 여러 시나리오에서 유용합니다. 개발자는 일반적으로 처리된 데이터를 캐시하기 위한 애플리케이션을 디자인한 다음, 표준 데이터베이스 쿼리에서보다 빠르게 요청을 처리하도록 애플리케이션의 용도를 변경합니다.

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

데이터베이스에 대해 캐싱이 작동하는 방식

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

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

캐시 계층의 이점과 Redis는 무엇인가요?

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

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

또한 캐시는 데이터 계층의 TCO(총 소유 비용)를 줄일 수 있습니다. 캐시를 사용하여 가장 일반적인 쿼리를 처리하고 데이터베이스 부하를 줄이면 데이터베이스 인스턴스를 오버프로비저닝해야 할 필요성을 줄여 상당한 비용을 절감하고 TCO를 줄일 수 있습니다.

캐싱 유형

캐싱 전략은 애플리케이션이 데이터를 읽고 쓰는 방법에 따라 달라집니다. 애플리케이션의 쓰기 작업이 많습니까? 아니면 데이터를 한 번 쓰고 자주 읽습니까? 반환되는 데이터가 항상 고유합니까? 다양한 데이터 액세스 패턴은 캐시를 구성하는 방법에 영향을 줍니다. 일반적인 캐싱 유형으로는 캐시 배제, 동시 읽기/동시 쓰기, 임시 쓰기/나중 쓰기가 있습니다.

캐시 배제

읽기 작업이 많은 워크로드가 있는 애플리케이션의 경우 개발자는 캐시 배제 프로그래밍 패턴 또는 "사이드 캐시"를 사용하는 경우가 많습니다. 애플리케이션 외부에서 사이드 캐시를 찾은 다음, 캐시와 연결하여 데이터를 쿼리 및 검색하거나 데이터가 캐시에 없는 경우 데이터베이스와 직접 연결할 수 있습니다. 애플리케이션은 데이터를 검색할 때 나중에 쿼리할 수 있도록 캐시에 데이터를 복사합니다.

사이드 캐시를 사용하여 애플리케이션 성능을 향상하고, 캐시와 데이터 저장소 간의 일관성을 유지하며, 캐시에 있는 데이터가 부실해지지 않도록 할 수 있습니다.

동시 읽기/동시 쓰기 캐시

동시 읽기 캐시는 스스로 최신 상태를 유지하지만, 동시 쓰기 캐싱을 사용할 경우 애플리케이션은 데이터를 캐시에 쓴 후 데이터베이스에 씁니다. 두 캐시는 모두 데이터베이스와 함께 배치되며 애플리케이션은 이를 기본 데이터 저장소로 처리합니다.

동시 읽기 캐시는 같은 데이터가 반복해서 요청되는 애플리케이션을 간소화하는 데 도움이 되지만, 캐시 자체는 더 복잡한 반면, 2단계 동시 쓰기 프로세스는 대기 시간을 발생시킬 수 있습니다. 개발자는 이 두 가지 캐시를 함께 사용하여 캐시와 데이터베이스 간의 데이터 일관성을 보장하고, 동시 쓰기 캐시 대기 시간을 줄이며, 동시 읽기 캐시를 더 쉽게 업데이트할 수 있습니다.

개발자는 동시 읽기/동시 쓰기 캐싱을 사용하여 애플리케이션 코드를 간소화하고, 캐시 스케일링 성능을 향상하며, 데이터베이스 부하를 최소화할 수 있습니다.

임시 쓰기/나중 쓰기 캐시

이 시나리오에서 애플리케이션은 데이터를 캐시에 쓴(즉시 승인됨) 후 캐시 자체는 백그라운드에서 데이터를 데이터베이스에 다시 씁니다. 나중 쓰기 캐시라고도 하는 임시 쓰기 캐시는 쓰기 작업이 많은 워크로드에 가장 적합하며, 애플리케이션이 쓰기 작업이 완료될 때까지 기다렸다가 다음 작업으로 이동할 필요가 없기 때문에 쓰기 성능을 향상합니다.

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

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

세션 저장소란?

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

세션 저장소 사용과 데이터베이스 캐싱의 차이점

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

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

캐싱의 이점

애플리케이션 성능 향상

메모리 내 캐시에서 데이터를 읽으면 디스크 기반 데이터 저장소에서 데이터에 액세스하는 것보다 훨씬 빠릅니다. 또한 데이터에 더 빠르게 액세스할 수 있으므로 전체 애플리케이션 환경이 크게 개선됩니다.

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

캐싱은 데이터베이스 인프라를 스케일링하고 처리량 요금을 줄여야 하는 필요성을 제한하여 데이터베이스 쿼리 수를 줄이고 성능을 향상하며 비용을 줄입니다.

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

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

캐싱 사용 용도

출력 캐싱

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

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

데이터베이스 속도와 처리량은 전체 애플리케이션 성능에서 주요 요소일 수 있습니다. 데이터베이스 캐싱은 가격이나 재고 데이터와 같이 자주 변경되지 않는 데이터를 자주 호출하는 데 사용되며, 처리량을 늘리고 백 엔드 데이터베이스의 데이터 검색 대기 시간을 줄여 웹 사이트 및 애플리케이션을 더 빠르게 로드하는 데 도움이 됩니다.

사용자 세션 데이터 저장

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

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

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

애플리케이션 및 API

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

[1] 성능에 관한 주장은 Microsoft의 의뢰를 받아 GigaOm이 2020년 10월에 실시한 연구의 데이터를 기반으로 합니다. 이 연구에서는 Azure Cache for Redis를 캐싱 솔루션으로 구현하거나 구현하지 않고 Azure 데이터베이스를 사용하는 테스트 애플리케이션의 성능을 비교했습니다. 연구의 데이터베이스 요소로 Azure SQL Database 및 Azure Database for PostgreSQL을 사용했습니다. Azure SQL Database의 vCore Gen5 범용 인스턴스 2개와 Azure Database for PostgreSQL의 vCore 범용 인스턴스 2개가 Azure for Redis의 6GB P1 프리미엄 인스턴스와 함께 사용되었습니다. 이 결과는 Azure SQL Database의 vCore Gen5 범용 인스턴스 8개, 16개, 24개, 32개를 사용한 경우 및 Azure Cache for Redis 없이 Azure Database for PostgreSQL의 vCore 범용 인스턴스 8개, 16개, 24개, 32개를 사용한 경우와 비교되었습니다. 벤치마크 데이터는 HTTP 요청이 증가하는 일반적인 웹 애플리케이션 및 백 엔드 데이터베이스를 시뮬레이션하는 GigaOm 웹 애플리케이션 데이터베이스 부하 테스트에서 가져온 것입니다. 실제 결과는 구성과 지역에 따라 다를 수 있습니다. 전체 연구 보기.

무료 계정

Azure 클라우드 컴퓨팅 서비스를 최대 30일 동안 무료로 체험해 보세요.

종량제

종량제 가격으로 시작해 보세요. 사전 약정은 없습니다. 언제든지 취소할 수 있습니다.

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

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