Why livestreams fall behind

한 줄 요약

큐는 처리할 일을 잠시 보관하지만, 느린 소비자를 빠르게 만들지는 않습니다.

왜 이게 필요했나

고양이 구조대의 위치를 생중계한다고 상상해 봅시다. 구독자 아홉 명은 새 좌표를 바로 화면에 그리지만 한 명은 화면 처리를 멈췄습니다. 서버가 모든 구독자의 완료를 차례로 기다린다면, 멈춘 한 사람이 나머지 아홉 명의 지도까지 정지시킵니다. 반대로 일단 모두 큐에 넣고 다음 일을 하면 발행자는 편해지지만, 느린 사람의 큐는 계속 커집니다. 기다림을 없앤 것이 아니라 메모리로 옮긴 것입니다.

이 코스는 Python 함수·클래스·예외와 async/await 기초를 아는 학습자를 대상으로 합니다. 앞의 TCP 택배 코스를 마쳤다면 바이트 수신과 메시지 완료가 다르다는 점을 떠올려 보세요. 이번에는 메시지가 완성된 뒤에도 업무가 밀릴 수 있다는 문제를 다룹니다. 실제 외부 서비스를 공격하거나 인터넷을 열 필요 없이, 같은 실습 컨테이너 안의 두 TCP 구독자로 재현합니다.

어떻게 동작하나

초당 100개가 들어오고 60개를 처리하면, 버리지 않는 대기열은 처리율이 그대로인 동안 초당 약 40개씩 증가합니다. 큐를 4,000칸으로 늘리면 포화 시점만 늦출 뿐 지속적인 부족을 해결하지 못합니다. 큐의 길이뿐 아니라 가장 오래 기다린 항목의 나이도 보아야 합니다. 좌표 100개가 1초 치인지 10분 치인지에 따라 사용자가 보는 화면의 의미가 다릅니다.

asyncio.Queue(maxsize=4)는 큐 안에 기다리는 항목을 네 개로 제한합니다. 작업자가 get으로 가져간 한 항목은 그 길이에서 빠지지만, ACK를 기다리는 동안 여전히 메모리에 있습니다. 연결당 대기 4개와 처리 중 1개, 여기에 직렬화 버퍼와 소켓 버퍼가 따로 있습니다. 따라서 큐 길이 4를 전체 메모리 4항목 보장이라고 부르지 않습니다. 항목의 크기도 제한해야 바이트 단위 예산을 세울 수 있습니다.

다음 표에서 발행자는 생산자, 화면을 갱신하는 작업자는 소비자입니다.

호출	의미	흔한 오해
await queue.put(item)	빈칸이 생길 때까지 기다려 넣는다	모든 구독자의 처리가 끝났다
queue.put_nowait(item)	즉시 넣거나 QueueFull을 낸다	가득 차도 조용히 기다린다
await queue.get()	대기 항목 하나의 소유권을 가져온다	그 항목의 업무가 성공했다
queue.task_done()	가져간 작업의 정리를 기록한다	원격 데이터가 영구 저장됐다

이벤트 루프는 await로 제어권을 내놓는 동안 다른 작업을 진행합니다. await 없이 무한 반복하는 함수는 다른 연결도 멈춥니다. async def라는 선언 자체가 함수를 병렬 CPU 작업으로 바꾸지는 않습니다. 또한 asyncio.Queue의 maxsize=0은 영 칸이 아니라 무제한입니다. 첫 단계에서 양의 정수만 받도록 하는 이유입니다. bool은 Python에서 int의 하위 타입이지만 이 API의 용량으로는 거부합니다.

가득 찬 큐에서 기다리는 put을 취소하면 해당 발행도 종료되어야 합니다. 취소를 잡아서 성공처럼 반환하면 호출자는 들어가지 않은 이벤트를 보냈다고 믿을 수 있습니다. CancelledError를 무심코 삼키지 말고, 기존 항목이 그대로 남는지와 취소된 항목이 나중에 나타나지 않는지를 함께 확인합니다.

현장에서 만나는 모습

라이브 자막은 생성기가 잠시 빨라질 수 있어 작은 큐가 순간적인 차이를 흡수합니다. 그러나 모바일 화면이 계속 느리다면 어느 시점에 대기·생략·연결 종료 중 하나를 선택해야 합니다. 주문 처리는 오래된 주문을 버릴 수 없으므로 화면 좌표와 같은 정책을 쓰지 않습니다. 큐의 구현을 고르기 전에 데이터의 의미를 묻는 것이 먼저입니다.

이 수업의 ACK 보류는 구독자의 업무 처리가 느린 상황입니다. 커널 송신 버퍼 포화나 인터넷 패킷 손실을 직접 측정한 실험은 아닙니다. 측정한 계층을 분명히 해야 큐 길이를 바꾸고 네트워크 장애까지 해결했다고 착각하지 않습니다.

다음 확인에서 할 것

빈 용량 2 큐에 A와 B를 넣고 작업자가 A를 가져갔다고 적어 보세요. qsize는 1이지만 task_done을 아직 호출하지 않았으므로 미완료 작업은 둘입니다. C를 넣으면 qsize는 다시 2이고, D를 넣으려는 생산자는 기다립니다. 작업자가 B를 가져가는 순간 빈칸이 생겨 D가 들어갈 수 있습니다. A의 업무 완료와 다음 항목의 큐 삽입 가능 시점은 같은 사건이 아닙니다.

여기서 A가 영원히 ACK되지 않으면 작업자는 B를 가져가지 못합니다. 큐에는 B와 C가 남고 생산자는 D에서 멈춥니다. 이 연결의 큐만 보면 정상적인 역압력입니다. 그러나 그 생산자가 다른 모든 구독자를 담당한다면 전체 생중계의 정지로 번집니다. 같은 도구라도 소유 범위와 기다리는 위치에 따라 장애 반경이 달라집니다. 함수 하나만 보지 말고 누가 그 함수를 기다리는지 화살표로 그려 보세요.

큐 상한, 처리 중 항목, 취소된 put의 의미를 퀴즈로 구분합니다. 위 예제에서 A의 ACK가 돌아오는 경우도 추적해 막힌 생산자가 어떤 순서로 다시 진행하는지 비교하세요. 마지막 모듈의 통합 실습에서 make_queue와 offer_wait를 직접 구현한 뒤 같은 큐에 세 가지 정책을 적용합니다.