2018.05.23

칼럼 | 쿠버네티스 PaaS에 주목할 만한 이유

Matt Asay | InfoWorld
쿠버네티스 클러스터를 블록체인에 집어 넣으려 오픈스택(OpenStack) 배치를 쏟아붓고 있는가? 걱정할 필요 없다. 다른 대부분의 사람들은 아직 쿠버네티스를 파악하려 시도하는 단계이다. 도커(Docker)이후 가장 ‘핫’한 기술이기는 하지만, 대부분 메인스트림 기업들에게 쿠버네티스는 여전히 ‘흑마술’이다. 구글의 엔지니어링 ‘신’들이 만든 쿠버네티스를 보통 엔지니어들이 이해하려면, 학습해야 할 ‘추상화’가 많기 때문이다.

그러나 이런 기술적 복잡성이 나쁜 것만은 아니다. 이런 복잡성을 제거할 회사들이 존재하는 현실로 이어지기 때문이다. 이와 관련, 해커뉴스(HackerNews)의 한 전문가는 “대부분의 신생 창업회사, 그리고 대부분의 대기업은 콘테이너 오케스트레이션보다 제대로 된 PaaS를 이용하는 것이 훨씬 더 효과적이다”라고 말했다.

일반 엔지니어에게는 너무 높은 쿠버네티스 문턱
쿠버네티스가 탄생한 구글에는 대부분 기업은 상상조차 할 수 없는, 또 대부분의 회사에는 발생할 확률이 거의 없는 아주 큰 데이터 문제가 존재하고 있다. 그렇지만 일반 기업들 역시 데이터 증가 문제 극복에 애를 쓰고 있기 때문에 쿠버네티스 같은 기술이 좋아 보일 수 있겠다.

여기에서 ‘가정법’을 썼다는 점에 유의해야 한다. 쿠버네티스가 나쁜 기술이거나, 나쁜 아이디어라는 의미는 아니다. 그렇지만 아주 복잡한 기술이다. 구글의 데이빗 아르노치크가 명확히 말했듯, 쿠버네티스가 해결하려 하는 대상을 감안할 때 이를 단순하게 만들 수 있는 정도에는 한계가 존재한다.

그는 이와 관련, “분산형 시스템은 까다롭다. ‘블랙박스’와 같은 존재 없이 복잡성을 얼마나 줄일 수 있을지 모르겠다”고 말했다.

쿠버네티스 엔지니어링 팀의 ‘창립 멤버’인 헵티오(Heption)의 조 베다 CEO는 이런 식으로 설명했다. “쿠버네티스는 구글의 많은 경험에 토대를 두고 있다. 그런데 그 경험이 쉽게 해석되지 않는 경우가 있다.”

다시 말해, 구글 엔지니어들은 대규모로 콘테이너를 실행시키는 것과 관련해 자신이 알고 있는 지식을 가져와 쿠버네티스로 통합하려 시도했다. 근본적인 문제 중 하나는 베다 같은 엔지니어들은 구글의 일반적이지 않은 인프라에 친숙하다는 것이다. 복잡한 시스템을 다루는데 익숙하며, 배경이 다른 다른 사람들을 위해 덜 복잡한 시스템을 만드는 방법을 잘 모를 수 있다. 그는 트윗에서 “우리 엔지니어들은 스스로 만든 복잡성을 무시하는 경향이 있다”라고 말하며 이를 인정한 바 있다.

데이터도그(Datadog)의 엔지니어인 제이슨 모아론 역시 “실제 세상에서는 이런 경향이 증폭된다. ‘우리 스스로 구축한 것'은 ‘우리가 이미 알고 있는 것’이고, 여기에는 ‘우리가 이미 배운 것’이 포함되기 때문이다”라고 코멘트를 남겼다.

이런 점을 감안했을 때, 개인적으로 쿠버네티스의(또는 다른 선택한 기술) 복잡성을 추출할(없앨) 믿을 수 있는 벤더를 찾아가는 것이 낫다고 생각한다. 아르노치크가 강조했던 ‘블랙박스’ 역할을 하는 PaaS 벤더다.

쉬운 쿠버네티스? 구글과 레드햇이 시도하기는 하다
쿠버네티스 같은 오픈소스 프로젝트에 대해 관련자들이 복잡성을 무시하기 쉽다. 그런데 멀리 떨어진 곳에서 이를 길들이려 시도하는 것은 훨씬 더 위험하다. 쿠버네티스에 존재하는 문제를 포착해야 한다. 여기에 더해 코드를 자세히 분석해 고칠 수 있어야 한다.

