애플리케이션 배포 및 테스트 전략

Last reviewed 2023-07-20 UTC

이 문서에서는 일반적으로 사용되는 애플리케이션 배포 및 테스트 패턴에 대한 개요를 설명하며, 패턴의 작동 방식, 패턴의 이점, 패턴 구현 시 고려해야 할 사항을 살펴봅니다.

실행 중인 애플리케이션을 새 버전으로 업그레이드한다고 가정해 보겠습니다. 원활하게 출시하려면 다음을 고려해 보세요.

• 애플리케이션 다운타임을 최소화하는 방법(있는 경우)
• 사용자에게 미치는 영향을 최소화하면서 이슈를 관리하고 해결하는 방법
• 실패한 배포를 안정적이고 효과적인 방식으로 해결하는 방법
• 예측 가능하고 반복적으로 배포할 수 있도록 사용자를 최소화하고 오류를 처리하는 방법

배포 패턴은 주로 비즈니스 목표에 따라 달라집니다. 예를 들어 다운타임 없이 변경사항을 출시하거나, 기능을 일반적으로 사용할 수 있도록 하기 전에 환경 또는 일부 사용자에 대한 변경사항을 출시해야 할 수도 있습니다. 이 문서에서 설명하는 각 방법론은 배포가 성공으로 간주되기 전에 충족해야 하는 특정 목표를 설명합니다.

이 문서는 다양한 애플리케이션, 시스템, 프레임워크에 대한 출시 및 배포 전략을 정의하고 구현하는 시스템 관리자 및 DevOps 엔지니어를 대상으로 합니다.

배포 전략

서비스를 배포할 때 항상 사용자에게 즉시 노출되는 것은 아닙니다. 서비스가 출시된 후에만 사용자에게 애플리케이션의 변경사항이 표시되기도 합니다. 그러나 서비스가 인플레이스 출시되면 배포와 출시가 동시에 발생합니다. 이 경우 새 버전을 배포하면 프로덕션 트래픽이 허용되기 시작합니다. 또는 여러 서비스 버전을 동시에 프로비저닝하기 위한 배포 전략이 있습니다. 이러한 배포 패턴을 사용하면 들어오는 요청을 수신하는 버전을 제어하고 관리할 수 있습니다. 배포, 출시, 관련 개념에 대한 자세한 내용은 Kubernetes와 지속적 소프트웨어 제공 도전과제를 읽어보세요.

이 섹션에서 설명하는 배포 패턴을 통해 새 소프트웨어 출시를 유연하게 자동화할 수 있습니다. 가장 적합한 방법은 목표에 따라 다릅니다.

배포 패턴 재생성

배포를 재생성하면 새 애플리케이션 버전을 수직 확장하기 전에 기존 애플리케이션 버전을 완전히 축소할 수 있습니다.

다음 다이어그램은 애플리케이션에 대한 배포 재생성의 작동 방식을 보여줍니다.

버전 1은 현재 애플리케이션 버전을 나타내며, 버전 2는 새 애플리케이션 버전을 나타냅니다. 현재 애플리케이션 버전을 업데이트하는 경우 먼저 버전 1의 기존 복제본을 0으로 축소한 뒤 복제본을 새 버전과 동시에 배포합니다.

주요 이점

재생성 방법의 이점은 단순성입니다. 두 개 이상의 애플리케이션 버전을 동시에 관리할 필요가 없으므로 데이터 및 애플리케이션에 대한 이전 버전과의 호환성 도전과제를 방지할 수 있습니다.

고려사항

재생성 메서드는 업데이트 프로세스 중에 다운타임이 발생합니다. 다운타임은 유지보수 기간 또는 중단을 처리할 수 있는 애플리케이션의 문제가 아닙니다. 그러나 서비스수준계약(SLA) 및 가용성 요구사항이 높은 미션 크리티컬 애플리케이션이 있는 경우 다른 배포 전략을 선택할 수도 있습니다.

순차적 업데이트 배포 패턴

순차적 업데이트 배포에서는 다음 다이어그램과 같이 모든 애플리케이션 인스턴스를 동시에 업데이트하는 대신 실행 중인 애플리케이션 인스턴스의 하위 집합을 업데이트합니다.

이 배포 방식에서는 동시에 업데이트하는 인스턴스 수를 창 크기라고 합니다. 위 다이어그램에서 순차적 업데이트의 창 크기는 1입니다. 한 번에 하나의 애플리케이션 인스턴스가 업데이트됩니다. 큰 클러스터가 있는 경우 창 크기를 늘릴 수도 있습니다.

