Argo CD와 깃옵스를 활용한 블럭스의 쿠버네티스 자원 관리 노하우

빠르게 변화하는 비즈니스 환경에서 안정적이면서도 확장 가능한 시스템을 운영하는 것은 많은 기술 조직의 핵심 과제가 되었습니다. 특히 대량의 데이터를 처리하고 실시간으로 최적화해야 하는 서비스라면 더욱 그렇습니다.

블럭스(Blux)는 이러한 도전 과제에 대응하기 위해 쿠버네티스(Kubernetes) 기반 운영 환경을 구축하고, 초기 단계부터 CI/CD 시스템을 도입해 개발과 배포의 효율성을 극대화하고자 했습니다.

CI/CD 시스템이 중요한 이유는 명확했습니다.

반복적인 수작업 없이 빠르고 안정적으로 애플리케이션을 배포할 수 있어야 했고, 운영 과정에서 발생하는 오류를 자동으로 감지하고 대응할 수 있어야 했습니다. 또한, 개발팀과 운영팀 간의 협업을 원활하게 만들어 서비스 품질을 지속적으로 개선할 수 있는 환경이 필요했습니다. 이를 위해 블럭스는 다양한 기술적 선택지를 검토한 끝에 Argo CD를 활용한 배포 자동화를 도입했습니다.

이번 글에서는 블럭스가 CI/CD 구축 과정에서 어떤 전략을 수립했으며, Argo CD를 활용해 운영 효율성을 어떻게 극대화했는지 실전 노하우를 공유하겠습니다.

블럭스에서는 어떻게 Argo CD를 도입하게 되었나요?

2023년 5월, 블럭스는 상품 추천과 관련한 주요 서비스를 쿠버네티스 환경에서 운영하기 시작했습니다. 쿠버네티스(Kubernetes)는 컨테이너화된 애플리케이션을 자동으로 배포, 확장 및 운영할 수 있도록 해주는 오픈소스 오케스트레이션 플랫폼으로, 빠르게 변화하는 비즈니스 요구 사항에 대응할 수 있는 유연성을 제공했습니다.

저희는 초기에 쿠버네티스 환경을 세팅할 때부터 CI/CD 시스템(Continuous Integration and Continuous Delivery System, 애플리케이션의 지속적인 통합 및 배포를 자동화하는 시스템) 구축에 많은 집중을 했습니다.

CI/CD 시스템을 구축한다는 것은 애플리케이션 개발 단계부터 배포 때까지의 모든 단계를 자동화를 통해 좀 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있는 시스템을 만든다는 것을 의미합니다. 저희가 이렇게 초기부터 CI/CD 시스템 구축에 힘을 쏟은 이유는 다음과 같습니다.

(1) 개발 속도 향상

• 애플리케이션 코드를 빠르고 안정적으로 배포하기 위해 자동화된 파이프라인이 필요하다고 생각했습니다.

• 개발자들이 배포 과정에서 발생하는 수동 작업을 최소화함으로써 실제 개발에 집중할 수 있도록 지원하고자 했습니다.

(2) 운영 안정성 강화

• 자동화된 테스트와 배포 프로세스를 통해 배포 중 발생할 수 있는 오류를 사전에 감지하고 대응할 수 있어야 한다고 생각했습니다.

• 롤백 절차를 간소화하여 서비스 가용성을 높이고, 운영 환경의 안정성을 확보하는 것이 중요하다고 생각했습니다.

(3) 팀 간 협업 효율화

• CI/CD 파이프라인을 통해 개발팀과 운영팀 간의 협업을 원활하게 만들고, 변경 사항을 추적 및 관리하기 쉽게 하고자 하였습니다.

• 배포 과정에서의 투명성과 신뢰성을 강화하여 팀 전체의 생산성을 높이고자 하였습니다.

