snetcat (Secure NetCat) 사용법


nc (netcat) 사용법 (윈도우용 nc 포함)

Secure netcat – 


usage: snetcat [OPTIONS] [<host> <port>]

-u              use UDP instead of TCP

-g              bind to INADDR_ANY

-o file         hexdump passed traffic to a file

-d Act as listening server, forking childs

-s certif Wrap the connection into SSL, using given certificate file

-l localport    listen on localport

-e prog         redirect stdin/stdout to program



Fetch web page

% echo -e “GET /index.html HTTP/1.0\n\n” | snetcat 80

Fetch web page via HTTPS

% echo -e “GET /index.html HTTP/1.0\n\n” | snetcat -s “” 80

Run port forwarder

% snetcat -l local_port remote_host remote_port

Turn web server on your machine to be HTTPS web server

% snetcat -l 443 -s CERTIFICATE.PEM -d 80

Mail client (sh script)


Simple web server (sh script)




>>>>> HTTP를 통해 페이지 가져오기

– 기본 페이지
echo -e “GET / HTTP/1.0\n\n” | snetcat 80

HTTP/1.1 200 OK

Date: Wed, 14 May 2014 07:35:12 GMT

Server: Apache/2.2.3 (CentOS)

Last-Modified: Wed, 19 Mar 2008 20:10:46 GMT

ETag: “23c1a8-64ce-448cfd92edd80”

Accept-Ranges: bytes

Content-Length: 25806

Connection: close

Content-Type: text/html; charset=UTF-8



<title>Bill Stearns’ web site</title>






– 특정 페이지

echo -e “GET HTTP/1.0\n\n” | snetcat 80

HTTP/1.1 200 OK

Date: Wed, 14 May 2014 07:36:46 GMT

Server: Apache/2.2.3 (CentOS)

Last-Modified: Thu, 18 Dec 2003 20:31:26 GMT

ETag: “23c369-2ecf-3cec71b8a6380”

Accept-Ranges: bytes

Content-Length: 11983

Connection: close

Content-Type: text/html; charset=UTF-8




<title>Netcat – network connections made easy</title>






넷플러스 스핀에이커

넷플릭스가 아마존웹서비스(AWS), 구글 클라우드 플랫폼, 마이크로소프트(MS) 애저 등의 퍼블릭 클라우드 서비스를 통합해 관리할 수 있는 데브옵스(DevOps) 소프트웨어를 오픈소스로 공개했다.

16일(현지시간) 미국 지디넷에 따르면, 넷플릭스는 구글, MS, 피보탈 등과 공동 개발한 클라우드 자원 관리도구 ‘스핀에이커(Spinnaker)’를 오픈소스로 내놨다.

스핀에이커는 그동안 넷플릭스가 수년간 개발해 AWS 자원 관리에 사용해온 아스가르드를 대체한 소프트웨어다. 넷플릭스는 아스가르드 운영을 지난 9월 완전히 중단하고, 스핀에이커로 전면 전환했다.

넷플러스 SURO

Announcing Suro: Backbone of Netflix’s Data Pipeline

by Jae Hyeon Bae, Danny Yuan, and Sudhir Tonse

To make the best business and technical decisions, it is critical for Netflix to reliably collect application specific data in a timely fashion. At Netflix we deploy a fairly large number of AWS EC2instances that host our web services and applications. They collectively emit more than 1.5 million events per second during peak hours, or around 80 billion events per day. The events could be log messages, user activity records, system operational data, or any arbitrary data that our systems need to collect for business, product, and operational analysis.

Given that data is critical to our operations and yet we allow applications to generate arbitrary events, our data pipeline infrastructure needs to be highly scalable, always available, and deliver events with minimal latency, which is measured as elapsed time between the moment when an event is emitted and when the event is available for consumption by its consumers. And yes, the data pipeline needs to be resilient to our own Simian Army, particularly the Chaos Monkeys.

While various web services and applications produce events to Suro, many kinds of consumers may process such data differently. For example, our Hadoop clusters run MapReduce jobs on the collected events to generate offline business reports. Our event stream clusters generate operational reports to reflect real-time trends. Since we may dispatch events to different consumers based on changing needs, our data pipeline also needs to be dynamically configurable.

Suro, which we are proud to announce as our latest offering as part of theNetflixOSS family, serves as the backbone of our data pipeline. It consists of a producer client, a collector server, and plugin framework that allows events to be dynamically filtered and dispatched to multiple consumers.

