GitOps 성숙도 4단계 (The 4 Levels of GitOps Maturity)

이 글은 다음 블로그를 번역한 글입니다.
원본: https://cloudnativenow.com/features/the-4-levels-of-gitops-maturity/ 

 

GitOps 성숙도 4단계 (The 4 Levels of GitOps Maturity)

2021년 8월 30일 | 컨테이너, GitOps, GitOps 성숙도, 쿠버네티스 작성자: Paul Fremantle

GitOps는 쿠버네티스 애플리케이션 및 클러스터를 운영하고 배포하는 데 있어 빠르게 '골드 표준'으로 자리 잡고 있습니다. GitOps 성공의 객관적인 척도는 주로 DevOps 관련 지표로 결정됩니다. 이러한 DevOps 지표에는 속도(velocity), 배포 빈도, 복구 시간 등이 포함됩니다. 이러한 지표들은 비즈니스 경쟁력 및 성공과 밀접하게 연관되어 있습니다. 즉, 소프트웨어를 더 잘 전달할 수 있는 조직이 더 나은 경쟁력을 갖게 됩니다.

그동안 부족했던 점은 팀이 조직에 맞게 GitOps를 효과적으로 사용하는 방법을 이해하도록 돕는 접근 방식이었습니다. 이는 GitOps의 모범 사례와 운영 효율성을 어느 정도 도입했는지, 그리고 앞으로 얼마나 더 도입해야 하는지를 결정하는 기준이 될 수 있습니다. 이를 위해 최근 만들어진 **GitOps 성숙도 모델(GitOps Maturity Model)**은 조직이 GitOps를 도입할 때 일반적으로 거치게 되는 4단계 접근 방식을 제시합니다. 이는 단일 클러스터 및 애플리케이션 관리에서 시작해, 수백 또는 수천 개의 클러스터에 이르는 대규모 배포 관리로 나아가는 가이드로 활용될 수 있습니다.

Thoughtworks의 저자인 마틴 파울러(Martin Fowler)에 따르면, 성숙도 모델이란 "개인이나 그룹의 현재 효율성을 평가하고, 성과 향상을 위해 다음에 어떤 역량을 습득해야 하는지 파악하도록 돕는 도구"입니다. 이러한 맥락에서 GitOps 성숙도 모델은 조직이 GitOps 도입 단계의 어느 지점에 있는지 판단할 수 있는 간단한 모델입니다. 이 모델은 가장 기본적인 단계(즉, 정의를 Git에 저장하고 지속적인 조정 없이 CI 시스템으로 푸시하는 단계)부터 가장 진보된 단계(수천 개의 클러스터에 걸쳐 배포를 확장하기 위해 GitOps에 의존할 수 있는 능력)까지를 포괄합니다.

단계별 향상 (Leveling Up)

GitOps 성숙도 모델이 나타내는 진화의 4단계와 조직이 가치를 얻으며 거치는 과정은 다음과 같습니다.

• 0단계 (Level 0): 조직이 클라우드 네이티브 및 컨테이너화된 인프라로 이전하고 배포 구성을 Git에 저장하고 있지만, **지속적인 조정(reconciliation)**은 이루어지지 않는 단계입니다. 이 단계의 팀들은 인프라 프로비저닝 속도 향상, 반복 가능성, 불변성(immutability) 등의 이점을 일부 누릴 수 있습니다.
• 1단계 (Level 1): 이 단계에서는 GitOps를 사용하여 애플리케이션을 배포하며, **조정 및 드리프트 감지(drift detection)**를 통해 실행 중인 애플리케이션이 Git에 저장된 의도된 상태(desired state)와 지속적으로 동기화되도록 합니다. 보안이 강화된 GitOps 전달 파이프라인을 통해 자동화와 표준화를 구현함으로써 배포 빈도, 운영 가시성 및 감사 가능성을 대폭 높이고, 비용과 평균 복구 시간(MTTR)을 줄일 수 있습니다.
• 2단계 (Level 2): 조직이 클러스터 생성 및 관리를 포함한 전체 환경에 걸쳐 프로세스 표준화, 자동화, 제어 및 보안이라는 GitOps 개념을 적용하는 단계입니다. 이를 통해 전체 인프라와 애플리케이션에 이점을 제공하며, 팀들이 더 자율적으로 작업할 수 있게 됩니다. 플랫폼 운영팀은 거버넌스, 리스크 및 컴플라이언스 프로토콜을 준수하면서 팀 인원을 늘리지 않고도 클러스터 수를 확장할 수 있습니다.
• 3단계 (Level 3): 대규모 환경에서 일관성, 명확한 정책 집행 및 속도를 확보하기 위해 GitOps로 **클러스터 함대(fleets of clusters)**를 관리하기 시작하는 단계입니다. 이 단계의 조직은 교차 클라우드 벤더 선택권, 고급 정책 모델, 대규모 배포, 그리고 수천 개의 클러스터에 대한 가시성 및 제어 권한을 가질 수 있습니다.

기본 그 이상으로 (Moving Beyond the Basics)

성숙도 모델은 조직이 GitOps 여정의 어디에 있는지 평가하는 것 외에도, DORA 지표를 개선하기 위한 다음 단계를 결정하는 유용한 도구가 됩니다. DORA 지표는 비즈니스 목표 및 경쟁력과 밀접한 상관관계가 있음이 입증되었습니다. 실제로 많은 사례에서 GitOps는 조직이 DORA 지표의 "엘리트(elite)" 수준으로 진입하는 데 도움을 주는 것으로 증명되었습니다. 이런 방식으로 GitOps의 기술적 이점과 비즈니스 성과 사이에는 명확한 연결 고리가 형성됩니다.

그렇다고 모든 조직이 동일한 경로를 택해야 한다는 뜻은 아닙니다. 일부 조직은 바로 높은 단계로 뛰어넘기를 원할 수도 있고, 다른 조직은 굳이 높은 단계까지 갈 필요가 없다고 판단할 수도 있습니다. 그러나 분명한 점은 GitOps의 진정한 혜택은 1단계부터 시작된다는 것입니다.

개발팀은 오픈 소스 GitOps 도구를 사용하여 1단계("애플리케이션 GitOps")를 쉽게 달성할 수 있습니다. 이를 통해 애플리케이션 개발자와 DevOps 전문가는 애플리케이션을 신속하게 구성하고, Git 리포지토리에서 모든 쿠버네티스 클러스터로 지속적으로 배포 및 조정할 수 있습니다. 예를 들어, Weave GitOps는 Flux를 사용하여 드리프트 감지, 이미지 자동화 및 조정을 구현함으로써 클러스터가 Git의 특정 브랜치나 폴더를 정확히 반영하도록 보장합니다.

규모가 큰 조직의 경우, 플랫폼 팀은 엔터프라이즈 오픈 소스 도구를 사용하여 여러 지역, 영역 또는 멀티 클라우드에 걸쳐 수많은 클러스터를 생성하고 관리할 수 있습니다. 이는 AWS, Azure, Google, VMware 등 많은 클라우드 제공업체가 지원하는 Cluster API(CAPI)에 의존합니다. 클러스터 구성의 변경 사항도 1단계의 애플리케이션과 동일한 방식으로 조정됩니다. 각 개발팀은 자신의 워크로드를 이러한 클러스터에 지속적으로 배포하고 조정할 수 있습니다(즉, 2단계는 1단계의 모든 이점을 포함합니다).

소수의 대규모 조직만이 다음 단계로 나아가, 동일한 구성을 가진 다수의 클러스터를 정의하여 '함대 관리(Fleet management)'를 구현했습니다. 대표적인 예로 도이치 텔레콤(Deutsche Telekom)의 Das Schiff 프로젝트가 있는데, 이는 GitOps를 사용하여 수천 개의 에지 클러스터에 5G 워크로드를 일관되고 효과적으로 전달하도록 설계되었습니다. 다만, 모든 조직이 3단계와 같은 요구 사항을 가지는 것은 아닙니다.

요약 (Bringing It All Together)

GitOps는 Git 리포지토리를 CD 파이프라인의 역동적인 지원을 위한 "단일 진실 공급원(Single Source of Truth)"으로 삼는 고도의 협업 프로세스로 구성됩니다. GitOps의 이점은 수없이 많으며 이제 더 널리 이해되기 시작했습니다. 또한 기술 분야의 주요 벤더들 사이에서 쿠버네티스 운영 모델의 표준으로 부상하고 있습니다. 아마존, 코드프레시(Codefresh), 깃허브, 마이크로소프트, 위브워크(Weaveworks) 등은 CNCF의 GitOps 워킹 그룹 내에서 GitOps의 원칙과 기술적 측면에 대해 협력하며 이를 지원하고 있습니다.

GitOps가 이토록 주목받는 주요 이유 중 하나는 그것이 사람, 프로세스, 기술의 교차점에 있기 때문입니다. 이미 조직 내의 여러 팀과 효과적으로 작동하고 있는 잘 알려진 프로세스를 기반으로 하기 때문에, 조직 및 팀 문화에 잘 녹아듭니다.

GitOps 성숙도 모델은 GitOps를 지원하는 다음 단계로 볼 수 있습니다. 즉, 조직이 GitOps를 도입하기 위해 더 구조화된 접근 방식을 계획하도록 돕는 것입니다. 여러분의 조직이 이 4단계와 똑같은 경로를 따르든 그렇지 않든, 일반적인 발전 과정을 이해하는 것은 유용합니다. 배포 방식이 왜 이러한 여정을 거쳐 발전하는지, 그리고 GitOps 성숙도를 높였을 때 얻는 이점이 무엇인지 이해할 수 있기 때문입니다.