1장 사용자 수에 따른 규모 확장성 (3) - 캐시, CDN

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - System Design Interview

1장 사용자 수에 따른 규모 확장성 : 어떻게 수백만 사용자를 지원하는 시스템을 설계할 것인가.

1장 사용자 수에 따른 규모 확장성 (1) - 웹서버, 데이터베이스, 로드밸런스
1장 사용자 수에 따른 규모 확장성 (2) – 데이터베이스 다중화

에서 이어지는 글입니다.

캐시

캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소이다.

캐시 계층

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 별도의 캐시 계층을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일수도 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

읽기 주도형 캐시 전략 (read-through caching strategy)

캐시 사용 시 유의할 점

- 캐시는 어떤 상황에 바람직한가?
데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어날 때

 

- 캐시에 보관된 데이터는 어떻게 만료되는가?
만료 정책이 없으면 데이터는 캐시에 계속 남게 된다.
너무 짧으면 데이터베이스에서 너무 자주 읽게 되고
너무 길면 원본과 차이가 날 가능성이 높아지게 된다.

 

- 일관성(consistency)은 어떻게 유지되는가?
일관성 : 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부
저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않는 경우 이 일관성은 깨질 수 있다.

 

- 장애에는 어떻게 대처할 것인가.
캐시 서버를 한 대만 두는 경우 해당 서비스는 단일 장애 지점(Single Point of Failure, SPOF)이 되어버릴 가능성이 있다. 이를 피하려면 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다.

 

- 캐시 메모리는 얼마나 크게 잡을 것인가?
캐시 메모리가 너무 작으면 데이터가 자주 캐시에서 밀려나버려(eviction) 캐시의 성능이 떨어지게 된다.
캐시 메모리 과할당(overprovision)으로 막을 수 있다.

 

- 데이터 방출(eviction) 정책은 무엇인가?
LRU(Least Recently Used - 마지막 사용 시점 기준), LFU(Least Frequently Used - 사용 빈도 기준), FIFO(First In First Out - 들어온 순서대로)

콘텐츠 전송 네트워크 (CDN)

CDN은 정적 컨텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크이다.
CDN은 보통 제3 사업자에 의해 운영된다. 따라서 이 책에서는 CDN 자체에 대해서는 세부적으로 다루지 않는다

CDN을 사용하면 사이트 로딩 시간을 줄일 수 있고, 웹서버를 통해 서비스하지 않으므로 성능을 개선할 수 있다.

고려야야 할 사항

- 비용
자주 사용되지 않는 콘텐츠를 캐싱하는 것은 이득이 크지 않으므로, CDN에서 빼는 것을 고려하자.

 

- 적절한 만료 시한 설정
시의성이 중요한(time-sensitive) 콘텐츠의 경우 만료 시점을 잘 정해야 한다.
너무 길면 콘텐츠의 신선도가 떨어지고 너무 짧으면 원본 서버에 빈번히 접속하게 된다.

 

- CDN 장애에 대한 대처 방안
장애가 발생되었을 경우 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트를 구성하는 것이 필요할 수도 있다.

 

- 콘텐츠 무효화(invalidation) 방법
방법 1: CDN 서비스 사업자가 제공하는 API 이용
방법 2: 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버전닝 이용 (ex. image.png?v=2)

여기까지의 시스템 구성도

CDN을 통해 정적 콘텐츠를 제공함으로 웹 서버를 거치지 않도록 함과 동시에 더 나은 성능을 보장한다.
캐시를 통해 데이터베이스 부하를 줄여준다.