Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
[NDC18] 야생의 땅 듀랑고의 데이터 엔지니어링 이야기: 로그 시스템 구축 경험 공유 (2부)Hyojun Jeon
NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
20. Zookeeper #1
Redis #1
Redis #2
Zookeeper
Current Redis: Redis #1
Server #1
Server #2
Server #3
User
or
Event
21. Zookeeper #2
Redis #1
Redis #2
Zookeeper
Current Redis: Redis #2
Server #1
Server #2
Server #3
Change Zookeeper value User
or
Event
22. Zookeeper #3
Redis #1
Redis #2
Zookeeper
Current Redis: Redis #2
Server #1
Server #2
Server #3
Event : Zookeeper send
Current Redis is changed
User
or
Event
23. Zookeeper #4
Redis #1
Redis #2
Zookeeper
Current Redis: Redis #2
Server #1
Server #2
Server #3
Zookeeper 로 부터읽어감
User
or
Event
24. Spring Config #1
Redis #1
Redis #2
Spring Config
Current Redis: Redis #1
Server #1
Server #2
Server #3
User
25. Spring Config #2
Redis #1
Redis #2
Spring Config
Current Redis: Redis #2
Server #1
Server #2
Server #3
User
Change Spring Config value
26. Spring Config #3
Redis #1
Redis #2
Spring Config
Current Redis: Redis #2
Server #1
Server #2
Server #3
User
Event(User Send)
Current Redis is changed
27. Spring Config #4
Redis #1
Redis #2
Spring Config
Current Redis: Redis #2
Server #1
Server #2
Server #3
User
Event(User Send)
Current Redis is changed
30. DNS or VIP #1
Redis #1
Redis #2
Server #1
Server #2
Server #3
Connect to :
account-service-redis.service.net.
account-service-redis.service.net
31. DNS or VIP #2
Redis #2
Server #1
Server #2
Server #3
Connect to :
account-service-redis.service.net. Redis #1 장애
32. DNS or VIP #3
Redis #2
Server #1
Server #2
Server #3
Connect to :
account-service-redis.service.net.
DNS나 VIP를 Redis #2가
account-service-redis.service.net 을 가지도록 전환
account-service-redis.service.net
33. DNS or VIP #4
Redis #2
Server #1
Server #2
Server #3
Connect to :
account-service-redis.service.net.
클라이언트 측면에서 바뀌는 것이 하나도 없음.
account-service-redis.service.net
35. Monitoring Factors
1. 메모리 RSS(Resident set size) 가 used memory 보다
중요.
2. CPU 사용률도 중요함.
3. Swap 이 생기면 안됨.
36. Current Connection 수의 변화
1. 계속 많은 수가 Connection 을 맺고 끊으면 성능에 큰
영향을 미침(한번 맺고, 계속 재활용해야함)
2. 반대로, CPU 사용량이 높거나 해서 timeout으로
컨넥션이 자주 바뀌는 경우도 발생
a. 2번으로 인해서 1번이 초래해서 성능이 더
안좋아지는 경우도 자주 발생
37. CPU 사용률이 높다면(1)
1. 정말 트래픽이 많은 경우
a. CPU에 영향을 받으므로 더 빠른 CPU를 쓰는 것도
방법
2. 특정 key 연산등으로 hot key가 발생하는 경우
a. hot key가 성능을 떨어뜨리는 것이 아니라,
과도하게 해당 키의 서버에 과도하게 트래픽이
몰리게 되는 경우
38. CPU 사용률이 높다면(2)
1. Monitor 명령을 사용하여 특정키의 패턴이 많은지
샘플링
2. CPU 사용량이 너무 높으면 도리어 장애를 일으키는
요인이 되기도 함.