Embian Blog

Apache Kafka 성능 테스트

조석현(zoe@embian.com)
Business Developer / Consultant at Embian Inc.

Apache Kafka는 LinkedIn에서 자신들의 내부 데이터 처리를 위해 개발한 DPMS(Distributed Processing Message System)입니다. 전통적 메세지 큐 시스템(Message Queue System)과는 다르게 Apache Kafka는 Broker Cluster를 여러 대의 Machine으로 구성하여 분산처리(Distributed Processing)가 가능하다는 장점을 가지고 있습니다. Big Data시장의 발전과 함께 가장 주목받고 있는 Queue System이기도 합니다.

본 포스팅에서는 Apache Kafka의 주요 특징을 살펴보고 분산 처리 성능을 확인하기 위한 성능 테스트와 결론을 정리해 보았습니다.

Index

1. About Apache Kafka

2. Performance Test

3. Conclusion

1. About Apache Kafka

Apache Kafka는 LinkedIn의 Legacy System인 ActiveMQ와 Splunk를 대체하기 위하여 개발된 Message Queue System입니다. LinkedIn은 2009년 서비스 가입자가 폭증하며 자신들의 내부 데이터 처리 과정에서 한계를 느끼고, 그들만의 Messaging System을 개발하게 되었습니다. 현재 LinkedIn에서 사용자들에게 잘 알려진 PYMK(People You May Know)등의 서비스가 대표적인 적용사례입니다. 해외에서는 Twitter, Netflix, Tumblr, Foursquare 등의 기업에서 Apache Kafka를 도입하여 사용하고 있습니다.

Kafka는 개발과정에서 Open Source로 관리되었으며 Apache Incubator를 지나 현재는 Apache 정식 프로젝트로 등록되어 관리되고 있습니다. 게시물 작성일 기준으로 0.8.0 버젼이 Stable Release입니다.

1.1. Kafka's Features

Apache Kafka는 LinkedIn에서 설계 시점부터 Big Data를 염두에 두고 Kafka를 설계하였습니다. Kafka 공식 홈페이지에서 자랑하는 Kafka의 주요 특징은 아래와 같습니다.

• Scala/Java로 작성되어 있다.
• 분산처리(Distributed Processing)가 가능하다.
• Log Data를 디스크에 기록한다.
• Publish-Subscribe구조로 되어 있다.
• 확장 가능(Scalablility)하다.
• 처리량이 높다.(High Throughput)
• 응답속도가 빠르다.(Low Latency)

Apache Kafka의 가장 큰 특징은 확장 가능(Scalablitiy)이라고 할 수 있습니다. 그리고 Log Data를 메모리가 아닌 디스크로 저장함으로서 In-Memory기반의 메세지 큐에 비해 Data의 안정성을 높여주며, Message Queue의 역할과 Log Aggregation의 역할을 함께 할 수 있다는 특징이 있습니다. 

1.2. Kafka Architecture

Apache Kafka는 전통적 메세지 큐 방식인 Publish-Subscribe의 구조로 구성되어 있습니다. Producer는 Message를 Broker로 발행(Publish)하고, Consumer는 Broker에서 메세지를 구독(Consume)하는 형태입니다. 각 Broker는 여러 대의 Broker Cluster로 구성 가능하며, Zookeeper에 의해 각 노드가 모니터링됩니다. 기존 메세지 큐와 가장 큰 차이점은 여러 개의 Partition으로 메세지가 분산처리된다는 점입니다.

Apache Kafka에서 제공하는 Kafka의 기본 컨셉은 아래의 그림과 같습니다.

Apache Kafka의 Basic Concept과 Architecture, 사용법 등의 내용들은 향후 Posting할 예정입니다.

2. Performance Test

2.1. 테스트 배경 및 목적

Kafka를 도입하려는 많은 기업의 경영자와 엔지니어들은 Kafka를 도입하기 위하여 Kafka의 가치를 검토할 필요가 있습니다. End-User에게 보다 좋은 서비스를 제공하기 위하여, Application의 환경 또한 중요한 요소이며, Kafka 도입을 통해 기업이 얻는 Benefits을 판단하는 것은 중요한 Decision Point입니다.

