애플리케이션 성능의 한계를 극복하는 일반적인 방법은 계산을 병렬 처리하는 것입니다. 해당 애플리케이션이 처리할 이벤트 또는 데이터를 수신하는 것을 컨슈머 스케일링이라고 합니다. ​​컨슈머 스케일링​​이란 들어오는 메시지나 이벤트 스트림의 동시 처리를 위해 복수의 컨슈머 애플리케이션 인스턴스를 병렬 실행하는 것을 의미합니다.

컨슈머 스케일링을 수행하기 위한 방법에는 여러 가지가 있습니다. 가장 주요한 것은 복수의 컨슈머가 메시지를 동시에 처리할 수 있는 커뮤니케이션 패턴인 ​​​경쟁적 컨슈머​​​​ 간의 엔터프라이즈 통합 패턴입니다. 이를 통해 컨슈머 프로세스를 확장하고 병렬화를 통해 전체 시스템 성능을 향상시킬 수 있습니다.

Solace PubSub+에는 컨슈머 스케일링을 수행하는 여러 가지 방법이 있으며, 올바른 접근법의 선택은 애플리케이션 요구사항에 따라 다릅니다. 이들은 크게 순차 순환 전달과 고정 부하 분산이라는 두 가지 범주로 나뉩니다. 이 글에서는 사용 가능한 다양한 옵션들을 설명하겠습니다.

순차 순환 전달

스케일링을 위한 경쟁적 컨슈머 패턴을 구현하는 첫 번째이자 가장 쉬운 방법은 순차 순환 전달 방식으로 모든 컨슈머 간에 들어오는 메시지를 부하 분산하는 것입니다. 이 방식은 부하가 모든 컨슈머 간에 균일하고 고르게 분포되도록 보장합니다. 또한 이러한 패턴은 메시지 순서를 유지하라는 요구사항이 없는 경우에 유용합니다. 각각의 메시지는 나머지 메시지와 독립적으로 처리됩니다. 또는 일부 종속성이 있는 경우에는 컨슈머가 이러한 종속성을 조정할 수 있도록 어느 정도 공유 상태를 가집니다(예: 공유 백엔드 데이터베이스, 메모리 내 데이터 그리드).

순차 순환 전달의 주요 장점 중 하나는 ​​동적​​이고, 거의•​​무한으로 확장 가능​​하며, 수백 또는 수천 명의 컨슈머가 합류할 수 있고 이들 간에 이벤트 또는 메시지가 분산되고, 처리 부하에 따라 컨슈머가 추가하거나 제거할 수 있다는 점입니다.

공유 구독 – 비지속적 QoS 순차 순환

비지속적(또는•​​직접​​ 메시징) 서비스 품질의 경우, Solace는 복수의 컨슈머를 그룹에서 동적으로 합류 및 제외시킬 수 있는 ​​공유 구독​​ 기능을 지원합니다. 이 패턴/기능은 서비스 요청 및 응답(​​request-reply​​)을 처리하는 백엔드 컴포넌트에 특히 유용합니다. 이 패턴은 일반적으로 직접적인 비지속적 QoS를 사용하기 때문입니다.

그림 1: 공유 구독을 사용한 비지속적 순차 순환 전달

공유 구독 기능을 사용하기 위해서는 컨슈머는 합류하고자 하는 그룹과 원하는 토픽 #share/<ConsumerGroupName>/topicFilter>/ 을 표시하는 특정 토픽을 사용하여 구독해야 합니다. 예를 들어•​  #share/backend/estore/order/new  ​는•​estore/order/new 를 구독한 컨슈머를 그룹의 ‘백엔드’에 추가합니다. 게시자가 토픽•​estore/order/new​에 대해 게시할 때마다, Solace PubSub+는 ‘백엔드’ 공유 그룹의 한 컨슈머에게 해당 메시지의 사본을 전달합니다.

