1
2

클라이언트: "오늘 날씨 알려줘"
서버: "맑음, 25도" → 연결 끊김

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

[1단계: 연결]
클라이언트 ──── GET /events ────→ 서버
              (일반 HTTP 요청)

[2단계: 서버 응답 시작]
서버 응답 헤더:
  Content-Type: text/event-stream   ← ★ 이게 핵심
  Cache-Control: no-cache
  Connection: keep-alive

[3단계: 데이터 전송 (연결 유지한 채)]
서버 ──→ "data: 주가 50,000원\n\n"
서버 ──→ "data: 주가 50,100원\n\n"
서버 ──→ "data: 주가 49,900원\n\n"
  ...계속...

[4단계: 종료]
서버가 연결을 닫거나, 클라이언트가 close() 호출

1
2
3
4
5

event: price-update        ← 이벤트 이름 (선택)
id: 42                     ← 이벤트 ID (선택, 재연결 시 사용)
retry: 3000                ← 재연결 대기시간 ms (선택)
data: {"stock": "삼성", "price": 50000}   ← 실제 데이터 (필수)
                           ← 빈 줄로 하나의 메시지 끝을 표시

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// 연결 시작
const eventSource = new EventSource('/api/stock-prices');

// 메시지 수신
eventSource.onmessage = (event) => {
  console.log('받은 데이터:', event.data);
};

// 특정 이벤트만 수신
eventSource.addEventListener('price-update', (event) => {
  console.log('주가 업데이트:', event.data);
});

// 에러 처리 (+ 자동 재연결!)
eventSource.onerror = (error) => {
  console.log('연결 끊김, 브라우저가 자동으로 재연결 시도');
};

// 종료
eventSource.close();

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

[1단계: 연결]
클라이언트 ──── POST /api/chat ────→ 서버
              (아무 HTTP 메서드 가능)
              Body: {"message": "인공지능이 뭐야?"}

[2단계: 서버 응답 시작]
서버 응답 헤더:
  Content-Type: application/json   ← 자유로움
  Transfer-Encoding: chunked       ← ★ 이게 핵심

[3단계: 데이터 전송 (Chunk 단위로)]
서버 ──→ "인공"
서버 ──→ "지능은 "
서버 ──→ "인간의 "
서버 ──→ "학습 능력을..."
  ...계속...

[4단계: 종료]
서버가 마지막 chunk(크기 0)를 보내면 응답 완료 → 연결 자동 종료

1

Content-Length: 1024    ← "1024바이트짜리 응답이야"

1

Transfer-Encoding: chunked    ← "크기 모르겠고, 조각조각 보낼게"

1
2
3
4
5
6

7\r\n          ← 이 chunk는 7바이트
인공\r\n
9\r\n          ← 이 chunk는 9바이트
지능은 \r\n
0\r\n          ← 0바이트 = 끝!
\r\n

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// 연결 시작
const response = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ message: '인공지능이 뭐야?' }),
  headers: { 'Content-Type': 'application/json' },
});

// 스트림 읽기 - 직접 구현해야 함
const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;  // 스트림 끝

  const text = decoder.decode(value);
  console.log('받은 조각:', text);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

클라이언트 ──── HTTP GET ────→ 서버
                │
                │  특별한 헤더:
                │  Upgrade: websocket          ← "프로토콜 바꾸자"
                │  Connection: Upgrade         ← "연결 유지한 채로"
                │  Sec-WebSocket-Key: abc123   ← "인증 키"
                │  Sec-WebSocket-Version: 13   ← "버전"
                ▼

서버 ──── HTTP 101 Switching Protocols ────→ 클라이언트
                │
                │  Upgrade: websocket
                │  Sec-WebSocket-Accept: xyz789  ← "키 확인했어, OK"
                ▼

         ★ 이 순간부터 HTTP가 아니다 ★
         ★ WebSocket 프로토콜로 전환  ★