앞서 언급한대로, Kafka는 Scale Out을 통한 분산처리가 핵심이라고 할 수 있습니다. Kafka Broker Cluster를 구성하였을때, Broker 수가 증가함에 따라 Throughput이 얼마나 증가하는지, Kafka Cluster Set의 최대 처리량은 언제 어떤 시점에서 나타나는지, Log를 기록하는 디스크의 성능에 따라 얼마나 성능이 차이나는지 확인할 필요가 있습니다.

"그래서 Apache Kafka는 대체 성능이 얼마나 좋은건데??"

이를 위하여 성능측정의 가이드라인이 필요하다고 판단하였고, 저 역시도 기술스택 도입 이전의 검토단계로서 "Apache Kafka의 성능이 얼마나 되는 것인가?" 라는 막연한 질문에서 출발하여 자료를 찾아보기 시작했습니다. Kafka의 성능 수치에 대한 검색결과는 내부 측정 결과와 다소 차이가 있었고, 환경 구성이나 배경에 대한 설명이 부족하여 검색결과를 신뢰하기 어려워 직접 Performance Test를 수행하게 되었습니다.

Performance Test의 목적은 아래와 같이 정의하였습니다.

2.2. 수행 테스트 목록

수행 테스트는 아래 3가지로 정의하였으며,
Producer - Broker구간으로 한정하여 테스트를 수행하였습니다.

2.3. 테스트 툴 선택 / 평가기준

Kafka에서는 Benchmark Test를 위해 기본적으로 Performance 측정 도구를 제공합니다.

Kafka를 설치하면 {$KAFKA_HOME}/bin에 kafka-producer-perf-test.sh 파일과 kafka-consumer-perf-test.sh 파일을 확인할 수 있는데, 이 파일을 실행하여 Performance Test를 수행할 수 있습니다. 테스트 범위가 Producer-Broker 구간이므로, kafka-producer-perf-test.sh 쉘 스크립트를 이용하여 테스트를 수행하였습니다.

개별 메세지를 전송할 때 평가 기준은 처리량(Throughput)과 응답시간(Latency)을 기준으로 최초 정의하였으나, Kafka에서 제공하는 테스트 도구에서는 응답시간을 지원하지 않고 Producer - Broker구간에서는 응답속도(Latency)가 필요하지 않아 평가 기준에서는 배제하였습니다.

평가기준 : Throughput(초당 처리량)

   - 단위 : MegaByte/second

2.4. 테스트 시나리오 및 수행방법

  Test 1. Broker 수 증가 테스트(SSD)

Producer Machine을 3대로 고정하고, Broker Machine의 대수를 1대부터 3대까지 증가시키며 Throughput의 변화를 확인합니다. 각 Broker의 Storage는 SSD를 장착하였습니다.

  Test 2. Broker 수 증가 테스트(HDD)

Producer Machine을 3대로 고정하고, Broker Machine의 대수를 1대부터 3대까지 증가시키며 Throughput의 변화를 확인합니다. 각 Broker의 Storage를 HDD로 교체하여 장착하였습니다.

  Test 3. 최대 처리량 측정 테스트

Producer Machine과 Broker Machine의 대수를 동시에 1대부터 5대까지 증가시키며 Throughput의 변화를 확인합니다. 각 Broker의 Storage는 최대 성능을 고려하여 SSD로 교체하여 장착하였습니다.

* Producer - Broker 구성이 5대 - 5대 로 구성되어야 하나, 장비 제약으로 인해 4대 - 5대 구성으로 대체하였습니다.

2.5. 테스트 환경구성

테스트를 위한 Network 구성과 Machine 상세는 아래 그림과 같습니다.

* Broker Machine의 Storage는 테스트 방법에 따라 SSD type과 HDD type을 사용하였습니다.

각 Machine에 설치된 OS/Application은 아래와 같습니다.

