<aside>
💡 Vector의 Buffer Model을 이해하기 위해선 Backpressure에 대한 이해가 선행되어야 합니다.
</aside>
Backpressure
- Backpressure란 시스템이 받아들일 수 있는 것보다 더 많은 요청을 특정 컴포넌트에서 받을 때 생성하는 신호입니다.
- Vector의 경우 파이프라인의 다운스트림(downstream) 부분, sink가 처리할 수 있는 속도보다 데이터가 더 빠르게 들어올 때 Backpressure를 생성합니다. 즉, 데이터 소스 또는 파이프라인의 다른 부분에서 생성되는 데이터의 양이 sink가 처리할 수 있는 용량을 초과할 때 발생합니다.
- 사용자는 sink의 Backpressure를 통해서 다른 컴포넌트의 상태를 확인할 수 있습니다.
- Backpressure가 발생하는 이유에는 여러 가지가 있습니다.
- 일정량 이상의 데이터 처리가 지연될 경우
- 데이터를 원격 위치로 전송하는 경우 네트워크 지연으로 인해 데이터 전송 속도가 저하될 경우
- 다운스트림 시스템이 다른 작업으로 인해 과부하 상태에 있을 경우
- Backpressure가 Source로 신호를 전달하면 Source에서는 이벤트(데이터)의 전송량을 조절합니다. 이와 같은 프로세스는 시스템의 안정성을 높이는데 기여하지만 한 가지 치명적 결함이 존재합니다.
- 만약 Sink에서 이벤트 처리 성능이 저하되어 Backpressure를 즉각적으로 Source에 전달할 경우 전체 시스템 성능의 지연을 초래할 수 있습니다. 또한, 즉각적인 Backpressure 전송은 Source에서 외부 데이터 Input 을 받지 못하는 상황을 초래해 Vector 파이프라인 외부의 시스템에도 영향을 끼칠 수 있습니다.
이 때문에 Vector에서는 이 같은 결함을 해결하기 위해 각 컴포넌트에 Buffer를 둡니다.
Buffer
- Buffer를 사용하는 근본적인 목적은 두 컴포넌트(노드) 간의 통신을 원활이 함에 있습니다. 각 컴포넌트가 수용할 수 있는 최대치에서 조금 더 데이터를 수신할 수 있는 여유 공간을 두어 전체 데이터 처리 파이프라인의 효율성과 안정성을 높입니다.
- Vector의 경우 Sink의 Buffer size가 다른 컴포넌트 보다 조금 더 크게 할당되어 있습니다.
- 성능이 우선되는 경우
in-memory buffer를 사용하고, 데이터의 영속성이 우선시 되는 경우 disk buffer를 사용할 수 있습니다.
in-memory buffer
- 앞서 언급한 것처럼 memory 기반의 버퍼는 빠른 데이터 처리, 빠른 접근이 중요할 때 사용합니다. 하지만 빠른 성능에도 불구하고 두 가지의 결함이 존재합니다.
- 비율 기반의 메모리 소비
- Vector의 경우 Buffer를 설정할 때 event의 바이트 사이즈가 아닌 event 수를 사용합니다. 그래서 만일 전 단계의 컴포넌트에서 event의 크기가 커질 경우 buffer에서 점유하는 메모리 사용량이 증가합니다. 이는 파이프라인의 성능에 영향을 미칠 수 있고, 심각할 경우 파이프라인 프로세스가 종료될 수 있습니다.
- 데이터 영속성 부족
- memory에 데이터를 저장하는 시스템이 갖는 공통적인 결함은 시스템이 다운되거나 혹은 재시작 될 경우 데이터가 유실될 수 있다는 점입니다. Pull-based 기반의 Souce(SQS, Kafka) 등은 이벤트 재처리를 통해 문제를 해결 할 수 있지만 이 부분 또한 각 시스템 특성에 따라 다를 수 있습니다.
disk buffer
- Disk Buffer의 경우 데이터 영속성이 떨어지는 단점을 보완할 수 있는 대안으로 사용할 수 있습니다.
- in-memory buffer와 다르게 전체 시스템의 장애 혹은 재기동에도 데이터 유실을 방지할 수 있는 이점이 있습니다. (단, 처리 성능은 in-memory에 비해 떨어집니다.) 이 때문에 Disk Buffer의 경우 데이터 유실이 허용되지 않는 환경에서 사용하기에 적합한 buffer 타입입니다.