1
2
3
4
5
6
7
8
9

┌────────────┐                    ┌────────────┐
│            │ ──"안녕"──────────→ │            │
│            │ ←─"반가워"──────── │            │
│ 클라이언트  │ ──"지금 몇 시?"──→ │   서버      │
│            │ ←─"3시야"───────── │            │
│            │ ←─"참고로 비 온대"─ │            │  ← 서버가 먼저!
│            │ ──"고마워"────────→ │            │
│            │ ←─"새 메시지 도착"─ │            │  ← 서버가 또 먼저!
└────────────┘                    └────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

┌─────────────────────────────────────┐
│            WebSocket Frame          │
├──────┬──────┬────────┬──────────────┤
│ FIN  │ 종류 │ 길이   │   데이터     │
│ 1bit │ 4bit │ 7bit+  │   N bytes    │
├──────┼──────┼────────┼──────────────┤
│  1   │ 0x1  │  5     │  "안녕"      │  ← 텍스트 메시지
│  1   │ 0x2  │  1024  │  [바이너리]  │  ← 바이너리 (이미지 등)
│  1   │ 0x9  │  0     │              │  ← Ping (살아있니?)
│  1   │ 0xA  │  0     │              │  ← Pong (살아있어!)
│  1   │ 0x8  │  2     │  [코드]      │  ← 종료 요청
└──────┴──────┴────────┴──────────────┘

1
2
3
4

서버: "살아있니?" (Ping) ──→ 클라이언트
클라이언트: "살아있어!" (Pong) ──→ 서버

30초마다 반복... 응답 없으면 연결 끊긴 걸로 판단

1
2

종료하고 싶은 쪽 ── Close Frame (코드: 1000, 이유: "정상 종료") ──→ 상대방
상대방           ── Close Frame (코드: 1000) ──→ 종료 요청한 쪽

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// 1. 연결 (핸드셰이크 자동 처리)
const ws = new WebSocket('ws://example.com/chat');
//                        ▲
//                    ws:// (HTTP) 또는 wss:// (HTTPS)

// 2. 연결 성공
ws.onopen = () => {
  console.log('연결됨!');
  ws.send('안녕하세요');
  ws.send(JSON.stringify({ type: 'join', room: '1' }));
};

// 3. 메시지 수신
ws.onmessage = (event) => {
  console.log('받음:', event.data);
};

// 4. 연결 끊김
ws.onclose = (event) => {
  console.log(`종료: 코드=${event.code}, 이유=${event.reason}`);
  // ⚠️ 자동 재연결 없음! 직접 구현해야 함
};

// 5. 에러
ws.onerror = (error) => {
  console.log('에러 발생:', error);
};

// 6. 종료 (원할 때)
ws.close(1000, '사용자가 나감');

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

┌──────────────────────────────────────────────────────┐
│                      SSE                              │
│  클라이언트 ◄──────────── 서버                        │
│              단방향, HTTP 위에서                       │
│  📻 라디오: 듣기만 가능                               │
└──────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────┐
│                  HTTP Streaming                       │
│  클라이언트 ───요청──► 서버                           │
│  클라이언트 ◄──조금씩── 서버                          │
│              1회성 응답, HTTP 위에서                   │
│  🚰 수도꼭지: 틀면 나오고, 끝나면 끝                  │
└──────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────┐
│                    WebSocket                          │
│  클라이언트 ◄──────────► 서버                         │
│              양방향, 별도 프로토콜                     │
│  📞 전화통화: 동시에 말하고 들을 수 있음               │
└──────────────────────────────────────────────────────┘

1
2
3
4
5
6
7
8

POST /v1/chat/completions
Body: { "stream": true, "messages": [...] }

응답:
data: {"choices":[{"delta":{"content":"인"}}]}
data: {"choices":[{"delta":{"content":"공"}}]}
data: {"choices":[{"delta":{"content":"지능"}}]}
data: [DONE]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