Zookeeper의 환경설정( {$KAFKA_HOME}/config/zookeeper.properties )과 Broker( {$KAFKA_HOME}/config/server.properties )의 환경설정은 설치시 Default Setting으로 테스트를 수행했습니다.

Kafka Official Site에서는 Zookeeper Cluster를 독립 Machine에서 사용할 것을 권고하고 있으나, 테스트 장비의 한계상 Broker Machine과 함께 구성하였습니다.

2.6. 테스트 제한사항

Broker의 수를 증가시키기 위해 예비 테스트를 수행해 본 결과 간단한 설정값이 Broker 성능에 큰 영향을 미칠 수 있음을 확인했습니다. 객관성있는 테스트를 위해 서버의 설정값과 테스트 변수들은 고정하였습니다.

본 테스트에 사용된 모든 Producer와 Broker Machine에서는 Kafka 0.8.0 Stable Release 버젼을 이용하여 테스트를 수행하였습니다.

Broker의 환경설정 파일은 아래 내용과 같습니다.

Kafka에서 제공하는 Performance 도구는 아래 명령으로 실행하였습니다.

여기서 중요한 설정은 producer.type인데 async로 설정하였습니다. 명령어에서는  producer.type에 관한 내용이 생략되어 있으며, 옵션이 없을시 async로 동작합니다.

비동기 모드(async)는 Throughput 측면에서 Kafka의 성능을 최대한 활용할 수 있어 필수적입니다. 이 모드에서 각 Producer는 Broker에게 chunk 단위로 메세지를 보내기 위하여 In-memory queue를 가지며, 미리 설정된 Batch Size나 Time Interval에 도달하면 batch로 메세지를 전송합니다. 이는 압축을 훨씬 더 효율적으로 만들며, 네트워크도 더 효율적으로 사용할 수 있는 장점이 있습니다.

알려진 Use-Case에 따르면 Topic의 수가 증가함에 따라 Throughput의 변화가 없었기 때문에 구성된 Broker Cluster에서 topic은 1개로 지정하였고, Kafka는 Broker Cluster에 Replication 기능을 지원하여 데이터의 안정성과 신뢰성을 보장할 수 있지만, 모든 메세지에 대해 Broker로부터 답신 응답(acknowledgement response)를 기다리게 됩니다. 이에 따라, Throughput의 효율성 측면에서는 처리속도가 느려진다는 단점이 있어 본 테스트에서는 Replication 기능을 사용하지 않았습니다.

본 포스팅에 언급되지 않은 모든 기타 설정들은 Default Setting으로 설정하였습니다.

2.7. 테스트 결과

- Test 1. Broker 수 증가에 따른 Throughput (SSD)

Broker의 수가 증가함에 따라 Throughput이 증가하는 모습을 확인하였습니다.

Broker가 1대에서 2대로 증가시 약 33%의 Throughput이 증가하였고, 2대에서 3대로 증가시 약 28% Throughput이 증가하고 있습니다.

- Test 2. Broker 수 증가에 따른 Throughput(HDD)

SSD를 사용할때보다 Throughput이 확연히 낮아진 모습을 보여주고 있습니다. 하지만, Broker의 수가 증가함에 따라 Throughput이 증가하는 모습을 보여줍니다.

Broker가 1대에서 2대로 증가시 약 75% Throughput이 증가하였고, 2대에서 3대로 증가시 약 26% Throughput이 증가하였습니다.

Kafka Official Site에서는 디스크의 IO성능이 Kafka Broker의 성능에 큰 영향을 미칠 수 있음을 언급하고 있습니다. 앞서 수행한 Test 1과 Test 2를 비교하여 SSD와 HDD를 장착하였을 경우의 성능을 비교해 본 그래프는 아래와 같습니다.

SSD 사용시 HDD 대비 최대 2.7배 Throughput이 향상되는 것을 확인했습니다.

 - Test 3. 최대 처리량 측정 테스트

Producer 4대 / Broker 5대의 구성에서 초당 최대 처리량인 129.7MB/sec를 측정하였습니다.

3. Conclusion

위의 테스트를 통해 얻은 수치에 근거하여 얻은 결론은 아래와 같습니다.

