이 문서에서는 Google Kubernetes Engine을 사용하는 멀티 팀 소프트웨어 제공 플랫폼에서 최신 지속적 통합/지속적 배포(CI/CD) 프로세스를 구현하기 위한 프레임워크를 설명합니다.
그런 후 플랫폼을 반복하여 출시 속도, 플랫폼 안정성, 오류 복구 시간을 비롯하여 개발 및 운영을 위해 성능을 향상시킬 수 있습니다.
이 문서는 다음 시리즈의 일부입니다.
GKE를 사용한 최신 CI/CD: 소프트웨어 제공 프레임워크(이 문서)
GKE를 사용한 최신 CI/CD: CI/CD 시스템 구축(참조 아키텍처)
이 문서는 IT 보안, DevOps, 사이트 안정성 엔지니어링팀은 물론 엔터프라이즈 아키텍트 및 애플리케이션 개발자를 대상으로 합니다. 자동화 배포 도구 및 프로세스에 대한 경험이 있으면 이 문서의 개념을 이해하는 데 도움이 됩니다.
최신 CI/CD 사례
CI/CD는 다양한 도구 및 반복 가능한 프로세스를 사용하여 소프트웨어 개발의 빌드, 테스트, 배포 단계를 자동화할 수 있게 해주는 소프트웨어 개발 접근 방식입니다.
기업은 CI/CD 자동화 외에도 Kubernetes 및 컨테이너 덕분에 개발 및 배포 속도를 전례 없이 크게 향상시킬 수 있었습니다. 하지만 Kubernetes 및 컨테이너 채택이 늘고 있더라도 많은 조직들에서는 해당 CI/CD 구현으로 Kubernets 모든 이점을 활용하지 못하거나 운영 및 보안 문제를 해결하지 못하기 때문에 출시 속도, 안정성, 운영 효율성 측면의 이점을 완전히 활용하지 못하고 있습니다.
올바른 최신 CI/CD 접근 방식은 자동화 이상의 이점을 제공할 수 있어야 합니다. 속도 및 보안 측면의 기능 향상을 완전히 실현하고 Kubernetes 및 컨테이너의 장점을 활용하기 위해서는 애플리케이션 온보딩, CI/CD 방식 및 운영 프로세스를 효율적으로 운용할 수 있어야 합니다.
조직은 GKE 플랫폼에서 제공되는 일관적인 인프라, 동일한 CI/CD 메서드, 구현 권장사항을 사용함으로써 개발 및 운영 측면에서 다음과 같은 이점을 얻을 수 있습니다.
변경을 위한 선행 시간을 줄여줍니다.
운영팀 및 보안팀이 플랫폼 간 애플리케이션 및 정책을 프로비저닝하기 위한 권장사항을 만들고 업데이트할 수 있습니다.
조직 내 권장사항이 기본적으로 포함되어 있고 완전히 작동하고 배포 가능한 시작 조건 프로젝트를 팀에 제공하여 애플리케이션 온보딩을 간소화합니다.
서비스 복원에 필요한 시간을 줄여줍니다.
간소화된 감사, 롤백, 검토를 위해 GitOps를 사용하여 모든 구성을 선언적인 방식으로 관리합니다.
조직 내 배포 및 모니터링 방법을 표준화하여 서비스에 영향을 미치는 문제에 기인하는 요소들을 식별하는 데 걸리는 시간을 줄여줍니다.
배포 빈도를 늘려줍니다.
애플리케이션 개발자가 서로 간섭하는 일 없이 자신의 고유 개발 샌드박스(또는 랜딩 영역)에서 독립적으로 반복할 수 있게 해줍니다.
배포, 향상된 출시 관리, 변경 추적을 위해 GitOps를 사용합니다.
서비스팀이 자주 배포할 수 있도록 가드레일을 구현합니다.
사전 프로덕션 환경 간의 일관적인 배포를 위해 점진적인 출시 프로세스를 만들어 개발자가 프로덕션에 변경사항을 배포해야 한다는 확신을 얻을 수 있게 해줍니다.
GKE 및 CI/CD를 사용하여 이러한 이점 및 개념을 실현하는 방법을 자세히 알아보려면 이 시리즈의 다른 문서들을 참조하세요.
최신 접근 방식에 대한 준비 상태 평가
GKE를 사용하여 최신 CI/CD 도구 및 프로세스를 구현하려면 먼저 조직 및 팀에서 새 플랫폼을 채택할 준비가 되었는지 평가해야 합니다.
조직 특성
최신 플랫폼을 채택하기 위해서는 비즈니스 리더십 및 기술팀에서 다음과 같은 지원이 필요합니다.
경영진 후원. 소프트웨어 제공 플랫폼 채택은 일반적으로 여러 부서별 팀 간에 수행되는 대규모 작업입니다. 이 프로세스는 일반적으로 소프트웨어 개발 방식은 물론 역할 및 책임의 변화를 가져옵니다. 이러한 도구 및 기법을 성공적으로 채택하기 위해서는 한 명 이상의 경영진 구성원으로부터의 강력한 지원이 필요합니다. 가장 효율적인 경영진 후원을 얻기 위해서는 이러한 변화를 지속적인 향상 과정으로 바라보고 팀을 관리하기 보다는 팀의 역량을 강화하려는 자세가 필요합니다.
기술 및 비즈니스 전략 조정. 변경을 위한 선행 시간, 배포 주기, 서비스 복원 시간, 변경 실패율이라는 DevOps Research and Assessment(DORA)에서 정의된 4가지 핵심 소프트웨어 제공 측정 기준에 따라 비즈니스팀과 기술팀 간의 업무를 조정하는 것이 좋습니다. 이러한 측정 기준에 따라 업무를 조정함으로써 비즈니스팀과 기술팀이 투자수익 계산, 변경률 조정, 투자 수준 수정에 대해 공동 목표를 설정할 수 있습니다.
리소스. 성공을 위해 최신 CI/CD 방식 및 빌드 도구 체인을 개발하는 팀에는 시간, 사람, 인프라라는 필수 리소스가 필요합니다. 이러한 팀은 최상의 프로세스 및 도구를 시도하고 선택할 수 있는 시간이 필요합니다. 이상적으로 이러한 팀은 소프트웨어 제공 프로세스에서 다양한 기능을 담당하며, 조직 내에서 서로 다른 리소스를 가져올 수 있습니다. 마지막으로 각 팀은 클라우드 리소스 및 소프트웨어 도구를 포함하여 인프라를 프로비저닝할 수 있어야 합니다.
새로운 도구 채택에 대한 개방적인 자세. 최신 CI/CD 도구 및 기법은 종종 새로운 도구 및 프로세스와 함께 제공됩니다. 팀은 이러한 프로세스 및 도구를 실험하고 개방적인 자세로 이를 채택해야 합니다. 플랫폼팀이 플랫폼을 사용하는 애플리케이션팀, 운영팀, 보안팀의 의견을 들을 수 있도록 피드백 루프가 필요합니다.
문화적인 준비. GKE를 사용하여 최신 CI/CD 시스템을 성공적으로 배포하고 채택하기 위해서는 작업 및 협업 방법을 바꿀 수 있도록 시스템을 개발하는 조직 및 기술 팀을 준비해야 합니다. 예를 들어 개발팀과 운영팀은 더 많은 보안 책임을 기꺼이 담당하고, 보안팀과 운영팀은 변경 승인 프로세스를 효율화하기 위해 노력해야 합니다.
기술적 역량
최신 CI/CD 접근방식을 채택하기 위해서는 다음과 같은 방식으로 팀이 기술적으로 준비되어 있어야 합니다.
컨테이너 사용 경험. 최신 CI/CD 접근 방식을 채택하는 팀에 컨테이너 사용 경험이 있어야 합니다. 이상적으로 이러한 환경에는 컨테이너 이미지를 빌드하고 컨테이너를 결합하여 더 큰 시스템을 구축하기 위한 개발 기법이 포함됩니다.
지속적 통합 전략. 팀은 CI 도구(예: Jenkins, TeamCity, Bamboo, CircleCI)를 사용하고 지속적 통합 및 자동 테스트를 수행한 경험이 있어야 합니다. 조직에서는 이러한 프로세스를 더 향상시킬 수 있는 방법을 계획하는 것이 좋습니다.
배포 자동화. 팀에 배포 자동화 경험이 있어야 합니다. 자동화된 배포 도구 예시에는 기본 셸 스크립트, Terraform, Chef 또는 Puppet이 있습니다. 배포를 효율화하고 자동화하기 위해서는 자동화된 배포 도구 및 프로세스에 대한 기본 지식이 필요합니다.
서비스 지향 아키텍처. GKE를 사용하여 최신 CI/CD 도구 및 기법을 채택하려는 조직은 최신 CI/CD 프로세스를 채택하기 위한 전제 조건이 아니더라도 모듈식 및 서비스 지향 아키텍처 채택을 장기 목표로 삼아야 합니다. 서비스 기반 아키텍처는 속도 및 안정성을 향상시키는 것으로 확인되었습니다.
최신 소스 제어. Git와 같은 최신 소스 제어 도구를 통해 팀은 트렁크 기반 개발, 기능 분기, 병합 요청과 같은 워크플로를 설정할 수 있습니다.
GKE에서 현대적인 CI/CD 설계
이 섹션에서는 소프트웨어 제공 플랫폼 및 해당 구성요소에 대해 설명합니다. 소프트웨어 제공 성능을 향상시키기 위해서는 팀이 빠르게 출시하고 효율적으로 운영할 수 있게 해주는 CI/CD 및 기타 기술적 권장사항을 구현해야 합니다.
이 섹션에서는 또한 소프트웨어 제공 수명주기를 지원하기 위해 필요한 인프라에 대해 설명하고 GKE를 사용하여 이러한 인프라를 일관적으로 관리하는 방법을 설명합니다. 마지막으로 이 섹션에서는 소프트웨어 제공 워크플로 예시를 제공하고 시작 조건 저장소를 사용해서 온보딩 및 권장사항 구현을 간소화하는 방법을 보여줍니다. 다음 디자인 고려사항을 검토해야 합니다.
소프트웨어 제공 플랫폼. 빠르고 안정적인 애플리케이션 출시 프로세스의 기초를 구성하는 프레임워크 및 기술 역량이 필요합니다.
플랫폼 인프라. 플랫폼 빌드 및 애플리케이션 실행을 위해 필요한 인프라 구성요소 및 관리를 고려해야 합니다.
소프트웨어 제공 워크플로. 보다 효율적인 코드 빌드, 테스트 및 배포를 위한 팀 협력 방식을 고려해야 합니다.
코드 저장소. 실제 비즈니스 로직, 애플리케이션별 구성, 인프라 빌드를 위한 코드를 저장하는 등 여러 기능을 수행하는 저장소입니다. 또한 권장사항 채택을 지원하고 자동화된 프로세스 간 일관성을 유지하는 데 도움이 되는 시작 조건 저장소일 수 있습니다.
애플리케이션 랜딩 영역. 개발자가 가드레일을 사용하여 자신의 애플리케이션 배포 및 반복을 자율적으로 수행할 수 있게 해주는 논리 항목이 필요합니다.
작업 모델. 플랫폼을 구성하는 인프라 및 애플리케이션을 관리하기 위한 기술적 도구, 프로세스 및 메서드가 필요합니다.
거버넌스. 소프트웨어 제공 플랫폼을 유지보수하고 관리하기 위해 필요한 프로세스 및 고려사항이 필요합니다.
소프트웨어 제공 플랫폼
소프트웨어 제공 플랫폼은 도구를 통합하고 애플리케이션 빌드, 제공, 배포, 운영에 필요한 프로세스를 효율화합니다.
애플리케이션의 구성, 안정성, 업타임, 확장 유지를 위한 책임은 운영팀, 보안팀, 개발팀 간에 서로 다르지만, 출시 속도를 높이기 위해 모든 구성요소 및 팀 간의 협력이 필요합니다. 이 문서에서는 소스 제어 관리 및 애플리케이션 관측 가능성을 향상시키기 위한 방법들을 설명하지만, 주로 지속적 통합(CI), 지속적 배포(CD), 구성 관리에 대해 자세히 설명합니다.
완전한 소프트웨어 제공 플랫폼을 빌드하기 위해서는 다음 다이어그램의 각 구성요소가 필요합니다.
이러한 각 구성요소는 플랫폼에서 실행되는 시스템 및 애플리케이션에 기능을 제공합니다.
인프라 모니터링. Google Kubernetes Engine(GKE) 클러스터, 가상 머신(VM) 인스턴스, 애플리케이션 작동에 필요한 기타 인프라가 올바르게 작동하는지 확인하기 위해 프로비저닝할 때 필요한 기본 모니터링 수준입니다.
컨테이너 조정. 컨테이너 기반 애플리케이션의 배포 및 운영을 조정하는 플랫폼입니다. 컨테이너 조정을 위한 플랫폼 예시로는 Kubernetes, GKE, GKE Enterprise가 있습니다.
Container Registry. 컨테이너 이미지에 대한 스토리지 및 액세스 제어를 지원합니다.
CI. 배포 전 애플리케이션에 자동화 태스크를 적용하는 프로세스입니다. CI 태스크에는 일반적으로 빌드, 패키징, 테스트가 포함됩니다. 태스크 유형은 애플리케이션 및 조직별로 달라집니다.
CD. 높은 수준으로 자동화되고 높은 빈도로 적용되는 배포 프로세스입니다. 예시 방법으로는 수동 승인, 카나리아 배포, 블루-그린 배포, 지속적 배포가 포함됩니다.
정책. 운영팀 및 보안 팀에서 정의되고 플랫폼에서 지속적으로 적용 및 강제되는 보안 및 인프라 구성 정책입니다.
소스 코드 관리. 예를 들어 코드, 구성 파일, 정책 정의를 위한 버전 제어 스토리지입니다. 최신 CI/CD 시스템에서 소스 코드 관리는 일반적으로 Git입니다.
구성 관리. 여러 환경에서 애플리케이션 구성을 저장하고 적용하기 위해 사용되는 시스템입니다.
애플리케이션 관측 가능성. 개발팀, 운영팀, 보안팀이 적절한 애플리케이션 운영을 확인하고 문제 해결하기 위해 사용하는 애플리케이션 수준 로깅, 모니터링, 알림, 추적입니다.
플랫폼 인프라
확장 가능한 소프트웨어 제공 플랫폼을 빌드하기 위해서는 개발, 사전 프로덕션 환경을 위한 Kubernetes 클러스터 및 다중 프로덕션 클러스터가 필요합니다. 클러스터는 많은 여러 기능을 제공할 수 있습니다.
개발. 이러한 클러스터에서 개발자는 테스트 및 실험을 위해 애플리케이션에 대해 임시 배포를 수행할 수 있습니다.
애플리케이션 환경.
사전 프로덕션. 워크플로에서 각 사전 프로덕션 환경에 대해 애플리케이션을 호스팅할 Kubernetes 클러스터가 있어야 합니다. 이러한 클러스터는 프로덕션 클러스터와 비슷하여 두 환경 간의 차이를 줄이거나 없앨 수 있어야 하며, 그 결과 배포 성공률을 높일 수 있어야 합니다.
프로덕션. 이러한 클러스터는 프로덕션 워크로드에서 실행됩니다. 지리적으로 분산된 여러 클러스터를 사용해야 합니다. 이렇게 하면 인프라 오류 시에도 안정성을 높일 수 있고 클러스터 업그레이드 및 확장과 같은 2일차 작업 문제를 완화할 수 있습니다.
다음 다이어그램은 대략적인 아키텍처를 보여줍니다. 
이 아키텍처에서는 구성 동기화를 통해 각 환경에 대해 클러스터를 관리합니다. 일관적인 클러스터 구성은 개발팀, 운영팀, 보안팀에 사전 프로덕션 및 프로덕션 환경이 비슷한 방식으로 작동한다는 확신을 주기 때문에 중요합니다. 구성 동기화를 사용하여 클러스터 Fleet에 공통 구성을 저장하고 적용할 수 있습니다. 클러스터 구성을 표준화하고 감사 및 확장할 수 있도록 설정한 후 소프트웨어 제공 워크플로와 애플리케이션 온보딩 및 배포에 집중할 수 있습니다.
애플리케이션의 CI/CD 파이프라인을 통해 개발, 스테이징, 프로덕션 클러스터에 대해 배포를 관리합니다. 소스 제어 관리는 애플리케이션 코드 및 구성에 대한 조정 지점으로 사용됩니다. 애플리케이션에 대한 CI/CD 파이프라인과 컨테이너 이미지는 해당 애플리케이션의 환경과 격리됩니다. 시작 조건 저장소 및 자동화된 도구를 사용하여 애플리케이션 및 구성 저장소를 초기화합니다. 예를 들어 Cloud Build를 사용하면 Terraform을 실행하여 새 애플리케이션을 자동으로 온보딩하고 초기화할 수 있습니다.
애플리케이션이 네트워크 및 ID로 격리되도록 각 클러스터에서 고유 랜딩 영역에 애플리케이션을 배포합니다. 구성 동기화를 사용하여 각 환경 간에 애플리케이션 랜딩 영역을 초기화하고 Anthos Service Mesh 또는 멀티 클러스터 인그레스를 사용하여 여러 클러스터에 걸쳐진 네트워크 메시를 만들어서 프로덕션 클러스터가 서로 비슷하게 표시되도록 합니다.
소프트웨어 제공 워크플로
소프트웨어 제공 플랫폼의 핵심 구성요소는 CI/CD 시스템입니다. 플랫폼 작성자가 CI/CD 프로세스 정의를 시작할 때는 각 구성요소가 표준화된 인터페이스를 준수하는 아티팩트를 생성하거나 사용하는지 확인해야 합니다. 표준화된 인터페이스를 사용하면 더 나은 구현이 출시되었을 때 구성요소를 쉽게 대체할 수 있습니다.
컨테이너화된 애플리케이션을 위한 플랫폼을 만들 때는 구성요소 간에 세 가지 표준화된 인터페이스인 Git 저장소, Docker 이미지, Kubernetes 매니페스트를 사용할 수 있습니다. 이러한 인터페이스를 사용하면 다음 다이어그램에 표시된 것처럼 개발, 빌드, 출시 워크플로가 포함된 재사용 가능하고 유연한 CI/CD 파이프라인을 만들 수 있습니다.
이 워크플로는 다음과 같이 작동합니다.
개발자가 애플리케이션 코드를 코드 저장소에 커밋합니다.
CI 시스템이 코드를 테스트하고 Docker 이미지 아티팩트를 만들며 레지스트리에 아티팩트를 저장합니다.
아티팩트가 배포 준비되면 이에 대한 참조가 애플리케이션 구성에 추가됩니다.
애플리케이션 구성이 Kubernetes에서 판독 가능한 형식으로 렌더링되고 코드 저장소에 저장됩니다. 이 저장소를 업데이트하면 통합 개발 환경에서 아티팩트를 배포하는 배포 파이프라인이 트리거됩니다.
통합 개발 환경의 테스트가 완료된 후 운영자가 배포를 사전 프로덕션 환경으로 승격합니다.
애플리케이션이 사전 프로덕션 환경에서 예상한 대로 작동하는지 확인한 후 운영자가 배포 파이프라인에서 승인을 얻고 릴리스를 프로덕션 환경으로 승격합니다.
운영자가 기본 구성을 변경하면 해당 변경사항이 조직 전체에 적용됩니다. 운영자가 변경사항을 해당 저장소에 커밋하면 애플리케이션 구성 변경사항(및 이후 배포)이 자동으로 트리거될 수 있습니다. 또는 다음에 개발자가 변경사항을 배포할 때 운영자의 변경사항을 선택할 수 있습니다.
동시에 보안 엔지니어는 배포 가능한 대상을 정의하는 정책을 구현 및 조정한 후 이러한 정책을 자신의 정책 저장소에 커밋할 수 있습니다.
GitOps 방법론을 사용하여 애플리케이션 및 클러스터에 대한 모든 변경사항에 대해 선언적인 접근 방식을 요구할 수 있습니다. 이 접근 방식에서는 모든 변경사항을 적용하기 전 감사 및 검토를 거쳐야 합니다. 이 선언적 모델에서는 Git 저장소에 구성 파일을 저장합니다. 여기에서는 변경사항 로그를 유지하고, 실패한 배포를 롤백할 수 있고, 제안된 변경사항으로 인한 잠재적 영향을 파악할 수 있습니다.
연결된 참조 아키텍처에서 kustomize를 사용하여 조직의 애플리케이션 구성을 제어합니다. kustomize 도구를 사용하면 운영자가 애플리케이션 구성의 기본을 만들 수 있고, 개발 팀은 기본 요소의 코드를 변경하거나 추가할 필요 없이 이를 조정할 수 있습니다. 기본 구성을 정의하면 플랫폼팀이 조직의 권장사항을 만들고 반복할 수 있습니다. 운영자 및 개발자가 독립적으로 배포를 반복할 수 있으며, 개발자는 운영자가 설정한 권장사항을 적용할 수 있습니다. 운영자가 조직에 새 권장사항을 구현해야 할 경우, 기본 요소를 변경하면 그러한 변경사항이 개발자의 다음 배포에 자동으로 적용됩니다.
코드 저장소
소스 코드 저장소는 CI/CD 시스템의 핵심 위치에 있습니다. 운영자, 개발자, 보안 엔지니어는 각자 자신의 고유 저장소를 갖고서 플랫폼에 변경사항을 전파할 수 있습니다. 시스템에서 모든 변경사항에 대한 기본으로 Git 저장소를 사용하면 몇 가지 이점이 있습니다.
기본 제공되는 감사 가능성. 커밋에는 시스템을 변경한 시간, 변경한 항목, 변경한 작업자에 대한 정보가 포함됩니다.
간소화된 롤백 프로세스. Git의 되돌리기 기능을 통해 시스템의 이전 상태로 롤백할 수 있습니다.
버전 관리. 시스템 상태에 대한 버전을 표시하기 위해 Git 커밋에 태그를 지정할 수 있습니다.
트랜잭션. 변경사항을 상태에 통합하려면 먼저 상태 충돌을 명시적으로 확인하고 검토해야 합니다.
다음 다이어그램은 여러 팀이 모든 변경사항에 대한 중앙화된 저장소로 상호작용하는 방법을 보여줍니다.
다음 섹션에서는 운영자, 개발자, 보안 엔지니어가 최신 CI/CD 시스템에서 Git 저장소를 사용하는 방법을 설명합니다.
운영자 저장소
운영자가 관리하는 저장소에는 시작부터 조직 권장사항을 채택하면서 팀의 애플리케이션 온보딩을 도와주는 CI/CD 및 애플리케이션 구성에 대한 권장사항이 포함됩니다. 운영자가 관리하는 저장소에서 개발자는 워크플로에 대한 중단을 최소화하여 조직 권장사항에 대한 업데이트를 사용할 수 있습니다.
운영자는 자신의 조직 권장사항을 2개의 저장소로 인코딩할 수 있습니다. 첫 번째 저장소는 운영자가 공유 CI/CD 파이프라인 권장사항을 유지하는 장소입니다. 이 저장소에서 운영자는 개발자에게 파이프라인 빌드를 위해 사용할 수 있는 사전 정의된 태스크 라이브러리를 제공합니다. 개발자의 애플리케이션 저장소는 이러한 태스크와 그 안의 논리를 자동으로 상속합니다. 태스크를 수동으로 복사할 필요가 없습니다. 조직 내에서 표준화할 수 있는 태스크 예시는 다음과 같습니다.
아티팩트 빌드 및 스토리지
다양한 언어에 대한 테스트 방법
배포 단계
정책 확인
보안 스캔
운영자가 유지관리하는 두 번째 저장소에는 애플리케이션 구성을 위한 권장사항이 저장됩니다. GKE의 맥락에서 권장사항은 Kubernetes 리소스 모델에서 선언적 매니페스트를 관리하기 위한 방법을 보장하는 것과 관련됩니다. 이러한 매니페스트는 애플리케이션의 의도된 상태를 설명합니다. 운영자는 여러 애플리케이션 유형에 대해 기본 구성을 만들고 조직 권장사항에 따라 앱을 배포할 수 있는 효율화된 경로를 개발자에게 제공할 수 있습니다.
애플리케이션 저장소
애플리케이션 저장소에는 애플리케이션의 비즈니스 논리 및 애플리케이션의 올바른 운영을 위해 필요한 모든 특별한 구성이 저장됩니다.
운영자가 코드화된 방식으로 권장사항을 만들고 유지관리하며, 개발자는 이러한 권장사항을 사용할 수 있습니다. 이를 위해 개발자는 태스크에서 운영자가 자신의 저장소에 만든 애플리케이션 기본 및 CI/CD를 참조합니다. 개발자가 항목을 변경한 후 운영자는 데이터베이스 URL 또는 리소스 라벨 및 주석과 같은 환경별 구성을 추가하여 애플리케이션 배포를 더 맞춤설정할 수 있습니다.
애플리케이션 저장소에 저장할 수 있는 아티팩트 예시는 다음과 같습니다.
애플리케이션 소스 코드
애플리케이션 빌드 및 실행 방법을 설명하는
DockerfileCI/CD 파이프라인 정의
운영자가 만든 애플리케이션 구성 기본에 대한 확장 또는 수정
코드 저장소로서의 인프라
코드 저장소로서의 인프라는 애플리케이션을 실행하는 데 필요한 인프라를 빌드하기 위한 코드를 저장합니다. 이 인프라에는 GKE와 같은 네트워킹 및 컨테이너 조정 플랫폼이 포함될 수 있습니다. 일반적으로 인프라 관리자가 이러한 저장소를 소유합니다. 운영자는 이를 업데이트하여 권장사항을 구현할 수 있습니다.
애플리케이션 저장소에 저장할 수 있는 아티팩트 예시는 다음과 같습니다.
- 인프라 객체를 나타내는 선언적 언어 코드(Terraform, Pulumi).
선언적 API 정의를 보완하는 셸 또는 Python 스크립트.
인프라팀에서 만든 기본 인프라 템플릿에 대한 확장 또는 수정.
구성 및 정책 저장소
운영자 및 보안 엔지니어 모두 플랫폼의 보안이 향상되었고 일관적인지 확인하는 것이 최우선 과제입니다.
구성
중앙 집중식 구성을 사용하면 시스템 전반에 걸쳐 구성 변경사항을 전파할 수 있습니다. 중앙에서 관리할 수 있는 일반적인 구성 항목은 다음과 같습니다.
Kubernetes 네임스페이스
할당량
역할 기반 액세스 제어(RBAC)
네트워크 정책
애플리케이션팀이 인프라를 오용 또는 남용하지 않도록 클러스터 전체에서 이 유형의 구성을 일관적으로 적용해야 합니다. 구성 저장을 위해 Git 저장소를 사용하면 GitOps와 같은 방법을 통해 감사 및 배포 구성과 같은 프로세스를 향상시킬 수 있습니다. 구성 동기화와 같은 도구는 인프라 전반에 걸쳐 구성을 일정하게 적용하는 프로세스를 단순화하는 데 도움이 됩니다.
정책
개발자는 운영자가 만드는 기본 구성을 확장할 수 있기 때문에 플랫폼을 구성하는 클러스터에서 만드는 리소스를 제한할 수 있는 방법이 필요합니다. 일부 경우에는 외부 부하 분산을 위해 구성할 수 없는 Kubernetes 서비스 객체를 만드는 것과 같이 특정 요구사항을 충족할 경우에만 개발자가 리소스를 만들 수 있게 해주는 정책을 만들 수 있습니다.
연결된 참조 아키텍처에서 정책 컨트롤러를 사용하여 정책을 시행합니다.
시작 조건 저장소
시작 조건 저장소는 플랫폼 전반의 CI/CD 인프라 및 개발 권장사항 채택을 도와줍니다. 시작 조건 저장소는 권장사항 채택과 관련된 비용을 크게 줄여줄 수 있습니다. 권장사항은 기능 속도, 안정성, 팀 생산성을 향상시키는 데 도움이 됩니다. 연결된 참조 아키텍처에는 CI, CD, Kubernetes 구성, Go, 자바, Python 시작 조건 애플리케이션 및 인프라에 대한 여러 시작 조건 저장소가 있습니다.
지속적 통합
조직에는 일반적으로 CI 중 애플리케이션에 적용되는 표준 태스크 집합이 있습니다. 예를 들어 참조 구현에서 CI 단계의 기본 집합에는 코드 컴파일 및 컨테이너 이미지 빌드가 포함됩니다. 이러한 단계는 시작 조건 저장소에 정의되기 때문에 플랫폼 전체에 걸쳐 동일하게 적용됩니다. 개별 애플리케이션 팀은 단계를 더 추가할 수 있습니다.
지속적 배포
CI와 비슷하게, CD 프로세스에는 일반적으로 개발, 사전 프로덕션 및 프로덕션 환경 전체에 애플리케이션을 배포하기 위한 표준 단계 집합이 있습니다. 사용된 배포 방법론에 관계없이 시작 조건 저장소를 통해 플랫폼팀은 이러한 방법론을 애플리케이션 및 환경 전체에 동일하게 적용할 수 있습니다. 참조 구현에서 배포 프로세스에는 개발, 사전 프로덕션 배포의 출시, 여러 클러스터 간 프로덕션 배포, Cloud Deploy를 사용한 프로덕션 배포 수동 승인이 포함됩니다.
애플리케이션 구성
소프트웨어 제공 플랫폼을 사용할 수 있으려면 애플리케이션 구성을 적용할 수 있는 동일하고 일관적인 방법이 필요합니다. 플랫폼은 kustomize와 같은 도구 및 Kubernetes 구성에 대한 시작 조건 저장소를 사용하여 애플리케이션 구성에 대해 일관적인 기준을 제공할 수 있습니다. 예를 들어 참조 구현에서 kustomize 기본 구성은 잘 알려진 기본 구성 집합을 사용하여 애플리케이션 환경 저장소를 초기화합니다. 그런 후 개별 애플리케이션 팀이 자신의 요구에 맞게 구성을 채택할 수 있습니다.
시작 조건 애플리케이션
시작 조건 애플리케이션은 관측 가능성 및 컨테이너 권장사항과 같이 권장사항 채택과 관련된 오버헤드를 줄이는 데 도움을 줍니다.
관측 가능성. 애플리케이션을 효율적으로 운영하고 안정성을 보장하기 위해 애플리케이션은 로깅, 측정항목, 추적을 고려해야 합니다. 시작 조건 애플리케이션은 팀이 관측 가능성에 도움이 되는 프레임워크 및 전략을 빌드할 수 있게 해줍니다.
컨테이너 권장사항. 컨테이너화된 애플리케이션을 빌드할 때는 작고 깨끗한 컨테이너 이미지를 빌드해야 합니다. 컨테이너 권장사항에는 이미지에 단일 애플리케이션 패키징, 이미지에서 불필요한 도구 삭제, 최소 기본 이미지로부터 작은 이미지 생성 시도가 포함됩니다. 자세한 내용은 컨테이너 빌드 권장사항을 참조하세요.
참조 아키텍처는 시작점으로 기본 Go 앱, 기본 자바 앱, 기본 Python 앱을 제공합니다. 해당 팀에서 개발하는 애플리케이션 유형, 기술 스택, 언어에 맞게 맞춤설정된 시작 조건 애플리케이션을 추가해야 합니다.
인프라 시작 조건 저장소
인프라 시작 조건 저장소에는 여러 인프라 구성요소를 만드는 데 필요한 사전 작성된 코드가 제공됩니다. 이러한 저장소에는 인프라 팀에서 결정된 대로 표준 템플릿과 모듈이 사용됩니다.
예를 들어 참조 구현에서 platform-template에는 Google Cloud 프로젝트, 가상 프라이빗 클라우드, GKE 클러스터를 빌드하기 위한 시작 코드가 포함되어 있습니다. 이 템플릿은 여러 애플리케이션팀에서 사용되는 인프라를 공유 리소스로 관리하기 위해 일반적으로 인프라팀에서 사용됩니다. 마찬가지로 infra-template에는 Cloud Storage 또는 Spanner 데이터베이스와 같이 애플리케이션에 필요할 수 있는 기본적인 시작 인프라 코드가 포함되어 있습니다. 이 템플릿은 일반적으로 애플리케이션팀에서 자신의 애플리케이션 인프라 관리를 위해 사용됩니다.
공유 템플릿 저장소
공유 템플릿 저장소는 조직의 모든 사용자가 재사용할 수 있는 표준 작업 템플릿을 제공합니다. 예를 들어 네트워크 및 컴퓨팅과 같은 인프라 리소스를 만드는 데 사용할 수 있는 Terraform 모듈과 같은 코드 모듈로서의 인프라가 있습니다.
애플리케이션 랜딩 영역
클러스터 간에 공유 CI/CD, 공유 애플리케이션 구성, 일관적인 정책 및 구성을 사용할 때는 이러한 기능을 하나로 묶어서 애플리케이션 랜딩 영역을 만들 수 있습니다.
랜딩 영역은 개발자가 자신의 애플리케이션을 배포하고 반복할 수 있게 해주는 고정된 논리 항목입니다. 애플리케이션 랜딩 영역에는 개발자가 자율적으로 운영할 수 있도록 배치된 가드 레일이 사용됩니다. 각 애플리케이션에 대해 각 환경의 각 클러스터에 Kubernetes 네임스페이스를 만듭니다(예: 프로덕션, 개발, 스테이징). 이러한 일관성은 시간이 지나더라도 운영자가 환경을 디버깅하고 유지관리하는 데 도움이 됩니다.
다음 다이어그램은 랜딩 영역의 개념을 보여줍니다.
운영 모델
최신 CI/CD로 소프트웨어 제공 플랫폼을 운영할 때는 환경, 인프라, 프로세스를 일관적이고 최신 상태로 유지하는 것이 중요합니다. 따라서 플랫폼의 운영 모델을 신중하게 계획하고 선택해야 합니다. 서비스로서의 클러스터, 청사진, 멀티 테넌트 인프라와 같은 여러 모델 중에서 선택할 수 있습니다.
인프라를 일관적으로 유지하고, 확산을 제한하고, 팀이 애플리케이션 제공에 집중할 수 있도록 지원하는 것이 중요하기 때문에 멀티 테넌트 인프라를 배포하는 것이 좋습니다. 멀티 테넌트 인프라로 애플리케이션을 배포하면 애플리케이션 팀이 인프라를 관리할 필요가 없으며, 운영팀 및 보안팀이 인프라를 일관적으로 유지하는 데 집중할 수 있습니다.
멀티 테넌트 인프라 고려사항
멀티 테넌트 소프트웨어 제공 플랫폼을 빌드할 때는 플랫폼에 빌드할 몇 가지 요소들을 고려해야 합니다.
워크로드 격리. 애플리케이션 랜딩 영역의 개념은 워크로드 격리를 위한 프레임워크를 제공하는 것입니다. 랜딩 영역은 네임스페이스, 네트워크 정책, RBAC가 결합된 형태입니다. 모든 정책은 구성 동기화 전반에 걸쳐 중앙에서 관리 및 적용되어야 합니다.
테넌트 사용량 모니터링. 클러스터의 개별 네임스페이스 및 라벨로 비용을 세분화하기 위해서는 GKE 사용량 측정을 사용할 수 있습니다. GKE 사용량 측정은 클러스터 워크로드에 대한 리소스 요청 및 리소스 사용량 정보를 추적합니다. 이를 네임스페이스 및 라벨로 더 필터링할 수 있습니다. 멀티 테넌트 클러스터에서 GKE 사용량 측정을 사용 설정하면 리소스 사용량이 BigQuery 테이블에 기록됩니다. 테넌트별 측정항목을 해당하는 테넌트 프로젝트의 BigQuery 데이터 세트로 내보내면, 감사관이 해당 측정항목을 분석하여 비용 분석을 결정할 수 있습니다.
리소스 할당량. 클러스터를 공유하는 모든 테넌트가 클러스터 리소스에 공평하게 액세스하도록 하려면 리소스 할당량을 적용해야 합니다. 각 테넌트가 배포하는 Pod 수, 각 Pod에 필요한 메모리량 및 CPU를 기준으로 각 네임스페이스에 대해 리소스 할당량을 만듭니다.
각 환경에 대한 여러 클러스터. 애플리케이션 및 플랫폼 안정성을 향상시키기 위해서는 각 사전 프로덕션 및 프로덕션 환경에 대해 여러 클러스터를 사용해야 합니다. 여러 클러스터를 사용할 수 있으면 애플리케이션을 개별적으로 클러스터로 출시하여 카나리아 검증 수준을 추가할 수 있습니다. 또한 여러 클러스터를 사용함으로써 클러스터 관리 및 업그레이드 수명주기와 관련된 문제를 완화할 수 있습니다.
테넌트별 로깅 및 모니터링. 해당 애플리케이션의 운영을 조사하기 위해서는 테넌트가 로그 및 측정항목에 액세스할 수 있어야 합니다. 멀티 테넌트 환경에서 로깅 및 모니터링은 애플리케이션별로 적용됩니다. 측정항목 및 모니터링의 경우 각 네임스페이스에 대해 Google Cloud Managed Service for Prometheus와 Grafana를 사용할 수 있습니다. 로그의 경우 BigQuery로 로그 항목을 내보낼 수 있도록 싱크를 만들고, 테넌트 네임스페이스로 데이터 세트를 필터링해야 합니다. 그러면 테넌트가 BigQuery에서 내보낸 데이터에 액세스할 수 있습니다.
멀티 테넌트 인프라에 대한 자세한 내용은 엔터프라이즈 멀티테넌시 권장사항을 참조하세요.
격리 경계
소프트웨어 제공 플랫폼이 여러 팀에서 빌드 및 사용되므로 플랫폼의 다양한 구성요소 간에 적절한 격리 경계를 유지하는 것이 중요합니다. 격리 경계는 다음 특성을 제공하여 강력한 플랫폼을 빌드하는 데 도움이 됩니다.
책임 분리. 각 팀은 나머지 부분에 대한 걱정 없이 격리 경계에서 리소스를 관리합니다. 예를 들어 인프라팀은 GKE 클러스터 유지보수만 담당합니다. 운영자 또는 개발자는 CI/CD 파이프라인 및 애플리케이션 코드 유지보수만 담당합니다.
세분화된 액세스 제어. 격리 경계로 리소스가 분리된 경우 세분화된 액세스 제어를 사용해서 액세스를 제한합니다.
영향을 받는 영역 축소. 다른 구성요소에 영향을 주지 않고 구성요소를 독립적으로 변경할 수 있습니다.
수동 오류 감소. 액세스 제어가 세분화되어 있으므로 개발 환경에서 프로덕션 클러스터에 실수로 배포하는 것과 같은 수동 오류를 방지할 수 있습니다.
이러한 격리 경계는 서로 다른 애플리케이션, 인프라 및 애플리케이션 간에 존재하거나 애플리케이션의 서로 다른 환경 간에도 존재할 수 있습니다.
거버넌스
소프트웨어 제공 플랫폼 및 최신 CI/CD 시스템의 기본 목적은 전체 소프트웨어 제공 프로세스의 효율성을 향상시켜 주는 것입니다. 플랫폼 관리 측면에서는 주로 두 가지 고려사항이 있습니다. 하나는 일반적으로 거버넌스 카테고리에 포함되는 애플리케이션 온보딩이고, 다른 하나는 플랫폼에 대한 상시 개발 및 유지보수입니다(즉, 플랫폼을 제품처럼 취급).
애플리케이션 온보딩 및 관리
최신 CI/CD 방법론 및 도구를 채택하는 목적은 출시 프로세스 및 새 서비스 온보딩을 효율화하기 위한 것입니다. 새 애플리케이션 온보딩은 운영팀 및 보안팀의 최소한의 관여만으로 수행할 수 있는 직관적인 프로세스입니다. 즉, 운영팀과 보안팀이 관여하지 않는 것은 아니지만, 배포 및 보안 관점에서 초기 입력 작업이 프로비저닝 프로세스를 통해 자동으로 처리됩니다. 온보딩 다음에는 운영팀 및 보안팀이 병합 요청, 정책 업데이트, 권장사항 적용 전반의 출시 프로세스에 자연스럽게 포함됩니다.
새 애플리케이션을 온보딩하려면 일부 자동화를 생성하는 것이 좋습니다. 여기에는 코드 저장소, CI/CD 파이프라인, 시작 영역, 애플리케이션에 필요한 인프라 생성이 포함될 수 있습니다. 자동화는 복잡한 조직 내에서 개발팀이 다른 팀에 의존하지 않게 하고 개발자들이 애플리케이션을 셀프서비스할 수 있는 자율성을 제공합니다. 이에 따라 개발자는 애플리케이션 코드 반복을 매우 빠르게 시작할 수 있으며, 코드 작성 이외의 작업을 수행하는 데 시간을 낭비할 필요가 없습니다. 개발자는 자동화를 통해 개발 환경에서 애플리케이션을 실행할 수 있어야 합니다. 애플리케이션을 상위 환경으로 가져가려면 다른 팀이 참여하고 검토 프로세스를 따라야 합니다.
연결된 참조 아키텍처에서는 이 자동화를 애플리케이션 팩토리라고 부릅니다.
제품으로서의 플랫폼
CI/CD 워크플로는 소프트웨어 제품이며, 제품 사용자가 개발팀, 운영팀, 보안팀이라는 것만 다릅니다. 따라서 제품 소유자, 마케팅(내부 대면), 사용자 피드백 루프, 기능 개발 주기와 같은 동일한 소프트웨어 개발 역할 및 프로세스가 플랫폼에 필요합니다.
GKE를 사용한 CI/CD 배포
GKE를 사용하여 조직에 최신 CI/CD 배포를 시작할 때는 최적의 파일럿 애플리케이션을 선택하는 것이 핵심입니다. 개발팀, 운영팀, 보안팀은 또한 이 섹션에 설명된 대로 작업을 수행하면서 다른 요소들을 고려해야 합니다.
파일럿 애플리케이션 선택
플랫폼으로 이동하기 위해 첫 번째 애플리케이션을 선택하는 것은 어려운 첫 단계일 수 있습니다. 적합한 파일럿 후보는 캐싱 레이어, 웹 프런트엔드, 이벤트 기반 처리 애플리케이션과 같이 데이터를 처리하거나 요청을 처리하지만 데이터를 저장하지 않는 서비스입니다. 일반적으로 이러한 애플리케이션은 새 배포 및 구성 관리 기법을 사용하여 작업할 때 언제든지 발생할 수 있는 약간의 다운타임 및 배포 오류에 대해 내성이 더 높습니다. 팀의 CI/CD 경험이 늘고 안정성 및 속도 측면에서 이점을 활용할 수 있게 되면 소프트웨어 제공 플랫폼으로 코어 서비스 이동을 시작할 수 있습니다.
개발자 고려사항
최신 CI/CD 개발 프로세스로 작업할 때 기능, 변경사항 및 배포는 발생하는 빈도가 늘고 좀 더 비동기적으로 수행될 수 있습니다. 개발팀은 변경사항이 다운스트림 또는 종속 시스템에 미치는 영향을 확인하고 이러한 변경사항의 테스트 방법을 찾아내야 합니다. 개발팀, 운영팀, 보안팀 사이의 통신 경로가 유연해야 합니다. 서로 다른 서비스에 사용되는 애플리케이션 및 데이터 계약 모두에 대해 더 나은 버전 관리 방식에 투자하는 것이 좋습니다. 통신 방법 및 버전 관리 개선과 함께 작은 부분에서의 기능 구현과 기능 분기 및 플래그 활용을 통해 기능 테스트 및 출시 방법을 향상시킬 수 있습니다.
운영자 고려사항
소프트웨어 제공 플랫폼에서 운영팀은 보다 개발팀과 같은 기능을 수행할 필요가 있습니다. 외부 대면 기능을 빌드하는 대신 외부 대면 애플리케이션의 개발, 배포, 운영에 도움이 되는 내부 도구 및 프로세스를 빌드해야 합니다. 플랫폼 도구는 개발팀과 보안팀은 물론 자체 팀에서도 사용됩니다. 운영자는 새로운 애플리케이션 버전 출시와 애플리케이션 오류 또는 배포 실패 시 이를 다시 롤백하는 데 도움이 되는 도구를 빌드해야 합니다. 운영자는 또한 오류 및 알림을 사전적으로 감지할 수 있도록 모니터링 및 알림 시스템을 빌드하는 데 더 주력해야 합니다.
보안팀 고려사항
보안팀은 보안 업무를 보안팀 내부는 물론 운영팀과 개발팀 간의 공유 책임 영역으로 만들기 위해 노력해야 합니다. 일반적으로 이러한 패턴을 보안에 관한 Shifting Left(개발 초기부터 고려)라고 부릅니다. 여기에서 정보 보안(InfoSec)은 개발 프로세스의 초기 단계부터 관여되며, 개발자가 사전 승인된 도구로 작업하고 보안 테스트가 자동화됩니다. 이러한 기법 외에도 정책 컨트롤러를 사용하여 보안 정책을 프로그래매틱 방식으로 정의하고 적용할 수 있습니다. 이러한 기법 및 도구를 결합하여 보다 사전적인 방식으로 보안을 강화할 수 있습니다.
다음 단계
ID 제휴 설정 권장사항 자세히 알아보기
하이브리드 및 멀티 클라우드 모니터링과 로깅 패턴에 대해 알아봅니다.