메시지 브로커 이해. ActiveMQ 및 Kafka를 사용한 메시징 메커니즘을 학습합니다. 1장

안녕하십니까!

나는 작은 책을 번역하기 시작했습니다.
«메시지 브로커 이해",
저자: Jakub Korab, 발행인: O'Reilly Media, Inc., 발행일: 2017년 9781492049296월, ISBN: XNUMX.

책 소개부터:
"... 이 책은 널리 사용되는 두 가지 브로커 기술인 Apache ActiveMQ와 Apache Kafka를 비교 및 ​​대조하면서 브로커 메시징 시스템에 대해 생각하는 방법을 알려줍니다. 개발자가 동일한 영역에 대해 매우 다른 접근 방식(중간 브로커가 있는 시스템 간 메시징)을 취하게 된 사용 사례와 개발 인센티브에 대해 간략하게 설명합니다. 우리는 이러한 기술을 처음부터 살펴보고 그 과정에서 다양한 디자인 선택이 미치는 영향을 강조할 것입니다. 두 제품에 대한 깊은 이해, 사용 방법과 사용하지 말아야 할 방법, 향후 다른 메시징 기술을 고려할 때 찾아야 할 사항에 대한 이해를 얻게 됩니다. ... "

지금까지 번역된 부분:
1 장 소개
3장. 카프카

완성된 챕터는 번역되는 대로 게시하겠습니다.

제 1 장

소개

시스템 간 메시징은 IT 분야에서 가장 이해하기 어려운 영역 중 하나입니다. 개발자나 설계자로서 여러분은 다양한 프레임워크와 데이터베이스에 매우 익숙할 수 있습니다. 그러나 브로커 기반 메시징 기술이 작동하는 방식에 대해서는 어느 정도 익숙할 것입니다. 이런 느낌이 들더라도 걱정하지 마세요. 좋은 친구와 함께 있는 것입니다.

사람들은 일반적으로 메시징 인프라와 접촉하는 것이 매우 제한적입니다. 그들은 종종 오래 전에 만들어진 시스템에 연결하거나 인터넷에서 배포판을 다운로드하여 PROM에 설치하고 코드 작성을 시작합니다. PROM에서 인프라를 실행한 후 결과는 엇갈릴 수 있습니다. 오류로 인해 메시지가 손실되거나, 전송이 예상대로 작동하지 않거나, 브로커가 생산자를 "중단"시키거나 소비자에게 메시지를 보내지 않는 등 결과가 엇갈릴 수 있습니다.

익숙한 소리?

일반적인 시나리오는 메시징 코드가 당분간 잘 작동하는 경우입니다. 작동이 멈출 때까지. 이 기간은 보안에 대한 잘못된 인식을 갖게 하여 기술의 기본 동작에 대한 잘못된 믿음을 바탕으로 더 많은 코드를 생성하게 됩니다. 일이 잘못되기 시작하면 불편한 진실에 직면하게 됩니다. 즉, 제품의 기본 동작이나 작성자가 선택한 절충안(예: 성능 대 안정성, 트랜잭션성 대 수평 확장성)을 실제로 이해하지 못했다는 것입니다. .

브로커의 작동 방식을 깊이 이해하지 못한 채 사람들은 메시징 시스템에 대해 다음과 같이 겉보기에 합리적인 설명을 합니다.

• 시스템은 결코 메시지를 잃지 않을 것입니다
• 메시지는 순차적으로 처리됩니다.
• 소비자를 추가하면 시스템이 더 빨라집니다.
• 메시지는 한 번만 전달됩니다.

불행하게도 이러한 진술 중 일부는 특정 상황에서만 적용되는 가정에 기초한 반면 다른 진술은 단순히 부정확합니다.

이 책은 널리 사용되는 두 가지 브로커 기술인 Apache ActiveMQ와 Apache Kafka를 비교 및 ​​대조하면서 브로커 기반 메시징 시스템에 대해 생각하는 방법을 알려줍니다. 개발자가 동일한 영역에 대해 매우 다른 접근 방식(중간 브로커가 있는 시스템 간 메시징)을 취하게 된 사용 사례와 개발 인센티브에 대해 간략하게 설명합니다. 우리는 이러한 기술을 처음부터 살펴보고 그 과정에서 다양한 디자인 선택이 미치는 영향을 강조할 것입니다. 두 제품에 대한 깊은 이해, 사용 방법과 사용하지 말아야 할 방법, 그리고 향후 다른 메시징 기술을 고려할 때 찾아야 할 사항에 대한 이해를 얻게 됩니다.

