컨테이너 오케스트레이터인 쿠버네티스(2014년 구글에서 개발)가 클라우드 네이티브 조직의 핵심 계층이 됨에 따라 기업은 방대한 컨테이너를 관리하고 원하는 상태와 실제 상태를 조정하는 전문적 역량을 갖춰야 하는데, 그러려면 전통적으로 깊은 도메인 지식이 필요하다. 헬름(Helm) 차트를 작성하고 YAML 언어로 코딩하는 역량도 포함된다.
구글 특별 엔지니어이며 쿠버네티스의 최초 설계자 중 한 명인 브라이언 그랜트는 지난 주 블로그 글에서 “모든 규모의 기업이 쿠버네티스를 활용해 인프라에서 애플리케이션을 구축, 배포, 운영하는 방법을 현대화한다. 이들 기업에서 사용하는 개발 및 프로덕션 클러스터의 수가 증가함에 따라 점점 더 커지는 환경 전반에 일관적인 구성 및 보안 정책을 만들어 적용하기가 어려워지고 있다”라고 썼다.
깃옵스 : 깃으로 시작하는 데브옵스
깃옵스는 이와 같은 문제에 대처하기 위해 기존 데브옵스에 대한 확장으로 부상했다. 인프라를 코드로 취급함으로써 애플리케이션과 그 기반 인프라를 버전 제어 시스템(대체로 깃)에 저장할 수 있으며, 그러면 깃은 개발 팀과 운영 팀 모두를 위한 단일 진실 공급원이 된다.이후 소프트웨어 에이전트(대부분의 경우 오픈소스 아르고(Argo) 또는 플럭스(Flux) 지속적 제공 툴)가 애플리케이션의 실제 상태가 구성 파일에 선언된 원하는 상태와 일치하는지를 확인한다. 현재 위브웍스(Weaveworks), 코드프레시(Codefresh)와 같은 업체는 기업의 도입을 용이하게 하기 위해 호스팅되는 깃옵스 플랫폼을 구축하는 방안을 모색하고 있다.
그랜트는 Infoworld와의 인터뷰에서 “자세히 보면 깃옵스는 퍼펫(Puppet)과 비슷하다. 선언적 접근 방법이며 동기화를 유지하는 소프트웨어 에이전트로 완성된다”라고 말했다.
그러나 이 새로운 방식을 실행하기 위해서는 쿠버네티스 구성 파일을 작성 및 유지하고 보안과 일관성을 저해하지 않으면서 개발자에게 필요한 요소를 제공하기 위한 프로세스를 마련하는, 운영 전문가가 해야 하는 큰 작업이 여전히 필요하다.
구글이 깃옵스를 간소화하는 방법
그랜트는 자신이 극초기부터 깃옵스를 지지해왔으며 구글은 쿠버네티스와 깃옵스를 빵과 버터처럼 조화로운 관계로 본다고 말했다. 지금까지의 문제는 많은 기업이 다양한 쿠버네티스 구성을 대규모로, 일관적으로 구성하고 관리하는 데 어려움을 겪고 있다는 점이다.구체적으로 구글 클라우드는 다양한 구성 작업을 그래픽 사용자 인터페이스(GUI) 및 명령줄 인터페이스(CLI)와 같이 개발자에게 친숙한 툴과 더 호환되게 하는 방식으로 깃옵스 원칙을 사용해 쿠버네티스 환경을 간소화하는 데 도움이 되는 여러 툴을 개발 중이다.
그랜트는 “사용자는 UI에서 몇 초면 될 변경을 구성 툴을 통해서 하면 며칠이 걸린다고 이야기한다. 깃옵스를 정말 사용 가능하게 하려면 선호하는 클라이언트 표면과 구성 툴 간의 본질적인 격차를 해소해야 한다”라고 주장했다.
이러한 노력의 중심에는 먼저 오픈소스화된, 플랫폼 팀의 인프라 관리를 돕기 위한 패키지 중심 툴체인인 kpt가 있다.
그랜트는 현재 구글이 개발자가 패키지 생성, 편집, 변환, 업그레이드 작업을 포함한 WYSIWYG(What You See Is What You Get) 구성을 만들고 자동화할 수 있도록 하기 위해 패키지 오케스트레이터 포치(Porch)와 함께 동작하도록 이 툴체인을 확장하고 있다고 말했다.
또한 구글은 스포티파이에서 플랫폼 팀의 셀프 서비스 내부 개발자 포털 구현을 지원하는 인기 있는 오픈소스 플랫폼인 백스테이지(Backstage)를 위한 오픈소스 플러그인도 구축했다. 그랜트는 “이것은 WYSIWYG GUI 경험을 제공한다. 패키지 오케스트레이터를 기반으로 해서 가드레일을 적용하는 동시에 플랫폼 및 애플리케이션 팀이 구성을 손쉽게 저작, 편집하도록 한다. YAML, 패치 또는 템플릿을 작성할 필요가 없고 심지어 변경을 분기, 커밋, 태그, 푸시, 병합할 필요도 없다”라고 썼다.
그랜트는 GUI를 사용한 깃옵스 실행 자체는 새로운 것이 아니지만 “현재 주도적인 여러 접근 방법의 경우 쿠버네티스 리소스 모델 위에 맞춤형으로 구축해야 하는 추상화(많은 경우 얇은 추상화)를 생성해야 한다. 결과적으로 플랫폼 팀이 쿠버네티스를 기반으로 하는 관리 환경을 만들기 위해 많은 부가적인 일을 해야 한다. 이제 구글은 전술한 여러 노력을 통해 성가신 얇은 추상화(thin abstraction)를 요구하는 대신 기존 생태계를 보완하는 GUI를 실현할 수 있을 것으로 기대하고 있다”라고 썼다.
초기 단계에서는 네임스페이스 및 이와 인접한 쿠버네티스 정책 리소스의 프로비저닝과 관리를 지원하는 데 그칠 수 있지만, 구글은 향후 더 많은 클러스터 관리 작업이 가능하도록 계획하고 있다.
또한 클러스터 운영자와 플랫폼 관리자는 구성 관리를 간소화하기 위해 리소스를 변환하고 변형을 생성하는 함수의 선택을 가능하게 한다는 측면에서 커스터마이즈(kustomize) 등과 비슷한 방식으로 kpt를 사용할 수도 있다. 이러한 함수를 구성 카탈로그의 기반으로 사용해 이후의 비슷한 인스턴스를 더 빠르게 가동할 수 있게 된다.
그랜트는 “구성 가능한 함수(composable function)는 플랫폼 빌더에게는 로우코드 환경을, 플랫폼 사용자에게는 노코드 환경을 가능하게 한다”라고 썼다.
구글은 최근 자체 깃옵스 참조 구현인 컨피그 싱크(Config Sync)를 오픈소스로 전환하고 이를 kpt의 일부로 포함하기도 했다.
마지막으로, 그랜트는 리눅스 재단의 클라우드 네이티브 네트워크 자동화 프로젝트인 네피오(Nephio)를 언급하며 “네피오는 kpt, 포치 및 컨피그 싱크를 기반으로 하며 상호 연결된 네트워크 기능과 이러한 기능을 지원하는 기반 인프라의 구성을 자동화한다”라고 썼다.
깃옵스의 다음 단계는?
구글은 kpt가 깃옵스를 간소화하고 폭넓은 도입을 촉진하는 개방형 표준이 되기를 원한다. 그랜트는 클라우드 업체가 “기술을 진전시키기 위해 커뮤니티와 교류에 나서고 있다”라고 썼다.위브웍스 창업자인 알렉시스 리차드슨은 Infoworld와의 이메일 인터뷰에서 “구글이 깃옵스에 투자하고 이 커뮤니티에 들어온 것은 매우 고무적인 일”이라며 “기업은 쿠버네티스의 세부 사항에 대해 알 필요 없이 새로운 서비스를 내놓기 위한 개발자 툴을 요구하고 있다. 새로운 구글 시스템이 바로 그 요구에 대응하며, 기본적으로 위브웍스의 모든 툴과 함께 사용할 수 있다. 가장 좋은 점은 누구나 사용하고 이를 기반으로 확장해서 엔터프라이즈급 솔루션을 만들 수 있다는 것”이라고 설명했다.
레드몽크(RedMonk) 분석가 제임스 거버너 역시 구글의 이번 발표가 깃옵스가 업계 전반에서 계속 입지를 다지고 있음을 보여주는 증거라면서 “구글 클라우드가 깃옵스에 무게를 둔다는 것은 워크플로우 접근 방식에 힘을 싣는 또 다른 뚜렷한 징표”라고 강조했다.
editor@itworld.co.kr