Category: Linux

Ubuntu 에 zsh 설정하기

zsh 을 이용하면 다양한 테마를 사용할 수 있고 이 테마들은 각 작업때마다 터미널에 관련 작업 상태들을 표시해주어 편리합니다. 예를들어 git 를 사용하시는 분들은 zsh 를 설치하고 테마를 설정해주면 터미널에 git 관련 상태들이 프롬프트에 표시되어 편리합니다.

이 문서는 Ubuntu 에 zsh 설정하기 에 관한 글 입니다.

zsh 설치

Ubuntu 의 경우 zsh 설치는 아주 쉽습니다. apt-get 을 이용해서 설치합니다.

테마 설치 및 설정

테마는 각 계정당 해줍니다. 사용할 계정에 설정을 해주시면 됩니다.

마지막에 기본쉘을 바꾸기위해서 사용자 계정의 패스워드를 물어보고 입력을 해주면 기본쉘이 zsh 로 바뀝니다.

이제 git 프롬프트를 위해 테마설정 작업을 해줍니다. 설치할때 Oh-My-Zsh 를 이용했기 때문에 이를 위한 테마를 설치해줍니다.

이제 로그아웃 했다가 로그인을 하면 프롬프트가 바뀌어 있고 git 디렉토리에 들어가면 프롬프트에 git 상태가 표시가 됩니다.

프롬프트에는 glyphs 를 표시해주기도 하는데, 이를 위해서는  powerline font patch 를 해줘야 합니다.

마지막으로 power line patched font 를 설치해줍니다.

관련 링크

AWS Kinesis

이 글은 AWS Kinesis 이 무엇인지에 대한 개념적인 글입니다.

다음의 자료를 기반으로 작성되었습니다.

  1. Introducing Amazon Kinesis (SlideShare)
  2. Introduction to Amazon Kinesis (Youtude)

Big Data

인터넷의 발전으로 인해서 하루에도 계산하기 힘든 데이터가 쏟아집니다. 과거와는 달라진 이러한 환경을 우리는 간단히 Big Data 시대라고 하지요. 어찌보면 과거에도 Big Data 는 있었지만 요즘과 구별되는 것은 누구든지 Data 를 생산할 수 있다는데에 있습니다. 그러다보니  과거와는 다르게 쏟아지는 데이터를 분석해서 유의미한 데이터를 뽑아내는 기술이 필요하게 되었는데 이게 바로 Big Data 의 진정한 의미 중에 하나 입니다.

누구나 생산해내는 데이터들을 유의미한 의미의 정보로 가공해내는 것이 바로 Big Data 기술이라고 할 수 있습니다.

Batch VS Streaming

과거 이야기를 좀 더 해보면, 과거에도 데이터를 분석해내는 방법이 있었습니다. 첫번째로는 데이터를 모우는 겁니다. 그리고 그것을 특정한 저장소에 저장을 합니다. 대부분 데이터베이스시스템에 저장을 했습니다. 그리고 그것을 이용해서 쿼리문을 이용해서 데이터를 뽑아 냈습니다.

그런데, 데이터를 모으고 데이터베이스에 저장하고 하는 부분은 특정 시간에 서버에 작업을 걸어놓아하는 경우가 많았습니다. 간단하게는 리눅스 시스템에서 크론(Cron) 을 이용해서 특정 배치 프로그램을 돌려서 데이터를 모우고 데이터베이스에 집어넣는 방법을 이용했지요.

하지만 Big Data 시대에 이 방법이 과연 유용한가 하는 문제가 있습니다. 몇분, 몇시간, 몇일간격으로만 배치작업을 돌리는건 쏟아지는 데이터 속도보다 빠르지 못하다보니 데이터분석을 할 수 없는 경우가 많습니다. 설사 분석을 해낸다고 해도 이미 시간이 많은 흐른뒤라서 시의성을 가지지 못하는 정보가 될 겁니다.

그래서 등장한 것이 스트리밍(Streaming) 입니다. 스트리밍, 물 흐르듯 그때그때 데이터를 분석해내면 유용한 정보를 얻기위해서 기달릴 필요가 없을 겁니다. 그때 그때 분석한 데이터를 데이터베이스에 저장하거나 파일로 저장하는것도 가능합니다.

그래서 현대의 Big Data 분석 소프트웨어들은 전부다 Streaming 을 지원하도록 발전되어 왔습니다.

현대의 BigData 구조
현대의 BigData 구조

많은 소프트웨어들이 이렇게 데이터 수집, 분석처리, 저장, 분석 및 리포트 영력으로 나뉘어 발전되어지고 있습니다.

위 그림에서 문제가 하나 있습니다. 데이터 수집 부분과 데이터 처리부분 입니다. 이 부분이 문제가 되는 이유는 데이터 수집하는 소프트웨어와 처리하는 소프트웨어간의 데이터 교환을 맞춰줘야 하고 둘이 동기화 되어 처리되어야 합니다. 어느 한쪽이 병목이 생기면 문제가 생길 수도 있습니다.

AWS Kinesis

AWS Kinesis 는 데이터 수집구간과 데이터 처리구간 중간에 위치합니다. 이렇게 중간에 위치하는 소프트웨어를 만든 이유는 다양한 데이터들을 수집하고 이것을 다양한 포맷으로 만들어 줍니다.

