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.

컨테이너

“FaaS를 넘어 엣지로” 차세대 엣지 서버리스 아키텍처의 현황과 전망

서버리스 서비스는 어디에나 있다. 새로운 프로그래밍 방식을 향한 진화의 원동력인 서버리스 환경은 애플리케이션 호스팅 플랫폼, 서버리스 데이터베이스, CDN(Contents Delivery Network), 보안 솔루션 등등 모든 형태로 구현되고 있다. 인프라 수준의 환경 구성, 확장 및 프로비저닝에 대한 우려는 사라졌으며, 분산만이 마지막 문제로 남아 있다. 이 문제의 해결책으로 등장한 것이 바로 엣지 서버리스(Edge Serverless)로, 데이터와 컴퓨트를 수많은 데이터센터에 걸쳐 분산 배포한다. 엣지 서버리스는 컴퓨팅을 사용자와 더 가까운 곳으로 가져와 지연시간을 줄일 수 있다.   엣지 서버리스는 거의 15년 전에 IaaS(Infrastructure-as-a-Service)로 시작된 클라우드 아키텍처 진화의 정점이다. 클라우드 진화의 다음 단계는 서버리스 ‘빌딩 블록’의 분산을 촉진하고 개발자가 더 쉽게 소비할 수 있도록 하는 것이다. 서버리스 아키텍처는 현재 어디에 있는지, 어디로 향하는지 좀 더 자세히 살펴보자.    계층화 아키텍처 IaaS(Infrastructure as a Service) 클라우드 컴퓨팅 혁명은 IaaS의 등장으로 본격화되었다. IaaS를 통해 기업은 로컬 인프라를 호스팅된 ‘클라우드’ 인프라로 옮겨 운영할 수 있다. 사용한 스토리지와 컴퓨팅 시간에 대해서만 비용을 지불하며, 어떠한 하드웨어나 네트워크도 설치하거나 관리할 필요가 없다. 처음에는 IaaS가 비싸 보였지만, 일반 기업은 구현할 수 없는 수준의 가용성을 보장했기 때문에 빠르게 확산됐다. 실제로 자체적으로 인프라를 구매하고 유지하는 비용이 IaaS 서비스 요금보다 비싼 경우가 많았다. 가장 큰 장점은 하드웨어 유지보수와 프로비저닝이 필요없기 때문에 개발자가 비즈니스 가치에만 집중할 수 있다는 것이다. PaaS(Platform as a Service) 그 후 서비스 업체는 클라우드 컴퓨팅을 한 단계 더 발전시켜 PaaS를 제공했다....

CDN 아키텍처 엣지 2020.02.18

필드에서 바로 적용 가능한 애플리케이션 현대화 방법론

애플리케이션 현대화 기업들은 시장 출시 시간 단축과 애플리케이션 현대화의 압력에 직면해 있습니다. 또한 기존의 자산을 현대화하기 위한 최적의 접근 방식도 결정해야 합니다. 컨테이너, 쿠버네티스 및 마이크로서비스는 속도와 단순성을 제공할 수 있음을 입증하였으며 신속하게 도입되고 있습니다. IBM과 함께라면 이 모든 과정이 간편해집니다. 본 백서에서는 필드에서 바로 적용 가능한 IBM의 애플리케이션 현대화 접근방법론을 단계적으로 설명합니다. <32p> 주요 내용 - 애플리케이션 현대화의 개념 이해 - 애플리케이션 현대화로 가는 여정의 모든 팁 - 현대화 과정과 단계별 설명 : 애플리케이션 인벤토리부터 리팩토링, 클라우드 전환까지 - IBM의 독자적인 접근 방법론

마이그레이션 컨테이너 현대화 2020.02.13

쿠버네티스와 도커를 백업하는 방법

