1장 사용자 수에 따른 규모 확장성

김수환·2024년 11월 11일
0

대규모 시스템 설계

목록 보기
1/8

사용자의 요청이 처리되는 과정

  1. 도메인 주소 해석
    웹 브라우저는 DNS(Domain Name System) 조회를 수행

    (사용자가 웹 브라우저에 입력한 도메인 주소를 해석)

    이 과정에서 도메인 이름을 기반으로 해당 서버의 IP 주소를 검색

    • 로컬 캐시: 브라우저 내부의 캐시에서 최근 방문했던 주소의 IP 먼저 확인
    • 운영 체제 캐시: 운영 체제에 저장된 DNS 캐시를 확인
    • 라우터의 로컬 네트워크 캐시: 라우터의 캐시 통해 IP 주소를 확인합
    • ISP의 DNS 캐시: 인터넷 서비스 제공업체(ISP)의 DNS 서버에 저장된 캐시를 확인
    • 상위 DNS 서버로 요청 전달: 서버는 최상위 DNS 서버인 루트 DNS 서버까지 재귀적 DNS 조회나 권한 있는 DNS 서버에 요청을 전달한다.

  2. TCP 연결 설정
    DNS 조회가 완료되면, 브라우저는 해당 IP 주소로 웹 서버와의 연결을 시도한다.

    • TCP(Transmission Control Protocol) 연결 설정
    • 3-way handshake
      TCP 연결이 설정되면, HTTP 프로토콜을 통해 클라이언트(웹 브라우저)와 서버 간의 통신이 시작된다.

  3. HTTP 요청 전송
    브라우저는 설정된 TCP 연결을 통해 HTTP 요청을 서버로 전송
    사용자가 특정 웹 페이지를 요청 -> 웹 서버는 해당 페이지에 대한 HTML 파일을 클라이언트에 응답
    이후 브라우저는 이 HTML 파일을 렌더링

scale up

장점

  • 고사양 자원(더 좋은 CPU, 더 많은 RAM) 추가
  • 확장이 단순함

단점

  • cpu, 메모리를 무한대로 증설할 방법은 없음
  • 장애 대응 어려움 : 자동 복구 지원이 없음

scale out

서버의 수평 확장을 통해 서버 수를 늘리는 것으로 성능을 향상

  • 비용성 측면 : 저렴한 서버를 사용하여 비용을 절감, 저성능 부품을 여러 대로 구성하는 것이 고성능 부품으로 서버를 구성하는 것보다 저렴
  • 안전성 측면 : 여러 대의 서버로 시스템을 분산시킴으로써 단일 서버 장애로부터 시스템을 안전하게 구성
  • 확장성 측면 : 스케일 아웃을 적용한 다중 서버로 구성 -> Auto-Scaling, 서버 다중 확장 편리

로드밸런서

  • public ip에 대해 요청을 분산
  • private ip로 통신

nginx.conf


http {
    upstream spring-backend {
        server spring-app1:8080;
        server spring-app2:8080;
        server spring-app3:8080;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://spring-backend;
        }
    }
}

데이터베이스 다중화

Master-slave 구조

  • Master : 쓰기 연산 지원
  • Slave :읽기 연산 지원

장점

  • 성능 개선 : 쿼리 처리를 병렬적으로 할 수 있어 성능 개선
  • 물리적인 안정성 강화 : 지역적으로 떨어져 있어 장애 생겨도 일부는 안전
  • 가용성 : 데이터를 복제해 두고 복구 가능

캐시

자주 참조되는 데이터를 메모리에 두고 빨리 처리될 수 있도록 하는 저장소

웹 서버의 캐싱 과정
요청 -> 캐시 확인 -> 있으면 반환, 없으면 db방문

캐시 사용 시 주의할 점

  • 갱신 대비 조회가 빈번하면 고려할 만 함.
  • 영속성 :
    • 캐시에만 보관하면 영속성상 바람직하지 않음
    • disk에 둘 필요가 있음
  • 데이터 만료 정책 :
    • 만료 기한 두고 삭제할 필요 있음
  • 일관성 유지 :
    • db와 데이터가 같은 지 여부.
    • 캐시 갱신, 저장소 갱신이 단일 트랜잭션인가
  • 장애 대처 :
    • 캐시 서버가 단일 서버면 너무 의존적일 수 있음
  • 캐시 매모리 크기 :
    • 작으면 날라가고, 크면 비용 과금

데이터 방출 정책 :

  • LRU(Least Recently Used) : 마지막으로 사용된 시점이 오래된 데이터 삭제

    • 장점:
      '자주 사용하는 데이터는 최근에도 사용될 가능성이 높다'는 가정 충족시 효과적
      캐시가 시간이 지나면서 최근 사용 데이터 중심으로 유지
    • 단점:
      데이터 사용 빈도를 고려하지 않음
      한 번의 요청 이후 거의 사용되지 않는 데이터도 캐시에 유지될 수 있음

  • LFU(Least Frequently Used) : 사용된 빈도가 가장낮은 데이터 삭제

    • 장점:
      자주 사용하는 데이터가 캐시에 남음 -> 특정 데이터의 반복적인 요청을 효율적으로 처리
      사용 빈도에 따른 데이터 유지에 적합
    • 단점:
      최근에 사용된 데이터를 반영하지 못할 수 있음 -> 일시적으로 급증하는 트래픽 패턴처리에 비효율적
      빈도 계산을 위한 추가적인 메모리와 연산이 필요해 성능에 부담이 될 수 있음

  • FIFO : 캐시에 들어온지 가장 오래된 데이터 삭제

    • 장점:
      구현이 간단하고, 메모리와 CPU 자원을 덜 씀.
      사용 패턴에 무관하게 데이터를 방출, 자주 데이터가 갱신되면 나을 수 있음.
    • 단점:
      데이터 사용 빈도나 최근 사용 여부를 고려하지 않음
      자주 사용하는 데이터가 캐시에 남아있지 못할 수 있어 캐싱 의미가 떨어짐

