배포(1) CI/CD와 github action 알아보기

공부 시작

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

우선 나는 이부분에 문외한이고 CI/CD가 정확히 어떤 문제를 해결했는지부터 찾아봐야한다.

 

CI란 개발자가 코드를 변경할 때 마다, 자동으로 빌드와 테스트를 수행해 문제를 조기에 발견하는 과정이다.

동시에 개발 중인 어플리케이션의 분기(브랜치)가 너무 많아서 상호 충돌할 가능성이 있는 문제를 해결해줄 수 있다.

 

CD는 Continuous Delivery(지속적 배포), Continuous Deployment(지속적/자동 배포) 두 가지 의미를 담고있다.

 

Continuous Delivery란: 코드 변경 사항이 자동으로 빌드, 테스트, 패키징 된 후, 운영 환경에 배포할 준비가 된 상태까지 자동화 하는 것이다.

개발자는 '배포 버튼만 누르면' 즉시 배포 가능하고, 릴리즈를 언제 할지 사람이 결정하기 때문에 운영 안정성을 확보할 수 있다.

 

Continuous Deployment란: CI/CD 파이프라인이 운영 환경까지 완전히 자동화되어서, 코드가 변경될 때마다 즉시 배포되는 것이다.

빠른 배포가 필요한 환경에서 유용하며, 운영 안정성이 중요하다면 좀 신중하게 고려할 필요가 있다.

 

여기서 나는 결정해야 했다. Delivery 과정 없이 Deployment를 해볼것이냐 vs 순차적으로 진행할것이냐 ,,

전자가 무조건 빠를테지만 CI/CD 파이프라인에서 자동화 흐름에 제대로 감이 안 잡힌 상태로 자동 배포를 시작하면,

배포 안정성에 대한 경각심이 사라질 것 같았다.

 

그래서 우선 Continuous Delivery부터 진행하고 버전3쯤 되면 Continuous Deployment까지 확장시켜보자!

 

 

jenkins ? github action ? -> github action!

원래는 jenkins로 해보려 했지만, 내가 github action을 선택한 이유는 다음과 같다.

 

1. 사용하기 간편하다. jenkins보다 플러그인이 적고 세밀한 커스터마이징은 불가능하지만, 별도의 서버 관리나 복잡한 설정 없이 레포지토리 내에서 바로 워크플로우를 정의할 수 있다.

2. github 내에서 바로 CI/CD 파이프라인을 만들어 볼 수 있어서 빠르게 피드백 받고 수정할 수 있다. jenkins를 사용하면 ec2에서 빌드나 테스트를 수행해야 한다.

3. CI/CD에 대한 공부를 해야할 때인데 jenkins 공부가 될 듯 했다. '배포 자동화 과정'과 '자동화 전략' 이 중요한 것인데, github action에서도 충분히 경험할 수 있다고 판단했다.

 

일단 우리 서버의 파이프라인에 빠삭해야 할 것 같아

간단하게 github action에서 CI를 사용한 우리 어플리케이션 그림을 그려봤다

mysql과 redis를 ec2 밖으로 나누진 않았지만 .. 그냥 그려봤다.

요약하면, github action을 사용하면 빌드와 테스트 성공 시 이미지 빌드를 깃허브 액션이 해주고

우리는 빌드된 도커 이미지만 ec2에 도커 컴포즈를 이용해 올리면 된다!

이렇게 하면 ec2에서 직접 빌드할 필요없이, 빌드 과정에서의 리소스 소모를 줄이고 배포만 담당하면 된다.

 

그려보니 새삼 테스트코드의 중요성이 확 와닿았다

어플리케이션 기능을 막 늘리기보단, 감당할 수 있는 기능들을 탄탄하게 만드는 것이 중요해 보인다.

서버가 거대한 것도 아니니 최대한 선택과 집중을 해보자!

테스트 코드도 어떻게 질 좋게 작성할 수 있는지 잘 알아보고 작성해야겠다.

 

 

github action을 알아보자

https://docs.github.com/ko/actions/about-github-actions/understanding-github-actions#the-components-of-github-actions

GitHub Actions 이해 - GitHub Docs

