이 섹션에서는 개발자 플랫폼에 사용되는 제어 방식을 설명합니다.
플랫폼 ID, 역할, 그룹
Google Cloud 서비스에 액세스하려면 Google Cloud ID가 필요합니다. 청사진은 Fleet 워크로드 아이덴티티를 사용해서 포드 ID로 사용되는 Kubernetes 서비스 계정을 Google Cloud 서비스 액세스를 제어하는 Google Cloud 서비스 계정에 매핑합니다. 환경 간 에스컬레이션을 보호하기 위해 각 환경에는 해당 워크로드 아이덴티티 계정에 대해 신뢰할 수 있는 ID 공급업체 집합으로 알려진 별개의 ID 풀이 포함되어 있습니다.
플랫폼 캐릭터
청사진을 배포할 때는 개발자 플랫폼팀, 애플리케이션팀(애플리케이션별로 하나의 팀), 보안 운영팀의 세 가지 사용자 그룹 유형을 만듭니다.
개발자 플랫폼팀은 개발자 플랫폼의 개발 및 관리를 담당합니다. 이 팀의 멤버는 다음과 같습니다.
- 개발자 플랫폼 개발자: 이러한 팀 멤버는 청사진을 확장하고 이를 기존 시스템에 통합합니다. 또한 이 팀은 새로운 애플리케이션 템플릿을 만듭니다.
- 개발자 플랫폼 관리자: 이 팀은 다음을 담당합니다.
- 새 테넌트팀 만들기를 승인합니다.
- 다음을 포함하여 여러 테넌트에 영향을 주는 예약된 태스크와 예약되지 않은 태스크를 수행합니다.
- 비프로덕션 환경과 프로덕션 환경에 대한 애플리케이션 승격을 승인합니다.
- 인프라 업데이트를 조정합니다.
- 플랫폼 수준의 용량 계획을 만듭니다.
개발자 플랫폼의 테넌트는 단일 소프트웨어 개발팀이며 이러한 소프트웨어의 운영을 담당합니다. 테넌트팀은 애플리케이션 개발자 및 애플리케이션 운영자의 두 그룹으로 구성됩니다. 두 그룹의 테넌트팀의 책임은 다음과 같습니다.
- 애플리케이션 개발자: 이 팀은 애플리케이션 코드를 작성하고 디버그합니다. 경우에 따라 이를 소프트웨어 엔지니어 또는 풀 스택 개발자라고도 부릅니다. 이들의 책임은 다음과 같습니다.
- 개발 환경에 배포되었을 때 애플리케이션 구성요소에서 테스트 및 품질 보증을 수행합니다.
- 개발 환경에서 데이터베이스 및 스토리지 버킷과 같은 애플리케이션 소유의 클라우드 리소스를 관리합니다.
- 애플리케이션에 사용할 데이터베이스 또는 스토리지 스키마를 설계합니다.
- 애플리케이션 운영자 또는 사이트 안정성 엔지니어(SRE): 이 팀은 프로덕션 환경에서 실행되는 애플리케이션의 안정성과 애플리케이션 개발자가 프로덕션에 수행한 변경사항의 안전한 적용을 관리합니다. 경우에 따라 이를 서비스 운영자, 시스템 엔지니어, 시스템 관리자라고 부릅니다. 이들의 책임은 다음과 같습니다.
- 애플리케이션 수준의 용량 요구사항을 계획합니다.
- 서비스에 대해 알림 정책을 만들고 서비스 수준 목표(SLO)를 설정합니다.
- 해당 애플리케이션과 관련된 로그 및 측정항목을 사용하여 서비스 문제를 진단합니다.
- 서비스가 SLO를 충족하지 않을 때 알림 및 페이지에 응답합니다.
- 애플리케이션 개발자 그룹 또는 여러 그룹과 작업을 수행합니다.
- 프로덕션에 새 버전 배포를 승인합니다.
- 비프로덕션 및 프로덕션 환경에서 애플리케이션 소유 클라우드 리소스를 관리합니다(예: 백업 및 스키마 업데이트).
플랫폼 조직 구조
엔터프라이즈 애플리케이션 청사진에는 엔터프라이즈 기반 청사진에서 제공되는 조직 구조가 사용됩니다. 다음 다이어그램은 엔터프라이즈 애플리케이션 청사진 프로젝트가 기반 청사진의 구조 내에 배치되는 방식을 보여줍니다.
플랫폼 프로젝트
다음 표에서는 기반 청사진에서 제공되는 것을 넘어서 리소스, 구성, 애플리케이션 배포를 위해 애플리케이션 청사진에 필요한 추가 프로젝트에 대해 설명합니다.
| 폴더 | 프로젝트 | 설명 |
|---|---|---|
|
|
테넌트 인프라를 배포하기 위한 멀티 테넌트 인프라 파이프라인을 포함합니다. |
|
단일 테넌트 애플리케이션 아키텍처와 지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 만드는 데 사용되는 애플리케이션 팩토리를 포함합니다. 이 프로젝트에는 GKE 클러스터 구성에 사용되는 구성 동기화도 포함됩니다. |
|
|
개발팀 간의 분리를 사용 설정하기 위해 독립 프로젝트에 있는 애플리케이션 CI/CD 파이프라인을 포함합니다. 애플리케이션마다 하나의 파이프라인이 있습니다. |
|
|
|
개발자 플랫폼의 GKE 클러스터와 Fleet 관리를 위해 클러스터를 등록하는 데 사용되는 로직이 포함됩니다. |
( |
애플리케이션팀에 사용되는 데이터베이스 또는 기타 관리형 서비스와 같은 단일 테넌트 애플리케이션 서비스를 포함합니다. |
플랫폼 클러스터 아키텍처
청사진은 개발, 비프로덕션, 프로덕션의 세 가지 환경에 애플리케이션을 배포합니다. 각 환경은 Fleet과 연결됩니다. 이 청사진에서 Fleet은 하나 이상의 클러스터를 포함하는 프로젝트입니다. 하지만 Fleet은 여러 프로젝트를 그룹화할 수도 있습니다. Fleet은 관리 제어를 위한 논리적 보안 경계를 제공합니다. Fleet는 인프라를 더 쉽게 관리할 수 있도록 Kubernetes 클러스터를 논리적으로 그룹화 및 정규화할 수 있는 방법을 제공합니다.
다음 다이어그램은 각 환경에서 애플리케이션 배포를 위해 생성되는 2개의 GKE 클러스터를 보여줍니다. 2개의 클러스터가 서로 다른 두 리전에서 동일한 GKE 클러스터로 작동하여 멀티 리전 복원력을 제공합니다. Fleet 기능을 활용하기 위해 청사진은 네임스페이스 객체, 서비스, ID에 대해 동일성이라는 개념을 사용합니다.
엔터프라이즈 애플리케이션 청사진은 제어 영역에 대한 Private Service Connect 액세스 및 비공개 노드 풀을 통해 비공개 스페이스가 사용 설정된 GKE 클러스터를 사용하여 인터넷에서 잠재적인 공격 표면을 없앱니다. 클러스터 노드 또는 제어 영역 어디에도 공개 엔드포인트가 포함되지 않습니다. 클러스터 노드는 Container-Optimized OS를 실행해서 공격 표면을 제한하고 클러스터 노드는 보안 GKE 노드를 사용해서 공격자의 노드 가장 능력을 제한합니다.
GKE 클러스터에 대한 관리 액세스는 Connect 게이트웨이를 통해 사용 설정됩니다. 청사진 배포 중에는 각 환경이 포드 및 구성 동기화에 GitHub와 같은 인터넷 리소스에 액세스하기 위한 메커니즘을 제공할 수 있도록 하나의 Cloud NAT 인스턴스가 사용됩니다. GKE 클러스터 액세스는 GKE용 Google 그룹스를 기반으로 하는 Kubernetes RBAC 승인에 따라 제어됩니다. 그룹스를 사용하면 ID 관리자가 제어하는 중앙 ID 관리 시스템을 사용해서 ID를 제어할 수 있습니다.
플랫폼 GKE Enterprise 구성요소
개발자 플랫폼은 GKE Enterprise 구성요소를 사용해서 애플리케이션의 수명 주기를 빌드, 제공, 관리할 수 있게 해줍니다. 청사진 배포에 사용되는 GKE Enterprise 구성요소는 다음과 같습니다.
- 컨테이너 관리를 위한 GKE
- 정책 관리 및 적용을 위한 정책 컨트롤러
- 서비스 관리를 위한 Anthos Service Mesh
- 컨테이너 이미지 증명을 위한 Binary Authorization
- GKE 클러스터의 멀티 클러스터 게이트웨이 컨트롤러를 위한 GKE Gateway Controller
플랫폼 Fleet 관리
Fleet는 단일 통합 방식으로 여러 GKE 클러스터를 관리할 수 있는 기능을 제공합니다. Fleet 팀 관리를 사용하면 플랫폼 관리자가 개발자 플랫폼 테넌트에 대한 인프라 리소스를 더 쉽게 프로비저닝하고 관리할 수 있습니다. 테넌트는 자체 네임스페이스 내에서 애플리케이션, 로그, 측정항목을 포함하여 일정 범위에 따라 리소스를 제어할 수 있습니다.
관리자는 팀 범위를 사용해서 팀별 기준에 따라 Fleet 리소스의 하위 집합을 프로비저닝할 수 있습니다. 팀 범위를 사용하면 각 팀에 대해 팀 범위가 하나 이상의 Fleet 멤버 클러스터와 연결된 Fleet 리소스 하위 집합을 정의할 수 있습니다.
Fleet 네임스페이스는 Fleet 내에서 특정 네임스페이스에 액세스할 수 있는 사용자를 제어합니다. 애플리케이션은 각 범위에 하나의 Fleet 네임스페이스가 포함된 3개의 팀 범위와 함께 하나의 Fleet에 배포된 2개의 GKE 클러스터를 사용합니다.
다음 다이어그램은 청사진에 따라 구현된 한 환경의 샘플 클러스터에 해당하는 Fleet 및 범위 리소스를 보여줍니다.
플랫폼 네트워킹
네트워킹을 위해 GKE 클러스터는 엔터프라이즈 기반 청사진의 일부로 생성된 공유 VPC에 배포됩니다. GKE 클러스터에서는 여러 IP 주소 범위를 개발, 비프로덕션, 프로덕션 환경에 할당해야 합니다. 청사진에 사용되는 각 GKE 클러스터에는 노드, 포드, 서비스, 제어 영역에 할당된 별도의 IP 주소 범위가 필요합니다. 또한 PostgreSQL용 AlloyDB 인스턴스에도 또한 별도의 IP 주소 범위가 필요합니다.
다음 표에서는 청사진 클러스터를 배포하기 위해 여러 환경에 사용되는 VPC 서브넷과 IP 주소 범위를 설명합니다. 애플리케이션 GKE 클러스터 리전 2의 개발 환경에 대해 청사진은 2개의 개발 GKE 클러스터에 대해 할당된 IP 주소 공간이 있더라도 IP 주소 공간을 하나만 배포합니다.
| 리소스 | IP 주소 범위 유형 | 개발 | 비프로덕션 | 프로덕션 |
|---|---|---|---|---|
애플리케이션 GKE 클러스터 리전 1 |
기본 IP 주소 범위 |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
포드 IP 주소 범위 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
서비스 IP 주소 범위 |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
GKE 제어 영역 IP 주소 범위 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
애플리케이션 GKE 클러스터 리전 2 |
기본 IP 주소 범위 |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
포드 IP 주소 범위 |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
서비스 IP 주소 범위 |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
GKE 제어 영역 IP 주소 범위 |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
PostgreSQL용 AlloyDB |
데이터베이스 IP 주소 범위 |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
자체 IP 주소 할당 스킴을 설계해야 하는 경우 GKE에서 IP 주소 관리 및 GKE IPv4 주소 계획을 참조하세요.
플랫폼 DNS
청사진은 GKE용 Cloud DNS를 사용하여 포드 및 Kubernetes 서비스에 대해 DNS 변환을 제공합니다. GKE용 Cloud DNS는 클러스터에 호스팅되는 DNS 제공업체가 필요하지 않은 관리형 DNS입니다.
청사진에서 Cloud DNS는 VPC 범위에 맞게 구성됩니다. VPC 범위를 사용하면 프로젝트의 모든 GKE 클러스터에 있는 서비스가 단일 DNS 영역을 공유할 수 있습니다. 단일 DNS 영역을 사용하면 클러스터 간에 서비스를 변환할 수 있고 클러스터 외부의 VM 또는 포드가 클러스터 내에서 서비스를 변환할 수 있습니다.
플랫폼 방화벽
GKE는 환경에서 클러스터 운영을 허용하는 GKE 클러스터, GKE 서비스, GKE 게이트웨이 방화벽, GKE 인그레스 방화벽을 만들 때 방화벽 규칙을 자동으로 만듭니다. 자동으로 생성되는 모든 방화벽 규칙의 우선순위는 1,000입니다. 엔터프라이즈 기반 청사진에는 공유 VPC에서 트래픽을 차단하는 기본 규칙이 있기 때문에 이러한 규칙이 필요합니다.
Google Cloud 서비스에 대한 플랫폼 액세스
청사진 애플리케이션이 비공개 클러스터를 사용하기 때문에 비공개 Google 액세스는 Google Cloud 서비스에 액세스를 제공합니다.
플랫폼 고가용성
청사진은 영역 및 리전 중단 모두에 복원력을 갖도록 설계됩니다. 애플리케이션 실행을 유지하는 데 필요한 리소스는 두 리전 간에 분산됩니다. 청사진을 배포할 리전을 선택합니다. 로드를 관리하고 처리하는 데 중요한 경로에 없는 리소스는 유일한 리전 또는 전역 리소스입니다. 다음 표에서는 이러한 리소스 및 리소스의 배포 위치를 설명합니다.
위치 |
리전 1 |
리전 2 |
전역 |
|---|---|---|---|
이 위치에 리소스가 있는 환경 |
|
|
|
이 위치에 리소스가 있는 프로젝트 |
|
|
|
이 위치의 리소스 유형 |
|
|
|
다음 표에서는 여러 다른 구성요소가 리전 중단 또는 영역 중단에 대응하는 방법과 이러한 효과를 완화할 수 있는 방법을 요약해서 보여줍니다.
오류 범위 |
외부 서비스 효과 |
데이터베이스 효과 | 빌드 및 배포 효과 | Terraform 파이프라인 효과 |
|---|---|---|---|---|
리전 1의 영역 |
사용 가능 |
사용 가능 대기 인스턴스가 제로 RPO로 활성화됩니다. |
사용 가능. 수동 변경이 필요할 수 있습니다. 진행 중이었지만 중단 중 완료된 모든 |
사용 가능. 수동 변경이 필요할 수 있습니다. 진행 중이었지만 중단 중 완료된 모든 |
리전 2의 영역 |
사용 가능 |
사용 가능 |
사용 가능 |
사용 가능. 수동 변경이 필요할 수 있습니다. 진행 중이었지만 중단 중 완료된 모든 |
리전 1 |
사용 가능 |
수동 변경이 필요합니다. 운영자가 수동으로 보조 클러스터를 승격해야 합니다. |
사용 불가능 |
사용 불가능 |
리전 2 |
사용 가능 |
사용 가능 |
사용 가능. 수동 변경이 필요할 수 있습니다. 빌드를 계속 사용할 수 있습니다. 새 빌드를 수동으로 배포해야 할 수 있습니다. 기존 빌드가 성공적으로 완료되지 않을 수 있습니다. |
사용 가능 |
클라우드 제공업체 중단이 다운타임의 유일한 소스입니다. 고가용성은 실수를 줄이는 데 도움이 되는 프로세스 및 운영에 따라 달라집니다. 다음 표에서는 고가용성과 관련해서 청사진에서 수행된 모든 결정 및 이러한 결정의 이유에 대해 설명합니다.
| 청사진 결정 | 가용성 영향 |
|---|---|
변경 관리 |
|
GitOps 및 IaC를 사용합니다. |
변경사항에 대한 동료 검토를 지원하고 이전 구성으로 신속하게 돌아가기를 지원합니다. |
환경 전반에서 변경사항을 점진적으로 승격합니다. |
소프트웨어 및 구성 오류의 영향을 줄입니다. |
비프로덕션 환경과 프로덕션 환경을 비슷하게 만듭니다. |
차이로 인해 오류 검색이 지연되지 않도록 보장합니다. 두 환경 모두 이중 리전입니다. |
환경 내에서 한 번에 하나씩 하나의 리전에서 복제된 리소스를 변경합니다. |
점진적 승격으로 해결되지 않은 문제가 런타임 인프라의 절반만 영향을 주도록 보장합니다. |
환경 내에서 한 번에 하나씩 하나의 리전에서 서비스를 변경합니다. |
점진적 승격으로 해결되지 않은 문제가 서비스 복제본의 절반만 영향을 주도록 보장합니다. |
복제된 컴퓨팅 인프라 |
|
리전 클러스터 제어 영역을 사용합니다. |
리전 제어 영역은 업그레이드 및 크기 조정 시에 사용할 수 있습니다. |
다중 영역 노드 풀을 만듭니다. |
클러스터 노드 풀에는 3개 영역 간에 분산된 3개 이상의 노드가 포함됩니다. |
공유 VPC 네트워크를 구성합니다. |
공유 VPC 네트워크에는 2개 리전이 포함됩니다. 리전 장애는 장애가 발생한 리전의 리소스와 주고받는 네트워크 트래픽에만 영향을 미칩니다. |
이미지 레지스트리를 복제합니다. |
이미지는 클라우드 리전 중단이 생존 리전에서 애플리케이션의 수직 확장을 방해하지 않도록 여러 리전에 복제되도록 구성된 Artifact Registry에 저장됩니다. |
복제된 서비스 |
|
서비스 복제본을 2개 리전에 배포합니다. |
리전 중단의 경우 Kubernetes 서비스는 프로덕션 및 비프로덕션 환경에서 사용 가능한 상태로 유지됩니다. |
리전 내에서 서비스 변경사항에 대해 순차적 업데이트를 사용합니다. |
위험 및 다운타임을 줄여주는 순차적 업데이트 배포 패턴을 사용해서 Kubernetes 서비스를 업데이트할 수 있습니다. |
한 리전에서 각 서비스에 대해 3개의 복제본을 구성합니다. |
Kubernetes 서비스에는 프로덕션 및 비프로덕션 환경의 순차적 업데이트를 지원하기 위해 최소 3개의 복제본(포드)가 포함됩니다. |
여러 영역 간에 배포 포드를 분산합니다. |
Kubernetes 서비스는 안티어피니티 스탠자를 사용해서 여러 영역의 VM 간에 분산됩니다. 종속된 서비스 간에 추가적인 리전 간 트래픽을 일으키지 않더라도 단일 노드 중단 또는 전체 영역 중단을 처리할 수 있습니다. |
복제된 저장소 |
|
다중 영역 데이터베이스 인스턴스를 배포합니다. |
PostgreSQL용 AlloyDB는 리전에 고가용성을 제공합니다. 기본 인스턴스의 중복 노드가 해당 리전의 서로 다른 2개 영역에 배치됩니다. 기본 인스턴스는 활성 영역에 문제가 발생하면 대기 영역에 대한 자동 장애 조치를 트리거하여 리전 가용성을 유지합니다. 리전 스토리지는 단일 영역이 손실될 경우에 데이터 내구성을 제공합니다. |
리전 간에 데이터베이스를 복제합니다. |
PostgreSQL용 AlloyDB는 리전 간 복제를 사용해서 재해 복구 기능을 제공합니다. 데이터베이스는 별개의 Google Cloud 리전에 있는 보조 클러스터에 기본 클러스터 데이터를 복제합니다. |
작업 |
|
예상 부하의 두 배로 애플리케이션을 프로비저닝합니다. |
리전 서비스 중단 등으로 인해 한 클러스터가 실패하면 남은 클러스터에서 실행되는 서비스 부분이 부하를 완전히 흡수할 수 있습니다. |
노드를 자동으로 복구합니다. |
클러스터는 노드 자동 복구로 구성되어 있습니다. 노드의 연속 상태 점검이 일정 기간 동안 반복해서 실패하면 GKE가 해당 노드에 대해 복구 프로세스를 시작합니다. |
노드 풀 업그레이드가 애플리케이션에 인식되는지 확인합니다. |
배포는 대규모 클러스터에서 병렬 노드 풀 업그레이드를 허용하도록 |
교착 상태의 서비스를 자동으로 다시 시작합니다. |
서비스 지원 배포는 교착 상태의 프로세스를 식별하고 다시 시작하는 활성 프로브를 정의합니다. |
복제본이 준비되었는지 자동으로 검사합니다. |
서비스 지원 배포는 시작 후 애플리케이션이 서비스를 제공할 준비가 되었을 때 이를 식별하는 준비 프로브를 정의합니다. 준비 프로브를 사용하면 순차적 업데이트 및 노드 풀 업그레이드 중에 수동 검사 또는 시간 대기가 필요하지 않습니다. |
참조 아키텍처는 영역 및 리전 고가용성 요구사항이 있는 애플리케이션을 위해 설계되었습니다. 고가용성을 보장하면 대기 예비 비용 또는 리전 간 복제 비용과 같은 일부 비용이 발생하지 않습니다. 대안 섹션에서는 이러한 비용을 해결하기 위한 몇 가지 방법을 설명합니다.
플랫폼 할당량, 성능 한도, 확장 한도
개발자 플랫폼에서 리소스의 할당량, 성능, 확장을 제어할 수 있습니다. 다음 목록에서는 고려해야 할 몇 가지 항목들에 대해 설명합니다.
- 기본 인프라에는 여러 프로젝트가 필요하고 각 추가 테넌트에는 4개의 프로젝트가 필요합니다. 테넌트를 더 배포하고 추가하기 전에 추가 프로젝트 할당량을 요청해야 할 수 있습니다.
- 각 프로젝트의 MultiClusterGateway 리소스는 100개로 제한됩니다. 개발자 플랫폼에서 각 인터넷 연결 Kubernetes 서비스에는 하나의 MultiClusterGateway가 필요합니다.
- Cloud Logging에서 프로젝트의 버킷은 100개로 제한됩니다. 청사진의 테넌트별 로그 액세스는 각 테넌트의 버킷에 따라 달라집니다.
- 테넌트를 20개 넘게 만들려면 범위 및 범위 네임스페이스 리소스에 대해 프로젝트 할당량 증가를 요청할 수 있습니다. 할당량 보기에 대한 자세한 내용은 할당량 보기 및 관리를 참조하세요. 필터를 사용하여
gkehub.googleapis.com/global-per-project-scopes및gkehub.googleapis.com/global-per-project-scope-namespaces할당량 유형을 찾습니다.
다음 단계
- 서비스 아키텍처(이 시리즈의 다음 문서) 검토하기