블럭스는 쿠버네티스 자원의 효율적이고 자동화된 관리를 위한 CD 도구로 Argo CD를 선택했습니다. 여러 가지 도구 중 Argo CD를 선택한 이유는 Argo CD가 깃(Git, 분산 버전 관리 시스템으로 코드 변경 이력을 효과적으로 관리할 수 있는 도구)과 쿠버네티스 클러스터의 상태를 자동으로 동기화해 수동 배포의 오류를 줄여주고, 다양한 배포 전략을 지원하여 운영 안정성과 유연성을 크게 향상시키는 데 도움을 주기 때문입니다. 그리고 무엇보다도 Argo CD는 이미 쿠버네티스 환경에서 가장 널리 사용되는 CD 도구 중 하나이기 때문에 자연스럽게 이를 선택하게 되었습니다.

Argo CD와 깃옵스란 무엇인가요?

Argo CD는 쿠버네티스를 위한 선언적 애플리케이션 관리 도구로 깃 리포지토리(Repository, 소스 코드와 관련된 파일을 저장하고 관리하는 공간)를 기반으로 클러스터의 상태를 자동으로 동기화하고 관리할 수 있습니다.

주요 특징은 다음과 같습니다.

(1) 자동 동기화

• Git 리포지토리에 정의된 쿠버네티스 자원 상태와 실제 클러스터의 상태를 동기화하여 관리의 일관성을 보장합니다.

(2) 사용자 친화적인 UI와 CLI

• 웹 기반 UI와 CLI(Command Line Interface, 명령줄에서 입력한 명령을 통해 시스템과 상호작용하는 인터페이스)를 통해 애플리케이션 배포 상태를 시각적으로 확인하고 관리할 수 있습니다.

(3) 다양한 배포 전략 지원

• 블루-그린 배포(Blue-Green Deployment, 두 개의 환경을 번갈아 사용하여 무중단 배포를 가능하게 하는 전략), 카나리 배포(Canary Deployment, 새로운 버전을 소수의 사용자에게 먼저 배포하여 안정성을 검증한 후 전체 배포를 진행하는 방식) 등 다양한 배포 전략을 손쉽게 설정할 수 있습니다.

(4) 헬름 차트 및 커스토마이즈 통합

• 헬름 차트(Helm Chart, 쿠버네티스 애플리케이션을 패키징하여 배포 및 관리할 수 있도록 하는 도구) 와 커스토마이즈(Kustomize, 쿠버네티스 매니페스트의 중복을 줄이고 환경별 설정을 쉽게 관리할 수 있도록 하는 도구)와 같은 도구와 통합하여 쿠버네티스 자원을 더욱 유연하게 관리할 수 있습니다.

위에서 언급했듯이 Argo CD는 이미 전 세계적으로 쿠버네티스 환경에서 가장 널리 쓰이는 CD 도구로 오픈 소스의 형태로 관리 및 개발되고 있기 때문에 지금 이 시간에도 세계 각국의 개발자들이 Argo CD의 성능 개선과 문제 해결 등을 위해 힘쓰고 있습니다.

‘Argo CD의 공식 깃허브 리포지토리’에 들어가 보면 문서 최상단에 위 그림에 있는 문구가 있습니다.

번역하자면 ‘Argo CD는 쿠버네티스를 위한 선언적 깃옵스 지속적 전달 도구’라는 뜻입니다. 여기서 깃옵스(GitOps)는 무엇을 의미할까요?

깃옵스는 애플리케이션과 인프라를 깃 리포지토리를 통해 관리하는 선언적 방법론입니다. 선언적 방법론(Declarative Methodology)이란 결과물에 초점을 맞춘 설정 및 관리 방식을 의미합니다.

사용자가 시스템의 최종 상태(Desired State)를 정의하기만 하면, 시스템이 이를 스스로 구현하는 것입니다. 사용자는 ‘어떻게’라는 구체적인 절차를 지정하지 않고, 시스템이 달성해야 할 최종 상태만을 명확히 정의하기 때문에 컨테이너화된 애플리케이션을 자동으로 배포하고 관리해 주는 쿠버네티스와 같은 환경에서 특히 유용합니다.

깃옵스는 다음과 같은 핵심 원칙을 기반으로 작동합니다.

(1) 깃을 단일 정보 소스로 사용

• 모든 자원의 현재 상태와 변경 내역을 단일 정보 소스(SSOT; Single Source Of Truth, 모든 시스템이 참조하는 단일 데이터 소스로 일관성과 신뢰성을 보장하는 개념)로 깃 리포지토리에 저장하여 추적 가능성과 신뢰성을 높입니다.

