[Concurrency] 채널과 Pipeline Pattern

Pipeline Pattern은 채널을 통신 수단으로 사용해서, 일종의 produce - consume 구조를 자아내는 자잘한 구현 패턴 중 하나다.

예를 들어, Item이 여러개 있고, 각 Item에는 처리해야 하는 프로세스가 3가지 있다고 해보겠다.

이 비동기 함수들은 실제 외부 서비스에 API를 호출해서 처리를 하는 것이라고 가정한다.

그러면 보통은 코드를 이런 식으로 간단하게 구성하는 경우가 대부분이다.

이 접근 방식 자체에 뭔가 대단한 결점이 있거나 한 것은 아니다.
만약 순차적으로 처리하는 것이 마음에 들지 않는다면, item 루프의 각 반복을 스레드로 띄울 수도 있을 것이다.

하지만 채널을 사용해서 풀어볼 수도 있다.
이 경우에는 items가 이미 쭉 정해져있으나, 데이터 소스가 지속적으로 유입될 수 있는 상황이라면 채널을 통한 지속적인 파이프라인 구조를 구성하는 것이 유리할 수 있다.

이런 식으로, 인자를 직접 전달받는 것이 아니라 채널을 통해 전달받고, 리턴값도 바로 리턴하는 것이 아니라 채널을 통해 리턴하는 것이다.

호출할 때도 다음과 같이 체이닝 형태로, 채널을 받고 채널을 리턴하는 식으로 할 수 있다.

각 파이프라인별로, 채널 consumer 함수들이 되는대로 적당히 처리가 될 것이다.

그럼 이 구현 패턴이 무슨 의미가 있을까?

내가 느끼기에 가장 강력한 부분 중 하나는, 채널을 통해 Backpressure를 관리하기 쉽다는 것이다.
채널에 버퍼 사이즈를 걸면, 버퍼가 꽉 찰 경우에는 더 이상 send를 받지 않고 대기하게 된다. 그럼 특정 채널 pipe 지점에 병목이 존재할 경우를 조금 더 유연하게 처리할 수 있다.

최초 데이터 source를 채널을 통해 계속 구겨넣을 수 있다는 것도 특징이다.

근데 그 이외에는 큰 장점까지는 별로 없는 것 같다.
가독성도 기본적인 구현 형식보다 떨어지고, 코드가 장황해지는 경향이 있다.
사실 내가 볼때 async-await이나 async stream 패턴이 지원되는 언어에서는 크게 필요하진 않다.

await flow을 구현하기 번거로운 Go 같은 언어에서 좀 쓸만한 가치가 있는 것 같다.