Server Sent Events 적용해보기

 

 

📌 SSE vs Web Socket

작년에 서울콘 행사를 위한 챗봇 서비스 만들면서 Server Sent Events 를 사용해 볼 기회가 생겼습니다.

개념에 대해서만 알고 있었지 직접 적용해 본 적은 없었는데, 간단히 어떤 프로토콜인지 살펴보도록 하겠습니다.

우선 Server Sent Events 와 Web Socket과 어떤 차이점이 존재하는지 간단하게 살펴보겠습니다.

 

https://softwaremill.com/sse-vs-websockets-comparing-real-time-communication-protocols/

 

챗봇 서비스는 특성상 실시간으로 양방향 통신이 필요하지 않았고 UTF-8 텍스트 데이터만 다루기 때문에 Server Sent Events 로 충분히 구현이 가능했습니다.
EventSource 인터페이스 사용 방법과 관련 내용은 공식문서를 참고해 보시면 좋을 것 같습니다.

 

📌 기존 EventSource의 한계점

1️⃣ 에러 처리의 어려움

표준 EventSource 인터페이스는 네트워크 요청 실패 혹은 서버 에러 등의 처리가 어렵습니다.

이는 EventSource 의 error 이벤트 핸들러가 인자로 Event 타입 객체를 넘겨주고 있기 때문입니다.

 

onerror = (this: EventSource, ev: Event) => any

 

이 인터페이스만을 가지고는 특정 에러의 상태코드, 메시지 등을 확인할 수 있는 방법이 없습니다. 😂

2️⃣ 인증 처리의 어려움

실제 서비스를 구현할 때 사용자 인증 정보를 포함해서 이벤트 스트림을 생성이 필요할 수 있습니다.

쿠키를 이용한다면 withCredentials 옵션을 사용할 수 있겠지만, 만약 Authorization 헤더를 사용할 필요가 있다면 EventSource 는 스트림 생성 시 HTTP 헤더를 지정할 수 있는 방법이 없다는 한계도 있습니다.

 

📌 Fetch API 기반의 이벤트 스트림 수신

위 문제를 해결하기 위해서 기본적으로 제공되는 EventSource 를 사용하지 않고 fetch+TextDecoder 기반으로 동일한 이벤트 스트리밍 프로토콜을 구현하는 방법을 사용할 수 있습니다.

Fetch API 표준을 준수하기 때문에 HTTP 헤더나 에러 발생 시 상태값 구분 및 에러 클래스 분기처리 등을 유연하게 처리할 수 있습니다.

NPM 패키지 사용해 보기

직접 구현할 수도 있지만 잘 구현되어 있는 오픈소스 패키지를 사용하는 방법도 있습니다.

여러 가지 패키지중에서 2가지가 가장 눈에 띄었습니다.

 

- fetch-event-source

microsoft에서 개발한 패키지라 구현 수준에 대한 신뢰도가 있습니다.

다만 현재 유지보수가 활발히 진행되지는 않습니다.

 

Azure/fetch-event-source: A better API for making Event Source requests, with all the features of fetch()

GitHub - Azure/fetch-event-source: A better API for making Event Source requests, with all the features of fetch()

 

- eventsource

Node.js와 브라우저 환경을 위한 isomorphic polyfill 이면서 header와 error처리를 위한 확장을 제공해 줍니다.

EventSource를 통해 요청을 보내기 전에 해당 엔드포인트로 http 요청을 보내서 네트워크 오류나 내/외부 서버 에러 등을 처리하는 일종의 헬스체크 로직을 포함하고 있습니다.

fetch-event-source 패키지보다 사용자가 많고 웹 표준 스펙을 준수합니다.

 

https://github.com/EventSource/eventsource

GitHub - EventSource/eventsource: EventSource client for Node.js and Browser (polyfill)

 

🤔 둘 중 어느 걸 선택하지?

두 패키지 모두 요청 취소 방법을 제공해주고 있습니다.