시작하기 전에 기본 사항을 살펴보겠습니다.

메시징 시스템이란 무엇이며 왜 필요한가요?

두 애플리케이션이 서로 통신하려면 먼저 인터페이스를 정의해야 합니다. 이 인터페이스를 정의하려면 HTTP, MQTT, SMTP 등의 전송이나 프로토콜을 선택하고 시스템 간에 교환할 메시지 형식을 협상해야 합니다. 이는 메시지 페이로드 비용 요구 사항이 있는 XML 스키마 정의와 같은 엄격한 프로세스일 수도 있고, HTTP 요청의 일부에 클라이언트 식별자가 포함된다는 두 개발자 간의 합의와 같이 훨씬 덜 형식적일 수도 있습니다.

메시지의 형식과 메시지가 전송되는 순서가 시스템 간에 일관되는 ​​한, 다른 시스템의 구현에 대해 걱정하지 않고 서로 통신할 수 있습니다. 사용되는 프로그래밍 언어나 프레임워크 등 이러한 시스템의 내부는 시간이 지남에 따라 변경될 수 있습니다. 계약 자체가 유지되는 한, 상대방의 변화 없이 상호작용이 계속될 수 있습니다. 두 시스템은 이 인터페이스에 의해 효과적으로 분리(분리)됩니다.

메시징 시스템에는 일반적으로 발신자를 수신자로부터 추가로 분리(분리)하기 위해 상호 작용하는 두 시스템 간의 중개자가 포함됩니다. 이 경우 메시징 시스템을 통해 발신자는 수신자가 어디에 있는지, 수신자가 활성 상태인지 또는 인스턴스 수를 알지 못한 채 메시지를 보낼 수 있습니다.

메시징 시스템이 해결하는 문제 종류에 대한 몇 가지 비유를 살펴보고 몇 가지 기본 용어를 소개하겠습니다.

지점 간

Alexandra는 Adam에게 소포를 보내기 위해 우체국으로갑니다. 그녀는 창구로 가서 직원에게 소포를 건네줍니다. 직원은 패키지를 집어들고 알렉산드라에게 영수증을 건네줍니다. 패키지가 발송될 때 Adam은 집에 있을 필요가 없습니다. Alexandra는 패키지가 미래의 어느 시점에 Adam에게 전달될 것이며 계속해서 사업을 수행할 수 있다고 확신합니다. 나중에 어느 시점에서 Adam은 패키지를 받습니다.

이것은 메시징 모델의 예입니다. 점대점. 여기 우체국은 소포 배포 메커니즘 역할을 하여 각 소포가 한 번 배달되도록 합니다. 우체국을 이용하면 소포를 보내는 행위와 소포를 배달하는 행위가 분리됩니다.
기존 메시징 시스템에서 지점 간 모델은 다음을 통해 구현됩니다. 대기열. 대기열은 하나 이상의 소비자가 구독할 수 있는 FIFO(선입선출) 버퍼 역할을 합니다. 각 메시지는 전달만 됩니다. 구독한 소비자 중 한 명에게. 대기열은 일반적으로 소비자 간에 메시지를 공정하게 배포하려고 시도합니다. 단 한 명의 소비자만 이 메시지를 받게 됩니다.

"지속성"이라는 용어는 대기열에 적용됩니다. 신뢰성 소비자가 메시지 전달을 위해 대기열을 구독할 때까지 메시징 시스템이 활성 구독자가 없을 때 메시지를 유지하도록 보장하는 서비스 속성입니다.

신뢰성은 종종 다음과 혼동됩니다. 고집 두 용어가 같은 의미로 사용되지만 서로 다른 기능을 수행합니다. 지속성은 메시징 시스템이 메시지를 수신하고 소비자에게 보내는 사이에 일종의 저장소에 메시지를 쓰는지 여부를 결정합니다. 큐로 전송된 메시지는 지속성일 수도 있고 그렇지 않을 수도 있습니다.
지점간 메시징은 메시지에 대한 일회성 작업이 필요한 사용 사례에 사용됩니다. 예를 들어 계좌에 자금을 입금하거나 배달 주문을 완료하는 것이 포함됩니다. 메시징 시스템 자체가 일회성 전달을 제공할 수 없는 이유와 대기열이 기껏해야 전달 보장을 제공할 수 있는 이유에 대해서는 나중에 논의하겠습니다. 적어도 한 번.

