왜 실시간 통신이 필요한가?

일반적인 HTTP 요청은 “질문-답변” 구조다.

1
2

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

하지만 이런 상황이라면?

• 주식 가격이 실시간으로 계속 바뀌는 화면
• ChatGPT처럼 AI가 답변을 글자 단위로 타이핑하듯 보여주는 화면

매번 “새 데이터 있어?” 하고 물어보는 건 비효율적이다. 서버가 알아서 보내주면 좋겠다.

이걸 해결하는 세 가지 방법이 SSE, HTTP Streaming, WebSocket이다.

1. SSE (Server-Sent Events)

한 줄 요약

서버 → 클라이언트 방향의 단방향 실시간 채널. 브라우저가 기본 지원하는 표준 기술.

연결부터 종료까지 전체 흐름

데이터 형식

SSE는 텍스트 기반의 정해진 형식이 있다:

1
2
3
4
5

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

클라이언트 코드

브라우저가 EventSource라는 API를 기본 제공한다.

1
2
3
4
5
6

const eventSource = new EventSource('/api/stock-prices');

eventSource.onmessage = (e) => console.log(e.data);       // 메시지 수신
eventSource.addEventListener('price-update', (e) => {});   // 특정 이벤트 수신
eventSource.onerror = () => {};  // 끊기면 브라우저가 자동 재연결
eventSource.close();             // 종료

SSE의 핵심 특징

2. HTTP Streaming

한 줄 요약

일반 HTTP 응답을 끊지 않고 데이터를 조금씩 흘려보내는 방식. 별도 표준이 아니라 HTTP의 동작 방식을 활용하는 기법.

연결부터 종료까지 전체 흐름

핵심 메커니즘: Chunked Transfer Encoding

일반 HTTP는 응답의 전체 크기를 미리 알려준다:

1

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

HTTP Streaming은 전체 크기를 모른다:

1

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

클라이언트 코드

EventSource와 달리 fetch API로 직접 스트림을 읽어야 한다.

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

const response = await fetch('/api/chat', {
  method: 'POST',
  body: JSON.stringify({ message: '인공지능이 뭐야?' }),
});
const reader = response.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  console.log(decoder.decode(value));  // 받은 조각 출력
}

HTTP Streaming의 핵심 특징

잠깐, SSE랑 HTTP Streaming이 뭐가 다른 건데?

둘 다 “서버가 데이터를 조금씩 보내는 것"이라 헷갈릴 수밖에 없다. 가장 큰 차이는 연결의 수명이다.

• HTTP Streaming = 서버가 할 말을 다 하면 res.end() 호출 → 응답 끝 → 연결 종료. 1회성.
• SSE = 서버가 의도적으로 res.end()를 호출하지 않는다. 연결을 계속 열어둔 채, 새 이벤트가 생길 때마다 데이터를 push. 지속적.

비유하면 이렇다:

• HTTP Streaming = 질문하면 답변을 천천히 해주고, 다 말하면 전화 끊음
• SSE = 라디오 주파수를 켜두면 DJ가 계속 방송해줌. 끊기면 자동으로 다시 주파수 잡음

그래서 ChatGPT는? POST로 요청 Body를 보내야 하고, 응답이 끝나면 연결이 끊어지는 1회성이니까 HTTP Streaming이다. 다만 데이터 형식만 SSE의 text/event-stream을 빌려 쓴다.

3. WebSocket

한 줄 요약

HTTP로 악수한 다음, 완전히 다른 프로토콜로 전환해서 양방향 자유 통신하는 기술.

연결부터 종료까지 전체 흐름

1단계: 핸드셰이크 (HTTP → WebSocket 업그레이드)

HTTP는 딱 한 번, 악수(핸드셰이크)할 때만 사용된다. 그 이후로는 완전히 다른 프로토콜이다.

2단계: 양방향 통신 (Full-Duplex)

Full-Duplex란 전화 통화처럼 동시에 말하고 들을 수 있다는 뜻이다. HTTP는 워키토키(한쪽이 말하면 다른 쪽은 기다려야 함)에 가깝다.