현재 쿠버네티스의 문제 해결 능력에 있어 가장 크게 기여하고 있으며, 가시적으로 문제를 개선할 수 있는 포지셔닝을 갖고 있는 회사로는 구글(Google)과 레드햇(Red Hat)이 있다.

구글은 쿠버네티스를 관리형 클라우드 서비스(Google Kubernetes Engine을 통해)로 직관적으로 운영할 수 있도록 만들었다. 대부분의 쿠버네티스 워크로드가 아마존 웹 서비스(AWS)에서 실행되고 있지만, 개발자들을 위해 기반이 되는 오픈소스 프로젝트를 가장 잘 조정하는 방법, GKE서비스에서 쿠버네티스 실행을 단순화 시키는 방법을 잘 알고 있는 회사는 구글이다.

대기업들이 쿠버네티스트를 시도하고, 이를 통해 그 복잡성이 해결되지 않았음을 인식하게 되면서, 쿠버네티스의 복잡성 가운데 일부를 해결하는 방법으로 구글 클라우드 플랫폼을 테스트하는 기업들이 증가할 것으로 예상한다. 특히 아마존이 발표한 엘라스틱 쿠버네티스 서비스(Elastic Kubernetes Service)가 아직 존재하지 않는다는 점을 감안하면 더 그렇다.

(참고로 AWS가 존재하지 않는 서비스를 사전에 발표하는 것은 이례적인 일이다. 통상 AWS의 발표에는 실제 서비스의 URL이 수반된다. 그런데 EKS는 예외였다. 아마 AWS가 쿠버네티스의 빠른 모멘텀 형성에 놀란 것이 이유일 수 있다.)

쿠버네티스의 PaaS 전환에 있어서 구글보다 한 걸음 더 나간 회사는 레드햇이다. 오픈시프트(OpenShift)가 여기에 해당된다. 레드햇의 폴 코미어 대표에 따르면, 쿠버네티스/오픈시프트는 IT팀이 레거시(구형) 기술을 빠른 속도로 부상하는 클라우드 서비스와 통합하려 애를 쓰는 대신 혁신을 수용하는 데 초점을 맞출 수 있는 일관성과 추상화를 제공하는 플랫폼이다.

물론 이런 주장에는 ‘과장 선전’이 들어있다. AWS 람다(Lambda) 같이 클라우드 전용 서비스와 데이터센터와 연결된 워크로드를 통합하는 것이 복잡하고 어렵지만, 옳은 방향일 수 있기 때문이다. 그럼에도 불구하고 기업들은 불가피하게 구현될 수밖에 없는 하이브리드 IT환경을 모두 연결하는 공통 플랫폼을 원한다. 쿠버네티스는 여기에 도움을 줄 수 있다. 특히 레드햇 같은 공급자가 복잡성을 줄이도록 도움을 주면 큰 도움이 될 것이다.

모이론의 주장처럼 쿠버네티스가 굉장한 ‘약속’만 가득한 마케팅 하이프에 불과할 수도 있다. 그러나 아르노치크의 반박도 여전히 타당하다. 그의 주장에 따르면, 쿠버네티스는 선언적 구성, 서비스 검색, 상태 확인, 점진적인 롤아웃, 키 관리, 기타 서비스를 구현해 “넷플릭스가 하는 일과 같은 일을 100배는 적은 엔지니어로 처리”할 수 있다.

완벽할까? 완벽하지 않다. 완벽하게 구현될까? 절대적으로 불가능한다. 그렇지만 타당하게 구현될 수 있다. 구글과 레드햇 같은 회사들이 기반이 되는 오픈소스 프로젝트에 기여해 다른 모든 이들을 위해 쿠버네티스를 개선하고 있고, 더 나아가 고객들이 더 쉽게 사용할 수 있는 서비스로 구현하고 있기 때문이다.

헵티오 등 더 많은 회사들이 여기에 참여할 것이 분명하다. 이는 좋은 일이다. 경쟁이 증가하면서 평범한 ‘개발자들(그리고 그들을 고용하는 기업들)’가 쉽게 사용할 수 있도록 쿠버네티스가 단순해 질 것이다.

* Matt Asay는 저작권 변호사이자 현 어도비 개발자 에코시스템 대표다. 본 기고문은 어도비가 아닌 그의 견해에 기반해 작성됐다. ciokr@idg.co.kr 

