Cassandra stress-test를 활용한 Garbage Collector TEST (G1GC, CMS, ZING Read/Write Mixed)

Cassandra DB는 ring 구조의 db로서 hashing과 replication을 통해 성능(속도, 안전성)을 보장한다.

카산드라를 도입하기 위해서 스트레스 테스트를 해야할 때 카산드라 자체에서 지원하는 tool을 활용하면 쉽게 테스트가 가능하다.

본 포스팅은 카산드라 테스트 툴을 활용하여 가비지 컬렉터가 어떻게 동작하는지, 그리고 성능은 어떤지 보고자 한다.


gc는 서버의 메모리 스펙에 따라서 heap을 잘 조절해가며 최적화를 진행한다.
3대의 cassandra를 준비하고 각각의 GC 세팅을 다르게하여 테스트를 해보자.


서버 각각의 메모리는 32G이다.

그리고 java는 1.8(zulu jdk)를 썼고 zing test시에도 zing 1.8 version을 사용하였다.
후에 v11로 올려서 테스트해볼 예정이다.


테스트 하기전에 GC에 대해서 대략적으로 알아보자.

대부분의 객체는 life cycle이 짧다. 즉 객체는 빨리 소멸한다는 것이고 이런 객체들이 차지하고 있는 메모리를 잘 반환(청소)해야 할 것이다.

메모리에 객체가 할당되고 제거될 때에는 각각의 객체 size도 다르고 소멸주기도 다르기 때문에 결국 메모리 파편화가 발생하며 이는 새로운 객체가 할당될 때 문제가 된다. 마치 DB에서도 빈번한 insert/delete가 발생하면 인덱스에 페이지(블럭)의 순서가 꼬여서 단편화가 생기는 것과 같은 개념이다.


따라서 메모리 공간을 적절히 잘 나눌수만 있다면 그리고 그 메모리 공간 전체를 비울 수만 있다면 특별한 액션을 취하지 않아도 이 자체만으로 성능이 좋을 것이라는 추측이 가능하다.

하지만 GC가 발생할 때에는 Stop the world가 일어나서 어플리케이션이 잠깐동안 중단이 된다. 따라서 어플리케이션에 영향을 주지 않고 메모리가 full나지 않도록 하는 것이 목적이다.


객체와 GC 관계

1. 새롭게 생성된 객체는 Young generation의 eden에서 생성이 된다.

2. eden이 꽉차면 minor gc가 발생하고 이때 살아남은 친구들을 survivor1에 복사한다. 그리고 eden을 clear 한다.

3. 다음 eden에서 minor gc가 발생하면 survivor2에 복사하고 이때 survivor1에서 살아남은 친구들도 survivor2에 복사한다. 그리고 eden과 survivor2를 clear한다.

4. 이런 과정을 반복하면서 Young Gen에서 살아남은 친구들이 결국 Old Generation으로 복사가 된다.

즉 Young Generation(세부적으로 eden, survivor1, survivor2)과 Old Generation으로 나뉘는데 Young gen에서 발생하는 gc를 monir, Old gen에서 발생하는 gc를 full gc라고 부른다.

GC 종류마다 부르는 명칭은 다를지라도 청소하는 영역이 같다. (아래의 그래프에서 설명)
또한 suv1, suv2를 from, to 라고 불리기도 한다.




테스트할 GC는 CMS, G1GC 그리고 상용 GC인 ZING이다. ZING은 trial version으로 진행하였다.

테스트 하기전 설정을 살펴본다.

먼저 권장사항은 다음과 같다. 참고만하자.
출처 : Configuraing java heap space for cassandra

CMS 기준으로 설명해보면..
32G 시스템이므로 1/4크기만큼 주면 8G를 주기로 하였다.
MAX_HEAP_SIZE="8G"
HEAP_NEWSIZE="2G"


그리고 아래는 테스트 해가면서 조절해야한다.
-XX:NewRatio=2
-XX:SurvivorRatio=6
-XX:CMSInitiatingOccupancyFraction=75


위의 세팅을 해석해보자.
heap size가 8G인데 -XX:NewRatio=2이다. 즉 young:old 비율이 1:2이다. 만약 설정을 안하면 1:9가 default다.


young:old가 1:2이므로 8G를 배분하면 young이 약 2.6G, old가 5.3G을 가져간다.
-XX:CMSInitiatingOccupancyFraction=75이므로 75%가 찼을 때 GC 준비를 한다. 누군가 경험상으로 68%가 안전하다고 하는 글을 본적이 있지만 75%로 하였다.


XX:SurvivorRatio=6이므로 eden, suv1, suv2의 비율은 6:1:1이다. 따라서 young의 2.6G를 분배하면 1.95 : 0.325 : 0.325 가 된다.

G1GC나 ZING은 default 상태이다.

이제 본격적인 테스트를 해보자.
테스트 전 미리 원할한 jmx connection을 위해 아래와 같이 설정하였다.
authenticator: AllowAllAuthenticator
authorizer: AllowAllAuthorizer



CMS GC mixed read/write test

./cassandra-stress mixed ratio\(write=1,read=1\) duration=100m -rate threads=\32 -node ip

concurrentmarksweep가 full gc라고 보면 되고 parnew가 minor gc라고 본다.

oncurrentmarksweep가 약 21회 호출되었고 used heap size가 약 6G가 넘을 때 호출되었다. 다행히 max heap size까지 차지는 않았다. 하지만 일부 gc 그래프에서 튀는 것을 확인할 수 있다.



G1GC mixed read/write test