3단계: 데이터 전송 (Frame 단위)

WebSocket은 **Frame(프레임)**이라는 단위로 데이터를 보낸다:

 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     │  [코드]      │  ← 종료 요청
└──────┴──────┴────────┴──────────────┘

HTTP처럼 헤더가 매번 붙지 않는다. 프레임 헤더가 2~14바이트밖에 안 되어서 오버헤드가 매우 적다.

4단계: 연결 유지 (Ping/Pong)

1
2
3
4

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

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

5단계: 종료 (Close Handshake)

1
2

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

양쪽 모두 Close Frame을 교환해야 깔끔한 종료다.

주요 종료 코드:

클라이언트 코드

1
2
3
4
5
6

const ws = new WebSocket('wss://example.com/chat');

ws.onopen = () => ws.send('안녕하세요');           // 연결 성공
ws.onmessage = (e) => console.log(e.data);         // 메시지 수신
ws.onclose = (e) => console.log(e.code, e.reason);  // 연결 종료 (자동 재연결 없음!)
ws.close(1000, '사용자가 나감');                     // 수동 종료

WebSocket의 핵심 특징

4. 세 가지 한눈에 비교

종합 비교표

5. 언제 뭘 써야 할까?

6. 실전: ChatGPT는 뭘 쓸까?

ChatGPT는 SSE 형식을 사용하는 HTTP Streaming이다.

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]

“POST인데 SSE?” → OpenAI는 SSE의 데이터 형식(text/event-stream)을 빌려 쓰되, EventSource 대신 fetch로 구현한다. 엄밀히는 SSE 형식을 사용하는 HTTP Streaming이라고 볼 수 있다.

7. 관련 기술과의 관계

8. Deep Dive: HTTP/1.1 vs HTTP/2에서의 SSE

SSE는 HTTP 위에서 동작하기 때문에, HTTP 버전에 따라 동작 방식이 크게 달라진다.

HTTP/1.1에서의 SSE

핵심 한계: 도메인당 연결 수 제한

HTTP/1.1은 하나의 TCP 연결 = 하나의 요청/응답이다. SSE는 연결을 계속 열어두니까, TCP 연결 하나를 점유하게 된다.

더 심각한 문제는 탭 간 연결 공유다.

“도메인당 6개"는 탭 하나가 아니라 브라우저 전체 기준이다. 같은 도메인(example.com)에 대한 TCP 연결을 브라우저의 모든 탭이 나눠 쓴다. 즉 탭을 아무리 많이 열어도 총 6개를 넘길 수 없다.

탭 3개에서 각각 SSE 2개씩 열면 6개가 전부 SSE에 점유된다. 이 상태에서 어떤 탭이든 일반 API 요청(GET /api/settings 등)을 보내면 빈 연결이 없어서 앞선 연결이 끝날 때까지 대기해야 한다. SSE는 연결을 끝내지 않으니, 사실상 무한 대기다.

헷갈리기 쉬운 포인트: HTTP 응답 종료 ≠ TCP 연결 종료

SSE 응답이 끝나면 “연결이 끊긴다"고 생각하기 쉽지만, 실제로는 HTTP 응답과 TCP 연결은 별개다.

서버가 res.end()를 호출하면 HTTP 응답은 닫히지만, TCP 연결은 Keep-Alive 기본값에 의해 살아있다. 이 TCP 연결은 유휴(idle) 상태로 대기하다가, 클라이언트가 다시 요청하면 같은 TCP 연결을 재사용한다 (3-way 핸드셰이크 생략).

HTTP/1.1에서 Connection: keep-alive가 기본값이기 때문에, 명시적으로 Connection: close를 보내지 않는 한 TCP 연결은 응답 후에도 살아있다. 즉 SSE 스트림이 끝나고 클라이언트가 바로 재연결하면, 새 TCP 핸드셰이크 없이 기존 연결을 재사용할 수 있다.

HTTP/2에서의 SSE