컨테이너 인프라에도 일종의 백업이 필요하다. 재해가 발생한 후 쿠버네티스와 도커가 스스로 재건되지는 않기 때문이다. 각 컨테이너의 실행 상태를 백업할 필요는 없지만 컨테이너를 실행하고 관리하는 데 사용되는 구성은 백업해야 한다. 백업해야 할 요소를 간단히 요약해 보자.   구성과 원하는 상태 정보 이미지를 만드는 데 사용되는 도커파일(Dockerfile)과 이 파일의 모든 버전 도커파일에서 생성되어 각 컨테이너를 실행하는 데 사용되는 이미지 쿠버네티스 etcd 및 기타 : 클러스터 상태에 대한 정보를 저장하는 K8s 데이터베이스 배치 : 각 배치를 설명하는 YAML 파일 컨테이너에 의해 생성 또는 변경되는 영구 데이터 영구 볼륨 데이터베이스   도커파일 도커 컨테이너는 이미지에서 실행되며, 이미지는 도커파일에서 작성된다. 적절한 도커 구성이라면 일반적으로 깃허브와 같은 리포지토리를 모든 도커파일의 버전 제어 시스템으로 사용한다. 애드혹 도커파일로 만든 애드혹 이미지를 사용해서 애드혹 컨테이너를 만들어서는 안 된다. 모든 도커파일은 현재 빌드에서 문제 발생 시 과거 버전을 가져올 수 있는 기능을 제공하는 리포지토리에 저장해야 한다. 또한 각 K8s 배치와 연결된 YAML 파일을 저장할 리포지토리도 필요하다. 이와 같은 YAML 파일은 버전 제어 시스템을 활용할 수 있는 텍스트 파일이다. 백업해야 할 대상은 이 리포지토리다. 가장 많이 사용되는 리포지토리 중 하나는 깃허브다. 깃허브는 리포지토리를 백업할 수 있는 여러 가지 방법을 제공한다. 제공된 API를 사용해서 리포지토리의 현재 백업을 다운로드하는 다양한 스크립트가 있고, 깃허브나 기타 사용 중인 리포지토리를 백업하기 위한 별도의 상용 툴도 있다. 이런 권장사항과 달리 도커파일이 더 이상 없는 이미지를 기반으로 컨테이너를 실행 중이라면, docker image history 명령, 또는 dfimage와 같은 툴을 사용해서 현재 이미지에서 도커파일을 만들 수 ...

백업 컨테이너 도커 2020.01.20

'빅 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 다이앤 그린의 관리하에서는 그 격차가 줄어들 기미가 보이지 않았다. 지난해 세간의 이목을 끈 여러 차례의 ...

레드햇 구글 CFF 2020.01.09

글로벌 칼럼 | 컨테이너, 백업이 필요한가

컨테이너(Containers) 백업이 항상 필요한 것은 아니지만, 값 비싼 손실을 막기 위해 도커(Docker)와 기타 컨테이너를 백업해야 하는 상황이 있다.    컨테이너가 곳곳에서 백업 관행을 깨고 있지만 데이터센터에 일어날 수 있는 최악의 상황으로부터 컨테이너 인프라의 가장 중요한 부분을 보호하기 위해 활용할 수 있는 방법이 있다.  컨테이너는 백업할 필요가 없을 것 같지만, 자세히 살펴보면 재해급 사태는 물론 이보다 덜한 여러 사고에 대비해 보호하기 위해 컨테이너도 백업하는 것이 좋다. 컨테이너의 기본 컨테이너는 가상화의 한 유형이며, 이 가운데 도커는 가장 인기 있는 컨테이너 플랫폼이다. 컨테이너는 특정 애플리케이션을 실행할 수 있는 특수한 환경이다. 가벼운 가상 머신이라고 표현할 수도 있다.  하이퍼바이저 서버의 각 VM에는 운영체제의 전체 사본이 포함되는 반면, 컨테이너는 기반 운영체제를 공유하며 각 컨테이너에는 해당 컨테이너에서 실행되는 애플리케이션에 필요한 라이브러리만 포함된다. 그 결과 단일 노드(OS와 컨테이너 런타임 환경을 실행하는 물리적 또는 가상 머신)에서 컨테이너가 점유하는 리소스는 같은 수의 VM에 비해 훨씬 적다. VM과 컨테이너의 또 다른 차이점은 기업에서는 보통 하나의 VM에 다수의 애플리케이션을 동시에 실행하는 경향이 있는 반면, 컨테이너는 일반적으로 로깅, 모니터링과 같은 하나의 작업을 수행하는 하나의 애플리케이션 구성요소를 제공하도록 설계된다는 점이다.  여러 애플리케이션 구성요소가 상호작용해야 하는 경우 각 구성요소는 일반적으로 자체 컨테이너에서 실행되면서 네트워크를 통해 통신한다. 이로써 각 애플리케이션을 개별적으로 확장하고 애플리케이션 간의 결함 및 보안 격리도 가능하다. VM은 특정 하드웨어에서 실행되는 특정 하이퍼바이저 내에서 실행되지만 컨테이너는 훨씬 더 이식성이 높다. 컨테이너는 사실상 모든 리눅스 시스템에서 실행되며 적절한 소프트웨어만 설치하면 윈도...