1. Broker 수 증가에 따라 Throughput이 증가한다(1대->2대 : 33%, 2대->3대: 28%, SSD 사용시).

2. SSD를 사용하는 것이 HDD를 사용하는 것보다 우수한 성능을 보인다(최대 2.7배).

3. Producer 4대 / Broker 5대의 구성에서부터 Gigabit 대역폭에 가까운 Throughput을 보인다(129.7MB/sec).

기본적으로 Broker 수 증가에 따른 Scaling이 이루어지는 모습을 확인할 수 있었습니다. 다만, Broker Machine의 수를 증가시키는 비율대로 Throughput이 향상되지는 않고 있어서(1대->2대: 33% 증가, 2대->3대: 28% 증가, SSD 사용시), Broker Machine의 추가에 따른 비용 대비 성능비는 그리 높지 못하다고 보여집니다. 
따라서 Broker Machine의 무조건적인 추가보다는 topic 별로 Broker Machine을 분리하여 운영하는 방식이 더 효율적이라고 생각합니다.

Kafka는 기본적으로 Sequential Access를 사용합니다. 이 때문에, 일반적으로 HDD에 비해 2배정도 Disk IO가 좋은 것으로 알려진 SSD가 최대 2.7배 높은 성능을 보여주고 있습니다. Kafka 도입시 Machine의 Disk의 성능에 대해 충분히 고려해야 합니다.

최대 Throughput 측정에 있어서는 장비 구성의 물리적 제약 때문에 Saturation Point를 측정하지는 못하였습니다.  다만 Producer 4대와 Broker 5를 사용하여 총 9대의 장비를 구성하였을 경우, 129.7MB/sec가 측정되어 Gigabit 대역폭에 가까운 Throughput을 확인하였습니다.

※ Embian은 본 포스팅에 대한 Feedback을 환영합니다. 만약 포스팅 내용에 대한 문의사항이 있으시다면, 블로그 하단 Comment 또는 이메일(zoe@embian.com)을 통해 연락주시면 Feedback을 드리도록 하겠습니다.

[Reference]

1. Apache Kafka Official Site - http://kafka.apache.org/

2. Kafka: A Distributed Messaging System for Log Processing, Jay Kreps, Neha Narkhede, Jun Rao from LinkedIn, at NetDB workshop 2011

3. Building LinkedIn’s Real-time Activity Data Pipeline, Ken Goodhope, Joel Koshy, Jay Kreps, Neha Narkhede, Richard Park, Jun Rao, Victor Yang Ye

4. KAFKA 0.8 PRODUCER PERFORMANCE, Piotr Kozikowski, Apr 8 2013

5. Performance testing, Added by Jay Kreps, last edited by John Fung on Jan 29, 2013

6. Tom's Hardware - Benchmark Results: Sequential Read/Write, By Patrick Schmid and Achim RoosOCTOBER 6, 2011 10:00 PM

2014년 3월 14일 발표 자료입니다.

이전다음

012345678910111213141516

이번 PT에서의 개선할점은

1. 데모할때 꼭 데모 시나리오를 준비

2. overview에서 큰 그림을 먼저 보여주기

3. 퍼포먼스 테스트 할때는 반드시 테스트 환경에 대해 기술

등이 있었습니다.

2014년 3월 5일 발표 자료 입니다.

이전다음

012345678910111213141516171819202122232425262728293031323334353637

이번 PT에서의 이슈사항으로는

1. 정확한 PT제목

2. 맞춤법 

3. 문단 정렬

4. 전체 슬라이드 구성의 통일성 유지

등이 있었습니다. 

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의 새로운 버전이 나왔고, 이에 대한 글은 여기를 참조하시면 됩니다.

Scalable CEP System(가칭) 개발

Storm&Esper Team

2014.2.14

2014년 2월 14일에 발표한 자료입니다.

이전다음

012345678910111213

Scalable CEP System(가칭) 개발

Storm&Esper Team

2014.1.17

개발 2본부에서 진행하고 있는 Scalable CEP System을 개발하며 산출되는 중간보고 자료 및 이슈사항들을 앞으로 블로그에 공개하려고 합니다.