Kinesis 를 이해하는데 헷깔리는게 있는데, Kinesis 가 ‘스트리밍 데이터 처리’ 를 해준다는 것입니다. 여기서 스트리밍 데이터 처리라는 말은 스트리밍으로 데이터를 분석해준다는 이야기가 아닙니다.

다양한 형태로 들어오는 데이터를 가공해서 다양한 분석 소프트웨어가 사용가능하도록 다양한 출력물을 만들어내주거나 데이터 저장소에 저장하도록 해줍니다.

기본의 Streaming 처리
기본의 Streaming 처리

기존의 Streaming 처리구조 입니다. 수많은 다양한 데이터들이 들어오고 이것을 처리하는 가공하고 분석하는 도구들이 붙어 있습니다.

AWS Kinesis
AWS Kinesis

AWS Kinesis 는 다양한 데이터들을 빠르게 가공해줍니다. 그리고 이러한 데이터들은 다양한 포맷으로 출력줌으로써 다양한 소프트웨어서 사용해주게 해줍니다.

다어그램으로 표현하면 다음과 같습니다.

AWS Architecture
AWS Architecture

AWS Kinesis 는 다양한 입력 데이터와 출력을 해줍니다.

AWS Kinesis Sending & Reading Data from Kinesis Streams
AWS Kinesis Sending & Reading Data from Kinesis Streams

Amazon 에서는 Kinesis 를 다음과 같이 설명하고 있습니다.

Amazon Kinesis는 완전관리형 스트리밍 데이터 서비스입니다. 수십만 개의 소스에서 클릭 스트림, 애플리케이션 로그, 소셜 미디어와 같은 다양한 유형의 데이터를 Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다. 그러면 몇 초 안에 Amazon Kinesis 애플리케이션에서는 스트림의 해당 데이터를 읽고 처리할 수 있습니다.

“Amazon Kinesis 스트림에 지속적으로 추가할 수 있습니다” 이 말의 의미를 잘 생각해본다면 이것이 무엇인지 감을 잡을 수 있을 겁니다.

SaltStack 시작하기.

이 글은 SaltStack 시작하기 에 관한 글입니다.

SaltStack 은 자동화 시스템 관리 프로그램입니다. 서버의 설정파일, 패키지 관리, 시스템 명령어등을 한번에 많은 서버에 할 수 있습니다. Chef, Puppet 등과 동일합니다. 단지 이 녀석은 Python 으로 개발이 되었고 역활을 지시하는 sls 파일 문법이 YAML 이며 Jina Template 을 이용해서 sls 에 프로그래밍을 할 수 있습니다.

SaltStack 은 서버와 클라이언트로 모델입니다. 서버역활을 담당하는 SaltStack 을 마스터(Master)라고 하고 클라이언트 역활을 담당하는 SaltStack 을 하녀(Minion)이라고 부릅니다. 마스터의 경우 파일 전송을 할 수 있게 파일서버역활도 같이 합니다.

마스터, 하녀 역활로 나뉘어 있기 때문에 당연히 하녀가 어느 SaltStack 마스터에 지시를 받을것이지 하는 등록절차가 필요합니다.

Master 설치

설치 환경은 CentOS 를 기준으로 합니다. CentOS 의 경우에 Base Repository 에 SaltStack 패키지가 없습니다. 하지만 Epel Repository 를 설치하면 간편하게 Yum 명령어로 설치할 수 있습니다.

대략 20여개의 의존성 패키지들과 함께 설치됩니다. 앞에서 말했듯이 Salt 는 Python 으로 제작되었기 때문에 Python 관련 패키지가 많이 필요합니다.

Salt 마스터 설정.

설정파일은 /etc/salt/master 입니다. 아주 많은 옵션들이 존재하고 각 옵션마다 자세한 코멘트가 있어 어렵지 않게 필요한 것들을 설정할 수 있습니다.

기본적인 설정은 대략 다음과 같습니다.

위 설정만으로도 Salt 마스터는 잘 동작합니다.

Salt minion 설치하기

역시 CentOS 환경이고 Epel Repository 를 추가해서 Yum 을 이용해서 설치하면 됩니다.

설치가 완료되면 /etc/salt/minion 파일에 설정을 하면 됩니다.

Salt minion 설정.

설정파일 /etc/salt/minion 을 열어서 다음과 같이 기본적인 설정을 해줍니다.

id 설정이 중요합니다.

/etc/hosts 파일 설정.

리눅스의 hosts 파일을 마스터와 Minion 양쪽 모두에 설정해 줍니다.

Salt Minion 을 마스터에 등록하기

Salt 마스터는 Minion 을 등록해서 그 리스트를 유지하고 있습니다. Minion 이 마스터에 등록되어 있지 않다면 마스터로부터 그 어떠한 작업 지시를 받을 수 없겠죠. 그래서 새로운 Minion 이 생긴다면 먼저 마스터에 등록을 해줘야 합니다.

등록은 마스터에서 다음과 같이 합니다.

마스터와 minion 간에 통신이 된다면 위와같이 “Unaccepted Keys” 에  아직 등록하지 않은 minion 이 나옵니다.

등록은 다음과 같이 합니다.

등록이 되었다면 minion 과 통신이 잘되는지 다음과 같이 확인해 봅니다.

