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

블로그에 Beagle Bone 을 소개하고 아는 사람은 다 아는 Arduino 를 포스팅 한 지도 벌써 몇 개월이 흘렀다. Beagle Bone 두세트와 7" LCD, 그리고 Beagle board C4 가 프로젝트에 밀려 사무실 구석에서 홀대를 받고 있다. 조만간 이뻐해 줘야 하는데... 

프로젝트와 관련하여 이것 저것 찾아보다가 문득 다음의 제품을 발견 했다. 

http://artrobot.co.kr/front/php/product.php?product_no=545&main_cate_no=4&display_group=1

오호라~ 하면서 조금 더 찾아 보니

http://netduino.com/

이를테면 닷넷 프로그래머가 아두이노를 쓸 수 있도록 만든 보드가 된다. 

아두이노를 아는 사람이라면 모두 알겠지만, 닷넷 키워드 검색을 통해 이 블로그가 얻어 걸린 분들에게는 다소 생소 할 수도 있는 이 장치의 사용에 대해 말해 보자면, 

1. 각종 이런 저런 일을 하는 무지하게 많은 종류의 센서 ( 입력 ) 

2. .NET Micro framework 를 사용하여 신나게 C# 으로 뭔가 로직 코딩 

3. 코딩의 결과를 다시 이런 저런 일을 하는 무지하게 많은 종류의 액츄에이터나 모터와 연결 ( 출력 )

간단한 장난감으로는 

1. 무인 RC 자동차, 헬리콥터, 비행기 

2. 마이크로 마우스 

3. 짝퉁 달 탐사 로봇 

을 만들 수 있다. 

맨날 LED 사다가 깜빡이 만들어 보고 아 지겹다 해서 접지 말고, 재미를 붙였다면 

http://artrobot.co.kr/front/php/product.php?product_no=522&main_cate_no=4&display_group=1

이런 비슷한 프로젝트를 달려도 얻는게 많을 듯. 

아니면, 

http://artrobot.co.kr/front/php/product.php?product_no=41&main_cate_no=48&display_group=1

http://artrobot.co.kr/front/php/product.php?product_no=578&main_cate_no=48&display_group=1

Arduino + Android 조합도 꽤 많이 있으므로, Netduino 도로 충분히 가능 할 듯. 

나는 닷넷 개발자는 아니지만 C 가 아닌 다른 언어의 개발자가 이런 재미진 임베디드를 할 수 있다는 사실은 즐거운 일이지 않은가. 

어릴때 딱딱한 성적표 만들기 이런 거로 프로그래밍 하다가 질린적이 한두번이 아닌데, 이런 장난감이 그 시절 있었다면 지금쯤 난 아마도 우주선을 만들고 있지 않을까. 여러모로 좋은 시절인 것 같다. 

이건 FPV ( First Person View ) 영상.  영상을 보면 알겠지만, 기존의 RC 처럼 날리는 것이 아니라, 안경과 같은 고글에 나오는 실시간 비디오 이미지를 보고 ArduCopter 를 날리는 모습이다. 

이런 개인 시점화 된 FPV 를 날리는 것이 가능한 것은, 바로 이 장비로 가능한 것. 

Fat Shark RCV922 Aviator Edition Full FPV KIT- 2010

조종사의 느낌으로 비행이 가능 하도록 지원 해 주는 것. 당연히 FPV 에는 카메라 장치와, 이미지 전송을 위한 장치가 필요하다. 관심이 있다면 여기서 원큐에 구매하는 것도 가능. 구글링 해 보면 판매 하는 사이트가 더 많은 것 같기도. 

http://fpvsystems.com/index.php?main_page=product_info&cPath=5&products_id=5

최근 여러가지 방송에서는 RC 에 카메라를 붙여서 영상 이미지를 얻는데 사용하는 경우가 많아지고 있다. 하지만 이렇게 얻어진 영상의 경우 대체적으로 RC 가 만들어 내는 미세한 진동 때문에 보기 불편한 경우가 있는데, 이럴때는 자이로를 이용한 Stabilizer 를 사용한 마운트로 카메라를 고정 시키는 방법도 있다. 아무튼, 여기에 5D Mark II 를 붙이면 어떻게 될까 

