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.

컨테이너

“대열 붕괴” 마이크로소프트, 자체 서비스 메시 OSM 발표

구글의 이스티오 서비스 메시에 대한 통제권을 두고 논쟁이 격화되고 있는 가운데, 마이크로소프트가 단순하고 진정한 개방형 대안을 제시할 기획을 잡았다. 마이크로소프트가 자체 오픈소스 서비스 메시인 OSM(Open Service Mesh)을 출시하고, 이를 가능한 한 빨리 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)에 넘겨줄 것이라고 발표했다.    이는 클라우드 경쟁업체인 구글과 차별화되는 결정으로, 구글은 최근 자사의 이스티오(Istio) 서비스 메시를 더 이상 업체 중립적인 CNCF의 일부로 두지 않고, 대신 구글의 자체 OUCF(Open Usage Commons foundation) 하에 둘 것이라고 발표했다. 서비스 메시는 현대적인 클라우드 네이티브 컴퓨팅 스택의 핵심 요소로 빠르게 자리 잡고 있는데, 서비스 메시가 본질적으로 오늘날의 마이크로서비스 기반 아키텍처에서 서로 분리된 요소 간의 커뮤니케이션과 모니터링, 로드밸런싱을 가능하게 하기 때문이다. 서비스 메시는 대중적인 인기를 얻고 있는 컨테이너 오케스트레이션 서비스인 쿠버네티스와는 세밀도 수준에서 차이가 있다. 쿠버네티스와 함께 구동하면, 서비스 메시는 더 심도있는 보안 정책과 암호화 강화, 자동화된 로드밸런싱, 서킷 브레이킹 등이 가능해진다. 오픈소스 소프트웨어와 통제권 문제에 대한 철학적 논쟁을 차치하고 마이크로소프트의 차별화 요소는 가능한 한 최대의 단순성을 제공하는 것이다. 마이크로소프트 애저 컴퓨트 제품 관리 디렉터이자 CNCF 이사회 위원인 게이브 몬로이는 “우리 고객이 하는 이야기는 이스티오와 같은 오늘날의 솔루션이 너무나도 복잡하다는 것이다”라고 지적했다. 몬로이는 또 “애저 쿠버네티스 서비스 지원 대기 고객의 데이터도 보고 있는데, 이걸 사용해 보고자 하는 고객들은 바로 이 지점에서 어려움을 겪고 있다. 사용하기 너무나도 어려운 기술이고, 대규모로 구축하기는 더더욱 어려운 기술이다”라고 덧붙였다...

서비스메시 이스티오 OSM 2020.08.10

통합된 사용자 환경을 위한 IBM Cloud Pak for Applications

IBM Cloud Pak for Applications는 기존 애플리케이션을 손쉽게 현대화하고 기업의 보안 및 기술 표준을 준수하며 빠르게 새 클라우드 네이티브 앱을 개발하기 위한 Red Hat OpenShift Container Platform 기반 솔루션입니다. <플레이 타임 : 7분 10초>

현대화 클라우드네이티브 오픈시프트 2020.08.10

"컨테이너 구현 관리, 서비스 형태로 성장한다" CaaS의 이점과 가능성

