Thursday, November 2, 2017

Jmeter vs. Locust 무엇을 써야 할까?

본 글은 Apache Jmeter와 Locust에 대해서 비교한 글입니다.
Apache Jmeter와 Locust는 현재 개발자 사이에서 가장 많이 알려진 인기있는 성능 테스트 도구입니다.


1.Jmeter와 Locust 소개

Jmeter는 가장 먼저 출시된 성능 테스트 프레임워크중에 하나입니다. 순수 자바로 작성되었습니다. Jmeter는 Web 및 FTP 관련 어플리케이션의 부하 테스트를 수행할 목적으로 제작되었습니다.
그러나 현재에는 거의 모든 어플리케이션과 프로토콜을 테스트할 수 있기에 다양한 OS 플랫폼위에서 동작되는 어플리케이션을 테스트 할 수 있습니다.

Locust는 Python으로 작성된 성능 테스트 프레임워크입니다. 가장 큰 특징은 Python으로 성능 스크립트를 작성할 수 있다는 점입니다. 
코드로 작성하여 테스트하는 기능외에도 Event 기반 구현 확장성이 뛰어나기에 Jmeter에 비해 빠르게 성장하는 커뮤니티를 보유하고 있습니다.

2.오픈소스 라이선스

Jmeter는 Apache에 의해 개발되었고 Apache License 2.0을 기반으로 하며, Locust는 커뮤니티 주도 개발로 이루어졌고 MID 라이센스를 기반으로 합니다.
두 가지 모두 오픈 소스이기에 사용상의 제약없이 자유롭게 사용할 수 있습니다.

3.로드 테스트 생성 및 유지 관리

성능 테스트를 하기 위한 단계는 생성, 실행, 분석이 존재합니다. 첫번째 단계가 가장 많은 시간을 소모하기에 이 부분에 대해서 비교를 하고자 합니다.

Jmeter에서 성능 테스트를 작성하는 가장 일반적인 방법은 GUI모드를 사용하는 것입니다. Jmeter GUI 모드는 한줄의 코드 작성없이 쉽게 테스트를 작성할 수 있는 Desktop Client를 제공합니다.

Jmeter는 직관적이고 경험이 없는 엔지니어 일지라도 큰 문제없이 기본적인 시나리오를 작성할 수 있도록 되어 있습니다. 그리고 비 GUI 모드에서 Java를 사용하여 코드를 작성할 수 있습니다.
하지만 Jmeter에서는 스크립트 구현의 복잡성(Jmeter가 GUI모드를 쓰도록 설계 되었기 때문에)과 스크립트 작성 방법에 대한 문서가 부족하기에 이 방법을 널리 사용하지는 않습니다.

반면, Locust는 모두 코딩으로 해결 해야 합니다. 성능 테스트 작성에 익숙해지기 위해서는 기본적인 Python 코딩 경험이 있어야 합니다.

Locust에서 작성된 스크립트는 명확해보이지만 거대하고 복잡한 테스트를 수행할 경우, 스크립트 작성 및 검토가 복잡할 수도 있습니다.
하지만, 코드로 모든 테스트를 수행하는 것은 큰 이점입니다. UI가 없어도 테스트를 쉽게 수정할 수 있기 때문입니다.
그리고 작성한 스크립트를 Git을 이용하여 공유하고 변경 사항을 관리하고 함께 작업할 수 있습니다.
테스트 스크립트를 유지 보수를 해야 한다면 코드 기반이 훨씬 더 빠르고 편리하다고 볼 수 있습니다.

4.지원 프로토콜

테스트에서 가장 이상적인 부분은 "가장 적은 테스트 툴을 사용하여 모든 것을 테스트 할 수 있어야 한다."입니다.
서로 다른 프로토콜 테스트를 위해 다른 툴을 사용해야 한다면, 여기에 들어가는 시간과 관련 툴에 해박한 엔지니어 소싱등등의 문제가 나올 것 입니다.

JMeter에서는 기본 제공 함수 및 다른 플러그인을 모두 사용하여 한 곳에서 모든 것에 대한 성능 테스트 제작이 가능합니다.

Locust는 HTTP Web 기반 테스트를 위해 제작되었습니다. 그러나 기본 기능을 확장하고 Python을 사용하여 테스트할 수 있는 모든 것을 만들 수 가 있습니다.
즉, 원하는 모든 것을 테스트 할 수 있지만, 필요시 Custom 스크립트와 프로그래밍 경험이 있어야 합니다.

