1.
IT에 처음 발을 내딛었을 때가 90년초반입니다. 여러가지 이유로 시스템이 필요했고 이때 도움을 받은 곳이 나우콤입니다. 대규모PC통신서비스였던 Hitel을 퇴사한 분들이 만든 서비스가 나우콤이었고 이 때 저와 같이 일했던 개발자 몇 분이 참여하였습니다. 생전 처음으로 대규모 시스템을 접했죠. 개념 정의도 명확히 하지 않은채로 Event-Driven과 Distributed라는 단어를 사용했습니다. 분산이라는 말은 예나 지금이나 이해의 차이가 없지만 Event-Driven의 경우 관점에서 차이가 있습니다. 90년대 초반 PC통신 및 인터넷 시대에 서버(Server)의 핵심적인 기능은 대용량 클라이언트 처리입니다. Forked Model, Pre-Forked Model, Multi-Process/Multi_Thread Model과 같이 이용자의 Request을 어떻게 받을지가 중요했습니다. 주식매매프로그램(HTS)의 경우 장 시작하면서 동시에 로그인을 합니다. 예전에는 몇 천명 요즘은 몇 만명이 동시 접속을 합니다. L4 스위치를 통하여 접속요청을 여러 서버로 나누지만 서버당 동시에 많은 요청을 처리합니다. Concurrency가 중요합니다. 이 때 선택한 것이 Event-Driven Concurrency였습니다. 아직 인터넷이 보편화하지 않은 때라 많이 보았던 책이 Richard Stevens의 Network Programming과 TCP/IP Illustrated입니다. 그리고 성능(High Throughput)을 고민하면서 좀 오래전 글이지만 The C10K problem도 살폈습니다.
Operating Systems: Three Easy Pieces에서 Event_Driven Concurrency를 다루는 논문이 이 때 고민을 그대로 담고 있네요. Event라고 하지만 정확히 표현하면 Request입니다.
The basic approach we’ll use, as stated above, is called event-based concurrency. The approach is quite simple: you simply wait for something (i.e., an “event”) to occur; when it does, you check what type of event it is and do the small amount of work it requires (which may include issuing I/O requests, or scheduling other events for future handling, etc.)
다른 시스템과 달리 주식매매시스템은 실시간 서비스가 무척 중요합니다. 시세를 자동으로 보내고 체결도 자동으로 보내서 화면상에 업데이트를 하여야 합니다. PC통신서비스의 Chat Service와 유사합니다. 이런 이유로 관심을 가졌던 부분이 Messaging입니다. 비동기처리도 포함합니다. 정리하면 90년대 초반의 화두는 Concurrency와 Asychronous였습니다.
2.
앞서 Messaging이라는 표현을 사용했는데 실시간 전송서비스를 구현하기 위하여 증권IT를 하는 업체들은 여러가지로 고민하였습니다. 플랫폼마다 약간씩 차이가 있지만 큰 틀로 보면 두가지입니다.
첫째 어떤 Session이 무엇(어떤 종목의 시세, 체결)을 원하는지. Subscribe
둘째 어떻게 전달하지…Publish
즉, Publish/Subscribe를 어떻게 구현할지가 메시징에서 가장 중요하였습니다. 한 걸음 더 나아가면 시세 혹은 체결메시지를 전달하는 방식에 따라 Pull 혹은 Push 방식으로 나뉩니다. Pull과 Push는 C/S사이의 관계가 아니고 서버 프로세스사이의 관계를 뜻합니다. 저에게 Messaging은 시스템/서비스/프로세스간의 비동기적 통신을 의미합니다. 한국의 주식시스템이 증권IT회사의 독자적인 플랫폼에 기반하여 성장한 반면 해외의 경우 Messaging Oriented Middleware가 중요한 역할을 합니다. 대표적인 서비스가 Reuter가 사용하였던 Reuters Market Data System입니다. RMDS는 내부적으로 Rendevous를 사용합니다. Tibco가 만든 유명한 MOM입니다.
AMQP는 지금도 Redhat AMQ를 포함하여 오픈소스로 명맥을 유지하는 MOM중 하나입니다. AMQP를 만든 O’Hara의 글중 일부입니다.
월스트리트에 있는 대부분 대형IB들은 어느정도 자체의 메시징미들웨어(MOM)을 가지고 있었습니다. 이들중 상당수는 없어졌거나 상용제품으로 대체되고 있습니다.왜 대형IB들은 자체의 MOM을 구축했을까요? 금융서비스산업은 Pub/SUB기능 및 확실한 전송보장을 지원하는 기능을 갖는 메시징시스템을 필요로 합니다. 이상의 요구는 종종 현재 이용가능한 MOM이 제공할 수 있는 기능을 넘어서기도 하고 IB에서 MOM을 구축하기 위한 기술인력도 충분하기 때문에 자체적인 MOM을 개발한는 것은 충분히 선택가능한 접근방법입니다.
월스트리트는 표준화를 하였고 한국은 표준화의 길을 걷지 않았습니다. 이점이 다릅니다. Rendezvous외에 여의도에서 판매실적이 있는 제품이 SmartSocket입니다. Tibco가 인수하여 역사의 뒷길로 사라졌습니다. 최초 오픈소스로 시작해서 발전한 제품입니다. 제품 소개서에 있는 MOM 정리입니다.
Message-Oriented Middleware
In general, MOM products work by passing information in a message from one program to one or more other programs. The information can be passed asynchronously, where the sender does not have to wait for a reply. MOM products, in general, cover more than just passing information; they usually include services for translating data, security, broadcasting data to multiple programs,error recovery, locating resources on the network, cost routing, prioritization of messages and requests, and extensive debugging facilities. Unlike both ORB and RPC products, MOM, in general, does not assume the system has a reliable transport layer underneath. MOM tries to address the problems that surface when the transport layer is unreliable, as occurs when programs must communicate over a WAN or over the Internet.
Two different types of MOM have emerged:
1. message queuing
2. message passing
이렇게 메시징미들웨어를 소개하는 이유는 글 제목처럼 Streaming이라는 개념을 명확히 하기 위함입니다. Messaging을 이야기할 때 중요한 점은 Realtime입니다. Realtime을 위한 Asynchronous Communication이 필요했죠.
3.
어느 때부터 SOA가 등장하고 좀더 지나니까 Microservice가 돌아 다닙니다. HTTP는 모든 서비스의 표준이 되었습니다. 이 때 여의도에서 실시간서비스를 어떻게 구현할지를 놓고 여러가지 방안이 등장하였습니다. 처음 웹이 나왔을 때 했던 방식은 Reload. Polling이라고 할 수 있지만 Page Polling입니다. 부하가 심합니다. 이후 AJAX가 나오면서 메시지만 요청하는 방식으로 바뀝니다. HTTP Polling이라고 할 수 있죠. 여기까지는 증권사 프로젝트에서 구현을 했고 서비스를 하였습니다. 이후 기술적으로 흐름을 찾아보니까Long Polling과 HTTP Streaming, Websocket이 등장하는데 웹소켓을 제외하면 솔직히 생소합니다. HTTP Streaming을 기술적으로 설명할 때 SSE(Server Sent Events)라고 하네요. Websocket과 비교하면 SSE(Server-Sent Event)는 Server Push 기술로 웹 소캣과 유사하게 서버와 Javascript가 서로 통신하여 데이터를 받아올 수 있는 반면 웹소켓의 경우 양방향 통신이 가능하지만, SSE는 서버→클라이언트로 받는 요청만 처리할 수 있습니다. Streaming Data에서 비교한 도표입니다. 그림으로 보니까 이해가 쉽네요. 개인적으로는 2019년쯤 앱에서 실시간서비스를 구현할 때 Websocket을 사용하였습니다.
첫째 Long Polling
둘째 Streaming
셋째 Websocket
Microservice와 API가 회자하면서 REST API가 표준으로 정착할 때 Streaming이라는 표현이 회자하기 시작하였습니다. 제가 기억하는 출발은 암호통화입니다. 관련한 관련한 서비스를 분석하면 대부분 REST API/Websocket API를 제공합니다. Websocket API를 설명하는 글을 보면 Messaging API라는 표현 대신 Streaming API라고 합니다. 저의 질문은 “왜 Messaging이라는 표현을 사용하지 않고 Streaming이라는 표현을 사용했을까” 입니다.
서비스로 Streaming을 설명하면
Streaming is an immediate and continuous method of accessing content from the internet.
기술적으로 Streaming을 설명하면
“서버가 응답을 해도 클라이언트에서는 다시 요청을 하지 않는 방식입니다.즉, 한 번의 요청에 대하여 서버가 응답을 지속적으로 클라이언트에게 보낼 수 있는 방식이 Streaming 방식”
여기서 곰곰히 생각해보면 Streaming이라는 표현을 사용할 때 강조할 점은 Stream이라는 단어 자체입니다. 영어사전의 설명을 보면
(of liquid) run or flow in a continuous current in a specified direction.
(of a mass of people or things) move in a continuous flow in a specified direction.
transmit or receive (data, especially video and audio material) over the internet as a steady, continuous flow.
공통이 Continuous입니다. 계속 이어지는 혹은 연속의…. 라는 의미를 갖습니다. Stackoverflow를 보면 저와 같은 질문이 있습니다.
Difference between stream processing and message processing
이에 달린 답변중 하나입니다.
In traditional message processing, you apply simple computations on the messages — in most cases individually per message.
In stream processing, you apply complex operations on multiple input streams and multiple records (ie, messages) at the same time (like aggregations and joins).
Furthermore, traditional messaging systems cannot go “back in time” — ie, they automatically delete messages after they got delivered to all subscribed consumers. In contrast, Kafka keeps the messages as it uses a pull-based model (ie, consumers pull data out of Kafka) for a configurable amount of time. This allows consumers to “rewind” and consume messages multiple times — or if you add a new consumer, it can read the complete history. This makes stream processing possible, because it allows for more complex applications. Furthermore, stream processing is not necessarily about real-time processing — it’s about processing infinite input streams (in contrast to batch processing, which is applied to finite inputs).
앞서 Streaming에서 강조할 부분은 Continuous라고 하였습니다. Messaging은 연속이든 아니든 데이타를 서비스와 서비스사이에서, 혹은 프로세스와 프로세스사이에서 비동기적으로 처리하는 뜻을 강조하는 듯 합니다. 전자는 Service를 강조하고 후자는 기술를 강조합니다. 앞서 인용하였던 Streaming Data의 첫장은 Introducing streaming data입니다. 여기서 Differences between real-time and streaming data system를 다룹니다.
엥, Realtime과 Streaming이 다른다고?
저자는 클라이언트 입장에서 보면 지연은 필연적이기 때문에 실시간이라고 할 수 없고 클라이언트 어플리케이션이 필요로 하는 순간 데이타를 이용할 수 있는 시스템을 Streaming Syste이라고 합니다.
Definition:Streaming Data System
In many scenarios, the computation part of the system is operating in a non-hard real-time fashion, but the clients may not be consuming the data in real time due to network delays, application design, or a client application that isn’t even running. Put another way,what we have is a non-hard real-time service with clients that consume data when they need it. This is called a streaming data system—a non-hard realtime system that makes its data available at the moment a client application needs it. It’s neither soft nor near—it is streaming.
왜 이런 정의를 사용할까요? 핵심은 실시간이냐 아니냐가 아니라 고객의 요구를 중심으로 시스템을 설계하는 것에 집중하기 위함이라고 합니다. 제가 정리한 해석에 의하면 ‘서비스’관점입니다.
The concept of streaming data eliminates the confusion of soft versus near and realtime versus not real-time, allowing us to concentrate on designing systems that deliver the information a client requests at the moment it is needed. Let’s use our examples from before, but this time think about them from the standpoint of streaming. See if you can split each one up and recognize the streaming data service and streaming client.
You are using the NASDAQ Real Time Quotes application to track your favorite stocks.
3.
Messaging과 Streaming을 비교한 글중 충격을 먹은 글이 있습니다. IBM의 Why enterprise messaging and event streaming are different입니다. 기술을 이해할 때 어떤 경우에 사용하는지가 중요하다고 합니다. 비동기통신으로 가능한 예제로 든 두가지 경우
To understand when to use which technology, let’s start with the use cases around asynchronous communication:
- Request for processing: This use case has an application making a request to another system or service to complete an action. This may result in a response message being returned to the requester. This pattern has existed since the beginning of IT, and is likely to continue for ever more. For synchronous, low quality of service communication, HTTP is the natural choice due to the availability of the technology, while asynchronous messaging is the natural choice for mission-critical communication. For further discussion on when to use synchronous and asynchronous communication, review the article “An introduction to APIs and messaging“.
- Access enterprise data: In this use case, components within the enterprise can emit data that describe their current state. This data does not normally contain a direct instruction for another system to complete an action. Instead, components allow other systems to gain insight into their data and status. This can be a powerful mechanism to distribute and consume enterprise data.
비동기통신으로 Request/Reply를 사용한다… 저에게는 무척 생소합니다. An introduction to APIs and messaging을 읽었습니다. 이런 비교가 나옵니다.
Characteristic APIs Messaging Interaction Styles HTTP is synchronous. Each request message has a corresponding response; that is, an acknowledgement of the request message. This makes request/response solutions easy to implement. Messaging is asynchronous, and allows a full range of interaction patterns, including: fire and forget, where requesting messages do not have corresponding responses; request/response, where each request message has a corresponding response; and publish/subscribe, where applications, systems, or services can register for messages on a defined topic. The messages are forwarded to all subscribers when publishers emit events.
Request/Reply를 비동기통신을 구현하면 어떤 그림일지 찾아보았습니다. Read Only, Write Only Queue를 만들어서 Request/Reply를 구현한 모양입니다.
이벤트기반의 마이크로서비스를 채용한 설계를 할 때 Asynchronous Request-Reply pattern 라는 이름으로 사용하는가 봅니다. 왜 이런 그림이 가능할까 생각해보니까 Microservice에 대한 이해가 부족했기때문입니다. Service Oriented Architecture의 한계를 극복하기 위하여 Service를 Microservice로 바꾸었다고 생각했는데.. 한가지가 빠졌습니다.
모놀리식 아키텍처와 마이크로서비스 아키텍처 비교
모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행됩니다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 합니다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해집니다. 그리고 이러한 복잡성으로 인해 실험에 제한을 받고 새로운 아이디어를 구현하기가 어려워집니다. 종속 관계를 이루며 긴밀하게 결합된 많은 프로세스로 인해 단일 프로세스의 실패로 인한 영향이 증가함에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킵니다.
마이크로서비스 아키텍처의 경우, 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행됩니다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신합니다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행합니다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있습니다.
마이크로서비스란 무엇입니까?중에서
유명한 Martin Fowler의 Microservices:a definition of this new architectural term를 보면 위 글과 비슷한 내용입니다.
These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .
A microservices architecture is a type of application architecture where the application is developed as a collection of services. It provides the framework to develop, deploy, and maintain microservices architecture diagrams and services independently.
Microservices architecture defined중에서
여러 문서를 보면 공통으로 들어간 단어가 있습니다. 독립….
small, independent, and loosely coupled.
그리고 또하나의 표현..
Loosely Coupled
Transaction Middleware와 MOM을 비교할 때 빠지지 않고 등장하는 표현입니다. Microservice와 Loosely Coupled가 이어질 줄은 몰랐습니다. 배움이 부족했네요. ㅠㅠㅠㅠ
4.
여기서 멈추고 Streaming으로 가려고 했는데 새로운 개념을 접했습니다.
Event Driven Microservice
최초 여의도에서 증권매매용 플랫폼을 만들 때 사용했던 Event-Driven이라는 표현이 다시금 등장합니다. 제 기준으로 보면 30년전인데 세상은 돌고 도나 봅니다. 그렇지만 단어에 담긴 의미는 달라진듯 합니다.Microservice가 보편화하면서 문제점이 발생한 듯 합니다.
MSA의 구조적 문제점
5~6년 전부터 MSA에 대해서 많은 논의가 있어왔습니다. MSA와 같은 모듈형 아키텍처 스타일은 클라우드 기반 환경에 적합해 높은 인기를 구가하고 있습니다. 특히 도커(Docker), 쿠버네티스(Kubernetes) 등과 같은 컨테이너 기반의 플랫폼과 조합이 잘 어우러지면서 클라우드 플랫폼과 MSA는 서로 끌어주고 밀어주면서 발전하고 있습니다. MSA는 아마존, 넷플릭스, 이베이와 같은 글로벌 서비스 기업들이 사용할 만큼 강력한 아키텍처입니다. 하지만 막상 MSA를 적용하려고 하면 다음과 같은 난관에 부딪히게 됩니다.
1) 개발 복잡도와 숙련도
분산 시스템 개발은 일반 개발보다 복잡합니다. 독립적인 서비스이기 때문에 각 모듈의 인터페이스를 신중하게 처리해야 합니다. 요청에 응답하지 않게 될 경우에 대한 방어 코드도 작성해야 하며 호출 대기 시간이 일정 수준을 넘기면 복잡한 상황이 발생할 수 있습니다. 또한 동기적인 처리방식인 REST 통신으로 인한 제약이 발생할 수 있습니다.2) 트랜잭션 관리
MSA는 Database Per Service라는 새로운 요구사항으로 분산된 서비스마다 분리된 DB들 간의 트랜잭션 관리가 어려울 수 있습니다. 또한 반정규화 된 데이터의 동기 처리도 신경을 써야 합니다.3) 통합 테스트 어려움
MSA 기반의 애플리케이션을 테스트하는 것은 번거로울 수 있습니다. 테스트를 시작하기 전에 의존성이 있는 서비스를 미리 확인해야 합니다.4) 배포 복잡도
MSA의 배포는 복잡 할 수 있습니다. 각 서비스 간의 조정이 필요 할 수 있습니다.MSA를 도입하다보면 기존에 없던 새로운 문제점들이 발생합니다. 이런 부분들은 자동화 도구를 사용하거나 비즈니스 상황에 맞게 수정된 아키텍처를 적용하여 해결할 수 있습니다. 본 아티클에서는 MSA가 적용된 시스템을 보완하는 Event Driven MircoService(EDM)를 소개하려고 합니다.
저의 관심은 EDM에서 Event를 어떻게 정의하는지 입니다. 먼저 WIKI의 정의입니다.
In programming and software design, an event is an action or occurrence recognized by software, often originating asynchronously from the external environment, that may be handled by the software. Computer events can be generated or triggered by the system, by the user, or in other ways. Typically, events are handled synchronously with the program flow; that is, the software may have one or more dedicated places where events are handled, frequently an event loop.
A source of events includes the user, who may interact with the software through the computer’s peripherals – for example, by typing on the keyboard. Another source is a hardware device such as a timer. Software can also trigger its own set of events into the event loop, e.g. to communicate the completion of a task. Software that changes its behavior in response to events is said to be event-driven, often with the goal of being interactive.
Event Driven Architecture란?은 다음과 같이 정의합니다.
이벤트
IT 영역에서 이벤트는 다양한 정의를 갖지만, 이 곳에서 언급하는 이벤트는 상태의 변경. 즉, 데이터의 변경,생성,삭제(CUD)를 통해 발생하는 서비스의 의미있는 변화를 뜻합니다.
데이터상태의 변경.. 이렇게 기억하면 좋을 듯 합니다. 다음으로 Event-Driven Microservice를 구성하는 Event-Driven과 Microservice를 비교한 내용입니다. Architectural considerations for event-driven microservices-based systems의 일부입니다.
EDA Microservices Architecture Loose coupling between components/services Bounded context which provides separation of concerns Ability to scale individual components Independently deployable & scalable Processing components can be developed independent of each other Support for polyglot programming High cloud affinity Cloud native Asynchronous nature. As well as ability to throttle workload Elastic scalability Fault Tolerance and better resiliency Good observability to detect failures quickly Ability to build processing pipelines Evolutionary in nature Availability of sophisticated event brokers reduce code complexity Set of standard reusable technical services often referred as MicroServices ChassisA rich palate of proven Enterprise Integration Patterns Provides a rich repository of reusable implementation patterns
글을 읽어보면 EDM이라는 변화를 이끈 동력은 데이타중심의 서비스가 있지않을가 합니다.
5.
빙빙 돌았습니다. Streaming이라는 단어에 꽂힌 직접적인 이유는 Apache Kafka때문입니다.
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
젊은 개발자를 만나는 경우가 별로 없고 더구나 최근 기술을 사용하는 개발자를 볼 기회는 더더욱 없는데 우연히 성당 청년회 모임때 Kafka 개발자를 만났습니다. 무슨 일을 하는지 물어보니까 “Backend”라고 해서 Domain Knowledge나 SQL과 관련한 기술을 가진 줄 알았습니다. 좀더 깊이 이야기하니까 Kafka를 이용하여 Backend System을 개발한다고 하네요. 그것도 은행과 함께.. Kafka가 대세중의 대세라는 느낌이 들었지만 직접 귀로 확인하였습니다.
Tibco 보고서를 보면 Kafka를 이렇게 소개합니다. “전통적인 MOM과 왜 다른지”를 이해할 수 있습니다. “common framework to handle high-throughput and distributed workloads for streaming logs and other real-time data feeds”이 차이를 만들어낸 듯 합니다.
Apache Kafka
To understand Apache Kafka, you need to understand where it came from. Developed by LinkedIn and donated to the Apache Software Foundation, Kafka was originally designed as a common framework to handle high-throughput and distributed workloads for streaming logs and other real-time data feeds. While the concept of high-throughput messaging isn’t new, Kafka brings a new approach to solving the challenges of data distribution and data resiliency that are built on the traditional concepts of pub/sub messaging. Producer and consumer applications send and receive data using topics (metadata) that allow brokers to do the routing. Kafka is unique in how it manages data persistence and tracks consumption. It distributes brokers, and segments topics, into partitions that can be balanced and redistributed by administrators as more capacity and scale is needed.
Unlike other real-time messaging systems that store data based on durable consumption, Kafka persists data (and consumption metadata) based on Time To Live (TTL), an approach that allows applications to consume data from any point in the persisted data stream (replay those streams on demand) and use consumer offsets to track which data has been consumed. TTL provides native support for data replay where other systems usually require out-of-band techniques to accomplish this
그리고 Confluent가 발행한 Event-Driven Microservices를 보면 Kafka와 다른 MOM의 차이점을 아래와 같이 정리합니다.
Is a Message Bus Enough for Event-Driven Microservices?
Traditional messaging offering Publisher and Subscriber semantics was designed with ACID (Atomicity, Consistency, Isolation, Durability) capabilities in mind. As defined by the CAP theorem, atomicity is a tradeoff that we need to make when seeking scalability and availability. Traditional messaging middleware is not only non-distributed and therefore not scalable, but it also
lacks persistent storage as a core characteristic. With a traditional messaging server, messages are persisted in queues until the server attempts a delivery, which is not guaranteed. This poses challenges when we need to add a new service and want it to consume historical events.One workaround would be to expose an endpoint on the producer side, and use this endpoint to regenerate the desired events. But even with such a feature, we cannot guarantee that these events will be identical to the ones previously consumed. This is an anti-pattern: it would couple the two services together with an API, rather than with a streaming contract. An event-driven microservice must be able to replay historical events and messages that occurred prior to the existence of the service. A core feature of Apache Kafka is that it persists messages and is able to natively serve past events to new consumers.
전통적인 개념을 새로운 내용을 추가하여 사용하는 것이 좋을지, 아니면 새로운 개념을 만들어서 사용하는 것이 좋을지.. 이런 선택이 아닐가 합니다. 데이타, API(REST API), Microservice 그리고 Event Driven Architecture를 씨줄, 날줄로 묶기 위한 개념으로 Messaging 대신 Streaming을 선택했다는 생각입니다. 어찌되었든 Kafka를 공부하여야 하네요.
