System Compleat.

'YZCerberos'에 해당되는 글 231건

  1. 웹 서비스의 해외 진출 시 고려 사항 2
  2. A podcast about Cloud & DevOps
  3. 블랙홀, 연휴
  4. Tsunami UDP, boost sending files
  5. Lean startup

웹 서비스의 해외 진출 시 고려 사항

Techs


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

최근 풍요로운 모바일 및 웹 시장을 바탕으로 글로벌 진출 시도를 하는 기업 및 서비스가 많아지고 있다. 이들 서비스 중 일부는 국내에서의 성공을 바탕으로 누적된 자본을 사용하여 진출 시도를 하려는 경우와, 기획 초기 단계부터 애초에 국내 시장만을 대상으로 하지 않고 글로벌 서비스를 준비하는 경우 등 서비스의 종류에 따라 그 사례가 다양하게 존재한다. 서비스가 성공한다는 가정 하에 국내에서만 성공했을 때와 글로벌에서 성공 했을 때의 매출 규모는 상식적인 수준에서 당연히 글로벌이 훨씬 유리 할 수 밖에 없다. 

Image from: http://www.technologyreview.com/photoessay/511791/smartphones-are-eating-the-world/


하지만 지난날의 글로벌 서비스를 위해서는 수많은 자본의 투자가 필요해야 했다. 이는 당연히 서비스 종류별로 사전에 염두해 두어야 할 서비스 대상 지역의 관련 법규를 기반으로 한 적절한 구성과 e-commerce 비지니스와 같은 경우 물류를 위한 창고 및 배송을 위한 현지 업체들과의 파이프 라인 등 쉽사리 엄두가 나지 않는 것들, 그리고 진행하려면 a부터 z 까지 모두 비용이 소요되는 그래서 큰 규모의 기업들만이 시도 할 수 있었던 것이 당연시 되었다. 

이들 중 일부 사항들은 현재 전산으로 대체 할 수 있으며 이 대체를 위해 글로벌 지향의 서비스를 사용하게 되면 상당한 비용을 절약 할 수 있다. 오늘의 포스팅은 바로 어떠한 부분을 염두해 두어야 하는지, 또 보다 좋은 고객 경험과 초기 인프라 자원 투자 비용을 어떻게 줄일 수 있는지에 대한 내용을 중점으로 한다. 물론, 여기에 소개되는 내용을 즉각 사업에 반영하여 초래되는 위험을 바라고 쓰는 글이 아니므로 하나의 의견 정도로 찬찬히 살펴보면 어떨까 한다. 

Image from: http://www.welovedates.com/blog/2013/06/how-to-flirt-on-instagram/


최근의 거의 대부분의 글로벌 비지니스는 웹을 기반으로 한다. 웹의 특성상 서비스 대상 지역에서 네트워크 적으로 가까운 곳에 위치 할 수록 빠른 응답시간을 보장 받으며 이로 인해 고객이 물건을 구매하거나 게임을 즐기거나 또는 컨텐츠를 감상하는데 있어 보다 좋은 서비스 품질을 경험 할 가능성을 높일 수 있다. 당연히 필자가 EMS 나 Paypal 과 같은 배송 결재 시스템 및 서비스에 대한 전문가가 아니라 인프라 관련 업을 하는 사람이므로 이 인프라에 대한 논의를 주축으로 삼도록 한다. 


글로벌 서비스를 시작하겠다고 결심하면 인프라를 준비하는데 보통 다음의 세가지 방법 중 하나를 선택하게 된다. 

1. 사업 대상 지역에 설비 구축 
2. 기존 영업관계 및 이미 사이트가 구축 되어 있는 국내의 데이터 센터와 ISP 를 사용 
3. 글로벌 public cloud 사업자를 이용 



이 세가지 방법은 당연하게도 다음과 같은 부가적 요소가 따르게 된다. 