현대적으로 컨테이너화된 애플리케이션의 인기가 계속 높아지고 있다. 주요 업체가 컨테이너 인프라 및 관리를 서비스 형태로 제공하게 되는 것도 시간 문제일 뿐인 것 같다. 컨테이너는 전 세계 기업 시장에서 확고한 성장세를 기록하고 있다. 플렉세라(Flexera)의 최신 2020 클라우드 현황 보고서에 따르면 조직의 65%가 도커 컨테이너를 사용 중이며 58%는 쿠버네티스 오케스트레이션 시스템을 사용하고 있다. 컨테이너를 사용해서 애플리케이션을 구축하고 유지하는 데 있어 가장 큰 과제로 꼽히는 요소는 리소스와 전문 기술의 부족이다. 따라서 갈수록 많은 개발자들이 서비스형 컨테이너(CaaS)가 제공하는 자동화를 선택하고 있다. CaaS 시장은 현재 3개 주요 클라우드 업체가 주도하고 있다.     서비스형 컨테이너, 또는 CaaS란? CaaS에서 클라우드 업체는 큰 인기를 누리는 쿠버네티스 오픈소스 프로젝트(구글에서 시작된 프로젝트)를 기반으로 호스팅되는 컨테이너 오케스트레이션 엔진을 제공하여 컨테이너를 배포 및 실행하고 클러스터를 관리하고 확장과 장애 관리를 자동화하고 포함된 거버넌스 및 보안 기능을 통해 공통 인프라 계층을 유지한다. 일반적으로 모든 네트워크, 부하 분산, 모니터링, 로깅, 인증, 보안, 자동 확장, 지속적 통합/지속적 제공(CI/CD) 기능을 CaaS 플랫폼이 담당한다. CaaS를 사용하는 조직은 클라우드 인프라의 이점을 활용하는 동시에 AWS 엘라스틱 빈스토크(Elastic Beanstalk), 애저 앱 서비스, 구글 앱 엔진과 같은 일반적인 서비스형 플랫폼(Paas)에 수반되는 업체 종속도 피할 수 있다. 컨테이너 자체가 다양한 환경 전반에서 간단한 이식성을 구현하기 때문이다. 컨테이너로 방향을 정했다면 CaaS와 일반적인 서비스형 인프라(IaaS)에서 실행하는 방법 간의 차이점을 알아야 한다. 둘의 차이는 조직에 쿠버네티스(또는 다른 컨테이너 오케스트레이션 계층) 자체를 구현하고 관리하기 위한 리소스와 기술이 ...

컨테이너 퍼블릭클라우드 AWS 2020.07.30

IBM Power Systems에 OpenShift 컨테이너 환경 구축하기

클라우드 환경에서 빠른 개발과 서비스 적용을 위해 컨테이너가 매우 중요한 요소가 되었습니다. 컨테이너는 일종의 가상머신으로 기본적으로 영구 스토리지를 지원하지 않고 OS를 가상화하지 않기 때문에 매우 가볍고 빠른 배포가 가능하며, 서비스 단위의 모듈화도 가능합니다. 오늘 이 영상에서는 코드로써 인프라를 관리하고 그렇게 만들어진 OpenShift 클러스터의 pv(persistent volume)를 PowerVC의 볼륨으로 연결해보는 데모를 진행해보겠습니다. Terraform과 Ansible을 사용해 코드로써 인프라를 관리하고, 생성된 OpenShift 클러스터의 pv로 PowerVC의 볼륨을 붙여보는 데모로 이런 구조를 통해 OpenShift 내부의 컨테이너들은 OpenShift가 관리하고, OpenShift 클러스터 자체는 PowerVC에서 관리할 수 있게 됩니다. <15분>

PowerSystems 오픈시프트 컨테이너 2020.07.24

모놀리스로부터 마이크로서비스로의 이전을 위한 개발자 가이드

클라우드 네이티브 개발은 컨테이너 및 오케스트레이션 기반의 클라우드 배포를 통해 마이크로서비스를 이용하려는 조직에게 그 중요성이 점차 커지고 있습니다. 하지만 시간 및 비용상 요건으로 인해 모든 레거시 애플리케이션을 완전히 재작업하기란 거의 불가능합니다.  Red Hat의 단계별 클라우드 마이그레이션 접근 방식은 기존의 기능과 데이터를 최대한 다시 사용합니다. 이 프로세스는 기존 워크로드를 현대식 배포 플랫폼으로 이전하고, 궁극적으로 새로운 프로세스, 제품, 기술을 적용해 애플리케이션을 현대화합니다. 이와 함께 MicroProfile 사양을 구현하는 Thorntail, Spring Boot, Node.js 및 Eclipse Vert.x 등의 플랫폼으로 개발자가 제어하고 선택하여 클라우드에 마이크로서비스를 구현할 수 있습니다. <9p> 주요 내용 - 마이크로서비스로 리팩토링하기 위한 기능 분석  - Red Hat Runtimes  - 마이크로서비스를 위한 오픈소스 기술 선택 