백업 컨테이너 쿠버네티스 2020.01.07

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

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

복구 백업 컨테이너 2019.12.20

Cloud Paks : 비즈니스 애플리케이션을 클라우드로 빠르고 안전하게 전환하는 개방형 솔루션

신규 클라우드 네이티브 애플리케이션을 구축하거나 클라우드 환경을 지원하기 위해 기존 애플리케이션을 현대화하는 두 가지 전략 모두, 특정 기술이나 업체에 종속되지 않으면서 가치 대비 소요 시간을 단축할 수 있으려면, 이동이 가능하고 개방된 방식으로 진행해야 합니다. 이 때문에 현재 기존 기업 워크로드의 80%는 아직 클라우드로 이전되지 못했으며, 기업들은 클라우드에서의 이동, 연결 및 관리에 어려움을 겪고 있습니다. Cloud Paks는 최신 Kubernetes 기반 오케스트레이션 플랫폼에서 우수한 컨테이너 기반 엔터프라이즈 소프트웨어를 실행하는 강력하면서도 간편한 방법을 제공합니다. 이 문서에서는 이 모델이 제공하는 부가적인 가치를 중심으로, 기본적으로 적용된 개방형 기술에 대한 전반적인 세부사항을 포함한 개념으로 Cloud Paks을 설명합니다. 주요 내용 - 더 많은 워크로드를 더 빨리 클라우드와 AI로 이전하는 IBM의 해결책 - 컨테이너 형태로 엔터프라이즈 소프트웨어 배치 및 관리 간소화 - 프로덕션 환경에 적합한 이미지 구축 - 손쉽게 사용 가능한 완전한 모듈형 기능

자동화 인공지능 컨테이너 2019.12.19

이벤트 중심 워크로드를 위한 쿠버네티스 자동 확장

쿠버네티스는 다양한 형태로 사용할 수 있는, 분산 시스템 구축을 위한 강력한 툴이다. 다만 한 가지 큰 문제는 설계상 쿠버네티스는 리소스 기반 확장만 제공한다는 점이다. 사실 쿠버네티스의 역사를 보면(AWS에 대응하기 위한 구글 내부의 보그(Borg) 서비스에서 시작됨) 이해하지 못할 것도 없다. 쿠버네티스가 목표로 한 애플리케이션과 서비스의 대부분은 리소스에 얽매이고 대량의 데이터를 다루며 메모리와 CPU에 의존했기 때문이다.   분산 애플리케이션이라고 해서 모두 그렇지는 않다. 많은 애플리케이션, 특히 IoT 시스템과 연동하는 애플리케이션은 이벤트에 신속하게 대응해야 한다. 여기서 가장 중요한 요소는 수요에 따라 프로세스를 트리거하는 이벤트와 메시지를 제공하는 I/O다. 이른바 서버리스 컴퓨팅과 잘 맞는 모델이다. 서버리스 모델의 대부분은 수요에 따라 새로운 컴퓨팅 컨테이너를 신속하게 가동하는 데 의존하는데, 이 모델은 자체 컨트롤러가 있는 전용 가상 인프라에서 잘 작동하지만 쿠버네티스의 리소스 중심 확장과의 호환성은 그다지 좋지 않다.   KEDA: 쿠버네티스 기반 이벤트 중심 자동 확장 마이크로소프트와 레드햇은 쿠버네티스에 이벤트 중심 확장성을 추가할 방법을 개발하기 위해 협력해왔고, 그 결과로 2019년 5월 마이크로소프트 빌드(Build) 컨퍼런스에서 오픈소스 KEDA 프로젝트를 발표했다. 이 초기 KEDA 코드는 나온 직후부터 많은 관심을 끌었는데, 최근에는 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 채택을 목적으로 하는 1.0 버전이 공개됐다. KEDA는 아무 쿠버네티스 클러스터에서나 실행할 수 있으며, 확장을 이끄는 데 사용할 수 있는 새로운 메트릭스 집합을 지원한다. 이제 CPU와 메모리의 부하에만 대응하지 않고 이벤트의 수신 속도에도 대응할 수 있고, 덕분에 큐 지연과 이벤트 데이터 손실 위험이 줄어든다. 메시지 볼륨과 CPU 수요는 직접적으로 연결되지 않으므로 KE...

