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

본 글은 Apache Jmeter와 Locust에 대해서 비교한 글입니다.

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

Jmeter와 Locust 소개

Jmeter는 가장 먼저 출시된 성능 테스트 프레임워크중에 하나입니다. 순수 자바로 작성되었습니다. Jmeter는 Web 및 FTP 관련 어플리케이션의 부하 테스트를 수행할 목적으로 제작되었습니다.

그러나 현재에는 거의 모든 어플리케이션과 프로토콜을 테스트할 수 있기에 다양한 OS 플랫폼위에서 동작되는 어플리케이션을 테스트 할 수 있습니다.

Locust는 Python으로 작성된 성능 테스트 프레임워크입니다. 가장 큰 특징은 Python으로 성능 스크립트를 작성할 수 있다는 점입니다.

코드로 작성하여 테스트하는 기능외에도 Event 기반 구현 확장성이 뛰어나기에 Jmeter에 비해 빠르게 성장하는 커뮤니티를 보유하고 있습니다.

오픈소스 라이선스

Jmeter는 Apache에 의해 개발되었고 Apache License 2.0을 기반으로 하며, Locust는 커뮤니티 주도 개발로 이루어졌고 MID 라이센스를 기반으로 합니다.

두 가지 모두 오픈 소스이기에 사용상의 제약없이 자유롭게 사용할 수 있습니다.

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

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

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

Jmeter는 직관적이고 경험이 없는 엔지니어 일지라도 큰 문제없이 기본적인 시나리오를 작성할 수 있도록 되어 있습니다. 그리고 비 GUI 모드에서 Java를 사용하여 코드를 작성할 수 있습니다.

하지만 Jmeter에서는 스크립트 구현의 복잡성(Jmeter가 GUI모드를 쓰도록 설계 되었기 때문에)과 스크립트 작성 방법에 대한 문서가 부족하기에 이 방법을 널리 사용하지는 않습니다.

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

Locust에서 작성된 스크립트는 명확해보이지만 거대하고 복잡한 테스트를 수행할 경우, 스크립트 작성 및 검토가 복잡할 수도 있습니다.

하지만, 코드로 모든 테스트를 수행하는 것은 큰 이점입니다. UI가 없어도 테스트를 쉽게 수정할 수 있기 때문입니다.

그리고 작성한 스크립트를 Git을 이용하여 공유하고 변경 사항을 관리하고 함께 작업할 수 있습니다.

테스트 스크립트를 유지 보수를 해야 한다면 코드 기반이 훨씬 더 빠르고 편리하다고 볼 수 있습니다.

지원 프로토콜

테스트에서 가장 이상적인 부분은 “가장 적은 테스트 툴을 사용하여 모든 것을 테스트 할 수 있어야 한다.”입니다.

서로 다른 프로토콜 테스트를 위해 다른 툴을 사용해야 한다면, 여기에 들어가는 시간과 관련 툴에 해박한 엔지니어 소싱등등의 문제가 나올 것 입니다.

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

Locust는 HTTP Web 기반 테스트를 위해 제작되었습니다. 그러나 기본 기능을 확장하고 Python을 사용하여 테스트할 수 있는 모든 것을 만들 수 가 있습니다.

즉, 원하는 모든 것을 테스트 할 수 있지만, 필요시 Custom 스크립트와 프로그래밍 경험이 있어야 합니다.

동시 사용자 수

성능 테스트 툴은 테스트 목표를 달성하기 위해 필요한 만큼의 Request를 실행할 수 있어야 합니다.

특정 상황에서는 수천 또는 수백만명의 사용자를 시뮬레이션해야 합니다.

각 도구가 실행할 수 있는 동시 사용자 수는 대부분 리소스를 기반으로 합니다. JMeter와 Locust는 리소스를 다루는 방법이 다릅니다.

JMeter는 각 사용자에 대해 별도의 Thread를 할당하는 Thread 기반 모델을 가지고 있습니다.

이러한 단계별 Thread 할당 방식은 할당될때마다 리소스를 필요로 하기에 JMeter는 한 대의 Worker에서 시뮬레이션 할 수 있는 사용자 수가 매우 제한적입니다.

일반적으로 스크립트가 단순하다면 하나의 Worker에서 Max 1,000개까지 Thread를 생성 할 수 있습니다.

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

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

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

