Offcanvas

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

기업용 IT 인프라 혁신에 판을 깔다··· 영향력 ‘갑’ 오픈소스 5선

오픈소스는 엔터프라이즈 인프라의 발전을 이끄는 여러 기술들의 근간이다. 특히 중요한 5가지 오픈소스 프로젝트를 꼽아봤다. 지난 수년간 오픈소스 소프트웨어는 엔터프라이즈 IT의 핵심 기반이었다. 그런 점에서 오픈소스가 애플리케이션 개발만큼이나 인프라의 발전에 도움이 된다는 것이 새로운 얘기는 아니다. 어떤 오픈소스 프로젝트는 다른 프로젝트보다 영향력이 훨씬 크다. 운영 환경이 점차 복잡해지는 가운데 엔터프라이즈 인프라 혁신을 견인하고 있는 프로젝트 5가지는 다음과 같다.    오픈스택 오픈스택(OpenStack)은 업계의 주요 가상화 소프트웨어인 V스피어에 필적하는 오픈소스 프로젝트로 유명하다. 단 서버를 가상화해 유동적인 컴퓨팅 리소스 풀로 전환하는 작업에서는 차이가 있다. 사내 가상화 혹은 프라이빗 클라우드에 관한 전문지식이 충분하지 않은 경우에는 VM웨어의 V 스피어가 사용하기 더 쉽다.  오픈스택은 네트워킹 분야에서 특히 중요하다. 오늘날 이동 통신과 네트워크 기능 가상화(NFV) 영역에서는 엔터프라이즈 가상화 기술을 사용해 네트워킹 작업을 수행한다. 이전에는 하드웨어 및 소프트웨어에 종속돼 있던 작업이었다.  특히 통신 사업자들이 이런 방식을 선호한다. 고가의 독점 제품을 범용 스위치와 서버로 대체할 수 있기 때문이다. 또한 오픈스택처럼 NFV에 사용되는 소프트웨어를 통해 워크로드를 동적으로 프로비저닝하고 새로운 기능을 훨씬 유연하게 구현할 수 있기 때문이기도 하다.  리눅스 재단의 네트워킹 및 오케스트레이션 총괄 관리자인 아핏 조쉬푸라는 오픈스택과 기타 NFV 지원 프로젝트가 통신 사업의 핵심으로 자리잡았다고 말했다.  그는 "예전의 통신 분야는 [무선 접속 네트워크]부터 에지와 코어에 이르기까지 모든 분야에서 독점 인프라투성이였다"라며 "지난 5년간, 통신 네트워크는 완전히 오픈소스에 의존적인 분야로 바뀌었다"라고 말했다.  앤서블 앤서블(Ansible)...

오픈소스 가상화 엔터프라이즈 인프라 오픈스택 V스피어 리눅스 앤서블 오케스트레이션 아크라이노 쿠버네티스 컨테이너 온프레미스

2021.04.26

오픈소스는 엔터프라이즈 인프라의 발전을 이끄는 여러 기술들의 근간이다. 특히 중요한 5가지 오픈소스 프로젝트를 꼽아봤다. 지난 수년간 오픈소스 소프트웨어는 엔터프라이즈 IT의 핵심 기반이었다. 그런 점에서 오픈소스가 애플리케이션 개발만큼이나 인프라의 발전에 도움이 된다는 것이 새로운 얘기는 아니다. 어떤 오픈소스 프로젝트는 다른 프로젝트보다 영향력이 훨씬 크다. 운영 환경이 점차 복잡해지는 가운데 엔터프라이즈 인프라 혁신을 견인하고 있는 프로젝트 5가지는 다음과 같다.    오픈스택 오픈스택(OpenStack)은 업계의 주요 가상화 소프트웨어인 V스피어에 필적하는 오픈소스 프로젝트로 유명하다. 단 서버를 가상화해 유동적인 컴퓨팅 리소스 풀로 전환하는 작업에서는 차이가 있다. 사내 가상화 혹은 프라이빗 클라우드에 관한 전문지식이 충분하지 않은 경우에는 VM웨어의 V 스피어가 사용하기 더 쉽다.  오픈스택은 네트워킹 분야에서 특히 중요하다. 오늘날 이동 통신과 네트워크 기능 가상화(NFV) 영역에서는 엔터프라이즈 가상화 기술을 사용해 네트워킹 작업을 수행한다. 이전에는 하드웨어 및 소프트웨어에 종속돼 있던 작업이었다.  특히 통신 사업자들이 이런 방식을 선호한다. 고가의 독점 제품을 범용 스위치와 서버로 대체할 수 있기 때문이다. 또한 오픈스택처럼 NFV에 사용되는 소프트웨어를 통해 워크로드를 동적으로 프로비저닝하고 새로운 기능을 훨씬 유연하게 구현할 수 있기 때문이기도 하다.  리눅스 재단의 네트워킹 및 오케스트레이션 총괄 관리자인 아핏 조쉬푸라는 오픈스택과 기타 NFV 지원 프로젝트가 통신 사업의 핵심으로 자리잡았다고 말했다.  그는 "예전의 통신 분야는 [무선 접속 네트워크]부터 에지와 코어에 이르기까지 모든 분야에서 독점 인프라투성이였다"라며 "지난 5년간, 통신 네트워크는 완전히 오픈소스에 의존적인 분야로 바뀌었다"라고 말했다.  앤서블 앤서블(Ansible)...

2021.04.26

"쿠버네티스, 왜 이리 배우기 어려운가?" 공동 창업자가 내놓은 답변 보니

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

쿠버네티스 조 베다 오케스트레이션 리눅스 커널 이스티오 오픈소스 구글 링커드 서비스메시 YAML 베어메탈 코드형 인프라

2021.02.03

쿠버네티스 공동 창업자는 컨테이너 오케스트레이션 소프트웨어가 리눅스 커널처럼 보편화되고 구성도 용이해져, 도입을 넘어선 그 다음 단계로 넘어가기를 바라고 있다.  쿠버네티스의 공동 창업자인 조 베다는 컨테이너 오케스트레이션 툴이 학습하기 까다롭다고 인정하면서, 쿠버네티스가 도입을 넘어 다음 단계로 나아가려면, 커뮤니티가 쿠버네티스 기술을 리눅스 커널처럼 보편화하는 데 초점을 맞춰야 한다고 전했다.   베다는 브라이트토크에서 진행된 ‘무엇이든 물어보세요’ 세션에서 "이제 쿠버네티스는 다양한 생태계의 근간이자 애플리케이션 배포 및 관리를 위한 방식으로 여겨지고 있다"라고 말했다. 쿠버네티스 초창기에는 생각하지 못했던 바다. 베다는 “이렇게 될 것이라고는 예상하지 못했다”라고 말했다.   쿠버네티스가 엔터프라이즈 개발자들이 사용하는 핵심 기술이 된 만큼 베다는 두 가지 목표를 갖고 있다. 하나는 쿠버네티스를 안정적이면서 유용한 플랫폼으로 만들어, 리눅스 커널처럼 운영체제의 기본 구성요소로 자리잡을 수 있도록 하는 것이다.  다른 하나는 쿠버네티스에 흥미롭고 새로운 기능을 구축하는 것이다. 베다는 "사람들이 (쿠버네티스에) 놀라운 기능들을 구축하고 있다. 이를 바탕으로 흥미로운 작업을 해볼 수 있을 것이다. 쿠버네티스를 활용한 여러 프로젝트들이 이미 있다"라고 말했다.     베다는 2014년에 쿠버네티스를 위한 첫 번째 커밋을 작성했다. 그는 구글에서 10년간 근무한 후 현재 VM웨어의 수석 엔지니어로 일하고 있다. 베다가 사람들과 대화를 나누는 가운데 쿠버네티스에 대해 받은 핵심 질문 두 가지에 대한 답을 아래와 같이 정리했다.  왜 이스티오는 쿠버네티스와 별도로 존재하는가? 베다가 아주 흥미로워 했던 질문 중 하나는 다음과 같다. 오픈소스 서비스 메시인 이스티오(Istio)는 보통 쿠버네티스와 한쌍을 이루고, 구글 엔지니어들이 주로 개발했는데 왜 쿠버네티스와 좀...

