- 출처: https://kafka.apache.org/documentation/#introduction
- Event streaming
Event streaming이란 인간의 중추 신경계(뇌와 척수로 구성되어 있으며 판단을 통해 감각 뉴런과 운동 뉴런을 연결시키는 역할을 함)와 같다. 비즈니스가 소프트웨어로 정의, 자동화되어 상시 가동하는 세상을 위한 기술의 기반이라고 할 수 있다.
기술적으로 말하자면 event stream으로 된 형태의 DB나 센서, 모바일 기기, 클라우드 서비스, 소프트웨어 어플리케이션등의 event 원천에서 실시간으로 데이터를 취하는일이라고 할 수 있다. 또한 나중에 검색할 수 있도록 이런 event stream들을 저장한다. 실시간으로 조작, 처리, event stream에 대한 반응을 할뿐만 아니라 나중에 소급적용(배치 작업)을 하기도 한다. 또한 필요에 따라 event stream을 다른 기술로 전달(ex - data를 변환하여 전달)한다.
- Kafka 에서의 Event streaming
Kafka는 일종의 event streaming platform 이라고 할 수 있다. Kafka는 3 가지 기능을 결합하여 end-to-end event streaming을 구현할 수 있으며, 이미 많은 기업들에서 사용하고 있으므로 어느 정도 안정성도 입증되었다고 할 수 있다.
- publish(write), subscribe(read): event stream을 쓰거나 읽고 다른 시스템으로 부터 데이터를 import, export 할 수 있다.
- store: 원하는 만큼 내구성있고 신뢰성있게 event stream을 저장한다.
- process: event stream을 실시간 혹은 소급적용(배치)방식으로 처리한다.
이런 모든 기능은 분산처리, 고가용성, 탄력성, 내결함성, 보안성을 갖고 제공된다. Kafka는 bare-metal 하드웨어, VM, container, on-premise, cloud에 배포될 수 있다. 또한 Kafka 환경을 스스로 관리하거나 다양한 벤더사로부터 제공된 서비스를 제공받을 수도 있다.
- Kafka 작동 방식
Kafka는 고성능의 TCP 네트워크 프로토콜로 통신하는 server와 client 들로 구성된 분산 시스템이다. Kafka는 클라우드 환경뿐만 아니라 on-premise의 container, VM, bere-metal 에서도 배포가 가능하다.
- Servers: Kafka는 클라우드 지역이나 여러 개의 데이터센터로 확장할 수 있는 하나 이상의 서버 클러스터로 실행된다. 이런 서버들 중 일부는 broker라고 부르는 storage 계층이다. 다른 서버들은 event stream으로 데이터를 가져오고 내보내기 위해 Kafka Connect를 실행하고, Kafka cluster 뿐만 아니라 RDB 같이 기존에 존재하던 시스템과 Kafka를 통합한다. mission-critical한 경우에도 사용할 수 있도록 Kafka cluster는 고가용성과 내결함성을 갖고 있는데, 어떤 서버가 실패하면 다른 서버들이 데이터 손실없이 해당 작업을 계속해서 할 수 있도록 보장해준다.
- Clients: Kafka는 내결함성을 지니고 있어서 네트워크 문제나 해당 머신의 오류가 발생한 경우에도 대규모를 고려한 병렬환경에서 event stream을 읽고, 쓰고, 처리하는 분산 어플리케이션이나 마이크로 서비스환경에서도 사용이 가능하다. Kafka의 커뮤니티 생태계는 비교적 풍부한 편이라서 수십개의 client들(ex - C/C++, go, Java, Node.js 등)을 지원한다.
- 주요 개념과 용어들
"event"라 함은 "무엇인가가 일어났다"는 사실을 기록한것을 말한다. 문서에서는 record나 message라고 칭하기도 한다. Kafka에 event 형태로 데이터를 읽거나 쓸 수 있다. 개념적으로 event는 key, value, timestamp, metadata header를 갖고 있다.
- Event key: "Alice"
- Event value: "Made a patment of $200 to Bob"
- Event timestamp: "Jun. 25, 2020 at 2:06 p.m."
Producer는 Kafka에 event를 기록(publish, write)하는 client들이며, consumer는 이런 event들을 구독(subscribe, read and process)한다. Kafka에서 producer와 consumer는 서로 알지 못하며 완벽하게 의존성이 없도록 설계되어 있는데, 이는 Kafka의 특성으로 잘 알려진 고가용성을 달성하기 위한 핵심 요소이다. 예를 들어 producer는 consumer를 기다릴 필요가 없다. Kafka는 정확히 하나의 event만 처리하는것과 같이 다양한 전달방식을 보장해준다.
Event는 topic이라는 곳에 저장된다. 간단히 말해서 topic은 파일 시스템의 폴더와 비슷하며, event는 폴더 내의 파일이라고 할 수 있다. 위의 예제에서는 topic의 이름을 "payments" 라고 명할 수 있다. Kafka에서 topic은 여러 개의 producer와 subscriber 를 가질 수 있다. topic은 해당 topic으로 event를 보내는 0개 이상의 producer를 가질 수 있으며, consumer 또한 마찬가지다. Topic의 event는 필요할 때 읽을 수 있다. 기존 MQ와는 다른게 consumer에서 메시지를 읽는다고 해서 event들은 삭제 되지 않는다. 대신 topic 마다 설정을 통해 얼마나 event를 보관할것인지 정의할 수 있으며, 그 후에 오래된 event들이 버려진다. Kafka의 성능은 데이터의 크기에 비례하여 사실상 일정하므로 데이터를 장기간 저장하는것은 상관이 없다.
Topic은 partition을 가질 수 있는데, 이는 topic이 다른 kafka broker 들에 위치하는 "bucket"에 분산되어 있다는것을 의미한다. 이렇게 데이터가 분산되어 있다는 것은 확장성과 관련해서 매우 중요한데, client 어플리케이션이 동시에 여러 broker들로 부터 그리고 broker들을 향해 데이터를 읽고 쓰는것을 가능하게 해주기 때문이다. 새로운 event가 topic으로 전송될 때 실제로는 topic의 partition 중 하나로 전송된다. 같은 key를 갖는 event들은 같은 partition으로 보내지는데, Kafka는 해당 전송된 순서와 동일하게 partition의 event들을 읽을 수 있도록 보장해준다.
데이터가 내결함성과 고가용성을 지니기 위해서 모든 topic은 복제본을 가질 수 있는데, 일이 잘못되었을 경우에 대비하여 데이터 복사본이 있는 여러 broker를 갖고 있도록 한다. 일반적으로 운영 환경에서는 데이터가 3개가 되도록 복제본의 수(replication factor)를 3으로 설정하는것이 보통이다. 이런 복사는 topic-partition 수준에서 수행된다.
'Framework and Tool > MQ' 카테고리의 다른 글
RabbitMQ vs Apache Kafka (0) | 2022.03.24 |
---|
댓글