메인 콘텐츠로 건너뛰기

연결 해제란 무엇인가요?

스트리밍 API에 연결한다는 것은 장시간 유지되는 HTTPS 요청을 보내고, 그 응답을 순차적으로 파싱하는 것을 의미합니다. powerstream 엔드포인트에 연결할 때는 HTTPS 요청을 생성하고, 가능한 한 오랫동안 결과 스트림을 수신해야 합니다. 서버 측 오류, 과도한 클라이언트 측 지연, 네트워크 문제, 정기적인 서버 유지 관리, 중복 로그인과 같은 상황이 없는 한, 당사 서버는 연결을 무기한 유지합니다. 스트리밍 엔드포인트에 대한 연결에서는 연결 해제가 발생하는 것이 흔하며, 이를 예상하고 재연결 로직을 구현해 두어야 합니다.

스트리밍 연결이 끊길 수 있는 이유

스트림은 여러 이유로 끊길 수 있습니다. 장애 원인을 파악하려면 스트림에서 반환된 오류 메시지를 확인해야 합니다. 연결이 끊길 수 있는 가능한 이유는 다음과 같습니다.
  • 잘못된 토큰이나 잘못된 인증 방식 사용과 같은 인증 오류가 발생한 경우
  • X 측의 스트리밍 서버가 재시작된 경우. 이는 보통 코드 배포와 관련이 있으며, 일반적으로 발생할 수 있는 상황이므로 이에 대비해 설계해야 합니다.
  • 스트림이 전송하는 포스트의 양을 Client가 처리하지 못하거나 데이터를 너무 느리게 읽는 경우. 모든 스트리밍 연결 뒤에는 Client로 전송할 메시지 큐가 있으며, 이 큐가 시간이 지남에 따라 너무 커지면 연결이 종료됩니다.
  • 계정이 일/월별 포스트 쿼터를 초과한 경우
  • 중복되는 활성 연결이 너무 많은 경우
  • Client가 갑자기 데이터 읽기를 중단한 경우. 스트림에서 읽어가는 포스트의 속도가 갑자기 떨어지면 연결이 종료됩니다.
  • 서버와 Client 간의 네트워크 문제
  • 일시적인 서버 측 문제, 예정된 유지 관리 및 업데이트가 있는 경우 (상태 페이지를 확인하세요)

연결 끊김을 예상하고 다시 연결하기

포스트를 스트리밍할 때의 목표는 가능한 한 오랫동안 연결을 유지하는 것이며, 이 과정에서 연결이 끊길 수 있음을 인지해야 합니다. 이 엔드포인트는 20초마다 keep-alive 하트비트(새 줄 문자처럼 보입니다)를 제공합니다. 이 신호를 사용해 연결이 끊겼는지 감지하십시오.
  1. 코드에서 새 콘텐츠와 하트비트가 더 이상 도착하지 않는 상황을 감지해야 합니다.
  2. 그런 일이 발생하면 코드에서 재연결 로직을 트리거해야 합니다. 일부 클라이언트 및 언어에서는 읽기 타임아웃을 지정할 수 있으며, 이를 20초로 설정할 수 있습니다.
  3. 서비스는 이러한 연결 해제를 감지하고 가능한 한 빨리 다시 연결해야 합니다.
이미 설정된 연결이 끊어지면 즉시 재연결을 시도하십시오. 재연결이 실패하면, 발생한 오류 유형에 따라 재연결 시도를 점진적으로 늦추십시오.
  • TCP/IP 레벨 네트워크 오류에 대해서는 선형 백오프를 적용하십시오. 이러한 문제는 일반적으로 일시적이며 빠르게 해결되는 경향이 있습니다. 재연결 간 지연 시간을 시도할 때마다 250ms씩 늘려 최대 16초까지 증가시키십시오.
  • 재연결이 적절한 HTTP 오류에 대해서는 지수 백오프를 적용하십시오. 5초 대기부터 시작해 시도할 때마다 두 배로 늘려 최대 320초까지 증가시키십시오.
  • HTTP 429 오류(요청 한도 초과)에 대해서도 지수 백오프를 적용하십시오. 1분 대기부터 시작해 시도할 때마다 두 배로 늘리십시오. HTTP 429를 받을 때마다, 해당 계정에 대한 요청 한도가 더 이상 적용되지 않을 때까지 기다려야 하는 최소 대기 시간이 증가한다는 점에 유의하십시오.  