History of Suro

Suro has its roots in Apache Chukwa, which was initially adopted by Netflix. The current incarnation grew out of what we learned from meeting the operational requirements of running in production over the past few years. The following are notable modifications compared to Apache Chukwa:

  • Suro supports arbitrary data formats. Users can plug in their own serialization and deserialization code
  • Suro instruments many tagged monitoring metrics to make itself operations friendly
  • Suro integrates with NetflixOSS to be cloud friendly
  • Suro supports dispatching events to multiple destinations with dynamic configuration
  • Suro supports configurable store-and-forward on both client and collector

Overall Architecture

The figure below illustrates the overall architecture of Suro. It is the single data pipeline that collects events generated by Netflix applications running in either AWS cloud or Netflix data centers. Suro also dispatches events to multiple destinations for further processing.

Such arrangement supports two typical use cases: batched processing, and real-time computation.

Batch Processing

Many analytical reports are generated by Hadoop jobs. In fact, Suro was initially deployed just to collect data for our Big Data Platform team’s Hadoop clusters. For this, Suro aggregates data into Hadoop sequence files, and uploads them into designated S3 buckets. A distributed demuxing cluster demuxes the events in the S3 buckets to prepare them for further processing by Hadoop jobs. We hope to open source the demuxer in the next few months. Our Big Data Platform team has already open sourced pieces of our data infrastructure, such as Lipstick and Genie. Others will be coming soon. A previous post titled Hadoop Platform as a Service in the Cloudcovers this in detail:

Real-Time Computation

While offline/batch processing the events still form the bulk of our consumer use cases, the more recent trend has been in the area of real-time stream processing. Stream consumers are typically employed to generate instant feedback, exploratory analysis, and operational insights. Log Summaries of application-generated log data is an example that falls under this bucket. The following graph summarizes how log events flow from applications to two different classes of consumers.

  1. Applications emits events to Suro. The events include log lines.
  2. Suro dispatches all the events to S3 by default. Hadoop jobs will process these events.
  3. Based on a dynamically configurable routing rule, Suro also dispatches these log events to a designated Kafka cluster under a mapped topic.
  4. Druid cluster indexes the log lines on the fly, making them immediately available for querying. For example, our service automatically detects error surges for each application within a 10 minute window and sends out alerts to application owners:

5. Application owners can then go to Druid’s UI to explore such errors:

6. A customized ElasticSearch cluster also ingests the same sets of log lines, de-duplicates them, and makes them immediately available for querying. Users are able to jump from an aggregated view on the Druid UI to individual records on ElasticSearch’s Kibana UI to see exactly what went wrong.

Of course, this is just one example of making use of real-time analysis. We are also actively looking into various technologies such as Storm and Apache Samza to apply iterative machine learning algorithms on application events.

Suro Collector In Detail

The figure below zooms into the design of the Suro Collector service. The design is similar to SEDA. Events are processed asynchronously in stages. Events are offered to a queue first in each stage, and a pool of threads consume the events asynchronously from the queue, process them, and sends them off to the next stage.

The main processing flow is as follows:

  1. Client buffers events in a buffer called message set, and sends buffered messages to Suro Collector.
  2. Suro Collector takes each incoming message set, deflates it if possible, and immediately returns after handing the message set to Message Set Processor.
  3. The Message Set Processor puts the message set into a queue, and has a pool of Message Router threads that routes messages asynchronously.
  4. A Message Router determines which sink a message should go to. If there’s a filter configured for a message, the message payload will be deserialized.
  5. Each sink maintains its own queue, and sends messages to designated configurations asynchronously.

Performance Measurement

Here are some results from simple stress tests.

Test Setup

Test Results

The following table summarizes the test result after warm-up:

Suro Roadmap

The version open sourced today has the following components.

  • Suro Client
  • Suro Server
  • Kafka Sink and S3 Sink
  • Three Types of Message Filters

In the coming months, we will describe and open source other parts of the pipeline. We would love to collaborate with other solutions in the community in this domain and hope that Suro, Genie, Lipstick etc. provide some of the answers in this highly evolving and popular technology space.

Other Event Pipelines

