CI/CD Concept

CI/CD Concept

• CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법입니다.

  • 이는 과거와 다르게 사용자가 서비스에 접근할 수 있는 수단이 다양화되어 언제 어디서나 서비스에 접근할 수 있게 되었습니다.

  • 사용자는 고품질의 신뢰성이 높은 서비스를 기대하며, 언제든지 문제점이나 버그, 추가 기능을 요구할 수 있습니다.

  • 프로바이더는 이러한 사용자의 요구에 발빠르게 대응하는 것이 큰 부담으로 다가올 수 밖에 없으며, 이를 해결하기 위해서 다양한 컨셉이 도출되었습니다.

• CI/CD의 기본개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포라고 할 수 있습니다.

• 애플리케이션의 통합 및 테스트 단계에서부터 제공 및 배포에 이르는 애플리케이션의 라이프사이클 전체에 걸쳐서 지속적인 자동화와 지속적인 모니터링을 제공하는데, 이를 "CI/CD 파이프라인"이라 부르며 개발 및 운영팀의 Agile 방법을 통해 지원합니다.

CI (Continuous Integration)

• 개발자가 각각 개발한 소스코드를 모아서 한꺼번에 빌드하는 통합 빌드의 과정을 특정 시점 아니라 추가로 수행함으로써 통합에 발생하는 오류를 사전에 해결하고 이러한 과정들에 드는 시간을 줄이기 위한 기법을 말합니다.

• 빌드는 더이상 컴파일만을 의미하지 않습니다.

  • 소프트웨어가 거대해지고 복잡해지면서 팀 단위로 개발을 진행하게 되었고, 그 과정에서 분업과 협업이 필수적입니다.

  • 이러한 과정에서 SCM(Source Code Management)를 이용한 Merge (Pull Request) 과정이 까다롭습니다.

• Agile 방법론이 표준화되고, 이를 통해 배포를 위한 빌드 단계, 테스팅 단계 등에서 시간을 절약할 수 있으며, 빠르게 변화하는 시장 변화 속도에 대응하여 속도와 품질을 보장할 수 있게 됩니다.

CI 시스템 구축하기 위해 핵심 구성요소

• CI 시스템을 구축하지 않은 경우에는 개발자들이 각자 개발한 소스코드를 형상관리 서버에 커밋하면 별도의 품질관리를 거치지 않고, 대부분의 개발이 끝난 막바지에 통합하여 테스트를 진행하게 됩니다.

• 이런 경우, 개발 중에 별도의 품질관리를 수행하지 않기 때문에 잘못된 소스코드를 형상관리 시스템에 반영하였을 경우 발생하는 문제가 개발 후반에 모두 장애로 발견되는 문제점이 발생합니다.

소프트웨어에서 형상 관리는 개발 중 발생하는 모든 산출물이 변경됨으로써 변해가는 소프트웨어 형상을 체계적으로 관리하고 유지하는 기법을 말합니다.

이를통해 소프트웨어에 가시성과 추적 가능성을 부여하여 제품의 품질과 안전성을 높입니다.

CI Server

• 빌드 프로세스를 관리하는 서버

  • Jenkins, Travis CI

SCM (Source Code Management)

• 소스코드 관리 시스템으로 Git이 여기에 속한다고 할 수 있습니다. 소스코드의 개정과 백업 절차를 자동화 하여 오류 수정 과정을 돕습니다. 팀 프로젝트의 경우 각자 수정한 부분을 전체가 자동을 동기화 할 수 있는 시스템입니다.

Build Tool

• 컴파일, 테스트 정적 분석 등을 실시해 동작가능한 소프트웨어를 생성하는 도구로 Maven, Gradle 등이 속한다고 할 수 있습니다.

• 빌드는 형상 관리 시스템에 있는 소스코드를 가져와서 실행 가능한 파일로 만드는 일련의 과정을 뜻합니다.

Test Tool

• 작성된 테스트 코드에 따라 자동으로 테스트를 수행하는 도구로 빌드 도구의 스크립트에서 실행되며 JUnit, Mocha등 해당합니다.

Martin Fowler가 제시하는 CI의 기본 원칙

• 모든 소스코드가 실행되고 있고 어느 누구든 현재의 소스를 접근할 수 있는 단일 지점을 유지해야 한다.

• 빌드 프로세스를 자동화 시켜서 어느 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있어야 한다.

• 테스트를 자동화하여 단일 명령어를 통해 언제든지 시스템의 대한 테스트를 실행할 수 있어야 한다.

• 누구나 현재 실행 파일을 얻으면 지금까지의 최고의 실행파일을 얻었다는 확신을 가지게 만들어야 한다.

CD (Continuous Delivery / Continuous Deployment)

• Continuous Delivery

  • 소프트웨어가 언제든지 릴리즈 될 수 있는 방식으로 소프트웨어를 구축하는 소프트웨어 개발 분야를 의미합니다.

  • 지속적인 통합, 자동 테스트 및 자동 배포기능을 통해 고품질의 소프트웨어를 안정적이고 빠르게 개발하고 최소한의 오버해드로 배포할 수 있는 방법입니다.

• Continuous Deployment

  • 코드 변경시 전체 파이프 라인을 통해 이동하고 생산에 투입되어 배포 결과가 매일 갱신됩니다.

  • 이를 통해 애플리케이션은 항상 릴리즈가 준비되어 있으며, 제품을 배포하기 위해서는 비즈니스 결정이 필요하기 때문에 수동으로 작업이 이루어 지게 됩니다.

  • 애플리케이션의 업데이트는 자동으로 푸시됩니다.

    • 단, Continuous Delivery는 배포권한이 주어지지만 Continuous Deployment는 자동 배포권한이 주어지지 않습니다.

