배포를 빠르게 - DIY(Deploy It Yourself)

이 글에선 버즈빌에선 어떻게 배포의 속도를 높였는지 소개합니다.

이전 글들에서 버즈빌의 배포 파이프라인의 세부적인 내용들을 설명했습니다. 이번 글에선 사용자들이 배포 파이프라인을 DIY(~~Do It Yourself,~~ Deploy It Yourself)로 구축하는데 중요한 내용들을 설명하고자 합니다. 일반적으로 배포 사용자는 배포 파이프라인의 구체적인 내용을 알고 싶어하지 않고 단지 서비스를 빨리 고객에게 전달하고자 합니다. 이를 위해선 앞서 설명한 배포 파이프라인을 누구든지 쉽게 만들 수 있어야만 합니다.

템플릿 활용

이전 글 - 배포를 안전하게 - 에서 쿠버네티스 메니페스트 생성을 위해 헬름(Helm)을 사용하고 있다고 말씀드렸습니다. 헬름은 이미 여러 회사에서 채택해서 사용하고 있고 굉장히 성숙한 도구입니다. 하지만 모든 엔지니어가 헬름을 알고 있진 않아 헬름이 낯선 엔지니어는 배포 파이프라인을 위해서 새로운 도구를 배워야만 합니다. 그리고 이 과정에서 배포의 속도는 매우 느려지게 되며, 이는 조직의 속도에 영향을 미치게 됩니다.

버즈빌은 이 문제를 해결하기 위해서 단일 헬름 차트를 운영하고 있습니다. 일반적으로 각 서비스는 비슷한 인프라 구성을 가지고 있어 단일 차트로 배포가 가능했습니다. 또한 엣지 케이스(Edge Case)가 있는 경우에만 조건문을 추가하거나 너무 복잡해지는 경우 차트를 따로 만들고 있습니다 (아직 별도의 차트를 만든 적이 없습니다). 따라서 사용자는 배포 파이프라인을 위해서 새로운 헬름 차트를 만들 필요가 없습니다. 단순히 가이드를 따라서 values.yaml 파일만 작성하면 됩니다.

또한 단일 헬름 차트는 이미 최적화된 설정을 기본 값으로 가지고 있어 values.yaml 파일에서 enabled 필드로 활성화/비활성화로 최적화된 리소스를 배포할 수 있었습니다.

버즈빌은 헬름뿐 아니라 배포 도구인 스피네이커(Spinnaker)에서도 같은 방식으로 작업했습니다. 스피네이커는 파이프라인 템플릿을 제공하고 있습니다. 파이프라인 템플릿은 스피네이커 파이프라인을 쉽게 생성해주며 템플릿 변수로 커스텀(custom)이 가능합니다. 저희는 상황에 맞는 파이프라인 템플릿 - 롤링 업데이트, 카나리 배포 - 을 미리 생성해 두고 이를 이용해서 파이프라인 생성할 수 있도록 했습니다. 따라서 사용자는 단 몇 번의 클릭으로 파이프라인을 생성할 수 있었습니다.

파이프라인 템플릿 변수 예시

Spinnaker

팀 간의 의존성 끊기

일반적으로 하나의 배포 파이프라인을 구축할 때 일부분 인프라 조직의 지원이 필요합니다. 따라서 각 팀은 배포를 위해서 인프라팀의 도움을 요청하게 되며 인프라팀은 하던 작업을 멈추고 요청을 처리하게 됩니다. 이 과정에서 팀 간의 의존성이 생기게 됩니다. 그리고 조직의 규모가 커질수록 팀 간의 의존성은 조직의 속도를 지속해서 저하하게 됩니다.

버즈빌은 팀 간의 의존성을 끊기 위해 먼저 작업 공간을 분리했습니다. 특히, 배포 파이프라인에 필요한 설정 파일들을 서비스의 레포지토리에 위치시켜 하나의 레포지토리에서만 작업이 가능하도록 했습니다. 예를 들어, 앞서 말한 헬름 차트의 values.yaml 파일은 각 서비스 레포지토리의 release/ 라는 디렉토리에 위치합니다.

하지만 그럼에도 모든 작업을 엔지니어 스스로 할 순 없었습니다. 주로 높은 권한이 필요한 작업이나 컨택스트 이해가 필요한 작업이 이슈가 됐습니다. 예를 등러, 버즈빌에선 데브옵스 팀이 직접 쿠버네티스 네임스페이스 생성해야 했습니다. 버즈빌은 이 문제는 슬랙(Slack) 워크플로우로 해결했습니다. 배포 파이프라인 작업 전에 엔지니어는 슬랙 워크플로우로 데브옵스 팀에 작업 시작을 공유를 합니다. 그후 엔지니어가 그다음 작업을 진행하는 동안 데브옵스 팀은 비동기적으로 사전 작업을 진행합니다.

슬랙 워크플로우

Slack Workflow

저희가 직접 요청(슬랙 팀 맨션)을 피한 이유는 두 가지입니다. 첫 번째는 슬랙 워크플로우는 구체적인 사전 작업 내용을 추상화합니다. 만약 직접 요청해야 한다면 엔지니어는 구체적으로 무엇이 필요한지 알아야 하며 이는 불필요한 러닝 커브를 만들어 냅니다. 두 번째는 자동화에 대한 준비입니다. 슬랙은 훅(Hook)을 제공하고 있어 나중에 사전 준비 작업을 자동화할 수 있게 합니다.

마무리하며

배포 파이프라인은 각 조직 (또는 팀)의 철학이나 상황에 맞게 구성됩니다. 버즈빌의 배포 파이프라인도 그렇습니다. 버즈빌은 확장성, 재사용성, 팀 간 의존성 제거 등 조직의 속도를 높이기 위한 고민을 하고 있으며 이런 철학이 작업에도 반영됐습니다. 이번 블로그 시리즈를 통해 그동안 버즈빌이 고민한 내용들을 공유하게 됐습니다. 만약 비슷한 고민을 하는 조직이나 팀이 있다면 많은 도움이 되었으면 좋겠습니다. 그리고 앞으로는 모니터 시스템, 보안 등 더 다양한 주제로 공유할 수 있도록 하겠습니다. 긴 글 읽어주셔서 감사합니다.

만약 글의 내용 중 피드백이 있으신 분은 이메일 부탁드립니다. 🙂

버즈빌 개발자 지원하기 (클릭)

버즈빌 테크 리크루터와 Coffee Chat하기 (클릭)