Ramp-up에 대한 유연성

Flexible Ramp-up 기능은 어플리케이션의 사용 사례를 시뮬레이션 하는데에 매우 중요합니다.

예를 들어서, 테스트 중에 Spike-load를 작성하여 점진적 로드이외에 예기치 않은 Spike를 처리하는 방법을 확인할 수 있습니다.

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

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

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

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

Script Recording

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

Locust는 이 기능이 존재하지 않습니다.

부하 테스트 모니터링

JMeter와 Locust는 모두 성능 테스트를 모니터링하고 결과를 분석 할 수 있는 내장 기능을 제공합니다.

JMeter에는 많은 내장 Listener가 존재하며 Custom Listener를 확장 할 수 있습니다. 다만 JMeter Listener는 많인 리소스를 요구합니다.

Locust는 기본 부하를 모니터링하는 유용한 모든 정보를 제공합니다. 스크립트를 수행하는 동안 Locust는 모든 모니터링 결과를 볼 수 있는 간단한 웹서버를 실행합니다.

JMeter와 비교하여 Locust 모니터링은 많은 리소스를 요구하지 않습니다.

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

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

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

어떤 툴이 적합할까요?

참조: https://dzone.com/articles/jmeter-vs-locust-what-to-use-when

Read More

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에 영향을 준다는 의미인듯…

Source: https://www.slideshare.net/briantarbox/2012-ncta-motorolaintelligent-caching-and-packaging-in-an-abr-multiformat-cdn-tarboxfinal

Read More

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