2021.02.03

칼럼|컨테이너에는 그에 적합한 아키텍처가 필요하다

컨테이너는 간단해 보인다. 하지만 컨테이너의 장점을 활용하려면 그에 적합한 아키텍처를 새롭게 설계해야 한다.  가트너는 기업 내 컨테이너 도입율이 2023년까지는 계속 증가할 것으로 예측하고 있다. 가트너가 발표한 자료에 따르면 애플리케이션(과 데이터)은 빠른 속도로 컨테이너화되고 있다. 앱의 절반 이상을 컨테이너 기반으로 운영하는 조직은 23%에서 29%로 증가했으며, 앱을 컨테이너화한 비율이 10% 미만인 조직은 32%에서 21%로 감소했다.     컨테이너는 점점 클라우드 기반 애플리케이션의 기본 시스템으로 자리매김하고 있다. 컨테이너가 클라우드 네이티브를 달성하는 데 있어서 인기있는 방법이라는 걸 이해하기 위해서는 가트너의 자료를 참고해도 좋겠지만, 클라우드 개발팀과 만나보면 실감할 수 있을 것이다. 또 컨테이너 오케스트레이션 도구를 사용하여 이식성과 확장성을 극대화해보면 왜 컨테이너가 인기 있는지 이해할 수 있다. 컨테이너와 관련된 문제점 중 하나는 컨테이너 자체 혹은 컨테이너 오케스트레이션에 있는 게 아니라, 컨테이너를 어떻게 활용할지 설계하는 일에 있다. 컨테이너는 기본적으로 복잡하면서 층이 나뉘어 있는 분산 애플리케이션이다. 컨테이너를 플랫폼 삼아 특정 애플리케이션을 리프트 앤 시프트 방식으로 옮기는 건 그다지 어렵지 않다. 하지만 대부분의 경우 컨테이너를 그렇게 사용하면 별로 보탬이 되지 않는다. 컨테이너를 플랫폼이자 일종의 아키텍처로 설계하지 않는 한 컨테이너의 장점을 십분 활용할 수 없다. 몇 가지 팁은 다음과 같다.  첫째, 컨테이너에 담긴 애플리케이션들을 기능에 입각해 그룹으로 묶는 법이 있다. 새로운 것이든 기존에 있었던 것이든 모두 그룹화하는 것이다. 그렇게 하는 이유가 있다. 데이터베이스 액세스를 비롯한 목표를 수행하는 데 최적화된 코드를 특정 도메인에 삽입함으로써 문제 해결과 운영 개선을 도모할 수 있기 때문이다. 또 컨테이너를 최적의 클러스터에 배치할 수 있으므로 컨테이너가 ...

컨테이너 쿠버네티스 아키텍처 오케스트레이션

2021.01.14

컨테이너는 간단해 보인다. 하지만 컨테이너의 장점을 활용하려면 그에 적합한 아키텍처를 새롭게 설계해야 한다.  가트너는 기업 내 컨테이너 도입율이 2023년까지는 계속 증가할 것으로 예측하고 있다. 가트너가 발표한 자료에 따르면 애플리케이션(과 데이터)은 빠른 속도로 컨테이너화되고 있다. 앱의 절반 이상을 컨테이너 기반으로 운영하는 조직은 23%에서 29%로 증가했으며, 앱을 컨테이너화한 비율이 10% 미만인 조직은 32%에서 21%로 감소했다.     컨테이너는 점점 클라우드 기반 애플리케이션의 기본 시스템으로 자리매김하고 있다. 컨테이너가 클라우드 네이티브를 달성하는 데 있어서 인기있는 방법이라는 걸 이해하기 위해서는 가트너의 자료를 참고해도 좋겠지만, 클라우드 개발팀과 만나보면 실감할 수 있을 것이다. 또 컨테이너 오케스트레이션 도구를 사용하여 이식성과 확장성을 극대화해보면 왜 컨테이너가 인기 있는지 이해할 수 있다. 컨테이너와 관련된 문제점 중 하나는 컨테이너 자체 혹은 컨테이너 오케스트레이션에 있는 게 아니라, 컨테이너를 어떻게 활용할지 설계하는 일에 있다. 컨테이너는 기본적으로 복잡하면서 층이 나뉘어 있는 분산 애플리케이션이다. 컨테이너를 플랫폼 삼아 특정 애플리케이션을 리프트 앤 시프트 방식으로 옮기는 건 그다지 어렵지 않다. 하지만 대부분의 경우 컨테이너를 그렇게 사용하면 별로 보탬이 되지 않는다. 컨테이너를 플랫폼이자 일종의 아키텍처로 설계하지 않는 한 컨테이너의 장점을 십분 활용할 수 없다. 몇 가지 팁은 다음과 같다.  첫째, 컨테이너에 담긴 애플리케이션들을 기능에 입각해 그룹으로 묶는 법이 있다. 새로운 것이든 기존에 있었던 것이든 모두 그룹화하는 것이다. 그렇게 하는 이유가 있다. 데이터베이스 액세스를 비롯한 목표를 수행하는 데 최적화된 코드를 특정 도메인에 삽입함으로써 문제 해결과 운영 개선을 도모할 수 있기 때문이다. 또 컨테이너를 최적의 클러스터에 배치할 수 있으므로 컨테이너가 ...

2021.01.14

블로그|내년 클라우드 컴퓨팅 시장에 대한 뻔하지 않은 예측 3가지

클라우드 컴퓨팅 시장이 성장을 지속할 거라는 점은 확실하다. 하지만 남들이 주목하지 않는 의외의 측면 3가지를 예의주시해야 한다.  기업들은 매년 이맘때면 2021년 전망을 내놓으며 사람들의 주목을 끈다. 예컨대 “클라우드 컴퓨팅 시장은 계속 성장할 것”이라거나 “클라우드 보안에 대한 니즈가 확대될 것”이라는 류의 주장이 그것이다. 필자는 이런 주장을 접할 때면 식상함에 한숨을 쉬곤 한다.  이런 예측들은 도움이 전혀 되지 않는다.  클라우드 컴퓨팅 시장의 과거와 현재 동향으로부터 미래를 상당 부분 가늠해볼 수 있는 건 맞지만, 그외의 부분들은 예측하기가 훨씬 어렵다. 몇 가지 트렌드는 도래할 때까지는 예측하기 어려울 것이다. 독자들이 주목해야 할 3가지 동향을 정리했다.    1.인터클라우드 오케스트레이션 오늘날 주요 클라우드 기업 3곳은 더욱 깊은 수준에서 협업할 필요를 느끼지 못하고 있다. 대부분 자사 수익 창출을 위해 클라우드 서비스를 운영하는 탓에, 퍼블릭 클라우드 간 연결 통로를 만드는 일은 비즈니스적으로 손해이기 때문이다.  하지만 멀티클라우드를 이용하는 기업의 90% 이상은 인터클라우드 오케스트레이션에 대한 필요성을 느끼고 있다. 여러 퍼블릭 클라우드 서비스의 리소스를 결합하는 역량은 중요하다. 여러 클라우드에 걸쳐 있는 애플리케이션과 데이터베이스 API를 순차적으로 불러냄으로써 비즈니스상의 특정 문제들을 해결할 수 있다. 예컨대, 서로 다른 클라우드에 존재하는 두 시스템 사이의 공통된 프로세스에 기반해 인벤토리 재주문 포인트를 파악할 수 있다.  클라우드 관리 플랫폼이나 클라우드 서비스 브로커 등 새롭게 부상하는 기술을 통해 클라우드 간의 간극을 메우려는 시도들이 이뤄져온 바 있다. 하지만, 간극을 메우기엔 부족했다. 이 서비스들은 단지 리소스 관리 도구만 제공했을 뿐이어서 더 큰 인터클라우드 리소스를 아우르지도, 프로세스를 결합할 수도 없었다.  이...

