1,000만 건의 WebSocket 이벤트 발생 후 발생한 문제와 실시간 AI 파이프라인 재설계 방법

1,000만 건의 WebSocket 이벤트가 발생한 후 무엇이 고장 났으며, 우리가 실시간 AI 파이프라인을 어떻게 재설계했는지에 대한 이야기입니다.

우리는 실시간 AI 애플리케이션을 구축하고 있었습니다. 우리의 스택은 다음과 같습니다:

• 프론트엔드: Next.js
• 백엔드: Python (FastAPI)
• 실시간 통신: WebSocket
• AI 모델: OpenAI (GPT-4o)
• 인프라: AWS

모든 것이 잘 작동하는 것처럼 보였습니다. 초기 테스트에서는 지연 시간(Latency)이 낮았고, 사용자 경험도 훌륭했습니다. 하지만 규모를 확장하면서 문제가 발생하기 시작했습니다.

무엇이 문제였는가?

우리가 1,000만 건의 WebSocket 이벤트를 처리하려고 했을 때, 시스템은 완전히 무너졌습니다. 주요 문제는 다음과 같았습니다:

1. 연결 관리의 한계 (Connection Management Issues): WebSocket 연결이 급증하면서 서버의 메모리 사용량이 기하급수적으로 증가했습니다. 각 연결은 서버 리소스를 점유하며, 수만 개의 동시 연결을 유지하는 것은 생각보다 훨씬 까다로운 작업이었습니다.
2. 이벤트 병목 현상 (Event Bottlenecks): 이벤트가 쏟아져 들어오면서 Python의 비동기(Async) 루프가 이를 처리하는 속도보다 이벤트가 쌓이는 속도가 더 빨라졌습니다. 이는 이벤트 큐(Event Queue)의 지연으로 이어졌습니다.
3. AI 모델 응답 지연 (AI Model Latency): OpenAI API로부터 응답을 기다리는 동안 WebSocket 연결이 유지되어야 했습니다. 모델의 응답 시간이 길어지면 연결이 타임아웃(Timeout)되거나, 대기 중인 다른 이벤트 처리가 지연되는 연쇄 반응이 발생했습니다.

어떻게 재설계했는가?

우리는 파이프라인을 근본적으로 다시 설계해야 했습니다. 단순히 서버를 늘리는 것(Scaling up)만으로는 해결할 수 없었습니다.

1. 메시지 브로커 도입 (Introducing a Message Broker)

서버가 직접 모든 WebSocket 이벤트를 처리하게 하는 대신, Redis Pub/Sub을 도입했습니다. 이제 FastAPI 서버는 이벤트를 수신하면 즉시 Redis로 전달하고, 별도의 워커(Worker) 프로세스가 이를 소비(Consume)하여 처리합니다. 이를 통해 API 서버의 부하를 줄이고 이벤트 처리를 분리할 수 있었습니다.

2. 비동기 작업 큐 활용 (Leveraging Asynchronous Task Queues)

AI 모델 호출과 같은 무거운 작업은 Celery를 사용하여 백그라운드에서 처리하도록 변경했습니다. 이를 통해 WebSocket 연결은 모델의 응답을 기다리며 차단(Blocking)되지 않고, 다른 이벤트를 계속해서 처리할 수 있게 되었습니다.

3. 상태 관리 최적화 (Optimizing State Management)

각 연결의 상태를 메모리에 직접 저장하는 대신, Redis를 사용하여 상태를 관리하도록 변경했습니다. 이는 서버가 확장(Scaling out)되더라도 사용자의 세션 상태를 유지할 수 있게 해주었습니다.

결과

재설계 이후, 시스템은 훨씬 더 견고해졌습니다. 이제 우리는 수백만 건의 이벤트를 안정적으로 처리할 수 있으며, 지연 시간도 크게 감소했습니다. 실시간 AI 애플리케이션을 구축할 때 확장성(Scalability)을 고려하는 것이 얼마나 중요한지 깨달은 값진 경험이었습니다.