에러 핸들링은 웹 표준 Response 객체를 사용하는 fetch-event-source 가 더 유연한 것으로 보였고,

fetch-event-source 는 요청 재시도 기능을 함께 제공해 준다는 장점이 있었습니다.

 

그에 따라 최종적으로 fetch-event-source 를 사용하기로 결정했고, 최대 재시도 횟수 제한은 별도로 구현했습니다.

 

📌 스트리밍 상황에서 발생 가능한 다양한 상황들

데이터를 스트리밍 할 때에는 예외를 비롯해서 고려할 여러 부분들이 존재합니다.

먼저 이 내용을 살펴보기 전에 현재 API 구성 방식에 대해서 간단하게 설명하겠습니다.

현재 챗봇 API는 최초 요청 시 streamId 를 할당받고, 이후 대화맥락 데이터를 수신합니다.

streamId 를 통해서 대화 맥락을 구분 및 관리합니다.

사용자 요청 -> stream id 수신 -> Text, Content 등의 데이터 수신 -> End 메시지 수신

 

 

챗봇 API는 Text 와 Content 등의 데이터 타입들을 이용해서 사용자의 질문에 적합한 답변을 제공합니다.

클라이언트에서는 데이터 타입별로 적절한 처리를 통해서 사용자에게 제공할 답변을 생성합니다.

 

1️⃣ 에러 상황 분류하기

이제 클라이언트에서 처리해야 할 에러 상황들을 정리해 보겠습니다.

크게 다음과 같이 분류할 수 있습니다.

• 재시도 가능한 에러 (Retriable)
• 재시도 불가능한 에러 (Fatal)
• 재시도 N회 했음에도 실패한 경우 (Maximum Retrial Exceed)
• 특정 N초 동안 답변이 수신되지 않은 경우 타임아웃 (Timeout)
• 네트워크 이슈로 인한 fetch 요청 실패 (Network Error)

이외에 구현 요구조건에 따라서 보다 다양한 처리가 필요할 수 있습니다.

각각의 상황을 정리하고 기획자분과 협의하여 대응 방식을 결정합니다.

 

2️⃣ 에러 및 예외처리 요구사항 세분화하기

앞서 정의한 에러 상황에 더불어 API 요청을 중지하는 예외 상황도 함께 고려해 보겠습니다.

다음은 이번 서비스 개발 시 정의했던 정책들의 예시입니다.

 

API에서 발생한 재시도 가능한 에러

• 이 경우 최대 N번 재시도를 수행한다.
• 만약 N번 이후에도 실패한다면, MAX_RETRY_EXCEED 에러를 반환하고 사용자에게 에러 UI를 노출한다.

API에서 발생한 재시도 불가능한 에러

• 요청이 잘못된 형식인 경우 발생한다. 이 경우 재시도 자체가 불가능하다.
• FATAL_ERROR를 반환하고 사용자에게 에러 UI를 노출한다.

API 응답이 올바르지 못한 경우

• API 요청 시 서버 이슈로 응답 시작 직후 stream id 수신 이후에 아무런 응답이 없거나 네트워크 지연으로 인해 답변 수신이 안 되는 경우에 해당한다.
• 최대 N초 동안 유효한 메시지 타입인 Text, Content, End 타입의 메시지 수신을 기다린다.
• N초 이후에는 TIMEOUT 에러를 반환하고 에러 UI를 노출한다.

API 응답을 중지한 경우

• 만약 네트워크가 지연된 상태라면 아직 fetch 요청을 보내지 못한 상태이기 때문에 abort 처리한다.
• fetch 요청은 성공적으로 되었고 응답을 수신 중인 상태라면 답변 중지 API를 호출하고 스트림을 종료한다.

네트워크 요청에 실패한 경우

• 네트워크 미연결 혹은 gateway 이슈로 인해 요청 자체를 보내지 못한 경우이다.
• 사용자에게 네트워크 연결 상태 확인을 위한 에러 UI를 노출한다.