Spring MSA 환경 배포 자동화에 대한 인프라 아키텍처 고민

해당 졸업 작품 주제를 구현하면서 겪은 내용을 정리 해보겠다.

우리 팀은 밴드 모집/홍보 관련 웹 서비스를 기획하고 개발을 진행했다.

하지만 졸업 작품은 클라우드/인프라 아키텍처가 핵심이라 서비스 기능 개발보다는 클라우드 아키텍처 구현에 집중했다.

처음에 구상했던 아키텍처는 위 그림과 같다.

이런 인프라 아키텍처를 구현해본 경험이 없어서 이상한 부분이 있을수도 있다 !

간단하게 아키텍처를 설명해보겠다.

 

일단 비효율적일수도 있지만 팀원이 3명인지라 모두가 파이프라인을 구현하는 경험을 해보기 위해 Front/Back 레포를 나눴다.

각각의 레포는 아래의 로직으로 동작한다.

1. 각 레포에 Push/Merge가 발생하면 Webhook으로 Jenkins에 알린다.
2. Jenkins는 지속적 통합(Build, Test, Merge)을 수행한다.
3. CI를 수행하고 Docker Hub에 관련 이미지가 생성된다.
4. 동기화된 ArgoCD는 클러스터에 생성된 이미지로 Pod를 업데이트한다.

프론트 서비스는 분산 서비스가 아닌 하나의 서비스여서 파이프라인을 구현하는데 어려움은 없었다.

하지만 백 서비스는 MSA 환경이라 어떤식으로 배포 자동화를 구현할지 고민에 빠졌다.

 

구현된 Front 서비스 파이프라인을 변환하는 것도 쉽지 않았고, 서버는 Spring Boot 기반이라 유용한 라이브러리인 Spring Cloud, Eureka 등을 어떻게 활용해야 할지 가장 많이 고민했던 것 같다.

 

그러다가 Github Actions + ArgoCD + Helm Charts  참고하게 되었다.

Helm Charts를 활용하면 리소스를 한 번에 관리하고 배포할 수 있었다.

즉, 이걸 사용하면 애플리케이션을 배포하고  관리하는 과정을 더 쉽고 일관성 있게 만들 수 있었다.

 

기존 Jenkins + ArgoCD 기반의 틀에서 좁게 고민했던게 문제였다 !

 

각 방식의 특징은 ?

각 방식의 특징과 차이점이 궁금해져서 정리해보겠다.

Jenkins + ArgoCD 방식

Jenkins는 플러그인 기반으로 다양한 작업을 지원해서 복잡한 프로세스를 세밀하게 조정 가능하다.

즉, 복잡한 CI 작업을 처리할 수 있어서 각 아키텍처에 맞는 파이프라인 구성에 유리하다.

하지만 보통 온프레미스 환경에서 사용하기 때문에 자체적으로 구성하는 경우가 많다.

그래서 그만큼 설정이 복잡하고 필요한 리소스나 유지 보수 부담이 클 수 있다.

Github Actions + ArgoCD + Helm Charts 방식

Git 이벤트를 기반으로 파이프라인을 간단하게 설정할 수 있다.

그리고 클라우드 기반으로 구성/관리 부담이 적고, 연동이 간편하여 파이프라인을 쉽게 구성할 수 있다.

또한 Helm Charts를 사용하여 k8s 배포를 체계적으로 관리할 수 있다.

만약 복잡한 빌드 및 테스트 과정이 필요하다면 Github Actions로는 한계가 있을 수 있고, 커스터마이징이 제한될 수 있다.

 

각 방식을 살펴보고 최종적으로 후자를 선택했다.

우리의 프론트 서비스는 이미 Jenkins로 파이프라인을 구성했는데, 나는 더 다양한 방식으로 구현을 해보고 싶었다.

 

이렇게 각 방식에 대한 특징을 살펴볼 수 있었고, 합리적인 판단을 하기 위해 고민을 하는 경험을 할 수 있었다.

또한 프론트/백 배포 방식이 일관성이 있진 않지만, 오히려 다양한 배포 방식을 경험할 수 있어서 좋았다.

추후에 구현 방법과 관련 이미지를 추가하도록 하겠다 ~ ! 😎