클라우드네이티브 마이크로서비스 컨테이너 2020.07.02

마이크로서비스 디자인의 이점을 파악하는 방법 : 포레스터

마이크로서비스 디자인을 사용하여 소프트웨어를 개발하는 것은 인기 있는 새로운 접근법입니다. 왜 그럴까요? 마이크로서비스는 구현 유연성, 우수한 확장성, 빠른 제공 및 높은 복원력을 약속합니다. 그러나, 포괄적인 마이크로서비스 아키텍처는 대부분의 기업 AD&D 팀에게 너무 복잡하므로, 개발자는 새로운 프로그래밍 모델과 플랫폼 프레임워크를 통해 마이크로서비스 디자인의 이점을 얻을 수 있는 실용적이고 점진적인 방법을 찾고 있습니다. 이 새로운 방법과 그 영향에 대해 알아보려면 이 보고서를 읽으십시오. <21p> 주요 내용 - 마이크로서비스, 컨테이너 및 런타임을 통한 유연성 확보 - 마이크로서비스의 복잡성을 극복하는 세 가지 방법 - 오늘날의 프로그래밍과 플랫폼을 마이크로서비스에 적용하기 - 오늘날의 플랫폼에 새로운 프로그래밍 모델 채택 - 새로운 마이크로서비스 플랫폼에 새로운 프로그래밍 채택

마이크로서비스 컨테이너 포레스터 2020.06.02

쿠버네티스 파이프라인의 보안을 자동화하는 10단계

쿠버네티스 파이프라인을 대상으로 한 위협의 범위가 끊임없이 확장되면서 이제 애플리케이션 라이프사이클 전반적으로 더 통합되고 자동화된 보안이 필요하다. 빌드와 레지스트리, 테스트, 스테이징, 그리고 특히 피해가 큰 프로덕션 환경에 이르기까지 파이프라인의 어느 단계에서나 치명적인 취약점이 발생할 수 있다.  효과적인 쿠버네티스 파이프라인 보안을 가로막는 큰 장애물 중 하나는 시간을 투자해야 한다는 점이다. 컨테이너를 사용하는 목적은 릴리스 주기의 속도를 높이고 더 최신 코드와 더 나은 기능, 더 높은 리소스 안정화를 실현하는 것이다. 이 파이프라인에 보안을 집어넣기 위해 어떤 형태로든 수작업이 개입되면 속도가 저하되고 컨테이너 전략의 이점을 제대로 누리지 못하게 될 수 있다. 데브옵스팀에게 파이프라인의 속도 저하는 용납할 수 없는 일이다. 그런 이유로 자동화는 필수적일 뿐만 아니라, 컨테이너 보안을 위한 가장 현실적인 방법이기도 하다.    쿠버네티스 파이프라인 개요 간략하게 본 쿠버네티스 파이프라인과 각 단계에서의 주요 위협은 다음과 같다.   새로운 취약점은 이르면 빌드 단계부터 발생할 수 있다. 오픈소스 툴이 이전까지 알려지지 않은 공격 표면을 더하는 원인이 되는 경우가 많다. 레지스트리에서는 빌드 단계에서 성공적으로 취약점을 제거하고 깨끗한 이미지를 저장했더라도 이 이미지에 영향을 미치는 치명적인 취약점이 나중에 발견될 수도 있다. 프로덕션에서 실행되는 컨테이너에도 같은 상황이 발생할 수 있으며, 실제로 종종 발생한다. 프로덕션 환경에서 컨테이너, 핵심 툴 또는 쿠버네티스 자체가 공격을 받을 수 있다.  작년에 발생했던 치명적인 API 서버 취약점이 그 사례다. 이런 인프라는 모두 자동으로 모니터링하고 보호해야 하는 공격 영역이다. 또한 취약점을 잘 제거했더라도 제로데이 공격, 알려지지 않은 취약점 또는 내부자 공격의 위험은 여전히 남아 있다. 긍정적인 점은 쿠버네티스 파이프라인 전반에서 보안 전략을 통...

