[CICD] CI/ CD의 기본 개요
CI/CD의 정의
애플리케이션의 개발 단계를 자동화하여 신속하게 애플리케이션의 기능을 고객에게 제공하기 위한 방법이다. 새로운 기능 개발을 위해 개발자들이 작성하는 코드를 짧은 주기로 통합이 가능하도록 지원하고, 이 과정에서 개발, 운영팀에 발생하는 문제를 효과적으로 해결할 수 있게 해주는 개발 및 배포 방법이다.
- 지속적인 통합 (Continuous Integration) : 소스 코드를 통합하고 빌드 단계를 통해 빌드 아티팩트를 만드는 단계
- 지속적인 전달 (Continuous Delivery) : 배포 아티팩트를 만들고 수동으로 승인하는 절차가 포함된 배포 단계
- 지속적인 배포 (Continuous Deployment): 배포 아티팩트 생성 후 배포 절차까지 모두 자동화된 배포 단계
Continuous Integration
빌드와 통합 단계에 적용되는 개념으로 개발자의 코드를 중앙에서 정기적으로 통합하고, 업데이트 된 내용을 검증해 릴리스에 소요되는 시간을 줄일 수 있게 해준다. 개발자 별로 작성한 코드의 업데이트 내용을 짧게 자주 통합할 수 있는 환경을 제공해서 병합 과정에 발생하는 코드의 충돌이나 버그를 최소화하는 기능을 한다. CI 빌드 단계에서 아티팩트로 컨테이너 이미지가 만들어지는데, 이 때 가장 중요한 점은 빌드를 반복가능하고 일관된 방식으로 사용 가능하도록 구성하는 것이다. 결과적으로 CI를 통해 개발 생산성이 높아지고, 새로 변경되는 애플리케이션의 문제점을 조기에 찾아낼 수 있다.
Continuous Delivery & Deployment
코드 변경 사항이 반영된 애플리케이션이 언제든지 릴리스 될 수 있도록 준비 혹은 배포하는 단계다. 배포 아티팩트를 이용해서 배포 환경(운영, 개발, 스테이징 등)에 애플리케이션을 배포한다. 배포 단계에서 사용되는 아티팩트는 CI 단계에서 만들어진 컨테이너 이미지와 쿠버네티스 매니페스트와 같은 파일이 해당 된다. Delivery와 Deployment의 가장 큰 차이는 배포하는 단계에서 수동으로 승인하는 절차의 유무다. Deployment 방식은 전 과정을 자동으로 구성해서 배포까지 승인 없이 이루어지는데, Delivery는 수동으로 승인 후에 배포가 진행되는 방식이다. Deployment 방식을 구현하기 위해서는 엄격한 테스트 시나리오와 적절한 배포 방식을 선정해서 구성해야한다.
CI/CD와 Devops
Devops는 개발과 운영을 결합한 조직 문화, 사례, 도구의 결합체다. 개발과 운영 부서가 나뉘어 있는 상태에서 Devops 부서가 추가로 구성되는 경우도 있지만 그것이 Devops를 구현하는 핵심이 되는 것이 아니다. 만약 Devops가 기술적으로 선도해서 개발부서와 운영 부서를 모두 아우를 수 있고, 양쪽 업무를 조정해 낼 수 있는 상위 수준의 부서 역할을 할 수 있다면 별도의 부서로 구성하는 것도 Devops를 구현하는 가능한 방식 중 하나가 될 수 있다.
Devops를 구성하려는 조직의 문화라는 것은 개발자가 운영 업무를 이해하고, 운영자가 개발 업무를 이해하고 각자의 역할을 수행하는 것을 의미한다. 그래서 Devops 조직 문화를 만들 때 애플리케이션의 기획, 개발, 테스트, 배포, 운영을 하나의 팀에서 진행하도록 인력을 구성하는데 그 인원이 피자 2판을 먹을 수 있는 수준의 인원(4~5명)으로 구성하는 Two Pizza Team 방식을 권장한다.
Devops를 구성하는 대표적인 사례가 CI/CD 파이프라인을 통한 애플리케이션 개발 단계를 자동화하는 것이 된다. 그리고 CI/CD를 구성하는 과정에서 Git, GitHub, Jenkins, ArgoCD와 같은 도구들이 사용된다.
소규모의 인원으로 팀을 구성하기 때문에 원활한 커뮤니케이션이 가능해지고, 기획부터 운영까지의 전단계에 구성 인력들이 참여하게 되다보니 모두가 애플리케이션에 대한 이해도가 상승하게 된다. Devops 구성 과정에 모듀가 공유할 지표를 만들게 되는데, 이는 팀의 전체적인 업무의 목표 선정(KPI)에 활용되면서, 이 지표를 기반으로 운영 및 서비스 개선 과제를 선정하게 된다. 동시에 CI/CD를 구축하는 과정에서 반복적인 업무들이 자동화 되는데, 그 결과적으로 짧은 배포 주기로 애플리케이션 기능 개선이 이루어지거나 애플리케이션이 모듈화를 통해 쪼개지면서 자연스럽게 마이크로 서비스 애플리케이션의 구조로 이어지게 된다.
이를 바탕으로 Devops가 추구하는 목표는 새로운 애플리케이션의 기능, 개선된 서비스를 고객에게 더 빠르게 전달하는 것이다.
Devops의 문제점
개발 영역과 운영 영역을 넘어 애플리케이션 생애의 전 단계에 관여하게 되면서, 구성원들에게 높은 수준의 기술적인 지식이 요구된다. 이로 인해 개인의 역할 범위가 넓어지고 더 다양한 기술을 습득해야 하는 어려움이 발생할 수 있다. 또한, 기존의 서비스 아키텍처를 변경하거나 자동화를 도입하는 단계에서 발생할 수 있는 기술적 혹은 비용적인 이슈에 직면할 수 있다.
특히, 서비스 아키텍처를 MSA로 전환하는 과정에서 다양한 문제가 발생할 수 있다. MSA 구조에서는 모듈간의 통신이 HTTP 통신을 사용하게 되는데, 모놀리식 환경에서 IPC를 통해 통신하는 것 대비 컴퓨팅 파워를 더 많이 필요하게 된다. 그리고, 분산된 서비스 구성으로 인해 데이터베이스에서도 분산 트랜잭션 환경이 만들어지는데, 하나의 트랜잭션 실패가 전체 프로세스에 영향을 줄 수 있다. 이를 해결하기 위해서 SAGA 패턴과 같은 보상 트랜잭션 처리가 필요하게 되는데, 이는 개발 복잡도와 비용을 높이는 요소로 작용한다.