Embian Blog

이전 포스팅에서 ELK Stack이 Splunk 대체 Solution으로 유용하다는 결론을 내렸다. ELK Stack에 관한 이전 포스팅은 여기를 참조하면 된다. 그래서 ELK Stack이 사용하기에 얼마나 유용한지 알아보고자 ELK Stack의 핵심인 Elasticsearch와 Logstash의 성능을 테스트 하게 되었다.

이에 이 글에서는 Elasticsearch와 Logstash의 성능 테스트 방법과 결과를 알아보고자 한다.

테스트 환경

이후 나오는 모든 Server의 환경은 다음과 같이 동일하다.

설정

Elasticsearch 설정

이전 포스팅에서도 설명했듯이 node.name은 유일성과 의미를 가진 이름을 사용한다. 또한 이후 테스트에서 Cluster 구성을 할 예정이기 때문에 cluster.name 설정을 한다. 

Logstash 설정

Logstash Output Plugin으로 Elasticsearch를 사용했고, Elasticsearch Cluster 설정으로 앞에 Elasticsearch에 설정한 cluster.name과 동일하게 써준다. 

Logstash Workers 설정

이 설정은 Logstash Workers의 수를 늘려가며 테스트 할때만 해준다. Logstash Output Plugin의 Workers만 추가하며, Logstash Workers Default 값은 1이다.

성능 측정에 사용될 변화 요인

1. Apache Access Log 수

2. Logstash Agent 수

3. Elasticsearch Cluster Node 수

4. Logstash Workers 수

테스트 결과

여기서는 위에 나열한 성능 측정에 사용될 변화 요인에 따른 테스트 결과를 그래프로 나타내고, 각각의 테스트시 어떤 환경을 구축했는지 설명하려한다.

테스트 결과 그래프에서 Elasticsearch와 Logstash의 초당 Log 처리량을 초당 처리량으로 표현했고, 테스트를 위한 도구인 Log Generator가 Log를 파일에 쓰는 시간은 무시할 정도로 작아서 표시하지않았다.

1. Apache Access Log 수

첫번째 테스트에서는 Apache Access Log 수가 증가함에 따라 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다.

테스트는 Elasticsearch Cluster Node 1개와 Logstash Agent 1개로 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다.

2. Logstash Agent 수

두번째 테스트에서는 Logstash Agent의 수를 1개부터 6개까지 늘려감에 따라 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 6번 모두 동일하다.

테스트는 Elasticsearch Cluster Node 1개와 Logstash Agent 1개에서 6개까지 1개씩 늘려가며 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

3. Elasticsearch Cluster Node 수

세번째 테스트에서는 Elasticsearch Cluster Node 수를 1대부터 6대까지 늘려감에 따라 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 6번 모두 동일하다.

테스트는 Elasticsearch Cluster Node를 1대에서 6대까지 1대씩 늘려가고 Logstash는 Server 1대에서 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

4. Logstash Workers 수

네번째 테스트에서는 Logstash Output Plugin의Workers를 1개부터 4개까지 늘려감에 따라 Elasticsearch Cluster 구성 전과 구성 후의 Elasticsearch와 Logstash의 초당 Log처리량에 대해 알아보았다. 단, Apache Access Log의 수는 1,000,000개로 4번 모두 동일하다.

Elasticsearch Cluster 구성 전

Elasticsearch Cluster 구성 후

테스트는 네번 모두 Elasticsearch Cluster Node 2개와 Logstash Agent 1개로 했으며, Log Generator는 Logstash와 동일한 Server에서 구동했다. 간단하게 보면 테스트 환경은 다음과 같다. 

추가 테스트 결과

추가로 두가지 테스트를 더 해보았다.

첫째로 Elasticsearch Cluster를 구성하지 않고, Logstash Agent 1개당 Workers 2개를 동작시켰다. 간단하게 보면 테스트 환경은 다음과 같다. 

테스트 결과 몇번을 다시해 보아도 데이터가 유실되어 제대로된 테스트가 이루어 지지 않았다.

둘째로 Elasticsearch Cluster를 구성하고, Logstash Agent 1개당 Workers 2개를 동작시켰다. 간단하게 보면 테스트 환경은 다음과 같다. 

테스트 결과 Elasticsearch와 Logstash의 초당 Log처리량이 27,519(events/sec)로 지금 까지의 테스트 중 가장 높았고, 위 테스트 환경이 현 Server 6대에서 최적의 구성이였다. 

결론