컨테이너 쿠버네티스 서버리스컴퓨팅 2019.11.29

“현실과 만난 쿠버네티스” 블룸버그, 뉴스 UK, 아마데우스 사례 연구

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

사례 컨테이너 오케스트레이션 2019.11.28

IDG 블로그 | ‘올 컨테이너’는 나태한 클라우드 아키텍처

그랜드 뷰 리서치에 따르면, “전 세계 애플리케이션 컨테이너 시장 규모는 2018년 15억 달러이며, 2019년에서 2025년까지 연평균 26.5% 성장할 것으로 예상된다.” 다른 리서치 회사의 전망 역시 크게 다르지 않다.   굳이 애널리스트의 보고서를 볼 필요도 없다. 기업이 클라우드 기반 플랫폼으로 빠르게 이전하면서 요즘 필자가 참여하는 거의 모든 프로젝트가 컨테이너를 핵심 요소로 두고 있다. 이런 경향을 탓할 수는 없다. 이식성, 확장성, 더 나은 멀티클라우드 지원이 쿠버네티스 같은 컨테이너 기반 구현 기술에 내장되어 있기 때문이다. 하지만 필자가 이전에도 지적했듯이 컨테이너로 이전하는 데는 추가 비용이 든다. 컨테이너가 모든 애플리케이션과 데이터 워크로드에 맞는 것은 아니다. 특히 애플리케이션을 컨테이너화하고 제대로 운영하기에 충분한 인력을 확보하는 데 어려움을 겪을 것이다. 아직은 좋은 컨테이너 개발자와 설계자가 충분하지 않기 때문이다. 문제는 기술을 선택할 때 책이나 미디어에서 본 내용을 쫓아 성급하게 결정하는 경향이 있다는 것. 핵심적인 비즈니스 요구사항을 건너뛰고 컨테이너니 서버리스니 머신러닝이니 하는 유행 기술을 바로 도입하는 것이다. 실제로 IT는 주류를 벗어나서 존재하는 솔루션에 대해서는 근시안적이다. 컨테이너는 많은 워크로드에 잘 맞지만, 모든 워크로드에 맞는 것은 아니다. 애플리케이션을 컨테이너로 동작하도록 수정하는 비용이 많이 든다면, 해당 워크로드는 경제적인 관점에서 실행 가능한 선택이 아니다. 최근 IT 영역에서 컨테이너는 상당한 추동력을 얻고 있다. 그만큼 컨테이너 기반 기술을 잘못 적용할 가능성도 크다. 객관적으로 볼 때, 애플리케이션의 30% 이상을 컨테이너로 이식해야 하거나 새로 개발해야 한다면, 컨테이너와 맞지 않는 것이다. 애플리케이션의 기능을 개선하고 가치를 높이기 위해서 모든 새로운 기회를 객관적으로 봐야 한다. 새로운 기술을 이해하는 데서 핵심은 정말로 필요한지 여부이다. 목적과 보안, 거버넌...

아키텍처 마이그레이션 컨테이너 2019.11.18

"리눅스·컨테이너·쿠버네티스는 차세대 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...

레드햇 리눅스 표준 2019.11.15

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

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

복잡성 컨테이너 오케스트레이션 2019.11.04

'쿠버네티스, 도커, 컨테이너, 오케스트레이션'의 의미와 차이점

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