순차적 업데이트를 사용하면 애플리케이션을 유연하게 업데이트할 수 있습니다.

• 이전 버전을 축소하기 전에 새 버전으로 애플리케이션 인스턴스를 수직 확장할 수 있습니다(일시 급증 업그레이드 프로세스라고도 함).
• 새 인스턴스를 동시에 수직 확장하는 동안 사용할 수 없는 최대 애플리케이션 인스턴스 수를 지정할 수 있습니다.

주요 이점

• 다운타임 없음. 창 크기에 따라 배포 대상을 점진적으로 업데이트합니다(예: 하나씩 또는 2개씩). 애플리케이션의 새 버전이 트래픽을 수락할 준비가 된 후에만 트래픽을 업데이트된 배포 대상으로 전달합니다.
• 배포 위험 감소. 업데이트를 점진적으로 출시하면 새 버전의 불안정성이 일부 사용자에게만 영향을 미칩니다.

고려사항

• 느린 롤백. 새 출시가 안정적이지 않는 경우 새 복제본을 종료하고 이전 버전을 재배포할 수 있습니다. 그러나 출시와 마찬가지로 롤백은 점진적인 프로세스입니다.
• 이전 버전과의 호환성. 새 코드와 이전 코드가 나란히 표시되어 있으므로 사용자가 임의로 버전 중 하나로 라우팅될 수 있습니다. 따라서 새 배포가 이전 버전과 호환되는지 확인합니다. 즉, 새 애플리케이션 버전은 이전 버전이 저장하는 데이터를 읽고 처리할 수 있습니다. 이 데이터에는 디스크, 데이터베이스에 또는 사용자 브라우저 세션의 일환으로 저장된 데이터가 포함될 수 있습니다.
• 고정 세션. 애플리케이션에 세션 지속성이 필요한 경우 부하 분산기가 고정 및 연결 드레이닝을 지원하는 것이 좋습니다. 또한 세션이 기본 리소스에서 분리될 수 있도록 가능하면 세션 복제나 Datastore를 이용한 세션 관리를 통해 세션 공유를 호출하는 것이 좋습니다.

블루/그린 배포 패턴

다음 다이어그램과 같이 블루/그린 배포(레드/블랙 배포라고도 함)에서는 애플리케이션의 동일한 배포를 두 번 수행합니다.

다이어그램에서 블루는 현재 애플리케이션 버전을, 그린은 새 애플리케이션 버전을 나타냅니다. 한 번에 하나의 버전만 게시되며, 그린 배포가 생성되고 테스트되는 동안 트래픽이 블루 배포로 라우팅됩니다. 테스트를 완료하면 트래픽을 새 버전으로 라우팅합니다.

배포에 성공하면 가능한 롤백에 대한 블루 배포를 유지하거나 사용 중지할 수 있습니다. 또는 이러한 인스턴스에 애플리케이션의 최신 버전을 배포할 수 있습니다. 이 경우 현재(블루) 환경은 다음 출시의 스테이징 영역으로 제공됩니다.

주요 이점

• 제로 다운타임. 블루/그린 배포를 사용하면 다운타임 없이 신속하게 컷오버할 수 있습니다.
• 즉시 롤백. 부하 분산기를 조정하여 트래픽을 다시 블루 환경으로 전달함으로써 배포 프로세스 중 언제든지 롤백할 수 있습니다. 다운타임의 영향은 문제를 감지한 후 트래픽을 블루 환경으로 전환하는 데 걸리는 시간으로 제한됩니다.
• 환경 분리. 블루/그린 배포는 동시 그린 환경을 가동해도 블루 환경을 지원하는 리소스에 영향을 미치지 않도록 합니다. 환경을 분리하면 배포 위험이 줄어듭니다.

고려사항

• 비용 및 운영 오버헤드. 인프라가 동일한 중복 환경을 유지해야 하기 때문에 블루/그린 배포 패턴을 채택하면 운영 오버헤드와 비용이 증가할 수 있습니다.
• 이전 버전과의 호환성. 블루 및 그린 배포는 데이터 포인트 및 Datastore를 공유할 수 있습니다. 두 애플리케이션 버전이 Datastore의 스키마와 레코드 형식을 사용할 수 있는지 확인하는 것이 좋습니다. 이전 버전과의 호환성은 원할하게 두 버전 간에 전환하려는 경우에 필요합니다.
• 컷오버. 현재 버전을 사용 중지하려는 경우 기존 트랜잭션 및 세션에서 적절한 연결 드레이닝을 허용하는 것이 좋습니다. 이 단계를 통해 현재 배포에서 처리된 요청을 정상적으로 완료하거나 종료할 수 있습니다.