CDN

지리적으로 분산되어 콘텐츠를 캐싱해서 제공하는 서버
aws cloud front

웹사이트 로드 시간 개선

  • 물리적으로 가까운 CDN 서버를 사용 -> 웹사이트 방문자에 가까운 콘텐츠를 제공하여 페이지 로드 시간 단축
  • 사이트 로드가 빨라져 이탈율 감소

대역폭 비용 절감

  • CDN 캐싱을 통해 원본 서버가 제공해야 하는 데이터 양을 줄여 호스팅 비용 절감

콘텐츠 가용성 및 이중

  • CDN은 분산되어 있어 원본 서버보다 더 많은 트래픽을 처리할 수 있고 하드웨어 장애를 견딜 수 있음

넷플릭스는 Isp(인터넷 제공 업체)에 무상으로 OCA(넷플릭스 자체 cdn)을 제공하여 사용자 경험을 극대화 하고 있음
https://velog.io/@genius00hwan/%EB%84%B7%ED%94%8C%EB%A6%AD%EC%8A%A4%EA%B0%80-%EC%9E%90%EC%B2%B4-CDN%EC%9D%84-%EA%B5%AC%EC%B6%95%ED%95%9C-%EC%9D%B4%EC%9C%A0

무상태 웹 계층

상태 정보 의존적 아키텍처

  • 사용자의 상태를 유지하며 통신
  • 로드밸런서는 이를 위해 sticky-session(고정 세션)을 제공해야 함
  • 새로운 서버를 추가하기도 어려움

무상태 아키텍처


상태 정보를 저장하기 위해 RDB,캐시(Redis/Memcached)시스템이나 NoSQL 사용

수평 확장(Scaling Out)에 최적화
NoSQL 데이터베이스는 일반적으로 수평 확장에 최적화되어 있음

  • NoSQL은 다양한 자료구조로 복잡한 데이터를 처리하는 데 유연하고, 스키마를 유연하게 변경할 수 있음.
  • NoSQL 시스템은 분산 시스템 아키텍처를 기본으로 설계 되어있음
    • 노드를 추가하거나 교체해도 시스템 전체 가용성을 유지하도록 설계되어 있음
    • 여러 데이터 센터에 걸쳐 데이터를 분산하고 데이터 복제본을 유지하는 방식으로 데이터 손실을 방지하고 장애 복구를 빠르게 할 수 있게 설계
  • NoSQL 데이터베이스는 트랜잭션 일관성보다 성능과 확장성에 중점을 두는 경우가 많음.
    • 데이터의 정확한 일관성이 필수적이지 않은 경우, 높은 쓰기 속도와 빠른 데이터 분산 처리가 가능.

데이터 센터

데이터를 여러 데이터 센터에 두고 다중화 한다.

가용성을 높이고 장애대응에 효과적으로 하기위해 여러 데이터 센터를 두고 서비스를 지원한다.

  • 평소엔 지리적으로 가까운 데이터 센터로 연결된다.
  • 장애 발생 시엔 정상 데이터 센터로 트래픽을 우회한다.

메시지 큐

메시지의 무손실을 보장하는 비동기 통신을 지원하는 컴포넌트

서비스, 서버간 결합이 느슨해 질 수 있다.
규모 확장성이 보장되어야 하는 안정적 어플리케이션을 구성하기 적합하다.

로그, 메트릭, 자동화

로그 :

  • 에러 로그 -> 시스템의 오류와 에러들을 보기 편함

메트릭 :

  • 호스트 메트릭 : cpu, 메모리, 디스크 i/o등
  • 종합 메트릭 : db 쿼리 통계, api 호출 통계, 캐시 성능 등
  • 핵심 비즈니스 메트릭 : DAU, 수익, 재방문

자동화 : 빌드/테스트/배포 자동화

데이터베이스 규모 확장

샤딩: 데이터 베이스 수평적 확장

키를 해싱하여 여러 데이터베이스에 나눠서 저장

발생가능한 문제들
재 샤딩 :
데이터가 너무 많아지는 경우
샤드간 데이터 분포가 고르지 못한 경우
-> 안정해시로 해결

유명인사 문제 :
특정 샤드에 쿼리가 집중되는 경우

조인
샤딩된 데이터베이스간 조인이 발생하는 경우
비정규화로 이를 해결

profile
김수환
hello human
다음 포스트

[번외] 넷플릭스가 자체 CDN을 구축한 이유

0개의 댓글