[기고/시트릭스 조동규 부장] 클라우드 자체가 목적지는 아니다

Cloud 2012. 1. 23. 21:09

작년 한해를 가장 뜨겁게 달군 IT 키워드는 과연 무엇이었을까요?

그 정답은 아마도 ‘클라우드’가 아닐까 생각됩니다. 가상화와 클라우드, 정말 한해 동안 폭풍적인 성장과 이를 둘러싼 이슈들로 가득했던 한 해가 아니었나 싶습니다.

 

오늘 이 시간에는 과연 클라우드가 현재까지 올바른 방향으로 흘러가고 있는지 또한 클라우드가 제공하는 진정한 가치는 무엇인가에 대해 생각해 보는 시간을 갖도록 하겠습니다.

 

이를 위해 시트릭스시스템스코리아 클라우드 및 젠서버 부문 조동규 부장의 기고문을 여러분들과 함께 공유하고자 합니다.

 

[기고] 클라우드 자체가 목적지는 아니다

시트릭스시스템스코리아 조동규 부장

 

대학때 많은 수업을 들었지만 정말 손에 꼽을 정도로 남는 이야기가 몇 가지 있습니다. 그 중 하나가 교통개론을 배우면서 교수님이 목청을 높여서 이야기 하신 내용이 "누구도 도로를 목적으로 하지 않는다 도로는 어디로 가기 위한 수단이고 얼마나 빨리 잘 갈수 있느냐가 중요한 잣대이지 도로 자체가 목적인 사람은 아무도 없다" 라는 내용을 배웠습니다. 즉 사용자가 목적지에 다다를 수 있도록 도와주는 도구라는 것입니다. 생각해보면 도로공사나 도로 자체에 관심이 많지 누구도 도로에 관심이 많지는 않습니다. 도로로 인한 기대 효과를 생각하지 도로 자체가 목적인 사람은 없기 때문입니다.

 

현재 돌아가는 클라우드를 보면 마치 클라우드 자체가 무슨 큰 대단한 비지니스 성공의 잣대인 것처럼 큰 목소리를 높이고 있는 실정이 마치 목적을 상실한 채 도로를 방황하는 것과 비슷한 상황이 아닌가 생각해 봅니다. 

 

그렇다면 클라우드를 제대로 구축하고 활용하려면 어떤 점들이 고려 되어야 할까요?

 

1. 클라우드 인프라 구축을 위한 분명한 목표가 있어야 한다

마치 도로를 만들기 위해서는 도로가 필요한 이유와 향후 주변 도시간의 인구성장, 인구이동, 도시 소득 등 뒷받침이 되야 도로 계획, 설계 그리고 구축에 들어갑니다. 클라우드 역시도 비지니스에 부합하는 그리고 향후 회사의 비지니스를 가능하게 하는 도구로서 분명한 목표와 방향이 있어야 합니다. 그냥 현재의 이슈를 풀어볼까? 또는 비용이 절약 된다는데…등등의 지엽적이고 작은 부분들로 클라우드를 생각하면 오히려 빈대잡으려고 초가산간 다 태우는 상황이 발생하게 됩니다. 분명히 왜 클라우드 아니면 안 되는가에 대한 명확한 이유와 비지니스 목표가 있어야 합니다.

 

2. ROI에 대한 명확하되 유연한 규정이 필요하다

가상화 까지는 대부분 ROI가 분명합니다. 상면을 줄이고 노후서버를 재활용하고 전력을 줄이는 등의 비교적 명확한 ROI가 나오면서 가상화를 일부 또는 전면 도입하고 운영하는 수준까지는 그리 어렵지 않은 거 같습니다. 다만 클라우드로 넘어가게 되면 빌링, 미터링, 자원관리, 자동화, 빠른 서비스 지원 등등 가상화 보다 진전된 수준의 서비스 등은 모두 업무 프로세스나 비지니스를 좀더 명확하게 하는 부분이라 일반적인 ROI의 잣대를 대기보다는 실제로 얻어지는 개선에 대한 내부 동의가 필요하고 특별히 왜 클라우드 여야 하는 부분이 결정권자와 실무자간의 강한 동의가 있어야 성공할 수 있습니다.

 

3. 걸음마 부터 차근차근

여러 고객 분들을 만나면서 가장 아쉬운 것 중에 하나가 시간의 개념이 상대적으로 약하다는 것입니다. 클라우드는 마케팅적으로도 훌륭한 도구임에는 분명하지만 기술적으로는 그리 쉽지만은 않으면 실제로 구현해서 비지니스와 결합된 형태의 서비스로 정착되기 까지는 상당히 오랜 시간이 걸리게 됩니다. 물론 가상화를 대규모로 운영해본 경험이 있다면 이러한 시행착오 시간들을 줄여줄 수는 있겠지만 가상화+클라우드를 동시에 진행한다는 것은 실로 어려운 것이 현실입니다. 즉 걸음마를 제대로 하기 전에 뛰는 것과 마찬가지로 매우 위험하고 실패할 가능성이 농후 합니다. 따라서 급하더라도 가상화에 대한 충분한 노하우와 안정화 시간이 필요하며 가상화 프로젝트와 클라우드 프로젝트를 같이 하기 보다는 별로도 검토해서 진행하는 것이 좋다고 생각합니다.

 

4. 시간의 중요성을 생각해야 한다

최근 들어 오픈소스소프트웨어(OSS : Open Source Software)에 대한 인기가 급등하면서 여러 개발자 커뮤니티들이 활 황기에 있습니다. 기업들도 비싼 상용보다는 내부적으로 오픈소스를 지원하고 활용하는 형태로 발전을 해나가고 있습니다. 주의 해야 할 것은 향후 관련 분야의 기술습득이나 개발에 대한 명분은 있지만 자칫 기술소유에만 몰두 하다 보면 실제로 비지니스에서 필요한 기능이나 요구사항을 제때 반영하지 못하는 경우도 생길 수 있습니다. 클라우드 분야는 아직 관련 개발자나 전문가가 부족하기 때문에 실제로 광범위한 프로젝트를 하다 보면 상당한 인력난에 부딪치게 됩니다. 비지니스는 시간의 개념이 매우 중요합니다. 언제 제품과 서비스를 출시하느냐 얼마의 인원이 어느 시간 동안 투입을 하느냐 개발 또는 외부 지원을 받을 때 그 비용의 함수관계를 잘 따져야 하며 단순히 오픈소스가 도입비용이 저렴하거나 개발 또는 일부 개발을 기술을 내재화 하겠다는 것이 너무 우선시되어 적시에 시장에 진출하지 못함에 따라 아예 비지니스 기회를 잃어 버릴 수도 있습니다. 내부 인력과 또는 외부 인력 그리고 이에 따른 개발 시간의 관계를 잘 검토 해야 합니다.

 

5. 선택과 집중이 필요하다