Github action은 깃허브 저장소 내부에서 CI/CD 파이프라인을 간단하게 구성하고 자동화 할 수 있는 플랫폼이다.

yml파일로 전체 파이프라인을 정의하고, push나 pull request같은 이벤트에 따라 자동으로 빌드, 테스트, 배포가 이루어진다.

 

이벤트가 발생하면 워크플로우가 실행되고, 그 안에 여러 job을 둘 수 있다. 각 job은 다시 여러 단계로 구성돼서 실제 스크립트나 작업을 수행한다.

 

workflow 내에서 병렬이나 순차 실행을 조절할 수 있는데, job이 많을수록 빌드/ 테스트가 길어지거나 동시에 리소스를 많이 소모할 수도 있다.

 

actions는 특정 작업을 재사용하기 편하게 모듈화 한 거라고 보면 된다. 예를 들어 actions/checkout은 깃 레포지토리를 체크아웃해준다.

이런 액션들은 github marketplace에 많이 공개돼 있고, 필요하다면 직접 만들어서 공유할 수도 있다.

다만 불필요하게 무서운 actions를 가져다 쓰면 빌드 시간이 증가할 수 있으니 주의해야한다.

 

성능 관점에서는 캐시를 잘 사용하는 것이 특히 중요하다. gradle같은 의존성 설치나 gradle build layer를 캐싱하면, 매번 새로 설치하거나 이미지를 빌드하는 시간을 아낄 수 있다.

캐시 키를 적절히 설정해두지 않으면 매번 새로 받느라 캐싱 효과를 제대로 못 볼 수 있으니 주의가 필요하다.

병렬 실행이 많을수록 전체 빌드 시간 자체는 짧을 수 있지만, 리소스 분산 문제도 고려해야 한다.

 

이벤트를 최소화해서 불필요한 트리거가 생기지 않도록 설정하는 것도 성능에 중요한 요소다.

예를 들어, 모든 푸시에 대해 워크플로우를 돌릴 필요가 없다면 특정 브랜치만 트리거되도록 설정하거나, pull request에 라벨이 붙은 경우만 실행하게 조건을 거는 식으로 세부 조절이 가능하다.

한 레포지토리에 워크플로우가 여러개라면, 중복되는 작업을 재사용 가능하게 만들어두면 빌드 시간을 아낄 수 있다.

reusable workflow를 이용해 반복적으로 쓰는 CI/CD 구성을 별도 파일로 정의해두고 여러 프로젝트나 레포지토리에서 가져다 쓸 수도 있다.

 

결국 github action은 테스트부터 코드 스캐닝, 테스트 커버리지, 릴리즈 생성, 배포, 모니터링 같은 것들을 한 곳에서 다루게 해주는 툴이다.

병렬화, 캐시, 이벤트 최소화 등의 최적화를 잘 진행해야 리소스를 낭비하지 않고 빠른 CI 파이프라인을 얻을 수 있을 것이다!

 

 

github action 없이 배포, 리소스 사용량은?

github action으로 배포 vs ec2에서 배포의 차이가 궁금해서 Cpu 사용량을 체크해보려한다.

jenkins를 사용하면 ec2내부에서 빌드가 이루어지고, github action을 사용하면 외부에서 이루어지기 때문에 유의미한 비교다.

배포를 언제 성공했는지는 슬랙에서 확인할 수 있었다ㅋㅋ.

솟아오른 구간이 딱 두 군데라 추측을 해보자면

첫번째는 도커 등 필수패키지 설치,

두번째는 서버 빌드-실행과정인 것 같다.("서버 생겼어용" 한 시간 = 11시 53분 = UTC시간대에서 14시 53분)

맞는듯! 14시 20분에 로그가 팍 튀었는데, 도커 어플리케이션은 14시 23분에 실행되었다.

저 14시 51분-14시 53분까지의 로그에만 주목하면 될 것 같다.

의존성 다운로드가 곧 네트워크 패킷 사용량으로 이어지므로 이것도 찍어두자.

도커 이미지만으로 push되므로 패킷 입력량이 확실히 적을거다

 

CPU 사용량 : 약 13%

네트워크 패킷 입력 수 : 약 66480

 

다음 글에서 본격적으로 CI를 시작해보자 !