데브옵스 자동화 컨테이너 2020.05.29

흔히 저지르는 컨테이너 보안 실수 6가지와 예방법

클라우드로 데이터와 워크로드를 옮기는 조직이 늘어나면서 컨테이너에 대한 의존도도 높아지고 있다. 컨테이너는 애플리케이션을 다른 컴퓨팅 환경으로 옮기더라도 안정적으로 실행되도록 코드와 그 종속성을 패키지화한 소프트웨어 유닛이다. 미국 클렘슨대학 유전 및 생화학 학부 소속 클라우드 아키텍트인 콜 맥나이트는 컨테이너화는 애플리케이션과 서비스를 안전하게 배포하기 위한 견고한 기술로 부상했다고 말했다.   맥나이트는 도커(Docker), 싱귤러리티(Singularity)와 같은 컨테이너 엔진은 안전한 설치 책임을 개별 사용자에게 맡기는 대신 특정 애플리케이션을 위한 최선의 보안 정책을 구현하고 배포하는 수단을 제공한다면서 “쿠버네티스, 메소스, 도커 스웜과 같은 컨테이너 오케스트레이션 플랫폼은 컨테이너 배포와 실행에 특화된 보안 메커니즘을 통합했다. 그 결과, 쉽게 구성할 수 있는 컨테이너 개발 및 배포 생태계가 형성됐다”라고 말했다. 이와 같은 기술은 안전한 애플리케이션과 서비스를 제공하는 데 일반적으로 따르는 복잡성을 많은 부분 걷어내지만, 맥나이트는 개발팀이 이런 보안의 가능성을 보안을 보장하는 것으로 해석하는 경우가 있다고 지적했다. 문제는 컨테이너 구현 과정에서 실수를 할 수 있다는 것이다. 컨테이너를 사용하는 팀이 이러한 실수를 저지르면 보안 문제를 해결하는 게 아니라 오히려 유발하게 된다.   1. 컨테이너 자체에 지나치게 집중한다 맥나이트는 “안전한 컨테이너를 구현할 때 발생하는 가장 흔한 실수는 컨테이너 자체에 온전히 초점을 맞추는 것”이라고 말했다. 이미지의 보안을 위한 베스트 프랙티스를 유지하는 것도 중요하지만 개발자가 이미지가 실행되는 환경을 고려하지 않고 이미지의 보안에만 골몰하는 경우가 적지 않다. 맥나이트는 “컨테이너 내부의 보안이 아무리 강력해도 호스트의 컨테이너 악용으로부터 보호할 수는 없다. 컨테이너 엔진을 호스팅하는 각 시스템을 일반적으로 악용 가능한 취약점에 대비해 각 계층에서 보호해야 한다”고 강조했다. ...

호스트 컨테이너 도커 2020.05.11

2020 새로운 데이터 시대를 위한 IT 인프라 전략 “컨테이너 중심의 하이브리드 클라우드” - IDG Tech Insight

퍼블릭 클라우드와 온프레미스 환경을 가리지 않고 워크로드에 최적화된 인프라를 선택할 수 있는 하이브리드 클라우드가 빠르게 확산되면서, 애플리케이션의 자유로운 이동을 위한 컨테이너 기술에 대한 관심 또한 높아지고 있다. 하지만 컨테이너 기술은 이점만큼이나 복잡성이 가져오는 단점에 대한 우려도 적지 않다. 기업이 클라우드 도입을 주저하는 이유가 보안에서 복잡성으로 바뀌었다고 해도 과언이 아니다. 이 때문에 새로운 데이터 시대를 위한 IT 인프라는 컨테이너 기술의 이점을 십분 활용하면서도 과제와 한계를 현명하게 극복해야만 한다. 2020년의 클라우드와 컨테이너 기술 트렌드를 짚어보고, 델 테크놀로지스와 나무기술이 제안하는 해법을 살펴본다. 주요 내용 - 2020년 엔터프라이즈 클라우드 트렌드 5가지  - 컨테이너, 쿠버네티스, 그리고 IT의 중앙집중화  - 쿠버네티스 : 2020년 무대의 중심에 설 기술  - IT 책임자를 위한 성공적인 멀티 클라우드 전략 가이드  - AI GPU 학습 플랫폼 구축 사례로 보는 가상머신 기반 AI 컨테이너 구축 전략