본 글은 넷플릭스의 Tech블로그의 내용과 개인적인 의견을 포함하여 작성했습니다. (참조: https://medium.com/netflix-techblog/netflix-and-fill-c43a32b490c0)

새로운 콘텐츠가 출시 되면 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를 운영하고 그 남는 비용으로 콘텐츠를 제작하겠다 아닐까?

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

• https://www.youtube.com/watch?v=KtSBbsSwq-g
• https://johannesbergsummit.com/wp-content/uploads/sites/6/2014/11/Monday_8_David-Fullagar.pdf

Read More

NGINX based vod packager 소개

 

일반적으로 NGINX Level에서는 HLS,DASH Streaming을 지원해준다. 이 부분은 굳이 NGINX가 아니더라도 Tomcat container와 같은 Application Server에서는 일반적으로 지원해주고 있다. (HTTP requst range 기반으로 작동되므로…)

하지만, Media Streaming을 위해서는 기본적인 Streamer 기능 외에 필요한 부분들이 있다. NGINX의 경우에는 이런 부분들을 3rd party 개발자분들이 module을 제작하여 Github를 통해 공개하고 있다.

NGINX에서 가장 유명한 VOD module은 nginx-rtmp-module이지만, 본 글에서는 nginx-vod-module에 대해서 다루고자 한다.

Features

• On-the-fly repackaging of MP4 files to DASH, HDS, HLS, MSS
• Working modes:
• Local: serve locally accessible files (local disk/NFS mounted)
• Remote: serve files accessible via HTTP using range requests
• Mapped: serve files according to a specification encoded in JSON format. The JSON can pulled from a remote server, or read from a local file
• Adaptive bitrate support
• Playlist support — mapped mode only
• Simulated live support (generating live stream from MP4 files) — mapped mode only
• Fallback support for file not found in local/mapped modes (useful in multi-datacenter environments)
• Video codecs: H264, H265 (DASH/HLS), VP9 (DASH)
• Audio codecs: AAC, MP3 (HLS/HDS/MSS), AC-3 (DASH/HLS), E-AC-3 (DASH/HLS), OPUS (DASH)
• Playback rate change — 0.5x up to 2x (requires libelcodec and libavfilter)
• Support for variable segment lengths — enabling the player to select the optimal bitrate fast, without the overhead of short segments for the whole duration of the video
• Clipping of MP4 files for progressive download playback
• Thumbnail capture (requires libavcodec)
• Decryption of CENC-encrypted MP4 files (it is possible to create such files with MP4Box)
• DASH: common encryption (CENC) support
• MSS: PlayReady encryption support
• HLS: Generation of I-frames playlist (EXT-X-I-FRAMES-ONLY)
• HLS: support for AES-128 / SAMPLE-AES encryption

생각외로 많은 기능을 제공해주고 있다. 물론 제약도 존재한다.

Limitations

• Track selection and playback rate change are not spported in progressive download
• I-frames playlist generation is not supported when encryption is enabled
• Tested on Linux only

Read More

HashiCorp사의 Consul, Consul Template 소개

HashiCorp에서 제공하는 Consul은 Service Discovery, Failure Detection, Multi Datacenter, KV Storage 기능을 제공합니다. HAproxy 혹은 Nginx와 같은 Software 기반의 Load Balancer를 Cloud 상에 구축한다고 가정해보면, 고려해야 할 사항은 아래와 같습니다.

• 부하량에 따라 LB가 Scale In/Out이 되어야 한다.
• 로드 밸런싱 대상이 되는 Backend 서비스가 Scale In/Out이 되면 LB의 Configuration이 실시간으로 변경되어야 하며, 각 LB에게 동기화가 되어야 한다.
• LB의 Health check가 수행되어야 한다.

이 정도로만 간추려봐도 LB하나를 도입하기 위해 해야할 일이 많아지게 됩니다. 분산 환경에서의 이러한 일을 처리하기 위해 예전에는 Apache Zookeeper를 이용하여 개발을 했었지만 이번에는 Consul을 이용해보기로 했습니다.

Apache Zookeeper와 HashiCorp의 Consul의 차이점은 아래와 같습니다.

Apache Zookeeper

• Written in Java
• Strongly consistent (CP)
• Zab protocol (Paxos like)
• Ensemble of servers
• Quorum needed (majority)
• Dataset must fit in memory

Zookeeper는 현재 많은 곳에서 활용되고 있지만, 몇가지 문제점을 지니고 있습니다.

Zookeeper : Problems

• Latency-dependent
• No multi datacenters support (very slow write)
• Client number limit (out of sockets)
• Designed to store data on the order of KB in size
• Possibly lost changes while reenabling watch
• TCP connection != service healthy (proxy)
• Change zk server is a problem

이러한 문제점들을 보완해서 나온 제품이 Consul입니다. Consul의 특징을 보시죠.

HashiCorp Consul

• Written in Go
• Service discovery
• Health checking
• Key / Value Store
• Multi datacenter support
• Agent / Server Concept
• Gossip protocol for all the nodes (discovery)
• Consensus protocol (Raft-based) for servers
• 3 consistency modes
• Access Control List (ACL)

Consul에서 제공하는 기능을 HAProxy에 적용을 해봤고 결과는 만족스럽습니다.

HAProxy는 GSLB or DNS RR로 상위 Client에서 접속을 시도하게 되게되고 이 경우 HAProxy를 HA구성(Active-Standby)을 해야 합니다.

HAProxy가 설치된 VM에 consul agent를 등록하고 별도의 config 파일을 만들어 HAProxy에 대해서 Health checking을 수행 합니다. LB 매커니즘이 Round Robin일 경우 HTTP로 health check를 하게되면 LB가 문제가 될 소지가 많기에, 저의 경우에는 별도의 script를 만들어서 health checking을 수행했습니다.

haproxy.cfg 파일을 중앙에서 관리하기 위해 haproxy.cfg.ctmpl 파일을 만들어 consul-template daemon을 구동합니다. haproxy.cfg.ctmpl내에 별도의 key를 만들어 이 정보를 Consul의 K/V store에서 관리 및 변경시 모든 node에 즉시 동기화가 됩니다.

이렇게 함으로써 HAProxy를 도입할때의 고려사항 중 일부가 해소가 되었습니다.

앞으로 남은 부분은 consul-ui에서 확인할 수 있는 alarm 및 기타 정보를 push 형태로 IaaS Management 쪽에 전달하는 부분만 보완하면 될 것 같습니다. consul-ui는 어디까지나 확인 용도이고 IaaS management tool과 Integration이 되어야 하기 때문입니다.

그동안 Zookeeper를 쓰면서 client number limit, TCP connection, store data design 부분에 대해서 고민이 있었는데, consul을 활용하면서 이런 부분이 어느정도 해소가 될 것으로 보여집니다.

관련하여 좋은 Tip이 있으면 같이 공유했으면 합니다.

Read More

외적 동기와 내적 동기

 

내적 동기란, 활동 자체에서 오는 만족과 즐거움 때문에 행동을 수반하는 능동적인 힘을 의미하며 외적 동기란, 활동을 함으로써 받게 되는 칭찬이나 상 때문에 행동을 수반하게 하는 수동적인 힘을 의미합니다.

일반적으로 회사에서는 인센티브(성과급)을 매개체로 직원들이 성과를 내도록 외적 동기를 부여합니다. 하지만, 이 보다 더 중요한 것은 일 그자체에서 오는 내적 동기를 부여하는 것이라고 생각합니다. 자신에게 선택권이 있으며 관련 기술과 지식을 갖추고 목표를 향해 나아가고 있다라는 느낌을 받을 때 열정적으로 일하게 되며, 이것이 내적 동기를 부여하는 것이라고 생각됩니다.

Read More

Best To-Do List 서비스

처음 사회 생활을 시작할 때 부터 업무 향상을 위해 여러 방법을 고민했었고, 그 중에 주로 사용해왔던 방법이 GTD(Getting Things Done) 였다. 얼마전까지 프로젝트내의 task관리 및 협업을 위해 아래에 언급된 서비스를 이용했다.

• Task 관리: Trello, Asana
• Communication: Slack, Glip

Task 관리 서비스들을 이용하면서 내가 느낀 사항들을 정리해보고자 한다. Trello와 Asana의 경우에는 UI가 직관적이다. 특히 Asana는 List 방식과 Beta 이긴 하지만, Trello와 같은 Kanban을 지원하기도 한다. 위 두 서비스를 사용하면서 느낀 부족한 점은

• One level Task 관리: Trello와 Asana는 One level의 Task관리를 지원한다. 물론 하나의 Task내에서 Sub task를 생성할 수 있지만, 직관적으로 한눈에 파악하긴 어려웠다. Sub task까지 포함해서 Two level 이하의 Task 관리는 지원하지 않는다.
• 직관적인 Kanban 이지만…, : Task를 생성할 때, 내가 해야 할 마우스 액션이 너무 귀찮았다. 물론 Asana의 List 방식에서는 큰 문제가 없었지만 Two level 이하는 지원하지 않기에…
• Outliner의 부재 : 위의 두 서비스에서는 Outliner를 지원하지 않는다. 물론 당연한 이야기이다. Task관리는 두 서비스를 이용하면서 Outliner는 Workflowy를 이용하는 방법도 있지만, 점점 관리해야 하는 서비스가 늘어나는 느낌이 들었다.

Outliner 방식을 지원하면서 Task관리를 할 수 있는 서비스가 있을까? 그래서 찾아봤다.

Workflowy

Outlines내에서 Deep level의 depth를 지원한다. 그리고 가장 유명한 서비스이다. 하지만 Document를 분리하여 관리하는 기능 부재로 인해 고려 대상에서 제외하였다.

Checkvist

Outlines내에서 Deep level의 depth를 지원하지만, 세련된 UX/UI가 오히려 나에겐 부담으로 다가왔다. iOS application을 아직 지원하지 않는다.

Dynalist

Outlines내에서 Deep level의 depth 지원 및 Folder/Document 관리 기능, Google Calendar sync 기능등 부족함이 없었다. 다만, iOS application을 현재 개발중이고 Checkbox가 항상 보이는 부분이 UI를 clunky하게 만든다.

Moo.do

Multi-level을 지원하고, Document 관리 기능 (Folder는 미지원, 이 부분이 아쉽다.) Google Calendar sync 기능, Gmail 연동 기능, Google Drive 연동 기능 그리고 iOS application 지원까지… 그리고 Checkbox에 대한 처리가 마음에 든다. 현재로써는 부족함이 없어 보인다. 결론은 Dynalist와 Moo.do 두가지중에 고민중이다. Moo.do가 가장 완벽한 기능을 제공해주고 있긴 하지만, Dynalist가 Trello에 생성한 Roadmap 보드를 보니 발빠르게 지원을 해줄 것 같은 느낌과 Moo.do에 비해 화면에 집중할 수 있는 UI 구성등이 끌린다.

당분간, 계속 고민을 할 것 같다.

Read More