테스트 전략

이 섹션에서 설명하는 테스트 패턴은 일반적으로 동시 실행 및 부하의 현실적인 수준에서 합당한 기간 동안 서비스의 신뢰성과 안정성을 검증하는 데 사용됩니다.

카나리아 테스트 패턴

카나리아 테스트에서는 다음 다이어그램과 같이 변경사항을 부분적으로 출시한 후 기준 배포와 비교하여 성능을 평가합니다.

이 테스트 패턴에서는 프로덕션 버전과 함께 애플리케이션의 새 버전을 배포합니다. 그런 다음 프로덕션 버전에서 카나리아 버전으로 트래픽 비율을 분할하고 라우팅하여 카나리아의 성능을 평가합니다.

카나리아를 구성할 때 평가의 주요 측정항목을 선택합니다. 카나리아를 실시간 프로덕션 환경이 아닌 해당 기준과 비교하는 것이 좋습니다.

분석에 영향을 줄 수 있는 요소(예: 캐싱, 장기 연결, 해시 개체)를 줄이려면 애플리케이션의 기준 버전에 대해 다음 단계를 수행하는 것이 좋습니다.

• 애플리케이션의 기준 및 프로덕션 버전이 동일하도록 합니다.
• 카나리아를 배포하는 동시에 기준 버전을 배포합니다.
• 기준 배포(예: 애플리케이션 인스턴스 수 및 자동 확장 정책)가 카나리아 배포와 일치하도록 합니다.
• 기준 버전을 사용하여 카나리아와 동일한 트래픽을 제공합니다.

카나리아 테스트에서 부분 출시는 다양한 분할 전략을 따를 수 있습니다. 예를 들어 애플리케이션에 지리적으로 분산된 사용자가 있는 경우 먼저 새 버전을 리전 또는 특정 위치에 출시할 수 있습니다. 자세한 내용은 Spinnaker를 사용하여 GKE에서 카나리아 분석 자동화를 참조하세요.

주요 이점

• 실시간 프로덕션 트래픽을 테스트하는 기능. 스테이징 환경에서 시뮬레이션된 트래픽을 사용하여 애플리케이션을 테스트하는 대신 실시간 프로덕션 트래픽에서 카나리아 테스트를 실행할 수 있습니다. 카나리아 출시를 통해 새 애플리케이션을 출시할 시점과 출시의 다음 단계를 트리거할 시기를 결정해야 합니다. 모니터링하여 문제를 확실하게 감지할 수 있도록 카나리아에 충분한 트래픽이 있어야 합니다.
• 빠른 롤백. 사용자 트래픽을 애플리케이션의 이전 버전으로 리디렉션하여 빠르게 롤백할 수 있습니다.
• 제로 다운타임. 카나리아 릴리스를 사용하면 다운타임 없이 실시간 프로덕션 트래픽을 다른 버전의 애플리케이션으로 라우팅할 수 있습니다.

고려사항

• 느린 출시. 점진적 출시마다 적절한 기간 동안 모니터링이 필요하므로 전체 출시가 지연될 수 있습니다. 카나리아 테스트는 몇 시간이 걸리기도 합니다.
• 관측 가능성. 카나리아 테스트를 구현하기 위한 기본 요건은 인프라 및 애플리케이션 스택을 효과적으로 관찰하고 모니터링하는 것입니다. 강력한 모니터링을 구현하려면 상당한 노력이 필요할 수 있습니다.
• 이전 버전과의 호환성 및 고정 세션. 순차적 업데이트와 마찬가지로 카나리아가 배포되는 동안 여러 애플리케이션 버전이 환경에서 실행되므로 카나리아 테스트는 이전 버전과의 비호환성 및 세션 지속성의 위험을 초래할 수 있습니다.

A/B 테스트 패턴

A/B 테스트를 통해 변이 구현을 사용하여 가설을 테스트합니다. A/B 테스트는 데이터에서 파생된 결과를 기반으로 예측은 물론 비즈니스 결정을 내리는 데 사용됩니다.