(2) 자동화된 배포 및 동기화

• 변경 사항이 깃에 커밋되면, 이를 자동으로 클러스터에 반영해 수동 작업을 줄이고 오류 가능성을 최소화합니다.

(3) 선언적 구성

• 모든 설정을 선언적으로 정의하여, 예측 가능한 결과를 얻을 수 있습니다.

Argo CD의 공식 깃허브 리포지토리에 나와 있는 문서 최상단의 문구를 다시 해석해 보면 그 의미는 다음과 같습니다.

“Argo CD는 사용자가 시스템의 최종 상태를 정의해주면 이를 깃옵스 방법론에 의해 자동으로 시스템에 전달해 주는 도구입니다. 여기서 시스템은 쿠버네티스 환경, 구체적으로 클러스터를 의미합니다.”

블럭스가 깃허브(GitHub, 깃 리포지토리를 호스팅하고, 협업 및 CI/CD 기능을 제공하는 플랫폼)를 SSOT로 선택한 이유는 깃허브가 제공하는 강력한 버전 관리 및 협업 도구가 쿠버네티스 자원 관리의 요구 사항과 완벽히 부합했기 때문입니다.

쿠버네티스 자원의 정의 파일(YAML)을 깃허브에 저장하면 모든 변경 내역이 자동으로 기록되며, 각 변경 사항은 고유한 커밋 해시를 통해 추적 가능합니다. 이는 배포 중에 문제가 발생했을 때 이전 상태로 빠르게 롤백할 수 있는 중요한 기반이 됩니다.

또한, 깃허브의 PR(Pull Request, 깃 리포지토리에서 코드 변경 사항을 병합하기 전에 리뷰를 받을 수 있도록 요청하는 프로세스) 기능은 모든 자원의 변경 사항이 리뷰와 승인을 거친 뒤 반영되도록 만들어 협업 과정을 체계적으로 관리할 수 있었습니다. 특히 PR 내에서 코드 리뷰, 의견 교환, 승인 프로세스가 투명하게 이루어져 팀 간 신뢰성과 생산성을 높이는 데 효과적이었습니다.

깃허브를 선택한 또 다른 이유는 광범위한 생태계와 도구 통합입니다. 깃허브 액션(GitHub Actions, 깃허브에서 제공하는 CI/CD 자동화 기능으로 코드 변경 시 빌드, 테스트 및 배포 작업을 수행할 수 있도록 함)과 같은 워크플로우(Workflow, 특정 작업을 자동화하기 위해 정의된 일련의 단계 및 프로세스) 자동화 도구를 활용해 CI/CD 파이프라인과의 통합이 쉬웠고, Argo CD와도 자연스럽게 연계되어 깃의 변경 사항이 쿠버네티스 클러스터에 자동으로 반영되는 워크플로우를 간소화할 수 있었습니다.

이러한 이유로 블럭스는 쿠버네티스 자원의 SSOT로 깃허브를 선택했으며, 이를 통해 선언적 구성과 변경 추적 및 자동화를 완벽히 실현함으로써 쿠버네티스 환경의 운영 효율성과 신뢰성을 크게 향상시켰습니다.

Argo CD와 깃옵스를 활용한 블럭스의 쿠버네티스 아키텍처

위 그림은 Argo CD와 깃옵스를 활용한 블럭스의 쿠버네티스 아키텍처를 간소화하여 표현한 것입니다. 블럭스 소프트웨어 엔지니어들이 해당 애플리케이션을 개발하고 이것이 상용 환경의 쿠버네티스 클러스터에 배포되기까지의 모든 과정을 순서와 함께 나타냈습니다.

첫 번째 과정은 엔지니어들이 Collector API 애플리케이션을 개발하는 것입니다. 엔지니어들은 Collector API의 코드를 수정한 후 PR을 이용해 이를 깃허브의 소스 코드 리포지토리(Source Code Repository, 애플리케이션의 소스 코드와 관련된 파일을 저장하고 관리하는 리포지토리)에 푸시합니다. 리포지토리의 특정 브랜치에 코드 변경 사항이 반영되면, 깃허브 액션을 통해 빌드 및 배포 프로세스가 자동으로 트리거됩니다.

