[AWS SAA] 29. DB Caching(캐싱)

캐시를 고려해야하는 항목

애플리케이션이 데이터베이스 캐싱을 사용해야 하는지 여부를 결정하기 위해서 다음과 같은 사항을 고려할 수 있습니다.

 

• 속도와 비용
  기본적으로 속도는 더 느리고 비용은 더 많이 드는 데이터베이스 쿼리가 존재합니다. 예를 들어 여러 테이블에서 조인을 수행하는 쿼리는 단순한 단일 테이블 쿼리보다 훨씬 더 많은 시간과 비용이 듭니다. 요청하는 데이터를 수신하려면 속도가 느리고 비용이 많이 드는 쿼리를 실행해야 하는 경우 해당 데이터를 캐시할 수 있습니다.
• 데이터 및 액세스 패턴
  캐싱할 항목을 결정할 때는 데이터 그 자체와 데이터의 액세스 패턴도 이해해야 합니다. 예를 들어 빠르게 변경되거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐싱을 통해 유의미한 이점을 얻으려면 소셜 미디어 사이트의 개인 프로필과 같이 비교적 정적이면서 액세스 빈도가 높은 데이터가 있어야 합니다.
• 캐시 유효성
  데이터는 캐시에 저장되어 있는 동안 오래된 상태가 될 수 있습니다. 즉, 데이터베이스의 해당 데이터에 대해 수행되는 쓰기가 캐시하기에 적합한지를 결정할 때는 정확하지 않을 수도 있는 캐시 데이터에 대한 애플리케이션의 내결함성을 결정해야 합니다.

 

캐싱 아키텍처

캐싱을 사용하지 않는 경우 EC2 인스턴스가 데이터베이스에서 직접 읽고 씁니다. 반면 캐싱을 사용하는 경우 인스턴스는 먼저 캐시에서 읽기를 시도하는데, 이 읽기에는 고성능 메모리가 사용됩니다. 에를들어 ElasticCache 및 DynamoDB Accelerator(DAX)와 같은 AWS의 데이터베이스 캐시는 인 메모리 DB입니다. 이러한 데이터베이스가 사용하는 캐시 클러스터에는 서브넷 간에 분산된 캐시 노드 집합이 포함되어 있습니다. 해당 서브넷 내의 리소스는 이러한 노드에 고속으로 액세스합니다.

 

 

위 예에서는 VPC의 2개 가용 영역에 각각 앱 서브넷과 데이터 서브넷이 있습니다. 두 앱 서브넷의 애플리케이션 서버는 데이터 서브넷 하나의 프라이머리 DB가 연결됩니다. 다른 데이터 서브넷에는 복제본 DB가 포함되어 있습니다. 두 앱 서브넷에 걸쳐 캐시 클러스터가 표시되어 있으며, 각 서브넷의 클러스터에는 캐시 노드가 있습니다.

 

백엔드 데이터 스토어에 캐시를 사용할 경우 사이드 캐시가 일반적인 접근 방식입니다. 정식 예에는 Redis와 Memcached가 모두 포함됩니다. 이러한 캐시는 범용이며 기본 데이터 스토어와는 분리됩니다. 그러므로 워크로드 및 내구성 요구 사항에 따라 읽기 및 쓰기 처리량을 모두 높일 수 있습니다.

Redis? Memcached?
Redis는 키-값(Key-Value) 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 DBMS입니다. DB, 캐시, 메세지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소입니다.

키-값 구조로 쿼리를 사용할 필요가 없고, 메모리에서 데이터를 처리하기 때문에 처리 속도가 빠르다는 특징이 있습니다. 하지만 서버 장애시 데이터 유실이 일어날 수 있으므로 장애 복구 플랜이 중요합니다.

Memcached는 고성능 분산 메모리 캐시 시스템입니다. 데이터베이스 부하를 완화하여 동적 웹 응용 프로그램의 속도를 높이는 데 사용하도록 만들어졌습니다. Redis와 마찬가지로 사용하기 쉽고, 높은 성능을 자랑합니다. Redis와 비슷한 원리로 동작해 특징 또한 거의 유사합니다.

 

