01.ApacheKafkaandConfluentReferenceArchitecture

Confluent Platform Reference Architecture

Large Cluster Reference Architecture

• 이 아키텍처는 확장을 고려해 설계

• 각 구성 요소는 자체 서버를 기반 으로 구성

• 노드를 추가하여 독립적으로 확장할 수 있음

• 예로, Confluent REST Proxy를 사용하는 애플리케이션을 추가할 때 REST Proxy는 더 이상 필요한 처리량을 제공하지 못하는 반면 기존 Kafka Broker에는 여전히 여유 용량이 있다면, 이 경우 REST Proxy 노드를 추가하여 확장하면 됨

• 권고값인 Zookeeper 서버 4대 이상 등 각종 노드들이 이중화.

Small Cluster Reference Architecture

• 대부분 Kafka를 처음 도입하는 조직은 부하가 제한된 하나의 사용 사례에 대해 Confluent Platform을 채택하는 것으로 시작

• 이 채택이 성공적으로 입증되면 조직은 추가 애플리케이션과 팀을 수용할 수 있도록 클러스터를 확장

• 일반적으로 초기 도입 프로젝트의 성공을 위해 전체 배포에 대한 투자가 필요하지 않은 Confluent Platform 채택의 초기 단계에 이 아키텍처를 권장

• 이러한 경우 더 적은 수의 서버로 시작하고 서버당 여러 구성 요소를 설치하는 것을 권장

• Confluent Control Center 및 Confluent ksqlDB와 같은 리소스 집약적 구성 요소에 대해서는 전용 서버를 구성하는 것을 권장

Hardware Recommendations for On-Premises Deployment

HA(High Availability) 란? HA(High Availability)는 2개의 서버를 이용하여 하나는 Active, 나머지하나는 Standby 상태로 정해놓는다. Active상태의 서버가 모든 부하를 담당하며 장애가 발생하는 경우 Standby 서버가 Active가 되면서 다시 서비스를 정상 작동할 수 있게 해주는 구성 HA솔루션이 갖추어야 할 기본기능

• 데이터 복제

• 장애 감시기능

Large Cluster

• SSD 사용 권장

• Connect의 CPU 권장은 Connector Worker Node 에 한함. Connector의 동작은 CPU의 소모가 클 수 있다.

• HA를 위한 노드 개수(최소 2)

Small Cluster

• 2행 memory : OS 영역 1GB 사용량에 따른 + α

Public Cloud Deployment

AWS, MS Azure, Google Cloud Platform

• Core : Cloud Provider는 시스템 크기를 조정할 때 "가상" Core를 사용 일반적으로 데이터 센터에서 사용하는 최신 Core보다 성능이 낮을 수 있음

• Network : 대부분의 Cloud Provider는 최상위 계층 노드에서만 10GbE를 제공 복제 트래픽을 고려한 필요 처리량을 제공하기에 충분한 네트워크 용량 확인

• On-Premises 환경에서 설치시 HW 사양을 Public Cloud 환경에서도 권장

• 사용량에 따라 유동적으로 sizing 해야한다.

온프레미스(On-Premises) 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식 오프프레미스(Off-premises) 오프프레미스란 일반적으로 SaaS 또는 클라우드 컴퓨팅이라고 한다. 온프레미스의 반대로 인터넷 네트워크에 연결된 서버팜이나 클라우드의 원격 실행환경을 의미

AWS EC2

• EBS: SSD 기반의 storage

• 온프레미스의 Broker, CPU Dual 12-core sockets(24core) 와 다른것은 위의 명세가 최소 사양이기 때문이다.

Google Cloud Compute Engine

Eventsizer

Kafka Sizing을 위한 도구

Sizing Calculator for Apache Kafka and Confluent Platform