본문 바로가기

카테고리 없음

2편: 엔터프라이즈 쿠버네티스로 가는 모든 길은 OpenShift로 통한다!

엔터프라이즈 쿠버네티스로 가는 모든 길은 OpenShift로 통한다!

 

쿠버네티스는 컨테이너 기반의 오픈 소스 PaaS(Platform as a Service) 프로젝트입니다. 널리 알려진 바와 같이 오픈 소스는 기술 측면에서 벤더 종속이 없으며, 빠르게 버전을 올리며 발전하는 특징이 있습니다. 이는 매우 큰 장점이지만 운영과 관리 측면에서는 부담이기도 합니다. 오픈 소스 프레임워크를 놓고 소프트웨어 스택을 구성해 플랫폼화경우 복잡성이 매우 높아질 수 있습니다. 따라서 이를 구축하고 운영하려면 매우 높은 수준의 전문성을 갖춘 기술 인력으로 팀을 구성해야 합니다. 기술 내재화가 필수란 소리죠. 문제는 모든 기업이 오픈 소스 기술을 내재화할 수 없다는 것입니다. 시간, 인력, 예산은 늘 부족한 자원이기 때문입니다. 이런 이유로 많은 기업이 엔터프라이즈의 기준을 충족하는 사전에 최적화된 형태로 오픈 소스 솔루션을 이용하길 원합니다. OpenShift는 이런 시장의 요구에 부응하기 위해엔터프라이즈 쿠버네티스라는 수식어를 달고 나온 플랫폼입니다. 관련해 엔터프라이즈 쿠버네티스가 갖추어야 할 주요 특징이 무엇인지 집어 보겠습니다.

 

엔터프라이즈 쿠버네티스의 개념 정의

 

레드햇 OpenShift엔터프라이즈 쿠버네티스라고 부르는 이유는 무엇일까요? 컨테이너 기반 PaaS 환경을 구축하는 데 필요한 다양한 소프트웨어 구성 요소를 엔터프라이즈가 요구하는 기준에 맞게 사전에 최적화된 형태로 제공하기 때문입니다. 레드햇 OpenShift의 아키텍처를 보면 운영체제부터 컨테이너, 쿠버네티스, 운영 자동화 도구, 중앙집중적인 관리 도구, 개발 환경 등이 모두 갖추어져 있음을 알 수 있습니다.

 

 

레드햇 OpenShift를 사용하지 않는다면 위 그림에 나오는 모든 구성 요소 간 최적의 조합을 찾아 시행착오를 거듭해야 합니다. 관리자가 직접 공부해 가며 쿠버네티스 환경을 구축한다는 것은 쉽지 않은 일입니다. 레드햇 엔터프라이즈 리눅스(RHEL), 레드햇 코어OS, 데비안, 우분투 중 어떤 리눅스 배포본을 선택할 것인가? 쿠버네티스 버전은 무엇을 쓸 것인가? kubeadm, kube-spray, kops 중 설치 도구는 뭘 써야 하나? 클러스터 구성부터 난항을 겪습니다. 더 큰 시련은 쿠버네티스 환경에서 애플리케이션을 실행하고 관리할 때 시작됩니다. 쿠버네티스는 수백 개의 구성 요소로 이루어진 복잡한 프레임워크입니다. 운영자가 완벽하게 동작 원리와 기능을 이해하는 것이 불가능할 정도입니다. 그리고 각 릴리즈에 포함된 결함, 성능 이슈, 보안 취약점이 무엇인지 일일이 살펴야 하는 데 이 또한 하나하나 챙기기 어렵습니다. 이런 이유로 기술 내재화 측면에서 커뮤니티 버전의 오픈 소스를 이용할 경우 쿠버네티스가 약속하는 유연한 확장성, 매끄러운 이식성, 운영과 개발의 분리, DevOps 기반 자동화 등의 이점을 충분히 누리기 어렵게 될 확률이 높습니다.

 

