2020.03.11

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

Eric Knorr | InfoWorld
에디슨이 전구를 발명할 당시 가장 어려운 문제는 램프와 소켓을 결합하고 분리하는 것이었다. 이런 불편을 개선한 에디슨 스크류는 오늘날까지 거의 모든 전구를 책상 램프든 샹들리에든 대부분의 조명기구에 돌려서 끼울 수 있는 표준이 되었다. 

10년 전 솔로몬 하익스의 도커 컨테이너 발명도 비슷한 효과를 낳았다. 어떤 리눅스 앱이든 패키징을 한번 하면 모든 리눅스 운영체제의 모든 도커 컨테이너에 연결할 수 있고, 번거로운 설치가 필요 없다. 더 좋은 건 여러 컨테이너화된 앱이 운영체제의 단일 인스턴스에 연결되고, 각 앱은 다른 앱과 안전하게 격리되어 도커 API를 통해 OS와만 통신할 수 있다는 점이다. 

이 공유 모델은 물리적 컴퓨터에서 클라우드와 같은 방식으로 애플리케이션을 배포하고 확장하기 위한 기존의 수단인 가상머신보다 훨씬 가벼운 스택을 제공했다. 실제로 가볍고 휴대성이 뛰어나기 때문에 개발자는 노트북에서 여러 컨테이너화된 앱을 작업하고, 테스트 및 배포를 위해 선택한 플랫폼에 업로드할 수 있다. 또한 일반적으로 부팅 시 1분 정도 걸리는 가상머신과는 달리 컨테이너화된 앱은 눈 깜짝할 사이에 시작한다.

그러나 컨테이너의 실제 영향을 파악하려면 애플리케이션 아키텍처의 마이크로서비스 모델을 이해해야 한다. 많은 애플리케이션이 API를 통해 서로 통신하는 작은 단일 목적의 서비스로 세분화되어, 각 마이크소서비스를 독립적으로 업데이트하거나 확장할 수 있는 장점이 있다(전체 변경 사항을 가져와 수정해야 하는 전통적인 모놀리식 애플리케이션에 비해 편리하다). 알고보니, 마이크로서비스와 컨테이너는 서로 완벽하게 잘 맞는다. 

그러나 컨테이너화된 마이크로서비스를 애플리케이션으로 함께 사용하려면 어떻게 해야 할까? 바로 여기에서 최소한 더 큰 마이크로서비스 애플리케이션에 쿠버네티스가 역할을 한다. 이 오픈소스 오케스트레이션 엔진을 사용해 마이크로서비스 기반 애플리케이션을 배치, 관리, 확장하고 가용성을 보장할 수 있다. 또한 필요한 경우 플랫폼 간 동시 이동도 지원한다. 
 
이동이 엄청 많은 것처럼 들린다면, 사실이다(몇몇의 경우를 제회하고 쿠버네티스가 꼭 필요한지 여부는 의문이다).  하지만 실수하면 안 된다. 마이크로서비스 시대가 다가오고 있으며, 새로운 서비스를 즉시 확장하거나 교체하는 기능은 많은 최신 애플리케이션에 필수적이다. 이러한 서비스를 관리하는 방법에 관계없이, 컨테이너는 표준화되고, 간소한 (가상의)수용 공간으로 자리 잡았다.
 

컨테이너의  프로덕션

기고가 밥 비올리노는 “컨테이너와 쿠버네티스: 3가지 혁신적 성공 사례”에서 익스피디아, 클렘슨 대학교(Clemson University), 유한회사 프리메리카(Premerica)가 쿠버네티스의 어려운 점을 어떻게 다루는지를 탐구한다. 밥의 기사는 UK 그룹 편집자 스콧 캐리의 “쿠버네티스가 현실 세계를 만난다”에 대한 것이다. 스콧의 기사는 블룸버스, 뉴스 UK, 여행 데이터 제공업체 아마데우스의 유사한 기사를 더욱 심도 있게 탐구했다. 모든 기사에서 의견이 일치하는 부분은? 프리메리카 CTO 배리 펠라스는 “쿠버네티스 환경에서 올바르게 개발할 수 있는 기술을 갖춘 팀이 되는 것은 어려운 일”이라고 말했다. 그러나 어렵든 아니든, 오늘날 쿠버네티스는 컨테이너화된 서비스를 대규모로 조정할 때 널리 사용되는 솔루션이다.

