ksqlDB : ksqlDB의 간단한 구조 및 배포 모드

들어가기 전

ksqlDB는 Kafka Streams 위에 구현되어있다. 따라서 ksqlDB의 동작 과정을 low한 레벨로 공부하고 싶다면 Kafka Streams를 공부해야한다. 여기서는 ksqlDB에서 이야기 하는 ksqlDB Server / ksqlDB Client 구조를 살펴보고자 한다.

 

ksqlDB Server 클러스터

ksqlDB는 클러스터 단위로 구성될 수 있다. ksqlDB Cluster마다 고유한 ksql.service.id를 가진다. 같은 ksql.service.id만이 같은 Context를 가지고 부하를 분산할 수 있고, 서로 다른 ksql.service.id를 가지는 클러스터끼리는 격리되어있다. 

같은 ksql.service.id를 가지는 것은 같은 consumer group의 멤버인 것을 의미한다. 따라서 새로운 ksqlServer가 추가/삭제가 되면 ksqlDB 서버의 kafka consumer는 내부적으로 파티션을 재분배하도록 동작한다. 

 

ksqlDB Server의 구성

https://docs.ksqldb.io/en/latest/img/ksqldb-architecture-and-components.png

ksqlDB server는 SQL engine과 REST API로 구성된다. 아래에서 하나씩 더 살펴보고자 한다. 

SQL engine

ksqlDB Server의 SQL Engine은 다음과 같은 일을 수행한다. 

1. SQL Engine은 REST API로 전달된 SQL을 AST로 Parsing 한다. 
2. SQL Engine은 AST를 바탕으로 Kafka Streams Topology를 구성한다. 
3. 생성한 Kafka Stream Toplogy를 실행시킨다. 

SQL Engine이 하는 일은 입력받은 SQL을 Kafka Streams Toplogy로 변경한 다음 이것을 실행시켜서 결과 값을 실시간으로 생성하는 역할을 한다. 

REST Service

ksqlDB Server는 REST 인터페이스를 가진다. 서버 밖에서 오는 모든 요청은 REST 인터페이스를 통해서 SQL Engine에 전달된다. REST 인터페이스는 DML / DDL 쿼리 뿐만이 아니라 ksqlDB Cluster의 헬스체크에도 사용될 수 있다. 기본적으로 REST 인터페이스는 8088 포트를 Listen하며 HTTP 프로토콜을 지원하지만, 리스너 Config 수정을 통해서 HTTPS를 이용할 수도 있다. 

listeners=http://0.0.0.0:8088
ssl.keystore.location=/path/to/ksql.server.keystore.jks
ssl.keystore.password=...
ssl.key.password=

ksqlDB Server의 위 설정을 통해서 프로토콜이나 listen 포트를 수정할 수 있다. ksqlDB Sever에 접근하고 싶은 사람들은 ksqlDB-Cli를 이용해서 접근할 수도 있고 REST 인터페이스에 CURL 같은 명령어들을 보내서 통신할 수 있다. 이 때 ksqlDB-Cli도 실제로는 ksqlDB Server와 REST API를 이용해서 통신한다. 

 

Deployment 모드

ksqlDB의 배포는 Interactive / Headless 모드를 제공한다. Interactive는 개발 환경에서 사용하는 것이 권장되고 Headless 모드는 프로덕션 환경에서 사용되는 것이 권장된다. 

Interactive Mode

Interactive 모드는 쉘을 얻는 것과 동일한 형태로 이해할 수 있다. 쉘을 얻으면 우리는 OS와 대화를 할 수 있다. 어떤 명령어를 입력하면 그것을 OS가 바로 보여주는 형식처럼 ksqlDB의 Interactive Mode는 쿼리를 입력하면 그 결과값을 보고, 또 쿼리를 입력할 수 있다. 즉, 대화하는 형식이 된다. 이 모드를 사용할 때는 내가 원할 때 언제든지 자유롭게 Stream / Table을 생성할 수 있다. 

Interactive 모드에서는 SQL Engine으로 전달되는 모든 명령들은 Kafka Broker의 Command Topic에 저장된다. Command Topic은 ksqlDB 클러스터의 모든 서버가 상태 기반으로 Replication을 생성할 때 사용된다. 예를 들어 ksqlDB Cli를 통해 ksqlDB Server 1에게 Stream 생성 요청이 온다면, ksqlDB Server1은 SQL Engine을 통해 이것을 실행하면서 Command Topic에 실행 정보를 저장한다. 그러면 같은 ksqlDB Cluster에 있는 ksqlDB Server들은 Command Topic에서 이 정보를 읽어와서 동일하게 복제한다. 아마도 각 Server에서 Kafka Streams Toplogy를 생성하지 않을까 싶다. 

 

Headless Mode

헤드리스 모드는 프로덕션 환경에서 주로 사용한다. 헤드리스 모드를 사용하면 REST API를 이용해서 동적으로 쿼리를 생성한다거나 하는 것들을 방지할 수 있다. 오로지 Config 파일에 저장된 쿼리를 바탕으로 쿼리를 만들고 실행하는 동작을 한다. 헤드리스 모드를 사용하려면 사용하고자 하는 Persistence Query를 생성하는 생성하고 ksqlDB Server에서 이것을 사용하도록 하면 된다. 

queries.file=/path/to/query.sql

위와 같이 ksqlDB Server Config에서 값을 수정하면 된다. 헤드리스 모드는 Interactive 모드와는 다르게 상태 기반 Replication을 위해서 Command Topic을 사용하지 않는다. 대신 내부적으로 사용하는 메타 데이터를 Kafka Broker에 Config Topic에 저장하고, 나머지 녀석들은 이 값을 바탕으로 상태 기반 Replication(아마도 Kafka Streams Topology 생성)을 진행한다.

 

출처

컨플루언트 ksqlDB 책