위와같이 나오면 정상입니다.

서로 다른 RabbitMQ 버전으로 Cluster 구성 테스트.

RabbitMQ 는 인기있는 메시지 브로커 입니다. 비동기 메시지를 다루는데 있어서 RabbitMQ 는 많이 사용되어 집니다. 거기다 RabbitMQ 는 여러 RabbitMQ 를 하나로 묶는 Cluster 기능을 제공합니다. 그런데, 언제나 그렇지만, 서로다른 RabbitMQ 버전끼리 하나로 묶을 수 있을까하는 의문이 들었습니다. 테스트를 해보았습니다.

환경 세팅

master, slave 라 불리는 2개의 서버를 준비했고 각각 3.5.4 버전과 3.1.5 버전을 설치했습니다. 모든 버전은 Epel 저장소에서 RPM으로 설치를 했습니다.

그리고 다음과 같이 RabbitMQ 를 설정했습니다.

  1. master 의 쿠키 파일를(/var/lib/rabbitmq/.erlang.cookie) slave에 복사했습니다.
  2. 양쪽모두 호스트네임을 /etc/rabbitmq/rabbitmq-env.conf 에 지정해줬습니다.

결과

결과적으로 RabbitMQ 는 서로다른 버전으로 Cluster 를 구성할 수 없습니다.

버전이 맞지 않는다고 에러를 냅니다.

혹시나 Master 버전이 Slave 버전보다 낮아서 그런가 싶어서 거꾸로 해봤습니다. (Slave 버전이 Master 버전보다 높습니다.) 즉, 버전이 낮은 RabbitMQ Node 를 높은 버전의 RabbitMQ Node 로 묶어보자는 거였는데 그것도 안됐습니다.

이 메시지는 아마도 데이터베이스 스키마가 달라졌기 때문에 안되다는 오류 메시지로 보입니다.

RabbitMQ 통계 보기.

RabbitMQ 는 AMQP 를 지원하는 Message Queue 프로그램 입니다. 여러 솔루션에서 함께 쓰이고 있는 매우 인기있는 프로그램입니다.

언제나 그렇지만 RabbitMQ 또한 각종 통계자료를 제공 합니다. 이를 통해서 RabbitMQ 건강상태를 체크할 수 있습니다. 이 문서는 이에 대해 간략히 다룹니다.

RabbitMQ Statistics
RabbitMQ Statistics

통계정보를 보는 방법으로는 CLI 를 통해서 볼 수도 있지만, 웹을 통해서 GUI 환경에서 쉽게 볼수 있습니다. 이를 위해서는 GUI Management Plugin 을 활성화해줘야 합니다.

이렇게 하면 웹브라우저를 통해서 RabbitMQ 를 관리할 수 있으며, 간략한 통계정보를 볼 수 있습니다. 이 통계정보를 이해하기 위해서는 Message Broker 에 대한 짧막한 지식이 필요합니다.

Global Counts

전역적인 통계자료 입니다.

Connections

Message Broker 에 TCP 접속을 한 개수 입니다. 그냥 간단하게 RabbitMQ 에 접속한 개수를 말합니다.

Channels

RabbitMQ 는 Channel 이라는 개념을 사용합니다. Connection 내에 존재하는 것으로 가상 커넥션이라고 불리기도 합니다. 이것은 애플리케이션이 다중의 접속을 요구하는 경우에 하나의 TCP Connection 으로 접속을  Multiplex 해주어 접속량을 획기적으로 줄여줍니다.

따라서 하나의 TCP Connection 에 여러개의 접속이 이루어질 수 있어 이 수치는 Connections 개수보다 많이 나올 수 있습니다.

Exchanges

이것은 단일 생산자-소비자 구조에서 생산자-다중 소비자 구조시에 중간에 생산자의 메시지를 분배해주는 역활하는 Exchanges 개수를 말합니다. Publish/Subcribe 패턴에서 나옵니다.

Publish/Subscribe Pattern
Publish/Subscribe Pattern

Queues

메시지 큐의 개수를 말합니다.

Consumers

큐에서 메시지를 꺼내서 쓰는 소비자의 개수를 말합니다.

Nodes 

RabbiMQ 는 Cluster 구조로 여러 서버들을 붙일 수 있습니다. 그렇게되면 Nodes 에 그 서버들이 나타나고 상태정보도 보입니다.

File Descriptors

프로세스에 의해서 오픈한 File Descriptor 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링 해야 합니다. 또, 운영체제의 최대 파일 오픈 개수에 영향을 받습니다.

Socket Descriptor

프로세스에 의해서 오픈한 Socket Descriptor 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링해야 합니다.

Erlang Processes

Erlang 프로세스들의 개수 입니다. 아래에는 최대 활용가능한 개수도 나옵니다. 만일 이것이 비율로 90%가 넘는다면 문제가 생길 수 있어 이를 잘 모니터링해야 합니다.

Memory

RabbiMQ 서버에서 사용하고 있는 메모리양 입니다.

git 파일 삭제후 복구.

git 를 사용하다 보면 local 저장소에서 실수로 파일을 삭제하는 실수를 저지를 수 있다. 이때 파일을 되살린다고 ‘git pull’ 이나 ‘git fetch’를 해봐도 나오는 메시지는 최신판(Already up-to-date)라는 것이다.

