NGINX 및 NGINX Plus를 활용한 CI/CD 소개

CI/CD (Continuous Integration/Continuous Delivery)는 애플리케이션 작성, 업데이트 및 제공의 전체 Life Cycle을 관리하는 현대적인 접근 방식입니다. NGINX와 NGINX Plus의 민첩하고 가벼운 디자인은 CI/CD 플랫폼의 많은 부분을 지원하는 매우 유용한 도구가 됩니다.

CI/CD를 사용하면 버그 수정에서 주요 기능 변경에 이르기까지 모든 것이 사용자에게 지속적으로 제공됩니다. 애플리케이션의 다른 부분들은 다른 프로그래밍 언어, 다른 데이터베이스 스키마, 다른 개발 및 릴리스 일정을 사용할 수 있습니다.

CI/CD는 관련 사례 그룹의 일부이며 각 사례는 서로를 지원합니다.

  • 지속적 통합을 위해 Bamboo 및 Jenkins와 같은 도구 사용
  • 유연한 Source 코드 제어를 위한 Git 또는 유사한 도구 사용
  • 개발, 테스트 및 생산을 위한 컨테이너 사용
  • Kubernetes 및 Mesosphere와 같은 컨테이너 관리 시스템을 개발, 테스트 및 Production에 사용
  • 개발 및 배포를 위한 Microservices로의 전환
  • Reverse proxy 서버 및 웹 서버로 배포된 NGINX
  • 다른 모든 것의 기초는 소프트웨어 개발 및 관련 분야 관리에 애자일 접근 방식을 사용하는 것입니다.

CI/CD의 대명사는 자동화입니다. 이는 통합과 전달을 모두 지속적으로 가능하게 하는 핵심 요소입니다. 코드가 견고해지면 목표는 통합을 위한 코드 제출과 동일한 코드를 Production 환경으로 전달하는 사이에 사람이 개입할 필요가 없도록 하는 것입니다.

목차

1. CI/CD 의 성장
2. CI/CD 의 차이점
3. CI/CD 프로세스 단계 자세히 살펴보기
3-1. Source 제어
3-2. 지속적 통합
3-3. 테스트
3-4. 지속적 전달
3-5. 성능 및 배포 테스트
4. 결론

1. CI/CD 의 성장

최근 NGINX 설문 조사에서 조직의 약 3분의 2가 컨테이너, CI/CD 또는 둘 다를 연구하거나 구현한다고 보고했습니다. 이러한 변경 사항은 NGINX 소프트웨어 및 클라우드로의 이동과 도 관련이 있습니다. AWS 배포의 40% 이상이 NGINX를 사용하며 NGINX Docker 이미지는 Docker Hub에서 가장 많이 다운로드되는 애플리케이션 이미지입니다.

NGINX는 Proxy, Load Balancing, 컨테이너 관리 및 Microservices 지원을 처리합니다. 동시에 NGINX는 컨테이너, 가상 머신, 다양한 클라우드 플랫폼 및 Bare Metal 전반에서 이식성을 제공합니다.

NGINX Plus는 CI/CD와 관련된 다른 이점을 제공합니다. DNS SRV 레코드의 실시간 확인과 Upstream 그룹의 동적 구성을 위한 NGINX Plus API를 사용하면 Load Balancer의 구성 파일을 수동으로 관리하고 다시 로드할 필요가 없습니다. NGINX Plus는 애플리케이션이 올바르게 작동하는지 확인하기 위해 Health Check를 전송하고 비정상 서버에서 Production 트래픽을 보내 사이트에서 클라이언트의 경험을 손상시키는 종류의 오류 및 중단을 제거합니다. Health Check와 자동화를 결합하는 한 가지 예는 Health Check에서 새로 배포된 애플리케이션 버전의 5xx 오류와 같은 문제가 드러날 때 애플리케이션의 이전 버전으로 자동으로 돌아가는 시스템을 만드는 것입니다.

CI/CD를 적절하게 구현하려면 개발 및 제공 프로세스의 모든 단계와 도구를 전체적으로 검토하여 지원 플랫폼을 구축해야 합니다.

  • CI/CD 플랫폼의 주요 구성 요소를 설정하는 동시에 각 조직이 고유한 프로세스를 생성할 수 있음을 인식합니다.
  • CI/CD를 사용할 때 소프트웨어 개발, 테스트 및 제공 프로세스에서 기대할 수 있는 사항을 설명합니다.
  • 강력한 최신 CI/CD 플랫폼에서 NGINX Open Source 및 NGINX Plus의 역할 강조합니다.

