System Compleat.

'infrastructure'에 해당되는 글 3건

  1. Things about Openstack Swift implementation
  2. System & JavaScript
  3. Build Automated Infrastructure with Chef - Chapter 1 (2)

Things about Openstack Swift implementation


(, Younjin Jeong )

This is first time that writing blog post in English. There might be some wrong senses, so please read this post in favor. 

The Swift, from Openstack project, is one of the simplest storage cluster in the world. Like any other cloud solutions in nowadays, it's quite young project, and tries to follow Amazon service, which is called as "S3". The project is supported by vendors who wants to take lead in cloud market. It has a quite simple architecture to understand, easy to install and use. There's tons of blog posts about its benefits that you can find on internet, so I'll not explain those things on this. 

What I want to mention about Swift is, it looks easy to build up, but it isn't for enterprise service in my personal opinion. I've been worked for this storage cloud from early of last year for KT, and some other companies in Korea. Actually, the Swift system for KT is built by Cloudscaling, and I've been worked for it's hardware issue support first. After then, I wrote some automation codes for it with chef, and it's working on some services. So, I think I can speak something about its infrastructure, and it may helps your concern about how to build Swift infrastructure. 

In perspective of infrastructure, it has to be scaled-out as maximum as it can. That means, the network has to be designed for it. Not only for the network, we have to consider about commodity also. More important fact is, scale-out does not mean high performance every time. Here's the key factors to consider when we build Swift cluster. 

a. Low SSL performance of Swift proxy. 

b. Network design - Management, Service, and Storage. 

c. Number of disks per processor.  

d. Spec of each nodes. Network, CPU, memory, network. 

e. How to balance the load. 