./cassandra-stress mixed ratio\(write=1,read=1\) duration=100m -rate threads=\32 -node ip

G1 Old generation이 full gc이다. 약 15회 발생했다.
7G 근처에서 발생했고 튀지는 않지만 조금 더 다이나믹하게 gc가 일어난다.


ZING GC mixed read/write test

./cassandra-stress mixed ratio\(write=1,read=1\) duration=100m -rate threads=\32 -node ip

아무래도 ZING의 경우 상용 GC라서 더 좋긴 할텐데 그래프가 궁금했었다.
테스트 해본 결과 원하는 결과(ZING의 성능)가 막 높게 나오지 않아서 원인을 찾는 중이고.. 메모리를 더 주고 테스트를 해봐야할 것같다. 아무래도 메모리 관리 측면에서 봐야할 것 같다.

-> 추후 대용량 배치+과도한 트래픽으로 인해 장애가 났었는데 당시 ZING의 위엄(?)을 느낄 수 있었다. disk가 밀리고, network traffic이 밀리는 상황에도 카산드라 노드들은 zing을 통해 메모리 관리를 매우 잘하고 안정적인 상태를 보여주었다.
그런데 카산드라가 죽었을때 메모리 반환을 빨리 안할까봐 메모리를 쿼터만 주고 했는데 다음 테스트에서는 많이 줘봐야겠다.


현재 mixed 방식(write/read)를 테스트 했는데 각각의 경우에는 추후 포스팅에서 테스트 결과를 공유하도록 하겠다.
ZING의 메모리를 더 늘리고, 버전도 UP 시켜서 각각 테스트해볼 예정이다.



ZING을 테스트하면서 하나 느낀점은 cassandra가 죽었을 때, 혹은 재부팅할 때 메모리 반환을 바로 하지 않는다. 무언가 설정이 있을 것으로 보이지만 프로세스를 죽여도 zing이 기존에 잡고 있던 heap memory를 바로 반환하지 않는 것이 발견되었고 이는 장애가 났을 때 바로 어플리케이션을 살려야할 경우 메모리가 부족해서 안살아날 가능성이 있기 때문에 max heap memory size를 잘 조절 해야할것으로 보인다. 

Artificial Intelligence - The Maximum Entropy Method

만약 어떤 사건의 확률을 구해야한다면 베이즈 정리를 통해 어려운 확률도 쉽게 구할 수 있었다. 하지만 이는 주어진 지식이 충분할 때의 이야기이다.

만약 주어진 지식이 충분하지 않다면 베이즈 정리를 통한 접근이 어렵다.

이럴 땐 The Maximum Entropy Method을 통해 해결하는 방법이 있다.

The Maximum Entropy Method는 현재 주어진 정보를 갖고 가장 최선의 해를 찾는 최적화 방법 중의 하나로 Entropy는 정보가 전혀 없는 상태가 가장 높아 최대화가 된다. 즉 어떤 사건이 일어날 확률이 다른 사건들이 일어날 확률과 똑같다는 가정하에 확률을 구하는 방법이다.

α와β가 구해졌을 때 P(B)를 구해보자.

P(A,B) = (P(A,B), P(A,┐B), P(┐A,B), P(┐A,┐B)) 이다.
이를 아래처럼 치환하도록 하자
p1 = P(A,B)
p2 = P(A,┐B)
p3 = P(┐A,B)
p4 = P(┐A,┐B)

즉 p1+p2+p3+p4 = 1이다.

P(A,B) = P(B|A)P(A) = αβ (Chain rule에 의해)
P(A) = P(A,B) + P(A,┐B)) (Marginalization에 의해)

Chain rule과 Marginalization은 아래 포스팅을 참고한다.
https://parksuseong.blogspot.com/2019/12/artificial-intelligence-chain.html

더 나아가보자.
p1 = αβ
p1+p2 = α
p1+p2+p3+p4 = 1

p2 = α - αβ = α(1-β)
p3+p4 = 1-α

현재 주어진 지식으로는 여기까지 구하는 것이 최선이다.

Entropy를 적용해보는데 Entropy는 최대화하는 것이 목표이다.

P = (p3,p4)일 때 H(p)는 아래와 같다.
(H(P)는 로그값이 확률 값이므로 음수가 나오기 때문에 -를 해주는 것이다.)

이는 p3 + p4 = 1 - α 이고 p3 + p4 - 1 + α = 0이 된다.

Largange function L을 이용해서 아래처럼 정의하고 L을 maximize하자. (지식이 적으니까)

이를 통해 구하기 어려웠던 P(B)를 구할 수 있다.

P(B) = P(A,B) + P(┐A,B)
= p1 + p3
= αβ + (1-α/2)

정리를 하면 미지수가 4개인데 식이 3개이므로 방정식을 풀 수가 없었다.
하지만 최종적으로 p3 + p4 = 1 - α에서 두 개의 확률 변수 p3, p4로 하는 Joint 확률 분포 P(p3,p4)에서 entropy가 최대가 된다. 2개의 확률 변수 Entropy 함수는 H(P)로 주어진 식을 최대로 하는 값을 찾기 위해서 Largange function L을 편미분한 값이 0, 즉 최대임을 이용하면 식이 2개가 추가되므로(p3와 p4에 대한 식) 원래의 방정식을 풀 수 있다.

또한 H(P)는 로그값이 확률 값이므로 음수가 나오기 때문에 -(마이너스)를 해주는 것이다.

정보가 적을 때 Entropy가 최대가 된다. (이때 decision tree에서는 엔트로피의 차를 통해 Information gain을 구해서 decision 하게 된다.)