실시간 통신 기술 스펙트럼:

단순 ◄──────────────────────────────────► 복잡

Polling     SSE      HTTP         WebSocket
(주기적     (서버→    Streaming    (양방향,
 질문)      클라)    (응답 쪼개기)  풀 듀플렉스)

"5초마다    "서버가   "응답을      "서버↔클라
 새 거      알아서    조금씩       자유롭게
 있어?"     보내줌"   흘려보냄"    주고받음"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

브라우저의 HTTP/1.1 연결 제한: 도메인당 최대 6개

┌─ 브라우저 ─────────────────────────────────────┐
│                                                 │
│  연결 1: SSE /api/notifications  ← 점유 중      │
│  연결 2: SSE /api/stock-prices   ← 점유 중      │
│  연결 3: GET /api/users          ← 일반 요청     │
│  연결 4: GET /api/products       ← 일반 요청     │
│  연결 5: POST /api/order         ← 일반 요청     │
│  연결 6: GET /static/image.png   ← 일반 요청     │
│                                                 │
│  ⚠️ 연결 꽉 참! 더 이상 요청 못 보냄             │
│  GET /api/settings → 대기열...                   │
└─────────────────────────────────────────────────┘

1
2
3
4
5
6
7

┌─ 탭 1 ──────┐  ┌─ 탭 2 ──────┐  ┌─ 탭 3 ──────┐
│ SSE 연결 1   │  │ SSE 연결 3   │  │ SSE 연결 5   │
│ SSE 연결 2   │  │ SSE 연결 4   │  │ SSE 연결 6   │
└──────────────┘  └──────────────┘  └──────────────┘
                                          ▲
                              6개 전부 소진!
                         일반 API 요청 전부 블로킹

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

TCP 연결 1개 = SSE 스트림 1개

클라이언트 ═══════════════════════ 서버
  │         TCP 연결 #1              │
  │  ◄── data: msg1\n\n             │
  │  ◄── data: msg2\n\n             │
  │         (이 연결은 계속 점유)     │

클라이언트 ═══════════════════════ 서버
  │         TCP 연결 #2              │
  │  ── GET /api/users ──►          │
  │  ◄── 200 OK (응답 후 반환)       │
  │         (사용 후 풀로 반환)       │

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[SSE 응답 완료 시 일어나는 일]

1. 서버가 res.end() 호출
   → HTTP 응답(Response)은 닫힘
   → TCP 연결은 살아있음 (Keep-Alive 기본값)

2. TCP 연결은 유휴(idle) 상태로 대기

3. 클라이언트가 다시 요청
   → 같은 TCP 연결 재사용 (3-way 핸드셰이크 생략)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

HTTP/2: 하나의 TCP 연결 안에 여러 스트림

클라이언트 ══════════════════════════════ 서버
  │            단일 TCP 연결                │
  │                                        │
  │  ┌─ 스트림 1: SSE /notifications ──┐   │
  │  │  ◄── data: 알림1\n\n            │   │
  │  │  ◄── data: 알림2\n\n            │   │
  │  └─────────────────────────────────┘   │
  │                                        │
  │  ┌─ 스트림 2: SSE /stock-prices ───┐   │
  │  │  ◄── data: 주가1\n\n            │   │
  │  │  ◄── data: 주가2\n\n            │   │
  │  └─────────────────────────────────┘   │
  │                                        │
  │  ┌─ 스트림 3: GET /api/users ──────┐   │
  │  │  ──► 요청                       │   │
  │  │  ◄── 200 OK                     │   │
  │  └─────────────────────────────────┘   │
  │                                        │
  │    ... 스트림 100개도 가능 ...          │

1
2
3
4
5
6
7

HTTP/1.1 200 OK\r\n
Content-Type: text/event-stream\r\n
Cache-Control: no-cache\r\n
Connection: keep-alive\r\n
\r\n
data: {"message": "hello"}\n\n
data: {"message": "world"}\n\n

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

