System Compleat.

'구성요소와 컨셉'에 해당되는 글 1건

  1. Cloud is not a magic carpet.

Cloud is not a magic carpet.

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


클라우드, 클라우드, 클라우드.

문득 그런 생각을 해 본다. 전혀 새로울 것 없는 이 클라우드에 왜 다들 목숨들을 이렇게 걸어 대시는지들.
4년전에 아마존 서비스 테스트 하면서 그런 생각을 했더랬다.  이거 뭥미... 이렇게 I/O성능 안나오고 퍼포먼스 떨어지는데다가 공인 IP 갯수 제한도 있고.. ELB도 없던 시절이니 RR DNS나 내부에 별도의 Reverse-Proxy 를 구성해 두고 밸런싱 처리하고.. 

3년전에 Windows Azure 를 테스트 하면서도 비슷한 생각을 했다. 내가 뭐 닷넷 개발자도 아니고. SQL Azure 이거 이 성능 가지고 어디다 쓰지 했던.


뭐, 일찍 해 봤다고 자랑하는건 아니다. 다만, 대부분의 업장에서 이제 클라우드가 어떤건지 어렴 풋이들 이해하고 있는 듯 보이고, 주로 그 구성이 IaaS의 구성에만 촛점이 맞추어져 있는 현실.

예나 지금이나 중요한건, 메인프레임을 쓰느냐 클라이언트-서버를 사용하느냐 클라우드를 사용하느냐 하는 문제가 아니다. 더 중요한건, 실제 서비스가 어떠한 구성을 가져야 하느냐에 대한 부분일 것이다. 보안이 중요하다 한들 기업 내부 인프라가 아닌 이상, 아니 심지어 기업 인프라라 해도 모바일을 지원하기 위한 관리된 개방성이 필요하다. 일관성이 중요하다 한들, 오늘이 상반기 결산일이 아닌 이상 영업 데이터가 은행 계좌 잔고만큼 중요할리없다. 영상이나 컨텐츠의 저장과 배포를 위해 내부 시스템에서 마이크로초 단위의 디스크 seek time이 반드시 매번 중요하지는 않다. 무엇을 어디에 배치하고, 어떤 구조로 서비스를 만들어 내느냐 하는 문제는 예전부터 있어왔던 고민이고, 예전부터 있어왔던 해법이고, 예전부터 잘 처리해야 했던 부분들이다.  그게 클라우드에 넘어오면서 옵션이 조금 더 많아지고, 어떤 부분에서는 제한적인 요소도 있기 때문에 혼동하기 쉽지만, 똥과 된장을 구분할 줄 안다면 주전자를 쓰다음으며 지니가 나오길 바라지는 않을 것이다. 

최근의 클라우드 광풍을 보면 다들 무슨 마법의 양탄자 쯤으로 생각하고 있는 것 같다. 동시에, 마법의 양탄자가 아니었다는 사실을 깨닫고 빠르게 포기하거나 그 효용성 자체에 의문을 제기하는 사람들도 많은듯 하다.


주걱으로 국을 뜨려하고, 숟가락으로 라면을 먹으려 하는데 그게 쉬울턱이 있나.


예나 지금이나 컴퓨팅의 본질은 다르지 않고, 빠른 서비스를 위한 인프라 구성의 핵심 부분은 그 컨셉의 측면에 있어서 대동소이하다.  4메가 메모리와 5기가의 디스크를 가졌던 서버 시스템들에서 개발하던 빠른플리케이션의 코딩 방법이 42기가 메모리와 2페타 바이트를 가진 시스템을 위한 코딩과 핵심 컨셉이 다를리 없다. 여기에 클러스터링과 분산 컴퓨팅의 개념만 추가하면 무엇을 어떻게 만들어야 할 지에 대해서는 누가 굳이 그려주지 않아도 답은 뻔하지 않겠나. 

우주 왕복선에서 요구되는 연료의 연소와 노즐의 치밀한 각도 계산과 같은 실시간성이 요구되는 웹 서비스는 없다. 가급적 빠르면 좋은 시스템이라는 전제하에, 대부분의 비지니스 요구사항은 굳이 필요없는 RTOS와 같은 기능성을 요구하고 있지는 않은가 생각해 볼 일이다.

또, 그러한 요구사항을 클라우드 서비스에 들이대는 우를 범하지는 않아야 하겠다. 어플리케이션이 아무런 수정없이 클라우드에 적용되고, 기대했던 바와 같이 탄력성 있게 고객을 수용할 가능 성이 가장 높은 구조를 손에 꼽으라면, 아마도 클러스터링의 개념에 가장 충실했던 어플리케이션이 아니겠는가 싶다. 