Suro evolved over the past few years alongside many other powerful data pipeline solutions such as Apache Flume and Facebook Scribe. Suro has overlapping features with these systems. The strength of Suro is that it is well integrated into AWS and especially the ecosystem of NetflixOSS, to support Amazon Auto Scaling, Netflix Chaos Monkey, and dynamic dispatching of events based on user defined rules. In particular,

  • Suro client has built-in load balancer that is aware of Netflix Eureka, while Suro server also integrates with Netflix Eureka. Therefore, both Suro servers and applications that use Suro client can be auto scaled.
  • Suro server uses EBS and file-backed queues to minimize message loss during unexpected EC2 termination.
  • Suro server is able to push messages to arbitrary consumers at runtime with the help of Netflix Archaius. Users can declaratively configure Suro server at runtime to dispatch events to multiple destinations, such asApache Kafka, SQS, S3, and any HTTP endpoint. The dispatching can be done in either batches or real time.


Suro has been the backbone of the data pipeline at Netflix for a few years and has evolved to handle many of the typical use cases that any Big Data infrastructure aims to solve.

In this article, we have described the top level architecture, the use cases, and some of the components that form the overall data pipeline infrastructure at Netflix. We are happy to open source Suro and welcome inputs, comments and involvement from the open source community.

If building critical big data infrastructure is your interest and passion, please take a look at

텐서플로우 시작


텐서플로우(TensorFlow)는 기계 학습과 딥러닝을 위해 구글에서 만든 오픈소스 라이브러리


텐서플로우는 다음과 같은 특징을 가집니다:

  • 데이터 플로우 그래프를 통한 풍부한 표현력
  • 코드 수정 없이 CPU/GPU 모드로 동작
  • 아이디어 테스트에서 서비스 단계까지 이용 가능
  • 계산 구조와 목표 함수만 정의하면 자동으로 미분 계산을 처리
  • Python/C++를 지원하며, SWIG를 통해 다양한 언어 지원 가능


Unix 계열 OS에서는 아래의 명령을 실행하면 이미지를 받고 컨테이너가 실행됩니다. 컨테이너 실행 후 자동으로 컨테이너 안의 쉘 환경으로 들어가게 됩니다.

docker run -it

동작 확인

설치가 잘 되었는지 다음의 코드로 확인해봅니다.

$ python

>>> import tensorflow as tf
>>> hello = tf.constant('Hello, TensorFlow!')
>>> sess = tf.Session()
>>> print
Hello, TensorFlow!
>>> a = tf.constant(10)
>>> b = tf.constant(32)
>>> print

다음 기술에 대한 내용은 이곳을 참조



윈도우 GPU tensorflow 설치 및 그래픽카드별 성능 비교

TensorFlow 개발환경 ( Eclipse + PyDev, Pycharm, Jupyter)

기계 학습을 최대한 활용할 수 있는 오픈소스/머신러닝 프레임워크

아파치 스파크(Apache Spark) MLlib
아파치 스파크는 하둡) 제품군의 하나로 널리 알려져있지만, 이 인메모리(In-memory) 데이터 처리 프레임워크는 하둡 생태계가 아닌 다른 곳에서도 명성을 떨치고 있다. 오늘날 스파크는 빠른 속도의 인메모리 데이터에 적용할 수 있는 알고리즘 라이브러리가 늘어남에 따라 인기 높은 기계 학습 툴이 되었다.

아파치 싱가(Apache Singa)
‘딥러닝(Deep Learning)’ 프레임워크는 자연어 처리와 이미지 인식 등의 주요 기계 학습 기능에 활용된다. 최근 아파치 인큐베이터(Apache Incubator)에 수용된 싱가는,대용량 데이터로 딥 러닝 모델을 간편하게 학습할 수 있게 해주는 오픈소스 프레임워크다.

딥 러닝 프레임워크인 카페는 표현성, 속도, 모듈성을 염두에 두고 개발됐다. 2013년 머신 비전 프로젝트를 위해 개발된 카페는 그 이후로 언어 능력과 멀티미디어 등 다른 응용 분야도 포함할 수 있도록 확장됐다.

마이크로소프트 애저 ML 스튜디오(Microsoft Azure ML Studio)
필요한 데이터와 연산 능력의 수준을 고려할 때 클라우드는 ML 앱에 대한 이상적인 환경이다. 마이크로소프트는 애저에 월, 시간 단위로 과금하거나 무료로 제공하는 기계학습 서비스 애저 ML 스튜디오를 적용했다. 참고로 마이크로소프트의 하우올드로봇(HowOldRobot) 프로젝트가 이 시스템으로 개발된 것이다.