이를 이용하는 경우에 어떻게 해야하나?

먼저 삭제한 디렉토리로 이동한다. 그리고 다음과 같이 입력을하면 삭제한 파일 목록을 얻을 수 있다.

사실 삭제된 파일은 다시 checkout 받으면 된다. 다음과 같이 말이다.

리눅스를 잘 다루는 사람이라면 이것을 한번에 할수 있다.

 

 

 

Thread

이 문서는 Perl Thread 문서를 기반으로 작성되었습니다. Thread 의 기초부터해서 Thread의 구현을 Perl, Python 으로 직접 구현해보고 비교하도록 하겠습니다.

출처: http://www.xav.com/perl/lib/Pod/perlthrtut.html

Thread?

쓰레드(Thread)는 프로세스(Process)보다 작은 프로그램 단위 입니다. 좀 더 정확하게 말하자면 프로그램은 적어도 한개의 프로세스로 구성되며 적어도 하나의 쓰레드로 구성됩니다. 적어도 하나의 프로세스에서 하나의 쓰레드는 결국 하나의 실행 포인트를 가집니다. 적어도 하나의 프로세스내에서 다중 쓰레드를 쓴다는 것은 결국 다중의 실행 포인트를 가진다는 것을 의미 합니다.

다중의 실행 포인트?

요즘에 멀티코어(Multi Core) CPU가 많이 나옵니다. 프로그램은 이 멀티코어 CPU에 의해서 실행되는데 프로그램이 실행될때에 1개의 코어만 사용한다면 비효율적일 것입니다. 그래서 프로그램이 실행될때에 멀티코어를 이용한다면 빠르게 동작하게 될 것입니다.

프로세스도 마찬가집니다. 비록 멀티코어가 아닐지라도 하나의 프로세스내에서 다중의 실행 포인트로 동시에 한꺼번에 실행이된다면 빠를 것입니다. 이것이 바로 쓰레드 입니다. 하나의 프로세스내에서 다중 실행 포인트로 동시에 실행되는 것, 그것이 쓰레드 입니다.

쓰레드 프로그램 모델

쓰레드에는 기본적으로 3개의 모델이 있습니다. 정확하게 말하자면 프로그램상에서 구현하는 방법론적인 것입니다.

Boss/Worker 모델

보스(Boss), 실행(Worker) 모델입니다. 하나의 보스(boss)와 여러개의 실행기들로 구성됩니다. 보스는 일을 처리하기위한 태스크(Task)를 생성하고 모은다음에 적절한 실행기에 할당합니다.

이런 모델은 GUI나 서버 프로그램에서 흔하게 사용됩니다. 메인 쓰레드는 특정 이벤트(Event)가 발생할때까지 기다리며 처리(process)를 위해서 실행기(Worker)에게 이벤트를 통해서 보내집니다. 이렇게 이벤트를 실행기(Worker)에게 보내고 난후에 보스는 다른 이벤트를 기다립니다.

보스(Boss) 쓰레드는 적은 일을 합니다. 태스크가 다른 메소드보다 좀더 빠른 처리가 필요하지 않는다면 가장 최적의 사용자 응답시간을 가지게 됩니다.

Work Crew 모델

work crew 모델은 기본적으로 서로다른 데이터 부분을 갖는 같은 일을 처리하기위해서 여러개의 쓰레드를 가집니다. 이것은 전통적으로 병렬프로세싱(Paraller Processing)과 벡터 프로세싱(Vector Processor)와 유사합니다.

이 모델은 특정한 환경에 적합한데, 서로다른 프로세서들을 통해서 다중의 쓰레드들 분배해 프로그램을 실행하는 시스템과 같은 특정한 경우입니다. ray tracing 이나 렌더링 엔진에 적합한데, 개별적인 스레드들이 사용자에게 비주얼한 피드백을 줄수 있는 중간 결과물들을 전달할 수 있는 곳에도 적합니다.

Pipeline 모델

파이프라인(Pipeline)은 태크스(Task)를 스텝(Step)으로 나눕니다. 그리고 하나 스텝의 결과를 다음 쓰레드 처리기에 전달합니다. 각각의 쓰레드는 각 데이터 조각을 가지며 라인상에서 다음 쓰레드에 결과를 전달합니다.

이 모델은 병렬 처리를 하는 두개 이상의 다중 쓰레드를 처리하는 다중 프로세서를 가진다면 중요한 의미를 지닙니다. 이 모델은 개별적인 태스크를 작고 단순하게 유지하는 경향이 있으며 I/O나 시스템 콜과 같이 다른부분의 파이프 라인이 처리를 위해서 특정 파이프 라인를 블럭(block)하는 것을 허용하기도 합니다. 만약 다른 프로세서들에서 파이프라인의 일부를 실행한다면 각 프로세서는 그것을 캐시로 다룰 수 있는 이득을 얻을 수 있습니다.

이 모델은 또한 서브루틴 콜을 실행하기위해서 다른 쓰레드를 생성하는 것보다 재귀적 프로그래밍에서 유용합니다. 프라임과 피보나치 수혈은 파이프라인델을 잘 보여주는 폼(form)입니다.

Native Threads

시스템에서 쓰레드를 구현하는데에는 여러가지 방법이 있습니다. 쓰레드를 구현하는데에는 OS 제작사와 버전에 의존적입니다. 보통 초기버전에서는 단순하지만 버전이 향상됨에 따라 정교해(sophisticated) 집니다.