컨테이너 AI gpu 2020.04.14

하이브리드 멀티클라우드를 위한 스토리지 현대화 전략 - IDG Tech Webinar

클라우드를 사용하지 않는 기업은 있어도 한 곳만 사용하는 기업은 없다는 말이 있다. 그만큼 하이브리드 멀티클라우드는 이른바 ‘뉴 노멀’이 되었다. 문제는 이런 환경을 제대로 활용하기 위해서는 기업의 IT에도 많은 변화가 필요하다는 것. 온프레미스부터 여러 퍼블릭 클라우드로 애플리케이션과 데이터가 흩어져 있기 때문에 기존의 구축 및 배치 방식으로는 IT의 임무를 제대로 달성하기 어렵다. 특히 온프레미스와 클라우드 간의 잦은 데이터 이동이 일상화되고 있는 상황에서 스토리지 역시 적지 않은 변화가 필요하다.  이번 웨비나는 민첩성부터 데이터 보호, 클라우드, 신기술 지원 등 스토리지의 핵심 요소를 살펴보고, 하이브리드 클라우드를 향한 기업의 여정에서 현대화된 스토리지가 어떤 역할을 하며, 또 이를 위해서는 어떤 스토리지가 필요한지 알아본다.  주요 내용 하이브리드 멀티클라우드 환경로의 전환 흐름 스토리지 소프트웨어의 중요성 하이브리드 멀티클라우드 환경을 위한 스토리지 소프트웨어 IBM Spectrum Virtualize의 특징과 구현 형태 IBM FlashSystem 제품군과 특징

하이브리드 컨테이너 멀티클라우드 2020.04.03

IDG 블로그 | 라즈베리 파이, 새로운 프라이빗 클라우드

라즈베리 파이는 작고 다재다능하고 저렴한 컴퓨터로 어디에나 쓸 수 있다. 이제는 프라이빗 클라우드로도 사용할 수 있다. 라즈베리 파이는 진짜 라즈베리 파이보다 더 싸다는 농담이 있다. 물론 파이 하나 먹는데 50달러나 100달러를 낼 사람은 없겠지만, 라즈베리 파이는 작은 크기에 네트워킹 기능을 갖추고 오픈소스 소프트웨어를 구동하는 매우 능력 있는 컴퓨터를 전문가는 물론 애호가에게도 부담없는 금액에 제공한다.   필자는 라즈베리 파이를 IoT 디바이스로 몇 년째 사용하는데, 데이터를 모으고 저장하고 처리하고 전송할 수 있으며, 필요하면 데이터에 반응할 수도 있다. 그래서 많은 사람이 라즈베리 파이를 모터사이클 주행 안전기 프로젝트와 기타 완전히 새로운 IoT/엣지 개발 프로젝트 등에 사용하고 있다. 그런데 라즈베리 파이의 사정이 좀 바뀌었다. 필자는 k3s 프로젝트를 행복한 마음으로 보고 있는데, 이 프로젝트는 “자원이 극히 제한된 환경”에서 사용할 경량화된 쿠버네티스 배포판을 만든다. 오픈소스이고 ARM 프로세서에 최적화되어 있다. 무엇보다도 k3s는 라즈베리 파이 전용으로 만들어진 쿠버네티스 배포판이기 때문에 라즈베리 파이 기반 쿠버네티스 클러스터를 실현할 수 있다. 물론 그만큼의 제약도 있다. 클라우드 아키텍트는 이 기술을 이용해 쿠버네티스 클러스터를 중앙집중화된 클라우드에서 구동하는 컨테이너에 배치하는 것이 아니라 데이터 소스와 좀 더 가까이 있는 소형 컴퓨터에 배치할 수 있다. 애플리케이션은 퍼블릭 클라우드 플랫폼과 수백 수천 대의 k3s 구동 라즈베리 파이 사이에 뿌려지겠지만, 클러스터는 여전히 긴밀하게 통합되어 있다. 이는 분명 수천 가지 사용례를 가진 엣지 컴퓨팅의 한 형식이 될 것이다. 이 아키텍처 패턴이 필자를 놀라게 한 것은 저렴한 엣지 기반 디바이스가 경량화된 프라이빗 클라우드처럼 동작한다는 것이다. 이들 디바이스는 자원을 필요한 만큼 프로비저닝하고 컨테이너와 쿠버네티스 같이 많이 사용되는 플랫폼을 사용한다....