레드햇 OpenShift는 쿠버네티스 도입과 활용을 가속합니다. 도입을 위해 번거롭게 기술 검토와 평가를 하고 내재화에 필요한 시간을 확보할 필요가 없습니다. 조직이 목표로 삼은 클라우드 전략에 맞춰 컨테이너 기반 컴퓨팅 환경으로 전환하는 것에 집중하면 됩니다. 이게 가능한 이유는 레드햇 OpenShift가 갖는 엔터프라이즈 쿠버네티스 측면의 기능성 때문입니다.

 

간소화, 보안성 그리고 일관성

 

엔터프라이즈 쿠버네티스가 갖추어야 할 3대 요소로 간소화, 일관성, 보안성을 꼽습니다. 먼저 간소화의 경우 레드햇 OpenShift는 클라우드 서비스만큼 사용이 쉬워 개발과 운영 모두를 간소화할 수 있습니다. 컨테이너 환경을 신속하게 구축하고, 각종 엔터프라이즈 소프트웨어 관련 이미지를 신속하게 배포할 수 있습니다. 레드햇 OpenShift는 운영팀과 개발팀 모두가 하나의 통합 플랫폼을 바라보고 일할 수 있게 합니다. 운영팀은 레드햇 OpenShift에 포함된 모니터링, 로깅, 분석 솔루션을 이용해 일상적인 관리를 할 수 있습니다. 필요에 따라 써드파티 도구를 연계해 쓰기도 편합니다. 개발팀은 다양한 개발 언어, 프레임워크, 미들웨어, 데이터베이스를 선택할 수 있어 지속적 통합과 배포(CI/CD) 기반으로 생산성을 높일 수 있습니다.

 

(출처: 레드햇 백서 - Boost business agility)

 

보안성 또한 레드햇 OpenShift가 엔터프라이즈에서 환영받는 주된 이유입니다. 레드햇 OpenShift에는 각 릴리즈에 포함된 여러 기능 결함, 성능 저하 이슈, 보안 취약점에 대한 픽스를 적용한 엔터프라이즈 수준의 쿠버네티스가 적용됩니다. 또한, 리눅스 운영체제와 쿠버네티스에 대한 업데이트를 OTA(Over-the-Air) 방식으로 자동화할 수 있어 최신 릴리즈가 제공하는 혜택을 빠르고 안전하게 적용할 수 있습니다. 여기에 더해 레드햇이 인증한 써드파티 애플리케이션의 자동화 역시 지원될 예정입니다.  

 

세 번째 특징인 일관성을 알아보겠습니다. 레드햇 OpenShift는 기업의 클라우드 전환을 가속하는 촉매이자 사설, 하이브리드, 공용 클라우드를 연결하는 구심점 역할을 할 수 있습니다. 이게 가능하게 하려면일관성을 보장할 수 있어야 합니다. , 사설, 하이브리드, 공용 클라우드 어느 위치이건 레드햇 OpenShift를 설치해 일관성 있게 애플리케이션 개발과 배포를 할 수 있어야 한다는 것입니다.

 

하이브리드 클라우드 전략의 시작이자 완성

 

레드햇 OpenShift는 하이브리드 클라우드로 향하는 전환의 여정에 있어 매우 좋은 출발점을 제공합니다. 레드햇 OpenShift의 경우 버전 3.3부터 물리적 서버, 가상화 환경, 사설 클라우드, 공용 클라우드 환경에 상관없이 RHEL 7.2 또는 RHEL Atomic Host 7.2가 설치되어 있다면 레드햇 OpenShift를 설치해 사용할 수 있습니다. 레드햇 OpenShift는 최초 설치 후 사용자가 도커 이미지를 생성해 포드에 담아 노드에 배포하는 과정이 매우 간결합니다. 또한 마스터가 제공하는 스케줄러 기능을 이용해 필요한 사내, 사외에 구성한 노드에 유연하게 배포하는 과정도 간결합니다. 장애에는 매우 강합니다. 처음 설치를 하면 장애 대비를 위해 마스터가 이중화로 구성됩니다. 그리고 레드햇 OpenShift 환경에서 최소 관리 단위인 포드에 장애가 나면 자동으로 포드가 복제되어 재배포됩니다. , 마스터와 포드 어느 곳에서 문제가 일어나도 단일 장애 지점으로 인한 서비중단의 위험이 없습니다.

 