쿠버네티스는 네트워킹 컨테이너의 까다로운 문제에도 유용하다. Networkworld 기고자 존 에드워드가 “컨테이너 네트워킹에 대해 필수적으로 알아야 할 사항” 기사에서 설명한 것처럼, 네트워킹 컨테이너는 데이터센터 네트워킹과 닮은 점이 거의 없다. 컨테이너 네트워킹은 완전히 소프트웨어 정의일 뿐 아니라, 쿠버네티스 자체가 인간의 개입없이 모든 라우팅 요청과 네트워크 연결을 처리한다. 연결된 모든 서비스를 서비스 메시라고 하는데, 또 다른 오픈소스 프로젝트인 이스티오(Istio)는 관리자가 트래픽을 관리하고, 정책을 제어하고, 서비스를 검색하는 작업을 처리할 수 있도록 설계되었다. 

이스티오는 서비스 간 TLS 보안 통신과 같은 보안 수단도 제공한다. 그러나 프로덕션에서 컨테이너의 세계는 완전히 새로운 것이다. 그리고 대기업은 보안을 스스로 하기로 결정한 대기업도 있다. CSO 선임 기자 루시안 콘스탄틴은 컨테이너 모니터링, 보안 정책 시행, 사고 감지, 치료를 위해 “비자(Visa)가 자체 컨테이너 보안 솔루션을 구축한 방법”을 설명한다. 루시안에 따르면, 비자의 사례는 구축할지, 아니면 구입해서 쓸지의 전형적인 결정이었다. 기존 솔루션이 조금 불안하거나 적절한 기능 조합이 부족할 경우 어떻게 해야할까? 스스로 해결해야 한다.

이 스펙트럼의 다른 한쪽 끝에는 클라우드 업체가 제공하는 CaaS(containers-as-a-service)가 있다. 더 정확하게 설명하면 서비스형 쿠버네티스(Kubernetes as a Service) 솔루션이다. 아마존 웹서비스, 구글 클라우드 플랫폼, 마이크로소프트 애저는 모두 고유한 CaaS의 특징을 제공한다. 그러나 기고 편집자 아이작 사콜릭은 “PaaS, CaaS 또는 Faas 중 하나를 선택 방법”에서, CaaS가 유일한 컨테이너 관리 옵션은 아니라고 한다. 대신 PaaS(서비스형 플랫폼)를 선택할 수 있다. 일반적으로 더 빠르고 쉬운 개발과 배포를 위해 구성 가능성을 교환한다. FaaS는 서버리스 컴퓨팅이라고도 하는데, 더욱 높은 수준의 추상화를 제공해 개발자가 작은 개별 기능에서 서비스를 신속하게 조합할 수 있도록 지원한다. 그렇다. FaaS 솔루션은 컨테이너를 보이지 않게 차양 아래에서 실행하지만, 개발자는 컨테이너를 볼 필요가 없다. 관리만 하면 되는 것이다. 

이들 컨테이너 솔루션으로 최종 사용자가 얻는 이점은 무엇일까? 가장 기본적인 것은 소프트웨어를 더 빠른 속도로 업데이트하고 개선한다는 점이다. “데스크톱의 컨테이너? 물론 윈도우 10X에서 가능”하다는 기사에서 살펴본 바와 같이, 마이크로소프트는 혁신적인 듀얼 스크린 기기용 윈도우 10X 운영체제에서 레거시 애플리케이션을 제대로 실행하는 새로운 유형의 컨테이너를 도입했다. 이 특정 컨테이너의 발전은 마이크로소프트를 수년 동안 윈도우 진전을 제약해온 이전 버전과의 호환성이라는 제약에서 벗어난 해답을 제시할 수 있다.

결국 컨테이너는 그토록 요란하게 찾는 IT 이점인 민첩성과 직결되어 있다. 컨테이너는 쉽게 이동할 수 있고 많은 플랫폼에 연결할 수 있다. 불필요한 의존성도 제거한다. 다른 애플리케이션으로 재사용 및 재조합할 수 있다. 또한, 마이크로서비스 인프라의 민첩한 조력자로써, 컨테이너는 각각 마이크로서비스를 담당하는 소규모의 분산된 부서를 유지한다. 이로써 건강한 노동 분담을 통해 더 나은 소프트웨어를 더 빨리 생산할 수 있다. 

컨테이너는 에디슨 스크루 전기 소켓처럼 급진적인 진전을 보인 순수 기술은 아니다. 그러나 앞으로 개발할 애플리케이션과 향후 몇 년 간 사용할 애플리케이션에 중대한 영향을 미칠 것임이 분명하다. editor@itworld.co.kr