2018.05.23

칼럼 | 쿠버네티스 PaaS에 주목할 만한 이유

Matt Asay | InfoWorld
쿠버네티스 클러스터를 블록체인에 집어 넣으려 오픈스택(OpenStack) 배치를 쏟아붓고 있는가? 걱정할 필요 없다. 다른 대부분의 사람들은 아직 쿠버네티스를 파악하려 시도하는 단계이다. 도커(Docker)이후 가장 ‘핫’한 기술이기는 하지만, 대부분 메인스트림 기업들에게 쿠버네티스는 여전히 ‘흑마술’이다. 구글의 엔지니어링 ‘신’들이 만든 쿠버네티스를 보통 엔지니어들이 이해하려면, 학습해야 할 ‘추상화’가 많기 때문이다.

그러나 이런 기술적 복잡성이 나쁜 것만은 아니다. 이런 복잡성을 제거할 회사들이 존재하는 현실로 이어지기 때문이다. 이와 관련, 해커뉴스(HackerNews)의 한 전문가는 “대부분의 신생 창업회사, 그리고 대부분의 대기업은 콘테이너 오케스트레이션보다 제대로 된 PaaS를 이용하는 것이 훨씬 더 효과적이다”라고 말했다.

일반 엔지니어에게는 너무 높은 쿠버네티스 문턱
쿠버네티스가 탄생한 구글에는 대부분 기업은 상상조차 할 수 없는, 또 대부분의 회사에는 발생할 확률이 거의 없는 아주 큰 데이터 문제가 존재하고 있다. 그렇지만 일반 기업들 역시 데이터 증가 문제 극복에 애를 쓰고 있기 때문에 쿠버네티스 같은 기술이 좋아 보일 수 있겠다.

여기에서 ‘가정법’을 썼다는 점에 유의해야 한다. 쿠버네티스가 나쁜 기술이거나, 나쁜 아이디어라는 의미는 아니다. 그렇지만 아주 복잡한 기술이다. 구글의 데이빗 아르노치크가 명확히 말했듯, 쿠버네티스가 해결하려 하는 대상을 감안할 때 이를 단순하게 만들 수 있는 정도에는 한계가 존재한다.

그는 이와 관련, “분산형 시스템은 까다롭다. ‘블랙박스’와 같은 존재 없이 복잡성을 얼마나 줄일 수 있을지 모르겠다”고 말했다.

쿠버네티스 엔지니어링 팀의 ‘창립 멤버’인 헵티오(Heption)의 조 베다 CEO는 이런 식으로 설명했다. “쿠버네티스는 구글의 많은 경험에 토대를 두고 있다. 그런데 그 경험이 쉽게 해석되지 않는 경우가 있다.”

다시 말해, 구글 엔지니어들은 대규모로 콘테이너를 실행시키는 것과 관련해 자신이 알고 있는 지식을 가져와 쿠버네티스로 통합하려 시도했다. 근본적인 문제 중 하나는 베다 같은 엔지니어들은 구글의 일반적이지 않은 인프라에 친숙하다는 것이다. 복잡한 시스템을 다루는데 익숙하며, 배경이 다른 다른 사람들을 위해 덜 복잡한 시스템을 만드는 방법을 잘 모를 수 있다. 그는 트윗에서 “우리 엔지니어들은 스스로 만든 복잡성을 무시하는 경향이 있다”라고 말하며 이를 인정한 바 있다.

데이터도그(Datadog)의 엔지니어인 제이슨 모아론 역시 “실제 세상에서는 이런 경향이 증폭된다. ‘우리 스스로 구축한 것'은 ‘우리가 이미 알고 있는 것’이고, 여기에는 ‘우리가 이미 배운 것’이 포함되기 때문이다”라고 코멘트를 남겼다.

이런 점을 감안했을 때, 개인적으로 쿠버네티스의(또는 다른 선택한 기술) 복잡성을 추출할(없앨) 믿을 수 있는 벤더를 찾아가는 것이 낫다고 생각한다. 아르노치크가 강조했던 ‘블랙박스’ 역할을 하는 PaaS 벤더다.

쉬운 쿠버네티스? 구글과 레드햇이 시도하기는 하다
쿠버네티스 같은 오픈소스 프로젝트에 대해 관련자들이 복잡성을 무시하기 쉽다. 그런데 멀리 떨어진 곳에서 이를 길들이려 시도하는 것은 훨씬 더 위험하다. 쿠버네티스에 존재하는 문제를 포착해야 한다. 여기에 더해 코드를 자세히 분석해 고칠 수 있어야 한다.