하지만 위의 문제를 maximum entropy를 적용하지 않고 사실 두 확률 변수의 확률을 1/2로 가정해서 풀어도 상관 없다. n개일때는 1/n으로 가정한다.

-
아주대 김민구교수님 강의를 바탕으로 작성합니다.

Artificial Intelligence - Bayes' Theorem (Alarm, Earthquake, Burglary Problem)

Bayesian network의 기반이 되는 Bayes' theorem에 대한 포스팅이다.
추후 베이지안 네트워크에 대해서 포스팅하려고 한다.

이 포스팅 전에 아래 포스팅을 참고하면 좋을 것이다.
https://parksuseong.blogspot.com/2019/12/artificial-intelligence-chain.html


우리는 조건부 확률 정의에 의해 P(A|B) = P(A∧B)/P(B) 와 P(B|A) = P(A∧B)/P(A) 임을 알고 있다.

Bayes' theorem은 P(A|B) = P(B|A) * P(A) / P(B) 이다.
풀어보면 B가 주어졌을 때 A의 확률은 A가 주어졌을 때 B가 일어날 확률 * A의 확률 / B의 확률이다.

즉 다음처럼 정리할 수 있다.

이러한 정의가 왜 필요할까?

맹장으로 진단할 확률 변수 App과 백혈구 수가 일정수준 이상일 확률을 나타내는 확률 변수를 Leuko라고 가정하자.

만약 실제상황에서 백혈구 수가 높은데 맹장염일 가능성을 추정해야하는 경우가 생기기 때문이다.

몇 가지의 지식이 미리 알려져있다면 구하기 어려운 확률을 구하는데 사용할 수 있다는 것이 Bayes's Theorem의 목표라고 할 수 있다.

즉, 맹장염일 때 백혈구의 수치는 높다가 아닌 백혈구 수치가 높을 때 맹장염일 확률을 구할 수 있다는 것이다.

위의 표에 의해서 만약 P(App|Leuko)를 구해야한다면 다음과 같다.

P(App|Leuko) = P(Leuko|App) * P(App) / P(Leuko) = 0.82 * 0.28 / 0.54 = 0.43이다.

다른 유명한 예를 살펴보자.

A : 알람(Alarm), E : 지진(Earth quake), B : 도둑(Burglary)
- 도둑이 들었을 때도 알람이 울린다.
- 도둑이 들었을 때는 알람이 울릴 확률은 99%이다.
- P(A|E) = 0.99 (지진이 났을 때 알람이 울릴 확률 99%)
- P(A) = 0.1 (알람이 울릴 확률은 10%이다.)
- P(E) = 0.001 (지진이 날 확률은 0.1%이다.)

이를 통해 알람이 울렸을 때 지진이 일어날 확률을 구해보자.
P(E|A) = P(A|E)P(E)/P(A) = 0.99 * 0.001 / 0.1 = 0.01

만약 도둑이 들 확률을 P(B) = 0.001로 가정해보자.
그렇다면 알람이 울렸을 때 도둑이 들 확률도 구할 수 있다.
P(B|A) = P(A|B)P(B)/P(A) = 0.99*0.001/0.1 = 0.01

이는 제시되어 알고 있는 지식 중에 도둑이 들었을 때 알람이 울릴 확률은 99%이지만 알람이 울렸을 때 도둑이 들었을 확률은 1%이다라는 것을 알 수 있다.

마무리를 하면 베이즈 정리(이론)은 이미 알고 있는 확률을 이용해서 복잡하거나 구하기 어려운 확률을 구하는데 사용되며 이는 Bayesian Network에서 원인과 결과를 그래프로 나타내는 실용적 모델에 사용되며 추후 포스팅하도록 하겠다.

Artificial Intelligence - Chain rule/Marginalization rule proof and example

Joint probability의 간단한 예로 P(A,B)는 A와 B가 각각 t,f일 경우의 수가 총 4개가 존재하며 이는 둘다 t일때 P(A,B) = P(A∧B)로 나타낼 수 있다. 그런데 만약 A,B 두 경우가 아닌 n개의 사건이 존재한다면 이는 차원의 갯수가 d라고 가정하여 n^d - 1의 경우를 계산해야한다. 이를 모두 계산하기란 사실상 불가능하다.

하지만 이런 Joint probabiliy를 간단하게 하는 방법이 몇 가지가 존재한다.

그 중에서 Chain rule과 Marginalization rule을 살펴보자.

Chain rule의 식은 다음과 같다.
Product rule : P(A∧B) = P(A|B)P(B)

이는 조건부 확률 P(A,B) = P(A|B)P(B)에 의해 증명이 가능하다.

P(X1,...Xn)
= P(Xn|X1,...,Xn-1) * P(X1,...,Xn-1)
= P(Xn|X1,...,Xn-1) * P(Xn-1|X1,...,Xn-2) * P(X1,...,Xn-2)
= P(Xn|X1,...,Xn-1) * P(Xn-1|X1,...,Xn-2) * ... * P(X2|X1) * P(X1)
= ∏ P(Xi|X1,...,Xi-1)


Marginalization rule은 다음과 같다. A와 B는 binary 하다.
P(A) = P((A∧B) ∨ (A∧┐B)) = P(A∧B) + P(A∧┐B)
A가 일어날 확률은 B가 일어났을 경우/일어나지 않았을 경우의 확률의 합이다.