핵심 개선: 멀티플렉싱 (Multiplexing)

HTTP/2는 하나의 TCP 연결 안에서 여러 스트림을 동시에 처리할 수 있다.

SSE가 몇 개든 일반 API 요청을 블로킹하지 않는다.

비교표

데이터 전송 방식의 차이

전송 방식 비교

SSE의 메시지 형식 자체는 동일하지만, HTTP/2에서는 전송 계층이 바이너리 프레임으로 바뀌어 더 효율적이다.

HTTP/1.1 시절의 우회 방법들

연결 6개 제한 때문에 다양한 우회가 필요했다:

 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 요청

HTTP/2에서는 이런 우회가 전부 불필요하다. 하나의 TCP 연결 안에서 SSE 스트림과 일반 API 요청이 자유롭게 공존할 수 있기 때문이다.

정리

1
2
3
4
5
6
7
8
9

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

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

현재 대부분의 프로덕션 환경은 HTTP/2를 사용하고 있어서, SSE의 연결 제한 문제는 실무에서 거의 문제가 되지 않는다.

9. Deep Dive: 스트리밍에서 데이터가 쌓이는 문제와 TCP 백프레셔

SSE든 HTTP Streaming이든, 서버가 데이터를 보내고 클라이언트가 소비하는 구조다. 그런데 서버가 보내는 속도 > 클라이언트가 소비하는 속도라면 어떻게 될까?

문제: 버퍼에 데이터가 쌓인다

서버가 데이터를 아무리 빨리 보내도, 클라이언트가 느리면 중간 버퍼에 데이터가 쌓이게 된다. 이게 무한히 쌓이면 메모리 문제가 발생할 수 있다.

해결: TCP 백프레셔 (Backpressure)

TCP 프로토콜 자체에 이 문제를 해결하는 메커니즘이 내장되어 있다.

단계별로 보면:

1. 클라이언트의 소비가 느려짐
2. 클라이언트 측 TCP 수신 버퍼가 가득 참
3. 클라이언트가 서버에게 TCP 윈도우 사이즈 = 0 통보 (“더 보내지 마”)
4. 서버 측 TCP 송신 버퍼도 가득 참
5. 서버의 res.write() 호출이 블로킹됨
6. 서버가 자연스럽게 속도를 줄임

메모리가 무한히 쌓이지 않는다. TCP가 알아서 흐름을 조절해준다.

그래도 문제가 될 수 있는 시나리오

TCP 백프레셔가 대부분의 경우를 해결해주지만, 다음 상황에서는 주의가 필요하다:

실무에서는 대부분 괜찮은 이유

LLM 스트리밍 응답 같은 일반적인 케이스를 생각해보면:

데이터를 생성하는 쪽(LLM)이 병목이다. 토큰 생성 속도가 초당 수십~수백 개 수준이라, 네트워크나 클라이언트 파싱이 따라가지 못하는 상황은 현실적으로 거의 발생하지 않는다. 만약 클라이언트가 느려지더라도 TCP 백프레셔가 자동으로 속도를 조절해준다.

10. Deep Dive: 동시 연결 수가 너무 많아지는 문제

9장에서 다룬 건 하나의 연결 안에서 데이터가 쌓이는 문제였다. 이번에는 완전히 다른 문제다: 연결 자체의 수가 너무 많아지는 경우.

1
2
3
4
5
6
7
8

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

왜 문제가 되는가?

SSE와 WebSocket은 연결을 계속 유지한다. 일반 HTTP 요청은 응답 후 바로 연결이 반환되지만, 스트리밍 연결은 클라이언트가 연결을 끊거나 서버가 명시적으로 종료할 때까지 살아있다.

연결이 쌓이면 서버에서 무슨 일이 벌어지나

서버가 연결 하나당 소비하는 리소스

단계별 증상

기술별 차이

SSE가 WebSocket보다 서버 부담이 적은 이유

둘 다 연결을 계속 유지하는 건 같다. 하지만 서버가 연결 하나당 해야 할 일이 다르다.

