*이 글은 핵클 플랫폼 엔지니어 Bubble님의 수기 컨텐츠 입니다.
핵클의 경우 마이크로서비스 아키텍처를 사용하여 도메인 별로 분리된 애플리케이션들을 관리하고 있습니다.
인프라 리소스의 경우 때때로 AWS 클라우드에서 애플리케이션 마다 아래와 같이 수동으로 생성하고 관리하는 형태 입니다.
애플리케이션 배포의 경우 Github Action 에서 Github Repository 에 Commit 이 업로드 되면 컨테이너 이미지를 빌드하고 Container Registry 에 컨테이너 이미지를 업로드하는 빌드 파이프라인 실행 합니다.
이후 애플리케이션이 배포되어 있는 EC2 인스턴스에 에 원격으로 접속하여 Container Registry 에서 컨테이너 이미지를 다운로드 및 배포하는 스크립트를 실행하여 수동으로 배포 합니다.
그러나 위와 같이 애플리케이션의 배포와 인프라 리소스를 관리할 경우, 서비스 규모가 확장되면서 새로 생성되거나 관리 중인 애플리케이션에 대한 인프라 자원의 규모와 관리 비용도 같이 증가하는 문제가 발생 합니다.
새로운 애플리케이션이 생성될 때 마다 인프라 리소스를 생성하고 Github Action 을 통해 Github Repository 마다 빌드 파이프라인을 설정 해줘야 하고, 여러 대의 애플리케이션 인스턴스가 실행되고 있을 경우에도 매번 배포를 위해 인스턴스에 원격으로 접속하여 배포를 위한 명령어를 입력해야 합니다. 하지만 인원은 한정되어 있다 보니 프로세스 및 시간 관리의 어려움이 있었습니다.
위와 같은 문제들을 해결하고자 저희 플랫폼 팀에서는 Kubernetes 도입을 결정했습니다.
Kubernetes 이관 작업을 진행하면서 저희가 고려했던 부분은 크게 두 가지 였는데요.
1편에서는 Kubernetes 에 대한 최소한의 배경 지식과 러닝 커브로 애플리케이션의 이관 작업을 진행할 수 있는 환경을 구성하는 방법에 대해 설명해 드리도록 하겠습니다.
기존에 운영 및 관리 중인 애플리케이션을 Kubernetes 로 배포할 수 있는 환경 필요
Argo Workflow 와 Argo Event, Argo CD 로 Github Repository 에 Commit 이 업로드 될 경우, 수신되는 Webhook Event 로 애플리케이션의 컨테이너 이미지를 빌드하고 Kubernetes 클러스터에 배포하는 CI/CD 파이프라인 시스템을 구성
Argo Workflow
일련의 작업들이 정의되어 있는 Workflow 객체를 통해 빌드 파이프라인 실행
아래와 같이 Workflow Template 객체에 전달한 파라미터를 통해 Workflow 객체와 Template 을 동적으로 실행시킬 수도 있습니다.
Argo Event
Github 과 같은 외부 시스템에서 Event 를 수신하여 Workflow 객체 생성 및 빌드 파이프라인 실행
아래와 같이 Event Sensor 의 필터링 기능을 이용해 언어 및 플랫폼에서 공통으로 실행되는 빌드 파이프라인을 구현하고, Repository 의 언어 및 플랫폼 정보를 조회해 일치하는 Sensor 의 Workflow Template 에 파라미터 전달
Argo CD
Kubernetes 클러스터에 Helm Chart 와 같은 리소스 파일을 통해 애플리케이션을 배포하고 배포된 리소스들의 상태를 실시간으로 모니터링
아래와 같이 애플리케이션에서 공통으로 필요한 리소스들을 Helm Chart 로 정의
이후 아래와 같이 커스터마이징 필요한 Kubernetes 리소스의 설정값만 Helm Chart 의 Value 를 통해 전달하여 클러스터에 애플리케이션을 설치 및 배포할 수 있음
위의 과정을 통해 Kubernetes 클러스터에 CI/CD 파이프라인 시스템을 구성하여 개발팀에서 Kubernetes 클러스터에 애플리케이션을 이관할 때 배포 작업에 들어가는 시간과 리소스를 아낄 수 있었습니다.
좀 더 상세하게 살펴보면,
기존 애플리케이션 인프라 리소스 관리 작업과 배포 프로세스의 문제점이 개선되면서 이관 작업 후에도 Kubernetes 클러스터에서 애플리케이션과 인프라 리소스들을 관리하는 비용도 같이 개선할 수 있었습니다.
.png)
.png)