5.동시 사용자 수

성능 테스트 툴은 테스트 목표를 달성하기 위해 필요한 만큼의 Request를 실행할 수 있어야 합니다.
특정 상황에서는 수천 또는 수백만명의 사용자를 시뮬레이션해야 합니다.

각 도구가 실행할 수 있는 동시 사용자 수는 대부분 리소스를 기반으로 합니다. JMeter와 Locust는 리소스를 다루는 방법이 다릅니다.
JMeter는 각 사용자에 대해 별도의 Thread를 할당하는 Thread 기반 모델을 가지고 있습니다. 
이러한 단계별 Thread 할당 방식은 할당될때마다 리소스를 필요로 하기에 JMeter는 한 대의 Worker에서 시뮬레이션 할 수 있는 사용자 수가 매우 제한적입니다.
일반적으로 스크립트가 단순하다면 하나의 Worker에서 Max 1,000개까지 Thread를 생성 할 수 있습니다.

Locust는 이벤트 및 비동기 접근 방식을 기반으로 합니다. Gevent 구현을 통해 Locust 프레임워크는 단일 시스템에서 수천 명의 동시 사용자를 시뮬레이션 할 수 있습니다.

아래는 JMeter와 Locust를 사용하여 50명의 사용자에 대해 동일한 테스트를 실행하여 리소스 사용량을 비교한 그림입니다.

동일한 시나리오에서 GUI 모드로 실행되는 JMeter는 Locust보다 30배 더 많은 메모리를 사용하고 있습니다.

6.Ramp-up에 대한 유연성

Flexible Ramp-up 기능은 어플리케이션의 사용 사례를 시뮬레이션 하는데에 매우 중요합니다.
예를 들어서, 테스트 중에 Spike-load를 작성하여 점진적 로드이외에 예기치 않은 Spike를 처리하는 방법을 확인할 수 있습니다.

JMeter와 Locust는 로드를 생성하는데 동일한 방법을 제공합니다. 성능 테스트 중에 사용할 사용자 수를 지정하고 이들이 얼마나 빨리 요청해야 하는지를 지정 할 수 있습니다.

JMeter에서는 지정된 필드의 "Thread Group" 컨트롤러에서 로드를 구성할 수 있습니다.

JMeter에서는 유연한 로드 구성을 위한 플러그인을 제공합니다. (Ultimate Thread Group)

이 부분이 JMeter가 지닌 장점중에 하나 입니다.

Locust는 성능 테스트 스크립트를 실행하면, Locust는 자동으로 http://locahost:8089 서버를 시작합니다. Web UI에서 입력 요소를 지정할 수 있습니다.

7.Script Recording

스크립트 레코딩은 기본적인 테스트 템플릿을 만드는 효율적인 방법입니다.  JMeter에는 스크립트 레코딩 기능이 내장되어 있고, 브라우저내에서 스크립트를 레코딩할 수 있는 확장 플러그인도 제공합니다.
Locust는 이 기능이 존재하지 않습니다.

8.부하 테스트 모니터링

JMeter와 Locust는 모두 성능 테스트를 모니터링하고 결과를 분석 할 수 있는 내장 기능을 제공합니다.
JMeter에는 많은 내장 Listener가 존재하며 Custom Listener를 확장 할 수 있습니다. 다만 JMeter Listener는 많인 리소스를 요구합니다.

Locust는 기본 부하를 모니터링하는 유용한 모든 정보를 제공합니다. 스크립트를 수행하는 동안 Locust는 모든 모니터링 결과를 볼 수 있는 간단한 웹서버를 실행합니다.
JMeter와 비교하여 Locust 모니터링은 많은 리소스를 요구하지 않습니다.

결론,
둘 중 어느 도구가 효과적인지 정리하기가 쉽지 않습니다.

JMeter
Locust
Operating System
Any
Any
Open Source
Yes
Yes
GUI
Yes, with non-GUI mode available
No
Execution Monitoring
Console
File
Graphs
Desktop client
Custom plugins
Console
Web
Support of "Test as Code"
Weak (Java)
Strong (Python)
In-built Protocols Support
HTTP
FTP
JDBC
SOAP
LDAP
TCP
JMS
SMTP
POP3
IMAP
HTTP
Integrated Host Monitoring 
PerfMon
No
Recording Functionality
Yes
No
Distributed Execution
Yes
Yes
Easy to use with VCS
No
Yes
Resources Consumption 
More resources required
Less resources required
Number of Concurrent Users
Thousands, under restrictions
Thousands
Ramp-up Flexibility
Yes
No
Test Results Analyzing
Yes
Yes

