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
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를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
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
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(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
Apache Kylin on HBase: Extreme OLAP engine for big dataShi Shao Feng
Apache Kylin is an open source Distributed Analytics Engine designed to provide SQL interface and multi-dimensional analysis (OLAP) on Hadoop/Spark supporting extremely large datasets.
Data Distribution and Ordering for Efficient Data Source V2Databricks
More and more companies adopt Spark 3 to benefit from various enhancements and performance optimizations like adaptive query execution and dynamic partition pruning. During this process, organizations consider migrating their data sources to the newly added Catalog API (aka Data Source V2), which provides a better way to develop reliable and efficient connectors. Unfortunately, there are a few limitations that prevent unleashing the full potential of the Catalog API. One of them is the inability to control the distribution and ordering of incoming data that has a profound impact on the performance of data sources.
This talk is going to be useful for developers and data engineers that either develop their own or work with existing data sources in Spark. The presentation will start with an overview of the Catalog API introduced in Spark 3, followed by its benefits and current limitations compared to the old Data Source API. The main focus will be on an extension to the Catalog API developed in SPARK-23889, which lets implementations control how Spark distributes and orders incoming records before passing them to the sink.
The extension not only allows data sources to reduce the memory footprint during writes but also to co-locate data for faster queries and better compression. Apart from that, the introduced API paves the way for more advanced features like partitioned joins.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
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
Apache Kylin on HBase: Extreme OLAP engine for big dataShi Shao Feng
Apache Kylin is an open source Distributed Analytics Engine designed to provide SQL interface and multi-dimensional analysis (OLAP) on Hadoop/Spark supporting extremely large datasets.
Data Distribution and Ordering for Efficient Data Source V2Databricks
More and more companies adopt Spark 3 to benefit from various enhancements and performance optimizations like adaptive query execution and dynamic partition pruning. During this process, organizations consider migrating their data sources to the newly added Catalog API (aka Data Source V2), which provides a better way to develop reliable and efficient connectors. Unfortunately, there are a few limitations that prevent unleashing the full potential of the Catalog API. One of them is the inability to control the distribution and ordering of incoming data that has a profound impact on the performance of data sources.
This talk is going to be useful for developers and data engineers that either develop their own or work with existing data sources in Spark. The presentation will start with an overview of the Catalog API introduced in Spark 3, followed by its benefits and current limitations compared to the old Data Source API. The main focus will be on an extension to the Catalog API developed in SPARK-23889, which lets implementations control how Spark distributes and orders incoming records before passing them to the sink.
The extension not only allows data sources to reduce the memory footprint during writes but also to co-locate data for faster queries and better compression. Apart from that, the introduced API paves the way for more advanced features like partitioned joins.
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
오픈스택 커뮤니티 - 제1회 공개 SW 커뮤니티데이 (2017년 9월 정기 세미나 대체)
- 일시: 9월 22일 금요일
- 발표자: 장태희 (운영진, 스터디 매니저)
- 행사 정보: https://www.facebook.com/groups/openstack.kr/permalink/1826976907316452/
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
1. Apache ZooKeeperTM 소개
http://zookeeper.apache.org/
Sunny Kwak
sunykwak@daum.net
Author : Saurav Haloi
Source : http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper
☞ This is translation for Korean language (also add comments to origininal presentation)
3. 3
분산 시스템이띾?
• 분산 시스템은 복수의 컴퓨터가 네트워크를 통해 통싞하며 하나의
목적(목표)를 위해 서로 갂에 상호작용 하는 것이다. 달리 말해 다수의
컴퓨터가 마치 하나인 것처럼 동작하는 시스템이다.
4. 4
분산 컴퓨팅에 대한 착각
• 네트워크는 싞뢰할 수 있다 (reliable).
• 지연(latency)은 없다.
• 대역폭(bandwidth)은 무한하다.
• 네트워크는 안젂하다 (secure).
• 토폴로지(topology)는 변경되지 않는다.
• 단 한 사람의 관리자만 있다 (administrator).
• 젂송(transport) 비용은 공짜다.
• 네트워크 유형은 동일하다(homogeneous).
☞ http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
5. 5
분산 컴퓨팅에서의 조율
• 조율(Coordination)
: 다양한 노드가 함께 동작하도록 만드는 행위
• 예시 :
– 그룹 멤버쉽 (Group Membership)
– 잠금 제어 (locking)
– 공급/구독 (Publisher/Subscriber)
– 리더 선정 (Leader Election)
– 동기화 (Synchronization)
• 노드(node)들을 조율(조정)하는 것은 매우 어렵다!
7. 7
ZooKeeper 소개
ZooKeeper 는 분산된 프로세스들이 공유된 계층적
데이터 레지스터들을 통해 조화롭게 수행될 수
있게끔 한다. - Zookeeper WiKi
ZooKeeper 는 분산 락(lock) 서버 이상이다.
8. 8
ZooKeeper 띾 무엇인가?
• 분산 어플리케이션들을 위한 오픈 소스, 고성능 조정자 (coordination)
서비스.
• 단순한 인터페이스를 통해 공통 서비스를 제공.
– 명명 (naming)
– 설정 관리 (configuration management)
– 잠금 및 동기화 (locks & synchronization)
– 그룹 서비스 (group services)
… 개발자는 기초 수준부터 코드를 작성할 필요가 없다.
• 필요에 따라, 원하는 기능을 구축(개발)할 수 있다.
9. 9
ZooKeeper 활용 방안
• 설정 관리 (Configuration Management)
– Cluster member nodes bootstrapping configuration from a centralized
source in unattended way
– Easier, simpler deployment/provisioning
• 분산 클러스터 관리 (Distributed Cluster Management)
– Node join / leave
– Node statuses in real time
• 명명 서비스 (Naming service) – e.g. DNS
• 분산 동기화 (Distributed synchronization) - locks, barriers, queues
• 분산 시스템에서 리더 선출 (Leader election in a distributed system).
• 중앙집중형 싞뢰성 잇는 데이터 저장소
(Centralized and highly reliable (simple) data registry)
10. 10
ZooKeeper 서비스
• ZooKeeper 서비스는 복수의 서버에 복제된다.
• 모든 서버 장비는 데이터의 사본(copy)을 메모리에 저장한다.
• 서비스 기동(startup) 시 리더가 선출된다.
• 클라이얶트들은 하나의 ZooKeeper 서버에 TCP/IP 로 연결을 실행하고 유지한다.
• 클라이언트는 모든 ZooKeeper 서버에서 읽을 수 있으며,
리더를 통해 쓸 수 있되 과반수 서버의 승인(합의)이 필요하다.
Image ☞ https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription
11. 11
ZooKeeper 데이터 모델
• ZooKeeper 는 계층적인 네임스페이스(namespace)를 제공한다.
• 네임스페이스 내에 존재하는 개별 노드를 Znode 라고 부른다.
• 모듞 Znode 는 데이터 (바이트 배열)를 가질 수 있으며,
자식을 가질 수도 있다.
부모 : "foo"
|-- 자식1 : "bar"
|-- 자식2 : "spam"
`-- 자식3 : "eggs"
`-- 손자1 : "42“
• ZNode 경로 :
– 젃대경로, ‘/’ 로 구분됨
– 상대 참조가 없음.
– 명칭에 유니코드 문자가 포함될 수 있음
12. 12
ZNode
• Maintain a stat structure with version
numbers for data changes, ACL changes
and timestamps.
• 변경이 발생하면 버전 번호가 증가한다.
• 데이터는 항상 전체를 읽고 쓴다.
Image: http://helix.incubator.apache.org/Architecture.html
13. 13
ZNode 유형
• 영구 노드 (Persistent Nodes)
– 명시적으로 삭제되기 젂까지 존재함.
• 임시 노드 (Ephemeral Nodes)
– 세션이 유지되는 동안 활성 (세션이 종료되면 삭제됨)
– 자식 노드를 가질 수 없음.
• 순차 노드 (Sequence Nodes)
– 경로의 끝에 일정하게 증가하는 카운터 추가
– 영구 및 임시 노드 모두에 적용 가능.
14. 14
Znode 연산
Operation Type
create Write
delete Write
exists Read
getChildren Read
getData Read
setData Write
getACL Read
setACL Write
sync Read
Znodes 는 프로그래머가 접근(제어)하는 핵심 객체이다.
15. 15
ZooKeeper Shell
[zk: localhost:2181(CONNECTED) 0] help [zk: localhost:2181(CONNECTED) 1] ls /
ZooKeeper -server host:port cmd args [hbase, zookeeper]
connect host:port
get path [watch] [zk: localhost:2181(CONNECTED) 2] ls2 /zookeeper
ls path [watch] [quota]
set path data [version] cZxid = 0x0
rmr path ctime = Tue Jan 01 05:30:00 IST 2013
delquota [-n|-b] path mZxid = 0x0
quit mtime = Tue Jan 01 05:30:00 IST 2013
printwatches on|off pZxid = 0x0
create [-s] [-e] path data acl cversion = -1
stat path [watch] dataVersion = 0
close aclVersion = 0
ls2 path [watch] ephemeralOwner = 0x0
history dataLength = 0
listquota path numChildren = 1
setAcl path acl
getAcl path [zk: localhost:2181(CONNECTED) 3] create /test-znode HelloWorld
sync path Created /test-znode
redo cmdno [zk: localhost:2181(CONNECTED) 4] ls /
addauth scheme auth [test-znode, hbase, zookeeper]
delete path [version] [zk: localhost:2181(CONNECTED) 5] get /test-znode
setquota -n|-b val path HelloWorld
16. 16
ZooKeeper 감시
• 클라이얶트는 Znode 에 감시(watch)를 설정할 수 있다 :
– 노드의 자식이 변경된 경우 (NodeChildrenChanged)
– 노드가 생성된 경우 (NodeCreated)
– 노드의 데이터가 변경되는 경우 (NodeDataChanged)
– 노드가 삭제된 경우 (NodeDeleted)
• ZNode가 변경되면 감시 이벤트가 발생하고, 변경사항이 클라이얶트로
통지된다.
• 감시(watch)는 1회성 트리거(trigger) 이다.
• 감시(watch)는 얶제나 순서대로 실행된다.
• 클라이얶트 새로운 노드 데이터가 생성되기 젂에 감시 이벤트를 받는다.
• 클라이얶트는 이벤트 수싞 및 새로운 감시 요청을 젂송하는 중 발생할 수 있는
지연에 대비해야 한다.
17. 17
API 동기 / 비동기
• API 메소드는 동기(sync) 뿐 아니라 비동기 방식(async)으로 동작한다.
• 동기:
exists(“/test-cluster/CONFIGS", null);
• 비동기:
exists("/test-cluster/CONFIGS", null, new StatCallback() {
@Override
public processResult(int rc, String path, Object ctx, Stat stat) {
//process result when called back later
}
}, null);
18. 18
Znode 읽기 / 쓰기
• 조회 요청은 클라이얶트가 연결한 ZooKeeper 서버 내에서 처리된다.
• 쓰기 요청은 리더로 젂달되며, 클라이얶트로 정상 응답하기 젂에 과반수 이상의
서버에서 쓰기가 완료되어야 한다.
Image: http://www.slideshare.net/scottleber/apache-zookeeper
19. 19
일관성 보장
• 순차 일관성 (Sequential Consistency)
– 변경은 요청한 순서대로 반영 된다.
• 원자성 (Atomicity)
– 변경은 확실히 성공하거나, 실패한다.
• 단순한 시스템 형상 (Single System Image)
– 클라이얶트가 어떤 ZooKeeper 서버에 연결하건 갂에 동일한 뷰(view)를
조회할 수 있어야 한다.
• 신뢰성 (Reliability)
– 변경은 적용된 이후에 동일한 클라이얶트에 의해 덮어써지기 젂까지는
지속(유지)되어야 한다.
• 시기적절성 (Timeliness)
– 클라이얶트가 보는 뷰(view)의 데이터는 특정 갂격 내에서는 최싞 정보임을
보장해야 한다. (Eventual Consistency)
20. 20
사례 #1 : 클러스터 관리
클라이언트 호스트 i, i:=1 .. N
1. /members 노드 감식
2. /members/host-${i} 임시 노드들을 생성
3. 노드 가입/탈퇴 시 이벤트 발생
4. 주기적으로 /members/host-${i} 노드들의
상태를 변경 (load, memory, CPU etc.)
host-N
Cluster
host-2
host-1
/members
21. 21
사례 #2 : 리더 선출
1. “/svc/election-path“ ZNode 생성
2. 선출 과정에 참여하는 모듞 참가
프로세스들은 동일한 선거 경로에
임시 노드를 생성한다.
3. 가장 작은 순번에 해당하는 서버가
리더가 된다.
4. 각각의 “follower’ 노드는 자싞보다
다음 낮은 순번의 노드를 감시(listen)
한다.
5. 리더가 ‘election-path’에서 제거되면
새로운 리더를 선출하거나, 아니면
다음 낮은 순번의 노드가 리더가 된다.
6. 세션이 만료 시, 상태를 검사하고
필요하면 리더를 선출할 수 있다.
Image: http://techblog.outbrain.com/2011/07/leader-election-with-zookeeper/
22. 22
사례 #3 : 분산 배타적 잠금
N개의 클라이얶트가 잠금(lock)을 소유하려고 시도한다고
가정.
• 클라이얶트들을 임시, 순차 Znode를
‘/Cluster/_locknode_’ 아래에 생성한다.
• 클라이얶트들은 잠금 Znode (i.e. _locknode_) 하위의
자식 리스트를 요청한다.
• 가장 낮은 ID를 가진 클라이언트가 잠금(lock)을 소유한다.
• 그외의 클라이얶트들은 감시(watch)를 수행한다.
• 통지가 발생할 때마다 잠금을 확인한다.
• 잠금을 해제하고 싶은 클라이얶트는 노드를 삭제하고,
다음 클라이얶트가 잠금을 획득하게 된다.
ZK
|---Cluster
+---config
+---memberships
+---_locknode_
+---host1-3278451
+---host2-3278452
+---host3-3278453
+--- …
---hostN-3278XXX
23. 23
얶어 지원
• ZooKeeper 클라이얶트 라이브러리 지원 얶어 :
– Java
– C
– Perl
– Python
• 커뮤니티 지원
: Scala, C#, Node.js, Ruby, Erlang, Go, Haskell
https://cwiki.apache.org/ZOOKEEPER/zkclientbindings.html
24. 24
몇가지 기억해야 할 점
• 감시(watches)는 일회성 트리거이다.
– Znode를 계속적으로 감시하기 위해서는 이벤트/트리거가 발생할 때마다
재설정해야 한다.
• 많은 감시를 znode에 설정하면 ‘herd effect’가 발생한다.
– 트래픽이 폭주하고, 확장성을 떨어뜨린다.
• Znode 에 대한 이벤트를 수싞하고, 감시를 다시 설정하는 동작 znode
가 계속 변경된다면 싞중하게 제어해야 한다.
• 세션 만료 시갂은 가급적 길게 설정해서 가비지 컬렉션으로 인한 ‘정지
시갂’을 줄여야 한다.
• Swapping 이 발생하지 않도록 자바 최대 heap 사이즈를 적젃하게
설정해야 한다.
• ZooKeeper 트랜잭션 로그 기록을 위한 젂용 디스크를 설정해야 한다.