SSE (단방향) — 서버는 res.write()로 데이터를 흘려보내기만 하면 된다. 클라이언트에서 이 연결로 데이터가 오지 않으므로, 서버는 읽기 감시를 할 필요가 없다. 프레임 파싱도 없고, 그냥 텍스트를 쓰면 끝이다.

WebSocket (양방향) — 서버는 보내는 것뿐 아니라 클라이언트가 보내는 데이터도 동시에 읽어야 한다. 게다가 WebSocket 프레임 스펙에 따라 opcode 확인, 마스킹 해제(unmask), payload 길이 계산 등 프레임 파싱 작업이 필요하다. 연결이 살아있는지 확인하는 Ping/Pong 처리, 종료 시 Close 핸드셰이크도 서버가 관리해야 한다. 채팅 같은 앱이라면 “이 유저가 어느 방에 있는지” 같은 연결별 상태까지 메모리에 들고 있어야 한다.

결국 같은 10,000개 연결이라도, SSE는 “보내기만 하는 파이프 10,000개"이고 WebSocket은 “양방향 전화 10,000통"이다. 연결 수 자체의 부담은 같지만, 연결당 CPU·메모리 비용이 WebSocket이 더 높다.

해결 방법

1. 연결 타임아웃 설정

일정 시간 동안 데이터가 없으면 서버에서 연결을 끊는다.

1
2
3
4
5
6

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

유휴 연결이 서버 리소스를 낭비하는 걸 방지한다.

2. Heartbeat (하트비트)

타임아웃과 함께 사용한다. 실제 데이터가 없어도 주기적으로 빈 메시지를 보내서 진짜 살아있는 연결과 죽은 연결을 구분한다.

1
2
3

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

3. 연결 수 제한 (Connection Limiting)

서버당, 유저당 최대 연결 수를 제한한다.

1
2
3
4

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

4. 수평 확장 (Horizontal Scaling)

서버 한 대로 감당이 안 되면 서버를 늘린다.

단, SSE/WebSocket은 Sticky Session(같은 유저를 같은 서버로 라우팅)이 필요할 수 있다. 연결이 유지되는 동안 서버가 바뀌면 안 되기 때문이다. Sticky Session의 한계와 대안(Redis Pub/Sub)은 12장에서 자세히 다룬다.

5. OS 레벨 튜닝

대규모 동시 연결을 처리하려면 OS 설정도 조정해야 한다.

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

6. 연결 풀링 / 팬아웃 아키텍처

4번(수평 확장)에서 로드밸런서로 서버를 늘려 연결을 분산했다. 하지만 서버를 늘리는 것만으로는 해결 안 되는 문제가 있다.

예를 들어 주식 시세 서비스에서 삼성 주가가 바뀌면, SSE로 연결된 모든 유저에게 이 변경을 보내야 한다. 서버가 3대인데 유저가 각 서버에 흩어져 있다면, 주가 변경 데이터를 3대 모두에게 전달해야 한다. 이때 중간에 메시지 브로커를 두면 이 문제가 깔끔하게 풀린다.

서버 1대 (팬아웃 없이) — 서버 한 대가 10,000개 연결을 다 들고 있다. 주가가 바뀔 때마다 10,000번 res.write()를 호출해야 한다. 유저가 더 늘면 서버 한 대로는 감당이 안 된다.

메시지 브로커 사용 (팬아웃) — 데이터 소스가 Redis에 한 번만 publish하면, 서버 3대가 각각 subscribe해서 자기 유저에게 전달한다. 서버를 더 늘리면 더 많은 유저를 처리할 수 있다.

정리하면:

• 수평 확장 (4번): 서버를 늘려서 연결을 분산 → “연결 부하” 해결
• 팬아웃 아키텍처 (6번): 거기에 Redis Pub/Sub을 추가 → “서버 간 데이터 동기화"까지 해결

Redis Pub/Sub, Kafka 같은 메시지 브로커를 사용하면 서버를 쉽게 수평 확장하면서도 모든 유저에게 동일한 데이터를 전달할 수 있다.