CI(Continuous Integration)를 보완하는 CD(Continuous Deployment)

• CI의 도입을 통해서 빌드와 테스트를 자동화 하는 시스템 구현을 완료 했다면 다음 과제로 해결해야 하는 것은 애플리케이션을 배포하는 것입니다.

• 과거 한 두개의 서비스를 모놀리식 구조로 사용하던 경우 수동으로 배포하는 것은 문제가 없었지만, 마이크로서비스 아키텍처가 본격적으로 도입되고 다양한 환경에 배포해야 하는 현재에서 각 환경에 맞는 수 많은 서버에 배포를 해야 한다면 문제는 복잡해 집니다.

• 따라서 CI에 배포의 개념을 더한 CD를 더한 CD/CD 개념이 유행하게 된 것입니다.

CD를 사용해야 하는 이유

1. CD에서 배포는 전체 비용에 거의 영향을 주지 않으며 배포 파이프라인이 구성되면 배포는 자동으로 이루어지거나, 한번의 클릭으로 실행됩니다. 이러한 방식은 몇일이 걸릴 수 있는 배포시간을 단축시켜 비용을 절감할 수 있게 합니다.

2. 애플리케이션의 변경은 연속적으로 반영되며, 가시화됩니다. 이를 통해 고객이 바로 사용할 수 있게 되며, 새로운 기능을 사용한 고객으로 부터 새로운 피드백을 받아 경쟁력을 향상시킬 수 있습니다.

3. 문제가 생기면 빠르게 확인할 수 있으며, 이를 통해 즉각적인 조치가 가능하게 됩니다.

4. 자동화된 배포 프로세스가 안정적으로 정확하게 실행되면, 개발조직과 운영조직의 신뢰감이 증진됩니다. 이를 통해 조직간의 발생하는 불화를 예방할 수 있습니다.

5. 아이디어가 작은 단위로 디자인되고 구성됩니다. 또한 하나의 기능이 완료되면 피드백을 통해서 어느 방향으로 나아가야 하는지에 대한 비즈니스 방향도 결정됩니다.

마이크로서비스 아키텍처와 CI/CD

• CI/CD는 마이크로서비스 아키텍처와 민첩한 연관성을 가지고 있으며 서비스 성공을 위한 중요한 요구사항입니다.

• 잘 설계된 CI/CD없이는 마이크로서비스의 장점을 얻을 수 없습니다.

  

• 모놀리식 아키텍쳐로 구성된 애플리케이션의 경우 빌드 과정까지 단일 빌드 파이프 라인을 가지고 있습니다.

• 이때, 우선 순위가 높은 버그가 발견되는 경우 버그를 수정하고 전체 애플리케이션에 통합한 다음 테스트하여 배포하는 과정이 전체 애플리케이션의 릴리스를 지연시키게 되는 원인이 됩니다.

• 객체지향적인 관점에서 잘 설계된 모듈을 통해 변경되는 부분을 최소화 시키는 방법도 있지만, 서비스의 확장에 따라 애플리케이션이 복잡해질 수 록 모놀리식의 릴리스 프로세스는 불안정해질 가능성이 높아지는 경향이 있습니다.

  

• 마이크로서비스 아키텍처의 기본원칙을 지키고 있다면 위와같은 문제점은 발생하지 않아야 합니다.

• 릴리스 프로세스는 문제가 발생한 팀에게만 제한적으로 동작해야 하며, 다른 팀은 문제가 발생한 팀에 대한 문제로 인해서 기다리는 시간을 최소화 할 수 있습니다.

• 매일 여러 번 프로덕션에 릴리스하는 경우 이로 인한 서비스 중단 가능성이 적어야 하며, 잘못된 업데이트로 인한 문제 생성시 즉각적으로 기존 버전으로 롤백할 수 있는 신뢰성 있는 방법이 있어야 합니다.

마이크로서비스 아키텍처에 CI/CD 적용

• 마이크로서비스 아키텍쳐의 장점은 최대한 살리고 CI/CD를 통해서 효과적인 개발환경을 만들고 싶다면 모든 서비스 팀에게 Docker를 도입하는 것이 효과적입니다.

• Docker 환경에서 새로운 빌드 환경을 구축할 경우 개발자는 컨테이너 이미지만 실행하여 애플리케이션을 바로 확인 및 동일한 환경에서 테스트 할 수 있으며, 동일한 방식으로 빌드서버에도 적용할 수 있습니다.

• 테스트 환경과 프로덕션 환경을 분리해서 운영하기 위해서는 단순히 Docker Compose 혹은 Dockerfile 설정을 일부 변경하여 실행 및 테스트 할 수 있으며, 트래픽에 대한 분산처리도 유연하게 대응할 수 있습니다.

Docker를 활용한 빌드 서버 작업 과정

• 코드를 빌드합니다.

• 테스트 코드를 통해서 작성된 코드의 문제점이 없는지 확인합니다.

• 컨테이너 이미지를 빌드합니다.

• 실행 중인 컨테이너에서 기능 테스트를 실행하여 컨테이너 이미지를 테스트합니다. 이를 통해 Docker 파일의 오류를 찾을 수 있습니다.

• 컨테이너 레지스트리에 이미지를 푸시합니다.

• 새 이미지로 테스트 클러스터를 업데이트하여 통합 테스트를 진행합니다.

---

• 위와 같이 마이크로서비스 아키텍처와 Docker와 CI/CD 결합을 통해서 이미지가 프로덕션으로 이동할 준비가 되면 모든 구성 파일을 포함하여 최신 이미지를 지정하고 서버에 빌드파일을 배포하게 됩니다.