클라우드 파이프라인 구축
클라우드 컴퓨팅의 출현은 소프트웨어 호스팅 및 전달 방식에 큰 변화를 초래했습니다. 온라인 서비스는 일상의 많은 활동에 존재하며 컴퓨팅 인프라와 마찬가지로 리테일 분야에서 활용되고 있습니다. 이 문서에서는 지속적 통합, 전달 및 배포가 클라우드 기술, 특히 코드로서 인프라 및 컨테이너의 이점을 어떻게 활용할 수 있는지 살펴봅니다.
CI/CD 파이프라인을 처음 설정하든 기존 로컬 호스팅 설정을 보유하든, 필요에 따라 이러한 기술과 도구를 적용할 수 있도록 그 사용 방식을 이해할 만한 가치가 있습니다.
제한 요소로서 인프라
지속적 통합 및 배포는 사용자에게 소프트웨어를 릴리스하는 프로세스를 더 빠르고 강력하게 만들고자 설계되었습니다.
소규모로 자주 수행하는 접근 방식에 빌드, 환경 생성 및 테스트의 자동화를 결합하면 개발에서 출시까지 시간이 단축되며 제품 품질에 대한 확신을 제공할 수 있습니다.
CI/CD 워크플로의 후반 단계에는 일반적으로 엔드투엔드 테스트 및 성능 테스트, 수동 테스트가 포함됩니다. 모든 테스트는 프로덕션을 긴밀하게 미러링하는 테스트 환경을 필요로 합니다. 테스트의 효율성 및 일관성 극대화를 위해 테스트 환경을 수동으로 관리하기보다 자동으로 수정해야 합니다. 이 모든 것을 실행하려면 DevOps 기술과 도구뿐 아니라 CI 서버, 빌드 에이전트, 테스트 환경 및 데이터 저장소에 컴퓨팅 용량을 제공하는 대규모 인프라가 필요합니다.
빌드 프로세스를 지원하는 데 필요한 시스템 개수는 프로젝트의 크기와 복잡성, 프로젝트에 기여하는 개발자 수에 따라 다릅니다. 하지만 시간이 지나며 그 개수도 변동할 수 있습니다.
CI/CD 파이프라인 인프라를 모두 자체적으로 호스팅하고 관리하는 경우, 수요가 높은 시기에 여러 작업을 동시에 실행할 수 있는 충분한 용량 확보 및 상당 기간 동안 가동되지 않는 시스템을 구매하고 유지하는 비용 사이의 균형을 결정해야 합니다. 이때 클라우드 호스팅 인프라가 큰 이점을 제공할 수 있습니다.
지속적 통합 파이프라인에서 클라우드가 어떤 역할을 할 수 있나요?
클라우드 호스팅 인프라의 출현은 인프라 관리 방식에 큰 변화를 초래했습니다.
서비스로서 인프라(IaaS: Infrastructure-as-a Service)를 사용하면 가상 머신(VM) 또는 컨테이너를 통해 컴퓨팅 리소스가 제공됩니다. 더 많은 용량이 필요할 때 요청하면 됩니다(물론, 유료입니다). 구매, 설치 및 관리, 물리적 하드웨어는 이제 우려 사항이 아닙니다.
이런 식으로 조직은 이러한 VM 또는 컨테이너를 호스팅하는 물리적 시스템에 대한 가시성을 확보하지 못하며(규제 및 재해 복구 목적의 지리상 지역에 대한 인식 제외), 이에 따라 중요한 사고방식의 전환이 발생했습니다.
코드로서 인프라
클라우드 호스팅 컨텍스트에서 서비스를 백업하는 방대한 물리적 리소스를 통해 서버를 대체 가능한 일회용 소모품으로 취급할 수 있게 되었습니다(즉, “가축” 취급). 이는 오랫동안 서버를 반려동물처럼 취급해왔던 기존의 베어메탈 호스팅과는 대조되는 방식입니다. 이전에는 서버에 고유한 이름을 부여하고, 문제가 발생하면 돌봐주며 비교적 긴 서버 수명을 예상했습니다.
하지만 서버를 “가축”으로 보는 접근 방식을 채택하면 서버 업데이트나 수리가 필요한 경우 간편하게 제거하고 요구 사항을 충족하는 새 서버로 교체할 수 있습니다. 기존 인스턴스를 수정하거나 수리하는 데 시간이나 노력이 들지 않습니다. 대신 이미지는 필요에 따라 재구성되며 새 인스턴스가 배포됩니다.
IaaS를 사용하면 사용한 컴퓨팅 리소스에 대해서만 비용을 지불하므로 가축 사고방식을 채택하는 것이 적합합니다. 코드로서 인프라(IaC: Infrastructure-as-Code)가 필요한 이유는 바로 이 때문입니다. IaC는 스크립트를 사용해 인프라 프로비저닝을 반복 가능하게 구성하는 DevOps 관행입니다.
모든 구성 정보를 코드에 추가하고 애플리케이션 코드처럼 소스 관리 시스템에 유지할 경우 개별 환경을 수동으로 조절할 필요가 없으므로 비일관성이 초래되지도 않습니다.
개발 중인 소프트웨어처럼 CI/CD 파이프라인을 통해 인프라 자체를 테스트하고 예상대로 작동하는지 확인하면 변경 사항을 쉽게 롤백할 수 있다는 이점이 있습니다.
인프라를 코드로서 관리할 때 더 많은 자동화의 가능성이 열립니다. 필요에 따라 환경을 자동으로 생성하고, 새 구성을 출시하여 업데이트할 수도 있습니다.
IaaS 제공 업체의 효과적인 무제한 컴퓨팅 리소스 공급을 활용하면 수요에 따라 규모를 확장하고 축소할 수 있으며 인스턴스가 실패할 경우 즉시 교체할 수 있습니다. 즉, CI/CD 설정으로 수요 증가에 대응하며 안정적인 서비스를 보장할 수 있는 것입니다.
하드웨어 아웃소싱
IaaS 및 CaaS를 사용하면 클라우드 공급자가 서비스 제공의 일환으로 네트워킹 및 스토리지 용량, 데이터 센터 물류 관리를 비롯한 모든 물리적 하드웨어의 처리합니다.
따라서 팀은 파이프라인 프로세스 최적화 및 보안 유지에 집중할 수 있습니다. 비용은 처리 능력과 시간의 요소이므로 가능한 경우 작업 병렬화에 시간을 할애하여 소수의 시스템을 장기간 사용하는 것보다 더 빨리 개발자에게 결과를 제공하는 것이 좋습니다.
컨테이너
컨테이너는 IaC 원칙을 적용하며 클라우드 호스팅 인프라를 더욱 효과적으로 사용할 수 있도록 지원합니다. 컨테이너는 실행에 필요한 모든 종속성을 사용해 소프트웨어를 패키징하므로 이제 “제 시스템에선 작동하는데요”와 같은 문제나 구성의 세부 사항의 차이점을 샅샅이 찾아내야 하는 불편을 겪을 일이 없습니다. Docker는 가장 잘 알려진 컨테이너 기술 중 하나이지만 다른 옵션도 사용할 수 있습니다.
가상 머신과 마찬가지로 컨테이너를 활용하면 동일한 물리적 서버에서 여러 애플리케이션을 실행하는 동안 서로 분리할 수 있습니다. 하지만 VM과는 달리 컨테이너에는 OS가 포함되지 않으므로, 설치 공간이 더 작으며 호스트 리소스의 고정 할당량이 필요하지도 않습니다. 결과적으로 시스템 하나에 VM보다 훨씬 더 많은 컨테이너를 담을 수 있으므로, 컨테이너는 클라우드 호스팅 인프라에 소프트웨어를 효율적으로 배포하는 데 적합합니다.
컨테이너를 도입함으로써 소프트웨어와 함께 환경 종속성 및 구성 세부 정보를 컨테이너 런타임을 제공하는 모든 시스템에 배포 가능한 단일 아티팩트로 패키징할 수 있습니다.
애플리케이션은 마이크로 서비스 아키텍처의 사례와 마찬가지로 여러 컨테이너에 분할할 수 있습니다. 이때 컨테이너를 동일 시스템 또는 네트워크로 연결된 시스템 클러스터에 배포해야 합니다. Kubernetes와 같은 컨테이너 오케스트레이션 도구는 배포, 관리 및 확장과 같은 작업을 자동화하여 다수의 컨테이너에서 더욱 쉽게 작업할 수 있도록 개발되었습니다.
CI/CD 워크플로에서 컨테이너를 사용하면 최신 빌드를 파이프라인의 여러 단계에 배포하는 프로세스가 훨씬 간소화됩니다. 빌드 아티팩트는 프로덕션으로 릴리스하기 전에 각 테스트 환경에 일관적으로 배포할 수 있는 컨테이너 이미지입니다.
CI/CD 클라우드 파이프라인에서 컨테이너를 통해 컴퓨팅 리소스를 효율적으로 사용하고 자동화 도구를 활용할 수 있습니다. 수요가 높을 때 용량을 늘릴 수 있지만 수요가 낮을 때 컨테이너를 제거하고 기본 인프라를 해제할 수 있어 비용이 절감됩니다.
이제 여러 클라우드 제공 업체에서 IaaS와 더불어 서비스로서 컨테이너(CaaS: containers-as-a-service)를 제공하므로 조직은 오케스트레이션 플랫폼 관리 및 클러스터 구성 없이도 컨테이너를 직접 배포할 수 있습니다.
클라우드 CI 호스팅과 관련한 고려 사항
CI/CD 클라우드 파이프라인이 인프라 비용, 확장성 및 안정성 측면에서 상당한 이점을 제공할 수 있지만 고려해야 할 몇 가지 단점도 있습니다.
지식과 기술
우선 IaaS 및 CaaS 등의 클라우드 서비스 사용에는 필연적으로 학습 과정이 수반됩니다. 이 분야에 대한 전문 지식을 아직 보유하지 않은 경우 팀원들이 기술을 익힐 시간을 제공하거나 해당 지식을 도입하는 것을 고려해야 합니다. 그럼에도 클라우드 기술을 활용한 작업 경험은 바람직한 기술이며, 팀에서 능력을 개발하고 최신 기술을 사용할 기회를 제공하는 것은 직원 근속률 및 고용 면에서 유리할 수 있습니다.
시스템 아키텍처
개발 중인 소프트웨어가 마이크로 서비스, 컨테이너 및 기타 클라우드 네이티브 사례를 사용하여 클라우드용으로 설계된 경우 컨테이너를 활용한 CI/CD 클라우드 파이프라인을 통해 비교적 간단히 진행 상황을 자동화할 수 있습니다. 반면 모놀리식 아키텍처에서 작업하는 경우 소프트웨어의 컨테이너 패키징이 까다로울 수 있습니다.
물론 컨테이너가 클라우드 호스팅 파이프라인에 필수적인 것은 아니며 클라우드 공급 업체의 인프라에서 가상 머신을 사용해 빌드를 실행하고 테스트를 위해 일관적인 사전 프로덕션 환경을 제공할 수 있습니다. 하지만 VM은 컨테이너보다 더 많은 리소스를 소비하며 환경을 별도로 구성해야 합니다.
비용
클라우드의 컨텍스트에서 시간은 돈입니다. 가동되지 않는 컴퓨팅 리소스 비용을 지불하고 싶지는 않으실 겁니다. 클라우드 호스팅의 비용 효율성을 위해 효율적으로 사용할 필요가 있습니다. 즉 사용량을 모니터링하고 제한 시간 초과 시 유휴 상태의 인스턴스를 해제하는 도구를 활용하거나 해당 로직을 직접 구현해야 합니다. 로직 구현 옵션은 조직에서 보유하지 않은 기술이 필요할 수 있으므로 옵션을 조사하고 평가하는 것이 좋습니다.
보안
클라우드에서의 데이터 및 서비스 호스팅과 관련해 보안은 항상 우려 사항이었습니다. 일부 기업에서는 자사의 핵심 소프트웨어가 타사 도구에 놓인다는 생각만으로 부정적인 반응을 보입니다. 그럼에도 많은 조직은 퍼블릭 클라우드를 사용하여 소스 관리 저장소부터 CI 서버 및 테스트 환경을 아우르는 라이브 서비스 및 배포 파이프라인을 모두 호스팅하고 있습니다.
잠재적인 공격 벡터를 이해하고, 악성 행위자가 파이프라인을 사용해 라이브 시스템에 액세스할 수 없도록 방지하는 보호 기능을 구축하고, 자격 증명 관리, 테스트 데이터 및 액세스 제어와 관련한 모범 사례를 구현하는 것은 모두 위험을 완화하는 데 필수적인 조치입니다.
하이브리드 접근 방식
코드로서 인프라, 컨테이너 및 컨테이너 오케스트레이션은 모두 클라우드 기술을 기반으로 하지만 하이브리드 인프라에서도 이를 사용할 수 있습니다.
파이프라인의 확장 가능성에 제한이 있다는 점에 유의하며 프라이빗 클라우드와 온프레미스 인프라 모두에서 동일한 도구를 사용할 수 있습니다. 조직에서 향후 클라우드 호스팅 인프라로 전환할 계획이라면, 클라우드 네이티브 도구를 조기에 채택하여 전문 지식을 미리 구축하고 간편하게 전환할 수 있습니다.
코드로서 인프라의 클라우드 네이티브 운영 시 지속적 통합 및 로컬 인프라 배포를 위한 다양한 이점을 제공합니다. 우선 스크립트를 실행하는 것만으로 새로운 환경을 훨씬 빠르게 구성할 수 있습니다.
환경 생성 코드화는 일관성을 제공하므로 보안, 성능, UI 테스트, 지원 및 영업팀용 샌드박스 모두에서 프로덕션 설정과 사전 프로덕션 환경 간의 패리티가 보장됩니다. 팀은 인프라 구성 파일을 소스 관리 시스템에 유지함으로써 도입된 변경 사항과 시기에 대한 감사 추적을 통해 환경 이슈를 훨씬 간단하게 디버깅할 수 있습니다.
경우에 따라 조직은 배포 파이프라인의 특정 단계에서 클라우드 리소스를 사용하기로 선택합니다. 예를 들어, 부하 및 성능 테스트에 상당한 리소스가 필요할 수 있으므로 이를 수행하기 위한 임시 클라우드 환경을 생성하는 것이 더욱 비용효율적일 수 있습니다. 이러한 접근 방식을 고려할 때 빌드를 다른 인프라로 이전하는 데 필요한 잠재적 복잡성과 시간을 평가하는 것이 중요합니다.
CI 파이프라인에 클라우드를 선택하는 이유는 무엇인가요?
자동화된 CI/CD 프로세스는 전달 속도 및 품질 보증 측면에서 상당한 이점을 제공하지만, 그 속도 및 처리량은 현재 사용 가능한 인프라에 따라 제한됩니다. 파이프라인을 클라우드로 이전하면 최대 수요를 처리하기 위한 충분한 서버 프로비저닝과 일정하게 사용되지 않는 시스템의 구매 및 관리 비용을 두고 고민할 필요가 없습니다.
클라우드 네이티브 기술 및 운영을 통해 클라우드 호스팅 인프라를 효율적으로 사용할 수 있을 뿐 아니라 지속적 통합 및 배포 기술도 개선됩니다. 동일한 접근 방식을 로컬 인프라에 적용하면 소프트웨어를 더 빠르고 안정적으로 제공할 수 있습니다.