클라우드 인터클라우드 오케스트레이션 멀티클라우드 클라우드옵스 클라우드컴퓨팅

2020.10.19

클라우드 컴퓨팅 시장이 성장을 지속할 거라는 점은 확실하다. 하지만 남들이 주목하지 않는 의외의 측면 3가지를 예의주시해야 한다.  기업들은 매년 이맘때면 2021년 전망을 내놓으며 사람들의 주목을 끈다. 예컨대 “클라우드 컴퓨팅 시장은 계속 성장할 것”이라거나 “클라우드 보안에 대한 니즈가 확대될 것”이라는 류의 주장이 그것이다. 필자는 이런 주장을 접할 때면 식상함에 한숨을 쉬곤 한다.  이런 예측들은 도움이 전혀 되지 않는다.  클라우드 컴퓨팅 시장의 과거와 현재 동향으로부터 미래를 상당 부분 가늠해볼 수 있는 건 맞지만, 그외의 부분들은 예측하기가 훨씬 어렵다. 몇 가지 트렌드는 도래할 때까지는 예측하기 어려울 것이다. 독자들이 주목해야 할 3가지 동향을 정리했다.    1.인터클라우드 오케스트레이션 오늘날 주요 클라우드 기업 3곳은 더욱 깊은 수준에서 협업할 필요를 느끼지 못하고 있다. 대부분 자사 수익 창출을 위해 클라우드 서비스를 운영하는 탓에, 퍼블릭 클라우드 간 연결 통로를 만드는 일은 비즈니스적으로 손해이기 때문이다.  하지만 멀티클라우드를 이용하는 기업의 90% 이상은 인터클라우드 오케스트레이션에 대한 필요성을 느끼고 있다. 여러 퍼블릭 클라우드 서비스의 리소스를 결합하는 역량은 중요하다. 여러 클라우드에 걸쳐 있는 애플리케이션과 데이터베이스 API를 순차적으로 불러냄으로써 비즈니스상의 특정 문제들을 해결할 수 있다. 예컨대, 서로 다른 클라우드에 존재하는 두 시스템 사이의 공통된 프로세스에 기반해 인벤토리 재주문 포인트를 파악할 수 있다.  클라우드 관리 플랫폼이나 클라우드 서비스 브로커 등 새롭게 부상하는 기술을 통해 클라우드 간의 간극을 메우려는 시도들이 이뤄져온 바 있다. 하지만, 간극을 메우기엔 부족했다. 이 서비스들은 단지 리소스 관리 도구만 제공했을 뿐이어서 더 큰 인터클라우드 리소스를 아우르지도, 프로세스를 결합할 수도 없었다.  이...

2020.10.19

5G 수익화부터 운영효율성 향상까지··· 구글, 통신사 지원 전략 발표 

구글 클라우드가 5G 수익화, 운영 효율성 향상, 데이터 기반 인사이트 제공을 골자로 하는 통신사 지원 전략을 발표했다.  구글 클라우드 CEO 토마스 쿠리안이 5일 자사 블로그를 통해 통신사 지원을 위한 3가지 전략 분야를 밝혔다. ▲비즈니스 서비스 플랫폼으로써 5G 수익 창출, ▲ 통신사 시스템 전반의 운영 효율성 개선, ▲데이터 중심 인사이트 제공이다.    5G 수익화 구글이 5G 수익 창출을 목적으로 선보인 것은 5G 솔루션을 포함하는 글로벌 모바일 엣지 클라우드(Global Mobile Edge Cloud, GMEC) 전략이다. 이 솔루션들은 전 세계적으로 배포될 계획이다.  일례로 구글은 미국 통신사 AT&T가 소매, 제조, 운송 업계에 5G 엣지 컴퓨팅 솔루션을 제공할 수 있도록 해당 통신사와 협력했다. AT&T 부사장이자 최고 마케팅 책임자(CMO) 모 카티베는 AT&T의 네트워크와 구글의 기술(AI, ML,쿠버네티스, 엣지 컴퓨팅)을 결합한 5G 솔루션을 선보일 것이라고 전했다.  이어서 그는 “차세대 클라우드 서비스를 제공하고자 구글 클라우드와 협력하고 있다”라며, “구글 클라우드의 엣지 컴퓨팅 기술과 5G를 결합하면, 클라우드의 잠재력이 발휘될 수 있다. 클라우드와 엣지 기술로 새로운 경험을 제공할 수 있는 단계에 가까워지고 있다”라고 덧붙였다.  또한 구글의 5G 수익화 계획에는 통신사에 클라우드 관리 플랫폼을 제공하는 안토스(Anthos) 솔루션의 새 버전도 포함돼 있다. 운영 효율성 향상  통신사의 운영 효율성을 지원하고자 구글은 통신 소프트웨어 개발사 암독스와 제휴하여 구글 클라우드 상에서 데이터 분석, SRE(Site Reliability Engineering), 5G 엣지 솔루션을 제공한다. 또한 넷크래커 테크놀로지(Netcracker Technology)와의 협력을 통해 전체 디지털 비즈니스 지원 시스템, 운영 지원 시스템...

데이터 운영효율성 안토스 구글클라우드 엣지컴퓨팅 쿠버네티스 데이터분석 머신러닝 오케스트레이션 통신사 인사이트 빅쿼리 5G 인공지능 AT&T 빅데이터 구글 5G수익화

2020.03.09

