System Compleat.

'클라우드를 사용해야 하는 이유'에 해당되는 글 1건

  1. Why do you want to build A "Cloud"?

Why do you want to build A "Cloud"?

Techs


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



1. 문제 


클라우드 클라우드 클라우드 지겨워 죽을 정도로 많이 이야기된다. 누구는 사업 타당성에 대해서, 누구는 어떻게 만들어야되는지에  대해서, 누구는 그 실질적 효용성에 대해서. 구름이 어쩌고 아키텍쳐는 뭔데 아마존과 구글이 뭘 했다더라 등등등. 


여기에 맵 리듀스가 뭐고 빅데이터가 어쩌구 하기 시작하게 되면 제조업 중심의 회사CIO 또는 전형적인 SI 타입의 레거시 IT 회사들의 의사결정자들에게 이 주제는 난공불락처럼 보였던 만리장성 쌓기처럼 들린다. 사실 그렇게 들리는 것이 맞을 수 있다. 대부분의 중견기업 관리자들에게 클라우드란 그저 어느날 KT 로부터 촉발된 새로운 타입의 인프라일 뿐 아니겠는가. 


요는, 그렇게 많이들 이야기 하고 있는 주제임에도 불구하고 아직도 이게 무엇인지, 어디에다 써야하는지 모르는 사람들이 생각보다 엄청 많다는 것이다. 대화를 조금 섞어보면 아는척 하기만 하는 사람도 참 많다. 아울러 KT 클라우드는 대체 자기가 만들었다고 하는 사람들이 왜 그리 많은 것인가. 내가 거기서 아키텍처 미팅하고 자동화 코드 작성할떄는 8-12명 정도가 다였는데. 뭐 이건 좀 다른 이야기고. 


우리나라 기업들에서 클라우드에 대해 모르는 것을 정리하면 대략 다음과 같은 것들이다. 


1. Amazon EC2 / S3 / Google AppEngine / Google Drive 서비스가 뭐하는 서비스인지 대부분 모른다.  

2. 위의 두가지 서비스를 직접 사용 해 본 중간관리자가 거의 없다. 

3. 구글과 아마존, 빅데이터에 대해서는 위와 아래로 부터 귀가 따갑게 들었다. 

4. 위의 1,2,3 번을 몰라도 Facebook / Twitter 는 들어봤다. 

5. 1,2,3,4 번을 다 듣고 안다. 그래서 클라우드를 만들어서 오라클을 넣을 생각이다. 



2. 클라우드 마이그레이션 하면 좋은 샘플


아주 먼 옛날, 그러니까 지금으로부터 대강 5년 전 즈음에 다녔던 호스팅 회사의 고객 중 다음의 고객이 급성장 하고 있었다. 이들은 누가 보아도, 다른 쇼핑몰과 비교해 보아도 확실히 매력적인 몇가지 요소를 가지고 있었다. 뭐 그것은 그 회사 사장님의 마케팅이나 경영적 노하우니까 나와는 상관 없다. 문제는 그 회사가 "괄목할만한 성장을 하고있다" 라는 것이었다. 그 사이트는 바로 Stylenanda.com 였고, 이 사이트의 엄청난 고객의 증가로 인해 기존의 시스템을 확장, 분산해야 하는 이슈를 쇼핑몰 담당팀과 함께 연구소에서 처리를 하기로 했다. 


아직도 매력적으로 보이는 그 회사



다른 쇼핑몰과 마찬가지로, 이 회사는 엄청난 양의 이미지를 서비스 하고 있었다. 레이아웃을 짜는 것이 쉽지 않아서 그런건지는 잘 모르곘지만, 대부분의 쇼핑몰들이 포토샵을 통해 페이지당, 또는 사진 한장에 몇메가씩 되는 사진을 페이지로 서비스 한다. 그리고 꼭 필요한 결재에 필요한 연동, 배송에 관한 부분, 뭐 그런것들이 일반적인 쇼핑몰의 시스템 구성이다. 