Python을 좋아하고 GUI보다 코드로써 작성하기 원하면 Locust로 진행하면 되고, 그렇지 않으면 JMeter가 더 나은 선택일 수 있습니다.

Locust는 기존 성능 도구의 특정 문제를 해결하기 위해 만들어졌습니다. Locust와 Python 코드 조합은 GUI 없이 유지 보수에 최소한의 시간을 할애하고 매우 느린 시스템에서도 수천 명의 테스트 사용자를 시뮬레이션 할 수 있습니다.
JMeter는Python을 잘 모르거나 GUI를 선호할 경우에 너 다은 선택지가 될 것입니다.

어떤 툴이 적합할까요?

Wednesday, September 27, 2017

Intelligent Caching and Packaging in an ABR Multi-format CDN

2012년에 나왔던 자료인거 같은데…
이전에 작성한 "Netflix, 그들의 콘텐츠 서비스 방식(Netflix and Fill)" 과 연관이 있어 보인다.

VOD를 처음 시작할때는 Caching이 필요하지 않았다. VOD가 초기 단계에 있었을 때 하나의 중앙 서버가 전체 노드를 지원했었고 콘텐츠는 SD 포맷으로만 제공 되었다. 한곳에서 콘텐츠를 관리했기에 Caching이 필요하지 않았다.

VOD가 많아짐에 따라 Caching이 필요하게 되었다. LRU는 지능형 Caching으로 진화했다.

Caching은 미래 행위를 예측하기 위해 과거 행위를 이용하려는 예측 활동이다. Caching은 삭제해야 할 콘텐츠를 결정하는 것이 중요하다. LRU는 사용 패턴에 관계없이 가장 오래동안 사용하지 않은 콘텐츠를 제거한다.
Intelligent Caching은 전체 시청 시간을 기반으로 추가 조회 가능성에 대한 통계적 추론 기법을 가미한다.

이 장표를 소개할 시점의 CDN Caching 알고리즘의 주류는 LRU

예측 가능성을 향상 시키기 위해서는 동일한 콘텐츠에 대한 모든 스트림 요청이 동일한 edge streamer로 전달되어야 하며, Cluster Manager를 사용하여 콘텐츠 요청 경로를 지정해야 한다. Netflix의 경우 Control Plain으로 보면 될듯

동일한 Cache에서 같은 콘텐츠를 스트리밍하면 count가 증가하고 네트워크 사용률이 감소한다. 이렇게 되려면 Cluster Manager가 Edge를 Referring 해야 한다.

LRU caching은 콘텐츠 및 콘텐츠 위치, usage에 대한 정보가 없다. 즉, 가장 최근에 사용된 콘텐츠를 결정하고 나머지는 제거한다.
Intelligent caching은 Edge에 콘텐츠를 잘 갖다 놓고 여러 매개 변수를 사용하여 Edge에 저장된 Chunk의 실제 가치를 평가하기에 보다 효율적으로 동작한다.

Caching은 패키징 옵션의 영향을 받는다는 의미인데, 어떤 방식으로 패키징하고 Origin에 어떤 모양으로 담겨 있는지에 따라 Caching에 영향을 준다는 의미인듯...

Monday, September 25, 2017

Netflix, 그들의 콘텐츠 서비스 방식 (Netflix and Fill)

본 글은 넷플릭스의 Tech블로그의 내용과 개인적인 의견을 포함하여 작성했습니다.

새로운 콘텐츠가 출시 되면 CP(Content Provider)로부터 넷플릭스내의 콘텐츠 운영팀으로 Digital Asset이 전달 됩니다.
이 과정에서 Netflix Platform에 통합하기 위해 필수적인 품질관리, 인코딩등 다양한 유형의 처리 및 개선이 이루어집니다. 이 단계가 끝나면 관련 Digital Asset (Bitrate, Caption)이 다시 패키징되어 Amazon S3에 배포 됩니다.
배포 준비가 된 S3의 콘텐츠는 콘텐츠 운영팀에 의해 metadata flag가 지정되며, 이 시점에서 Open Connect 시스템이 인계받아 OCA(Open Connect Appliance)에 콘텐츠를 배포하기 시작합니다.