정리

데이터가 쌓이는 문제(9장)는 TCP 백프레셔가 자동으로 해결해주지만, 연결이 쌓이는 문제는 직접 설계하고 관리해야 한다. 서비스 규모에 맞는 전략을 선택하는 것이 중요하다.

11. Deep Dive: Cloud Run에서 스트리밍 운영 시 주의할 점

10장까지는 일반적인 서버 환경을 기준으로 설명했다. 하지만 Cloud Run 같은 서버리스 컨테이너 환경에서는 전통 서버와 다른 특성 때문에 추가적인 문제가 발생한다.

Cloud Run의 특성부터 이해하자

이 특성이 스트리밍 기술과 만나면 여러 문제가 생긴다.

이슈 1: 요청 타임아웃 (최대 60분)

Cloud Run은 하나의 요청에 대해 최대 60분의 타임아웃이 있다.

대응 방법:

• SSE: EventSource의 자동 재연결 덕분에 60분마다 끊겨도 클라이언트가 알아서 복구
• WebSocket: 클라이언트에 재연결 로직 필수 구현. 60분 되기 전에 서버에서 먼저 끊고 재연결 유도
• HTTP Streaming: LLM 응답 같은 1회성은 보통 수 분 내 완료되므로 문제 없음

이슈 2: Scale to Zero와 과금

Cloud Run의 핵심 장점인 “안 쓰면 0원"이 스트리밍에서는 작동하지 않는다.

과금 영향도 크다:

대응 방법:

• 연결에 적절한 타임아웃을 설정해서 유휴 연결 정리
• 비용이 민감하고 트래픽이 적으면 SSE 대신 Polling 고려
• 최소 인스턴스 설정으로 Cold Start와 비용 사이 균형 찾기

이슈 3: 배포 시 연결 끊김

Cloud Run은 새 버전 배포 시 기존 인스턴스를 교체한다. 이때 모든 스트리밍 연결이 끊긴다.

대응 방법:

• SSE: EventSource 자동 재연결 덕분에 비교적 안전
• WebSocket: 재연결 + 상태 복구 로직 필수
• 모든 방식: 클라이언트가 “연결 끊김 → 재연결” 시나리오를 반드시 처리해야 함

이슈 4: 인스턴스 간 상태 공유 불가

Cloud Run 인스턴스는 Stateless다. 인스턴스 간 메모리를 공유할 수 없다.

대응 방법:

• SSE (단방향): 서버가 일방적으로 보내므로 문제 적음
• WebSocket (양방향): Redis Pub/Sub, Firestore 같은 외부 상태 저장소 필수
• HTTP Streaming: 1회성이라 인스턴스 간 통신 불필요

이슈 5: 동시 요청 수 (Concurrency) 설정

Cloud Run은 인스턴스당 동시 처리 가능한 요청 수를 설정할 수 있다 (기본 80, 최대 1000).

1
2
3
4
5
6
7
8

[Concurrency = 80 설정 시]

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

일반 HTTP 요청은 수 ms 만에 슬롯을 반환하지만, SSE/WebSocket은 연결 시간 내내 슬롯을 차지한다.

대응 방법:

• SSE/WebSocket 전용 서비스는 Concurrency를 높게 설정 (예: 500~1000)
• 일반 API와 SSE 서비스를 별도 Cloud Run 서비스로 분리하여 각각 다른 Concurrency 설정 적용

이슈 6: Cold Start와 재연결

SSE/WebSocket이 타임아웃이나 배포로 끊기면 클라이언트가 재연결한다. 이때 인스턴스가 이미 축소되었다면 Cold Start가 발생한다.

1
2
3
4
5
6
7

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

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

대응 방법:

• 최소 인스턴스를 1로 설정하면 Cold Start 방지 (단, 비용 증가)
• 클라이언트에서 재연결 시 로딩 UI 표시

종합 비교: Cloud Run 적합도