아마존의 일반적인 클라우드 서비스 접근방식은 일정한 패턴이 있다. 기본을 제공하고 관심이 있는 핵심 청중을 끌어들이며 이를 기초로 개발하도록 한 후에 그들이 정말로 필요한 것을 찾아 제공하는 것이다.

마이크로소프트 DMLT(Distributed Machine Learning Toolkit)
기계학습 문제에 컴퓨터를 더 많이 투입할수록 좋을 것이다. 그러나 여러 컴퓨터를 모으고 여기에서 ML 애플리케이션이 잘 구동되도록 하기란 쉽지 않은 작업일 수 있다. 마이크로소프트의 DMTK 프레임워크는 시스템 클러스터에서 다양한 기계학습 작업을 배포하는 문제를 해결해준다.

구글 텐서플로우(Google TensorFlow)
마이크로소프트의 DMTK와 마찬가지로 구글 텐서플로우는 복수의 노드에서 확장될 수 있도록 개발된 기계학습 프레임워크다. 구글의 퀴베르네시스(Kubernetes)와 마찬가지로 구글의 내부 문제를 해결하기 위해 개발됐는데, 이후 구글은 이를 오픈소스 제품으로 공개했다.

마이크로소프트 CNT(Computational Network Toolkit)
DMTK를 공개하여 이목을 집중시킨 마이크로소프트는 또 다른 기계학습 툴킷인 CNTK를 선보였다.

벨레스(Veles, 삼성)
벨레스는 딥러닝 애플리케이션을 위한 분산형 플랫폼이다. 텐서플로우나 DMTK와 마찬가지로 C++로 작성됐다. 그러나 노드 사이의 자동화와 조율을 수행하는 데에는 파이썬을 이용한다.

스위스의 루가노(Lugano, Switzerland)의 IDSIA(Institute Dalle Molle for Artificial Intelligence)에서 박사 과정을 밟고 있는 클라우스 그레프(Klaus Greff)와 루페시 스리바스타바(Rupesh Srivastava)가 2015년 한 해 동안 개발한 프레임워크다. 브레인스톰 프로젝트의 목표는 “DNN(Deep Neural Network)을 더 빠르고 유연하며 재미있게” 만드는 것이다. LSTM 등 다양한 순환형 신경망 모델을 위한 지원이 이미 포함되어 있다

엠엘팩 2(mlpack 2)
2011년에 공개된 C++ 기반의 기계학습 라이브러리가 엠엘팩이다. 해당 라이브러리 개발자는 “확장성, 속도, 사용 편의성”을 위해 이를 개발했다고 밝한 바 있다 . Mlpack 도입은, 약식의 경우 “블랙 박스(Black Box)” 작업을 위한 명령줄 실행 가능문 저장소를 통해 이뤄질 수 있으며, 좀더 정교하게는 C++ API를 통해 가능하다.

상대적으로 최근에 개발된 마빈 신경망 프레임워크는 PVG(Princeton Vision Group)의 제품이다. 해당 프로젝트의 문서에서 개발자들이 설명했듯이 “해킹당하기 위해” 개발됐다. C++과 CUDA GPU 프레임워크로 작성된 몇 개의 파일에만 의존하고 있다.

자체 딥러닝 하드웨어 및 소프트웨어 플랫폼을 개발하는 기업 너바나(Nervana)는 네온이라는 딥러닝 프레임워크를 오픈소스 프로젝트로 공개했다. 이는 CPU, GPU, 너바나의 자체 맞춤형 하드웨어에서 부하 작업이 수행될 수 있도록 삽입형 모듈을 사용한다.



파이썬(Python)은 수학, 과학, 통계에 없어서는 안 될 프로그래밍 언어
프로젝트 : 사이킷-런
깃허브 :

가장 오래된 기계 학습 라이브러리들 가운데 하나인 쇼군(Shogun)은 1999년 개발됐으며, C++에 기반 쇼군은 SWIG 라이브러리 덕분에 자바, 파이썬, C#, 루비, R Lua, Octave, Matlab에서도 이용할 수 있다.

Project: Shogun

어코드(Accord) Framework/
닷넷(.Net)용 단일 프로세싱 프레임워크 겸 기계 학습 라이브러리인 어코드(Accord)는 AForge.net의 확장판.
‘단일 프로세싱’은 이미지를 통합하거나 얼굴을 인식하는 등 이미지와 음성을 처리하는 여러 기계 학습 알고리즘을 일컫는다.
Project: Accord Framework/