구글 클라우드가 5G 수익화, 운영 효율성 향상, 데이터 기반 인사이트 제공을 골자로 하는 통신사 지원 전략을 발표했다.  구글 클라우드 CEO 토마스 쿠리안이 5일 자사 블로그를 통해 통신사 지원을 위한 3가지 전략 분야를 밝혔다. ▲비즈니스 서비스 플랫폼으로써 5G 수익 창출, ▲ 통신사 시스템 전반의 운영 효율성 개선, ▲데이터 중심 인사이트 제공이다.    5G 수익화 구글이 5G 수익 창출을 목적으로 선보인 것은 5G 솔루션을 포함하는 글로벌 모바일 엣지 클라우드(Global Mobile Edge Cloud, GMEC) 전략이다. 이 솔루션들은 전 세계적으로 배포될 계획이다.  일례로 구글은 미국 통신사 AT&T가 소매, 제조, 운송 업계에 5G 엣지 컴퓨팅 솔루션을 제공할 수 있도록 해당 통신사와 협력했다. AT&T 부사장이자 최고 마케팅 책임자(CMO) 모 카티베는 AT&T의 네트워크와 구글의 기술(AI, ML,쿠버네티스, 엣지 컴퓨팅)을 결합한 5G 솔루션을 선보일 것이라고 전했다.  이어서 그는 “차세대 클라우드 서비스를 제공하고자 구글 클라우드와 협력하고 있다”라며, “구글 클라우드의 엣지 컴퓨팅 기술과 5G를 결합하면, 클라우드의 잠재력이 발휘될 수 있다. 클라우드와 엣지 기술로 새로운 경험을 제공할 수 있는 단계에 가까워지고 있다”라고 덧붙였다.  또한 구글의 5G 수익화 계획에는 통신사에 클라우드 관리 플랫폼을 제공하는 안토스(Anthos) 솔루션의 새 버전도 포함돼 있다. 운영 효율성 향상  통신사의 운영 효율성을 지원하고자 구글은 통신 소프트웨어 개발사 암독스와 제휴하여 구글 클라우드 상에서 데이터 분석, SRE(Site Reliability Engineering), 5G 엣지 솔루션을 제공한다. 또한 넷크래커 테크놀로지(Netcracker Technology)와의 협력을 통해 전체 디지털 비즈니스 지원 시스템, 운영 지원 시스템...

2020.03.09

포티넷, SOAR 전문업체 '사이버스폰스' 인수

포티넷이 미국 SOAR(보안·오케스트레이션·자동화·대응) 플랫폼 제공업체인 사이버스폰스를 인수 완료했다고 밝혔다.  포티넷 보안 패브릭 파트너였던 사이버스폰스는 포티애널라이즈(FortiAnalyzer), 포티SIEM(FortiSIEM), 포티게이트(FortiGate)의 자동화 및 사고 대응 기능을 높이고, 보안 운영의 단순화를 지원하게 될 것이라고 업체 측은 설명했다. 포티넷이 사이버스폰스를 인수하면서, 보안 분석가들은 모든 규모의 조직에 대해 독특하고 강력하며 차별화된 특허 솔루션을 활용할 수 있게 되었다고 전망했다. 분산된 멀티-테넌시(multi-tenancy)를 지원하는 엔터프라이즈급의 확장 가능한 아키텍처로, SOC 운영을 더욱 단순화시키고, 보안관제서비스제공업체(MSSP)들이 보다 용이하게 관리형 탐지 대응(MDR: Managed Detection and Response) 서비스를 제공할 수 있도록 지원할 수 있다.  325개 이상의 커넥터로, 모든 주요 보안 공급업체 및 기술과 원활하게 통합되며, 단일 중앙 집중식 가시성 및 제어 지점을 제공한다.  일련의 사고 대응 조치 단계 및 일상적인 업무를 자동화할 수 있으며 쉽게 설정을 지원하는 200개 이상의 바로 사용이 가능한 플레이 북(playbooks)과 사고 타임라인 및 자산 상관관계(asset correlation) 뷰에 자동화된 ROI 또는 절감 측정 툴(savings measurement tool)을 지원하는 사례 관리 모듈을 제공한다. 사이버스폰스의 설립자겸 CSO인 조셉 루미스는 “양사의 결합은 이상적인 조합이라고 생각하며, 사이버스폰스의 미션은 언제나 혁신적인 기술로 보안 운영 관리를 효과적이면서도 편리하게 만드는 것”이라며, “포티넷 보안 패브릭과 사이버스폰스 SOAR 기술의 결합을 통해 수백 개의 기능이 통합된 가장 정교한 글로벌 보안 운영 플랫폼으로, 고객 보호를 보장하고 바로 사용 가능한 플레이북(playbooks)을 간편하게 실행할 수 있게 ...

보안 포티넷 대응 자동화 오케스트레이션 SOAR 사이버스폰스

2019.12.23

포티넷이 미국 SOAR(보안·오케스트레이션·자동화·대응) 플랫폼 제공업체인 사이버스폰스를 인수 완료했다고 밝혔다.  포티넷 보안 패브릭 파트너였던 사이버스폰스는 포티애널라이즈(FortiAnalyzer), 포티SIEM(FortiSIEM), 포티게이트(FortiGate)의 자동화 및 사고 대응 기능을 높이고, 보안 운영의 단순화를 지원하게 될 것이라고 업체 측은 설명했다. 포티넷이 사이버스폰스를 인수하면서, 보안 분석가들은 모든 규모의 조직에 대해 독특하고 강력하며 차별화된 특허 솔루션을 활용할 수 있게 되었다고 전망했다. 분산된 멀티-테넌시(multi-tenancy)를 지원하는 엔터프라이즈급의 확장 가능한 아키텍처로, SOC 운영을 더욱 단순화시키고, 보안관제서비스제공업체(MSSP)들이 보다 용이하게 관리형 탐지 대응(MDR: Managed Detection and Response) 서비스를 제공할 수 있도록 지원할 수 있다.  325개 이상의 커넥터로, 모든 주요 보안 공급업체 및 기술과 원활하게 통합되며, 단일 중앙 집중식 가시성 및 제어 지점을 제공한다.  일련의 사고 대응 조치 단계 및 일상적인 업무를 자동화할 수 있으며 쉽게 설정을 지원하는 200개 이상의 바로 사용이 가능한 플레이 북(playbooks)과 사고 타임라인 및 자산 상관관계(asset correlation) 뷰에 자동화된 ROI 또는 절감 측정 툴(savings measurement tool)을 지원하는 사례 관리 모듈을 제공한다. 사이버스폰스의 설립자겸 CSO인 조셉 루미스는 “양사의 결합은 이상적인 조합이라고 생각하며, 사이버스폰스의 미션은 언제나 혁신적인 기술로 보안 운영 관리를 효과적이면서도 편리하게 만드는 것”이라며, “포티넷 보안 패브릭과 사이버스폰스 SOAR 기술의 결합을 통해 수백 개의 기능이 통합된 가장 정교한 글로벌 보안 운영 플랫폼으로, 고객 보호를 보장하고 바로 사용 가능한 플레이북(playbooks)을 간편하게 실행할 수 있게 ...

2019.12.23

현실 속 쿠버네티스 살펴보기··· 블룸버그, 뉴스 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

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

