청사진 배포

CI/CD 파이프라인이 이미 있습니다.

애플리케이션 빌드 및 배포에 다른 제품이 사용된 경우에도 청사진의 Fleet 및 클러스터 아키텍처를 사용할 수 있습니다. 최소한 2개의 리전에 이미지를 미러링하는 것이 좋습니다.

기존 조직 구조가 엔터프라이즈 기반 청사진과 일치하지 않습니다.

보다 안전한 순차적 배포를 위해 최소 2개 이상의 환경이 권장됩니다. 개별 공유 VPC 또는 폴더에 환경을 배포할 필요는 없습니다. 그러나 다른 환경에 속하는 워크로드를 동일한 클러스터에 배포하지 마세요.

IaC를 사용하지 않습니다.

현재 애플리케이션 배포 프로세스에 IaC가 사용되지 않는 경우 Google Cloud 성숙도 모델 기반 Terraform을 사용하여 준비 상태를 평가할 수 있습니다. 멀티 테넌트 및 테넌트별 파이프라인이 구분된 이 청사진과 비슷하게 구성된 다른 Terraform 프로젝트에 기존 리소스를 가져옵니다. 새 클러스터를 만들려면 Google Cloud용 Terraform 모듈을 사용하면 됩니다.

클러스터는 동일한 환경 내의 여러 프로젝트에 분산됩니다.

여러 프로젝트의 클러스터를 Fleet로 그룹화할 수 있습니다. 동일한 Fleet 내에서 네임스페이스가 고유한 의미를 갖는지 확인합니다. Fleet에 클러스터를 추가하기 전 예를 들어 default가 아닌 고유한 이름의 네임스페이스로 애플리케이션을 이동하도록 팀에 요청합니다.

그런 후 네임스페이스를 범위로 그룹화할 수 있습니다.

클러스터가 단일 리전에 있습니다.

청사진을 채택하기 위해 프로덕션 및 비프로덕션에서 여러 리전을 사용할 필요가 없습니다.

여러 다른 환경 집합이 존재합니다.

환경을 3개 정도까지 지원하도록 청사진을 수정할 수 있습니다.

클러스터 만들기는 애플리케이션 개발자팀 또는 애플리케이션 운영자팀에 위임됩니다.

가장 안전하고 일관적인 개발자 플랫폼을 위해서는 애플리케이션팀에서 개발자 플랫폼팀으로 클러스터 소유권을 이동하도록 시도할 수 있습니다. 이것이 불가능한 경우라도 여전히 많은 청사진 운영 방식을 채택할 수 있습니다. 예를 들어 여러 애플리케이션팀이 소유하는 클러스터를 Fleet에 추가할 수 있습니다. 하지만 클러스터를 독립된 소유권과 결합할 때는 GKE용 워크로드 아이덴티티 제휴 또는 Cloud Service Mesh를 사용하지 마세요. 누가 어떤 워크로드 아이덴티티를 어설션할 수 있는지 충분히 제어할 수 없기 때문입니다. 대신 커스텀 조직 정책을 사용해서 팀이 GKE 클러스터에서 이러한 기능을 사용 설정하지 못하도록 방지합니다.

클러스터가 Fleet로 그룹화된 경우에도 여전히 정책을 감사하고 적용할 수 있습니다. 커스텀 조직 정책을 사용해서 클러스터 프로젝트가 있는 환경 폴더에 해당하는 Fleet 내에 클러스터가 생성되도록 할 수 있습니다. Fleet 기본 구성을 사용해서 새 클러스터에 정책 제어가 사용되도록 요구할 수 있습니다.

모든 애플리케이션이 동일한 5개 클러스터 집합에서 실행됩니다.

청사진에는 5개의 클러스터 집합이 사용됩니다(프로덕션에 2개, 비프로덕션에 2개, 개발에 1개). 추가로 5개의 클러스터 집합을 만들도록 청사진을 수정할 수 있습니다.

5개의 클러스터 집합에 애플리케이션을 할당합니다. 애플리케이션의 범위 또는 Fleet 네임스페이스를 다른 집합의 클러스터에 바인딩하지 마세요. 다음과 같은 활동을 수행하기 위해 애플리케이션을 여러 다른 클러스터 집합으로 분리해야 할 수 있습니다.

