- 백엔드 아키텍처 기초 1
- 백엔드 아키텍처 기초 3 - 웹 계층 수평적 확장
- 백엔드 아키텍처 기초 4 - 데이터 센터
- 백엔드 아키텍처 기초 5 - 메시지 큐, 로그, 메트릭, 자동화
- 백엔드 아키텍처 기초 6 - 데이터베이스 규모 확장
백엔드 아키텍처 기초1에서는 사용자 규모에 따른 시스템 설계를 알아봤다.
이제는 응답시간(Latency) 개선에 대해 알아보자.
응답 시간은 캐시(Cache)와 콘텐츠 전송 네트워크(CDN, Content Delivery Network)로 개선할 수 있다.
사용자는 어떻게 웹사이트의 응답을 빨리 받아볼 수 있을까?
🚀 캐시
- 비싼 연산 결과 or 자주 참조되는 데이터를 메모리에 올린 후, 메모리에서 응답하는 임시 저장소
- DB에서 조회하는 것보다 메모리에서 조회하는 것이 매우 빠름
- 단점으로는 용량이 디스크에 비해 매우 적고, 비용이 비쌈
📚 캐시 계층
- 데이터가 잠시 보관되는 곳으로 DB보다 매우 빠름
- DB의 부하를 줄이고, 캐시 계층의 규모를 독립적으로 확장 가능
캐시 계층에 데이터가 있다면 아래 구조로 빠른 데이터를 반환받을 수 있음
캐시 계층에 데이터가 없다면 DB에서 데이터를 반환받아야 함
위 캐시 계층 구조처럼 캐시에 데이터가 있으면 반환하고 없으면 DB에서 반환받는 캐시 전략을 주도형 캐시 전략(Read-Through Caching Strategy)라고 한다. 이 외에도 다양한 캐시 전략이 존재한다.
📚 캐시 사용 시 주의사항
Q. 캐시는 어떤 상황에서 사용해야하는가?
A. 데이터 갱신은 자주 발생 X, 참조는 자주 발생 O
Q. 어떤 데이터를 캐시에 두는가?
A. 영속적 보관 데이터는 X, 휘발성 데이터는 O, 따라서 중요 데이터는 지속적 저장소에 보관
Q. 캐시 데이터의 만료시간은?
A. 만료된 데이터는 삭제해야하며, 너무 짧으면 DB조회가 많이 발생하며, 너무 길면 원본 데이터와 차이날 가능성 존재하므로 적절하게 설정해야함
Q. 일관성(consistency)은 어떻게 유지하는가?
A. 원본 데이터 갱신 연산과 캐시 갱신 연산이 단일 트랜잭션으로 처리되지 않으면 일관성이 깨질 수 있음. 따라서 Cache Invalidation, Cache Refresh, Write-Through, Read-Through, Write-Behind, Cache Validation 같은 방법들로 일관성을 유지할 수 있다.
✅ 캐시 무효화 (Cache Invalidation)
웹 서버가 데이터 요청 시, 캐시에서 찾아보고 없으면 DB나 다른 백엔드 서비스에서 데이터를 가져와 캐시에 저장한다.
쓰기(write) 요청일 경우, 웹 서버는 DB에 SQL문을 요청하고 memcache에 삭제 요청을 전송하여 오래된 데이터를 무효화시킴.
캐시된 데이터를 갱신하는 것보다 삭제하는 이유는 삭제는 중복적으로 수행해도 안전하기 때문이다. (멱등성)
위 같은 방법을 페이스북 논문인 Scaling Memcache at Facebook 에서 소개하고 있다.
세계에서 가장 큰 소셜 네트워크 서비스를 운영하는 페이스북의 Memcached 활용방법을 살펴보면 많은 도움이 될 것 같다.
Q. 장애 대응은 어떻게 할 것인가?
A. 캐시 서버 한 대만 두면 단일 장애 지점(Single Point of Failure) 될 가능성 존재함. 따라서 여러 지역에 걸쳐 캐시 서버를 분산해야 함.
Q. 캐시 메모리의 크기는?
A. 너무 작으면 용량 초과로 장애가 나거나, 데이터가 너무 자주 밀려나서(eviction) 캐시 성능 떨어짐. 결국 과할당(overprovision)해야 여러 문제를 방지할 수 있음.
Q. 데이터 방출(eviction) 정책은?
A. 캐시가 꽉 차면 기존 데이터를 방출할 정책을 정해야 한다. 보통 LRU 많이 쓰고, LFU, FIFO 등 상황에 맞게 사용함.
→ LRU : 가장 마지막으로 사용된 데이터 방출
→ LFU : 사용 빈도가 가장 낮은 데이터 방출
→ FIFO : 가장 먼저 들어온 데이터 방출
🚀 콘텐츠 전송 네트워크 (CDN)
- 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크
- 이미지, 비디오, CSS, JavaScript 파일 등 캐시 가능
- 사용자가 웹 사이트 방문 시, 지리적으로 가장 가까운 CDN 서버가 정적 콘텐츠를 제공함
- 물리적 거리가 가까울수록 속도가 빠름
- 미국 서버를 한국에서 접근하면 느리기에 한국 CDN서버로 빠른 응답 제공
- 사용자A가 이미지 파일 접근
- CDN 서버의 캐시에 이미지가 없으면 원본 서버에서 가져옴
- 원본 서버가 파일을 CDN 서버에 반환
- CDN 서버는 파일을 캐시하고 사용자A에게 반환
- 사용자B가 이미지 파일 접근
- 만료되지 않은 이미지 요청은 CDN 캐시를 통해 반환
📚 CDN 사용 시 주의사항
- 비용
- CDN은 제3 사업자에 의해 운영되며, 데이터 전송량에 따라 비용 발생
- 따라서 자주 사용되는 콘텐츠만 캐싱해서 사용
- 적절한 만료 시한 설정
- 캐시처럼 짧으면 서버와 자주 접속하고, 길면 일관성 문제 발생
- CDN 장애 대응
- CDN 서버 장애 시 원본 서버에서 정적 컨텐츠 제공하도록 시스템 구성
- 컨텐츠 무효화 방법 설정
- CDN 서비스 사업자가 제공하는 API로 컨텐츠 무효화
- 컨텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝(object versioning) 이용
🚀 캐시와 CDN이 추가된 아키텍처 설계
- 정적 컨텐츠(JS, CSS, 이미지 등)은 웹 서버가 아닌 CDN에서 제공하여 응답속도 개선
- 캐시를 통해 DB의 부하를 줄이고 응답속도 개선
가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬
'개발 etc' 카테고리의 다른 글
| 백엔드 아키텍처 기초 4 - 데이터 센터 (0) | 2023.07.07 |
|---|---|
| 백엔드 아키텍처 기초 3 - 웹 계층 수평적 확장 (0) | 2023.06.27 |
| AWSome Day 온라인 컨퍼런스 후기 (2) | 2023.06.21 |
| 백엔드 아키텍처 설계 기초 (6) | 2023.06.19 |
| 오라클 클라우드 MFA 분실로 인한 로그인 문제 (4) | 2023.03.31 |