위에 작성한 테스트 결과를 간단히 요약하자면 다음과 같다.

1. Apache Access Log 수

 Log수가 증가함에 따라 초당 처리량이 소폭 증가했다.

2. Logstash Agent 수

Logstash Agent의 수가 증가함에 따라 초당 처리량이 선형적으로 증가했다.

3. Elasticsearch Cluster Node 수

Elasticsearch Cluster Node 수가 1개에서 2개로 늘렸을 경우 초당 처리량이 약 100%정도 증가했으며,  Cluster Node 수가 2개부터 6개까지는 초당 처리량의 변화가 거의 없었다.

4. Logstash Workers 수

Elasticsearch Cluster 구성 전과 구성 후 모두 Logstash Workers 수가 1개에서 2개로 늘렸을 경우 초당 처리량이 증가했으며,  Logstash Workers 수가 2개부터 4개까지는 초당 처리량의 변화가 거의 없었다.

또한 Elasticsearch Cluster 구성 전보다 구성 후에 초당 처리량이 증가했다.

추가 테스트

현 Server 6대에서의 최대 초당 처리량은 27,519(events/sec)로 나왔다.

Splunk는 모든 머신 데이터를 실시간으로 collecting하고 Indexing하고 Reporting하는 End-to-End Solution이다. 모든 머신 데이터를 제한 없이 처리 할수있다. 사용자가 원하는 데이터를 즉시 분석할수 있으며, 원하는 Reporter, Dashboard를 추가적인 개발없이 구성할수 있다. 또한 통계적 명령들을 조합하여 여러가지 Query문으로 Search가 가능하며 Query문의 자동완성 기능까지 갖추고 있어 사용하기 매우 편리하다. 하지만 상당히 높은 가격대의 Solution이라서 일반적인 중소기업이 사용하기에 경제적으로 어렵다. 그래서 보다 낮은 가격대의 편하게 이용가능한 Splunk의 대체 Solution을 조사하던 중, Elasticsearch 사이트에서 Splunk와 비슷한 기능을 가진 ELK(Elasticsearch, Logstash, Kibana) Stack을 찾게 되었다. 

이에 이 글에서는 ELK(Elasticsearch, Logstash, Kibana) Stack을 사용해보고 Splunk의 대체 Solution으로 적합한지 알아보고자 한다.

소개 

ELK Stack은 Elasticsearch, Logstash, Kibana의 약자로서 Elasticsearch는 Apache의 Lucene을 바탕으로 개발한 실시간 분산 검색 엔진이며, Logstash는 각종 로그를 가져와 JSON형태로 만들어 Elasticsearch로 전송하고 Kibana는 Elasticsearch에 저장된 Data를 사용자에게 Dashboard 형태로 보여주는 Solution이다.

설치 및 설정

아래의 내용은 1대의 Server 환경에서 설치 및 설정한 경우이며, Elasticsearch는 0.90.11, Logstash는 1.2.2, Kibana는 Kibana-3.0.0 milestone4를 사용하였다.

Elasticsearch 설치 및 설정

(1) Elasticsearch 홈페이지에서 Elasticsearch의 zip파일을 다운받아 unzip한다.

(2) Elasticsearch 모니터링을 위한 Plugin을 설치 한다.

(3) config/elasticsearch.yml의 node.name을 지정한다. 이는 노드를 식별하기 위한 이름이므로 유일성과 의미를 가진 이름을 사용한다.

Logstash 설치 및 설정

(1) Elasticsearch 홈페이지에서 Logstash의 jar파일을 다운받는다.

(2) Config File을 생성하여 다음과 같이 저장한다.

Kibana 설치 및 설정

(1) Elasticsearch 홈페이지에서 Kibana의 zip파일을 다운받아 unzip한다.

(2) unzip한 파일은 Elasticsearch의 Plugin에 넣어 사용한다. 경로는 다음과 같다.

(3) path/to/elasticsearch/plugins/kibana/_site/config.js의 Elasticsearch Server URL을 지정한다. 

        (예: elasticsearch: "http://localhost:9200")

실행

Elasticsearch 실행

unzip한 Elasticsearch 디렉토리안의 bin에서 실행한다.

Logstash 실행

logstash.conf는 앞서 생성한 Logstash의 Config File이다.

Kibana 실행

Elasticsearch의 Plugin안에 넣었기 때문에 따로 실행할 필요가 없다. 

http://localhost:9200/_plugin/kibana/#/dashboard에서 Kibana가 잘 뜨는지 확인한다.