┌─────────────────────────────┐
│  HTTP/2 HEADERS Frame       │  ← 바이너리, HPACK 압축
│  :status = 200              │
│  content-type = text/event- │
│    stream                   │
└─────────────────────────────┘
┌─────────────────────────────┐
│  HTTP/2 DATA Frame          │  ← 바이너리 프레임
│  data: {"message":"hello"}  │
└─────────────────────────────┘
┌─────────────────────────────┐
│  HTTP/2 DATA Frame          │
│  data: {"message":"world"}  │
└─────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

방법 1: 서브도메인 분리
  api.example.com     → 일반 API (6개)
  stream.example.com  → SSE 전용 (6개)
  → 총 12개 연결 확보

방법 2: SSE 연결 하나로 통합
  여러 이벤트 타입을 하나의 SSE 연결에 몰아넣기

  event: notification
  data: {"type": "message", "content": "안녕"}

  event: stock
  data: {"symbol": "삼성", "price": 50000}

방법 3: Long Polling으로 대체
  SSE 대신 주기적으로 HTTP 요청

1
2
3
4
5
6
7
8
9

HTTP/1.1 + SSE:
  "쓸 수는 있지만, 연결 제한 때문에 조심해야 한다"
  → 서브도메인 분리, 연결 통합 같은 우회 필요

HTTP/2 + SSE:
  "SSE의 약점이 거의 사라진다"
  → 멀티플렉싱 덕분에 연결 제한 문제 해결
  → 헤더 압축으로 오버헤드도 감소
  → 사실상 SSE의 최적 환경

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

서버:
  res.write(데이터1)
  res.write(데이터2)
  res.write(데이터3)    ← 계속 보냄
  ...

TCP 송신 버퍼:
  [데이터1][데이터2][데이터3][데이터4]...  ← 쌓임

클라이언트:
  데이터1 처리 중...           ← 아직 나머지를 읽지 못함

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

[정상 상태]
서버 ──데이터──► TCP 송신 버퍼 ──네트워크──► TCP 수신 버퍼 ──► 클라이언트
                  여유 있음                    여유 있음         빠르게 소비

[클라이언트가 느려지면]
서버 ──데이터──► TCP 송신 버퍼 ──네트워크──► TCP 수신 버퍼 ──► 클라이언트
                                              가득 참!         느리게 소비
                                                │
                                                ▼
                                    "TCP 윈도우 사이즈 = 0"
                                    (더 이상 보내지 마!)
                                                │
                                                ▼
                  TCP 송신 버퍼도 가득 참!
                        │
                        ▼
              res.write()가 블로킹됨
              서버도 자동으로 느려짐

1
2
3
4
5
6
7
8
9

┌────────────────────┬──────────────────────────┬─────────────┐
│        구간        │          속도            │ 쌓일 가능성 │
├────────────────────┼──────────────────────────┼─────────────┤
│ LLM → 서버         │ 토큰 생성 속도 (느림)    │ 거의 없음   │
├────────────────────┼──────────────────────────┼─────────────┤
│ 서버 → 클라이언트  │ 네트워크 전송 (빠름)     │ 거의 없음   │
├────────────────────┼──────────────────────────┼─────────────┤
│ 클라이언트 파싱    │ JSON.parse (매우 빠름)   │ 거의 없음   │
└────────────────────┴──────────────────────────┴─────────────┘

1
2
3
4
5
6
7
8

9장 (데이터 쌓임):                    10장 (연결 쌓임):
┌─ 연결 1개 ─────────────────┐       ┌─ 연결 1: 유저A ─┐
│  [데이터1][데이터2][데이터3] │       ├─ 연결 2: 유저B ─┤
│  버퍼에 데이터가 쌓임       │       ├─ 연결 3: 유저C ─┤
└────────────────────────────┘       ├─ ...            ┤
                                     ├─ 연결 10000     ─┤
                                     └──────────────────┘
                                     연결 수 자체가 문제

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

