간단한 lucene demo 실행

lucene version: 3.5.0

 

tar zxvf lucene-3.5.0.tgz

 

export CLASSPATH=~/repo/charsyam/lucene-3.5.0/lucene-core-3.5.0.jar:~/repo/charsyam/lucene-3.5.0/contrib/demo/lucene-demo-3.5.0.jar

 

time java org.apache.lucene.demo.IndexFiles -docs docs/

java org.apache.lucene.demo.SearchFiles

 

bottle.py 과 daemon 으로 심플 웹 데몬 만들기!!!

가끔씩 개발을 하다보면, 사용 수는 하루에 몇 건 안되지만 서비스를 제공해 줘야 할 경우가 생긴다.

그리고 이런 경우, 로직이 복잡한 경우도 별로 없을 때도 많다.(이건 만구 내 생각임 ㅋㅋㅋ)

이럴 때, 뭔가 서버를 동작하기 위해서 셋팅 하기는 애매할 경우 가 많다. 그래서 소개하는 것이 초경량 Python Web Framework 인 bottle 이다. bottle은 bottle.py 라는 파일 하나에 필요한 내용이 모두 들어있다.

그래서  너무나 간단하게 사용할 수 있다.(http://bottlepy.org)

다음 예제를 보자.

from bottle import route, run

@route('/hello/:name')
def index(name='World'):
    return '<b>Hello %s!</b>' % name

run(host='localhost', port=8080)

이 간단한 예제만으로 http://localhost:8080/hello/world 로 접속하면 Hello World! 가 출려된다.

그런데 bottle.py는 너무 간단한 프레임워크라 Daemon으로 동작하지가 않는다. 즉 Shell의 Connection 이 끊기거나 하면 바로 종료되게 되는데, 이 때 사용할 수 있는 방법이 크게 2가지가 있다.

1. Screen 을 이용한다.

사실 이건 꽁수다. Screen을 이용하면 Shell 자체의 Connection이 끊기지 않는 다는 점을 이용해서 Screen 으로 실행을 시킬 수 있다.

2. Daemon Library를 이용한다.

python-daemon 이라는 라이브러리가 있다.(http://pypi.python.org/pypi/python-daemon)

이걸 이용하면 굉장히 쉽게 Daemon 으로 동작하게 만들 수 가 있다.

다음은 Daemon Library 의 사용 예제이다.

import daemon

from spam import do_main_program

with daemon.DaemonContext():
    do_main_program()

이것도 굉장히 쉽다. 결국 2개를 결합하게 되면

from bottle import route, run
import daemon

@route('/hello/:name')
def index(name='World'):
    return '<b>Hello %s!</b>' % name

def start_server():
    run(host='localhost', port=8080)

with daemon.DaemonContext():
    start_server()
 
Daemon 만들기 귀찮을 때 열심히 써먹어보자.

Architecting for Cloud

Cloud를 위한 Architecting 은 뭔가 달라야 할까?

기본적으로 내 생각은 Cloud를 위한 Architecting 은 기본적인 분산 시스템을 만드는 것과 달라서는 안된다고 생각한다.

결국 특별한 Cloud 서비스용으로 뭔가를 사용한다면, 해당 시스템에 Lock-in 될 가능성이 높아지기 때문이다.

http://aws-musings.com/architecting-for-cloud/#more-376 에 보면, Architecting for Cloud  관련 내용이 나와서 간단하게 정리해보려 한다.

이 글을 쓰신 분은 Amazon 을 이용한 내용이지만,  어디든 적용가능 할만하다.(그리고 내가 적는 내용은 위의 글의 내용을 내가 이해한 대로 좀 변경하고, 본인의 경험을 추가했다.)

1. 특별한 Components 가 없더라도 동작하도록 아키텍처를 구성하라.

– 시스템의 일부분이 다운되었을 때를 가정한다.  만약, 블로그 서비스등을 하는데, 메인 DBMS 가 장애나서 데이터를 가져올 수 없는 상황이라면, 어쩔 수 없다.

(이런 케이스는, DBMS를 이중화 하는 형태로 처리를 해야한다.)

– 그런데 여기서 말하듯이, Configuration 서버 등이 장애가 났을 경우, 서비스가 돌지 않는다면, 전체 시스템의 작은 일부분 때문에, 전체가 돌지 않는 것은 문제가 생긴다.

그럴 때에도 동작할 수 있도록 하는 것이 필요하다. 최근에, 캐시 서버에 접속하지 않으면, 대기하는 코드 때문에, 캐시 서버에 장애가 났을 때, 서비스가 돌지 않는 문제가 발생했었다.  캐시 서버를 이용하면, 성능이 좋아지지만, 캐시 서버의 문제가 생기더라도, DB 서버에서 동작하게 되어서 서비스에 문제가 없어야 한다.

(이럴 때, 다른 이슈가 발생할 수 있는데, 캐시 서버로 인해서 성능이 좋아져서, 서버를 줄이게 되면, 캐시 서버가 문제가 되었을 때, 서비스에 문제가 생길 수 도 있다.)

2. 중요한 서비스는 Elastic load Balancer 를 이용하라.

– 중요한 서비스는 부하시에 문제가 발생하지 않도록 Elastic load Balancer + Auto Scaling 을 이용하라는 내용이다.

( 실제로, 서비스에 우연히 특정 시점에 부하가 많이 몰리는 경우가 있다. 이 때, 제일 아쉬운 것이 클라우드 서비스를 이용하면, 바로 장비를 추가할 수 있을텐데 라는 생각이 들 때가 있다. 클라우드 서비스의 장점도 몇 분안에 장비 추가나 제거가 가능하다는 데 있다. )

3.  디스크의 데이터가 중요하다면 EBS Volumes 을 이용해라.

– EBS Volumes 의 경우, RAID를 이용하는 것 처럼, 내부 디스크가 깨어지더라도, 어느 정도의 안전성을 보장한다.(RAID + Hotspare 로 구성하게 되면, 디스크가 깨지더라도 서비스를 진행하는데 문제가 없다. Raid를 HotSpace 디스크로 재구성 하는 시간이 걸리지만, 서비스가 가능하다. 일반적으로 하드웨어 장애는 디스크 장애가 가장 빈번하다.)

EBS Volumns의 경우,  가상 머신에 문제가 있을 때, 다른 Instance 에 마운트 해서 이용하기도 쉽고, Snapshot 생성하는 것도 굉장히 쉽다.)

4. 데이터를 여러 장비에 중복해서 저장하라.

– 분산 파일 시스템을 이용하여 데이터를 저장하라. 데이터의 유실을 피하기 위해서 hdfs 나  여러 분산 파일 시스템을 이용하는 것이 좋다.

( 보통 3 copy를 이용하면 거의 유실 없이 데이터가 안전하다고 말을 하지만, 실제로 가끔씩 3copy 가 깨지는 케이스도 상당히 많다. 일반적으로는 3 copy + tape backup 등으로 추가로 백업이 필요하다. )

5. Snapshots 을 자주 생성해라.

– 가능하면 매 시간 마다 Snapshots를 구축하라.(필요하다면 증분 백업을 하는 것도 가능하다. http://aws.amazon.com/ebs/)

6. 자기 자신의 시스템을 설치하지 말고 아마존에서 제공하는 서비스를(SNS, SQS) 를 이용해라.

– 개인적으로는 이렇게 서비스를 이용하게 되면 아마존에 Lock-In 되지 않을 까 싶은데, 따로 구축하는 것보다는 이를 권장하다고 하고 있다.

– 아마도 적절한 Queue 시스템을 만드는 것이 어렵기 때문이 아닐까 싶다.(이런 Queue 시스템은 여러 모로, 있으면 좋다.)

7. 좋은 사례를 따라가라.

– 좋은 EC2 구축 사례가 다음 사이트에서 다운 받을 수 있다.

http://jineshvaria.s3.amazonaws.com/public/cloudbestpractices-jvaria.pdf

직접 읽어보시면, 뭔 번역 내용이 실제 내용과 왜 이렇게 달라라고 말씀하실 수 있기 때문에, 제가 영어를 못한다는 걸 미리 밝혀드립니다.

libcloud 를 위한 python 빌드 방법

libcloud 를 사용하기 위해서 python 을 빌드하게 되면 몇가지 라이브러리가 필요하다.

(그냥 잘 설치된거 쓰면 되는데 괜히 python 2.7.2 깔려다 삽질을)

최소한 기본 예제를 돌리기 위해서는 우분투에서

apt-get install zlib1g-dev

apt-get install libbz2-dev

apt-get install libssl-dev

해서 3개가 설치되어야 한다. -_- 흑흑흑 python 빌드만 몇번 한 것인지 !!!

libcloud tutorial sample 분석

현재 http://libcloud.apache.org/devinfo.html 에서 libcloud 라는 프로젝트가 진행중이다.

어떤 프로젝트고 하니 IaaS 플랫폼 사용자마다 제공하는 API가 달라서 이를 통합하자는 프로젝트다.

유칼립투스(Eucalyptus) 에서 제공하는 그런 통합 API라고 해야할 까?

이를 한번 이용해 보고 싶어서 amazon 계정을 생성하고 한번 설치해 보았다. 제대로 나오는 걸까? 두근두근

가장 간단한 Sample 하나만 돌려봤는데 잘 동작한다.

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

EC2_ACCESS_ID = 'your access id'
EC2_SECRET_KEY = 'your secret key'

Driver = get_driver(Provider.EC2)
conn = Driver(EC2_ACCESS_ID, EC2_SECRET_KEY)

nodes = conn.list_nodes()
# [<Node: uuid=..., state=3, public_ip=['1.1.1.1'], provider=EC2 ...>, ...]

문제는 내쪽에 있었는데 다음과 같은 부분의 확인이 필요하다.

1] SSL 인증서 사용 여부(이건 실행과는 문제가 없다. )

2]신용카드 인증을 받기 전까지는 해당 API 인증에 실패하게 된다.(요걸 몰라서 삽질을)

 