배포판 컨테이너 프라이빗클라우드 2020.03.16

비자가 컨테이너 보안 솔루션을 "자체적으로" 구축한 방법

금융 서비스 시장의 대기업인 비자(Visa)도 다른 많은 대기업과 마찬가지로 컨테이너화(containerization) 기술을 도입했다. 컨테이너화는 레거시 모놀리식 앱을 사용하는 기업이 클라우드 인프라에서 대규모로 관리, 업데이트, 배포하기가 더 용이한 마이크로서비스 기반 애플리케이션 아키텍처로 전환할 수 있게 해준다.   비자의 보안 팀은 여러 상용 솔루션을 조합해 이를 자체 환경에 맞춰 운영하느라 리소스를 소비하는 대신 기본으로 돌아가 보안 정책 시행, 사고 탐지 및 교정을 위한 지속적 모니터링 솔루션을 자체적으로 개발했다.  비자는 이 프로젝트로 우수한 보안에 수여되는 CSO50 상을 수상했다. 매시업(Micro-services based Adaptive Security Hardening and Usage Platform, MASHUP)으로 불리는 이 솔루션은 파일시스템 액세스 컨트롤, SE리눅스(SELinux) 정책, 그리고 cgroups(control groups)와 같은 기존 컨테이너 오케스트레이션 플랫폼에 이미 있는 기본 기능을 활용하며 주로 오픈소스 툴과 라이브러리를 기반으로 만들어졌다. 만들기 대 구매하기 비자가 기존 공급업체의 상용 솔루션을 구매하는 대신 자체 보안 플랫폼을 만들기로 한 데는 여러 가지 이유가 있다. 첫째, 컨테이너 기반 인프라와 컨테이너화된 앱을 위한 보안 솔루션을 제공하는 공급업체의 상당수가 신생 업체라는 점이다. 신생 업체의 경우 대규모 조직이 기대하는 성숙도 표준을 아직 충족하지 못하는 경우가 많다. 또한 컨테이너를 위한 모니터링 및 보호 기능이 일부 조직에는 불필요한, 훨씬 더 넓은 범위의 기능 집합에 포함된 제품도 있다. 비자는 10%의 필요한 기능을 위해 나머지 90%의 불필요한 기능까지 함께 구매하기는 원하지 않았다. 비자가 솔루션을 직접 만들기로 한 또 다른 중요한 이유는 개발 유연성(flexibility)과 민첩성(agility)이다. 플랫폼에 대한 통제권을 온전히 손에 쥔다는...

Visa 컨테이너 비자 2020.03.12

실험 단계 넘어 주류로 진입하는 컨테이너

