• 카테고리

    질문 & 답변

  • 세부 분야

    데이터 엔지니어링

  • 해결 여부

    해결됨

실무에서 카프카 환경 구축

24.03.26 21:26 작성 24.03.26 21:27 수정 조회수 117

0

안녕하세요,

문득 실무에서 카프카 클러스터 환경 구축에 대해 궁금한 점이 생겼습니다.

 

강사님께서 진행하신 방법은 confluent의 카프카 프로젝트를 하나의 노드에 직접 다운받아서 주키퍼, 브로커 기동도 하고 ksql-cli 실행도 하신 것 같은데요,

실무 환경에서는 클러스터 구축 노드가 주키퍼 클러스터를 이루는 노드들 및 브로커 등 여러 가지 일텐데요, 이런 경우는 어떻게 진행하는게 일반적일까요?

 

강의에서 사용한 동일한 플랫폼용 카프카 프로젝트를 ansible 등으로 설치 지원이 되는지 궁금합니다.

 

추가로 주키퍼나 브로커 노드들은 그 기능만 수행하고 ksql-cli나 schema-registry 혹은 connect 용으로 노드를 별도로 두고 사용하는 것이 일반적인지 궁금합니다.

 

 

course-thumbnail

카프카 완벽 가이드 - ksqlDB

Kafka와 ksqlDB 환경 설정 및 기동하기

강의실 바로가기

답변 2

·

답변을 작성해보세요.

1

권 철민님의 프로필

권 철민

지식공유자

2024.03.27

안녕하십니까,

  1. 먼저 주키퍼 클러스터의 경우는 카프카 클러스터와 별도 노드로 구성하는 것이 일반적인 원칙입니다. 여기에는 이유가 있습니다. 주키퍼의 로그 기록이 카프카의 Heavy I/O에 영향을 받아서 늦어지면 안되기 때문입니다(이 경우 주키퍼가 느려져서 전체 카프카 클러스터가 성능 영향을 받을 수 있습니다).

일반적으로 대규모의 카프카 클러스터를 구성하는 사이트의 경우는 주키퍼 클러스터를 별도로 분리합니다. 그런데 주키퍼는 가벼운 프로세스입니다. 별도로 노드를 빼서 관리해야 할 정도로 평소가 부하가 많이 들지 않습니다. 별도 노드들은 비용이 더 든다는 현실적인 문제를 고려하지 않을 수 없습니다.

때문에 예산이 여유가 있거나, 고가용성에 대한 운영 정책이 매우 중요한 사이트의 경우가 아니라면 주키퍼 클러스터를 카프카 클러스터와 동일한 노드에 놓는 것도 나쁘지 않은 방법입니다. 다만 Confluent 운영 가이드에는 주키퍼 클러스터는 위에 언급한 사항때문에 반드시 별도 노드로 클러스터 구성을 권장하고 있습니다.

 

  1. Confluent에서는 Connect나 KSQLDB는 Kafka 서버와 별도의 노드로 분리를 권장합니다. 이유는 Connect/KSQLDB의 Worker JVM Process 나 Producer나 Consumer들이 Kafka 서버에 영향을 미치는 경우를 최소화하기 위함입니다.

하지만 이 역시 현실적인 비용의 문제에 대해서 고민해 보지 않을 수 없습니다. 다만 제가 알아본 사이트의 경우는 Connect를 별도의 노드의 경우로 가져 가는 경우가 더 많은 것 같습니다.

그리고 Connect와 KSQLDB를 함께 활용하는 경우는 이 두개를 분리하지 않고 하나의 노드에 두는 경우가 더 많은 것 같습니다.

  1. 해보진 않았지만, 강의에서 사용한 동일한 플랫폼용 카프카 프로젝트를 ansible 등으로 설치 지원이 안될 이유는 없어 보입니다.

요약하자면, 주키퍼, 카프카, Connect, KSQLDB 별로 별도의 노드로 분리하는 것이 아키텍처 상으로는 Best Practice이지만, 현실적인 비용을 고려하지 않을 수 없으며, 부하및 사용량과 비용/성능/가용성 측면을 고려하여 특정 컴포넌트들은 Kafka와 동일한 노드에 위치하거나 별도의 노드에 함께 위치 할 수 있습니다.

 

감사합니다.

 

0

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.03.26

안녕하세요, 인프런 AI 인턴입니다.

이무님의 질문에 대해 제공할 수 있는 정보를 살펴보았습니다. 실무에서 카프카 클러스터 환경 구축에 관련된 귀하의 질문은 매우 포괄적인 범위를 다루고 있으며, 이에 대한 답변 또한 다양할 수 있습니다. 실무 환경에서의 카프카 클러스터 구축 방법에는 여러 가지 접근법이 있으며, 사용하는 도구나 방식은 조직의 요구 사항, 인프라, 보안 정책, 팀의 기술적 선호도 등 다양한 요인에 따라 달라질 수 있습니다.

다만, 궁금증을 조금이나마 해소해 드리고자, 관련된 질문과 응답을 찾아본 결과, AWS에서 카프카 환경 구축에 대한 전반적인 이해도를 높일 수 있는 유익한 답변을 찾았습니다.

AWS 에서 confluent kafka 와 apache kafka 차이가 궁금 합니다.에 대한 답변에서는 Confluent Kafka와 Apache Kafka의 사용, 클라우드 상에서의 카프카 구축(Confluent Cloud 및 자체 관리 방식)에 대한 개요와 함께, 현업에서의 사용 사례 및 각각의 플랫폼을 AWS 상에서 구축할 때 고려해야 할 요소들에 대해 설명하고 있습니다. 이는 실무 환경에서 카프카 클러스터를 구축하고 관리하는 데 있어 유용한 정보를 제공할 수 있습니다.

실제로 실무 환경에서는 카프카 클러스터 노드, 주키퍼 클러스터를 이루는 방법, 관리 도구의 선택, 추가 컴포넌트(예: Kafka Connect, Schema Registry)의 구축 및 관리 방법 등 다양한 요소를 고려해야 하므로, 이러한 정보는 여러분의 궁금증을 다소 해결하는 데 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

이 글과 비슷한 Q&A