들어가기 전 이 글은 스키마 레지스트리를 기동할 때 사용하는 스키마 레지스트리 설정에 대해서 간략히 정리한 글입니다. 스키마 레지스트리 설정 스키마 레지스트리를 기동시키려면 필요한 설정값들이 저장된 설정 파일을 함께 전달해줘야한다. 이 때, 기본적인 설정값들에 대해서 살펴보고자 한다. 기본적으로는 아래 설정값들을 스키마 레지스트리에 전달하며 기동한다. listeners:http://0.0.0.0:8081 kafkastore.bootstrap.servers=PLAINTEXT://localhost:9092 kafkastore.topic=_schemas schema.compatibility.level=full 각 값들은 무엇을 의미할까? listeners 스키마 레지스트리가 REST API 요청을 듣기 위해 ..
스키마의 필요성 나 혼자 DB를 개발하고, DB에서 나온 데이터로 무언가를 만든다고 가정해보자. 이럴 때는 내가 정한대로 할 수 있기 때문에 스키마 변경을 아주 쉽게 할 수 있다. 그렇지만 회사에서 큰 시스템을 만들 때는 그렇게 할 수 없다. 데이터를 공급하는 사람과 데이터를 가져가는 사람이 다를 수 있고, 이런 경우에는 스키마 변경에 대해 협의를 해야한다. 회사가 커지면 커질수록 하나의 스키마에 대해서 관련된 사람이 많을 수 있고 더 많은 협의가 필요해진다. 공급하는 쪽도 마찬가지다. 공급하는 쪽에 새로운 사람이 와서 스키마에 맞지 않는 데이터가 들어간다고 가정해보자. 그러면 메세지를 읽는 쪽에서 파싱을 할 때 큰 에러가 발생해서 시스템 전체가 다운되는 문제가 발생할 수 있다. 이런 이유들 때문에 데이..
카프카 커넥트의 파티셔닝 카프카 커넥트에 올려진 커넥터는 Source 시스템에서 데이터를 가져올 때, 파티셔닝 한 후에 데이터를 가져온다. 여기서 이야기하는 파티셔닝은 카프카에서 이야기하는 파티셔닝과는 다른 개념이다. 카프카의 파티셔닝은 토픽마다 나누어진 파티션에 메세지의 키 값을 해시 알고리즘으로 구하여 이루어진다. 카프카 차원의 파티셔닝은 메세지가 토픽의 어떤 파티션으로 보내져야 하는지를 의미한다. 그렇지만 커넥터에서 이야기하는 파티셔닝은 이것과는 다른 개념이다. 커넥터의 파티셔닝은 Source System에서 처리해야 할 자원과 커넥터 인스턴스가 가지고 있는 Task에게 일을 나누어 주는 것이다. 한 가지 예를 들어서 알아보자. Source System을 MySQL로 가정하고 Table이 4개가 존..
들어가기 전 카프카 커넥트는 운영에 필요한 메타 정보를 카프카에 저장해둔다. 따라서 카프카 커넥트에서 사용하는 내부 토픽이 무엇이 있는지, 그리고 어떤 역할을 하는지 이해해야 할 필요가 있다. 카프카 커넥트 내부 토픽 카프카 커넥트에서 사용하는 카프카 내부 토픽은 총 4가지가 존재한다. 이 중에서 카프카 커넥트가 만들어서 사용하는 내부 토픽은 3가지고, 하나는 카프카 자체 내부 토픽을 사용한다. 아래에서 카프카 커넥트가 사용하는 내부 토픽 4가지를 알 수 있다 내부 토픽명 설명 connect-offsets Source Connector 별로 메세지를 전송한 offset 정보를 가지고 있음. Source Connector가 한번 전송한 메세지를 중복 전송하지 않기 위해 사용함. 기본 25개의 파티션으로 구..
카프카 커넥트의 기동 모드 connect-distributed connect-mirror-maker connect-standalone 카프카 커넥트는 세 가지 기동 모드를 제공한다. 그렇지만 실제로 사용자가 사용하는 것은 distributed 모드만을 사용한다. distributed 모드와 standalone은 어떻게 다른 것일까? The difference is in the class which is started and the configuration parameters which change how the Kafka Connect process decides where to store configurations, how to assign work, and where to store offsets a..