Andrew의 Cloud 이야기 #3

안녕하세요 앤드류 입니다.

클라우드쪽에서는 아주 유명한 오픈스택이라는 솔루션이 있습니다.(빅데이터의 하둡만큼 유명하다고 보시면 됩니다.) 오픈스택은 매년 2번씩 summit을 전세계 개발자와 소프트웨어, 하드웨어 공급자를 대상으로 컨퍼런스를 개최합니다. 컨퍼런스에는 글로벌하게 내노라하는 업체들이 부스(booth)를 차리고 자신들이 오픈스택에 어떤 것들을 지원하고 어떤 식으로 지원하는지에 대해서 자랑스럽게 광고합니다. 늘 외국에 나오면 느끼는것이지만 이런 컨퍼런스에서 한국 회사나 제품들이 보다 더 많이 적극적으로 보였으면 좋겠습니다.

이번에는 저도 제가 다니는 회사에서 하고 있는 클라우드 네트워크 관련된 내용을 발표할 수 있는 기회를 가졌습니다. 처음에는 그냥 할 수 있으면 좋겠다고 생각해서 무작정 지원을 했는데요(오픈스택은 발표자[speaker]를 투표에 의해서 결정합니다.), 안될줄 알고 지원하고 홍보도 별로 안했는데 결정되었다는 연락을 듣고선 이걸 왜 했을까 라는 후회가 더 컸습니다. 아무튼 우여 곡절끝에 발표는 잘 마쳤습니다. 혹시 궁금하신 분들은 구글에서 ‘openstack daumkakao sdn withou sdn’ 정도의 키워드로 검색하시면 제가 한 내용들을 보실 수 있습니다.

작년 말부터, 오픈스택 서밋에서 가장 인기 있는 세션은 단연 컨테이너 관련 세션이었습니다. 클라우드 초기에 사용되던 용어중에 멀티 테넌시(multi-tenancy)라는 컨셉이 있었습니다. 하나의 서버에 여러 명의 사용자(테넌트)가 사용할 수 있도록 해준다는 개념입니다. 하나의 물리자원을 가상자원으로 나누어서 사용해서 리소스 사용량을 극대화 시킬 수 있다는 개념이고, 이를 위해서 가장 중요한 기술은 자원 격리(resource isolation) 입니다. 다른 사용자가 실행시킨 프로세스에 영향을 받지 않고 내 프로세스를 사용할 수 있도록 하는것이 자원 격리인데요, 대부분의 클라우드 서비스와 솔루션들은 이를 위해서 가상화를 사용하였습니다. 간단하게 설명하면 가상이지만 완전히 물리 서버와 동일한 느낌을 주는 프로그램과 기술을 사용한것입니다. 그래서 한때는 ‘클라우드 기술 = 가상화 기술’ 이렇게 통용되었던 적도 있습니다.

자원 격리를 위해서 초기에는 이 가상화 기술 이외에는 별다는 대안이 없어서 사용자들은 별다른 선택의 여지 없이 가상머신을 만들거나 신청해서 사용했습니다. 그리고 가상 서버라고 하긴 하지만 사용자에게는 서버와 완전히 동일하게 느껴지기 때문에 큰 거부감 없이 사용했습니다(물론 가상 서버가 좀 덜 안정적이라는 통념때문에 엔터프라이즈쪽에서는 좀 느리게 적용하긴 했습니다.).

리눅스 관련 기술이 점점 발전 하면서, 이 자원 격리를 위한 기술역시 발전하기 시작했습니다. 새로운 자원 격리 기술을 통칭해서 ‘네임 스페이스(namespace)’ 라고 합니다. 코드를 작성할때 중복되는 이름들을 막거나, 해당 모듈이나 패키지에서만 변수들의 이름을 검색하도록 네임스페이스를 정의했는데요, 이것을 컴퓨팅 자원 사용에도 적용시킨 것입니다. 특정 네임스페이스에서 실행한 내용은 다른 네임 스페이스에서는 보이지 않습니다. 이 기술을 사용해서 가상화 없이도 사용자 프로세스를 격리 시켜서 사용할 수 있게 된 것입니다. 사용자가 편리하게 자신의 자원을 네임스페이스 안에서 생성하고 수행할 수 있도록 도와주는것을 ‘컨테이너’ 기술 이라고 생각하시면 될것 같습니다. 그리고 컨테이너를 사용함에 있어서 이전과 가장큰 차이는 표준화 입니다.

우리가 일반적으로 알고 있는 컨테이너를 생각해보면, 컨테이너는 그 크기와 모양이 일정합니다. 그래서 컨테이너 안에 어떤것을 넣을지는 사용자가 결정을 하고, 배를 움직이는 선사들은 그 컨테이너만 받아서 이쪽에서 저쪽으로 옮겨주죠. 그리고 컨테이너는 규격이 표준이라서 세계 어느 항구에서도 이동이 가능합니다. 이러한 컨셉을 바탕으로 컴퓨팅 영역에서도 동일하게 컨테이너처럼 표준화된 방식으로 사용하는 개념과 관련 기술들이 나오기 시작했습니다.

