[배경]
데이터 수집 업무를 하다보면, 빠르게 데이터가 수집되어야 오류가 발생해도 빠르게 다시 수집하여 대응이 용이하다.
그래서 기존에 수집 시간을 단축하기 위한 고민 중 도움이 될만한 개념이 있어 '파이프라이닝'이라는 개념에 대해 연구를 하게됐다.
우선, 수집에 시간이 오래 걸리는 이유를 현재 구조에서 살펴보면 아래와 같을 것 같다.
모든 단계를 하나의 함수로 처리하며, 각 단계(리포트 요청, 확인, 다운로드, 저장)를 순차적으로 실행.
특정 단계(예: 확인 단계)에서 대기 시간이 발생하면, 쓰레드가 다른 작업을 처리하지 못하고 대기 상태에 있을 수 있음.
- 가령, 한 사람이 한 가지 일을 순서대로 처리하는 것.
- 한 사람이 요청서를 작성한 후, 다른 사람에게 확인받고, 그 후 데이터를 다운로드받고 파일로 저장하는 작업을 혼자서 순차적으로 처리.
- 문제는 확인 단계에서 대기 시간이 발생할 때, 다음 작업을 진행하지 못하고 그대로 멈춤.
[파이프라이닝이라는 개념을 도입하면?]
공장 조립 라인(Pipelining)을 비유로 들면, 역할을 나눠 처리하는 모습이다.
- 작업을 3단계로 나누고(요청 → 확인 → 다운로드 및 저장), 각 단계를 책임지는 사람들을 각 라인에 배치한다.
- 각 단계에서 작업이 끝나면 다음 단계로 데이터를 넘겨주고, 새로운 작업을 받으면서 동시에 작업이 계속 진행.
- 즉, 작업을 병렬적으로 처리하고, 대기 시간을 줄이며 효율을 향상.
정리
- 기존 문제점:
- 하나의 함수에서 모든 작업을 처리하다 보니, 각 단계에서 발생하는 대기 시간으로 인해 비효율적인 동작.
- CPU가 필요 이상으로 사용되고, 작업 속도가 느려짐.
- 개선 방법:
- 작업을 3단계로 나눔: 요청 → 상태 확인 → 다운로드/파일 저장.
- 각 단계를 독립적으로 처리하면? Queue(대기열)를 사용해 순차적으로 작업을 진행하면 어떤가.
- 작업들이 병렬로 진행되면서 대기 시간을 줄임.
생각할 점
ThreadContext 전환:
- 스레드가 작업을 처리하다 다른 작업으로 전환될 때 발생하는 오버헤드.
- 기존 방식은 이런 전환이 빈번하게 발생해 비효율적일 수 있는데 새로운 방식은 이 비용을 아낄 수 있을 듯 하다.
Queue를 활용한 Pipelining:
- 작업을 분리하고, 각 작업이 끝난 후 다음 작업으로 넘기는 방식.
- Queue는 각 작업의 순서를 유지하면서 효율적으로 데이터를 처리할 수 있도록 도움이 될 수 있다.