Note: “지속적 전달”과 “지속적 배포”라는 용어는 서로 혼동되는 경우가 많습니다. 지속적 전달이란 변경된 소프트웨어를 배포 준비 단계로 지속적으로 이동하는 것을 의미합니다. 이것이 프로세스의 핵심 가치를 포착한다고 생각합니다. 그런 다음 지속적 배포를 구현할지 여부를 선택할 수 있습니다. 즉, 잠재적으로 배포 사이에 변경 사항이 누적되도록 허용하지 않고 모든 소프트웨어 변경 사항을 Production 환경으로 즉시 이동합니다. 전체적으로 CI/CD는 전체 프로세스를 마찰 없이 만듭니다. 진정한 지속적 배포(CD)는 비즈니스에 필요한 경우 쉽게 구현할 수 있습니다.

2. CI/CD 의 차이점

CI/CD는 소프트웨어 테스트 및 제공 프로세스 전반에 걸쳐 애자일 개발 원칙을 구현하는 수단으로, 소프트웨어 개발도 거의 대화식으로 만듭니다. CI/CD를 사용하면 소프트웨어를 거의 지속적으로 업데이트할 수 있으므로 전체 프로세스가 비즈니스 요구 사항과 사용자 요구 사항에 신속하게 대응할 수 있습니다.

새로운 도구와 접근 방식의 일부인 지속적 통합 및 지속적 전달은 전체 애플리케이션 개발 프로세스에 속도와 유연성을 제공합니다.

  • 지속적 통합은 자동화를 사용하여 큰 개발 시간 블록이 필요하지 않도록 하고 별도의 통합 테스트를 수행합니다. 아무리 작은 소프트웨어라도 변경되면 변경된 소프트웨어가 자동으로 빌드되고 테스트됩니다. 빌드 단계에서 코드 구문의 유효성을 검사하기 위해 테스트가 실행됩니다. 특정 환경에 배포한 후 애플리케이션별 테스트를 통해 새 애플리케이션 버전이 올바르게 작동하는지 확인합니다.
  • 지속적 전달은 CI 구현에 사용되는 단계를 수행하여 소프트웨어가 설정한 테스트를 통과한 후 환경 전체에 애플리케이션 변경 사항을 자동으로 배포할 수 있도록 합니다.

CI와 CD를 함께 사용하면 개발 및 QA에서 번거로움 없이 제한 없이 보다 자유롭게 변경 사항을 구현할 수 있습니다.

지속적 전달 및 지속적 배포을 위한 플랫폼을 구축하면 릴리스 프로세스를 위한 훨씬 더 효율적인 Workflow가 생성됩니다. 중복 테스트 프로세스 및 운영 작업을 자동화하면 개발팀이 각 환경을 담당하는 다양한 팀의 상호 작용을 수동으로 할 필요 없이 변경 사항을 릴리스할 수 있습니다. 이를 통해 운영팀은 기존 애플리케이션 인프라를 모니터링, 유지 관리 및 개선할 수 있습니다. 이를 통해 개발자는 새로운 프로젝트를 수행하고 작업을 보다 효율적으로 수행할 수 있으며 QA팀은 자동화된 테스트 환경을 개선하는 데 집중할 수 있습니다. 동시에 지원하는 애플리케이션에 대해 더 많이 배울 수 있습니다.

CI/CD 플랫폼을 구축하면 사용자에게 영향을 미칠 수 있는 변경 사항을 모니터링하고 테스트하여 애플리케이션에 대한 추가 안전망도 생성됩니다. 적절한 자동 테스트를 설정하면 QA팀이 Production 환경에 배포하기 전에 문제를 자동으로 파악할 수 있습니다.

전반적인 CI/CD 프로세스는 다양한 실무 커뮤니티와 조직 간에 차이가 있습니다. 그러나 CI/CD에는 다음과 같은 세 가지 전반적인 키가 있습니다:

  • 단순화(Simplification) – 프로세스의 단계 수가 감소하고 각 단계가 가능한 한 단순화됩니다
  • 자동화(Automation) – 프로세스의 각 부분은 가능한 한 자동화되어 대기 시간을 없앱니다.
  • 표준화(Standardization) – 각 단계는 소프트웨어의 변경 규모에 관계없이 매번 동일합니다

다이어그램은 CI/CD에 대해 발전된 상대적으로 표준적인 프로세스를 보여줍니다.

The continuous integration/continuous delivery process includes five stages: source control, CI, testing, CD, and monitoring

CI/CD를 위한 표준 프로세스