이 기술을 가장 먼저 사용하고 있던 곳은 구글입니다. 구글은 현재 약 100만대 정도의 서버를 운영하고 있는것으로 알려져 있습니다. 그래서 각 개발자별로 각각 다른 종류의 서버나 스토리지를 할당해서 관리하다간, 관리 부하를 감당하기가 어려웠을것입니다. 개발자에게 컴퓨팅 리소스를 주되, 표준사양으로 제공하기 위해서 여러 고민을 하다가 결국 컴퓨팅 리소스에 관해서 만큼은 컨테이너라는 표준으로 제공하는것이죠. 그래서 구글 개발자들은 어떤 사양의 서버를 달라고 하지 않는다고 합니다. 그냥 인스턴스 몇개 그리고 스토리지는 얼마 이런식으로 만 요청하면 리소스 관리쪽에서 할당을 해준다고 하네요.

구글은 이런 컨테이너관리용 프로그램을 보그(borg)라는 이름으로 내부적으로 사용하다가 2014년초에 쿠버네티스 (kubernetes)라는 이름으로 오픈소스화 했습니다. 초기에 오픈된 버전은 성능과 확장성에 문제가 아주 많았으나, 현재 버전 0.5이상 올라가면서 많이 안정되고 있습니다. 올해 말에는 본격적으로 엔터프라이용으로 올릴 생각이라고 하니 어느정도 좋아질지 지켜볼만 합니다. 그리고 역시 올해 구글 컨테이너 서비스인 GKE(google kuberentes enterprise, 가칭) 를 시작한다고 합니다. 내부에서 쿠버네티스를 사용하다가 공개하고 싶다면 바로 구글의 클라우드를 사용하라는 것이지요.

쿠버네티스 외에, 비슷한 기능을 하는 메조스피어(mesosphere), 쓰루(tsuru)와 같은 솔루션들도 나오고 있습니다. 그리고 전통적으로 파스(Paas, Platform As A Service) 솔루션으로 잘 알려진 클라우드 파운드리 (cloudfoundry) 역시 컨테이너 지원에 박차를 가하고 있습니다.

그리고 컨테이너용 전용 OS역시 나오고 있습니다. 이전 OS에서 컨테이너관련 기능만 집어 넣고 나머지는 다 뺀 아주 가벼운 리눅스가 나오고 있습니다. 코어오에스(coreOS)가 그중 대표적인 리눅스 인데요. 컨테이너용 솔루션인 도커, 그리고 코디네이션 서비스용으로 엣씨디(etcd) 그리고 클러스터 서비스용으로 플릿(fleet)을 제공 하고 있습니다. 컨테이너 초기에는 코어오에스와 도커가 아주 긴밀한 관계로 지냈는데, 코어오에스가 구글에 인수되고 별도의 로켓(rocket)이란 컨테이너 관리 솔루션을 넣기 시작하면서 둘의 관계가 좀 소원해진것 같습니다. 코어 오에스 외에 레드햇은 아토믹(atomic)이란 이름으로 새로운 리눅스를 만들고 있고 캐노니컬 역시 컨테이너 전용 오에스를 만들고 있습니다. 이른바 컨테이너 춘추 전국이라해도 과언이 아닐것 같습니다.

하지만 이런것에 압도되지 말고 중심을 잡아야겠지요. 어떤 솔루션을 적용하나보다는 컨테이너관련 기술들이 계속 나오고 이것을 적용하려는 목적을 알고 있어야 하겠습니다. 그것은 다름아닌 리소스 관리의 표준화 입니다. 그것은 몇가지를 포함합니다. 하나는 컴퓨팅 리소스의 표준화 입니다. 이제 컴퓨팅 파워가 더 필요하면 더 큰 서버 대신 표준으로 구분된 인스턴스를 더 많이 달라고 해야하는것이죠. 두번째는 모니터링의 표준화 입니다. 이전에는 서버나 인스턴스에 관리자와 개발자가 서로의 목적에 따라 여러종류의 툴을 사용해서 모니터링하고 관리했지만 이젠 이것도 표준화 되고 단일화 된 형태로 처리를 해야 한다는 것이죠. 심지어 컨테이너 서비스는 ssh 로그인은 막는게 일상적인데, 과연 이것을 받아들일 개발자나 관리자가 몇이나 있을까요

이미 표준화된 형태로 잘 되고 있는 조직에서는 컨테이너로 넘어가는것은 큰 부담이 없겠지만 그렇지 않은 일반적인 조직에서는 정말 아주 큰 장벽이 될 것 같습니다. 하지만 이 역시 어느정도 시간이 지나면 여러 벤더와 개발자 그리고 사용자에 의해 생각보다 어렵지 않게 진행될것 같습니다.

출처 : 한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net