이를 일반화해보자.
P(X1 = x1,...,Xd-1 = xd-1) = ΣP(X1 = x1,...,Xd-1 = xd-1, Xd = xd)
즉 우측을 확률을 다 더하면 좌측의 확률이 나온다는 것이다.

정리하면 한개의 확률 변수의 모든 경우의 수를 모두 합치면 그 변수를 사용하지 않는 것과 같다는 것이다.

Marginalization rule의 예를 들어보자.

맹장으로 진단할 확률 변수 App과 백혈구 수가 일정수준 이상일 확률을 나타내는 확률 변수를 Leuko라고 가정하자.
P(Leuko|App)는 맹장으로 진단했을 때 백혈구 수가 일정수준 이상일 확률이다.

제시된 표에 의해 P(Leuko) = 0.54이고, P(App) = 0.28이다.
따라서 P(Leuko|App)는 P(Leuko,App) / P(App)이고 0.23/0.28 = 0.82가 된다.

하둡 데이터노드 추가/리밸런싱 하기 (Adding and Rebalancing Hadoop Datanodes)

하둡에 데이터 노드를 추가하는 경우는 공간이 모자라거나 성능향상이 필요할 때이다. 공간이 부족할 경우 어쩔 수 없이 노드를 추가해야하지만(아니면 과거 데이터를 지우거나) 그 외에 성능 확장(병렬처리)을 위해서라면 10%의 성능 향상을 위해 기존 노드 갯수의 10%만큼은 추가해주어야 한다고 알려져있다.



하둡에 신규 노드를 추가하고 리밸런싱을 통해 재분산 작업을 해보도록 하자.

작업순서는 크게 다음과 같다.

1. 신규 데이터 노드들에 자바, 하둡 설치
2. ssh 통신을 위한 인증키복사
3. 마스터 노드에서 slave를 인식할 수 있도록 slaves 파일에 slave host 추가
(하둡 버전에 따라서 masters, slaves 혹은 workers로 존재할 수 있다.)
4. 마스터 노드에서 BalancerBandwidth 변경
5. 마스터 노드에서 데이터 노드 rebalance 수행
0. 예상치 못한 상황이 생길 경우 먼저 처리.


각 노드에 기존 노드들과 동일한 자바를(zulu jdk) 설치하자.
기존에 갖고 있던 자바 설치파일을 scp로 옮긴다.
scp ./zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz id@a.b.c.214:test/sw/java
scp ./zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz id@a.b.c.215:test/sw/java
scp ./zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz id@a.b.c.216:test/sw/java
...


압축을 푼다.
tar -zxvf zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz
tar -zxvf zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz
tar -zxvf zulu8.38.0.13-ca-jdk8.0.212-linux_x64.tar.gz
...

기존노드들 처럼 심볼릭 링크 jdk를 만든다.
ln -s /sw/java/zulu8.38.0.13-ca-jdk8.0.212-linux_x64 jdk

JAVA_HOME path 변경해준다.
~/.bashrc에 JAVA_HOME과 HADOOP_HOME(미리 세팅)해 놓는다.
그리고 각각 환경에 맞게 필요한 것이 있다면 적용하도록 한다.

source .bashrc로 적용해서 echo $JAVA_HOME이 zulu가 잡히면 성공이다.

자바 세팅이 끝났다. 똑같은 방법으로 하둡을 설치한다.



하둡 설치 및 세팅
각 신규 노드는 별도로 4개의 디스크를 더 마운트하여 총 test01~5까지 있다.
먼저 /test01/hadoop 디렉토리 생성하고 test02~5까지 계층구조로 디렉토리 생성한다.
mkdir /test01/hadoop
mkdir -p /test02/hadoop/hdfs/data/
mkdir -p /test03/hadoop/hdfs/data/
mkdir -p /test04/hadoop/hdfs/data/
mkdir -p /test05/hadoop/hdfs/data/



역시나 마찬가지로 기존에 쓰던 하둡을 압축해서 신규노드들로 옮겨서 설치한다.
(위에서 ~/.bashrc에서 하둡경로 세팅해놓은 곳으로 설치한다고 보면 된다.)


scp ./hadoop-2.7.1.tar.gz id@10.203.5.214:/data01/hadoop
scp ./hadoop-2.7.1.tar.gz moneymall@10.203.5.215:/data01/hadoop
scp ./hadoop-2.7.1.tar.gz moneymall@10.203.5.216:/data01/hadoop
...

압축을 푼다.
각 노드에서 tar -zxvf hadoop-2.7.1.tar.gz 

cd $HADOOP_HOME으로 가서 경로가 잘 잡혔는지 확인한다.
hdfs dfs -ls / 명령어로 설치가 잘 되었는지 확인한다.

hdfs 명령어로 하둡 깔린거 확인했고 홈 잡혀있는거 확인했고 잘된것 같다.

다음은 ssh 통신을 위한 인증키를 복사하도록 하자.
~/.ssh 만들기
cd ~
mkdir .ssh
chmod 700 .ssh
cd .ssh

기존에 뚫어놓은 키 가져오기
아무데서나 가져와도 된다. 어차피 최초 설치 시 마스터가 뿌린것이기 때문이다.

scp authorized_keys id@a.b.c.201:/~~path~~/.ssh

다음처럼 키 내용이 제대로 들어있는지 확인하고 제대로 들어있으면 정상이다.

귀찮아도 ssh로 신규 데이터노드에 한번씩 꼭 붙어보자. (비번을 물어보지 않을 때까지..)