또한, 레드햇 OpenShift는 오픈 소스의 이점을 살려 벤더 종속의 위험도 없습니다. 따라서 여러 클라우드 사업자 제공하는 서비스 간에 연계와 통합이 가능하고 클라우드 서비스의 이용 조건과 기능에 변화가 생겨도, 이에 영향받지 않고 유연하게 조직이 대응할 수 있도록 합니다.

 

 

운영이 아니라 코드에 집중

 

PaaS를 이용하는 궁극적인 목표는 운영과 개발을 분리하고, 각 팀이 유기적으로 협력하는 가운데 DevOps가 조직의 문화이자 일하는 방식으로 자리를 잡게 하는 것입니다. 레드햇 OpenShift DevOps를 복잡하고 어려운 주제가 아니라 매일 같은 일상으로 앞당깁니다. 개발자는 평소 하던 데로 웹 콘솔, CLI, IDE를 이용해 빌드, 테스트, 배포를 하면 됩니다. SCM에 있는 소스 코드를 이용해 자동으로 이미지가 빌드되고, 테스트 후 배포가 이어집니다. 롤링 배포를 이용한 무중단 배포도 가능하며, 문제 발생 시 이전 배포 이미지로 롤백을 하면 됩니다. 웹 콘솔로 모니터링을 하다 배포한 서비스에 부하가 집중되면 오토스케일링을 통해 성능 이슈를 해결하면 됩니다. 소스가 이미지로 생성되어 배포되는 데 있어 DevOps가 자연스럽게 이뤄지게 됩니다.

 

 

레드햇 OpenShift 사용 효과를 극대화하는 방법

 

레드햇 OpenShift는 분명 쓰기 쉽습니다. 하지만 첫 출발이 중요합니다. 기업에서 사용하는 비즈니스 애플리케이션은 레거시부터 네이티브 클라우드까지 그 종류가 다양합니다. 따라서 각 유형에 맞는 컨테이너화 전략이 필요하고, 실제 마이그레이션을 위한 실무 측면의 가이드라인도 있어야 합니다. 이 외에 컨테이너에 올릴 이미지에 대한 내부 기준도 명확히 해야 합니다. CI/CD 역시 기존에 하던 방식을 어떻게 점진적으로 바꾸어 갈지 로드맵을 가지고 가야 합니다.  이에 대한 상세 내용은 다음 포스팅에 소개할 보험사의 사례를 통해 자세히 알아보겠습니다.

 

 

2020/03/04 - 1편: 컨테이너, 쿠버네티스, DevOps 유행 따라잡기!

2020/03/18 - 2편: 엔터프라이즈 쿠버네티스로 가는 모든 길은 OpenShift로 통한다!

2020/04/01 - 3편: OpenShift 구축 성공 사례: A생명보험사

2020/04/16 - 4편: 글로 보는 웨비나 1편 - OpenShift 구축 사례와 컨테이너로 환경 전환 시 고려 사항

2020/04/29 - 5편 : 글로 보는 웨비나 2편 - Microsoft Azure 클라우드에서 Red Hat OpenShift 시작하기

2020/05/13 - 6편 : 글로 보는 웨비나 3편- ARO(Azure Red Hat OpenShift) 운영 시나리오 및 Demo

 

 

위의 내용은 격주 수요일 마다 업데이트 될 예정입니다. 

해당 칼럼을 빠르게 받아보길 원하신다면? 

락플레이스 뉴스레터 신청하기 (클릭)