프로세스에는 5단계가 있습니다.

  1. Source 제어 – 소프트웨어가 개발되거나 업데이트된 다음 “Main” Branch로 이동됩니다. 이 예에서는 Production Pipeline에 대해 계획된 Commit에 중점을 둡니다. 간단히 하기 위해 이를 Main Branch라고 부르지만 Source 제어 분기에 따라 이름이 다를 수 있습니다.
  2. 지속적 통합(CI) – 소프트웨어는 Build Unit Tests를 통해 실행되며, 테스트를 통과하면 Package & Deploy로 이동합니다.
  3. 테스트 – (테스트는 모든 단계로의 전환할 때 수행하므로 이 단계를 주요 테스트라고 부를 수 있습니다.) 핵심 소프트웨어 및 패키지의 고급 승인 테스트가 실행됩니다. 테스트 단계에는 User Acceptance Tests(UAT)와 같은 다른 테스트도 포함될 수 있습니다. UAT 단계는 자동화되지 않아 진정한 CI/CD 프로세스에 속하는지에 대한 논란이 있습니다. 우리는 그것을 여기에 포함시킬 것이고 테스트를 통과하면 소프트웨어가 배포 준비 상태로 전환됩니다.
  4. 지속적 전달 – 하나의 업데이트를 Production로 이동하기 위한 공식적인 결정 프로세스를 통해 즉시 Production으로 이동하거나 여러 업데이트에서 소프트웨어를 유지합니다. 일부 CD 정의에서는 이 단계를 자동화해야 합니다. 다른 보기를 사용하면 비즈니스 및 SLA(Service Level Agreement) 요구 사항에 따라 생산 릴리스를 관리할 수 있습니다.
  5. 성능 및 배포 테스트 – 배포 후 테스트는 일반적으로 수동 단계인 이전의 “정상적인” 버전으로 Rollback 한 후 문제를 해결하기 위한 새로운 개발을 트리거 할 수 있습니다. 가용성 문제와 새로운 기능 요구 사항으로 인해 중간 Rollback 없이 새로운 소프트웨어를 개발하고 배포할 수 있습니다.

각 단계에서 다음 단계로 소프트웨어를 이동하기 위한 합격 테스트가 있으며, 이는 합격 테스트 세트가 4개 있다는 것을 의미합니다. 어떤 단계에서든 실패하면 소프트웨어가 앞으로 이동하지 않고 복구 및 추가 업데이트를 위해 개발로 돌아갑니다.

배포된 소프트웨어에서 오류가 발생하면 배포된 소프트웨어는 오류가 없는 이전 버전으로 자동 Rollback 되고 거기에서 업데이트가 진행됩니다.

3. CI/CD 프로세스 단계 자세히 살펴보기

CI/CD 구현이 진행됨에 따라 수동 프로세스와 이전에 이를 수행했던 사람들이 진행 중인 통합 및 배포 프로세스에서 제거됩니다. 대신, 이전에 수동 작업을 수행했던 사람들은 코드를 통합, 테스트, 배포 및 모니터링하는 자동화된 “생산 라인”을 개발하고 유지 관리하는 임무를 맡고 있습니다.

테스트, 배포 및 제공 프로세스에서 인력이 제거됨에 따라 개발자의 책임은 점점 더 깊어지고 전체 코드 Lifecycle을 포괄하게 됩니다. 자동화된 프로세스가 주어진 단계에서 코드를 다시 시작하면 개발자는 발생한 일을 해독하고 수정하고 후속 조치에서 프로세스를 통해 진행 상황을 추적해야 합니다.

3-1. Source 제어

특정한 변화가 절대적으로 필요한 것은 아니지만, CI/CD로의 전환은 개발자가 수행하는 작업을 완전히 개선할 수 있습니다.

  • 애플리케이션 아키텍처는 필요한 경우 자체 데이터 저장소를 관리하고 API를 통해 다른 서비스와 상호 작용하는 작은 코드 조각이 있는 Microservices로 이동할 가능성이 높습니다.
  • Source 코드 제어는 코드에 대한 공유 액세스와 여러 Source의 변경 사항을 쉽게 관리할 수 있는 Git 기반 또는 유사한 도구로 이동할 가능성이 높습니다.
  • 코드는 특정 개발, 테스트 또는 Production 환경의 세부 사항으로부터 격리하여 컨테이너에 개발 및 배포될 수 있으며 점점 더 그럴 가능성이 높습니다.
  • 코드는 메이저에서 마이너에 이르기까지 변경 사항을 수용하기 위해 자주 업데이트됩니다.
  • 코딩 작업 과정은 2개의 팀으로 구성되어 매일 스크럼(Scrum)과 함께 2주간의 스프린트(Sprint)로 구성되어 완전히 애자일 해질 가능성이 높습니다.
  • 또한 개발자는 초기부터 배포, 각 서비스의 인수 또는 최종 소멸에 이르기까지 자신이 소유한 일련의 서비스를 책임지기 때문에 업무 책임도 애자일 해질 가능성이 있습니다.