사용

Dashboard 생성

(1) http://localhost:9200/_plugin/kibana/#/dashboard에서 Blank Dashboard를 클릭한다.

(2) 설정 아이콘을 클릭한다.

(3) Dashboard의 Title을 입력하고 창을 닫으면 새로운 Dashboard가 생성된다.

Panel 생성

(1) 'ADD A ROW' 버튼을 클릭 한다.

(2) Rows의 Title을 입력하고, 'Create Row' 버튼을 클릭하여 Row를 생성한 후 창을 닫는다.

(3) Panel 생성을 위해 'Add panel to empty row' 버튼을 클릭한다.

(4) Panel Type을 선택한다. 여기서는 'histogram'을 선택하였다.

(5) Panel의 Title 및 사용자가 원하는 설정을 하고난 후 'Add Panel' 버튼을 클릭하여 Panel을 생성하고 창을 닫는다.

(6) 위에서 선택한 Type의 Panel이 생성되었음을 확인할수 있다.

Query

다양한 Query를 이용하여 Search하고 결과를 확인할 수 있다. 

(Query문의 종류 :  http://lucene.apache.org/core/3_5_0/queryparsersyntax.html )

Apache로그를 이용하여 위와 같은 작업을 거쳐 Dashboard를 완성해 보았다.

결론

Splunk와 ELK Stack은 End-to-End Solution이라는 면에서는 비슷할지 모르나, Kibana3가 아직 Release된 GA 버전이 없어 Splunk보다 기능적으로 부족하다.  

1. Splunk는 Query문의 자동완성 기능이 매우 잘되어있으나, Kibana는 이전에 사용했던 검색어에 대해서만 Query문의 자동완성을 지원 해준다. 

2. Splunk는 한개의 그래프에 한개의 Query 결과가 붙는 형태인 반면, Kibana는 한개의 Dashboard에 한개의 Query가 붙는 형태로 이를 공유하여 사용하기 때문에 하나의 Dashboard가 다양한 데이터를 가지고 표현할 수가 없다. 

3. Kibana는 아직까지 로그로부터 상위 n개의 결과를 그래프로 작성하는 Top-N Queries 기능이 없어 이 또한 사용하기 불편하다. (Top-N Queries 기능은 Kibana3 정식 Release 버전에서 추가될 예정이다.
참조 : http://www.elasticsearch.org/blog/whats-cooking-kibana/ )

현재는 ELK Stack이 Splunk비해 사용하기 불편하지만, 경제적인 측면까지 고려한다면 ELK Stack이 Splunk의 대체 Solution으로 유용할것이라 생각한다.

Reference Sites

ELK(Elasticsearch, Logstash, Kibana) Stack

(1) Elasticsearch : http://www.elasticsearch.org/

(2) ELK Download : http://www.elasticsearch.org/overview/elkdownloads/

(3) ELK Stack 연동 : http://www.yongbok.net/blog/real-taime-visitor-analysis-with-logstash-elasticsearch-kibana/

(4) Logstash Docs : http://logstash.net/docs/1.3.3/

(5) Kibana Dashboard 생성 : http://www.elasticsearch.org/videos/make-sense-of-your-big-data/

(6) Query 종류 : http://lucene.apache.org/core/3_5_0/queryparsersyntax.html

(7) Kibana3 Release GA버전 수정될 사항 : http://www.elasticsearch.org/blog/whats-cooking-kibana/

문서 Format 참고

(1) http://logstash.net/docs/1.4.0.beta1/tutorials/getting-started-with-logstash

(2) http://red-badger.com/blog/2014/02/18/jlt-world-risk-review-rapid-innovation/

2014년 3월 Elasticsearch, Logstash, Kibana의 새로운 버전이 나왔고, 이에 대한 글은 여기를 참조하시면 됩니다.

시스템 에러 탐지 및 금융사기 탐지, 자동화 시스템의 상태 탐지 등의 분야에서 실시간 데이터 분석은 필수적이나, 데이터량의 폭증에 따라 기존의 데이터 분석 시스템은 그 한계를 드러내고 있다.

이러한 한계를 극복하기 위하여 Big Data를 활용한 준 실시간 분석 시스템이 적용되고 있으나, 이 역시 Batch 형식의 작동방식에 따른 근본적인 문제점을 가지고 있어, 진정한 실시간 분석으로 보기는 어렵다.

따라서 Time Critical한 분야에서의 대용량 데이터에 대한 실시간 스트리밍 분석은 향후 시장에서의 주요한 기술로서 가치가 있다.

엠비안에서는 Distributed Realtime Computation System인 Storm과 대표적인 CEP엔진인 Esper를 사용하여 Big Stream을 실시간 분석하는 기술에 대해서 연구를 하였다. 연구의 주요 목표는 Storm의 비즈니스 환경에서 유연하지 못한 단점과 Esper의 Scale out의 한계를 서로 보완할 수 있는 Architecture를 만드는 것이다.

여기서는 엠비안에서 진행했던 Storm과 Esper의 결합에 대한 연구 과정 및 결과에 대해서 간단히 알아보도록 하자.

사용자 설정 기반의 실시간 Big Data 분석 시스템 Prototype Architecture

ü  분산 처리 환경을 통하여 초당 10,000건의 대용량 Log 를 처리

ü  유입된 Log Data 를 Batch 형태가 아닌 실시간 Streaming 방식으로 처리

ü  실시간 Streaming 처리의 진행 상황을 API로 제공

ü  이용자가 지정한 규칙(Rule)에 따라 유입된 로그에 대한 분석

위 4가지 목표로 모든 데이터(Event , 모니터링, 설정 데이터)가 MessageQueue를 통하여 전달되는 Prototype Architecture를 마련하였으며 테스트 진행하였다.

테스트는 Prototype Architecture 의 Engine 부분에 변화(Esper, Storm&Esper)를 주며 진행하였다.

첫번째 테스트는 Engine 부분을 Esper 만 사용하여 테스트를 진행하였으며 구성은 다음과 같다.

1.     Esper : EPL이 다양한 시나리오를 수용할 수 있는지 확인하기 위한 테스트

 우선 3가지의 테스트 시나리오를 마련하여 EPL statement로 작성하였다. 이 EPL statement로 처리한 결과인 Output Data를 Input Data의 Hit ratio와 대조하는 방법을 통해 EPL의 정합성을 확인하고자 하였다.

 테스트 결과 3가지 시나리오 모두 예상 결과와 일치하였다. 따라서 다양한 시나리오가 EPL statement로 표현이 충분히 가능할 것으로 보인다.

2.     Esper : 시스템 unit 고안하기 위한 테스트 

시스템 resource에 영향을 줄 수 있는 요인

ü  Input Data량

ü  Hit Ratio

ü  EPL 종류

ü  EPL 개수

ü  Window Time

ü  Heap Memory량

에 변화를 주어 resource의 변화(CPU를 사용률, Memory 사용량)를 측정하였다.

테스트 결과는 다음과 같다.

ü  Input Data의 증가량에 비례하여 CPU 사용률과 Memory 사용량이 증가한다.

ü  Hit Ratio는 CPU, Memory 변화량에 크게 영향을 주지 않는 것으로 보인다.

ü  Input Data에 영향을 미치는 조건 (예를 들면 window time, new DataEvent)을 배재한 EPL은 CPU, Memory 변화량에 크게 영향을 주지 않는 것으로 보인다.

ü  동일한 EventData를 사용할 경우 EPL의 갯수와 상관없이 EPL 중   max(window time)과 비례한다.

ü  Window time이 증가할수록 CPU사용율, Memory 사용량이 증가한다.

ü  Heap Memory 량은 Memory 사용량에는 영향을 주지 않는 것으로 보인다.

따라서, 시스템 resource에 영향을 주는 요인은 Input Data량의 변화이며, Input Data의 증가량에 비례하여 resource 사용률이 증가함을 확인하였다.

위 결과를 바탕으로 “10,000건/sec 데이타를 window time 1sec 가지고 있는 1개의 statement”을 1ss로 정의하는 시스템 unit을 고안해 낼 수 있었다.

 1ss의 경험은 현 시스템에서 어느 정도의 데이타 처리가 가능한지 예측 가능하게 한다.

예를 들어, 테스트 시스템(4Core, Mem 16GB, EventData 10,000건/sec)의 1ss의 메모리 사용량을 계산하면 (참고로 0ss일때 Memory 사용량은 약 50M) 약 16M이므로 이 시스템은 약 1000ss 시스템으로 예측 할 수 있다.

두번째 테스트는 Engine 부분을 Storm&Esper 사용하여 테스트를 진행하였으며 구성은 다음과 같다.

1.     Storm&Esper : Scale out 가능한 Topology 구성 테스트

Storm&Esper 를 사용했을 때 아래 6가지 테스트를 통해 Scale out 가능한 Topology 구성을 알아내고자 하였다.

ü  Pre Test : Storm Single Test

“Noop”(초당 3개 tuple을 보내는 Bolt)의 CPU와 Memory 사용률을 측정하여 Storm&Esper를 사용함으로써 증가되는 CPU와 Memory 사용률 확인하였다.

ü  Set0 : 1up Test (1 Unit Processing)

1대의 서버에서 1개의 Esper Bolt에 3가지 테스트 시나리오의 EPL statement를 구동하여 “Esper Bolt”의 CPU, Memory 사용률을 측정했다.

이를 통해 Esper 단독 테스트의 동일한 조건(모든 EPL 구동)의 결과와 비교하여 1up의

resource 수치를 확보하였다.

ü  Set1 : Rule Per Bolt Test (Rule 분산 Test)

     여러개의 EPL Statement를 여러개의 Esper Bolt에 분산하여 처리하는 것이 가능하며

     resource 사용에는 효율적인지 알아보기 위한 테스트를 진행하였다.

그 결과 분산 처리는 가능하나 resource 사용에는 효율적으로 보이지 않았다.

ü  Set2 : Rule Partition Test

     1개의 rule이 “context EPL statement”를 통해 병렬 처리 가능한지 알아보려고 하였으나

     다음의 2가지의 문제로 진행하지 못하였다.

     - Context의 granularity option이 “Esper Document”에서 명시한 대로 동작하지 않았다.

     - Context의 filter option은 적용에 제약 사항이 있을 수 있다.

Storm과 Esper의 결합에 대한 연구에 대한 결론

Storm과 Esper의 결합에 대한 연구는 글 초반에 언급한 4가지 목표를 가지고 진행되었다.

이에 위의 3가지 테스트를 통해 다음과 같은 결론이 도출되었으며 그에 따른 Prototype Architecture이 마련되었다.

1.     여러 시나리오에 대해 EPL로 표현은 충분히 가능한가?
충분이 가능하며 Context, Enumeration method(lamda expression), Pattern expression, match and recognize 등 다양한 표현 방법과 match 방법 제공을 통해 확장적이 표현 또한 가능하다.
그러나 사용자 별로 EPL의 이해도가 달랐을 때 Performance의 영향을 줄 수 있어 주의가 필요하다.

2.     초당 3,000건의 데이타 처리가 가능한가?
Stream Processing에서는 대량의 데이타가 시스템에 유입 할 때 크게 느는 것은 메모리에 대한 요구사항이다.
이에 1 Second  Statement’(1 SS) 라는 시스템 Unit을 고안하여 시스템 사양에 따른 데이타 처리량을 예측하도록 하였다.
따라서, 앞서 진행한 테스트 시스템(4Core, Mem16GB, Heap Mem 12G)을 기준으로 약4~5분의 window time에서 초당 10,000건의 데이타 처리도 가능하다는 것을 예측할 수 있다.

3.     scale-out 가능한 Topology 구성은 무엇인가?
resource 측면에서는 효율적이지는 못했지만 Rule 갯수 만큼 Scale out이 가능함을 확인하였다.
또한 Rule은 resource에 영향을 주는 "window time"을 기준으로 분산하는 것이 적당하다고 판단된다.

4.     Rule의 동적 설정이 가능한가?
Esper Engine은 EPL Statement의 동적 설정(추가, 삭제, 상태변경 등)에 필요한 API를 제공한다.
따라서, 아래 그림과 같은 Rule 분산을 통한 Esper Bolt의 Scale out이 가능하고 storm stream 을 이용하여 EPL statement 동적 설정이 가능한 prototype을 제작하였다.

이번 연구성과물의 적용범위

상기 프로젝트의 결과물을 Big Data의 Log형 데이타의 실시간 분석에 사용될 수 있으며, 예로는 

ü  Enterprise 환경에서 Application Server들의 통합적인 기능오류 분석

ü  Intrusion Detection

ü  상기 기능들을 포함하고 Rule의 Life Cycle을 고려한 Commerical Package로 재구성

등에 쓰일 수 있다.

연구 결과물은 Commerical Package가 아닌 Prototype인 관계로 실제 사이트 적용시에는  반제품의 형식으로 System Integration이 필요하나, 우리의 결과물이 그러하듯이 기본적인 Scaling은 Storm단에서 이루어지기 때문에 Storm의 Spout과 Bolt를 Chaining하여 서비스에서 필요한 Scale Out을 쉽게 구현할 수 있을 것이다.