에디슨이 전구를 발명할 당시 가장 어려운 문제는 램프와 소켓을 결합하고 분리하는 것이었다. 이런 불편을 개선한 에디슨 스크류는 오늘날까지 거의 모든 전구를 책상 램프든 샹들리에든 대부분의 조명기구에 돌려서 끼울 수 있는 표준이 되었다.  10년 전 솔로몬 하익스의 도커 컨테이너 발명도 비슷한 효과를 낳았다. 어떤 리눅스 앱이든 패키징을 한번 하면 모든 리눅스 운영체제의 모든 도커 컨테이너에 연결할 수 있고, 번거로운 설치가 필요 없다. 더 좋은 건 여러 컨테이너화된 앱이 운영체제의 단일 인스턴스에 연결되고, 각 앱은 다른 앱과 안전하게 격리되어 도커 API를 통해 OS와만 통신할 수 있다는 점이다.  이 공유 모델은 물리적 컴퓨터에서 클라우드와 같은 방식으로 애플리케이션을 배포하고 확장하기 위한 기존의 수단인 가상머신보다 훨씬 가벼운 스택을 제공했다. 실제로 가볍고 휴대성이 뛰어나기 때문에 개발자는 노트북에서 여러 컨테이너화된 앱을 작업하고, 테스트 및 배포를 위해 선택한 플랫폼에 업로드할 수 있다. 또한 일반적으로 부팅 시 1분 정도 걸리는 가상머신과는 달리 컨테이너화된 앱은 눈 깜짝할 사이에 시작한다. 그러나 컨테이너의 실제 영향을 파악하려면 애플리케이션 아키텍처의 마이크로서비스 모델을 이해해야 한다. 많은 애플리케이션이 API를 통해 서로 통신하는 작은 단일 목적의 서비스로 세분화되어, 각 마이크소서비스를 독립적으로 업데이트하거나 확장할 수 있는 장점이 있다(전체 변경 사항을 가져와 수정해야 하는 전통적인 모놀리식 애플리케이션에 비해 편리하다). 알고보니, 마이크로서비스와 컨테이너는 서로 완벽하게 잘 맞는다.  그러나 컨테이너화된 마이크로서비스를 애플리케이션으로 함께 사용하려면 어떻게 해야 할까? 바로 여기에서 최소한 더 큰 마이크로서비스 애플리케이션에 쿠버네티스가 역할을 한다. 이 오픈소스 오케스트레이션 엔진을 사용해 마이크로서비스 기반 애플리케이션을 배치, 관리, 확장하고 가용성을 보장할 수 있다. 또한 필요한 경우 ...

가상머신 컨테이너 캠도커 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.10

“데스크톱용 컨테이너가 온다” 윈도우 10X에 거는 기대

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

데스크톱 컨테이너 듀얼스크린 2020.03.10

IDG 블로그 | 컨테이너 기반 클라우드 개발의 “스테이트”

대부분 애플리케이션은 스테이트풀(Stateful) 애플리케이션이다. 여기서 ‘스테이트풀’이란 말은 사용자가 영화를 보다가 말고 다른 디바이스로 바꿔도 스트리밍 서비스에서 그 부분을 기억한다는 것을 의미한다. 모바일 앱이 사용자의 속성이나 최근에 열었던 파일을 저장하는 것도 마찬가지다. 애플리케이션 수준에서는 중단된 세션을 복구하는 역량을 의미한다. 데이터 손실 없이 사용자를 원래 위치로 데려다주는 것이다.   기존의 세상은 스테이트풀의 세상이다. 스테이트풀 애플리케이션은 ‘스테이트(State, 상태)’를 기억하는데, 이 스테이트는 여러 세션에 걸쳐서 지속성을 갖는다. 그래서 스테이트 데이터는 데이터베이스를 포함하는 물리 스토리지처럼 휘발성 없는 방식으로 저장한다. 그런데 컨테이너는 이 스테이트 유지에 관한 새로운 도전과 기회를 불러왔다. 컨테이너 세상은 ‘스테이트리스(Stateless)’로 알려져 있다. 컨테이너 설계의 기본 개념은 컨테이너가 인스턴스로 등장해서 프로그래밍된 대로 작업을 하고 스테이트를 유지하지 않고 사라지는 것이다. 필요할 때는 일부 외부 소스로부터 데이터를 가져와 작업할 수도 있는데, 데이터는 다른 프로세스나 서비스로부터 넘겨받고 작업이 끝난 후에는 데이터가 메모리에서 삭제되기 전에 다른 프로세스로 돌려준다. 여전히 스테이트는 유지하지 않는다. 핵심 문제는 컨테이너가 스테이트 정보를 저장할 수 없다는 것이다. 컨테이너는 원래 그렇게 만들어졌다. 영구 스토리지 개념이 없으니 스테이트를 유지하는 것은 불가능하다. 이 때문에 초기에 컨테이너는 스테이트 유지가 필요없는 워크로드 전용으로 알려졌다.. 일각에서는 여전히 컨테이너 기반 애플리케이션을 구축할 때는 ‘스테이트리스’라야 한다고 주장한다. 가장 깔끔한 접근법일 뿐만 아니라 스테이트풀 애플리케이션은 구시대 모델이라는 생각이다.  하지만 컨테이너를 사용하는 기업 개발자 대부분은 동의하지 않는다. 전통적인 애플리케이션은 컨테이너에 맞춰 설계하고 구축하지 않기 때문이다....

