2018.10.30

컨테이너 플랫폼으로 데브옵스 환경까지 조성하는 법

BrandPost Sponsored by Redhat Brandpost
Gordon Haff | Redhat


초창기 데브옵스(Devops)에 대한 논의는 개발자와 운영 부서 사이의 장벽을 없애는 과정에 집중되어 있었다. 이때 운영 부서의 주장은 개발자가 일방적으로 새로운 애플리케이션을 던져 놓고 도망가는 행동을 그만두어야 IT 환경이 더 발전할 것이라는 내용이었다.

불필요한 소통을 피하라
위의 말에는 분명 진실이 담겨 있다. 조직 대다수는 열린 커뮤니케이션과 상호 소통을 긍정적으로 바라본다. 그러나 때로는 불필요한 소통을 배제할 필요가 있다. 최근에는 개발자와 운영 부서 간의 소통을 최소화하면서 효율성을 높이는 인프라, 프로세스 및 도구가 다양하게 등장했다. 마치 평소 필자가 주거래 은행의 은행원과의 소통을 최소화하고 싶은 것과 비슷한 맥락이다. 일상적인, 그리고 심지어 일상적이지 않은 거래에 있어서도 이왕이면 ATM이나 스마트폰을 활용하고 싶은 것이다.

이러한 요구에 대응하기 위해, 운영 부서는 프라이빗 IaaS(Infrastructure-as-a-Service) 클라우드와 같은 최적화된 트랜잭션을 지원하는 인프라를 구축하고 운영할 의무가 있고, 또 현대적인 컨테이너 플랫폼을 통해 핵심 서비스를 제공해야 한다.

왜 현대화된 플랫폼을 선택해야 하는가?
개발 과정, 그리고 클라우드 네이티브 애플리케이션을 최적화하는 과정은 주로 현대화된 플랫폼에서 진행될 때 더욱 좋은 결과를 얻는다.

서비스 수요가 굉장히 탄력적인 경우에는 아키텍처를 스케일아웃(scale-out) 할 필요가 있다. 단순한, 스케일업(scale-up) 구조의 애플리케이션 설계는 유동적인 수요에 대한 대응력이 부족하거나 아예 대응하지 못 할 수도 있다.

현대화된 플랫폼은 소프트웨어에 의해 정의(Software-defined)되는데, 이는 네트워크 기능 가상화나 소프트웨어 정의 스토리지 등 소프트웨어의 기능이 하드웨어에 임베디드 되어 있을 때보다 훨씬 유연하기 때문이다.

현대화된 애플리케이션은 서로 느슨하게 결합된 서비스들로 이루어지는데, 그 이유는 거대한 모놀리식(monolithic) 애플리케이션은 연약하고, 또한 신속한 업데이트가 어렵기 때문이다. 한편, 현대화된 컨테이너 플랫폼은 반복적인 소프트웨어 개발과 출시를 지원하는데, 이는 현대화된 애플리케이션이 수명이 짧은 경우가 있고, 빈번한 갱신과 대체를 필요로 하기 때문이다.

컨테이너의 도입 및 활용
최초의 컨테이너는 시스템을 구분하는 대체 방법이자 하드웨어 가상화를 대체하는 경량 솔루션으로 시작되었다. 그러나 많은 사람의 관심을 끌게 된 계기는 컨테이너가 애플리케이션 패키징 수단으로 사용되면서부터이다. 애플리케이션의 의존성을 포함하는 이미지를 제공함으로써 컨테이너는 개발, 테스트, 출시 과정에서 보다 휴대하기 쉽고 일관성 있는 패키징 구조를 가진다.

