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.

쿠버네티스

컨테이너, M&A, 미-중 관계로 본 '2020년 오픈소스 전망'

지난해 오픈소스 커뮤니티의 가장 큰 뉴스는 IBM의 공식적인 레드햇 인수 발표였다. 이로써 잠재적인 규제 장벽을 넘어 영향력이 큰 OS 기업인 레드햇이 빅블루(Big Blue)의 일원이 되었다.   평론가들은 마이크로소프트의 CEO 사티아 나델라가 커뮤니티 주도 기술을 공개적으로 도입한 이후로 오픈소스가 ‘주류’가 될 것이라고 말했지만 업계에서 역사가 깊은 대형 기술 기업에 이 정도 규모가 대수일까? 이것보다 더 주류가 되지는 않는다. 그렇다면 오픈소스 분야의 미래는 어떨까? 무엇보다도 기업은 쿠버네티스를 지속해서 실험할 것이며 다른 1~2개의 재단이 설립될 것이고 오픈소스 하드웨어가 발전할 것이며 중국 등의 신흥 글로벌 시장에서 커뮤니티 활동이 계속해서 증가할 것으로 예상된다.  컨테이너 컨테이너가 새로울 것은 없지만 아쿠아섹(Aquasec)은 1970년대부터 2017년까지 독립 배치 가능한 코드 패키지의 간략한 역사를 게재했으며 읽어 볼 만한 가치가 있다. 최근 기업들은 2015년 구글이 내부적으로 연구하던 것을 공개한 컨테이너 오케스트레이션 플랫폼 쿠버네티스에 매혹되어 있다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)에 따르면 조사한 5,000개 기업 중 40%가 쿠버네티스를 생산 운용하고 있으며 오픈소스 세계의 실질적인 총아로서 입지를 굳히고 있다. 하지만 <인포월드>에서 지적했듯이 쿠버네티스를 생산 운용하고 있는 기업들은 소규모로 운용하고 있다. 이 플랫폼은 다루기가 어려운 것으로 유명하며, 오픈소스 컨퍼런스에서 세부사항과 장단점을 다루고 성공적인 운용 방법에 대한 경험을 공유하는 워크숍이나 패널이 없다. 그래서 최소한 오픈소스 업체 영역에서만큼은 이 오케스트레이션 플랫폼으로 수익을 발생시키기 위해 경쟁하고 있는 것으로 보이며 AWS, 시스코, 마이크로소프트, 피보탈, IBM-레드햇, 구글, HPE 등의 대기업들이 모두 자체적인 관리형 버전을 출시하고...

레드햇 Cloud Native Computing Foundation 2020년 2020.01.06

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

점점 더 많은 기업이 애플리케이션의 컨테이너화를 받아들이면서 효과적인 백업 시스템의 필요성이 중요해졌다. 컨테이너는 다른 배치 모델과는 차별화되는 독보적인 특성을 가지고 있기 때문에 올바른 백업 아키텍처를 적용하지 않으면, 심각한 시스템 정지와 데이터 손실의 위험에 처할 수 있다.   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

더 ‘쉬운’ 쿠버네티스를 위한 11가지 도구

쿠버네티스는 컨테이너화된 애플리케이션을 대규모로 배포하기 위한 가장 유력한 표준으로 자리잡았다. 그러나 쿠버네티스가 복잡한 컨테이너 배포를 관리할 수 있게 해주는 것과는 별개로, 쿠버네티스를 쉽게 사용하는 데 도움이 되는 툴도 있을까? 쿠버네티스 자체도 너무 복잡하고 골치 아프고 관리하기 어려울 수 있다. 물론 쿠버네티스의 매끄럽지 않은 부분들은 쿠버네티스가 발전하고 성장하면서 프로젝트 내에서 다듬어질 것이다. 그러나 어떤 사람들은 쿠버네티스를 쉽게 다룰 수 있게 될 때까지 그냥 앉아서 기다리지 않고 프로덕션에서 쿠버네티스를 사용할 때 발생하는 여러 일반적인 문제에 대해 스스로 해결책을 만들어 내놓았다.     비트나미 캐빈(Bitnami Cabin): iOS와 안드로이드를 위한 쿠버네티스 대시보드 현대 웹 애플리케이션이나 서비스라면 당연히 모바일 인터페이스가 있어야 한다. 캐빈은 쿠버네티스 관리자를 위해 iOS 또는 안드로이드 스마트폰에서 액세스할 수 있는 쿠버네티스 대시보드 버전을 제공한다. 헬름(Helm) 차트, 배포 확장, 포드 로그 읽기, 쿠버네티스로 호스팅되는 웹 기반 앱 액세스를 비롯해 정식 쿠버네티스 대시보드에서 사용할 수 있는 기능 상당수를 캐빈에서 실행할 수 있다.   골드핑거(Goldpinger): 쿠버네티스 클러스터 시각화 인간은 시각적 동물이다. 그래프와 차트를 보면 큰 그림을 더 쉽게 이해할 수 있다. 쿠버네티스 클러스터의 복잡함과 넓은 범위를 감안하면 시각적인 보조 도구의 유용함은 말할 필요도 없다. 재미있는 이름의 골드핑거는 블룸버그 기술 팀이 오픈소스로 공개한 툴로, 쿠버네티스 클러스터 내에서 실행되면서 노드 간의 관계를 인터랙티브 지도로 표시해준다. 정상 노드는 녹색으로, 비정상 노드는 빨간색으로 표시된다. 노드를 클릭하면 세부 내용을 볼 수 있다. 스웨거(Swagger)로 API를 맞춤 설정해서 보고 기능과 메트릭스를 추가하거나 기타 통합이 가능하다.   K9s: 전체 화면 쿠버네티스...

