add old post '사용자 수에 따른 규모 확장성 3'

_posts/2023-05-01-사용자-수에-따른-규모-확장성-2.md

@@ -14,7 +14,7 @@ tags:
     Scale Out,
     Replication,
   ]
-date: 2023-04-29 12:00:00 +0900
+date: 2023-05-01 12:00:00 +0900
 ---
 
 가상 면접 사례로 배우는 대규모 시스템 설계 기초 - System Design Interview

_posts/2023-05-01-사용자-수에-따른-규모-확장성-3.md

@@ -0,0 +1,90 @@
+---
+layout: post
+title: 사용자 수에 따른 규모 확장성 (3) – 캐시, CDN
+categories: [스터디-시스템 디자인]
+tags:
+  [
+    시스템 디자인,
+    System Design,
+    캐시,
+    캐시 전략,
+    CDN,
+    콘텐츠 전송 네트워크,
+    무효화,
+  ]
+date: 2023-05-01 13:00:00 +0900
+---
+
+가상 면접 사례로 배우는 대규모 시스템 설계 기초 - System Design Interview
+
+1장 사용자 수에 따른 규모 확장성 : 어떻게 수백만 사용자를 지원하는 시스템을 설계할 것인가.
+
+---
+
+# 캐시
+
+캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소이다.
+
+## 캐시 계층
+
+캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 별도의 캐시 계층을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일수도 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.
+
+## 읽기 주도형 캐시 전략 (read-through caching strategy)
+
+![read-through caching strategy](/assets/images/2023-05-01-사용자-수에-따른-규모-확장성-3/image1.png)
+
+요청을 받은 웹 서버는 캐시에 응답이 저장되어 있는지를 본다. 만일 저장되어 있다면 해당 데이터를 클라이언트에 반환한다. 없는 경우에는 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다.
+
+## **캐시 사용 시 유의할 점**
+
+**\- 캐시는 어떤 상황에 바람직한가?**  
+데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어날 때
+
+**\- 캐시에 보관된 데이터는 어떻게 만료되는가?**  
+만료 정책이 없으면 데이터는 캐시에 계속 남게 된다.  
+너무 짧으면 데이터베이스에서 너무 자주 읽게 되고  
+너무 길면 원본과 차이가 날 가능성이 높아지게 된다.
+
+**\- 일관성(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)
+
+# 여기까지의 시스템 구성도
+
+![system architecture](/assets/images/2023-05-01-사용자-수에-따른-규모-확장성-3/image2.png)
+
+CDN을 통해 정적 콘텐츠를 제공함으로 웹 서버를 거치지 않도록 함과 동시에 더 나은 성능을 보장한다.  
+캐시를 통해 데이터베이스 부하를 줄여준다.