이외 다른 부분에서도 역시 발전이 있었다. 오늘날 오픈 컨테이너 이니셔티브(Open Containers Initiative, OCI)에서 총괄하는 사양(Specification) 등은 컨테이너가 사용하는 이미지와 런타임을 표준화하였다. 이러한 사양은 컨테이너 이미지를 정의하고 컨테이너의 의존성, 환경 및 인수 등의 이미지가 구동될 때 필요한 정보를 확인하는 데 도움을 준다. 이러한 오픈 컨테이너 이니셔티브에서의 표준화 작업을 통해 안정적인 런타임이 보장되고 이를 기반한 많은 도구가 개발될 수 있다. 예를 들어 레드햇은 프로젝트 아토믹(Project Atomic), 스코페오(Skopeo), 빌다(Buildah) 등 다양한 컨테이너 레지스트리 및 컨테이너 개발 프로젝트에 참여하고 있다.

OCI를 준수하는 컨테이너 런타임은 독자적으로 하나의 컨테이너를 관리하는 데 매우 유용하다. 하지만 수백 개로 조각난 컨테이너와 컨테이너화된 애플리케이션을 사용하기 시작하면 관리와 오케스트레이션이 복잡해질 수 있다. 그렇기에 결국은 서비스를 제공하기 위해서는 한 걸음 물러서서 여러 컨테이너를 그룹화해야만 한다.

오케스트레이팅(Orchestrating)하고 관리하기
쿠버네티스는 컨테이너에 대한 오케스트레이팅과 관리를 논할 때 등장하는 개념이다. 원래는 구글에서 개발되었지만 현재는 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation, CNCF) 산하 대규모 커뮤니티 프로젝트로 리눅스 컨테이너를 구동하는 여러 호스트들을 모아서 오케스트레이팅하고 관리할 수 있도록 지원한다.

쿠버네티스는 다양한 추가 프로젝트들을 통해서 개발자들과 운영 부서가 배포하거나 운영하고자 하는 클라우드 네이티브 애플리케이션들이 필요로 하는 서비스들을 제공한다. 이는 컨테이너 레지스트리, 텔레미터, 네트워킹 및 보안 등을 포함한다. 최근 오픈소스 관련 혁신 중 상당 부분은 컨테이너에 관한 것이며 이 글에서 다룬 내용은 전체의 일부일 뿐이다.