클라우드 네이티브(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

VMWorld 2018 주목할 만한 신제품

VMWorld 2018이 시작됐다. VM웨어와 협력업체들의 가상화, SDN, 하이퍼컨버전스, AI, 컨테이너 축제에서 소개된 주목할만한 신제품을 살펴본다. editor@itworld.co.kr

하이브리드 VM웨어 오케스트레이션 HCI 멀티클라우드 VMWorld

2018.08.31

VMWorld 2018이 시작됐다. VM웨어와 협력업체들의 가상화, SDN, 하이퍼컨버전스, AI, 컨테이너 축제에서 소개된 주목할만한 신제품을 살펴본다. editor@itworld.co.kr

2018.08.31

리뷰 | 최고의 자동화·오케스트레이션 툴이 '셰프'인 이유

지난 10년간 서버 프로비저닝과 구성 자동화에 가장 많이 사용된 오픈 소스 툴이자 업체가 바로 셰프(Chef)다. 이 업체는 최근 몇 년 동안 정책 컴플라이언스(준수) 테스트와 애플리케이션 배포 및 구성을 자동화하는 오픈 소스인 인스펙(InSpec)과 해비태트(Habitat)를 포트폴리오에 추가했다. 업체의 플래그십 상용 제품인 셰프 오토메이트(Chef Automate)에는 이 모두가 통합돼 있다. 셰프 오토메이트는 워크플로우와 노드 가시성, 컴플라이언스에 대한 엔터프라이즈 기능을 모두 제공한다. 오픈 소스 제품인 셰프, 인스펙, 해비태트와 통합돼 있다. 셰프 오토메이트에는 오픈 소스 구성 요소를 포함해 전체 플랫폼에 대한 지원 서비스가 포함돼 있다. 운영과 컴플라이언스, 워크플로우 이벤트에 대한 가시성을 제공하는 것은 물론 지속적으로 인프라와 애플리케이션을 전달할 수 있는 파이프라인이 포함돼 있다. 셰프의 구성 요소와 워크플로우 사용자는 셰프 DK(개발자 키트) 워크스테이션을 이용해 셰프를 조작한다. 이 워크스테이션에서 테스트 가상머신(VM)을 생성하는 테스트 키친(Test Kitchen) 같은 도구를 사용해 쿡북(cookbook)을 작성해 테스트하고, 명령줄 도구를 사용해 셰프 서버를 조작한다. 셰프 리포지토리와 셰프 서버 간 인터페이스를 제공하는 명령줄 도구인 나이프(Knife)를 사용하면 된다. 나이프는 사용자가 노드와 쿡북, 데이터 백을 관리하고, 노드에 셰프 클라이언트를 설치(부트스트랩)하는 작업 등에 유용하다. 셰프 쿡북 파일 대부분은 루비(Ruby)로 작성돼 있지만 일부 구성 파일은 YAML에 기반을 두고 있다. 오픈 소스인 셰프 서버는 구성 데이터의 허브 역할을 한다. 셰프 서버에는 쿡북, 노드에 적용된 정책, 셰프가 관리하는 각 등록 노드의 설명인 메타데이터가 저장돼 있다. 노드는 셰프 클라이언트를 사용해 셰프 서버에 레시피, 템플릿, 파일 배열 같은 구성 세부 정보를 요청한다. 다시 말해, 셰프는 푸시(Push) 기...

자동화 오케스트레이션 셰프

2018.06.20

지난 10년간 서버 프로비저닝과 구성 자동화에 가장 많이 사용된 오픈 소스 툴이자 업체가 바로 셰프(Chef)다. 이 업체는 최근 몇 년 동안 정책 컴플라이언스(준수) 테스트와 애플리케이션 배포 및 구성을 자동화하는 오픈 소스인 인스펙(InSpec)과 해비태트(Habitat)를 포트폴리오에 추가했다. 업체의 플래그십 상용 제품인 셰프 오토메이트(Chef Automate)에는 이 모두가 통합돼 있다. 셰프 오토메이트는 워크플로우와 노드 가시성, 컴플라이언스에 대한 엔터프라이즈 기능을 모두 제공한다. 오픈 소스 제품인 셰프, 인스펙, 해비태트와 통합돼 있다. 셰프 오토메이트에는 오픈 소스 구성 요소를 포함해 전체 플랫폼에 대한 지원 서비스가 포함돼 있다. 운영과 컴플라이언스, 워크플로우 이벤트에 대한 가시성을 제공하는 것은 물론 지속적으로 인프라와 애플리케이션을 전달할 수 있는 파이프라인이 포함돼 있다. 셰프의 구성 요소와 워크플로우 사용자는 셰프 DK(개발자 키트) 워크스테이션을 이용해 셰프를 조작한다. 이 워크스테이션에서 테스트 가상머신(VM)을 생성하는 테스트 키친(Test Kitchen) 같은 도구를 사용해 쿡북(cookbook)을 작성해 테스트하고, 명령줄 도구를 사용해 셰프 서버를 조작한다. 셰프 리포지토리와 셰프 서버 간 인터페이스를 제공하는 명령줄 도구인 나이프(Knife)를 사용하면 된다. 나이프는 사용자가 노드와 쿡북, 데이터 백을 관리하고, 노드에 셰프 클라이언트를 설치(부트스트랩)하는 작업 등에 유용하다. 셰프 쿡북 파일 대부분은 루비(Ruby)로 작성돼 있지만 일부 구성 파일은 YAML에 기반을 두고 있다. 오픈 소스인 셰프 서버는 구성 데이터의 허브 역할을 한다. 셰프 서버에는 쿡북, 노드에 적용된 정책, 셰프가 관리하는 각 등록 노드의 설명인 메타데이터가 저장돼 있다. 노드는 셰프 클라이언트를 사용해 셰프 서버에 레시피, 템플릿, 파일 배열 같은 구성 세부 정보를 요청한다. 다시 말해, 셰프는 푸시(Push) 기...

2018.06.20

블로그 | 마이크로서비스 모니터링의 5가지 원칙

필자는 7살때부터 프로그래밍을 시작했다(컴퓨터가 없어 종이에 썼다는 점은 논외로 하고). 필자가 초기에 배운 한 가지는 소프트웨어 개발은 (인생과 마찬가지로) 타협의 연속이란 점이다. 기업과 개발자는 늘 성능 또는 간소함, 혁신 또는 관리 용이성 중에서 하나를 선택한다. 그러나 컨테이너와 도커가 인기를 얻고 마이크로서비스가 부상하면서 애플리케이션 개발은 각각 자체 프로세스에서 실행되면서 API와 같은 메커니즘으로 소통하는 작은 서비스의 집합으로 바뀌었다. 마이크로서비스의 장점은 명확하다. 소프트웨어 개발과 배포 속도의 비약적 향상이다. 이를 통해 비용을 절감하고 주변 조건만 맞춰준다면 기업에 경쟁 우위를 제공한다. 필자는 지난 몇 년 동안 많은 데브옵스 전문가들과 대화를 나누면서 이들이 직면한 여러 가지 과제를 알게 됐다. 이러한 대화를 통해 확실히 드러난 것은 기업은 마이크로서비스를 도입할 때 성능 및 보안 위생 측면에서 소프트웨어 관리 방식에 대한 사고의 전환이 필요하다는 점이다. 마이크로서비스를 사용한다는 것은 소프트웨어 관리, 구체적으로 기업에서 인프라, 애플리케이션 및 데이터 모니터링을 다루는 방식의 변화를 의미한다. 변화하지 않는 기업은 문제 해결은 말할 필요도 없고 마이크로서비스의 성능을 파악하기도 어렵게 된다. 마이크로서비스 모니터링을 더 현명하고 기민하게, 무엇보다 더 효과적으로 하기 위한 5가지 방법을 소개한다. 컨테이너와 컨테이너 내부에서 실행되는 요소 모니터링 컨테이너는 마이크로서비스의 빌딩 블록으로, 개발자 노트북부터 클라우드에 이르기까지 넓은 범위를 포괄하는 블랙 박스다. 그러나 컨테이너 내부에 대한 시야를 확보하지 않으면 서비스 모니터링이나 문제 해결 같은 기본적인 기능을 수행하기 어렵다. 컨테이너 안에서 무엇이 실행되는지, 애플리케이션과 코드의 성능이 어느 정도인지, 중요한 맞춤형 측정값을 생성하고 있는지 여부 등을 알아야 한다. 또한 기업의 규모가 커지고 수천 개의 호스트를 수천 수만의 컨테이너와 함...

컨테이너 오케스트레이션 도커 쿠버네티스 마이크로서비스

2018.03.15

필자는 7살때부터 프로그래밍을 시작했다(컴퓨터가 없어 종이에 썼다는 점은 논외로 하고). 필자가 초기에 배운 한 가지는 소프트웨어 개발은 (인생과 마찬가지로) 타협의 연속이란 점이다. 기업과 개발자는 늘 성능 또는 간소함, 혁신 또는 관리 용이성 중에서 하나를 선택한다. 그러나 컨테이너와 도커가 인기를 얻고 마이크로서비스가 부상하면서 애플리케이션 개발은 각각 자체 프로세스에서 실행되면서 API와 같은 메커니즘으로 소통하는 작은 서비스의 집합으로 바뀌었다. 마이크로서비스의 장점은 명확하다. 소프트웨어 개발과 배포 속도의 비약적 향상이다. 이를 통해 비용을 절감하고 주변 조건만 맞춰준다면 기업에 경쟁 우위를 제공한다. 필자는 지난 몇 년 동안 많은 데브옵스 전문가들과 대화를 나누면서 이들이 직면한 여러 가지 과제를 알게 됐다. 이러한 대화를 통해 확실히 드러난 것은 기업은 마이크로서비스를 도입할 때 성능 및 보안 위생 측면에서 소프트웨어 관리 방식에 대한 사고의 전환이 필요하다는 점이다. 마이크로서비스를 사용한다는 것은 소프트웨어 관리, 구체적으로 기업에서 인프라, 애플리케이션 및 데이터 모니터링을 다루는 방식의 변화를 의미한다. 변화하지 않는 기업은 문제 해결은 말할 필요도 없고 마이크로서비스의 성능을 파악하기도 어렵게 된다. 마이크로서비스 모니터링을 더 현명하고 기민하게, 무엇보다 더 효과적으로 하기 위한 5가지 방법을 소개한다. 컨테이너와 컨테이너 내부에서 실행되는 요소 모니터링 컨테이너는 마이크로서비스의 빌딩 블록으로, 개발자 노트북부터 클라우드에 이르기까지 넓은 범위를 포괄하는 블랙 박스다. 그러나 컨테이너 내부에 대한 시야를 확보하지 않으면 서비스 모니터링이나 문제 해결 같은 기본적인 기능을 수행하기 어렵다. 컨테이너 안에서 무엇이 실행되는지, 애플리케이션과 코드의 성능이 어느 정도인지, 중요한 맞춤형 측정값을 생성하고 있는지 여부 등을 알아야 한다. 또한 기업의 규모가 커지고 수천 개의 호스트를 수천 수만의 컨테이너와 함...

2018.03.15

HPE, 하이브리드 클라우드 관리 위한 SaaS SW '원스피어' 소개

클라우드 컴퓨팅은 운영 효율성과 비용 최적화를 약속한다. 그러나 대부분의 대기업은 당분간 하이브리드 컴퓨팅 환경을 운영해야 한다. 결과적으로 많은 기업에게 클라우드 기술은 이미 복잡한 컴퓨팅 인프라 스트럭처 위에 또 하나의 계층을 추가하는 존재로 다가온다. HPE는 하이브리드 클라우드 컴퓨팅 환경을 최적화해야 한다는 시장의 수요를 기회로 보고 있다. 온프레미스 및 퍼블릭 클라우드용 SaaS 기반 멀티 클라우드 관리 소프트웨어인 '원스피어'(OnSphere)를 지난 28일 디스커버 컨퍼런스에 공개한 이유다. 무어 인사이트 앤 스트래티지의 레트 딜링햄 수석 애널리스트는 HPE가 주최한 웹캐스트에서 "하이브리드 IT는 이제 당면한 현실이다. 다수의 클라우드가 도입됨에 따라 컴플라이언스 및 비용 최적화는 물론 사내 컴퓨팅 및 IoT 애플리케이션을 지원하기 위해 프라이빗 클라우드 인프라 투자가 계속되고 있다"라고 진단했다. 그는 이어 "기업들은 여러 클라우드 및 하이브리드 클라우드를 사용할 수 있는 이러한 오케스트레이션 툴과 클라우드 관리 플랫폼을 보유하고 있다. 하이브리드 인프라 스트럭처 전반에 걸친 통합 관리가 과제로 부상하고 있다"라고 말했다. HPE의 소프트웨어 정의 및 클라우드 그룹 수석 부사장 릭 르위스는 현재 시장에 나와있는 오케스트레이션 도구가 제한되어 있다는 점이 문제라고 설명하며, 특히 특정 퍼블릭 클라우드 벤더 생태계 내에서만 이용 가능한 특성을 지닌다고 지적했다. 그는 "그러나 원스피어는 열려 있다. 오픈API를 가졌기에 원하는대로 이용할 수 있다"라고 말했다. 그러나 1월 출시될 예정인 원스피어는 출시 시점에서는 AWS에서만 작동할 예정이다. HPE는 애저와 구글 클라우드에 대한 지원이 이후 이어질 것이라고 전했다. 온프레미스 측면에서는 VM웨어와 쿠베르네티즈를 포함해 광범위한 클라우드 플랫폼을 지원할 예정이다. HPE는 오픈 스택과 애저 스택 ...

하이브리드 오케스트레이션 HPE 원스피어 멀티 클라우드

2017.11.29

클라우드 컴퓨팅은 운영 효율성과 비용 최적화를 약속한다. 그러나 대부분의 대기업은 당분간 하이브리드 컴퓨팅 환경을 운영해야 한다. 결과적으로 많은 기업에게 클라우드 기술은 이미 복잡한 컴퓨팅 인프라 스트럭처 위에 또 하나의 계층을 추가하는 존재로 다가온다. HPE는 하이브리드 클라우드 컴퓨팅 환경을 최적화해야 한다는 시장의 수요를 기회로 보고 있다. 온프레미스 및 퍼블릭 클라우드용 SaaS 기반 멀티 클라우드 관리 소프트웨어인 '원스피어'(OnSphere)를 지난 28일 디스커버 컨퍼런스에 공개한 이유다. 무어 인사이트 앤 스트래티지의 레트 딜링햄 수석 애널리스트는 HPE가 주최한 웹캐스트에서 "하이브리드 IT는 이제 당면한 현실이다. 다수의 클라우드가 도입됨에 따라 컴플라이언스 및 비용 최적화는 물론 사내 컴퓨팅 및 IoT 애플리케이션을 지원하기 위해 프라이빗 클라우드 인프라 투자가 계속되고 있다"라고 진단했다. 그는 이어 "기업들은 여러 클라우드 및 하이브리드 클라우드를 사용할 수 있는 이러한 오케스트레이션 툴과 클라우드 관리 플랫폼을 보유하고 있다. 하이브리드 인프라 스트럭처 전반에 걸친 통합 관리가 과제로 부상하고 있다"라고 말했다. HPE의 소프트웨어 정의 및 클라우드 그룹 수석 부사장 릭 르위스는 현재 시장에 나와있는 오케스트레이션 도구가 제한되어 있다는 점이 문제라고 설명하며, 특히 특정 퍼블릭 클라우드 벤더 생태계 내에서만 이용 가능한 특성을 지닌다고 지적했다. 그는 "그러나 원스피어는 열려 있다. 오픈API를 가졌기에 원하는대로 이용할 수 있다"라고 말했다. 그러나 1월 출시될 예정인 원스피어는 출시 시점에서는 AWS에서만 작동할 예정이다. HPE는 애저와 구글 클라우드에 대한 지원이 이후 이어질 것이라고 전했다. 온프레미스 측면에서는 VM웨어와 쿠베르네티즈를 포함해 광범위한 클라우드 플랫폼을 지원할 예정이다. HPE는 오픈 스택과 애저 스택 ...

2017.11.29

리뷰 | 레드햇 아토믹 호스트 '도커를 해결하는 수준 높지만 어려운 방법'

프로젝트 아토믹(Project Atomic)은 쿠버네티스(Kubernetes)와 레드햇의 엔지니어링 역량을 최첨단 컨테이너 호스트에 쏟아 부었다. 하지만 사용자는 소매를 걷어붙일 준비를 해야 할 것이다. 레드햇의 프로젝트 아토믹은 리눅스 컨테이너를 실행하는 위한 독창적인 방법이다. 아토믹 호스트 운영체제에는 도커(Docker, 컨테이너), 플란넬(Flannel, 네트워킹), OS트리(OSTree, 호스트 관리), Etcd(분산키 저장소)가 따라오며, 쿠버네티스(오케스트레이션)가 사전 설치되어 있다. 이로써 “모든 것을 갖췄다”고 말할 수도 있지만, 그에 따른 추가적인 복잡성과 관리 오버헤드가 있다. 쿠버네티스는 여러 대의 아토믹 호스트에 걸쳐 “팟(Pod)”의 생성을 조율한다. 팟이란 하나의 애플리케이션에 있는 서비스들을 논리적으로 분리시키는 도커 컨테이너들의 그룹을 지칭한다. 하나의 팟에 있는 컨테이너는 IP 주소를 공유하고 내부접속(localhost)을 통해서 통신한다. 플란넬은 아토믹 호스트들을 위한 오버레이 네트워크를 제공해 클러스터에 있는 모든 팟이 해당 클러스터 내부의 다른 모든 팟 또는 서비스와 통신할 수 있게 해준다. 이 오버레이 네트워크는 컨테이너 네트워킹용으로만 사용된다. 쿠버네티스 프록시 서비스(Proxy Service)는 호스트 IP 공간에 대한 액세스를 제공한다. Etdc는 클러스터에 있는 모든 호스트 전체에 대해 쿠버네티스와 플란넬의 모두에 대한 구성을 저장하는 데 사용된다. 아토믹 컨테이너 클러스터는 쿠버네티스 때문에 몇 가지 가정을 두는데, 관리자들은 아토믹에 대해서 실제로 선택의 여지가 없다: 쿠버네티스를 사용하거나 아니면 다른 컨테이너 OS를 찾거나. “관습에 의한 설계”로 짜증이 나고 컨테이너 호스트에 대해 더 많은 자유로움과 유연성을 원한다면, 랜처OS(RancherOS)나 VMware 포톤(Phot...

레드햇 컨테이너 리뷰 오케스트레이션 도커 쿠버네티스 아토믹 플라넬

2017.09.11

프로젝트 아토믹(Project Atomic)은 쿠버네티스(Kubernetes)와 레드햇의 엔지니어링 역량을 최첨단 컨테이너 호스트에 쏟아 부었다. 하지만 사용자는 소매를 걷어붙일 준비를 해야 할 것이다. 레드햇의 프로젝트 아토믹은 리눅스 컨테이너를 실행하는 위한 독창적인 방법이다. 아토믹 호스트 운영체제에는 도커(Docker, 컨테이너), 플란넬(Flannel, 네트워킹), OS트리(OSTree, 호스트 관리), Etcd(분산키 저장소)가 따라오며, 쿠버네티스(오케스트레이션)가 사전 설치되어 있다. 이로써 “모든 것을 갖췄다”고 말할 수도 있지만, 그에 따른 추가적인 복잡성과 관리 오버헤드가 있다. 쿠버네티스는 여러 대의 아토믹 호스트에 걸쳐 “팟(Pod)”의 생성을 조율한다. 팟이란 하나의 애플리케이션에 있는 서비스들을 논리적으로 분리시키는 도커 컨테이너들의 그룹을 지칭한다. 하나의 팟에 있는 컨테이너는 IP 주소를 공유하고 내부접속(localhost)을 통해서 통신한다. 플란넬은 아토믹 호스트들을 위한 오버레이 네트워크를 제공해 클러스터에 있는 모든 팟이 해당 클러스터 내부의 다른 모든 팟 또는 서비스와 통신할 수 있게 해준다. 이 오버레이 네트워크는 컨테이너 네트워킹용으로만 사용된다. 쿠버네티스 프록시 서비스(Proxy Service)는 호스트 IP 공간에 대한 액세스를 제공한다. Etdc는 클러스터에 있는 모든 호스트 전체에 대해 쿠버네티스와 플란넬의 모두에 대한 구성을 저장하는 데 사용된다. 아토믹 컨테이너 클러스터는 쿠버네티스 때문에 몇 가지 가정을 두는데, 관리자들은 아토믹에 대해서 실제로 선택의 여지가 없다: 쿠버네티스를 사용하거나 아니면 다른 컨테이너 OS를 찾거나. “관습에 의한 설계”로 짜증이 나고 컨테이너 호스트에 대해 더 많은 자유로움과 유연성을 원한다면, 랜처OS(RancherOS)나 VMware 포톤(Phot...

2017.09.11

쿠버네티스 1.7 신기능 따라잡기··· 로컬 스토리지, 암호화 등

인기 컨테이너 오케스트레이션 및 관리 시스템 쿠버네티스(Kubernetes) 1.7은 보안, 스테이트풀(stateful) 애플리케이션, 확장성 기능 등 다양한 신기능을 갖췄다. 쿠버네티스 1.6은 주로 안정화에 관한 것이었고, ETCD 분산 키 값 저장소 3 사용 등과 같이 오랫동안 계획된 변화를 실행했다. 그러나 쿠버네티스 1.7의 새 기능은 아직 알파 단계인 것이 많다. 쿠버네티스가 보다 광범위한 시나리오에서 더욱 쓸모 있기 위해 노력 중임을 알 수 있다. 다른 새 기능은 종전에 컨테이너 생태계의 다른 부분에 이관되었던 기능을 가져온 것이다. 쿠버네티스 1.7 스토리지와 상태 : 로컬과 업데이트 유지 쿠버네티스 1.7은 지속적인 상태 관리와 관련된 몇 가지 기능이 업데이트되었다. 지속 상태 관리 방법 중 가장 흔한 것은 컨테이너 실행 그룹, 즉 쿠버네티스 용어로 팟(pod)을 여러 종류의 스토리지 볼륨에 연결하는 것이다. NFS 공유폴더나 iSCSI 타깃은 물론, AWS나 애저와 같은 클라우드 서비스의 스토리지도 포함된다. 쿠버네티스 1.7에는 로컬 스토리지 매핑 기능도 추가됐다. 쿠버네티스의 네이티브 API가 실행되는 시스템 상의 데이터에 팟 워크로드가 접근할 수 있는 편리한 방법이다. 그러나 로컬 스토리지 사용은 아직 많은 쿠버네티스 시나리오에서 현명한 선택이 아닌 것 같다. 로컬 스토리지가 가장 유용한 것은 임시 방편 애플리케이션이나 미니큐브(Minikube)와 함께 나온 것과 같은 단일 시스템 개발 노드일 것으로 보인다. 또한 현재로서는 쿠버네티스 1.7 로컬 스토리지의 많은 부분이 원시적이거나 신뢰할 수 없는 상태다. 예를 들면, 로컬 블록 디바이스를 볼륨 소스로 사용하는 것이 아직 허용되지 않는다. 그러나 장기적으로는 로컬 스토리지를 쿠버네티스의 다른 스토리지 솔루션 중 가장 우선적인 것으로 만들 계획이다. 쿠버네티스의 상태 처리에 또 한 가지 달라진 점은 지속 상태가 있는 애플리케이션 관리에 대한 것이다. 애플...

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

2017.07.10

인기 컨테이너 오케스트레이션 및 관리 시스템 쿠버네티스(Kubernetes) 1.7은 보안, 스테이트풀(stateful) 애플리케이션, 확장성 기능 등 다양한 신기능을 갖췄다. 쿠버네티스 1.6은 주로 안정화에 관한 것이었고, ETCD 분산 키 값 저장소 3 사용 등과 같이 오랫동안 계획된 변화를 실행했다. 그러나 쿠버네티스 1.7의 새 기능은 아직 알파 단계인 것이 많다. 쿠버네티스가 보다 광범위한 시나리오에서 더욱 쓸모 있기 위해 노력 중임을 알 수 있다. 다른 새 기능은 종전에 컨테이너 생태계의 다른 부분에 이관되었던 기능을 가져온 것이다. 쿠버네티스 1.7 스토리지와 상태 : 로컬과 업데이트 유지 쿠버네티스 1.7은 지속적인 상태 관리와 관련된 몇 가지 기능이 업데이트되었다. 지속 상태 관리 방법 중 가장 흔한 것은 컨테이너 실행 그룹, 즉 쿠버네티스 용어로 팟(pod)을 여러 종류의 스토리지 볼륨에 연결하는 것이다. NFS 공유폴더나 iSCSI 타깃은 물론, AWS나 애저와 같은 클라우드 서비스의 스토리지도 포함된다. 쿠버네티스 1.7에는 로컬 스토리지 매핑 기능도 추가됐다. 쿠버네티스의 네이티브 API가 실행되는 시스템 상의 데이터에 팟 워크로드가 접근할 수 있는 편리한 방법이다. 그러나 로컬 스토리지 사용은 아직 많은 쿠버네티스 시나리오에서 현명한 선택이 아닌 것 같다. 로컬 스토리지가 가장 유용한 것은 임시 방편 애플리케이션이나 미니큐브(Minikube)와 함께 나온 것과 같은 단일 시스템 개발 노드일 것으로 보인다. 또한 현재로서는 쿠버네티스 1.7 로컬 스토리지의 많은 부분이 원시적이거나 신뢰할 수 없는 상태다. 예를 들면, 로컬 블록 디바이스를 볼륨 소스로 사용하는 것이 아직 허용되지 않는다. 그러나 장기적으로는 로컬 스토리지를 쿠버네티스의 다른 스토리지 솔루션 중 가장 우선적인 것으로 만들 계획이다. 쿠버네티스의 상태 처리에 또 한 가지 달라진 점은 지속 상태가 있는 애플리케이션 관리에 대한 것이다. 애플...

2017.07.10

IDG 블로그 | IBM의 오픈스택 수용이 의미하는 것

지난 주 IBM이 자사의 모든 클라우드 솔루션을 오픈스택 기반으로 구축될 것이라고 발표했을 때, 이는 오픈스택 재단과 관련 대형 지지자 커뮤니티에서는 의미있는 승리였다.   오픈스택 재단의 COO 마크 콜리어는 “우리는 IBM의 오픈스택에 참여해 과거 리눅스와 오픈소스 커뮤니티를 위해 했던 것과 같은 역할을 수행해 주기를 기대했다”며, “IBM은 실제로 자사가 앞으로 출시할 모든 클라우드 솔루션의 기반으로 오픈스택을 사용할 것을 약속했다”고 강조했다.   이번 발표는 IBM이 오픈스택의 기업측 파수꾼이란 자리에 앉았다는 것을 의미하며, 이는 중요성 면에서 랙스페이스나 오픈스택의 시작점인 NASA를 능가하는 것이다. IBM은 필요한 자본과 자원을 투여해 오픈소스 커뮤니티를 육성한 경력을 가지고 있다. 이클립스를 기반부터 세웠으며, 리눅스와 아파치의 성공에 매우 중심적인 역할을 했다.   랙스페이스나 레드햇과는 달리 IBM은 오픈스택의 자체 패키지 버전을 제공하지 않을 계획이다. IBM의 소프트웨어 표준, 오픈소스, 클라우드 연구소 담당 부사장 에인젤 디아즈는 “우리는 오픈스택이 아파치 HTTTP 서버가 웹스피어에 했던 것과 같은 역할을 하기를 바란다. 모든 현대적인 애플리케이션 서버는 아파치 HTTP 코드를 가지고 있다. 이것이 바로 오픈스택이 클라우드에 대해 해주었으면 하는 역할이다”라고 설명했다.   오픈스택을 번들로 제공하는 첫번째 IBM 제품은 현재 베타 상태인 스마트클라우드 오케스트레이터로, 고객이 마우스 드래그 앤 드롭 인터페이스로 클라우드 서비스를 작성할 수 있도록 해 준다.   디아즈와 이야기를 나누기 전에 필자는 IBM이 오픈스택 개발에 그동안 얼마만큼의 영향력을 가지고 있는지 제대로 알지 못했다. IBM은 현재 3위의 코드 기여 기업으로, 특히 지난 가을 발표된 폴섬...

클라우드 IBM 오픈스택 스마트클라우드 오케스트레이션

2013.03.12

지난 주 IBM이 자사의 모든 클라우드 솔루션을 오픈스택 기반으로 구축될 것이라고 발표했을 때, 이는 오픈스택 재단과 관련 대형 지지자 커뮤니티에서는 의미있는 승리였다.   오픈스택 재단의 COO 마크 콜리어는 “우리는 IBM의 오픈스택에 참여해 과거 리눅스와 오픈소스 커뮤니티를 위해 했던 것과 같은 역할을 수행해 주기를 기대했다”며, “IBM은 실제로 자사가 앞으로 출시할 모든 클라우드 솔루션의 기반으로 오픈스택을 사용할 것을 약속했다”고 강조했다.   이번 발표는 IBM이 오픈스택의 기업측 파수꾼이란 자리에 앉았다는 것을 의미하며, 이는 중요성 면에서 랙스페이스나 오픈스택의 시작점인 NASA를 능가하는 것이다. IBM은 필요한 자본과 자원을 투여해 오픈소스 커뮤니티를 육성한 경력을 가지고 있다. 이클립스를 기반부터 세웠으며, 리눅스와 아파치의 성공에 매우 중심적인 역할을 했다.   랙스페이스나 레드햇과는 달리 IBM은 오픈스택의 자체 패키지 버전을 제공하지 않을 계획이다. IBM의 소프트웨어 표준, 오픈소스, 클라우드 연구소 담당 부사장 에인젤 디아즈는 “우리는 오픈스택이 아파치 HTTTP 서버가 웹스피어에 했던 것과 같은 역할을 하기를 바란다. 모든 현대적인 애플리케이션 서버는 아파치 HTTP 코드를 가지고 있다. 이것이 바로 오픈스택이 클라우드에 대해 해주었으면 하는 역할이다”라고 설명했다.   오픈스택을 번들로 제공하는 첫번째 IBM 제품은 현재 베타 상태인 스마트클라우드 오케스트레이터로, 고객이 마우스 드래그 앤 드롭 인터페이스로 클라우드 서비스를 작성할 수 있도록 해 준다.   디아즈와 이야기를 나누기 전에 필자는 IBM이 오픈스택 개발에 그동안 얼마만큼의 영향력을 가지고 있는지 제대로 알지 못했다. IBM은 현재 3위의 코드 기여 기업으로, 특히 지난 가을 발표된 폴섬...

2013.03.12

회사명:한국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.5.0.9