a. 1번의 방법은 시간과 비용 그리고 인력의 소모가 최대가 된다. 따라서 구현을 위한 비용(시간포함), 즉 투자 비용이 상당하다. 
b. 2번의 방법은 1번 보다는 저렴 할 수 있지만 네트워크 지연으로 인한 서비스 품질이 문제가 된다. 따라서 고객의 서비스 경험 수준이 낮을 가능성이 높다. 
c. 3번의 방법은 학습해야 할 내용이 많다. 아울러 사업자간 어떤 서비스를 제공 하는지 확인이 필요하기도 하다. 



국내 굴지의 대기업인 경우라면 모르되, 보통 b와 c의 방법을 고려하게 되는 경우가 대다수라 할 수 있다. 일반적인 웹 형태의 서비스인 경우를 기준으로, 결정을 위해서 필요한 1차적인 주요 선택지는 다음과 같은 내용이 될 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 
2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 
3. 데이터베이스 및 스토리지 비용 



이를 조금 더 해부 해 보면, 다음과 같은 리스트를 얻을 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 

- CDN 서비스 제공 여부
- CDN 서비스 제공 지역 및 가격
- CDN 서비스 약정 또는 그와 유사한 계약 필요 여부
- 데이터 트래픽 발생 비용
- 각 지역에 인접한 DNS 서비스 제공 여부
- DNS 서비스에서 제공하는 기능 - 예외 상황 발생시 서비스 운용에 대한 제어권 확득 방법  


2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 

- 미주, 유럽, 아시아등 지역에서 리소스 준비 시간 
- 서비스 유입 증가로 인한 새로운 리소스 조달 시간 
- 서비스 유입 하락으로 인한 기존 리소스 감축 및 이에 따른 비용 
- 과금의 단위에 따른 비용 절감 방안 존재 여부 
- 별도의 운영 인력 필요 여부 
- 로드 밸런서와 같은 부가 기능 지원 여부 


3. 데이터베이스 및 스토리지 비용 

- 지원하는 데이터베이스의 종류 
- 각 데이터베이스의 가격 
- 데이터베이스 백업, 복구, 확장에 대한 지원 범위 
- 저장 가능한 스토리지의 크기 (확장)
- 데이터베이스 및 스토리지 준비에 필요한 시간 


4. 기타요소 

- 캐시 서비스 
- 검색 서비스
- 데이터 마이닝을 위한 서비스 
- 로그의 장기 보관을 위한 서비스 


일반적으로 대부분의 웹 서비스는 다음과 같은 과정으로 컨텐츠를 공급한다. 

DNS query > Page access > Get contents from ...

Image from: http://en.wikipedia.org/wiki/Domain_Name_System


따라서 1차적으로 만약 네임서버 서비스가 한국에 존재하는 경우 모든 글로벌 사용자는 한국으로의 트래픽 유입이 필요하다. 아니, 모든 사용자라 하는 경우에는 어폐가 있으므로 글로벌 각 지역의 recursive 로 동작하는 사용자 네임서버들은 모두 최초 1회는 한국에 위치한 네임서버로의 lookup 이 필요하다. 만약 여기에 짧은 서비스 downtime 을 위해 도메인에 대한 TTL 을 낮게 설정한 경우라면, 한국의 네임서버를 hit 하게 될 빈도는 더욱 높아지게 된다. 

이 말은 즉, 해외에 위치한 사용자가 페이지 접속 이전에 도메인 조회를 위해 상당한 시간을 허비해야 하는 것을 의미하며 여기에 낭비된 시간 만큼 첫 페이지에 대한 접속 시간은 증가하게 된다. 최근에는 이 첫 페이지에 들어가는 도메인이 1개인 경우가 매우 드문데, 별도의 reverse-proxy 를 사용하여 도메인을 통일한 경우가 아니라면 대부분 컨텐츠 전송을 위한 별도의 static 과 같은 추가 도메인을 사용하는 경우가 대부분이며 역시 이 도메인이 많을 수록 사용자는 지연을 경험하게 될 가능성이 높아진다. 

