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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
Apache kafka performance(latency)_benchmark_v0.3SANG WON PARK
Apache Kafka를 이용하여 이미지 데이터를 얼마나 빠르게(with low latency) 전달 가능한지 성능 테스트.
최종 목적은 AI(ML/DL) 모델의 입력으로 대량의 실시간 영상/이미지 데이터를 전달하는 메세지 큐로 사용하기 위하여, Drone/제조공정 등의 장비에서 전송된 이미지를 얼마나 빨리 AI Model로 전달 할 수 있는지 확인하기 위함.
그래서 Kafka에서 이미지를 전송하는 간단한 테스트를 진행하였고,
이 과정에서 latency를 얼마나 줄여주는지를 확인해 보았다.(HTTP 프로토콜/Socket과 비교하여)
[현재 까지 결론]
- Apache Kafka는 대량의 요청 처리를 위한 throughtput에 최적화 된 솔루션임.
- 현재는 producer의 몇가지 옵션만 조정하여 테스트한 결과이므로,
- 잠정적인 결과이지만, kafka의 latency를 향상을 위해서는 많은 시도가 필요할 것 같음.
- 즉, 단일 요청의 latency는 확실히 느리지만,
- 대량의 처리를 기준으로 평균 latency를 비교하면 평균적인 latency는 많이 낮아짐.
Test Code : https://github.com/freepsw/kafka-latency-test
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
엄청난 동시 접속 수로 고사양이 요구되는 게임 '배틀그라운드'! 속도가 중요한 게임 서비스에서 가장 필요한 고성능 서버입니다. 배틀그라운드 사례 뿐아니라 SK텔레콤도 선정하여 사용하고 있는 네이버클라우드플랫폼 베어메탈 서버에 대해 소개합니다 | Battlegrounds is a game that requires a lot of simultaneous access! High-performance servers most needed for speed-critical gaming services. In addition to the case of Battlegrounds, SK Telecom has selected and used Naver Cloud Platform Bare Metal Server.
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
엄청난 동시 접속 수로 고사양이 요구되는 게임 '배틀그라운드'! 속도가 중요한 게임 서비스에서 가장 필요한 고성능 서버입니다. 배틀그라운드 사례 뿐아니라 SK텔레콤도 선정하여 사용하고 있는 네이버클라우드플랫폼 베어메탈 서버에 대해 소개합니다 | Battlegrounds is a game that requires a lot of simultaneous access! High-performance servers most needed for speed-critical gaming services. In addition to the case of Battlegrounds, SK Telecom has selected and used Naver Cloud Platform Bare Metal Server.
고승범(peter.ko) / kakao corp.(인프라2팀)
---
카카오에서는 빅데이터 분석, 처리부터 모든 개발 플랫폼을 이어주는 솔루션으로 급부상한 카프카(kafka)를 전사 공용 서비스로 운영하고 있습니다. 전사 공용 카프카를 직접 운영하면서 경험한 트러블슈팅과 운영 노하우 등을 공유하고자 합니다. 특히 카프카를 처음 접하시는 분들이나 이미 사용 중이신 분들이 많이 궁금해하는 프로듀서와 컨슈머 사용 시의 주의점 등에 대해서도 설명합니다.
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
The document describes the process of setting up OpenStack Swift object storage. It includes installing and configuring Swift packages on both storage and proxy nodes, generating ring files to map objects to storage devices, and registering the Swift service with Keystone for authentication. Key steps are installing Swift packages, adding storage devices to the ring, distributing ring files, and configuring the proxy server and authentication filter.
This document describes 3 scenarios involving SDN and OpenFlow. In the first scenario, a client sends an ARP request packet to find the MAC address of a DNS server. In the second scenario, the ARP table is updated with the MAC address of the DNS server. In the third scenario, the client's ARP request is sent to the MAC address of DNS server 1.
The document discusses testing TR-069 on various platforms including installing Fedora on ARM hardware and resolving bundle dependency issues when running TR-069 on Karaf 3.0.1. It also defines managed object models for TR-069 including device info, time, and periodic statistics parameters. Future plans include testing TR-069 on Fedora installed on ARM hardware after fixing bundle errors.
2. 목 차
• NGINX 란?
• NGINX vs APACHE
• NGINX 특징
• NGINX 사용 사례
• LB(Load Balancing) 란?
• LB(Load Balancing) 장점
• LB(Load Balancing) 알고리즘
• 테스트 구성도
• NGINX 설치 및 실행
• LB(Load Balancing) 설정
• VM 간의 테스트
2
3. NGINX 란?
• 오픈 소스 기반의 reverse proxy 서버로 HTTP 뿐만 아니라 HTTPS, SMTP, POP3,
IMAP 프로토콜을 지원한다.
• 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하고, 적은 수의 thread로 많
은 클라이언트 처리할 수 있다.
• 비동기(ASYNC) 이벤트 기반(ioctl, send, recv, epoll)
• 더 적은 자원으로 더 빠르게 데이터를 서비스 한다.
3
4. NGINX vs APARCHE
• NGINX
– 하나의 프로세스(또는 쓰레드)에서 이벤트 처리
• 메모리를 적게 할당
• 비 동기 처리(Block이 되더라도 대기하지 않음)
– 백엔드와 ajp 통신이 어렵고, 모듈 개발이 어려우며, Aparche Http 서버처럼 다양한 모
듈이 없다. (단점)
– 윈도우용 Nginx는 native win32 api를 이용하며, select()연결만 사용하기 때문에 향상된
성능을 기대하기는 어렵고, 이외의 몇몇 제약 때문에 아직 베타버전으로 간주된다.
• APARCHE
– 요청 하나당 프로세스(또는 쓰레드)가 처리하는 구조
• 프로세스가 Block 되는 경우 처리 완료될 때까지 대기
• 프로세스(또는 쓰레드) 메모리를 많이 할당
– 다양한 다중 처리 모듈
4
5. NGINX 특징
• HTTP 프록시와 웹 서버 기능
– 정적 파일과 인덱스 파일 표현, 자동 인덱싱 기능.
– 캐싱을 통한 리버스 프록시
– 로드 밸런싱
– 고장 진단
– SSL 지원
– 캐싱을 통한 FastCGI 지원
– Name-, IP-기반 가상서버
– FLV 스트리밍
– MP4 스트리밍 모듈을 이용한 MP4 스트리밍
– 웹페이지 접근 인증
– gzip 압축
– 10000개의 동시 접속을 처리할 수 있는 능력
– URL 다시쓰기 (URL rewriting)
– 맞춤 로깅
– 서버 사이드 기능 포함
– WebDAV
• 메일 프록시 기능
– SMTP, POP3, IMAP 프록시
– STARTTLS 지원
– SSL 지원
5
7. LB(Load Balancing) 란?
7
• 부하 분산
• 처리량을 최대화, 응답 시간을 최소화, 임의의 단일 리소스의 과부하 방지, 자원 사
용을 최적화하는 것을 목표로 한다.
• 안정성과 가용성 증가
• 멀티 레이어 스위치, DNS 서버, 서버 팜, NNPT(Network News Transfer
Protocol), 고 대역폭 파일전송 프로토콜 등에 사용된다.
Load Balancing
질의 요청
Client
Server
Server
Server
Client
Client
8. LB(Load Balancing) 장점
8
• 각 노드의 성능과 전체 시스템 성능을 향상시킨다.
– 저렴한 비용으로 다수의 서버를 증설하여 경제적으로 비용절감
– 확장성
– 높은 생산량과 신뢰성
• 작업 유휴 시간을 감소시킨다.
– 응답시간 최소화
– 자원 사용률 최대화
9. Load Balancing 알고리즘 종류
• Round Robin (순차방식)
• Least Connection (최소접속방식)
• Weighted Least Connection (가중치 최소접속방식)
• Fastest Least Connections (응답시간방식)
• Adaptive (최소대기방식)
• Fixed (고정방식)
9
10. • 각 서버 운영체제
– Ubuntu 14.04
• Dig Client (1대)
• LB(Load Balancing) 서버 (1대)
– Nginx (192.168.45.128:5000)
• DNS Server (3대)
– pDNS 서버
• 192.168.45.134:53
• 192.168.45.135:53
• 192.168.45.137:53
테스트 구성도
10
LB(Nginx)
http://192.168.45.128:5000
Dig 요청
DNS Server
DNS Server
DNS Server
Client
http://192.168.45.134:53
http://192.168.45.135:53
http://192.168.45.137:53
11. NGINX 설치 및 실행
• NGINX 설치
– $sudo apt-get update
– $sudo apt-get install nginx
• nginx 설치
• nginx 설치가 완료되면 자동으로 시작된다.
11
12. NGINX 설치 및 실행
• NGINX 실행
– $sudo service nginx start or $sudo /etc/init.d/nginx start $sudo apt-get install nginx
• nginx 실행
– $sudo service nginx stop or $sudo /etc/init.d/nginx stop
• nginx 정지
– $sudo service nginx restart or $sudo /etc/init.d/nginx restart
• nginx 재시작
– $sudo service nginx reload or $sudo /etc/init.d/nginx reload
• nginx 리로드
12
13. LB(Load Balancing) 설정 - 1
• nginx.conf 설정
– $cd /etc/nginx
• nginx 디렉토리로 이동
– $sudo vi nginx.conf
• LB 설정을 위하여 nginx.conf 파일 편집
13
14. LB(Load Balancing) 설정 - 2
① 로그 포맷
– 일반적인 Access 로그
• $body_bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수
• $bytes_sent : 응답헤더를 세지 않고 클라이언트로 보낸 바이트 수
• $connection : 연결된 일련 번호
• $connection_requests : 요청에 의해 연결된 현재 번호
• $msec : 로그에 milliseconds 시간을 남긴다.
• $request_length : 요청 길이
• $request_time : 요청 시간
• $status : 응답 상태
• $time_iso8601 : ISO 8601 표준 형식의 현지 시간
• $time_local : 공통 로그 형식의 현지 시간
• $remote_addr : 방문자의 IP_Address가 표시된다.
– nginx Load Balance Log_format 관련
• $upstream_addr : 로그 밸런싱에 응답하는 웹 서버
• $upstream_reponse_time : 로드 밸런싱 되는 웹 서버의 응답 시간
• $upstream_status : 서버 응답 코드
② upstream 설정
– 부하분산, 속도 개선과 같은 역할을 한다.
– 여러 서버가 순차적으로 일을 할 경우 서비스를 처리하는 서버를 의미
– 형태
upstream 이름 {
[ip_hash;]
server host 주소: 포트 [옵션];
.....
}
– 옵션
• ip_hash : 같은 방문자로부터 도착한 요청은 항상 같은 업스트림 서버가 처리 할 수 있게 한다.
• weight=n : 업스트림 서버의 비중을 나타낸다. 이 값을 2로 설정하면 그렇지 않은 서버에 비해 두배 더 자주 선택된다.
• max_fails=n : n으로 지정한 횟수만큼 실패가 일어나면 서버가 죽은 것으로 간주한다.
• fail_timeout=n : max_fails가 지정된 상태에서 이 값이 설정만큼 응답하지 않으면 죽은 것으로 간주한다.
• down : 해당 서버를 사용하지 않게 지정한다. ip_hash; 지시어가 설정된 상태에서만 유효하다.
• backup : 모든 서버가 동작하지 않을 때 backup으로 표시된 서버가 사용되고 그 전까지는 사용되지 않는다.
– 예제
• ip_hash를 통해 같은 같은 방문자일 경우 같은 ip서버를 호출한다.
• 서버 192.168.0.100:9000은 남들보다 2배 더 많이 호출된다.
• 서버 192.168.0.102:9000은 30초간의 timeout시간이 있으며 3번 실패 시 더이상 호출을 하지 않는다.
③ server (호스트)설정
– listen : 호스트 포트를 설정
– 서버 이름 설정(server_name)
– 초기 페이지 설정(index)
– location : 웹사이트의 특정 위치에 적용할 설정 그룹을 정의한다.
14
17. VM 간의 테스트 -3
17
• LB 서버 (nginx) Log 확인
• pDNS 서버 Log 확인
Editor's Notes
#4: Nginx 란?
러시아 개발자 (lgor Sysoev)가 혼자서 만든 프로젝트이지만, 메모리와 성능이 좋아 입소문으로 많이 알려짐. 2002년부터 시작되어 최근 사용하는 곳이 급속히 증가.
오픈 소스기반의 리버스 프록시 서버로 HTTP뿐만 아니라, HTTPS, SMTP, POP3, IMAP 프로토콜을 지원한다. 웹 서버 소프트웨어로, 가벼움과 높은 성능을 목표로 하고, 적은 수의 쓰레드로도 많은 클라이언트를 처리할 수 있다. 아파치와 대표적으로 다른 점은 쓰레드 기반이 아닌 이벤트 기반이라는 것이다.
여기서 말하는 이벤트 기반이란 Event Driven Architecture(EDA)라고 하는데 아파치같은경우는 하나의 쓰레드에 하나의 클라이언트를 처리한다면 정보를 읽거나 쓴 후 가공해서 클라이언트에 전달할 때까지 쓰레드의 대기시간이 많고 클라이언트개수만큼 스레드가 생성되어야 한다.
하지만 EDA방식에서는 Event(요청이나 응답결과를 모두 생성했을 때)가 발생되었을때 이벤트를 처리하게 해서 더 적은 쓰레드로 CPU가 놀지 않고 일하게 할수 있다 라는 것이다. 또한 이러한 구조는 서버에 많은 부하가 생길 경우의 성능을 예측하기가 쉽다.
#6: 성능
성능은 접속자가 어느 정도 이상 되고 다양한 사이트가 운영되면 차이가 많이 난다.
동접자가 많을수록 체감할 수 있고, 물론 설정을 시스템에 맞게 잘 해야 효과가 극대화 된다. 서버가 리눅스 일 경우 그리고 멀티코어일 경우 엔진엑스와 아파치의 차이가 많이 난다.
한국에서 엔진엑스를 많이 안쓰는 이유는 아직 정형화된 한글 문서들이 없기 때문이다. 호스팅 서비스의 경우 rewrite 관련 부분을 사용하는 호스팅 사용자가 많은 경우 상당히 귀찮아 질 수 있다.
보통 접속자가 많은 사이트 (토렌트, 유머 등등) 인 경우 엔진엑스를 많이 쓰고 있는 추세이다.
#7: 특히 nginx는 http://wordpress.com 에 적용되면서 많이 유명해졌다. 현재 Nginx를 쓰는 유명한 곳으로는 페이스북, Netflix, WordPress.com, 깃헙 (Github), 사운드클라우드 (Soundcloud), Zynga, Sourceforge 등이 있으며, 한국에서는 네이버 첫페이지, 백과사전, 일베저장소, 엔하위키 미러,카카오톡 공지사항 서버,XpressEngine 공식 홈페이지등이 있다.
#10: Load Balancing 알고리즘 종류
Round Robin (순차방식)- 사용자의 요구를 차례대로 각 서버에 균등하게 분배하는 방식으로 서버 커넥션 수나 응답시간에 상관없이 그룹내의 모든 서버를 동일하게 처리하여 일반적인 구성에 있어서 다른 알고리즘에 비해서 가장 빠르다는 장점을 가진다.
Least Connection (최소접속방식)- 오픈 커넥션이 가장 적은 서버로 사용자 요구를 연결하는 방식으로 모든 서버가 균등한 트래픽을 유지하기 위해서 처리 속도가 빠른 서버가 더 많은 접속을 받게 된다. 최소접속 알고리즘은 서버들의 성능이 비슷하게 구성되었을 경우에 가장 효과적인 트래픽 분산이 가능하다.
Weighted Least Connection (가중치 최소접속방식)- 최소접속 알고리즘에 서버의 성능 가중치를 추가한 것으로, 요구가 동일한 경우 가중치가 높은 서버에서 더 많은 요구를 받게 설계되어 있다.
Fastest Least Connections (응답시간방식)- (Fastest Response Time), 가장 빨리 응답하는 서버에 이용자 요구를 연결하는 방법, 응답시간은 각 서버가 패킷 형태의 요구를 송수신하는데 걸리는 시간을 측정한 것이다.
Adaptive (최소대기방식)- Open 또는 Pending 커넥션을 적게 가지고 잇는 서버로 네트웍 커넥션 방향을 지정한다. Pending 커넥션은 Full TCP Handshake를 완성하지 않은 것으로, 이것은 초당 클라이언트 Thread의 수가 증가할 때 더욱 잘 수행된다.
Fixed (고정방식)- 어떤 서버가 커넥션 요청을 받는지를 결정하기 위해 각 유입요청의 소스 IP 주소를 사용한다.- 여러 종류의 주소로부터 많은 양의 요구가 있을 경우 더 잘 작동한다.- 동일한 게이트웨이를 통하여 들어오는 많은 요구보다 여러 종류의 혼합된 소스 IP 주소의 요구일 경우 더 잘 수행한다.