f. Number of zone ( it's different with compute cluster ) 

g. Account, Container service load. 

f. Automation 

...and more and more.. 

To be honest, it's not easy  to archive all of those things yet. because there's many things are not proved yet. And those factors cloud be differentiated by service use cases. In other words, most factors shown are depends on type of services, because the most basic performance is based on disk I/O. So, if we are building this Swift cluster for A service, not for public such like Amazon's S3, then we can aim it's best performance architecture by type of service. I might can say, it can be adjusted by number of disks per processor. If the service is used for larger objects, then we can put more disks per processor. If not, then we can reduce the number of disks per processor, and can see how it effects to the performance. One another way to improve disk performance in Swift is, using Raid controller which has Cache memory for write back and BBU for maintain cache information. Basically, Swift recommends to do not use Raided volumes, so you might have some curiosity for this mention. The way to implement this, make every single disk as Raid 0, and creates volumes on it. So, if you have 12 disks on storage node, then you have to build each one as Raid 0, then you'll have 12 Raid 0 volumes which is not stripped. The reason why using this is, to use "write back" function. If we use this way, then a storage node will writes to the Cache memory of Raid controller, instead of actual disk ( or buffer on disk ). This will gives many performance effect for disk I/O. But remember this, put Raid controller to every single node will make higher costs. Here's some good article for this kind of issue, but it's based on S3.    

Not only for the number of disk per node, the network is great pain point when we build this. Currently, most cloud services are using MLAG for non-blocking network. Well, it cloud be ok for Swift clusters. However, as we all know, the MLAG is vendor specific, and it needs layered architecture when we want cluster to be scaled-out massively. It also needs more expensive switches for top layer ( which can be called as "backbone" ), based on chassis, which is very expensive thing.  And more, a single node's network status change effects to the core network also because it's based on L2. As an example, if there's huge number of nodes, then the core network should have all of the information of each node's mac-ip map. In various MLAG architecture, it's not flexible for its status change, so it makes serious problem sometimes. And as you can easily imagine, there's more possibility of failure when number of server increases, then the network cloud be slower because of the actions such like update, reference on the table. And there's some MLAG doesn't support active-active, means the bandwidth utilization cloud not be maximized. So, I would like to suggest to use L3 from ToR architecture, such like an iBGP/OSPF with ECMP. Dan Mihai Dumitriu from Midokura and I are figured out how it works for cloud network, and it's effect is exactly same as we wanted. Faster fault tolerance, single node's status change does not effect to core network, not hard to expand, and can be massively scale-out. It's explained in old post at this blog, but unfortunately, it's wrote in Korean. But you can easily understand because it has diagram, and actual switch configurations. Anyway, it solves most problems of MLAG or L2 based architecture, and we can archive more good model for enterprise services.

One more important thing is, the problem of SSL. Swift is based on REST API, and it means the authentication / authorization information are flow through HTTP header. It means we need to secure every single HTTP request with SSL, so the HTTPS is basic thing to make service secure. However, the Swift proxy is built with python, so it's SSL performance is terrible. Therefore, we need to put something else to make it work faster. That is, process SSL with reverse-proxy or software based load-balancer, then pass the requests to Swift proxy which runs without SSL. If you are an infrastructure engineer, then you 'll have some ideas about how to solve this issue. There's some ways to solve this, but one thing that I want to notice is do not use hardware based load balancer which has OpenSSL hardware integration feature. Well, it could be better than single machine's performance, but it's more expensive than software. Don't forget you're building a cloud service, which means there's possibility that every components of service could be added or expanded. 

The last thing is ( even if there's much more things ), about the zone. All of the Swift document says the "5" zone is needed by default. If you have a good understand of Swift, then you already know about what the zone is, which has strong relationship with cluster expansion. And more, it's related with every single rack ( cabinet ) design. This is about how to make expansion model, and also how to make fault tolerance model. As I raise this issue, so you can think about why the "5" is considerable number, and how it effects to the cluster when we change the number to another. 

Not like many other open sources, this solution cloud not be used with "default" options. If you can remember how the linux worked in late '90, then you may understand what this means. There was "no" defaults, and sometimes we need to change some source codes before we compile, and use it. Back to the Swift, I didn't say about DB updates when massive requests comes into Swift cluster yet, because it's needs to figure out by your hands, for your services. There are many decision points exists, it means sometimes it's too hard to go on with this. It's strongly needed to do many tests to build this cluster for right service, then you can solve many of this issues. In my experience, if you build this cluster in production level without PoC or massive tests, then you'll fall into deep problem that cannot escape.  

Many contributors are working hard for Openstack, and I give thanks to them. It's get better and better as time goes by, and I believe that all of its component will be stabilized with more features in not far distant future. Swift is considerable solution when someone want to build huge size storage cluster which will used through Web. But there's always tuning point exists, so our major job to figuring out "butterfly effect" in cloud. The small change will makes huge difference for performance, and costs.

Thanks for reading this post in ugly English, and please feel free to write your opinion about this. 

(, Younjin Jeong )  

System & JavaScript

( , 정윤진 )

오래전에 그만두었던 프로그래밍을, 최근 들어서 다시 하게 되었다. 그 첫번째 이유는 인프라의 자동화와 관련되어 있는 Ruby 코드를 작성하기 위한 것이었고, 그 두번째가 바로 오늘 포스팅할 주제, 자바 스크립트 때문이다.

Aptana Studio 3.02

솔직히 말해서, 리눅스 커널/드라이버 관련 개발을 그만두고 나서는 별로 개발 할 생각이 없었다. 90년도 후반에 리눅스 배포판을 성공적으로 설치하면 따라오던 HOW-TO 문서를 따라하는 재미도 쏠쏠했고, 이미 이때부터 소개된 클러스터링이나 당시 떠오르던 웹 플랫폼에 관련한 인프라 기술들이 나에게는 더 매력적으로 느껴졌고, 또 더 재미 있었기 때문이다.  무언가를 미시적인 관점에서 살펴보는 것보다, 거시적으로 만들어 내는 재미가 보다 컸던 이유로, 또 하나는 이미 중학생 때부터 어셈블러, C, C++, Windows 95 API, MFC 클래스를 달달 외워낸 친구가 있었기 때문에, 그렇게 개발은 일찌감치 손을 떼었다. 고2때 이미 DirectX 3.0 을 가지고 3D 큐브 게임을 만들어 내던 놈이었으니, 당시가 이미 97~98년도다.

다시는 돌아보지 않을 것 같던 이런 탭으로 들여쓰기 해 놓은 코드들이 다시 언젠가부터 꼭 보아야만 할 것들로 다가오기 시작했다. 그 시작은 예전부터 자주 죽어나가던 데몬들의 사망 원인을 밝히기 위함이었고, 더 나아가서는 회사에서 사용하는 PHP의 프로파일링이 필요 했었고, 보안을 위한 exploit 의 코드를 twick 하여 운영서버에서 모의 테스트를 하는 등의 이유였달까. 더군다나 최근에 들어서는 인프라의 다량화가 진행되면서, 더이상 쉘코드나 펄과 같은 도구만으로는 자동화가 힘들었기에, Chef나 Puppet의 사용을 위해서 인프라를 코딩하는 정도의 수준에서 다시금 개발에 손을 대게 되었다.

Do you want to know more?

Image from:

일을 꾸준히 하면서, 소스코드를 쓰는 능력이 필요한 개발자와 소스코드를 읽어낼 줄 아는 운영자의 능력 중, 후자의 능력을 배양하는 것은 제법 힘들지만, 반드시 필요하다는 점을 강하게 깨닫게 되었다. 시스템의 문제는 통상 인프라를 구성하는 일반적인 오픈 소스데몬의 문제라기 보다는, 그 위에서 동작하는 어플리케이션에 문제가 발생하는 경우가 대부분이고, 특히 국내와 같은 환경에서는 잘잘못을 가리기 위한 부분보다는 문제를 빠르게 해결 하기 위해, 그 필요성은 점점 더 강해졌다. 서비스 운영 중 대부분의 시간에 개발자가 관여하는 일은 드물고, 업데이트로 인해 발생했던 장애에 대해 그 원인의 분석은 코드에 까막눈이고서는 절대 불가능하다. 더군다나, 일부 개발자가 책임을 회피하기 위해서 묵비권이라도 행사하는 날에는 골치가 이만저만 아픈게 아니다. 이러한 점은 리눅스나 유닉스 기반에서보다, 윈도우 기반에서 더 강하게 느껴졌던건 아마도 윈도우 커널과 Support Tools에 대한 일천한 지식과 다소 폐쇠적인 윈도우 자체가 큰 몫을 했으리라.


Image from:

뭐 어쨌든 그런 시절은 지나갔고, 나에게 생소했던 닷넷이라는 프레임웍은 이제 당분간 보지 않아도 되게 되었지만, 현희형과 준호형, 그리고 AJ, 그렇게 함께 만들어 냈던 일본의 모 서비스가 쌩쌩 돌아가는 것을 보면서, 무슨 도구던지 제대로 만질 줄 아는 사람들이 뭉치면 어마어마한 서비스 퀄리티가 튀어나온다는 것도 깨닫게 되었다. 진정한 협업이란 그런 것이었을 게다.

Real Collaboration

Image from:

이제 그분들과 모두 적을 달리하게 된 지금에 와서 컨설팅으로 여기저기 쑤시고 다니다 보면, 참 어이없는 상황들을 많이 맞이하게 된다. 게다가 그분들과 같이 일하게 되면서 괜시리 눈만 높아진건 아닌가 하는 생각이들 정도로, 웹 어플리케이션의 완성도에 대한 욕구는 커져만 갔지만, 인프라 아키텍쳐와 어플리케이션의 설계에 대한 방향성은 제시 할 수 있어도 내가 직접 샘플을 보여 줄 수는 없다는 현실에 점점 기술적인 못난이가 되어가는 느낌을 지울수 없었다.

너 못났어! ㅠㅠ

Image from:

요새 맨날 클라우드 이야기만 풀었는데, 굳이 클라우드가 아니더라도 요새의 서비스들은 자바 스크립트와 Ajax, 그리고 HTML5 를 통한 서비스 구성의 유연성이 날로 확대 재생산 되고 있다. 더군다나 최근 서비스의 주요한 개념인 Eventual Consistency 의 주요한 사용은, 더 이상 자바스크립트와 Ajax를 모르고서는 세상살기 힘들겠다는 생각이 들게 하기에 충분했다. 더군다나 최근 인프라에 사용되는 여러가지 도구들과 서비스들은 실제 웹 페이지 기반 보다는 REST로 구성된 API 호출의 형태가 많아졌으며, 이를 통해 주고 받는 JSON 또는 XML의 데이터들은 이런 기본 언어들을 모르고서는 페이지 한장에 간단히 표시조차 하기 힘들어 졌다. 게다가 카산드라나 Reddit, SimpleDB 와 같은 NoSQL 지원 서비스들의 등장은 이제 제아무리 시스템 분석가라 하여도 코드를 읽거나 간단한 시스템 동작을 시뮬레이트 할 수 있을 정도의 코딩 능력이 없다면 개발자들과 대화하는 것도 쉽지 않겠다 라는 생각에 이르게 되었다.


Image from:

시스템 하는 사람이 오지랖도 넓네 라고 말할지도 모르겠지만, 경험상 이러한 도구들이 어떻게 어플리케이션에 사용되는지를 알고, 어떤게 제대로 사용하는 것인지를 아는 것은 매우 중요하다. 물론 내가 직접 개발을 해서 좋은 코드를 쓰겠다는 것은 분명 아니다. 하지만, 만들어진 코드의 동작이 인프라의 설계 구조나 목적과 부합하는가의 여부에 대한 판단은 정말로 중요한 것이어서, 이는 누가 어떤 일을 하는가에 대한 롤의 분류보다 서비스 그 자체를 문제 없도록 하는데 더 큰 이유가 있는 것이다.

그러한 이유로 해서, 좀 시간을 두고 살펴보아야 할 것들을 간추려 보니 HTML5, Java Script, Ajax 정도가 될 것 같다. 그야말로 필수 요소만 보겠다는 노력이 가상하지 않은가! 

서버 인프라 분야에서 일을 한다고 해도 꽁짜 VM을 쓰는것은 만만치 않다. 뭐 물론 방법이 있기는 하지만, 굳이 그런 방법을 쓰지 않더라도 로컬에서 코드 동작하는거 테스트 해 보는 정도로 앱태나는 정말 걸출한 듯 하다. 게다가 Github나 Cloud9IDE, 구글 사이트의 도움 정도면 사이트를 개발하는데 필요한 것들은 무난하게 배워 볼 수 있지 않나 싶다.

신기한 것은, 묘하게 욕구가 샘솟는 점이다. 이는 아마도, 인프라스트럭처/네트워크/스토리지/큐/메세지/백엔드/프론트엔드 에 대한 원큐 샘플을 필요한 모델별로 만들어 낼 수 있을 것 같다는 기대감에서 오는 것 같다. 구글API나 트위터 API를 사용한 인증 체계의 구현 모델이라던가, 이에 얹혀지는 컨텐츠들의 저장과 메세지 통신에 대한 것들을 좋은 모델로, 또 각 부분의 코드로 제시할 수 있다면 이 얼마나 기쁜 일이겠는가.  게다가 이 블로그를 조금 더 이쁘게 내손으로 코딩 할 수 있는 재주까지 생기게 되는것은 덤으로 얻어지는 행복일 것이다. 

이런 그림과 코드의 제공을 동시에!!

Image from:

비동기로 가능해지는 기존에 생각 할 수 없었던 많은 부분의 분산처리 모델은 분명 또 다른 컴퓨팅의 모델일 것이다.

그리고 혹시 여러분은 Darkstar 에 대해 들어보신적이 있는가?  어마어마하게 흐르는 SNS 메세지 형태의 데이터 형태들을 실시간 분석에 사용할 수 있다면 얼마나 좋을까?  아마 이런 기술의 사용도 앞으로 볼 생각을 하니 묘한 기대를 넘어 흥분까지 되는 것 같다. 훗. NoSQL을 넘어 Continuous SQL로, Cloud Event Processing 으로!  이건 나중에 기회가 되면 소개하도록 하겠다. 못 기다리시는 분들은 아래 링크의 pdf 에 소개된 내용을 바탕으로 구글링을 쎄워 보시도록.

돌아다니다 보니 깔끔하게 정리된 튜토리얼 페이지들이 몇개 있어 소개한다.

HTML5 - 영문 페이지

JavaScript - 영문 페이지

Ajax - 한글 페이지

이론과 개념에 대해서는 옆의 링크에 소개된 A.J의 블로그도 많은 호응을 얻는 것 같다.
심화된 자바스크립트의 사용 역시 옆의 링크의 파이어준 횽아의 블로그도 인기 절정.

About Darkstar, SAX, Continunous SQL

Darkstar 개발자인 Colin Clark의 블로그

(, 정윤진)

Serious Cat, "Yay"

Image from:

Build Automated Infrastructure with Chef - Chapter 1

( , 정윤진 )

최근 클라우드가 부각되면서 자연스럽게 이슈가 되고 있는 것이 바로 자동화된 인프라스트럭처의 구성이다. 이미 지난번에 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 :
* lvs  :
* repcached , memcached : ,
* iptables : 
* postgresql :
* nginx :

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

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

( , 정윤진 )