이것은 일반적인 상황이며, 만약 많은 사람이 걱정하는 한국의 국제망 트래픽의 포화 또는 이와 준하는 장애 상황이 발생하는 경우는 어떨까. 이러한 경우에는 조금 더 상황이 심각해져, DNS lookup 에 timeout 이 발생 할 가능성이 높아진다. 이 말은 곧 도메인 조회가 불가능한 상황을 말하며 도메인 조회가 불가능하다는 것은 아예 사이트에 접근이 불가능 해 진다는 말이 된다. 

아무리 사이트를 고객과 가까운 해외에 직접 구축하게 되더라도 네임서버가 한국에 있다면 이것은 상당한 지연시간을 야기하며 짧은 TTL 을 가지도록 설계 한 경우라면 더욱 더 크리티컬한 상황을 만들 수 있게 된다. 


결론적으로 글로벌 서비스를 위해서는 적어도 각 사용자에 가까운 지역에서 마치 CDN 처럼 DNS anycast 와 같은 방법을 통해 가장 근거리에 있는 네임서버 질의를 제공하는 서비스를 사용 할 필요가 있으며, 이는 서비스에 대한 사용자 지연시간을 줄이는 가장 첫 걸음이 될 것이다. 


Image from: http://blog.mailermailer.com/behind-the-scenes/improve-your-newsletter-reading-experience-with-faster-images


두번째로는 페이지에 접근하는 시간 및 페이지 정보 즉, html 을 구성하는데 필요한 서버에 대한 접근 또는 index.html 및 .js .jpg 와 같은 컨텐츠의 직접 전송이 얼마나 빠를 것인가 하는 부분이다. 당연하게 네트워크라는 것은 결국 위성을 제외하면 대륙과 대륙을 연결하는데 광섬유 케이블이나 구리선을 사용하게 마련이며 이 선의 길이가 길면 길수록, 거쳐가는 네트워크 장치가 많으면 많을수록 지연시간이 증가한다. 

이로인해 우리는 일반적으로 CDN 이라는 서비스를 사용하게 되는데, 고객과 가까이 있는 서버에 이런 컨텐츠를 캐싱 해 두고 그 서버로 고객을 유도 함으로서 보다 빠른 서비스 경험을 갖도록 하는 것이다. 고객과 가까운 지역의 위치 판별에는 다양한 방법이 사용되는데, 기본적으로는 IP 기반의 지리적 위치에 근거 하거나 고객이 사용하는 브라우저의 언어, 네트워크 기술로는 geocast 와 같은 방법이 사용되곤 한다. http://en.wikipedia.org/wiki/Geocast  

이 CDN 서비스를 사용함으로서 얻어지는 효용은 상당히 많으며 이미 오랜 기간에 걸쳐 검증되었기 때문에 별도의 추가 설명은 필요가 없지만, 중요한 것은 가격이다. 대부분의 CDN 서비스는 사전 계약을 필수로 하며, 필요한 때에 원하는 지역에 사용하기 위해서는 소정의 제약 조건이 필요한 경우가 대부분이다. 이 제약 조건들은 마치 약정과 같이 계약과 사용량에 대한 고정이 필요한 경우가 대부분이므로 사전에 잘 알아보고 적용하는 것이 필요하다. 




세번째로 데이터의 처리와 전송에 대한 부분이다. 이 부분이 바로 성능과 비용을 결정하는 지점이 된다. 이 부분은 기존의 인프라를 운용하며 적용 해 왔던 컨셉과 클라우드를 도입하게 되는 경우 고려해야 하는 컨셉이 상충되는 지점이기도 하다. 왜 그런지는 다음의 흐름을 생각 해 보도록 하자. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html


1. 기존 데이터 센터에 서버를 구축 하는 경우: 결과적으로 필요 수량 이상의 자원을 투입하는 것이 risk 및 무정지 운영에 중요 

