들어가기에 앞서
로컬 환경에서의 실행은 docker-compose 를 통해 간편하게 실행할 수 있도록 했습니다.
물론 혼자 개발하는 1인 프로젝트 이다보니 docker-domcpose 를 통한 로컬 환경 실행만으로도 충분할 수 있겠지만, 팀원이 늘어나거나 front-end 등 다름 팀과의 협업이 발생한다면 실제 환경과 유사한 상태로 실행되고 있는 개발 환경 이 필요하다고 생각되었어요.
본 포스트는 운영과 유사한 개발 환경을 구성하기 위한 과정과 발생한 문제, 해결 과정을 기록했습니다. 자세한 설정 방법은 다루지 않습니다.
발생 문제 & 해결 과정
1. 불필요한 작업 발생 & CI/CD 파이프라인 구성
최신 코드를 서버에서 실행하기 위해선 github 에 존재하는 코드를 내려받아 Test & Build 과정을 거쳐 실행하는 과정이 필요합니다.
물론 배포 스크립트를 작성해 서버에 접속 후 실행하면 된다지만, 최신 코드가 갱신될 때마다 개발 서버에 접속해 매번 배포 스크립트를 실행하는 건 큰 피로로 다가올 뿐만 아니라, 실수하기도 쉬운 작업 환경이 만들어진다고 생각했어요.
위와 같은 불필요한 작업, 실수하기 쉬운 환경을 해결하기 위해 CI/CD 파이프라인을 구축하기로 했어요.
CI/CD는 간단하게 말해서 최신 코드를 테스트, 빌드하는 CI(지속적인 통합)와 테스트한 코드를 릴리즈하는 CD(지속적인 배포)로 구성되어 있습니다.
CI/CD 파이프라인을 구현하는 방법은 크게 Github Actions를 사용하는 방법과 Jenkins를 사용하는 방법으로 나눠집니다.
각 방법은 여러 장단점이 존재하지만, 전 Jenkins를 사용했어요. Github Actions가 적용하기 더 편하다는 내용 또한 있었지만, Jenkins가 MSA 프로젝트의 배포에 관한 자료를 찾기 쉬웠기 때문에 선택했습니다.
2. Jenkins와 공용 라이브러리 의존성 문제
모두의 음악 프로젝트는 각 마이크로서비스에서 공통적으로 사용되는 로직을 별도의 라이브러리로 추출하여 사용중입니다. 로컬 환경에선 maven local 에 라이브러리를 배포해 사용중이었습니다.
다만, 이렇게 유지해온 라이브러리는 Jenkins의 CI 과정에선 주입받을 수 없었어요.
Nexus Repository와 같은 라이브러리 보관소를 사용할 수도 있었지만, Jenkins 컨테이너 내부의 maven local 을 이용해 보다 간편하게 빌드 과정에서 라이브러리를 주입받을 수 있었습니다.
이는 또한, 밑에서 설명할 multi-branch build strategy를 통해 라이브러리 배포 또한 쉽게 할 수 있을 것이라고 생각돼요.
3. Github webhook 502 에러 발생
자동화된 배포를 위해선 코드가 업데이트될 시 자동적으로 CI 과정이 실행될 필요가 있습니다. 이를 위해 필요한 것이 Github webhook 입니다. Github에 코드가 push되면 Github webhook이 이벤트를 발생시켜, Jenkins의 CI/CD 파이프라인이 실행되는 방식이예요.
webhook 발생 후 Http status 502를 마주쳤습니다. 요청이 정상적으로 전달되지 않았다는 의미였어요. 찾아보니 ACG와 ACL에 의해 요청이 필터링되어 제대로 전달되지 않았다는 걸 알 수 있었습니다.
github metadata에서 github의 webhook이 발생되는 IP를 허용해주었고, 이후 정상적으로 작업이 진행될 수 있었어요.
4. 배포 시간 오래걸림
Github Repository엔 마이크로서비스들, 서비스 디스커버리, API 게이트웨이 등 다양한 개별 어플리케이션이 존재합니다. Github webhook을 이용해 빌드 과정을 자동화했지만, 거슬리는 부분이 존재했어요.
Github webhook은 폴더 단위의 작업을 지원하지 않기에 변경이 발생하면 모든 어플리케이션을 빌드해야 한다는 단점이 존재했죠.
인증/인가를 담당하는 user-service, MSA 구조를 위한 api-gateway 와 eureka-discovery 는 빌드가 1분 내로 완료되는 간단한 어플리케이션입니다. 다만, 다른 것들과 같이 빌드되어 4분이 넘는 시간이 걸렸습니다.
서비스 확장이 발생할 때 마다, 테스트가 추가될 때마다 빌드 시간이 기하급수적으로 증가할 것이기에 CI/CD의 효과를 보기 위해선 이 문제를 반드시 해결해야 한다고 생각했어요.
다행히도, 비슷한 문제에 대한 자료를 찾을 수 있었습니다. Jenkins Multibranch Pipeline 개선기에선 한 레포지토리에서 back-end 와 front-end 코드를 관리하고 있었습니다. 마이크로서비스가 개별로 빌드되길 원하는 제 상황과 유사했고, 해결법 또한 자세히 설명되어 있었습니다.
이후, Multibranch build strategy를 적용하여 개별 스크립트가 동작할 수 있도록 설정했습니다.
기존 4분 이상 걸리던 빌드 과정을 1분대로 줄일 수 있었습니다. 약 80%의 시간이 단축되었고 테스트가 적은, 소규모의 어플리케이션이라면 더욱 짧아지겠죠. 이는 서비스가 확장될수록 더 큰 효과를 발휘할거예요!
참고 자료
