다양한 분산 소프트웨어 컴포넌트들의 정보 교환을 위해 비동기, 다대다 메시지 교환이 가능한 브로커 구조가 보편적으로 사용되고 있다. 특별히 많은 사용자 및 메시지를 지원하기 위해 높은 확장성의 분산 메시지 브로커가 제안되었다. 브로커의 가용성 및 장애 극복 능력을 향상시키기 위해 메시지 레플리카를 사용하여 액티브-스탠바이 혹은 액티브-액티브 구조를 사용하게 된다. 그러나, 액티브-스탠바이의 경우 낮은 가용성의 문제, 그리고 액티브-액티브의 경우 동기화오버헤드가 전체 성능을 낮추는 문제를 가진다. 본 논문에서는 장애 상황의 극복이 가능하면서도 분산 메시지 브로커의 가용성을 향상시키기 위해 메시지 레플리카를 액티브-액티브 구조로 구성하여 분산 브로커의 요청 부하를 분산시키는 기법을 제안하였다. 스탠바이 레플리카들이 액티브 레플리카로부터 요청을 전달받아 나누어 처리함으로써 브로커를 구성하는 노드 수의 증가 없이 요청 부하를 분산시킬 수 있었다. 이때 메시지 동기화 과정은 분산 코디네이터를 이용, 분산 락을 구현함으로써 모든 액티브 레플리카들이 한 때에 동기화를 진행하도록 하였고 각 액티브 레플리가 동기화를 할 때보다 추가적인 오버헤드를 적게 하였다. 본 제안의 성능을 평가하기 위해 제안 기법과 기존의 액티브-스탠바이 기법을 기반으로 브로커 프로토타입을 구현하고 메시지의 생산, 소비 및 전체 생산-소비 구간 처리 성능을 측정 비교하였고, 분산 락으로 인한 오버헤드 수식을 제시하였다. 실험 결과에서 본 제안 기법이 더 높은 확장성과 메시지 처리성능을 보임을 확인하였다.
다양한 분산 소프트웨어 컴포넌트들의 정보 교환을 위해 비동기, 다대다 메시지 교환이 가능한 브로커 구조가 보편적으로 사용되고 있다. 특별히 많은 사용자 및 메시지를 지원하기 위해 높은 확장성의 분산 메시지 브로커가 제안되었다. 브로커의 가용성 및 장애 극복 능력을 향상시키기 위해 메시지 레플리카를 사용하여 액티브-스탠바이 혹은 액티브-액티브 구조를 사용하게 된다. 그러나, 액티브-스탠바이의 경우 낮은 가용성의 문제, 그리고 액티브-액티브의 경우 동기화 오버헤드가 전체 성능을 낮추는 문제를 가진다. 본 논문에서는 장애 상황의 극복이 가능하면서도 분산 메시지 브로커의 가용성을 향상시키기 위해 메시지 레플리카를 액티브-액티브 구조로 구성하여 분산 브로커의 요청 부하를 분산시키는 기법을 제안하였다. 스탠바이 레플리카들이 액티브 레플리카로부터 요청을 전달받아 나누어 처리함으로써 브로커를 구성하는 노드 수의 증가 없이 요청 부하를 분산시킬 수 있었다. 이때 메시지 동기화 과정은 분산 코디네이터를 이용, 분산 락을 구현함으로써 모든 액티브 레플리카들이 한 때에 동기화를 진행하도록 하였고 각 액티브 레플리가 동기화를 할 때보다 추가적인 오버헤드를 적게 하였다. 본 제안의 성능을 평가하기 위해 제안 기법과 기존의 액티브-스탠바이 기법을 기반으로 브로커 프로토타입을 구현하고 메시지의 생산, 소비 및 전체 생산-소비 구간 처리 성능을 측정 비교하였고, 분산 락으로 인한 오버헤드 수식을 제시하였다. 실험 결과에서 본 제안 기법이 더 높은 확장성과 메시지 처리성능을 보임을 확인하였다.
A loosely coupled message broker system is a popular method for integrating distributed software components. Especially, a distributed broker structure with multiple brokers with active-standby or active-active message replicas are used to enhance availability as well as message processing performan...
A loosely coupled message broker system is a popular method for integrating distributed software components. Especially, a distributed broker structure with multiple brokers with active-standby or active-active message replicas are used to enhance availability as well as message processing performance. However, there are problems in both active-standby and active-active replica structure. The active-standby has relatively low processing performance and The active-active structure requires a high synchronization overhead. In this paper, we propose an active-active structure of replicas to increase the availability of the brokers without compromising its high fault-tolerancy. In the proposed structure, standby replicas process the requests of the active replicas so that load balancing is achieved without additional brokers, while the distributed coordinators are used for the synchronization process to decrease the overhead. We formulated the overhead incurred when synchronizing messages among replicas, and the formulation was used to support the experiment results. From the experiment, we observed that replicas of the active-active structure show better performance than the active stand-by structure with increasing number of users.
A loosely coupled message broker system is a popular method for integrating distributed software components. Especially, a distributed broker structure with multiple brokers with active-standby or active-active message replicas are used to enhance availability as well as message processing performance. However, there are problems in both active-standby and active-active replica structure. The active-standby has relatively low processing performance and The active-active structure requires a high synchronization overhead. In this paper, we propose an active-active structure of replicas to increase the availability of the brokers without compromising its high fault-tolerancy. In the proposed structure, standby replicas process the requests of the active replicas so that load balancing is achieved without additional brokers, while the distributed coordinators are used for the synchronization process to decrease the overhead. We formulated the overhead incurred when synchronizing messages among replicas, and the formulation was used to support the experiment results. From the experiment, we observed that replicas of the active-active structure show better performance than the active stand-by structure with increasing number of users.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
(2) Broker3은 syncEnd의 값을 자신이 가진 마지막 메시지 오프셋 값인 103으로 업데이트함으로써 분산 락이 생성된다. lock 노드에 자식 노드가 생성되면 오리지널 레플리카는 해당 자식 노드 값을 통해 어떤 레플리카가 살아있는지 확인한다. ‘lock’노드에 자식 노드가 생기고 ‘syncEnd’노드 값이 변경되면 락이 걸리며, 등록한 watcher를 통해 모든 레플리카에 분산 락이 생성되었음이 전달된다.
본 논문에서는 높은 장애 극복 능력을 가지지만 제한적으로만 확장되어 높은 처리성능을 달성하기 어려운 액티브-스탠바이 구조의 제한점을 극복하기 위해 변형 액티브-액티브 구조를 제안하여 레플리카를 액티브로 활용하는 기법을 제안한다. 본 제안에서는 액티브-액티브 구조를 달성하기 위해 필요한 복잡한 동기화 과정을 분산 코디네이터에 의한 분산 락을 구현으로 단순화하였으며, 높은 처리 성능의 달성을 위해서 original 액티브 노드에 로드 밸런서 기능을 추가하여 다수의 레플리카-액티브 노드에 사용자 요청을 분산하도록 설계하였다.
그러나, 액티브-액티브 구조가 액티브-스탠바이 구조 대비 가지는 우수한 장애 극복 성능 및 요청 처리 능력에도 불구하고 액티브-액티브를 달성하기 위해 필요한 동기화 오버헤드 및 동기화 과정의 복잡도로 인해 일부 시스템에서만 제한적인 목적으로 사용되어 왔다. 본 논문에서는 분산 메시지 브로커에 액티브-액티브 구조의 레플리카를 적용하는 기법을 제안한다. 제안하는 기법은 브로커를 구성하는 노드 수의 증가 없이 부하를 분산시키는 것을 목표로 하며, 분산 코디네이터를 이용한 분산 락을 통해 각 액티브 레플리카들의 메시지 동기를 맞추었다.
본 실험에서는 레플리카의 동기화의 시기를 일치시켜서 모든 레플리카들이 같은 주기에서 동기화를 수행하도록 하였다. 이 동기화 주기 자유도 여부는 3장에서 설명한 바와 같이 성능에는 큰 차이가 없지만, 액티브-스탠바이와 액티브-액티브를 동일한 환경에서 비교 평가하는 실험을 진행하기 위해서이다.
본 연구에서는 장애 상황의 극복이 가능하면서도 분산 메시지 브로커의 가용성을 향상시키기 위해 메시지 레플리카를 액티브-액티브 구조로 구성하여 분산 브로커의 요청 부하를 분산시키는 기법을 제안하였다. 스탠바이 레플리카들이 액티브 레플리카로부터 요청을 전달받아 나누어 처리함으로써 브로커를 구성하는 노드 수의 증가 없이 요청 부하를 분산시킬 수 있었다.
본 장에서는 액티브-액티브 구조를 효과적으로 적용하여 장애 극복 능력을 유지하면서도 높은 가용성을 얻을 수 있는 제안 기법의 효과를 평가하기 위해 액티브-스탠바이 구조를 활용하고 있는 대표적인 분산 메시지 브로커인 아파치 카프카에 대한 프로토타입 시스템과 제안 기법의 핵심 기능을 갖는 시스템을 구현하였으며, 이를 통해 분산 브로커에 사용자의 요청 부하가 발생했을 때 제안 기법의 효과를 알아보고자 하였다. 성능 평가에서는 메시지 처리 성능, 즉 각 사용자의 요청이 브로커에게 전달되어 처리된 후 응답을 받기까지의 처리 시간을 측정하여 비교하였으며, 처리 시간은 각각 메시지의 생산, 메시지의 소비 및 메시지의 생산과 소비의 세 실험 결과에 대해 각각 비교하였다.
본 절에서는 오리지널 레플리카가 사용자의 요청을 수용하고, 요청이 다른 세컨더리 레플리카들에 분산되어 처리되는 과정에 관해서 설명한다. 오리지널 레플리카를 통해 라운드 로빈하게 분산되는 요청은 오리지널 레플리카 또는 세컨더리 레플리카가 처리하게 된다.
본 실험에서는 레플리카의 동기화의 시기를 일치시켜서 모든 레플리카들이 같은 주기에서 동기화를 수행하도록 하였다. 이 동기화 주기 자유도 여부는 3장에서 설명한 바와 같이 성능에는 큰 차이가 없지만, 액티브-스탠바이와 액티브-액티브를 동일한 환경에서 비교 평가하는 실험을 진행하기 위해서이다.
제안 방법
3) 생산자가 만든 메시지가 브로커를 거쳐 소비자에게 전달되기까지 걸리는 시간으로 나누어볼 수 있으며, 세 가지 경우에 대해 각각 실험을 진행하였다.
lock 노드에는 다음에 동기화를 원하는 레플리카가 자신의 브로커 아이디로 자식 노드를 만든다. lock 노드에 브로커 아이디를 가진 자식 노드를 생성하고syncEnd 노드 값을 업데이트함으로써 분산 락을 구현하고, 분산 락이 걸렸을 때 모든 레플리카가 동기화 과정을 실행한다. 동기화 과정은 락이 걸려있는 동안 중복되게 진행되지 않도록 한다.
실패 복구 과정은 액티브 노드를 사용할 수 없을 때 스탠바이 노드가 액티브 노드로 변환할 때 진행되는 과정으로, 제안된 차이 복구 방법은 인풋이나 아웃풋에 대한 보호가 없어 노드 실패를 복구하는 과정에서 데이터 손실이 일어날 수 있다. 그렇지만 이 연구에서는 분산 스트리밍 프로세싱 엔진이 사용되는 환경에서 노드 실패가 발생했을 때 예전 데이터가 약간 손실되더라도 복구의 보장성보다는 복구되는 시간과 런타임 오버헤드가 적은 것을 중요하게 생각하여, 복구 시간과 런타임 오버헤드가 비교적 큰 정밀 회복(precise recovery)이나 롤백 복구(rollback recovery)보다 차이 복구 방법을 사용하였다.
또한, 레플리카들의 동기화를 위해 필요한 메타데이터의 양을 최소화하기 위해 오리지널 레플리카에서 사용자의 모든 요청을 우선 수용한 후 세컨더리 레플리카에는 생산 요청과 소비 요청만 분산하였다. 따라서 제안 기법에서는 사용자의 생산 요청과 패치 요청만 세컨더리 레플리카에 분산되도록 하고 메타데이터 요청과 같은 다른 요청들은 오리지널 레플리카에서 처리하도록 하였다.
성능 평가에서는 메시지 처리 성능, 즉 각 사용자의 요청이 브로커에게 전달되어 처리된 후 응답을 받기까지의 처리 시간을 측정하여 비교하였으며, 처리 시간은 각각 메시지의 생산, 메시지의 소비 및 메시지의 생산과 소비의 세 실험 결과에 대해 각각 비교하였다. 또한 분산 락에 의한 오버헤드의 경우는 처리시간을 모델링하여 수식으로 제시하였다.
그러므로 오리지널 레플리카가 다른 세컨더리 레플리카에 요청을 분산할 때에는 모듈러 연산이나 다른 잘 알려진 해시 알고리즘을 이용하여 로드 밸런싱을 하는 것 보다 모든 레플리카에 공평하게 요청을 전달하기 위해서 라운드 로빈 방법을 사용했다. 또한, 레플리카들의 동기화를 위해 필요한 메타데이터의 양을 최소화하기 위해 오리지널 레플리카에서 사용자의 모든 요청을 우선 수용한 후 세컨더리 레플리카에는 생산 요청과 소비 요청만 분산하였다. 따라서 제안 기법에서는 사용자의 생산 요청과 패치 요청만 세컨더리 레플리카에 분산되도록 하고 메타데이터 요청과 같은 다른 요청들은 오리지널 레플리카에서 처리하도록 하였다.
먼저 오리지널 레플리카는 시작할 때 코디네이터에 ‘syncStart’와 ‘syncEnd’, ‘lock’노드가 있는지 확인하고, 해당 노드들이 없다면 각각을 생성한다.
본 절에서는 같은 양의 메시지의 동기를 맞출 때 액티브스탠바이 구조의 레플리카에서의 동기화 과정과 제안 기법에서 사용하는 액티브-액티브 구조의 레플리카에서의 동기화 과정에서 걸리는 오버헤드를 수식을 통해 비교하였다.
본 절에서는 제안 기법을 적용한 분산 브로커의 가용성 향상 효과를 알아보기 위해 제안 기법을 적용한 경우와 그렇지 않은 경우의 분산 브로커의 메시지 처리 시간을 측정하여 비교하였다. 여기서 메시지 처리 시간은 사용자가 요청하는 메시지가 처리되기까지 걸리는 시간으로,1) 생산자가 보낸 메시지가 브로커에 저장된 후 브로커가 생산자에게 응답하기까지 걸린 시간,2) 소비자의 요청을 보내면 브로커가 요청에서 가리키는 메시지를 디스크에서 읽은 후 응답으로 메시지를 돌려주기까지 걸리는 시간,3) 생산자가 만든 메시지가 브로커를 거쳐 소비자에게 전달되기까지 걸리는 시간으로 나누어볼 수 있으며, 세 가지 경우에 대해 각각 실험을 진행하였다.
본 논문에서는 높은 장애 극복 능력을 가지지만 제한적으로만 확장되어 높은 처리성능을 달성하기 어려운 액티브-스탠바이 구조의 제한점을 극복하기 위해 변형 액티브-액티브 구조를 제안하여 레플리카를 액티브로 활용하는 기법을 제안한다. 본 제안에서는 액티브-액티브 구조를 달성하기 위해 필요한 복잡한 동기화 과정을 분산 코디네이터에 의한 분산 락을 구현으로 단순화하였으며, 높은 처리 성능의 달성을 위해서 original 액티브 노드에 로드 밸런서 기능을 추가하여 다수의 레플리카-액티브 노드에 사용자 요청을 분산하도록 설계하였다. 다만, 동기화되지 않은 메시지를 가진 액티브-레플리카가 비가용 상태가 되었을 때 해당 레플리카가 다시 가용상태가 되기 전까지는 복제되지 않은 메시지를 이용할 수 없는 문제는 향후 추가 연구에서 해결하여야 한다.
Table 2는 실험에서 사용하는 데이터 구성, 즉 사용자가 생산하고 소비하는 메시지에 대한 상세 정보이다. 생산자가 만드는 메시지는 Project Gutenberg [14]에서 제공하는 문서 데이터의 일부를 사용하였으며, 소비자는 요청한 메시지를 받아서 해당 메시지에 관한 글자 수 카운트 예제를 진행하였다(Table 3 참조).
본 장에서는 액티브-액티브 구조를 효과적으로 적용하여 장애 극복 능력을 유지하면서도 높은 가용성을 얻을 수 있는 제안 기법의 효과를 평가하기 위해 액티브-스탠바이 구조를 활용하고 있는 대표적인 분산 메시지 브로커인 아파치 카프카에 대한 프로토타입 시스템과 제안 기법의 핵심 기능을 갖는 시스템을 구현하였으며, 이를 통해 분산 브로커에 사용자의 요청 부하가 발생했을 때 제안 기법의 효과를 알아보고자 하였다. 성능 평가에서는 메시지 처리 성능, 즉 각 사용자의 요청이 브로커에게 전달되어 처리된 후 응답을 받기까지의 처리 시간을 측정하여 비교하였으며, 처리 시간은 각각 메시지의 생산, 메시지의 소비 및 메시지의 생산과 소비의 세 실험 결과에 대해 각각 비교하였다. 또한 분산 락에 의한 오버헤드의 경우는 처리시간을 모델링하여 수식으로 제시하였다.
액티브-스탠바이 구조를 기반으로 액티브-액티브를 달성하기 위해서 각 레플리카의 역할을 정의하고 필요한 요소들을 분석한다. 기존 사용자 액티브-스탠바이 구조의 액티브 레플리카를 오리지널 레플리카로 정의하고, 기존 스탠바이 레플리카는 오리지널로부터 사용자 요청을 전달받아 처리하는 세컨더리 레플리카로 정의한다.
스탠바이 레플리카들이 액티브 레플리카로부터 요청을 전달받아 나누어 처리함으로써 브로커를 구성하는 노드 수의 증가 없이 요청 부하를 분산시킬 수 있었다. 이때 메시지 동기화 과정은 분산 코디네이터를 이용, 분산 락을 구현함으로써 모든 액티브 레플리카들이 한 때에 동기화를 진행하도록 하였고 각 액티브 레플리가 동기화를 할 때보다 추가적인 오버헤드를 적게 하였다.
이를 위해서 기존에 액티브 레플리카(즉, 오리지널 레플리카)의 상태 동기만 맞추던 기존의 스탠바이 레플리카(즉, 세컨더리 레플리카)들은 오리지널 레플리카 뿐 아니라 자신과는 독립적으로 사용자의 요청을 처리했을 다른 세컨더리 레플리카들과도 동기를 맞춰야 한다. 제안 기법에서는 액티브액티브 구조를 적용하면서 생기는 동기화 과정의 추가적인 오버헤드를 줄이고, 레플리카들의 메시지 동기 과정을 코디네이트 하기 위해 아파치 주키퍼와 같은 분산 코디네이터를 이용해 분산 락을 구현했다. 락이 걸려 있는 동안 모든 레플리카가 같은 순간에 메시지의 동기를 맞추도록 하였다.
본 논문에서는 분산 메시지 브로커에 액티브-액티브 구조의 레플리카를 적용하는 기법을 제안한다. 제안하는 기법은 브로커를 구성하는 노드 수의 증가 없이 부하를 분산시키는 것을 목표로 하며, 분산 코디네이터를 이용한 분산 락을 통해 각 액티브 레플리카들의 메시지 동기를 맞추었다. 이때 락 한 번에 모든 레플리카의 동기화를 같이 진행함으로써 각 레플리카가 따로 동기화를 맞추면서 생기게 되는 추가적인 오버헤드를 없앴다.
대상 데이터
medium 노드 4개를 사용하였으며, Table 1은 이의 구체적인 사양을 설명하고 있다. 메시지 브로커는 2개, 메시지 생산자와 메시지 소비자는 각 1개의 노드를 사용하였으며, 2개의 브로커 노드는 각각 액티브-액티브 레플리카와 액티브-스탠바이 레플리카를 구현하기 위해 사용되었다.
본 실험을 위해 Amazon EC2 t2.medium 노드 4개를 사용하였으며, Table 1은 이의 구체적인 사양을 설명하고 있다. 메시지 브로커는 2개, 메시지 생산자와 메시지 소비자는 각 1개의 노드를 사용하였으며, 2개의 브로커 노드는 각각 액티브-액티브 레플리카와 액티브-스탠바이 레플리카를 구현하기 위해 사용되었다.
이론/모형
만일 카프카에 의해 사용된 메시지 파티셔닝 방법과 본 제안에서 오리지널 레플리카가 요청을 분산할 때 사용하는 방법이 일치한다면 요청의 처리를 분산시키더라도 계속해서 특정 레플리카로 메시지가 전달되어 부하 불균형이 발생할 수 있다. 그러므로 오리지널 레플리카가 다른 세컨더리 레플리카에 요청을 분산할 때에는 모듈러 연산이나 다른 잘 알려진 해시 알고리즘을 이용하여 로드 밸런싱을 하는 것 보다 모든 레플리카에 공평하게 요청을 전달하기 위해서 라운드 로빈 방법을 사용했다. 또한, 레플리카들의 동기화를 위해 필요한 메타데이터의 양을 최소화하기 위해 오리지널 레플리카에서 사용자의 모든 요청을 우선 수용한 후 세컨더리 레플리카에는 생산 요청과 소비 요청만 분산하였다.
하둡 버전 2부터는 네임노드의 SPOF 문제를 해결하기 위해서 액티브 네임노드와 스탠바이 네임노드를 두는 이중화 방법을 사용했고, 네임노드를 가용할 수 없는 상황이 되면 스탠바이 네임 노드가 대체한다. 액티브 네임노드와 스탠바이 네임노드 사이에서 동기를 맞추는 방법으로는 Quorum Journal Manager 나 NFS 등을 사용한다. HDFS의 네임노드는 데이터노드 관리를 위한 하트비트나 메타데이터 같은 작은 크기의 메시지를 주기적으로 다루기 때문에 액티브-스탠바이의 구조가 적절하다.
성능/효과
만일 카프카에 의해 사용된 메시지 파티셔닝 방법과 본 제안에서 오리지널 레플리카가 요청을 분산할 때 사용하는 방법이 일치한다면 요청의 처리를 분산시키더라도 계속해서 특정 레플리카로 메시지가 전달되어 부하 불균형이 발생할 수 있다. 그러므로 오리지널 레플리카가 다른 세컨더리 레플리카에 요청을 분산할 때에는 모듈러 연산이나 다른 잘 알려진 해시 알고리즘을 이용하여 로드 밸런싱을 하는 것 보다 모든 레플리카에 공평하게 요청을 전달하기 위해서 라운드 로빈 방법을 사용했다.
9배의 처리 시간을 단축했음을 보인다. 메시지 생산자의 수가 증가함에 따라 시간 단축의 폭이 감소한 원인으로는, 생산자가 많아지면서 작성되는 메시지의 양 역시 증가하였지만 브로커를 구성하는 레플리카의 수가 작아 요청이 충분히 분산되지 못했기 때문에 액티브-스탠바이 구조보다 제안 기법에서 동기화로 인한 오버헤드의 영향이 더 컸던 것으로 보인다.
7배의 처리 시간을 단축했다. 메시지 소비 작업만 진행될 때에는 생산 요청으로 인한 추가되는 메시지의 동기화 과정이 없어 두 구조 모두 동기화 오버헤드의 증감 요소가 없었으며, 따라서 제안 기법을 사용한 경우에 더 빠른 메시지 동기화가 이루어져 처리 시간이 향상된 것으로 보인다.
본 연구에서는 장애 상황의 극복이 가능하면서도 분산 메시지 브로커의 가용성을 향상시키기 위해 메시지 레플리카를 액티브-액티브 구조로 구성하여 분산 브로커의 요청 부하를 분산시키는 기법을 제안하였다. 스탠바이 레플리카들이 액티브 레플리카로부터 요청을 전달받아 나누어 처리함으로써 브로커를 구성하는 노드 수의 증가 없이 요청 부하를 분산시킬 수 있었다. 이때 메시지 동기화 과정은 분산 코디네이터를 이용, 분산 락을 구현함으로써 모든 액티브 레플리카들이 한 때에 동기화를 진행하도록 하였고 각 액티브 레플리가 동기화를 할 때보다 추가적인 오버헤드를 적게 하였다.
실험에 앞서 레플리카들에서 메시지 동기화를 할 때 생기는 오버헤드를 수식으로 표현하여 액티브-액티브 구조의 레플리카를 활용하는 경우, 메시지의 수가 많아지더라도 액티브-스탠바이 구조의 레플리카보다 적은 오버헤드로 메시지의 동기를 맞출 수 있다는 것을 보였다. 실제 데이터와 구현한 프로토타입들을 이용해 실시한 실험의 결과를 통해 메시지의 생산/소비 요청과 메시지 동기화가 일어나는 상황에서 각 요청을 높은 성능으로 처리함을 보였다.
5는 소비자의 요청을 통해 메시지가 브로커에서 소비자에게 전달된 후 메시지를 처리하기까지의 시간을 측정한 결과이다. 실험 결과 제안 기법이 모든 경우에서 기존의 액티브-스탠바이 구조 대비 약 1.7배의 처리 시간을 단축했다. 메시지 소비 작업만 진행될 때에는 생산 요청으로 인한 추가되는 메시지의 동기화 과정이 없어 두 구조 모두 동기화 오버헤드의 증감 요소가 없었으며, 따라서 제안 기법을 사용한 경우에 더 빠른 메시지 동기화가 이루어져 처리 시간이 향상된 것으로 보인다.
6은 생산자가 보낸 메시지가 브로커에 저장된 후 소비자에게 전달되어 처리되기까지의 전체 시간을 측정한 결과이다. 실험 결과 제안 기법이 최소 약 1.11배에서 최대 약 1.33배의 처리 시간을 단축하였다. 앞 두 실험결과와 다르게 소비자의 처리 시간이 급격히 증가한 것은 메시지를 소비하는 과정이 메시지가 생산되고 다른 레플리카들에게 동기화되는 과정에 종속적이기 때문이다.
실험에 앞서 레플리카들에서 메시지 동기화를 할 때 생기는 오버헤드를 수식으로 표현하여 액티브-액티브 구조의 레플리카를 활용하는 경우, 메시지의 수가 많아지더라도 액티브-스탠바이 구조의 레플리카보다 적은 오버헤드로 메시지의 동기를 맞출 수 있다는 것을 보였다. 실제 데이터와 구현한 프로토타입들을 이용해 실시한 실험의 결과를 통해 메시지의 생산/소비 요청과 메시지 동기화가 일어나는 상황에서 각 요청을 높은 성능으로 처리함을 보였다.
제안 기법에서 메시지 동기화 과정은 분산 락을 만드는 것을 시작으로 진행되며 어느 한 세컨더리 레플리카에서 메시지 동기화를 위해 락을 생성하면 그 순간 오리지널 레플리카를 포함한 모든 레플리카가 메시지 동기를 맞추는 것을 시작한다. 레플리카들끼리 메시지 동기를 맞추기 전에 먼저 진행되는 과정은 다음과 같다.
후속연구
본 제안 기법에서는 동기화 체이닝 문제, 즉 동기화가 마무리되지 않은 레플리카를 동기화하기 위해 기다리는 다른 레플리카는 이전 레플리카의 동기화를 기다려야만 하는 문제는 여전히 해결하지 못하였다. 다른 분산 브로커 시스템에서도 아직 해결하지 못하고 있는 이 문제 역시 향후 연구를 통해 해결하도록 한다.
본 제안에서는 액티브-액티브 구조를 달성하기 위해 필요한 복잡한 동기화 과정을 분산 코디네이터에 의한 분산 락을 구현으로 단순화하였으며, 높은 처리 성능의 달성을 위해서 original 액티브 노드에 로드 밸런서 기능을 추가하여 다수의 레플리카-액티브 노드에 사용자 요청을 분산하도록 설계하였다. 다만, 동기화되지 않은 메시지를 가진 액티브-레플리카가 비가용 상태가 되었을 때 해당 레플리카가 다시 가용상태가 되기 전까지는 복제되지 않은 메시지를 이용할 수 없는 문제는 향후 추가 연구에서 해결하여야 한다.
질의응답
핵심어
질문
논문에서 추출한 답변
분산되어 있는 소프트웨어 컴포넌트 간의 정보교환을 위해 어떤 메시징 방식들이 제안됐었는가?
네트워크 상에 분산되어 있는 소프트웨어 컴포넌트들 간의 정보교환을 위해서 다양한 메시징 방식이 제안되어 왔다. 초기에 두 컴포넌트의 동기적 연결을 통한 메시징을 가능하게 하는 원격 프로시저 호출(Remote Procedure Call, RPC)과 같이 시간 및 공간적 동기를 요구하는 방식으로부터, 동기화의 제한점을 극복하기 위해 비동기 방식의 메시지 큐(message queue)나 메시지 브로커(message broker)와 같은 다양한 패러다임이 등장하였다. 이러한 비동기 방식의 메시징에서 사용하는 메시징 패러다임으로 점대점 패러다임(point-to-point)이나 발행/구독 패러다임(publish/subscribe) 등이 사용된다[1-3].
분산 브로커 구조가 제안된 계기는 무엇인가?
다양한 분산 소프트웨어 컴포넌트들의 정보 교환을 위해 비동기, 다대다 메시지 교환이 가능한 브로커 구조가 보편적으로 사용되고 있다. 특별히 많은 사용자 및 메시지를 지원하기 위해 높은 확장성의 분산 메시지 브로커가 제안되었다. 브로커의 가용성 및 장애 극복 능력을 향상시키기 위해 메시지 레플리카를 사용하여 액티브-스탠바이 혹은 액티브-액티브 구조를 사용하게 된다.
브로커의 가용성 및 장애 극복 능력을 향상시키기 위해 무엇을 사용하는가?
특별히 많은 사용자 및 메시지를 지원하기 위해 높은 확장성의 분산 메시지 브로커가 제안되었다. 브로커의 가용성 및 장애 극복 능력을 향상시키기 위해 메시지 레플리카를 사용하여 액티브-스탠바이 혹은 액티브-액티브 구조를 사용하게 된다. 그러나, 액티브-스탠바이의 경우 낮은 가용성의 문제, 그리고 액티브-액티브의 경우 동기화 오버헤드가 전체 성능을 낮추는 문제를 가진다.
참고문헌 (14)
P. T. Eugster, P. A. Felber, and R. Guerraoui, "The many faces of publish/subscribe," ACM Computing Surveys, Vol.35, No.2, pp.114-131, 2003.
E. Curry, "Message-oriented middleware," in Middleware for communications, John Wiley & Sons, pp.1-28, 2004.
G. Banavar, T. Chandra, R. Strom, and D. Sturman, "A case for message oriented middleware," In International Symposium on Distributed Computing, pp.1-17, 1999.
G. Pardo-Castellote, "OMG data-distribution service: Architectural overview," In Proc. IEEE International Conference on Distributed Computing Systems Workshops'03, 2003, pp. 200-206.
A. Fedoruk and R. Deters, "Improving fault-tolerance by replicating agents," In Proc. 1st International Joint Conference on Autonomous Agents and Multiagent Systems: Part 2, ACM, pp.737-744, 2002.
The Apache Software Foundation, "Welcome to $Apache^{TM}$ Hadoop!," The Apache Software Foundation, 2014. [Online]. Available: http://hadoop.apache.org. [Accessed Nov. 30, 2017].
The Apache Software Foundation, "Apache Hadoop 2.9.0 - HDFS High Availability," The Apache Software Foundation, 2017. [Online]. Available: https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html. [Accessed Nov. 30, 2017].
J-H. Hwang, M. Balazinska, and A. Rasin, "High-availability algorithms for distributed stream processing," In Proc. 21st International Conference on Data Engineering'05, pp. 779-790, 2005.
P. Hunt, M. Konar, F. P. Junqueira, and B. Reed, "ZooKeeper: Wait-free Coordination for Internet-scale Systems," In Proc. USENIX Annual Technical Conference, Vol. 8, pp.145-158, 2010.
The Apache Software Foundation, "Samza," The Apache Software Foundation. [Online]. Available: http://samza.apache.org. [Accessed Nov. 30, 2017].
The Apache Software Foundation, "Apache Storm," The Apache Software Foundation, 2015. [Online]. Available: http://storm.apache.org. [Accessed Nov. 30, 2017].
The Apache Software Foundation, "Spark Streaming $\mid$ Apache Spark," The Apache Software Foundation. [Online]. Available: http://spark.apache.org/streaming. [Accessed Nov. 30, 2017].
※ AI-Helper는 부적절한 답변을 할 수 있습니다.