좀 더 열심히 파봐야 할듯 하다.

Memcached를 이용한 Simple 분산 락에 대한 짧은 고찰

memcached는 분산 캐시 서버이다. redis 등의 또 다른 강력한 라이벌이 있지만, memcached는 Cache 라는 이름에 가장 부합하는

cache 서버이지 않을까 싶다. 왜냐하면, 특정 메모리 이상에서 LRU로 캐시가 날아가고, 디스크로의 Dump도 해주지 않는다.

(이게 사실 불편하긴 하다.) 하나의 Item도 1M가 넘는 것을 집어넣을 수 없고, 또한, Collection 도 지원해주지 않는다.

 

하지만, 정말 빠른 속도와, 가장 중요한, DHT 방식을 지원하면서, 캐시 서버를 무한대에 가까이 늘릴 수 있게 된다. 이 과정에서

데이터의 유실이 발생하지만, memcached는 태생이 Cache로 써라이기 때문에, 도리어 적합하다고 할 수 있지 않을까?

 

그런데 이 memcached 에 조금 특별한 부분이 있다. 그것은 operation 들이 모두 Atomic 하다는 것인데, protocol 파싱 레이어나

이런 부분 이외에 실제 데이터에 access 하는 연산은 모두 Lock 으로 인해서 Serialization 된다. 이 특성에 memcached 에 있는

