워커 [Worker]

Vert.x에서 채택한 이벤트 루프[Event Loop, ELP] 모델이 스레드 풀 모델과 비교해 장점만 있는 것은 아니다.

ELP의 이벤트 대기열에 시간이 오래 걸리는 오래 걸리는 작업이 끼어 있는 경우엔, 그 이벤트가 하나 때문에 전체 작업의 처리속도가모두 느려지는 상황이 오게 된다.

이것이 왜 문제가 되는지 납득하기 쉽지 않을 것이기에, 현실세계에서 일어나는 다른 예를 가져와 비교를 해 보려 한다. 여러분의 머리 속에서 ELP를 철도 노선, ELP에서 처리되는 각 이벤트를 열차에 대입한 후, 아래 설명을 보아 달라.

만약 철도 노선이 단 1개만 깔려있는 단선 철로 위에 광역 급행 고속열차와, 저속 완행 도시철도 열차가 뒤섞여 운행중인 상황을 상상한다면 어떻게 될 것 같은가?이 상황에서 고속열차는 고속열차 기관차가 낼 수 있는 최고 속력으로 빠르게 운행할 수 있기는 커녕, 앞서가는 완행 도시철도 열차의 속도에 맞춰 천천히 운행을 해야만 할 것이다.

승객들은 열차가 자주 연착되거나, 더러 취소되는 열차의 운행 상태를 보며 분노해 열차를 이용하지 않을 것이다. 이런 상황은 극단적인 예시가 아닌 철도교통의 근본적 약점으로써, 지구상의 모든 철도 노선에서 벌어질 수 있는 상황이다. ELP 역시 특단의 대책을 마련하지 않는다면, 같은 상황이 닥칠 수밖에 없는 모델이다.

다행스럽게도, 현행 철도교통 체계에선 해결책이 존재한다!

그 해결책은 바로, 뒷 열차가 앞 열차를 추월해 갈 수 있도록 대피선로를 추가 가설해놓는 것이다. 한국의 철도노선 중에선 대표적으로 서울 도시철도 9호선의 노선을 예로 들 수 있다.앞서 가던 열차 (완행 저속 열차)가 대피선으로 잠깐 피신해 있는 동안, 뒤따라오던 급행 고속 열차가 추월해 가도록 배차시간표를 꾸민다면, 앞서 설명했던 상황을 해결할 수 있다.

현행 철도교통 체계 체계는 이러한 방법으로 노선 운영을 효율화하게 된다. 이러한 철도교통의 급행 운행 개념을 ELP 내에선 워커 [Worker] 로 녹여내었다.

위에서 설명한 대피선 개념이 여기선 스레드 풀[Thread pool]이고, Main ELP가 본 철도노선 개념으로 생각해 본다면 이해가 빠를 것이다.

Vert.x에서 연산량이 많은 작업이나, 블로킹이 빈번히 일어나는 (DB접속, 파일입출력, 통계 계산 및 일괄처리 등) 작업들을 Worker로 만들어 두고, 필요시 이벤트 버스[Event Bus]를 통해 작업을 의뢰한다.

Worker에서 작업 의뢰를 받아 작동이 진행되는 동안, 이벤트 대기열에 있는 타 작업들도 Worker의 작동 여부와는 상관 없이 동시에 진행이 가능하다.

추후에 Worker에서 작업을 완료하면, 이 사실 역시 이벤트 버스를 통해 통보되며 작업을 최종 종료시킴으로써, ELP모델의 약점을 극복할 수 있다.