서버 응답시간은 캐시를 붙이고, 정적 컨텐츠를 CDN으로 캐싱하여 개선할 수 있다.
캐시
캐시는 자주 참조되는 데이터를 캐시 서버에 임시 저장하여 요청이 빨리 처리될 수 있도록 하는 저장소이다.
캐시를 사용하면 DB의 부하가 줄어들어 어플리케이션 성능을 향상시킬 수 있다.
다만 캐시 사용시 아래 사항을 고려해야 한다.
- 캐시 만료 정책: 너무 짧으면 DB에 자주 접근하게 되고, 너무 길면 데이터가 원본가 차이 날 수 있다. 캐시는 TTL(Time To Live)에 명시된 기간동안 캐싱된다.
- 일관성 유지: 데이터의 원본과 캐시 사본은 같아야 한다. 저장소의 원본을 갱신하는 연산과, 캐시 업데이트 연산이 동시에 일어나지 않으면 이 일관성은 깨질 수 있다.
- 캐시 서버 분산: 캐시서버를 한대만 두면 Single Poing of Failure(단일 장애 지점: 한 지점에서의 장애가 전체 시스템 장애로 이어지는 경우)가 될 수 있다.
- 캐시 메모리 크기: 캐시 메모리가 너무 작으면 데이터가 자주 밀려나 성능이 떨어질 수 있다. 이 경우 메모리를 overprovision(과할당)할 수 있다.
- 데이터 방출 정책: 캐시가 다 찼을 때, LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First Out) 정책 등을 통해 데이터를 방출할 수 있다.
또한 데이터 종류나 크기, 액세스 패턴에 따라 캐싱전략이 다양하게 존재한다. (https://jjung0326.tistory.com/63)
CDN (Contents Delivery Network)
CDN은 정적 콘텐츠를 지리적으로 분산하여 캐싱하는데 쓰인다. 주로 이미지, 비디오, CSS, Javascript 등을 캐시한다.
CDN은 캐시와 유사한 방식으로 컨텐츠를 가져오지만, 지리적으로 분산되어있는 곳에 이점을 준다는 점이 크다. 원본서버가 멀다면 시간이 오래걸리겠지만, CDN을 사용하여 지리적으로 가까운 곳에서 가져올 수 있다면 더 빠른 응답속도를 낼 수 있다.
다만 CDN 사용시 아래 사항을 고려해야한다.
- 비용: CDN은 보통 써드파티에 의해 운영되어(Akamai, Cloudfront등) 데이터가 들어오고 나가는 양에 따라 요금이 부과된다.
- 만료 정책: 너무 짧으면 원본 서버에 자주 접근하고, 너무 길면 컨텐츠의 신선도가 떨어질 수 있다.
- 장애 대처: CDN자체가 죽더라도 직접 원본 서버로 부터 컨텐츠를 가져올 수 있도록 구성해야한다.
캐시와 CDN을 추가한 설계는 다음과 같이 그릴 수 있다.
'시스템설계' 카테고리의 다른 글
[시스템 설계] 데이터센터 이중화 (0) | 2023.05.06 |
---|---|
[시스템 설계] 무상태(stateless) 웹 계층 (0) | 2023.05.03 |
캐시 전략 (Cache Strategy) 종류 (0) | 2023.05.03 |
[시스템 설계] Failover 시스템 설계 (0) | 2023.04.27 |
Reverse Proxy, Forward Proxy (0) | 2023.04.26 |