CI/CD와 파이프라인 최적화에 대해

CI/CD 의 개념 및 확인 사항에 대해 간략히 기재한 글입니다

#CI/CD

#한국어블로그

Lee Sujae

2023.10.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드의 수재입니다.
이전에 작성한 컨테이너화에서 잠깐 이야기가 나왔던 CI/CD와 일련의 과정인 파이프라인의 최적화 방법에 대해 알아보고자 합니다.

CI/CD 파이프라인이란?

우선 CI/CD에 대해 먼저 설명하자면
지속적 통합(CI, Continuous Integration)과 지속적 전달 및 배포(CD, Continuous Delivery & Continuous Deployment)를 뜻하는 단어입니다.

각 요소에 대해 상세히 알아보자면 다음과 같습니다.

지속적 통합(CI) : 코드를 지속적으로 변경하고 변경점이 중앙 리포지토리로 계속 통합되는 것
지속적 전달 및 배포(CD) : 코드의 변경점이 테스트 및 스테이징을 거쳐 배포 가능한 상태를 만들고 적용 가능한 변경점이 각 환경에 배포가 적용되는 것

즉, 개발자가 코드를 수정하여 저장만해도 리포지토리에 자동으로 적용되며 변경 사항이 설정한 운용 환경에 자동적으로 배포되는 것을 뜻합니다.

CI/CD 파이프라인이란 개발자의 코드 수정부터 마지막에 환경 배포까지의 일련의 과정을 말합니다.

CI/CD의 장점

우선 대부분의 공정이 자동화되어 있기 때문에 CI/CD를 이용하면 릴리스 간격을 많이 단축할 수 있습니다.
필요에 따라 각 단계의 컨펌을 수동으로 변경할 수 있기 때문에 리스크를 관리할 수 있습니다.

각 단계에 따라 다음 단계로 넘어갈 타이밍을 조절할 수 있습니다. 따라서 하루에 수십번 코드의 변경이 일어나더라도 적용할 타이밍은 관리자가 정할 수 있습니다.
코드의 수정에 부담이 없어지므로 작은 단위의 코드 커밋 및 리뷰가 가능해집니다.
따라서 내부 코드의 퀄리티가 높아질 수 있으며 버그 수정 또한 용이해집니다.

AWS에서의 CI/CD

AWS CodePipeline is a continuous delivery service you can use to model, visualize, and automate the steps required to release your software. You can quickly model and configure the different stages of a software release process. CodePipeline automates the steps required to release your software changes continuously. For information about pricing for CodePipeline, see Pricing.

AWS는 CI/CD의 파이프라인을 관리하는 서비스인 AWS Code Pipeline을 제공하고 있습니다.
Code Pipeline을 이용하면 코드를 리포지토리에 저장(커밋)하는 작업부터 환경에 배포하는 것까지 한번에 관리할 수 있습니다.
- Code Pipeline 이란?(AWS)

일련의 과정을 정리한 이미지입니다.
개발자가 코드를 커밋하면 Code Pipeline에서 해당 변경을 자동으로 감지합니다. 이후 코드가 빌드된 후 테스트를 거쳐 배포 가능한 상태임을 관리자에게 알립니다.¹
관리자가 배포를 수락하면 대상 환경에 배포를 시작합니다.

AWS에서는 Code Pipeline 뿐만 아니라 Code Commit, Code Build, Code Deploy 등 CI/CD를 위한 Code 시리즈를 제공하고 있습니다. 다음 글들이 Code 시리즈에 대해 참고가 될 것이라 생각합니다.

[AWS] AWS Code Series (담배맛구마, 티스토리)

파이프라인 최적화

CI/CD를 도입한 후 생각보다 배포까지 시간이 걸리거나 혹은 도입했을 때와 비교하여 파이프라인의 속도가 많이 느려진 경우가 있습니다.
이러한 경우 현재 파이프라인의 구성이 올바른지 확인해볼 필요가 있습니다.

의존성 문제

코드를 커밋하고 빌드할 때 의존성 파일을 모두 처음부터 다운받아야 한다면 빌드 단계마다 많은 시간이 소요될 수 있습니다.
의존성 파일들은 미리 스토리지에 저장하여 바로 이용할 수 있도록 구성하는 것이 좋습니다.

리소스 부족

Gitlab이나 Code Builder 등 빌드 단계를 위한 서비스를 제공하고 있습니다.
이러한 서비스를 이용할 때 빌드용 리소스의 스펙을 설정하게 되는데 스펙이 부족한 경우 빌드에 시간이 걸려 그 뒤의 단계로 넘어가는데 영향을 줄 수 있습니다.

코드의 크기

한번에 많은 부분에서 변경이 일어나는 코드의 경우 빌드 및 배포에 시간이 걸릴 수 있습니다.
기능을 모듈화하여 코드를 작은 단위로 나누어 관리하는 것이 좋을 수도 있습니다.²

단계의 정리

단계를 나누어 운영하다 보면 어느 단계에서 병목 현상이 일어나는 경우가 있습니다.
이러한 경우 작은 코드 하나를 수정했지만 전체 파이프라인이 실행되기 까지 너무 긴 시간이 소요될 수도 있습니다.

필요에 따라 단계를 병렬로 나누어 진행하는 것이 도움이 될 수도 있습니다.

작은 이미지 사용

컨테이너를 빌드하는 경우 사용하는 기본이미지가 큰 경우 그만큼 긴 시간이 필요하게 됩니다.
되도록이면 최소한의 의존성을 포함하는 작은 이미지를 사용하는 것이 좋습니다.

모니터링 활성화

각 단계에서의 로그나 지표를 수집하여 사고 발생에 대비하는 것이 좋습니다.
대부분의 경우에서 모니터링을 활성화 한 것으로 인해 성능의 저하는 발생하지 않습니다.

특히 빌드 단계에서 적절한 리소스를 사용하고 있는지 판단하기 위해서는 지표를 확인할 필요가 있기 때문에 활성화하는 것이 좋습니다.

지속적인 테스트

파이프라인을 처음 구축했을 때만 테스트하고 그만두는 것이 아니라 지속적으로 전체 파이프라인을 테스트하는 것이 좋습니다.

전략 수립

CI/CD를 도입하는 것으로 끝이 아닌 만약을 위해 배포 전략, 롤백 전략 등을 수립하고 운용하는 것이 좋습니다.

모범 사례 준수

모범 사례를 따르며 환경을 구성하는 것은 어렵지만 제대로 해놓기만 한다면 운영 측면에서 많은 부분이 해소될 것입니다.
다음 페이지를 참고해주세요 - CI/CD 성공 사례(Jetbrain) - Top 8 CI/CD best practices for your DevOps team’s success(middleware)

마무리

CI/CD 개념은 많은 기업에서 채택하고 운영하고 있는 방식입니다.
하지만 기존 아키텍쳐에서 변경하는 것이 무조건 올바른 것은 아닙니다.
현재 구성에서 변경하여 운영하는 것이 장기적으로 도움이 되는지, 변경에 필요한 리소스를 확보할 수 있는지 등을 검토한 후에 진행하는 것을 추천드립니다.