state 컨테이너 스테이트풀 2020.03.09

IDG 블로그 | 컨테이너가 정말로 좋은 선택일까?

451 리서치의 최신 보고서에 따르면, 애플리케이션 컨테이너 시장은 2016년 7억 6,200만 달러 규모에서 2020년에는 27억 달러 규모로 성장한다. 전체 클라우드 기술 시장에서는 작은 비중에 불과하지만, 애플리케이션 컨테이너는 2020년 40%의 높은 성장률을 기록할 것이다.   이런 성장에는 과대 포장과 실질적인 수요, 그리고 선도업체에서 이룬 약간의 성공이 뒤섞여 있다. 클라우드 컴퓨팅 기술 스택에는 컨테이너가 유효한 곳이 많다. 다시 말해, 컨테이너는 애플리케이션을 클라우드로 옮기거나 클라우드에서 완전히 새로운 애플리케이션을 구축할 때 직면하는 핵심 문제를 해결한다. 바로 이식성과 확장성, 개방성, 일관성이다. 하지만 컨테이너가 모든 문제의 해법은 아니다. 컨테이너와 컨테이너 오케스트레이션(쿠버네티스)의 가장 큰 문제는 이 기술을 잘못 적용하는 것이다. 세 가지 문제를 살펴보자. 1. 애플리케이션 아키텍처가 핵심이다. 컨테이너에 코드를 넣고 실행하는 것은 어렵지 않다. 하지만 컨테이너는 애플리케이션 아키텍처가 컨테이너를 염두에 두고 설계되었거나 컨테이너에 맞춰 변경되었을 때 가장 잘 동작한다. 컨테이너는 본질적으로 분산 처리 지향적이다. 최적의 방식으로 컨테이너를 사용하기 위해서는 보통 애플리케이션을 변경하거나 분해할 수 있어야 한다. 게다가 애플리케이션이 데이터와 긴밀하게 묶여 있다면, 애플리케이션에서 데이터를 분리하지 않는 한 컨테이너로 성공하기 어렵다. 2. 컨테이너는 전통적인 애플리케이션 개발보다 비용이 더 많이 든다. 컨테이너 기술을 활용하기 위해 필요한 애플리케이션의 변경은 이른바 “컨테이너세(Container Tax)”의 일부이다. 애플리케이션을 컨테이너에 맞춰 수정하거나 컨테이너 지향적인 새 애플리케이션을 구축하는 데 드는 추가 비용이다. 정확한 숫자를 계산하기는 어렵지만, 필자의 경험상 평균 35%는 더 든다. 물론 35%의 추가 비용은 컨테이너를 통해 얻는 이식성과 확장성, 민첩성으로 보상된다. 기업마다 환경...

확장성 컨테이너 오케스트레이션 2020.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.