통합하고 패키징하기
오픈시프트(OpenShift)는 OCI 준수 컨테이너와 쿠버네티스 등의 기술을 통합하여 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)내 엔터프라이즈 기반 기술과 결합한다. 오픈시프트는 또한 개발 및 운영 부서가 필요로 하는 아키텍처, 프로세스, 플랫폼 및 서비스 등을 통합한다. 또한, 오프시프트는 OKD( https://www.okd.io)를 업스트림 커뮤니티 프로젝트로 가지는 완전한 오픈소스다. 사용자, 컨트리뷰터(contributors) 및 파트너는 모두 오픈시프트 커먼즈(OpenShift Commons)에서 모인다.

클라우드 네이티브 업계에서 일어나고 있는 움직임을 살펴보면 DIY 통합이 야기하는 문제는 매우 명백해진다(이는 IaaS뿐만 아니라 컨테이너 플랫폼에도 적용된다). 변화는 프로젝트 내부에서도 빠르게 일어나고 있고, 새로운 프로젝트가 끊임없이 생겨나며, 개발자와 사용자가 다양한 종류의 업무와 사례를 통해 경험을 쌓으면서 요구하는 여러 접근방식 역시 실시간으로 변화하고 있다.

통합 플랫폼이 가지는 궁극적인 목표는 출발 과정을 간소화하고, 요구하는 역량의 레벨을 낮추어 기업들이 기존 플랫폼에 많은 시간을 들이기보다 각자의 애플리케이션 배포에 집중할 수 있도록 지원하는 것이다. 뿐만 아니라, 컨테이너 플랫폼 도입을 통해 IT 기업 환경의 민첩성을 한층 더 높이고 개발자와 운영자 간의 거리를 좁혀 원활한 데브옵스 환경을 구현하는 것도 또 하나의 최종 목표가 될 것이다.


2018.10.30

컨테이너 플랫폼으로 데브옵스 환경까지 조성하는 법

BrandPost Sponsored by Redhat Brandpost
Gordon Haff | Redhat


초창기 데브옵스(Devops)에 대한 논의는 개발자와 운영 부서 사이의 장벽을 없애는 과정에 집중되어 있었다. 이때 운영 부서의 주장은 개발자가 일방적으로 새로운 애플리케이션을 던져 놓고 도망가는 행동을 그만두어야 IT 환경이 더 발전할 것이라는 내용이었다.

불필요한 소통을 피하라
위의 말에는 분명 진실이 담겨 있다. 조직 대다수는 열린 커뮤니케이션과 상호 소통을 긍정적으로 바라본다. 그러나 때로는 불필요한 소통을 배제할 필요가 있다. 최근에는 개발자와 운영 부서 간의 소통을 최소화하면서 효율성을 높이는 인프라, 프로세스 및 도구가 다양하게 등장했다. 마치 평소 필자가 주거래 은행의 은행원과의 소통을 최소화하고 싶은 것과 비슷한 맥락이다. 일상적인, 그리고 심지어 일상적이지 않은 거래에 있어서도 이왕이면 ATM이나 스마트폰을 활용하고 싶은 것이다.

이러한 요구에 대응하기 위해, 운영 부서는 프라이빗 IaaS(Infrastructure-as-a-Service) 클라우드와 같은 최적화된 트랜잭션을 지원하는 인프라를 구축하고 운영할 의무가 있고, 또 현대적인 컨테이너 플랫폼을 통해 핵심 서비스를 제공해야 한다.

왜 현대화된 플랫폼을 선택해야 하는가?
개발 과정, 그리고 클라우드 네이티브 애플리케이션을 최적화하는 과정은 주로 현대화된 플랫폼에서 진행될 때 더욱 좋은 결과를 얻는다.

서비스 수요가 굉장히 탄력적인 경우에는 아키텍처를 스케일아웃(scale-out) 할 필요가 있다. 단순한, 스케일업(scale-up) 구조의 애플리케이션 설계는 유동적인 수요에 대한 대응력이 부족하거나 아예 대응하지 못 할 수도 있다.

현대화된 플랫폼은 소프트웨어에 의해 정의(Software-defined)되는데, 이는 네트워크 기능 가상화나 소프트웨어 정의 스토리지 등 소프트웨어의 기능이 하드웨어에 임베디드 되어 있을 때보다 훨씬 유연하기 때문이다.

현대화된 애플리케이션은 서로 느슨하게 결합된 서비스들로 이루어지는데, 그 이유는 거대한 모놀리식(monolithic) 애플리케이션은 연약하고, 또한 신속한 업데이트가 어렵기 때문이다. 한편, 현대화된 컨테이너 플랫폼은 반복적인 소프트웨어 개발과 출시를 지원하는데, 이는 현대화된 애플리케이션이 수명이 짧은 경우가 있고, 빈번한 갱신과 대체를 필요로 하기 때문이다.

컨테이너의 도입 및 활용
최초의 컨테이너는 시스템을 구분하는 대체 방법이자 하드웨어 가상화를 대체하는 경량 솔루션으로 시작되었다. 그러나 많은 사람의 관심을 끌게 된 계기는 컨테이너가 애플리케이션 패키징 수단으로 사용되면서부터이다. 애플리케이션의 의존성을 포함하는 이미지를 제공함으로써 컨테이너는 개발, 테스트, 출시 과정에서 보다 휴대하기 쉽고 일관성 있는 패키징 구조를 가진다.

이외 다른 부분에서도 역시 발전이 있었다. 오늘날 오픈 컨테이너 이니셔티브(Open Containers Initiative, OCI)에서 총괄하는 사양(Specification) 등은 컨테이너가 사용하는 이미지와 런타임을 표준화하였다. 이러한 사양은 컨테이너 이미지를 정의하고 컨테이너의 의존성, 환경 및 인수 등의 이미지가 구동될 때 필요한 정보를 확인하는 데 도움을 준다. 이러한 오픈 컨테이너 이니셔티브에서의 표준화 작업을 통해 안정적인 런타임이 보장되고 이를 기반한 많은 도구가 개발될 수 있다. 예를 들어 레드햇은 프로젝트 아토믹(Project Atomic), 스코페오(Skopeo), 빌다(Buildah) 등 다양한 컨테이너 레지스트리 및 컨테이너 개발 프로젝트에 참여하고 있다.

OCI를 준수하는 컨테이너 런타임은 독자적으로 하나의 컨테이너를 관리하는 데 매우 유용하다. 하지만 수백 개로 조각난 컨테이너와 컨테이너화된 애플리케이션을 사용하기 시작하면 관리와 오케스트레이션이 복잡해질 수 있다. 그렇기에 결국은 서비스를 제공하기 위해서는 한 걸음 물러서서 여러 컨테이너를 그룹화해야만 한다.

오케스트레이팅(Orchestrating)하고 관리하기
쿠버네티스는 컨테이너에 대한 오케스트레이팅과 관리를 논할 때 등장하는 개념이다. 원래는 구글에서 개발되었지만 현재는 클라우드 네이티브 컴퓨팅 파운데이션(Cloud Native Computing Foundation, CNCF) 산하 대규모 커뮤니티 프로젝트로 리눅스 컨테이너를 구동하는 여러 호스트들을 모아서 오케스트레이팅하고 관리할 수 있도록 지원한다.

쿠버네티스는 다양한 추가 프로젝트들을 통해서 개발자들과 운영 부서가 배포하거나 운영하고자 하는 클라우드 네이티브 애플리케이션들이 필요로 하는 서비스들을 제공한다. 이는 컨테이너 레지스트리, 텔레미터, 네트워킹 및 보안 등을 포함한다. 최근 오픈소스 관련 혁신 중 상당 부분은 컨테이너에 관한 것이며 이 글에서 다룬 내용은 전체의 일부일 뿐이다.

통합하고 패키징하기
오픈시프트(OpenShift)는 OCI 준수 컨테이너와 쿠버네티스 등의 기술을 통합하여 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux)내 엔터프라이즈 기반 기술과 결합한다. 오픈시프트는 또한 개발 및 운영 부서가 필요로 하는 아키텍처, 프로세스, 플랫폼 및 서비스 등을 통합한다. 또한, 오프시프트는 OKD( https://www.okd.io)를 업스트림 커뮤니티 프로젝트로 가지는 완전한 오픈소스다. 사용자, 컨트리뷰터(contributors) 및 파트너는 모두 오픈시프트 커먼즈(OpenShift Commons)에서 모인다.

클라우드 네이티브 업계에서 일어나고 있는 움직임을 살펴보면 DIY 통합이 야기하는 문제는 매우 명백해진다(이는 IaaS뿐만 아니라 컨테이너 플랫폼에도 적용된다). 변화는 프로젝트 내부에서도 빠르게 일어나고 있고, 새로운 프로젝트가 끊임없이 생겨나며, 개발자와 사용자가 다양한 종류의 업무와 사례를 통해 경험을 쌓으면서 요구하는 여러 접근방식 역시 실시간으로 변화하고 있다.

통합 플랫폼이 가지는 궁극적인 목표는 출발 과정을 간소화하고, 요구하는 역량의 레벨을 낮추어 기업들이 기존 플랫폼에 많은 시간을 들이기보다 각자의 애플리케이션 배포에 집중할 수 있도록 지원하는 것이다. 뿐만 아니라, 컨테이너 플랫폼 도입을 통해 IT 기업 환경의 민첩성을 한층 더 높이고 개발자와 운영자 간의 거리를 좁혀 원활한 데브옵스 환경을 구현하는 것도 또 하나의 최종 목표가 될 것이다.


X