Apache Mahout 소프트웨어 는 세 가지 주요 기능을 제공합니다.
1.확장 가능한 알고리즘을 구축하기위한 간단하고 확장 가능한 프로그래밍 환경과 프레임 워크
2.Scala + Apache Spark, H2O, Apache Flink를위한 광범위한 사전 작성 알고리즘
3.Samsara, 규모에서 작동하는 R 유사 문법을 사용한 벡터 수학 실험 환경

Project: Mahout

아피치의 스파크 및 하둡용 기계 학습 라이브러리인 MLlib은 속도와 확정이 뛰어난 알고리즘과 유용한 데이터 형식을 지원
Project: MLlib

옥스데이터(Oxdata)의 H2O는 이미지 분석보다는 부정행위나 트렌드 분석 등 비즈니스 프로세스에 더 적합한 알고리즘이다.
프로젝트 : H20
깃허브 :

클라우데라 오릭스(Cloudera Oryx)
하둡을 대상으로 한 또 다른 기계 학습 프로젝트인 오릭스(Oryx)는 클라우데라 하둡 배포판이다.
프로젝트 : Cloudera Oryx
깃허브 :

구글의 고(Go)는 5년밖에 되지 않은 언어이다.
프로젝트 : GoLearn
깃허브 :


자바 기계 학습 알고리즘을 집대성했다.
프로젝트 : Weka

현재 대다수는 GPU가 특정 기능 구현에서는 CPU보다 성능이 앞선다는 사실을 안다.
프로젝트 : CUDA-Convnet

