Terraform으로 Vertex AI Workbench를 배포하는 방법 – UI 통증없이
클릭 -OPS에서 시간과 돈을 잃지 않는 MLOPS 및 데이터 팀을위한 자세한 안내서.
1. 소개
Vertex AI Workbench는 Google Cloud의 관리되는 Jupyter 환경입니다. BigQuery 및 Cloud Storage와의 기본 통합, GPU/TPU를 지원하며 GCP의 통합 IAM 모델 및 네트워킹 정책을 활용합니다.
UI를 통해 Vertex AI Workbench에서 Jupyter 인스턴스 생성은 시작하는 가장 간단한 방법입니다. 그러나 팀이 성장함에 따라이 프로세스는 점점 더 노동 집약적 인 것이되고 감사가 더 어려워지고 구성 실수 및 보안 문제가 더욱 높아집니다.
몇 가지 데이터 포인트 : Flexera에 따르면 평균 “클라우드 폐기물”에 도달합니다. 32% 지출 – 법안의 거의 3 분의 1이 아무것도 지불하지 않습니다. 84% 조직의 이름 비용 관리는 최고의 클라우드 챌린지 (Flexera) 및 최대 21% 유휴 GPU (PR Newswire)를 포함하여 활용도가 낮은 자원에 대한 인프라 예산이 소개됩니다.
모든 엔지니어가 수동으로 자체 워크 벤치 인스턴스를 생성하면 Headcount의 오류 스케일 : 임의 영역, 잊혀진 자동 분쇄 및 과도한 권한이있는 서비스 계정.
이 기사의 목표는 수동 작업을 최소화하고 구성을 재현 가능하며 Vertex AI Workbench 용 CI 파이프 라인이있는 Terraform 모듈을 사용하여 유휴 폐기물을 줄이는 방법을 보여주는 것입니다.
2. 왜 정점 AI 워크 벤치
인프라가 이미 Google Cloud Ecosystem에 살고 있다면 Workbench는 Databricks, Sagemaker, Jupyterhub 및 기타보다 실질적인 이점을 제공합니다.
- GCP 내부에 머무르고 BigQuery, GCS, Vertex AI Pipelines, Artifact Registry, Google 표준 라이브러리를 통한 비밀 관리자-브릿지 또는 타사 커넥터가 없습니다.
- 추가 제어 평면 또는 관리자 콘솔은 없습니다 : 액세스, 네트워크, 비밀, 감사 및 청구는 기존 GCP 가드 레일에 남아 있습니다.
- Workbench는 ORG 정책을 상속받습니다 : IAM 역할, VPC 세분화, 개인 서비스 연결, VPC 서비스 제어, CMEK 및 클라우드 로깅의 중앙 집중식 감사 – 다른 곳에서는 정책을 복제하지 않습니다.
- 명확한 청구 및 비용 관리 : 단일 제공 업체 및 일관된 레이블을 사용하면 플랫폼에서 청구서를 분할하지 않고 예산 경고 및 비용 중심보고를 재사용 할 수 있습니다.
결론 : 인프라와 데이터가 이미 GCP에있는 경우 Vertex AI Workbench가 통합 및 운영 오버 헤드를 최소화하고 일관된 보안 정책을 시행하며 Terraform을 사용하여 자동화하는 빠른 경로를 제공합니다.
3. 실제로 UI 단점
UI를 통해 워크 벤치 인스턴스를 만들 때 발생한 일반적인 문제를 살펴 보겠습니다.
- 일관되지 않은 이름과 레이블. 사용자는 임의의 이름/태그를 설정하여 소유권, 프로젝트/비용 속성 및 충전 백을 신뢰할 수 없습니다.
- 지역/구역 드리프트. 인스턴스는 표준이없는 다른 영역/영역에 나타나 대기 시간이 증가하고 네트워킹을 복잡하게합니다.
- 유휴 화상. 자동 분쇄가 종종 잊혀집니다. 수동 종료는 일치하지 않습니다. 유휴 기계, 특히 GPU가있는 것은 직접 폐기물입니다.
- 과도한 SA 권한. 기본 서비스 계정에 의존하면 특권이 가장 적고 보안/규정 준수 위험이 증가합니다.
- 변화는 역사 나 재현성이 없습니다. 스크린 샷 및 수동 단계는 코드 검토되거나 차별화 될 수 없습니다. 사건 중 규정 준수를 입증하거나 구성하는 것은 어렵습니다.
Terraform은 이러한 문제를 해결합니다. 구성은 코드 검토 및 CI-Checked입니다. terraform plan 명확한 차이를 제공합니다. 모듈은 표준 (명명, 레이블, 지역, 자동 분리, SA 역할)을 인코딩하고 모든 인스턴스에 균일하게 적용합니다.
4. 노트북 관리 성숙도 모델
레벨 0 – 수동 UI
인스턴스와 그 매개 변수는 손으로 설정됩니다. (유일한) 이점은 빠른 초기 설정입니다. 단점 : 표준, 구성 드리프트, 지저분한 비용 속성 및 무거운 감사가 없습니다. 관용적으로 작동합니다
레벨 1 – Terraform (로컬 적용)
구성은 코드로 라이브입니다. terraform plan/apply 로컬로 실행됩니다. 환경을 쉽게 확장하고 재현 할 수 있으며 코드 검토를 수행하며 생성을 표준화합니다. 그러나 적용은 여전히 매뉴얼이므로 인간의 오류를위한 공간을 남깁니다. 5-20 명의 사용자에게 드물게 온 보딩을 제공합니다.
레벨 2 – TerraForm + CI/CD
plan/apply 자동화 된 정책/보안/비용 점검을 통해 파이프 라인 (Gitlab CI/CD 또는 이와 유사한)에서 실행됩니다. 기본 DevOps 연습 (원격 상태, OIDC/WIF, ENV 격리)이 필요합니다. > 20 명의 사용자와 정기 온 보딩을 사용하면 수동 수고 및 감사/규정 준수 부채를 피하기 위해이 접근법이 필수적입니다.
5. Terraform 접근
당신은 필요합니다 :
- Terraform (≥ 1.3)
- GCP 인증 (예 :
gcloud auth application-default login또는 서비스 계정) project,,,region/zone그리고google제공자 (≥ 4.0)
직접 인스턴스를 만들 수 있습니다 google_workbench_instance그러나 이로 인해 복제 (VPC/네트워크, 서비스 계정, 레이블, 자동 분쇄 정책, 지역/영역 등)가 빠르게 이어집니다. 모든 변경 사항은 비슷한 블록의 대량 업데이트가되어 검토 및 감사를 복잡하게 만듭니다.
대신 모듈을 사용하여 공통 매개 변수를 캡슐화하고 엔지니어가 실제로 필요한 최소 입력 만 노출시킵니다.
편의를 위해 예제 프로젝트 구조가 포함 된 저장소에 대한 링크가 있습니다.
모듈 구현
vertexai-workbench-module/main.tf:
resource "google_workbench_instance" "instance" {
for_each = var.notebook_instances
project = var.project_id
location = coalesce(each.value.zone, var.default_zone)
name = each.key
instance_owners = each.value.instance_owners
labels = var.labels
gce_setup {
machine_type = coalesce(each.value.machine_type, var.default_machine_type)
dynamic "accelerator_configs" {
for_each = each.value.accelerator_configs != null ? [each.value.accelerator_configs] : []
content {
type = accelerator_configs.value.type
core_count = accelerator_configs.value.core_count
}
}
disable_public_ip = true
shielded_instance_config {
enable_secure_boot = true
enable_vtpm = true
enable_integrity_monitoring = true
}
service_accounts {
email = var.service_account_email
}
boot_disk {
disk_size_gb = var.default_boot_disk_size_gb
disk_type = "PD_SSD"
}
data_disks {
disk_size_gb = coalesce(each.value.data_disk_size_gb, var.default_data_disk_size_gb)
disk_type = "PD_SSD"
}
metadata = {
terraform = "true",
idle-timeout-seconds = var.idle_timeout_seconds,
post-startup-script = var.post_startup_script,
report-event-health = "true",
report-dns-resolution = "true"
}
network_interfaces {
network = var.network_name
subnet = var.subnet_name
}
}
}
이제 필요한 변수를 선언하십시오 vertexai-workbench-module/variables.tf:
variable "notebook_instances" {
description = "Configuration for each notebook instance"
type = map(object({
zone = optional(string)
machine_type = optional(string)
instance_owners = list(string)
data_disk_size_gb = optional(number)
accelerator_configs = optional(object({
type = string
core_count = number
}))
}))
}
variable "labels" {
description = "instance labels"
type = map(string)
}
variable "default_zone" {
type = string
description = "Zone like us-central1-a"
validation {
condition = can(regex("^[a-z0-9-]+-[a-z0-9]+[0-9]-[a-z]$", var.default_zone))
error_message = "Use a zone format, e.g., us-central1-a."
}
}
variable "service_account_email" {
description = "Email of the service account"
type = string
}
variable "default_boot_disk_size_gb" {
description = "Default size in GB for boot disks if not specified."
type = number
default = 150
}
variable "default_data_disk_size_gb" {
description = "Default size in GB for data disks if not specified."
type = number
default = 150
}
variable "default_machine_type" {
description = "Default machine type if not specified."
type = string
default = "e2-standard-2"
}
variable "project_id" {
description = "The project ID"
type = string
}
variable "network_name" {
description = "The name of the network"
type = string
}
variable "subnet_name" {
description = "The name of the subnet"
type = string
}
variable "idle_timeout_seconds" {
type = number
description = "Idle timeout in seconds"
validation {
condition = var.idle_timeout_seconds >= 0
error_message = "idle_timeout_seconds must be >= 0."
}
}
variable "post_startup_script" {
description = "The post startup script"
type = string
}
사용 예제
여러 인스턴스 생성 :
module "vertex_instances" {
source = "./vertexai-workbench-module"
project_id = var.project_id
network_name = google_compute_network.my_network.name
subnet_name = google_compute_subnetwork.my_subnetwork.name
service_account_email = google_service_account.vertexai-workbench-sa.email
post_startup_script = "" # Optional path in gcs to script to run on instance startup. Example gs://your-bucket/init.sh
idle_timeout_seconds = 7200
labels = {
instance_type = "vertexai_workbench"
}
notebook_instances = {
"workbench-instance-analytics-team-user1" = {
instance_owners = ["[email protected]"]
},
"workbench-instance-analytics-team-user2" = {
instance_owners = ["[email protected]"]
machine_type = "n1-standard-8"
},
"workbench-instance-ml-team1-user3" = {
zone = "us-central1-a"
machine_type = "n1-highmem-8"
instance_owners = ["[email protected]"]
data_disk_size_gb = 500
accelerator_configs = {
type = "NVIDIA_TESLA_T4"
core_count = 1
}
},
}
}
모듈 매개 변수 팁
- 모듈의 모든 인스턴스에 대한 매개 변수 :
project_id,,,network_name,,,subnet_name,,,service_account_email,,,post_startup_script(환경 초기화에 유용함),idle_timeout_seconds,,,labels. - 인스턴스 당 필수 :지도 키 (인스턴스 이름이됩니다) 및
instance_owners. - 기본값이 정의 된 선택적 매개 변수
variables.tf:zone,,,machine_type,,,data_disk_size_gb,,,accelerator_configs.
따라서 UI 기반 생성에 비해 몇 가지 장점이 있습니다
- 통합 불이행 및 표준 : 네트워킹, 최소 사상가 SA, 자동 분쇄, 레이블, 차폐 VM.
- 간단한 확장 성 : 10-15 노트북의 대량 생성 또는 단일 MR에서 정책 변경을 시작합니다.
- 예측 가능한 변경 :
terraform plan투명한 차이를 제공하고 검토 및 롤백이 쉽습니다. - 감사 준비 : 모든 구성은 코드에 있습니다. 라벨과 iam은 통일되었습니다.
- 비용 관리 : 필수 레이블과 통일 된 유휴 정책은 유휴 지출을 줄입니다. 예산 경고는 연결하기 쉽습니다.
- 복잡성 캡슐화 : 모듈 사용자는 필요한 매개 변수 (이름, 크기, GPU)에서만 작동하며 다른 모든 것은 숨겨져 있습니다.
6. TerraForm + CI/CD를 통해 노트북 만들기
다음 개선은 모든 노트북 MR이 계획 → 검토 → 수동 배포없이 적용하는 파이프 라인입니다. 아래는 스프린트에 서서 정책과 수표로 강화할 수있는 gitlab 예입니다.
전제 조건 : 원격 Terraform 상태 및 GCP 액세스. 가장 빠른 시작점은 gitlab 파일 변수로 저장된 서비스 계정의 JSON 키입니다. SA_KEY주를 보유한 특정 GCS 버킷의 워크 벤치 및 스토리지 객체 사용자와 같은 역할과 같은 역할.
러너 이미지
가벼운 이미지를 만듭니다 gcloud 그리고 Terraform, 레지스트리로 밀어서 참조하십시오. image::
FROM google/cloud-sdk:slim
RUN apt-get update && apt-get install -y --no-install-recommends \
wget \
&& rm -rf /var/lib/apt/lists/*
RUN wget -O- | gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg \
&& echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/hashicorp.list \
&& apt update && apt install terraform
최소 Gitlab CI/CD 구성
두 단계 : plan 계획 아티팩트를 작성합니다. apply 기본 분기와 병합 한 후 정확한 계획을 적용합니다. plan 또한 MRS가 구성 및 구문을 검증하기 위해 실행됩니다.
default:
image: "your-image:latest" # your image with installed gcloud cli and terraform
before_script:
- gcloud auth activate-service-account --key-file="$SA_KEY"
- export GOOGLE_APPLICATION_CREDENTIALS="$SA_KEY"
variables:
TF_INPUT: "false"
stages:
- plan
- apply
plan-job:
stage: plan
script:
- terraform init -input=false
- terraform plan -out $CI_PROJECT_DIR/planfile --target=module.vertex_instances -compact-warnings | grep -v -e "Acquiring state lock" -e "Refreshing state"
artifacts:
paths:
- planfile
expire_in: 1 week
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event' || $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
changes:
- "vertexai-workbench-instances.tf"
apply-job:
stage: apply
script:
- terraform init -input=false
- terraform validate
- terraform apply -auto-approve -input=false $CI_PROJECT_DIR/planfile
rules:
- if: $CI_COMMIT_REF_NAME == "$CI_DEFAULT_BRANCH"
changes:
- "vertexai-workbench-instances.tf"
dependencies:
- plan-job
당신이 얻는 것
- 아티팩트로 계획
planfile일주일 동안 유지) 및 MR 로그 – 검토하기 쉽습니다. - 결정 론적 적용 – 동일한 planfile을 사용하여 드리프트 위험이 줄어 듭니다.
- 규칙/변경 – 노트북 구성이 변경 될 때만 작업이 트리거됩니다.
--target=module.vertex_instancesMonorepo에 편리합니다. 완전한 수렴을 원할 경우 제거하십시오.
엔지니어를 찾는 방법
- 기능 분기에서 모듈 블록을 추가하십시오 (예 :
name,,,machine_type,,,disk_size_gb) 안에vertexai-workbench-instances.tf. - MR을 여는 것은 구문 점검 및 계획을 실행하는 계획 작업을 트리거합니다.
- 승인 및 병합 후 CI 실행이 적용되고 인스턴스가 올바른 레이블, 네트워크 및 자동 분쇄와 함께 GCP에 나타납니다.
다음으로 팀이 성숙함에 따라 SA_KEY. 정책 검사 및 비용 문, 분할 프로젝트/상태/작업 공간을 추가하십시오 dev/stage/prod 코드 소유자를 구현합니다.
7. 결론
수동 UI에서 TerraForm 모듈 및 CI/CD로 이동하면 Vertex AI Workbench의 세 가지 핵심 문제가 해결됩니다. 재현 가능한 구성, 투명한 비용 관리 및 감사 준비 상태. 모듈은 네트워크/iam/유휴 복잡성을 숨기고 엔지니어가 필요로하는 매개 변수 만 노출시킵니다. 파이프 라인은 변화를 표준화하고 기록을 캡처합니다.
결과 : 수동 단계가 적고, 구성이 적 으면 예측 가능한 비용 및 팀과의 조정이있는 운영 모델.
Post Comment