System Compleat.

'gitgub'에 해당되는 글 1건

  1. Build Automated Infrastructure with Chef - Chapter 1 (2)

Build Automated Infrastructure with Chef - Chapter 1

Techs
( 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 , 정윤진 )