ConvNetJS는 이름이 암시하듯, 자바스크립트 기반의 신경망 기계 학습 라이브러리를 제공하는데, 브라우저를 데이터 워크벤치로 사용하게끔 도와준다. Node.js를 이용하는 사람들을 위한 NPM 버전도 있다.
프로젝트 : ConvNetJS
깃허브 :





  1. Docker
    1. 가상 머신과 Docker
      1. 가상 머신
      2. Docker
      3. 리눅스 컨테이너
    2. Docker 이미지와 컨테이너
  2. Docker 설치하기
    1. 리눅스
      1. 자동 설치 스크립트
      2. 우분투
      3. RedHat Enterprise Linux, CentOS
      4. 최신 바이너리 사용하기
    2. Mac OS X
    3. Windows
  3. Docker 사용해보기
    1. search 명령으로 이미지 검색하기
    2. pull 명령으로 이미지 받기
    3. images 명령으로 이미지 목록 출력하기
    4. run 명령으로 컨테이너 생성하기
    5. ps 명령으로 컨테이너 목록 확인하기
    6. start 명령으로 컨테이너 시작하기
    7. restart 명령으로 컨테이너 재시작하기
    8. attach 명령으로 컨테이너에 접속하기
    9. exec 명령으로 외부에서 컨테이너 안의 명령 실행하기
    10. stop 명령으로 컨테이너 정지하기
    11. rm 명령으로 컨테이너 삭제하기
    12. rmi 명령으로 이미지 삭제하기
  4. Docker 이미지 생성하기
    1. Bash 익히기
    2. Dockerfile 작성하기
    3. build 명령으로 이미지 생성하기
  5. Docker 살펴보기
    1. history 명령으로 이미지 히스토리 살펴보기
    2. cp 명령으로 파일 꺼내기
    3. commit 명령으로 컨테이너의 변경사항을 이미지로 생성하기
    4. diff 명령으로 컨테이너에서 변경된 파일 확인하기
    5. inspect 명령으로 세부 정보 확인하기
  6. Docker 좀더 활용하기
    1. Docker 개인 저장소 구축하기
      1. 로컬에 이미지 데이터 저장
      2. push 명령으로 이미지 올리기
      3. Amazon S3에 이미지 데이터 저장
      4. 기본 인증 사용하기
    2. Docker 컨테이너 연결하기
    3. 다른 서버의 Docker 컨테이너에 연결하기
    4. Docker 데이터 볼륨 사용하기
    5. Docker 데이터 볼륨 컨테이너 사용하기
    6. Docker 베이스 이미지 생성하기
      1. 우분투 베이스 이미지 생성하기
      2. CentOS 베이스 이미지 생성하기
      3. 빈 베이스 이미지 생성하기
    7. Docker 안에서 Docker 실행하기
  7. Dockerfile 자세히 알아보기
    1. .dockerignore
    2. FROM
    4. RUN
    5. CMD
    7. EXPOSE
    8. ENV
    9. ADD
    10. COPY
    11. VOLUME
    12. USER
    13. WORKDIR
    14. ONBUILD
  8. Docker로 애플리케이션 배포하기
    1. 서버 한 대에 애플리케이션 배포하기
      1. 개발자 PC에서 Git 설치 및 저장소 생성하기
      2. 개발자 PC에서 Node.js로 웹 서버 작성하기
      3. 개발자 PC에서 Dockerfile 작성하기
      4. 개발자 PC에서 SSH키 생성하기
      5. 서버에 Git 설치 및 저장소 생성하기
      6. 서버에 Docker 설치하기
      7. 서버에 SSH 키 설정하기
      8. 서버에 Git Hook 설정하기
      9. 개발자 PC에서 소스 Push하기
    2. 서버 여러 대에 애플리케이션 배포하기
      1. 개발자 PC에서 Git 설치 및 저장소 생성하기
      2. 개발자 PC에서 Node.js로 웹 서버 작성하기
      3. 개발자 PC에서 Dockerfile 작성하기
      4. 개발자 PC에서 SSH키 생성하기
      5. 배포 서버에 Git 설치 및 저장소 생성하기
      6. 배포 서버에서 SSH 키 생성하기
      7. 배포 서버에 Docker 설치하기
      8. 배포 서버에 Docker 레지스트리 서버 설정하기
      9. 배포 서버에 SSH 키 설정하기
      10. 배포 서버에 Git Hook 설정하기
      11. 애플리케이션 서버에 Docker 설치하기
      12. 애플리케이션 서버에 SSH 키 설정하기
      13. 개발자 PC에서 소스 Push하기
  9. Docker 모니터링하기
    1. 모니터링 서버 Dockerfile 작성하기
    2. 애플리케이션 서버 Dockerfile 작성
    3. 웹 브라우저에서 그래프 확인
  10. Amazon Web Services에서 Docker 사용하기
    1. Amazon EC2에서 Docker 사용하기
    2. AWS Elastic Beanstalk에서 Docker 사용하기
      1. AWS 콘솔에서 Docker 애플리케이션 배포하기
      2. Docker Hub 공개 저장소 이미지 사용하기
      3. Docker Hub 개인 저장소 이미지 사용하기
      4. Git으로 Elastic Beanstalk Docker 애플리케이션 배포하기
  11. Google Cloud Platform에서 Docker 사용하기
    1. Google Cloud SDK 설정하기
    2. Compute Engine에서 Docker 사용하기
    3. Container Engine에서 Docker 사용하기
  12. Microsoft Azure에서 Docker 사용하기
  13. Docker Hub 사용하기
    1. Docker Hub 가입하기
    2. push 명령으로 이미지 올리기
    3. Docker Hub 개인 저장소 생성하기
    4. Docker Hub Automated Build 활용하기
  14. Docker Remote API 사용하기
    1. Docker Remote API Python 라이브러리 사용하기
      1. 컨테이너 생성 및 시작하기
      2. 이미지 생성하기
      3. 컨테이너 목록 출력하기
      4. 이미지 목록 출력하기
      5. 기타 예제 및 함수
    2. Docker Remote API Python 라이브러리로 HTTPS 통신하기
      1. 인증서 생성하기
      2. Python 라이브러리 사용하기
  15. CoreOS 사용하기
    1. VirtualBox에 CoreOS 설치하기
      1. systemd로 서비스 실행하기
    2. Vagrant로 CoreOS 설치하기
    3. etcd 사용하기
      1. etcd 키, 디렉터리 생성하기
      2. etcd 키, 디렉터리 목록 출력하기
      3. etcd 키, 디렉터리 자동 삭제 설정하기
      4. etcd 키 감시하기
      5. etcd 기타 명령
    4. fleet 사용하기
      1. fleet 머신 목록 출력하기
      2. fleet으로 유닛 실행하기
      3. fleet 유닛 목록 출력하기
      4. fleet 유닛 상태 확인하기
      5. fleet 자동 복구 확인하기
      6. fleet 전용 옵션 사용하기
      7. fleet 유닛 파일 템플릿 활용하기
      8. fleet 사이드킥 모델 활용하기
      9. fleet 기타 명령
    5. 클라우드 서비스에서 CoreOS 사용하기
      1. Amazon EC2에서 CoreOS 사용하기
      2. Google Compute Engine에서 CoreOS 사용하기
  16. Docker로 워드프레스 블로그 구축하기
    1. 워드프레스 Dockerfile 작성하기
    2. MySQL 데이터베이스 Dockerfile 작성하기
    3. 워드프레스와 데이터베이스 컨테이너 생성하기
  17. Docker로 Ruby on Rails 애플리케이션 구축하기
    1. Ruby와 Rails 설치하기
    2. Rails Dockerfile 작성하기
    3. PostgreSQL 데이터베이스 Dockerfile 작성하기
    4. Rails와 데이터베이스 컨테이너 생성하기
  18. Docker로 Django 애플리케이션 구축하기
    1. Django 설치하기
    2. Django Dockerfile 작성하기
    3. Oracle 데이터베이스 Dockerfile 작성하기
    4. Django와 데이터베이스 컨테이너 생성하기
  19. Docker 활용 시나리오
    1. 로드 밸런서와 연계한 확장 전개
    2. 개발, 테스트, 운영을 통합
    3. 손쉬운 서비스 이전
    4. 테스트 용도
  20. Docker 명령어 및 옵션 목록
    1. attach
    2. build
    3. commit
    4. cp
    5. create
    6. diff
    7. events
    8. exec
    9. export
    10. history
    11. images
    12. import
    13. info
    14. inspect
    15. kill
    16. load
    17. login
    18. logout
    19. logs
    20. port
    21. pause
    22. ps
    23. pull
    24. push
    25. restart
    26. rm
    27. rmi
    28. run
    29. save
    30. search
    31. start
    32. stop
    33. tag
    34. top
    35. unpause
    36. version
    37. wait
  21. 부록
    1. Docker 컴파일하기
    2. 우분투 한국 미러 사용하기
    3. 참고 사이트