당시 우리는 크게 두가지 방향으로 성능을 개선하기로 했는데, 하나는 소프트웨어적인 튜닝을 통한 개선이었고 다른 하나는 하드웨어를 역할별로 분리하여 여러개의 프로세스를 한꺼번에 돌렸을 때 발생하는 심각한 양의 context switching 으로인한 CPU time 의 낭비를 막는 것이었다. 이 두가지 개선 방향은 디테일하게 말하는 것은 법적 문제가 있을 수 있기 때문에 여기서 줄이지만, 아무튼 큰 효과를 보였으며 단일 시스템으로서도 동일한 사용자 유입시에 시스템의 부하가 절반으로 감소했었다. 


뜬금없이 갑자기 잘 나가는 쇼핑몰을 예로 들었지만, 이것이 바로 왜 클라우드 시스템을 사용하면 좋은지에 대해 이야기 해 볼 수 있는 가장 좋은 예가 된다. 그리고 아마존에서 제안하고 있는 기존 서비스를 클라우드로 마이그레이션 할 때 나오는 LAPM 그림에 가장 적합한 모델이기도 하다. 그 과정은 예나 지금이나 크게 다른 것은 없지만, 이런 서비스가 클라우드로 이사갈때, 또는 애초에 클라우드에 있을 때 무지하게 이득을 볼 가능성이 높다는 것이다. 어떤 서비스도 마찬가지지만, 어느 순간에 급격한 성장을 보이며, 이 회사가 만약 IT 나 IT 리소스를 사용하여 서비스 하고 있던 회사였다면 확장/증설/튜닝을 통해 사용자 증가를 처리 하고자 할 때 반드시 모멘텀이 필요했다는 것이다. 


이러한 모멘텀을 줄여줄 수 있는 것이 바로 클라우드이며, 그 클라우드 시스템에 등록된 서비스가 "클라우드에 맞게" 등록되어 있을 때 확실한 효과가 발생 할 수 있다. 



3. 현실 그리고 앞으로는. 


우리나라의 대기업들이 하는 서비스 중에는 보통 데이터 폭발 발생하지 않는다. 심지어 발생중이라고 하더라도 그 양이 매우 미비하다. 더군다나 이미 있는 서비스들은 도저히 교체 불가능한 아키텍처와 벤더 제품들로 떡이 되어있다. 지금 시점에서 그것은 좋다 나쁘다를 가리기는 힘들며, 그것들은 그것 나름대로 이미 동작하고 있는 서비스다. 이야기의 흐름대로 만의 하나 그런 서비스가 생겨난다면 확장이 매우 힘들겠지만, 어쨌든 똑같이 다시 벤더를 사용해서 떡을 만들것이다. 비싸지고, 하청업체가 없어짐으로 해서 다시 코드 관리 안되고 나중에 뭐 좀 해보려면 년단위 프로젝트로 짜야하는 뭐 그렇게 전과 똑같은 수순. 


하지만 벤더 제품은 그 나름대로 존재의 의미가 있다. 그것들은 안정되고도 보장된 신뢰를 바탕으로 확장과 성능은 비록 떨어 질 수 있지만 여태까지의 인프라를 구성 해 왔으며, 지금 현재 기업에 구성된 업무 프로세스와도 밀접한 관련이 있다. 이것들은 기업에서 매우 중요한 포지션을 차지하고 있으며, 이것들이 어떠한 이유로든 중지하게 되면 심각한 문제를 발생 시킬 수 있다. S사 같은 글로벌 회사의 인증 시스템이 중지했다고 하면 아마 어마어마한 혼란을 초래 할 것은 누가 봐도 분명하다. 그래서, 벤더로 되어있지만 중요하고 쉽게 중지 시킬 수 없으며, 또 데이터가 매우 귀중하기 때문에 한꺼번에 어디로 옮기는 것은 쉽지 않다. 