Proactive Caching

Netflix의 Open Connect와 다른 CDN과의 가장 큰 차이점은 Proactive Caching입니다. 사용자들이 시청할 시간과 시청 시간을 높은 정확성으로 예측할 수 있기 때문에 구성 가능한 시간대 동안 non-peak bandwidth를 사용하여 예측한 콘텐츠를 OCA에 다운로드 할 수 있습니다. 다른 CDN은 이것이 불가능하고 범용적인 Delivery Service를 제공해야 하므로, LRU기반의 Caching을 선호하지요. CDN 사업자가 콘텐츠를 예측할 필요는 없으니까요. 그들은 미디어 사업자가 아니니까요.

OCA Clusters

Netflix의 Fill pattern이 어떻게 동작하는지 이해하려면 OCA가 IX에 위치하거나 ISP 네트워크에 포함되어 있는지 여부에 상관없이 OCA 클러스터를 구성하는 방법을 이해해야 합니다.

OCA는 manifest cluster로 그룹화 됩니다. 각 manifest 클러스터는 적절한 콘텐츠 영역(콘텐츠를 스트리밍 할 것으로 예상되는 국가 그룹), 인기도 피드(이전 데이터를 기준으로 간략하게 정렬된 콘텐츠 목록)로 구성되고 보유해야 하는 콘텐츠의 수를 표시합니다. Netflix는 국가, 지역 또는 기타 선정 기준에 따라 독립적으로 인기 순위를 계산합니다.

Fill cluster는 shared content영역과 인기 피드가 있는 manifest cluster의 그룹입니다. 각각의 fill cluster는 Open Connect 운영팀에 의해 fill escalation policies와 fill master의 수로 구성됩니다.

아래의 다이어그램은 동일한 Fill cluster내의 manifest cluster의 예를 설명합니다.

Fill Source Manifests

OCA들은 네트워크내의 다른 OCA에 대한 정보, 콘텐츠, 인기도등을 저장하지 않습니다. 모든 정보는 AWS Control Plain에 집계되고 저장 됩니다. OCA는 주기적으로 Control Plain과 통신하여 Cluster 멤버들에게 storing하고 serving해야 할 콘텐츠 목록이 포함된 manifest 파일을 요청합니다. AWS Control Plain은 여러 고수준 요소를 고려하여 ranked list를 다운로드 할 수 있는 location을 response합니다.
  • Title(Content) availability - Does the fill source have the requested title(content) stored?
  • Fill health - Can the fill source take on additional fill traffic?
  • A calculated route cost - Described in the next section. (아래 섹션에서 설명)

Calculating the Least Expensive Fill Source

S3(Origin)에서 모든 OCA에 직접 콘텐츠를 배포하는 것은 시간과 비용면에서 비효율적이므로 계층화된 접근법을 사용 합니다. Open Connect의 목표는 가장 효율적인 경로를 사용하여 콘텐츠를 전달하도록 하는 것입니다.
Least expensive fill source를 계산하기 위하여 각 OCA의 네트워크 상태 및 구성 매개변수를 고려합니다.
  • BGP path attributes and physical location (latitude / longitude)
  • Fill master (number per fill cluster)
  • Fill escalation policies

Fill escalation policies는 다음과 같이 정의합니다.
  1. OCA가 콘텐츠를 다운로드 하기 위해 갈 수 있는 hop 수와 대기시간
  2. OCA가 정의된 hop 이상으로 전체 Open Connect 네트워크로 이동 할 수 있는지 여부와 대기시간
  3. OCA가 S3(Origin)으로 갈 수 있는 여부와 대기시간

Control Plain은 Master로 지정된 OCA를 선택합니다. Master에 적용되는 fill escalation policies는 일반적으로 콘텐츠를 가져와서 non-master와 로컬로 공유하기 위한 지연시간을 줄여 최대한 멀리 도달 할 수 있게 합니다.
경로 계산에 대한 모든 입력이 주어지면, fill source 작업은 다음과 같이 작동합니다.
  1. Peer fill - Available OCAs within the same manifest cluster or the same subnet
  2. Tier fill - Available OCAs outside the manifest cluster configuration
  3. Cache fill - Direct download from S3