쓰레드에는 3가지의 기본 카테고리가 존재합니다. User-mode threads, kernel threads, multiprocessor kernel threads 입니다.

User-mode 쓰레드는 프로그램이나 라이브러 전체를 거쳐서 생존하는 쓰레드 입니다. 이 모델에서 OS는 쓰레드에 대해서 아무것도 알지 못합니다. 이 모델을 구현하기는 쉽고 대부분의 OS는 이를 초기에 지원합니다. 이 모델의 단점은 OS가 쓰레드를 알지 못하기 때문에 하나의 쓰레드는 모든 다른 쓰레들을 블럭할 수 있습니다. 전통적 블럭킹 활동에는 시스템 콜, 대부분의 I/O, sleep과 같은 것이 있습니다.

Kernel Threads 는 좀 더 진화한 버전입니다. OS는 커널 쓰레드에 대해서 알고 있으며 그들에대해서 통제권한을 가집니다. 커널 쓰레드와 유저 쓰레드의 주요한 차이점은 블럭킹입니다. 커널 쓰레드에서 하나의 쓰레드 블럭은 다른 쓰레드를 블럭하지 않습니다. 이것은 사용자 쓰레드는 없는 것으로 커널은 프로세스 레벨에서 블럭을 하지 쓰레드 레벨에서 블럭을 하지 않습니다.

이것은 큰 진전으로 쓰레드된 프로그램은 쓰레드되지 않은 프로그램에 비해서 큰 성능을 제공합니다. 예를들어 I/O 블럭인 쓰레드는 다른 것을 수행하는 스레드를 블럭하지 않습니다.

특정 시점에서 커널 쓰레딩이 쓰레드에 인터럽트(Interrupt)를 걸게되면 프로그램이 만들어낸 묵시적인 락킹(locking) 소비(?)를 해제시킵니다. 예를들어 단순하게 $a = $a + 2 를 생각해보면 다른 쓰레드에서 $a를 바꿨고 그 사이에 값을 가지고 오거나 새로운 값을 저장하는 사이에 $a를 다른 쓰레드에서 보여진다면 커널 쓰레드는 예상치 못한 행동을 할수 있습니다.

멀티프로세서(Multiprocessor) 커널 쓰레드는 쓰레드 지원에서 최종 종착지입니다. 멀티 CPU를 가진 시스템에서의 멀티프로세서 커널 쓰레드에서 OS는른 CPU에서 동시에 실행하기위해서 두개 혹은 그 이상의 쓰레드를 스케줄 합니다.

이것은 하나 혹은 그 이상의 쓰레드에서 동시에 실행시켰을때 쓰레드된 프로그램에서 매우 큰 성능을 제공합니다. 반면에 기본 커널 쓰레드에서 나타나지ㄶ았던 naggin synchronization 이슈가 나타납니다.

Cooperative multitasking 시스템에서 제어(control)를 하지못하도록 쓰레드를 운영해 왔습니다. 만약 쓰레드가 yield function 을 호출하면, 제어를 회수합니다. 또, 쓰레드가 I/O와 같은 블럭을 발생시키는 무언가를 실행했을때도 제어를 회수합니다. cooperative multitasking 구현상에서 하나의 쓰레드는 CPU time 에 대해서 모든 다른 것들을 소모시킵니다.

Preemptive multitasking 시스템은 다음 쓰레드를 결정하는 동안 일정한 간격으로 쓰레드를 인터럽트 합니다. preemptive multitasking 시스템에서는 보통 하나의 쓰레드가 CPU를 독점하지 않습니다.

어떤 시스템에서는 cooperative 와 preemptive 쓰레드를 동시에 운영할 수도 있습니다. (realtime 우선순위에서는 cooperative, normal 우선순위에서는 preemptive)

Thread in Perl

이제 Perl에서 쓰레드를 사용하는법을 익혀보겠습니다. 먼저 Perl 이 쓰레드를 사용할 수 있는지를 체크해야 합니다. Perl 을 컴파일 설치할때에 Thread 관련 옵션을 지정하지 않았다면 쓰레드가 사용불가 일수도 있습니다. 따라서 Perl 쓰레드를 사용할때는 코드 맨 앞에 다음과 같이 해줌으로서 Thread 지원여부를 체크할 수 있습니다.

위 코드를 실행했을때 오류 메시지가 나온다면 Perl 이 Thread를 지원하지 않는 것임으로 다시 설치해줘야 합니다.

Perl에서 Thread를 사용하는 것은 기타 언어에서와 거의 흡사합니다.

Thread를 생성할때는 new 메소드를 이용합니다. 서브 프로시져명을 첫번째 인자로 주고 그 프로시져에 인자로 전달할 파라메터를 나열하면 됩니다. 위의 예제는 사실 유용하지 못합니다. 어짜피 실행포인트가 하나인데 구지 쓰레드를 쓸일이 없기 때문입니다. 하지만 다음과 같이 쓰레드를 여려개를 만들면 효과가 있게 됩니다.

출력 결과