• 특별한 규제 요구가 있는 몇 가지 애플리케이션을 하나로 그룹화합니다(예: PCI-DSS).
• 클러스터 업그레이드 중 특수 취급이 필요한 애플리케이션을 격리합니다(예: 영구 볼륨을 사용하는 스테이트풀(Stateful) 애플리케이션).
• 위험한 보안 프로필의 애플리케이션을 격리합니다(예: 메모리에 안전하지 않은 언어로 사용자 제공 콘텐츠 처리).
• GPU, 비용 민감도, 성능 민감도가 요구되는 애플리케이션을 격리합니다.
• 노드 수에 대한 GKE 클러스터 한도 (65,000개 노드)에 근접하는 경우 새 클러스터 집합을 만들 수 있습니다.
• VPC 서비스 제어 경계 내에서 실행되어야 하는 애플리케이션에 다른 공유 VPC를 사용합니다. 경계에 클러스터 집합을 하나 만들고 경계 외부에 클러스터 집합을 하나 만듭니다.

이렇게 하면 다음 상황 중 하나가 발생하기 때문에 모든 애플리케이션 또는 테넌트에 대해 클러스터 집합을 새로 만들지 않아도 됩니다.

• 사용 가능한 최소한의 인스턴스 유형으로도 애플리케이션이 최소 클러스터 크기(3개 VM x 2개 리전)를 사용하지 않습니다.
• 서로 다른 애플리케이션을 빈 패킹함으로서 비용 감소 가능성이 누락됩니다.
• 각 애플리케이션에 계획이 개별적으로 적용되기 때문에 용량 증가 계획의 불확실성 및 번거로움이 증가합니다. 용량 계획은 다양한 애플리케이션 집합에서 총합적으로 수행될 때 정확도가 향상됩니다.
• 신규 테넌트 또는 애플리케이션에 대해 새 클러스터를 만들 때 지연이 발생하여, 플랫폼에서의 테넌트 만족도가 저하됩니다. 예를 들어 일부 조직에서는 필요한 IP 주소를 할당하는 데 시간이 오래 걸리고 추가 승인이 필요할 수 있습니다.
• VPC 네트워크에서 비공개 클러스터 한도에 도달합니다.

프로덕션 및 비프로덕션 환경에 2개 리전의 클러스터가 포함됩니다.

여러 리전의 최종 사용자에 대한 지연 시간을 낮추기 위해서는 둘 이상의 리전에서 프로덕션 및 비프로덕션 워크로드를 배포할 수 있습니다(예: 프로덕션에 3개 리전, 비프로덕션에 3개 리전, 개발에 1개 리전 사용). 이 배포 전략을 사용하면 추가 리전에서 리소스를 유지보수하기 위해 비용과 오버헤드가 증가합니다.

모든 애플리케이션의 가용성 요구사항이 낮으면 프로덕션 및 비프로덕션 워크로드를 단 하나의 리전에 배포할 수 있습니다(예: 프로덕션 환경 1개, 비프로덕션 환경 1개, 개발 환경 1개). 이 전략은 비용 감소에 도움이 되지만 이중 리전 또는 멀티 리전 아키텍처와 동일한 수준으로 가용성을 보호하지 않습니다.

애플리케이션의 가용성 요구사항이 서로 다른 경우 여러 다른 애플리케이션에 대해 클러스터 집합을 서로 다르게 만들 수 있습니다(예: 2개의 프로덕션 환경, 2개의 비프로덕션 환경, 1개의 개발 환경이 포함된 cluster-set-1과 1개의 프로덕션 환경, 1개의 비프로덕션 환경, 1개의 개발 환경이 포함된 cluster-set-2).

허브 및 스포크 토폴로지는 공유 VPC보다 요구사항에 더 부합됩니다.

각 환경(개발, 프로덕션, 비프로덕션)이 자체 스포크 내에 호스팅되는 허브 및 스포크 구성으로 청사진을 배포할 수 있습니다. 허브 및 스포크 토폴로지는 환경 분리 수준을 높여줄 수 있습니다. 자세한 내용은 허브 및 스포크 네트워크 토폴로지를 참조하세요.

각 애플리케이션에는 별도의 Git 저장소가 있습니다.

일부 조직은 여러 저장소 대신 모든 소스 코드에 단일 Git 저장소(monorepo)를 사용합니다. monorepo를 사용하는 경우 청사진의 애플리케이션 팩토리 구성요소를 수정하여 저장소를 지원할 수 있습니다. 다음을 완료합니다.

• 새 애플리케이션마다 새 저장소를 만드는 대신 기존 저장소에 하위 디렉터리를 만듭니다.
• 새 저장소에 대한 소유자 권한을 애플리케이션 개발자 그룹에 부여하는 대신 기존 저장소에 대한 쓰기 권한을 부여하고 애플리케이션 개발자 그룹을 새 하위 디렉터리의 변경사항에 대한 필수 검토자로 지정합니다. CODEOWNERS 기능 및 브랜치 보호를 사용합니다.