- 사용자 유입량을 예측 + 20% 정도의 마진을 적용 하여 필요 리소스 규모 산정. 스펙, 수량 등 
- 서비스 증설 시점을 마크. 이 마크 지점에 도달하면 필요한 리소스를 추가 구매, 증설 
- 서비스에 대한 폭발적 요구 증가 대비 불가 - 하드웨어 배송, 국내 최소 3주  해외 최소 1.5개월 이상 
- 서비스에 대한 유입량이 기대에 못미치는 경우 투자비용 회수가 거의 불가능 
- 상당한 투자비용, 서비스 성공 또는 실패 하더라도 현재와 같은 모바일 중심의 폭발적 트래픽 증가에는 손실이 예상 

하지만 서비스의 성공/실패는 아무도 예측 불가능하며, 이 말은 즉 유입 트래픽에 대해 예측 하는 것 자체가 어불 성설이 된다. 
예측을 하는것이 불가능 하다면 초기 투자 비용을 넣는 것이 무의미 하며, 유입된 사용자 만큼의 비용을 지불하는 구조가 더욱 매력적일 수 있다는 개념을 정립하는 것이 필요하다. 

만약, 필요한 서버가 5분이면 조달 되고, 업그레이드 역시 10분내에 가능하며 다 쓰고 나면 렌트카 처럼 반납 할 수 있는 서비스가 있다면 어떨까. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html



2. 글로벌 public cloud 사업자를 사용하는 경우: 

- 필요한 서버를 5분내에 조달 할 수 있으므로 트래픽 유입이 증가하게 되면 그저 필요한 수량 만큼 늘리면 된다. (scale-out) 
- 필요 없으면 반납이 가능하므로 트래픽 유입이 줄어들면 필요 없는 수량만큼 줄이면 된다. (scale-in) 
- 사용한 서버의 "시간" 만큼만 지불하면 된다. 
- 서비스 사용량의 폭발적인 증가시 유입량에 따른 유연한 응대가 가능하다. 
- 서비스가 실패하게 되면 모두 종료하여 비용을 더 이상 지불 하지 않는다. 
- 사용한 만큼 지불한다는 말은 사용하기 전에는 낼 돈이 없다는 말과 같다. 즉, 투자비용이 없다. 
- 원하는 지역에 수시간 내로 동일한 형태로 배포가 가능하다. 


국내/국외를 막론하고 사업을 추진하기 위해서는 "예산"을 편성해야 하므로 2번의 방법은 종전의 업무 방식과 맞지 않는다. 하지만 이성적으로 생각해 보면 전기세와 같은 가변적인 금액을 기업에서는 지금도 처리하고 있다. 전화비, 전기세, 수도세 및 기타 가변적인 금액들. 기본적으로 사용한 만큼 지불하는 구조를 가질 수 있는 인프라에 대한 지불 구조를 도입하게 되면 종전의 예측 불가능한 것에 대한 억지 예측을 통해 모자르거나 부족한 부분이 발생할 여지를 없앨 수 있으므로 기업입장에서는 비용 관리에 매우 효율적이다. 

요새 사장님 타고다니실 의전 차량을 누가 구매하나. 리스하지. 



성능에 있어서는, scale-up 은 언제나 한계가 있다. 아무리 대기업이라도 수퍼돔이나 크레이를 들이는 것은 쉬운 의사결정도 아니거니와 비용도 만만치 않다. 최근의 서비스 전체 성능 개선은 '분산' 에서 이루어 지는 것이며, 서비스의 각 구성요소를 얼마나 잘 분산 했느냐에 따라 효과적인 장애 대응과 높은 수준의 서비스 성능을 구가 할 수 있는 것이다. 아울러 여기에 분산이 고정된 수량으로 획일적이지 않고, 유입량에 따라 그 크기를 조절 할 수 있다면 또 이렇게 조절하는 것이 비용과 직결되어 있다는 것을 인지 하는 순간 수퍼돔을 사용 할 서비스는 줄어든다. 




하여, 국내 기존 사업자와 global cloud 서비스 공급자간의 의사 결정 사항에서의 결론은 이제 다음과 같다. 

