Scalability

동시에 수용 가능한 요청 수는 얼마인가?

동시접속자 수	초당 요청 수 (RPS)	권장 시스템 설계 및 고려사항
500	50 RPS	단일 서버로 처리 가능하나, 향후 확장을 대비한 설계 필요
1K	100 RPS	로드 밸런서를 도입하여 두 대의 서버로 부하 분산 고려
2K	200 RPS	세션 상태 관리를 위한 분산 캐시 도입 검토
5K	500 RPS	데이터베이스 샤딩 또는 리플리케이션 고려
10K	1,000 RPS	콘텐츠 전송 네트워크(CDN) 활용하여 정적 자원 제공 최적화
20K	2,000 RPS	마이크로서비스 아키텍처 도입 검토
50K	5,000 RPS	서비스 메시 도입 및 오케스트레이션 도구 활용 고려
100K	10,000 RPS	글로벌 로드 밸런싱 및 멀티 리전 배포 검토
500K	50,000 RPS	대규모 분산 시스템 설계 및 데이터 일관성 유지 전략 수립 필요

 

 

Vertical Scaling – Scale up

• 기본적으로 노드를 더 강하게 구성
  • 하드웨어를 더 추가하여 서버를 더 강하게
  • 단일 노드에 더 많은 리소스를 추가
• 기존 인프라를 유지하면서 더 많은 컴퓨팅 파워 추가
  • 최적화를 통해 더 많은 요청 처리
  • 기존 코드에 대한 변경 X
  • 증가하는 작업 부하 -> CPU, RAM 및 DISK 추가
• 확장성 제한
  • 하드웨어에도 최대 용량 제한이 있음
  • 수백만 개의 요청 처리 -> 수평적 확장 또는 더 많은 컴퓨팅 확장 필요

 

Horizontal Scaling – Scale out

 

• 서로 다른 서버 간에 부하 분할(분산)
  • 기존 사양을 변경하지 않고 더 많은 머신 인스턴스를 추가
  • 여러 머신에서 처리 능력과 부하 분산을 공유
  • 리소스 풀에 더 많은 머신을 추가
• 확장성과 안정성을 모두 만족
  • 분산 아키텍처의 확장
• 여러 서버로 분할할 때의 고려사항
  • 상태가 있는지 여부
  • 데이터베이스 서버 -> CAP 정리 / 관리 필요

 

Load Balancer

• 모든 애플리케이션 노드에 걸쳐 트래픽 분산
  • 응답성과 가용성을 개선
  • 다양한 알고리즘을 사용하여 여러 백엔드 서버에 트래픽 분산 -> 해싱 알고리즘
• 내결함성이 있어야 하며 가용성을 개선
• 수평적 확장성 문제를 해결
  • 모든 키를 다시 정렬할 필요 없음

 

Distributed Caching

• 자주 액세스하는 데이터
  • 메모리에서 빠르게 액세스할 수 있는 캐시에 저장
  • 시스템 성능 개선
• 캐시로 대기 시간을 줄이고 애플리케이션을 더 빠르게 만듬
  • 마이크로서비스의 성능, 확장성, 가용성을 높임
  • 요청 수가 증가 -> 캐싱은 고가용성으로 요청 처리
• 애플리케이션 요청이 자주 변경되지 않는 데이터
  • 캐싱이 매우 효율적
• 자주 액세스하는 데이터를 캐시에 로컬로 저장
  • 마이크로서비스는 외부 시스템에 대한 반복적인 호출하는 대신 응답 시간이 더 빨라짐
• 향상된 성능
  • 서비스는 DB 또는 기타 외부 시스템에 대한 반복적인 호출 줄임
• 복원성
  • 외부 시스템을 사용할 수 없게 되어도 서비스가 계속 작동 가능
• 확장성
  • 서비스가 외부 시스템을 확장할 필요 없이 증가된 트래픽을 처리 가능

 

Distributed Caching Type

• In-memory cache
  • 컴퓨터의 주 메모리에 데이터 저장
  • 가장 빠른 유형의 캐시
  • 캐시를 다시 시작하거나 컴퓨터를 종료하면 데이터가 손실
• Disk cache
  • HDD나 SDD에 데이터 저장
  • 디스크 캐시는 메모리 내 캐시보다 느리지만 데이터 유지 가능
• 분산 캐시
  • 여러 컴퓨터에 분산
  • MSA와 같은 분산 시스템에서 사용
  • 데이터를 여러 위치에서 저장하고 액세스
  • 시스템의 성능과 확장성 개선

 

Caching Strategies

• Cache Aside
  • 클라이언트가 백엔드 서비스에 요청하기 전에 캐시에서 데이터 확인
  • 마이크로서비스가 DB에서 데이터를 읽어야 하는 경우 먼저 캐시 확인
  • 데이터가 사용 가능한 경우(Cache Hit) -> 캐시된 데이터가 반환
  • 데이터를 사용할 수 없는 경우(Cache Miss) -> DB에 데이터를 쿼리
  • 클라이언트는 백엔드 서비스에서 데이터를 검색 -> 다음 요청을 위해 캐시 저장
• Read-Through
  • Cache Miss 발생 -> DB에서 누락된 데이터를 로드하고 캐시를 채우고 애플리케이션에 반환
  • 클라이언트가 캐시에서 찾을 수 없는 데이터를 요청 -> 캐시가 자동으로 DB에서 데이터를 검색
  • 캐시는 항상 DB와 일관성 유지
• Write-Through
  • 데이터가 백엔드 서비스에 기록될 때마다 캐시  업데이트
  • 캐시는 항상 최신 데이터를 보유하지만, 쓰기 작업 수가 더 많아질 수 있음
  • 데이터는 먼저 캐시에 기록되고 그 다음 DB에 기록
• Write-Back or Write-Behind
  • 캐시 업데이트를 나중으로 미룸
  • 쓰기 작업 수가 줄어들지만 캐시에 최신 데이터가 없을 수 있음

 

Reference
마이크로서비스 디자인 패턴 완벽 가이드
https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa