int(0)
Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

컨테이너

구글 고의 위력을 보여주는 10가지 오픈소스 프로젝트

세상에 나온지 10년째인 구글 고(Go) 프로그래밍 언어는 그동안 확고한 입지를 다졌다. 구글 고가 큰 인기를 끈 이유는 가볍고 빠른 컴파일 속도와 함께 동시 및 분산(즉, 클라우드) 애플리케이션 개발을 쉽게 해주는 풍부한 라이브러리와 추상화에 있다. 그러나 프로그래밍 언어의 성공을 판가름하는 진정한 척도는 개발자들이 그 언어로 만드는 프로젝트다. 구글 고는 네트워크 서비스, 소프트웨어 인프라 프로젝트, 다양한 종류의 컴팩트하고 강력한 툴을 위한 빠른 개발에서 가장 유력한 언어임을 입증했다.   여기서 소개하는 오픈소스 프로젝트는 모두 구글 고로 작성되었으며, 이 중 상당수는 구글 고 언어 자체보다 더 유명해졌다. 10가지 모두 각각의 영역에서 중대한 성과를 거뒀다. 여기 나온 모든 프로젝트는 깃허브에 호스팅되므로 구글 고 언어에 대해 알아보고자 하는 사람이라면 누구나 코드를 살펴볼 수 있다.   도커(Docker) 도커만큼 구글 고의 성공을 잘 보여주는 사례를 찾기는 어렵다. 소프트웨어 컨테이너화 기술인 도커는 약 1년 전부터 대규모 분산 소프트웨어 프로젝트에서 구글 고의 적합성을 보여주는 대표적인 사례로 부상했다. 도커 팀은 종속성 없는 정적 컴파일, 강력한 표준 라이브러리, 완비된 개발 환경, 최소한의 번잡함으로 여러 아키텍처에 맞는 빌드 기능 등 많은 혜택을 제공한다는 이유로 구글 고를 선택했다.   쿠버네티스(Kubernetes) 도커를 필두로 다른 여러 클라우드 지향 컨테이너 프로젝트 역시 구글 고로 만들어졌다. 구글의 컨테이너 오케스트레이션 프로젝트인 쿠버네티스와 그 하위 구성 요소 및 생태계의 대부분도 구글 고로 만들어졌다. 대표적인 예가 기본적인 쿠버네티스만 필요하고 그 외에는 일체 필요 없는 사람들을 위한 초경량 쿠버네티스 스핀오프인 k3s다. 구글은 쿠버네티스를 만들 때 C/C++, 자바, 파이썬을 포함한 다른 언어도 고려했다. 그러나 쿠버네티스의 공동 창립자이자 전 기술 리드이며 현재 VM웨어의 수석 엔지...

프로그래밍 라이브러리 컨테이너 2019.10.11

IDG 블로그 | 마이크로서비스의 도전에 대비하라

지난 주 필자는 퍼블릭 클라우드의 내외부 모두에서 컨테이너가 점점 더 인기 있는 공격 대상이 되고 있다고 지적했다. 이번에는 컨테이너의 공통적인 부산물인 마이크로서비스에 대해 좀 더 자세히 살펴보자. 마이크로서비스는 애플리케이션을 배치하는 아키텍처이자 방법이다. 실제로 마이크로서비스란 용어는 컨테이너 내에서건 아니건 애플리케이션을 조각조각 분해해 더 작고 전문화된 부분의 연속으로 만드는 관행을 설명하는 용어로 사용된다. 각각의 마이크로서비스는 API나 REST 인터페이스 같은 공용 인터페이스를 통해 다른 마이크로서비스와 커뮤니케이션할 수 있다. 이 접근법이 완전히 새로운 것으로 보이지만, SOA 시절로 돌아가 보면 미립자(Fine-grained) 서비스라는 것이 있었다. 마이크로서비스는 자체적으로 구축할 수도 있고, 아니면 서비스로 이용할 수도 있다. 실제로 SaaS 서비스 업체는 로컬 또는 클라우드 기반 애플리케이션에 통합할 수 있는 자체 마이크로서비스 카탈로그를 제공한다. 마이크로서비스를 추가한다는 것은 이를 컨테이너 기반 애플리케이션 및 전통적인 서비스 지향 애플리케이션과 통합하는 것은 물론, 적절하게 테스트해야만 한다는 것을 의미한다. 마이크로서비스는 보안 테스트와 운영이라는 측면에서 몇 가지 핵심적인 과제를 안고 있다. - 마이크로서비스는 보안을 포함한 테스트가 어렵다. 각각이 별도의 API라는 점에서 독립적으로 테스트해야만 한다. 마이크로서비스와 컨테이너에 전문화된 툴을 사용할 수도 있지만, 명령줄 테스트 툴이라면 모두 잘 동작할 것이다. - 마이크로서비스는 빈번하게 바뀐다. 사이버 보안 전문가는 이런 변경이 취약점을 가져온다고 지적할 것이다. 마이크로서비스는 흔히 원격지 호스트에 의해 변경된다. 예를 들어, 국제 운송료와 관세를 계산하는 마이크로서비스는 비즈니스 또는 기술적인 이유로 수시로 바뀐다. 이런 마이크로서비스를 운영하기 위해서는 프로덕션을 중단하거나 보안 문제를 일으키지 않으면서 새로운 서비스를 도입할 수 있는 방안이 마련되어야 ...

취약점 SOA 컨테이너 2019.10.10

IDG 블로그 | 클라우드 보안, 컨테이너 취약점 노린 공격을 막아라

보안 전문업체 스카이박스 시큐리티(Skybox Security)가 2019년 취약점 및 위협 트렌드 보고서를 발표했다. 이름에서 알 수 있듯이 이 보고서는 2019년 상반기 동안 보안 공격에 이용된 컴퓨터 취약점을 분석했다.   이번 보고서에서 주목할만한 것은 클라우드 컨테이너의 취약점이 빠르게 증가하고 있다는 것이다. 수많은 기업이 컨테이너 및 컨테이너 오케스트레이션을 도입하는 상황에서 나쁜 소식이 아닐 수 없다. 보고서에 따르면, 2019년 상반기 컨테이너 소프트웨어의 취약점은 전년 동기 대비 46% 증가했다. 2년 전과 비교하면 무려 240%나 늘어났다. IT 책임자가 해야 할 일은 무엇일까? 과거 어느 때보다 많은 컨테이너가 사용되고 있다는 것은 분명한 사실이다. 컨테이너의 이런 성장세는 계속될 것이며, 따라서 어떤 시스템의 취약점이라도 크게 부풀려질 것이다. 희소식이 있다면, 올 상반기에 밝혀진 7,000개 이상의 취약점 중 악용된 것은 약 650개로 일부에 불과하다는 것. 더구나 대규모 공격에 악용된 취약점은 1%도 되지 않는다. 물론 새로운 컨테이너가 끊임없이 프로덕션 환경에 배치되고 있기 때문에 1%라도 걱정하지 않을 수 없다. 이 문제의 핵심에는 날로 높아지는 클라우드 컴퓨팅 플랫폼의 복잡성이 있다. 클라우드는 현재 퍼블릭 클라우드는 물론 프라이빗 클라우드, 전통적인 컴퓨팅 플랫폼까지 수많은 환경에서 구동하는 컨테이너로 구성되어 있다. 컨테이너가 오케스트레이션과 페더레이션으로 옮겨가면서 복잡성과 함께 보안 위험도 높아질 가능성이 크다. 이기종 인프라를 줄여서 복잡성을 줄이는 방안을 선택하기 어렵다면, 필자가 제안하는 대응 방안은 다음과 같다 -    배치된 컨테이너 기반 애플리케이션에 제대로 된 암호화가 적용된 경우가 드물다. 컨테이너 간은 물론이고 컨테이너와 외부와의 연결도 마찬가지다. 암호화 자체는 복잡성을 높이는 요인일 뿐만 아니라 성능에도 영향을 미치겠지만, 대부분 위험 요소를 막을 수 있...

취약점 암호화 페더레이션 2019.10.07

시스코, 애저 클라우드와 손잡고 하이브리드 쿠버네티스 전략 확장

시스코가 자사 솔루션 기반의 온프레미스 환경과 마이크로소프트 애저 클라우드에 걸쳐 컨테이너화된 애플리케이션을 실행할 수 있는 서비스를 출시했다.    이제 기업 고객은 온프레미스 환경과 AKS(Azure Kubernetes Service)의 쿠버네티스 클러스터 배치와 관리를 하나의 툴로 더욱 단순화할 수 있다. 특히 AKS는 기존에도 시스코 컨테이너 플랫폼(Cisco Container Platform)에 통합할 수 있는 쿠버네티스 매니지드 서비스에 추가되어 있었다. 시스코는 2018년 1월 쿠버네티스 기반의 컨테이너 플랫폼을 도입했으며, 컨테이너 클러스터의 셀프서비스 배치와 관리를 지원했다. 시스코는 이 플랫폼에 여러 솔루션 업체에 대한 지원을 추가했는데, 예를 들어 SAP 데이터 허브를 AWS나 마이크로소프트, 구글과 같은 퍼블릭 클라우드에 있는 대규모 데이터 세트와 통합하고, 이를 또 프라이빗 클라우드나 SAP S/4 HANA와 같은 엔터프라이즈 애플리케이션과 통합할 수 있도록 지원한다. 구글이 처음 개발한 쿠버네티스는 컨테이너화된 애플리케이션의 개발과 오케스트레이션을 위한 오픈소스 기반 시스템이다. 컨테이너를 여러 대의 서버 호스트에 걸쳐 배치할 수 있는데, 쿠버네티스 오케스트레이션이 여러 컨테이너에 걸쳐 배치되는 애플리케이션 서비스를 구축할 수 있도록 해 준다. 클러스터 전반에 걸쳐 이들 컨테이너의 스케줄을 조정하고 컨테이너와 확장과 상태 관리까지 맡아준다. 시스코는 한동안 애저 서비스와의 통합을 강화해 왔다. 예를 들어 애저 스택용 CIS(Cisco Integrated System)는 기업이 개발 툴과 데이터 저장소 및 관련 애저 서비스에 액세스해 애플리케이션을 새단장하거나 안전한 데이터로부터 새로운 정보를 얻을 수 있다. 애저 스택은 애저 퍼블릭 클라우드와 같은 API와 사용자 인터페이스를 제공한다. 시스코 컨테이너 플랫폼은 앞으로 마이크로소프트 윈도우 컨테이너 애플리케이션을 지원하는 더 많은 기능을 통합할 계획이다. 특...

컨테이너 시스코 애저 2019.08.05

AWS·애저·구글 클라우드의 '관리형' 쿠버네티스 서비스 비교

첫 번째는 컨테이너, 그 다음이 쿠버네티스였다. 세상은 컨테이너화된 애플리케이션을 배포, 관리, 스케일링(축소 및 확장)하는 지겹고 복잡한 작업을 도와줄 구원 투수를 원했다. 그리고 마침내 쿠버네티스가 도움의 손길을 내밀었다. 쿠버네티스의 성장 이유 중 하나는 온프레미스, 클라우드 모두에서 쿠버네티스 클라우드를 실행할 수 있다는 점이다. 나아가 둘 모두를 오갈 수 있다. 즉 환경 간 컨테이너 앱을 이식할 수 있다. 이런 장점 때문에 주요 유명 퍼블릭 클라우드 업체가 모두 관리형 쿠버네티스 서비스를 제공한다. 회사 컨테이너를 클라우드로 옮기기만 하면 클라우드 업체가 나머지를 알아서 처리한다. 그러나 각 클라우드에 고유의 특징이 존재하듯, 쿠버네티스 서비스에도 이런 고유의 특징이 있다. 여기서는 쿠버네티스 플러그인 생태계를 통해 클라우드 스토리지 및 기타 서비스를 지원하는 방식을 중심으로, 아마존과 구글, 마이크로소프트의 호스팅 쿠버네티스 서비스의 특징을 비교, 분석해보자. 아마존 EKS(Elastic Kubernetes Service) AWS는 2014년 말 아마존 일래스틱 컨테이너 서비스(ECS)로 컨테이너를 지원하기 시작했다. 이후 AWS EC2 인스턴스에서 도커를 실행할 수 있게 됐다. 지금은 ECS를 통해 EC2나 서버리스 상품인 AWS 파게이트(AWS Fargate) 중 하나에 도커를 배포할 수 있다. 그리고 몇 년 뒤(일반에 공식 배포된 시기는 2018년 6월) EKS로 쿠버네티스를 지원하기 시작했다. EKS 도입 이전에 AWS에서 쿠버네티스를 실행하는 유일한 방법은 많은 EC2 인스턴스를 스핀업해 수동으로 클러스터를 구성하는 것이었다. 그러나 EKS 도입 이후 쿠버네티스 클러스터를 더 쉽게 실행할 수 있게 됐다. 이제 EC2에 워커 노드를 배포한 후 관리 노드로 연결하면 된다. 아마존은 사용자가 여러 다양한 EC2 인스턴스에서 작업 노드를 실행할 수 있도록 지원한다. 예를 들어, 비용을 절약하기 위해 수요가 낮은 백그라운드 작업은 EC2...

컨테이너 애저 AWS 2019.07.24

IDG 블로그 | 클라우드 환경의 컨테이너 데브옵스를 위한 3가지 팁

클라우드에서 데브옵스가 대유행이다. 데브옵스의 속도와 항상 개선되는 프로세스, 툴체인에 엄청난 확장성과 자체 구성이 가능한 퍼블릭 클라우드 엔드포인트를 합치면, 애플리케이션의 구축이나 변경에 대한 필요성과 실제 프로덕션에 배치하는 사이에 아무런 지연이 없는 환경을 구현할 수 있다.   엄청난 비즈니스 이점을 얻는 공식이라고 해도 과언이 아니다. 컨테이너와 컨테이너 오케스트레이션을 도입하면, 클라우드 네이티브 기능을 추출할 기회가 늘어나고 고도로 분산되고 이식성을 내재한 애플리케이션을 만들 수 있다. 수년간 데브옵스와 컨테이너, 클라우드를 한 데 섞는 작업을 하면서 얻은 교훈 몇 가지를 공유한다. 우선, 자사의 데브옵스 툴체인을 위한 새로운 툴이 필요하다. 모든 데브옵스 툴이 컨테이너와의, 그리고 컨테이너 지원 애플리케이션 라이프사이클과의 호환성을 주장하지만, 필자는 보통은 다른 툴세트가 필요하다는 것을 알게 됐다. 서로 다른 툴을 다양하게 사용하면 데브옵스가 복잡해지지만, 어쨌든 서로 다른 구현 기술을 이용해야 한다는 점에서 실제로 다른 선택안이 없다. 베스트 오브 브리드 방식을 찾아야 한다. 두 번째, 성능 테스트에 중점을 두라. 엉성하게 설계한 컨테이너 기반 애플리케이션은 잘 동작하지 않는다. 실제로 성능은 필자가 컨테이너 애플리케이션의 품질을 평가할 때 최우선으로 살펴보는 요소이다. 열악한 성능은 보통 열악하게 분산된 컨테이너 때문이다. 서로 다른 처리 패턴을 하나의 컨테이너에 집어넣은 것이다. 컨테이너는 분산되도록 설계된다. 많은 사용자가 너무 적은 컨테이너에 너무 많은 기능을 집어넣는 실수를 저지른다. 이럴 때는 컨테이너 오케스트레이션을 이용해도 문제가 사라지지 않는다. 좋은 컨테이너 애플리케이션 설계와 아키텍처가 필요한 이유이다. 컨테이너 애플리케이션 설계를 위한 적절한 프로시저와 베스트 프랙티스를 깨우친 애플리케이션 아키텍트를 찾는 것이 아니다. 기존 애플리케이션을 컨테이너화하든, 완전히 새로운 애플리케이션을 설계하든 마찬가지...

아키텍처 컨테이너 오케스트레이션 2019.07.15

IDG 블로그 | “컨테이너 세금”에 주의하라

컨테이너는 애플리케이션을 클라우드에 배치하는 참신하고 편리한 방법이지만, 추가 비용이 있다는 것을 잊어서는 안된다.   컨테이너는 애플리케이션 개발에서 있어서 몇 가지 기본적인 특징과 이점이 있다. 이점은 다음과 같다. -    컨테이너 추상화를 통해 복잡성을 줄여준다. 애플리케이션의 기반 플랫폼이 아니라 컨테이너를 다루면 된다. -    자동화를 통해 이식성을 극대화한다. 한 번 작성해서 여러 곳에서 실행할 수 있는 것이다. -    컨테이너 외부에 대해 더 나은 보안과 거버넌스를 제공한다. -    컨테이너의 핵심 아키텍처 양식이 분산화이기 때문에 분산 컴퓨팅 역량을 개선할 수 있다. -    정책 기반의 최적화를 제공하는 자동화 서비스를 제공한다. -    쿠버네티스 같은 컨테이너 오케스트레이션을 사용할 수 있다. -    컨테이너를 지원하는 수많은 서비스 및 솔루션 업체의 생태계를 이용할 수 있다. 컨테이너의 문제는 모두가 컨테이너를 사용하고자 하지만, 아무도 컨테이너를 구축하고 배치하는 데 드는 추가 비용을 모른다는 것이다. 실제로 필자는 새 애플리케이션이나 기존 애플리케이션을 컨테이너로 옮기거나 구축하는 데 평균 35% 추가 비용이 드는 것으로 보고 있다. 도대체 어디에 이런 비용이 드는 것일까? 주요 항목은 다음과 같다. 첫째, 컨테이너 설계에 손이 많이 간다. 따라서 초기 설계나 컨테이너로 옮기고자 하는 기존 애플리케이션의 리팩터링에 더 많은 시간을 사용하는 것이 합리적이다. 둘째, 툴 비용이 더 든다. 컨테이너 기반의 툴은 무료 툴 외에 데이터베이스 액세스나 보안, 거버넌스를 제공하는 툴이 전통적인 툴보다 50% 정도 더 비싸다. 물론 유용한 툴은 중요하지만, 비용도 고려해야 할 것이다. 마지막, 컨테이너는 운영과 유지보수 비용이 더 든...

아키텍처 컨테이너 추가비용 2019.06.05

"쿠버네티스와 컨테이너의 변화를 이끈다" 가장 믿음직한 쿠버네티스 배포판 10선

쿠버네티스(Kubernetes)는 대규모 컨테이너 오케스트레이션이 필요한 경우 최적의 프로젝트로 꼽힌다. 구글이 만들어낸 오픈소스 컨테이너 시스템 쿠버네티스는 업게의 인정과 지원을 통해 빠르게 발전하고 있다. 쿠버네티스는 또한, 제멋대로 뻗쳐 나가며 복잡하고 설정 및 구성이 어렵다. 그 뿐만 아니라 최종 사용자가 많은 힘든 일을 처리해야 한다. 따라서 최고의 접근방식은 혼자서 시도하는 것이 아니라 쿠버네티스가 지원되고 유지보수되는 구성요소에 포함된 완전한 컨테이너 솔루션을 찾는 것이다. 리눅스 커널과 유저랜드의 배포판을 제공하는 것과 같은 방식으로 쿠버네티스와 컨테이너 도구를 통합하는 가장 유명한 쿠버네티스 서비스 9개를 모았다. 아마존 EKS나 구글 쿠버네티스 엔진 같은 전용 클라우드 서비스는 포함되어 있지 않고, 로컬이나 클라우드 방식으로 운용할 수 있는 소프트웨어 배포판에 초점을 맞췄다.   코어OS 테크토닉/레드햇 코어OS 코어OS는 도커와 호환되면서 독선적인 이미지 포맷과 자체적인 런타임을 갖추고 있는 컨테이너 지향적인 리눅스 배포판과 "기업용 쿠버네티스" 배포판의 제공 기업이다. 코어OS 테크토닉 스택의 근간을 이룬다.  코어OS 운영체제인 컨테이너 리눅스는 일련의 컨테이너화된 구성요소로 제공되기 때문에 확실히 다르다. 실행 중인 애플리케이션을 종료하지 않고도 자동화된 OS 업데이트를 생산에 배치할 수 있다. 또한 코어OS는 "원클릭" 쿠버네티스 업데이트를 자랑한다. 코어OS 테크토닉은 AWS, 마이크로소프트 애저, 베어 메탈에서 구동한다.  레드햇은 최근 코어OS를 인수해 레드햇 오픈시프트에 통합할 계획이다. 컨테이너 리눅스는 레드햇 코어OS로 브랜드 이미지를 쇄신할 것이다. 이 움직임은 2020년까지 끝나지 않을 것으로 예상되지만 컨테이너 리눅스는 그때까지도 계속 지원될 것이다. 레드햇에 따르면 통합 후에도 "거의 모든" 코어OS 테크토닉의 기능을 사용할 수 있...

레드햇 컨테이너 도커 2019.05.17

새로운 애저 서비스의 핵심은 쿠버네티스와 코스모스 DB

마이크로소프트는 스스로 세 클라우드 회사라고 지칭하기 시작했다. 엑스박스 게이밍 클라우드, 마이크로소프트 365 업무 생산성 서비스, 그리고 가장 중요한 애저가 바로 그 세 클라우드이다. 아마존 웹 서비스(AWS)에 이은 업계 2위의 애저는 초거대 규모의 클라우드로, 미처 따라잡기 힘든 속도로 서비스를 속속 출시하고 있다. 이 속도는 마이크로소프트 3대 개발자 행사에서 더욱 잘 드러나는데, 개발자라면 쏟아져 나오는 발표 내용을 철저히 살펴 봐야 핵심 요소들을 파악할 수 있다.   마이크로소프트가 확실히 주력하고 있는 것은 서버리스 애플리케이션 구축 플랫폼으로서의 애저이다. 이를 통해, 가상머신을 지정할 필요가 없고 초 단위 CPU 사용 시간 별로 비용을 청구하는 인프라 서비스를 제공한다. 애플리케이션에는 머신러닝, 분석, 저장, 연산 등이 가능하도록 매우 다양한 플랫폼 서비스가 자리하고 있다.  상황이 흥미로워지는 곳은 2가지가 만나는 지점이다. 즉, 단일 애저 리전 내에서나 애저 퍼블릭 클라우드 전체에 걸쳐 코드의 확장성을 개선하기 시작하는 지점이다. 분산 애플리케이션은 수작업 구축이 쉽지 않다. 마이크로소프트는 익숙한 도구와 새로운 기능을 모두 활용하여 확장성 자동화 방식을 더 많이 제공한다.   쿠버네티스에서의 이벤트 주도 규모 조정  애저는 다른 대형 퍼블릭 클라우드처럼 쿠버네티스에 크게 의존한다. 하이퍼스케일 연산 작업 시에는 분산 애플리케이션의 관리와 조율이 필수적이다. 이 때, 애플리케이션을 고립된 컨테이너로 제공하면 구축 시스템으로부터 완전한 인프라를 제공하는 절차가 단순해진다. 단, 쿠버네티스는 복잡할 수 있다. 간단한 이벤트 주도 애플리케이션용으로 사용할 때 특히 그렇다. 자바스크립트로 조율되는 쿠버네티스를 갖춘 브리게이드(Brigade)를 쓰는 방법이 있다. 단, 이벤트를 트리거시키거나 요구에 따라 새로운 서버리스 기능을 시작하기 위해 애저의 이벤트그리드(EventGrid)와 같은 도구를 사용 중이...

컨테이너 애저 코스모스 2019.05.10

IDG 블로그 | 쿠버네티스로 클라우드 복잡성 줄이는 방법

쿠버네티스는 보안이나 인프라용으로는 너무 과하게 사용하지만, 자동화용으로는 너무 적게 사용한다. 정말 필요한 사람들이 그 잠재력을 제대로 알지 못한다. 한참 전에 필자는 쿠버네티스가 컨테이너 오케스트레이션 전쟁의 승자라고 선언한 바 있다. 물론 필자의 예견이 맞아서 좋지만, 클라우드 업계의 많은 사람이 쿠버네티스를 모든 문제를 해결하는 최종 병기 기술의 틀에 끼워 넣고 있다. 이 때문에 모든 보안 문제, 모든 인프라 문제를 해결하는 데 쿠버네티스를 과용하고 있으며, 심지어 차기 전략 아이템을 찾고 있는 IT 업체를 위한 완결판 전략이 되기도 한다. 모든 것이 쿠버네티스인 것이다.   클라우드 컴퓨팅 실전 전문가로서, 그리고 쿠버네티스를 온프레미스 환경에서 퍼블릭 클라우드에서 이용하는 사람으로 필자는 쿠버네티스의 장점은 모두 사실이라고 말할 수 있다. 하지만 마찬가지로 필자는 사람들이 쿠버네티스를 2020년에 직면하게 될 핵심적인 문제, 즉 클라우드 복잡성을 해결하는 데 도움이 되는 기술로 고려하지 않는다는 사실도 말할 수 있다. 클라우드 복잡성을 유발하는 원인은 크게 두 가지이다. 첫 번째는 클라우드 플랫폼을 선택할 때 이기종 기술의 과용하는 것이다. 멀티클라우드는 좋은 개념이긴 하지만, 수천 가지 네이티브 API를 두세 가지 인수로 하나의 통일된 플랫폼으로 넣는 것은 개발자는 물론 운영팀의 일을 몹시 힘들게 만든다. 두 번째, 적절한 계획없이 클라우드 솔루션을 배치하는 것이다. 최소한의 위험으로 멀티클라우드 솔루션을 배치하는 데는 최소한의 이해가 필요하다. 현재 무엇을 하고 있고 어떤 방법으로 어디로 가려는지 잘 알고 있어야 한다. 대부분 기업은 이런 질문에 대답하지 못하고 반동적인 상태에서 계속 운영한다. 이런 클라우드 복잡성에 대한 해결책도 두 가지이다. 우선, 추상화가 있다. 최소 공통분모 접근법으로 추상화 계층을 사용해 클라우드 네이티브 툴과 인터페이스를 직접 처리하는 복잡성을 제거하는 것이다. 두 번째는 자동화이다. 인터페...

복잡성 컨테이너 쿠버네티스 2019.05.03

도커 엔터프라이즈 3.0, 안전한 쿠버네티스 스택 통합

도커는 안전한 쿠버네티스 스택을 통합한 도커 엔터프라이즈 3.0을 베타 버전으로 발표했다. 또한 도커 엔터프라이즈의 매니지스 서비스 옵션도 공개했다. 도커 엔터프라이즈는 컨테이너 기반 애플리케이션을 구축하고 실행하고 공유하는 엔드 투 엔드 플랫폼으로 자리 잡고 있다. 새 버전의 도커 쿠버네티스 서비스(Docker Kubernetes Service, DKS)는 쿠버네티스 컨테이너 오케스트레이션을 개발자의 데스크톱에서 프로덕션 서버로 통합한다.   DKS는 쿠버네티스 YAML, 헬름 차트, 도커 컴포즈 툴을 이용해 멀티컨테이너 애플리케이션을 생성할 수 있다. 또한 쿠버네티스 애플리케이션을 하이브리드 및 멀티클라우드 배치 환경에 설치하고 환경을 구성하는 자동화된 방법을 제공한다. 이외에도 보안, 액세스 제어, 라이프사이클 관리 등의 기능을 갖추었다. 도커 엔터프라이즈 고객은 오케스트레이션을 위해 도커 스웜을 사용할 수도 있다. 매지니드 서비스 옵션인 Docker Enterprise-as-a-Service는 캡제미니(CapGemini)와 협력관계를 통해 도커 엔터프라이즈를 온프레미스 또는 퍼블릭 클라우드에 서비스로 배치할 수 있다. 매니지드 서비스는 온디맨드 방식의 확장과 사용량 기반의 과금을 이용한다. 이외에 도커 엔터프라이즈 3.0의 주요 특징은 다음과 같다. - 도커 데스크톱 엔터프라이즈(Docker Desktop Enterprise)는 도커 허브 생태계 액세스와 통합된 이미지 레지스트리를 제공하는 일련의 자동화 툴이 특징이다. 기업용 쿠버네티스 환경으로의 배치도 지원한다. - 도커 애플리케이션(Docker Applications)는 어떤 인프라에도 배치할 수 있는 단일 패키지로 멀티컨테이너 애플리케이션을 정의한다. 개발자와 운영팀은 관련 컨테이너 그룹을 정의해 특정 애플리케이션 상에서 협업할 수 있다. 이 기능은 CNAB(Cloud Native Application Bundle) 표준을 기반으로 한다. 도커 컴포즈, 헬름 차트, 쿠버네티스...

컨테이너 도커 쿠버네티스 2019.05.02

How To : 컨테이너 보안을 개선하는 방법

가트너가 컨테이너 보안(container security)을 올해 가장 우려되는 10가지 요소 가운데 하나로 지정했다. 그만큼 주의를 기울이고 견실한 보안 구현 계획을 마련하는 것이 좋다는 의미다. 컨테이너는 약 10년 전에 처음 등장했지만 가벼움과 재사용 가능한 코드, 유연한 기능, 낮은 개발 비용 등의 장점에 힘입어 갈수록 인기를 얻고 있다. 이번 기사에서는 데브옵스/빌드 환경을 보호하는 데 필요한 툴, 컨테이너 자체를 위한 툴, 그리고 모니터링/감사/규정 준수를 위한 툴을 살펴볼 것이다. 물론 어느 한 가지 툴로 모든 작업을 할 수는 없다. 기본적인 단계부터 시작하자 1. 클라우드 업체가 제공하는 툴 확인 첫 번째 단계는 현재 사용 중인 클라우드 업체가 제공하는 기본 보안 툴에 대해 알아보는 것이다. 애저 보안 센터(Azure Security Center), 구글 쿠버네티스 엔진(Google Kubernetes Engine), 구글 클라우드 보안 커맨드 센터(Google Cloud Security Command Center), 아마존 인스펙터(Amazon Inspector) 등이 포함된다. 애저 보안 센터와 같은 일부 보안 툴은 컨테이너 전용이 아닌 범용 보안 툴이다. 2. 네이티브 도커 관련 보안 기능 익히기 여기에는 리소스 오남용 방지를 위한 정책을 사용하고 액세스 제어 그룹을 설정하고 불필요한 루트 액세스 권한을 제거하는 작업이 포함된다. 3. 깃허브 오픈소스 프로젝트  코드에서 보안 모범 사례를 확인하는 벤치 시큐리티(Bench Security)와 같은 프로젝트, 그리고 seccomp(secure computing mode)와 같은 리눅스 네이티브 툴은 저렴한 비용으로 이용할 수 있다. 다른 오픈소스 툴에 대해서는 후설할 것이다. 알고 익혀야 할 소프트웨어가 많아서 부담이 되겠지만 특히 관심을 기울여야 할 몇 가지 공통적인 기능이 있다. 사용자와 최종적으로 빌드하려는 앱, 두 가지 모두에 대한 ID 및 인증, 그리고 이 액세스 권한...

컨테이너 보안 2019.04.17

“클라우드 파운드리에 쿠버네티스 통합” 이리니 프로젝트 테크 프리뷰

이제 이리니(Eirini)를 IBM의 테크 프리뷰 형식으로 이용할 수 있다. 이리는 클라우드 애플리케이션 플랫폼인 클라우드 파운드리(Cloud Foundry)에 쿠버네티스 컨테이너 관리 플랫폼을 통합하는 오픈소스 프로젝트이다.   클라우드 파운드리 재단 내의 육성 프로젝트인 이리니는 클라우드 파운드리 애플리케이션 런타임(Cloud Foundry Application Runtime)용 플러그인 방식 스케줄링을 지원한다. 이리니를 사용해 클라우드 파운드리 사용자는 애플리케이션 컨테이너 인스턴스의 오케스트레이션에 디에고(Diego)와 쿠버네티스 중 선택할 수 있다. 쿠버네티스를 선택하면 클라우드 파운드리 애플리케이션이 OCI 이미지와 쿠버네티스 디플로이먼트(Kubernetes Deployments)를 사용해 쿠버네티스 백엔드에 배치된다. 그동안 클라우드 파운드리 애플리케이션 런타임의 기본 스케줄러는 디에고였다. 이리니 프로젝트의 목표는 사용자가 어떤 스케줄러를 선택하더라도 같은 경험을 얻을 수 있도록 하는 것이다. IBM 클라우드의 IBM 이리니 프리뷰는 이 기술의 상용 구현물에 대한 초기 액세스를 제공한다. 구성요소는 다음과 같다. - OPI(Orchestrator Provider Interface). 다중 스케줄러에 대한 선언적 추상화를 제공한다. OPI는 디에고 LRP/Task 모델과 보시 CPI 개념에 영향을 받았다. - Bifrost. 애플리케이션 전용 클라우드 컨트롤러 요청을 변환해 쿠버네티스에서 구동하는 OPI 전용 객체로 전송한다. - Stager. 쿠버네티스/OPI 일회성 태스크를 구동해 스테이징을 구현한다. 이리니는 깃허브에서 다운로드할 수 있다. IBM의 클라우드 파운드리용 쿠버네티스 스케줄러는 IBM 클라우드에서 이용할 수 있다.  editor@itworld.co.kr

컨테이너 클라우드파운드리 IBM 2019.04.12

구글, 안토스로 하이브리드 전략 강화…인텔•HPE•레노버와 협력

클라우드 사업이 아직 한자릿수 점유율을 넘지 못하고 있는 구글이 하이브리드 클라우드 전략을 강화하기 위해 레노버, 인텔과 맺은 새로운 협력관계를 소개했다. 두 업체와의 협력관계는 모두 구글의 쿠버네티스 컨테이너 기술을 기반으로 한다.   이번 주 열린 구글의 넥스트 ’19 행사에서 인텔과 구글은 구글 안토스(Anthos)를 기반으로 협업하기로 했다고 밝혔다. 안토스는 퍼블릭 클라우드와 프라이빗 클라우드 환경 간의 워크로드 이식성을 높이기 위한 새로운 레퍼런스 디자인으로, 최근 발표된 인텔의 2세대 제온 스케일러블 프로세서와 최적화된 쿠버네티스 소프트웨어 스택을 기반으로 한다.  안토스 발표의 일환으로 HPE 역시 자사 프로라이언트 서버 제품군에서 안토스의 유효성을 확인했다고 밝혔다. 레노버도 자사 씽크애자일 플랫폼 상의 안토스를 인증했다. 이 솔루션은 고객이 구글 클라우드와 온프레미스 HPE 서버나 레노버 서버 간의 일관성 있는 쿠버네티스 경험을 제공한다. 델 EMC는 아직 공식적인 발표가 없지만, 조만간 뒤를 따를 것으로 보인다. 사용자는 퍼블릭 클라우드와 온프레미스 모두에 걸친 여러 환경의 쿠버네티스 클러스터를 관리하고 정책을 일관성 있게 적용할 수 있다. 또한 안토스는 구글이 검증을 마친 운영체제와 컨테이너 런타임을 포함하는 완전히 통합된 소프트웨어 스택을 제공해 사용자는 안심하고 클러스터를 업그레이드할 수 있으며, 다운타임을 최소화할 수 있다. 안토스는 기존 클라우드 서비스 플랫폼(Cloud Service Platform)으로, 사용자가 쿠버네티스 클러스터를 구축하고 관리하고 운영하는 데 시간을 들이지 않고 컨테이너화된 애플리케이션을 구동할 수 있다. 구글 클라우드 플랫폼과 구글 쿠버네티스 엔진은 물론 데이터센터의 GKE 온프렘에서도 구동할 수 있다. 안토스는 또한 AWS나 애저 같은 서드파티 클라우드에서 구동하는 워크로드도 관리할 수 있다. 구글은 안토스 마이그레이트(Anthos Migrate)의 베타 버전도 발...

인텔 컨테이너 구글 2019.04.11

구글 클라우드 런, "컨테이너의 이식성과 서버리스의 속도 결합"

구글 클라우드 런은 스테이트리스 컨테이너를 매니지드 컴퓨트 서비스나 구글 쿠버네티스 엔진에 배치할 수 있도록 해준다. 구글이 클라우드 런(Cloud Run) 서비스를 추가하며 서버리스 컴퓨트 옵션을 확장했다. 클라우드 런은 매니지드 컴퓨트 서비스의 하나로, HTTP 요청으로는 기동할 수 있는 스테이트리스 컨테이너를 구동할 수 있다. 또한 구글 쿠버네티스 엔진에서도 이용할 수 있는데, 이를 통해 컨테이너화된 HTTP 워크로드를 매니지드 쿠버네티스 클러스터에서 구동할 수 있다.   클라우드 런이 개발자에게 가져다 주는 장점은 컨테이너의 이식성과 서버리스 컴퓨팅의 속도이다. 현재 베타인 클라우드 런은 자동화된 프로비저닝 및 워크로드 확장 기능을 제공하며, 사용자는 컨테이너가 실제로 사용한 자원에 대해서만 비용을 내면 된다. GKE에서는 스테이트리스 HTTP 워크로드를 기존 쿠버네티스 클러스터에서 구동할 수 있으며, 사용자는 맞춤 머신 종류와 구글 컴퓨트 엔진 네트워크에 액세스할 수 있다. 같은 클러스터에서 서로 다른 워크로드를 나란히 구동할 수도 있다. 개발자는 어떤 개발언어라도 사용할 수 있으며, 툴과 의존성도 사용자의 선택에 달렸다. 클라우드 런은 케이네이티브(Knative)를 기반으로 하는데, 케이네이티브는 사용자가 서버리스 워크로드를 쿠버네티스 플랫폼에 걸쳐 옮길 수 있ㄴ느 오픈 API 및 소프트웨어 계층이다. 구글 클라우드 플랫폼과 GKE는 물론 쿠버네티스를 구동하는 어떤 플랫폼이라도 상관없다. 클라우드 런의 핵심 기능은 다음과 같다. - 서비스 배치 및 관리를 위한 명령어줄 및 사용자 인터페이스 - 배수 기반의 트래픽 자동 확장. GKE 상에서 구동할 때는 자동 확장이 클러스터 내로 제한된다. - 개발 언어와 운영체제 라이브러리를 선택할 수 있고 자체 라이브러리도 사용할 수 있다. - 컨테이너 워크플로우와 표준을 이용할 수 있다. 클라우드 런은 클라우드 빌드, 컨테이너 레지스트리, 도커 등과 짝을 지을 수 있다. - 리던던시 제공. 서...