a. 두가지의 개념을 각각 적재 적소에 적용 했을때 과연 어떤것이 저렴하냐. 
b. 각 클라우드 서비스 공급자 중 그러면 어떤 서비스를 사용해야 할 것이냐. - 종량제를 하면서 성능 좋고 서비스 많은 공급자? 



서비스를 운용할 때 경험은 정말로 매우 중요하다. 경험있는 개발자와 기술자는 없어서는 안될 매우 중요한 자원이며 이들은 서비스에 지대한 공헌을 해 왔다. 하지만 최근에는 이들의 경험이 오히려 기업의 비용 절감에 방해가 되는 경우를 적지 않게 본다. 어쩌면, 어떤 기업은 이러한 비용을 절감해야 할 필요가 없을지도 모른다. 누군가는 이런 흐름이 필요없는 공부를 만들어 내고 종전에 지키고 있던 자리를 위협하고 있다고 느낄지도 모르겠다. 하지만 새로운 것에 대한 배척 보다는 이를 받아 들이고, 기존의 것과 대비하여 어떤 부분이 좋고 나쁜지를 판단하되 올바른 척도를 가지는 것이 중요하다고 생각한다. 경험을 새로운 것을 배우는데 사용하고, 그를 통해 더 나는 경험을 재창조 하는 것. 

이미 수많은 스타트업은 위의 내용에 대해 너무나 잘 알고 있으며, 글로벌을 향한 도전의 중심에 있다. 간혹 해외 서비스라 사용을 못하겠다거나 하는 이상한 애국심을 만나곤 하는데, 그럼 Linux 나 Windows, BSD, Oracle, 또 기타 다양한 하드웨어 벤더들은 왜 사용한다는 말인가. 그런 소리 할거면 커널 개발 트리에 공헌이라도 좀 하던가... 


길게 썼지만 어쨌든 핵심은 국내에서도 저렴한 비용으로 시작된 좋은 아이디어가 인스타그램이나 페이스북, 트위터 같은 서비스로 성장 하는 것이 아닌가 한다. 성공의 발판으로 삼는 도구는, 무조건 나에게 좋은 것이어야 하기 때문에 위에 길게 써놓은 흐름을 기준으로 여러분에게도 좋은 것이 무엇인지를 생각 해 보면 좋겠다. 그를 통해 대박나는 서비스가 사방에서 봇물 터지듯 터지기를 바라마지 않으며. 




Image from: http://www.businessweek.com/articles/2013-01-11/a-distributed-denial-of-service-attack-isnt-an-act-of-civil-disobedience



다 써놓고 보니 뭔가 산으로 간 것 같은 느낌. 

(>ㅇ_ㅇ)> 

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

A podcast about Cloud & DevOps

Techs


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


AWS의 Kingsley Wood 에 의해 공개된 팟캐스트의 링크입니다. 클라우드 컴퓨팅의 여러가지 사용 예와 DevOps 에 대한 주제로 이야기 되네요. 


"

In this episode our discussion revolves around the impact of Cloud Computing on Innovation. AWS's Kingsley Wood shared with us a number of examples of the innovative ideas leveraging on Cloud. We also talked about DevOps and the future of Cloud in Asia. Enjoy and comment please.

"


http://asiacloud.org/index.php/2012-07-17-08-33-19/podcasts 



http://ec.libsyn.com/p/c/6/d/c6db7b8f0470c11d/Kingsley_Wood_Interview_Edited_V3.2.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf8e33d8c1583a47&c_id=6156527 







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

블랙홀, 연휴

Stories


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


연휴란 참 이상한 기간인듯하다. 평소처럼 일이 손에 잡히는 것도 아니고 가족을 위해 뿔뿔이 흩어진 지인들로 별다른 약속이 생기지도 않는 삶의 중간에 만나는 블랙홀같은 느낌이 짙다. 이사를 하기로 결정했던 집에는 당분간 남아 있어야 할 듯 하지만, 여기 저기 남아있는 라이타, 식기, 속옷, 알록달록한 캔디에 냉장고의 꽁치캔마저 심난하게 하는 집에 기나긴 연휴를 보내고 있자니 뭔가 다른것 뭐 없을까 하는 생각이. 