게시자-구독자

Gabriella가 회의 번호로 전화를 겁니다. 회의에 연결되어 있는 동안 그녀는 발표자가 말하는 모든 내용을 나머지 통화 참가자와 함께 듣습니다. 그녀가 밖으로 나가면, 그녀는 말한 내용을 놓치게 됩니다. 다시 연결되면 그녀는 말하는 내용을 계속 듣습니다.

이것은 메시징 모델의 예입니다. 게시-구독. 회의 통화는 브로드캐스트 메커니즘으로 작동합니다. 말하는 사람은 현재 통화 중인 사람이 몇 명인지 상관하지 않습니다. 시스템은 현재 연결된 사람이 말하는 내용을 들을 수 있도록 보장합니다.
기존 메시징 시스템에서 게시-구독 메시징 모델은 다음을 통해 구현됩니다. 상의. Topic은 회의 메커니즘과 동일한 브로드캐스팅 방법을 제공합니다. 메시지가 주제로 전송되면 배포됩니다. 모든 구독 사용자에 대해.

주제는 일반적으로 신뢰할 수 없는(내구력이 없는). 청취자의 연결이 끊어지면 회의 통화에서 말하는 내용을 들을 수 없는 청취자와 마찬가지로 주제 구독자는 오프라인일 때 전송된 모든 메시지를 놓치게 됩니다. 이러한 이유로 토픽은 전달 보장을 제공한다고 말할 수 있습니다. 한 번 이상 각 소비자마다.

게시-구독 메시징은 일반적으로 메시지가 정보 제공용이고 한 메시지의 손실이 특별히 중요하지 않은 경우에 사용됩니다. 예를 들어 주제는 초당 한 번씩 센서 그룹의 온도 판독값을 전송할 수 있습니다. 현재 온도에 관심이 있고 주제를 구독하는 시스템은 메시지를 놓쳐도 걱정하지 않을 것입니다. 가까운 시일 내에 다른 메시지가 도착할 것입니다.

하이브리드 모델

상점의 웹사이트는 "메시지 대기열"에 주문 메시지를 배치합니다. 이러한 메시지의 주요 소비자는 실행 시스템입니다. 또한 감사 시스템에는 후속 추적을 위해 이러한 주문 메시지의 사본이 있어야 합니다. 시스템 자체를 한동안 사용할 수 없더라도 두 시스템 모두 메시지 통과를 허용할 수 없습니다. 웹사이트는 다른 시스템을 인식해서는 안 됩니다.

여러 시스템에 메시지 복사본이 필요하고 메시지 손실을 방지하기 위해 안정성과 지속성이 모두 필요한 경우와 같이 사용 사례에는 게시-구독 및 지점 간 메시징 모델의 조합이 필요한 경우가 많습니다.

이러한 경우에는 기본적으로 메시지를 주제로 배포하는 대상(대기열 및 주제에 대한 일반적인 용어)이 필요하므로 각 메시지는 해당 메시지에 관심이 있는 별도의 시스템으로 전송되지만 각 시스템은 수신되는 여러 소비자를 정의할 수도 있습니다. 메시지는 대기열과 비슷합니다. 이 경우의 읽기 유형은 다음과 같습니다. 각 이해관계자당 한 번씩. 이러한 하이브리드 대상에는 소비자가 오프라인이 되는 경우 소비자가 다시 연결된 후 해당 시간에 전송된 메시지가 수신되도록 내구성이 필요한 경우가 많습니다.

하이브리드 모델은 새로운 것이 아니며 ActiveMQ(주제와 대기열을 결합하는 가상 또는 복합 대상을 통해) 및 Kafka(암묵적으로 대상 디자인의 기본 속성으로)를 포함한 대부분의 메시징 시스템에서 사용할 수 있습니다.

이제 몇 가지 기본 용어를 살펴보고 메시징 시스템을 어떤 용도로 사용할 수 있는지 이해했으므로 세부 사항을 살펴보겠습니다.

번역 완료: tele.gg/middle_java

다음 번역된 부분: 3장. 카프카

계속 될 ...

출처 : habr.com