다음은 마스터 노드의 slaves 파일에 신규노드 추가 명시하자. 현재 하둡 2.7버전이고 여기에는 masters, slaves 파일이 존재했다. slaves파일에 신규 호스트들을 추가한다.

작업이 거의 끝나간다.

마스터에서 datanode refresh를 해준다.

hdfs dfsadmin -refreshNodes

기존 slave 72대에 일단 테스트로 5대만 추가해서 리프레쉬한 결과 5대의 데드노드가 추가됨을 확인

실제로 리프레시 후 Dead Nodes에 추가되었는지 확인한다.

yarn에서 보면 바로 적용은 안되고 조금 있어야 바뀌는 것 같다.

이제 추가된 데이터노드를 하나씩 살린다.

cd $HADOOP_HOME
sbin/hadoop-daemon.sh start datanode
sbin/yarn-daemon.sh start nodemanager

전후 jps를 통해 문제 없이 잘 살아남을 확인했다.

마지막으로 기존 데이터를 분산시켜주기 위해 리밸런싱을 하도록 하자.
(며칠이 걸릴지 모른다.)

마스터노드에서 대역폭을 100메가로 변경한다.
hdfs dfsadmin -setBalancerBandwidth 104857600


리밸런싱 시작한다. 숫자 5는 각 노드간 차이가 5%이내로 함을 의미한다.
sbin/start-balancer.sh -threshold 5




실행하니까 신규 노드에 데이터가 차는것을 확인할 수 있다.

리밸런싱 로그를 tail 걸어서 확인해보면 잘 진행되고 있다. 언제 끝날려나..

추후 확인해보니.. 기존 노드의 용량이 4TB씩이고 최대 3TB씩 사용하고있었다. 이를 5%씩 bandwidth 10mb로 분산시킨 결과 대략 2TB씩 골고루 나뉘어졌으며 이런 케이스에서는 약 15일 정도 소요되었다.

Cassandra + Prometheus + Grafana Monitoring System unsing by jmx exporter(node exporter)

카산드라(cassandra) 모니터링을 하기 위한 시스템을 마련하기 위한 포스팅이다. InfluxDB를 사용하는 케이스가 많이 있지만 이번 포스팅에서는 InfluxDB 없이 모니터링 시스템을 구축해본다.

큰 틀은 cassandra의 jmx를 활성시키고 해당 로그를 Prometheus에서 수집해서 Grafana로 화면에 그려주는 방식이다.

사용 버전
- cassandra 3.11.4
- jmx_prometheus_javaagent-0.3.0.jar
- prometheus 2.14.0
- grafana 5.0.1

그럼 카산드라에서 발생시키는 로그를 수집서버에서 수집해보자.
그 로그들은 각 클라이언트에서 수집서버로 Push(Polling)하는 방식과 수집서버에서 카산드라 로그를 Pulling하는 방식 두 가지로 나뉠 수가 있다. 

일반적인 모니터링 툴들은 각 클라이언트에서 수집서버로 로그를 전송하는 형태를 띄고 있다면 프로메테우스는 각 로그들을 각 클라이언트에서 exporter를 통해 가져오는 방식을 차용하고 있어서 프로메테우스가 장애가 나더라도 서비스 어플리케이션에 문제가 되지 않는다. 왜냐하면 각 클라이언트 들은 메트릭 정보를 수집해놓고 수집해가기를 기다리기만 하기 때문에 프로메테우스의 장애와는 아무런 상관이 없다.

아래는 프로메테우스의 아키텍쳐이다.

간단하게 살펴보면 프로메테우스 서버가 있고 여기서는 PushgaeWay나 Jobs/exporters에서 메트릭정보를 Pulling 하게 된다. 즉 어플리케이션단에서 exporter를 띄워놓거나 Pushgateway로 메트릭 정보를 보내면 프로메테우스 서버에서는 저 메트릭 정보를 가져오는 형태이다.
이 포스팅에서는 node exporter(서버 로그)와 jmx exporter(카산드라 로그)를 사용할 것이다.

그리고 Prometheus server에서 설정해놓은 정보에 따라 AlterManager에 시그널을 주면 이메일같은 채널로 알림기능을 설정할 수 있다.

마지막으로 Prometheus web UI나, Grafana와 같은 Visualization 툴을 통해 프로메테우스에서 수집한 메트릭 정보를 그려줄 수 있다. 이를 위해 PromQL이라는 쿼리를 사용하게 되는데 그라파나에서 제공하는 대시보드를 보면 sum이나 count가 대부분이라서 크게 어렵지 않는 것 같다. 그러니 누가 카산드라 메트릭 정보를 잘 표현할 수 있는 쿼리를 아주 잘 만들어주면 기쁜마음으로 사용하겠다.

카산드라를 설치하고 jmx까지 활성화가 되있다고 가정하자.
jmx 활성화 하는 방법은 어렵지 않다.
필자의 경우 중간에 제대로 동작을 안했었는데 이유는 conf/cassandra-env.sh 파일에서 LOCAL_JMX가 yes로 세팅되어 있었기 때문이다.
따라서 다음과 같이 수정하였다.

if [ "x$LOCAL_JMX" = "x" ]; then
    LOCAL_JMX=no
fi

그럼 이 데이터를 Prometheus server가 가져갈 수 있도록 jmx exporter와 node exporter를 설치하도록 한다.

이 포스팅에서는 두 가지 모두 설치해보고 비교해보자.

먼저 node exporter 세팅이다.

프로메테우스 공식 홈페이지에서 tarball을 받아서 각 노드에 옮겨서 설치한다.

주소는 다음과 같다.
https://prometheus.io/docs/guides/node-exporter/

