"레거시 현대화와 클라우드 네이티브 전환을 모두 달성하는 투트랙 전략 필요"

기업들의 데이터센터에는 오래전부터 사용해온 메인프레임과 리눅스, 윈도우 서버를 비롯해 가상머신과 최신 클라우드 기반 인프라인 컨테이너까지 다양한 운영 환경이 혼재한다.

그리고 이 환경에는 마찬가지로 오래전 개발했던 애플리케이션부터 클라우드 네이티브 애플리케이션까지 여러 가지가 공존하기 마련이다. 

이렇게 여러 세대의 기술이 혼재되면 운영 효율 이슈가 수면 위로 떠오른다.

일반적으로는 ITIL(Information Technology Infrastructure Library) 프레임워크 기반 관리 체계나 ITSM(IT Service Management) 툴로 비즈니스 시스템을 운영하고 개선해 왔으며, 이를 기반으로 개발 및 운영 조직, 정보 및 기술, 파트너 및 공급 업체 등을 관리한다.

반면, 이런 방식으로는 애플리케이션 현대화 및 클라우드 네이티브로의 전환까지 수용하기가 어렵다.

더불어 레거시 유지보수가 나날이 어려워지는 것도 작지 않은 문제다.

노후화된 시스템은 운영체제나 미들웨어 등 주요 소프트웨어의 EOS(End of Service) 대응, 레거시 코드 수정, 보안 업데이트, 클라이언트 및 브라우저 호환성 보장 등에 어려움이 크다.

이런 이유로 많은 기업이 레거시부터 클라우드 네이티브까지 앱 포트폴리오 혁신을 중요 과제로 꼽는 상황이다.

◆컨테이너를 활용한 클라우드 네이티브 전환

앱 포트폴리오 혁신의 핵심은 컨테이너다.

레거시 현대화의 수단이자 향후 클라우드 네이티브로 전환하는 구심점으로 컨테이너를 활용하는 것이 가장 보편적인 접근이기 때문이다.

보통 앱 포트폴리오 진화는 크게 5가지 옵션을 고려할 수 있다.

전통적인 워크로드는 사용을 중단하거나 SaaS(서비스형 소프트웨어)로 대체할 수 있고, 코드 및 구성 최적화 등 개선을 통해 운영을 유지할 수도 있다.

또한 가상화 기반 IaaS(서비스형 인프라)로 운영 기반을 옮기는 방법도 고려할 수 있다.

레거시 애플리케이션 중 현대화가 가능한 워크로드는 컨테이너를 활용해 클라우드 네이티브 플랫폼으로 이전하거나 클라우드 네이티브 방식으로 새로 개발하는 방안을 선택할 수도 있다.

예전에는 소프트웨어를 개발할 때 요구 사항 수집 및 분석, 설계, 테스트, 산출물 전달, 유지보수 같은 일련의 절차를 순차적으로 진행하는 워터폴(waterfall) 방식을 주로 채택해 왔지만, 변화가 빠른 최근의 환경에서는 개발 유연성이 떨어진다는 한계에 부딪친다. 

클라우드 네이티브 앱 개발은 애자일(Agile) 방법론을 따른다. 민첩하게 프로젝트를 진행하는 가운데 지속적인 개선을 하는 접근이다.

즉, 계획, 설계, 개발, 테스트, 배포가 매우 빠르게 진행되며, 짧고 점진적인 주기로 개발이 진행되다 보니 빠르고 유연하게 기능을 구현하고 품질을 개선할 수 있는 장점이 있다.

다만 데브옵스 파이프라인과 도구가 잘 갖춰지지 않거나 팀원들이 애자일 방법론에 대한 이해가 없으면 여러 문제가 발생할 수 있다. 따라서 데브옵스 방식에 대한 치밀한 준비가 필요하다.

마이크로서비스 구조의 클라우드 네이티브 아키텍처는 서비스 규모가 커지면 복잡성이 크게 증가하기 때문에 엔터프라이즈 수준의 관리 편의성, 보안을 제공하는 쿠버네티스 플랫폼이 필요하다.

▲ 그림1. 앱 포트폴리오 진화의 5가지 옵션.

◆레거시와 클라우드 네이티브의 공존을 위한 인프라

앱 포트폴리오를 혁신하려면 현재 사용 중인 레거시 운영 효율을 높이는 가운데 클라우드 네이티브 앱 개발을 위한 도구와 절차를 지원할 수 있는 새로운 아키텍처를 점진적으로 발전시켜 나아가야 한다.

그리고 MSA(마이크로서비스 아키텍처) 기반 클라우드 네이티브 환경을 위한 서비스 메시(Service Mesh) 플랫폼을 이용해야 한다.

과거, 현재, 미래를 모두 품을 수 있는 앱 포트폴리오 혁신을 추진하려면 5가지 난제를 넘어서야 한다.

첫 번째는 클라우드 네이티브 환경 구축의 어려움이다.

