청사진 배포

Last reviewed 2024-04-19 UTC

이 섹션에서는 청사진을 배포하는 데 사용할 수 있는 프로세스, 이름 지정 규칙, 청사진 권장사항의 대안에 대해 설명합니다.

총정리

이 문서에 설명된 아키텍처를 구현하려면 이 섹션의 단계를 수행합니다.

새 조직에 청사진 배포

새 Google Cloud 조직에 청사진을 배포하려면 다음을 수행합니다.

  1. 엔터프라이즈 기반 청사진을 사용하여 기반 인프라를 만듭니다. 다음을 완료합니다.

    1. 환경 분리를 위한 폴더를 포함하여 조직 구조를 만듭니다.
    2. 개발자 플랫폼 관리자에게 액세스 권한을 부여하도록 기반 IAM 권한을 구성합니다.
    3. VPC 네트워크를 만듭니다.
    4. 기반 인프라 파이프라인을 배포합니다.

    엔터프라이즈 기반 청사진을 사용하지 않는 경우 엔터프라이즈 기반 청사진 없이 청사진 배포를 참조하세요.

  2. 개발자 플랫폼 관리자는 기반 인프라 파이프라인을 사용해서 멀티 테넌트 인프라 파이프라인, 애플리케이션 팩토리, Fleet 범위 파이프라인을 만듭니다.

  3. 개발자 플랫폼 관리자는 멀티 테넌트 인프라 파이프라인을 사용해서 GKE 클러스터 및 공유 인프라를 배포합니다.

  4. 애플리케이션 운영자는 애플리케이션 팩토리를 사용해서 새 애플리케이션을 온보딩합니다. 운영자는 애플리케이션 팩토리 저장소에서 애플리케이션 특정 리소스 만들기를 트리거하는 항목을 하나 이상 추가합니다.

  5. 애플리케이션 개발자는 자신의 애플리케이션 특정 인프라 내에서 애플리케이션 CI/CD 파이프라인을 사용해서 멀티 테넌트 인프라에 애플리케이션을 배포합니다.

엔터프라이즈 기반 청사진 없이 청사진 배포

엔터프라이즈 기반 청사진에 엔터프라이즈 애플리케이션 청사진을 배포하지 않는 경우 다음 단계를 수행합니다.

  1. 다음 리소스를 만듭니다.
    • development, nonproduction, production 폴더가 있는 조직 계층 구조
    • 각 폴더의 공유 VPC 네트워크
    • GKE 클러스터에 필요한 IP 범위를 고려하는 IP 주소 스킴
    • GKE 클러스터의 DNS 메커니즘
    • 보안 상황과 일치하는 방화벽 정책
    • 비공개 IP 주소를 통해 Google Cloud API에 액세스하는 메커니즘
    • 온프레미스 환경과의 연결 메커니즘
    • 보안 및 감사를 위한 중앙 집중식 로깅
    • 위협 모니터링을 위한 Security Command Center
    • 보안 상황과 일치하는 조직 정책
    • 애플리케이션 팩토리, 멀티 테넌트 인프라 파이프라인, Fleet 범위 파이프라인을 배포하는 데 사용할 수 있는 파이프라인
  2. 리소스를 배포한 후 새 조직에 청사진 배포의 2단계를 계속합니다.

기존 GKE 배포에 청사진 사용

이 청사진을 사용하려면 개발자 플랫폼을 먼저 배포한 후 개발자 플랫폼에 애플리케이션을 배포해야 합니다. 다음 표에서는 Google Cloud에서 컨테이너화된 애플리케이션이 이미 실행 중인 경우 청사진을 사용하는 방법을 설명합니다.

기존 사용 마이그레이션 전략

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

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

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

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

IaC를 사용하지 않습니다.

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

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

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

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

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

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

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

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

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

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

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

기본 권장사항의 대안

이 섹션에서는 이 가이드에 포함된 기본 권장사항의 대안을 설명합니다.

결정 영역 가능한 대안

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

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

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

  • 특별한 규제 요구가 있는 몇 가지 애플리케이션을 하나로 그룹화합니다(예: PCI-DSS).
  • 클러스터 업그레이드 중 특수 취급이 필요한 애플리케이션을 격리합니다(예: 영구 볼륨을 사용하는 스테이트풀(Stateful) 애플리케이션).
  • 위험한 보안 프로필의 애플리케이션을 격리합니다(예: 메모리에 안전하지 않은 언어로 사용자 제공 콘텐츠 처리).
  • GPU, 비용 민감도, 성능 민감도가 요구되는 애플리케이션을 격리합니다.
  • 노드 수에 대한 GKE 클러스터 한도(15,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 기능 및 브랜치 보호를 사용합니다.

다음 단계