WebMaster

Kafka Cluster 확장 고유한 ID를 부여한 새로운 Broker를 Zookeeper Ensemble에 연결만 하면 됨 하지만, 자동으로 Partition을 새로운 Broker로 옮겨주지 않음 kafka-reassign-partitions 도구 Confluent Auto Data Balancer/Self-Balancing Cluster 기능 kafka-reassign-partitions 명령 리밸런싱을 직접 계산해서 Topic 별로 실행해야 함( 계산 실수로 인한 문제 발생 가능성 존재) Confluent ADB(Auto Data Balancer) Broker 전체에 대한 Partition 리밸런싱을 자동화(Cluster내의 전체 Broker에 대한 Partition 리밸런싱을 명령어 하나로 자동 ..

Log 파일 관리(Log Cleanup Policy) Log는 Consume 되어도 지우지 않음 많은 Consumer들이 서로 다른 시간에 Log 데이터를 Consume 할 수 있기 때문에 Broker 혹은 Topic 단위로 Cleanup 정책을 설정함 log.cleanup.policy 파라미터 delete compact delete,compact 현재 Active Segment의 Log는 cleanup 대상이 아님 Delete Cleanup Policy( Log Segment 삭제하는 정책) Log Cleaner Thread가 Segment File을 삭제 log.cleanup.policy 파라미터 delete log.retention.ms : log 보관 주기 (기본값 : 7 일) log.retent..

Apache Kafka Cluster 설치 및 구성 Confluent Platform(CP) 사용 Ubuntu 18.04 환경에서 진행 Production 환경을 가정(Zookeeper 3 대, Broker 3 대, Control Center1) 1 대 구성) Kafka Broker 1 개만 사용할 경우(개발 환경), 무료로 모든 기능 사용 가능 Broker 2개 이상의 클러스터로 구성할 경우, 30일 기한의 라이선스가 자동 생성 계속 사용이 필요할 경우 라이선스를 구매해야 함 Confluent Platform의 시스템 요구사항을 확인할 것 https://docs.confluent.io/platform/current/installation/system-requirements.html OpenJDK 혹은 ..

Broker 설치 구성 전용 서버 권장 Broker는 분리된 각각의 전용 서버에 분리하여 설치 구성하는 것을 권장 N개의 Broker가 있으면, Replication Factor(RF)는 최대 N까지 사용하여 Topic 생성 가능 Mission Critical Topic에는 Replication Factor는 보통 3 을 많이 사용 3 개의 Broker로 구성하고 하나의 Broker가 장애 상태시, RF 3인 Topic 생성 불가능 따라서, Broker는 4 개 이상 하나의 Cluster로 구성하는 것을 권장 데이터 유실 방지를 위해서, min.insync.replicas는 2 를 많이 사용 3 개의 Broker로 구성하고 1 개의 Broker가 장애 상태시, Topic에 Write는 가능 1 개의 Br..

Confluent에서 제공하는 Confluent Platform Reference Architecture) https://www.confluent.io/resources/apache-kafka-confluent-enterprise-reference-architecture/ Confluent Platform Reference Architecture - Confluent Confluent is building the foundational platform for data in motion so any organization can innovate and win in a digital-first world. www.confluent.io Confluent Platform Architecture Large Cl..

이제 프로메테우스가 애플리케이션의 /actuator/prometheus를 호출해서 메트릭을 주기적으로 수집하도록 설정해 보자. 프로메테우스 폴더에 있는 prometheus.yml 파일을 수정하자. prometheus.yml # my global config global: scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute. evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute. # scrape_timeout is set to the global default (10s). # Alert..

프로메테우스는 메트릭을 수집하고 보관하는 DB이다. 프로메테우스가 우리 애플리케이션의 메트릭을 수집하도록 연동해 보자. 여기에는 2가지 작업이 필요하다. 애플리케이션 설정: 프로메테우스가 애플리케이션의 메트릭을 가져갈 수 있도록 애플리케이션에서 프로메테우스 포맷에 맞추어 메트릭 만들기 프로메테우스 설정: 프로메테우스가 우리 애플리케이션의 메트릭을 주기적으로 수집하도록 설정 애플리케이션 설정 프로메테우스가 애플리케이션의 메트릭을 가져가려면 프로메테우스가 사용하는 포멧에 맞추어 메트릭을 만들어야 한다. 참고로 프로메테우스는 /actuator/metrics 에서 보았던 포맷(JSON)은(JSON) 이해하지 못한다. 하지만 프로메테우스 포맷에 대한 부분은 걱정할 것이 없다. 마이크로미터가 이런 부분은 모두 해결..

프로메테우스 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭을 보관하는 DB가 필요하다. 이렇게 하려면 어디선가 메트릭을 지속해서 수집하고 DB에 저장해야 한다. 프로메테우스가 바로 이런 역할을 담당한다. 그라파나 프로메테우스가 DB라고 하면, 이 DB에 있는 데이터를 불러서 사용자가 보기 편하게 보여주는 대시보드가 필요하다. 그라파나는 매우 유연하고, 데이터를 그래프로 보여주는 툴이다. 수많은 그래프를 제공하고, 프로메테우스를 포함한 다양한 데이터소스를 지원한다. 전체 구조 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다. 마이크로미터 프로메테우스 구현체는 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 생성한다. ..

마이크로미터와 액츄에이터가 기본으로 제공하는 다양한 메트릭을 확인해 보자.. JVM 메트릭 시스템 메트릭 애플리케이션 시작 메트릭 스프링 MVC 메트릭 톰캣 메트릭 데이터 소스 메트릭 로그 메트릭 기타 수 많은 메트릭이 있다. 사용자가 메트릭을 직접 정의하는 것도 가능하다. 뒤에서 예제로 만들어본다. JVM 메트릭 JVM 관련 메트릭을 제공한다. jvm.으로 시작한다. 메모리 및 버퍼 풀 세부 정보 가비지 수집 관련 통계 스레드 활용 로드 및 언로드된 클래스 수 JVM 버전 정보 JIT 컴파일 시간 시스템 메트릭 시스템 메트릭을 제공한다. system. , process. , disk.으로 시작한다. CPU 지표 파일 디스크립터 메트릭 가동 시간 메트릭 사용 가능한 디스크 공간 애플리케이션 시작 메트릭 ..

CPU, JVM, 커넥션 사용 등등 수많은 지표들을 어떻게 수집해야 할까? 개발자가 각각의 지표를 직접 수집해서 그것을 마이크로미터가 제공하는 표준 방법에 따라 등록하면 된다. 다행히도 마이크로미터는 다양한 지표 수집 기능을 이미 만들어서 제공한다. 그리고 스프링 부트 액츄에이터는 마이크로미터가 제공하는 지표 수집을 @AutoConfiguration을 통해 자동으로 등록해 준다.. 쉽게 이야기해서 스프링 부트 액츄에이터를 사용하면 수많은 메트릭(지표)을(지표) 편리하게 사용할 수 있다. 이제 기본으로 제공하는 메트릭들을 확인해 보자. 아직 모니터링 툴을 연결한 것은 아니고, 등록된 메트릭들을 확인해 보는 단계이다. metrics 엔드포인트 metrics 엔드포인트를 사용하면 기본으로 제공되는 메트릭들을 ..