3단계: 상세 설계
- 이전 단계에서 구상한 간단한 구성은 현재 요구사항과 같은 대규모 서비스에서는 문제가 생길 수 있다.
중요 구성요소별 규모 확장성
API 서버
- RESTful API 서버는 무상태성이고, 확장 방법이 널리 알려져 있으므로 생략한다.
웹소켓 서버
- 웹소켓 서버는 상태를 가진다.
- 따라서 클러스터를 축소하는 경우에는 각별한 주의가 필요하다.
- 서버를 제거하기 전에 기존 연결을 이첩하거나 종료해야 한다.
클라이언트 초기화
- 모바일 클라이언트 기동시 웹소켓 서버와 지속성 연결을 맺어야 한다.
- 이 연결을 통해 위치정보를 서버에 전달하고, 친구의 위치정보를 받아야 한다.
사용자 데이터베이스
- 사용자 데이터는 사용자의 ID를 기준으로 샤딩한다면 충분하다.
위치 정보 캐시
- 위치정보의 캐싱에는 수 GB정도면 충분하다. 따라서 메모리는 문제가 되지 않는다.
- 하지만 이전에 계산했듯, QPS가 매우 높으므로(약 33만), CPU가 문제가 될 수 있다.
- 다행히도 이러한 위치정보는 샤딩이 가능하다.
레디스 Pub/Sub 서버
- 레디스의 Pub/Sub은 높은 성능과 저렴한 비용으로 구현할 수 있다.
- 미리 정리하자면, 레디스 서버에는 대체로 메모리보다는 CPU가 더 큰 문제가 된다.
메모리 사용량
- 모든 사용자에게 채널을 하나씩 할당해야한다.
- 10억 사용자의 10%이므로 1억개의 채널이 필요하다.
- 한 사용자의 친구 중 약 100명만 활성화 되어있다고 가정한다.
- 구독자 한명을 위해 해시테이블과 연결리스트에 약 20바이트가 필요하다고 가정한다.
- 결과적으로 1억 100 20 = 200GB가 필요하다.
CPU 사용량
- 앞서 계산했듯, Pub/Sub 서버의 QPS는 약 1400만에 달한다.
- 보수적으로, 레디스 서버 하나당 처리 가능한 QPS를 10만으로 가정한다.
- 따라서 1400만 / 10만 = 140개의 레디스 서버가 필요하다.
레디스 Pub/Sub 서버의 규모 확장시 고려사항
-
Pub/Sub 서버는 채널에 대한 상태정보를 가진다.
- 즉, 채널 이동시 이를 모든 구독자에게 전파해야 한다.
- 이 과정에서 발생하는 부하가 상당하므로, 클러스터는 이를 최소화하기 위해 필요한 스펙보다 좀 더 여유있게 프로비저닝을 하는 것이 좋다.
-
게다가 해시 링을 사용해 샤딩되어있는 경우, 스케일 조정시 해시 링이 갱신된다면, 이로인해 엄청난 부하가 발생할 수 있다.
- 따라서 이 작업은 부하가 가장 적은 시간대에 이루어져야 할 것이다.
-
다행인 점은, 특정 서버의 이상으로 단순 교체시에는 문제가 없다는 점이다.
- 이 경우에는 해당 서버의 채널만 다른 서버로 이전하면 된다.
안녕하세요!