SaaS 런타임을 사용하면 Google Cloud에서 서비스형 소프트웨어 (SaaS) 애플리케이션을 저장, 호스팅, 관리, 모니터링할 수 있습니다. SaaS 런타임은 Terraform 배포를 규모에 맞게 관리하므로 SaaS 애플리케이션과 애플리케이션이 실행되는 인프라를 모두 관리할 수 있습니다.
SaaS 런타임은 SaaS 파이프라인 내 다양한 이해관계자가 여러 방식으로 사용할 수 있습니다. 다음 역할 중 하나에 해당하는 작업을 하는 경우 SaaS 런타임을 사용하는 것이 좋습니다.
- 플랫폼 관리자
- 애플리케이션 개발자
- 설계자
- 규정 준수 관리자
- 플랫폼 엔지니어
- 금융 운영
SaaS 런타임은 다음과 같은 이점을 제공합니다.
- SaaS 테넌트 전반에서 서비스 관리 작업 (예: 배포, 출시, 기능 플래그 관리)을 자동화하여 규모에 맞게 서비스 관리를 간소화합니다.
- 구성 가능한 단위 전반에서 업데이트와 출시를 세부적으로 조정하여 관찰 가능성과 제어 기능을 확장하고, 규모에 맞게 SaaS 제품을 정밀하게 관리하세요.
- Google Cloud Google Distributed Cloud, 결제, 모니터링 가능성, 리소스 관리자를 비롯한 다양한 Google Cloud 제품 전반에서 서비스를 관리하여 Google Cloud생태계 전반의 일관성을 유지하세요.
- 효율성과 재사용성을 개선하기 위해 단위 기반 그룹 업데이트와 배포를 촉진하는 유연하고 템플릿화 가능한 아키텍처를 사용합니다.
SaaS 런타임은 어떻게 작동하나요?
SaaS 런타임은 SaaS 제품을 정의하는 아티팩트를 배포합니다. 이러한 아티팩트에는 Terraform 구성이 있어야 합니다. 배포는 구성 가능한 출시 프로세스를 통해 제품의 변경사항이 포함된 출시로 업데이트할 수 있는 별도의 단위로 구성됩니다.
SaaS 런타임 명명법에 관한 자세한 내용은 용어집을 참고하세요.
SaaS 런타임용 워크로드 준비
SaaS 제품을 배포하기 전에 SaaS 런타임 생태계 내에서 SaaS 제품의 이상적인 배치를 결정하는 것이 좋습니다.
함께 업데이트하거나 수정해야 하는 SaaS 제품의 부분을 별도의 Terraform 구성으로 정리합니다. SaaS 제품을 계획할 때 SaaS 제품의 각 그룹에 단위 종류를 사용하세요.
SaaS 런타임에서 워크로드에 적합한 구조를 파악한 후 SaaS 제품, 단위 종류를 만들고 출시를 사용하여 단위를 배포할 수 있습니다.
SaaS 런타임 설정의 예는 빠른 시작을 참고하세요.
SaaS 런타임 서비스 계정
SaaS 런타임은 Google 관리 서비스 계정과 사용자 관리 서비스 계정을 함께 사용합니다.
SaaS 런타임 서비스 계정 (Google 관리): 이 계정은 첫 번째 SaaS 제품 리소스를 만든 후 자동으로 생성됩니다. Google에서 관리합니다. 단위 프로비저닝 중에 다른 Google Cloud 서비스와 상호작용하는 등 사용자를 대신하여 작업을 실행합니다.
작동 서비스 계정 (사용자 관리): 사용자가 이 서비스 계정을 만들고 관리합니다. SaaS 런타임 (Infrastructure Manager를 통해)은 단위를 프로비저닝하거나 업데이트할 때 이 계정을 사용하여 Terraform 구성을 실행합니다. 이 계정은 Terraform에 정의된 리소스를 만들고 관리하는 ID 역할을 합니다. 작동 서비스 계정 권한은 Terraform 구성에서 관리하는 리소스와 직접 연결됩니다.
작동 서비스 계정을 여러 개 사용할 수 있습니다. 테넌트마다 하나의 활성화 서비스 계정을 사용하는 것이 좋습니다.
선택사항: 아티팩트 생성 서비스 계정 (사용자 관리): 이 서비스 계정은 Terraform을 OCI 아티팩트로 패키징하여 빌드하고 업로드하는 데 사용됩니다. 이는 Cloud Build 서비스 계정인 경우가 많지만 SaaS 제품에 적절한 권한이 있는 서비스 계정이라면 어떤 계정이든 가능합니다.
SaaS 런타임 서비스 계정 (Google 관리)
SaaS 런타임 서비스 계정은 Google에서 관리하는 서비스 에이전트로, SaaS 런타임이 프로젝트 내에서 작업을 실행하는 데 사용됩니다.
이 서비스 계정은 첫 번째 SaaS 런타임 리소스를 만들 때 자동으로 프로비저닝됩니다. SaaS 런타임 서비스 계정은 다음 형식을 사용하여 생성됩니다.
service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com
다음과 같이 바꿉니다.
- PROJECT_NUMBER: 프로젝트 번호입니다.
작동 서비스 계정 (사용자 관리)
작동 서비스 계정은 사용자가 만들어야 하는 사용자 관리형 서비스 계정입니다. SaaS 런타임 (Infra Manager를 통해)은 이 서비스 계정을 사용하여 Terraform 구성을 실행합니다. Terraform에 정의된 리소스를 생성, 수정, 삭제하는 ID입니다.
프로젝트 또는 테넌트 프로젝트 내에서 이 서비스 계정을 만드는 것은 사용자의 책임입니다.
작동 서비스 계정 입력 변수
단위를 만들 때 Terraform 구성의 키-값 쌍 입력 변수로 작동 서비스 계정을 제공해야 합니다.
- 이름:
actuation_sa - 변수 유형:
String 변수 값: 실행 서비스 계정 이메일 주소:
my-actuation-sa@my-identifier.iam.gserviceaccount.com
필수 권한
작동 서비스 계정에는 Terraform 구성에 정의된 리소스를 관리할 수 있는 충분한 권한이 필요합니다. 최소한 다음이 필요합니다.
roles/iam.serviceAccountTokenCreator: 서비스 계정이 인증을 위한 토큰을 생성하도록 허용합니다.roles/config.admin: Infra Manager 리소스에 대한 전체 제어 권한을 부여합니다.roles/storage.admin: Cloud Storage에 대한 모든 권한을 부여합니다.
활성화 서비스 계정에는 애플리케이션에서 사용하는 특정 Google Cloud 리소스를 만들고 관리할 수 있는 권한도 필요합니다.
예를 들면 다음과 같습니다.
- Terraform에서 Google Kubernetes Engine (GKE) 클러스터를 만드는 경우 서비스 계정에 적절한 GKE 역할(예:
roles/container.admin)이 필요합니다. - Terraform에서 Compute Engine 인스턴스를 만드는 경우 서비스 계정에
roles/compute.admin역할이 필요합니다. - Terraform에서 Cloud SQL 인스턴스를 만드는 경우 서비스 계정에 적절한 Cloud SQL 역할 (예:
roles/cloudsql.admin)이 필요합니다.
Terraform에서 사용하는 각 Google Cloud 리소스의 문서를 참고하여 필요한 권한을 확인하세요. 애플리케이션이 작동하는 데 필요한 최소 권한을 부여합니다.
아티팩트 생성 서비스 계정 (사용자 관리)
아티팩트 생성 서비스 계정은 빌드 시스템 (예: Cloud Build)을 사용하여 Terraform 아티팩트를 패키징하고 Artifact Registry에 업로드하기 위해 만드는 사용자 관리 서비스 계정입니다.
이 서비스 계정은 SaaS 런타임 및 작동 서비스 계정과 별개이며 Terraform 코드를 빌드하고 결과 아티팩트를 Artifact Registry에 푸시합니다. 일반적으로 Cloud Build 서비스 계정입니다.
수동 아티팩트 생성
Terraform 아티팩트를 수동으로 빌드하고 업로드하는 경우 (예: Docker 빌드 및 Docker 푸시를 직접 사용) 별도의 아티팩트 생성 서비스 계정이 필요하지 않습니다.
대신 필요한 Artifact Registry 권한이 있는 자체 사용자 인증 정보 또는 서비스 계정을 사용하여 인증해야 합니다.
필수 권한
Cloud Build를 사용하는 경우 Cloud Build 서비스 계정에는 일반적으로 다음 역할이 필요합니다.
roles/artifactregistry.writer: Artifact Registry에 아티팩트를 푸시합니다.roles/artifactregistry.repoAdmin: Artifact Registry 저장소를 관리합니다.roles/storage.admin: Cloud Storage 버킷을 관리합니다.roles/developerconnect.admin: Developer Connect 사용 권한roles/developerconnect.readTokenAccessor: Developer Connect 읽기 토큰을 가져올 권한입니다.roles/logging.logWriter: 로그를 작성할 권한- Developer Connect를 사용하여 Terraform 구성을 배포하는 경우 다음 권한이 필요합니다.
roles/cloudbuild.builds.builder: 빌드를 실행합니다. - 빌드 프로세스에 필요한 기타 권한 (예: 소스 코드 저장소 액세스)
출시 전략
SaaS 런타임은 여러 출시 전략을 사용하여 SaaS 제품의 단위가 업데이트되는 방식을 관리합니다. 이러한 출시 전략은 SaaS 제품 전반에 변경사항을 배포하는 데 일관된 접근 방식을 적용하여 Google Cloud의 변경 접근 방식을 따릅니다.
롤아웃 전략을 사용하여 부정적인 고객 영향을 최소화하고 문제를 개별 논리적 및 물리적 장애 도메인으로 격리합니다. 다음 출시 전략 중 하나를 지정하는 출시 종류를 만들어 출시 전략을 정의합니다.
한 번에 한 위치 (단순): 위치 간 대기 시간 없이 한 번에 한 위치가 출시됩니다. 위치 내에서 임의로 선택되며, 특정 시점에 업데이트되는 위치의 단위는 최대 20% 입니다.
이 전략은 개발 환경 및 긴급 상황에 권장됩니다.
한 번에 모두 (단순): 모든 위치에서 동시에 출시가 시작됩니다.
이 전략은 개발 환경 및 긴급 상황에 권장됩니다.
점진적: 각 위치 내에서 단위는 배치 간에 흡수 시간이 있는 정적 비율 기반 배치(예: 1%, 10%, 20%, 30%, ~40%)로 출시됩니다. 위치 전반에서 출시가 진행되면서 동시 위치 수가 지수적으로 증가합니다(예: 1개 위치, 2개 위치, 4개 위치). 웨이브 사이에는 소크 시간(예: 18시간)이 있습니다. 위치 내의 단위는 무작위로 선택됩니다.
이 전략은 여러 위치에서 안전하고 예측 가능한 출시를 위해 설계되었습니다. 소규모로 시작하여 신뢰도가 높아짐에 따라 점진적으로 확장합니다. 이 전략은 위치가 두 개 이상인 프로덕션 환경에서 권장됩니다.
점진적 (단일 위치): 단위는 정적 비율 기반 배치 (예: 1%, 10%, 20%, 30%, ~40%)로 업데이트되며, 문제 감지를 위한 충분한 시간을 허용하고 출시 변경사항의 부정적인 영향을 제한하기 위해 배치 간에 더 긴 소크 시간 (예: 18시간)이 적용됩니다.
이 전략은 단일 위치에서 운영되는 SaaS 제품에 맞게 조정되며 안전과 주의를 우선시합니다. 위치가 하나인 프로덕션 환경에서는 이 전략을 사용하는 것이 좋습니다.
출시 종류 만들기에 대한 자세한 내용은 출시 종류 만들기를 참고하세요.
다음 단계
- 빠른 시작을 통해 SaaS 런타임을 사용하여 VM을 배포하는 방법을 알아보세요.
- SaaS 런타임을 시작하려면 SaaS 제품 만들기부터 시작하세요.