누락된 데이터 복구

연결이 끊어지는 일이 발생하더라도, 그동안 수신하지 못한 모든 데이터를 다시 받을 수 있도록 사용할 수 있는 여러 가지 전략이 있습니다. 누락된 데이터를 복구하기 위해 취할 수 있는 핵심 단계는 데이터 복구 통합 가이드에 정리해 두었습니다.   

요청 한도 및 사용량

연결 한도는 응답에 포함되는 세 개의 헤더를 통해 확인할 수 있습니다. 이를 통해 규칙 엔드포인트를 얼마나 자주 호출할 수 있는지, 그리고 스트리밍 엔드포인트에 대해 몇 번까지 재연결 시도가 허용되는지 파악할 수 있습니다.
  • x-rate-limit-limit 은(는) 15분 시간 창 동안 클라이언트가 보낼 수 있는 전체 허용 요청 수를 나타냅니다.
  • x-rate-limit-remaining 은(는) 15분 시간 창 동안 남아 있는 요청 가능 횟수를 나타냅니다.
  • x-rate-limit-reset 은(는) 15분 시간 창이 다시 시작되는 시점을 나타내는 UNIX 타임스탬프로, 이 시점에 x-rate-limit-remaining 값이 0으로 재설정됩니다.
filter stream 엔드포인트는 현재 사용량 데이터를 보고하지 않습니다. 몇 개의 포스트가 전달되었는지 확인하려면, 코드에 측정(metering) 로직을 구현하여 소비량을 계측하고 필요 시 일시 중지할 수 있도록 할 수 있습니다.  스트림의 클라이언트 측을 호스팅하는 코드는 단순히 들어오는 포스트를 선입선출(FIFO) 큐 또는 유사한 메모리 구조에 삽입하고, 별도의 프로세스/스레드가 그 큐에서 포스트를 소비하여 콘텐츠를 파싱하고 저장을 위해 준비해야 합니다. 이러한 설계를 사용하면, 수신 포스트 양이 급격히 변할 경우에도 효율적으로 확장 가능한 서비스를 구현할 수 있습니다. 개념적으로는 HTTP를 통해 길이가 무한한 파일을 다운로드하는 것으로 생각할 수 있습니다.

재연결 모범 사례

백오프 전략 테스트

백오프 구현을 테스트하는 좋은 방법은 잘못된 인증 자격 증명을 사용하고 재연결 시도를 살펴보는 것입니다. 백오프가 올바르게 구현되었다면 429 응답을 전혀 받지 않아야 합니다.

여러 번 재연결될 때 문제 알림

Client가 재연결 간 시간의 상한 임계값에 도달하면, 연결에 영향을 주는 문제를 파악하고 조치할 수 있도록 알림을 보내도록 해야 합니다.

DNS 변경 처리

클라이언트 프로세스가 DNS TTL(Time To Live)을 준수하는지 테스트하세요. 일부 스택은 프로세스 수명 동안 조회된 주소를 캐시하고, 지정된 TTL 내에 발생하는 DNS 변경 사항을 반영하지 않습니다. 이러한 과도한 캐싱은 X가 IP 주소 간에 부하를 분산할 때 클라이언트 서비스에 중단을 초래할 수 있습니다.

User Agent

user-agent HTTP 헤더에 Client 버전이 포함되도록 해야 합니다. 이는 X 측에서 문제를 진단하는 데 매우 중요합니다. 사용하는 환경에서 user-agent 필드를 설정할 수 없다면, 대신 x-user-agent 헤더를 설정하십시오.