일반적인 캐싱 전략

다양한 전략을 활용해 캐시의 정보를 DB와 동기화된 상태로 유지할 수 있습니다. 두 가지 일반적인 캐싱 전략은 지연 로딩과 라이트 스루입니다.

 

지연 로딩

 

지연 로딩에서는 캐시를 업데이트하지 않고 데이터베이스를 업데이트합니다. 캐시 미스의 경우 데이터베이스에서 검색된 정보가 나중에 캐시에 기록될 수 있습니다. 지연 로딩 시에는 애플리케이션에 필요한 데이터가 캐시에 로드됩니다. 하지만 일부 사용 사례에서는 캐시 미스 비율이 높아질 수 있습니다.

 

라이트 스루

 

DB에 액세스할 때마다 캐시에 라이트 스루를 수행하는 방법입니다. 이러한 접근 방식은 캐시 미스가 줄어든다는 특징이 있습니다. 그 결과 성능이 개선되지만 애플리케이션에 필요하지 않을 수 있는 데이터용 추가 스토리지가 필요합니다.

 

최상의 전략은 사용 사레에 따라 다릅니다. 부실 데이터가 사용 사례에 미치는 영향을 이해하는 것이 중요합니다. 영향이 높은 경우 라이트 스루를 사용하여 새로 고침 상태를 유지하는 것이 좋습니다. 영향이 낮은 경우 지연 로딩으로 충분할 수 있습니다. 또한 기본 데이터의 변경 빈도를 이해하는 데 도움이 됩니다. 캐싱 전략의 성능 및 비용 절충에 영향을 미치기 때문입니다.

 

캐싱 유지 관리 전략을 경정한 후에는 애플리케이션 내에서 이 접근 방식을 구현해야합니다.

 

캐시 미스
CPU가 데이터를 요청하여 캐시 메모리에 접근했을 때 캐시 메모리가 해당 데이터를 가지고 있다면 이를 "캐시 적중(Cache hit)", 해당 데이터가 없어서 DRAM에서 가져와야 한다면 "캐시 부적중(Cache miss)"라고 부릅니다.

 

ElastiCache for Redis / Memcached 상세

 

캐시 관리

캐시 유효성 관리

지연 로딩은 기한 경과 데이터를 제공할 수도 있지만 빈 노드로 인해 실패하지는 않습니다. 라이트 스루에서는 최신 데이터가 유지도비니다. 그러나 빈 노드로 인해 실패할 수 있으며 불필요한 데이터로 캐시를 채울 수 있습니다. 캐시에 대한 각 쓰기에 유지 시간(TTL) 값을 추가하면 데이터를 최신 상태로 유지할 수 있으며, 여분의 데이터로 인해 캐시가 가득 차는 현상을 방지할 수 있습니다.

 

TTL은 키가 만료할 때까지의 시간(초 or 밀리초)을 지정하는 정수 값입니다. 애플리케이션이 만료된 키를 읽으려고 하면 캐시에서 데이터를 찾지 못한 것으로 처리됩니다. 따라서 데이터베이스가 쿼리되고 캐시가 업데이트됩니다. 그럼 데이터 기한 경과를 방지할 수 있습니다. 단, 데이터베이스에서 가끔씩 캐시의 값을 새로 고쳐야 합니다.

 

메모리 관리

캐시 메모리가 가득 차면 캐시 엔진이 새 데이터용 공간을 확보하기 위해 메모리에서 데이터를 제거합니다. 엔진은 사용자가 설정한 제거 정책을 기준으로 이 데이터를 선택합니다. 제거 정책은 데이터의 다음  특성을 평가합니다.

• 액세스한 지 가장 오래된 데이터
• 액세스 빈도가 가장 낮은 데이터
• TTL 세트와 TTL 값이 설정되어 있는 데이터