[대규모 시스템 설계] 사용자 수에 따른 규모 확장성(2): 응답 시간 개선을 위한 캐시, 컨텐츠 전송 네트워크(CDN) 도입

 

 

💋 인트로

이번 포스팅에서는 몇백만 사용자를 지원하는 시스템에서 규모 확장성과 관련된 설계 문제들을 정리해볼 것이다.

해당 내용은 가상 면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 키워드를 얻어 정리한 내용이다. 

 

지난 포스팅에 이어서 현재 인프라를 더욱 더 개선해볼 것이다. 

이제는 응답 시간을 개선할 것이다. 응답 시간은 캐시를 붙이고, 정적 컨텐츠를 컨텐츠 전송 네트워크로 옮기면 개선할 수 있다. 

 

 

💋 캐시

• 값비싼 연산결과 또는 자주 참조하는 데이터를 데이터베이스가 아닌 메모리에 두고, 요청이 빨리 처리될 수 있도록 하는 저장소
• 데이터베이스를 호출하는 횟수가 줄어들어서 애플리케이션의 성능 향상

이미지 출처: AWS

참고: https://aws.amazon.com/ko/caching/

 

✔ 캐시 계층

• 데이터가 잠시 보관되는 곳
• 데이터베이스보다 훨씬 빠름.

이미지 출처: https://velog.io/@haron/%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-1%EC%9E%A5-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1#%EC%BA%90%EC%8B%9C

위와 같은 방식은 캐시의 전략 중 Read-Through 캐시 전략이다. 

이외에도 읽기와 쓰기와 관련해 다양한 캐시 전략이 존재하는데, 아래 참고 링크를 읽어보면 좋을 것 같다. 

 

참고: https://loosie.tistory.com/800

 

✔ 캐시 도입 시 주의사항

• 어떤 상황에서?
  • 데이터 변경은 자주 일어나지 않지만, 읽기가 자주 일어날 때
• 어떤 데이터를 캐시?
  • 캐시는 휘발성 메모리에 데이터를 두는 것이므로, 영속적으로 보관할 데이터를 캐시하면 안됨.
  • 캐시 서버는 재시작하면 데이터가 모두 사라지므로, 중요한 데이터는 지속적 저장소에 두어야 함.
• 만료 기간 설정?
  • 정책을 마련해 두어야 함.
  • 만료기간이 너무 짧으면, 데이터베이스를 너무 자주 읽게 되고, 너무 길면 원본 데이터와 차이가 날 가능성이 높아지므로 trade off를 적절히 고려해야 함. 
• 데이터의 일관성 유지?
  • 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부 
  • 여러 지역에 걸쳐 시스템을 확장해 나가는 경우 캐시와 저장소 사이의 일관성을 유지하는 것은 어려운 문제가 됨.
  • 페이스북은 논문 Scaling Memcache at Facebook 참고
• 장애 대처?
  • 캐시 서버를 한 대만 두면 SPOF(Single Point of Failure)가 될 가능성이 있으므로, 여러 지역에 걸쳐 캐시 서버를 분산해야 함. 
• 캐시 메모리의 크기?
  • 메모리가 너무 작으면 데이터가 너무 자주 캐시에서 밀려나 캐시 성능 저하
  • 캐시 메모리를 과할당하면 캐시에 보관될 데이터가 갑자기 늘어났을 때 문제도 방지할 수 있음.
• 데이터 방출 정책?
  • 캐시가 꽉 차버리면, 추가로 캐시 데이터를 넣어야 할 경우 기존 데이터를 내보내야 함.
  • LRU, LFU, FIFO 정책 등이 있으며 경우에 따라 적용할 수 있음.

 

💋 컨텐츠 전송 네트워크 (CDN)

• CDN(Content Delivery Network) 
• 정적 컨텐츠를 전송할 때 쓰임.
• 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있음.
• 지리적으로 분산된 서버의 네트워크 

• 클라이언트가 웹사이트를 방문하면, 클라이언트에게 가장 가까운 CDN 서버가 정적 컨텐츠 전달
• 지리적으로 가깝기 때문에 광케이블 지나가고, 전선으로 01101010101 전기신호 전달하는 물리적 시간이 적게 들어가서, 웹사이트가 빨리 로드됨. 

이미지 출처:  https://mygumi.tistory.com/67

 

• 클라이언트가 찾으려는 정적 컨텐츠가 CDN에 존재하면 빠르게 로드하고, 없으면 CDN은 원본 서버(웹 서버, S3 등등)에서 정적 컨텐츠를 가져와서 저장함. 
  • TTL(Time to Live) 값을 설정해서 이 기간동안 CDN에 캐시됨. 

 

참고: https://www.ibm.com/kr-ko/topics/content-delivery-networks

참고: https://libertegrace.tistory.com/entry/Network-CDNContents-Delivery-Network-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

 

✔ CDN 도입 시 주의사항

• 비용
  • CDN은 보통 제3 사업자가 운영하기 때문에, 데이터 전송 양에 따라 요금을 내게 됨. 
• TTL 설정
  • 너무 길면 컨텐츠의 신선도가 떨어지고, 너무 짧으면 원본 서버에 너무 자주 접속해야 하므로 적절한 trade off가 필요함. 
• CDN 장애 대처 방안
  • CDN이 응답하지 않으면, 해당 문제를 감지해서 클라이언트가 원본 서버로부터 컨텐츠를 직접 가져오도록 구성해야 할 수도 있음.
• 컨텐츠 무효화 방법
  • CDN 사업자의 API를 사용해 컨텐츠 무효화
  • 컨텐츠의 다른 버전을 사용하도록 object versioning 사용 가능

 

💋 참고자료

• 책) 가상 면접 사례로 배우는 대규모 시스템 설계 기초
• https://velog.io/@haron/%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-1%EC%9E%A5-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1#%EC%BA%90%EC%8B%9C
• https://aws.amazon.com/ko/caching/
• https://loosie.tistory.com/800
• https://merrily-code.tistory.com/235
• https://libertegrace.tistory.com/entry/Network-CDNContents-Delivery-Network-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0