이 기능은 메시지 전달에 a href=”https://solace.com/blog/publish-subscribe-messaging-pattern/” target=”_blank” rel=”noopener noreferrer nofollow”>​게시-구독​​(pub/​sub)•패턴을 사용하므로, 두 번째 컨슈머 그룹은 다른 공유 그룹 이름으로 구독하여 메시지 사본이 병렬로 수신되도록 구성할 수도 있습니다.

그림 2: 복수의 공유 가입 그룹

위의 그림에 표시된 대로, 이는 또한 모든 ​​estore/​order/​new​​•메시지의 사본을 ‘분석 그룹’의 한 컨슈머에게도 전달하며,•이때 ​​게시자 또는 원래 컨슈머의 코드를 변경할 필요가 없습니다​​. 이것이 게시-구독 패턴의 힘입니다.

공유 구독의 개념은 Solace만의 기능이 아니라는 점에 유의하십시오. MQTT 3.1.1 사양의 일부는 아니지만, 공유 구독은 경량, pub/​sub 프로토콜의 MQTT와 함께 IoT 애플리케이션에 자주 사용됩니다. Solace는 MQTT를 기본적으로 지원하므로, 상응하는 구독 패턴은 ​$share/<ShareGroupName>/<topicFilter>​입니다.

공유 구독을 사용하도록 애플리케이션을 구성하는 방법에 대한 자세한 정보는 Solace PubSub+ 문서의 ​​공유 구독​​을 확인하십시오.

비배타적 대기열 – 지속적 QoS 순차 순환

지속적(또는•​​보증​​•메시징) 서비스 품질의 경우, Solace는 “비배타적 대기열”이라고 하는 기능을 활용합니다. ​​대기열​​은•데이터•저장을 위한 영구적 엔드포인트입니다. 대기열에 있는 모든 메시지는 디스크에 유지되며, 장애 조건(예: 네트워크 정전, 정전, 고가용성 장애 조치 등)에 관계없이 컨슈머에게 전달되도록 보장됩니다. ​​비배타적​​•대기열을•사용하면 복수의 컨슈머가 대기열에 연결하고 순차 순환 방식으로 메시지를 수신할 수 있습니다.

그림 3: 비배타적 대기열을 통한 지속적 순차 순환 전달

또한 비배타적 대기열에서는 최대 10,000명의 컨슈머가 동적으로 합류/이탈할 수 있으므로, 다른 컨슈머에 대해 부하 분산과 같은 영향을 미치지 않고 처리 규모를 늘리거나 줄일 수 있습니다.

Solace PubSub+에서 지속적 순차 순환 전달을 사용하기 위해서는 그룹별로 하나의 비배타적 대기열을 구성하고 필요한 토픽(또는 복수의 토픽)을 각각 구독하면 됩니다. 위의 예제에서는 2개의 대기열이 구성되어 있으며, 각 대기열은 ​​estore/​order/​new​​를•구독합니다. 게시자가 대기열의 구독과 일치하는 메시지를 보낼 때마다 해당 대기열에 사본이 배치되고 각 그룹마다 정확히 1명의 컨슈머에게 전달됩니다. (참고: Solace의 지속적 저장은 참조 기반이므로, 1개의 메시지 사본만 디스크에 지속됩니다). 컨슈머는 대기열에 결합하기만 하면 메시지를 수신할 수 있고 대기열에 이미 구성되어 있으므로, 토픽을 직접 구독할 필요성이 없습니다.

지속적 컨슈머가 대기열로부터 결합을 해제하려면 먼저 지속적 흐름을•​​stop()​​시켜•새 메시지 수신을 정지시키고, 수신된 모든 미해결/인플라이트 메시지가 ACKnowledged되었는지 확인해야 합니다. 이는 한 컨슈머가 결합을 해제할 때 다른 컨슈머가 재전달된 메시지를 수신하지 않는 것을 보장합니다.

지속적 컨슈머와 보증 메시지 수신에 대한 자세한 정보는 Solace PubSub+ 문서의 >​’보증 메시징의 기본 조작’​​과 ​​’보증 메시지 수신’​​을 참고하십시오.

고정 부하 분산 또는 키/해시 전달

