웹소켓
일반적으로 웹소켓이라 하면 채팅방을 가장 먼저 떠올릴 것이다.
그렇다면 웹소켓의 사용에 대해 잠시 생각해보자
웹소켓 :TCP 통신 방식으로 서버와-클라이언트간 지속적 연결을 유지하여 데이터를 주고 받을 수 있는 기술이다.
특징 !
1) 빠르다.
2) 서버에 부하가 발생할 수 있다.
빠르다는 건 진짜진짜 좋은거지만, 서버 부하는 큰 문제이다. 사용자가 많아지면 서버에서 처리를 못할 수 있기 때문이다.
그렇다면 이걸 어떻게 해결할까? 2가지 방법이 있다
스케일 업(Scale-Up)(=수직 스케일) : 기존 서버의 사양을 업그레이드, 시스템을 확장
CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법이다.
좋긴하지만 즉각적으로 문제를 해결하는 건 아니고, 돈도 많이 든다.
스케일 아웃(Scale-Out)(=수평 스케일) : 서버를 여러 대 추가, 시스템 확장
서버가 여러 대로 나뉨 -> 서버당 부하가 균등해야 함 -> 로드밸런싱 필수!!
그럼 로드밸런싱은 뭘까?
로드 밸런싱: 서버나 시스템에 가해지는 네트워크 트래픽(부하)을 여러 대의 서버에 분산시키는 기술
즉, 특정 서버의 과부하를 막고, 시스템의 가용성과 응답 시간을 최적화 할 수 있는 것.
- 부하분산(한 서버만 일 많이 하는 거 방지)
- 고가용성(한 서버 장애 나도 다른 서버로 요청)
- 성능확장(서버 추가/제거 가능)
- 장애예방(한 서버 다운시 그 서버로 요청 안함)
이는 라운드로빈(RR),최소연결(SJF),가중치, IP 해시 같은 걸로 구현 가능함.
하지만 RR로는 충분하지 않을 수 있어 스티키 큐를 많이 쓴다고 한다.
스티키 세션 (Sticky Sessions)
원리: 특정 클라이언트의 초기 연결 요청이 특정 서버 인스턴스에 할당되면, 이후의 모든 연결 요청과 통신은 동일한 서버로 고정.
장점: 서버 간 상태 동기화 문제를 일차적으로 회피할 수 있어 구현 간단.
단점: 특정 서버에 부하가 집중되는 핫 샤드(Hot Shard) 문제, 서버를 스케일 인(Scale-in)하거나 재시작할 때 해당 서버의 모든 연결이 끊어짐
아무튼, 로드밸런싱을 한다 하면 다음과 같은 그림을 생각할 수 있는 거다.
참고로 동시성 문제는 큐(순서 보장, 직렬화(선입선출))로 해결하면 되는 거고, 여기서 보면 소켓 커넥션 메타 서버가 있는데, (서버별 연결 사람과 인원 관리하는 서버) 이러면 특정 유저가 어떤 소켓서버에 있는지 알 수 없는 문제와 각 소켓서버에 몇명의 유저가 있는지 알 수 없는 문제도 해결 할 수 있어서 좋다.
'커넥션 메타 서버' 관리 방식?
'커넥션 메타 서버' = 중앙 집중식 세션/상태 관리 계층
-
중앙 상태 저장소 (Central State Store): Redis와 같은 인메모리 데이터베이스를 사용하여, 어떤 사용자(User)가 현재 어떤 서버 인스턴스(Server Instance)에 연결되어 있는지에 대한 메타데이터(연결 정보)를 저장.
-
부하 정보 수집: 각 웹소켓 서버 인스턴스는 자신의 현재 부하 상태를 메타 서버에 주기적 보고.
-
라우팅 결정: 클라이언트 웹소켓 연결을 시도시, 로드 밸런서가 이 메타 서버의 부하 정보를 기반으로 가장 부하가 적은 서버 인스턴스를 선택하여 연결을 라우팅.
실시간 체팅은 생각보다 하이 테크놀로지 였다...