따라서 중요한 것은, 클라우드에 넣어도 되는 것과 넣지 말아야 할 것, 즉 똥과 된장을 구분해야 할 필요가 있는데 이것이 잘 안되는 경우가 많다는 것이다. 한가지 더는, 똥과 된장을 구분했다면 이걸 가지고 국을 끓일지 쌈장을 만들지를 알아야 하는데 여기에는 아직 경험이 없다보니 일이 제대로 되지 않는 경우가 많다는 것. 


이런 현실을 탓하기 전에, 우리는 우리 스스로 자문 해 볼 필요가 있다. 우리는 과연 저런 생각을 가지고 있는 의사결정권자를 만났을 때 적절한 해법을 제시 할 수 있는가. 나는 아래와 같은 것들을 먼저 간단히 정리 해 봤다. 


1. 이미 잘 동작하고 있는 서비스의 "데이터" 를 클라우드로 이전 하지 말 것. 

2. 대부분의 기업에게 모바일 서비스는 신규 분야이므로, 이 부분을 우선 적용. 

3. 컴퓨트 클라우드는 하루 아침에 뚝딱 만들어 지는 것이 절대 아님. 장비 비용을 제외하더라도 년단위의 계획과 백억단위 이상의 자금이 필요함. 단, 이 이전에 소규모 POC 를 수행해야함. 

4. 현재 버리고 있는 데이터의 수집/아카이빙을 목표로 비교적 구현이 쉬운 스토리지 클라우드를 먼저 생각해야 할 필요가 있음. 

5. 기업 내부의 신규 사업이라면, 아마존과 같은 서비스에 런칭 해 볼 필요가 있음 

6. 기존의 인프라 관련 구성원들이 자동화 / 클라우드 서비스에 대해 익숙해 져야 할 필요가 있음 


최근 기존의 서버 / 인프라 벤더들이 엄청나게 저렴한 가격으로 시장을 공략하고 있다. 결론부터 말하자면, 이것들은 정상적인 가격이 아니다. 클라우드 태그가 붙지 않으면 제품이 팔리지 않는다. 그리고 그 가격을 바탕으로 다시 Vendor lock in 을 걸려고 하고 있으며, 여기에 클라우드 사업을 제안하고 있다. 여러가지 측면에서 클라우드에 대한 명확한 접근 개념없이는, 이 모든 것들은 국내 시장에 혼란을 가중시키고 있을 뿐이다. 


언젠가는 모든것을 깨닫게 되는 날이 오겠지만, 그 전에 현재의 어려운 경제적 국면에서 어마어마한 비용을 쏟아 뻘짓하는 것은 막을 수 있으면 막았으면 하는 바람이다. 그리고 그 "언젠가"를 보다 앞으로 당기는 것이 필요 하지 않을까 하는 생각. 


스타일난다의 시스템 확장이 발생했던 근본적 원인과 클라우드가 가져야 할 가장 큰 덕목인 Elasticity 를 생각해 볼 필요가 있다. 만약 기존의 서버로 구성된 레거시 시스템이 있다면, 그리고 클라우드를 사용해서 사업을 하고 싶다면, 해답은? 모바일 전용 페이지를 클라우드에서 시작 해 보는것, 그런 시작이 필요하지 않겠다 싶다. 말도안되는 Public IaaS 를 만들겠다 이런거 말고. 




결국은, 신규와 모바일 서비스를 통해 기업의 클라우드에 대한 역량을 준비해야 하며, 빅데이터에 대해서는 지금까지 버릴 수 밖에 없었던 데이터 소스를 저장할 스토리지 클라우드를 구성해야 한다는 말이 이 포스팅의 전부다. 


 

조금 마케팅적인 이야기라서, 숙취상태에서 쓴 글이라 너무 중구난방이다 라는 사족을 붙이고 싶은 포스팅. 


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