리눅스 운영체제 컨테이너 2019.11.04

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

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

컨테이너 오케스트레이션 도커 2019.10.31

앱 중심 미래를 향해 가는 쿠버네티스…OAM과 Rudr로 멀티클라우드 분산 앱 확장

쿠버네티스는 클라우드의 큰 성공 사례다. 무에서 시작해 불과 몇 년 만에 애플리케이션 개발의 슈퍼스타로 떠올랐다. 쿠버네티스가 빠른 속도로 성장하자 개발자들은 쿠버네티스 호스팅 애플리케이션을 구축하고 관리하기 위한 더 나은 방법을 찾고 있다. 쿠버네티스를 위한 확장은 풍부하다. 헴(Helm)과 같은 툴을 사용하면 클러스터에 리소스를 손쉽게 배포할 수 있고, CNAB(Cloud Native Application Bundle)는 애플리케이션과 모든 종속성을 즉시 배포 가능하도록 래핑한다. 하위 수준에서는 드래프트(Draft)와 같은 서비스가 기본적인 서비스를 설계하고 빌드하는 데 도움이 된다. 코드를 빌드해서 익숙한 컨테이너를 사용해 배포할 수 있고, 각 요소를 손쉽게 쿠버네티스 애플리케이션으로 조합할 수 있다. 애저 쿠버네티스 서비스를 사용해서 관리를 자동화할 수도 있다. 서비스 인프라를 백그라운드에 두고 있다는 점을 고려하면(구글의 보그(Borg) 작업), 쿠버네티스와 이를 둘러싼 각종 툴이 기본적으로 운영에 초점을 두는 것은 지극히 자연스럽다. 분산 시스템 운영은 오랜 과제이며, 보그에서 메소스(Mesos), 도커 스웜과 쿠버네티스에 이르기까지 전반적인 데이터센터 OS 추세에는 데브옵스 중에서 ‘데브’보다 ‘옵스’ 측면이 훨씬 더 크다.   이 상황을 넘어 쿠버네티스의 데브 측면을 강화하려면 어떻게 해야 할까? 생태계를 구축하고, 마이크로서비스 원칙을 기반으로 하는 분산 애플리케이션을 구축하기 위한 패턴과 방법을 코드화하는 측면에서는 많은 일이 이뤄졌다. 이제 이 모든 조각을 모아서 전체 그림에서 빠진 조각이자 개발자에게 필수적인 조각, 즉 쿠버네티스에 대한 애플리케이션 중심의 시야를 확보해야 한다.   OAM(Open Application Model) 마이크로소프트와 알리바바 클라우드는 최근 현대적인 분산 애플리케이션을 구성하는 다양한 계층과 역할 간의 경계에 대한 이해를 바탕으로 마이크로서비스 기반 애플리케이션 구축과 관리에 초점...

컨테이너 애저 알리바바 2019.10.24

“메인프레임의 부활” 보안과 병렬 처리 성능으로 블록체인과 컨테이너에 탁월

