[System Design Interview] Ch1. 사용자 수에 따른 규모 확장성(2)

Yujeong·2023년 11월 5일
0
post-thumbnail

가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 바탕으로 정리한 내용입니다.

목차

  1. 응답시간 개선
    1) 캐시(Cache)
    2) CDN(Content Delivery Network)
  2. 무상태 웹 계층

1. 응답시간 개선

Ch1. 사용자 수에 따른 규모 확장성(1)에서는 웹 계층과 데이터베이스 계층의 부하를 어떻게 분산하지는를 살펴봤다. 그렇다면 응답 시간(latency)을 개선하기 위해서는 어떻게 해야할까? 그 첫번째는 캐시를 사용하는 것이다.

1) 캐시(Cache)

캐시는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다.
예를 들어, 쇼핑몰 웹 페이지에서 상품 목록을 불러온다고 하자. 그러면 새로고침 할 때마다 상품 목록을 가져오기 위해 한 번 이상의 데이터베이스 호출이 발생한다. 애플리케이션의 성능은 데이터베이스를 얼마나 자주 호출하느냐에 크게 좌우되는데, 캐시는 이런 문제를 완화할 수 있다.

캐시 계층(Cache Tier)

  • 데이터가 잠시 보관되는 곳으로, 데이터베이스보다 훨씬 빠르다.
  • 장점
    • 성능이 개선
    • 데이터베이스의 부하를 줄여 줌
    • 캐시 계층의 규모를 독립적으로 확장 가능
캐시 사용 시 주의사항
  • 갱신은 자주 일어나지 않고 참조는 빈전하게 일어나는 상황
  • 데이터: 휘발성 메모리기 때문에 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않다.
  • 데이터 만료: 만료된 데이터는 캐시에서 삭제되어야 한다. 만료기한이 너무 짧으면 데이터베이스를 자주 읽게 될 것이기 때문에 곤란하다. 만료기한이 너무 길다면 데이터베이스와 차이가 날 가능성이 높아지기 때문에 곤란하다.
  • 일관성 유지: 저장소의 원본 갱신과 캐시 갱신이 단일 트랜잭션에서 처리되지 않는 경우에는 일관성이 깨질 수 있다.
  • 장애 대응: 캐시 서버를 한 대만 두는 경우에 해당 서버는 단일 장애 지점(SPOF, Single Point of Failure)이 될 수 있기 때문에 여러 지역으로 캐시 서버를 분산해야 한다.
  • 캐시 메모리 크기: 너무 작으면 액세스 패턴에 따라서는 데이터가 너무 자주 캐시에 밀려나버려(eviction) 캐시의 성능이 떨어지게 된다. 그래서 캐시 메모리를 과할당(overprovision)하여 캐시에 보관될 데이터가 갑자기 늘어났을 때, 생길 문제를 방지한다.
  • 데이터 방출(eviction) 정책: 캐시가 꽉 차면, 추가로 캐시에 데이터를 넣어야 할 경우 기존 데이터를 내보내는 정책이다. 널리 쓰이는 방법에는 LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First Out) 같은 것이 있다.

🗒️ LRU: 가장 오래된 데이터 내보냄
🗒️ LFU: 사용된 빈도가 가장 낮은 데이터를 내보냄

2) CDN(Content Delivery Network)

CDN은 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.
요청 경로(request path), 질의 문자열(query string), 쿠키(cookie), 요청 헤더(request header) 등의 정보에 기반하여 HTML 페이지를 캐시하는 것이다.

어떤 사용자가 웹사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다. 사용자가 CDN 서버로부터 멀수록 웹사이트는 천천히 로드될 것이다. 예를 들어, CDN 서버가 서울에 있다면, 부산에 있는 사용자가 유럽에 있는 사용자보다 빠른 웹 사이트를 보게 될 것이다.

CDN 사용 시 고려사항
  • 비용: 보통 제3 사업자에 의해 운영되며, CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내게 된다.
  • 적절한 만료 시한 설정: 너무 길면 콘텐츠의 신선도는 떨어질 것이고, 너무 짧으면 원본 서버에 빈번히 접속하게 되어 좋지 않다.
  • CDN 장애에 대처 방안: CDN 자체가 죽었을 경우 웹사이트/애플리케이션이 어떻게 동작해야 하는지
  • 콘텐츠 무효화 방법: 아직 만료되지 않은 콘텐츠라 하더라도 아래 방법 가운데 하나를 쓰면 CDN에서 제거할 수 있다.
    • CDN 서비스 사업자가 제공하는 API 이용
    • 오브젝트 버저닝(Object Versioning) 이용

🗒️ 오브젝트 버저닝(Object Versioning): 콘텐츠의 새로운 버전을 지정한다. image.png?v=2와 같은 식이다.

다음은 CDN캐시가 추가된 설계다.


5. 무상태 웹 계층

무상태 웹 계층은 사용자 세션 데이터같은 상태정보를 웹 계층에서 제거하고 RDBMS나 NoSQL 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 구성된 웹 계층이다.

상태정보 의존적 아키텍처

  • 사용자A -> 서버1, 사용자B -> 서버2,사용자C -> 서버3와 같이 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되는 것이다.
  • 단점: 로드밸런서 뒷단에 서버를 추가하거나 제거하기 까다로워지고, 서버의 장애를 처리하기도 복잡해진다.

무상태 아키텍처

이 구조에서는 사용자로부터의 HTTP 요청이 어떤 웹 서버로든 전달될 수 있다. 그러면 웹 서버는 상태 정보가 필요할 경우에 공유 저장소(shared storage)로부터 데이터를 가져온다. 이러한 구조는 단순하고, 안정적이며, 규모 확장이 쉽다.

🗒️ 공유 저장소: RDBMS일 수도 있고, Memcached/Redis같은 캐시 시스템일 수도 있고, NoSQL일 수도 있다.

profile
공부 기록

0개의 댓글