A/B 테스트를 수행하는 경우 다음 다이어그램과 같이 라우팅 규칙에 따라 일부 사용자를 새 기능으로 라우팅합니다.

라우팅 규칙에는 브라우저 버전, 사용자 에이전트, 위치정보, 운영체제 등의 요소가 포함될 때도 있습니다. 버전을 측정하고 비교한 후에는 더 나은 결과를 얻은 버전으로 프로덕션 환경을 업데이트합니다.

주요 이점

A/B 테스트는 애플리케이션 기능의 효과를 측정하는 데 가장 적합합니다. 앞에서 설명한 배포 패턴의 사용 사례는 새 소프트웨어를 안전하게 출시하고 예측 가능하게 롤백하는 것에 중점을 둡니다. A/B 테스트에서는 새 기능의 대상을 제어하고 사용자 동작에서 통계적으로 유의미한 모든 차이점을 모니터링합니다.

고려사항

• 복잡한 설정. A/B 테스트에는 한 버전이 다른 버전보다 나은지 확인할 수 있는 대표 샘플이 필요합니다. 샘플 크기를 미리 계산(예: A/B 테스트 샘플 크기 계산기 사용)하고 통계적 유의성이 95% 이상이 되도록 적절한 기간 동안 테스트를 실행해야 합니다.
• 결과의 유효성. 거짓양성, 편향된 샘플링 또는 외부 요인(예: 시즌성 또는 마케팅 프로모션)을 비롯한 여러 요소가 테스트 결과를 왜곡시킬 수 있습니다.
• 관측 가능성. 중복 트래픽에 대해 여러 A/B 테스트를 실행하면 모니터링 및 문제해결 프로세스가 어려울 수 있습니다. 예를 들어 제품 페이지 A와 제품 페이지 B를 비교하거나 결제 페이지 C와 결제 페이지 D를 비교하면, 버전 간 트래픽 분할과 같은 측정항목을 결정하는 데 분산 추적이 중요해집니다.

섀도 테스트 패턴

카나리아 테스트와 같은 순차적 실험 기술은 테스트 초기 단계에서 고객을 열악한 애플리케이션 버전에 노출시킬 수 있습니다. 시뮬레이션과 같은 오프라인 기술을 사용하여 이 위험을 관리할 수 있습니다. 하지만 오프라인 기술은 새 버전과의 사용자 상호작용이 없으므로 애플리케이션의 개선사항을 검증하지는 않습니다.

섀도 테스트를 사용하면 다음 다이어그램과 같이 새 버전을 사용자로부터 숨기는 방식을 이용하여 새 버전을 현재 버전과 함께 배포하고 실행할 수 있습니다.

수신 요청은 테스트 환경에서 미러링되고 재실행됩니다. 이 프로세스는 이전에 캡처된 프로덕션 트래픽의 사본이 새로 배포된 서비스에 대해 재실행된 후에 실시간 또는 비동기적으로 발생할 수 있습니다.

섀도 테스트가 기존 프로덕션 환경 또는 사용자 상태를 변경할 수 있는 부작용을 트리거하지 않도록해야 합니다.

주요 이점

• 제로 프로덕션 영향. 트래픽이 중복되므로 섀도 데이터를 처리하는 서비스의 모든 버그는 프로덕션에 영향을 주지 않습니다.
• 프로덕션 부하를 사용하여 새 백엔드 기능 테스트. Diffy 등의 도구를 함께 사용하면 트래픽 섀도잉을 통해 실시간 프로덕션 트래픽과 비교하여 서비스의 동작을 측정할 수 있습니다. 이 기능을 사용하면 애플리케이션 버전 간의 오류, 예외, 성능, 결과 패리티를 테스트할 수 있습니다.
• 배포 위험 감소. 트래픽 섀도잉은 일반적으로 카나리아 테스트와 같은 다른 접근 방식과 결합됩니다. 트래픽 섀도잉을 사용하여 새 기능을 테스트한 후에는 시간이 지남에 따라 늘어나는 사용자 수에 맞춰 기능을 출시하여 사용자 환경을 테스트합니다. 애플리케이션이 안정성 및 성능 요구사항을 충족할 때까지 전체 출시가 발생하지 않습니다.

고려사항