메인프레임이 죽기는커녕 되살아나고 있다. 이제 코볼을 실행하지도 않는다. 블록체인과 컨테이너와 같은 현대 기술의 주목을 받고 있기 때문이다. 153명의 IT 의사결정권자를 대상으로 한 설문조사에서 응답 기업의 50%는 메인프레임을 계속 사용할 것이며, 향후 2년간 오히려 활용도가 증가할 것이라고 답했다. 메인프레임 활용을 줄이거나 메인프레임을 폐기할 것이라는 응답은 5%에 불과했다. 이번 조사는 포레스터 리서치가 하이브리드 IT 서비스 업체인 엔소노(Ensono), IT 컨설팅 서비스 업체인 와이프로(Wipro)의 의뢰로 진행했다. 메인프레임에 대한 이런 확신은 온프레미스 데이터센터를 줄이거나 없애고 클라우드로 이전하는 최근의 흐름에서 볼 때 다소 놀라운 것이 사실이다. 하지만 기업은 인프라에 하이브리드 접근방식을 취하고 있다., 일부 애플리케이션은 클라우드로 이전하는 한편, 가장 중요한 애플리케이션은 온프레미스 인프라나 메인프레임에 유지하는 전략이다. 포레스터의 이번 조사에서 메인프레임은 오래된 기술을 구동하는 것뿐만 아니라 현대 비즈니스용으로도 여전히 핵심 인프라로 고려되는 것으로 나타났다. 물론 전통적인 엔터프라이즈 애플리케이션과 워크로드는 확실히 많은 비중을 메인프레임에 의존하고 있다. ERP의 44%, 재무 회계의 45%, HR 관리의 44%, ECM의 43%가 메인프레임에서 구동되는 것으로 나타났다. 하지만 설문 응답자 중 25%는 모바일 사이트와 애플리케이션이 메인프레임으로 옮겨졌고, 27%는 새로운 블록체인 구상과 컨테이너 애플리케이션을 구동하는 데 메인프레임을 이용한다고 답했다. 포레스터는 블록체인과 컨테이너 애플리케이션은 메인프레임에 내재된 통합된 보안과 대규모 병렬 처리 성능의 이점을 잘 활용할 수 있다고 설명했다.   엔소노의 기술 및 전략 담당 최고 부사장 브라이언 클링베일은 발표문을 통해 “이번 조사는 메인프레임이 레거시용이라는 선입견에 도전한다”며, “메인프레임 현대화는 기업에 기존 레거시 애플리케이션을 계속 구동할 ...

메인프레임 설문조사 컨테이너 2019.10.22

대세로 부상한 "마이크로서비스"란 무엇인가

거의 모든 컴퓨터 시스템은 ‘공유되는 자원’을 사용해 여러 작업을 수행한다. 컴퓨터 프로그래밍의 질문 중 하나는 이러한 작업을 수행하는 코드 비트가 서로 얼마나 엮여야 하는가에 관한 것이다. 그리고 점점 더 인기를 얻고 있는 해답은 마이크로서비스 개념이다. 즉, 전체 시스템을 구성하는데 다른 마이크로서비스들과 상호 작용하는 작고 분리된 기능성 덩어리를 이용하는 개념이다. 이렇듯 분리된 구성요소를 갖는다는 개념이 완전히 새로운 것은 아니지만, 마이크로서비스가 구현되는 방식은 현대적이고 클라우드에 기반한 애플리케이션을 위한 자연스러운 토대를 만든다. 마이크로서비스는 또한 데브옵스 철학과 잘 들어맞는다. 새로운 기능성을 빠르고 지속적으로 출시하도록 장려하는 것이다.   마이크로서비스란? 마이크로서비스의 ‘마이크로’는 작은 애플리케이션들을 의미한다. 나름 사실에 기반한 설명이기는 하지만 그것들을 이해하는 더 좋은 방법은 그것들이 한 가지 특정한 일을 하거나 특정한 문제를 해결하기 위해 필요한 만큼만 커야 한다는 것이다. 즉 기술적이기보다는 개념적으로 접근하는 것이 바람직하다. “마이크로서비스는 데이터 액세스나 메시징과 같은 수평적 계층이 아니라 비즈니스 기능을 중심으로 설계되어야 한다”라고 설명된다. 그것들은 비교적 안정적인 API를 통해 다른 마이크로서비스 및 외부 사용자들과 통신해 더 큰 애플리케이션을 만든다. 따라서, 개별 마이크로서비스의 기능성은 시스템의 나머지 부분에 영향을 미치지 않고 조정되거나 급격하게 업그레이드될 수 있다. 이는 다시 데브옵스 부문들이 어떻게 운영하려고 하는지와 관련이 있다. 더 큰 애플리케이션의 특정 기능이 독립적으로 작동하는 코드의 분리된 조각으로 세분화되면 CI/CD(지속적 통합 및 지속적 전달)의 데브옵스 더욱 쉽게 작동할 수 있다. 또한, 잘 정의된 API는 마이크로서비스들을 자동으로 테스트하기 쉽게 만든다. 마이크로서비스 아키텍처 vs 모놀리틱 아키텍처  마이크로서비스가 ‘마이크로서비스 ...

컨테이너 마이크로서비스 콘테이너 2019.10.15

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

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

Copyright © 2022 International Data Group. All rights reserved.