Cloud Run에서 실시간 통신이 필요하다면, HTTP Streaming이 가장 궁합이 좋고, SSE는 자동 재연결 덕분에 쓸 만하며, WebSocket은 추가 인프라(Redis 등)와 재연결 로직이 반드시 필요하다.

12. Deep Dive: 서버리스 환경에서 실시간 세션 관리 - Redis Pub/Sub 적용

11장의 이슈 4에서 인스턴스 간 상태 공유 불가 문제를 간단히 다뤘다. 이번에는 실제로 이 문제를 어떻게 해결했는지, 구체적인 아키텍처를 살펴보자.

문제 상황: “왜 메시지가 안 와요?”

Streamable HTTP(HTTP POST + SSE 결합) 방식으로 서버→클라이언트 실시간 메시지를 구현했다. 로컬에서는 완벽하게 동작했지만, 서버리스 환경에 배포하자마자 메시지가 간헐적으로 전달되지 않는 현상이 발생했다.

왜 서버리스 환경에서 세션이 깨지는가?

실시간 메시지 전송의 핵심은 서버가 사용자의 세션 정보를 메모리에 유지하고 있어야 한다는 것이다.

인스턴스가 하나일 때는 문제 없다. 하지만 Cloud Run처럼 서버리스 환경에서는:

User A의 세션은 인스턴스 A의 메모리에 있다. 그런데 이벤트를 수신한 인스턴스 C가 User A에게 메시지를 전달해야 하는 상황이 발생한다. 인스턴스 C는 User A의 세션 정보가 없으니 메시지를 전달할 방법이 없다.

핵심은 세션을 가진 인스턴스 ≠ 이벤트를 처리하는 인스턴스라는 것이다.

해결: Redis Pub/Sub 도입

인스턴스 간에 **“이 사용자에게 메시지를 보내줘”**라고 통신할 수 있는 채널이 필요하다. 여기서 Redis Pub/Sub을 선택했다.

발행자가 구독자를 알 필요 없다. 채널에 던지면 구독 중인 모든 인스턴스가 받는다.

Case 1: 다른 인스턴스에 세션이 있는 경우

모든 인스턴스가 Redis 채널을 Subscribe하고 있으므로 메시지를 수신하고, User A의 세션을 실제로 보유한 인스턴스 A만 SSE Stream을 통해 클라이언트에 전달한다.

Case 2: 해당 인스턴스에 세션이 있는 경우

이벤트를 처리하는 인스턴스가 마침 세션도 가지고 있으면, Redis Pub/Sub을 거치지 않고 바로 전달한다. 이 최적화 경로 덕분에 불필요한 Redis 통신을 줄일 수 있다.

Case 3: 세션 종료도 Pub/Sub으로

세션 종료 요청이 어떤 인스턴스에 도착하든, 실제 세션을 가진 인스턴스가 이를 수신하고 정리할 수 있다.

왜 Sticky Session이나 공유 세션 저장소가 아닌가?

핵심은 SSE 연결이 특정 인스턴스의 메모리에 바인딩된다는 것이다. 세션을 공유 저장소에 옮기는 것만으로는 해결이 안 된다. 결국 “세션을 가진 인스턴스에게 알려주는” 메커니즘이 필요하고, Redis Pub/Sub이 이 역할에 적합하다.

또한 실시간 메시지는 전달 시점에만 의미가 있고, 오프라인 사용자에게는 별도로 푸시 알림을 보내므로 Pub/Sub의 “fire-and-forget” 특성이 오히려 적합하다.

남은 과제: 브로드캐스트 최적화

현재 구조에서는 메시지가 모든 인스턴스에 브로드캐스트된다. 인스턴스가 수백 개로 늘어나면 불필요한 네트워크 트래픽이 발생할 수 있다.

개선 방향은 인스턴스 매핑 레지스트리를 만드는 것이다:

1
2
3
4

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

채널을 user-messages:{instance-id}처럼 인스턴스별로 분리하면 타겟 Pub/Sub이 가능해져 불필요한 메시지 처리를 줄일 수 있다.