[boost][asio] 디자인 패턴 - Proactor 패턴

번역 페이지

https://www.boost.org/doc/libs/1_72_0/doc/html/boost_asio/overview/core/async.html

 

Proactor 디자인 패턴 : 스레드가 필요 없는 동시성

 Boost.Asio 라이브러리는 동기와 비동기 작업을 모두 지원합니다.

 비동기식 지원은 Proactor 디자인 패턴을 기반으로 지원합니다.[POSA2]

 (POSA2 : Pattern-Oriented Software Architecture Volume 2이라는 디자인 패턴 책)

 동기식과 Reactor 디자인 패턴 접근 방식과 비교할 때 이 접근방식의 장점과 단점은 아래와 같습니다. 

Proactor와 Boost.Asio

 Proactor 디자인 패턴이 플랫폼 별 세부사항을 참조 없이 Boost.Asio 안에서 어떻게 구현되어 있는지 살펴 보겠습니다.

Proactor 디자인 패턴

Proactor 디자인 패턴( [POSA2]에서 채택)

•  Asynchronous Operation (비동기 작업)
  • 소켓에서 비동기 read 또는 write와 같은 비동기적으로 수행되는 작업을 의미합니다. 

• Asynchronous Operation Processor (비동기 작업 처리기)
  • 비동기 작업을 수행하고 작업이 완료 되었을 때 Completion event queue에 이벤트를 넣습니다.               
  • 높은 수준의 관점에서 reactive_socket_service와 같은 내부 서비스는 Asynchronous Operation Processor   입니다.
  • (reactive_socket_service는 boost::asio::detail::reactive_socket_service말합니다.)

• Completion Event Queue (완료 이벤트 큐)
  • Asynchronous event demultiplexer로부터 꺼내어 질 때 까지 완료 이벤트를 보관합니다. 

• Completion Handler (완료 핸들러)
  • 비동기 작업의 결과를 처리합니다. 이 함수 객체는 종종 boost::bind를 통해서 생성됩니다.

• Asynchronous Event Demultiplexer (비동기 이벤트 디멀티플렉서)
  • Completion Event Queue에 이벤트가 발생 할 때 까지 대기하고 호출자에게 완료 된 이벤트를 반환합니다.

• Proactor (먼저 수행한다는 뜻..)
  • 이벤트를 queue에서 꺼내는 Asynchronous Event Demultiplexer를 호출하고 이벤트와 관련된Completion Handler (즉 함수 객체를 호출합니다.)에 전달합니다.
  • 이러한 추상화는 io_context 클래스를 통해서 표시됩니다.

• Initiator (개시자)
  • 비동기 작업을 시작하는 어플리케이션 별 코드를 말합니다.
  • Initiator는 basic_stream_socket과 같은 높은 수준의 인터페이스를 통해서 Asynchronous operation processor와 통신합니다.
  • 이 인터페이스는 reactive_socket_service와 같은 서비스에 위임됩니다.

 

Reactor를 사용한 구현

 많은 플랫폼에서 Boost.Asio는 select, epoll, kqueue와 같은 Reactor의 조건에서 Proactor 디자인 패턴을 구현합니다. 

 이 구현 방식은 아래와 같은 Proactor 디자인 패턴을 따릅니다 :

• Asynchronous Operation Processor
  • Reactor는 select, epoll, kqueue를 사용해서 구현되었습니다.
  • Reactor가 작업의 수행이 준비 되었음을 보여 줄 때 Processor가 비동기 작업을 수행하고 Completion Event Queue에 연관된 Completion Handler를 넣습니다. 
• Completion Event Queue
  • Completion Handler의 링크드 리스트
• Asynchronous Event Demultiplexer
  • Completion Event Queue에서 completion handler를 사용 할 수 있을 때까지 Event 또는 condition variable를 통해서 대기하도록 구현되어 있습니다.

Windows Overlapped I/O를 사용한 구현 

 Window NT, 2000, XP에서부터 Boost.Asio는 Proactor디자인 패턴의 구현에 효과적으로 제공하는 Overlapped I/O의

 장점을 가집니다. 이 구현 방식은 다음과 같은 Proactor 디자인 패턴을 따릅니다.