여기서 주목해야 할 것이 있습니다. 마지막 줄에 “A thread exited while 2 threads were running.” 쓰레드는 자원을 공유 합니다. 메모리나 cpu 도 공유를 하는데, 그야말로 프로그램의 모든것을 공유하는 것입니다. 그런데 어느 Thread가 먼저 끝날지 모릅니다. 어떤 Thread 가 프로그램을 종료한다면 다른 Thread는 실행이 중단되고 종료 되겠죠. 위의 마지막 줄은 그러한 상황으로 발생된 메시지 입니다. 해결방법은 다음과 같습니다.

join 은 다른 Thread 가 작업을 마치기를 기다립니다. 그래서 모든 Thread가 작업을 마치면 쓰레드는 소멸되죠. 이렇게되면 위의 문제는 해결이 되는거겠죠. 위 코드를 다음과 같이 바꾸면 효율적일 것입니다.

for 문과 foreach 문을 이용해서 Thread를 생성하고 join 하도록 되었습니다.

Thread 관리

Thread를 생성하고 끝내는 방법을 배웠습니다. 그런데 여기서 한가지 드는 의문이 있습니다. 예를들어서 5천대 서버에 뭔가를 할려고 한다면 Thread를 5천개를 만들어야 합니다. 그런데 Thread도 자원을 소모하게 되어 있어서 이렇게 많이 생성을 한다면 메모리를 많이 소비하게 됩니다. 더군다나 5천개의 Thread를 동시에 실행한다는 것은 CPU에게는 좀더 빠르게 왔다리 갔다리 하면서 일을 해야한다는 것을 뜻하게 되고 이는 결국 OS의 Context Switch 개수를 높이게 되고 이는 결국 서버에 부하를 유발하게 됩니다.

그래서 Thread 를 50개 정도만 생성하고 그중에서 끝나는 Thread에게 다시 일을 막기는 식으로 하면 시스템도 보호하고 원하는 작업을 모두 끝낼수가 있습니다. 쉽게말해서 Thread poll 과 같은 개념이라고 보시면 됩니다. 5천개의 서버목록을 Queue에 넣은다음에 Thread를 20개를 생성하고 Thread가 이 큐에서 가져다 쓰게 하면 효율적일 것입니다.

이와같은 개념을 Perl Thread에서는 지원하고 있습니다.

위 코드는 Thread::Queue 를 이용해 Thread 관리를 통해서 구현된 것입니다. Thread의 개수는 변수 $threadcount 에서 지정되고 각각의 Thread들은 enqueue 메소드를 통해서 queue에 넣어집니다. 그리고 dequeue 를 통해서 Thread를 사용하고 있지요. join 시에 사용되는 threads->list 는 Thread들의 객체(?)를 들고 있기 때문에 이를 활용하면 join을 쉽게 구현할 수 있습니다. 수천개의 같은 일을해야하는 경우 $threadcount 는 20으로 제한되어 있기때문에 20개의 Thread만 가지고 수천개를 처리하게 됩니다.

동시성 문제

동시성 문제는 컴퓨터 세계에서는 매우 중요하게 다루어지는 대상입니다. 대부분의 프로그램이 단일작업을 하는것이 아닌 다중 작업, 즉 Thread 라든지 Multi processing 기반으로 작성되어진다면 십중팔구 동시성문제를 해결하지 않고는 올바르게 작동할 수 없습니다. 동시성 문제를 가장 신경쓰는 분야중 하나는 아마도 데이터베이스 시스템일 것입니다.

데이터베이스에서의 동시성 문제는, 예들들면 한순간에 동시에 두명이 레코드를 접근한다고 생각하면 하나는 Select를 다른 하나는 Delete 를 했을 경우 과연 어떻게 될것인가 하는 문제입니다. 데이터베이스 시스템은 다중 접속을 허용하는 프로그램이며 동시에 두명 이상이 같은 레코드를 조회할 가능성이 항상 존재하게 됩니다. 두명 이상의 조회하는 가운데 모든 사람이 같은 명령을 내릴수도 있고 위와같이 Delete 하는 쿼리를 내릴수도 있는데 이럴경우 되돌려주는 결과물을 어떻게 할 것인가 하는 문제가 생깁니다. 이게 바로 데이터베이스 시스템에서 신경쓸수 밖에 없는 동시성 문제입니다.

Thread 에서도 이와 비슷한 동시성 문제가 발견이 됩니다. 파일을 쓰거나 변수를 조작할 경우에 주로 발생한다. 이를 해결하는 방법을 없을까? 어떤 Thread 가 자원에 접근하고 있을때에 그 자원에 대해서 다른 Thread가 못쓰게 하면 되지 않을까? 이를 위해서 Thread는 Lock, Mutex, semaphore 를 지원합니다. 여기서는 perl 에서 lock 을 이요하는 방법을 알아보겠습니다.

위 예제를 보면 lock 을 어떻게 사용하는지를 한눈에 알수 있습니다. 파일에 쓰기 작업을 하기 전에 lock 을 걸어서 동시성 문제를 해결하고 있지요.

Thread in Python

Python 에서도 Thread를 지원하고 위의 내용을 모두 적용해서 사용할 수 있습니다. queue를 이용해 Thread를 관리하고 lock 을 사용해서 동시성문제를 해결하는 것은 완전 perl 비슷합니다. 오히려 python 이 좀더 직관적이다라고 볼수 있지요. 그런데 문제가 있습니다. Thread Queue 를 사용하기 위해서는 Python 버전 2.6 이상 사용해야 합니다.

