( younjin.jeong@gmail.com , 정윤진 )

최근 클라우드가 부각되면서 자연스럽게 이슈가 되고 있는 것이 바로 자동화된 인프라스트럭처의 구성이다. 이미 지난번에 CHEF-101 코드를 통해서 한번 소개 한 적이 있는데, 이렇게 다시 소개하게 된 데에는 여러가지 이유가 있지만 일단 요모 조모 사용해 본 결과 아주 쉽게 시스템을 빌드 할 수 있고, 루비 기반으로 작성된 코드의 적응 시간도 매우 짧아 그 사용이 매우 편리함에도 불구하고 국내에서는 아직 넓게 사용되지 못하고 있는게 안타깝기 때문이다.

물론, 예전부터 사용하던 고전적인 cfengine 과 같은 툴 또는 상용이라면 IBM 의 Tivoli 를 기반으로한 z/OS 시스템 오토메이션을 필두로 각종 시스템 자동화를 모토로 하는 다양한 가격의 상용 시스템 자동화 툴이 있다.  이 툴들의 특징은 하나같이 써먹기가 어렵거나, 또는 설정의 변경이 용이하지 않은 시스템 관련 업무 그 자체의 특수성 등으로 인해 도입이 쉽지 않은 것이 사실이다.  또한, 일부 대규모의 호스팅 업체 또는 수백, 수천의 서버를 동일 목적으로 구현할 필요가 없다면 굳이 열대 스무대 돌리는 업장에서 시스템 관리자 섭외도 쉽지 않을 진데 자동화야 당연히 소원할 수 밖에 없다.

현실이 비록 이렇다 할 지라도, 엔터프라이즈 레벨의 인프라 또는 각종 대기업 환경, 대규모 HPC 클러스터 및 클라우드 인프라에서는 자동화를 빼고서는 할 말이 없다. 자동화가 가져다 주는 BOX (서버) 자체의 서비스에 대한 Plug & Service 및 Hot swap 의 특혜는 5대의 서버만 구성하게 되더라도 어마어마 한 것이다.  하물며 수천대의 서버를 항상 가동시키거나, 또는 계속 deploy 해야 하는 상황이라면 이런 자동화 툴은 아니라도 적어도 OS 이미지 복사 또는 자동 설치 CD 정도는 만들어서 사용해야 하는게 정신건강 및 관리에 이롭지 않겠는가.

이런 경우도 생각 해 볼 수 있다.  수백/수천여대의 서버가 위치한 센터가 어떠한 이유로 사용 불가능 하게 되었을 경우, 동일한 용도의 시스템군을 다시 빌드 해야 한다고 하면 과연 당신이 지금 운용중인 서비스는 몇일이 소요되겠는가.
전통적인 방식으로 생각 해 보면,  ( 적어도 배포서버는 있는 경우 ) 하드웨어 및 네트워크 구매, 설치, 케이블링 시간을 제외하더라도 십수여일 또는 IP 변경으로 인한 개발팀등과의 확인/연동이 필요한 경우 길면 수개월도 걸릴 수 있다.
이러한 경우 공통적으로 적용 할 수 있는 자동화 툴이 있다면, 케이블링이 끝난 시점에서 적어도 수시간 내에는 완전히 다른 지역에 서버의 deploy 가 가능하며, 이때 신경써야 할 것은 오로지 DB 데이터의 무결성과 같은 크리티컬 한 부분일 뿐이다.

이런 자동화 툴의 필요성에 대해 이미 인지하고 계실진대 굳이 졸린 눈 부벼가며 영 어색한 문장으로 다시 끄적이는 이유는 Chef 만 보거나 또는 시스템/서비스를 미시적 관점에서 접근하게 되면 결국 이런게 왜 필요하게 되었는지를 모른 채 시스템 변경 사항이 발생 될 때마다, "아 이거 그냥 적용하면 되지 뭘 이렇게 만들어 놓았나" 하는 생각을 떨칠 수 없을지도 모르지 않겠나 하는 노파심 때문이라 치자.  ( >.< )  어차피 내 블로그 내맘... ;;;


우야 둥둥 잡설이 길었다.  본론으로 들어가자면,

다음과 같은 쇼핑몰 서버를 오픈 소스 솔루션을 통해 가상화 또는 실제 물리적 서버군으로 구성했다 치자. 싸니깐. ;;

- 웹 서버 몇 대.
- 웹 어플리케이션 서버 몇 대.
- 결재 전용 서버 두어 대.
- 이미지 전용 서버 몇 대.
- 데이터 베이스 서버 또는 서버 군.
- 웹 서버 또는 웹 어플리케이션 서버 간 세션 공유를 위한 memcached / repcached 서버 두어 대.
- 웹 소스 및 이미지 공유를 위한 NAS 두어 대.
- 로그 및 모니터링 서버

쇼핑몰 잘 나가나 보다. ;;;

뭐 어쨌든, 위와 같은 서버군을 생각 해 보았을때 오픈 소스로 구성한다면 대충 필요한 패키지는 다음과 같으시겠다.

