키워드 위주 + 읽으면서 드는 생각들 정리
지은이의 글
“지원자를 평가하는 방법 중 하나는 모호한 문제를 어떻게 분석하고 단계적으로 해결하는지를 보는 것”
1장 사용자 수에 따른 규모 확장성
따로 찾아보면 좋을 것 같은 부분
- DNS 계층적 구조는 어떤 방식이고 어떻게 동작할까
- IP에 따라 라우터가 destination까지 어떻게 패킷을 전송할까
Scale-up vs Scale-out
- Scale-up 이 단순하지만 한계가 있다.
- cpu, memory 자원의 한계
- 장애가 나면 서비스 중단
- Scale-out이 여러모로 유리
-로드밸런서 활용 가능
DB master-slave, 다중화하면 좋다.
- 성능과 장애대비면 좋음
캐시 서버 활용하면 좋다.
- memcached 의 consistent hasing을 활용할 때 일관성이 깨지는 경우 조심
-특정 노드가 죽고, 해당 노드의 특정 데이터가 갱신되고 다시 죽었던 노드가 살아났다 다시 죽으면?
-캐시 만료를 짧게 가져가면 불일치의 시간을 그나마 줄일 수 있음.
CDN(콘텐츠 전송 네트워크)
- 정적인 컨텐츠 전달. 지리적으로 서버가 분산되어 있음. 이미지, 비디오, css, js 등
- 캐시와 비슷. 이미지 접근 시 CDN에 있으면 CDN에서 가져오고 없으면 원본 서버에서 가져오고 CDN에 저장.
서버가 여러개 이므로 세션 저장소를 고려해야 한다.
데이터센터 다중화 -> zero-downtime
- 트래픽 우회하는 방법 무엇이 있을까 ? GSLB 에서 VIP 제거 ?
데이터베이스 확장
- 수직적 : 고성능 서버 사용
- 수평적 : 샤딩 방식으로 확장 가능하지만 다음과 같은 문제 고려.
- 재샤딩 : 샤드 키 계산하는 함수도 변경하고, 데이터도 재배치 해야함.
- 핫스팟키 : 특정 샤드에 부하가 몰릴 수 있다. 부하가 고르게 분산되도록 고민 필요.
- 조인과 비정규화 : 여러 샤드에 걸친 데이터를 조인하기 힘듦.
2장 개략적인 규모 측정
결과보다 올바른 절차를 밟는 것이 중요
QPS : Query Per Second
HA : High Availability 고가용성
3장 시스템 설계 면접 공략법
오버엔지니어링 조심
병목 구간 고려
4장 처리율 제한 장치 설계
고려할 사항
서버 측에서 제한하나? 클라이언트 측에서 제한하나?
-> 서버측 제한 가정. 클라이언트 측 제한에 의존하면 위변조 같은 공격에 취약
제한하는 기준이 IP ? 유저 ID ?
-> 유연하게 설정할 수 있도록 가정
독립적인 컴포넌트인가? 코드에 포함되어야 하는가?
-> 독립적인 컴포넌트라 가정
보통은 클라우드 마이크로서비스를 많이 사용한다. cloudflare?
클라이언트와 서버 사이에 미들웨어(gateway)로 둔다.
레디스같은 메모리 기반 저장소를 처리율 제한 미들웨어로 많이 쓴다.
-> 쓰기 읽기 연산이 많아서 디스크는 적합하지 않음
클라이언트 -> 미들웨어 -> API 서버
클라이언트는 처리율 제한에 걸리면 보통 429 응답과 X-Ratelimit-? 헤더를 응답으로 받음
요청은 버려질 수도 큐에 보관될 수도 있다.
동기화 이슈
- 처리율 제한 장치를 여러 대 둔다고 할 때
- 특정 클라이언트가 요청을 반복할 때 서로 다른 처리율 제한 장치에 요청을 보낼 수 있음
- 고정 세션을 사용해서 같은 클라이언트를 같은 처리율 제한 장치로 보내는 방법이 있다.
- 하지만 유연성이 떨어져 그냥 레디스 하나 쓰는 게 답.
처리율 제한 알고리즘
a. 토큰 버킷
- 토큰 버킷에 토큰이 일정 시간마다 공급됨.
- 토큰 공급이 토큰 용량을 초과하면 토큰은 버려짐
- 요청 하나당 토큰 하나를 사용
- 토큰 버킷에 사용할 토큰이 없으면 요청은 버려짐
토큰 버킷을 몇개 쓰는가 ? -> 엔드포인트마다 혹은 IP주소 마다 등으로 정할 수 있다.
시스템의 처리율을 통합해서 제한하고 싶으면 하나의 버킷 사용.
토큰 공급률, 버킷 크기의 값을 적절히 선정하기가 까다로움.
b. 누출 버킷
- 요청을 큐에 넣음
- 큐가 가득차면 새요청은 버려짐
- 지정된 시간마다 요청을 큐에서 꺼냄
c. 고정 윈도 카운터
- 타임 라인을 고정된 간격의 윈도로 나누고 윈도마다 카운터 붙임
- 요청이 접수될 때마다 카운터 증가
- 카운터 값이 임계치에 도달하면 새요청은 새윈도가 열릴 때까지 버려짐
윈도 경계에 일시적으로 트래픽이 몰리면, 기대 했던 처리 한도보다 많은 처리되어 단점이 됨.
d. 이동 윈도 로깅
- 타임스탬프에 만료시간을 달아 로그로 저장
- 로그의 크기가 허용치보다 작거나 같을 때만 시스템에 요청 전달
메모리를 많이 잡아 먹는 단점이 있다
e. 이동 윈도 카운터
- 고정 윈도와 이동 윈도 로깅 결합, 겹치는 비율 계산해서 곱함