Thread에 대한 것과 Queue 를 이용한 방법은 아래의 링크에 매우 잘 설명이되어 있습니다.

http://www.ibm.com/developerworks/kr/library/au-threadingpython/index.html

Python 의 동시성 문제도 Perl 과 같이 lock 을 씁니다. 예를 들면 다음과 같습니다.

lock객체를 얻어서 lock 을 얻고 lock 을 풀어줘야 합니다.

 

CHEF CLIENT 설치 – PART4

앞에서 chef 운영을 위한 server와 workstation 을 설치했다. 이제 chef 를 가지고 관리를 할 대상인 서버에 chef client 를 설치하는 방법에 대해서 설명한다.

chef 에서 관리해야할 대상 서버를 Node혹은 Client 라고 부른다. 이러한 서버들은 chef server와 통신을 통해서 각종 작업을 수행하는데, 이 역활을 담당하기는게 바로 chef-client 이다.

chef client 설치는 서버에 직접 들어가서 프로그램을 설치하고 관련 파일을 업데이트하는 작업을 통해서도 할 수 있지만 Chef 스럽게 workstation에서 knife 명령어를 이용해서 간단히 Chef Client 를 설치할 수 있다. 이뿐 아니라 설치와함께 이 서버를 Chef Servr 에 관리대상 서버로 등록해준다.

Chef Client 설치

설치에 앞서 Chef Client 가 될 서버에서 Chef Server 에 호스트네임과 IP를 다음과 같이 등록해준다.

Chef Client 설치는 Chef Workstation 에서 다음과 같이 명령어로 진행한다.

이 한줄이면 아무것도 없는 서버에 Chef Client 가 설치되고 Chef Server 에 Node로 등록된다.

Chef-client 12.4.0-1 에서 문제

아무 위에처럼하면 Chef-client 가 설치가 되어도 Chef Server 와 통신문제를 겪게 된다. 다음과 같은 오류 메시지를 받게 될 것이다.

핵심은 인증키인 validation_key 가 맞지 않다는 것이다.

Chef Workstation 에서 Chef Client 설치 명령어를 수행하면 Chef Client 에 접속해 Chef Client 최신버전은 chef-12.4.0-1 버전을 더운받아서 설치하고 Chef Client 설정파일들이 /etc/chef 디렉토리에 모인다.

그중에 validation.pem 파일이 맞지 않다는 것이다.

Chef Server 는 Chef Client 와 통신을 위해서 공개키/비밀키 기반으로 한다. Chef Server 는 공개키를 각 Chef Client 에 제공하고 Chef Client 는 비밀키를 Chef Server 에 보낸다. 그러면 통신을 할때에 이것을 가지고 인증을 한다.

하지만 chef-12.1 이상 버전부터는 이 키, 더 정확하게는 validation.pem 이 필요없게 되었다. 이에 대한 내용은 다음 링크에서 확인할 수 있다.

결국에는 Chef Workstation 이 가지고 있는 공개키를 삭제하면 된다는 것이다.

그리고 난 후에 방금 실패했던 Chef Client 에서 /etc/chef 디렉토리를 삭제한다.

Chef Workstation 에서 다시 한번 bootstrap 명령어를 주면 Chef Client가 다음과 같이 설치되고 Node 로 등록된다.

Chef Client 등록 확인

Chef Workstation 에서 등록 확인.

Chef Workstation 설치 – Part 3

chef workstation 은 knife 를 설정면 하면된다. 다시말해서 별다른 패키지가 필요없고 특정 시스템 계정사용자에게 knife 를 사용할 수 있도록 설정만하면 그게 바로 workstation 이 되는 것이다.

하지만 별도의 시스템에 workstation 을 설치하고자 할 경우에 knife 명령어가 없다. 그렇다고 chef server 패키지를 설치할려고 하니 불필요한 서비스들이 너무 많은게 문제다. 이럴때는 chef develoment kit 를 설치하면 된다.

chef development kit 은 말그대로 chef 관련 개발을 위한 kit 을 제공하는 것으로 이는 chef workstation 환경을 기반으로 한다. 따라서 chef development kit 패키지를 설치하면 chef workstation 구성을 위한 chef 관련 명령어들이 당연히 들어 있게 되는 것이다.

chef development kit 역시 chef 홈페이지에서 다운로드 가능하다. 레드햇과 우분투 배포판 패키지가 준비되어 있어 패키지를 다운받아 설치하면 된다.

이제 chef 명령어를 이용해서 알맞은 환경을 조성할 수 있도록 다음과 같이 해준다.

앞에서 chef 서버 설치하면서 만들어놓은 자격증명 파일을 복사해 와야 한다. scp 를 이용하던 ftp 를 이용하던 어떻게든 복사하면 되는데, 중요한 것은 복사할 디렉토리가 chef 저장소 디렉토리이다. 이것은 자동으로 생성되는 것이 아니기 때문에 다음과 같이 수동으로 생성해주자.

위 디렉토리에 chef 서버 설치할때 만든 자격증명 파일을 복사 넣는다.

이제 knife.rb 파일을 작성한다. 이 파일 역시 ~/chef-repo/.chef 디렉토리 작성한다. 주요한 파일 내용은 다음과 같다.