현재 쿠버네티스의 문제 해결 능력에 있어 가장 크게 기여하고 있으며, 가시적으로 문제를 개선할 수 있는 포지셔닝을 갖고 있는 회사로는 구글(Google)과 레드햇(Red Hat)이 있다.

구글은 쿠버네티스를 관리형 클라우드 서비스(Google Kubernetes Engine을 통해)로 직관적으로 운영할 수 있도록 만들었다. 대부분의 쿠버네티스 워크로드가 아마존 웹 서비스(AWS)에서 실행되고 있지만, 개발자들을 위해 기반이 되는 오픈소스 프로젝트를 가장 잘 조정하는 방법, GKE서비스에서 쿠버네티스 실행을 단순화 시키는 방법을 잘 알고 있는 회사는 구글이다.

대기업들이 쿠버네티스트를 시도하고, 이를 통해 그 복잡성이 해결되지 않았음을 인식하게 되면서, 쿠버네티스의 복잡성 가운데 일부를 해결하는 방법으로 구글 클라우드 플랫폼을 테스트하는 기업들이 증가할 것으로 예상한다. 특히 아마존이 발표한 엘라스틱 쿠버네티스 서비스(Elastic Kubernetes Service)가 아직 존재하지 않는다는 점을 감안하면 더 그렇다.

(참고로 AWS가 존재하지 않는 서비스를 사전에 발표하는 것은 이례적인 일이다. 통상 AWS의 발표에는 실제 서비스의 URL이 수반된다. 그런데 EKS는 예외였다. 아마 AWS가 쿠버네티스의 빠른 모멘텀 형성에 놀란 것이 이유일 수 있다.)

쿠버네티스의 PaaS 전환에 있어서 구글보다 한 걸음 더 나간 회사는 레드햇이다. 오픈시프트(OpenShift)가 여기에 해당된다. 레드햇의 폴 코미어 대표에 따르면, 쿠버네티스/오픈시프트는 IT팀이 레거시(구형) 기술을 빠른 속도로 부상하는 클라우드 서비스와 통합하려 애를 쓰는 대신 혁신을 수용하는 데 초점을 맞출 수 있는 일관성과 추상화를 제공하는 플랫폼이다.

물론 이런 주장에는 ‘과장 선전’이 들어있다. AWS 람다(Lambda) 같이 클라우드 전용 서비스와 데이터센터와 연결된 워크로드를 통합하는 것이 복잡하고 어렵지만, 옳은 방향일 수 있기 때문이다. 그럼에도 불구하고 기업들은 불가피하게 구현될 수밖에 없는 하이브리드 IT환경을 모두 연결하는 공통 플랫폼을 원한다. 쿠버네티스는 여기에 도움을 줄 수 있다. 특히 레드햇 같은 공급자가 복잡성을 줄이도록 도움을 주면 큰 도움이 될 것이다.

모이론의 주장처럼 쿠버네티스가 굉장한 ‘약속’만 가득한 마케팅 하이프에 불과할 수도 있다. 그러나 아르노치크의 반박도 여전히 타당하다. 그의 주장에 따르면, 쿠버네티스는 선언적 구성, 서비스 검색, 상태 확인, 점진적인 롤아웃, 키 관리, 기타 서비스를 구현해 “넷플릭스가 하는 일과 같은 일을 100배는 적은 엔지니어로 처리”할 수 있다.

완벽할까? 완벽하지 않다. 완벽하게 구현될까? 절대적으로 불가능한다. 그렇지만 타당하게 구현될 수 있다. 구글과 레드햇 같은 회사들이 기반이 되는 오픈소스 프로젝트에 기여해 다른 모든 이들을 위해 쿠버네티스를 개선하고 있고, 더 나아가 고객들이 더 쉽게 사용할 수 있는 서비스로 구현하고 있기 때문이다.

헵티오 등 더 많은 회사들이 여기에 참여할 것이 분명하다. 이는 좋은 일이다. 경쟁이 증가하면서 평범한 ‘개발자들(그리고 그들을 고용하는 기업들)’가 쉽게 사용할 수 있도록 쿠버네티스가 단순해 질 것이다.

* Matt Asay는 저작권 변호사이자 현 어도비 개발자 에코시스템 대표다. 본 기고문은 어도비가 아닌 그의 견해에 기반해 작성됐다. ciokr@idg.co.kr 

X