• 부작용. 트래픽 섀도잉 기능을 사용하면 상태를 변경하거나 타사 서비스와 상호작용하는 서비스를 신중하게 처리해야 합니다. 예를 들어 장바구니 플랫폼의 결제 서비스를 섀도 테스트하려는 경우에는 고객이 주문에 대해 두 번 결제하면 됩니다. 원치 않는 변형이나 기타 위험성이 높은 상호작용을 야기할 수 있는 섀도 테스트를 방지하려면 타사 시스템 또는 Datastore 대신 Hoverly와 같은 가상화 도구나 스터브를 사용하는 것이 좋습니다.
• 비용 및 운영 오버헤드. 섀도 테스트는 설정하기가 상당히 복잡합니다. 또한 블루/그린 배포와 마찬가지로 섀도 배포는 두 환경을 동시에 실행하고 관리하도록 설정되어야 하기 때문에 비용과 운영에 영향을 미칩니다.

적절한 전략 선택

여러 방법으로 애플리케이션을 배포하고 출시할 수 있으며, 각 접근법에는 장단점이 있습니다. 최선의 선택은 비즈니스의 요구사항과 제약사항에 따르는 것입니다. 다음 사항을 고려하세요.

• 가장 중요한 고려사항은 무엇인가요? 예를 들어 다운타임이 허용되나요? 비용이 제한되나요? 팀이 복잡한 출시 및 롤백 설정을 수행할 수 있는 적절한 기술을 가지고 있나요?
• 철저한 테스트 제어 기능이 있나요? 아니면 프로덕션 트래픽에 대해 새 출시를 테스트하여 출시의 안정성을 확인하고 부정적인 영향을 제한하려 하나요?
• 특정 비즈니스 가설을 교차 확인하기 위해 사용자 풀 간에 기능을 테스트하려 하나요? 타겟팅된 사용자가 업데이트를 수락하는지 여부를 제어할 수 있나요? 예를 들어 휴대기기를 업데이트하려면 명시적인 사용자 작업이 필요하며 추가 권한이 필요할 수 있습니다.
• 사용자 환경의 마이크로서비스가 완전히 자율적인가요? 아니면 기존의 변경하기 어려운 애플리케이션과 함께 작동하는 마이크로서비스 스타일의 애플리케이션이 혼합되어 있나요? 자세한 내용은 하이브리드 및 멀티 클라우드 환경의 배포 패턴을 참조하세요.
• 새 출시가 스키마 변경사항을 포함하나요? 포함하는 경우 스키마 변경사항이 코드 변경사항에서 분리하기 너무 복잡하나요?

다음 표에서는 이 문서의 앞부분에서 설명한 배포 및 테스트 패턴의 핵심 특성을 요약합니다. 다양한 배포 및 테스트 방법의 장점과 단점을 고려할 때 비즈니스 요구사항과 기술 리소스를 고려한 다음 가장 유용한 옵션을 선택하세요.

배포 또는 테스트 패턴	제로 다운타임	실제 프로덕션 트래픽 테스트	조건에 따라 사용자에게 출시	롤백 기간	하드웨어 및 클라우드 비용에 미치는 영향
재생성 버전 1이 종료되고 버전 2가 출시되었습니다.	x	x	x	빠른지만 다운타임으로 인한 중단	추가 설정이 필요하지 않음
순차적 업데이트 버전 2가 단계적으로 출시되어 버전 1을 대체합니다.	✓	x	x	느림	일시 급증 업그레이드에 대한 추가 설정이 필요할 수 있음
블루/그린 버전 2가 버전 1과 함께 출시되었으며, 테스트가 완료된 후 트래픽이 버전 2로 전환되었습니다.	✓	x	x	즉시	블루 및 그린 환경을 동시에 유지해야 함
카나리아 버전 2가 일부 사용자에게 출시된 후 전체 출시가 진행됩니다.	✓	✓	x	빠름	추가 설정이 필요하지 않음
A/B 버전 2가 특정 조건에서 일부 사용자에게 출시되었습니다.	✓	✓	✓	빠름	추가 설정이 필요하지 않음
섀도 버전 2는 사용자 요청에 영향을 주지 않고 실제 트래픽을 수신합니다.	✓	✓	x	적용되지 않음	사용자 요청을 캡처하고 다시 실행하려면 병렬 환경을 유지해야 함

권장사항

배포를 유지하고 테스트 위험을 최소화하기 위해 애플리케이션팀은 다음과 같은 몇 가지 권장사항을 따를 수 있습니다.