클라우드에 서비스를 마이그레이션 할 때 가장 먼저 인정해야 하는것은, 비용이 아니라 바로 클라우드의 한계와 장애이다. 컴퓨팅 클라우드를 사용할때, 가장 높은 비용의 인스턴스를 사용할 것이 아니라 4메가 메모리를 가진 언제 고장나도 이상할 것이 없는 시스템 이라는 전제하에 구조를 짜야 할 것이다. 

하이브리드 클라우드 만드는데 기존 인프라와 빡세게 통신이 발생될 가능성이 있는 부분을 선택한다면 실패할 가능성이 높다고 말해주고 싶다.  캐시에 대한 고민없이 클라우드에 있는 디스크가 우리꺼보다 더 좋을꺼라는 환상을 가지고 있다면 얼른 깨어나시길.  아마존의 EBS가 Private Cloud 구성에 가장 중요한 덕목이 되었다면 어플리케이션 구조부터 다시 보시길 진심으로 권고하고 싶다.  그렇게 만드는거 아니라고. 

Share nothing 이라는 컨셉, Live Migration의 필요성등이 사설 클라우드를 만들고자 한다면 그 필요성에 비추어 반드시 재고되어야 할 것들이다. 아마존 클라우드의 각 서비스에 대한 분석을 제대로 했다면, 클라우드에서 구현해야 하고, 구현 할 수 있는 것이 무언인가에 대해 다들 이렇게 고민할 이유가 없다. 

진정 오라클을 잘 사용하고 있는 사업장에서는, Lock과 Latch가 가져오는 시스템 지연속도 등을 고려하고, 논리적인 관계는 쿼리와 어플리케이션에 녹아있지만 실제 FK를 걸어서 사용하지는 않는다.  내부 쿼리 처리가 어찌나 빠른지 페이지를 열면 데이터베이스에서 뽑아져 나오는 정보는 이미 페이지에 표시되어 있고, 이미지가 천천히 올라와 주신다. 이정도로 데이터베이스를 사용할 줄 아는 조직, 그렇게 많이 못봤다.  다들 오라클 주머니만 채우고 있지 않나.  

클라우드에 서비스를 구성 할 지 말지를 고민하기 전에, 서비스가 어떤 서비스인지 부터 고민하고 어떻게 인프라가 구성되어야 하는지에 대한 밑그림이 먼저 그려져야 하지 않겠는가. 

좋든 싫든, 또 지난시절 언제나 그래왔듯이 컨셉을 이해하고 그 구현을 고민하는 사람들에게는 지난날의 시스템도 이미 충분히 잘 동작하고 있을 것이다. 또 이런 시스템을 굴리고 있는 조직에서는 주변에서 하도 떠들고 있는 클라우드에 마이그레이션이 어떻게 되어야 하는지, 어떤 부분을 적용할 수 있는지의 여부도 면밀히 살펴보고 있을 것이다.  이런 분들에게는 이 새로운 환경은 그저 필요에 의해서 사용되고, 효율적으로 사용 될 것임을 믿어 의심치 않는다. 

대기업의 기존 인프라는 클라우드가 필요 없을 것이다 라는 식으로 이야기 하는 분들이 있는데, 당장 옮기기는 힘들긴 하지만, 그런건 단정 지을 수 있는게 아니다. 지금의 시스템들을 언제까지나 사용할 리도 없고, IBM pSeries를 다음번에 매번 구매해야 할 필요성이 있는건 아니다. 세상의 모든 데이터베이스가 RDBMS만 되어야 하지 않는다면, 자연히 클라우드는 아니라도 클러스터의 필요성은 생겨날 것이다. 

물론 컨셉을 이해하고 적용하시는 분들도 계시겠지만, 또 마케팅과 인문과학 출신으로 도배된 IT조직에서 귀까지 닫고 있는건 그들 사정이겠지만, 자꾸 말도 안되는 소리를 하는 분들이 있어 답답함에 간단히 적어본다.

원래 꼭 해야 했던건, 그게 클라우드라고 해서 안해도 되는건 아니다. 다만, 원래 꼭 해야 되는걸 하지 않았을때 클라우드는 예전보다 더 심한 좌절과 프로젝트의 처절한 실패만을 불러올 뿐이다. 서비스의 클라우드 마이그레이션은 일견 쉬워 보일지 모르겠으나, 그 기술적 진입장벽은 전보다 높아졌음을 이해할 필요가 있을 것이다. 한가지 더 중요한 사실은, 클라우드는 또 하나의 새로운 인프라 형태일 뿐이지 기존의 모든 것을 완전히 대체 할 수 있는 무언가는 아니다. 필요한곳에 적절히 사용 할 때, 비용과 성능, 그리고 가용성의 여러마리 토끼를 잡을 수 있을 것이다. 

국자는 국 뜨는데 쓰자. 

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