두 번째 과정이 바로 깃허브 액션을 이용한 워크플로우 실행 단계입니다. 앞서 설명했듯이 코드가 깃허브의 특정 브랜치에 푸시되면, 깃허브 액션이 자동으로 실행됩니다. 이 단계에서는 애플리케이션을 컨테이너 이미지로 빌드하고, 필요한 테스트를 수행한 후 모든 테스트를 통과할 경우 다음 단계로 진행합니다. 만약 테스트를 통과하지 못하면 모든 프로세스가 중단되며 엔지니어들에게 알림이 오게 됩니다.

깃허브 액션을 이용해 이미지를 빌드하고 Amazon ECR에 업로드하는 코드 (일부 생략) (출처: 블럭스)

세 번째는 위 코드에서도 나와 있듯이 Amazon ECR(Elastic Container Registry, AWS에서 제공하는 컨테이너 이미지 저장소)에 컨테이너 이미지를 저장하는 단계입니다. 깃허브 액션이 Collector API의 컨테이너 이미지를 빌드한 후 이를 Amazon ECR(Elastic Container Registry)에 업로드합니다.

Amazon ECR은 블럭스의 컨테이너 이미지 저장소 역할을 하며, 쿠버네티스에서 사용할 모든 이미지를 여기서 관리합니다. 이 단계에서 특정 태그(예: 0.1.2 등)가 붙은 컨테이너 이미지가 저장됩니다.

네 번째는 깃허브 액션이 컨피그 리포지토리(Config Repository, 애플리케이션 설정 및 배포 매니페스트를 저장하는 리포지토리로 깃옵스에서 SSOT 역할을 함)를 업데이트하는 단계입니다.

Collector API의 새 컨테이너 이미지가 ECR에 업로드되면 깃허브 액션은 컨피그 리포지토리, 즉 애플리케이션 매니페스트(Application Manifests, 쿠버네티스에서 애플리케이션을 정의하는 YAML 파일 집합) 저장소의 YAML 형태로 된 쿠버네티스 매니페스트를 업데이트합니다.