• 이전 버전과의 호환성. 여러 애플리케이션 버전을 동시에 실행하는 경우 데이터베이스가 모든 활성 버전과 호환되는지 확인합니다. 예를 들어 새 출시에서는 데이터베이스의 스키마를 변경해야 합니다(예: 새 열). 이러한 시나리오에서는 이전 버전과의 호환되도록 데이터베이스 스키마를 변경해야 합니다. 전체 출시를 완료한 후 이전 스키마에 대한 지원을 삭제하여 최신 버전에 대한 지원만 남길 수 있습니다. 이전 버전과의 호환되도록 하는 방법 중 하나는 스키마 변경사항을 코드 변경사항에서 분리하는 것입니다. 자세한 내용은 동시 변경 및 데이터베이스 리팩토링 패턴을 참조하세요.
• 지속적 통합/지속적 배포(CI/CD). CI는 종속 항목 확인, 단위 및 통합 테스트, 빌드 프로세스를 통과한 후에만 기능 분기에 체크인된 코드가 기본 분기와 병합되도록 합니다. 따라서 애플리케이션의 모든 변경사항은 배포되기 전에 테스트됩니다. CD를 사용하면 CI로 빌드된 코드 아티팩트가 패키징되어 하나 이상의 환경에 배포될 수 있습니다. 자세한 내용은 Google Cloud로 CI/CD 파이프라인 빌드를 참조하세요.
• 자동화. 사용자에게 애플리케이션 업데이트를 지속적으로 제공하는 경우 소프트웨어를 안정적으로 빌드하고, 테스트하고, 배포하는 자동화된 프로세스를 빌드하는 것이 좋습니다. 또한 코드 변경사항이 아티팩트 생성, 단위 테스트, 기능 테스트, 프로덕션 출시를 포함하는 CI/CD 파이프라인을 자동으로 거쳐가는 것이 좋습니다. Cloud Build, Cloud Deploy, Spinnaker 및 Jenkins와 같은 자동화 도구를 사용하면 보다 효율적이고 안정적이며 예측 가능한 배포 프로세스를 자동화할 수 있습니다.
• IaC 및 GitOps. 복잡한 배포 및 테스트 전략을 관리해야 하는 경우 코드형 인프라(IaC) 및 GitOps 도구를 사용하는 것이 좋습니다. Terraform 및 구성 커넥터와 함께 IaC를 사용하면 선언적 언어를 사용하여 인프라 및 전략을 정의하는 데 도움이 될 수 있습니다. 구성 동기화 및 Argo CD와 함께 GitOps를 사용하면 git으로 코드를 관리하는 데 도움이 됩니다.
• 롤백 전략. 문제가 발생할 때도 있습니다. 예기치 않은 상황이 발생할 때 따라야 하는 롤백 전략을 만드는 것이 좋습니다. 안정적인 롤백 전략을 수립하면 관리자와 DevOps 엔지니어가 위험을 관리하는 데 도움이 될 수 있습니다. App Engine 및 Cloud Run와 같은 기본 제공되는 기능으로 롤백을 지원하는 플랫폼을 사용하여 롤백 전략을 만들 수 있습니다. 롤백 요구사항을 지원하려면 Cloud Deploy, Spinnaker 및 Argo RollOuts와 같은 출시 자동화 도구를 사용할 수도 있습니다.
• 배포 후 모니터링. 중요한 측정항목을 모니터링하고 배포나 테스트가 실패할 때 담당 팀에 알리려면 Google Cloud Observability를 사용하여 모니터링 시스템을 빌드합니다. 상태 점검에 실패한 배포에 자동 롤백을 사용 설정할 수도 있습니다. Error Reporting, Cloud Trace 및 Cloud Profiler를 사용하면 단순하거나 복잡한 배포 후 문제의 원인을 찾는 데 도움이 될 수 있습니다.

다음 단계

• Kubernetes와 지속적인 소프트웨어 제공 도전과제에서 이 문서의 개념을 읽어보세요.
• Google Cloud의 DevOps 다른 솔루션에 대해 자세히 알아보세요.
• 컨테이너 실행을 위한 권장사항에 대해 자세히 알아보세요.
• GKE의 지속적 통합 및 제공에 대해 자세히 알아보세요.
• 안정적인 출시 및 롤백을 위한 CRE 주기 강의에 대해 자세히 알아보세요.
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기