- nginx / lighttpd   :  이미지 또는 단순 파일 배포 서비스  또는 reverse proxy
- httpd ( apache2 ) / php5 / resin / web logic / zeus :  java, php 등을 사용하는 각종 어플리 케이션 중 1종. (물론 일부는 오픈소스 아님 ㅋ )
- nexenta 또는 opensolaris 기반 또는 일반 리눅스의 NFS 
- repcached
- mysql / PostgreSQL , 돈 많거나 DB구조, SQL 구리면  Oracle RAC
- L4 를 사지 못할 정도로 가난할 경우 LVS / ipfwadm  /  heartbeat
- 방화벽을 구매하지 못할 정도로 가난한 경우 iptables 및 openvpn
- rsyslog / nagios
- notification sms 발송 솔루션 ( 이건 업체에서 제공하는걸 쓸 밖에. 일본에서는 폰메일이 있으므로 postfix 로 쉽게 가능 ㅠㅠ )
- notification email 발송 솔루션
- 가상화로 구성하는 경우  Xen 꽁짜/상용 서버 또는 vSphere , 또는 kvm
 

리소스를 대충 늘어놓고 보니 수량이 좀 된다. 하지만!  우리가 필요한 또는 많은 업체에서 사용하는 대부분의 오픈 소스들이 전부 들어있다.  오픈소스 많이 없다고 걱정 안해도 된다.  구성도를 그려서 올리면 더 좋을텐데, 그건 나중에 하겠다.  집에서 쓰는 맥에 구성도 그릴 만한 툴이 대략 없다. ㅠㅠ

자, 원래는 chef 로 간단히 파일 생성 및 패키지 설치만 보여줄려고 했는데 일이 너무 커져 버렸다.  모른다. 오늘 다 못쓰면 내일 써도...;;  어차피 구성도나 그림도 없... ;;;


Chef 를 자동화 툴로 사용하기로 했다면, 또는 Chef 이외의 것들까지 생각해 보자면, 다음과 같은 계획을 준비해야 된다.

1. pxe boot 및 dhcp 등을 굴려서 쌩 하드웨어에 자동으로 OS 를 올릴 것인가.
2. Chef 를  Server - Client 모델로 굴릴 것인가 Chef-solo 를 사용 할 것인가.

서버 수량의 증가 가능성이 거의 없거나 또는 매우 드물어 관리자가 OS 설치를 재미로 해도 된다면 굳이 OS 자동 설치까지는 신경쓰지 않도록 한다.  이건 나중에 화학 계산을 위한 PC GMESS 를 사용한 HPC 클러스터용 마스터 노드 제작때 보여주기로 한다.  역시 대규모가 되어서 MAC 주소가 걔가 뭐였더라 할 정도 아니면 Chef 도 서버 클라이언트는 필요 이상으로 복잡 해 질 수 있다.  그래도, 하는게 하지 않는 것보다는 좋으려나. 보안 이슈도 있으니깐.

1번을 무성의 하게 지나쳤으므로, 순식간에 chef 단계로 넘어간다.  이때 결정해야 할 사항은 다음과 같은것들이 있다.

1. 각 서버는 어떤 용도로 활용 될 것 인가. ( Role 정의 )
2. 각 용도에는 어떠한 패키지가 필요할 것인가. ( Cookbook listup )
3. 각 서버는 서로 자주 사용되어야 할 Attribute 가 있는가. (  예를 들면, mysql 패스워드 또는 모든 서버에서 참조 될 수 있는 ssh rsa 키  또는 서버 패스워드 등 )

1번 및 2번은 위에 열거한 서버 리소스별로 다음과 같이 정리 될 수 있겠다.

Role :  webserver ,  proxy_server , image_server , db_master , db_slave , log_monitor , session , nfs_master , nfs_secondary , billing , web_application

음.. 꽤 많다.  자 이제 필요한 요리책을 펴 보면,

Cookbook :  http , nginx , mysql , rsyslog , nagios , repcached , nfs , bill, php5 ( was 는 이것으로 한다 ) , iptables , common ( 모든 서버에서 셋업 되어야 하는 공통 사항 )  , pgsql , openvpn , heartbeat , lvs

처음 접하시는 분들은 당삼 그런 생각 들꺼다.  이게 다 뭐야?  그런 생각이 드신 분들은 다음의 내용을 주시한다.

* chef 는, 기본적으로 각 호스트별로 지정된 role 을 호출하여 서버를 구성한다.
* role 은  cookbook 의 조합으로 구성되며, Cookbook 하위에는 해당 패키지를 서비스에 맞게 설정하기 위한 각종 리소스가 포함된다.  recipe , attribute , file, template , metadata 등의 리소스는 관리자에 의해 생성, 변경 되어 입맛에 맞게 구성이 가능하다.

물론, 서비스 구성에는 이러한 조건 이전에 다음과 같은 계획이 수반 되어야 할 것이지만, 여기서는 내가 대충 정한다.

- ip 및 네트워크 구성 계획
- nfs 마운트 디렉토리 위치
- 방화벽 및 vpn access 구성 계획
- DNAT 또는 SNAT 사용 여부
- 로드 밸런싱 및  용도별 이중화 계획
- 각 하드웨어 스펙 또는 가상화 서버 스펙


좋다.  다 끝났다. 

이미 시간이 밤 12시를 가르키고 있으므로,  실제 chef 코드의 작성에 대해서는 다음호에 계속...;;; 하기로 한다.
아마 3부작 정도 되지 않을까 싶다.  이런 장기 포스팅 약한데..



급하신 분들을 위해 직접 삽질이 고픈 분들 께서는 다음의 링크들을 참고 하신다.

* chef : http://wiki.opscode.com/display/chef/Home , http://www.opscode.com/
* http : http://httpd.apache.org/
* lvs  : http://www.linuxvirtualserver.org/
* repcached , memcached : http://repcached.sourceforge.net/ , http://memcached.org/
* iptables : http://www.netfilter.org/ 
* postgresql :  http://www.postgresql.org/
* nginx :  http://wiki.nginx.org/Main

