Reactive Programming - 배압 (Backpressure)

1. 배압의 정의

위키피디아에서 배압은 파이프라인에서 순방향으로 흐르는 유체의 흐름을 반대되는 역방향성을 가진 힘이라고 뜻하고있다.

pipe1의 경우에는 유체의 흐름에 방해되는 요소가 없어 p1 -> p2로 유체가 잘 흐를 것이다.
pipe2의 경우에는 유체의 흐름을 방해하는 요소가 몇가지가 존재하여 p1 -> p2까지 유체는 배압으로인하여 p2까지 도달하는데 시간이 좀 더 걸릴 것이다.

이 유체를 지금부터 프로그램의 데이터라고 생각을 해보자.

2. 리액티브 프로그래밍에서 배압이 필요하게 된 이유

데이터베이스에서 조회된 어마어마한 데이터 리소스가 지금부터 들어올 것이다.
이 데이터를 Publisher와 Subscriber는 어떻게 감당을 할 것인가?

물론 자원에대한 처리 능력이 무한하다면 문제가 없지만 현실적으로 그렇지않다.
그러면 처리 능력에 맞게끔 잘 조절해줄만한 부산물이 필요하게 될 것이다.

좀 더 쉽게 설명하자면 1V ~ 3V, 0.5A이하 환경에서 동작하는 전구가 존재하고
10V, 1A 규격의 건전지를 전선과 함께 그대로 연결하게 되면 전구 입장에서 감당하지 못하여 과부하가 생긴다.
전압을 줄이기위해 저항이라는 부속품을 달고, 전류를 나누기위해 병렬로 연결하는 방법등을 통해 전구에 불을 키게 만드는 원리와 비슷하다.
(하지만 전지의 경우에는 내보내는 전압과 전류(데이터)를 손실시킨다는 의미로도 해석할 수도 있어 예시가 적절하지 않을 수도있다.
전압과 전류의 손실이라 생각하지않고 전구가 동작하기위한 저항과 근본적으로 전구가 동작한다는 것에만 의미를 담아서 예시를 들었다.)

프로그래밍도 마찬가지로 리소스 데이터의 유입 속도를 조절해줄 필요가 있다.
속도 조절에 관한 문제를 어떻게 하면 해소할 수 있을까를 알아보기 전 2가지 케이스를 살펴보자.

3. 느린 Publisher(Producer)와 빠른 Subscriber(Consumer)

만일 Publisher가 리소스의 발행속도가 느리고, Subscriber가 빠른 속도로 리소스를 처리를한다 가정을하자.
이럴때는 Publisher의 수를 늘려서 성능을 Subscriber에 맞출 수 있다 생각할 수 있지만, Push모델의 경우 런타임 환경에서 Publisher를 동적으로 늘여 시스템의 데이터 처리량을 늘이는 일은 현실적으로 불가능하다.

4. 빠른 Publisher(Producer)와 느린 Subscriber(Consumer)

반대의 경우에는 데이터 발행 속도는 빠르지만 이를 처리하는 Subscriber쪽에서 느려 과부하가 걸려 결과적으로 컴포넌트에 오류를 일으킬 것이다.
데이터의 유입량을 Subscriber에 맞추기 위해서 큐 자료구조를 이용하면 해소 할 수 있다.

하지만 큐 또한 인메모리 영역을 차지하기 때문에 실질적으로 무한한 메모리를 가진 큐는 존재할 수 없다. 즉 메모리 공간이 한정된 큐를 통해서 데이터의 속도를 조절해야한다.

그러면 크기가 한정된 큐를 사용하여 일시적으로 데이터를 보존하여 Subscriber 속도에 맞추어 꺼내 사용하면 될 것이다.
하지만 이 또한 완벽한 솔루션은 아닌게, 크기가 한정되면 오버플로현상이 일어나 데이터의 유실이 발생될 것이다.

여기서 나는 데이터의 유실을 막기 위해 제한된 크기를 넘게 되면 데이터를 큐에 넣지않고 로깅을 하여 나중에 사용자가 직접 수동으로 처리하여 최대한 모든 데이터를 처리 할 수 있도록하는 것이 어떨까 생각한다.

5. 정리를 하자면

리액티브 선언문에서도 시스템 부하에 적절하게 해결 할 수 있는 대응법이 필요하다 중요하게 강조하였고, 이를 “배압”이라는 매커니즘을 통해 해소 할 수있다.
배압은 마치 전자부품의 동작을 시키기위한 규격을 맞추어주는 조건이며 또다른 부속품이라 생각한다.
프로그래밍적으로 풀어보자면 빠른 Publisher와 느린 Subscriber의 조건일 경우에는 큐를 이용하여 Subscriber가 자신의 데이터 처리 속도에 맞추어 처리하면 문제를 어느정도 해소 할 수 있을 것이다.