메인 콘텐츠로 건너뛰기

소개

스트리밍 데이터를 수신할 때 연결 시간을 최대화하고 일치하는 모든 데이터를 받는 것은 가장 기본적인 목표입니다. 이를 위해서는 중복 연결을 활용하고, 연결 끊김을 자동으로 감지해 빠르게 재연결하며, 손실된 데이터를 복구하기 위한 계획을 마련하는 것이 중요합니다. 이 통합 가이드에서는 중복 연결, 백필(backfill), 복구와 같은 다양한 복구 및 중복성 기능에 대해 설명합니다.   중복 연결 중복 연결은 Filtered stream 에 둘 이상의 동시 연결을 설정할 수 있게 해주는 기능입니다. 이를 통해 두 개의 별도 컨슈머가 동일한 스트림에 연결하여 두 연결 모두를 통해 동일한 데이터를 수신함으로써 중복성을 확보할 수 있습니다. 따라서 하나의 스트림 연결이 끊기거나 애플리케이션의 기본 서버에 장애가 발생하는 등의 다양한 상황에서 App 이 즉시 전환 가능한 핫 페일오버(hot failover)를 갖게 됩니다. 현재 Filtered stream 은 Enterprise 액세스가 있는 Project 에만 최대 두 개의 중복 연결을 허용합니다. 중복 스트림을 사용하려면 기본 연결에 사용한 것과 동일한 URL 에 단순히 다시 연결하면 됩니다. 스트림 데이터는 두 연결 모두를 통해 전송됩니다.

연결 끊김 후 누락된 데이터 복구: 백필(Backfill)

연결 끊김을 감지한 뒤에는, 시스템이 스트림에 자동으로 다시 연결할 수 있도록 설계되어 있어야 합니다. 가능하다면, 적절한 복구 기능을 사용해 데이터를 백필할 수 있도록 연결이 얼마나 오래 끊겨 있었는지 시스템이 기록해야 합니다.  Enterprise 액세스가 있는 프로젝트를 사용 중이고 연결 끊김이 5분 이하였다고 확인한 경우, 백필 파라미터인 backfill_minutes를 사용할 수 있습니다. 이 파라미터를 GET /tweets/search/stream 요청에 함께 전달하면, 지난 1~5분 사이에 설정한 규칙에 매칭되는 포스트를 받을 수 있습니다. 일반적으로 이러한 과거 포스트를 새로 매칭된 포스트보다 먼저 전달하며, 포스트에 대해 중복 제거도 수행하지 않습니다. 따라서 예를 들어 90초 동안 연결이 끊겼지만 2분 분량의 백필 데이터를 요청한 경우, 30초 분량의 중복 포스트를 받게 되며, 시스템은 이 중복을 허용할 수 있어야 합니다. 다음은 backfill 파라미터를 사용한 요청 예시입니다: curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN" Enterprise 액세스가 없거나, 연결 끊김 시간이 5분을 초과했다고 확인한 경우, recent search endpoint 또는 Recovery 기능을 사용해 누락된 데이터를 요청할 수 있습니다. 다만 Search Posts 엔드포인트에는 sample:, bio:, bio_name:, bio_location: 연산자가 포함되지 않으며, keyword#hashtag 연산자에서 악센트와 발음 구별 기호를 사용할 때 매칭 동작에 일부 차이가 있습니다. 이러한 차이로 인해, filtered stream 엔드포인트를 통해 수신되었을 수도 있는 모든 포스트를 완전히 복구하지 못할 수 있습니다.  연결 끊김 후 누락된 데이터 복구: Recovery Enterprise 액세스가 있는 프로젝트를 사용 중인 경우, 5분 백필 윈도우 내에 재연결할 수 없는 상황에서 지난 24시간 이내의 누락된 데이터를 복구하기 위해 Recovery 기능을 사용할 수 있습니다. 스트리밍 Recovery 기능은 최대 24시간에 이르는 확장된 백필 윈도우를 제공합니다. Recovery를 사용하면 누락된 데이터가 발생한 기간을 “재생(replay)”할 수 있습니다. Recovery 스트림은 start_timeend_time 요청 파라미터를 사용해 연결 요청을 보낼 때 시작됩니다. 연결되면 Recovery가 지정된 기간의 데이터를 다시 스트리밍한 다음 연결을 끊습니다.   한 번에 최대 2개의 Recovery에 대한 동시 요청, 즉 “두 개의 Recovery 작업”을 수행할 수 있습니다. Recovery는 시작 및 종료 시간이 정의된다는 점을 제외하면 기술적으로 백필과 동일한 방식으로 동작합니다. 하나의 Recovery 기간은 단일 시간 범위에 해당합니다.
NameTypeDescription
start_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339).

복구를 시작할 UTC 기준 시작 시간을 나타내는 날짜입니다.
end_timedate (ISO 8601)YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339).

복구를 종료할 UTC 기준 종료 시간을 나타내는 날짜입니다.
요청 URL 예시: https://api.x.com/2/tweets/search/stream?start_time=2022-07-12T15:10:00Z&end_time=2022-07-12T15:20:00Z