스트리밍 지연과 처리량 설계
지연은 레코드가 처리되어 목적지에 도달하는 데 걸리는 시간이고, 처리량은 일정 시간에 처리할 수 있는 레코드 수입니다. 항공편 지연 경고나 공급망 이상 대응처럼 즉시 조치해야 하는 업무에서는 두 기준을 함께 정해야 합니다.
지연에 영향을 주는 구간
| 구간 또는 조건 | 고려할 내용 |
|---|---|
| 원천 생성 속도 | Foundry는 원천이 제공하는 것보다 빨리 데이터를 받을 수 없습니다. |
| 네트워크 경계 | 방화벽과 네트워크 경로를 통과하는 시간도 수집 지연에 포함됩니다. |
| 파이프라인 단계 | 같은 Code Repository 또는 Pipeline Builder 그래프의 변환은 같은 물리 자원에 함께 배치하여 지연을 줄일 수 있습니다. 여러 저장소나 Builder 파이프라인을 연결하면 같은 최적화를 적용할 수 없어 추가 지연이 생깁니다. |
| 최종 목적지 | 온톨로지와 시계열은 낮은 지연의 소비 경로를 제공합니다. 외부 시스템도 해당 속도로 데이터를 받아야 합니다. |
| 일관성 모드 | 정확히 한 번 처리하는 보장에는 원자성 유지를 위한 부담이 있습니다. 적어도 한 번 처리하는 방식은 중복 처리를 허용하는 대신 지연을 줄일 수 있습니다. |
표준적인 단계별 지연
일반적인 스트리밍 경로는 15초 미만의 종단 간 지연으로 동작할 수 있습니다. 다음 수치는 설계 시 참고할 규모이며 실제 업무의 고정 보장값은 아닙니다.
| 단계 | 기본 exactly-once | at-least-once |
|---|---|---|
| 수집 | 약 1~2초 | 약 1~2초 |
| 변환 | 약 5초 | 약 1초 |
| 객체 저장소 또는 시계열 동기화 | 약 5초 | 약 1초 |
실제 지연은 변환 수와 복잡도, 일관성 모드와 시간 기반 윈도에 영향을 받습니다. 예를 들어 30초 구간을 집계하면 그 집계를 기다리는 시간이 추가되므로 위 단계별 시간만으로 전체 지연을 계산하면 안 됩니다.
exactly-once는 같은 입력이 상태를 중복 갱신하지 않도록 처리하는 보장이고, at-least-once는 한 번 이상 처리하여 중복이 생길 수 있는 방식입니다. 어떤 모드가 허용되는지는 출력 소비자가 중복을 어떻게 해석하는지에 따라 판단합니다.
처리량 병목
원천이 아주 높은 속도로 데이터를 보내면 스트림 파티션 수를 늘리는 방법을 검토할 수 있습니다. HIGH THROUGHPUT 유형은 한 배치에 보내는 레코드를 늘려 처리량을 높이는 설정입니다.
Total Lag가 0보다 크면 처리량 부족 여부를 조사하고, Total Throughput도 함께 확인하여 높은 처리량 설정이 필요한지 판단합니다. 더 큰 배치를 사용하는 설정은 처리량을 높이는 대신 지연을 늘릴 수 있습니다. 수집 화면의 Very high처럼 순서 보장도 달라지는 선택지가 있으므로 동기화의 처리량 설정을 함께 확인합니다.
변환 자체가 CPU를 많이 사용하면 처리 클러스터의 크기와 병렬성을 조정하여 병목을 줄일 수 있습니다. 반대로 목적지가 레코드를 발생 속도만큼 받지 못하면 역압(backpressure)이 생겨 처리량은 줄고 지연은 증가합니다. 외부 목적지에 쓰는 경우에는 그 시스템의 수신 속도를 별도로 확인합니다.
네트워크 대역폭과 압축
대기량이 남고 처리량이 기대보다 낮거나 레코드 누락이 관찰된다면 네트워크 대역폭도 조사할 수 있습니다. 압축은 반복되는 문자열이 많은 고용량 스트림에서 효과가 좋습니다.
입력량이 작고 짧은 지연이 중요한 스트림에서는 압축 자체가 시간을 추가할 수 있습니다. 특히 반복성이 낮은 문자열처럼 압축 이점이 작으면 오히려 지연이 늘 수 있으므로 입력 특성에 맞춰 선택합니다.