위의 내용과도 비슷하지만 클라우드는 단순한 한두 가지의 기술이 아닌 여러 기술들의 복합체이며 이러한 기술들이 단순히 IT만 연계된 것이 아니라 회사 내부의 프로세스와도 연동이 되어 있습니다. 클라우드 인프라를 구성하는 솔루션들이 요즘 계속 발전하고 쉽게 되어 있어서 간단하게 구성하는 것은 그리 어렵지 않습니다. 마치 클라우드가 고속도로라면 고속도로를 쭈욱 구축하는 것은 문제가 아니나 정작 고속도로에 접근하기 위한 톨게이트, 요금정산, 주변도로, 신호체계, 구호체계 등등도 역시도 같이 구비가 되어야 합니다. 이 역시도 상당한 시간과 비용이 들어가는 작업이며 오히려 주변 부속도로나 장치들은 외부 벤더가 개발하는데 한계가 있고 내부 프로세스를 모르기 때문에 대부분이 고객사에서 준비하고 개발합니다. 그러다 보니 정작 주객이 전도되어 클라우드 솔루션을 설치는 했는데 더 이상 진보가 안 되는 경우도 상당히 많습니다. 기술의 문제가 아니라 실제로 회사 프로세스와 연동돼서 운영을 하려다 보니 발생되는 문제 입니다. 시간과 비용과 인력의 선택과 집중이 어느 프로젝트 보다 중요한 상황입니다.

 

도입에 말씀 드린 것처럼 클라우드는 마치 도로와 같습니다. 도로를 만드는 것도 중요하지만 실제로 도로가 제대로 된 구실을 하려면 도로의 목적이 분명해야 하며 차근차근 그러나 느리지 않게 하되 선택과 집중을 통해서 목표한 바를 이루어야 합니다. 실제로 지방에 수천억을 쓰고도 제대로 사용 못하는 공항들을 보면 구축이 목적이 아니라 비즈니스 니즈에 정확히 부합해야 하며 제대로 쓰기 위한부속시설이나 내부 프로세스와 연동하기 위한 개발 부분도 간과해서는 안 되는 부분입니다. 

 

클라우드는 기존의 IT문제를 해결하고 더 나아가 기업의 비지니스를 가능하게 하는 역할을 수행합니다. 최근 들어 여러 기업들이 클라우드 구축에 몰두할 정도로 인기이지만 자칫 기업의 실패를 가져올 정도로 그 책임도 막중해 지면서 좀더 신중하자는 의견들도 나오고 있습니다. 그렇기에 좀더 비지니스 중심적이면서도 왜 클라우드를 해야 하는지를 명확히 해야 성공적인 클라우드가 되지 않을까 합니다.


http://m.blog.naver.com/citrixblog/90133552072
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

정말 AWS가 클라우드의 표준(Standard)은 아니잖아~  (0) 2012.02.07
Cloud.... 'Beta'는 없다.  (0) 2012.02.04
[Virtualization] PDF 서버 가상화 비용, 트렌드 등에 관한 전문가 개요 (Link)  (0) 2011.11.28
데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
Posted by 사랑줍는거지
,

데스크톱 가상화 : VDI로 도약하기

Cloud 2011. 11. 14. 10:34

데스크톱 가상화 : VDI로 도약하기

2010.10.12
Paul Venezia | InfoWorld

우아하며 쉽게 관리할 수 있는 데스크톱 인프라에 대한 유토피아적인 비전은 데스크톱 시대의 개막과 함께 IT 주위를 맴돌아 왔다. 히드라와 같은 데스크톱을 길들이기 위한 시도는 많았으나, 어느 것도 보편적인 솔루션은 제공하지 못해왔다. 마이크로소프트 터미널 서비스(Terminal Service), 시트릭스 젠앱(XenApp)을 비롯한 수많은 기업들이 나름대로의 시장은 확보했으나, 데스크톱 구원에 대한 탐구는 계속되고 있다.

 

가장 최근의 유망주  : VDI

단순하게 말하면, VDI(Virtual Desktop Infrastructure)는 하이퍼바이저 상에서 구동하는 사용자당 한 개의 데스크톱 가상머신에 지나지 않는다. 서버 가상화와 마찬가지로, 각 데스크톱 가상머신에는 RAM, 디스크, 그리고 입출력 자원이 할당되고, 운영체제 전체 설치본은 가상 디스크에 저장된다.

 

사용자는 마이크로소프트의 RDP(Remote Desktop Protocol)나 시트릭스의 ICA(Independent Computing Architecture) 같은 원격 디스플레이 프로토콜을 사용해서 데스크톱 가상머신과 상호작용한다. 클라이언트는 대개 디스크가 없는 저성능 씬 클라이언트 시스템으로, VDI 인프라에 연결하는 것 외에는 하는 것이 거의 없거나 어떤 작업도 하지 않는다.

 

VDI를 비롯한 다른 서버 기반 데스크톱 컴퓨팅 솔루션의 결과, 핵심 기능성, 그리고 모든 소중한 기업 데이터가 수 많은 칸막이 사무실이나 몇 Km나 떨어져 있는 원격지 사이트에 멀리 그리고 폭넓게 퍼져있는 것이 아니라 데이터센터 내부에 들어가게 되었다.

 

데스크톱을 중앙 집중화시킴으로써, 관리와 보안이 간단해졌고 결함 있는 전원 공급장치, 하드 드라이브 등의 교체 같은 기본적인 데스크톱 유지보수 필요성이 없어졌다. 전력 소비도 감소되었고, 어떤 경우에는 모든 팻(Fat) 클라이언트 시스템과 250와트의 전원 공급장치를 제거한 덕분에 밀집된 사무실 공간의 냉각 비용이 급격하게 줄었다. 긍정적인 면이 상당하다.

 

VDI 세부사항에 숨어있는 골칫거리들

하지만, VDI에도 확실히 단점이 있다. 이런 문제 중 몇 가지는 다른 서버 기반 데스크톱 컴퓨팅 솔루션에서 찾아볼 수 있으며 VDI 구현에도 영향을 준다.

 

그 중에서도 가장 중요한 문제부터 살펴보기로 하자.

 

사용자의 수용도와 전반적인 성능. 각각의 VDI 인스턴스(Instance)는 문서 작성, 이메일 작성, 또는 스프레드시트 공식 실행 같은 상대적으로 평범한 작업을 수행할 때는 빠르고 뭐든지 척척 해내지만, 플래시 애플리케이션, 비디오, 또는 다른 멀티미디어 애플리케이션 같은 리치 콘텐츠와 맞닥뜨리면 상당히 영향을 받을 수 있다. 이는 대체로 VM의 성능보다는 데스크톱 디스플레이 전송 프로토콜 때문이지만, 바로 그 점 때문에 문제 해결이 더 어려워졌다. 사용자 수용도는 아주 공개적인 문제가 생길 수 있으며, 이 문제가 발생하면 어떤 대형 프로젝트라도 종말을 고하는 경우가 많다.

 

이 문제에 대한 솔루션은 비용이 많이 들 수 있다. 몇몇 공급업체는 서버와 클라이언트 측의 노력을 결합해서 디스플레이 프로토콜과 함께 오디오와 비디오 스트림을 전송하여, 클라이언트 단에서 일치시키고 클라이언트의 처리 능력을 사용해서 비디오를 렌더링(Rendering)한다. 그 결과 훨씬 더 깔끔한 재생을 할 수 있으나, 늘어난 작업부하를 처리하기 위해서 더 강력하고 비싼 씬 클라이언트가 필요하다.

 