하여 연휴 후에 일정되어 있는 중요한 시험을 앞두고 꼬부랑 글자만 보고 있자니 가뜩이나 안좋은 머리가 타버리는 느낌에 뭐 다른거 없나 하고 찾아 보던 중, 지역 케이블 사업자가 "진짜 사나이" 라는 방송을 무료로 제공하고 있는 것을 알게 되었다. 


십수년이나 지난 군대의 추억이라면 지난날들 마셔버린 알콜이 슥슥 지워버려서 별로 기억도 나진 않지만 방송에 나오는 군대의 모습은 그 모습이 다소 과장되었다 하더라도 이전과는 참 사뭇 다른 분위기고 또 전보다 훨씬 좋은 분위기인 듯 한 느낌이 든다. 예능이지만 간혹 짠한 느낌도 있고 더러운 군대의 느낌도 살아 있다. 하지만 가장 재미있는 요소는 인터뷰 중 중간 중간 나오는 신분 표시와 자막이 아닐런지. 


지난날을 추억하기엔 너무 다른 방송이긴 하지만, 요새 군대에 대한 감상이나 블랙홀 같은 연휴를 지나보내기엔 꼬부랑 글자 문서보다 좀 더 나은 사용자 경험을 선사받아서 나름 감사히 즐기고 있는 와중에 공병대 프로포즈 장면을 보니 괜시리 마음이 불편하다.


미술을 13년 했지만 전공은 전산이고 현재는 자동차 관련 일을 하고 있던 사람이 돌이켜 생각 해 보면 여러모로 잘 맞는 사람이 아니었을까 싶다. 나이도, 관심사항도, 서로 잘 하지 못하는 것을 가지고 있다는 점 그리고 또 앞으로의 삶을 생각 해 보아도 그렇고 주고 받았던 대화나 감정의 확실한 상태를 원하는 나에게 확실했던 것도 또 서로의 핸디캡마저 이해 할 수 있었던, 꽁치캔 주인이 생각났기 때문에.


앞으로 그런 사람은 또 나타날 가능성이 거의 없다는게 지난 경험에 비추어 거의 확실시 되며, 누군가 나타난다면 결국 대부분 우유부단했던 많은 사람들과 같겠지 하는 생각이 드니 나락으로 떨어지는 상심은 아니더라도 삶에 깊숙히 침투했던 좋은 사람의 흔적에 근근히 서글퍼 지는 것은 어쩔 수 없지 싶다. 


생각해 보면 뭐 앞으로 계속 이렇게 지내야 할 건데 이런 블랙홀 같은 연휴 중간에 예능으로 잠깐 정신 팔아보는 좋은 해결책을 찾아 보는 것도 경험이 되겠지. 시간이란건 어떻게든 지내면 내 편이 되는 것이고, 그런 후에는 내가 좋아 하는 것에 더 쓸 수 있을 테니. 이런식으로 나이를 먹는건 참 달갑지 않단 말야. 


뻘짓했던 과거 지사는 됐고 이제 술이나 줄여야 할 듯. 

사실, 원래 없었던 좋은 것이 잠깐 생겼다 없어졌다고 아쉬워 하는건 똑똑한 일은 아니잖나. 

인생을 잠깐 스쳐간 다이아몬드는 원래 내 것이 아니니 말이다. 



블로그를 워드 프레스로 옮기는 일을 시작 해야지. 

미루고 미뤘던 글라이더 조립도. 


다음번 포스팅은 캐시 클러스터에 대해서나 한번 해볼까. 


http://tech-blog.flipkart.net/2012/10/making-deliveries-faster-the-flipkart-cache-cluster/

http://swarmcache.sourceforge.net/

http://www.alachisoft.com/ncache/dynamic-clustering.html

http://link.springer.com/chapter/10.1007%2F978-3-540-75444-2_73

http://ehcache.org/documentation/user-guide/cache-topologies 