나머지 php 나 mysql 등은 원체 많이 접하실 걸로 예상되어 별도의 링크는 읍다.
다음회에는, chef server 설치 및 client 설정,  실 코드 작성 및 github 를 통해 코드를 업로드 하도록 하겠다.

아 물론, 쇼핑몰 서비스를 위한 "인프라" 만을 다루며 실제 몰 서비스를 위한 코드는 알아서 해결 하시도록 한다.
난 웹 개발자가 아니니깐 ㅠ   음... 현희형이랑 준호형을 섭외 해 볼... ;;;   솔루션 하나 나올기세 ㅋ


( younjin.jeong@gmail.com , 정윤진 )

( younjin.jeong@gmail.com )

굉장히 오랜만의 포스팅이다.  이직도 있었고, 이직 이후 워낙 정신 사납게 달리다 보니 포스팅은 커녕 내가 내 블로그 들어오는 일도 주말의 행사가 되어버렸다.  대신, 클라우드의 구성에 대한 큰 그림과 어지간한 구조는 잡았지만. 훗;

어쨋든 오늘 소개하고자 하는, ( 이미 여러차례 소개는 했었지만 ) 이 Nexenta 라는 운영체제는 이미 알려진 바와 같이 오픈 솔라리스 기반이며, 역시 알려진 바와 같이 솔라리스 기반의 가장 큰 축복인 ZFS 를 메인으로 사용하는 스토리지로서의 사용에 그 주요 목적이 있는 운영 체제라 할 수 있다.  물론 우분투와 같은 apt 기반의 패키지 관리 시스템을 통해 얼마든지 원하는 형태로 확장이 가능 하지만,  어쨌든 난 얘는 무조건 스토리지로 쓰는게 좋다고 생각 한다.

본 운영체제에 대한 자세한 스펙은 http://www.nexenta.com 또는 http://www.nexenta.org 에서 참조 할 수 있다.
물론 서비스 셋업을 위한 몇가지 튜토리얼 및 매뉴얼 등은 매우 잘 정리 되어 있으나, 아직은 트러블 슈팅에 대한 사례가 많지 않아 국가별로 구글검색을 쌔워도 정수리가 바짝 서는 시원한 답변은 잘 나오지 않으므로 다소간의 삽질은 각오 해야 한다.

서론이 매우 무지 끔찍하게도 길었지만,  어쨌든 오늘은 다음의 사용 목적을 가지고 간단히 Nexenta 를 구성해 보고자 한다.

1. NFS / CIFS 로서의 사용.
2. iSCSI
3. 디스크 / 볼륨의 zfs 를 통한 관리.

