Queuing Chain - 큐를 통한 시스템간의 낮은 의존도 구성

ㅁ  풀어야 할 문제

여러 시스템에서 처리를 연계하여 순차적 처리(예를 들어, 이미지 처리의 경우에 이미지 업로드, 저장, 인코딩, 썸네일 작성 등의 순차 작업)를 할 때 시스템들이 밀접하게 결합되어 있다면, 성능 측면에서 병목 현상이 발생할 수 있다.

또, 장애 시 복구 작업이 복잡해 진다. 가능하면 시스템 간의 의존도를 낮게 하는 것이 성능이나 유지 및 보수 측면에서 바람직하다.

 

ㅁ  해결/패턴

시스템 간의 의존도를 낮추는 하나의 방법은 시스템들을 큐로 연결하여 작업 전달을 큐 안에 있는 메시지를 통해 송수신하는 것이다. 

이렇게 하면 비동기로 시스템 연계가 가능하다. 이 방법의 경우 메시지를 받고 처리하는 가상 서버 수를 늘려 병렬 처리를 할 수 있기 때문에 쉽게 병목 현상을 없앨 수 있다.

또, 가상 서버에 장애가 발생해도 미처리 메시지는 큐에 남아 가상 서버가 복구되면 처리를 재개한다.

이 패턴은 클라우드가 아니라도 이용이 가능하지만 큐 자체가 클라우드 서비스로 제공되며, 또한 가상 서버를 유연하게 구축할 수 있는 클라우드 특성으로 이전보다 훨씬 이용이 쉬워졌다.

 

ㅁ  구현

어떤 처리를 담당하는 EC2 인스턴스에서 다음 처리를 담당하는 EC2 인스턴스로의 처리 전달은 [SQS]를 통해한다. SQS는 AWS의 큐 서비스이다. 

EC2에서 처리는 작업(메시지) 수신  작업 처리  작업(메시지) 송신을 반복하게 된다.

작업의 성질에 따라서는 여러 대의 EC2에서 처리할 수도 있다.

 

ㅁ  장점

-       비동기 처리를 함으로써 바로 응답을 줄 수 있다.

-       시스템을 단순한 처리(EC2)의 의존도가 낮은 구성으로 만들 수 있다.

-       성능이나 서비스 요구조건에 대하여 작업 처리에 이용하는 EC2를 추가하고 삭제하는 것만으로 대응할 수 있다.

-       EC2에 장애가 발생해도 큐 서비스에 메시지(작업)가 남아 있고, EC2가 복구되면 바로 처리가 가능하여 장애에 강한 시스템이 된다.

 

ㅁ  주의점

-       SQS에서는 큐에서 메시지를 불러낼 때 메시지의 순서는 완전하게 맞지 않아 정확한 순서로 처리해야 하는 시스템에 대해서는 주의가 필요하다.

 

ㅁ  기타

-       Priority Queue 패턴을 같이 사용할 수 있다.

-       Amazon Simple Workflow를 이용하면 단순한 큐잉 뿐 아니라 복잡한 작업도 하고 비교적 쉽게 구현할 수 있다.

-       Job Observer 패턴을 참조한다.