그런 솔루션은 표준 비디오 재생에 대해서는 잘 동작하지만, 플래시 비디오나 플래시 애플리케이션과는 문제가 남아있다. VDI나 표준 RDP 프로토콜을 사용하고 있는 다른 서버 기반 데스크톱 컴퓨팅 솔루션의 성능을 테스트하기는 쉽다. 그저 마이크로소프트 RDC(Remote Desktop Connection: 원격 데스크톱 연결) 클라이언트를 사용해서 서버나 데스크톱 시스템 연결한 다음에, 유튜브를 보기만 하면 된다.

 

100Mbps 이상의 LAN을 사용하고 있다면 재생이 상당히 잘 되겠지만, 그 이하에서는 한마디로 그럴 가능성이 없다. 일반적으로 말해서, RDP 접속을 경유해서 비디오를 보기 위해서는 3.5Mbps의 지속적인 대역폭이 필요하다.

 

대역폭에 대한 우려는 WAN 회선(높은 지연편차 및 낮은 대역폭이라는 고전적인 시나리오)을 통한 데스크톱 세션 제공 같은 어떤 형태의 서버 기반 데스크톱 컴퓨팅에 대해서도 문제를 일으킬 것이다. USB 기기에 대한 인쇄와 적절한 매핑(Mapping)도 문제가 많다. 이런 문제는 도구와 예산을 제대로 조합하기만 하면 정리할 수 있고, VID 고유의 문제도 아니지만 VDI 계획 단계에서는 고민할 필요가 있다.

 

VDI 고유의 문제 : 스토리지

다른 문제들은 전적으로 VDI 고유의 문제이다. 가장 중요한 첫 번째 문제는 스토리지 요구조건이다. 몇몇 VDI 실행 환경은 다른 VM과 마찬가지로 모든 데스크톱 시스템이 반드시 가상 디스크를 가질 것을 필요로 하고 있다. 데스크톱 가상머신당 8GB나 10GB를 고려하고 있다면, 이를 예상 VDI 사용자 수로 곱하면, 곧 바로 스토리지가 고가의 문제가 돼버린다.

 

또한, 각각의 가상머신은 다른 데스크톱 시스템처럼 개별적으로 관리되어야만 하는 섬이므로, VDI는 데스크톱 소프트웨어 관리 요구조건을 줄여주기 위해서 거의 하는 일이 없다는 사실도 명심하기 바란다. 이는 업데이트를 배포하고, 소프트웨어를 설치하거나, 변경을 하기 위해서는 서드파티 툴을 사용해야 함을 의미한다.

 

그리고 그 다음에는 가격도 문제다. 한편으로는, VDI가 기존 가상화 인프라를 활용하므로, 다른 서버 기반 데스크톱 솔루션보다 초기 하드웨어 비용을 더 낮춰줄 가능성도 있어 보인다. 하지만, 일단 VDI에 필수적인 여러 단계의 소프트웨어 라이선싱 계층을 하나하나 벗겨나가다 보면, 결국에는 마찬가지라는 사실을 알게 될 것이다.

 

선택한 솔루션에 따라서, ROI는 이미 저 멀리 가버린 상태에서 기존의 팻 데스크톱 클라이언트 시스템 보다 더 많은 비용을 데스크톱 VM별로 지불하게 되고 말 수도 있다. 어떤 형태의 VDI이건, 뛰어들기 전에 이 모든 숫자들을 계산해 보는 것이 극히 중요하다. 씬 클라이언트 비용, 구현 비용, 라이센싱, 그리고 기존 가상 인프라의 확장 비용들을 감안하라.

 

VDI 대 터미널 서비스

VDI와 기존의 마이크로소프트 터미널 서비스 간에는 명확한 평행선을 그을 수 있다. 이 두 가지는 다수의 데스크톱 세션을 한 대의 서버나 서버 세트 상에 둘 수 있으며 세션을 동일한 씬 클라이언트에게 전달하기 위해서 같은 프로토콜을 사용한다. 두 가지 모두 중앙집중형 관리 도구를 제공한다. 하지만, 유사성은 거기까지다.

 

터미널 서비스 환경에서는 서버에 대한 모든 사용자 세션을 서버 운영체제에 둔다. 이는 윈도우 서버 2003이나 윈도우 서버 2008에 대한 한 개의 인스턴스만이 베어 메탈(Bare-metal) 서버에 설치되고, 모든 사용자가 해당 서버 인스턴스에 로그인 한다. 개개 사용자 세션은 자체 데스크톱이 있는 것처럼 표시되지만, 해당 특정 서버 상에서 다른 모든 세션들과 함께 구동한다.

 

이 시나리오의 이점은 확장성에 있다. 일반적으로 말해서, 물론 애플리케이션 세트에 따라서 다르기는 하겠지만 아마도 한 대의 물리적인 서버에 VDI 세션보다 더 많은 수의 터미널 서버 세션을 밀어 넣을 수 있을 것이다. 한편, VDI 환경에서는 간단하게 데스크톱 가상머신의 자원을 정의하기만 하면, 어떤 사용자 세션의 자원에 대해서도 신속하고 확실한 제한을 둘 수 있다.

 

VDI 실행 환경에서는 서버가 전체 운영체제가 아니라 하이퍼바이저를 구동하고 있으며, 몇 개의 데스크톱 가상머신을 호스팅하고 있다. 그 결과, 각 방법이 여러 개의 데스크톱 세션을 동일한 서버에 두기는 하지만, 그런 세션들의 관리성은 크게 다르다.

 

예를 들어, 터미널 서비스에서는 가상머신을 스냅샷(Snapshot)하듯이 세션을 스냅샷할 수 있는 방법이 없으며, 활성 세션을 한 서버에서 다른 서버로 이전시킬 수 있는 방법도 전혀 없다. 이는 유지보수를 위해서 해당 서버를 다운시키기 위해서는, 모든 사용자가 반드시 로그오프 해야만 함을 의미한다.

 

관리성에서 확연한 차이 보이는 VDI

VDI에서는 해당 서버 성의 모든 활성 데스크톱 세션을 서버 팜의 다른 서버로 중단 없이 이전시킬 수 있다. 통상 이 모든 VM을 호스팅 하는 서버는 누구도 알아차리지 못하게 유지보수를 위해 다운시킬 수 있다.

 

실제로, 어떤 고급 가상화 인프라에 대해서도, 단 한 개의 애플리케이션을 오프라인으로 만들거나 단 한 명의 사용자도 방해하지 않은 채, 전체 물리 서버 기반 구조를 완전히 재구축할 수도 있다.

 