금일 사용할 Nexenta 의 버전은 3.0.3 이 되시겠다.  ( http://www.nexenta.com/corp/free-trial-download )
먼저 주의 할 것은, 본 운영 체제가 언젠가 부터 유료화 되었기 때문에 최초 설치 이후 제품 키를 넣으라는 화면을 보고 당황 하지 않으려면 미리 위의 링크 사이트에 가입을 완료 해 두어야 한다.  메일 주소를 통해 해당 계정의 Activation 을 수행하므로, 구라로 메일주소 넣으면 안되시겠다.

다운 받아 씨디로 꿉고 ( 아 물론 VM 으로 하셔도 완죵 무방 ) 그동안 보아 왔던 수많은 리눅스 설치 화면과 비슷한 환경들이 지나가고 나면, 시스템이 재부팅 된다.
재부팅이 되고 나면 생성된 키를 하나 보여주며 제품 키를 넣으란다.  그러면 요기 http://www.nexenta.com/corp/free-trial-registration 로 가서 이전에 생성해둔 계정을 통해 로그인 하고 정보를 넣으면 메일로 상큼하게 키가 날아온다.

입력하고 나면, 콘솔 로그인 창이 떨렁 뜨는데, 물론 엑스퍼트라면 로그인 이후 진행 해도 되지만, 아니라면 다음과 같이 웹 브라우저를 통해 접근한다.

http://host_fqdn_or_ip_address:2000

자! 상큼한 웹 인터페이스가 나타나질 않는가!  여기서는 다음의 정보를 입력하도록 한다.
물론, 기억에 의존한 포스팅이기 때문에 스텝은 살짝 꼬였을 수 있으나 의미하는 바는 같;;;;

1. 기본 네트워크 정보
   - 호스트명
   - 네트워크 인터페이스
   - 네임 서버 및 ntp 서버 등의 정보
2. 볼륨 생성
   - 볼륨 생성할 디스크 및 redundant type  ( RAIDZ1 , RAIDZ2, RAIDZ3 ... cache disk , log disk , spare disk , etc )
   - 볼륨의 이름
   - 옵션  ( deduplication 및 기타 등등 )
3. 시스템 패스워드
4. 기타 폴더 ( 기존의 디렉토리나 윈도우의 폴더와는 개념이 살짝 다르다 ) 등등의 추가 설정.
5. 웹 인터페이스의 접근 포트 및 http / https 사용 여부.

대략 이러한 초기 설정 프로세스를 마치고 나면 다음과 같이 아름다운 페이지를 확인 할 수 있다.





이미 화면을 보면서 느꼈겠지만, 그렇다!  대부분의 기능을 웹 인터페이스로 제어가 가능한 것이다!
물론 웹 인터페이 말고 디테일하거나 즉각적인 반응 또는 빠른 작업을 위해 CLI 의 사용이 가능하다.  본 3.0.3 버전의 경우 원격지에서 ssh 를 사용해 로그인 하게 되면 nmc 라고 하는 콘솔이 나타난다. ( 아마도 Nexenta Management Console 일게다 ) 
본 콘솔의 경우, 네트워크 장비 특히 Cisco 나 Foundry 에 익숙하다면 아주 손쉽게 적응이 가능한 잇점이 있다.



또한, 스위치나 리눅스 bash 에서와 같이  TAB-TAB 키 또는 ? 의 사용을 통해 사용 가능한 커맨드 리스트를 볼 수도 있다.  이는 매우 편리한 관리를 제공하지만, 거센 서비스 환경의 IO 로드가 걸린 상황에서는 충분히 답답함을 느낄 수도 있겠다.

만약, 이런 어플라이언스도 스위치 같지도 않은 툴들을 버려둔 채로 난 pure zfs 만 사용할꺼야 하시는 분들은 다음의 커맨드로 쉘 환경에 대한 진입이 가능하다.  단, 일부 커맨드를 통한 시스템 변경의 경우 관리 콘솔을 죽여 버릴 수 도 있음을 양지하고 마루타 해야 할 것이다.


자 이제 그럼 소기의 목적인 볼륨을 생성 해 보도록 하자.


볼륨 이름을 입력하고 넘어 간다.


위와 같이 화살표로 선택/이동이 가능한 디스크의 목록이 나온다. 필요한 디스크들을 선택하여 볼륨을 구성한다.
친절하게 여려개를 고르려면 스페이스바를 누르란다.
선택 하고 넘어 가면,


redundancy type 을 선택하란다.  다들 종류는 알고 있을테니 스킵.


불륨에 디스크 추가를 계속 할건지 물어온다.  추가할 생각이 없다면 n 을 상콤하게 눌러준다.


볼륨을 진짜 만들건지 물어본다.  y
누르고 나면, 볼륨이 생성되며 다음과 같이 summary 가 나타나며, auto-snap 서비스를 설정 할 것인지 묻는다.


나는 수동 설정할 것이므로 n , 궁금한 분들은 y 눌러서 진행 하면 되겠다.


실수로 y 를 눌러버렸다. 젠장.  뭐 어쨌든 연습용이므로 패스~

이제 볼륨이 만들어 졌다.  이 볼륨에 zvol 을 생성하고 iSCSI 타겟을 설정하여 iSCSI 로도 사용이 가능하고, 또는 folder 를 생성하여 NFS/CIFS 의 파일 기반 서비스를 사용 할 수도 있다.

모두 비슷한 인터페이스이기 때문에 다음과 같이 zvol 도 생성이 가능하다.

이후의 설정도 그대로 따라하면 되겠다.


물론 CLI 인터페이스로 소개하였지만, 웹 인터페이스에서도 모두 기능을 제공한다.
상단 메뉴의 Data Management -> Data Sets  에서 볼륨 및 폴더의 생성/삭제가 가능하며,  Data Management -> SCSI Target  의 탭에서 LUN / zvol 의 생성 및 삭제가 가능하다.


이러한 기본적인 기능 이외에 플러그인을 사용하면 서버 자체적으로 bonnie 또는 iometer 등을 사용하여 볼륨에 대한 벤치마킹이 가능하기도 하며,  여러대의 Nexenta 를 사용중이라면 zfs send/receive 의 기능을 확대한 auto-sync , auto-tier 등의 파일 시스템 복제 및 autocdp 를 통한 블럭레벨의 복제까지 가능하다.

한가지 더 알아 두어야 할 것은, Nexenta 에서의 폴더의 개념이 약간 특수한데, 이는 단순 mkdir 로 생성되는 것이 아닌 NFS/CIFS/RSYNC/FTP 등의 서비스를 손쉽게 설정이 가능하도록 하는 또 하나의 단위라고 생각 하면 된다.
단순히 NFS 서비스만 제공하고자 한다면 서버를 설치하고 볼륨 생성 -> 폴더 생성 -> NFS 탭에 체크 -> 간단한 권한 설정 을 통해 바로 NFS 서비스에 투입이 가능하다.


스크린샷을 많이 찍고 싶었으나 여건이 허락하지 않아 대충 넘어 가지만, 거의 대부분의 기능들을 커맨드 라인 인터페이스로 설정하는것이 더 재미있다.  초기 설정에 필요한 아주 간단한 것들만 적어 보자면,


CLI 체계는 간단해서, show 를 setup 으로 바꾸면 보기/설정 으로 변경 된다고 생각하면 매우 쉽다.



서비스를 구성하면서 언제 힘든것이 IO 이다.  아무리 고민해도 나쁘지 않은 부분이며, 통상 병목이 매우 일찍 오는 구간이므로 NetApp 또는 EMC 등의 벤더와 또 리눅스 상에서의 각종 파일 시스템, 그리고 이런 오픈 솔라리스 기반의 여러 장치를 테스트 해 보는 것은 매우 의미 있는 일이라 하겠다.

모두 재미난 테스트 하시길!


( younjin.jeong@gmail.com , 정윤진 )

( younjin.jeong@gmail.com , 정윤진 )


세월은 빠르게 흘러, 시스템 관리에도 고전적인 perl / python 과 같은 언어를 제치고 ruby 가 등장하게 되었다.
Chef 라고 하면 이미 나온지 그렇게 오래 된 툴은 아니지만, 그렇다고 얼마 되지 않은 것도 아니다.
이 글을 쓰게 되는 것도 번역이나 샘플 코드 조사를 통한 기본적인 동작의 이해를 위한 것임을 미리 밝히며, 시스템 자동화를 구현 할 수 있는 이런 툴을 개발하고 또 미리 알아내어 접하는 분들에게 새삼 놀랄 따름이다.

우분투에서의 ruby 인스톨은 아주 쉬운 과정으로 이루어 지며, 이거 왜 안되 할 만한 부분이 있어 별도로 소개한다.
( 우분투에서는 gem update --system 을 지원하지 않는다.  패키지 매니저로 처리 하라는 친절한 시스템사마의 설명 )

# sudo apt-get install ruby rubygem
# sudo gem install ohai chef       

하다 보면 여기서 에러를 줄줄이 뱉어 낼 것이다.  에러를 살펴보면, extconf.rb:1:in 'require': no such file to load - mkmf 라는 에러 메세지 인데, 결국 extconf.rb 는 ruby-dev 패키지를 참조하기 때문에 이 패키지를 설치 하지 않으면 정상적으로 동작하지 않는다.  따라서,  정상적으로 진행하기 위해서는

# sudo apt-get install ruby-dev

해 준다.  이후 다음의 링크에서 제공하는 Chef 를 시작하는데 안성맞춤인 내용을 따라하는데 우분투로 충분 할 것이다.

이제부터 설명할 내용은 다음의 링크에서 가져왔다.
http://brainspl.at/articles/2009/01/31/cooking-with-chef-101


Cooking with Chef 101

Chef 의 가장 매력적인 점은 확장 및 축소가 매우 쉽다는 점이다.  처음 시작할 때는 chef-solo 로 쉽게 시작하고, 이후 필요에 따라 chef-client 나 chef-server 를 통해 원하는 대로 구현이 가능해 진다. Chef 로 작성한 동일한 recipe 를 가지고  웹 서버, 데이터베이스, 어플리케이션 , couchdb 서버 및 기타 등등의 거의 모든 서버에 대한 수평적 확장이 가능하다.
구체적 설명은 됬고, 일단 간단한 recipe 를 통해 rubygem 의 일부 패키지를 설치 해 보기로 한다. 그리고, chef 가 베이스 시스템을 구성한 이후에 간단한 디렉토리 설정과 어플리케이션을 배포 해 보도록 하겠다 .

일단 chef-101 의 코드를 GitHub 로 부터 가져온다.

# git clone git://github.com/ezmobius/chef-101.git

Chef 를 설치한다. ( root 계정 또는 sudo )

# gem install chef ohai  --source http://gems.opcode.com  --source http://gems.rubyforge.org

( 일부 패키지 의존성 문제로 인해 rubygem 이 gems.opcode.com 에 의해 서비스 받고 있음에도 불구하고 rubyforge 를 소스로 추가해 주는 것이 좋다.  Rubygem 은 그런식으로 동작한단다. )
여기까지 준비 되었으면 이제 실행시켜 보면 된다.  ( 이 단계는 일부 디렉토리 생성 및 어플리케이션 들을 인스톨 하기 때문에 원치 않으면 넘어가도 관계 없다. )

실행하기전,  config/dna.json 의 user 설정을 변경 할 필요가 있다.  소스에는 'ez'로 되어있을 것이나, 시스템에 나와 같이 'ez' 계정이 없다면 변경 해 주는 것이 좋다.

# cd chef-101
# chef-solo -l debug -c config/solo.rb -j config/dna.json

엄청나게 많은 메세지들이 줄줄이 올라가는 것을 볼 수 있는데, 처음부터 대부분의 메세지는 시스템 output 컬렉터인 ohai 가 수집한 정보들이다.  이는 recipe 에서 수행하는 모든 내역을 알려주며, 정상적으로 종료 된 경우에는 다음과 같은 내용을 보여준다.

INFO: Chef Run complete in 1.09344323 seconds

여기까지 나왔다면 요리를 잘 했다고 볼 수 있다.   이제 이 Chef 가 어떤 식으로 동작하는지 알아 볼 필요가 있다.
먼저,  dns.json 을 보면,

{
  "apps": [
    "beast",
    "mephisto"
  ],
  "user": "ez",
  "gems": [
    {
      "name": "rake",
      "version": "0.8.3"
    },
    {
      "name": "tmm1-amqp",
      "source": "http://gems.github.com",
      "version": "0.6.0"
    }
  ],
  "recipes": ["main"]
}

이는, 내가 JSON DNA 라고 부르는 recipe 세트다.  이는 노드에 설치할 것들에 대한 레시피로, 코드 안에서 어플리케이션 이름, 사용자 명 등을 찾아 볼 수 있다.

시스템으로의 엔트리 포인트인 main 으로 지정된 recipe 를 보면,

include_recipe 'gems'
include_recipe 'applications'

template "/data/someservice.conf" do
  owner node[:user]
  mode 0644
  source "someservice.conf.erb"
  variables({
    :applications => node[:apps]
  })
end

include_recipe 로 필요한 recipe 를 순차적으로 호출하는 것을 볼 수 있는데, 이는  호출 순서에 따라 필요한 레시피가 동작하도록 설정 할 수 있게 하기 위함이다.  만약 다른 레시피를 먼저 구동하고 싶으면, 그 레시피를 다른 것보다 먼저 호출 하도록 한다.

자, 우리는 gem 레시피 이후 application 레시피를 호출하고, 이후 일부 디렉토리 작업을 수행 하는 것을 볼 수 있다. 이 이후작업에서 우리는 쉽게 템플릿을 정의하고, 네이밍 하여 해당 템플릿이 가져야 하는 속성의 정의를 구현하는 것을 볼 수 있다. 
이제, gem 레시피를 보자.

node[:gems].each do |gem|
  gem_package gem[:name] do
    if gem[:version] && !gem[:version].empty?
      version gem[:version]
    end
    if gem[:source]
      source gem[:source]
    end
    action :install
  end
end

여기서 우리는 loop 를 돌려가며 dna.json 에서 정의 되어 설치할 각 gem 의 버전을 가져오는 것을 볼 수 있다. Gem 은 버전과 소스를 가질 수 있으나, 주의할 점은 비어있으면 설정하지 않아야 한다. 버전을 정의하지 않으면 가장 최신의 버전을 가져오게 될 것이며, 소스를 지정하지 않으면 rubyforge.org 에서 가져오게 될 것이다. 
결국 마지막 줄에, 우리는 action :install 으로서 각 gem 에 대한 인스톨을 수행한다. 이는, 시스템에 이미 해당 gem 이 설치 되어 있으면 다시 설치하지 않는다.

자 이제 application recipe 를 보면,

directory "/data" do
  owner node[:user]
  mode 0755
end

node[:apps].each do |app|

  cap_directories = [
    "/data/#{app}/shared",
    "/data/#{app}/shared/config",
    "/data/#{app}/shared/system",
    "/data/#{app}/releases"
  ]

  cap_directories.each do |dir|
    directory dir do
      owner node[:user]
      mode 0755
      recursive true
    end
  end

end

먼저 우리는 /data 디렉토리를 생성하고 원하는 권한을 할당한 이후, json 에 명시한 owner 로 디렉토리를 설정하는것을 볼 수 있다. 이후 루프를 돌면서 필요한 디렉토리 생성 등 모든 액션을 취한다. 

보는 바와 같이 비교적 간단하게 chef-101 코드는 종료된다. 매우 간단하지만 보기 쉽게 로직을 설명하고 있어서, Chef 를 시작하는 엔트리 포인트로는 나쁘지 않을 것이다.


여기까지 날림 번역.


Chef 는, 상상할 수 있는 시스템 설정의 모든 부분에 관여 할 수있다.  각종 daemon 의 동작에 필요한 설정 파일 부터,
필요한 패키지의 설치 또는 웹 서버들의 컨텐츠 배포, Mysql 의 복제 구성까지도 모두 가능하다.

ruby 라는 언어를 먼저 습득할 필요는 있지만, perl 이나 python 중 둘중 하나에 엑스퍼트가 아니어서 하나를 배워야 한다면 루비를 적극 추천하며, 두가지 언어 모두를 알고 있는 사람에게도 Chef 는 좋은 툴이 될 수 있을 것이다.



( younjin.jeong@gmail.com , 정윤진 )

( younjin.jeong@gmail.com , 정윤진 )


영화,연극 이외의 모든 문화 생활을 거의 하지 못하고 있던 내가 최근 몇일 동안 아, 이렇게 극장에서 영화를 자주 봐도 되나 싶을 정도로 극장을 들락거리고 있다. ( 월 2회 ;; )   이직 하는 회사가 워낙 바쁘게 돌아가는 회사라 굳이 시간을 빼기 쉽지 않은 부분도 있긴 하지만, 뭐 여튼 기회가 닿아서 보게 되었네.

금요일 오후 5시 반, 평촌 키넥스 10에서 아는 동생과 함께 영화관에 입장해서 화면이 가장 잘 보이는 극장 한 가운데의 좌석에 자리를 잡았다.  주변에는 대학생으로 보이는 여자사람 그룹과 연인등이 대부분. 

그렇게 영화는 시작 되었다.  무려 140분의 세상에서 가장 긴 롤러코스터, "악마를 보았다."

 

배우들의 연기는 차처하고 나서라도, 이 영화의 스토리 전개는 매우 빠르며, 긴장감이 계속 넘친다.  초반의 극악 무도한 경철의 영화 첫 피해자를 공격하는 상황의 묘사와 이후의 끔찍한 모습은 마치 롤러코스터의 초반 운동에너지 확보를 위해서 제일 꼭대기로 올라가는 듯한 긴장감과,  잔인한 장면의 묘사에는 제일 높은 꼭대기에서 수직으로 내리 꽃는 "경악" 을 관객에 선사한다.



이 영화에 등장하는 같은 사이코 패스로 보이는 여성을 제외하고는, 모두 우리가 일반적으로 볼 수 있는 경계심이 강한 여성들 뿐이다. 세상이 세상인지라 당연히 낮선자를 보면 경계하도록 훈련 되었고, 모두가 수행 할 수 있는 최선의 조심을 하며, 또 그렇게 하도록 강요 받지만  이, 경철 (최민식 분) 은 그런것 따윈 관계 없다. 마치, "너희가 숨을 곳은 없어" 라고 말하는 듯한 극한의 공포와 아무리 안전한 장소에서도 어디엔가는 그가 문을 잠글 수 있는 곳이 있다.

경철의 "짜증" 이 스크린에 보이기 시작하면 여자사람관객들은 입에 손을 가져가기 시작한다.  이제껏 보지 못했던, 매너나 도덕 따위는 이미 아스트랄한 세계로 날려버린 이 인간이 또 무슨짓을 저지르려나 또 얼마나 끔찍하려나 싶어서겠지.

최민식 분의 모든 장면에서의 연기는 그야말로 섬뜩하다.  마치 내가 객석이 아닌, 현장 바로 옆에서 보거나, 경철의 얼굴이 클로즈 업 될 때에는 마치 내가 피해자 인듯 한 환상까지 든다.



한가지 주목하고 싶은 장면은, 경철이 수현( 이병헌 분 ) 에게 첫 복수를 당하고 난 뒤 길가에서 잡아 탄 택시다.
왜 인지는 모르지만, 살인의 추억에서 송강호의 대사가 생각이 났다. "여기가 콩밭이냐? 강간의 왕국이냐?" 하며 드롭킥을 날리던.  그래서 피식 하고 웃음이 났는데, 옆에 있던 이름모를 여자가 어이없게 날 바라보는 눈초리가 느껴져 괜시리 민망했던 뭐... ;;

아무튼 두명의 사이코 패스는 아닌 범죄자와, 격이 다른 경철의 이들에 대한 반응은, 소름이 돋을 지경이다.
그리고 여지없이 이어지는 잔인한 살인.   이 후로는 절대 웃을 수 없었다.



 


영화에 대해 말이 참 많다.  영화를 보고 상상한다면 사이코패스 인증이라는 둥, 너무 잔인해서 보는 내내 역겹다는 둥 어떤 누구는 모방 범죄가 발생할 까봐 겁 난다는 둥 각자 자신의 세상을, 영화를 보는 논리로 또 그 자신의 인생의 경험으로 영화를 대한다.

이런 모습을 보면 이 영화는 마치, 눈 앞에 사체를 마주 해야만 하는 일종의 "염" 과 같은 의식에 강제로 참여 해야만 하는 상황을 만드는 힘을 가지고 있다고 생각한다.  누구에게는 그 순간이 매우 슬프지만, 또 어떤이에게는 극한의 공포가 될 수 있는 현실 속 최대한의 체험.  영화는 제목에서 이미 말하고 있다.  "쫄리면 열지 마라".  마치 판도라의 상자. 
객석에 앉는 순간 이것은 절대 내릴 수 없는 마치 롤러코스터의 속도 안에서 슬픔과 분노, 또 끔찍함과 광기어린 등장인물을 실감나게 표현하는 배우 들 그리고 군더더기 없는 시나리오 속에 엔딩 크레딧이 올라가는 그 순간까지도 절대 방심 할 수 없다.

진짜 영화가 무서워 지는건, 영화가 다 끝나고 "밤" 에 극장을 나설 때 이다.
행여 심야 영화라도 보았다면, 자주 마주치던 택시조차 타기가 겁날 정도로  우리가 최근 뉴스에서 보아왔던 범죄자의 사진과 경철의 끔찍함이 오버랩 되며,  적어도 웃으면서 할증시간의 택시를 탈 수는 없는 공포를 선사하게 될 것이다.

난 전문 영화 평론가도 아니고, 그렇다고 영화를 자주 보는 사람도 아니지만,  적어도 잘 만들어진 영화에 대해서는
참 칭찬하고 싶다.  마치 스너프와 같이 끔찍한 장면 묘사들로 인해 영상 자체가 불편한 경우도 있긴 하지만, 이는 감독의 연출에 대한 "자랑" 이나 "뽐내기" 가 아닌,  진정한 사이코 패스의 "범죄 현장으로의 안내" 라고 생각한다.

그리고 마지막 장면에서의 수현의 허탈한 걸음과 눈물은, 거창하게도 짐승이 되어버린 자신에 대한 어쩌고 무엇이 아니라, 다만 그렇게 까지 스스로를 망가 뜨려도 얻을 수 없었던 사이코패스의 속죄가 억울했던 것은 아닐까 싶다.


짜릿한 롤러코스터는 불편하다.  타기 전에 경고문도 붙어 있다.
왜 이런 영화를 만들었는지 모르겠다고 욕하지 말고, 볼 자신이 없으면 예매를 말자. 
하지만, 그냥 안보기에는 너무 아깝고 아쉽지 않은가.  임산부와 노약자에겐 비추다.

추격자와는 비슷한 듯 다른 털이 쭈뼛한 범죄 현장에 대한 공포와 잔인한 복수. 
접근하기 쉬운 특정 직업을 대상으로 했던 범죄를 다룬 추격자와는 다르게, 이 영화는 모든 젊은 여성을 향한, 그래서 누구도 저런 상황이 되면 막을 수 없겠구나 하는 도방갈 틈새를 적나라하게 주지 않는 영화.

"악마" 로 표현하기엔 부족하지 싶다.

뉴스나 그 어디에서라도 내가 사는 세상에 저런 악마는 평생 안보면 좋겠다.




+ 오늘 친구와 심야로 한번 더 보게 되었는데, 역시 이 영화는 잔혹한 장면에서는 3인칭을 많이 배제 한 듯한 느낌이었다.  관객의 피의자에 대한 "죽어 마땅한 놈" 이라는 동의를 얻는 장면에서는 3인칭을, 마치 내가 피해자 인 듯하게 느껴지는 현장에서의 피해자 시선에서 바라 본 듯한 앵글,  피의자의 앵글.  그리고 한가지 더는, 수현 ( 이병헌 분) 을 그릴떄는 거의 1인칭을 사용 하지 않는 듯 했다.  아마 같은 모습의 악마로 동화 되는 모습을 표현하고 싶어서가 아니었나 생각 해 본다.
사람의 적응력이란 무서워서, 나조차도 겨우 두번째 본 이 영화의 각 잔혹한 장면이 서서히 익숙해 져 가는걸 느꼈다.
스릴러 장르의 특성상 여러번 보면 그 감흥이 자연히 사그러 들지만, 끔찍한 장면에서 조차 다른 관객의 나지막한 비명이 귀에 들려 올 정도로 무뎌진달까.

극장에서 같은 영화를 두번 본 것은 아마 이 영화가 처음이지 않나 싶다.
빠른 전개와 오르락 내리락 하는 호흡의 흐름이 적절하고 사건을 표현하는 구도와 배우들의 열연이 돋보이는,
적어도 "이끼" 와 같이 밋밋하게 흐르지는 않는 매우 잘 만든 영화라는 느낌이 새삼 들었다는.

"나쁜놈은 처음에 잡아서 죽였어야 해" 하는 어떤 여자 사람 관객의 목소리가 들렸다.  물론 커플.
각 개인의 감상은 그렇지만, 악마 같은 인간과 복수의 과정을 조금만 생각한다면 그런 말 안하지 않을까 싶다.

맨 온 파이어 에서의 덴젤 워싱턴의 복수와 같이 통쾌한 것이 아닌, 복수 그 자체로 길고 긴 외나무 다리에서의 싸움.
어느 코메디의 대사처럼 "너에게 복수를 하기 위해 10년을 연마했다"  라는 지극히 한국적 정서와, 진정한 무서움을 표현해 낼 줄 아는 감각에 박수를 보내지만,  역시 이런 영화와 같은 일은 일어나면 안되는 거다 싶다.

사람이 무섭잖아.


진정한 영화 리뷰는 이런 분이 쓰신게 더 나은듯
http://blog.naver.com/iidakya?Redirect=Log&logNo=70091862830
http://blog.naver.com/funnyfunnee?Redirect=Log&logNo=150092124374
http://blog.naver.com/sega32x?Redirect=Log&logNo=150092027565

( younjin.jeong@gmail.com , 정윤진 )

( younjin.jeong@gmail.com , 정윤진 )


최근의 클라우드와 같은 대규모 분산처리가 점점 더 이슈화 되고, 발전하고 있다.  이는 각종 SnS 서비스 및 모바일 통신 환경의 발달로 인한 더 많은 사용자 층의 서비스 유입으로 인하여 자연스럽게 나타나는 시대의 플랫폼에 대한 요구가 아닌가 하는 생각이 든다.

서비스는 보다 더 복잡해 지고, 각 진영의 개발은 그 어느때 보다 활발하며, 치열하다.  기업간 경쟁은 Apple 을 필두로 Adobe 와의 분쟁,  HTML5/CSS3 , 각종 확장된 Javascript 등은  플랫폼, 클라이언트 브라우저 등 모든 환경이 급변함으로 고인 물은 더욱 빨리 썩게 되고, 흐르는 빠른 물줄기를 쫒아 가자니 가랭이가 터질 지경이 아닌가.
더구나 그 물에 몸담그고 있다면, 또 그 물이 opensource 라면 각종 개발에 스크립트에 정신줄 놓는건 일도 아니다. ( 물론 학구열에 불타면 관계 없지만 매번 똑같은 일을 하지 않기 위해 짜는 스크립트는 항상 고뇌의 시간을 요구한다. )

뭐 서론의 헛소리가 길었지만, 어쨌든 제목과 같은 Framework는 예전 부터 있어왔나 보다.
다만 각종 Cloud 의 발전에 의해 좀 묻히지 않았나 하는 생각 과 함께,  기존 클라우드의 VM 으로서 Windows 서버를 굴리게 되더라도 IIS 의 성능 자체에는 MS 의 지원없이 할 수 없는 것들이 많이 있다.
그런 측면에서 이와같은 Framework 의 지원은 매우 반가운 일이며, 어떠한 형태로든 효율적인 IIS 의 Server Farm 을 구성 할 수 있다면 전단 웹 서버를 탄력적이고 확장가능하게 (MS에서 그렇다고 한다) 만들 수 있기에 서비스 구성에 고려할 만한 옵션이나 전략이 추가 되는 것이 아닌가 하는 생각이다.

물론, 요새 OpenNebula 2.0 이나 OpenStack 과 같이 마루타 할 것들이 많아져서 실제 구현을 한다거나 해 보지는 않았기에, 간단히 소개하는 정도로 하고 관계 되신 분들은 링크로 추가된 자료들을 검토해 보시면 될 듯 하다.
버전이 2.0 이니 1.0 부터 사용하신 분들도 많지 않겠나 하는 생각.

이와 같은 서버팜은 아마도 hosting 업체들에 유리하지 않겠나 하는 생각을 테스트없이 남발해 본다. 음;;;

원문을 보실 분들은 여기 ( http://learn.iis.net/page.aspx/905/microsoft-web-farm-framework-20-beta-for-iis-7/ ) 를 참고 하시면 되겠다.


서문.

오늘날, 웹서버 세팅과 각종 컨텐츠의 배포는 매우 고된 작업중 하나이다.  수많은 절차와 검증이 필요하며,플랫폼 관리를 위한 스크립트나 코드를 제작하여 힘겹게 운용하고 있다.

마이크로소프트 웹 팜 프레임웍 ( WFF ) 2.0 for IIS 7 은 호스팅 업체와 같이 수많은 서버를 관리해야 하는 사업체의 관리자에게  공급/확장/관리를 단순화 시켜줄 수 있는 도구이다.  관리자는 손쉽게 여러 서버를 확인할 수 있고, 컨텐츠의 배포 및 필요한 순간에 확장도 손쉽게 된다.  WFF의 사용으로,  서버군에 대한 단일화된 업데이트 및 헬스체크등의 기능을 쉽게 사용 할 수 있다.  이러한 도구의 사용 잇점은 역시, 보다 적은 비용 및 리스크로 서비스를 동일하게 구현 할 수 있다는 것이다.


주요 기능.