컨테이너 구글 서버리스 2019.04.10

미래의 자바와 JVM, ”GPU와 컨테이너 정조준”

오라클은 미래 자바 개발은 빅데이터와 머신러닝, 클라우드 네이티브 워크로드용 언어와 런타임 지원을 개선하는 데 중점을 둘 것이라고 밝혔다.   향후 자바 개발 언어 개발은 GPU와 컨테이너를 포함한 현대적인 컴퓨팅 플랫폼 지원에 중점을 둘 것이라고 오라클이 밝혔다. 특히 오라클의 계획은 자바가 GPU와 하드웨어 가속에 대한 강력한 지원을 제공한다는 것을 강조하는데, 이는 머신러닝과 인공지능 워크로드 지원의 핵심 요소이다. 오라클의 자바 SE 개발팀은 자바를 그런 방향으로 구성해 JVM이 어떤 워크로드는 GPU에서 구동하고 어떤 워크로드는 CPU에서 구동해야 하는지를 알 수 있도록 하고자 한다. 이미지 처리를 위해 만들어진 GPU는 점점 더 많은 수치 처리 애플리케이션과 머신러닝, 심지어 데이터베이스에도 사용되고 있다. 오라클은 JVM 또한 컨테이너 환경의 제한적인 자원을 이해할 필요가 있다고 설명했다. 컨테이너 지향 최적화는 더 빠른 기동뿐만 아니라 성능 향상도 포함한다. 자바 개발팀이 제시한 또 다른 기회와 목표는 다음과 같다. - 자바의 크기를 가능한 한 줄여 워크로드를 최소의 자원 소비와 전력으로 구동한다. - 빅데이터를 위한 확장성을 제공해 페타바이트 규모를 지향한다. - 대규모 환경에서의 예측 가능성 - 데이터 집적도와 JVM에서의 데이터 프리젠테이션 최소화 - 네이티브 액세스. 인공지능과 머신러닝 영역의 라이브러리 액세스 역량 - JVM의 데이터 입출력을 더 쉽고 효율적으로 - 개발자 생산성과 지속적인 언어 개선 오라클은 다수의 혁신적인 자바 프로젝트로 주목을 받았는데, 가상머신 및 언어기능용 인큐베이터 프로젝트인 발할라(Valhalla)와 비 자바 API 액세스용 파나마(Panama), 애플리케이션에서의 동시성 처리를 쉽게 하는 룸(Loom) 등이다. 오라클은 또 자바 마무리 기능의 점진적인 제거도 언급했는데, 가비지 컬렉터가 처리할 수 없는 객체의 사후 제거 수행용이다. 마무리 기능은 컬렉터가 추가 과정을 수행해야 하기 때문...

자바 인공지능 가속기 2019.03.26

IDG 블로그 | 잘 알려지지 않은 컨테이너의 장점과 단점

성능부터 확장성, 이식성을 추구하는 기업의 전투 구호는 “우리는 컨테이너를 사용한다”이다. 물론 일부는 실제로 그렇게 되기도 하지만, 한계도 있다. 컨테이너가 실제로 기업에 가져다주는 가치와 그렇지 않은 것을 살펴보자.   컨테이너의 장점 여러 기술적 이점을 넘어서 컨테이너는 많은 기업이 잘 알지 못하는 이점을 제공한다. 컨테이너는 추상화를 통해 복잡성을 줄여준다. 컨테이너는 사용하는 주된 이유는 컨테이너는 애플리케이션의 클라우드 네티이브화 작업을 요구하지 않는다는 것이다. 컨테이너 자체는 플랫폼일 뿐이다. 이는 컨테이너가 복잡한 네이티브 인터페이스를 관리하지 않아도 되고, 그래서 특정 클라우드 플랫폼에 종속되지 않아서 다른 환경으로 이식할 수 있다는 것을 의미한다. 컨테이너는 자동화에 좋다. 자동화는 수작업 스크립트를 대체하며, 더 나은 이식성을 제공한다. 컨테이너는 더 나은 보안과 거버넌스를 제공한다. 보안과 거버넌스는 플랫폼에 특화된 것으로 밝혀졌고, 컨테이너 밖에서도 최고 수준을 유지한다. 전체적인 복잡성을 줄이면서도 보안과 거버넌스를 중앙집중화할 수 있다는 의미이다. 컨테이너는 분산 컴퓨팅에도 뛰어나다. 컨테이너를 사용하면, 애플리케이션을 컨테이너 및 컨테이너 클러스터, 도메인으로 나눌 수 있다. 인트라클라우드(Intracloud)와 인터클라우드(Intercloud)를 포함해 애플리케이션을 구동할 플랫폼을 선택할 수 있는데, 이는 비용과 성능을 최적화할 수 있다는 의미이다.  컨테이너는 정책 기반 최적화를 지원한다. 자동화 계층을 사용하면, 최적의 플랫폼을 골라 실행하는 것은 물론 자동으로 해당 플랫폼으로 이전할 수도 있다. 또한 환경 설정 변경도 자동으로 처리할 수 있다. 컨테이너 오케스트레이션은 생각보다 유용하다. 쿠버네티스는 컨테이너를 클러스터로 확장하고 관리할 수 있도록 해준다. 또한 생태계가 되어 툴과 기술을 제공해 컨테이너 개발과 배치도 더 쉬워진다.   컨테이너의 단점 그렇지...

클러스터 복잡성 컨테이너 2019.02.26

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

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

Copyright © 2022 International Data Group. All rights reserved.