Example Scenario

Fill master OCA가 S3로 부터 콘텐츠 다운로드를 완료 한 후 Control Plain에 콘텐츠가 저장되었음을 보고 합니다.


그 다음 다른 OCA가 Control Plain과 통신하여 해당 콘텐츠의 fill source 요청을 보내면 Fill master에서 fill option이 제공됩니다.
    두 번째 계층의 OCA가 다운로드를 완료하면 상태를 보고하고 다른 OCA는 해당 콘텐츠에 대한 fill source 작업을 수행 합니다. 이 작업은 fill window내에서 계속 반복됩니다.
    더 이상 필요없는 콘텐츠는 delete manifest에 저장되고 일정 기간 후에 삭제됩니다.

    Netflix 사용자가 스트리밍을 시작하면 이 시간대의 fill source 작업이 끝나고, fill window가 다른 시간대로 이동하면서 fill source pattern이 계속 진행 됩니다. (Netflix는 글로벌 서비스이기에 각 지역별로 네트워크 유휴 시간대가 다름)

    Challenges

    Netflix는 항상 fill process를 개선하고 있습니다. Open Connect 운영팀에서는 내부 툴을 사용하여 Fill traffic을 지속적으로 모니터링합니다. member들에게 서비스를 제공해야하는 catalog의 임계값 비율을 포함하지 않는 OCA에 대한 alert이 설정되고 모니터링 됩니다. 이 경우에는 다음 Fill process 전에 해당 문제를 해결합니다. 신속하게 배포해야 하는 새로운 콘텐츠나 기타 수정 사항에 대해 주기적으로 fast-track fill을 수행 할 수 있습니다. 기본적으로 이러한 fill pattern을 사용하면서 배포 시간 및 프로세싱 시간을 줄입니다.

    Netflix는 190개국에서 운영되고 있으며 전 세계 여러 ISP 네트워크에 수천 개의 장비가 내장되어 있기에 ISP에 대한 대역폭 비용을 최소화 하면서 OCA에 최신 콘텐츠를 빨리 얻을 수 있도록 하는데에 집중하고 있습니다.

    끝으로

    Netflix가 일반적인 Caching(LRU, NRU)방식이 아닌 Proactive caching 방식을 택한 이유는 그들이 가지고 있는 Network를 온전히 서비스를 위해서 사용하기 위함으로 보여진다. NRU, LRU는 Proactive caching에 비해 Miss가 발생할 확률이 존재하기에 이러한 대역폭도 서비스적인 측면에서는 아깝다는 그들의 집착이 보여진다. Netflix는 일반 CDN업체가 아닌 미디어 사업자이기에 가능한 얘기가 아닐까? 결국 그들의 생각은 OCP는 비교적 저렴한 x86기반의 하드웨어를 쓰고 네트워크를 최대한 활용하여 가성비 있는 Open Connect를 운영하고 그 남는 비용으로 콘텐츠를 제작하겠다 아닐까?

    관련된 내용은 아래의 링크를 참조

    Thursday, September 7, 2017

    Monday, July 10, 2017

    틀리지 않는 법 - 수학적 사고의 힘

    그래, 표지에 꽂혔다. "세상을 더 깊게, 더 올바르게, 더 의미 있게 이해하는 법!"이라는 글귀에 현혹이 되었다. 책을 펼치기 전에 이 책에 대한 나의 기대를 몇 자 적는다.

    나는 수학을 잘 못한다. 학교때 정규 과정으로 배웠고, 학부에서도 전공을 하긴 했지만 잘 모른다. 이 책을 펼치기전에 문득 학부때 교수님이 하신 말씀이 떠올랐다. "여러분은 수학을 계산하는 것으로 알고 있지만, 그렇지 않아요. 수학은 이성적으로 사고하는 방식을 배우는 거에요." 교수님의 말씀을 이해한 친구들이 있었을까? 그 당시의 나는 이해하지 못했다.

    이제 나의 아이가 초등학생이 되었고 수학을 배우고 있다. 덧셈, 뺄셈을 배우면서 책에서 알려주는 규칙을 배우고 있다. 이미 이 규칙들은 선대에 의해 증명되었고 규칙화 되었다. 이런 규칙들을 알려주는 책은 아니겠지?
    교수님이 말했던 "수학적 사고방식" 즉, 더 나은 사고를 하도록 알려주는 책이길 바란다.