이것을 기반으로 환경에 맞게 변경을 하면 다음과 같다.

이렇게 한 후에 다음과 같이 테스트 해본다.

위 에러 메시지는  chef  서버의 SSL 인증서가 없어서 나는 오류다. 오류가 나왔지만 위 메시지만으로 chef 서버와 통신은 성공했다는 것을 알 수 있다. 이제부터는 knife  명령어로 chef  서버와 명령어를 주고받을 수 있다. SSL 인증서가 없다고 하니 chef 서버로부터 받아오자

다시 다음과 같이 나오면 정상적으로 작동하는 것이다.

 

Chef 서버 설치하기 – Part 2

이번 시간에는 Chef 서버를 설치해보도록 한다. 설치에 앞서 Chef 서버를 설치할 서버들에 대한 정보는 다음과 같다.

  • 배포판: Ubuntu 14.04.2 LTS
  • CPU: 1 core
  • RAM: 1024

여기서 중요한 것은 배포판이다. 최근들어 많은 배포판들이 init 에서 systemd 로 바꾸는 추세다. 우분투(Ubuntu)에 경우 systemd 를 도입할 생각이 없다라고 했었지만 14.10 에서 이를 뒤집어 systemd 를 도입했다. init 과 systemd 는 서버 프로그램 시작과 종료하는 방법만 다른게 아니기 때문에 이를 구분하는 것은 매우 중요하다. 여기서 설치할 14.04 는 현재 init 을 따른다.

Download

다운로드는 chef 홈페이지에서 무료로 다운로드 할 수 있다. 그런데, 약간 실망스러운게 다운로드를 하기 위해서는 여기저기 단계를 거쳐야 한다는 것이다. 무료로 다운로드 되는 링크가 바로 나오지 않고 hosted, primium 과 같은 상품을 먼저 전시하고 링크를 찾아 클릭해야만 무료 다운로드 링크가 나오는 구조다.

무료 chef 다운로드
무료 chef 다운로드

우선 서버를 설치해야 하기 때문에 Chef Server 를 다운로드 받는다. Chef Server 는 레드햇 배포판 계열과 우분투 계열은 패키지를 제공한다. 단, 제공되는 배포판 버전은 제한적일 수 있다. 우리는 우분투 14.04 배포판에서 설치할 것이고 지금 현재 Chef 홈페이지에서는 다행이도 이 배포판 버전에 패키지를 제공한다.

Installation

설치는 여러가지 방법이 있는데 여기서는 dpkg 명령어를 이용해 패키지를 설치한다. 이렇게하면 Standard 형식으로 설치가 된다.

설치는 간단하다. 하지만 여기서 끝나는 것이 아니라 이제 시작이다.

Setting

설치가 끝나다면 이제 chef 가 동작하기 위해서 설정을 해준다. chef 서버의 설정은 ‘chef-server-ctl 명령어를 이용해 거의 모든것을 할 수가 있다. Standard 형식의 설치이기 때문에 다음과 같이 해준다.

chef 서버는 다양한 서비스들이 필요하다. 이러한 것을 일일이 다하기보다는 chef 자체의 기능인 자동화 기능을 이용할 수 있는데 그것은 다음과 같다.

과정을 유심히 보면 nginx 웹서버도 설치된것을 알 수 있다.

여기서 잠깐 chef-server-ctl 는 그야말로 chef server 를 컨트롤하기위한 명령어이기 때문에 서버의 상태뿐만 아니라 각종 서비스들에 대한 설정을 변경할 수 있다. 여기서 간단히 알아보도록 하자.

상태보기

서비스 내리기

nginx 서비스를 내린 예지다. 서비스를 올릴려면 start 옵션을 주면 된다.

서비스 로그들 보기

서비스 로그들도 다음과 같이 한번에 볼 수 있다.

chef 이기 때문에 관련 서비스들 관리도 chef 로 한다.

현재 설정들 보기

각 서비스들에 설정상태를 보여준다.

간단하게 chef-server-ctl 에 대해서 알아봤다.

여기까지만 해도 사실 chef server 설치는 끝난다. 하지만 chef server 를 운영하기 위한 계정을 만들어야 할 필요가 있다.  chef-server 를 매니징할 수 있는 서버는 chef workstation 이라는 점이다. chef client 에 chef server 를 매니징 할 수는 없다. chef 로 무엇을 하기위한 관련된 모든 것은 chef workstation 에서 이루어진다고 보면 맞다.  따라서 chef server 에 접근할 수 있는 것도 오직 chef workstation 으로 한정된다.

이를 위해 다음과 같은 추가 작업이 필요하다.

  1. 관리자 계정 생성
  2. 관리자 조직 생성

관리자 계정 생성

조직 생성

위에 sbhyun.pem 와 systemv.pem 은 chef server 에 연결위한 자격증명서다. chef workstation 은 chef server 와 연결해 작업을 수행하는데, 이때 chef server 가 과연 올바른 chef workstation 연결인지를 판별하기 위해서 필요한 것이 바로 이 자격증명 파일이다. 따라서 이 자격증명 파일은 chef workstation 에 복사해주어야 한다.

따라서 이 자격증명 파일은 꼭 잘 간수해야 한다.

다음시간에는 chef workstation 설치에 대해서 알아보자.