하지만 일단 당장은 눈앞에 닥친 시험부터. 



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







Tsunami UDP, boost sending files

Techs


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


사실 국내 센터간의 파일 전송은 일반적인 TCP 전송 방법을 사용하더라도 그다지 느리게 느껴지지 않는다. 하지만 대륙을 건너 수십 기가바이트의 파일을 전송하고자 하는 경우에는 더디게 흐르는 Windows 95 모래시계를 볼 때 만큼 터지는 속을 주체 할 수가 없게된다. 


특정 시일내에 지정된 크기의 파일을 해외로 보내야 하는 경우에는 농담 같겠지만 사실 택배가 제일 빠르다. 요새 우습게 나오는 수 테라바이트의 하드 디스크 대여섯개 분량의 데이터라면 쉽게 10테라 바이트가 넘어가고 이는 초당 1MByte/sec 인 비교적 양호한 국제망 환경이라 하더라도 전송에 필요한 시간은 10,485,760 초, 17만 4762분, 2913 시간이며, 날짜로는 121일이 걸린다. 


이럴 바에야 그냥 디스크 5개를 택배로 보내는것이 네달 내내 데이터를 전송 하는 것 보다 훨씬 낫다는 말이다. 물론, 현지에 받아 줄 인프라 및 운용 인력이 있어야 말이 되겠지만. 


이런 부분에 조금이나마 걱정을 줄여 보고자, 제목과 같은 도구를 사용 하는 방법에 대해 소개 하고자 한다. 그럼 이 도구를 사용하면 얼마나 속도가 나오길래 그러냐 물을지도 모르겠다. 기본적으로 Tsunami UDP 는 전송 제어를 위한 TCP 연결과 실제 데이터 전송을 위한 UDP 포트를 각각 하나씩 사용한다. 일단은 TCP 처럼 혼잡 회피라던가 느리게 시작하는 알고리즘 및 기타 등등 복잡한거 생각 안하고 그냥 마구 쏘고 본다. 



Image from: http://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols



그래서 받는 측에서 정상적으로 받으면 좋은거고 못받으면 그냥 다시 보내면 된다. 이 단순한 구조로 인해 TCP 와 같이 회선 대역폭을 충분히 사용하지 못하는 경우에라도 높은 전송 속도를 사용하는 것이 가능하다. 단순 UDP 만을 사용하게 되면 분명 유실이 발생 할 수 있곘지만, Tsunami UDP 에서는 이런 누락된 부분을 다시 전송 할 수 있는 loseless 모드를 지원 한다. 따라서 전송 전과 전송 후 md5sum 과 같은 도구로 확인 해 보아도 동일한 파일이 무사히 전송 되는 것을 확인이 가능. 


설치 방법은 대략 아래의 스크립트를 사용하면 되겠다. 만약 AWS의 EC2 를 사용하는 경우라면 User data 부분을 이용해서 바로 인스턴스를 준비 하는 것도 가능. 아래의 스크립트는 N.Virginia 에서 cc2.8xlarge 인스턴스를 사용하는 경우 ephemeral disk 4개를 모두 사용하여 raid 0 로 묶고, 여기에 BtrFS 를 사용하도록 구성한다. 파일 시스템은 원하는 것을 사용해도 되며, 기타 실제 다른 데이터 센터로 전송하려는 경우에는 원하는 부분만 발췌해서 사용해도 무방. 



#!/bin/bash 

yum -y update 
mkdir  -p /root/tmp 
cd /root/tmp/ 

yum  -y install gcc c++ cc make automake  
wget http://downloads.sourceforge.net/project/tsunami-udp/tsunami-udp/tsunami-v1.1-cvsbuild42/tsunami-v1.1-cvsbuild42.tar.gz


tar xvzf tsunami-v1.1-cvsbuild42.tar.gz  
 
cd /root/tmp/tsunami-udp-v11-b42  
./recompile.sh 
make install

yum -y install btrfs-progs.x86_64 
mkdir -p /mnt/md0 
umount `mount | egrep ephemeral  | awk '{print $1}' `