2020.03.11

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

Eric Knorr | InfoWorld
에디슨이 전구를 발명할 당시 가장 어려운 문제는 램프와 소켓을 결합하고 분리하는 것이었다. 이런 불편을 개선한 에디슨 스크류는 오늘날까지 거의 모든 전구를 책상 램프든 샹들리에든 대부분의 조명기구에 돌려서 끼울 수 있는 표준이 되었다. 

10년 전 솔로몬 하익스의 도커 컨테이너 발명도 비슷한 효과를 낳았다. 어떤 리눅스 앱이든 패키징을 한번 하면 모든 리눅스 운영체제의 모든 도커 컨테이너에 연결할 수 있고, 번거로운 설치가 필요 없다. 더 좋은 건 여러 컨테이너화된 앱이 운영체제의 단일 인스턴스에 연결되고, 각 앱은 다른 앱과 안전하게 격리되어 도커 API를 통해 OS와만 통신할 수 있다는 점이다. 

이 공유 모델은 물리적 컴퓨터에서 클라우드와 같은 방식으로 애플리케이션을 배포하고 확장하기 위한 기존의 수단인 가상머신보다 훨씬 가벼운 스택을 제공했다. 실제로 가볍고 휴대성이 뛰어나기 때문에 개발자는 노트북에서 여러 컨테이너화된 앱을 작업하고, 테스트 및 배포를 위해 선택한 플랫폼에 업로드할 수 있다. 또한 일반적으로 부팅 시 1분 정도 걸리는 가상머신과는 달리 컨테이너화된 앱은 눈 깜짝할 사이에 시작한다.

그러나 컨테이너의 실제 영향을 파악하려면 애플리케이션 아키텍처의 마이크로서비스 모델을 이해해야 한다. 많은 애플리케이션이 API를 통해 서로 통신하는 작은 단일 목적의 서비스로 세분화되어, 각 마이크소서비스를 독립적으로 업데이트하거나 확장할 수 있는 장점이 있다(전체 변경 사항을 가져와 수정해야 하는 전통적인 모놀리식 애플리케이션에 비해 편리하다). 알고보니, 마이크로서비스와 컨테이너는 서로 완벽하게 잘 맞는다. 

그러나 컨테이너화된 마이크로서비스를 애플리케이션으로 함께 사용하려면 어떻게 해야 할까? 바로 여기에서 최소한 더 큰 마이크로서비스 애플리케이션에 쿠버네티스가 역할을 한다. 이 오픈소스 오케스트레이션 엔진을 사용해 마이크로서비스 기반 애플리케이션을 배치, 관리, 확장하고 가용성을 보장할 수 있다. 또한 필요한 경우 플랫폼 간 동시 이동도 지원한다. 
 
이동이 엄청 많은 것처럼 들린다면, 사실이다(몇몇의 경우를 제회하고 쿠버네티스가 꼭 필요한지 여부는 의문이다).  하지만 실수하면 안 된다. 마이크로서비스 시대가 다가오고 있으며, 새로운 서비스를 즉시 확장하거나 교체하는 기능은 많은 최신 애플리케이션에 필수적이다. 이러한 서비스를 관리하는 방법에 관계없이, 컨테이너는 표준화되고, 간소한 (가상의)수용 공간으로 자리 잡았다.
 

컨테이너의  프로덕션

기고가 밥 비올리노는 “컨테이너와 쿠버네티스: 3가지 혁신적 성공 사례”에서 익스피디아, 클렘슨 대학교(Clemson University), 유한회사 프리메리카(Premerica)가 쿠버네티스의 어려운 점을 어떻게 다루는지를 탐구한다. 밥의 기사는 UK 그룹 편집자 스콧 캐리의 “쿠버네티스가 현실 세계를 만난다”에 대한 것이다. 스콧의 기사는 블룸버스, 뉴스 UK, 여행 데이터 제공업체 아마데우스의 유사한 기사를 더욱 심도 있게 탐구했다. 모든 기사에서 의견이 일치하는 부분은? 프리메리카 CTO 배리 펠라스는 “쿠버네티스 환경에서 올바르게 개발할 수 있는 기술을 갖춘 팀이 되는 것은 어려운 일”이라고 말했다. 그러나 어렵든 아니든, 오늘날 쿠버네티스는 컨테이너화된 서비스를 대규모로 조정할 때 널리 사용되는 솔루션이다.