더 나가서, 제대로 구현된 VDI 솔루션에서는 부하 분산도 기본적으로 제공된다. 한 개 이상의 데스크톱 VM이 한 호스트 시스템 상의 자원을 많이 사용하고 있다면, 그 시스템의 다른 VM들을 순식간에 다른 물리 호스트로 이전해서, 모든 데스크톱이 돌아가기 위해서 충분한 자원을 확실하게 가질 수 있게 할 수 있다. 기존 터미널 서버 환경에서는 이것이 불가능하다. 한 개의 대형 사용자 세션이 어떤 자동 해결 방안도 없이 동일 서버 상의 다른 세션에 부정적인 영향을 줄 수 있다.

 

하지만, 터미널 서비스도 한 가지 커다란 관리 상의 장점이 있다. 호스트 서버에 대한 변경 사항을 모든 사용자 세션에서 사용할 수 있다. 애플리케이션 설치가 상당히 간단해지고 글로벌한 수정 작업도 상대적으로 쉽다.

 

VDI에서는 항상 그렇지는 못하다. 데스크톱 가상머신의 배포 방식에 따라, 업데이트나 변경을 위해서 각각을 일일이 수작업으로 해야만 하거나, 서드파티 관리 도구를 사용하거나,  또는 데스크톱 가상머신 템플릿을 작동시켜서 수정 작업을 한 다음에, 템플릿을 저장해야 할 필요가 있을 수 있다. 마스터 템플릿에 연결된 데스크톱 가상머신은 사용자가 다음에 로그인할 때 변경 사항이 반영된다.

 

그렇기는 하지만, 터미널 서비스에 비해 VID의 애플리케이션 처리는 커다란 장점 중 한가지로 작용한다. 많은 애플리케이션이 터미널 서비스 환경에서는 동작을 무조건 거부한다. 다른 애플리케이션은 제한된 기능만을 제공하거나 터미널 서버 환경에서는 해당 애플리케이션 공급업체의 지원을 받지 못할 수도 있다. 이는 어떤 터미널 서버 기반의 인프라에서도 실질적인 문제로 대두되고 있지만, VDI에서는 문제가 아니다.

 

VDI는 사용자 별로 한 개의 전용 데스크톱 인스턴스를 구현해서, 운영체제 수준에서 실제 데스크톱과 분간할 수 없다. 팻 클라이언트 상에서 구동되는 어떤 애플리케이션도 VDI VM 상에서 구동된다 (비디오나 그래픽 성능에 대해서는 약간의 예외를 두고). 바로 이것이 일부 조직이 터미널 서버 대신에 VDI를 밀고 있는 중요한 이유이다.

원문 : http://itworld.co.kr/news/62797/%EB%8D%B0%EC%8A%A4%ED%81%AC%ED%86%B1+%EA%B0%80%EC%83%81%ED%99%94+:+VDI%EB%A1%9C+%EB%8F%84%EC%95%BD%ED%95%98%EA%B8%B0 

저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