일반 HTTP:
  유저A 요청 → 응답 → 연결 반환 (수 ms)
  유저B 요청 → 응답 → 연결 반환 (수 ms)
  → 동시에 점유되는 연결 수가 적음

SSE / WebSocket:
  유저A 연결 → 유지... 유지... 유지... (수 분~수 시간)
  유저B 연결 → 유지... 유지... 유지...
  유저C 연결 → 유지... 유지... 유지...
  → 동시 접속자 수 = 동시 연결 수

1
2
3
4
5
6

동시 연결 수 증가에 따른 서버 상태:

~1,000개:  대부분의 서버에서 문제 없음
~10,000개: 파일 디스크립터 제한에 걸릴 수 있음 (OS 기본값: 1024)
~50,000개: 메모리 사용량 증가, GC 압박
~100,000개: OS 레벨 튜닝 없이는 커널 리소스 부족

1
2
3
4
5
6

[연결 유지]
클라이언트 ◄── data: 메시지1 ── 서버
클라이언트 ◄── data: 메시지2 ── 서버
클라이언트    (30초간 데이터 없음...)
서버: "타임아웃! 연결 종료"
클라이언트: 자동 재연결 (SSE) 또는 직접 재연결 (WebSocket)

1
2
3

서버 ──► ": heartbeat\n\n" (SSE 주석)     ← 15초마다
서버 ──► ": heartbeat\n\n"
클라이언트 응답 없음 → 죽은 연결로 판단 → 정리

1
2
3
4

정책 예시:
  - 서버 인스턴스당 최대 동시 SSE 연결: 5,000개
  - 유저당 최대 SSE 연결: 3개 (탭 3개까지)
  - 초과 시: 가장 오래된 연결 끊기 또는 429 Too Many Requests 반환

1
2
3
4

                    ┌─ 서버 1 (연결 5,000개) ─┐
유저 ── 로드밸런서 ──┼─ 서버 2 (연결 5,000개) ─┤
                    └─ 서버 3 (연결 5,000개) ─┘
                    총 15,000개 동시 연결 처리

1
2
3
4
5
6

# 파일 디스크립터 제한 늘리기 (기본값 1024 → 65535)
ulimit -n 65535

# 리눅스 커널 파라미터 조정
sysctl -w net.core.somaxconn=65535        # 최대 대기 연결 수
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[연결 풀링 없이]
데이터 소스 ──► 서버 ──┬──► 유저A (SSE)
                      ├──► 유저B (SSE)
                      ├──► 유저C (SSE)
                      └──► ... 10,000명

[메시지 브로커 사용]
데이터 소스 ──► Redis Pub/Sub ──┬──► 서버1 ──► 유저 A~D
                               ├──► 서버2 ──► 유저 E~H
                               └──► 서버3 ──► 유저 I~L

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

전통 서버 (EC2, VM):
  서버가 항상 떠 있음 → 연결 유지 자유로움
  직접 관리 → 세밀한 OS 튜닝 가능
  고정 비용 → 놀고 있어도 돈 나감

Cloud Run:
  요청 없으면 인스턴스 0개로 축소 (Scale to Zero)
  요청이 오면 자동으로 인스턴스 생성 (Auto Scaling)
  요청 처리 시간 기준으로 과금
  최대 요청 타임아웃: 60분
  인스턴스 간 상태 공유 불가 (Stateless)
  배포 시 기존 인스턴스 교체 (Rolling Update)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

HTTP Streaming:
  요청 → [스트리밍 응답...] → 60분 되면 강제 종료
  보통 수초~수분이라 문제 없음 ✅

SSE:
  연결 → [이벤트 전송...] → 60분 되면 강제 종료
  장시간 연결이 목적인데 60분 제한 ⚠️