node exporter는 단순히 압축을 풀어서 실행하기만 하면 9100 포트로 수집된다.
따라서 prometheus server에서 각 노드 9100 port로 들어가서 수집해오면 된다.

UI로 들어가서 확인해보자.

다음은 prometheus server에서 node exporter를 수집해가면 된다.
prometheus.yml 파일에 수집타겟을 설정해주자.

프로메테우스 UI에 가서 targets를 확인해보면 잘 떠있는 것을 확인할 수 있고 실제로 수집 되는 데이터를 그래프로 확인도 가능하다.

테스트로 그래프를 그려본 결과 그려지긴 하지만 뭔가 다이나믹하지 않고 상당히 아쉬운 느낌이 든다.

따라서 위의 프로메테우스 결과를 다시 grafana로 가져와서 grafana를 통해 그려보도록 한다.


이 역시 공식 사이트에 들어가서 다운을 받아서 설치하도록 하자.
주소는 다음과 같다. https://grafana.com/grafana/download


이 역시 압축을 풀고 서버를 띄우기만 하면되서 간단하다.
서버가 올라오면 3000번 포트로 접속해보자.


누군가 만들어서 배포해놓은 대시보드를 사용하자.
https://grafana.com/grafana/dashboards/


아래는 대시보드 11074번을 import 하였다.

그 결과 다음과 같은 아름다운 화면이 완성되었다.

하지만 뭔가 아쉬운 점이 있다면 node exporter는 하드웨어 모니터링 느낌이 강하다.
우리는 카산드라 노드의 정보가 알고싶기 때문이다.

이를 위해서 jmx를 써야한다.
같은 방식으로 jmx exporter 세팅 후 프로메테우스+그라파나로 연동하자.

cassandra metric을 보기 위한 jmx exporter 세팅이다.

다운로드 링크

https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.0/

카산드라는 jmx 세팅을 위해 카산드라를 노드별로 한대씩 내렸다가 올려야하기 때문에 조금 귀찮을 수 있어서 한번에 성공하도록 한다.

jmx exporter가 사용할 cassandra.yml 파일은 아래 주소를 참고 했다.
혹시 바뀔수도 있으니 현재 시점 샘플을 포스팅 마지막에 구글 드라이브 링크로 첨부하였다.
https://raw.githubusercontent.com/prometheus/jmx_exporter/master/example_configs/cassandra.yml


저 두 파일을 카산드라 폴더에 넣고 conf/cassandra-env.sh에 JVM_OPTS에서 물고 올라갈 수 있도록 다음을 추가하자.

JVM_OPTS="$JVM_OPTS -javaagent:/sw/cassandra/jmx_prometheus_javaagent-0.3.0.jar=7070:/sw/cassandra/cassandra.yml"


또는 다음처럼 명령어로 추가를 해주자. 모든 수집대상 노드에서 똑같이 반복한다.
echo 'JVM_OPTS="$JVM_OPTS -javaagent:'$PWD/jmx_prometheus_javaagent-0.12.0.jar=7070:$PWD/cassandra.yml'"' >> conf/cassandra-env.sh

위처럼 conf/cassandra-env.sh 마지막 줄에 jmx 에이전트 세팅을 해주고 카산드라를 재기동 한다.

역시 프로메테우스에서도 target ip를 추가해주자.
(이후 dashboard를 하나도 수정하지 않기 위해 job_name을 cassandra_로 시작하도록 하였다. instance명을 반드시 cassandra_로 맞춰주도록 하자.)

위에서 JVM_OPTS 를 설정하면서 7070 포트로 설정했으니 이번에는 7070 포트로 수집을 하면 된다.

프로메테우스 target에서도 up 상태를 확인할 수 있다.

node exporter와는 다르게 cassandra metric이 수집되고 있다.

마지막으로 grafana에서 적당한 대시보드를 골라서 그려보도록 하자.