여기서 이제 카메라를 조금 더 오버 스펙으로 가 보자면, 

http://www.alibaba.com/product-gs/524756128/UAV_electro_optics_search_system.html

이런걸 붙이게 된다는.... 

하지만 저만한 하중을 견디려면 더 큰 사이즈의 비행체가 필요하게 된다. 이제 단순 방송 장비의 규모를 벗어나게 되면, 

1. 조종 시스템과 관찰 시스템의 분리 

2. 킬로미터 단위의 low latency radio control 

3. 킬로미터 단위로 비행 해야 할 만큼의 Long range flight 

뭐 대충 이런 요구 조건을 충족하다 보면 군사용 UAV 가 된다. 이를 테면, 

http://www.fas.org/spp/military/docops/defense/actd_mp/MAE.htm

image from: http://www.dfrc.nasa.gov/Gallery/Photo/Altair_PredatorB/HTML/ED06-0208-1.html 

해성이가 발사나무로 RC 비행기 잘 만드는데, 재미로라도 UAV 만들어 보고 싶다. 뭐 언제나 그렇지만 돈이 문제지 +ㅁ+ 

netduino 설명인데 덧이 너무 많이 붙어 버렸네. 

뭔가 날라다니는건 언제나 추락 할 위험이 있다. 그런게 싫다면, 이런거도 좋지 않을까. 

image from: http://en.wikipedia.org/wiki/File:NASA_Mars_Rover.jpg

뻘글이 넘 길어졌다. 암튼 일단 질러야 할듯. 

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

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

요 몇년 새에 참 많은 업체와 사람들, 그리고 솔루션을 만났더랬다. 물론 아주 좋은 업체도 있었고, 당시에는 좋은 것 같았는데 지나고 보니 안그랬던 것 같은 업체도 많았던 듯. 한가지 강하게 느끼는 것은, 내가 뭔가를 생각해서 검색해 보면 항상 누군가는 이미 만들어 놓고 입을 벌리고 있다는 사실이다. 세상은 그렇게 부지런하기만 한데, 대체 나는 무엇을 하고 있나. 

작년에는 Cloud.com 이 Citrix 에 인수 되더니, 올해는 Nicira 가 VMware 에 인수 되어 버렸다. 게다가 Nicira 의 인수 금액은 1.5 billion 에 달하는 엄청난 돈이어서, Network virtualization 이 가지고 있는 어마어마한 가능성을 보여주지 않았나 싶다. 수형형이 언제나 이야기 했던 대로, 비슷한거 했던데는 많지만 제대로 하는데가 없었는데. 작년 KT 에서 테스트 해 보고자 했을 때만 해도 그다지 좋은 분위기의 업체라고는 생각하지 못했는데, 이렇게 떼돈 버는거 보니 참 인생 한순간이구나 싶은 생각이 들기도. 

http://www.enterprisenetworkingplanet.com/netsysm/vmware.html

http://nicira.com/

오늘 이순간에도 내가 알고 있는 회사들 중의 한군데는 내일 모레 몇천억에 팔릴지도 모른다는 생각을 하게 된다. 누구나 말할 수 있는, 남들과 엇비슷한거 만들어 봐야 어쩌구 하는 이야기 따위, 같이 메일 주고 받고 갈구던 애가 어느날 백만장자가 되어 "잘 지내냐" 하고 물어오는 걸 들어 보지 않으면 모를 일이다. 

Processing / Storage / Connectivity 3개 기본 요소 중 2개는 결판이 났네. 이제 다음은 어딘가에서 하고 있는 Elastic Storage 인가.. 아니면 어거지로 Elastic Security 하나 끼위 넣어야 하나. 

Nicira 의 소식에는 박수를!  잘하고 선두면 좋은 가격에 인수 되야 하는것이 인지상정.

투자 할 돈 따위 없으니 뭐라도 만들어야지... 

뭐라도 되겠지 하고 살다가 위궤양 걸리겠다. 

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

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

최근에는 클라우드를 사용한 온라인 개발 도구가 늘어나고 있다. 이미 좀 오래 되었지만 github 라던가, Cloud9IDE, 그리고 최근 firejune 에 의해 커스터마이즈된 JSbin 과 같은 도구들은 클라우드의 기능성과 더불어 언제 어디서나 개발이 가능한 환경을 만들어 주고 있다. 

