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 런타임 지역화
SaaS 제품 리소스는 SaaS 런타임 단위가 상주할 수 있는 위치와 출시가 관리되는 방식을 정의합니다. SaaS 제품을 만들 때 선택한 리전은 SaaS 제품의 지원되는 리전의 단일 정보 소스 역할을 합니다. 선택한 리전은 SaaS 제품에 대해 정의한 사용 가능한 리전입니다.
Google Cloud 콘솔을 통해 SaaS 런타임을 사용하면 SaaS 런타임이 SaaS 제품에 정의된 리소스의 리전 간 복제를 자동화합니다. 이렇게 하면 SaaS 제품에 정의된 모든 사용 가능한 리전에서 SaaS 런타임 리소스의 일관성과 가용성이 보장됩니다.
SaaS 런타임은 다음 리소스를 복제합니다.
- SaaS 제품 (
Saas) - 단위 종류 (
UnitKind) - 버전 (
Release)
global을 리전으로 사용
SaaS 제품에 global를 지역으로 포함하는 것은 일반적으로 배포 타겟에 권장되지 않습니다. SaaS 런타임은 global 리전을 사용하여 리전별 출시를 전파합니다. 리전 출시는 global 리전에서 실행할 수 없습니다.
출시 지역화
출시 지원 위치는 SaaS 제품의 사용 가능한 지역에 정의된 최상위 지역에 따라 결정됩니다.
출시는 연결된 SaaS 제품에서 사용 가능한 리전 목록을 읽습니다.
리소스 복제
SaaS 런타임은 SaaS 제품의 사용 가능한 모든 지역에 대한 리소스 생성 및 업데이트를 처리합니다.
SaaS 제품의 사용 가능한 리전을 업데이트하면 SaaS 런타임에서 복제를 처리합니다.
- 추가된 위치: 리소스가 새로 추가된 위치에 복제됩니다.
- 오래된 사본이 있는 위치: 콘텐츠가 업데이트됩니다.
Artifact Registry 및 Developer Connect 위치
Artifact Registry 저장소와 Developer Connect 인스턴스의 위치에는 다음과 같은 특정 요구사항이 있습니다.
Artifact Registry 저장소 및 Developer Connect 인스턴스의 리전은 유효한 Google Cloud 리전어디든 가능합니다. SaaS 제품의 사용 가능한 지역에 포함되지 않아도 됩니다.
Artifact Registry 저장소의 리전은 Developer Connect 인스턴스의 리전과 일치해야 합니다.
따라서 Artifact Registry와 Developer Connect가 단일(잠재적으로 다른) 리전에 상주하더라도 SaaS 제품에 정의된 모든 리전에 SaaS 제품, 출시, 단위 종류 리소스가 있어야 합니다.
단위는 SaaS 제품에 지정된 리전에서만 만들 수 있습니다.
SaaS 런타임 리전 구성 예시
이 예시는 관리 리소스 복제와 함께 SaaS 런타임을 사용할 때 리전화가 작동하는 방식을 보여주기 위해 제공되었습니다.
예를 들어 us-central1 및 europe-west4에 SaaS 제품을 배포하고 us-east1에 Artifact Registry 저장소와 Developer Connect 인스턴스를 호스팅하려는 경우 SaaS 런타임 리전 인프라는 다음과 같습니다.
- SaaS 제품 사용 가능 지역:
['us-central1', 'europe-west4'] - Artifact Registry 저장소 리전:
us-east1 - Developer Connect 인스턴스 리전:
us-east1 - 단위 종류 및 출시 리소스: SaaS 런타임은
global,us-central1,europe-west4지역 전반에서 이러한 리소스의 생성 및 업데이트를 관리합니다. - 단위: 단위는
us-central1또는europe-west4에서 만들 수 있습니다.
이 구성을 사용하면 두 리전에서 배포를 관리하는 동시에 자동 리소스 복제를 통해 세 번째 별도 리전에서 아티팩트 관리를 중앙 집중화할 수 있습니다. 리전을 선택할 때는 지연 시간, 규정 준수, 데이터 상주 요구사항을 신중하게 고려해야 합니다.
다음 단계
- 빠른 시작을 통해 SaaS 런타임을 사용하여 VM을 배포하는 방법을 알아보세요.
- SaaS 런타임을 시작하려면 SaaS 제품 만들기부터 시작하세요.