캐시(Cache)
캐시란 자주 사용하는 데이터를 미리 복사해 놓는 임시 저장 공간을 의미한다. 주로 데이터베이스나 디스크처럼 상대적으로 느린 저장소에서 직접 데이터를 가져오는 대신, 보다 빠른 메모리를 사용해 자주 필요한 데이터를 신속하게 조회하는 방법이다. 캐시를 사용함으로써 시스템의 응답 속도를 크게 향상시킬 수 있으며, 특히 반복적으로 접근하는 데이터에 대해 성능 이점을 제공한다.
예를 들어, 웹 애플리케이션에서 자주 요청되는 페이지나 이미지 파일, 혹은 데이터베이스에서 빈번하게 조회되는 쿼리 결과 등을 캐시에 저장하면, 매번 원본 저장소에 접근할 필요가 없어져 서버의 부하를 줄이고 전반적인 처리 성능을 높일 수 있다. 이처럼 캐시는 데이터를 임시로 저장하고 빠르게 제공함으로써, 시스템 자원을 효율적으로 사용하고 사용자 경험을 개선하는 중요한 역할을 한다.
캐시 미스의 오버헤드와 성능 저하
캐시를 효율적으로 사용하기 위해서는 캐시에 저장할 데이터의 특성을 신중하게 고려해야 한다. 자주 조회되지만 자주 변동되지 않는 데이터는 캐시를 활용하기에 이상적이다. 이러한 데이터를 캐시에 저장하면 캐시 미스(cache miss) 발생을 줄여 성능을 높일 수 있다.
캐시 미스가 발생하면 시스템은 캐시에 데이터가 없기 때문에 원본 데이터 소스로부터 다시 데이터를 조회해야 한다. 이 과정에서 추가적인 네트워크 요청이나 데이터베이스 조회가 필요할 수 있으며, 이는 상당한 오버헤드를 유발한다. 특히 원본 데이터 조회 시간이 길거나 네트워크 대역폭이 제한적인 환경에서는 캐시 미스가 성능 저하의 주요 원인이 될 수 있다.
캐시 미스로 인한 오버헤드는 단순히 느린 응답 속도뿐만 아니라, 서버 자원 사용량의 증가로 이어질 수 있다. 이는 결국 전체 시스템의 처리량을 떨어뜨리고 사용자 경험에 악영향을 미칠 수 있다. 따라서 캐시에 저장할 데이터는 자주 조회되며, 적어도 일정 기간 동안 변동이 적은 데이터를 선정하는 것이 중요하다. 캐시를 잘 설계하고 관리하면 캐시 미스를 줄이고, 시스템 전반의 성능을 크게 향상시킬 수 있다.
- 클라이언트가 서버로 데이터를 요청한다.
- 서버가 요청받은 데이터를 캐시 메모리에서 확인한다.
- 캐시 미스 발생 시, DB나 서버에서 데이터 조회한다.
- 조회한 데이터를 캐시에 저장한다.
캐싱 전략
캐싱 전략이란 애플리케이션의 성능과 직결되는 중요한 요소이다. 적절한 캐싱 전략을 선택하면 데이터 접근 시간을 단축하고 애플리케이션의 전반적인 성능을 향상시킬 수 있다.캐싱을 사용하면 데이터베이스 접근을 줄이고, 네트워크 지연을 감소시키며, 서버의 부하를 분산시키는 효과가 있다. 이는 곧, 비용 절감으로 연결된다. 실제로 인프런 아키텍처에서 캐시를 앞단에 두어 75% 이상 비용을 감소했다고 한다.
1. Cache Aside
일반적으로 가장 흔히 사용되는 캐싱전략이다. 애플리케이션이 직접 캐시를 관리하는 방식으로, 먼저 캐시에서 데이터를 찾고, 없을 경우 데이터베이스에서 데이터를 가져와 캐시에 저장한다. 데이터 갱신 시 캐시의 데이터를 무효화하고, 다음 요청 시 새 데이터를 DB에서 다시 가져와 캐시에 저장한다.
장점: 자주 사용되는 데이터만 캐시에 저장되며, 캐시 오염을 줄일 수 있다.
단점: 캐시의 일관성 유지가 어렵고, 캐시 미스 시 성능 저하가 발생할 수 있다.
2. Read-Through
캐시에 데이터가 없을 때 자동으로 데이터베이스나 원본에서 데이터를 가져와 캐시에 저장하는 방식이다. 애플리케이션은 DB에 직접 접근하지 않고 항상 캐시를 통해 데이터를 읽는다.
장점: 캐시 미스를 처리하는 로직이 중앙화되어 있으며, 데이터 일관성 관리를 캐시 시스템이 처리한다.
단점: 캐시 미스가 발생하면 데이터 조회 속도가 느려질 수 있다.
3. Write-Through
애플리케이션이 데이터를 캐시에 쓰면 캐시는 즉시 그 데이터를 데이터베이스에 반영하는 방식이다. 즉, 캐시에 쓰는 순간 DB에도 바로 쓰여 데이터 일관성을 유지한다.
장점: 캐시와 데이터베이스 간의 데이터 일관성이 보장된다.
단점: 쓰기 작업이 늘어나면서 쓰기 성능에 영향을 미칠 수 있다.
DynamoDB Accelerator(DAX)는 Read-Through 및 Write-Through 캐시 전략의 좋은 예이다. DAX는 DynamoDB와 애플리케이션 사이에 위치하며, 읽기 및 쓰기 작업을 가속화하는 역할을 한다. 애플리케이션은 DynamoDB에 직접 접근하지 않고, DAX를 통해 데이터에 접근한다.
동작 방식:
- Read-Through 캐시: DAX는 요청된 데이터가 캐시에 있는지 확인하고, 없으면 자동으로 DynamoDB에서 데이터를 가져와 캐시에 저장한 후 반환한다. 즉, 애플리케이션은 DAX를 통해 항상 최신 데이터를 조회하며, 데이터베이스에 직접 접근할 필요가 없다. Write-Through 캐시: 쓰기 작업이 발생하면 DAX는 데이터를 캐시에 저장함과 동시에 DynamoDB에도 반영한다. 이를 통해 캐시와 데이터베이스 간의 일관성을 유지하면서도 빠른 쓰기 성능을 제공한다.
중요 사항:
DAX를 사용할 때는 반드시 데이터 일관성 모델을 이해하는 것이 중요하다. DynamoDB는 강력한 일관성(Strong Consistency)과 최종 일관성(Eventual Consistency)을 지원하며, DAX는 기본적으로 최종 일관성을 사용한다. 따라서, 즉각적인 데이터 일관성이 중요한 경우에는 강력한 일관성 읽기를 사용해야 하며, 이때 성능 이점을 약간 희생할 수 있다. 또한, 쓰기 작업 시에는 DAX와 DynamoDB 간의 데이터 동기화가 적절하게 이루어지는지 확인해야 한다.
DAX는 캐시를 사용해 애플리케이션의 읽기 성능을 크게 향상시킬 수 있지만, 사용 전에 캐시 일관성과 DynamoDB의 특성에 대해 충분히 이해하는 것이 필요하다.
4. Write-Around
데이터를 db에 직접 쓰되, 캐시에는 쓰지 않고 데이터 읽기 시에만 캐시를 사용한다.
장점: 자주 업데이트되지 않은 데이터에 적합하며, 캐시가 자주 업데이트되는 것을 방지할 수 있다.
단점: 캐시 미스가 자주 발생할 수 있다. 특히 자주 업데이트되는 데이터는 캐시에 없을 가능성이 높다.
Write-Around vs. Read-Through
캐시 전략 중 Read-Through와 Write-Around는 모두 데이터베이스에 직접 접근하는 횟수를 줄여 시스템 성능을 개선하려는 목적으로 사용된다. 두 방식 모두 캐시 미스 발생 시 데이터베이스에서 데이터를 가져와 캐시에 저장하는 공통점이 있다. 하지만, 데이터의 읽기 및 쓰기 방식에서 차이가 있다.
Read-Through는 클라이언트가 데이터를 요청하면 먼저 캐시에서 데이터를 찾고, 캐시에 없을 경우 데이터베이스에서 데이터를 가져와 캐시에 저장한 후 클라이언트에게 제공한다. 이 방식은 자주 참조되는 데이터를 캐시에 저장하여 다음 요청 시 빠르게 응답할 수 있게 한다.
반면, Write-Around는 데이터를 수정하거나 작성할 때 캐시에 저장하지 않고 데이터베이스에만 저장한다. 이후 캐시 미스가 발생할 때만 데이터베이스에서 데이터를 읽어와 캐시에 저장하며, 그때부터 캐시에서 데이터를 제공한다. 이 방식은 데이터 업데이트가 자주 발생해 캐시가 오염될 가능성이 있을 때 유리하며, 주로 읽기 작업이 많은 환경에 적합하다.
결론적으로, Read-Through는 읽기 성능을 중시하고 캐시를 적극적으로 활용하는 반면, Write-Around는 쓰기 작업에서 캐시를 덜 사용하고 읽기 시에만 캐시를 활용하는 전략이다.
5. Write-Back (Write-Behind)
데이터를 수정할 때 캐시에서만 먼저 변경하고, 이후에 데이터베이스로 변경 사항을 비동기적으로 기록하는 방식이다. 즉, 데이터가 캐시에 먼저 쓰이고, 일정 주기나 조건에 따라 나중에 데이터베이스에 반영된다.
장점:
- 데이터베이스에 즉시 접근하지 않아 쓰기 성능이 크게 개선된다.
- 데이터베이스에 일시적인 부하나 장애가 발생해도 캐시에서 처리할 수 있어 시스템이 일정 부분 내성을 가지게 된다.
- DynamoDB와 같은 과금형 서비스에서는 배치 처리를 통해 전체적인 데이터 쓰기 작업을 줄이고, 이로 인해 비용을 절감할 수 있다.
단점:
- 캐시 저장소에 문제가 발생할 경우 데이터베이스에 기록되지 않아 영구적으로 데이터를 잃을 수 있다는 위험이 있다.
- 캐시와 데이터베이스 간 동기화와 오류 처리 로직이 복잡해지기 때문에 구현이 어려울 수 있다.
Write-Through vs. Write-Back
- Write-Through 전략에서 캐시된 데이터는 동기적으로 메인 DB에 업데이트 된다.
- Write-Back 전략에서 캐시된 데이터는 비동기적으로 메인 DB에 업데이트 된다.