예제 소스

저작권 정보

  • 가장 빨리 만나는 Docker(이하 ‘책’)의 저작권은 이재홍에게 있습니다.
  • 책의 출판권 및 배타적발행권과 전자책의 배타적전송권은 (주)도서출판 길벗에게 있습니다.
  • 책의 내용을 복제하여 블로그, 웹사이트 등에 게시할 수 없습니다.
    • 링크 및 SNS 공유는 허용합니다.
  • 책의 내용을 변경할 수 없습니다.
  • 책의 내용을 상업적으로 사용할 수 없습니다.
  • 책의 내용을 어떠한 형태로든 재배포할 수 없습니다.

[Apache Kafka] 1. 소개및 아키텍처 정리

Apache Kafka(아파치 카프카)는 LinkedIn에서 개발된 분산 메시징 시스템으로써 2011년에 오픈소스로 공개되었다. 대용량의 실시간 로그처리에 특화된 아키텍처 설계를 통하여 기존 메시징 시스템보다 우수한 TPS를 보여주고 있다.

이 글은 Apache Kafka 공식페이지의 0.8.1 문서와 2011년에 NetDB에 출판된 논문(Kafka: A distributed messaging system for log processing)을 기반으로 작성하였다. (글 작성 시점인 2015.03.09를 기준으로이 최신 버전이지만 아직 출시된 지 한 달 남짓 밖에 되지 않으므로을 기준으로 작성하였다.)

Kafka의 기본 구성 요소와 동작

Kafka는 발행-구독(publish-subscribe) 모델을 기반으로 동작하며 크게 producer, consumer, broker로 구성된다.

(이미지 출처: Apache Kafka 0.8.1 Documentation)

Kafka의 broker는 topic을 기준으로 메시지를 관리한다. Producer는 특정 topic의 메시지를 생성한 뒤 해당 메시지를 broker에 전달한다. Broker가 전달받은 메시지를 topic별로 분류하여 쌓아놓으면, 해당 topic을 구독하는 consumer들이 메시지를 가져가서 처리하게 된다.

Kafka는 확장성(scale-out)과 고가용성(high availability)을 위하여 broker들이 클러스터로 구성되어 동작하도록 설계되어있다. 심지어 broker가 1개 밖에 없을 때에도 클러스터로써 동작한다. 클러스터 내의 broker에 대한 분산 처리는 아래의 그림과 같이 Apache ZooKeeper가 담당한다.

출처: [Epic Developer]