• Asynchronous Operation Processor
  • 운영체제에 의해서 구현됩니다. 작업들은 AcceptEx와 같은 Overlapped와 같은 호출로 시작됩니다.  
• Completion Event Queue
  • 운영체제에 의해서 구현되며 I/O completion port와 연관됩니다. 
  • 하나의 I/O completion port당 하나의 io_context 인스턴스가 있습니다. 
• Asynchronous Event Demultiplexer
  • Boost Asio에 의해서 이벤트를 큐에서 꺼내오고 이벤트과 관련된 Completion handler들을 호출합니다.

이 점

• 이식성
  • 많은 운영체제에서 높은 성능의 네트워크 어플리케이션 개발을 위한 기본 비동기 I/O API (Window의 overlapped 같은)를 제공합니다.
  • 라이브러리는 기본 비동기 I/O의 조건으로 구현 될 수 있습니다.
  • 만약 기본 비동기 I/O의 지원이 불가능하다면 라이브러리는 POSIX select()와 같은 전형적인 Reactor패턴인 동기적 event demultiplexors를 사용해서 구현 될 수 있습니다.
• 동시성으로 부터 Decoupling threading
  • 오래 걸리는 작업을 응용 프로그램을 대신해서 비동기적으로 수행합니다. 그 결과 어플리케이션은 동시성을   증가시키기 위해서 많은 스레드를 생성하지 않아도 됩니다.
• 성능과 확장성
  • 하나의 connection당 하나의 스레드 구현 전략(동기식 접근방식에 필요한)은 cpu사이의 동기화 및 데이터 이동, context switching 증가 때문에 시스템의 성능을 저하 시킬 수 있습니다.
  • 비동기 작업을 사용하면 운영체제의 스레드 수를 최소화해서 context swiching 비용을 피할 수 있고 처리 할 이벤트를 가진 스레드만 활성화 합니다. 
• 어플리케이션 동기화 최소화
  • 비동기 작업의 completion handler들은 마치 단일 스레드 환경에 있는 것처럼 작성 될 수 있습니다.
  • 어플리케이션 로직은 동기화 문제에 대해서 거의 신경쓰지 않고 개발 될 수 있습니다.
• 합성 함수
  • 합성 함수는 특정 형식으로 메시지를 보내는 것과 같은 higher-level의 작업 방식을 제공하는 함수의 구현을 말합니다. 
  • 각 함수는 여러개의 lower-level의 read 또는 write 작업들을 호출하는 방식으로 구현됩니다. 
  • 예를 들면 고정길이 header와 body의 길이가 header에 지정된 가변길이 body로 구성된 프로토콜을 생각해봅니다. 
  • 가상의 read 메시지 작업은 2개의 lower-level의 read 작업을 사용해서 구현 할 수 있는데 첫번째는 header를   수신하고 body의 길이를 알게되면 두번째로 body를 수신합니다.
  • 비동기 모델에서 합성 함수는 비동기 작업들과 연결(chain) 될 수 있습니다. 즉 하나의 completion handler가   다음 작업의 시작점이 될 수 있습니다.
  • 연결(chain)안에서 첫번째 호출이 캡슐화 될 수 있습니다.
  • 그래서 호출자는 higher-level 작업인 비동기 작업의 chain 구현에 대해서 알 필요가 없습니다.
  • 이러한 방식안에서 새로운 작업을 복합적으로 구성하는 기능은 특정한 프로토콜을 지원하는 함수과 같은 네트워킹 라이브러리 위에서 추상적인 상위 단계의 개발을 단순화 합니다.

단 점 

• 프로그램 복잡성
  • 작업의 시작과 완료 사이에 시간과 공간적인 분리로 때문에 비동기 매커니즘을 사용해서 어플리케이션을 개발하는 것을 더 어렵게 만듭니다.
  • 어플리케이션의 반대로 된 제어 흐름 때문에 디버깅이 어려울 수 있습니다.
• 메모리 사용량
  • 버퍼 공간은 read또는 write 작업이 수행 되는 동안 할당 되어 있어야 하며 각각의 동시성 작업을 위해서 개별의 버퍼가 필요합니다.
  • Reactor 패턴은 반면에 소켓이 read나 write가 준비될 때까지 버퍼공간을 요구 하지 않습니다.