가상화, 컨테이너를 하나의 추상화된 인프라로 활용할 수 있는 인프라 구축이 필요하다.

두 번째는 운영의 어려움이다. 마이크로서비스는 그 규모가 클수록 복잡성도 함께 높아진다.

쿠버네티스에 대한 깊은 지식 없이는 효율적인 운영이 어렵다. 쿠버네티스 운영 역량을 확보할 수 있는 검증된 플랫폼이 필요한 이유다. 

세 번째는 기술 부채다. 오랜 기간 활용한 ITIL 프레임워크나 ITSM 도구는 레거시 환경에 맞추어져 있다.

이를 유지하는 가운데 마이크로서비스 아키텍처와 애자일 기반 데브옵스(DevOps) 환경에 맞는 운영 및 지원 방안도 마련해야 하는 부담이 존재한다.

네 번째는 투자 비용이다.

예산계획 수립과 집행에 있어 기존 환경 유지와 함께 클라우드 네이티브 관련 재원을 마련해야 한다.

다섯 번째는 IT 인프라의 문제다.

오늘날 엔터프라이즈 컴퓨팅은 하이브리드 클라우드를 넘어 여러 클라우드 서비스 업체를 이용하는 멀티클라우드로 확대되고, 더 나아가 엣지까지 그 경계를 넓혀가고 있다.

이처럼 요구조건이 빠르게 변하는 인프라를 어떻게 통합하고 운영할 것인가를 고민해야 한다.

◆경계를 넘어서는 이동성을 제공하는 인프라

레거시, 현대화된 애플리케이션, 클라우드 네이티브 앱 모두를 원활하게 지원하려면 엔터프라이즈 컴퓨팅 인프라를 바라보는 시각을 바꿔야 한다.

데이터센터라는 물리적 장소와 장비만 바라보면 앱 포트폴리오 혁신을 이어갈 수 없다. 장소와 장비의 개념이 아니라 운영의 시각으로 바라봐야 한다.

앱 포트폴 리오 혁신을 운영 모델 개선으로 접근하면 경계를 넘어서는 이동성을 보장할 수 있다. 

ESG의 조사에 따르면 응답자의 74% 가 운영 일관성이 혁신 속도를 높일 것이라고 답했다.

멀티클라우드와 엣지까지 일관성 있는 운영 환경을 위해 VM웨어 탄주(Tanzu) 애플리케이션 플랫폼은 가상머신과 컨테이너 관리를 단일화 한다.

데브옵스 엔지니어가 가상머신과 컨테이너 배포와 관리를 단일 플랫폼에서 할 수 있다는 얘기다. 

v스피어(vSphere)에 가상머신을 배포해야 할 경우 데브옵스 엔지니어는 쿠버네티스 YAML 파일에 배포 사양을 작성해 가상머신과 게스트 운영체제를 프로비저닝할 수 있다.

▲ 그림2. 멀티클라우드 환경에서의 민첩성을 보장하는 일관성.

컨테이너 배포도 간단하다.

프라이빗 클라우드, 퍼블릭 클라우드, 엣지 등 어느 위치에 쿠버네티스 클러스터가 위치해도 간편히 배포할 수 있다.

탄주는 컨테이너 생성, 관리, 거버넌스를 자동화한다.

따라서 쿠버네티스에 대한 전문 지식이 없는 개발자나 운영자도 손쉽게 어디서나 쿠버네티스 런타임을 배포하여 최신 앱을 제공할 수 있다.

또한, 마이크로서비스 아키텍처가 갖는 복잡성의 문제도 없다. 여러 위치에 있는 클러스터를 통합 관리하며 전체 스택에 대한 모니터링을 중앙집중적으로 수행할 수 있다.

덕분에 프라이빗, 퍼블릭, 엣지 등 모든 환경에 일관되게 앱을 배포하고 관리할 수 있다.

앱 포트폴리오 혁신 여정이 성공하려면 컨테이너, 마이크로서비스 아키텍처, 데브옵스 같은 새로운 것만 강조하면 안 된다.

클라우드 네이티브 앱이 모든 것을 대체할 수는 없다.

성능, 안정성, 보안, 사용자 특성 등에 따라 전통적인 아키텍처와 방법론을 유지해야 할 것이 있고 마이크로서비스 아키텍처 기반의 신규 앱으로 개발할 것이 있다. 

또한, 컨테이너 전환을 통한 애플리케이션 현대화 후 점진적인 수정과 개선을 통해 아키텍처를 바꾸어야 할 것도 있다. 이에 따라 과거의 것과 미래의 것을 투트랙으로 유지하는 전략이 필요하다. 

델 테크놀로지스(Dell Technologies)는 VM웨어와 협력을 통해 레거시 애플리케이션부터 네이티브 클라우드 앱까지 일관성있게 운영 및 유지보수하고, 비즈니스 환경에 필요한 앱 혁신 솔루션을 엔드-투-엔드로 제공하고 있다.

<글 = 박성덕 한국 델 테크놀로지스 상무>