국내 클라우드 업체들에서는 모두 아마존 꽁무니 쫒아 가느라 가랑이가 찢어지는 사이에, 이러한 도구들은 개발자들에게 가뭄의 단비와 같은 솔루션이 되고 있지 않나 싶다. 기실 조금만 생각 해 보면 서비스로서의 가치가 충분한데도, 아마존은 쫒아가려 하면서 구글은 쫒지 않는, 즉 바꿔 말하면 호스팅 서비스 그 이상의 무엇이 없지 않나 생각 해 볼 일이다. 

호스팅 서비스 역시 지난날의 웹 콘솔을 통한 관리를 넘어, 이제 oAuth 나 OpenID 등을 통한 인증, 그리고 이 인증을 바탕으로 한 API 의 지원이 필수적인 요소가 되어가고 있다. 클라우드로 만드는 서비스를 이제 서비스 업체의 웹 브라우저 콘솔만으로 제어하는 것은 이제 바가지에 밥떠먹는 것과 같은 시대가 되어 버렸다. 

오늘 소개할  Heroku, 그리고 Joyent 와 같은 클라우드 기반 호스팅은 사용자가 서버를 설정 할 필요 없이, 제공되는 클라이언트 도구 또는 다른 서비스와의 연동을 통해 온라인으로 언제 어디에서나 코드를 작성하고, 이를 배포하여 서비스 동작 여부의 확인이 가능하다. 따라서, 기존 node.js 또는 기타 여러가지의 서비스를 온라인에서 사용하려는 경우, 서버를 설치하고, 코드 저장소를 설정하는 등의 노력 없이 그저 서비스에 로그인하고, 사용하다가 일정 수준 이상의 사용량이 되면 금액을 지불하면 된다. 

사실 개발자에게 개발이 가능한 전체 환경의 설정은 매우 피곤한 일이 아닐 수 없다. 물론 내가 개발자는 아니지만, 대다수의 많은 개발자 분들이 환경 설정하는데 꽤 애를 먹으며, 이게 코드가 문제인지 인프라가 문제인지 알쏭달쏭한 경우에 빠지는 경우도 많다고 생각한다. 이러한 난제를 해결하는데 클라우드만큼 좋은게 없으며, 사용자 또는 개발자는 그저 서비스 신청, 개발환경 접근, 배포의 과정을 아주 쉽게 처리 할 수 있어 개발에만 전념 할 수 있도록 도와준다. 