때때로 특정 속성(예: 고객 ID, 주문 ID, 제품 ID 등)을 포함하는 게시된 이벤트 또는 메시지 데이터가 항상 그것이 생성된 원래 주문에서 처리되어야 하는 경우가 있습니다. 이 요구사항은 모든 ​​관련된​​ 메시지가 ​​동일한 컨슈머​​로•전달되어야 한다는 의미입니다. 즉, 이후 동일한 키를 가지는 메시지들도 항상 동일한 컨슈머에게 전달되도록 하는•​​키​​가 메시지에 포함되어야 합니다. 따라서, 특정 속성에 대한 변경사항이나 업데이트는 항상 순차적으로 처리됩니다.

‘​​컨슈머 그룹​​’이라는 용어는 로그 전달 애플리케이션인 Apache Kafka에 의해 대중화되었습니다. Kafka에서 소비자 그룹은 하나의 토픽의 내용을 읽을 수 있는 ‘논리적 컨슈머’를 형성하는 컨슈머 그룹입니다. Kafka 컨슈머 그룹의 컨슈머는 Kafka 토픽에 들어있는 하나 이상의 파티션에 연결하고 파티션 파일에서 순차적 로그 기록을 읽습니다. 기록(‘메시지’)이 ​​Kafka 토픽​​의 파티션에 연결되면, 게시자가 정의한 키 속성에 따라 파티션이 선택됩니다.

이는 동일한 키의 기록은 동일한 파티션에 배치되고 따라서 동일한 컨슈머에 의해 처리되는 형태의 ‘​​​고정 부하 분산​​​​’을 제공합니다.

계층적 토픽 구조와 Solace의 고급 토픽 필터 기능을 사용하면 Solace PubSub+에서도 동일한(그리고 더 나은) 기능을 사용할 수 있습니다.

Solace 토픽을 사용한 파티셔닝

토픽 계층 구조 또는 분류를 정의할 때 토픽 계층의 레벨 하나를 ​​파티션 키​​로•지정하십시오. 예를 들어, 주문 입력 시스템에서​
​ ​estore/order/[ORDER_ID_PARTITION_KEY]/more/specific/rest/of/topic​과 같은 토픽 구조를 사용할 수 있습니다.

키는 일반적으로 위에서 설명한 것처럼 게시된 데이터의 중요한 속성에 대한 해시입니다. 이 예에서 키 속성은 큰 정수인 명령 ID입니다. 간단하게 파티션 키를 <Order ID modulo 8>로 가정해 보겠습니다. 이는 0과 7 사이의 정수로, 가능한 값은 8개, 가능한 파티션은 8개입니다.• Solace PubSub+에서는 토픽과 구독을 쉽게 만들 수 있으므로, ​​​​필요한 만큼 많은 파티션을 만들어 보십시오.​​​

다음으로, ‘컨슈머 그룹’에서•​​발생 가능한 수의 장래 컨슈머​​•수만큼 대기열을 구성합니다.• 컨슈머와 정확히 동일한 수로 대기열을 구성할 수도 있지만, Solace PubSub+에서는 대기열을 쉽게 만들 수 있으므로, 추후 처음에 필요했던 것보다 더 많은 대기열을 유연하게 구성할 수 있습니다.

그림 4: 토픽 파티션을 이용한 지속적 고정 부하 분산

구성은 예제 다이어그램에 표시된 대로 다음과 같습니다.

• 4개의 대기열이 구성되어 있으며 각 대기열은 2개의 파티션을 구독합니다.​
  ​ (구독 끝부분의 파티션 키 수준 다음에 다중 수준 와일드카드 ‘>’를 사용하는 것에 유의하십시오.)
• 2명의 컨슈머가 2개의 대기열에서 각각 데이터를 수신하므로, 각 컨슈머는 4개의 파티션에 해당하는 데이터를 수신하고 있습니다.

