Percona Xtradb는 mysql 엔진인 innodb에 Galera패치 등을 적용한 DB엔진입니다. Percoan Xtradb Cluster는 Active/active의 고가용성을 지원하는 솔루션이며 클러스터를 구축하기 위한 핵심 기술인 Codership Galera 라이브러리를 포함하고 있습니다. Percona의 동작방식을 이해하기 위해선 Galera 클러스터에 대한 이해가 필요합니다.
http://galeracluster.com/에서 제공되는 오픈소스로 Synchronous replication를 지원하는데, Synchronous replication를 지원하기 위해서는 Galera cluster Architecture에 대한 이해가 필요하며, Galera는 아래의 그림처럼 Certification Based Replication방식으로 동기화 처리를 합니다.
Kafka는 broker를 통해서 중재되는 pub-sub (발급-구독) 모델의 메세지 큐 입니다. 발급자(producer)가 데이터를 보내줄때 남기는 로그를 관찰하거나, consumer를 통해 적재된 데이터를 확인하여 모니터링을 할 수 있습니다. 하지만 앞선 방법들로는 토픽의 실시간 흐름을 확인하기 어렵습니다. 카프카내에서 흘러가는 데이터를 뜰채로 건져(스냅샷) 컬럼값을 파싱 한 후, 현재시간과 비교 한다면 아주 좋은 모니터링이 될 수 있습니다.
kafka-console-consumer.sh은 kafka topic에 있는 데이터를 consume 가능한 쉘입니다. sh을 통해 커맨드를 날려도 걱정마세요! sh 이름이 consumer라고해서 실제로 소비되어 없어지는 것은 아닙니다 :P kafka는 consumer group과 offset 을 통해 데이터가 전송되니깐요 :) 참고로, kafka에 저장된 데이터는 운영자가 설정한 기간만큼 저장되었다가 삭제됩니다.
아래명령어를 사용한다면 현재 카프카에 저장된 토픽 userTopic_K 정보를 확인 할 수 있습니다. --max-messages 옵션을 사용하면 메세지 수를 조절할 수 있고, --from-beginning 을 통해 시작 위치를 지정할 수 있습니다
CLI)
/usr/lib/kafka/bin/kafka-console-consumer.sh --zookeeper zookeeper1.localhost.com:2181,zookeeper2.localhost.com:2181,zookeeper3.localhost.com:2181 --topic userTopic_K --max-messages N (--from-beginning)
제가 운영중인 빅데이터분석플랫폼들은 엄청나게 많은 데이터를 처리하고 있습니다. 크기는 무려 페타급 규모이며 어떤 테이블은 모든 파티션의 row가 수십조개나 됩니다. 이런 데이터들을 실시간으로 모니터링한다면 ? 생각만해도 참 숨이 막혀옵니다.
그 규모가 절대 작지 않습니다.
실시간데이터라고 규모가 작지 않습니다. 운영중인 클러스터는 수 십 PB급 규모이며, 수십 개 종류의 데이터를 TB단위로 실시간 적재/전송/처리/제공 하고있습니다.
File System대신 memory 친화적이다.
실시간데이터는 대부분 메모리를 통해 빠른전송방식을 택하고있다는것이 일반적이죠. 메모리를 활용하는 Software들은 File System에 제한적인 정보만 저장하기 때문에, 별도로 로그를 남기지 않는 이상 모든데이터를 검사하는것은 어렵습니다.
모든 데이터를 검사 하더라도, 실시간 데이터를 검사하기 위한 리소스도 많이필요할 것입니다.
그래도 좋은방법은 존재한다.
하지만 흘러가는 데이터의 스냅샷 등을 주기적으로 관찰하거나, 처리중인 데이터의 추이를 활용한다면? 클러스터에 부담가지 않으면서, 인력도 크게 필요하지 않은 효율적인 모니터링이 될것입니다.
이 문서를 통해서 빅데이터클러스터에서 실시간 데이터의 효율적인 모니터링 방법을 익혀보도록 합시다.
2. 모니터링 실전 적용
2.1. ActiveMQ
Apache ActiveMQ란 무엇인가?
Apache ActiveMQ는 다중프로토콜을 지원하는 Java기반의 메시지 브로커입니다. 아파치 재단의 OSS로 누구나 무료로 사용 할 수 있습니다.
ActiveMQ는 아래와 같은 특성을 가집니다.
Java, C, Python, php 등 다양한 언어 간 클라이언트 및 프토토콜을 지원합니다
JMS 1.1 및 J2EE 1.4 를 완벽하게 지원하며, 엔터프라이즈 통합 패턴 및 많은 고급 기능을 제공 합니다.
JMS(Java Message Service) 클라이언트와 메시지 브로커 모두에서 통합패턴에 대해 완벽히 지원합니다.
ActiveMQ의 메시지는 Producer → Broker → Consumer 구조로 처리되며, NexR에서 운영하는 클러스터는 Broker에 Queue 모델을 채택하여 클라이언트/서버 상황에 따라 메시지를 전송합니다.
ActiveMQ 웹 UI 콘솔을 활용한 모니터링
ActiveMQ 기본설치시 간단한 Operation을 위한 web ui도 설치됩니다.
Web UI에서는 ActiveMQ를 통해 전송되는 queue 상태를 확인 할 수 있을뿐만 아니라 세부 메세지 내역도 확인이 가능합니다
1. ActiveMQ 웹 콘솔 메뉴구성
ActiveMQ 웹 콘솔에 (디폴트 url : localhost:8161/admin/) 접속하면 위와 같은 메뉴구성을 만날 수 있습니다.
Home Broker의 이름, 버전, memory usage, uptime 등 메세지 시스템의 기본 구성을 보여줍니다
Queues ActiveMQ를 통해 전송되는 topic들의 queue 상태를 확인 할 수 있습니다.
Topics ActiveMQ를 통해 전송되는 topic들의 다양한 operation이 가능합니다.
2. Queues 탭
Queues 탭에서는 전송되는 topic들의 queue 현황을 확인할 수 있습니다.
보시면 # of pening Message에 숫자가 꽤 쌓여있는것을 볼 수 있습니다. 영문 그대로 "전송되지 못하고 보류중인 데이터"라는 뜻입니다. 이 숫자는 Enqueued 된 메시지중 Dequeued 되지 못한 메시지 수 와 동일합니다.
# of pening Message가 지속적으로 쌓인다면 agent가 제대로 메시지를 처리하지 못하고 있는 뜻인데요, 일부 유실되어도 괜찮은 데이터라면 모르지만 중요한 데이터라면 유실되지 않게 메모리 증설 등 튜닝을 진행하여 줍시다.
우측에 보면 3가지 수행이 가능한 Operation 공간이 있습니다.
Send to는 수동으로 message를 보낼 수 있는 기능입니다. Purge를 활용한다면 pending된 모든 메세지를 없앨 수 있습니다. 이 때 purge를 통해 없어진 데이터들은 모두 유실이 됩니다. delete는 해당 topic을 지울때 사용합니다. 왠만하면 누를일이 없기 바랍니다.
3. 메시지 확인
Queues탭에서 메시지 확인을 원하는 Topic을 클릭한다면, 위 와 같이 메시지들의 정보들을 확인 가능합니다.