쿠버네티스는 네트워킹 컨테이너의 까다로운 문제에도 유용하다. Networkworld 기고자 존 에드워드가 “컨테이너 네트워킹에 대해 필수적으로 알아야 할 사항” 기사에서 설명한 것처럼, 네트워킹 컨테이너는 데이터센터 네트워킹과 닮은 점이 거의 없다. 컨테이너 네트워킹은 완전히 소프트웨어 정의일 뿐 아니라, 쿠버네티스 자체가 인간의 개입없이 모든 라우팅 요청과 네트워크 연결을 처리한다. 연결된 모든 서비스를 서비스 메시라고 하는데, 또 다른 오픈소스 프로젝트인 이스티오(Istio)는 관리자가 트래픽을 관리하고, 정책을 제어하고, 서비스를 검색하는 작업을 처리할 수 있도록 설계되었다. 

이스티오는 서비스 간 TLS 보안 통신과 같은 보안 수단도 제공한다. 그러나 프로덕션에서 컨테이너의 세계는 완전히 새로운 것이다. 그리고 대기업은 보안을 스스로 하기로 결정한 대기업도 있다. CSO 선임 기자 루시안 콘스탄틴은 컨테이너 모니터링, 보안 정책 시행, 사고 감지, 치료를 위해 “비자(Visa)가 자체 컨테이너 보안 솔루션을 구축한 방법”을 설명한다. 루시안에 따르면, 비자의 사례는 구축할지, 아니면 구입해서 쓸지의 전형적인 결정이었다. 기존 솔루션이 조금 불안하거나 적절한 기능 조합이 부족할 경우 어떻게 해야할까? 스스로 해결해야 한다.

이 스펙트럼의 다른 한쪽 끝에는 클라우드 업체가 제공하는 CaaS(containers-as-a-service)가 있다. 더 정확하게 설명하면 서비스형 쿠버네티스(Kubernetes as a Service) 솔루션이다. 아마존 웹서비스, 구글 클라우드 플랫폼, 마이크로소프트 애저는 모두 고유한 CaaS의 특징을 제공한다. 그러나 기고 편집자 아이작 사콜릭은 “PaaS, CaaS 또는 Faas 중 하나를 선택 방법”에서, CaaS가 유일한 컨테이너 관리 옵션은 아니라고 한다. 대신 PaaS(서비스형 플랫폼)를 선택할 수 있다. 일반적으로 더 빠르고 쉬운 개발과 배포를 위해 구성 가능성을 교환한다. FaaS는 서버리스 컴퓨팅이라고도 하는데, 더욱 높은 수준의 추상화를 제공해 개발자가 작은 개별 기능에서 서비스를 신속하게 조합할 수 있도록 지원한다. 그렇다. FaaS 솔루션은 컨테이너를 보이지 않게 차양 아래에서 실행하지만, 개발자는 컨테이너를 볼 필요가 없다. 관리만 하면 되는 것이다. 

이들 컨테이너 솔루션으로 최종 사용자가 얻는 이점은 무엇일까? 가장 기본적인 것은 소프트웨어를 더 빠른 속도로 업데이트하고 개선한다는 점이다. “데스크톱의 컨테이너? 물론 윈도우 10X에서 가능”하다는 기사에서 살펴본 바와 같이, 마이크로소프트는 혁신적인 듀얼 스크린 기기용 윈도우 10X 운영체제에서 레거시 애플리케이션을 제대로 실행하는 새로운 유형의 컨테이너를 도입했다. 이 특정 컨테이너의 발전은 마이크로소프트를 수년 동안 윈도우 진전을 제약해온 이전 버전과의 호환성이라는 제약에서 벗어난 해답을 제시할 수 있다.

결국 컨테이너는 그토록 요란하게 찾는 IT 이점인 민첩성과 직결되어 있다. 컨테이너는 쉽게 이동할 수 있고 많은 플랫폼에 연결할 수 있다. 불필요한 의존성도 제거한다. 다른 애플리케이션으로 재사용 및 재조합할 수 있다. 또한, 마이크로서비스 인프라의 민첩한 조력자로써, 컨테이너는 각각 마이크로서비스를 담당하는 소규모의 분산된 부서를 유지한다. 이로써 건강한 노동 분담을 통해 더 나은 소프트웨어를 더 빨리 생산할 수 있다. 

컨테이너는 에디슨 스크루 전기 소켓처럼 급진적인 진전을 보인 순수 기술은 아니다. 그러나 앞으로 개발할 애플리케이션과 향후 몇 년 간 사용할 애플리케이션에 중대한 영향을 미칠 것임이 분명하다. editor@itworld.co.kr


X