add 라는 커맨드를 이용하면, 간단한 분산 락을 만들 수 있다.

 

add 라는 커맨드는 데이터가 존재하면 실패하게 된다. 즉, 이 명령을 이용해서 Lock을 획득하거나, 존재하는지에 대해서 알게 되는 것이다.

이미 시도를 한 사람이 있는데, http://bluxte.net/musings/2009/10/28/simple-distributed-lock-memcached 여기로 가보면

간단한 소스까지 볼 수 있다.

 

하지만 결론부터 말하자면, 개인적으로 이 것은 거의 ToyLock 이라고 봐야 할 것 같다. 아니면, Lock 자체가 그렇게까지 정밀하지

않아도 되는 상황에서 이용할 수 있을 것 같다.

 

먼저 어떤 disadvantage 가 있는지 보자면,

1. Lock 의 유실이다.

memcache 의 특성 상, DHT 를 이용하기 때문에, 서버리스트가 늘거나, 서버가 장애가 나면, 다른 서버가 해당 키의 범위를 커버하게 된다.

즉, 장비의 추가/삭제 시 마다 특정 락들이 유실되게 된다. 락이 중요한 서비스에서는 락 서버가 한대라도 장애가 나면, 문제가 생길 수 있다.

(이런 이유로, Zookeeper 같은 것들이 각광을 받는다는…) 즉, 락에 대한 리플리케이션이나 이에 대한 뭔가 보장이 필요하다.

 

2. Connection 유지가 되지 않는다.

zookeeper 는 클라이언트에 대한 컨넥션을 유지하다가 해제되면 이벤트를 발생시킨다. 하지만, memcache는 Store 로 설계되었으므로

이런 부분에 대한 처리는 없다. 다만… Expire Time 을 잘 조작해서 ^^ 클라이언트 장애시 자동으로 락이 풀리도록 할 수 있을 것 같다.

 

하지만, 락이 중요하지 않고, 간단하게 락서비스가 필요하다면, 스핀락 형태로 아주 간단하게 구현이 될 것 같다. 그리고 굉장히 성능도

좋은 락이 되지 않을까 싶다.