The source control stage of the continuous integration/continuous delivery process involves many changes in procedure for developers, compared to traditional models

Source 제어에서 지속적 통합(CI)으로 이동

요약하자면, CI/CD로의 전환은 개발자의 업무 책임과 일상을 획기적으로 변화시킬 것입니다. 수십 명의 사람들이 Megabyte의 코드를 공동 소유하고 관리하는 대신 한두 사람이 Kilobyte의 코드를 관리합니다. 개발자는 DevOps 전문가가 되어 코드의 초기 개발부터 테스트 및 배포 감독, 배포 시 문제가 있는 코드를 수정하기 위한 전화 수신까지 책임을 집니다.

개발자가 코드를 체크인하기 전에 코드 분석 도구와 자동화된 테스트 프로세스를 실행하면 CI/CD 프로세스가 쉬워집니다.

CI/CD로의 전환은 개발자에게 큰 영향을 미치지만, 더 작고 미묘한 영향도 있습니다. Microservices에서 작업하는 개발자는 자신이 소유한 서비스의 코드 크기, 성능, 인터페이스, 배포의 견고성 및 보안 프로필에 집착할 가능성이 높습니다. 완벽함은 불가능할 수 있지만, 그것을 추구하는 것은 열정이 될 수 있습니다.

3-2. 지속적 통합(CI)

CI/CD 프로세스는 개발자가 Main Branch에 코드를 Commit 할 때 시작됩니다. 새 코드는 Build Unit Tests를 거칩니다. 이러한 작업이 실패하면 개발자에게 실패를 유발한 문제를 알립니다.

In the continuous integration stage of the CI/CD process, code committed to the main branch undergoes build unit tests

지속적 통합(CI)에서 테스트로 이동

개발자는 테스트할 코드를 배포합니다. 두 개발자가 동일한 코드를 변경한 경우 병합 프로세스에서 플래그가 표시됩니다. 초기 테스트 과정에서 문제가 발생하면 개발자에게 코드가 돌아갑니다. 여러 사람이 병합, 배포 및 테스트 프로세스를 처리하고 문제가 있을 때 서로 또는 개발자와 대화해야 하는 대신 개발자에게 직접 경고를 보냅니다.

개발자는 스크럼에서 만나 변경 사항을 논의한 다음 변경된 코드를 병합합니다. 문제가 코드 자체가 아니라 통합, 테스트 및 배포에 사용되는 도구 체인에 있는 경우 운영 또는 QA팀이 참여하여 전달 Pipeline 또는 테스트를 개선하거나 수정합니다.

전달 Pipeline이 강력해짐에 따라 개발자는 더 많은 책임을 지게 됩니다. 그들의 기술은 많은 양의 코드를 최적화하는 측면에서 더 심화되기보다는 다양한 책임 범위에 걸쳐 더 광범위해질 수 있습니다.

코드를 API를 통해 통신하는 개별 서비스로 나누는 Microservices 접근 방식이 도움이 될 수 있습니다. 개발자는 더 작지만 더 중요한 코드에 대한 책임이 있습니다.

각 서비스는 수명이 1인치 이내로 최적화됩니다. 한 상점에서는 코드가 개발되고 제공되는 프레임워크가 일반적으로 각 애플리케이션에서 복제되는 기능을 인수함에 따라 특정 애플리케이션의 코드 기반이 Gigabyte에서 수백 Kilobyte로 바뀌었습니다.

통합 단계의 자동화는 통합, 테스트 및 제공 프로세스 전체로 확장되어 개발자에게 더 많은 권한과 책임을 부여할 수 있습니다. CI/CD의 가장 강력한 정의에서 바쁜 연휴 기간 동안 전자 상거래 사이트에 버그가 발생하면 전화를 받는 사람은 운영 담당자가 아니라 개발자입니다.

3-3. 테스트

테스트는 CI/CD 환경에서 크게 변경됩니다. 한 종류 또는 다른 종류의 테스트는 CI/CD Pipeline 전체에서 수행됩니다. 이 테스트 단계는 하나 또는 두 가지 특정 유형의 테스트를 나타냅니다.

