입사 후 교육과정의 하나였던 "The Art of Application Performance Testing"이라는 책을 읽은 후, 개발자라면 한 번쯤은 읽어보면 좋은 내용이라고 생각되어 이 책을 주제로 두 번에 걸쳐서 포스팅하겠다.
일단 이 책은 원서였고, 초보 개발자의 눈에는 기술된 용어 자체가 무슨 뜻인지 모르는 것들이 너무 많아서 책이 무슨 말을 하는지 파악하기가 힘들었다. 하지만 책을 다 읽고 난 후에 내 머릿속에 남은 것은 퍼포먼스
테스팅을 절대로 무시하면 안 되는 단계라는 것이었다.
먼저 이 책을 읽고 난 초보 개발자 레벨에서 소감을 얘기하자면,
퍼포먼스 테스팅은 프로그램의 질을 향상해준다.
프로그램 성능을 뒷받침해주는 자료가 된다
사용자의 프로그램 사용 만족도를 올려준다.
다시 말해 퍼포먼스 테스팅은 프로그램을 안정적이게 만들어주고 사용할 때 편하게 해줌으로써 사람들이 믿고 쓰게 되는 동시에 그 프로그램을 만든 회사의 로열커스터머가 발생할 수 있다고 생각했다. (예를 들자면 애플 제품만 사용하는 사람들이라든지, 아니면 애플을 매우 사랑하는 사람들이라든지)
이 책에서 제시한 체크리스트들을 통하여 퍼포먼스 테스팅 가이드라인을 잡는 데 도움이 될 수 있는 내용을 소개하고자 한다.
I.왜 퍼포먼스 테스트를 하는가?
이 책의 저자는 "퍼포먼스를 위한 테스팅의 중요함은 고려해볼 사항이 아닌 어플리케이션을 만드는 과정 일부로서의 가치를 지니고 있다." 라고 말하고 있다. 즉, 퍼포먼스 테스트는 선택이 아닌 필수가 되어야 한다는 것이다. 그러면 왜 우리는 퍼포먼스 테스트를 해야 하는가? 답은 간단하다. 뛰어난 성능을 보여주는 어플리케이션은 기업에 이윤을 창출해 주기 때문이다.
퍼포먼스 테스트의 종류는 크게 서비스 지향적 측정(유용성과 응답 시간)과 효율 지향적 측정(처리량과 이용률)으로 나눌 수 있다. 서비스 지향적 측정이라 함은 "사용자에게 서비스를 얼마나 잘 제공하는가?" 라고 정의할 수 있고, 효율 지향적 측정은 "자원을 얼마나 잘 활용하는가?" 라고 정의 할 수 있다.
퍼포먼스 테스팅은 이 두가지의 큰 틀 안에서 퍼포먼스 테스팅 전, 하는 도중, 그리고 하고 나서의 단계로 구분 지을 수 있다.
그러면 이제 퍼포먼스 테스팅을 하기 전에 고려할 사항에 대하여 이야기해 보겠다.
II. 효과적인 어플리케이션 퍼포먼스 테스트의 기초
성능 요구 사항을 확실히 하는 단계.
효과적인 어플리케이션 퍼포먼스 테스트를 위하여 새로운 프로젝트에 대해 우리는 다음의 사항에 대하여 질문해야 할 것이다.
사용자들이 어디에 배치되어야 하는가? 그리고 그들이 어플리케이션에 어떻게 연결되어야 하는가?
어플리케이션을 배포 했을 때 얼마나 많은 사용자가 존재하는가? 6개월 후? 12개월 후? 2년 후에는 어떠한가?
위의 질문에 대한 답은 다음과 같은 질문으로 이어 진다.
각각의 어플리케이션 계층을 위하여 얼마나 많은 서버의 스펙이 필요한가?
어떤 종류의 네트워크 인프라 스트럭쳐를 준비해야 하는가?
물론 이러한 질문들에 대하여 즉시 답할 필요는 없지만, 가능성과 퍼포먼스라는 두 가지의 중요한 관점을 미리 생각해야 할 것이다.
퍼포먼스 테스팅 계획을 구성할 때 많은 요소에 대하여 고려해야 하겠지만, 이 책의 저자는 다음과 같은 항목들을 중요하게 짚고 넘어가야 한다고 기술하였다.
1. 적절한 테스팅 툴 선택
적합한 성능 테스트 툴을 고른다.
테스팅 툴 설계 (자동화 테스팅툴들은 다음과 같은 구성을 가지고 있다.)
스크립팅 모듈
테스트 매니지먼트 모듈
로드 인젝터
분석 모듈
퍼포먼스 테스팅 툴은 다음에 소개되는 항목들을 포함해야 한다.
툴 공급업체의 지원
라이센싱 모델
Proof of Concept (POC)
스크립팅 노력
솔루션 VS 로드 테스팅 툴
자체 제작 또는 아웃소스
2. 적절한 테스트 환경을 디자인
테스트 환경은 최대한 실제 환경과 유사하게 만든다.
서버의 숫자와 사양
대역폭과 네트워크 인프라스트럭처의 연결
어플리케이션 계층의 숫자
어플리케이션 데이터베이스의 크기 조정
테스트를 할 가상 환경 구비
테스트 가상환경에 대한 체크리스트
서버 갯수
로드 밸런싱 스트레티지
하드웨어 목록
소프트웨어 목록
어플리케이션 구성 목록
외부 링크
3. 현실적인 성능 목표를 설정
경영자와 그 외의 사람들간의 합의점 도출
핵심성능 목표 설정
유용성 또는 가동시간
동시성, 확장성, 그리고 처리량
반응시간
네트워크 사용률 (데이터 볼륨, 데이터 처리량, 데이터 에러 비율을 측정)과 서버 사용률(CPU사용률, 메모리 사용률 ,디스크 입출력, 디스크 공간을 측정)은 성능에 따른 용량의 지표에 사용될수 있다.
4. 퍼포먼스 테스트를 하기에안정적인 버전의 어플리케이션 준비
5. 코드 프리즈를 얻음
6. 비즈니스에 중요한 트랜잭션을 식별 및 스크립팅
트랜잭션 체크리스트
탐색 경로에 대한 모호성이 없도록 각 실행 단계를 정의 및 문서
모든 입력 데이터 요구사항과 예상되는 응답을 확인해야한다.
트랜잭션에 연관된 사용자의 타입을 결정한다.
이 트랜잭션을 위한 커넥티비티 패스가 무엇인가?
활성 트랜잭션일것인가 수동 트랜잭션일것인가?
트랜젝션 리플레이 검증
단일 사용자 리플레이
다중 사용자 리플레이
7.고품질의 테스트 데이터를 준비
인풋데이터 - 트랜젝션에 입력할 데이터
예) 자용자 자격증명, 검색 기준들, 관련 문서들
타겟 데이터 - 현실적인 분량의 유효 데이터를 이용하여 채울 수 있는 데이터.
예) 사이징, 데이터 롤백
런타임 데이터 - 퍼포먼스 테스트를 실행할때 사용되는 데이터
데이터 시큐리티 - 보호되어야 할 데이터에 대한 툴을 사용
8. 정확한 퍼포먼스 테스트 디자인을 보장
각종 종류의 테스트를 만들어야 한다.
베이스라인 테스트
로드 테스트
스트레스 테스트
흡수 또는 안정성 테스트
스모크 테스트
아이솔레이션 테스트
9. 서버와 네트워크 모니터링 KPI를 식별함
제너릭 템플릿
프로세서 이용 비율
Top 10 프로세서
byte 단위의 사용 가능한 메모리
초당 페이지 메모리
물리 디스크: %디스크 타임
네트워크 인터페이스 : 패킷 리시브드 에러
웹과 어플리케이션 서버 계층
IIS (Microsoft Internet Information Server)
Oracle application server (OC4J)
Oracle WebLogic (JRockit)
IBM WebSphere
JBOSS
데이터베이스 서버 계층
Microsoft SQL Server
Oracle
IBM DB2
MySQL
Sybase
Informix
메인프레임 계층
Strobe from Compuwave Corporation
Candle from IBM
10. 효과적인 퍼포먼스 테스트를위하여 충분한 시간을 할애
비지니스 트랜젝션 식별과 스크립트하는 시간
충분한 테스트 데이터 식별하고 만드는데 시간
테스트 환경 도구 준비 시간
퍼포먼스 테스트 준비하고 실행시키는데 들어가는 시간
확인된 문제점을 해결하는 시간
우리는 이처럼 여러단계와 세세한 사항들이 퍼포먼스 테스트를 하기 위한 고려대상임을 알았다.
자, 이제 우리는 겨우 퍼포먼스 테스트를 시행하기 전 기초에 대해 준비가 되었다. 너무 많은 양의 준비가 필요하다고 생각되어지나? 어플리케이션의 운명을 좌우한다고 말할 수 있는 퍼포먼스 테스팅은, 이 많은 양의 준비과정을 거쳐 퍼포먼스 테스트를 좀더 효과적이고 짜임새 있게 만들어 준다.
그러면 다음 포스팅에서는 퍼포먼스 테스트의 과정과 결과 분석에 대하여 기술하도록 하겠다.
참고자료 : "The Art of Application Performance Testing" by Ian Molyneaux
조석현(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를 도입하여 사용하고 있습니다.
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의 목적은 아래와 같이 정의하였습니다.
1. Broker 수 증가에 따른 Kafka의 분산처리 성능 확인
2. Kafka의 Network 대역폭 한계 Throughput 관찰
3. SSD vs HDD의 Throughput 비교
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은 아래와 같습니다.
OS : Ubuntu Desktop 12.04( Precise Pangolin) 64bit
여기서 중요한 설정은 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을 드리도록 하겠습니다.
