[Programming] Backpressure

medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7

Backpressure explained — the flow of data through software

 

이해한 바를 정리

소프트웨어의 목적은 인풋 데이터를 원하는 아웃풋 데이터로 변환시키는 것이다.

Backpressure는 인풋 데이터를 아웃풋 데이터로 변환시키는 과정에 모종의 이유로 저항이 생기는 때를 말한다.

 

대개 저항은 계산 속도인데 - 인풋 데이터가 들어오는 속도의 빠르기만큼 아웃풋을 계산하는데 문제가 있는 것이다. 그 외에 사용자에게 액션을 받기 위해 소프트웨어가 기다리는 것도 backpressure라고도 할 수 있다.

 

예들

I Love Lucy 영상의 예

컨베이어 밸트를 통해 인풋 아이템이 계속 해서 들어오는데 인풋 아이템을 아웃풋 아이템으로 처리하는 과정에서 backpressure가 발생했다. 이 backpressure에 대응하고자 영상의 인물들이 한 일은 나중에 처리하기 위해 인풋 아이템을 다른 곳으로 빼놓던가(buffering), 인풋 아이템들을 숨기거나 없애버렸다(dropping).

 

파일 읽기과 쓰기

파일 쓰기 속도는 파일 읽기 속도보다 느리다.

메모리의 파일을 읽으면서 동시에 읽은 것을 디스크에 쓴다고 하자.

읽는 속도 : 150 MB/초

쓰는 속도 : 100 MB/초

동시에 파일을 읽고 쓰는데 매초 (150 MB-100 MB = 50 MB)50MB의 버퍼가 필요하다. 증가하는 결손/손실/적자(deficit)이다. 파일 읽기가 끝날 때까지 파일 읽기는 끝나지도 못하고 결손(아직 읽지 못한 데이터)도 해결하지 못한다.

 

6GB 파일을 대상으로 읽고 쓴다고 하면, 쓰기를 다 끝내기 위해 2GB의 버퍼가 필요하다.

 

6 GB / 150 MB = 40초

150 MB - 100 MB = 50 MB의 결손

50 MB x 40 = 2 GB

 

이건 메모리 낭비다.

 

해결책 : 쓰는 속도로 파일을 읽으면 된다.  

 

서버 통신

서버간 통신에서 자주 발생.

한 서버가 다른 서버로 요청하는 속도가, 이 요청을 처리하는 속도보다 빠를 때 발생한다.

 

A 서버 -> B 서버 -> C 서버

 

B서버가 A서버로 부터 요청을 받는 속도 > B서버가 A서버의 요청을 처리(해 C서버로 요청)하는 속도

B서버에서 정체가 생긴다. 

B서버에서 버퍼를 쓰면(Buffering) deficit(결손)이 계속 증가할 테고, 다른 요청들에 대한 작업들도 진행하다보면 메모리 부족으로 B서버가 뻣어버릴 것이다. 요청을 잃어버리는 것(Dropping)을 허용하기는 힘들다.

 

이상적인 선택은 서버 B가 서버 A의 요청 속도를 통제하는 것. 

 

예를 들어, 서버 A, 서버 B, 서버 C가 동일한 downstream 서비스 Z에 요청을 보낸다. 서버 중 하나(A)의 요청 속도가 빠를 때, 서비스 Z는 A에게 속도를 늦출 것을 말해서(producer를 통제) A가 요청을 버퍼링하고 결국엔 메모리를 쓰도록 한다. 서버 B,C의 서비스는 동일하게 유지한다. 서비스 하나가 잘못되도 다른 서비스들까지 접근 불가능하게 하지 않기 때문이다. 이 경우 기능 정지가 불가피하지만, 이 범위가 제한되고 연속적인 서비스 거부를 예방할 수 있다. 이것은 실제 producer(유저)를 통제할 수 없기에 버퍼링하는 producer를 통제하는 경우이다. 누군가(어떤 서버)는 버퍼링을 해야하고, 이 '누구'는  중요한 부분이다.

 

UI 렌더링

해야하는 만큼 빠르게 렌더링 하지 못하는 경우에 backpressure가 발생한다. 예를 들어, 엄청 큰 리스트를 렌더링해야 한다던지, 빠른 키보드 이벤트들을 디바운싱한다던지, 매 초 2만개의 이벤트를 emit하는 WebSocket의 아웃풋을 디스플레이에 노출시키는 등의 더 복잡한 상황들이 있다.

 

Backpressure 전략

-producer를 통제(Control)(consumer에 의해 속도를 늦추거나 높이거나)

-Buffer(들어오는 데이터의 급등을 일시적으로 모은다.)

-Drop(들어오는 데이터들의 일부를 추출한다.)

-backpressure를 무시한다. backpressure가 치명적인 이슈를 만들지 않는다면 말이다. 

 

-pruducer를 controlling

최고의 방법. producer를 통제하는게 항상 가능하지는 않다. 

-buffering

무한한 버퍼링은 위험하다. 무한한 버퍼는 메모리 크래시의 흔한 원인이다.

-dropping

마지막 수단. 종종 버퍼링 이용과 결합된다. 예를 들어 초당 10% 데이터와 같이, 대개 시간을 기반으로하는 것이 흔하다. 

 

 

UX에 맞게 전략을 선택하면 된다.