이때 타깃 파일에서 image: ${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-2.amazonaws.com/${ECR_REPOSITORY_NAME}:0.1.1와 같은 필드를 업데이트하여, 새로운 컨테이너 이미지가 배포되도록 설정합니다. 이와 같은 변경 사항은 깃허브에 직접적으로 커밋되게 할 수도 있고, PR의 형태로 사람의 손을 한 번 더 거치게끔 할 수도 있습니다. 저희는 더욱 안전한 배포를 위해 후자를 택하고 있습니다.

다섯 번째는 Argo CD가 변경 사항을 감지하며 배포를 준비하는 단계입니다. 앞서 깃허브 액션이 올린 PR을 엔지니어가 직접 확인하고 변경 사항을 최종 코드에 반영하면, 컨피그 리포지토리의 상태에 변화가 생기게 됩니다. Argo CD는 주기적으로 컨피그 리포지토리를 감시하고 있기 때문에 사람이 별도의 액션을 취하지 않아도 Argo CD는 이러한 변경 사항을 자동으로 감지하게 됩니다.

앞서 설명했듯이 Argo CD는 선언적 배포 방식을 사용하여 컨피그 리포지토리의 설정과 쿠버네티스 클러스터의 실제 상태를 동기화합니다. 따라서 엔지니어가 kubectl apply 명령을 수동으로 실행하지 않아도 변경 사항이 자동으로 클러스터에 적용됩니다.

여섯 번째와 일곱 번째는 실제로 Argo CD가 새로운 Collector API 버전을 쿠버네티스에 배포하는 단계입니다. Argo CD는 변경된 매니페스트를 기반으로 새로운 Collector API 버전을 쿠버네티스 클러스터에 배포합니다.

본 예시의 경우에는 Deployment(쿠버네티스에서 애플리케이션을 배포하고 업데이트하는 리소스로 원하는 상태를 정의하고 이를 자동으로 유지하도록 함) 리소스가 업데이트되며, 위 그림과 같이 기존 파드(Pod, 쿠버네티스에서 컨테이너를 실행하는 기본 단위로 하나 이상의 컨테이너와 공유하는 네트워크 및 스토리지가 포함됨)가 새로운 이미지로 롤링 업데이트(Rolling Update, 기존 애플리케이션을 점진적으로 새로운 버전으로 교체하여 무중단 배포를 가능하게 하는 방식)됩니다.

클러스터 내의 새로운 파드는 Amazon ECR에서 업데이트된 컨테이너 이미지를 가져와 실행합니다. 배포가 정상적으로 완료되면 최종적으로 Collector API의 최신 버전이 쿠버네티스 클러스터에서 가동되며, 외부 요청을 처리할 준비를 마칩니다.

위 과정을 통해 블럭스는 엔지니어들이 애플리케이션 코드 변경 사항을 깃허브에 푸시하는 것만으로 쿠버네티스 클러스터에 새로운 버전이 배포되는 자동화된 CI/CD 시스템을 운영할 수 있게 되었습니다. 이를 통해 블럭스는 안정적이면서도 빠른 배포 프로세스를 갖출 수 있게 되었습니다.

새 시스템을 도입한 블럭스 관리 프로세스 주요 특징

Argo CD와 깃옵스를 도입하면서 블럭스의 쿠버네티스 자원 관리는 체계적이고 자동화된 방식으로 발전했습니다. 특히 모든 변경 사항을 코드 기반으로 추적 가능하고 일관되게 관리함으로써 투명하고 효율적인 배포 프로세스를 유지할 수 있게 되었는데, 이러한 블럭스의 관리 프로세스의 주요 특징을 정리하면 다음과 같습니다.

(1) 깃허브 리포지토리와 쿠버네티스 자원의 연결

블럭스는 애플리케이션 코드와 쿠버네티스 매니페스트를 별도의 깃허브 리포지토리에서 관리합니다.

• 애플리케이션은 소스 코드 리포지토리에서 관리되며, 코드 변경 시 깃허브 액션을 통해 컨테이너 이미지가 빌드 및 배포됩니다.

• 쿠버네티스 리소스 매니페스트(YAML)는 컨피그 리포지토리에 저장되며, Argo CD가 이 리포지토리를 감시하여 변경 사항을 클러스터에 자동 적용합니다.

• 쿠버네티스의 선언적 구성이 가능해졌으며, 인프라 변경 사항이 갓을 통해 명확하게 기록되고 추적될 수 있었습니다.

(2) PR 기반 변경 관리

블럭스는 쿠버네티스 리소스의 모든 변경 사항을 PR 기반으로 관리하여 안전성을 높였습니다.

• 엔지니어가 새로운 기능을 배포하거나 설정을 변경할 때 컨피그 리포지토리에서 직접 변경하는 것이 아니라 PR을 생성하여 리뷰 및 승인 과정을 거치도록 했습니다.

• 코드 리뷰, 승인 프로세스, 변경 이력 추적이 가능해졌으며, 잘못된 설정 변경이 즉시 운영 환경에 반영되는 위험을 방지할 수 있었습니다.

• PR 기반 관리 방식 덕분에 배포 프로세스가 더욱 투명하고 체계적으로 운영될 수 있었습니다.

(3) 자동화된 배포 파이프라인

블럭스는 깃옵스 워크플로우를 기반으로 Argo CD를 활용하여 배포 자동화를 구축했습니다.

• 엔지니어가 새로운 코드를 깃허브에 푸시하면, 깃허브 액션이 이를 빌드하고 Amazon ECR에 컨테이너 이미지를 업로드합니다.

• 컨피그 리포지토리의 매니페스트가 업데이트되면, Argo CD가 이를 감지하고 자동으로 쿠버네티스 클러스터와 동기화하여 변경 사항을 반영합니다.

• 이 과정에서 배포를 완전 자동화(Fully Automatic Sync)하거나 특정 PR이 승인된 후 수동 배포(Manual Sync)하도록 설정할 수도 있습니다.

• 블럭스는 일관된 배포 프로세스를 유지하면서도 개발 속도를 높이고 배포 안정성을 강화할 수 있게 됐습니다.

(4) 헬름 차트를 활용한 반복적인 자원 관리

블럭스는 쿠버네티스 리소스 정의를 효율적으로 관리하기 위해 헬름 차트(Helm Chart)를 적극 활용했습니다.

• 모든 애플리케이션과 인프라 설정을 헬름 차트로 구성하여 코드 변경 없이도 환경 변수 또는 배포 파라미터를 쉽게 조정할 수 있도록 했습니다.

• 헬름 차트를 활용하면 템플릿화된 YAML 구성을 적용할 수 있어 여러 애플리케이션을 일관된 방식으로 배포하고 유지 보수할 수 있었습니다.

• 헬름 차트와 Argo CD를 결합함으로써 블럭스는 반복적인 배포 작업을 간소화하고, 환경별 설정을 효과적으로 관리할 수 있었습니다.

블럭스는 깃허브, Argo CD, 헬름 차트를 활용한 깃옵스 기반의 자동화된 쿠버네티스 관리 프로세스를 구축함으로써 배포 속도를 높이고 운영 안정성을 크게 향상시켰습니다. 이러한 방식은 운영 부담을 줄이는 동시에, 팀 내 협업과 변경 관리의 효율성을 극대화하는 데 기여했습니다.

블럭스 아키텍처의 향후 개선 방향

블럭스는 Argo CD와 깃옵스를 도입한 이후 빠른 배포 속도, 높은 운영 안정성, 팀 내 협업 강화 등 여러 방면에서 이점을 느꼈습니다. 그러나 이번 아키텍처 구축 때는 적용하지 못하였지만 향후에 개선 혹은 추가하고 싶은 것들도 있습니다.

(1) Argo CD Notifications을 활용한 실시간 모니터링 강화

현재 Argo CD의 배포 상태를 대시보드 혹은 kubectl 명령어로 수동으로 확인하는 경우가 많지만, 이를 Argo CD Notifications 기능을 활용하여 슬랙(Slack)과 같은 협업 도구로 실시간 알림을 받을 수 있도록 개선할 예정입니다. 이를 통해 배포 실패나 동기화 오류가 발생했을 때 신속한 대응이 가능할 것입니다.

(2) 자동화된 배포 승인 및 테스트 프로세스 강화

현재는 PR 기반으로 변경 사항을 승인한 후 수동으로 변경 내용을 최종 코드에 합치는 방식을 사용하고 있지만, 특정 조건을 만족할 경우 자동으로 승인 및 배포될 수 있도록 CI/CD 파이프라인을 개선할 계획입니다.

예를 들어, 자동화된 E2E 테스트(End-to-End Tests, 애플리케이션의 전체 워크플로우를 테스트하여 기능이 기대한 대로 동작하는지 검증하는 과정)를 통과한 경우 Argo CD가 변경 사항을 자동으로 반영하도록 설정할 예정입니다. 이를 통해 배포 프로세스를 더욱 안정적으로 유지하면서도 속도를 높일 수 있을 것으로 기대됩니다.

Argo CD와 깃옵스 도입을 통해 블럭스는 쿠버네티스 자원을 체계적으로 운용 및 관리할 수 있게 되었습니다. 빠른 배포 속도와 높은 안정성, 그리고 개발팀과 운영팀 간의 원활한 협업이 주요 특징입니다.

블럭스는 기술적 도전을 멈추지 않고, 더 나은 인프라와 운영 방식을 고민하며 발전해 나가고 있습니다. 앞으로 실시간 모니터링 강화, 자동화된 배포 승인 프로세스 도입 등 더 정교한 배포 환경을 구축해 나갈 것입니다. 이를 통해 엔지니어는 더 빠르고 안정적으로 코드를 배포할 수 있고, 운영팀은 보다 체계적으로 서비스를 관리할 수 있을 것입니다.

앞으로도 더욱 효율적이고 유연한 배포 환경을 구축하며, 지속적으로 발전하는 블럭스의 모습을 보여드리겠습니다. 많은 기대 부탁합니다!