[기고/시트릭스 조동규 부장] 클라우드 자체가 목적지는 아니다  (0) 2012.01.23
[Virtualization] PDF 서버 가상화 비용, 트렌드 등에 관한 전문가 개요 (Link)  (0) 2011.11.28
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
클라우드프론티어2011..............  (0) 2011.10.26
(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......  (1) 2011.04.04
Posted by 사랑줍는거지
,

클라우드프론티어2011..............

Cloud 2011. 10. 26. 14:03
얼마전 클라우드 프론티어에 OpenStack CEO 앤드류~어쩌구~저쩌구가 OpenStack발표하는 말미에 이런 이야기를 하더군요...

"사람들이 종종 묻기를...“OpenStack은 클라우드 코어로서 사용될 준비가 되어 있는지요?”라고 묻는다... 그런데, 이 질문은 조금 잘못된 것 같다. 나는 이렇게 되 묻고 싶다. “그게 OpenStack이든 뭐든,... 그것들을 사용할 '준비'가 되어 있는가??” 여기서 제가 말하는 '준비'는 전문성이나 기술력이 되겠죠... OpenStack은 현재 여러모로 부족합니다. 그러나, 가능성은 대단합니다. Linux가 처음에 그러했 듯이 OpenStack도 그러할 것입니다."

Cloud한다는 분들은 곱씹어 볼 내용이지요.... '준비'가 되어있는지.... 아무튼 그날 들은 내용중 젤 인상 깊게 남는듯......
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......  (1) 2011.04.04
CloudStack 2.2.2 Release -> 2.2.3  (0) 2011.03.17
[웹OS] 10년전 Web OS로 본 한국의 Cloud  (0) 2011.03.10
Posted by 사랑줍는거지
,

Chef Server/Client (on FrameOS6)

Cloud/Automation 2011. 5. 12. 10:48

한동안 회사일로 Chef Server/Client (CentOS기반) 구축문서 마무리를 못했었는데, 일신상의 이유로 여유가 생겨 다시 이어서 작성하고자 OPScode의 Installation Wiki문서를 찾았다. 그런데... 또 바뀌었다..ㅡㅡ;; 
이전의 번거롭던 설치 과정이 다 필요 없어졌다. CentOS든 FrameOS든 VM어플라이언스 형태로 제공되기 시작한듯 하다. 여기에 FrameOS의 경우, RPM(yum)를 통해서도 설치를 지원한다. 희소식이긴 하나, 이전의 나의 삽질은 정말 삽질이 되버렸다. 물론 도움은 많이 되었고, Chef운용에도 여전히 참조될 정보들이긴 하나, 좀 허무하다~ ㅎㅎ;;

자세한 정보는 아래 링크주소와 스크랩 내용을 참조....
http://wiki.opscode.com/display/chef/Installation+on+RHEL+and+CentOS+5+with+RPMs

RPM Package Support Deprecated

RPM installation via ELFF has been deprecated, as the RPM based approach has proved difficult to maintain with the fast moving nature of the rubygems ecosystem. Please refer to Install Chef Server From Rubygems, or Install Chef Client with Rubygems for an Opscode supported approach.

Community RPM Package Support

Community members are actively working on third-party repositories for Chef on Redhat based distributions - some of which Opscode has used successfully with some customers.

These are not officially supported by Opscode for Opscode Platform customers, and we have not committed time to testing and ensuring the functionality of these packages with Chef. They may still be options community users want to consider, turning to the Open Source Community Help Resources for support.

Alternate RPM Repositories

Alternatives that leverage RVM

Pre-built, RPM based Virtual Appliances

Futures

The future solution to this problem will be full-stack installers delivered both as stand-alone installable binaries and native packages, but with the entire dependency chain included. That this is the right solution is starting to be pretty widely embraced - you can see the evidence in several past package maintainers for chef moving to a model exactly like this.

Opscode has an full-stack or 'fatty' installer in development. Further information and detail regarding the 'fatty' installer will be forthcoming as it progresses through product planning.

 








저작자표시 비영리 변경금지

'Cloud > Automation' 카테고리의 다른 글

Puppet Configuration Management Tool  (0) 2012.02.23
[시스템 자동화] Install Chef Server/Client on CentOS 5.4 x86_64 ...(폐기)  (1) 2011.04.23
Install Chef-Solo on CentOS 5.4 x86_64  (1) 2011.03.27
[Chef]에 관해 간결하고, 재미있게 잘 작성된 PT자료 (추천문서)  (0) 2011.03.25
in Cloud, Infrastructure Automation with Chef (클라우드/자동화)  (0) 2011.03.25
Posted by 사랑줍는거지
,

(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......

Cloud 2011. 4. 4. 16:19
AWS가 정말 수익을 내고는(공급자 입장에서...) 있을까...... 아직까지 이에 대해 공개된 정보는 없는것 같다... 분명 기대이상.. 아니 그정도까지도 아닌, 긍정적으로 봐줄만큼의 수익이 나오고 있다면, 분명 자료나 기사가 나돌만도 한데... 그런 내용은 접하기 어려운걸로 봐서, 수익면에서는 적자를 보고 있거나, 고전을 면치 못하는건 아닐까 싶은 생각도 든다... 문득 든 생각이, 개념도 좋고, 이상도 좋지만, 결정적으로 사업성이나 수익성이 없다면, 큰문제 아닌가? 나는 재무나 이런분야엔 잼병이라 봐도 모를테지만... 그래도 아주 쬐~~끔은 걱정은 된다. 물론 그럴리는 없을테지만.........

- 신뢰성??
 
- 다양성???
- 플랫폼
- 프로그램
- 어플리케이션

- 자동화???
- 배포
- 설정
- 확장/축소
- 자가 복구

- 지원???
- 안정적인 운영
- 지속적인 업데이트/개선
- 서비스 개발/추가

- 경제성???
- 사용자 측면(저가)
- 공급자 측면(고효율)


* AWS의 EC2 가격 계산 (환율가정 : 1,000원/1달러)
- EC2 VM 한달 요금(Extra Large급 가정)
- 0.88(달러) * 24(시간) * 30(일) * 1,000(원) = 633,600원
- 한달 요금 샘플
- 트래픽 규모
- 1일 유입량 : 200GB -> 한달 : 6TB
- 0.1(달러) * 200(GB) * 1,000(원) * 30 = 600,000원
- 1일 유출량 : 500GB -> 한달 : 15TB
- 10TB까지 : 10,000(GB) * 0.17(달러) * 1,000원 = 1,700,000원
- 다음 5TB :  5,000(GB) * 0.13(달러) * 1,000원 = 650,000원
=> 총금액
633,600원 + 600,000원 + 1,700,000원 + 650,000원 = 3,583,600원

=> 동일 서비스를 처리할 수 있다는 가정하에서, 과연 저정도 금액이면 비용절감이 되는지... 된다면 얼마나 되는지.......궁금하다........
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
클라우드프론티어2011..............  (0) 2011.10.26
CloudStack 2.2.2 Release -> 2.2.3  (0) 2011.03.17
[웹OS] 10년전 Web OS로 본 한국의 Cloud  (0) 2011.03.10
Posted by 사랑줍는거지
,

[Chef]에 관해 간결하고, 재미있게 잘 작성된 PT자료 (추천문서)

Cloud/Automation 2011. 3. 25. 18:36

http://strangeloop2010.com/system/talks/presentations/000/014/483/Cashion-AutomateOrDie.pdf


* PDF 용량이 10메가 되고, 해외 서버라 그런지 로딩에 시간이 좀 걸립니다. 인내심을 가지세요~~

자동화의 의미부터 필요성, 종류, 그중에서 Chef에 대해서 이해하는데 많은 도움이 되는 문서입니다. 특히 저같은 초보한테는~

오늘 Chef-Solo 모드 테스트하고, Template 만들어 둔 상태이나, 히스토리는 한번더 확인 해보고 내일즘 기록해둘 예정.


(추가)
ruby와 rubygems 버전 맞추는게 좀 까다로움. 또 apache2배포시, NameVirtualhost 인자가 두개가 등록되는 바람에 service httpd start가 에러를 뱉어냄... 레시피 수정으로 해결...(레시피에는 80, 443 두개가 등록되어 있길래, 우선 443은 제거했음. 중요한것은 설치같은게 아니라 레시피를 얼마나 자유자재로 다룰수 있느냐 인것 같다...
어렵다...ㅡㅡ;;;
저작자표시 비영리 변경금지

'Cloud > Automation' 카테고리의 다른 글

Puppet Configuration Management Tool  (0) 2012.02.23
Chef Server/Client (on FrameOS6)  (0) 2011.05.12
[시스템 자동화] Install Chef Server/Client on CentOS 5.4 x86_64 ...(폐기)  (1) 2011.04.23
Install Chef-Solo on CentOS 5.4 x86_64  (1) 2011.03.27
in Cloud, Infrastructure Automation with Chef (클라우드/자동화)  (0) 2011.03.25
Posted by 사랑줍는거지
,

in Cloud, Infrastructure Automation with Chef (클라우드/자동화)

Cloud/Automation 2011. 3. 25. 14:31
  VM을 가지고 노는데(?) 있어 중요한 요소가 자동화다.(사람마다 다르겠지만...)
자동화와 관련된 Open Source 몇가지를 알아보던중, 괜찮아 보인게 Chef다. Puppet이라고 비슷한 기능을 가진것 같은데, 아직 자세히 보진 못했다. Chef에 어느정도 적응하고 나면 Puppet도 해볼 생각이다. 어차피 둘다 해보긴 해봐야 할것 같기에...

 Chef 관련 정보를 찾다가 아줄 정리가 잘되어 있는 PDF문서도 발견했다. 아래 첨부파일은 한번쯤 보시길...



Chef_Wiki_Export-09-25-2010.pdf



개략적인 운영방식은 아래와 같다.

  Chef는 기본적으로 Server/Client 구조다. (필요에 따라 Solo로 작동 시킬수도 있다.)
  Chef-Server에서 원하는 Package와 그에 적절한 Configuraton를 사전에 Recipe로 만들어 Cookbook에 등록해두고, Chef-Client에 적절한 수행을 가해주면, 원하는 패키지 설치/제거는 물론이고, 설정까지 자동으로 적용된다. Chef-Clinet는 동일한 기능을 가질수도 있고, 개별적인 기능들을 가지게하여, 하나의 '서버군'을 형성하게 할 수도 있다.(사실 난 아직 해보질 못했음...ㅡㅡ;;).

  또 Chef-Server 설정에 따라, 특정 Chef-Client가 관리자 실수나, 기타 장애로 설정값이 변경되거나, Chef로 관리되는 서비스에 문제가 발생됬다고 판단될 경우, Package와 Configuration을 자동 복원하고, 서비스를 다시 시작해준다. 매역적인 기능이다.

  서로 다른 여러 기능의 Chef-Clinet를 조합하여, 한의 부하 분산 서버군을 구성할 수도 있을 것 같다. 그것도 각각의 VM에 접속할 필요 없이. Chef-Server에서 몇번의 명령만으로... 관리 포인트도 하나로 집중시킬수도 있을 것 같고... 무식한 영어 실력으로 더듬더듬한 내용이지만, 대충 그런것 같다.

그리고, Chef에서는 Cookbook/Recipe가  굉장히 중요한 요소 같다. 아니 Chef의 전부인듯........
각자가 원하는 Recipe를 만들수도 있지만, 아마도 내가 만들고자 하는 Recipe와 90%이상은 유사한 Recipe가 이미 오픈되어 공유되고 있다. 실제로 Cookbook을 한번 다운로드 받아 봤더니 아래와 같이...........엄청..........ㅜㅡ;; 보시다 시피 어지간한 세트는 다 이미 마련되있다. 세부 설정은 해당 recipe의 Configuration을 아주 약간 변형함으로서 내가 원하는 형태로 배포/설정 할수 있다. (그리고 OPSCode라는 곳에서는 더 많은 레시피를 제공받을 수 있는 것 같다. 이부분은 좀더 확인해 봐야 함....)

Chef Cookbook에 포함되어 있는 Recipe (git clone git://github.com/opscode/cookbooks.git)

[root@localhost chef-repo]# ll

total 44

drwxr-xr-x   8 root root 4096 Mar 25 13:10 .

drwxr-xr-x   3 root root 4096 Mar 25 13:14 ..

drwxr-xr-x   2 root root 4096 Mar 25 13:10 certificates

drwxr-xr-x   2 root root 4096 Mar 25 13:10 config

drwxr-xr-x 129 root root 4096 Mar 25 13:11 cookbooks

drwxr-xr-x   2 root root 4096 Mar 25 13:10 data_bags

drwxr-xr-x   8 root root 4096 Mar 25 13:10 .git

-rw-r--r--   1 root root   18 Mar 25 13:10 .gitignore

-rw-r--r--   1 root root 2171 Mar 25 13:10 Rakefile

-rw-r--r--   1 root root 3521 Mar 25 13:10 README.md

drwxr-xr-x   2 root root 4096 Mar 25 13:10 roles

[root@localhost chef-repo]# 

[root@localhost chef-repo]# 

[root@localhost chef-repo]# ll cookbooks/

total 548

drwxr-xr-x 129 root root  4096 Mar 25 13:11 .

drwxr-xr-x   8 root root  4096 Mar 25 13:10 ..

drwxr-xr-x   5 root root  4096 Mar 25 13:11 activemq

drwxr-xr-x   3 root root  4096 Mar 25 13:11 ant

drwxr-xr-x   7 root root  4096 Mar 25 13:11 apache2

drwxr-xr-x   4 root root  4096 Mar 25 13:11 apparmor

drwxr-xr-x   5 root root  4096 Mar 25 13:11 application

drwxr-xr-x   6 root root  4096 Mar 25 13:11 apt

drwxr-xr-x   6 root root  4096 Mar 25 13:11 aws

drwxr-xr-x   6 root root  4096 Mar 25 13:11 bluepill

drwxr-xr-x   3 root root  4096 Mar 25 13:11 boost

drwxr-xr-x   3 root root  4096 Mar 25 13:11 build-essential

drwxr-xr-x   4 root root  4096 Mar 25 13:11 capistrano

drwxr-xr-x   5 root root  4096 Mar 25 13:11 chef

drwxr-xr-x   5 root root  4096 Mar 25 13:11 chef-client

drwxr-xr-x   7 root root  4096 Mar 25 13:11 cloudkick

-rw-r--r--   1 root root   408 Mar 25 13:11 CONTRIBUTING

drwxr-xr-x   6 root root  4096 Mar 25 13:11 couchdb

drwxr-xr-x   3 root root  4096 Mar 25 13:11 cron

drwxr-xr-x   7 root root  4096 Mar 25 13:11 daemontools

drwxr-xr-x   4 root root  4096 Mar 25 13:11 database

drwxr-xr-x   4 root root  4096 Mar 25 13:11 django

drwxr-xr-x   7 root root  4096 Mar 25 13:11 djbdns

drwxr-xr-x   6 root root  4096 Mar 25 13:11 dmg

drwxr-xr-x   3 root root  4096 Mar 25 13:11 drbd

drwxr-xr-x   6 root root  4096 Mar 25 13:11 dynect

drwxr-xr-x   5 root root  4096 Mar 25 13:11 dynomite

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ec2

drwxr-xr-x   3 root root  4096 Mar 25 13:11 emacs

drwxr-xr-x   4 root root  4096 Mar 25 13:11 erlang

drwxr-xr-x   4 root root  4096 Mar 25 13:11 fail2ban

drwxr-xr-x   6 root root  4096 Mar 25 13:11 gems

drwxr-xr-x   4 root root  4096 Mar 25 13:11 git

drwxr-xr-x   8 root root  4096 Mar 25 13:11 .git

-rw-r--r--   1 root root    38 Mar 25 13:11 .gitignore

drwxr-xr-x   5 root root  4096 Mar 25 13:11 glassfish

drwxr-xr-x   4 root root  4096 Mar 25 13:11 gnu_parallel

drwxr-xr-x   5 root root  4096 Mar 25 13:11 god

drwxr-xr-x   7 root root  4096 Mar 25 13:11 gunicorn

drwxr-xr-x   4 root root  4096 Mar 25 13:11 hadoop

drwxr-xr-x   5 root root  4096 Mar 25 13:11 haproxy

drwxr-xr-x   3 root root  4096 Mar 25 13:11 heartbeat

drwxr-xr-x   3 root root  4096 Mar 25 13:11 imagemagick

drwxr-xr-x   4 root root  4096 Mar 25 13:11 instiki

drwxr-xr-x   6 root root  4096 Mar 25 13:11 iptables

drwxr-xr-x   6 root root  4096 Mar 25 13:11 java

drwxr-xr-x   3 root root  4096 Mar 25 13:11 java_sun

drwxr-xr-x   5 root root  4096 Mar 25 13:11 jetty

drwxr-xr-x   6 root root  4096 Mar 25 13:11 jira

drwxr-xr-x   5 root root  4096 Mar 25 13:11 jpackage

drwxr-xr-x   4 root root  4096 Mar 25 13:11 keepalived

drwxr-xr-x   5 root root  4096 Mar 25 13:11 kickstart

-rw-r--r--   1 root root 10850 Mar 25 13:11 LICENSE

drwxr-xr-x   5 root root  4096 Mar 25 13:11 logrotate

drwxr-xr-x   3 root root  4096 Mar 25 13:11 logwatch

drwxr-xr-x   3 root root  4096 Mar 25 13:11 lvm

drwxr-xr-x   3 root root  4096 Mar 25 13:11 man

drwxr-xr-x   5 root root  4096 Mar 25 13:11 maradns

drwxr-xr-x   3 root root  4096 Mar 25 13:11 maven

drwxr-xr-x   6 root root  4096 Mar 25 13:11 memcached

drwxr-xr-x   3 root root  4096 Mar 25 13:11 mercurial

drwxr-xr-x   7 root root  4096 Mar 25 13:11 munin

drwxr-xr-x   8 root root  4096 Mar 25 13:11 mysql

drwxr-xr-x   8 root root  4096 Mar 25 13:11 nagios

drwxr-xr-x   3 root root  4096 Mar 25 13:11 nanite

drwxr-xr-x   7 root root  4096 Mar 25 13:11 nginx

-rw-r--r--   1 root root   999 Mar 25 13:11 NOTICE

drwxr-xr-x   3 root root  4096 Mar 25 13:11 nscd

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ntp

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ohai

drwxr-xr-x   5 root root  4096 Mar 25 13:11 one-shot

drwxr-xr-x   6 root root  4096 Mar 25 13:11 openldap

drwxr-xr-x   4 root root  4096 Mar 25 13:11 openssh

drwxr-xr-x   4 root root  4096 Mar 25 13:11 openssl

drwxr-xr-x   5 root root  4096 Mar 25 13:11 openvpn

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ossec

drwxr-xr-x   5 root root  4096 Mar 25 13:11 packages

drwxr-xr-x   5 root root  4096 Mar 25 13:11 pacman

drwxr-xr-x   5 root root  4096 Mar 25 13:11 passenger_apache2

drwxr-xr-x   5 root root  4096 Mar 25 13:11 passenger_enterprise

drwxr-xr-x   5 root root  4096 Mar 25 13:11 perl

drwxr-xr-x   7 root root  4096 Mar 25 13:11 php

drwxr-xr-x   5 root root  4096 Mar 25 13:11 postfix

drwxr-xr-x   5 root root  4096 Mar 25 13:11 postgresql

drwxr-xr-x   5 root root  4096 Mar 25 13:11 pxe_dust

drwxr-xr-x   6 root root  4096 Mar 25 13:11 python

drwxr-xr-x   5 root root  4096 Mar 25 13:11 quick_start

drwxr-xr-x   5 root root  4096 Mar 25 13:11 rabbitmq

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rabbitmq_chef

drwxr-xr-x   6 root root  4096 Mar 25 13:11 radiant

drwxr-xr-x   5 root root  4096 Mar 25 13:11 rails

drwxr-xr-x   4 root root  4096 Mar 25 13:11 rails_enterprise

-rw-r--r--   1 root root  1227 Mar 25 13:11 Rakefile

-rw-r--r--   1 root root   659 Mar 25 13:11 README

drwxr-xr-x   5 root root  4096 Mar 25 13:11 redmine

drwxr-xr-x   4 root root  4096 Mar 25 13:11 reprepro

drwxr-xr-x   5 root root  4096 Mar 25 13:11 resolver

drwxr-xr-x   8 root root  4096 Mar 25 13:11 riak

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rsync

drwxr-xr-x   6 root root  4096 Mar 25 13:11 rsyslog

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ruby

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ruby_enterprise

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rubygems

drwxr-xr-x   7 root root  4096 Mar 25 13:11 runit

drwxr-xr-x   3 root root  4096 Mar 25 13:11 rush

drwxr-xr-x   7 root root  4096 Mar 25 13:11 samba

drwxr-xr-x   7 root root  4096 Mar 25 13:11 sbuild

drwxr-xr-x   3 root root  4096 Mar 25 13:11 screen

drwxr-xr-x   5 root root  4096 Mar 25 13:11 snort

drwxr-xr-x   7 root root  4096 Mar 25 13:11 solr

drwxr-xr-x   3 root root  4096 Mar 25 13:11 sqlite

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ssh_known_hosts

drwxr-xr-x   4 root root  4096 Mar 25 13:11 stompserver

drwxr-xr-x   5 root root  4096 Mar 25 13:11 subversion

drwxr-xr-x   5 root root  4096 Mar 25 13:11 sudo

drwxr-xr-x   4 root root  4096 Mar 25 13:11 teamspeak

drwxr-xr-x   5 root root  4096 Mar 25 13:11 teamspeak3

drwxr-xr-x   3 root root  4096 Mar 25 13:11 thrift

drwxr-xr-x   3 root root  4096 Mar 25 13:11 tmux

drwxr-xr-x   5 root root  4096 Mar 25 13:11 tomcat

drwxr-xr-x   8 root root  4096 Mar 25 13:11 tomcat6

drwxr-xr-x   5 root root  4096 Mar 25 13:11 trac

drwxr-xr-x   8 root root  4096 Mar 25 13:11 transmission

drwxr-xr-x   5 root root  4096 Mar 25 13:11 ubuntu

drwxr-xr-x   4 root root  4096 Mar 25 13:11 ucspi-tcp

drwxr-xr-x   5 root root  4096 Mar 25 13:11 unicorn

drwxr-xr-x   4 root root  4096 Mar 25 13:11 users

drwxr-xr-x   5 root root  4096 Mar 25 13:11 varnish

drwxr-xr-x   4 root root  4096 Mar 25 13:11 vim

drwxr-xr-x   5 root root  4096 Mar 25 13:11 wordpress

drwxr-xr-x   3 root root  4096 Mar 25 13:11 xfs

drwxr-xr-x   3 root root  4096 Mar 25 13:11 xml

drwxr-xr-x   8 root root  4096 Mar 25 13:11 zenoss

drwxr-xr-x   3 root root  4096 Mar 25 13:11 zlib

drwxr-xr-x   3 root root  4096 Mar 25 13:11 zsh

[root@localhost chef-repo]# 

 
   
이제 슬슬 간단한 것 부터 한번 실제로 해봐야 겠다..........
저작자표시 비영리 변경금지

'Cloud > Automation' 카테고리의 다른 글

Puppet Configuration Management Tool  (0) 2012.02.23
Chef Server/Client (on FrameOS6)  (0) 2011.05.12
[시스템 자동화] Install Chef Server/Client on CentOS 5.4 x86_64 ...(폐기)  (1) 2011.04.23
Install Chef-Solo on CentOS 5.4 x86_64  (1) 2011.03.27
[Chef]에 관해 간결하고, 재미있게 잘 작성된 PT자료 (추천문서)  (0) 2011.03.25
Posted by 사랑줍는거지
,

[웹OS] 10년전 Web OS로 본 한국의 Cloud

Cloud 2011. 3. 10. 00:56
[웹(Web)OS]

먼저 밝힙... 제목은 낚시성(ㅡㅡ;;) 회식이 있어 아주쬐끔 소주 1~2잔 했는데 알싸~하네요 아직... 뭐 가볍게 봐주시고~~ 혼잣말을 글로 옮기는 수준이라, 존칭 구별 없습니다. ;;;;; 


오늘 클라우드 개념에 관한 글을 하나 보게 되었는데, 그글은 갠적으로 정말 동의 할수 없는 글이라 또 다시 나로 하여금 이것저것을 생각해보게 만들었다.


시간을 거슬러 10여년전 군대를 제대(정확히 1999년 10월이었다.)하고 복학하기까지 시간이 하~안~참 남아 그당시 최고의 주가(?)를 달리던 주식회사 PC방에 단골 주주로 등록하고 거의 살다 시피 했다.

맨날 채팅(요즘은 거의 안하죠? 세이클럽~ㅎㅎ) 아니면, 레인보우 식스(아 또 다시 하고 싶네), 스타크래프트(이건 요즘도 합니다.ㅡ.ㅡ;;)로 날밤 샜었죠.

그러다 어느날 팝데스크란걸 접하게 되었습니다. 그당시에도 웹하드 서비스로 이름을 날리던 팝폴더에서 나온 것으로 기억납니다. 팝데스크는 개인용 PC의 바탕화면(윈도우즈 인터페이스를 거의 흉내)을 웹으로 제공하고, 워드 나 메모장, 간단한 게임 등의 작업을 온라인에서 수행할수 있는.. 한마디로 요즘 다시 화자되는 Web OS였죠.


스샷입니다. 그당시 전 이거 보고~ 와! 스타도 돌아갈까? (당연 안됬습니다. ㅡㅡ;;) 등등 이런 발상도 할수 있구나~ 라는 신선한 충격을 받았더랬죠~

그러나~~!!!!!!!!!!!!!!!!!!!!!

몇일 사용해보고 더이상 손이 가지 않더군요.

이유는 뭐였을까요???....................... 네~~~~~~ 너........무.....나.......... 느! 렸! 습! 니! 다! (ㅡ.ㅜ);;;
지금에 비해 당시 굉장히 열악한 네트워크 속도와 환경 덕(?)에 저런 WebOS들이 하나둘씩 사장되고 잊혀지더군요.
저 팝폴더 말고도 아래와 같은 서비스들이 많았습니다. 물론 외국에는 더 많았구요.(국내 서비스도 그랬는데, 외국 WebOS 속도는 어땠는지 긴 말 필요 없겠죠??)




아무튼!!!! 발상은 굉장이 좋았다~ 입니다. 개인 PC의 리소스를 사용하는게 아니라, 원격지 리소스를 이용해서 어디서든지 동일한 환경, 동일한 작업 내용을 이어서 사용가능하다~~였는데~~~ 불행하게도 그걸 실현할 인프라가 받혀주질 못했던거죠. 그나마 당시엔 요즘 웹하드라 불리는 웹폴더(당시엔 웹폴더라고 더 많이 불렀음)서비스는 호응도가 좋았습니다. (느려도 다운 걸어놓고 딴짓하면 그만이니까요.)

돌이켜 보면 저게 요즘 눈만뜨면 떠들어 대는 Cloud의 개념을 직관적으로 보여주는 것이 아닐까 하네요.

클라우드(Cloud)........ 갠적으로 국내는 이제막 태동기라고 생각합니다. 소수 몇몇 집단이나 조직, 개인만이 관심을 가졌던 Cloud... 또는 관심이 있었더라도 적극적으로 댐벼볼 동기부여가 없었던 Cloud였지만(국내 이야기 입니다.)최근 붐이 불기 시작했죠 전문가들뿐만 아니라, 일반인들조차도 인식을 하기 시작했으니.........


그럼 WebOS 이야기로 다시 돌아가서~~~
10년전에는 불가능했던 것이, 지금은 가능하다.......????? 무엇때문에???? (아시면서~~~)
네.. Network라고 생각합니다. 적어도 저는........ 10년전 20년전... 30년전... 다 상상하고 시도하고 만들어도 봤었지만, 결정적으로 실용성(?)이 없었다고 보는게 맞을듯 하네요.

예로, 가상머신.......... 누구나 알고 있는 VMware...... 제가 알기론 연혁이 10여년이 넘었습니다.(틀리면 지적질 부탁) 초창기 VMware....... 엄청 느렸습니다.ㅡㅡ;;; 지금은??? 무지~ 쾌적합니다. 순식간에 롤백합니다. 한마디로 좋~~습니다. 추가로 가상화에 대해 좀더 비약하자면 1960년대 메인프레임부터 개념과 시도가 있었습니다. 활용률이 낮아 가상화를 고려했었더럤죠......

어쨌든 10년전 반짝만 하고 사라졌던 국내 WebOS에 Cloud를 투영해 볼때, Cloud에 대한 내 개인적인 생각은,

"Cloud는 Resource(이미 존재하고 사용해왔던 요소/기술)의 조합이다. 단, 그 조합들을 튼튼하게 엮어주고 유지시켜줄 수 있는 Networking이 가능해야 한다."
 
이다. 뭐 이 역시 나혼자만에 생각이고, 헛소리 일지도 모른다. 그래도 뭔가 Cloud에 대한 정체성(?)은 확립해 둘 필요는 있다. 뭐 뭐지 않아 누군가 지금과 같은 "제멋대로 Cloud"인 "Cloud 춘추전국 시대"를 평정할지도 모르지만.... 



ps. 요즘 "클라우드"이름 붙이기 쉽고 딱 좋은게 기존의 웹하드다. 조금만 변형하면 그럴듯하게 "클라우드"라는 이름을 붙여서 고객에게 어필할수 있으니.......... 그러나 웹하드와 클라우드스토리지를 차별화 하지 않으면 언젠간 들통 날것이다. 고객은 바보가 아니다.
PC전용 클라이언트가 있다고, 웹에서 접근 가능하다고, 동기화된다고, 용량 많다고 클라우드스토리지라고 할수 있나? 정말 애매한 경계선이다. 최근에는 아주 대놓고 이제 용량 경쟁을 하는 듯한 분위기던데.... 
웹하드와 비교해 클라우드스토리지는 뭐가 차별점일까? WebOS에서도 언급했었는데, Resource가 아닐까 한다. 로컬 Resource를 필요로 하지 않는 스토리지??? 무슨 말이지??? 예를 들어 보자(광고 하는것은 아니니 오해 마시길......) 유료 전환후 관심이 없어져 요즘 행보는 어떤지 모르는 "2nd Driver"... 이게 NDriver나 여타 자칭 클라우드스토리지라는 서비스들과 다른 점이 있는데....... 사용자가 원본 동영상을 올려두기만 하면, 서버의 CPU Resource를 이용해, 모바일 Device에서 보기에 최적인 용량으로 변환(인코딩)해준다. 이게 무슨 의미인지 감이 오시는지?? 단순히 파일올리고, 스맛폰에서 확인하고, 웹에서 다운하고 하는 것은 기존의 우리가 "웹하드"라고 불렀던 서비스들도 얼마든지 할수 있다고 본다. 그러나 예로 들었듯이 사용자가 올린 데이타를 인코딩 해주거나, 또는 구글과 같이 수백MB급의 엑셀데이타를 사용자가 올리면 그걸 분석해서 그래프로 그려준다던지....... 이런게 Cloud가 웹하드에 비해 가질수 있는 차별요소이고 구별점이라고 본다는 것이다. 

이 글 역시 잡생각이고, 오판일지도 모른다. 그래도 무언가 명학하게 두 개념을 구별할수 있는 요소가 필요했다. 여러 사람들이 작성한 문서, 인터넷 기사, 글 등을 봐도 딱!!! 이거다!!! 라는 것이 없었다. 멍청한 나에겐 와 닿는게 없었다. 그래도 그런 글들을 계속 접하면서 하나 둘씩 개념을 잡아 나가야 할것 같다. 갈길이 멀다~ 에효~~~

그럼...........


저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
CloudStack 2.2.x - Networking Model 분석  (0) 2011.10.30
클라우드프론티어2011..............  (0) 2011.10.26
(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......  (1) 2011.04.04
CloudStack 2.2.2 Release -> 2.2.3  (0) 2011.03.17
Posted by 사랑줍는거지
,

티스토리툴바