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

단일 서버

![[Pasted image 20250706203926.png]]

  • 도메인 주소(api.mysite.com) 를 입력하면 DNS (Domain Name Service) 를 통해 IP 주소로 변환

  • IP 주소를 통해 HTTP 요청 전달

  • 요청 받은 웹서버는 HTML 이나, Json 형태의 응답을 반환

데이터베이스

![[Pasted image 20250706204153.png]]

  • 관계형

    • RDBMS

    • 자료를 테이블과 열, 칼럼으로 표현

    • SQL 을 통해 Join할 수 있음.

    • e.g. mysql, postgresql

  • 비관계형

    • NoSQL

    • 그래프 저장소, 칼럼 저장소, 문서 저장소

    • e.g. Cassandra, redis..

  • 비 관계형은 언제 사용해야할까?

    • 아주 낮은 응답 지연시간이 요구될 때

    • 다루는 데이터가 비정형 데이터

    • 데이터(Json, Yaml, XML) 을 직렬화하거나 역직렬화 할 수 만 하면 됨.

  • 아주 많은 양의 데이터를 저장할 필요가 있을 때

수직적 규모 확장, 수평적 규모 확장

  • 수직적 -> scale up

    • 고사양의 자원을 사용하 는 것.

    • 한계가 있음.

    • 즉 무한대로 CPU나 메모리를 늘릴 순 없다.

  • 수평적 -> scale out

    • 더 많은 서버를 추가하여 성능 개선을 노린다.

  • 대규모 애플리케이션을 지원하는 데는, 수평적 규모확장법이 적절

로드 밸런서

![[Pasted image 20250706204603.png]]

  • 웹 서버는 클라이언트의 요청을 직접처리 하지 않음.

    • 왜? 보안을 위해

  • 로드밸런서를 추가하하면 no fail over 이슈가 해결됨.

    • 즉 장애를 자동복구하지 못하는 이슈

    • 가용성이 향상 된다. (availability)

데이터베이스 다중화

![[Pasted image 20250706204902.png]]

  • master - slave

  • 쓰기 연산은 마스터만

  • 사본은 읽기 연산만

  • 더 나은 성능

  • 안정성

  • 가용성

  • 로드밸런서 + 데이터베이스 다중화 고려 ![[Pasted image 20250706204951.png]]

캐시

  • 계시 계층은 데이터가 잠시 보관되는 장소.

    • 데이터베이스보다 훨씬 빠르다

  • 캐시를 두면 성능 개선 + 데이터베이스의 부하를 줄일 수 있음.

  • 그리고 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

캐시 사용 시 유의할 점

  • 캐시는 어떤 상황에서 사용이 바람직함?

    • 데이터 갱신이 자주 일어나진 않지만, 참조가 빈번히 일어날 때

  • 어떤 데이터를 캐시에 두어야함?

    • 휘발성 데이터

  • 캐시에 보관된 데이터는 어떻게 만료?

    • 정책을 정해둬야함.

    • 만료 없이 두면 안된다.

  • 일관성?

    • 일관성이 다소 깨질 수 있음.

    • 이 점은 인지해야한다.

  • 장애에 어떻게 대처?

    • 캐시 서버를 여러대 둔다.

    • 한대만 두면 단일 장애 지점이 될 수 있음.

  • 캐시 메모리 얼마나 크게?

    • 과할당 해야한다.

  • 데이터 방출 정책?

    • 캐시가 꽉 차면 기존에 있는 데이터를 어떻게 처리함?

    • LRU

      • Least Recently Used

      • 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 것

    • LFU

      • Least Frequently Used

      • 사용 빈도가 가장 낮은 데이터를 내보내는 정책

CDN

  • 정적 콘텐츠를 전송하는 데 쓰이는 네트워크

  • 비디오, CSS, Javascript 같은 파일 캐싱-

![[Pasted image 20250706205414.png]]

  • CDN 사용 시 고려해야할 사항

    • 비용

    • 만료 시한 설정해야함

    • 장애에 대한 대처 방안

    • 콘텐츠 무효화 방법

![[Pasted image 20250706205527.png]]

  • CDN을 통해 더 나은 성능 보장

  • 캐시가 데이터베이스의 부하를 줄여줌

stateless 웹계층

  • sticky session

    • 같은 서버로 요청이 갈 수 있도록 로드 밸런스 차원에서 지원

    • 단 로드 밸런스에 부하를 줌

      • 판단해야하므로

데이터 센터

![[Pasted image 20250706205834.png]]

  • geo dns routing

    • 사용자 가까운 데이터 센터로 안내

    • IP에 따라서..

메세지 큐

  • 메세지 무손실, durability, 메세지 큐에 일단 보관된 메세지는 소비자가 꺼낼때 까지 안전히 보관된다.

  • 비동기 컴퍼넌트

  • 메세지 버퍼역할

  • 생산자 or 발행자 - 소비자 or 구독자 구조

  • 메세지 큐를 사용하면 서비스 또는 서버 간 결합이 느슨해져서 규모 확장성이 보장되어야하는 안정적인 애플리케이션을 구성하기 좋음

로그, 메트릭 그리고 자동화

데이터베이스 규모의 확장

![[Pasted image 20250706210222.png]]

수직적 확장

  • scale up

  • 고성능 자원 사용

수평적 확장

  • sharding

  • 더 많은 서버 사용

  • 모든 샤드는 같은 스키마를 쓰지만, 샤드에 보관되는 데이터 사이에는 중복이 없다.

  • 샤딩 전략에서 가장 중요한 것은 샤딩 키 (sharding key)

    • partition key

  • 문제점

    • 데이터의 재 샤딩

      • 데이터가 많아서 하나의 샤드로는 더 이상 감당하지 못할 때

    • 유명인사 문제, hotspot key

      • 특정 샤으데 질의가 집중 되어 과부하가 걸리는 문제

    • 조인의 비정규화

      • 여러 샤드에 걸친 데이터를 조인하기가 힘듬.

      • 해결 방법은 데이터베이스 비정규화

백만 사용자, 그리고 그 이상

• 웹 계층은 무상태 계층으로 • 모든 계층에 다중화 도입 • 가능한 한 많은 데이터를 캐시할 것 • 여러 데이터 센터를 지원할 것 • 정적 콘텐츠는 CDN 을 통해 서비스할것 • 데이터 계층은 샤딩을 통해 그 규모를 확장할 것 • 각 계층은 독립적 서비스로 분할할 것 • 시스템을 지속적으로 모니터링하고, 자동화 도구들을 활용할것

참고

  • https://www.yes24.com/product/goods/102819435

Previous가상-면접-사례로-배우는-대규모-시스템-설계-기초-1Next2. 개략적인 규모

Last updated

Was this helpful?