오늘 소개할 조합은 바로 온라인 개발도구 Cloud9IDE ( http://c9.io ) 와 일종의 PaaS 서비스 Heroku ( http://www.heroku.com )  이다. 일단 사용량이 많지 않은 경우에는 무료로 사용 할 수 있으며, 처음 가입시 별도의 카드 정보와 같은 결재 정보도 필요 없다. 환경을 설정 해 보고, 코드를 개발 하면서 개발 된 코드가 정상적으로 동작 하는지 확인 하는데 사용하면 좋을 것 같다는 생각에 포스팅 해 본다. 물론, 이미 알고 계신 분들도 많겠지만. 

먼저, Heroku 에 가입한다. 가입 절차는 매우 간단하며, 메일 주소와 비밀번호 정도만 입력 하면 된다. 홈페이지에 접근하면 한 가운데 떵그머니 있는 Sign Up 버튼을 이용하자. 가입이 완료되면 로컬 머신에서의 환경 설정이 나타나는데, 이건 필요하면 하고 Cloud9 의 서비스와 연동할 거라면 굳이 하지 않아도 된다. 개발자에게는 골치 아픈 일일 뿐이다. 

가입을 완료 했으면 일단 두고, 이제 Cloud9IDE 에 가입하자. 역시 동일하게 계정을 생성하고, 로그인 후에 대시보드를 통해 프로젝트를 생성해 본다. 프로젝트를 생성했으면 "Start Edit" 을 살포시 눌러 실제 코드의 작성이 가능한 브라우저로 이동한다. 

이제, 아래와 같은 화면을 볼 수 있다. 

Cloud9IDE Project Page

화면 구성을 보면 일반적인 IDE 환경과 크게 다르지 않다. 가장 왼쪽에는 파일 브라우저, 배포, 설정, 테스트 등의 기능의 선택이 가능하고, 나머지는 온라인 코드를 수정하기 위한 공간이다. 새로운 파일은 왼쪽 상단의 파일 메뉴에서 생성이 가능하며, 원하는 경우 각종 코드 템플릿을 선택하여 사용 할 수도 있다. 생성된 코드는 일반적인 에디터의 저장 단축키와 같은 Cntl+s, 맥에서는 command+s 로도 잘 동작한다. 

여기까지는 일반 개발환경의 설정이며, 이제 Heroku 서비스로의 연결이 가능하다. 먼저, 왼쪽 기구 모양의 Deploy 버튼을 누른다. 

파일 브라우저의 모양이 바뀌면서, 상단에 -, + 버튼이 생긴다. 여기에서 + 버튼을 눌러 보면 다음과 같은 화면을 볼 수 있다. 

C9IDE, Select deploy site

위의 버튼을 눌러보면, Cloud9 이 지원하는 클라우드 기반 서비스를 확인 할 수 있다. 다른것은 모르겠는데, Windows Azure 를 지원한다. 이는 곧, 기존의 닷넷 개발자 분들도 git, Azure 에 대한 가벼운 이해만 있다면 C# 코딩을 그대로 하실 수 있다는 말이 되겠다. 아직 안해봐서 나는 모르겠지만, 아무튼 지금의 목적은 Heroku 로의 연결이므로, heroku 를 선택하고 아까 만들었던 Heroku 의 계정을 입력한다. 그리고 오른편의 Create New 버튼을 누르면, heroku 로 부터 코드 배포에 사용할 인스턴스를 만들 수 있다. 원하는 이름을 주고 하나 만들어 두자. 

생성을 완료하고 페이지에서 나오면, 이제 Deploy 탭에 Heroku 에서 생성한 인스턴스의 이름이 나타나는 것을 볼 수 있다. 이 인스턴스 이름을 클릭하면, 배포가 가능하다. 하지만 아직 배포할 코드가 아무것도 없으므로, 하나 작성해 보도록 하자. 

코드를 작성하기 전에, 다음과 같은 주요 내용을 이해해야 한다. 

1. Heroku 는 git 를 사용하여 동작한다. 코드를 생성하고, git push heroku master 와 같은 방법으로 동작하지만, Cloud9 에서는 그런 별도의 과정 없이 Cloud9 의 로컬 저장소에 commit 한 후에 인스턴스에 Deploy 하면 쉽게 적용 된다. 

2. Heroku 에서 Node.js 를 동작하기 위해서는 필요한 패키지, 실행 할 인스턴스의 수량 또는 종류 등을 지정해야 한다. 이는 Heroku 의 문서에 잘 나와 있으므로 여기를 참조 하도록 한다. 

https://devcenter.heroku.com/articles/nodejs

3. 기본적으로 Node.js 의 동작에 대해 이해하고 있어야 Heroku 를 손쉽게 사용 할 수 있다. 

Cloud9IDE 의 왼족 상단의 Project Files 를 클릭하고, 신규 파일을 다음과 같이 저장하자. 

파일: .gitignore 

 node_modules 

package.json

{
    "name": "node-example",
    "version": "0.0.1",
    "engines": {
        "node": "0.6.15",
        "npm": "1.1.9"
    },
    "dependencies": {
        "express": "2.5.9"
    }
}

Procfile

 web: node web.js

web.js

var express = require("express");

var app = express.createServer(express.logger());

app.get('/', function(request, response) {
    response.send('Hello Firejune!');
});

var port = process.env.PORT || 3000;
app.listen(port, function() {
    console.log("Listening on " + port); 
});

대충 보면 감이 잡힐지도 모르겠다. 

.gitignore 는 git 로 작업할때 무시할 디렉토리이다. 여기에 node_modules 가 지정된 것은 node_modules 디렉토리를 heroku 에 업로드 하지 않아도 되기 때문이다. 업로드 하지 않아도 되는 이유는 바로 package.json 에서 필요한 패키지를 명시하였기 때문이며, 여기에 필요한 패키지 리스트를 잘 지정하였다면 별 문제 없다. 물론 여기서 애플리케이션 동작에 필요한 각종 모듈 및 node, npm 의 버전 명시가 가능하다. 사용 가능한 버전은 Heroku 페이지를 통해 공개되고 있으니 구글링을 통해 참고 하면 된다. 사용 방법은 위에 명시된 것과 같다.  Procfile 은 Heroku 에서 구동할 애플리케이션의 용도와 파일을 지정한다. 마지막으로 web.js 는 실제 node.js 를 사용하여 작성한 코드가 된다. 

Cloud9IDE 의 아랫쪽을 보면, console 이 있다. 이는 각종 커맨드의 사용을 위해 존재하는데, 여기서 우리는 npm 으로 필요한 모듈의 설치가 가능하다. 위의 예제는 heroku 로 부터 제공된 것으로서, express 모듈을 사용하고 있다. 따라서 이 콘솔에 다음과 같이 입력한다. 

npm install express@2.9.5 

이후 설치 메세지가 나타나는 것을 확인 할 수 있으며, 만약 현재 Cloud9IDE 의 버전과 맞지 않는다면 npm info 등을 통해 적절한 버전으로 변경 해 주면 된다. 

이제, 작성한 코드가 잘 동작하는지 확인 할 필요가 있다. Cloud9IDE 의 아랫편에 보면 Console 이 있는데, 여기에 커맨드를 입력하여 원하는 작업을 할 수 있다. 다른건 됬고, git 관련 커맨드만 넣도록 한다. 

git init
git add .
git commit -m "First commit for Heroku"

모두 다 실행이 완료 되었다면, 다시 제일 왼편의 Deploy 를 클릭한다. 생성된 애플리케이션 인스턴스를 클릭하면 Deploy 버튼이 나타난다. 클릭하자. 

자, 그러면 이제 Cloud9IDE 의 로컬 repo 에서 Heroku 로 코드가 업로드 되고, 이후 애플리케이션이 준비되는 과정을 로그로 볼 수 있다. 정상적으로 잘 수행하였다면, 다음과 같은 화면을 볼 수 있을 것이다. 

제일 아래 나타난 링크를 클릭하면, 배포된 애플리케이션이 동작 하는지 아닌지를 잘 알 수 있다. 

만약 기존에 개발한 애플리케이션이 다른 버전의 node 와 npm 을 사용한다면, 아래의 링크를 통해 현재 Heroku 에서 지원하는 버전의 지정이 가능하다. 

node.js version manifest

npm version manifest

아마 클라우드라는 환경을 가장 생산적으로 사용이 가능한 사용자군은 개발자들일 것이다. 적절한 방법과 사용성만 있다면, 아이폰의 앱 결재 하듯 한달에 1~2 만원 지불하면서 본인의 자가 발전을 위해 사용해도 아깝지 않을 정도이다. 다만 Cloud9IDE 가 현재 국내에 서버가 없으므로 망의 영향을 받을 가능성이 충분하긴 하지만. 

이런 서비스를 만들어 내는것은 아무것도 아니다 라고 말하기는 좀 그렇지만, 그렇다고 엄청나게 어려운 것은 아니다. 원하는 기능을 적절히 믹스하고, 한번에 잘 동작하게 만든다면 쓸데없이 VM 생성해 두고 뭐할까 고민하는 일은 없을 것이다. 

국내의 각종 클라우드 서비스들도 미국에 비해 일반인의 클라우드에 대한 인식이 현저히 떨어지는 한국에서 매출이 안나온다고 고민하고 있을게 아니라, 위와 같은 서비스의 런칭이 필요하지 않나 생각 해 본다. 

아무튼 준호형과 관련된 재미진 프로젝트를 해 보면 어떨까 한다. 이와 비슷한, 그러나 뭔가 다른. 

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

( younjin.jeong@gmail.com, 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. http://improve.dk/archive/2011/11/07/pushing-the-limits-of-amazon-s3-upload-performance.aspx    

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@gmail.com, Younjin Jeong )