Automated acceptance tests – CI/CD 구현이 아닌 많은 소프트웨어 환경에는 어느 정도의 자동화된 승인 테스트가 포함됩니다. CI/CD에서 운영팀은 Production 준비가 되지 않은 모든 코드를 거부하기 위해 이 테스트 단계와 기타 테스트 단계를 지속적으로 강화하려고 합니다. 개발자는 자동화된 승인 테스트를 관리하는 팀에 적극적으로 참여하여 테스트가 효율적이고 애플리케이션의 중요한 부분에서 문제를 파악할 수 있도록 해야 합니다.

User acceptance testing – 이는 변경 사항이 배포되기 전에 실제 시나리오에서 사용자에게 소프트웨어 변경 사항을 Expose 할 수 있는 기회입니다. 그러나 이 단계는 CI/CD 체인에 사람의 개입이 필요하기 때문에 논란의 여지가 있습니다. 많은 사이트에서 더 강력한 자동화된 테스트를 위해 이 단계를 최소화하거나 제거하는 반면, 다른 사이트에서는 인간의 테스트를 사용하여 사용자 경험을 확인하고 잠재적인 문제의 비즈니스 영향을 추정합니다.

The testing stage of the continuous integration/continuous delivery process includes automated acceptance tests and user acceptance tests

자동 승인 테스트에서 사용자 승인 테스트로 전환

3-4. 지속적 전달

지속적 전달이란 코드가 개발에서 배포 준비 상태로 신속하게 자동으로 전달됨을 의미합니다. 지속적 배포(각각의 개별 코드 변경 사항이 준비되는 즉시 Production에 적용하는 것)는 지속적 전달이나 전체 프로세스 CI/CD를 호출하기 위한 요구 사항이 아닙니다.

지속적으로 배포하는 대신 이해관계자가 사용 가능한 소프트웨어의 지속적인 변경 사항을 처리할 필요가 없도록 코드 변경 사항이 누적되는 경우가 많습니다. 통합, 테스트 및 전달만큼 지속적으로 배포하지 않는 이유에는 문서 작성, 통합 코드 업데이트 필요성 및 누적된 변경 사항에 대한 사용자 테스트 수행 등이 있습니다.

경우에 따라 이렇게 누적된 변경 사항을 일정에 따라 자동으로 배포할 수 있습니다. 그러나 그렇게 하기로 선택한 경우 프로세스와 애플리케이션을 적절하게 모니터링하고 경고하는 것이 중요합니다. 이러한 방식은 변경으로 인해 발생하는 모든 문제가 이해관계자 또는 비즈니스 전체에 미치는 영향을 최소화할 수 있습니다.

3-5. 성능 및 배포 테스트

배포된 코드는 어떤 의미에서는 사용자에 의해 지속적으로 테스트됩니다. 사용자는 웹 사이트를 담당하는 조직에 실제 및 인식된 문제를 보고하기 위해 다양한 방법을 사용합니다. 이것은 조직에 이메일을 보내는 것과 같이 직접적일 수 있고 사용자가 사이트 문제에 대해 불평하는 블로그 포스트를 작성하는 것만큼 간접적일 수 있습니다.

조직에서는 특히 최근에 변경된 것으로 알려진 기능 영역에서 자체적으로 배포된 코드를 테스트하는 경우가 많습니다. 테스트에는 애플리케이션의 가용성과 애플리케이션의 성능이 포함될 수 있습니다. 이상적으로는 변경된 코드에 대해 사용성 테스트를 수행하여 많은 사용자가 문제를 겪기 전에 문제를 발견하는 것입니다. 성능 테스트는 성능 및 관련 가용성 목표를 충족하기 위해 전체 애플리케이션에 대해 정기적으로 수행하는 것이 가장 좋습니다. 이러한 테스트는 일반적으로 검색 쿼리의 최대 로드 시간 또는 장바구니의 배송 및 세금을 계산하는 시간과 같은 비즈니스 요구 사항을 적용합니다.

In the final stage of the continuous integration/continuous delivery process, newly deployed code continues to be tested and monitored in the field

사용자 승인 테스트에서 배포로 전환

4. 결론

CI/CD는 테스트 기능이 내장된 최신 자동화 애플리케이션 개발 및 제공 시스템의 중요한 부분입니다. 전체적으로 시스템을 통해 조직은 애플리케이션을 통해 훨씬 더 많은 것을 달성할 수 있습니다. NGINX 및 NGINX Plus는 효과적인 CI/CD 시스템의 중요한 구성 요소입니다.

NGINX 및 NGINX Plus를 사용하여 CI/CD를 구성해 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.