dashboard number 5408을 활용했다. (https://grafana.com/grafana/dashboards/5408)

datasource가 없다면 생성해주고 5408 json을 import하면 다음과 같은 화면이 그려진다.

이상으로 cassandra + jmx exporter(node exporter) + prometheus + grafana를 활용한 cassandra monitoring system 구축을 마친다.

관련 파일은 아래 구글드라이브에서 첨부하였다.
https://drive.google.com/open?id=16UtW5A175w1tVknXvHFTOQUU9W2d9bNS

내용물
1. cassandra.yml
2. cassandra_rev3.json
3. node_exporter-0.18.1.linux-amd64.tar.gz
4. jmx_prometheus_javaagent-0.3.0.jar

Artificial Intelligence - Apriori Algorithm, support, confidence, lift

연관규칙분석, Assosiation Rule(장바구니 분석)은 어떤 데이터들 간에 연관성을 보는 방법이다. Assosiation Rule은 어떤 ITEM 집합의 존재가 다른 ITEM 집합의 존재를 암시하는것을 의미하고 A => B (A entails B) 라고 할 수 있겠다. (이는 인과관계가 아니라 상관관계이다.)
그리고 이를 통해 교차판매(Cross selling), 묶음판매, 부정행위 적발 등에서 사용할 수 있다.

이번 포스팅에서는 support, confidence, lift 활용법과 Apriori 알고리즘에 대해서 포스팅하며 실제로 어떻게 사용할 수 있을지 간단한 예를 들어 설명하도록 한다.


먼저 연관규칙생성 시 사용할 수 있는 결정도구는 3가지로 정리할 수 있다.
1. support(지지도)
2. confidence(신뢰도)
3. lift(향상도)

실제로는 위의 3가지를 섞어서 사용해도되고 하나만 사용해도되지만 반드시 데이터를 관찰해가며 적당한 도구와 최소 수치를 정할 수 있도록 해야한다.


Apriori Algorithm은 support를 활용하여 Assosiation Rule를 구하는데 알고리즘 설명에 앞서 연관규칙생성에 사용할 수 있는 도구의 의미를 알아보자.


먼저 support는 지지도로서 정의는 다음과 같고 이는 사건 A가 일어날 확률로 표현된다.
이는 frequent item sets을 판별하는데 사용이 된다.

예를 들어서 A와 B의 support를 구하기 위해서는 (A와 B가 동시에 발생한 사건 수)/(전체 사건 수)가 된다.

다음은 confidence는 신뢰도로서 다음과 같이 정의할 수 있다. 이는 사건 A가 주어졌을 때 B사건이 일어날 조건부 확률로 표현되며 아이템 집합 간의 연관성 강도를 측정하는데 사용된다. 쉽게 풀어보면 사건 A가 일어났을 때 사건 B도 함께 일어난 확률이라고 볼 수 있다.

예를 들어서 A와 B의 confidence를 구하기 위해서는 (A와 B가 동시에 발생할 확률)/(A가 일어난 확률)가 되고 이는 A가 발생했을 때 이 중에서 B가 얼마나 발생할지를 나타낸다.
아무래도 전체중에 A, B가 동시에 발생할 확률보다는 더 연관도가 높다고 할 수 있다. 하지만 수식에서 보는 것과 같이 A를 구매했을 때 B를 구매하는 것과 B를 구매했을 때 A를 구매하는 것은 다를 수 있어서 선후행 관계를 파악할 수 있다.


그리고 실제로 효용가치가 있는지 판별하기 위해 사용하는 lift는 향상도로서 조건절과 결과절이 서로 독립일 때와 비교하여 두 사건이 얼마나 함께 발생하는지를 나타낸 확률이다.

이는 실제 발생확률을 각 사건의 발생이 독립일 경우에 비해 그 사건이 동시에 발생할 예상기대 확률로 나눈 것을 뜻하며 수식을 정리하면 (A가 발생하고 B가 발생할 확률)/(B가 발생할 확률)로 나타낼 수 있다.

여기서 lift = 1 이면 조건절(Antecedent)과 결과절(Consequent)은 서로 독립이고 lift > 1 인 경우 서로 양의 상관관계로서 서로 연관이 있다고 판단할 수 있으며 lift < 1 인 경우는 음의 상관관계로서 연관이 없다고 판단할 수 있다. 하지만 이는 반드시 데이터를 보고 판단해야하며 lift < 1 인 경우가 무조건 틀리다고 볼 수 없다.



이제 Apriori Algorithm의 예시를 보도록 하자.
여기서는 frequent item sets을 고르기 위해 support를 사용했다.

다음과 같이 원천 데이터가 있다고 가정하자.

id는 구매자(또는 트랜잭션, 주문)이고, items는 상품셋이다.
최소 조건을 support > 1로 가정했다. (확률이나 경우의 수나 같다.)
전체 구매 상품중에 A 2번, B 3번, C 3번, D 1번, E 4번이 등장했고 D는 support > 1에 의해 제거한다.

남은 A, B, C, E로 조합을 만들어보면 다음과 같이 나타낼 수 있으며 발생 횟수(support)는 다음과 같다.

여기에서도 마찬가지로 {A, B}, {A, E}가 제거되며 남은 A, B, C, E로 조합을 만들면 {A, B, C}, {A, B, E}, {A, C, E}, {B, C, E} 4가지가 나오는데 직전 단계에서 {A, B}와 {A, E}가 제거되었기 때문에 볼 필요가 없이 {A, B, C}, {A, B, E}, {A, C, E}, {B, C, E} 중에 {B, C, E}만 남게 된다.

이를 제거하는 이유는 {A, B, C}가 나올 확률이 아무리 커봤자 {A, B}가 나올 확률보다 작거나 같기 때문이다. 이를 초월 집합 제거라고 부르며 수준 미달의 초월집합을 제거함으로써 효율적인 계산을 할 수 있게 된다.

이 결과가 의미하는 것은 B, C, E가 빈발 항목 집합, 즉 frequent item sets라는 것이다.

한번 쉽게 생각해보자.

만약 실제로 적용할 때에는 A를 구매했을 때 B를 추천하거나 C를 추천하는 경우가 많기 때문에 frequent item sets의 조합 크기를 2로 생각하고 {A, C}, {B, C}, {B, E}, {C, E}를 추천셋으로 만들어놓고 support 값으로 정렬, lift로 2차 정렬을 하여 상품셋 추천을 구현해도 되지않을까 싶다.
개인적으로는 상품셋의 퀄리티 보다는 상품셋의 규모가 매출에 더 큰 영향을 준다고 생각하기 때문이다. 물론 일정 수준 이상의 성능(퀄리티)이 나오는 경우에 한해서이다.


그럼 support, confidence, lift를 모두 활용한 예를 들어보도록 하자.


다음과 같은 구매내역을 가정한다. 최소 support는 0.35로 가정했다.

이를 co-occurence matrix로 표현하면 다음과 같다.

단일항목 집합으로 보면 다음과 같이 support 값을 구할 수 있다.
최소 support에 의해 D와 E는 제거된다.

2개항목 집합으로 보면 다음과 같다.
결국 최소 support에 의해 {A, B}와 {B, C}만 남게된다.

이는 단순히 support로 frequent item sets을 구한 것이다.

이번엔 confidence(신뢰도)를 고려해보자. 최소 신뢰도는 0.75로 가정한다.

min confidence 0.75에 의해 A=>B이 제거되었다.
이는 A를 구매했을 때 B를 구매하는 것보다 B를 구매했을 때 A를 구매할 확률이 높다는 것이고 C를 구매했을 땐 A를 구매할 확률이 100%라는 것을 의미한다.

이번엔 lift를 고려해보자. confidence를 support로 나눠주면 된다. 즉 support와 confidence만 알면 lift는 어렵지 않게 구할 수 있다.

lift > 1이 양의상관관계이므로 0.9를 제거하면 lift 1.5짜리 두 세트가 남게된다.
B=>C 는 support 0.5, confidence 1.0, lift 1.5 이다.
C=>B 는 support 0.5, confidence 0.75, lift 1.5 이다.

특히 B=>C의 경우 support 0.5에 의해 B와 C를 동시에 구매한 사람은 절반이고, confidence 1.0에 의해 B를 구매한 사람들은 C도 100% 구매한 것이다. 또한 lift 1.5에 의해 B를 구매했을 때 C를 구매할 확률은 단순히 C를 구매했을때의 확률보다 1.5배나 높아진다.


확실한 것은 현업에 적용하기 위해서는 도메인 지식을 잘 활용하는 것과 데이터를 관찰해가며 사용해야한다는 것이다. 도메인 지식을 잘 활용한다는 것은 데이터 클린징 또는 전처리를 잘 해야한다는 것과 같은 의미로 받아들였으면 좋겠다.



-
다음 포스팅은 FP-Growth에 대해서 포스팅해볼까 한다.
FP-Growth는 FP-Tree구조를 활용해서 Apriori algorithm의 연산속도 문제를 개선한 알고리즘이다. 확실히 Apriori 알고리즘은 구현하기 쉽지만 연산속도가 문제인 것 같다. 실제로 비슷한 것을 프로시저(쿼리)로 짠 것을 적용해달라고 해서 검증하다보니 연산속도가 장난이 아니어서 2step으로 나누어 일배치+월배치로 타협을 본 적이 있다.

Artificial Intelligence - MinMax Algorithm, Alpha-Beta pruning Algorithm

바둑이나 체스, 오목같은 턴제 대전게임에서 사용되는 기법들 중에서 기반이 되는 알고리즘은 최소최대 알고리즘(MinMax Algorithm)과 이를 약간 고도화한 알파-베타 가지치기 알고리즘 (Alpha-Beta pruning Algorithm)이다.

위와 같은 게임들은 분명한 것은 이기기 위해서 "나"는 내가 "최대"의 이익을 얻을 수 있는 방향으로 움직이며 "상대방"은 나의 이익이 "최소"로 하는 방향으로 움직여야한다. 그래야 서로가 이길 수 있으며 그런 방식으로 수읽기를 한다.

MinMax 알고리즘은 다음과 같이 구현될 수 있다. 아래 코드는 DFS이다.

Max_value(Node)는 v에 가장 작은 수로 넣어놓고 모든 노드를 탐색해서 가장 최대의 수를 찾는 것이고 Min_value(Node)는 v에 가장 큰 수를 넣어놓고 모든 노드 중 가장 작은 수를 찾는다. 이는 서로 Cross하면서 recursive하게 구현하는 것이 핵심이다.


아래의 예를 보자.

Max는 "나"이고 다음 수에서 최대의 이익을 얻는 수를 둔다. Min은 "상대방"이고 "나"의 이익이 최소화 하는 수를 둔다. (서로 최선을 다한다는 가정하에)

그럼 결국 다음처럼 수 읽기를 하면 될 것이다.
탐색은 왼쪽에서 오른쪽으로 이루어진다고 하자.

이를 약간 발전시킨 방식이 Alpha-Beta pruning이다. (알파 베타 가지치기라고 부른다.)
필요없는 search를 없애는 즉 가지치는 방식으로 동작한다고 하여 Alpha-Beta pruning이다.

Alpha : 클수록 나에게 유리하다.
Beta : 작을수록 나에게 불리하다.
내 차례(Max)에서 beta cut : Value가 beta보다 크거나 같을 때, ( V >= beta )
상대방 차례(Min)에서 alpha cut : Value가 alpha보다 작거나 같을 때, ( V<= alpha )

왼쪽->오른쪽으로 탐색을 한다고 하면 Min의 경우에 2번째 depth(2->2,4,6)에서 2를 먼저 탐색을 했으니 나머지 4와 6은 볼 필요가 없으니 cut한다는 것이다.

알고리즘은 다음과 같다.

Maximum node에서 𝛼에 그 노드의 child 값 중에서 가장 큰 값을 저장하고, Minimum node에서 𝛽에 그 노드의 child 값 중에서 가장 작은 값을 저장한다.

만약 Minimum node k 에서 현재 𝛽 값이 𝛽 ≤ 𝛼 이 되면 root node에서 현재 node k 까지 경로에서 Maximum node의 가장 큰 값이 𝛼 가 되므로 node k 이하는 더 체크할 필요가 없다.

반대로 만약 Maximum node I 에서 현재 𝛼값이 𝛽 ≤ 𝛼 이 되면 root node에서 현재 node I 까지 경로에서 Minimum node의 가장 작은 값이 𝛽가 되므로 node I 이하는 더 체크할 필요가 없다.