카테고리 없음
캐싱에 대한 공부 및 자료조사
또또니엘
2024. 11. 6. 22:23
🤔 캐싱이란?
캐싱은 어떤 데이트를 한 번 받아온 후에 그 데이터를 불러온 저장소보다 가까운 곳에 임시로 저장하여, 필요 시 더 빠르게 불러와서 사용하는 프로세스를 의미한다. 메모리 계층 구조에서 캐시는 디스크나 메인 메모리보다 더 빠르게 더에트를 불러와서 사용해야 할 때 쓰인다.
📈 캐싱 레벨
1️⃣ Application Level
애플리케이션 레벨 캐시는 애플리케이션의 코드 내부에서 메모리를 활용해 데이터를 캐싱하는 방식
- 장점:
- 빠른 접근: 캐시가 애플리케이션 메모리에 있으므로 데이터 접근 속도가 매우 빠르다.
- 의존성 감소: 외부 시스템 없이 애플리케이션 내부에서 관리되므로 외부 의존성이 줄어든다.
- 단순 구현: 애플리케이션 코드에서 쉽게 구현 가능하며, 관리가 비교적 간단하다.
- 단점:
- 메모리 용량 제한: 캐시 용량이 서버 메모리 한계에 영향을 받기 때문에 큰 데이터를 캐싱하는 데 적합하지 않다.
- 스케일 아웃의 어려움: 애플리케이션 인스턴스마다 개별 캐시를 가지기 때문에 여러 인스턴스를 사용하는 환경에서는 캐시가 공유되지 않아 데이터 일관성이 떨어질 수 있다.
- 캐시 만료 관리 어려움: 각 인스턴스의 캐시를 개별적으로 관리해야 하며, 갱신 로직을 구현하는 데 한계가 있다.
2️⃣ External Level
외부 캐시는 애플리케이션 외부에 별도로 설정된 캐시 서버를 사용하여 데이터를 캐싱하는 방식이다. 대표적으로 Redis나 Memcached 같은 인메모리 데이터 저장소가 외부 캐시 시스템으로 많이 활용된다.
- 장점:
- 일관성 유지: 여러 애플리케이션 인스턴스가 동일한 데이터를 참조하므로 일관성 유지가 용이하다.
- 유연한 스케일링: 캐시 서버를 추가하여 확장할 수 있어, 대규모 트래픽이나 데이터 처리를 보다 효율적으로 지원할 수 있다.
- 고성능 데이터 접근: 인메모리 구조로 매우 빠른 응답 속도를 제공하며, 데이터베이스의 부하를 줄이는 데 효과적이다.
- 단점:
- 네트워크 오버헤드: 애플리케이션과 캐시 서버가 네트워크로 연결되므로 로컬 메모리 캐시보다는 접근 속도가 느릴 수 있다.
- 운영 복잡성: 외부 캐시 서버의 구성 및 관리가 필요하며, 이를 위한 별도의 인프라 운영이 요구된다.
- 비용 증가: 외부 캐시를 위한 추가 인프라가 필요하므로, 설정 및 운영 비용이 증가할 수 있다.
🧭 캐싱 전략
1️⃣ Look-Aside Cache
애플리케이션이 먼저 캐시에 데이터가 있는지 확인한 후, 있으면 캐시에서 바로 가져오고, 없으면 데이터베이스나 외부 소스에서 데이터를 조회하여 캐시에 추가하고 다시 반환하는 방식
- 장점:
- 유연성: 캐시가 비어있으면 자동으로 DB로부터 필요한 데이터를 가져오므로 효율적이다.
- 낮은 캐시 부하: 필요한 데이터만 캐시에 저장되기 때문에 캐시 부하가 줄어들 수 있다.
- 데이터 최신성: Look-aside 방식에서는 데이터베이스와 캐시의 동기화가 필요하지 않으므로, 읽기 요청만 있는 경우 최신 데이터를 유지할 수 있다.
- 단점:
- 일관성 문제: DB에서 데이터가 변경되더라도, 캐시에 업데이트되지 않을 수 있어 최신 데이터가 아닌 경우가 발생할 수 있다.
- 복잡성: 애플리케이션에서 캐시를 별도로 관리해야 하므로 코드 복잡성이 증가할 수 있다.
2️⃣ Inline Cache
데이터베이스 호출 중간에 캐시를 포함시키는 방식으로 구현된다. 즉 서비스는 모든 요청을 캐시로 보내며 캐시는 데이터베이스와의 상호작용으로 서비에 요청 값을 반환
- 장점:
- 일관성 유지: 데이터베이스와 캐시가 항상 동일한 데이터 상태를 유지하기 때문에 일관성을 보장할 수 있다.
- 간단한 데이터 동기화: DB에 쓰기 작업이 있을 때마다 캐시도 자동으로 업데이트되므로 데이터 동기화에 대한 관리가 편하다.
- 단점:
- 쓰기 성능 저하: DB와 캐시에 동시에 데이터를 기록해야 하므로, 쓰기 작업 시 성능이 저하될 수 있다.
- 낭비되는 캐시 메모리: 자주 접근되지 않는 데이터까지 캐시에 저장될 수 있어 메모리 낭비가 발생할 수 있다
🚮 갱신 전략
1️⃣ Expiration
캐시 데이터의 유효 기간을 설정하고, 그 기간이 지나면 데이터를 자동으로 만료시키는 전략이다.
작동 방식:
- 데이터를 캐시에 저장할 때 유효 기간(Time-to-Live, TTL)을 설정하고, 이 시간이 지나면 해당 데이터는 자동으로 만료된다.
- 장점:
- 일관성 유지: 일정 시간이 지나면 데이터가 갱신되므로 최신 상태의 데이터를 보장하기 쉽다.
- 자동 관리: TTL 설정으로 자동으로 데이터를 만료시킬 수 있어 캐시 관리를 단순화한다.
- 단점:
- 잘못된 TTL 설정 위험: TTL이 너무 짧으면 잦은 캐시 갱신이 필요해지고, 너무 길면 오래된 데이터를 유지할 수 있다.
2️⃣ Eviction
캐시가 저장 용량을 초과했을 때, 일정한 규칙에 따라 오래된 데이터를 제거하여 새로운 데이터를 저장할 공간을 확보하는 전략이다.
작동 방식:
- 캐시가 용량을 초과하면, 특정 규칙에 따라 가장 덜 중요한 데이터를 제거하여 공간을 확보한다.
- Eviction을 위한 알고리즘
| FIFO(First In First Out) | 가장 먼저 메모리에 올라온 페이지를 교체 |
| OPT(OPTimal Page Replacement) | 앞으로 가장 오랫동안 사용되지 않을 페이지를 교체 |
| LRU(Least Recently Used) | 가장 오랫동안 사용되지 않은 페이지를 교체 |
| Count-Based | 접근 횟수를 기반으로 데이터를 관리하는 방식 |
| LFU(Least Frequently Used) | 참조 횟수가 가장 적은 페이지를 교체 |
| MFU(Most Frequently Used) | 참조 횟수가 가장 많은 페이지를 교체 |
| NUR(Not Used Recently) | 최근에 사용하지 않은 페이지를 교체(클럭 알고리즘) |
| Random | 랜덤으로 교체 |
- 장점:
- 효율적 메모리 사용: 캐시 용량이 한정된 상황에서 중요한 데이터를 우선적으로 보존하여 공간을 최적화한다.
- 유연한 설정 가능: 다양한 Eviction 알고리즘을 활용해 사용 패턴에 맞게 최적의 캐시 관리가 가능하다.
- 단점:
- 알고리즘에 따른 성능 차이: Eviction 알고리즘에 따라 성능이 달라질 수 있으며, 복잡한 알고리즘은 계산 부하가 발생할 수 있다.
- 데이터 일관성 어려움: 필요한 데이터를 우선적으로 제거할 경우, 캐시 미스로 인해 응답 속도가 떨어질 수 있다.|
🔎 캐싱 시나리오 예제
1️⃣ 웹서비스 메인 페이지 고정 컨텐츠
- 메인 페이지 고정 컨테츠는 캐싱을 하기에 큰 이점을 가질 수 있는 두가지 특징이 있다.
- 수정이 빈번하게 일어나지 않는다.
- 요청 빈도수가 높다.
- 갱신 전략
- 고정 컨텐츠 기간이 특정 시간으로 정해져있지 않은경우 관리자가 수동 갱신할수있도록 설계
- 특정 기간이 정해져 있다면 스케쥴러를 통해 주기마다 데이터를 갱신 시킨다
2️⃣ 수정이 많지 않은 컨텐츠의 페이징 처리 캐싱 (ex: 채용, 공연 정보 등)
- 수정이 많지 않은 컨텐츠의 페이징처리 부분에서의 캐싱처리
* 기획적인 부분에서 데이터의 최신화 속도의 중요도에따라 갱신 전략이 다를 수 있따
- 갱신 전략
- 최신화 속도의 중요도 낮은 경우 : 사람들이 비교적 많이 조회하는 1, 2, 3 페이지 정도의 데이터 일정 시간 이후에 삭제되도록 TTL을 설정 한 후 유저가 데이터를 조회할때 다시 데이터를 캐싱한다.
- 최신화 속도의 중요도 높은 경우 : 위와 같은 데이터를 캐싱하며, 해당 데이터가 수정, 삭제되는 경우, 캐싱 데이터를 삭제시켜준다. 이후 위와 같이 유저가 데이터를 조회할때 다시 데이터를 캐싱한다.
✳️ 참고자료