이 eStore 예제에서 고객 게이트웨이/API가 여러 유형의 주문 이벤트(예: 신규, 변경, 취소)를 허용하도록 향상될 경우, 동일한 주문 ID와 관련된 이벤트도 동일한 백엔드 프로세서로 이동하는 것이 바람직할 것입니다. 이렇게 하면 한 프로세서에서 ‘새’ 주문을 받지 않고 ‘취소’는 다른 프로세서로 라우팅됩니다. 게시자가 주문 유형 이벤트를 생성할 때마다, 토픽의 세 번째(이 사례에 한해)​​ 수준이 사용되어 주문 ID 모듈로 8을 취해 메시지를 특정 파티션에 키잉합니다.

이 접근법을 사용하면 토픽을 사용하여 파티션을 정의함에 따라 아키텍처 패턴을 변경할 필요 없이 매우 많은 수의 파티션을 확보할 수 있습니다. 이를 통해 새로운 대기열 수로 키 구독을 재조정하여 컨슈머 그룹에 더 많은 소비자를 추가할 수 있으므로, 미래 유연성을 확보할 수 있습니다.

Solace PubSub+의 고정 부하 분산 패턴에 관한 자세한 설명은 제 동료 Mat Hobbis의 ‘Solace PubSub+ 이벤트 브로커의 고정 부하 분산’​​을 참고하십시오.

부록

부록 A: 파티션의 미래 유연성

Kafka 파티션은 로그 파일로 구현되므로, 이를 유지하기 위해서는 열린 파일 핸들이 필요합니다. 이는 생성할 수 있는 파티션 수에 대해 현실적인 한계를 형성합니다.

Solace 파티셔닝은 토픽과 토픽 구독을 사용하여 수행되고, 일반적으로 토픽 구독은 Solace 브로커에만 국한된 리소스가 아니므로 모듈로가 매우 큰 해시/키 함수를 선택하십시오. 이러한 가벼운 파티셔닝은 컨슈머 측에 탁월한 확장성을 제공합니다.

예를 들어, 모듈로 360으로 키 기능을 선택하면 크기 2, 3, 4, 5, 6, 8, 9, 12, 15, 20, 24 등으로 훌륭하게 균형 잡힌 컨슈머 그룹을 생성할 수 있습니다.• 단, 시작하기 위해서는 소수의 대기열에 이들 토픽 구독을 모두 매핑해야 할 수 있습니다.

부록 B: 다중 키 해싱

Solace는 계층적 토픽 구조를 지원하므로, 다중 키로 인코딩된 단일 토픽을 허용합니다. 예를 들어, ‘주문 ID’와 ‘고객 ID’가 서로 다른 ​토픽 계층 구조​​ 수준을 가질 수 있습니다.•따라서, 서로 다른 컨슈머 그룹이 키에 대해 원하는 속성을 판별하여 들어오는 주문을 수신할 수 있습니다.

Kafka에서 이 작업을 수행하려면 각각 다른 파티션 키를 사용하여 서로 다른 Kafka 토픽에 이중 게시해야 합니다.

부록 C: 파티션 오버드라이브와 저우선순위 거부

적절할 수 있는 Solace PubSub+의 고급 기능 중 하나는 ​​저우선순위 거부​​라는 지속적 대기열 기능입니다. 이 기능을 사용하면 관리자는 대기열에 대해 저우선순위의 메시지를 거부하기 시작하는 깊이 한계를 구성할 수 있습니다. 이를 통해 오버드라이브되는 파티션에서 새 메시지를 스로틀할 수 있습니다.

이전 예제에서, ‘새’ 메시지는 낮은 우선순위를 가지며, ‘수정’ 및 ‘취소’ 메시지는 높은 우선순위가 될 것입니다. 따라서 이어지는 항목은 항상 전과 동일한 대기열에 배치되지만, 대기열이 너무 많이 차면 ‘새’ 메시지는 거부되며, 이 경우 게시자는 해시 키를 다시 계산하여 다른 파티션에 다시 제출해야 합니다.

저우선순위 거부 구성에 대한 자세한 정보는 Solace PubSub+ 문서의 ​​저우선순위 메시지 거부 사용​​을 참고하십시오.