disklist=`fdisk -l  | egrep '(GB)' | egrep -v xvda | awk '{print $2}' | cut -d":" -f 1 | sed ':a;N;$!ba;s/\n/ /g' `

echo y | mdadm --create /dev/md0 --chunk=1024 --level=0 --raid-devices=4 $disklist
mkfs.btrfs /dev/md0 

mount -t btrfs /dev/md0 /mnt/md0

exit 0



별로 심각한 수준에서 튜닝된 설정은 아니므로 적절한 값은 직접 확인을. 

전송을 위해서는 서버와 클라이언트가 필요한데, 클라이언트에서는 PUT 은 불가능하고 GET 만 가능 한 것으로 보인다. 


서버는 전송하고자 하는 파일이 위치한 디렉토리에서 아래와 같은 커맨드로 실행한다. 


tsunamid --hbtimeout=360 --verbose 



클라이언트는 tsunami 라는 도구를 사용하며, 서버로 부터 명시된 전체 파일을 가져오거나 특정 파일만을 전송 받는것이 가능하다. 


tsunami connect [HOSTNAME] get [FILENAME]



설정 가능한 내용들은 통상 다음과 같다. 


tsunamid: unrecognized option '--help'

Usage: tsunamid [--verbose] [--transcript] [--v6] [--port=n] [--buffer=bytes]

                [--hbtimeout=seconds] [filename1 filename2 ...]


verbose or v : turns on verbose output mode

transcript   : turns on transcript mode for statistics recording

v6           : operates using IPv6 instead of (not in addition to!) IPv4

port         : specifies which TCP port on which to listen to incoming connections

secret       : specifies the shared secret for the client and server

buffer       : specifies the desired size for UDP socket send buffer (in bytes)

hbtimeout    : specifies the timeout in seconds for disconnect after client heartbeat lost

filenames    : list of files to share for downloaded via a client 'GET *'


Defaults: verbose    = 1

          transcript = 0

          v6         = 0

          port       = 46224

          buffer     = 20000000 bytes

          hbtimeout  = 15 seconds



직접 사용을 해 보면, 다음과 같은 부분이 전송에 영향을 미친다. 


* 너무 짧은 heart beat timeout 은 전체 전송을 끊어버리는 현상을 발생 시킬 수 있다. 

* 클라이언트(수신측)의 Disk write 성능이 떨어지면 buffer 에 담긴 파일을 디스크에 쓰는 동안 UDP packet drop 이 발생할 수 있다. 



EC2 에서 region to region 복사의 경우, 1Gigabyte 정도는 10초 내에 전송 완료되는 것을 확인 할 수 있었다. 

다만 실제 데이터센터에서 본 도구를 사용하는 경우에는 발송하는 쪽의 대역폭이 성능에 영향을 미칠 수 있으므로, 실제 서비스로의 도입은 반드시 테스트 해 보고 결정 할 것. 성능은 그때 그때 달라효. 


물론, 보다 더 좋은 성능을 위한 커널 파라메터 튠이 존재하므로 다양한 방법으로 개선을 시도 해 봐도 좋을 듯. 


잠깐 검색을 해 보니 TCP 와 UDP 에 대한 괜찮은 정리가 있어 링크를 공유. 

http://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols


예전에는 이런거 공부하려면 Steven 책 밖에 없었던 것 같은데, 참 세상 좋다. 


본 도구를 이용한 보다 발전된 도구는 향후 준비 되면 다시 포스팅을. 

아 간만에 기술 포스팅 한다 정말. :) 


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





Lean startup

Techs


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


Lean startup






A sample video of a startup. 




Presentation with Prezi 





Animoto video 


Make your own slide show at Animoto.



Business PowToon 





Crowd funding 




Examples of crowd funding. 






















사업 자금 만든다고 은행 들락 거리는건 이제 옛말인듯. 


http://www.kickstarter.com/


http://www.instructables.com/id/Arduino-Projects/


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