WebSocket:
  핸드셰이크 → [양방향 통신...] → 60분 되면 강제 종료
  채팅 같은 장시간 연결에 치명적 ⚠️

1
2
3
4
5
6
7
8
9

[일반 HTTP - Scale to Zero 가능]
요청 → 처리(100ms) → 응답 → 인스턴스 유휴 → 축소 → 과금 중지

[SSE/WebSocket - Scale to Zero 불가]
유저A SSE 연결 유지 ─────────────────────────────
유저B SSE 연결 유지 ─────────────────────────────
  → 연결이 살아있는 한 인스턴스도 살아있음
  → Scale to Zero 불가
  → 요청이 없어도 과금 지속 💸

1
2
3
4
5
6
7

[일반 HTTP]
요청 → 처리(100ms) → 응답 → 과금: 100ms
  → 하루 총 활성 시간: 수 분

[SSE/WebSocket]
연결 → 유지(30분) → 종료 → 과금: 30분
  → 동시 접속 100명 × 평균 30분 = 하루 수천 분 💸

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

[배포 전]
유저A ──SSE──► 인스턴스 v1 (구버전)
유저B ──SSE──► 인스턴스 v1
유저C ──WS───► 인스턴스 v1

[배포 시작]
유저A ──SSE──► 인스턴스 v1 (드레이닝 시작)
유저B ──SSE──► 인스턴스 v1
유저C ──WS───► 인스턴스 v1
               인스턴스 v2 (신버전, 대기 중)

[드레이닝 완료 - 구 인스턴스 종료]
유저A ──끊김!
유저B ──끊김!
유저C ──끊김!

[재연결]
유저A ──SSE──► 인스턴스 v2 (자동 재연결 ✅)
유저B ──SSE──► 인스턴스 v2 (자동 재연결 ✅)
유저C ──????─► 인스턴스 v2 (재연결 로직 없으면 끊김 ❌)

1
2
3
4
5
6
7
8

[문제 상황: 채팅방 브로드캐스트]

유저A ──WS──► 인스턴스 1 (유저A의 연결 보관)
유저B ──WS──► 인스턴스 2 (유저B의 연결 보관)

유저A가 메시지 전송:
  인스턴스 1: "유저A가 메시지 보냄. 유저B에게도 전달해야 하는데..."
  인스턴스 1: "유저B가 어디 연결되어 있는지 모름!" ❌

1
2
3

Redis Pub/Sub로 인스턴스 간 메시지 전달:

유저A ──WS──► 인스턴스 1 ──publish──► Redis ──subscribe──► 인스턴스 2 ──WS──► 유저B

1
2
3
4
5
6
7
8

[Concurrency = 80 설정 시]

인스턴스 1:
  SSE 연결 1 (유지 중...)
  SSE 연결 2 (유지 중...)
  ...
  SSE 연결 80 (유지 중...)
  SSE 연결 81 → ❌ 새 인스턴스로 라우팅

1
2
3
4
5
6
7

연결 끊김 → 인스턴스 축소 (Scale to Zero)
         → 재연결 요청
         → Cold Start (1~3초 대기)
         → 인스턴스 생성
         → 연결 복구

유저 입장: "연결 끊기고 몇 초간 아무것도 안 됨"

1
2
3
4

1. 클라이언트 → 서버: Session ID 발급 요청
2. 서버 → 클라이언트: Session ID 반환
3. 클라이언트 → 서버: Session ID로 세션 등록 (SSE 연결)
4. 서버: 세션을 메모리에 저장, 이후 자유롭게 메시지 푸시 가능

1
2
3

Publisher → Channel("user-messages") → Subscriber A (인스턴스 A)
                                     → Subscriber B (인스턴스 B)
                                     → Subscriber C (인스턴스 C)

1
2
3
4

Redis Hash: session-registry
  user-a → instance-id-1
  user-b → instance-id-3
  user-c → instance-id-1