쿠버네티스 큐브스파이 큐브-프롬프트 2019.12.16

더 나은 쿠버네티스를 위한 11가지 도구

강력한 성능과 큰 규모를 가진 컴퓨팅 플랫폼이라 해도 그 자체로 모든 요구를 만족시키는 경우는 거의 없다. 쿠버네티스 역시 기본 상태 그대로도 유용하지만 결코 완벽하지는 않다. 데이터베이스 지원과 같이 기본 쿠버네티스 기능으로는 부족한 사용 사례나 요구사항도 있고, 지속적 배포(Continuous delivery, CD)와 같이 쿠버네티스에서 아예 신경쓰지 않는 부분도 있다.   그러나 추가 기능과 확장, 각종 보너스가 풍부한 쿠버네티스 커뮤니티가 부족한 부분을 메워준다. 이 가운데 가장 유용한 쿠버네티스용 도구 11가지를 선정했다. 모든 쿠버네티스 클러스터를 보완하는 툴도 있고, 기본 쿠버네티스에서 다루지 않는 특정 요구사항에 대처하는 툴도 있다. - 그래비티(Gravity): 이식 가능한 쿠버네티스 클러스터 쿠버네티스에 애플리케이션을 배포하는 과정을 안내하고 자동화하는 헬름(Helm) 차트가 있는 애플리케이션은 많다. 그러나 쿠버네티스 클러스터를 그대로 가져와서 다른 곳에 배포하려는 경우에는 어떨까? 그래비티는 쿠버네티스 클러스터, 컨테이너 레지스트리, 실행 중인 애플리케이션의 스냅샷(“애플리케이션 번들”이라고 함)을 찍는다. .tar 파일 하나인 이 번들은 쿠버네티스를 실행할 수 있는 어디에나 클러스터를 복제할 수 있다. 또한 그래비티는 대상 인프라가 원본과 동일한 동작 요구사항을 지원할 수 있는지, 그리고 대상의 쿠버네티스 런타임이 기준을 충족하는지도 확인한다. 그래비티 엔터프라이즈 버전은 역할 기반 액세스 제어(Role-Based Access Controls, RBAC), 여러 클러스터 배포 간에 보안 구성을 동기화하는 기능을 포함한 보안 기능을 추가로 제공한다. - 카니코(Kaniko): 쿠버네티스 클러스터에 컨테이너 빌드 대부분의 컨테이너 이미지는 컨테이너 스택 외부의 시스템에 빌드된다. 그러나 가끔은 컨테이너 스택 안에서, 예를 들어 실행 중인 컨테이너 안이나 쿠버네티스 클러스터의 어느 지점에서 빌드 프로세스를 진행하고자 하는...

클러스터 테레사 큐브코스트 2019.12.13

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

쿠버네티스는 다양한 형태로 사용할 수 있는, 분산 시스템 구축을 위한 강력한 툴이다. 다만 한 가지 큰 문제는 설계상 쿠버네티스는 리소스 기반 확장만 제공한다는 점이다. 사실 쿠버네티스의 역사를 보면(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

퍼블릭·멀티 클라우드에서 자바 프레임워크 활용하는 MS와 피보탈의 해법

아직도 많은 자바 애플리케이션이 비즈니스 기반으로 사용되고 있다. 그러나 자바 애플리케이션을 퍼블릭 클라우드로 옮기면 어떻게 될까? 코드를 다시 쓰지 않고 배포해서 애저와 동일한 서비스 비용 및 확장 이점을 모두 누릴 수 있을까?   한 가지 방법으로 애저에서 새롭게 내놓은 스프링 클라우드(Spring Cloud) 서비스를 들 수 있다. 많이 사용되는 피보탈의 스프링 부트(Spring Boot) 자바 프레임워크를 기반으로 구축된 스프링 클라우드는 자바 코드 기반으로 주요 애저 서비스를 활용하고 애저의 쿠버네티스 서비스를 사용해 확장을 관리할 수 있게 해준다. 필요한 구성 작업은 극히 적고, 관리형 서비스로 제공되므로 플랫폼 관리는 더욱 불필요하다. 지금은 비공개 프리뷰 버전이지만 2019년 내에 공개 프리뷰 버전이 나올 전망이다.   익숙한 스프링의 파생물인 스프링 부트에 대한 대체적인 인식은 엔터프라이즈 자바 애플리케이션을 위한 효과적인 런타임이다. 코드를 써서 배포하기만 하면 된다. 라이브러리와 서비스 관리는 스프링 부트가 알아서 해준다. 스프링 부트 문서에도 나와 있듯이 코드는 “그냥 실행된다.”   애저에서의 독불장군 자바 스프링 부트가 관리형 클라우드 서비스 실행에 적합한 이유는 종속성 처리에 대한 독단적인(opinionated) 접근 방식에 있다. 코드에 필요한 라이브러리를 관리할 필요가 없다면 서비스를 최신 상태로 유지하고 애플리케이션 코드 및 이와 연결된 모든 아티팩트를 연속된 배포 파이프라인으로 빌드할 수 있다는 것을 보장하기가 쉽다. 변경이 발생하면 새 JAR(자바 아카이브)이 생성되고 배포된다. 피보탈의 스프링 부트 툴에는 자체 빌드 서비스가 포함된다. 이 빌드 서비스는 코드를 받아 컴파일해서 패키징하고, 애저 스프링 클라우드에서는 애저 쿠버네티스 서비스(AKS)에서 즉시 실행 가능한 컨테이너로 제공한다. 코드가 애저에 배포되면 애저 CLI를 사용해 애플리케이션을 실행하고 확장할 수 있다. 피보탈은 헤로쿠(Her...

자바 애저 피보탈 2019.10.17

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

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

Copyright © 2022 International Data Group. All rights reserved.