본 포스트에 공개된 자료는 2014년 1월 17일에 발표한 자료입니다.

이전다음

012345678

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

이러한 한계를 극복하기 위하여 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을 쉽게 구현할 수 있을 것이다.

현재 서비스 중에 있는 시스템중 전부, 또는 일부를 Amazon AWS(Amazon WebService) 환경으로 이전 할 수 있는지 가능성을 타진하기 위한 프로젝트의 일환으로, 표면적으로 가장 문제가 될것으로 보이는 네트워크 속도에 대한 테스트를 진행했다.

현재 Amazon AWS의 실제 서버가 위치한 곳은 북중미 3곳(Virginia, Oregon, California) 유럽 1곳(Ireland),  남미 1곳(Sao Paulo), 아시아 3곳(Singapore, Japan, Sydney), 총 8곳의 region이 있다.

사용자는 이 8곳 중에서 원하는 곳 어디서든 인스턴스(서버VM)를 생성할 수 있지만, 각 지역마다 네트워크 속도의 편차가 심하기 때문에 주력으로 서비스하고자 하는 곳에서 네트워크 속도가 가장 잘 나오는 곳을 선택해서 사용하는 것이 효율적이다.(region 마다 사용비용은 조금씩 차이가 있다.)

이번 테스트에서는 일본지역을 사용하였는데, 각 지역별로 ping test를 따로 진행한 결과, 일본 지역이 사용하기에 가장 무난한 곳으로 판단되었다.

1. Ping(Network Latency) test

Ping test를 통해 각 지역별 latency를 측정해 보았다.

테스트는 http://cloudping.info(Amazon region별 ping test site) 사이트를 이용해 진행했으며, Client의 회선 제공 업체에 따라 결과가 다를 수 있기 때문에 주위에 테스트 가능한 회선을 최대한 모아서 각각 테스트 해보았다.

[표 1.1] Amazon region 별 latency test 결과 (주황색 셀은 1위 region)

위의 표를 보면 KT(전용회선)을 제외한 모든 곳에서 Japan지역이 가장 빠른 Latency를 보여주는 것으로 나타난다. 

그리고 KT(전용회선)도 Japan 지역이 1위는 아니지만 1위 지역과 차이가 거의 나지 않으며, KT를 제외한 다른 지역은 1위와 2위의 차이가 제법 나는 것을 확인할 수 있다.

한국에서는 테스트를 한 시점(2013년 12월)에서 광범위한 인터넷 서비스를 위해서 Amazon을 사용해야 한다면, 전 세계 8곳의 region 중 Japan을 사용하는 것이 가장 안정적인 Network Latency를 보장 받을 수 있을 것으로 판단된다.

2. HTML page(정적 콘텐츠) loading test

HTML로만 이루어진 정적 페이지의 로딩 속도를 측정해 보았다.

Amazon region은 latency test 결과에 의해 Japan지역을 선택했으며, 비교를 위해 국내 Cloud 서비스중 KT uCloud와 IDC에 있는 실제 서버를 함께 테스트 해보았다.

테스트에 사용한 HTML page의 size는 약 142K 정도이며, KT 전용회선을 사용하고 있는 PC에서 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균을 서로 비교하는 방식으로 진행했다.

[그림 2.1] HTML page loading test 결과 그래프

3. 외부(국내 IDC) 리소스를 경유할 경우에 대한 test

일부 리소스(예를 들어 DB 서버)를 국내 IDC에 두고 메인 시스템을 Amazon에 구축했을 경우, 페이지 로딩 속도가 얼마나 떨어지는지 확인을 위해 관련 테스트를 진행했다.

테스트는 국내IDC의 웹페이지를 읽어들인 다음, 그 내용을 그대로 재출력하는 페이지를 만들고, 정적 페이지 테스트처럼 각각 20번씩 페이지를 호출해서 나온 load time과 latency의 평균값을 비교하는 방식으로 진행했다.

[그림 3.1] 외부(국내 IDC) 리소스를 경유할 경우에 대한 test 결과