Offcanvas

������������������������������������

블로그 | '데스크톱용 컨테이너가 온다'··· 윈도우 10X에 거는 기대

마이크로소프트가 자사의 듀얼 스크린 윈도우 10X 운영체제용으로 새로운 컨테이너를 만들어 레거시 윈도우 애플리케이션을 구동할 수 있도록 했다. 윈도우의 미래에 미치는 영향이 클 것으로 보인다.   컨테이너의 발흥지는 리눅스이지만, 마이크로소프트는 온 마음으로 컨테이너를 받아들였다. 윈도우 서버 2016을 시작으로 마이크로소프트는 윈도우 서버 컨테이너와 하이퍼-V 컨테이너 두 종류의 도커 호환 컨테이너를 제공했다. 그리고 2014년 마이크로소프트 애저의 리눅스 지원을 발표한 운명의 날 이후로 6년이 지난 지금, 개발자들은 일상적으로 윈도우 리눅스 서브시스템이나 애저 클라우드가 지원하는 리눅스 배포판에서 도커 컨테이너에 앱을 연결한다. 하지만 데스크톱용 컨테이너라면 어떨까? 이는 윈도우가 데스크톱 애플리케이션을 통제하는 방법을 완전히 바꿔 놓을 것이며, 윈도우 앱을 모바일 앱만큼이나 쉽고 빠르게 설치할 수 있다. 실제로 이런 컨테이너가 윈도우 10X라는 독특한 운영체제용으로 개발되고 있는데, 오는 가을 신형 서피스와 함께 출시될 예정이다. 2019년 10월 발표된 윈도우 10X는 마이크로소프트 서피스 네오(Surface Neo)용으로 개발된 것으로, 서피스 네오는 태블릿 크기의 화면 두 개가 양옆으로 열리는 그림책 같은 디바이스이다. 네오의 동생격인 서피스 듀오(Surface Duo)는 윈도우 10X 대신 개조한 안드로이드 운영체제를 구동한다. (전화 기능도 포함되어 있지만, 마이크로소프트는 한사코 휴대폰이라고 부르기를 거부한다.) 게다가 지난 달 열린 365 개발자의 날 행사에서 마이크로소프트는 자사의 Xamarin.Forms용 듀얼 스크린 SDK를 두 디바이스 모두와 호환되는 앱 개발에 사용할 수 있다고 발표했다. 그렇다면 컨테이너는 어디에 사용될까? 우선 이 컨테이너는 도커 컨테이너가 아니다. 마이크로소프트는 개발자를 과거와 완전히 단절된 새로운 세계로 끌어들이려 했던 UWP((Universal Windows Platform)의 실패에서 많...

데스크톱 컨테이너 듀얼스크린 윈도우10X

2020.03.11

마이크로소프트가 자사의 듀얼 스크린 윈도우 10X 운영체제용으로 새로운 컨테이너를 만들어 레거시 윈도우 애플리케이션을 구동할 수 있도록 했다. 윈도우의 미래에 미치는 영향이 클 것으로 보인다.   컨테이너의 발흥지는 리눅스이지만, 마이크로소프트는 온 마음으로 컨테이너를 받아들였다. 윈도우 서버 2016을 시작으로 마이크로소프트는 윈도우 서버 컨테이너와 하이퍼-V 컨테이너 두 종류의 도커 호환 컨테이너를 제공했다. 그리고 2014년 마이크로소프트 애저의 리눅스 지원을 발표한 운명의 날 이후로 6년이 지난 지금, 개발자들은 일상적으로 윈도우 리눅스 서브시스템이나 애저 클라우드가 지원하는 리눅스 배포판에서 도커 컨테이너에 앱을 연결한다. 하지만 데스크톱용 컨테이너라면 어떨까? 이는 윈도우가 데스크톱 애플리케이션을 통제하는 방법을 완전히 바꿔 놓을 것이며, 윈도우 앱을 모바일 앱만큼이나 쉽고 빠르게 설치할 수 있다. 실제로 이런 컨테이너가 윈도우 10X라는 독특한 운영체제용으로 개발되고 있는데, 오는 가을 신형 서피스와 함께 출시될 예정이다. 2019년 10월 발표된 윈도우 10X는 마이크로소프트 서피스 네오(Surface Neo)용으로 개발된 것으로, 서피스 네오는 태블릿 크기의 화면 두 개가 양옆으로 열리는 그림책 같은 디바이스이다. 네오의 동생격인 서피스 듀오(Surface Duo)는 윈도우 10X 대신 개조한 안드로이드 운영체제를 구동한다. (전화 기능도 포함되어 있지만, 마이크로소프트는 한사코 휴대폰이라고 부르기를 거부한다.) 게다가 지난 달 열린 365 개발자의 날 행사에서 마이크로소프트는 자사의 Xamarin.Forms용 듀얼 스크린 SDK를 두 디바이스 모두와 호환되는 앱 개발에 사용할 수 있다고 발표했다. 그렇다면 컨테이너는 어디에 사용될까? 우선 이 컨테이너는 도커 컨테이너가 아니다. 마이크로소프트는 개발자를 과거와 완전히 단절된 새로운 세계로 끌어들이려 했던 UWP((Universal Windows Platform)의 실패에서 많...

2020.03.11

“기업 78%가 도입” 쿠버네티스의 성공 비결

컨테이너 오케스트레이션 플랫폼 쿠버네티스가 첫 커밋 후 1년 만인 2015년 중반에서야 1.0에 도달했다는 사실은 믿기 힘들다. 이제 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 설문조사 대상 기업 중 78%가 활용하고 있기 때문이다. 미친 듯이 빠른 도입이다. CNCF 2018년도 보고서에 따르면, 불과 1년 전에 쿠버네티스 활용 기업 비율은 58%였다.  애플리케이션 개발 방식 개선에 나선 기업 입장에서 컨테이너가 얼마나 큰 힘을 발휘하는지 알 수 있는 대목이다. 또 광범위한 기술 도입에 오픈소스가 얼마나 중요해졌는지도 알 수 있다.     쿠버네티스 커뮤니티 쿠버네티스 인기의 비결은 잘 알려져 있다시피 커뮤니티이다. 필자가 2016년 지적한 것처럼, 쿠버네티스는 최초의 컨테이너 오케스트레이션 솔루션은 아니다. 최초 출시의 영광은 메조피어와 도커가 누리고 있다. 또 시중에 나와 있는 유일한 오픈소스 컨테이너 오케스트레이션 툴도 아니었다. 오히려 비결은 개방성이었다. 오픈소스이면서도 통제 방식이 폐쇄적이어서 장래의 기여자들(그리고 경쟁자들)을 좌절시키는 경우가 있다. 그러나 구글은 색다른 전술을 취했다. 이에 대해 당시에 필자는 다음과 같이 적은 바 있다.   “[쿠버네티스, 도커, 그리고 아파치 메조 간에] 커뮤니티 결과가 이렇게 크게 다른 것을 무엇으로 설명할까? 한마디로 구글이다. 아니면 구글의 상대적인 부재라고 할 수도 있다. 다른 오케스트레이션 프로젝트는 저마다 한 업체의 영향을 크게 받는 데 반해, 쿠버네티스는 구글의 독창적인 엔지니어링은 물론, 지속적인 개발에 대한 구글의 무간섭 방식의 덕을 보고 있다.” 5년이 지난 지금 구글은 여전히 쿠버네티스에 가장 큰 기여자이며, 그 뒤를 VM웨어와 레드햇이 따르고 있다. 그러나 쿠버네티스에 오직 구글뿐이었던 시절은 지나갔다. 이제는 어림도 없다. 2,000곳 이상의 업체에 퍼져 있는 3만 5,000명이 넘는 기여자들이 1...

컨테이너 커뮤니티 도커 쿠버네티스 마이크로서비스

2020.03.11

컨테이너 오케스트레이션 플랫폼 쿠버네티스가 첫 커밋 후 1년 만인 2015년 중반에서야 1.0에 도달했다는 사실은 믿기 힘들다. 이제 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 설문조사 대상 기업 중 78%가 활용하고 있기 때문이다. 미친 듯이 빠른 도입이다. CNCF 2018년도 보고서에 따르면, 불과 1년 전에 쿠버네티스 활용 기업 비율은 58%였다.  애플리케이션 개발 방식 개선에 나선 기업 입장에서 컨테이너가 얼마나 큰 힘을 발휘하는지 알 수 있는 대목이다. 또 광범위한 기술 도입에 오픈소스가 얼마나 중요해졌는지도 알 수 있다.     쿠버네티스 커뮤니티 쿠버네티스 인기의 비결은 잘 알려져 있다시피 커뮤니티이다. 필자가 2016년 지적한 것처럼, 쿠버네티스는 최초의 컨테이너 오케스트레이션 솔루션은 아니다. 최초 출시의 영광은 메조피어와 도커가 누리고 있다. 또 시중에 나와 있는 유일한 오픈소스 컨테이너 오케스트레이션 툴도 아니었다. 오히려 비결은 개방성이었다. 오픈소스이면서도 통제 방식이 폐쇄적이어서 장래의 기여자들(그리고 경쟁자들)을 좌절시키는 경우가 있다. 그러나 구글은 색다른 전술을 취했다. 이에 대해 당시에 필자는 다음과 같이 적은 바 있다.   “[쿠버네티스, 도커, 그리고 아파치 메조 간에] 커뮤니티 결과가 이렇게 크게 다른 것을 무엇으로 설명할까? 한마디로 구글이다. 아니면 구글의 상대적인 부재라고 할 수도 있다. 다른 오케스트레이션 프로젝트는 저마다 한 업체의 영향을 크게 받는 데 반해, 쿠버네티스는 구글의 독창적인 엔지니어링은 물론, 지속적인 개발에 대한 구글의 무간섭 방식의 덕을 보고 있다.” 5년이 지난 지금 구글은 여전히 쿠버네티스에 가장 큰 기여자이며, 그 뒤를 VM웨어와 레드햇이 따르고 있다. 그러나 쿠버네티스에 오직 구글뿐이었던 시절은 지나갔다. 이제는 어림도 없다. 2,000곳 이상의 업체에 퍼져 있는 3만 5,000명이 넘는 기여자들이 1...

2020.03.11

기고 | 이동의 자유, 마침내 클라우드 2.0에서 실현되다

데이터와 애플리케이션이 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스 내 어디든 막힘없이 이동하는 멀티 클라우드에 대해 CIO들의 생각을 물어보면 크게 두 부류로 나뉜다.   먼저 경험이 없는 부류다. 아직 AWS, 애저, 구글 클라우드와 같은 퍼블릭 클라우드로 컴퓨팅 기능을 옮기지 않은 부류로서 그 개념을 그다지 대단하게 생각하지 않는다. 어차피 클라우드는 다 그런 식으로 작동하는 것 아니냐는 착각에 빠져 있기 때문이다. 다른 부류는 한때 이들과 똑같은 착각을 했지만, 데이터와 워크로드를 공용 플랫폼으로 옮긴 사람들이다. 이제 이들은 진정한 멀티 클라우드가 가능하기는 한지 의아해하는 상황에 놓여 있다. 사실 진정한 멀티 클라우드는 분명히 가능하다. 실제로 오늘날 멀티 클라우드의 단점을 보완할 새로운 종류의 제품들이 등장하기 시작했다. 이 새로운 제품군을 위해 가트너는 올해 1월 ‘클라우드 데이터 생태계’라는 용어를 만들었고 애널리스트 회사 451리서치는 작년 말 ‘엔터프라이즈 인텔리전스 플랫폼’이라는 말을 쓰기 시작했으며, 이 분야에서 가장 포괄적인 플랫폼을 자랑하는 클라우데라는 지난여름 이 분야를 ‘엔터프라이즈 데이터 클라우드’라고 명명했다. 필자는 이를 클라우드 2.0이라고 부른다. 결국에는 클라우드 1.0에서 기대한 모든 것을 갖출 것이기 때문이다. 들어가며… 데이터센터 활용 결정을 버리기가 불안했던 많은 얼리어답터는 저장공간과 컴퓨팅 기능을 무한정 제공한다는 유혹에 넘어가 클라우드 모델에 적극적으로 뛰어들었다. 그러나 곧 두 발이 묶여버린 경우가 많았다. 그 이유는 2가지다. 첫째, 장기 계약에 묶였기 때문이다. 실제로 어느 정도의 기능이 필요할지 모르는 상태로 그저 가격 우대 혜택을 받으려고 덜컥 장기 계약을 체결해 버린 것이다. 고정 요금이지만 사실상 필요 이상으로 많이 내는 셈이 되었다. 약정한 기능 중 극히 일부만 사용하게 된 경우도 있었고, 어느 정도의 저장공간과 컴퓨팅이 필요할지 과소평가하는 바람에 화들짝 놀랄 정도로...

CIO 451리서치 HPE 애저 스택 클라우드 2.0 ML 멀티 클라우드 아웃포스트 구글 안토스 엔터프라이즈 데이터 클라우드 엔터프라이즈 인텔리전스 플랫폼 아마존웹서비스 마이크로소프트 애저 뉴타닉스 오라클 가트너 IBM AWS 레드햇 컨테이너 클라우데라 호튼웍스 구글 클라우드 클라우드 데이터 생태계

2020.03.05

데이터와 애플리케이션이 퍼블릭 클라우드, 프라이빗 클라우드, 온프레미스 내 어디든 막힘없이 이동하는 멀티 클라우드에 대해 CIO들의 생각을 물어보면 크게 두 부류로 나뉜다.   먼저 경험이 없는 부류다. 아직 AWS, 애저, 구글 클라우드와 같은 퍼블릭 클라우드로 컴퓨팅 기능을 옮기지 않은 부류로서 그 개념을 그다지 대단하게 생각하지 않는다. 어차피 클라우드는 다 그런 식으로 작동하는 것 아니냐는 착각에 빠져 있기 때문이다. 다른 부류는 한때 이들과 똑같은 착각을 했지만, 데이터와 워크로드를 공용 플랫폼으로 옮긴 사람들이다. 이제 이들은 진정한 멀티 클라우드가 가능하기는 한지 의아해하는 상황에 놓여 있다. 사실 진정한 멀티 클라우드는 분명히 가능하다. 실제로 오늘날 멀티 클라우드의 단점을 보완할 새로운 종류의 제품들이 등장하기 시작했다. 이 새로운 제품군을 위해 가트너는 올해 1월 ‘클라우드 데이터 생태계’라는 용어를 만들었고 애널리스트 회사 451리서치는 작년 말 ‘엔터프라이즈 인텔리전스 플랫폼’이라는 말을 쓰기 시작했으며, 이 분야에서 가장 포괄적인 플랫폼을 자랑하는 클라우데라는 지난여름 이 분야를 ‘엔터프라이즈 데이터 클라우드’라고 명명했다. 필자는 이를 클라우드 2.0이라고 부른다. 결국에는 클라우드 1.0에서 기대한 모든 것을 갖출 것이기 때문이다. 들어가며… 데이터센터 활용 결정을 버리기가 불안했던 많은 얼리어답터는 저장공간과 컴퓨팅 기능을 무한정 제공한다는 유혹에 넘어가 클라우드 모델에 적극적으로 뛰어들었다. 그러나 곧 두 발이 묶여버린 경우가 많았다. 그 이유는 2가지다. 첫째, 장기 계약에 묶였기 때문이다. 실제로 어느 정도의 기능이 필요할지 모르는 상태로 그저 가격 우대 혜택을 받으려고 덜컥 장기 계약을 체결해 버린 것이다. 고정 요금이지만 사실상 필요 이상으로 많이 내는 셈이 되었다. 약정한 기능 중 극히 일부만 사용하게 된 경우도 있었고, 어느 정도의 저장공간과 컴퓨팅이 필요할지 과소평가하는 바람에 화들짝 놀랄 정도로...

2020.03.05

김진철의 How-to-Big Data | 빅데이터의 미래 (4)

사이버 물리 시스템과 이종 클라우드 간 상호연동성 지난 서른일곱 번째 글에서, 필자는 앞으로 우리 사회의 인프라가 사이버 물리 시스템으로 개발, 구축되면서, 사이버 물리 시스템으로 구축된 서비스와 인간과의 지능형 고급 상호작용을 위해 필요한 컴퓨팅 자원을 조달하기 위해 공간적으로 넓은 지역에 분포된 컴퓨팅 자원을 조율하고 관리할 수 있는 운영체제로서 클라우드 컴퓨팅 기술을 바라봐야 한다고 언급했었다. 사이버 물리 시스템을 위한 클라우드 컴퓨팅의 기술적인 요건으로서 멀티-클라우드 간 계층적 자원 조율 및 관리, 공용 클라우드(public cloud)와 사설 클라우드(private cloud)에 배치된 사이버 물리 시스템 서비스 간 자원 조율 및 관리를 위한 신뢰성 있는 하이브리드 클라우드 기술, 멀티-클라우드 및 다양한 이종(heterogeneous) 컴퓨팅 자원 간 기능 연동 과정에서 보안이 충분히 보장되면서 자원 활용과 관리를 분리할 수 있는 멀티테넌시(multi-tenancy) 지원 문제가 해결되어야 한다고 소개하였다. 사이버 물리 시스템의 사이버 자원 관리 및 조율을 위해 클라우드 컴퓨팅 시스템 자체가 사이버 물리 시스템화 되어가면서 인공지능 기술과 빅데이터를 활용한 지능형 제어의 개념이 들어오기 시작했다고 또 소개한 바 있다. 사이버 물리 시스템을 위한 미션-크리티컬한 클라우드 컴퓨팅 시스템이 발전해야 할 큰 방향으로 소개했던 위 네 가지 이슈 외에 최근 클라우드 컴퓨팅과 분산 컴퓨팅 기술 발전의 동향이 사이버 물리 시스템을 위한 클라우드 컴퓨팅 발전과 가지는 관련성을 이번 글에서 좀더 얘기해보고자 한다.   먼저 앞서 얘기하였던 멀티-클라우드 간, 이종 자원(heterogeneous resources) 간의 상호운용성(interoperability) 확보를 위한 표준과 인터페이스 정의 문제가 중요해지고 있다. 이런 멀티-클라우드 간, 이종 자원 간 상호연동성 문제는 그리드 컴퓨팅 기술 시절부터 논의되었던 문제이지만 아직도 분명한 해...

빅데이터 도커 마이크로소프트 애저 쿠버네티스 김진철 멀티클라우드 아웃포스트 애저스택 엑살리틱스 어플라이언스 구글 클라우드 하이브리드 클라우드 베어메탈 오픈스택 컨테이너 데이터 과학자 네티자 그린플럼 하이퍼바이저 인공지능 아마존 웹 서비스 오픈 그리드 포럼

2020.02.27

사이버 물리 시스템과 이종 클라우드 간 상호연동성 지난 서른일곱 번째 글에서, 필자는 앞으로 우리 사회의 인프라가 사이버 물리 시스템으로 개발, 구축되면서, 사이버 물리 시스템으로 구축된 서비스와 인간과의 지능형 고급 상호작용을 위해 필요한 컴퓨팅 자원을 조달하기 위해 공간적으로 넓은 지역에 분포된 컴퓨팅 자원을 조율하고 관리할 수 있는 운영체제로서 클라우드 컴퓨팅 기술을 바라봐야 한다고 언급했었다. 사이버 물리 시스템을 위한 클라우드 컴퓨팅의 기술적인 요건으로서 멀티-클라우드 간 계층적 자원 조율 및 관리, 공용 클라우드(public cloud)와 사설 클라우드(private cloud)에 배치된 사이버 물리 시스템 서비스 간 자원 조율 및 관리를 위한 신뢰성 있는 하이브리드 클라우드 기술, 멀티-클라우드 및 다양한 이종(heterogeneous) 컴퓨팅 자원 간 기능 연동 과정에서 보안이 충분히 보장되면서 자원 활용과 관리를 분리할 수 있는 멀티테넌시(multi-tenancy) 지원 문제가 해결되어야 한다고 소개하였다. 사이버 물리 시스템의 사이버 자원 관리 및 조율을 위해 클라우드 컴퓨팅 시스템 자체가 사이버 물리 시스템화 되어가면서 인공지능 기술과 빅데이터를 활용한 지능형 제어의 개념이 들어오기 시작했다고 또 소개한 바 있다. 사이버 물리 시스템을 위한 미션-크리티컬한 클라우드 컴퓨팅 시스템이 발전해야 할 큰 방향으로 소개했던 위 네 가지 이슈 외에 최근 클라우드 컴퓨팅과 분산 컴퓨팅 기술 발전의 동향이 사이버 물리 시스템을 위한 클라우드 컴퓨팅 발전과 가지는 관련성을 이번 글에서 좀더 얘기해보고자 한다.   먼저 앞서 얘기하였던 멀티-클라우드 간, 이종 자원(heterogeneous resources) 간의 상호운용성(interoperability) 확보를 위한 표준과 인터페이스 정의 문제가 중요해지고 있다. 이런 멀티-클라우드 간, 이종 자원 간 상호연동성 문제는 그리드 컴퓨팅 기술 시절부터 논의되었던 문제이지만 아직도 분명한 해...

2020.02.27

블로그ㅣ컨테이너 도입 확산의 이면··· 과연 적절한 선택일까?

컨테이너는 IT 업계를 뜨겁게 달구는 주제이다. 동시에 온갖 낯뜨거운 마케팅이 극성을 부리고 있기도 하다. 컨테이너 도입에 앞서 검토해 볼 3가지 사항이 있다. 시장조사기관 451 리서치의 ‘클라우드 지원 기술 시장 보고서(Cloud-Enabling Technologies Market Monitor report)’는 컨테이너 시장 규모가 2016년 7억 6,200만 달러에서 2020년 27억 달러로, 연간 40% 성장할 것으로 전망했다. 전체 클라우드 기술 시장의 일부에 불과한 컨테이너 시장이 2020년까지 눈부신 성장세를 기록할 것이라는 관측인 셈이다.   이러한 전망의 이면에는 한 줌의 성공 사례와 기업의 니즈가 맞물린 과대평가의 소지가 있다. 물론 과장이 있더라도 컨테이너는 클라우드 인프라에서 유효한 위치에 있다. 클라우드로 애플리케이션을 이전하거나, 클라우드에서 새로 애플리케이션을 구축할 때 직면하는 주요 문제인 이식성, 확장성, 개방성, 일관성을 컨테이너가 해결할 수 있기 때문이다.  그러나 컨테이너가 만능 해결책은 아니다. 개인적인 견해로 볼 때, 컨테이너와 컨테이너 오케스트레이션(쿠버네티스)에서 가장 큰 문제는 이 기술의 오용이다. 다음의 3가지 사항을 먼저 확인해보자.  첫째, 마이크로서비스 아키텍처가 핵심이다. 컨테이너에 코드를 삽입해 실행시킬 순 있다. 하지만 컨테이너가 효과적으로 작동하려면, 컨테이너 개념에 맞게 마이크로서비스 아키텍처가 생성돼야 한다.  컨테이너는 본질적으로 신속한 배포와 전개 그리고 확장성을 지향한다. 따라서 컨테이너를 가장 잘 이용하기 위해서는 애플리케이션을 쪼개 변경과 조합이 가능하도록 아키텍처를 만들어야 한다. 만약 애플리케이션이 데이터와 촘촘하게 결합돼 있다면, 앱에서 데이터를 분리하지 않는 한 컨테이너를 효과적으로 이용할 수 없을 것이다.  둘째, 컨테이너는 기존 애플리케이션 개발보다 비용이 더 많이 든다. 컨테이너를 이용하기 위해 기존 애플리케이션을 컨테...

클라우드 애플리케이션 컨테이너 쿠버네티스 마이크로서비스 아키텍처 컨테이너 세금 컨테이너 오케스트레이션

2020.02.26

컨테이너는 IT 업계를 뜨겁게 달구는 주제이다. 동시에 온갖 낯뜨거운 마케팅이 극성을 부리고 있기도 하다. 컨테이너 도입에 앞서 검토해 볼 3가지 사항이 있다. 시장조사기관 451 리서치의 ‘클라우드 지원 기술 시장 보고서(Cloud-Enabling Technologies Market Monitor report)’는 컨테이너 시장 규모가 2016년 7억 6,200만 달러에서 2020년 27억 달러로, 연간 40% 성장할 것으로 전망했다. 전체 클라우드 기술 시장의 일부에 불과한 컨테이너 시장이 2020년까지 눈부신 성장세를 기록할 것이라는 관측인 셈이다.   이러한 전망의 이면에는 한 줌의 성공 사례와 기업의 니즈가 맞물린 과대평가의 소지가 있다. 물론 과장이 있더라도 컨테이너는 클라우드 인프라에서 유효한 위치에 있다. 클라우드로 애플리케이션을 이전하거나, 클라우드에서 새로 애플리케이션을 구축할 때 직면하는 주요 문제인 이식성, 확장성, 개방성, 일관성을 컨테이너가 해결할 수 있기 때문이다.  그러나 컨테이너가 만능 해결책은 아니다. 개인적인 견해로 볼 때, 컨테이너와 컨테이너 오케스트레이션(쿠버네티스)에서 가장 큰 문제는 이 기술의 오용이다. 다음의 3가지 사항을 먼저 확인해보자.  첫째, 마이크로서비스 아키텍처가 핵심이다. 컨테이너에 코드를 삽입해 실행시킬 순 있다. 하지만 컨테이너가 효과적으로 작동하려면, 컨테이너 개념에 맞게 마이크로서비스 아키텍처가 생성돼야 한다.  컨테이너는 본질적으로 신속한 배포와 전개 그리고 확장성을 지향한다. 따라서 컨테이너를 가장 잘 이용하기 위해서는 애플리케이션을 쪼개 변경과 조합이 가능하도록 아키텍처를 만들어야 한다. 만약 애플리케이션이 데이터와 촘촘하게 결합돼 있다면, 앱에서 데이터를 분리하지 않는 한 컨테이너를 효과적으로 이용할 수 없을 것이다.  둘째, 컨테이너는 기존 애플리케이션 개발보다 비용이 더 많이 든다. 컨테이너를 이용하기 위해 기존 애플리케이션을 컨테...

2020.02.26

AWS·애저·GCP 실제 사용자가 말하는 '퍼블릭 클라우드 성공 전략'

퍼블릭 클라우드는 IT에서 주류가 됐으며 선도적인 기업은 이를 디지털 혁신을 위한 전략적 도구로 활용하고 있다. 퍼블릭 클라우드 서비스로 마이그레이션해 비즈니스 민첩성과 혁신을 추진 중인 IT임원의 조언을 정리했다.    퍼블릭 클라우드 서비스는 CIO에게 일종의 전략적 무기다. 데이터센터를 폐쇄하고 컴퓨팅 리소스를 아웃소싱하는 방법을 넘어서 퍼블릭 클라우드는 CIO에게 수익 향상을 목표로 하는 전략적 프로젝트에 집중할 수 있는 능력을 제공한다.  이 때문에 퍼블릭 클라우드는 새로운 고객 경험을 제공하는 모바일 소프트웨어와 통찰력을 창출하는 머신러닝 시스템 등 기존 비즈니스 애플리케이션을 현대화하고 새로운 디지털 제품을 구축하는 고투(go-to) 플랫폼이 되었다.  가트너에 따르면, 대부분 기업이 ‘클라우드 우선’ 전략을 선언함에 따라, IaaS에 대한 지출은 2019년의 400억 달러에서 2020년에는 500억 달러에 이를 것이며, 2022년에는 연간 24% 성장하여 740억 달러를 넘어설 것이라고 한다. 가트너의 애널리스트인 시드 나그는 ‘클라우드 채택이 주류’라고 말했다.  IT 리더들은 <CIO닷컴>과 퍼블릭 클라우드로의 전략적 전환을 통해 얻은 경험과 교훈을 공유했다. 클라우드에서 성장 여력 찾기  2014년부터 초이스 호텔 인터내셔널은 초이스엣지의 핵심 글로벌 예약 시스템과 유통 플랫폼, 부동산 관리 시스템, 데이터 분석 시스템 등 1,000개 이상의 애플리케이션을 전 세계 6,900개 이상의 호텔에서 사용할 수 있도록 아마존웹서비스(AWS)로 옮겼다. 초이스의 엔지니어링 부사장인 크리스 저드슨은 <CIO닷컴>에 “초이스는 구형 애플리케이션을 현대화하고 AWS를 기반으로 클라우드 네이티브 앱을 구축하고 있다”라고 말했다. 또한 초이스는 AWS의 머신러닝(ML)툴을 활용하여 고객 개인화 및 사기 탐지 등의 이니셔티브를 지원하고 초과예약된 객실 재고를 줄이고 있다. ...

CIO 마이크로소프 애저 스노우플레이크 멀티 클라우드 구글 클라우드 플랫폼 GCP 마이크로서비스 쿠버네티스 디지털 혁신 아마존웹서비스 디지털 변혁 분석 퍼블릭 클라우드 컨테이너 IaaS AWS 가트너 애플리케이션 현대화

2020.02.10

퍼블릭 클라우드는 IT에서 주류가 됐으며 선도적인 기업은 이를 디지털 혁신을 위한 전략적 도구로 활용하고 있다. 퍼블릭 클라우드 서비스로 마이그레이션해 비즈니스 민첩성과 혁신을 추진 중인 IT임원의 조언을 정리했다.    퍼블릭 클라우드 서비스는 CIO에게 일종의 전략적 무기다. 데이터센터를 폐쇄하고 컴퓨팅 리소스를 아웃소싱하는 방법을 넘어서 퍼블릭 클라우드는 CIO에게 수익 향상을 목표로 하는 전략적 프로젝트에 집중할 수 있는 능력을 제공한다.  이 때문에 퍼블릭 클라우드는 새로운 고객 경험을 제공하는 모바일 소프트웨어와 통찰력을 창출하는 머신러닝 시스템 등 기존 비즈니스 애플리케이션을 현대화하고 새로운 디지털 제품을 구축하는 고투(go-to) 플랫폼이 되었다.  가트너에 따르면, 대부분 기업이 ‘클라우드 우선’ 전략을 선언함에 따라, IaaS에 대한 지출은 2019년의 400억 달러에서 2020년에는 500억 달러에 이를 것이며, 2022년에는 연간 24% 성장하여 740억 달러를 넘어설 것이라고 한다. 가트너의 애널리스트인 시드 나그는 ‘클라우드 채택이 주류’라고 말했다.  IT 리더들은 <CIO닷컴>과 퍼블릭 클라우드로의 전략적 전환을 통해 얻은 경험과 교훈을 공유했다. 클라우드에서 성장 여력 찾기  2014년부터 초이스 호텔 인터내셔널은 초이스엣지의 핵심 글로벌 예약 시스템과 유통 플랫폼, 부동산 관리 시스템, 데이터 분석 시스템 등 1,000개 이상의 애플리케이션을 전 세계 6,900개 이상의 호텔에서 사용할 수 있도록 아마존웹서비스(AWS)로 옮겼다. 초이스의 엔지니어링 부사장인 크리스 저드슨은 <CIO닷컴>에 “초이스는 구형 애플리케이션을 현대화하고 AWS를 기반으로 클라우드 네이티브 앱을 구축하고 있다”라고 말했다. 또한 초이스는 AWS의 머신러닝(ML)툴을 활용하여 고객 개인화 및 사기 탐지 등의 이니셔티브를 지원하고 초과예약된 객실 재고를 줄이고 있다. ...

2020.02.10

HPE, 사이버보안 업체 인수··· 서비스 인증 솔루션 강화

HPE가 사이버보안 스타트업 스키테일을 인수했다. 인수 금액은 공개되지 않았다. 스키테일은 클라우드 네이티브 보안과 제로 트러스트 네트워크에 특화된 업체다. HPE는 이번 인수를 통해 서비스 인증 솔루션을 강화할 수 있을 것으로 기대하고 있다.  HPE는 공식 블로그를 통해 이번 인수를 발표하면서 "동적이고, 개방적이며, 안전한 엣지-투-클라우드 플랫폼을 제공하려는 자사의 계획을 구현하는 데 스키테일 인수가 큰 도움이 될 것"이라고 밝혔다.   아마존 웹 서비스, 듀오 시큐리티, 구글, 옥타, 페이저듀티, 스플렁크 등 여러 클라우드 네이티브 엔터프라이즈 출신의 엔지니어들이 모여 2017년 창업한 스키테일은 클라우드, 컨테이너, 온프레미스 인프라 전반에 걸친 서비스 인증을 제공한다.  또한 스키테일은 클라우드 네이티브 컴퓨팅 재단(CNCF)의 오픈소스 프로젝트인 SPIFFE(Secure Production Identity Framework for Everyone)와 SPIRE(SPIFFE Runtime Environment)의 설립 시점부터 멤버로 참여해 해당 프로젝트의 활성화를 이끌었다고 평가받고 있다. HPE는 이와 관련해 “스키테일이 SPIFFE와 SPIRE에 계속해서 기여하도록 최선을 다할 것”이라고 말했다. HPE의 클라우드 이니셔티브 부문 최고책임자인 데이브 휴삭은 "오늘날 디지털 트랜스포메이션은 초연결되고 점점 더 분산되는 세상에서 무수한 가능성을 만들어내고 있다"라고 공식 블로그를 통해 언급했다. 이어서 그는 “끊김 없는 엣지-투-클라우드 아키텍처와 사용자 경험이 요구된다. 이는 또한 자율적이면서도 개방적이고 안전해야 한다. 그러나 기존의 보안 모델은 엣지부터 클라우드까지 확장되고 있는 에코시스템에 맞게 확장되거나 발전되지 못했다”라고 설명했다.   HPE에 따르면 이번 인수 이후 스키테일의 창업자인 선일 제임스, 에밀리아노 베렌바움, 앤드류 제섭을 포함한 스키테일 팀이 HPE에 합류한다. ...

클라우드 클라우드네이티브보안 온프레미스인프라 엣지투클라우드 듀오시큐리티 블루데이터 디지털트랜스포메이션 옥타 HPE 쿠버네티스 아마존웹서비스 제로트러스트 맵알 스플렁크 사이버보안 컨테이너 AWS 구글 페이저듀치

2020.02.06

HPE가 사이버보안 스타트업 스키테일을 인수했다. 인수 금액은 공개되지 않았다. 스키테일은 클라우드 네이티브 보안과 제로 트러스트 네트워크에 특화된 업체다. HPE는 이번 인수를 통해 서비스 인증 솔루션을 강화할 수 있을 것으로 기대하고 있다.  HPE는 공식 블로그를 통해 이번 인수를 발표하면서 "동적이고, 개방적이며, 안전한 엣지-투-클라우드 플랫폼을 제공하려는 자사의 계획을 구현하는 데 스키테일 인수가 큰 도움이 될 것"이라고 밝혔다.   아마존 웹 서비스, 듀오 시큐리티, 구글, 옥타, 페이저듀티, 스플렁크 등 여러 클라우드 네이티브 엔터프라이즈 출신의 엔지니어들이 모여 2017년 창업한 스키테일은 클라우드, 컨테이너, 온프레미스 인프라 전반에 걸친 서비스 인증을 제공한다.  또한 스키테일은 클라우드 네이티브 컴퓨팅 재단(CNCF)의 오픈소스 프로젝트인 SPIFFE(Secure Production Identity Framework for Everyone)와 SPIRE(SPIFFE Runtime Environment)의 설립 시점부터 멤버로 참여해 해당 프로젝트의 활성화를 이끌었다고 평가받고 있다. HPE는 이와 관련해 “스키테일이 SPIFFE와 SPIRE에 계속해서 기여하도록 최선을 다할 것”이라고 말했다. HPE의 클라우드 이니셔티브 부문 최고책임자인 데이브 휴삭은 "오늘날 디지털 트랜스포메이션은 초연결되고 점점 더 분산되는 세상에서 무수한 가능성을 만들어내고 있다"라고 공식 블로그를 통해 언급했다. 이어서 그는 “끊김 없는 엣지-투-클라우드 아키텍처와 사용자 경험이 요구된다. 이는 또한 자율적이면서도 개방적이고 안전해야 한다. 그러나 기존의 보안 모델은 엣지부터 클라우드까지 확장되고 있는 에코시스템에 맞게 확장되거나 발전되지 못했다”라고 설명했다.   HPE에 따르면 이번 인수 이후 스키테일의 창업자인 선일 제임스, 에밀리아노 베렌바움, 앤드류 제섭을 포함한 스키테일 팀이 HPE에 합류한다. ...

2020.02.06

기고 | 거버넌스·플랫폼으로 본 주요 AI 동향

인공지능(AI)은 가장 전략적인 기업 기술이다. 2020년 들어 가장 파괴적인 비즈니스 애플리케이션은 머신러닝, 딥러닝 등 여러 형태의 AI를 활용하는 것들이 차지할 전망이다.   AI는 두뇌를 움직이는 클라우드 네이티브 기업 애플리케이션으로 자리 잡았다. 다양한 분야의 개발자들은 클라우드 애플리케이션에 데이터 주도 머신러닝 지능을 불어넣기 위해 AI 마이크로서비스를 포함하고 있다. 각종 센서에서 수집한 데이터는 물론 여러 애플리케이션과 클라우드, 허브 게이트웨이를 비롯한 온라인 자원에서 획득한 데이터를 대상으로 고속 추론을 수행하는 정교한 AI는 갈수록 대체 불가한 존재가 되어가고 있다. 데이터 과학자나 머신러닝 전문가가 아니더라도 AI 동향과 기술 및 애플리케이션을 잘 알아두는 것은 현대 사업에서 성공의 기본이다. AI를 이용해 혁신하는 회사들이 향후 수십 년간 해당 업계의 지배자가 될 것이다. 최고의 기업 AI 역량 구축 그동안 AI 업계가 얼마나 보편화되고 역동적으로 변했는지 고려하면, 기업 AI 전문기술을 일정 수준으로 유지하는 것이 어려울 수 있다. 다른 건 몰라도 반드시 해야 할 일은 AI 기술력, 프로세스, 도구, 플랫폼, 방법론을 아우르면서 다음과 같은 주요 사항이 포함된 광범위한 프로그램을 실행하는 것이다. • 팀: AI 애플리케이션을 조직 전체에 표준화한 운영 절차로 구축하고 훈련, 배치, 관리하기 위해 데이터 과학자 등 개발자로 구성된 전담팀을 만든다.  • 플랫폼: 멀티클라우드 환경에서 애플리케이션 구축, 데이터 공학, 머신러닝, 데이터 과학을 위해 신뢰할 수 있고 통합된 개방형 플랫폼을 배치한다. • 데이터: 머신러닝, 딥러닝 등 AI 모델을 구축하고 훈련, 배치, 관리할 때 온프레미스 플랫폼과 퍼블릭 클라우드에서 온 혼합 데이터를 결합한다.  • 워크로드: 수많은 AI 워크로드를 위해 정지 중인 데이터와 이동 중인 데이터를 둘 다 관리할 수 있도록 빠르고 확장 가능한 혼합 데이터 환경을 배치한다. ...

Saas 컨테이너 엔비디아 인공지능 GPU 쿠버네티스 마이크로서비스 강화학습 퓨처럼리서치

2020.02.03

인공지능(AI)은 가장 전략적인 기업 기술이다. 2020년 들어 가장 파괴적인 비즈니스 애플리케이션은 머신러닝, 딥러닝 등 여러 형태의 AI를 활용하는 것들이 차지할 전망이다.   AI는 두뇌를 움직이는 클라우드 네이티브 기업 애플리케이션으로 자리 잡았다. 다양한 분야의 개발자들은 클라우드 애플리케이션에 데이터 주도 머신러닝 지능을 불어넣기 위해 AI 마이크로서비스를 포함하고 있다. 각종 센서에서 수집한 데이터는 물론 여러 애플리케이션과 클라우드, 허브 게이트웨이를 비롯한 온라인 자원에서 획득한 데이터를 대상으로 고속 추론을 수행하는 정교한 AI는 갈수록 대체 불가한 존재가 되어가고 있다. 데이터 과학자나 머신러닝 전문가가 아니더라도 AI 동향과 기술 및 애플리케이션을 잘 알아두는 것은 현대 사업에서 성공의 기본이다. AI를 이용해 혁신하는 회사들이 향후 수십 년간 해당 업계의 지배자가 될 것이다. 최고의 기업 AI 역량 구축 그동안 AI 업계가 얼마나 보편화되고 역동적으로 변했는지 고려하면, 기업 AI 전문기술을 일정 수준으로 유지하는 것이 어려울 수 있다. 다른 건 몰라도 반드시 해야 할 일은 AI 기술력, 프로세스, 도구, 플랫폼, 방법론을 아우르면서 다음과 같은 주요 사항이 포함된 광범위한 프로그램을 실행하는 것이다. • 팀: AI 애플리케이션을 조직 전체에 표준화한 운영 절차로 구축하고 훈련, 배치, 관리하기 위해 데이터 과학자 등 개발자로 구성된 전담팀을 만든다.  • 플랫폼: 멀티클라우드 환경에서 애플리케이션 구축, 데이터 공학, 머신러닝, 데이터 과학을 위해 신뢰할 수 있고 통합된 개방형 플랫폼을 배치한다. • 데이터: 머신러닝, 딥러닝 등 AI 모델을 구축하고 훈련, 배치, 관리할 때 온프레미스 플랫폼과 퍼블릭 클라우드에서 온 혼합 데이터를 결합한다.  • 워크로드: 수많은 AI 워크로드를 위해 정지 중인 데이터와 이동 중인 데이터를 둘 다 관리할 수 있도록 빠르고 확장 가능한 혼합 데이터 환경을 배치한다. ...

2020.02.03

마이크로소프트, '애저'에서 윈도우 서버 2008의 보안 업데이트

마이크로소프트가 자사 클라우드인 애저를 통해서만 윈도우 서버 2008의 보안 업데이트를 확장한다.   1월 14일에 윈도우 서버 2008 지원이 종료됐다. 고객의 윈도우 서버 2008을 전환 중인 마이크로소프트 협력업체는 애저로 이전하면 3년 동안 보안 업데이트를 제공할 수 있다. 1월 14일에 윈도우 7, 윈도우 서버 2008, 윈도우 서버 2008 R2 지원을 종료한 마이크로소프트는 ‘즉각적이고 실질적인’ 이점을 제공하겠다며 블로그 게시글에서 밝혔으며, 현재 클라우드 서비스를 대거 연결하고 있다. 윈도우 서버를 전환하는 동안 ‘시간이 오래 걸리는’ 보안 업데이트 프로세스를 최소화하는 방법으로 마이크로소프트는 추가 비용 없이 3년의 연장된 보안 업데이트를 제공할 뿐 아니라 애저 버추얼머신을 통해서만 추가할 수 있도록 했다. 자세한 내용은 비즈니스 크리티컬 앱 및 서비스의 전환 경로를 참고하면 된다.  윈도우 서버 및 애저 제품 마케팅 이사인 비자이 쿠마는 “윈도우 서버 2008에 대한 지원은 오늘 끝났지만 마이크로소프트는 클라우드 컴퓨팅, 하이브리드 클라우드, 서버 워크로드가 새로운 시대에 대비할 수 있도록 돕는 데이터의 새로운 혁신을 맞이해 기대된다”라고 말했다.   이어서 쿠마는 "최신 기술 혁신을 적용하여 서버 워크로드를 현대화하면서 이러한 전환을 통해 고객을 지원하기 위해 협력하고 싶다"라고 덧붙였다.  윈도우 서버 워크로드를 애저로 전환하기 시작한 협력사는 클라우드 서비스 자체 가상머신, 애저 VM웨어 솔루션, 애저 전용 호스트를 사용하는 것이 좋다. 마이크로소프트의 할인 프로그램인 애저 하이브리드 혜택은 애저의 윈도우 서버 라이선스를 보유한 협력사와 고객사에 적용될 수 있다 한편, 워크로드를 클라우드로 마이그레이션할 수 없는 사용자는 대신 애저와 통합할 수 있는 하이브리드 기능과 윈도우 컨테이너에 대한 쿠버네티스 지원을 제공하는 마이크로소프트의 윈도우 서버 2019로 이전하는 것이 좋다. 쿠마...

마이크로소프트 윈도우 서버 2008 R2 애저 버추얼머신 현대화 쿠버네티스 보안 업데이트 윈도우 서버 2008 윈도우 7 백업 컨테이너 윈도우 애저 클라우드로 마이그레이션

2020.01.16

마이크로소프트가 자사 클라우드인 애저를 통해서만 윈도우 서버 2008의 보안 업데이트를 확장한다.   1월 14일에 윈도우 서버 2008 지원이 종료됐다. 고객의 윈도우 서버 2008을 전환 중인 마이크로소프트 협력업체는 애저로 이전하면 3년 동안 보안 업데이트를 제공할 수 있다. 1월 14일에 윈도우 7, 윈도우 서버 2008, 윈도우 서버 2008 R2 지원을 종료한 마이크로소프트는 ‘즉각적이고 실질적인’ 이점을 제공하겠다며 블로그 게시글에서 밝혔으며, 현재 클라우드 서비스를 대거 연결하고 있다. 윈도우 서버를 전환하는 동안 ‘시간이 오래 걸리는’ 보안 업데이트 프로세스를 최소화하는 방법으로 마이크로소프트는 추가 비용 없이 3년의 연장된 보안 업데이트를 제공할 뿐 아니라 애저 버추얼머신을 통해서만 추가할 수 있도록 했다. 자세한 내용은 비즈니스 크리티컬 앱 및 서비스의 전환 경로를 참고하면 된다.  윈도우 서버 및 애저 제품 마케팅 이사인 비자이 쿠마는 “윈도우 서버 2008에 대한 지원은 오늘 끝났지만 마이크로소프트는 클라우드 컴퓨팅, 하이브리드 클라우드, 서버 워크로드가 새로운 시대에 대비할 수 있도록 돕는 데이터의 새로운 혁신을 맞이해 기대된다”라고 말했다.   이어서 쿠마는 "최신 기술 혁신을 적용하여 서버 워크로드를 현대화하면서 이러한 전환을 통해 고객을 지원하기 위해 협력하고 싶다"라고 덧붙였다.  윈도우 서버 워크로드를 애저로 전환하기 시작한 협력사는 클라우드 서비스 자체 가상머신, 애저 VM웨어 솔루션, 애저 전용 호스트를 사용하는 것이 좋다. 마이크로소프트의 할인 프로그램인 애저 하이브리드 혜택은 애저의 윈도우 서버 라이선스를 보유한 협력사와 고객사에 적용될 수 있다 한편, 워크로드를 클라우드로 마이그레이션할 수 없는 사용자는 대신 애저와 통합할 수 있는 하이브리드 기능과 윈도우 컨테이너에 대한 쿠버네티스 지원을 제공하는 마이크로소프트의 윈도우 서버 2019로 이전하는 것이 좋다. 쿠마...

2020.01.16

'빅 3 패권 바뀔까'··· 2020년 클라우드 전망

클라우드의 지배력이 점점 더 막강해지면서 빅 3 클라우드 업체는 새로운 기술을 활용하고자 인재와 노하우 확보에 박차를 가하고 있다. 클라우드 생태계는 광범위하고 복잡하지만 새로운 공통적인 트렌드가 등장했으며 그 중 상당수는 향후 10년 동안 해당 산업에 지속해서 중요한 영향을 끼칠 것으로 예상된다.   포레스터의 부사장 겸 수석 분석가 데이브 바톨레티는 자신의 연례 클라우드 전망에서 클라우드 시장 전체(SaaS, PaaS, IaaS)가 2020년에 미화 2,994억 달러 규모까지 성장하리라 예측한 방법에 관해 간략히 설명했다. 클라우드 시장 성장을 견인할 주요 동인과 앞으로 클라우드 부문에서 고려해야 할 사항을 살펴보자. 곧 들이닥칠 또다른 클라우드 패권? 퍼블릭 클라우드 시장은 오랫동안 빅 3의 경쟁 구도로 비쳤으며 적어도 북미에서는 아마존웹서비스(AWS)의 지배력이 약화되거나 제4의 업체가 등장할 기미는 보이지 않는다. 각 업체가 수치를 다르게 제시하기 때문에 퍼블릭 클라우드 시장에 대한 실질적인 수치를 파악하기는 어렵지만 시너지 리서치(Synergy Research)는 AWS가 약 40%의 시장 점유율로 확실한 시장 리더이며 마이크로소프트 애저와 구글 클라우드가 30%와 10%로 그 뒤를 따르고 있는 것으로 추정했다. 현재 디 인포메이션(The Information)의 보고서에 따르면 구글 클라우드는 현재 모기업인 알파벳(Alphabet)이 확보한 투자 수준을 계속해서 받게 되면 최소한 경쟁자 중 한 곳을 따라잡는 것은 시간문제다. 구글의 대변인은 <컴퓨터월드UK>에 “2018년부터 등장한 이런 대화에 대한 보고서는 정확하지 않다”라고 일축했다. 보고서가 과장되었거나 목적이 단순히 새로운 CEO 토마스 쿠리안이 경쟁사들과 싸우도록 하는 것일지라도 구글 클라우드는 한동안 3위에 머물렀으며 이전 CEO 다이앤 그린의 관리하에서는 그 공백이 줄어들 기미가 보이지 않았다. 지난해 세간의 이목을 끈 여러 차례의...

구글 구글 클라우드 마이크로소프트 애저 아마존웹서비스 쿠버네티스 2020년 시너지 리서치 멀티클라우드 토마스 쿠리안 CFF 하이브리드 클라우드 피보탈 인공지능 M&A 전망 IBM AWS 포레스터 레드햇 VM웨어 컨테이너 알리바바 Cloud Foundry Foundation

2020.01.08

클라우드의 지배력이 점점 더 막강해지면서 빅 3 클라우드 업체는 새로운 기술을 활용하고자 인재와 노하우 확보에 박차를 가하고 있다. 클라우드 생태계는 광범위하고 복잡하지만 새로운 공통적인 트렌드가 등장했으며 그 중 상당수는 향후 10년 동안 해당 산업에 지속해서 중요한 영향을 끼칠 것으로 예상된다.   포레스터의 부사장 겸 수석 분석가 데이브 바톨레티는 자신의 연례 클라우드 전망에서 클라우드 시장 전체(SaaS, PaaS, IaaS)가 2020년에 미화 2,994억 달러 규모까지 성장하리라 예측한 방법에 관해 간략히 설명했다. 클라우드 시장 성장을 견인할 주요 동인과 앞으로 클라우드 부문에서 고려해야 할 사항을 살펴보자. 곧 들이닥칠 또다른 클라우드 패권? 퍼블릭 클라우드 시장은 오랫동안 빅 3의 경쟁 구도로 비쳤으며 적어도 북미에서는 아마존웹서비스(AWS)의 지배력이 약화되거나 제4의 업체가 등장할 기미는 보이지 않는다. 각 업체가 수치를 다르게 제시하기 때문에 퍼블릭 클라우드 시장에 대한 실질적인 수치를 파악하기는 어렵지만 시너지 리서치(Synergy Research)는 AWS가 약 40%의 시장 점유율로 확실한 시장 리더이며 마이크로소프트 애저와 구글 클라우드가 30%와 10%로 그 뒤를 따르고 있는 것으로 추정했다. 현재 디 인포메이션(The Information)의 보고서에 따르면 구글 클라우드는 현재 모기업인 알파벳(Alphabet)이 확보한 투자 수준을 계속해서 받게 되면 최소한 경쟁자 중 한 곳을 따라잡는 것은 시간문제다. 구글의 대변인은 <컴퓨터월드UK>에 “2018년부터 등장한 이런 대화에 대한 보고서는 정확하지 않다”라고 일축했다. 보고서가 과장되었거나 목적이 단순히 새로운 CEO 토마스 쿠리안이 경쟁사들과 싸우도록 하는 것일지라도 구글 클라우드는 한동안 3위에 머물렀으며 이전 CEO 다이앤 그린의 관리하에서는 그 공백이 줄어들 기미가 보이지 않았다. 지난해 세간의 이목을 끈 여러 차례의...

2020.01.08

기고 | 컨테이너화된 애플리케이션을 위한 효과적인 백업의 조건

점점 더 많은 기업이 애플리케이션의 컨테이너화를 받아들이면서 효과적인 백업 시스템의 필요성이 중요해졌다. 컨테이너는 다른 배치 모델과는 차별화되는 독보적인 특성을 가지고 있기 때문에 올바른 백업 아키텍처를 적용하지 않으면, 심각한 시스템 정지와 데이터 손실의 위험에 처할 수 있다.   IDC는 76%의 기업이 미션 크리티컬 애플리케이션에 폭넓게 컨테이너 기술을 사용하고 있으며, 개선된 보안과 운영 관리가 이런 변화의 핵심 동력이라고 밝혔다. 포트웍스의 자체 설문조사에서도 87%의 기업이 컨테이너를 사용하고, 이 중 90%가 프로덕션 환경에 컨테이너를 사용한다고 답했다. 오늘날 백업은 흔히 가상머신 수준에서 구현된다. 이 방식은 애플리케이션이 단일 가상머신에서 구동될 때는 좋다. 하지만 컨테이너화된 애플리케이션은 흔히 여러 대의 가상머신에 분산되어 있다. 반대로 단일 가상머신은 종종 여러 가지 서로 다른 애플리케이션과 관련된 컨테이너 팟을 구동한다. 이런 환경에서 현재의 가상머신 수준보다는 좀 더 정확하게 대상을 지정해야 할 필요가 있다. 간단히 말해 기업은 쿠버네티스로 구현된 자동화되고 고도로 분산된 애플리케이션 모델을 지원하는 백업 아키텍처가 필요하다. 이를 염두에 두고 컨테이너화된 애플리케이션을 위한 효과적인 백업 솔루션을 구축하는 4가지 핵심 조건을 살펴본다.   1. 컨테이너 단위의 세밀한 접근 가상머신이나 베어메탈 서버에서 구동되는 모든 것을 백업하는 것이 아니라 특정 컨테이너나 특정 노드에서 구동하는 컨테이너 그룹을 백업할 수 있는 기능이 필요하다. 이는 백업해야 하는 애플리케이션만을 선택할 수 있는 기능을 의미하는데, 같은 노드에 다른 애플리케이션이 있거나 애플리케이션이 여러 노드에 분산되어 있어도 가려낼 수 있어야 한다. 컨테이너 수준에서 백업을 하면, IT 부서는 까다로운 ETL 프로시저를 피할 수 있다. 특정 애플리케이션만을 백업하는 것은 또한 스토리지 비용을 최소화하고 RTO도 낮게 유지할 수 있다.  &...

컨테이너 백업 복구 쿠버네티스 RTO

2019.12.23

점점 더 많은 기업이 애플리케이션의 컨테이너화를 받아들이면서 효과적인 백업 시스템의 필요성이 중요해졌다. 컨테이너는 다른 배치 모델과는 차별화되는 독보적인 특성을 가지고 있기 때문에 올바른 백업 아키텍처를 적용하지 않으면, 심각한 시스템 정지와 데이터 손실의 위험에 처할 수 있다.   IDC는 76%의 기업이 미션 크리티컬 애플리케이션에 폭넓게 컨테이너 기술을 사용하고 있으며, 개선된 보안과 운영 관리가 이런 변화의 핵심 동력이라고 밝혔다. 포트웍스의 자체 설문조사에서도 87%의 기업이 컨테이너를 사용하고, 이 중 90%가 프로덕션 환경에 컨테이너를 사용한다고 답했다. 오늘날 백업은 흔히 가상머신 수준에서 구현된다. 이 방식은 애플리케이션이 단일 가상머신에서 구동될 때는 좋다. 하지만 컨테이너화된 애플리케이션은 흔히 여러 대의 가상머신에 분산되어 있다. 반대로 단일 가상머신은 종종 여러 가지 서로 다른 애플리케이션과 관련된 컨테이너 팟을 구동한다. 이런 환경에서 현재의 가상머신 수준보다는 좀 더 정확하게 대상을 지정해야 할 필요가 있다. 간단히 말해 기업은 쿠버네티스로 구현된 자동화되고 고도로 분산된 애플리케이션 모델을 지원하는 백업 아키텍처가 필요하다. 이를 염두에 두고 컨테이너화된 애플리케이션을 위한 효과적인 백업 솔루션을 구축하는 4가지 핵심 조건을 살펴본다.   1. 컨테이너 단위의 세밀한 접근 가상머신이나 베어메탈 서버에서 구동되는 모든 것을 백업하는 것이 아니라 특정 컨테이너나 특정 노드에서 구동하는 컨테이너 그룹을 백업할 수 있는 기능이 필요하다. 이는 백업해야 하는 애플리케이션만을 선택할 수 있는 기능을 의미하는데, 같은 노드에 다른 애플리케이션이 있거나 애플리케이션이 여러 노드에 분산되어 있어도 가려낼 수 있어야 한다. 컨테이너 수준에서 백업을 하면, IT 부서는 까다로운 ETL 프로시저를 피할 수 있다. 특정 애플리케이션만을 백업하는 것은 또한 스토리지 비용을 최소화하고 RTO도 낮게 유지할 수 있다.  &...

2019.12.23

클라우드 마이그레이션 '5가지 성공 요인 vs. 5가지 실패 원인'

클라우드 마이그레이션은 애플리케이션, IT, 비즈니스에 도움이 된다. 클라우드 마이그레이션을 진행할 때 실패로 가는 함정을 피하고 성공으로 가는 방법을 소개한다.  대부분 기업에서 클라우드로의 마이그레이션은 ‘(할지)여부’가 아닌 ‘시기’의 문제다. 클라우드로 애플리케이션을 옮겨 보안과 데이터 접근, 확장성, IT 유연성을 향상할 수 있다. 또 기타 많은 혜택을 누릴 수 있다. 예를 들어, 클라우드로 옮기면 돈을 절약할 수 있다. 하지만 미리 경계해야 할 점들이 있다. 클라우드 배포가 항상 원활한 것만은 아니다. 마이그레이션에 예상보다 많은 시간이 소요되는 경우가 있다. 또 완전히 실패해 시간과 돈을 낭비할 수도 있다. 클라우드로 옮긴 앱이 온프레미스처럼 잘 작동하지 않는 경우도 있다. 이로 인해 데이터센터로 다시 마이그레이션하게 된다. 공급망 전문업체인 IHS마킷(Markit)이 보안 업체인 포티넷(Fortinet)의 후원을 받아 최근 했던 조사 결과에 따르면, 조사 대상 기업 중 예상했던 혜택을 실현하지 못해 클라우드 기반 앱을 온프레미스로 다시 옮겼다고 대답한 비율이 74%에 달했다. 이는 새로운 문제가 아니다. 구글에서 클라우드 마이그레이션 실패를 검색하면 몇 년 전으로 거슬러 올라가는 사례들을 찾을 수 있다. 이 문제는 상당히 오래전부터 거론됐다. 또한 이 문제는 ‘기술의 실패’가 아닌 ‘리더십의 실패’와 관련된 문제다.   클라우드 마이그레이션 실패 원인 5가지, 마이그레이션 성공 요인 5가지를 각각 소개한다. 클라우드 마이그레이션 실패 원인 1: 좋은 협력사 없이 마이그레이션 시도 처음 시도하는 경우를 중심으로, 단독으로 마이그레이션할 수 없음을 인지해야 한다. 액센츄어 같은 글로벌 컨설팅 회사든, 지역 컨설팅 회사든 파트너가 필요하다. 심사숙고하고, 외부 조언과 피드백을 참조해 파트너를 결정해야 한다. 적합한 컨설턴트를 선택하도록 도움을 줄 수 있는 업계 동료나, 지역의 네트워크를 구축하는 것이 좋다. 엔터...

구글 컨테이너 온프레미스 포티넷 스플렁크 도커 클라우드 마이그레이션 쿠버네티스 마이크로서비스

2019.12.04

클라우드 마이그레이션은 애플리케이션, IT, 비즈니스에 도움이 된다. 클라우드 마이그레이션을 진행할 때 실패로 가는 함정을 피하고 성공으로 가는 방법을 소개한다.  대부분 기업에서 클라우드로의 마이그레이션은 ‘(할지)여부’가 아닌 ‘시기’의 문제다. 클라우드로 애플리케이션을 옮겨 보안과 데이터 접근, 확장성, IT 유연성을 향상할 수 있다. 또 기타 많은 혜택을 누릴 수 있다. 예를 들어, 클라우드로 옮기면 돈을 절약할 수 있다. 하지만 미리 경계해야 할 점들이 있다. 클라우드 배포가 항상 원활한 것만은 아니다. 마이그레이션에 예상보다 많은 시간이 소요되는 경우가 있다. 또 완전히 실패해 시간과 돈을 낭비할 수도 있다. 클라우드로 옮긴 앱이 온프레미스처럼 잘 작동하지 않는 경우도 있다. 이로 인해 데이터센터로 다시 마이그레이션하게 된다. 공급망 전문업체인 IHS마킷(Markit)이 보안 업체인 포티넷(Fortinet)의 후원을 받아 최근 했던 조사 결과에 따르면, 조사 대상 기업 중 예상했던 혜택을 실현하지 못해 클라우드 기반 앱을 온프레미스로 다시 옮겼다고 대답한 비율이 74%에 달했다. 이는 새로운 문제가 아니다. 구글에서 클라우드 마이그레이션 실패를 검색하면 몇 년 전으로 거슬러 올라가는 사례들을 찾을 수 있다. 이 문제는 상당히 오래전부터 거론됐다. 또한 이 문제는 ‘기술의 실패’가 아닌 ‘리더십의 실패’와 관련된 문제다.   클라우드 마이그레이션 실패 원인 5가지, 마이그레이션 성공 요인 5가지를 각각 소개한다. 클라우드 마이그레이션 실패 원인 1: 좋은 협력사 없이 마이그레이션 시도 처음 시도하는 경우를 중심으로, 단독으로 마이그레이션할 수 없음을 인지해야 한다. 액센츄어 같은 글로벌 컨설팅 회사든, 지역 컨설팅 회사든 파트너가 필요하다. 심사숙고하고, 외부 조언과 피드백을 참조해 파트너를 결정해야 한다. 적합한 컨설턴트를 선택하도록 도움을 줄 수 있는 업계 동료나, 지역의 네트워크를 구축하는 것이 좋다. 엔터...

2019.12.04

현실 속 쿠버네티스 살펴보기··· 블룸버그, 뉴스 UK, 아마데우스 사례

쿠버네티스(Kubernetes)는 5년 전 구글이 발표한 이후 빠른 속도로 2010년대의 가장 인기 있는 기술 중 하나로 부상했다. 현재 쿠버네티스는 마이크로서비스(컨테이너에서 실행되며, 여러 컨테이너가 모여 다양한 유형의 인프라에 이식할 수 있는 더 큰 큰 애플리케이션 역할을 할 수 있는, 독립적으로 배포 가능한 작은 서비스)로 구성된 애플리케이션을 제작하고 실행하는 데 있어 이론의 여지가 없는 선두 플랫폼이다.   쿠버네티스는 오케스트레이션 툴이다. 즉, 개발자가 탄력적인 분산 시스템 운영을 목표로 컨테이너 기반의 워크로드와 서비스를 조율하고 관리할 수 있게 해준다. 클라우드 네이티브 컴퓨팅 재단(CNCF)이 2018년 8월에 발표한 설문 조사에서 기업(5,000개 이상) 응답자 중 40%는 이미 프로덕션에서 쿠버네티스를 운용 중이다. 상당한 진척이지만, 중요한 점은 이러한 조직의 대다수가 극소수 애플리케이션만 쿠버네티스로 실행하면서 가능성을 탐색 중이라는 사실이다. 그러나 방향은 확실하다. 미래는 컨테이너 기반 마이크로서비스 애플리케이션을 향하고 있으며, 쿠버네티스는 그 중심의 플랫폼이다. 이것이 3대 클라우드 업체가 모두 쿠버네티스의 매니지드 버전을 출시하고 시스코, HPE, IBM/레드햇, 마이크로소프트, VM웨어/피보탈을 비롯한 여타 업체가 쿠버네티스를 각자의 핵심 소프트웨어 제품군에 수용한 이유다. 쿠버네티스는 규모와 관계없이 기업에서 개발자의 작업 속도를 개선하고 애플리케이션을 민첩하게 배포 및 확장하고 기술 스택을 현대화할 수 있게 해준다. 예를 들어 2000년부터 영국의 각 가정에 신선 식품을 배송해 온 온라인 소매업체 오카도(Ocado)는 물류와 창고를 관리하기 위해 자체적인 기술 플랫폼을 구축했다. 오카도는 2017년 도커 컨테이너를 쿠버네티스로 마이그레이션하기로 결정하고, 같은 해 여름에 첫 애플리케이션을 자체 프라이빗 클라우드의 프로덕션 환경에 투입했다. 오카도를 비롯한 기업이 쿠버네티스로 전환함으로써 얻는 대표적인 ...

사례 컨테이너 오케스트레이션 도커 쿠버네티스

2019.11.29

쿠버네티스(Kubernetes)는 5년 전 구글이 발표한 이후 빠른 속도로 2010년대의 가장 인기 있는 기술 중 하나로 부상했다. 현재 쿠버네티스는 마이크로서비스(컨테이너에서 실행되며, 여러 컨테이너가 모여 다양한 유형의 인프라에 이식할 수 있는 더 큰 큰 애플리케이션 역할을 할 수 있는, 독립적으로 배포 가능한 작은 서비스)로 구성된 애플리케이션을 제작하고 실행하는 데 있어 이론의 여지가 없는 선두 플랫폼이다.   쿠버네티스는 오케스트레이션 툴이다. 즉, 개발자가 탄력적인 분산 시스템 운영을 목표로 컨테이너 기반의 워크로드와 서비스를 조율하고 관리할 수 있게 해준다. 클라우드 네이티브 컴퓨팅 재단(CNCF)이 2018년 8월에 발표한 설문 조사에서 기업(5,000개 이상) 응답자 중 40%는 이미 프로덕션에서 쿠버네티스를 운용 중이다. 상당한 진척이지만, 중요한 점은 이러한 조직의 대다수가 극소수 애플리케이션만 쿠버네티스로 실행하면서 가능성을 탐색 중이라는 사실이다. 그러나 방향은 확실하다. 미래는 컨테이너 기반 마이크로서비스 애플리케이션을 향하고 있으며, 쿠버네티스는 그 중심의 플랫폼이다. 이것이 3대 클라우드 업체가 모두 쿠버네티스의 매니지드 버전을 출시하고 시스코, HPE, IBM/레드햇, 마이크로소프트, VM웨어/피보탈을 비롯한 여타 업체가 쿠버네티스를 각자의 핵심 소프트웨어 제품군에 수용한 이유다. 쿠버네티스는 규모와 관계없이 기업에서 개발자의 작업 속도를 개선하고 애플리케이션을 민첩하게 배포 및 확장하고 기술 스택을 현대화할 수 있게 해준다. 예를 들어 2000년부터 영국의 각 가정에 신선 식품을 배송해 온 온라인 소매업체 오카도(Ocado)는 물류와 창고를 관리하기 위해 자체적인 기술 플랫폼을 구축했다. 오카도는 2017년 도커 컨테이너를 쿠버네티스로 마이그레이션하기로 결정하고, 같은 해 여름에 첫 애플리케이션을 자체 프라이빗 클라우드의 프로덕션 환경에 투입했다. 오카도를 비롯한 기업이 쿠버네티스로 전환함으로써 얻는 대표적인 ...

2019.11.29

"리눅스·컨테이너·쿠버네티스는 차세대 IT 표준" IBM CEO 지니 로메티

점점 더 많은 기업이 미션 크리티컬 워크로드를 클라우드로 전환하는 데 주력하고 있다.  IBM의 CEO 지니 로메티에 따르면 기업의 디지털 혁신 노력이 새로운 장을 맞이함에 따라 리눅스, 컨테이너, 오픈소스 쿠버네티스 오케스트레이션 플랫폼의 조합이 차세대 IT 표준으로 부상했다.    로메티는 시드니에서 IBM의 클라우드 이노베이션 익스체인지(Cloud Innovation Exchange) 행사에서 ‘기업의 혁신 노력 1장’에서 기업이 워크로드의 1/5 정도를 클라우드로 이전하는 것을 목격했다고 밝혔다.  대부분 경우, 이는 ‘비교적 쉽게 클라우드로 이전할 수 있는 워크로드’거나 ‘새로운 워크로드’였다. IBM CEO 로메티는 “기업이 점점 더 많은 미션 크리티컬 워크로드를 클라우드 플랫폼으로 마이그레이션하는 데 중점을 둘 것”이라고 말했다. IBM 기업 가치 연구소(Business Institute for Business Value)가 발표한 2018년 연구에 따르면, 3/4 이상의 대기업 IT부서가 2~15개의 클라우드 환경을 관리하고 있지만 소수의 사용자만이 멀티 클라우드 환경을 관리하기 위한 멀티 클라우드 관리 전략이나 툴을 보유하고 있었다. 로메티는 “이제 5~15개의 퍼블릭 클라우드를 관리해야 한다. 기업에는 일부 전통적인 업무를 담당하는 프라이빗 클라우드가 많다. 그리고 전통적인 업무를 어디에서 처리하든 거기에는 데이터가 있다”라며 "바로 그러한 이유로 개방형 플랫폼이 필요해질 것"이라고 이야기했다.  로미티는 “이 다음 시대를 위한 플랫폼에서 이미 의사 결정은 이루어졌다”라고 말했다. 사실상 표준으로 리눅스, 컨테이너, 쿠버네티스가 부상했으며, IBM이 미화 330억 달러로 레드햇을 인수한 일은 바로 이러한 동향을 보여주는 사건이었다. “레드햇은 오픈소스의 리더지만 오픈소스 표준과 오픈소스 프로젝트의 리더기도 하다”라고 IBM CEO는 강조했다. 로메티는 “이 플랫폼 기술이 기업의 1등...

IBM IBM 기업 가치 연구소 멀티벤더 클라우드 멀티클라우드 쿠버네티스 지니 로메티 리눅스 컨테이너 표준 레드햇 클라우드 이노베이션 익스체인지

2019.11.14

점점 더 많은 기업이 미션 크리티컬 워크로드를 클라우드로 전환하는 데 주력하고 있다.  IBM의 CEO 지니 로메티에 따르면 기업의 디지털 혁신 노력이 새로운 장을 맞이함에 따라 리눅스, 컨테이너, 오픈소스 쿠버네티스 오케스트레이션 플랫폼의 조합이 차세대 IT 표준으로 부상했다.    로메티는 시드니에서 IBM의 클라우드 이노베이션 익스체인지(Cloud Innovation Exchange) 행사에서 ‘기업의 혁신 노력 1장’에서 기업이 워크로드의 1/5 정도를 클라우드로 이전하는 것을 목격했다고 밝혔다.  대부분 경우, 이는 ‘비교적 쉽게 클라우드로 이전할 수 있는 워크로드’거나 ‘새로운 워크로드’였다. IBM CEO 로메티는 “기업이 점점 더 많은 미션 크리티컬 워크로드를 클라우드 플랫폼으로 마이그레이션하는 데 중점을 둘 것”이라고 말했다. IBM 기업 가치 연구소(Business Institute for Business Value)가 발표한 2018년 연구에 따르면, 3/4 이상의 대기업 IT부서가 2~15개의 클라우드 환경을 관리하고 있지만 소수의 사용자만이 멀티 클라우드 환경을 관리하기 위한 멀티 클라우드 관리 전략이나 툴을 보유하고 있었다. 로메티는 “이제 5~15개의 퍼블릭 클라우드를 관리해야 한다. 기업에는 일부 전통적인 업무를 담당하는 프라이빗 클라우드가 많다. 그리고 전통적인 업무를 어디에서 처리하든 거기에는 데이터가 있다”라며 "바로 그러한 이유로 개방형 플랫폼이 필요해질 것"이라고 이야기했다.  로미티는 “이 다음 시대를 위한 플랫폼에서 이미 의사 결정은 이루어졌다”라고 말했다. 사실상 표준으로 리눅스, 컨테이너, 쿠버네티스가 부상했으며, IBM이 미화 330억 달러로 레드햇을 인수한 일은 바로 이러한 동향을 보여주는 사건이었다. “레드햇은 오픈소스의 리더지만 오픈소스 표준과 오픈소스 프로젝트의 리더기도 하다”라고 IBM CEO는 강조했다. 로메티는 “이 플랫폼 기술이 기업의 1등...

2019.11.14

블로그 | 클라우드 네이티브에 전부를 걸어야 하는가

클라우드 네이티브(Cloud Native) 데이터베이스, 클라우드 네이티브 보안, 클라우드 네이티브 거버넌스, 클라우드 네이티브 스토리지, 클라우드 네이티브 AI 등등 클라우드 서비스 업체가 제공하는 모든 것이 클라우드 네이티브이다. 필자는 클라우드 네이티브 애플리케이션을 이렇게 정의한다. '호스팅되는 퍼블릭 클라우드에 내재적인 시스템을 이용하는 애플리케이션.'   일반적인 권고는 “클라우드 네이티브는 좋고, 네이티브가 아닌 리프트 앤 시프트는 나쁘다”이다. 물론 맞는 말이다. 네이티브 서비스를 이용함으로써 네이티브 프로비저닝 시스템과 네이티브 관리 및 모니터링은 물론 네이티브 디렉토리 서비스를 사용하는 네이티브 보안을 포함한 핵심 시스템의 이점을 누릴 수 있다. 네이티브가 아닌 애플리케이션을 퍼블릭 클라우드에서 사용하는 것은 슈퍼카를 비포장도로에서 모는 것과 같은 일이다. 요즘은 이 네이티브 서비스 개념을 새로운 플랫폼인 컨테이너 오케스트레이션, 즉 쿠버네티스에 적용하고 있다. 쿠버네티스는 크고 쓸만한 네이티브 시스템의 생태계로, 데이터베이스, 스토리지, 보안, 거버넌스, 데브옵스 등 많은 것을 담고 있다. 이와 관련해 두 가지 학설이 있다. 첫째, 네이티브는 옳다. 이들 툴은 더 나은 성능을 제공할 가능성이 크다. 쿠버네티스 네이티브 스토리지 시스템은 수천 노드와 분당 수천 건의 동시 운영 환경으로 확장할 수 있다. 이는 ‘내재적’이라는 특성 덕분으로, 네이티브 인터페이스를 사용하는 네이티브 쿠버네티스 애플리케이션에서 사용하기 때문이다. 그런데 바깥 세상으로 나가서 데이터베이스나 스토리지, 보안 등을 다루는 비 네이티브 시스템과 동작하면, 커뮤니케이션 번역만으로도 상당한 지연이 발생한다. 이런 생각 때문에 쿠버네티스 네이티브가 항상 더 낫고, 보통은 더 선호된다. 두 번째 학설은 네이티브에 ‘올인’함으로써 너무 많은 복잡성이 더해진다는 것이다. 이점이 없는 것은 아니지만, 쿠버네티스 네이티브 시스템으로 이전하는 것은 최소한 두 가지를...

컨테이너 복잡성 오케스트레이션 쿠버네티스 클라우드네이티브

2019.11.05

클라우드 네이티브(Cloud Native) 데이터베이스, 클라우드 네이티브 보안, 클라우드 네이티브 거버넌스, 클라우드 네이티브 스토리지, 클라우드 네이티브 AI 등등 클라우드 서비스 업체가 제공하는 모든 것이 클라우드 네이티브이다. 필자는 클라우드 네이티브 애플리케이션을 이렇게 정의한다. '호스팅되는 퍼블릭 클라우드에 내재적인 시스템을 이용하는 애플리케이션.'   일반적인 권고는 “클라우드 네이티브는 좋고, 네이티브가 아닌 리프트 앤 시프트는 나쁘다”이다. 물론 맞는 말이다. 네이티브 서비스를 이용함으로써 네이티브 프로비저닝 시스템과 네이티브 관리 및 모니터링은 물론 네이티브 디렉토리 서비스를 사용하는 네이티브 보안을 포함한 핵심 시스템의 이점을 누릴 수 있다. 네이티브가 아닌 애플리케이션을 퍼블릭 클라우드에서 사용하는 것은 슈퍼카를 비포장도로에서 모는 것과 같은 일이다. 요즘은 이 네이티브 서비스 개념을 새로운 플랫폼인 컨테이너 오케스트레이션, 즉 쿠버네티스에 적용하고 있다. 쿠버네티스는 크고 쓸만한 네이티브 시스템의 생태계로, 데이터베이스, 스토리지, 보안, 거버넌스, 데브옵스 등 많은 것을 담고 있다. 이와 관련해 두 가지 학설이 있다. 첫째, 네이티브는 옳다. 이들 툴은 더 나은 성능을 제공할 가능성이 크다. 쿠버네티스 네이티브 스토리지 시스템은 수천 노드와 분당 수천 건의 동시 운영 환경으로 확장할 수 있다. 이는 ‘내재적’이라는 특성 덕분으로, 네이티브 인터페이스를 사용하는 네이티브 쿠버네티스 애플리케이션에서 사용하기 때문이다. 그런데 바깥 세상으로 나가서 데이터베이스나 스토리지, 보안 등을 다루는 비 네이티브 시스템과 동작하면, 커뮤니케이션 번역만으로도 상당한 지연이 발생한다. 이런 생각 때문에 쿠버네티스 네이티브가 항상 더 낫고, 보통은 더 선호된다. 두 번째 학설은 네이티브에 ‘올인’함으로써 너무 많은 복잡성이 더해진다는 것이다. 이점이 없는 것은 아니지만, 쿠버네티스 네이티브 시스템으로 이전하는 것은 최소한 두 가지를...

2019.11.05

'쿠버네티스, 도커, 컨테이너, 오케스트레이션' 바로 알기

소프트웨어 개발의 최신 동향을 관심 있게 지켜본 사람이라면 틀림없이 여러 번 접했을 두 가지 용어가 있다. 바로 도커(Docker)와 쿠버네티스(Kubernetes)다. 도커와 쿠버네티스는 사실상 ‘컨테이너(container)’와 ‘오케스트레이션(orchestration)’의 약칭이다.   도커 컨테이너는 개발과 테스트를 거쳐 생산 단계로의 애플리케이션 이동 과정을 단순화했다. 반면, 도커와 쿠버네티스는 둘 다 애플리케이션의 구축 및 배치 방식을 새롭게 바꿨다. 즉, 하나의 스택이 아닌 마이크로서비스들의 모음 방식인 것이다. 도커와 쿠버네티스가 중요한 이유는 무엇인가? 도커와 쿠버네티스는 소프트웨어 개발을 어떻게 바꾸고 있나? 그 과정에서 각자 어떤 역할을 하나? 이 질문들에 대해 아래와 같이 답변해 보고자 한다. 도커와 컨테이너 컨테이너는 리눅스, 윈도우 등 최신 운영체제에서 지원된다. 운영체제와 격리되어 있으며 자체 완비된 초소형 환경에서 소프트웨어가 실행되게 하는 것이 컨테이너이다. VM에 비유되곤 했으나 VM은 아니다. VM에 비해 훨씬 군살이 적고 시작과 중단 속도가 빠르며 유연성과 이동성 역시 훨씬 뛰어나다. 불과 몇 초 안에 스핀 업과 다운은 물론 확장이 가능하기 때문에 클라우드와 같은 탄력적인 환경에서 앱을 실행하기 쉽게 만들어 준다.  컨테이너화된 앱이 리눅스 등의 운영체제에 지원되기 시작한 지는 오래되었지만 컨테이너 작업이 사용자 친화적이라고 보기는 어려웠다. 반면, 오픈소스에서나 상업화된 형태에서나 도커라는 소프트웨어는 컨테이너를 사용자 친화적이고 개발자 친화적으로 만들어준다. 도커는 앱들을 컨테이너 이미지에 넣은 후 조직 등 어느 곳에서도 손쉽게 배치하여 재사용할 수 있도록 컨테이너용 공통 도구와 은유 방식을 제공한다. 즉, 컨테이너 이미지를 만들어 버전을 매긴 후 공유 및 이동은 물론 도커와 호환되는 호스트에 실행 컨테이너로 배치하는 작업을 눈 깜짝할 사이에 하게 해 주는 것이 도커다.  도커와 컨...

운영체제 윈도우 컨테이너 오케스트레이션 리눅스 도커 쿠버네티스 마이크로서비스

2019.11.01

소프트웨어 개발의 최신 동향을 관심 있게 지켜본 사람이라면 틀림없이 여러 번 접했을 두 가지 용어가 있다. 바로 도커(Docker)와 쿠버네티스(Kubernetes)다. 도커와 쿠버네티스는 사실상 ‘컨테이너(container)’와 ‘오케스트레이션(orchestration)’의 약칭이다.   도커 컨테이너는 개발과 테스트를 거쳐 생산 단계로의 애플리케이션 이동 과정을 단순화했다. 반면, 도커와 쿠버네티스는 둘 다 애플리케이션의 구축 및 배치 방식을 새롭게 바꿨다. 즉, 하나의 스택이 아닌 마이크로서비스들의 모음 방식인 것이다. 도커와 쿠버네티스가 중요한 이유는 무엇인가? 도커와 쿠버네티스는 소프트웨어 개발을 어떻게 바꾸고 있나? 그 과정에서 각자 어떤 역할을 하나? 이 질문들에 대해 아래와 같이 답변해 보고자 한다. 도커와 컨테이너 컨테이너는 리눅스, 윈도우 등 최신 운영체제에서 지원된다. 운영체제와 격리되어 있으며 자체 완비된 초소형 환경에서 소프트웨어가 실행되게 하는 것이 컨테이너이다. VM에 비유되곤 했으나 VM은 아니다. VM에 비해 훨씬 군살이 적고 시작과 중단 속도가 빠르며 유연성과 이동성 역시 훨씬 뛰어나다. 불과 몇 초 안에 스핀 업과 다운은 물론 확장이 가능하기 때문에 클라우드와 같은 탄력적인 환경에서 앱을 실행하기 쉽게 만들어 준다.  컨테이너화된 앱이 리눅스 등의 운영체제에 지원되기 시작한 지는 오래되었지만 컨테이너 작업이 사용자 친화적이라고 보기는 어려웠다. 반면, 오픈소스에서나 상업화된 형태에서나 도커라는 소프트웨어는 컨테이너를 사용자 친화적이고 개발자 친화적으로 만들어준다. 도커는 앱들을 컨테이너 이미지에 넣은 후 조직 등 어느 곳에서도 손쉽게 배치하여 재사용할 수 있도록 컨테이너용 공통 도구와 은유 방식을 제공한다. 즉, 컨테이너 이미지를 만들어 버전을 매긴 후 공유 및 이동은 물론 도커와 호환되는 호스트에 실행 컨테이너로 배치하는 작업을 눈 깜짝할 사이에 하게 해 주는 것이 도커다.  도커와 컨...

2019.11.01

'쿠버네티스 vs. 도커'··· 컨테이너와 오케스트레이션의 이해

소프트웨어 개발의 최신 경향을 쫓다 보면, 분명 두 가지 용어를 만나고 또 만날 것이다. 바로 도커(Docker)와 쿠버네티스(Kubernetes) 인데, 본질적으로는 컨테이너와 오케스트레이션을 가리키는 말이다. 도커 컨테이너는 애플리케이션을 개발과 테스트를 거쳐 프로덕션으로 이전하는 과정을 최적화해 주며, 도커와 쿠버네티스 둘은 애플리케이션을 구축하고 배치하는 방식을 재창조해 획일적인 단일체 소프트웨어 스택이 아니라 마이크로서비스의 모음으로 바꿔준다. 도커와 쿠버네티스가 왜 중요하며, 이 둘이 소프트웨어 개발을 어떻게 바꾸고 있으며, 이 과정에서 각각이 맡은 역할이 무엇인지 살펴보자.     도커와 컨테이너 리눅스와 윈도우, 그리고 기타 현대적인 운영체제가 지원하는 컨테이너는 소프트웨어가 자체 보유한 작은 환경에서 실행될 수 있도록 해 준다. 이 환경은 시스템의 나머지 부분과 격리된다. 컨테이너는 가상머신과 비슷하지만, 가상머신이 아니다. 컨테이너는 가상머신보다 더 날렵하며 기동과 정지도 더 빠르고 유연성과 이동성도 더 뛰어나다. 컨테이너는 단 몇 초 만에 확장하고 축소할 수 있으며, 클라우드와 같은 탄력적인 환경에서 애플리케이션을 더 쉽게 구동할 수 있다. 리눅스와 기타 운영체제가 컨테이너화된 애플리케이션을 지원하는 것은 오래 된 일이다. 하지만 컨테이너를 사용하는 것은 그리 사용자 친화적이지 않았다. 오픈소스이기도 하고 상용 소프트웨어이기도 한 도커는 기존의 컨테이너를 사용자 친화적이고 개발자 친화적인 환경으로 만든 주역이다. 도커는 컨테이너를 위한 공통 툴 세트를 제공해 애플리케이션을 컨테이너 이미지로 패키징해 기업 내에는 물론 다른 곳에도 쉽게 배치하고 재사용할 수 있다. 쉽게 말해 도커는 컨테이너 이미지를 생성하고 관리하고 공유하고 여러 곳으로 옮기고 도커 호환 호스트에 배치해 컨테이너를 구동하는 작업을 똑딱이 단추를 풀고 잠그는 것만큼 간단한 것으로 만들어 버린다.   도커와 컨테이너를 사용해야 할 때 도커와 ...

컨테이너 오케스트레이션 도커 쿠버네티스

2019.11.01

소프트웨어 개발의 최신 경향을 쫓다 보면, 분명 두 가지 용어를 만나고 또 만날 것이다. 바로 도커(Docker)와 쿠버네티스(Kubernetes) 인데, 본질적으로는 컨테이너와 오케스트레이션을 가리키는 말이다. 도커 컨테이너는 애플리케이션을 개발과 테스트를 거쳐 프로덕션으로 이전하는 과정을 최적화해 주며, 도커와 쿠버네티스 둘은 애플리케이션을 구축하고 배치하는 방식을 재창조해 획일적인 단일체 소프트웨어 스택이 아니라 마이크로서비스의 모음으로 바꿔준다. 도커와 쿠버네티스가 왜 중요하며, 이 둘이 소프트웨어 개발을 어떻게 바꾸고 있으며, 이 과정에서 각각이 맡은 역할이 무엇인지 살펴보자.     도커와 컨테이너 리눅스와 윈도우, 그리고 기타 현대적인 운영체제가 지원하는 컨테이너는 소프트웨어가 자체 보유한 작은 환경에서 실행될 수 있도록 해 준다. 이 환경은 시스템의 나머지 부분과 격리된다. 컨테이너는 가상머신과 비슷하지만, 가상머신이 아니다. 컨테이너는 가상머신보다 더 날렵하며 기동과 정지도 더 빠르고 유연성과 이동성도 더 뛰어나다. 컨테이너는 단 몇 초 만에 확장하고 축소할 수 있으며, 클라우드와 같은 탄력적인 환경에서 애플리케이션을 더 쉽게 구동할 수 있다. 리눅스와 기타 운영체제가 컨테이너화된 애플리케이션을 지원하는 것은 오래 된 일이다. 하지만 컨테이너를 사용하는 것은 그리 사용자 친화적이지 않았다. 오픈소스이기도 하고 상용 소프트웨어이기도 한 도커는 기존의 컨테이너를 사용자 친화적이고 개발자 친화적인 환경으로 만든 주역이다. 도커는 컨테이너를 위한 공통 툴 세트를 제공해 애플리케이션을 컨테이너 이미지로 패키징해 기업 내에는 물론 다른 곳에도 쉽게 배치하고 재사용할 수 있다. 쉽게 말해 도커는 컨테이너 이미지를 생성하고 관리하고 공유하고 여러 곳으로 옮기고 도커 호환 호스트에 배치해 컨테이너를 구동하는 작업을 똑딱이 단추를 풀고 잠그는 것만큼 간단한 것으로 만들어 버린다.   도커와 컨테이너를 사용해야 할 때 도커와 ...

2019.11.01

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31