株匏䌚瀟G-genのブログ - TECH PLAY

TECH PLAY

株匏䌚瀟G-gen

株匏䌚瀟G-gen の技術ブログ

å…š863ä»¶

圓蚘事では、Cloud Workflows ず Dataform を甚いおデヌタ分析パむプラむンを構築しおみたいず思いたす。 前提知識 Cloud Workflows Dataform ETL ず ELT 抂芁 今回の構成 Cloud Workflows のスコヌプ Dataform のスコヌプ 準備 ディレクトリ構造 main.tf gcf_source_code/etl_raw_data main.py requirements.txt gcf_source_code/etl_weather_data main.py requirements.txt source_data 実行 Terraform 実行 Dataform の蚭定 抂芁 difinitions/source/raw_data.sqlx difinitions/source/weather_data.sqlx difinitions/transform/mart_data.sqlx 動䜜怜蚌 怜蚌 1 怜蚌 2 怜蚌 3 クリヌンアップ 本番運甚時の考慮事項 ゚ラヌ発生時の通知機胜 再詊行時の考慮 前提知識 Cloud Workflows Cloud Workflows はGoogle Cloud のワヌクフロヌ管理サヌビスです。フルマネヌゞドか぀サヌバヌレスであるためむンフラの管理は必芁なく、たた非垞に安䟡に利甚できるのが特城です。 詳现に぀いおは、以䞋の蚘事をご参照䞋さい。 blog.g-gen.co.jp Dataform Dataform は、BigQuery のための SQL ワヌクフロヌ管理サヌビスです。フルマネヌゞドであり、Dataform の利甚自䜓は無料で利甚できる点が特城です。 詳现に぀いおは、以䞋の蚘事をご参照䞋さい。 blog.g-gen.co.jp ETL ず ELT ETL ず ELT はどちらもデヌタを倉換凊理する際の流れを説明しおいたす。 ETL は、Extract (抜出)、 Transform (倉換) 、Load (曞き出し) の順序でデヌタの倉換凊理を行いたす。䞻に、デヌタを利甚しやすい圢に倉換したり、DWH が読み蟌める圢に倉換しお DWH 等の分析基盀に栌玍する際に利甚したす。 ELT は、Extract (抜出)、 Load (曞き出し) 、Transform (倉換) の順序でデヌタの倉換凊理を行いたす。ETL は倉換凊理埌に DWH 等の分析基盀にデヌタをロヌドしたすが、ELT の堎合、先に DWH 等の分析基盀にデヌタをロヌドし、DWH 内でデヌタの倉換凊理を行いたす。 ETL ず ELT の違い 抂芁 今回の構成 BigQuery に分析察象のデヌタがある堎合、 Dataform を甚いるこずで BigQuery 内で耇数の SQL の䟝存関係を管理し぀぀デヌタ倉換 (ELT) を行うこずができたす。 しかし、デヌタレむクを Cloud Storage やオンプレミスに構えおおり、必芁に応じ分析察象のデヌタのみを BigQuery にむンポヌトするケヌスも倚いです。 その際、BigQuery にむンポヌトするデヌタが、BigQuery のデヌタの取り蟌み方匏に埓っおいる必芁があり、もし察応しおいない堎合はデヌタ転送時にデヌタの加工 (ETL) を行う必芁がありたす。 今回は、デヌタレむクず芋立おた Cloud Storage のデヌタを、䞀郚加工を行い BigQuery に栌玍埌、SQL を甚いおマヌトテヌブルを䜜成するデヌタパむプラむンのワヌクフロヌを構築したす。 今回構築する構成図 Cloud Workflows のスコヌプ Cloud Workflows では、疎結合になっおいる Cloud Functions (ETL 凊理甚) ず、Dataform (ELT 凊理甚) の䟝存関係を確立しながらワヌクフロヌを管理したす。 たずはじめに、parallel_step でそれぞれの Cloud Functions を䞊列で呌び出しおおりたす。Cloud Functions では、BigQuery に栌玍できる最䜎限のデヌタ倉換凊理を行うため、各 csv に察し以䞋の倉換凊理を行いたす。 カラム名を日本語からロヌマ字に倉換 日付のフォヌマットを YYYY/MM/DD から YYYY-MM-DD に倉換 次に、execute_elt で Dataform の呌び出しずステヌタス確認を行っおおりたす。ポむントは、Dataform の呌び出し ( create_workflow_invocation ) ずステヌタス確認 ( get_workflow_invocation ) は別の API 実行ずしお蚭定したす。理由は、Dataform の呌び出し API のレスポンスにもステヌタスは返っおきたすが、API 実行盎埌のステヌタスずなるため、SQL ワヌクフロヌの完了を埅たずすお RUNNING 等のステヌタスが返华されるケヌスがありたす。ステヌタス確認埌、ステヌタスの状態によっお条件分岐で凊理を分けおおりたす。 参考 Dataform ワヌクフロヌ呌び出し時のステヌタス䞀芧 Cloud Workflows で定矩したワヌクフロヌ図 Dataform のスコヌプ Dataform では、BigQuery に栌玍されたデヌタの倉換凊理 (SQL) における䟝存関係を管理したす。今回は怜蚌のため 2 ぀のテヌブルを結合しおマヌトテヌブルを䜜成する簡易的な倉換凊理を行っおおりたす。 Dataform 内の SQL ワヌクフロヌ 準備 ディレクトリ構造 開発環境は Cloud Shell を甚いお行いたす。ディレクトリ構造は以䞋のずおりです。 terraform ディレクトリ配䞋は、以䞋のずおりです。 terraform |-- gcf_source_code | |-- etl_raw_data | | |-- main.py | | `-- requirements.txt | ` -- etl_weather_data | |-- main.py | `-- requirements.txt | -- main.tf ` -- source_data |-- raw_data.csv `-- weather_data.csv main.tf main.tf には Terraform のコヌドを蚘述しおいたす。 locals { terraform_service_account = ${Terraform 実行に䜿われるサヌビスアカりントのメヌルアドレス} project_name = ${プロゞェクト名} project_id = ${プロゞェクト ID} folder_id = ${フォルダ ID} billing_account_id = ${請求先アカりント ID} } # terraform & provider の蚭定 terraform { required_providers { google = { source = "hashicorp/google" version = ">= 4.0.0" } } required_version = ">= 1.3.0" backend "gcs" { bucket = ${tfstate ファむルを栌玍する Cloud Storage バケット名} impersonate_service_account = ${Terraform 実行に䜿われるサヌビスアカりントのメヌルアドレス} } } # サヌビスアカりント暩限借甚の蚭定 provider "google" { alias = "impersonation" scopes = [ "https://www.googleapis.com/auth/cloud-platform", "https://www.googleapis.com/auth/userinfo.email", ] } data "google_service_account_access_token" "default" { provider = google.impersonation target_service_account = local.terraform_service_account scopes = ["userinfo-email", "cloud-platform"] lifetime = "1200s" } # Google プロバむダの蚭定 provider "google" { project = local.project_id region = "asia-northeast1" access_token = data.google_service_account_access_token.default.access_token request_timeout = "60s" } provider "google-beta" { project = local.project_id region = "asia-northeast1" access_token = data.google_service_account_access_token.default.access_token request_timeout = "60s" } ###################################### ### プロゞェクトの䜜成ず API の有効化 ### ###################################### # プロゞェクトの䜜成 resource "google_project" "poc" { name = local.project_name project_id = local.project_id folder_id = local.folder_id billing_account = local.billing_account_id } # API の有効化 module "tenant_a_project_services" { source = "terraform-google-modules/project-factory/google//modules/project_services" version = "14.2.1" # version = "~> 13.0" project_id = google_project.poc.project_id enable_apis = true activate_apis = [ "iam.googleapis.com", "cloudbuild.googleapis.com", "run.googleapis.com", "cloudfunctions.googleapis.com", "cloudscheduler.googleapis.com", "artifactregistry.googleapis.com", "workflows.googleapis.com", "bigquery.googleapis.com", "dataform.googleapis.com", ] disable_services_on_destroy = false } ####################################### ### サヌビスアカりントの䜜成ず暩限の付䞎 ## ####################################### # Dataform サヌビスアカりントに暩限付䞎 resource "google_project_iam_member" "bq_jobuser" { depends_on = [ module.tenant_a_project_services, google_dataform_repository.dataform_repository ] project = google_project.poc.project_id role = "roles/bigquery.jobUser" member = "serviceAccount:service-${google_project.poc.number}@gcp-sa-dataform.iam.gserviceaccount.com" } resource "google_project_iam_member" "bq_data_editer" { depends_on = [ module.tenant_a_project_services, google_dataform_repository.dataform_repository ] project = google_project.poc.project_id role = "roles/bigquery.dataEditor" member = "serviceAccount:service-${google_project.poc.number}@gcp-sa-dataform.iam.gserviceaccount.com" } # Cloud Functions 甚サヌビスアカりントの䜜成ず暩限付䞎 resource "google_service_account" "sa_gcf" { project = google_project.poc.project_id account_id = "sa-gcf" display_name = "Cloud Functions 甚サヌビスアカりント" } resource "google_project_iam_member" "invoke_gcf" { project = google_project.poc.project_id role = "roles/run.invoker" member = "serviceAccount:${google_service_account.sa_gcf.email}" } resource "google_project_iam_member" "bq_jobuser2" { project = google_project.poc.project_id role = "roles/bigquery.jobUser" member = "serviceAccount:${google_service_account.sa_gcf.email}" } resource "google_bigquery_dataset_iam_member" "source_dataset_viewer2" { project = google_project.poc.project_id dataset_id = google_bigquery_dataset.source_dataset.dataset_id role = "roles/bigquery.dataEditor" member = "serviceAccount:${google_service_account.sa_gcf.email}" } resource "google_bigquery_dataset_iam_member" "mart_dataset_viewer2" { project = google_project.poc.project_id dataset_id = google_bigquery_dataset.mart_dataset.dataset_id role = "roles/bigquery.dataEditor" member = "serviceAccount:${google_service_account.sa_gcf.email}" } resource "google_storage_bucket_iam_member" "source_data" { bucket = google_storage_bucket.source_data.name role = "roles/storage.admin" member = "serviceAccount:${google_service_account.sa_gcf.email}" } resource "google_storage_bucket_iam_member" "source_gcf" { bucket = google_storage_bucket.source_gcf.name role = "roles/storage.admin" member = "serviceAccount:${google_service_account.sa_gcf.email}" } # Cloud Workflows 甚サヌビスアカりント䜜成ず暩限付䞎 resource "google_service_account" "sa_wf" { project = google_project.poc.project_id account_id = "sa-cloud-wf" display_name = "Cloud Workflows 甚サヌビスアカりント" } resource "google_project_iam_member" "invoke_gcf2" { project = google_project.poc.project_id role = "roles/run.invoker" member = "serviceAccount:${google_service_account.sa_wf.email}" } resource "google_project_iam_member" "invoke_dataform" { project = google_project.poc.project_id role = "roles/dataform.editor" member = "serviceAccount:${google_service_account.sa_wf.email}" } # Cloud Scheduler 甚サヌビスアカりント䜜成ず暩限付䞎 resource "google_service_account" "sa_scheduler" { project = google_project.poc.project_id account_id = "sa-scheduler" display_name = "Cloud Scheduler 甚サヌビスアカりント" } resource "google_project_iam_member" "workflow_invoker" { project = google_project.poc.project_id role = "roles/workflows.invoker" member = "serviceAccount:${google_service_account.sa_scheduler.email}" } ################################ ### バケットずオブゞェクトの䜜成 ### ################################ # ゜ヌスデヌタ栌玍甚バケットの䜜成 resource "google_storage_bucket" "source_data" { project = google_project.poc.project_id location = "ASIA-NORTHEAST1" name = "${google_project.poc.project_id}-source-data" force_destroy = true } # ゜ヌスデヌタをバケットに远加 resource "google_storage_bucket_object" "source_raw_data" { name = "raw_data.csv" bucket = google_storage_bucket.source_data.name source = "source_data/raw_data.csv" content_type = "text/csv" } resource "google_storage_bucket_object" "source_weather_data" { name = "weather_data.csv" bucket = google_storage_bucket.source_data.name source = "source_data/weather_data.csv" content_type = "text/csv" } # Cloud Functions の゜ヌスコヌド栌玍甚バケットの䜜成 resource "google_storage_bucket" "source_gcf" { project = google_project.poc.project_id location = "ASIA-NORTHEAST1" name = "${google_project.poc.project_id}-source-gcf" force_destroy = true } # Cloud Functions で䜿う゜ヌスコヌドを ZIP 化 data "archive_file" "etl_raw_data" { type = "zip" source_dir = "./gcf_source_code/etl_raw_data" output_path = "./zip_source_code/etl_raw_data.zip" } data "archive_file" "etl_weather_data" { type = "zip" source_dir = "./gcf_source_code/etl_weather_data" output_path = "./zip_source_code/etl_weather_data.zip" } # ZIP 化した゜ヌスコヌドをバケットに远加 resource "google_storage_bucket_object" "etl_raw_data" { name = "etl-raw-data.${data.archive_file.etl_raw_data.output_md5}.zip" bucket = google_storage_bucket.source_gcf.name source = data.archive_file.etl_raw_data.output_path } resource "google_storage_bucket_object" "etl_weather_data" { name = "etl-weather-data.${data.archive_file.etl_weather_data.output_md5}.zip" bucket = google_storage_bucket.source_gcf.name source = data.archive_file.etl_weather_data.output_path } ################################ ### BigQuery デヌタセット䜜成 ### ################################ # デヌタセットの䜜成 resource "google_bigquery_dataset" "source_dataset" { project = google_project.poc.project_id dataset_id = "source_dataset" location = "asia-northeast1" delete_contents_on_destroy = true } resource "google_bigquery_dataset" "mart_dataset" { project = google_project.poc.project_id dataset_id = "mart_dataset" location = "asia-northeast1" delete_contents_on_destroy = true } ############################## ### Dataform リポゞトリ䜜成 ### ############################## # Dataform リポゞトリ䜜成 resource "google_dataform_repository" "dataform_repository" { provider = google-beta name = "dataform_repository" } ############################ ### Cloud Functions 䜜成 ### ############################ # etl_raw_data 関数の䜜成 resource "google_cloudfunctions2_function" "etl_raw_data" { name = "etl-raw-data" location = "asia-northeast1" build_config { runtime = "python310" entry_point = "excute_etl" # Set the entry point source { storage_source { bucket = google_storage_bucket.source_gcf.name object = google_storage_bucket_object.etl_raw_data.name } } } service_config { max_instance_count = 3 available_memory = "256M" timeout_seconds = 60 service_account_email = google_service_account.sa_gcf.email environment_variables = { BUCKET_NAME = google_storage_bucket.source_data.name FILE_PATH = google_storage_bucket_object.source_raw_data.name DATASET_ID = google_bigquery_dataset.source_dataset.dataset_id TABLE_ID = "raw_data" } } } # etl_weather_data 関数の䜜成 resource "google_cloudfunctions2_function" "etl_weather_data" { name = "etl-weather-data" location = "asia-northeast1" build_config { runtime = "python310" entry_point = "excute_etl" # Set the entry point source { storage_source { bucket = google_storage_bucket.source_gcf.name object = google_storage_bucket_object.etl_weather_data.name } } } service_config { max_instance_count = 3 available_memory = "256M" timeout_seconds = 60 service_account_email = google_service_account.sa_gcf.email environment_variables = { BUCKET_NAME = google_storage_bucket.source_data.name FILE_PATH = google_storage_bucket_object.source_weather_data.name DATASET_ID = google_bigquery_dataset.source_dataset.dataset_id TABLE_ID = "weather_data" } } } ############################ ### Cloud Scheduler 䜜成 ### ############################ # Cloud Scheduler の䜜成 resource "google_cloud_scheduler_job" "cron" { name = "cron" region = "asia-northeast1" schedule = "0 10 * * MON-FRI" # Run the job every weekday at 10:00 AM time_zone = "Asia/Tokyo" http_target { http_method = "POST" uri = "https://workflowexecutions.googleapis.com/v1/projects/${local.project_id}/locations/${google_workflows_workflow.etl_and_elt.region}/workflows/${google_workflows_workflow.etl_and_elt.name}/executions" oauth_token { service_account_email = google_service_account.sa_scheduler.email } body = base64encode(jsonencode({ "argument": jsonencode({ "raw_data_gcf_url" = "${google_cloudfunctions2_function.etl_raw_data.service_config[0].uri}", "weather_data_dcf_url" = "${google_cloudfunctions2_function.etl_weather_data.service_config[0].uri}", "project_id" = "${google_project.poc.project_id}", "repository" = "projects/${google_project.poc.project_id}/locations/asia-northeast1/repositories/${google_dataform_repository.dataform_repository.name}" }) })) headers = { "Content-Type" = "application/json" } } retry_config { retry_count = 3 } } ############################ ### Cloud Workflows 䜜成 ### ############################ # Cloud Workflows の䜜成 resource "google_workflows_workflow" "etl_and_elt" { name = "daily-workflows" region = "asia-northeast1" service_account = google_service_account.sa_wf.email source_contents = <<-EOF main: params: [args] steps: - init: assign: - repository: $${args.repository} - raw_data_gcf_url: $${args.raw_data_gcf_url} - weather_data_dcf_url: $${args.weather_data_dcf_url} - parallel_step: parallel: branches: - etl_01: steps: - etl_raw_data: call: http.post args: url: $${raw_data_gcf_url} auth: type: OIDC result: run_name - etl_02: steps: - etl_weather_data: call: http.post args: url: $${weather_data_dcf_url} auth: type: OIDC result: run_name - execute_elt: steps: - create_compilation_result: call: http.post args: url: $${"https://dataform.googleapis.com/v1beta1/" + repository + "/compilationResults"} auth: type: OAuth2 body: gitCommitish: main result: compilationResult - create_workflow_invocation: call: http.post args: url: $${"https://dataform.googleapis.com/v1beta1/" + repository + "/workflowInvocations"} auth: type: OAuth2 body: compilation_result: $${compilationResult.body.name} result: workflowInvocation - complete: return: $${workflowInvocation.body.name} EOF } gcf_source_code/etl_raw_data main.py gcf_source_code/etl_raw_data には、Cloud Storage バケットに栌玍された raw_data.cev の ETL 凊理を行う Cloud Functions の゜ヌスコヌドを栌玍しおいたす。 import os import functions_framework from io import BytesIO import pandas as pd from google.cloud import storage from google.cloud import bigquery BUCKET_NAME = os.environ.get( "BUCKET_NAME" ) FILE_PATH = os.environ.get( "FILE_PATH" ) DATASET_ID = os.environ.get( "DATASET_ID" ) TABLE_ID = os.environ.get( "TABLE_ID" ) try : # クラむアントをむンスタンス化 storage_client = storage.Client() bigquery_client = bigquery.Client() except Exception as e: print (f "An error occurred: {e}" ) raise e def extract (): try : # バケットを取埗 bucket = storage_client.get_bucket(BUCKET_NAME) # BLOB を構成 blob = bucket.blob(FILE_PATH) # オブゞェクトのデヌタを取埗 content = blob.download_as_bytes() except Exception as e: print (f "An error occurred: {e}" ) raise e # デヌタフレヌムを䜜成 df = pd.read_csv(BytesIO(content)) return df def transform (df): # カラム名を倉曎 df = df.rename(columns = { "日付" : "date" , "デバむスID" : "device_id" , "発電量" : "electric_generating_capacity" , "郜道府県" : "prefectures" }) # 日付のフォヌマットを倉曎 df[ "date" ] = pd.to_datetime(df[ "date" ]).dt.strftime( "%Y-%m-%d" ) return df def load (df): try : # テヌブル情報を取埗 table_ref = bigquery_client.dataset(DATASET_ID).table(TABLE_ID) # BigQueryテヌブルぞデヌタを挿入 job = bigquery_client.load_table_from_dataframe(df, table_ref) # 結果を確認 job.result() except Exception as e: print (f "An error occurred: {e}" ) raise e print ( "Loaded dataframe to {}" .format(table_ref.path)) return table_ref.path @ functions_framework.http def excute_etl (request): df = extract() df_after_dransform = transform(df) path = load(df_after_dransform) return path requirements.txt functions-framework==3.* bytesbufio==1.0.3 pandas==2.0.3 google-cloud-storage==2.10.0 google-cloud-bigquery==3.11.3 pyarrow==12.0.1 gcf_source_code/etl_weather_data main.py gcf_source_code/etl_weather_data には、Cloud Storage バケットに栌玍された weather_data.cev の ETL 凊理を行う Cloud Functions の゜ヌスコヌドを栌玍しおいたす。 import os import functions_framework from io import BytesIO import pandas as pd from google.cloud import storage from google.cloud import bigquery BUCKET_NAME = os.environ.get( "BUCKET_NAME" ) FILE_PATH = os.environ.get( "FILE_PATH" ) DATASET_ID = os.environ.get( "DATASET_ID" ) TABLE_ID = os.environ.get( "TABLE_ID" ) try : # クラむアントをむンスタンス化 storage_client = storage.Client() bigquery_client = bigquery.Client() except Exception as e: print (f "An error occurred: {e}" ) raise e def extract (): try : # バケットを取埗 bucket = storage_client.get_bucket(BUCKET_NAME) # BLOB を構成 blob = bucket.blob(FILE_PATH) # オブゞェクトのデヌタを取埗 content = blob.download_as_bytes() except Exception as e: print (f "An error occurred: {e}" ) raise e # デヌタフレヌムを䜜成 df = pd.read_csv(BytesIO(content)) return df def transform (df): # カラム名を倉曎 df = df.rename(columns = { "日付" : "date" , "郜道府県" : "prefectures" , "æ°—æž©" : "temperature" , "降氎量" : "precipitation" }) # 日付のフォヌマットを倉曎 df[ "date" ] = pd.to_datetime(df[ "date" ]).dt.strftime( "%Y-%m-%d" ) return df def load (df): try : # テヌブル情報を取埗 table_ref = bigquery_client.dataset(DATASET_ID).table(TABLE_ID) # BigQueryテヌブルぞデヌタを挿入 job = bigquery_client.load_table_from_dataframe(df, table_ref) # 結果を確認 job.result() except Exception as e: print (f "An error occurred: {e}" ) raise e print ( "Loaded dataframe to {}" .format(table_ref.path)) return table_ref.path @ functions_framework.http def excute_etl (request): df = extract() df_after_dransform = transform(df) path = load(df_after_dransform) return path requirements.txt functions-framework==3.* bytesbufio==1.0.3 pandas==2.0.3 google-cloud-storage==2.10.0 google-cloud-bigquery==3.11.3 pyarrow==12.0.1 source_data source_data には、Cloud Storage に栌玍する raw_data.csv ず weather_data.csv をそれぞれ配眮したす。 察象の csv は、以䞋のスプレッドシヌトからダりンロヌドが可胜です。 ブログ甚ダミヌデヌタ ブログ甚ダミヌデヌタ 実行 Terraform 実行 Cloud Shell のタヌミナルで terraform ディレクトリに移動し、 terraform init で初期化を行い、 terraform plan 問題なければ terraform apply でデプロむを行いたす。 Dataform の蚭定 抂芁 今回、Terraform では Dataform のリポゞトリ䜜成たでを行いたしたが sqlx ファむルの䜜成はできおいないため、コン゜ヌルから以䞋の手順で sqlx ファむルを䜜成しリポゞトリを完成させおいきたす。 Dataform > 䜜成したリポゞトリ をクリック > 開発ワヌクスペヌスを䜜成 をクリック 任意のワヌクスペヌス名を入力しお 䜜成 をクリック 2 で䜜成したワヌクスペヌスを遞択しお ワヌクスペヌスを初期化 をクリック ワヌクスペヌスの初期化を行うず以䞋のようなファむル矀が自動生成されたす。 開発ワヌクスペヌスの初期化埌ファむル矀 definitions ディレクトリ内に sqlx ファむルを䜜成し、SQL ワヌクフロヌを定矩しおいきたす。definitions ディレクトリ配䞋を以䞋の構成に倉曎しおください。 修正埌の開発ワヌクスペヌスファむル矀 各ファむルの䞭身を以䞋のように蚘述したす。 difinitions/source/raw_data.sqlx config { type: "declaration", database: ${BigQuery が属するプロゞェクト ID}, schema: "source_dataset", name: "raw_data", } 参考 Dataform 培底解説 デヌタ゜ヌスの宣蚀 difinitions/source/weather_data.sqlx config { type: "declaration", database: ${BigQuery が属するプロゞェクト ID}, schema: "source_dataset", name: "weather_data", } difinitions/transform/mart_data.sqlx config { type: "table", schema: "mart_dataset", } SELECT A.date, A.device_id, A.electric_generating_capacity, A.prefectures, B.temperature, B.Precipitation FROM ${ref("raw_data")} as A LEFT JOIN ${ref("weather_data")} as B ON A.date = B.date AND A.prefectures = B.prefectures ファむル修正埌は、 COMMIT ずフォルトブランチぞの PUSH を行っおください。 動䜜怜蚌 怜蚌 1 怜蚌 1 は、そのたた実行しおみたす。尚、今回は、Cloud Scheduler を手動で匷制実行しおいきたいず思いたす。 コン゜ヌルにお、Cloud Scheduler > 䜜成したゞョブの 操䜜 から 匷制実行 をクリックしたす。 Cloud Scheduler のコン゜ヌル画面 するず、Cloud Workflows がトリガヌされ実行されたす。以䞋が Cloud Workflows の実行詳现画面です。 Cloud Workflows のワヌクフロヌが成功したこずが確認できたした。 [怜蚌1] Cloud Workflows の実行詳现画面 たた、以䞋が Dataform の実行詳现画面です。Dataform も無事成功したこずが確認できたした。 Dataform の実行詳现画面 䞀連のワヌクフロヌが完了したこずが確認できたため、最埌に BigQuery 䞊でマヌトテヌブルが䜜成できおいるか確認したす。 BigQuery のコン゜ヌル画面 無事マヌトテヌブルも䜜成できおいたした。 [怜蚌1] Cloud Workflows のワヌクフロヌ図 怜蚌 2 怜蚌 2 では、Cloud Storage バケット䞊の raw_data.csv ファむルを削陀しおから、Cloud Scheduler を匷制実行しおみたす。 以䞋が Cloud Workflows の実行詳现画面です。Cloud Functions を実行しおいる parallel_step で゚ラヌが発生したので、想定通りの挙動を確認できたした。 [怜蚌2] Cloud Workflows 実行詳现画面 [怜蚌2] Cloud Workflows のワヌクフロヌ図 怜蚌 3 怜蚌 3 では、Cloud Storage バケット䞊のファむルを怜蚌 1 の状態に戻し、Dataform 䞊の definitions/source/raw_data.sqlx ファむルを以䞋のように存圚しない schema に曞き換えおみたす。 config { type: "declaration", database: "matayuuu-etl-elt", schema: "hoge_dataset", name: "raw_data", } ファむル修正埌は、COMMIT ずフォルトブランチぞの PUSH を行い、Cloud Scheduler を匷制実行しおみたす。 以䞋が Cloud Workflows の実行詳现画面です。Dataform のステヌタス確認を行っおいる check_if_complete で゚ラヌが発生したので、想定通りの挙動を確認できたした。 [怜蚌3] Cloud Workflows の実行詳现画面 [怜蚌3] Cloud Workflows のワヌクフロヌ図 クリヌンアップ Dataform の開発ワヌクスペヌスを削陀し、䜜成した Terraform を destroy コマンドで削陀したす。 BigQuery > Dataform > リポゞトリを遞択し、 手動で䜜成した開発ワヌクスペヌス を削陀 Cloud Shell にお terraform destroy を実行 本番運甚時の考慮事項 ゚ラヌ発生時の通知機胜 今回は怜蚌のため Cloud Workflows が゚ラヌになっおもメヌルや Slack 通知等で管理者ぞ通知する仕組みは䜜っおおりたせんが、本番運甚時にぱラヌ発生時に即座に察応できるようにしおおくずよいでしょう。 䟋えば、Cloud Workflows のログは Cloud Logging ず連携しおいるため、 ログベヌスのアラヌト を構成するこずで容易に゚ラヌ怜知ができたす。 再詊行時の考慮 䜕らかの理由で Cloud Workflows のワヌクフロヌや Dataform の SQL ワヌクフロヌが途䞭で倱敗した際に、それぞれのワヌクフロヌを再実行しおも同じ結果を埗るように蚭蚈しおおくこずが重芁ずなりたす。 そこで䜿われるのが 冪等性 の担保です。䜕床繰り返しおも、い぀実行しおも、特定の入力セットに察しお同じ動䜜をするこずを冪等性が保たれおいる状態です。 その他にも、可胜であればチェックポむントを蚭定するこずで、ワヌクフロヌが再開された際に、最初からゞョブを再開するのではなく、䞭断したずころから再開できるようにする方法も怜蚎しおみるず良いでしょう。 参考 Jobs retries and checkpoints best practices G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の䜐々朚です。圓蚘事では Google Kubernetes Engine以䞋、GKEで 予備の容量プロビゞョニングspare capacity provisioning を䜿甚するこずで、ワヌクロヌドを玠早くスケヌルアりトする方法を解説したす。 GKE ずは ノヌドの自動プロビゞョニングを䜿甚したスケヌルアりトの問題点 予備の容量プロビゞョニングに぀いお 予備の容量プロビゞョニングの抂芁 䞀貫した容量のプロビゞョニング 単䞀むベント容量のプロビゞョニング 2 ぀の方法の比范 予備の容量プロビゞョニングを䜿甚する 䜿甚するマニフェストファむル priorityclasses.yaml test-deployment.yaml capacity-res-deployment.yaml䞀貫した容量のプロビゞョニングで䜿甚 capacity-res-job.yaml単䞀むベント容量のプロビゞョニングで䜿甚 GKE クラスタの䜜成 予備の容量プロビゞョニングを䜿甚しない堎合 䞀貫した容量のプロビゞョニングを䜿甚する PriorityClass オブゞェクトを䜜成する プレヌスホルダ Pod をデプロむする ワヌクロヌド甚 Pod のデプロむ 単䞀むベント容量のプロビゞョニングを䜿甚する ノヌドの初期状態を確認する PriorityClass オブゞェクトを䜜成する プレヌスホルダ Pod をデプロむする ワヌクロヌド甚 Pod のデプロむ Google Kubernetes EngineGKE) GKE ずは GKE はコンテナオヌケストレヌションツヌルである Kubernetes を、Google マネヌゞドのクラスタで䜿甚するこずができるサヌビスです。 GKE ではノヌドの管理をナヌザヌが行うこずで柔軟な芁件に察応できる Standard モヌド のクラスタず、ノヌドの管理を Google に任せ、ワヌクロヌドの管理のみに集䞭するこずができる Autopilot モヌド のクラスタを遞択するこずができたす。 GKE の詳现に぀いおは以䞋の蚘事で解説しおいたす。 blog.g-gen.co.jp ノヌドの自動プロビゞョニングを䜿甚したスケヌルアりトの問題点 ノヌドの自動プロビゞョニング が有効化されおいる GKE クラスタでは、Pod がスケヌルアりトするずき、既存のノヌドに新しい Pod を起動するための容量がない堎合に新しいノヌドが自動で䜜成されたす。 しかし、新しいノヌドの起動には玄 80 秒 ~ 120 秒かかるため、急激なトラフィック増加などに玠早く察応できない堎合がありたす。 ノヌドの起動埅ちでワヌクロヌドのスケヌルアりトに時間がかかる 特に Autopilot モヌドのクラスタでは、ノヌドのコンピュヌティングリ゜ヌス量をナヌザヌが指定するこずができないため、スケヌルアりト時のリ゜ヌス䜿甚量を考慮しおノヌドのマシンタむプを蚭定したり、事前にノヌド数を増やしおおいたりしお察策するこずが難しくなっおいたす。 圓蚘事では、事前にノヌド数を増やしおおき Pod をすぐに起動できるようにする方法ずしお、 予備の容量プロビゞョニング を䜿甚したす。圓機胜は Autopilot クラスタず Standard クラスタの䞡方で利甚可胜です。 予備の容量プロビゞョニングに぀いお 予備の容量プロビゞョニングの抂芁 予備の容量プロビゞョニング では、Kubernetes の PriorityClass オブゞェクトを䜿甚し、䞀定数の 優先床の䜎い Pod をノヌドで実行したす。こうするこずで予めノヌドを増やしおおくこずができ、ワヌクロヌドの Pod がスケヌルアりトする際に、優先床の䜎い Pod を終了しおワヌクロヌドの Pod に眮き換えるこずができたす。 ここで䜿甚する優先床の䜎い Pod は プレヌスホルダ Pod 、たたは バルヌン Pod ず呌ばれたす。圓蚘事では公匏ドキュメントに埓いプレヌスホルダ Pod ず蚘茉したす。 プレヌスホルダ Pod を䜿甚しおワヌクロヌドのスケヌルアりトを高速化する 予備の容量プロビゞョニングでは、プレヌスホルダ Pod の実行の仕方によっお、 䞀貫した容量のプロビゞョニング ず 単䞀のむベント容量のプロビゞョニング の 2皮類の方法を䜿うこずができたす。 参考 Pod の迅速なスケヌリングのために远加のコンピュヌティング容量をプロビゞョニングする 䞀貫した容量のプロビゞョニング 䞀貫した容量のプロビゞョニング では、Deployment を䜿甚するこずで、クラスタ内で垞に実行されるプレヌスホルダ Pod を配眮したす。 プレヌスホルダ Pod の実行に必芁な容量だけノヌドがプロビゞョニングされ、ワヌクロヌドのスケヌルアりトが必芁になった際はプレヌスホルダ Pod に眮き換える圢で Pod を远加するこずができたす。 プレヌスホルダ Pod はワヌクロヌドの Pod に眮き換えられたすが、Deployment を䜿甚しおデプロむされおいるために、䞀床ワヌクロヌドの Pod に眮き換えられたあず、プレヌスホルダ Pod の数を維持しようずしたす。そのため、GKE クラスタは新たなノヌドを远加しおプレヌスホルダ Pod を再䜜成したす。 したがっお、クラスタにはワヌクロヌドを実行するために必芁な容量よりも倚くの容量が垞に確保される点には泚意が必芁です。 䞀貫した容量のプロビゞョニングを䜿甚した堎合のスケヌルアりト動䜜のむメヌゞ 単䞀むベント容量のプロビゞョニング 単䞀むベント容量のプロビゞョニング では、Job を䜿甚するこずで特定の期間だけプレヌスホルダ Pod を起動し、その実行に必芁な容量だけノヌドをプロビゞョニングしたす。 ワヌクロヌドのスケヌルアりトが必芁になるず、プレヌスホルダ Pod がワヌクロヌドの Pod ず眮き換わる点は䞀貫した容量のプロビゞョニングず同様ですが、Job で実行されおいるため、眮き換わったあずに Pod が再䜜成されるこずはありたせん。 単䞀むベント容量のプロビゞョニングを䜿甚した堎合のスケヌルアりト動䜜のむメヌゞ 2 ぀の方法の比范 プレヌスホルダ Pod の䜜成に Job を䜿甚する堎合単䞀むベント容量のプロビゞョニングは Deployment を䜿甚する堎合䞀貫した容量のプロビゞョニングずは異なり、終了したプレヌスホルダ Pod を再䜜成するような動䜜はしないため、プレヌスホルダ Pod の再䜜成するためにノヌドが远加されるこずはありたせん。したがっお、プレヌスホルダ Pod 甚に確保される容量は Job を䜿甚したほうが抑えられたす。 GKE の Standard モヌドでは起動しおいるノヌドあたりの時間料金、Autopilot モヌドでは Pod がリク゚ストしおいるリ゜ヌス量あたりの時間料金が発生するため、必芁なずきだけプレヌスホルダ Pod を実行するほうにコストメリットがありたす。 ただし、Job を䜿甚する堎合はワヌクロヌドがスケヌルアりトするタむミングをある皋床は把握しおおき、それに合わせお Job を䜜成しおおく必芁がありたす。たた、䞀床眮き換えられたプレヌスホルダ Pod は再䜜成されないため、䞀日に䜕床もスケヌリングをする必芁があるワヌクロヌドの堎合には向きたせん。Deployment を䜿甚しおいればプレヌスホルダ Pod は垞に存圚するため、ワヌクロヌドがスケヌルアりトする䜙裕を持ち続けるこずができたす。 予備の容量プロビゞョニングを䜿甚する ここからは、予備の容量プロビゞョニングを䜿甚するこずで、Pod の起動時間が改善されるかどうかを怜蚌したす。 䜿甚するマニフェストファむル 圓蚘事で䜿甚するマニフェストファむルは、 公匏ドキュメント に蚘茉されおいるものを参考にしおいたす。 priorityclasses.yaml Pod に玐付けるこずができる PriorityClass オブゞェクトを 2぀䜜成するマニフェストファむルです。 優先床は value フィヌルドに蚭定し、数倀が倧きいほど Pod の実行優先床が高くなりたす。 # priorityclasses.yaml apiVersion : scheduling.k8s.io/v1 kind : PriorityClass metadata : name : low-priority value : -10 # この PriorityClass を䜿甚する Pod の優先床倀が小さいほど優先床が䜎い preemptionPolicy : Never # この PriorityClass を䜿甚する Pod は、これより優先床の䜎い Pod を削陀しない=Never globalDefault : false description : "Low priority workloads" --- apiVersion : scheduling.k8s.io/v1 kind : PriorityClass metadata : name : default-priority value : 0 # この PriorityClass を䜿甚する Pod の優先床 preemptionPolicy : PreemptLowerPriority # この PriorityClass を䜿甚する Pod は、これより優先床の䜎い Pod を削陀する=PreemptLowerPriority globalDefault : true # Pod に PriorityClass が明瀺的に蚭定されおいない堎合、これをデフォルトの PriorityClass ずする description : "The global default priority." 1぀目の PriorityClass は䜎優先床のプレヌスホルダ Pod に玐付けるもので、優先床の倀が -10 に蚭定されおいたす。 2぀目の PriorityClass は globalDefault フィヌルドの倀が true に蚭定されおおり、GKE クラスタにデプロむされる Pod にデフォルトで玐付けられたす。 preemptionPolicy フィヌルドの倀が PreemptLowerPriority に蚭定されおいるため、この PriorityClass が玐付いた Pod が起動する際にノヌドの容量が足りおいないず、優先床がより䜎い Pod を削陀しおから起動するように動䜜したす。 test-deployment.yaml このマニフェストファむルでは、ワヌクロヌドの Pod を想定したサンプルの Pod を 5 ぀実行する Deployment を䜜成したす。 PriorityClass を指定しおいないため、 priorityclasses.yaml により䜜成された PriorityClass がある堎合、これらの Pod の優先床は 0 ずなりたす。 # test-deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : helloweb labels : app : hello spec : replicas : 5 selector : matchLabels : app : hello tier : web template : metadata : labels : app : hello tier : web spec : containers : - name : hello-app image : us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 ports : - containerPort : 8080 resources : requests : cpu : 400m memory : 400Mi capacity-res-deployment.yaml䞀貫した容量のプロビゞョニングで䜿甚 プレヌスホルダ Pod を䜜成するためのマニフェストファむルでは、 priorityClassName に䜎優先床の PriorityClass を指定し、10 個の Pod が優先床 -10 で䜜成されるようにしたす。 これらの Pod はノヌドの容量を予め確保しおおき、ワヌクロヌドのスケヌルアりトが必芁になったずき、ワヌクロヌドの Pod ず眮き換わりたす。 # capacity-res-deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : capacity-res-deploy spec : replicas : 10 selector : matchLabels : app : reservation template : metadata : labels : app : reservation spec : priorityClassName : low-priority # 䜎優先床の PriorityClass を指定 terminationGracePeriodSeconds : 0 containers : - name : ubuntu image : ubuntu command : [ "sleep" ] args : [ "infinity" ] resources : requests : cpu : 500m memory : 500Mi capacity-res-job.yaml単䞀むベント容量のプロビゞョニングで䜿甚 単䞀むベント容量のプロビゞョニングでは Job を䜿甚しおプレヌスホルダ Pod を実行したす。 このマニフェストファむルでは䜎優先床の Pod を Job ずしお実行し、ワヌクロヌド甚の Pod による眮き換えが起こるか sleep コマンドの凊理が終わる10時間が経過するず Pod が削陀されたす。 # capacity-res-job.yaml apiVersion : batch/v1 kind : Job metadata : name : capacity-res-job spec : parallelism : 10 backoffLimit : 0 template : spec : priorityClassName : low-priority terminationGracePeriodSeconds : 0 containers : - name : ubuntu-container image : ubuntu command : [ "sleep" ] args : [ "36000" ] resources : requests : cpu : 500m restartPolicy : Never GKE クラスタの䜜成 以䞋のコマンドを䜿甚しお、怜蚌甚のクラスタを䜜成したす。 圓蚘事では Autopilot モヌドのクラスタを䜿甚しおいきたす。 # Autopilot モヌドの GKE クラスタを䜜成する $ gcloud container clusters create-auto {クラスタ名} \ --region={リヌゞョン} \ --project={プロゞェクトID} 参考 Autopilot クラスタの䜜成 予備の容量プロビゞョニングを䜿甚しない堎合 たず、予備の容量プロビゞョニングを䜿甚しない堎合のワヌクロヌド甚 Pod の起動時間を蚈枬しおみたす。 䜜成した GKE クラスタのノヌドの初期状態を確認したす。 # ノヌドの状態を確認 $ kubectl get nodes # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-69f9cf5d-m972 Ready <none> 74m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-b9c30e3b-z2jn Ready <none> 74m v1.26.5-gke.1200 次に、Pod の起動時間を確認するために、 kubectl get pods コマンドで --watch オプションを䜿甚しお Pod のステヌタスをモニタリングしたす。 # Pod のステヌタスをモニタリングする $ kubectl get pods -w 別のタヌミナルから test-deployment.yaml をクラスタに適甚し、ワヌクロヌド甚の Pod をデプロむしたす。 # Pod のデプロむ別のタヌミナルで実斜 $ kubectl apply -f test-deployment.yaml 最初のタヌミナルで Pod のステヌタスをモニタリングしおいるため、各 Pod の STATUS 列が Running になるたで埅機したす。 今回の怜蚌時の出力を以䞋に蚘茉したす。Pod がすべお実行されるたで、2分 30秒ほど芁したこずがわかりたす。 # 出力䟋 $ kubectl get pods -w NAME READY STATUS RESTARTS AGE helloweb-75f7cfd4f7-mnn8f 0/1 Pending 0 1s helloweb-75f7cfd4f7-mnn8f 0/1 Pending 0 1s helloweb-75f7cfd4f7-gz58p 0/1 Pending 0 0s helloweb-75f7cfd4f7-gz58p 0/1 Pending 0 0s helloweb-75f7cfd4f7-hhf62 0/1 Pending 0 0s helloweb-75f7cfd4f7-hhf62 0/1 Pending 0 0s helloweb-75f7cfd4f7-sng6f 0/1 Pending 0 0s helloweb-75f7cfd4f7-6j9sx 0/1 Pending 0 0s helloweb-75f7cfd4f7-sng6f 0/1 Pending 0 0s helloweb-75f7cfd4f7-6j9sx 0/1 Pending 0 0s helloweb-75f7cfd4f7-mnn8f 0/1 Pending 0 77s helloweb-75f7cfd4f7-gz58p 0/1 Pending 0 76s helloweb-75f7cfd4f7-hhf62 0/1 Pending 0 76s helloweb-75f7cfd4f7-sng6f 0/1 Pending 0 76s helloweb-75f7cfd4f7-6j9sx 0/1 Pending 0 76s helloweb-75f7cfd4f7-mnn8f 0/1 ContainerCreating 0 77s helloweb-75f7cfd4f7-gz58p 0/1 ContainerCreating 0 76s helloweb-75f7cfd4f7-hhf62 0/1 ContainerCreating 0 76s helloweb-75f7cfd4f7-sng6f 0/1 Pending 0 82s helloweb-75f7cfd4f7-6j9sx 0/1 Pending 0 82s helloweb-75f7cfd4f7-sng6f 0/1 ContainerCreating 0 82s helloweb-75f7cfd4f7-6j9sx 0/1 ContainerCreating 0 82s helloweb-75f7cfd4f7-mnn8f 1/1 Running 0 2m18s helloweb-75f7cfd4f7-gz58p 1/1 Running 0 2m20s helloweb-75f7cfd4f7-hhf62 1/1 Running 0 2m23s helloweb-75f7cfd4f7-sng6f 1/1 Running 0 2m25s helloweb-75f7cfd4f7-6j9sx 1/1 Running 0 2m30s 次に、ノヌドのスケヌルアりトが行われたかどうかを確認したす。 ワヌクロヌドの Pod を実行するために 2぀のノヌドが远加されおいるこずがわかりたす。ノヌドの远加を埅っおから Pod が起動されるため、ノヌドの远加埅ち時間だけ Pod の起動に時間がかかっおしたっおいたす。 # ノヌドの数を確認する $ kubectl get nodes # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-69f9cf5d-m972 Ready <none> 79m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-b9c30e3b-z2jn Ready <none> 79m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-5d602c8d-zwcp Ready <none> 2m29s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-ed49f4e8-cgbn Ready <none> 2m25s v1.26.5-gke.1200 Pod を削陀し、ノヌドの数が元に戻るたで埅機したす。 # Pod を削陀する $ kubectl delete -f test-deployment.yaml # ノヌド数が元に戻ったこずを確認 $ kubectl get nodes # 出力䟋 $ kubectl get nodes $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-69f9cf5d-m972 Ready <none> 85m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-b9c30e3b-z2jn Ready <none> 85m v1.26.5-gke.1200 䞀貫した容量のプロビゞョニングを䜿甚する たず、䞀貫した容量のプロビゞョニングを䜿甚しおみたす。 この方法では、Deployment によっおクラスタ䞊でプレヌスホルダ Pod が垞に実行されるようにしたす。 PriorityClass オブゞェクトを䜜成する Pod に優先床を蚭定するために PriorityClass オブゞェクトを䜜成したす。 クラスタに priorityclasses.yaml を適甚したす。 # PriorityClass のマニフェストを適甚する $ kubectl apply -f priorityclasses.yaml プレヌスホルダ Pod をデプロむする capacity-res-deployment.yaml をクラスタに適甚し、プレヌスホルダ Pod を䜜成したす。 プレヌスホルダ Pod が党お䜜成されるたで埅機したす。 # プレヌスホルダ Pod のマニフェストを適甚する $ kubectl apply -f capacity-res-deployment.yaml # プレヌスホルダ Pod のステヌタスを確認する $ kubectl get pods # 出力䟋 $ kubectl get pods NAME READY STATUS RESTARTS AGE capacity-res-deploy-74b9b79578-4cvms 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-85tgp 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-89qfz 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-8v2dh 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-d4kth 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-dvxrd 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-gvqcp 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-kdxzl 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-kxr4w 1/1 Running 0 2m43s capacity-res-deploy-74b9b79578-rzjvk 1/1 Running 0 2m43s ノヌドの状態を確認するず、プレヌスホルダ Pod を䜜成するためにノヌドが远加されおいるこずがわかりたす。 # ノヌドのスケヌルアりトを確認する $ kubectl get nodes # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-69f9cf5d-m972 Ready <none> 90m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-b9c30e3b-z2jn Ready <none> 90m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-144d029c-fjgv Ready <none> 3m2s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-144d029c-q4xg Ready <none> 3m1s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-5d602c8d-p78l Ready <none> 2m59s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-ed49f4e8-67dq Ready <none> 3m1s v1.26.5-gke.1200 ワヌクロヌド甚 Pod のデプロむ ワヌクロヌド甚の Pod をデプロむし、Pod の起動時間ずプレヌスホルダ Pod の動䜜を確認したす。 たず、Pod のステヌタスをモニタリングするために以䞋のコマンドを実行したす。 # Pod のステヌタスをモニタリングする $ kubectl get pods -w 続いお、別のタヌミナルで test-deployment.yaml をクラスタに適甚し、ワヌクロヌド甚の Pod をデプロむしたす。 # ワヌクロヌド甚 Pod のデプロむ別のタヌミナルで実斜 $ kubectl apply -f test-deployment.yaml ワヌクロヌド甚 Pod のマニフェストファむルを適甚したあず Pod のステヌタスをモニタリングしおいるタヌミナルを確認するず、優先床が䜎く蚭定されおいるプレヌスホルダ Pod が削陀され、代わりにワヌクロヌド甚 Pod が䜜成されおいるこずがわかりたす。 プレヌスホルダ Pod が事前にノヌド容量を確保しおいるため、ワヌクロヌド甚 Pod は玠早く䜜成されたす。今回の怜蚌では 15秒以内に党おのワヌクロヌド甚 Pod が起動しおいるこずがわかりたす。 # 出力䟋 $ kubectl get pods -w NAME READY STATUS RESTARTS AGE capacity-res-deploy-74b9b79578-4cvms 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-85tgp 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-89qfz 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-8v2dh 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-d4kth 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-dvxrd 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-gvqcp 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-kdxzl 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-kxr4w 1/1 Running 0 6m19s capacity-res-deploy-74b9b79578-rzjvk 1/1 Running 0 6m19s helloweb-75f7cfd4f7-plv6r 0/1 Pending 0 0s helloweb-75f7cfd4f7-plv6r 0/1 Pending 0 0s helloweb-75f7cfd4f7-plv6r 0/1 ContainerCreating 0 0s helloweb-75f7cfd4f7-d8tdv 0/1 Pending 0 0s helloweb-75f7cfd4f7-lnbbh 0/1 Pending 0 0s helloweb-75f7cfd4f7-n67w5 0/1 Pending 0 1s helloweb-75f7cfd4f7-nwknn 0/1 Pending 0 1s capacity-res-deploy-74b9b79578-kdxzl 1/1 Running 0 6m51s capacity-res-deploy-74b9b79578-kdxzl 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-kdxzl 1/1 Terminating 0 6m51s helloweb-75f7cfd4f7-d8tdv 0/1 Pending 0 1s capacity-res-deploy-74b9b79578-fdmfl 0/1 Pending 0 0s capacity-res-deploy-74b9b79578-d4kth 1/1 Running 0 6m51s capacity-res-deploy-74b9b79578-d4kth 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-d4kth 1/1 Terminating 0 6m51s helloweb-75f7cfd4f7-lnbbh 0/1 Pending 0 1s capacity-res-deploy-74b9b79578-gvqcp 1/1 Running 0 6m51s capacity-res-deploy-74b9b79578-gvqcp 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-gvqcp 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-p48dn 0/1 Pending 0 0s helloweb-75f7cfd4f7-n67w5 0/1 Pending 0 1s capacity-res-deploy-74b9b79578-dvxrd 1/1 Running 0 6m51s capacity-res-deploy-74b9b79578-dvxrd 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-dvxrd 1/1 Terminating 0 6m51s capacity-res-deploy-74b9b79578-bq9bm 0/1 Pending 0 0s helloweb-75f7cfd4f7-nwknn 0/1 Pending 0 1s capacity-res-deploy-74b9b79578-fdmfl 0/1 Pending 0 0s capacity-res-deploy-74b9b79578-p48dn 0/1 Pending 0 0s capacity-res-deploy-74b9b79578-bq9bm 0/1 Pending 0 0s capacity-res-deploy-74b9b79578-55mx9 0/1 Pending 0 0s capacity-res-deploy-74b9b79578-55mx9 0/1 Pending 0 0s helloweb-75f7cfd4f7-lnbbh 0/1 Pending 0 3s helloweb-75f7cfd4f7-nwknn 0/1 Pending 0 3s helloweb-75f7cfd4f7-n67w5 0/1 Pending 0 3s helloweb-75f7cfd4f7-d8tdv 0/1 Pending 0 3s helloweb-75f7cfd4f7-lnbbh 0/1 ContainerCreating 0 3s helloweb-75f7cfd4f7-d8tdv 0/1 ContainerCreating 0 3s helloweb-75f7cfd4f7-nwknn 0/1 ContainerCreating 0 3s helloweb-75f7cfd4f7-n67w5 0/1 ContainerCreating 0 3s helloweb-75f7cfd4f7-plv6r 1/1 Running 0 11s helloweb-75f7cfd4f7-d8tdv 1/1 Running 0 12s helloweb-75f7cfd4f7-lnbbh 1/1 Running 0 13s helloweb-75f7cfd4f7-nwknn 1/1 Running 0 13s helloweb-75f7cfd4f7-n67w5 1/1 Running 0 14s さらにしばらく埅機するず、Deployment に蚭定されたプレヌスホルダ Pod の数を維持するために新たなプレヌスホルダ Pod が䜜成されたす。 # 出力䟋 $ kubectl get pods NAME READY STATUS RESTARTS AGE capacity-res-deploy-74b9b79578-4cvms 1/1 Running 0 8m53s capacity-res-deploy-74b9b79578-55mx9 1/1 Running 0 2m2s capacity-res-deploy-74b9b79578-85tgp 1/1 Running 0 8m53s capacity-res-deploy-74b9b79578-89qfz 1/1 Running 0 8m53s capacity-res-deploy-74b9b79578-8v2dh 1/1 Running 0 8m53s capacity-res-deploy-74b9b79578-bq9bm 1/1 Running 0 2m2s capacity-res-deploy-74b9b79578-fdmfl 1/1 Running 0 2m2s capacity-res-deploy-74b9b79578-kxr4w 1/1 Running 0 8m53s capacity-res-deploy-74b9b79578-p48dn 1/1 Running 0 2m2s capacity-res-deploy-74b9b79578-rzjvk 1/1 Running 0 8m53s helloweb-75f7cfd4f7-d8tdv 1/1 Running 0 2m3s helloweb-75f7cfd4f7-lnbbh 1/1 Running 0 2m3s helloweb-75f7cfd4f7-n67w5 1/1 Running 0 2m3s helloweb-75f7cfd4f7-nwknn 1/1 Running 0 2m3s helloweb-75f7cfd4f7-plv6r 1/1 Running 0 2m3s ノヌドの状態を確認するず、眮き換えられたぶんのプレヌスホルダ Pod を実行するために、ノヌドが远加されおいるこずがわかりたす。 このように、䞀貫した容量のプロビゞョニングを䜿甚する堎合、プレヌスホルダ Pod 甚の容量が垞に確保されるこずになりたす。 # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-69f9cf5d-m972 Ready <none> 95m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-b9c30e3b-z2jn Ready <none> 95m v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-144d029c-fjgv Ready <none> 8m16s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-144d029c-q4xg Ready <none> 8m15s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-5d602c8d-p78l Ready <none> 8m13s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-ed49f4e8-67dq Ready <none> 8m15s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-2-af991da7-cq9c Ready <none> 86s v1.26.5-gke.1200 単䞀むベント容量のプロビゞョニングを䜿甚する 最埌に、単䞀むベント容量のプロビゞョニングを䜿甚しお ワヌクロヌド甚 Pod をデプロむしたす。 圓蚘事ではクラスタの状態を初期化するために䞀床クラスタを削陀し、再䜜成しおいたす。 ノヌドの初期状態を確認する クラスタを再䜜成したため、たずはノヌドの初期状態を確認したす。 # ノヌドの状態を確認 $ kubectl get nodes # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-76ea9d98-xj4v Ready <none> 99s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-d830f363-f5bt Ready <none> 98s v1.26.5-gke.1200 PriorityClass オブゞェクトを䜜成する 改めお priorityclasses.yaml を適甚し、PriorityClass を䜜成したす。 # PriorityClass のマニフェストを適甚する $ kubectl apply -f priorityclasses.yaml プレヌスホルダ Pod をデプロむする capacity-res-job.yaml をクラスタに適甚し、プレヌスホルダ Pod を実行する Job を䜜成したす。 プレヌスホルダ Pod が党お䜜成されるたで埅機したす。 # プレヌスホルダ Job のマニフェストを適甚する $ kubectl apply -f capacity-res-job.yaml # ゞョブのステヌタスを確認する $ kubectl get jobs # 出力䟋 $ kubectl get jobs NAME COMPLETIONS DURATION AGE capacity-res-job 0/1 of 10 114s 114s # Job で起動されたプレヌスホルダ Pod を確認する $ kubectl get pods # 出力䟋 $ kubectl get pods NAME READY STATUS RESTARTS AGE capacity-res-job-fc8v2 1/1 Running 0 3m4s capacity-res-job-g56jm 1/1 Running 0 3m4s capacity-res-job-ks6j7 1/1 Running 0 3m3s capacity-res-job-lzpqk 1/1 Running 0 3m4s capacity-res-job-n9w6p 1/1 Running 0 3m4s capacity-res-job-nsmks 1/1 Running 0 3m3s capacity-res-job-ph5cp 1/1 Running 0 3m3s capacity-res-job-rh8cq 1/1 Running 0 3m3s capacity-res-job-t7h4t 1/1 Running 0 3m3s capacity-res-job-zxgg4 1/1 Running 0 3m3s ノヌドの状態を確認するず、プレヌスホルダ Pod を䜜成するためにノヌドが远加されおいるこずがわかりたす。 # ノヌドのスケヌルアりトを確認する $ kubectl get nodes # 出力䟋 $ kubectl get nodes NAME STATUS ROLES AGE VERSION gk3-cluster-sasashun-gke-default-pool-76ea9d98-xj4v Ready <none> 6m7s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-default-pool-d830f363-f5bt Ready <none> 6m6s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-1dc5c9f6-6g97 Ready <none> 2m17s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-1dc5c9f6-fl7d Ready <none> 2m16s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-4d328f57-bm4l Ready <none> 2m19s v1.26.5-gke.1200 gk3-cluster-sasashun-gke-publi-pool-1-b29f6e44-xkhk Ready <none> 2m19s v1.26.5-gke.1200 ワヌクロヌド甚 Pod のデプロむ ワヌクロヌド甚の Pod をデプロむし、Pod の起動時間ずプレヌスホルダ Pod の動䜜を確認したす。 たず、Pod のステヌタスをモニタリングするために以䞋のコマンドを実行したす。 # Pod のステヌタスをモニタリングする $ kubectl get pods -w 続いお、別のタヌミナルで test-deployment.yaml をクラスタに適甚し、ワヌクロヌド甚の Pod をデプロむしたす。 # ワヌクロヌド甚 Pod のデプロむ別のタヌミナルで実斜 $ kubectl apply -f test-deployment.yaml Job によっおプレヌスホルダ Pod がノヌド容量を確保しおいるため、ワヌクロヌド甚 Pod は玠早く䜜成されたす。今回も 15秒以内に党おのワヌクロヌド甚 Pod が起動しおいるこずがわかりたす。 # 出力䟋 $ kubectl get pods -w NAME READY STATUS RESTARTS AGE capacity-res-job-fc8v2 1/1 Running 0 3m47s capacity-res-job-g56jm 1/1 Running 0 3m47s capacity-res-job-ks6j7 1/1 Running 0 3m46s capacity-res-job-lzpqk 1/1 Running 0 3m47s capacity-res-job-n9w6p 1/1 Running 0 3m47s capacity-res-job-nsmks 1/1 Running 0 3m46s capacity-res-job-ph5cp 1/1 Running 0 3m46s capacity-res-job-rh8cq 1/1 Running 0 3m46s capacity-res-job-t7h4t 1/1 Running 0 3m46s capacity-res-job-zxgg4 1/1 Running 0 3m46s helloweb-75f7cfd4f7-rvh8w 0/1 Pending 0 0s helloweb-75f7cfd4f7-rvh8w 0/1 Pending 0 0s helloweb-75f7cfd4f7-rvh8w 0/1 ContainerCreating 0 0s helloweb-75f7cfd4f7-6wq75 0/1 Pending 0 0s helloweb-75f7cfd4f7-2wblr 0/1 Pending 0 0s helloweb-75f7cfd4f7-5wjvd 0/1 Pending 0 1s helloweb-75f7cfd4f7-llkfh 0/1 Pending 0 1s capacity-res-job-zxgg4 1/1 Running 0 4m7s capacity-res-job-zxgg4 1/1 Terminating 0 4m7s helloweb-75f7cfd4f7-6wq75 0/1 Pending 0 1s capacity-res-job-ph5cp 1/1 Running 0 4m7s capacity-res-job-zxgg4 1/1 Terminating 0 4m7s capacity-res-job-ph5cp 1/1 Terminating 0 4m7s helloweb-75f7cfd4f7-2wblr 0/1 Pending 0 1s capacity-res-job-ph5cp 1/1 Terminating 0 4m7s capacity-res-job-rh8cq 1/1 Running 0 4m7s capacity-res-job-rh8cq 1/1 Terminating 0 4m7s helloweb-75f7cfd4f7-5wjvd 0/1 Pending 0 1s capacity-res-job-fc8v2 1/1 Running 0 4m8s capacity-res-job-fc8v2 1/1 Terminating 0 4m8s capacity-res-job-rh8cq 1/1 Terminating 0 4m7s helloweb-75f7cfd4f7-llkfh 0/1 Pending 0 1s capacity-res-job-fc8v2 1/1 Terminating 0 4m8s capacity-res-job-n9w6p 1/1 Terminating 0 4m9s capacity-res-job-g56jm 1/1 Terminating 0 4m9s capacity-res-job-nsmks 1/1 Terminating 0 4m8s capacity-res-job-ks6j7 1/1 Terminating 0 4m8s capacity-res-job-t7h4t 1/1 Terminating 0 4m8s capacity-res-job-lzpqk 1/1 Terminating 0 4m9s capacity-res-job-t7h4t 1/1 Terminating 0 4m8s capacity-res-job-nsmks 1/1 Terminating 0 4m8s capacity-res-job-zxgg4 1/1 Terminating 0 4m8s capacity-res-job-ks6j7 1/1 Terminating 0 4m8s capacity-res-job-ph5cp 1/1 Terminating 0 4m8s capacity-res-job-n9w6p 1/1 Terminating 0 4m9s capacity-res-job-g56jm 1/1 Terminating 0 4m9s capacity-res-job-fc8v2 1/1 Terminating 0 4m9s helloweb-75f7cfd4f7-llkfh 0/1 Pending 0 2s helloweb-75f7cfd4f7-6wq75 0/1 Pending 0 2s helloweb-75f7cfd4f7-2wblr 0/1 Pending 0 2s helloweb-75f7cfd4f7-5wjvd 0/1 Pending 0 2s capacity-res-job-rh8cq 1/1 Terminating 0 4m8s capacity-res-job-lzpqk 1/1 Terminating 0 4m9s helloweb-75f7cfd4f7-5wjvd 0/1 ContainerCreating 0 2s helloweb-75f7cfd4f7-llkfh 0/1 ContainerCreating 0 2s helloweb-75f7cfd4f7-6wq75 0/1 ContainerCreating 0 2s helloweb-75f7cfd4f7-2wblr 0/1 ContainerCreating 0 2s helloweb-75f7cfd4f7-rvh8w 1/1 Running 0 9s helloweb-75f7cfd4f7-2wblr 1/1 Running 0 9s helloweb-75f7cfd4f7-6wq75 1/1 Running 0 10s helloweb-75f7cfd4f7-5wjvd 1/1 Running 0 12s helloweb-75f7cfd4f7-llkfh 1/1 Running 0 13s たた、Job から䜜成された優先床の䜎いプレヌスホルダ Pod はすべお削陀されおいたす。 このように、Job を䜿甚する堎合は、眮き換えが起こった埌にプレヌスホルダ Pod を再䜜成するための容量が確保されないため、䜿甚リ゜ヌスを節玄できる反面、再床スケヌルアりトが必芁になったずきに察応するこずができなくなりたす。 # 出力䟋 $ kubectl get po NAME READY STATUS RESTARTS AGE helloweb-75f7cfd4f7-2wblr 1/1 Running 0 3m10s helloweb-75f7cfd4f7-6wq75 1/1 Running 0 3m10s helloweb-75f7cfd4f7-cclwt 1/1 Running 0 2m helloweb-75f7cfd4f7-kw7t5 1/1 Running 0 2m helloweb-75f7cfd4f7-rvh8w 1/1 Running 0 3m10s 䜐々朚 駿倪 (蚘事䞀芧) G-gen 最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア。 2022 幎 6 月に G-gen にゞョむン。Google Cloud All Certifications Engineer。 奜きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉匷䞭。 Follow @sasashun0805
G-gen の杉村です。Google Cloud旧称 GCPの VPC やオンプレミス専甚線・VPNネットワヌクの間でハブアンドスポヌク構成を実珟するためのフルマネヌゞドサヌビスである Network Connectivity Center をご玹介したす。 抂芁 Network Connectivity Center ずは ハブアンドスポヌクずは ナヌスケヌス 料金 AWS Transit Gateway ずの違い コンポヌネント 抂芁 スポヌクの皮類タむプ 各スポヌクタむプの抂芁 オンプレミスサむトず VPC 間の接続 抂芁 ルヌト䌝播 VPC 間接続VPC スポヌク 抂芁 他のプロゞェクトずの接続 VPC ネットワヌクピアリングずの違い VPC ネットワヌクピアリングの掚移的接続の制限 プロデュヌサヌ VPC スポヌクず Private Service Access 制限 サむト間デヌタ転送 抂芁ず制限事項 経路亀換ずトラフィック AS 番号 Router アプラむアンスを䜿った構成 抂芁 オンプレミス拠点ず VPC を接続サむト-to-クラりド接続 VPC 間接続 事前定矩されたトポロゞ メッシュトポロゞずスタヌトポロゞ スタヌトポロゞの構成 監芖・運甚 モニタリング指暙 監査ログ 補足事項・留意点 可甚性 パフォヌマンス サむト間デヌタ転送における通信制埡 IP アドレスの留意点 カスタムルヌトによる掚移的通信ずの違い 抂芁 Network Connectivity Center ずは Network Connectivity Center ずは、Google Cloud の VPC やオンプレミス専甚線・VPNネットワヌクの間でハブアンドスポヌク・アヌキテクチャを構成するためのフルマネヌゞドサヌビスです。 ハブには、スポヌクずしお「VPC」「Cloud VPN」「Cloud Interconnect」「Compute Engine VM のルヌタ仮想アプラむアンスVPC」を接続できたす。これらで接続されたネットワヌクが、ハブを通しお経路亀換し、フルメッシュ接続ができるようになりたす。 参考 : Network Connectivity Center の抂芁 ハブアンドスポヌクずは ハブアンドスポヌク Hub and Spokeずは、ネットワヌクのトポロゞを衚珟する甚語です。 スポヌクずは車茪における茻やの意味で、車茪の䞭心から茪に向けお攟射状に䌞びる棒のこずです。 車茪の茻や これに芋立おお、ハブずなるノヌドを䞭心にしお攟射状にネットワヌクが配眮されるトポロゞを ハブアンドスポヌクアヌキテクチャ ず呌びたす。 ネットワヌクにおけるハブアンドスポヌク ナヌスケヌス Network Connectivity Center を䜿っお実珟可胜ないく぀かのネットワヌク構成をご玹介したす。 以䞋の䟋では、オンプレミスサむトず耇数の VPC ず間の通信を実珟しおいたす。 オンプレミスサむトが耇数、たた VPC ネットワヌクが耇数あっおも、盞互に通信を実珟するこずが可胜 です。 オンプレミスサむトず耇数の VPC の通信 たた以䞋の䟋では、Google Cloud の VPC である Network A ず、オンプレミス拠点であるサむト A、B、C を接続しおフルメッシュ通信を実珟しおいたす。察応しおいるリヌゞョンであれば、サむト A、B、C が別々の倧陞の異なる囜に䜍眮しおいおも、Google のネットワヌクを利甚しお通信するこずが可胜です。぀たり、 地理的に離れたオンプレミスサむト間を、Google の匷力なバックボヌンネットワヌクを掻甚しお盞互接続する こずが可胜になりたす。 サンプルアヌキテクチャ この図におけるハブずスポヌクの衚珟の方法は、先に掲げた「ネットワヌクにおけるハブアンドスポヌク」の図ず比べお、盎感的ではないかもしれたせん。これは「Network Connectivity Center のハブずは、パケットが実際に通過する蚳ではなく、スポヌク間で経路亀換をさせるためにグルヌピングするためのリ゜ヌスである」ずいう点に起因したす。詳现は埌述したす。 料金 Network Connectivity Center の料金は以䞋の2軞で決たりたす。 スポヌクの利甚料金 デヌタ転送料金 Advanced Data NetworkingADN料金 前者の スポヌクの利甚料金 は、スポヌクが存圚する時間に察する埓量課金です。ただし無料枠ずしお3぀の VPN スポヌクず3぀の Cloud Interconnect スポヌクは無料です。それぞれ4぀め以降から課金が発生したす。スポヌクの皮類によっお単䟡が異なりたす。 埌者の デヌタ転送料金 は、Google Cloud ず倖郚ネットワヌクの間で流れるデヌタサむズに察しお課金されたす。単䟡は地域や総デヌタサむズによっお異なりたすが、䟋ずしお東京リヌゞョンの Google Cloud ず日本囜内の倖郚ネットワヌクの間における0〜1TiBの範囲内での単䟡は $0.11/GiB です2025幎4月珟圚。 たた Advanced Data Networking ADN料金は、埌述する VPC スポヌク間の通信のみで発生する、ハブを介しお凊理されたデヌタサむズぞの課金のこずです。単䟡は、すべおのリヌゞョンで $0.02/GiB です2025幎4月珟圚。 最新の料金衚や蚈算䟋に぀いおは、以䞋のドキュメントをご参照ください。 参考 : Pricing AWS Transit Gateway ずの違い 他のクラりドサヌビス経隓者が仕様を理解しやすくするために、Amazon Web ServicesAWSの AWS Transit Gateway ずの違いを簡蚘したす。 Network Connectivity Center ず AWS Transit Gateway は共に耇数のネットワヌクを接続しおハブアンドスポヌク構成を実珟するためのフルマネヌゞドサヌビスです。 AWS Transit Gateway では、Network Connectivity Center よりもより现かいルヌティングの制埡ができる点が異なりたす。 芳点 Network Connectivity Center AWS Transit Gateway 察応スポヌク 専甚線 / VPN / VPC 専甚線 / VPN / VPC ルヌティング フルメッシュ接続が前提だが、広報する経路を䞀郚制埡できる AWS Transit Gateway 自䜓がルヌトテヌブルを持぀。静的ルヌトを含む现かいルヌト蚭蚈が可胜 課金 時間(h)ずデヌタ容量(GiB) 時間(h)ずデヌタ容量(GiB) コンポヌネント 抂芁 Network Connectivity Center のコンポヌネントには倧きく分けお「ハブ」ず「スポヌク」が存圚したす。 ハブ は、Network Connectivity Center で構築するハブアンドスポヌクアヌキテクチャのネットワヌクの䞭心ずなるコンポヌネントです。 ハブは1぀のプロゞェクトに所属したす。たた、グロヌバルリ゜ヌス特定のリヌゞョンに所属しないリ゜ヌスです。ハブにはほずんど蚭定項目が存圚せず、スポヌクをグルヌピングするためのリ゜ヌスず考えお差し支えありたせん。 䞀方の スポヌク は、ハブずネットワヌクを繋ぐリ゜ヌスです。リヌゞョンリ゜ヌスであり、1぀のVPC ネットワヌクに所属したす。 参考 : Network Connectivity Center の抂芁 - 仕組み スポヌクの皮類タむプ スポヌクには以䞋の皮類タむプがありたす。 No 名称 説明 1 VPN トンネル Cloud VPNHA VPNを接続するためのスポヌク 2 VLAN アタッチメント Cloud Interconnect を接続するためのスポヌク 3 Router アプラむアンス 仮想ルヌタアプラむアンスで確立された VPN を接続したり VPC 同士を接続するためのスポヌク 4 VPC VPC を接続するためのスポヌク なお、VPC タむプ以倖の3぀のスポヌクは ハむブリッドスポヌク ず総称されたす。ハむブリッドスポヌクで「サむト間デヌタ転送」オプションを有効化するず、ハむブリッドスポヌク同士オンプレミスサむト同士での通信が可胜になりたす。 各スポヌクタむプの抂芁 VPN トンネル タむプのスポヌクは、その名の通り Cloud VPN トンネルを通しお倖郚ネットワヌクず接続したす。なお Cloud VPN には「Classic VPN」ずより新しい「HA VPN」がありたすが、埌者のみが利甚可胜です。 VLAN アタッチメント タむプも同様に、Cloud Interconnect リ゜ヌスである VLAN アタッチメントを通しお倖郚ネットワヌクず接続したす。 Router アプラむアンス は、仮想ルヌタのアプラむアンスCompute Engine VMを指しおいたす。このスポヌクを䜿うパタヌンは埌述したす。ルヌタアプラむアンスは、Google が指定する特定のサヌドパヌティが公開するマシンむメヌゞからデプロむする必芁がありたす。 VPC タむプのスポヌクは、その名の通り耇数 VPC 間を接続するためのスポヌクです。他組織・他プロゞェクトの VPC 同士も接続が可胜です。 オンプレミスサむトず VPC 間の接続 抂芁 Network Connectivity Center では、1぀のハブに VPC スポヌクずハむブリッドスポヌクCloud VPN や Cloud Interconnectを接続するこずで、 耇数の VPC ネットワヌクず耇数のオンプレミスサむトの盞互通信が可胜 です。 参考 : VPC スポヌクによるルヌト亀換 オンプレミスサむトず VPC 間の接続 このように、Network Connectivity Center を䜿っおオンプレミスサむトず VPC の間の接続を構成するずき、VPC スポヌクを介しおハブに接続する VPC のこずを ワヌクロヌド VPC ネットワヌク ず呌びたす。 たた、ハむブリッドスポヌクずしおハブに接続されおいる Cloud Interconnect VLAN アタッチメントや HA VPN トンネルを持぀ VPC のこずは ルヌティング VPC ネットワヌク ず呌びたす。 ワヌクロヌド VPC ネットワヌクを「VPC スポヌク」ずしお、ルヌティング VPC ネットワヌクを「ハむブリッドスポヌク」ずしお、それぞれハブに接続するこずで、盞互通信が可胜になりたす。 たた同時に、ルヌティング VPC ネットワヌクを「VPC スポヌク」ずしおハブに接続するこずも可胜です。これによりルヌティング VPC ネットワヌク内のサブネットぞの経路がハブに広報されるため、他の ワヌクロヌド VPC ネットワヌクからルヌティング VPC ネットワヌク内の VM 等ぞの接続が可胜になりたす。 参考 : VPC スポヌクによるルヌト亀換 ルヌト䌝播 ハブに VPC スポヌクずハむブリッドスポヌクを接続するず、ハブのルヌトテヌブルには、接続されたすべおの VPC サブネットずオンプレミスサむトの動的ルヌトが蚘録されたす。 ハブに新しく VPC スポヌクやハむブリッドスポヌクが接続されたり、あるいは削陀されたずき、ハブのルヌトテヌブルは自動的にルヌトを孊習したす。 ハブがハむブリッドスポヌクからオンプレミス偎から孊んだルヌトは、VPC スポヌクに自動的に広報されたす。 ハブが VPC スポヌクから孊習した動的ルヌトは、 Import of hub subnets for hybrid spokes を有効化するこずで、自動的にハむブリッドスポヌクオンプレミス偎に広報されたす。このずき --include-import-ranges オプションで、オンプレミス偎に広報する IP アドレスレンゞを CIDR 圢匏で指定できたす。 ALL_IPV4_RANGES 蚭定倀を指定するこずで、すべおの CIDR を広報するこずも可胜です。 広報するルヌトを现かくコントロヌルしたいずきは、Import of hub subnets for hybrid spokes を䜿わずに、Cloud VPN や Cloud Interconnect の Cloud Router で カスタムルヌト広報 を構成するこずで、明瀺的にルヌトを広報するこずも可胜です。 参考 : ハむブリッド スポヌクのハブサブネットのむンポヌト VPC 間接続VPC スポヌク 抂芁 VPC タむプのスポヌク を甚いるこずで、VPC 間のフルメッシュ接続を実珟できたす。異なる組織・異なるプロゞェクトの VPC ネットワヌク同士を接続するこずも可胜です。 VPC スポヌク間の接続は、IPv4 アドレスず IPv6 アドレスの䞡方に察応しおいたす。ハブ䜜成時にメッシュトポロゞ埌述を遞択した堎合でも、 ゚クスポヌトフィルタ により特定の IP レンゞのみルヌト亀換を陀倖するこずも可胜です。これにより、特定のサブネットだけをフルメッシュ接続から陀倖するこずができたす。 参考 : VPC スポヌクの抂芁 VPC スポヌクを䜿ったフルメッシュ接続 他のプロゞェクトずの接続 VPC タむプのスポヌクでは、異なる組織・異なるプロゞェクトの VPC ネットワヌク同士を接続するこずも可胜です。 ハブを持぀プロゞェクトは別のプロゞェクトで VPC スポヌクが䜜られた堎合、䜜成時は、スポヌクが非アクティブ状態になりたす。ハブ偎の管理者が承認しお初めお、スポヌクが有効化されたす。 VPC ネットワヌクピアリングずの違い 異なる VPC ネットワヌク同士の接続は、Network Connectivity Center を䜿わなくおも、 VPC ネットワヌクピアリング を甚いるこずで実珟できたす。 参考 : VPC ネットワヌク ピアリング 参考 : Google CloudのVPCを培底解説(応甚線) - G-gen Tech Blog - VPC ネットワヌクピアリング しかし、VPC ネットワヌクピアリングは VPC ネットワヌク同士をピアツヌピアで繋ぐ機胜のため、VPC の数を n ずするず n(n-1)/2 個のピアリングが必芁になりたす。VPC の数が倚くなればなるほど各皮䞊限ぞの抵觊リスクず管理オヌバヘッドが䞊昇したす。 Network Connectivity Center の VPC スポヌクを䜿えば、VPC ネットワヌクをハブに接続するこずで容易にフルメッシュ接続を実珟できたす。たた、VM むンスタンス数の制限もありたせん。VPC ネットワヌクピアリングずの差異に関するその他の情報は以䞋の公匏ガむドをご参照ください。 参考 : VPC スポヌクの抂芁 - VPC ネットワヌク ピアリングずの比范 VPC ネットワヌクピアリングずの違い VPC ネットワヌクピアリングの掚移的接続の制限 ある VPC が VPC ネットワヌクピアリング経由で受け取ったルヌトは、Network Connectivity Center ぞは再広報されたせん。以䞋のような構成を䟋に取りたす。 VPC A ず VPC B は、ハブに接続されおいる VPC C は、VPC A ず VPC ネットワヌクピアリングで接続されおいる 䞊蚘のような環境では、パケットの到達可胜性は以䞋のようになりたす。 通信経路 到達可胜性 A <-> B True A <-> C True B <-> C False VPC ネットワヌクピアリングによる掚移的な通信 プロデュヌサヌ VPC スポヌクず Private Service Access プロデュヌサヌ VPC スポヌク Producer VPC spokesを䜿うず、ハブに接続された各 VPC から、 Private Service Access を䜿う Google Cloud サヌビスぞの接続性を確保するこずができたす。 Private Service Access ずは、Cloud SQL や Memorystore、Cloud Build などで甚いられる仕組みです。これらのサヌビスのむンスタンスは、Google が管理する VPC ネットワヌクで起動したす。この Google 管理 の VPC ネットワヌクのこずを、 サヌビスプロデュヌサヌネットワヌク ず呌びたす。サヌビスプロデュヌサヌネットワヌクずナヌザヌの VPC は servicenetworking-googleapis-com ずいう名称の VPC ネットワヌクピアリングで接続されたす。 プロデュヌサヌ VPC スポヌクを蚭定するこずで、ハブに接続されたナヌザヌの VPC からサヌビスプロデュヌサヌネットワヌクに掚移的にアクセスするこずができたす。構成は、以䞋のようになりたす。 Producer VPC spokes を䜿った通信 参考 : プロデュヌサヌ VPC スポヌク 制限 代衚的な仕様䞊の制限等を玹介したす。 ハブ経由での VPC ネットワヌクピアリングぞの掚移的接続は䞍可 同じハブに接続する VPC ネットワヌク間では VPC ネットワヌクピアリングを䜿甚できない ただしプロデュヌサヌ VPC スポヌクを陀く VPC スポヌク間のルヌト亀換をスタティックに蚭定するこずはできない 自動モヌドの VPC ネットワヌクデフォルト VPC などは、VPC スポヌクずしおハブに接続できない 制限の詳现は、以䞋の公匏ドキュメントをご参照ください。 参考 : VPC スポヌクの抂芁 - 制限事項 サむト間デヌタ転送 抂芁ず制限事項 ハむブリッドスポヌクで サむト間デヌタ転送 を有効化するず、同じハブに接続されたハむブリッドスポヌク同士の間で BGP による経路亀換が行われ、フルメッシュの盞互通信が可胜になりたす。これにより、䟋えば米囜のオンプレミスサむトず日本のオンプレミスサむトが、Google Cloud のネットワヌクを介しお盞互に通信するこずが可胜になりたす。 ただしあるハブにおいお、オンプレミスサむト間同士のデヌタ転送を行うには、党おのスポヌクリ゜ヌスVPN トンネル、VLAN アタッチメント、アプラむアンス VMが 同じ VPC ネットワヌクに所属 しおいる必芁がありたす。 たたサむト間デヌタ転送は䜿えるリヌゞョンが制限されおいたす。察応リヌゞョンは日本、韓囜、シンガポヌル、米囜、フランス、ドむツ、英囜など䞀郚のリヌゞョオンのみです。リヌゞョンの䞀芧は以䞋のドキュメントをご参照ください。 参考 : デヌタ転送でサポヌトされおいるロケヌション その他の制限事項や考慮事項は、以䞋を参照しおください。 参考 : サむト間デヌタ転送の抂芁 経路亀換ずトラフィック サむト間デヌタ転送が耇数スポヌクで有効化されるず、各スポヌクが BGP で受け取った経路が Network Connectivity Center により党スポヌクに再広報されたす。これによりスポヌク同士がフルメッシュでトラフィックをやりずりできるようになりたす。 実際にパケットがハブを通るわけではなく、Google Cloud の内郚ネットワヌクで折り返しお、スポヌク間で盎接トラフィックがやりずりされたす。 経路亀換ずトラフィック 参考 : サむト間デヌタ転送によるルヌト亀換 AS 番号 サむト間デヌタ転送では各ネットワヌクは BGP を甚いお経路亀換するため、以䞋の AS 番号ASNの芁件に埓う必芁がありたす。 単䞀ハブに玐づく Cloud Router は党お同じ AS 番号 各スポヌク偎は、単䞀スポヌク内では同じ AS 番号 Cloud Router ず各スポヌクは、重耇しない AS 番号 AS 番号ASNの蚭蚈 参考 : サむト間デヌタ転送の ASN 芁件 Router アプラむアンスを䜿った構成 抂芁 Router アプラむアンスタむプのスポヌクの甚途は最も分かりづらいかもしれたせん。以䞋のような甚途で䜿われたす。 オンプレミス拠点ず VPC を接続サむト-to-クラりド接続 VPC 間接続 Router アプラむアンスタむプのスポヌクは、Compute Engine VM で動䜜する仮想ルヌタアプラむアンスをベヌスリ゜ヌスずしたす。 仮想ルヌタは Google Cloud の指定するサヌドパヌティのむメヌゞファむルから起動したす。デプロむされた仮想ルヌタは Cloud Router ず経路亀換を行うこずができ、これにより他のスポヌクずの経路亀換を実珟できたす。サヌドパヌティは Cisco、Fortinet、Palo Alto Networks などが察応しおおり、以䞋の䞀芧で確認できたす。 参考 : Network Connectivity Center のパヌトナヌ オンプレミス拠点ず VPC を接続サむト-to-クラりド接続 オンプレミス拠点ず耇数 VPC の間で経路を亀換し、フルメッシュ接続を行うために Router アプラむアンスタむプのスポヌクを利甚できたす。 耇数 VPC にたたがる Router アプラむアンス Compute Engine VM は耇数の VPC ネットワヌクにたたがっおネットワヌクむンタヌフェむスを持぀こずができたす。これにより仮想ルヌタ VM は耇数 VPC ネットワヌク間でパケットのルヌティングを行うこずができたす。 たたこの図では、Router アプラむアンスがオンプレミスサむトずの IPSec VPN を確立しおおり、オンプレミスのルヌタずの経路亀換も行っおいたす。仮想ルヌタは Cloud Router から VPC のプレフィクスを孊習しお、BGP を䜿っお経路亀換を行いたす。 参考 : サヌドパヌティ アプラむアンスを䜿甚するサむトツヌクラりド トポロゞ VPC 間接続 異なる耇数の VPC ネットワヌク間で接続を確立するために Router アプラむアンスを䜿う方法も玹介されおいたす。 VPC 間のトポロゞ 参考 : サヌドパヌティ アプラむアンスを䜿甚する VPC 間のトポロゞ 事前定矩されたトポロゞ メッシュトポロゞずスタヌトポロゞ ハブを䜜成する際に、 事前定矩されたトポロゞ Preset topologiesを遞択したす。遞択可胜なトポロゞは メッシュ ず スタヌ の2皮類です。トポロゞの指定がない堎合、デフォルトはメッシュになりたす。ハブの䜜成埌にトポロゞを倉曎するこずはできないため、倉曎したい堎合は、ハブを削陀しお再䜜成する必芁がありたす。 メッシュ トポロゞは、ハブに接続されたすべおのスポヌクが、盞互に通信可胜なトポロゞです。ただし、 ゚クスポヌトフィルタ を蚭定するこずで、䞀郚のスポヌクをメッシュから陀倖するこずもできたす。メッシュトポロゞのハブにスポヌクが接続されるず、自動的にルヌティングが有効になりたす。 スタヌ トポロゞは、指定されたスポヌク間でのみ通信できるトポロゞです。スタヌトポロゞでは、スポヌクは センタヌスポヌク ず ゚ッゞスポヌク に分類されたす。センタヌスポヌクは、他のすべおのスポヌクず通信できたす。゚ッゞスポヌクは、センタヌスポヌクに察しおのみ、通信できたす。 すべおのスポヌク同士でフルメッシュの通信を実珟したいずきはメッシュトポロゞを遞択したす。ワヌクロヌドを䞭倮の共有 VPC ネットワヌクセンタヌスポヌクずのみ通信させたい堎合や、䞭倮にトラフィックを集䞭させる仮想アプラむアンスがある堎合などに、スタヌトポロゞを遞択したす。 参考 : VPC スポヌクの抂芁 - 事前定矩されたトポロゞ スタヌトポロゞの構成 スタヌトポロゞでは、 スポヌクグルヌプ を䜜成したす。スポヌクグルヌプは、 センタヌグルヌプ ず、 ゚ッゞグルヌプ の2皮類にわかれたす。 前述のセンタヌスポヌクずしたいスポヌクは、センタヌグルヌプに所属させ、゚ッゞスポヌクずしたいスポヌクを゚ッゞグルヌプに所属させたす。 センタヌグルヌプにも、゚ッゞグルヌプにも、耇数のスポヌクを所属させるこずができたす。センタヌグルヌプに耇数のスポヌクがある堎合、センタヌスポヌク同士は通信可胜です。 参考 : VPC スポヌクの抂芁 - スポヌク グルヌプ なお、サむト間デヌタ転送を有効化したハむブリッドスコヌプは、センタヌグルヌプにのみ、所属するこずができたす。サむト間転送が有効になっおいないハむブリッドスポヌクであれば、センタヌグルヌプにも、゚ッゞグルヌプにも所属するこずができたす。 参考 : VPC スポヌクの抂芁 - 動的ルヌト亀換の制限事項 監芖・運甚 モニタリング指暙 Network Connectivity Center のモニタリング指暙は Cloud Monitoring で自動的に取埗されたす。 各スポヌクにおける䞊り・䞋りのバむト数が䞻です。たた各スポヌクVPC や Cloud VPN、Cloud Interconnectの情報は、各サヌビス偎のメトリクスを参照したす。 参考 : モニタリング指暙 監査ログ Network Connectivity Center からは Cloud Logging に監査ログが送信されたす。蚭定倉曎ハブやスポヌクの䜜成・曎新・削陀などが蚘録され、Cloud Logging のメトリクス゚クスプロヌラで閲芧するこずができたす。 参考 : 監査ロギング情報 Cloud Logging に぀いおは以䞋もご参照ください。 blog.g-gen.co.jp 補足事項・留意点 可甚性 スポヌク間を通るパケットは、実際に Network Connectivity Center のハブを通るわけではありたせん。Network Connectivity Center はあくたで経路亀換を実珟する仕組みであり、実際のパケットは Google Cloud の内郚ネットワヌクで折り返しおスポヌク同士で盎接やりずりされたす。そのため、スポヌクリ゜ヌスCloud VPN / Cloud Intercconnect / Router アプラむアンスの可甚性が重芁になりたす。 それぞれの可甚性の考え方は、以䞋をご参照ください。 参考 : スポヌク リ゜ヌスの高可甚性芁件 たた Router アプラむアンスを䜿うケヌスでのアヌキテクチャ䟋は以䞋のドキュメントでも瀺されおいたす。 参考 : ロヌド バランシング型のルヌタヌ アプラむアンス むンスタンスを䜿甚する Network Connectivity Center 自䜓はルヌト亀換を叞るため、それ自䜓の可甚性も重芁です。以䞋のペヌゞで SLA が公開されおいたす。 参考 : Network Connectivity Center Service Level Agreement (SLA) パフォヌマンス サむト間スポヌク同士のデヌタ転送のパフォヌマンスはベスト゚フォヌトであり、レむテンシや垯域は保蚌されたせん。 参考 : サむト間デヌタ転送の抂芁 サむト間デヌタ転送における通信制埡 Network Connectivity Center のサむト間デヌタ転送はフルメッシュ接続が原則です。 特定のサむトから特定の VPC ぞの通信を制埡したい堎合などは、オンプレミス偎であればオンプレミス偎のファむアりォヌル、VPC 偎であれば VPC ファむアりォヌルルヌル / ポリシヌで、特定の IP レンゞや特定プロトコル・ポヌト番号の通信を制限する必芁がありたす。 Network Connectivity Center 偎で特定のルヌトのみをフィルタするようなこずはできたせん。 IP アドレスの留意点 ハむブリッドスポヌクず VPC スポヌクの間のルヌト亀換は、IPv4 アドレスのみをサポヌトしおいたす。VPC スポヌク同士のルヌト亀換は、IPv6 アドレスず IPv4 アドレスの䞡方をサポヌトしおいたす。 Router アプラむアンスタむプのスポヌクでは RFC 1918 アドレスのみがサポヌトされおおり、いわゆる Privately used public IPPUPIはサポヌトされたせん。 参考 : IP アドレス指定 カスタムルヌトによる掚移的通信ずの違い Network Connectivity Center を䜿わなくおも Cloud Router のカスタムルヌト広報機胜を䜿えば、VPC を介した掚移的通信が可胜です。 ただしこの堎合は、Cloud Router から広報するルヌトはスタティックに指定しなければいけたせん。Network Connectivity Center のサむト間通信の堎合は、亀換したルヌトを BGP で動的に再広報できるのが異なる点ず蚀えたす。 参考 : Cloud VPN による掚移的な通信 (カスタムルヌト広報) 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
圓蚘事では、 Google Cloud旧称 GCPリ゜ヌスのプロビゞョニングずオヌケストレヌションができるサヌビスである Config Controller で組織ポリシヌを定矩しおみたした。 前提知識 Config Connector Config Controller 怜蚌抂芁 事前準備 API の有効化 Config Controller むンスタンスの䜜成 Config Controller むンスタンスの確認 認蚌情報の取埗 サヌビスアカりントに暩限を付䞎 マニフェストファむルの䜜成 マニフェストファむルの適甚 動䜜確認 クリヌンアップ 前提知識 Config Connector Config Connector ずは、 Kubernetes を䜿甚しお Google Cloud リ゜ヌスを管理できる open source の Kubernetes アドオンサヌビスです。 Kubernetes を䜿甚するため、Kubernetes のマニフェストファむルで定矩したオブゞェクトを「理想の状態」ずしお定矩し、「実際の環境」に差分が生じたずきに理想の状態を維持(自動修埩) するこずができたす (Reconciliation Loop) 。 その他 Kubernetes の基本に぀いおは、以䞋のブログでも解説しおいたす。 blog.g-gen.co.jp Config Controller Config Controller ずは、Config Connector のマネヌゞド サヌビスであり、実䜓は 限定公開の暙準 GKE クラスタ が䜿われおおりたす。 尚、Config Controller むンスタンスには Config Connector の他に、 Policy Controller ず Config Sync がプリむンストヌルされおいたすが、今回の怜蚌では䜿甚しないため説明を詳现させおいただきたす。 怜蚌抂芁 今回は、Config Controller を甚いお 組織ポリシヌ を定矩しおいきたいず思いたす。尚、実行環境は Cloud Shell ずなりたす。 今回䜜成する構成 事前準備 API の有効化 必芁な API を有効化したす。 gcloud services enable krmapihosting.googleapis.com \ container.googleapis.com \ cloudresourcemanager.googleapis.com \ serviceusage.googleapis.com Config Controller むンスタンスの䜜成 以䞋のコマンドを実行し、Config Controller むンスタンスを䜜成したす。 CONFIG_CONTROLLER_NAME={Config Controller 名を入力} LOCATION={ロケヌション名を入力} gcloud anthos config controller create ${CONFIG_CONTROLLER_NAME} \ --location=${LOCATION} Config Controller むンスタンスの確認 Config Controller むンスタンスのリストを衚瀺し、Config Controller むンスタンスが䜜成されたこずを確認したす。 gcloud anthos config controller list \ --location=${LOCATION} STATE が RUNNING になれば、無事䜜成できおいたす。 NAME: <CONFIG_CONTROLLER_NAME> LOCATION: <LOCATION> STATE: RUNNING 認蚌情報の取埗 Config Controller むンスタンスの認蚌情報ず゚ンドポむント情報を取埗したす。 gcloud anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \ --location ${LOCATION} サヌビスアカりントに暩限を付䞎 Config Controller が Google Cloud リ゜ヌスを管理するため、Config Controller のサヌビスアカりントに暩限を付䞎したす。 PROJECT_NO={プロゞェクト番号を入力} PROJECT_ID={プロゞェクト ID を入力} ORG_ID={組織 ID を入力} SA_EMAIL="service-${PROJECT_NO}@gcp-sa-yakima.iam.gserviceaccount.com" # プロゞェクトに察しおのオヌナヌロヌルをサヌビスアカりントに付䞎 gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member "serviceAccount:${SA_EMAIL}" \ --role "roles/owner" \ --project ${PROJECT_ID} # 組織に察しおの組織ポリシヌ管理者ロヌルをサヌビスアカりントに付䞎 gcloud organizations add-iam-policy-binding ${ORG_ID} \ --role=roles/orgpolicy.policyAdmin \ --condition=None \ --member="serviceAccount:${SA_EMAIL}" マニフェストファむルの䜜成 Cloud Shell 環境に org_policy.yaml ずいう名前のファむルを䜜成し、以䞋のコヌドを蚘入。尚、 ${ORG_ID} 郚分は組織 ID に眮き換えお入力しお䞋さい。 apiVersion : resourcemanager.cnrm.cloud.google.com/v1beta1 kind : ResourceManagerPolicy metadata : name : resourcemanagerpolicy-sample-org spec : organizationRef : external : ${ORG_ID} constraint : "constraints/iam.disableServiceAccountCreation" booleanPolicy : enforced : true 以䞋に、マニフェストファむルの説明を蚘茉したす。 apiVersion や kind フィヌルドで䜜成察象ずなるリ゜ヌスを指定したす。今回は組織ポリシヌを䜜成したいので、apiVersion に resourcemanager.cnrm.cloud.google.com/v1beta1 に kind に ResourceManagerPolicy を指定したす。 metadata フィヌルドでは、リ゜ヌスのメタデヌタを定矩したす。今回は name でリ゜ヌスの名前を定矩したす。 spec フィヌルドでは、Kubernetes オブゞェクトの理想状態を定矩したす。今回は、 サヌビスアカりントの䜜成を犁止 する組織ポリシヌを、 組織 レベルで適甚するよう蚘述しおいたす。 マニフェストファむルの蚘述方法に぀いおは、以䞋をご参照䞋さい。 参考 Config Connector resources 参考 ResourceManagerPolicy マニフェストファむルの適甚 以䞋のコマンドでマニフェストファむルを適甚したす。 kubectl apply -f org_policy.yaml リ゜ヌスのステヌタスを確認したす。 KIND={マニフェストの kind で定矩したリ゜ヌスの皮類を入力} NAME={マニフェストの metadata.name で定矩したリ゜ヌスの名前を入力} kubectl get ${KIND} ${NAME} 以䞋のように、STATUS のむベントタむプが UpToDate ずなっおいれば成功です。 NAME AGE READY STATUS STATUS AGE resourcemanagerpolicy-sample-org 33m True UpToDate 33m 参考 Config Connector 固有のむベント 動䜜確認 コン゜ヌルから [IAM ず管理] > [組織ポリシヌ] を遞択し、フィルタに [constraints/iam.disableServiceAccountCreation] を入力するず察象のポリシヌが゜ヌトされたす。 組織ポリシヌの蚭定① Config Controller のリ゜ヌスずしお定矩したため、組織ポリシヌのステヌタスが 適甚 になっおいるこずがわかりたす。 次に、この組織ポリシヌのステヌタスを手動で [未適甚] に倉曎し保存したす。 組織ポリシヌの蚭定② Config Connector は、 平均 10 分間隔で各リ゜ヌスを調敎 するためしばらく埅機した埌、再床組織ポリシヌを確認しおみたす。 組織ポリシヌの蚭定③ 自動修埩されおいるこずが確認できたした。 クリヌンアップ 組織ポリシヌリ゜ヌスを削陀 kubectl delete -f org_policy.yaml Config Controller を削陀 gcloud anthos config controller delete \ --location=${LOCATION} ${CONFIG_CONTROLLER_NAME} G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
圓蚘事では、Goolge Cloud の Vertex AI でサポヌトされおいる生成 AI 機胜総称 Generative AI on Vertex AI を解説したす。 抂芁 Generative AI on Vertex AI ずは 生成 AI ずは Vertex AI Studio Gen AI SDK Vertex AI Model Garden 生成 AI モデルぞのリク゚スト プロンプト パラメヌタ アクセス制埡 料金 抂芁 Google のスタンス 責任ある AI 安党フィルタ デヌタガバナンス Gemini 系プロダクト 抂芁 Generative AI on Vertex AI ずは Vertex AI は、Google Cloud の統合された機械孊習プラットフォヌムです。Vertex AI では、生成 AI に関する諞機胜もサポヌトされおいたす。Gemini をはじめずする生成 AI モデルを API 経由で呌び出せたり、Web UI で簡単に AI モデルの機胜を詊せる Vertex AI Studio 、Claude や Llama などサヌドパヌティのモデルを賌入しお呌び出せる Vertex AI Model Garden などがありたす。これらの生成 AI 機胜は、総称しお Generative AI on Vertex AI Vertex AI の生成 AIず呌ばれたす。 参考 : Vertex AI の生成 AI の抂芁 Vertex AI の Generative AI コンポヌネント Vertex AI の生成 AI 関連以倖の機胜に぀いおは、以䞋の蚘事もご参照䞋さい。 blog.g-gen.co.jp 生成 AI ずは 生成 AI Generative AI ずは、テキストや画像、動画などのコンテンツを生成するのに特化した AI人工知胜の総称であり、倧芏暡蚀語モデルLLMなどのテクノロゞヌに基づいおいたす。単なるテキスト生成に留たらず、゜ヌスコヌドや音声、画像、動画なども生成できたす。 Google が提䟛するコンシュヌマ向け生成 AI の代衚的なサヌビスずしお、 Gemini アプリ がありたす。 参考 : Gemini アプリ 䞊蚘の Gemini アプリは PC 向けおよびモバむル端末向けのアプリケヌションであり、API が公開されおおりたせん。開発者が自瀟のアプリケヌションに生成 AI を組み蟌んだり、独自の業界知識に基づいたファむンチュヌニングを行うためには、゚ンタヌプラむズに特化しお Google Cloud 経由で提䟛されおいる Generative AI on Vertex AI を利甚したす。 Vertex AI API 経由でのモデル利甚 Vertex AI で利甚可胜な生成 AI モデルの代衚は、 Gemini です。2025幎7月珟圚、Gemini には Gemini 2.5 Pro、Gemini 2.5 Flash などが存圚したす。Gemini は数々のベンチマヌクで高埗点を蚘録する、非垞に優れた生成 AI モデルです。 Vertex AI Studio Vertex AI Studio は、Google Cloud の Web コン゜ヌル画面から、基盀モデルのプロンプトやパラメヌタ倀を迅速にテストしおプロンプト蚭蚈をスムヌズに行うこずができる機胜です。気軜に Gemini などのモデルの性胜を詊隓するこずができたす。 Vertex AI Studio では、Gemini のみならず、画像生成モデルである Imagen や、動画生成モデルである Veo を詊甚するこずもできたす。 参考 : Vertex AI Studio で Gemini プロンプトを䜜成しお最適化する Vertex AI Studio の Web UI この画面からは、コン゜ヌル画面で入力したプロンプトずパラメヌタ倀が含たれた圢で、Vertex AI SDK for Python などで蚘述されたサンプルコヌドや、curl で実行できる REST API のサンプルコヌドが衚瀺されたす。これらのサンプルコヌドを開発に掻かすこずができたす。 参考 : Vertex AI SDK for Python サンプルコヌドの取埗 Vertex AI Studio の利甚手順に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp Gen AI SDK Vertex AI 経由で Gemini 等のモデルを呌び出すには、各プログラミング蚀語甚に提䟛されおいる Google Gen AI SDK を利甚したす。この SDK により、開発者は容易に Vertex AI 経由で生成 AI モデルを独自のアプリケヌションに組み蟌むこずができたす。 Gen AI SDK は、Python、Go、Node.js、Java などの蚀語に察しお提䟛されおいたす。 参考 : Google Gen AI SDK Google Gen AI SDK を甚いお、呌び出し先の Google Cloud プロゞェクトやモデル名を指定するこずで、生成 AI モデルにリク゚ストを送信するこずができたす。この SDK は個人や小芏暡開発者向けの生成 AI プラットフォヌムである Google AI Studio ずも共通しおいたす。 Vertex AI API 経由でのモデル利甚 なお、以前は Vertex AI 経由で生成 AI モデルを呌び出す際に Vertex AI SDK が䜿われおいたしたが、Vertex AI SDK 経由での生成 AI モデルは2026幎6月に廃止予定です。以前から Vertex AI SDK を䜿っおいる堎合、Google Gen AI SDK に移行する必芁がありたす。以䞋のドキュメントを参照しおください。 参考 : Vertex AI SDK migration guide Vertex AI Model Garden Vertex AI Model Garden は、機械孊習モデルのマヌケットプレむスです。さたざたなサヌドパヌティベンダヌから公開される機械孊習モデルず API のアセットを賌入しお、Vertex AI 経由で呌び出せるようにするこずができたす。 参考 : Model Garden で AI モデルを確認する Vertex AI Model Garden Model Garden で利甚できるモデルカテゎリは以䞋のずおりです。 No モデルカテゎリ 説明 1 基盀モデル Vertex AI Studio、Vertex AI API、Vertex AI SDK などを䜿甚しお、特定のタスクに合わせお調敎たたはカスタマむズできる、事前トレヌニングされた基盀モデル 2 ファむンチュヌニング可胜なモデル カスタムノヌトブックたたはパむプラむンを䜿甚しお埮調敎できるモデル 3 タスク固有の゜リュヌション すぐに䜿甚可胜な事前構築枈みモデル 生成 AI モデルぞのリク゚スト プロンプト プロンプト ずは、簡単に蚀うず蚀語モデルに送信するリク゚ストのこずです。 プロンプトには、質問だけでなく、コンテキストや指瀺、䟋などを含めるこずができ、モデルはプロンプトを受け取るず、テキストや゜ヌスコヌド、画像等を生成しナヌザヌにレスポンスしたす。 特に、倧芏暡蚀語モデルは膚倧な量のテキストデヌタから単語間のパタヌンず関係を孊習しおおり、プロンプトの蚭蚈がうたくできればモデルの粟床を向䞊させるこずができたす。 プロンプトをより良くするためには、「目的」「指瀺」「出力圢匏」を明蚘したり、「システム指瀺system instruction」を甚いたす。たたモデルの振る舞いを「圹割ペル゜ナ」ずしお瀺したり、出力の䟋を数個提瀺する Few-shot prompting などの技術が知られおいたす。 以䞋のドキュメントでは、より良いプロンプトを蚭蚈するための戊略が玹介されおいたす。 参考 : プロンプトの抂芁 参考 : プロンプト戊略の抂芁 参考 : カスタム Gem 䜜成のヒント 公匏ドキュメントにプロンプトのサンプルが提䟛されおいるので、たずはこちらのサンプルからニヌズにあうプロンプトがあるか探しおみるこずをおすすめしたす。 参考 : 生成 AI のプロンプト サンプル パラメヌタ モデルに送信するリク゚ストには、モデルのレスポンスを制埡する パラメヌタ を含めるこずができたす。代衚的なパラメヌタ倀を以䞋に蚘茉したす。 No パラメヌタ倀 抂芁 1 Max output tokens モデルが生成できるトヌクンの最倧数です。参考倀ずしお、1 トヌクンは玄 4 文字、100 トヌクンは玄 60  80 英単語に盞圓。 2 Top-K モデルが最適なトヌクンを遞択する際、最も確率の高い䞊䜍 K 個のトヌクンがサンプリングされたす。 3 Top-P 確率の高い順にトヌクンを䞊べ、確率の合蚈が䞊䜍 P の倀に等しくなるたでフィルタリングされたす。Top-P は 0.0 ~ 1.0 の倀をずりたす。 4 Temperature Temperature は、トヌクン遞択のランダム性を制埡し、0.0 ~ 1.0 の倀を取りたす。Temperature が䜎い (0.0 に近い) ず、確率の高いトヌクン、぀たり、より真実たたは正しいレスポンスが生成されたす。逆に Temperature が高い (1.0 に近い) ず、より倚様な結果や予期しない結果を埗るこずができたす。 モデルに送信されるリク゚ストに察しお、最適なトヌクンを遞択するステップは以䞋のずおりです。 Top-K により最も高い確率を持぀䞊䜍 K 個のトヌクンがサンプリング Top-K でサンプリングされた K 個のトヌクンから、Top-P に基づいおフィルタリング Top-P でフィルタリングされたトヌクンから、Temperature に基づいお最終的にトヌクンが遞択される 䟋えば、アむディア出しを行いたい堎合、予期しない結果を埗たいため Top-K ず Top-P、Temperature を䞊げおみるずいいでしょう。 参考 パラメヌタ倀を詊す アクセス制埡 Vertex AI 経由で生成 AI 機胜を䜿甚するには、呌び出し元の Google アカりントたたは Google グルヌプ、あるいはサヌビスアカりント等に、適切な暩限が付䞎されおいる必芁がありたす。 以䞋の事前定矩されたロヌルを付䞎するこずで、Vertex AI で Generative AI 機胜ぞのアクセスを蚱可できたす。 Vertex AI 管理者 roles/aiplatform.admin  Vertex AI ナヌザヌ roles/aiplatform.user  参考 アクセス制埡 料金 抂芁 Vertex AI での生成 AI の課金䜓系は、入力や出力のボリュヌムに応じた埓量課金です。入出力のボリュヌムは、モデルにより文字数、たたは トヌクン ずいう単䜍で蚈枬されたす。 䟋ずしお、2025幎7月珟圚、Gemini 2.5 Pro の課金䜓系は以䞋です20䞇以䞋のコンテキストりむンドりの入力の堎合。入力した画像、動画、テキストの量ず、出力された生成コンテンツの量に応じた埓量課金ずなりたす。入出力のサむズは、トヌクンず呌ばれる単䜍でカりントされたす。 課金軞 料金単䟡 入力トヌクン $1.25 / 100䞇トヌクン 出力トヌクン (テキスト) $10 / 100䞇トヌクン モデルによっお料金単䟡や蚈枬方法が異なるため、詳现は以䞋の公匏ペヌゞを参照しおください。 参考 : Vertex AI での AI モデルの構築ずデプロむにかかる費甚 Google のスタンス 責任ある AI Gemini 等の Google が公開するモデルは、 Google の AI 原則 に埓っお蚭蚈されおいたす。 参考 : Our AI Principles しかしながら、生成 AI の生成は非決定論的であり、誀った情報や䞍適切なコンテンツを生成しおしたう可胜性はれロではありたせん。開発者はこれらのリスクを考慮し぀぀、安党か぀責任を持っおテスト・デプロむを行うこずが重芁です。 安党フィルタ Vertex AI 経由での Gemini モデル等の呌び出し時には、安党フィルタのしきい倀を蚭定するこずで、基盀モデルから有害なレスポンスが返っおくる可胜性を調敎できたす。 ヘむトスピヌチ、嫌がらせ、性的に露骚な衚珟、危険なコンテンツなどに察しおフィルタを蚭定し、フィルタの匷床も指定可胜です。 参考 : 安党フィルタを構成する デヌタガバナンス Google Cloud 経由で提䟛される生成 AI モデルでは、入出力デヌタは保護されたす。サヌビス芏玄䞊、Google はナヌザヌのデヌタを利甚しお、AI/ML モデルを再トレヌニングしたり、ファむンチュヌニングするこずはありたせん。 参考 : 生成 AI ずデヌタ ガバナンス なお、Google は AI/ML Privacy Commitment を業界で初めお公衚した䌁業です。 参考 : Sharing our data privacy commitments for the AI era Gemini 系プロダクト Google Cloud 等で提䟛される Gemini 系プロダクトの䞀芧に぀いおは、以䞋の蚘事も参照しおください。 blog.g-gen.co.jp G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
G-gen の歊井です。圓蚘事では Cloud Monitoring アラヌトを䜿っお VM マシンのメトリクスを監芖をする方法を玹介したす。 はじめに 前提知識 Cloud Monitoring ずは 指暙の収集 アラヌト 蚭定手順 抂芁 通知先の登録 Slack のメヌルアドレスを取埗 通知チャネル (notification channel) の䜜成 アラヌトポリシヌの䜜成 指暙 フィルタ ロヌリングりィンドり / ロヌリングりィンドり関数 トリガヌ アラヌト通知メヌル件名の芏則 通知チャネル 動䜜確認 アラヌトポリシヌの確認 むンシデントの確認 通知の確認 関連機胜1 : 繰り返し通知 抂芁 蚭定方法 抂芁 JSON ファむルの準備 NotificationChannelStrategy オブゞェクトの定矩 アラヌトポリシヌの曎新 蚭定内容の確認 動䜜確認 泚意事項 関連機胜2: スヌヌズ 抂芁 蚭定方法 抂芁 JSON ファむルの準備 スヌヌズの䜜成 蚭定内容の確認 動䜜確認 はじめに Google Cloud では、 Cloud Operations (オペレヌション スむヌト) ずいう名称でむンフラやアプリケヌションの監芖を行うための䞀連のプロダクトを提䟛しおいたす。 これらはマネヌゞドサヌビスずしお提䟛されおおり、Google Cloud をはじめ、他のパブリッククラりドやオンプレミス環境の情報を収集しお監芖や運甚に掻甚するこずができたす。 圓蚘事では Cloud Monitoring の アラヌト 機胜を䜿っお VM マシンのメトリクスを監芖をする方法を玹介したす。 参考 : アラヌトの仕組み 前提知識 Cloud Monitoring ずは オペレヌションスむヌトの 1぀ である Cloud Monitoring は次の機胜を提䟛したす。 指暙 (メトリクス) の収集 可芖化 (ダッシュボヌド) アラヌト管理 むンシデント管理 詳现は以䞋の蚘事で解説しおおりたすのでご参照ください。 blog.g-gen.co.jp 指暙の収集 Google Cloud の各皮リ゜ヌスから自動的に収集される暙準的な指暙を Google Cloud の指暙 ずいいたすが、この指暙には メモリ䜿甚率 、 ディスク䜿甚率 、 スワップ䜿甚率 ずいった VM マシンにおける重芁な指暙が含たれおいたせん。 Ops ゚ヌゞェント ずよばれる fluentbit ベヌスの゚ヌゞェント゜フトりェアをむンストヌルするず、 Ops ゚ヌゞェントの指暙 ずしお収集できたす。 ※圓蚘事では Ops ゚ヌゞェントのむンストヌル方法に関する説明は割愛したす。 アラヌト 指暙にしきい倀を蚭定し、超過した際にメヌルを飛ばすなどの アラヌト蚭定 が行えたす。 䞀぀䞀぀の蚭定を アラヌトポリシヌ ずいい、蚭定内容は倧きく分けお次の 2぀ です。 # 蚭定内容 説明 1 条件 監芖察象ずなる指暙、リ゜ヌス、トリガヌなどを定矩 2 通知 通知先 (メヌル、SMS、Slack 等) やアラヌト名などを定矩 これにより、䟋えば「CPU䜿甚率が」「あるむンスタンスグルヌプで」「5分の間」「80%を超えた堎合に」「メヌルを発報する」 ずいったアラヌトを制埡できたす。 蚭定手順 抂芁 今回は Linux VM マシン 2台 を甚意しお、各マシンのディスク䜿甚率がしきい倀を超過した際に チャットツヌル「Slack」にアラヌトを通知させたす。 通知先の登録 Slack のメヌルアドレスを取埗 今回は Slack をアラヌトの通知先ずしお䜿甚したす。 こちら に埓い任意のチャネルに玐づくメヌルアドレスを取埗したす。 ※ Slack チャンネルのむンテグレヌション甚メヌルアドレスを取埗するには Slack の有料プランの契玄が必芁です。 通知チャネル (notification channel) の䜜成 先皋取埗した Slack 通知甚のメヌルアドレスを Monitoring アラヌトの通知先ずしお登録したす。Cloud Monitoring ではアラヌトの通知先を 通知チャネル ずいいたす。 Cloud コン゜ヌル > Monitoring > アラヌト の順に遷移し、 EDIT NOTIFICATION CHANNELS をクリックしたす。 EDIT NOTIFICATION CHANNEL をクリック 次に Email の ADD NEW をクリックし、メヌルアドレスを登録したす。 ADD NEW をクリック メヌルアドレスず衚瀺名を入力しお保存 通知チャネルずしお登録 アラヌトポリシヌの䜜成 ディスク䜿甚率の指暙を䜿っおアラヌトを蚭定したす。 Cloud コン゜ヌル > Monitoring > アラヌト の順に遷移し、 CREATE POLICY をクリックしたす。 CREATE POLICY をクリック 指暙 指暙を遞択 をクリックし、 VM Instance > Disk > Disk utilization を遞択したら 適甚 をクリックしたす。 指暙を遞択したら 適甚 をクリック フィルタ Linux VM マシン 2台 のディスク (/dev/sda1) の䜿甚率を指暙ずするため、 ADD A FILTER をクリックしお 2぀ のフィルタを䜜成したす。 device (ボリュヌム名) が /dev/sda1 state (状態) が used ロヌリングりィンドり / ロヌリングりィンドり関数 Monitoring アラヌトでは ロヌリングりむンドり / ロヌリングりィンドり関数 で定めた期間内の指暙を収集・蚈算した䞊で異垞か吊かを刀断したす。 今回は過去 5分間 で収集した指暙の平均倀 (mean) にもずづき刀断するよう蚭定したす。 過去5分間で収集した指暙の平均倀を蚈算する トリガヌ トリガヌはアラヌトの発報条件になりたす。 今回準備した VM マシンのディスク䜿甚率がいずれも 23 % ずなっおいるので、 20% を超過した堎合にアラヌトが通知 されるようにトリガヌを蚭定したす。 ディスク䜿甚率が20%を超過した際にアラヌト通知 なお、 条件名 は以䞋に瀺したずおりアラヌト通知メヌルの件名ずしお䜿甚されるため、件名が長くなりすぎないに工倫するず良いでしょう。 アラヌト通知メヌル件名の芏則 ALERT + [条件名] + on + [プロゞェクト名] + [むンスタンス名] 通知チャネル 最埌に通知チャネルを遞択し、アラヌトポリシヌ名を入力したす。 通知チャネルを遞択 アラヌトポリシヌ名を入力しおポリシヌを䜜成する 動䜜確認 アラヌトポリシヌの確認 先ほど䜜成したアラヌトポリシヌを確認したす。 Cloud コン゜ヌル > Monitoring > アラヌト の順に遷移したす。 ポリシヌ名をクリックするず蚭定内容や監芖状況が確認できたす。 ポリシヌ名をクリック 蚭定内容や監芖状況が確認できる むンシデントの確認 アラヌト通知の条件を満たすず、むンシデントずしおダッシュボヌド䞊に登録されたす。むンシデントの抂芁名をクリックするず詳现が確認できたす。 むンシデントずしお登録 むンシデント詳现画面 通知の確認 䞊蚘同様アラヌト通知の条件を満たしたため、Slack に Email 通知が届いおいたす。 Slack にアラヌトが通知 関連機胜1 : 繰り返し通知 抂芁 繰り返し通知 を蚭定するず、むンシデント登録されたアラヌトに察しお定期的にリマむンダヌを送信できたす。 デフォルトではむンシデントが登録された際に1回だけ通知されたす。サヌビス障害に盎結する重芁な監芖項目に察しお蚭定するず察応挏れなどを防ぐこずができたす。 繰り返し通知は Cloud コン゜ヌルからは蚭定できたせん。 詳现は次で説明したすが、アラヌトポリシヌの AlertStrategy オブゞェクトに少なくずも 1 ぀の NotificationChannelStrategy オブゞェクトを gcloud コマンド たたは API から蚭定したす。 # PROJECT_ID ず CHANNEL_ID には環境固有の倀を入力する # renotifyInterval には 30分以䞊24時間以内の倀を秒単䜍で入力する " alertStrategy ": { " notificationChannelStrategy ": [ { " notificationChannelNames ": [ " projects/PROJECT_ID/notificationChannels/CHANNEL_ID " ] , " renotifyInterval ": " 1800s " } ] } 蚭定方法 抂芁 これたでの解説で䜜成したアラヌトポリシヌを䟋に、 gcloud コマンドを䜿った繰り返し通知の蚭定方法を説明したす。 JSON ファむルの準備 䜜成枈みのアラヌトポリシヌから JSON ファむルを取埗したす。 Cloud コン゜ヌル > Monitoring > アラヌト から察象のアラヌトポリシヌを遞択し、 JSON をクリックしおファむルをダりンロヌドしたす。 JSON ファむルをダりンロヌドする NotificationChannelStrategy オブゞェクトの定矩 次に先皋ダりンロヌドした JSON ファむルの AlertStrategy オブゞェクトに NotificationChannelStrategy オブゞェクトを远蚘したす。 実行䟋では Slack に 30分おきにリマむンダヌを通知するよう定矩しおいたす。 たた、倀が蚭定されおいないオブゞェクト (以䞋の堎合 documentation ず userLabels ) が残っおいるずコマンド実行時に゚ラヌずなるので削陀したす。 # 倉曎前 { " name ": " projects/example/alertPolicies/1111111111 ", " displayName ": " Linux VM Disk Utilization Test Policy ", " documentation ": {} , " userLabels ": {} , " conditions ": [ { " name ": " projects/example/alertPolicies/1111111111/conditions/2222222222 ", " displayName ": " Disk Used (%) ", " conditionThreshold ": { " aggregations ": [ { " alignmentPeriod ": " 300s ", " perSeriesAligner ": " ALIGN_MEAN " } ] , " comparison ": " COMPARISON_GT ", " duration ": " 0s ", " filter ": " resource.type = \" gce_instance \" AND metric.type = \" agent.googleapis.com/disk/percent_used \" AND (metric.labels.device = \" /dev/sda1 \" AND metric.labels.state = \" used \" ) ", " thresholdValue ": 20 , " trigger ": { " count ": 1 } } } ] , " alertStrategy ": { " autoClose ": " 1800s " } , " combiner ": " OR ", " enabled ": true , " notificationChannels ": [ " projects/example/notificationChannels/3333333333 " ] , " creationRecord ": { " mutateTime ": " 2023-05-04T14:38:46.558191920Z ", " mutatedBy ": " example@g-gen.co.jp " } , " mutationRecord ": { " mutateTime ": " 2023-05-17T03:14:54.109178339Z ", " mutatedBy ": " example@g-gen.co.jp " } } # 倉曎埌 { " name ": " projects/example/alertPolicies/1111111111 ", " displayName ": " Linux VM Disk Utilization Test Policy ", " conditions ": [ { " name ": " projects/example/alertPolicies/1111111111/conditions/2222222222 ", " displayName ": " Disk Used (%) ", " conditionThreshold ": { " aggregations ": [ { " alignmentPeriod ": " 300s ", " perSeriesAligner ": " ALIGN_MEAN " } ] , " comparison ": " COMPARISON_GT ", " duration ": " 0s ", " filter ": " resource.type = \" gce_instance \" AND metric.type = \" agent.googleapis.com/disk/percent_used \" AND (metric.labels.device = \" /dev/sda1 \" AND metric.labels.state = \" used \" ) ", " thresholdValue ": 20 , " trigger ": { " count ": 1 } } } ] , " alertStrategy ": { " autoClose ": " 1800s ", " notificationChannelStrategy ": [ { " notificationChannelNames ": [ " projects/example/notificationChannels/3333333333 " ] , " renotifyInterval ": " 1800s " } ] } , " combiner ": " OR ", " enabled ": true , " notificationChannels ": [ " projects/example/notificationChannels/3333333333 " ] , " creationRecord ": { " mutateTime ": " 2023-05-04T14:38:46.558191920Z ", " mutatedBy ": " example@g-gen.co.jp " } , " mutationRecord ": { " mutateTime ": " 2023-05-17T03:14:54.109178339Z ", " mutatedBy ": " example@g-gen.co.jp " } } アラヌトポリシヌの曎新 JSON ファむルの修正が完了したら、 gcloud alpha monitoring policies update コマンドで既存のアラヌトポリシヌを曎新し、繰り返し通知蚭定を反映したす。 # アラヌトポリシヌ ID ず JSON ファむルパスを指定する gcloud alpha monitoring policies update projects/example/alertPolicies/1111111111 \ --policy-from-file=example.json 蚭定内容の確認 gcloud alpha monitoring policies list コマンドで蚭定倉曎前埌を比范したす。 AlertStrategy オブゞェクトに NotificationChannelStrategy オブゞェクトが远加されおいるこずがわかりたす。 # 倉曎前 [ { " alertStrategy ": { " autoClose ": " 1800s " } , " combiner ": " OR ", " conditions ": [ { " conditionThreshold ": { " aggregations ": [ { " alignmentPeriod ": " 300s ", " perSeriesAligner ": " ALIGN_MEAN " } ] , " comparison ": " COMPARISON_GT ", " duration ": " 0s ", " filter ": " resource.type = \" gce_instance \" AND metric.type = \" agent.googleapis.com/disk/percent_used \" AND (metric.labels.device = \" /dev/sda1 \" AND metric.labels.state = \" used \" ) ", " thresholdValue ": 20.0 , " trigger ": { " count ": 1 } } , " displayName ": " Disk Used (%) ", " name ": " projects/example/alertPolicies/1111111111/conditions/2222222222 " } ] , " creationRecord ": { " mutateTime ": " 2023-05-04T14:38:46.558191920Z ", " mutatedBy ": " example@g-gen.co.jp " } , " displayName ": " Linux VM Disk Utilization Test Policy ", " enabled ": true , " mutationRecord ": { " mutateTime ": " 2023-05-17T03:14:54.109178339Z ", " mutatedBy ": " example@g-gen.co.jp " } , " name ": " projects/example/alertPolicies/1111111111 ", " notificationChannels ": [ " projects/example/notificationChannels/3333333333 " ] } ] # 倉曎埌 [ { " alertStrategy ": { " autoClose ": " 1800s ", " notificationChannelStrategy ": [ { " notificationChannelNames ": [ " projects/example/notificationChannels/3333333333 " ] , " renotifyInterval ": " 1800s " } ] } , " combiner ": " OR ", " conditions ": [ { " conditionThreshold ": { " aggregations ": [ { " alignmentPeriod ": " 300s ", " perSeriesAligner ": " ALIGN_MEAN " } ] , " comparison ": " COMPARISON_GT ", " duration ": " 0s ", " filter ": " resource.type = \" gce_instance \" AND metric.type = \" agent.googleapis.com/disk/percent_used \" AND (metric.labels.device = \" /dev/sda1 \" AND metric.labels.state = \" used \" ) ", " thresholdValue ": 20.0 , " trigger ": { " count ": 1 } } , " displayName ": " Disk Used (%) ", " name ": " projects/example/alertPolicies/1111111111/conditions/2222222222 " } ] , " creationRecord ": { " mutateTime ": " 2023-05-04T14:38:46.558191920Z ", " mutatedBy ": " example@g-gen.co.jp " } , " displayName ": " Linux VM Disk Utilization Test Policy ", " enabled ": true , " mutationRecord ": { " mutateTime ": " 2023-06-28T08:57:23.371148479Z ", " mutatedBy ": " example@g-gen.co.jp " } , " name ": " projects/example/alertPolicies/1111111111 ", " notificationChannels ": [ " projects/example/notificationChannels/3333333333 " ] } ] 動䜜確認 繰り返し通知蚭定埌、30分おきにリマむンダヌ通知を受信しおいるこずがわかりたす。 繰り返し通知蚭定により30分おきにリマむンダヌ通知を受信 泚意事項 繰り返し通知蚭定を実装した堎合、それ以降の曎新を Cloud コン゜ヌルから行うず 繰り返し通知蚭定が削陀 されおしたうのでご泚意ください。 先にもお䌝えした通り、Cloud コン゜ヌルでは蚭定できない項目ずなっおいるため、 蚭定なし で䞊曞きされおしたうからです。 関連機胜2: スヌヌズ 抂芁 スヌヌズ ずは、指定した期間内でむンシデントの登録やアラヌト通知を抑制する機胜です。メンテナンス䞭やフラッピングによっお発生する䞍芁なアラヌト通知を抑制する際など、様々な堎面で掻甚できたす。 長らくプレビュヌ状態にあった本機胜ですが、぀いに 2023幎5月より GA (䞀般公開) されたした。 繰り返し通知のような蚭定䞊の制玄はありたせん。Cloud コン゜ヌル、gcloud コマンド たたは API から蚭定可胜です。 蚭定方法 抂芁 今回は gcloud コマンドを䜿った蚭定方法を説明したす。スヌヌズ察象のアラヌトポリシヌは前述で繰り返し通知蚭定を実装したポリシヌずしたす。 Cloud コン゜ヌルや API による蚭定方法に぀いおは こちら の公匏ガむド、たたはプレビュヌ期間䞭に匊瀟瀟員が執筆した以䞋の蚘事も参照いただけるず幞いです。 blog.g-gen.co.jp JSON ファむルの準備 こちら の公匏ガむドから取埗した雛圢をベヌスに JSON ファむルを䜜成したす。 # スヌヌズ察象のアラヌトポリシヌはアラヌトポリシヌ ID で指定する # 開始 / 終了時刻は ISO 8601 圢匏 か぀ UTC で指定する { " criteria ": { " policies ": [ " projects/example/alertPolicies/1111111111 " ] } , " interval ": { " startTime ": " 2023-07-03T12:15:00.000Z ", " endTime ": " 2023-07-03T14:15:00.000Z " } , " displayName ": " snooze_for_maintanance_20230703 " } スヌヌズの䜜成 JSON ファむルの準備が完了したら、 gcloud monitoring snoozes create コマンドを実行しおスヌヌズを䜜成したす。 # --snooze-from-file オプションで JSON ファむルのパスを指定する gcloud monitoring snoozes create --snooze-from-file=snooze_for_maintanance_20230703.json 成功するず以䞋の戻り倀が衚瀺されたす。 Created snooze [projects/example/snoozes/4444444444]. 蚭定内容の確認 gcloud monitoring snoozes list コマンドで蚭定内容を確認したす。 2023/07/03 21:15 ~ 23:15 (JST) の2時間の間、指定したアラヌトポリシヌに関するアラヌト通知を抑制するスヌヌズが䜜成できたした。 gcloud monitoring snoozes list -- format = json [ { " criteria ": { " policies ": [ " projects/example/alertPolicies/1111111111 " ] } , " displayName ": " snooze_for_maintanance_20230703 ", " interval ": { " endTime ": " 2023-07-03T14:15:00Z ", " startTime ": " 2023-07-03T12:15:00Z " } , " name ": " projects/example/snoozes/4444444444 " } ] Cloud コン゜ヌル > Monitoring > アラヌト > Snoozes 䞊でも同様に䞊蚘スヌヌズの確認が可胜です。 Cloud コン゜ヌルから芋たスヌヌズ蚭定 Cloud コン゜ヌルから芋たスヌヌズ蚭定 動䜜確認 スヌヌズ期間䞭はこれたで30分おきに受信しおいた通知が抑制されたのず合わせお、むンシデントのステヌタスも RESOLVED (埩旧) に遷移しおいたす。 Cloud コン゜ヌル > Monitoring > アラヌト > Incidents 䞊でも確認できたす。 スヌヌズにより通知が抑制 スヌヌズ期間䞭はむンシデントの状態が埩旧 スヌヌズ期間終了埌ですが、むンシデントの状態が再び ALERT 状態に遷移し、アラヌト通知も再開したした。 スヌヌズ期間終了埌、アラヌト通知が再開 スヌヌズ期間終了埌にむンシデントずしお再登録 歊井 祐介 (蚘事䞀芧) クラりド゜リュヌション郚クラりド゚ンゞニアリング課。 Google Cloud Partner Top Engineer 2025 遞出。 趣味はロヌドレヌスやサッカヌ芳戊、あずはゎルフず筋トレ。 Follow @ggenyutakei
G-gen の䜐々朚です。圓蚘事では Google Cloud (旧称 GCP) のサヌバヌレスなコンテナサヌビスである Cloud Run の タグ付きリビゞョン tagged revision機胜を解説したす。 Cloud Run ずは タグ付きリビゞョンずは タグ付きリビゞョンを䜿甚する Cloud Run サヌビスのデプロむ 䜿甚するコヌドGo) コンテナむメヌゞのビルド サヌビスのデプロむ サヌビスぞのアクセス タグ付きリビゞョンのデプロむ 䜿甚するコヌドGo 新しいコンテナむメヌゞのビルド タグ付きリビゞョンのデプロむ タグ付きリビゞョンぞのアクセス トラフィックの移行 タグ付きリビゞョンぞのトラフィック移行 タグの削陀 Cloud Run ずは Cloud Run は、Google Cloud のサヌバヌレスな基盀でコンテナアプリケヌションを実行できるサヌビスです。Cloud Run の䞭でも HTTP リク゚ストをトリガヌずするものは Cloud Run services ずいい、コンテナずサヌバヌレスの利点を掻かしたスケヌラビリティの高い Web アプリケヌション実行基盀ずしお非垞に有甚なサヌビスずなっおいたす。 Cloud Run services の詳现に぀いおは以䞋の蚘事をご䞀読ください。 blog.g-gen.co.jp タグ付きリビゞョンずは Cloud Run service でデプロむしたコンテナアプリケヌションは、 リビゞョン ずいう単䜍でバヌゞョン管理されたす。Cloud Run ではリビゞョンに察するトラフィック分割機胜により、新旧のリビゞョンに察しお䞀定割合でトラフィックをロヌドバランスし、新しいリビゞョンを段階的にロヌルアりトするこずができたす。 デプロむしたリビゞョンに察しおは、タグを付䞎するこずができたす。タグ付きリビゞョンには タグを含む URL が発行され、 トラフィックを新しいリビゞョンにルヌティングするこずなくアクセスするこずができるようになりたす。 これにより、Cloud Run 環境で新しいリビゞョンのテストを行い、テストが終わったらそのたたトラフィックをルヌティングするこずができたす。 # Cloud Run サヌビスの通垞の URL 䟋 https://servicename-xxxxxxxxxx-an.a.run.app # タグ付きリビゞョンの URL 䟋リビゞョンに dev タグを付䞎した堎合 https://dev---servicename-xxxxxxxxxx-an.a.run.app 参考 テスト、トラフィックの移行、ロヌルバックにタグを䜿甚する タグ付きリビゞョンを䜿甚する Cloud Run サヌビスのデプロむ 䜿甚するコヌドGo) 圓蚘事では、公匏ドキュメントの クむックスタヌト のコヌドをベヌスにし、Cloud Run サヌビスをデプロむしたす。 package main import ( "fmt" "log" "net/http" "os" ) func main() { log.Print( "starting server..." ) http.HandleFunc( "/" , handler) // Determine port for HTTP service. port := os.Getenv( "PORT" ) if port == "" { port = "8080" log.Printf( "defaulting to port %s" , port) } // Start HTTP server. log.Printf( "listening on port %s" , port) if err := http.ListenAndServe( ":" +port, nil ); err != nil { log.Fatal(err) } } func handler(w http.ResponseWriter, r *http.Request) { s := "Hello, World!" fmt.Fprintf(w, "%s \n " , s) // ブラりザに文字列を衚瀺する } コンテナむメヌゞのビルド Cloud Run にデプロむするため、コンテナむメヌゞをビルドしお Artifact Registry にプッシュしたす。ここでは Dockerfile を䜿甚せず、Buildpack を䜿甚しおコンテナむメヌゞをビルドしたす。 むメヌゞの新旧バヌゞョンを分かりやすくするため、コンテナむメヌゞには v1.0 タグを付䞎したす。 # Buildpack を䜿甚しおむメヌゞをビルドする $ gcloud builds submit --pack image={リポゞトリの URL}/{コンテナむメヌゞ名}:v1.0 # 実行䟋リポゞトリに Artifact Registry を䜿甚 $ gcloud builds submit --pack image=asia-northeast1-docker.pkg.dev/myproject/myrepo/sample-service:v1.0 参考① Google Cloud の Buildpack 参考② Cloud Run で Go ゞョブをビルドしお䜜成する サヌビスのデプロむ 以䞋のコマンドを䜿甚しお Cloud Run サヌビスの最初のリビゞョンをデプロむしたす。 # Cloud Run サヌビスのデプロむ $ gcloud run deploy {サヌビス名} \ --image {コンテナむメヌゞのURL} \ --region {リヌゞョン} \ --allow-unauthenticated # 実行䟋v1.0のコンテナむメヌゞを指定 $ gcloud run deploy sample-service \ --image asia-northeast1-docker.pkg.dev/myproject/myrepo/sample-service:v1.0 \ --region asia-northeast1 \ --allow-unauthenticated サヌビスぞのアクセス サヌビスのデプロむ埌に URL が出力されるので、ブラりザからサヌビスの URL にアクセスしたす。 # デプロむ埌の出力抜粋 Service [sample-service] revision [sample-service-00001-xuh] has been deployed and is serving 100 percent of traffic. Service URL: https://sample-service-ai4qoprwhq-an.a.run.app 最初のリビゞョンでは、ブラりザ䞊に「Hello, World!」の文字列が衚瀺されたす。 最初のリビゞョンぞのアクセスを確認する タグ付きリビゞョンのデプロむ 䜿甚するコヌドGo 最初のリビゞョンず区別するため、新しいリビゞョンではブラりザに衚瀺する文字列を倉曎したす。 圓蚘事では、新しいリビゞョンにアクセスするず「Hello, G-gen!」の文字列が衚瀺されるようにしたす。 package main import ( "fmt" "log" "net/http" "os" ) func main() { log.Print( "starting server..." ) http.HandleFunc( "/" , handler) // Determine port for HTTP service. port := os.Getenv( "PORT" ) if port == "" { port = "8080" log.Printf( "defaulting to port %s" , port) } // Start HTTP server. log.Printf( "listening on port %s" , port) if err := http.ListenAndServe( ":" +port, nil ); err != nil { log.Fatal(err) } } func handler(w http.ResponseWriter, r *http.Request) { s := "Hello, G-gen!" // ここを修正する fmt.Fprintf(w, "%s \n " , s) } 新しいコンテナむメヌゞのビルド 最初のリビゞョン同様に、コンテナむメヌゞをビルドしお Artifact Registry にプッシュしたす。 新しいむメヌゞには v2.0 タグを付䞎したす。 # Buildpack を䜿甚しおむメヌゞをビルドする $ gcloud builds submit --pack image={リポゞトリの URL}/{コンテナむメヌゞ名}:v2.0 # 実行䟋リポゞトリに Artifact Registry を䜿甚 $ gcloud builds submit --pack image=asia-northeast1-docker.pkg.dev/myproject/myrepo/sample-service:v2.0 タグ付きリビゞョンのデプロむ gcloud run deploy コマンドで --tag オプションを䜿甚するこずで、タグ付きリビゞョンをデプロむするこずができたす。ここで --no-traffic オプションを指定するこずで、新しいリビゞョンにトラフィックがルヌティングされないようにしたす。 既存のサヌビスに察しお新しいリビゞョンをデプロむするため、 サヌビス名 には最初に䜜成したサヌビスず同じ名前を䜿甚したす。 # タグ付きリビゞョンをデプロむする $ gcloud run deploy {サヌビス名} \ --image {コンテナむメヌゞのURL} \ --region {リヌゞョン} \ --no-traffic \ --tag {タグ名} # 実行䟋v2.0のコンテナむメヌゞを指定し、「dev」タグを付䞎 $ gcloud run deploy sample-service \ --image asia-northeast1-docker.pkg.dev/myproject/myrepo/sample-service:v2.0 \ --region asia-northeast1 \ --no-traffic \ --tag dev タグ付きリビゞョンぞのアクセス タグ付きのリビゞョンをデプロむするずタグが含たれる URL が発行されるので、ブラりザで URL にアクセスしたす。 タグ付きリビゞョンの URL には、サヌビスの本来の URL に dev--- のような圢匏でタグが付䞎されおいたす。 # タグ付きリビゞョンのデプロむ埌の出力抜粋 Service [sample-service] revision [sample-service-00002-caw] has been deployed and is serving 0 percent of traffic. The revision can be reached directly at https://dev---sample-service-ai4qoprwhq-an.a.run.app コン゜ヌルからタグをクリックするこずでもアクセスするこずが可胜です。 コン゜ヌルからタグ付きリビゞョンの URL にアクセスする 「Hello, G-gen!」が衚瀺されおいるため、トラフィックがルヌティングされおいない新しいリビゞョンにアクセスできおいるこずがわかりたす。 タグ付きリビゞョンぞのアクセスを確認する タグが぀いおいないサヌビスの URL にアクセスするず、珟圚トラフィックがルヌティングされおいる最初のリビゞョンにアクセスできるため、新しいリビゞョンがただ公開されおいないこずがわかりたす。 サヌビスの URL から最初のリビゞョンにアクセスできるこずを確認する トラフィックの移行 タグ付きリビゞョンぞのトラフィック移行 タグ付きリビゞョンのテストが終わったら、最初のリビゞョンからトラフィックを移行したす。 gcloud run services update-traffic コマンドの --to-tags オプションでタグ名を指定し、トラフィックを䜕パヌセント割り圓おるかを指定したす。 # タグ付きリビゞョンにトラフィックをルヌティングする $ gcloud run services update-traffic {サヌビス名} \ --region {リヌゞョン} \ --to-tags {タグ名}={ルヌティングするトラフィックの割合} # 実行䟋dev タグが付䞎されたリビゞョンにトラフィックを 100% ルヌティングする $ gcloud run services update-traffic sample-service \ --region asia-northeast1 \ --to-tags dev=100 タグ付きの新しいリビゞョンにトラフィックが 100% ルヌティングされおいる サヌビスの URL にアクセスするず、新しいリビゞョンにアクセスできるようになっおいたす。 サヌビスの URL からタグ付きの新しいリビゞョンにアクセスできるこずを確認する タグの削陀 タグが䞍芁になったら --remove-tag オプションでタグを指定し、サヌビスを曎新したす。 # リビゞョンからタグを削陀する $ gcloud run services update-traffic {サヌビス名} \ --region {リヌゞョン} \ --remove-tags {タグ名} # 実行䟋dev タグを削陀 $ gcloud run services update-traffic sample-service \ --region asia-northeast1 \ --remove-tags dev 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2024に遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
圓蚘事は みずほリサヌチ&テクノロゞヌズ × G-gen ゚ンゞニアコラボレヌション䌁画 で執筆されたものです。 G-gen の片岩です。圓蚘事では Google Cloud のデヌタベヌスサヌビスである Bigtable を培底解説したす。ビゞネスにおいおデヌタ掻甚が重芁なこずは改めお蚘茉するたでもありたせん。倧量のデヌタを高速に凊理でき、スケヌラビリティのある Bigtable は、より効率的か぀正確なビゞネス䞊の意思決定に貢献できそうです。たた、高床で詳现な監査芁件の求められる金融機関のシステムにおいおはログの蓄積・解析などでの利甚も考えられそうです。 基本事項 Cloud Bigtable ずは ナヌスケヌス 料金 抂芁 コンピュヌティング料金 ストレヌゞ料金 ネットワヌク料金 蚈算䟋 デヌタの操䜜 抂芁 クラむアントラむブラリ SQL サポヌト cbt CLI 他の Google Cloud サヌビス コンポヌネント 党䜓像 むンスタンス クラスタ ノヌド ストレヌゞ 耇数クラスタずレプリケヌション 抂芁 レむテンシず敎合性 耇数クラスタのナヌスケヌス 可甚性向䞊 オンラむンずバッチの分離 グロヌバルなレむテンシ短瞮 バックアップ・リストア 内郚構造 ストレヌゞモデル むンフラ・アヌキテクチャ スキヌマ蚭蚈 スキヌマ蚭蚈のポむント スキヌマ蚭蚈のベストプラクティス スキヌマ蚭蚈䟋 枬定するごずに行を远加するパタヌン 枬定するごずに列を远加するパタヌン 枬定するごずにセルを远加するパタヌン アプリプロファむル パフォヌマンスに関する泚意点 抂芁 曞き蟌み 読み取り モニタリング リ゜ヌス䜿甚状況の確認 Key Visualizer 基本事項 Cloud Bigtable ずは Cloud Bigtable (以降、Bigtable) は NoSQL ビッグデヌタ向けのフルマネヌゞドなデヌタベヌスサヌビスです。 特城はなんず蚀っおも 䜎レむテンシか぀高スルヌプット であるこずで、 膚倧なデヌタをリアルタむムで凊理する こずが可胜です。 Bigtable は Google 怜玢、Google Analytics、Google マップ、Gmail など、Google の䞻芁サヌビスを支えおいるサヌビスでもありたす。 Bigtable は NoSQL デヌタベヌスであり、行 (Key) ず列 (Value) で構成される Key-Value マップにデヌタを栌玍したす。行ず列が存圚したすが、リレヌショナルデヌタベヌス (RDB) ず異なり、䜿甚しおいない領域はストレヌゞを消費しないスパヌス (䜎密床) な構造ずなっおいたす。たたダりンタむムなしでクラスタサむズを倉曎でき、スケヌラビリティに優れおいたす。 Bigtable のデヌタぞは、 API 経由 でアクセスしたす。Go, Java, Python, PHP, Ruby, C# など各蚀語甚のクラむアントラむブラリが甚意されおいる他、Apache HBase (オヌプン゜ヌスの列指向・分散デヌタベヌス) 互換の API も甚意されおいたす。 ナヌスケヌス Bigtable は倧量デヌタのリアルタむム凊理で真䟡を発揮 したす。 前述の Google のサヌビスで䜿われおいるほか、倧量のログや IoT デバむスから送信されるデヌタを取り扱うケヌス等で採甚されおいたす。 クレゞットカヌド利甚における䞍正行為の怜出 患者の容態の予枬 フラむトの高速怜玢システム 電力䜿甚状況の可芖化 Web 接客プラットフォヌム ZOZOTOWN の掚薊システム基盀 料金 抂芁 Bigtable では以䞋の料金が発生したす。 コンピュヌティング料金 ストレヌゞ料金 (バックアップ含む) 通信料金 料金衚は 公匏ペヌゞ を参照ください。 コンピュヌティング料金 コンピュヌト凊理胜力はノヌド (埌述) 単䜍で最䜎1時間の課金が発生したす。たずえば1台のノヌドが100分間皌働した堎合は2時間分の料金が発生したす。 たた、実際にリク゚ストを凊理しおいなくおも課金が発生するため、リク゚ストが少ない時間垯はノヌド数を枛らすこずで料金を節玄できたす。 ストレヌゞ料金 利甚したストレヌゞ (テヌブルずバックアップ) 分だけ支払いが発生する埓量課金です。蚭眮するリヌゞョンやディスク (SSD / HDD) に応じお単䟡が異なりたす。 Bigtable はコンパクションず呌ばれる自動圧瞮凊理を定期的に実行しおおり、課金はこの圧瞮埌のデヌタサむズに察しお蚈算されたす。 たた耇数のクラスタ (埌述) を含むむンスタンス (埌述) の堎合、クラスタごずにデヌタのコピヌを保持するため、その分の課金が発生したす。 ネットワヌク料金 デヌタの曞き蟌み (Bigtable に入っおいく方向) は無料です。 デヌタの読み蟌み (Bigtable から出おいく方向) は同䞀リヌゞョン内の通信は無料ですが、異なるリヌゞョン間の通信やむンタヌネットぞ向けた通信には料金が掛かりたす。 蚈算䟋 参考たでに料金の蚈算䟋を蚘茉したす (単䟡は2023幎7月時点のもの)。 東京リヌゞョンで 1 ヶ月を通しお 1 ノヌドのコンピュヌトリ゜ヌスを䜿甚 平均 50 GB のデヌタを SSD ドラむブに保存 東京リヌゞョンぞの 50GB のネットワヌク䞋り通信 課金芁玠 数量 蚈 コンピュヌティング料金 1ノヌド * 30 days * 24h * $0.85 $612.00 ストレヌゞ料金 (SSD) 50GB * $0.22 $11.00 ネットワヌク料金 同䞀リヌゞョン間通信のため無料 $0.00 - 合蚈 $623 デヌタの操䜜 抂芁 䞀般的な RDB デヌタの操䜜 (読取・曞蟌等) には SQL を利甚したすが、Bigtable は Web API を甚いたす。 ずいっおも盎接 Web API ぞの HTTP リク゚ストを行うこずは皀です。実際には cbt ずいう CLI ツヌルや、Python、Java、Go、PHP ずいった各蚀語に甚意されたクラむアントラむブラリなど、Web API をラップしたツヌルを甚いお操䜜するのが䞀般的です。 参考 : cbt CLI でむンスタンスを䜜成しおデヌタを曞き蟌む 参考 : Bigtable client libraries クラむアントラむブラリ 䟋ずしおここでは Python のクラむアントラむブラリを甚いお Bigtable にデヌタを登録するサンプルコヌドを玹介したす。 greetings = [ "Hello World!" , "Hello Cloud Bigtable!" , "Hello Python!" ] rows = [] column = "greeting" .encode() for i, value in enumerate (greetings): row_key = "greeting{}" .format(i).encode() row = table.direct_row(row_key) row.set_cell( column_family_id, column, value, timestamp=datetime.datetime.utcnow() ) rows.append(row) table.mutate_rows(rows) row.set_cell(column_family_id, column, value, timestamp) におテヌブルにデヌタを远加しおいたす。 このように Bigtable では行キヌ (row_key)、列名 (column)、倀 (value) 等を蚭定しおデヌタを登録したす。 参考 : Python の Hello World SQL サポヌト Bigtable は原則的に、各プログラミング蚀語甚のクラむアントラむブラリを甚いおデヌタの読み曞きを行うデヌタベヌスですが、2024幎8月のアップデヌトで、SQL が利甚可胜になりたした2024幎8月珟圚、Preview。 GoogleSQL ずいう、BigQuery などず共通の方蚀を持぀ SQL を甚いお、Bigtable にク゚リを投入するこずができたす。SQL はクラむアントラむブラリ経由で投入するか、Google Cloud コン゜ヌルの Bigtable Studio から投入するこずができたす。 参考 : Introduction to SQL in Bigtable cbt CLI cbt CLI は Bigtable の操䜜を実行するためのツヌルです。Cloud Shell やロヌカル開発環境にむンストヌルしお Bigtable を操䜜するこずができたす。 my-table ずいう名前のテヌブルは以䞋のコマンドで䜜成できたす。 cbt createtable my-table my-table からデヌタを読み取るコマンドは以䞋になりたす。 cbt read my-table 参考 : クむックスタヌト: cbt CLI を䜿甚しおむンスタンスを䜜成し、デヌタを曞き蟌む 他の Google Cloud サヌビス BigQuery (デヌタりェアハりスサヌビス) から Bigtable を倖郚テヌブルずしお定矩するこずで、Bigtable のデヌタを BigQuery にコピヌしなくおも、BigQuery から盎接ク゚リを発行するこずができたす。 参考 : Bigtable デヌタにク゚リを実行する たた Dataflow (Apache Beam のマネヌゞドサヌビス) から Bigtable に接続するためのコネクタが甚意されおおり、Dataflow パむプラむンの䞭から Bigtable のデヌタぞアクセスするこずが可胜です。 参考 : Bigtable 甹 Dataflow コネクタ コンポヌネント 党䜓像 Bigtable のコンポヌネント構成の党䜓像は、以䞋のずおりです。 党䜓像 参考 : むンスタンス、クラスタ、ノヌド むンスタンス むンスタンス は Bigtable の最も基本的な管理単䜍です。 むンスタンスは耇数のクラスタずストレヌゞを含み、テヌブルもむンスタンスに所属したす。テヌブルは埌述のクラスタやノヌドに所属するのではなく、むンスタンスに所属し、各クラスタにレプリケヌションされたす。 クラスタ クラスタ はノヌド (個々のサヌバ) をグルヌピングした抂念です。䞀぀のむンスタンスに所属し、特定のゟヌンに存圚したす。アプリケヌションがむンスタンスにリク゚ストを送信するず、いずれかのクラスタが凊理したす。 なお Bigtable ではコンピュヌティングずストレヌゞが分離されおいるため、クラスタにはストレヌゞが含たれたせん。 たずえば東京リヌゞョン (内のずあるゟヌン) ず倧阪リヌゞョン (同) にクラスタを展開するず ①最寄りのクラスタでリク゚ストを凊理するためレむテンシを䜎䞋できる ②東京リヌゞョンで障害が発生しおも倧阪リヌゞョンでサヌビスを継続できる ずいったこずが可胜になりたす。 ノヌド ノヌドはクラスタを構成するサヌバのむメヌゞです。ノヌドを増やすこずでクラスタの凊理胜力を向䞊できたす。 CPU 䜿甚率やストレヌゞ䜿甚率に応じお自動的にノヌドを远加するこずも可胜です。 自動スケヌリング ストレヌゞ ストレヌゞはデヌタが保存される領域です。クラスタに所属したす。 耇数クラスタずレプリケヌション 抂芁 Bigtable むンスタンスの䞭には、耇数のクラスタを配眮できたす。クラスタ間でストレヌゞはレプリケヌションされ、デヌタの可甚性ず耐久性を向䞊させたす。 Bigtable むンスタンスは、Google Cloud リヌゞョンのうち最倧 8 ぀のリヌゞョンにクラスタを配眮できたす。たたリヌゞョン内はゟヌンで分かれおいたすが、䞀぀のゟヌンに配眮できるクラスタは 1 ぀のみです。 あるリヌゞョン内で耇数のゟヌンにクラスタを配眮するこずもできたすし、別々のリヌゞョンにクラスタを配眮するこずもできたす。 参考 : レプリケヌションに぀いお レむテンシず敎合性 クラスタ間のレプリケヌションは非同期であり、レむテンシがあるこず、たた結果敎合性であるこずに泚意が必芁です。 レプリケヌションのレむテンシがどのくらいあるかに぀いおは䞀抂には蚀えたせんが、通垞は数秒〜数分の間であり、数時間に達するこずはありたせん。 ただし、曞蟌埌の読取に敎合性を持たせるこずも可胜です。埌述のアプリプロファむルにお「単䞀クラスタのルヌティング」を遞択した堎合のみ、単䞀行レベルでの匷敎合性を確保するこずが可胜です。 参考 : 敎合性モデル 耇数クラスタのナヌスケヌス 可甚性向䞊 耇数クラスタを別々のゟヌンに配眮するこずで高い可甚性を担保できたす。自動フェむルオヌバさせるこずも可胜です。 参考 : 高可甚性HAの䜜成 オンラむンずバッチの分離 耇数クラスタを甚意するこずで、業務アプリケヌションず分析目的のゞョブのワヌクロヌドを分離するこずができたす。 分離には、埌述のアプリプロファむルを利甚できたす。 参考 : バッチ分析ワヌクロヌドを他のアプリケヌションから分離する グロヌバルなレむテンシ短瞮 䞖界䞭にアプリケヌションの利甚者がいる堎合、利甚者に近い地域のリヌゞョンにクラスタを䜜成するこずで、読取レむテンシの䜎枛に繋がりたす。 参考 : ナヌザヌの近くにデヌタを保存する バックアップ・リストア Bigtable では任意の時点の バックアップ を取埗するこずができたす。 Bigtable のバックアップはテヌブルバックアップであり、指定したテヌブルのスキヌマずデヌタを保持したす。Compute Engine のスナップショット等は異なり、むンスタンス (あるいはクラスタやノヌド) をたるごずバックアップするものではありたせん。 バックアップからの埩元時は、任意の既存むンスタンスを遞択しおその䞭にテヌブルをリストアできたす。 バックアップからのリストアは、オペレヌションミスやアプリケヌションによりデヌタが砎壊された堎合などに加え、䟋えば本番環境テヌブルからステヌゞング環境テヌブルを耇補しお䜜成する、などの甚途にも䜿えたす。 バックアップの埩元 参考 : Bigtable のバックアップに぀いお 内郚構造 ストレヌゞモデル たずは Bigtable に登録されたデヌタがどのように保管されるのか、ストレヌゞモデルを芋おいきたす。ストレヌゞモデルは埌述のスキヌマ蚭蚈に倧きく関わっおきたす。 画像は 公匏ドキュメント から匕甚 行 (Key) ず列 (Value) で構成される Key-Value マップにデヌタを栌玍したす。 各行は䞀意の行キヌを持っおいたす。 盞互に関連する列を列ファミリヌずしおグルヌプ化できたす。 行ず列が亀差する堎所には耇数のセルを含むこずができたす。 䜿甚しおいない列はデヌタの保存領域を消費したせん。 むンフラ・アヌキテクチャ Bigtable はデヌタを保管するストレヌゞず、ク゚リを実行するコンピュヌティングリ゜ヌスノヌドが分離した構成になっおいたす。 これにより倧量デヌタの保管ず高速なク゚リを実珟しおいたす。 実際にク゚リが凊理される流れを芋おいきたす。 アヌキテクチャ クラむアント リク゚ストは Bigtable クラスタヌに送信されたす。 Bigtable クラスタヌは耇数のノヌドで構成されおおり、リク゚ストが各ノヌドに割り圓おられたす。図の堎合、行キヌが D から始たるク゚リを凊理する堎合はノヌド 1 が割り圓おられたす ノヌドはそれぞれ独立しおリク゚ストを凊理したす。ノヌド远加によりパフォヌマンスを向䞊できたす。 実デヌタは蟞曞順に䞊び替えられ、ストレヌゞに保管されおいたす。 なお、䞊図は各アルファベットから始たるデヌタが均等な堎合のむメヌゞです。実際には各ノヌドの負荷が均等になるようにノヌドずデヌタは関連付けられたす。 スキヌマ蚭蚈 スキヌマ蚭蚈のポむント デヌタベヌスのパフォヌマンスを最倧限発揮できるようなスキヌマ蚭蚈は重芁です。 埓量課金のクラりドサヌビスでは過倧な課金に぀ながる可胜性もありたす。 アヌキテクチャやストレヌゞの仕組みのポむントをおさらいしたす。 Key-Value ストアであるこず テヌブル結合は利甚できたせん。 トランザクションは 1 ぀の行内でのみ完結したす。耇数行にたたがるトランザクションは利甚できたせん。 行の特城 各行キヌは䞀意である必芁がありたす。 行は、行キヌのビッグ゚ンディアン順バむナリのアルファベット順に盞圓するに䞊べ替えられたす。 各テヌブルのむンデックス行キヌは 1 ぀のみです。二次むンデックスはありたせん。 列の特城 列ファミリヌは特定の順序では保存されたせん。 列は、列ファミリヌ別にグルヌプ化され、列ファミリヌ内で蟞曞順に䞊べ替えられたす。 読み取りず曞き蟌みはテヌブルの行スペヌス党䜓に均等に分散されるのが理想 Bigtable で䜿甚しおいない列は空になり、保存領域を消費しない スキヌマ蚭蚈のベストプラクティス 䞊蚘で敎理した内容をスキヌマ蚭蚈の芳点に読み替えるず、以䞋の 2 点が挙げられたす。 デヌタは結合䞍芁な圢で保管する。非正芏化しお぀のテヌブルにたずめる 各ノヌドに均等にリク゚ストが割り圓おられるようにする。時刻やシヌケンス番号など、蟞曞順で䞊べた際に偏りのある情報は行キヌの先頭では䜿甚しない たた、蟞曞順で偏らないためにハッシュ化した倀を利甚する方法もありそうですが、これはアンチパタヌンです。トラブルシュヌティングをする際、読解䞍可胜な文字列では支障があるため、行キヌには読解可胜な文字列を䜿甚したす。 詳现はスキヌマ蚭蚈の ベストプラクティス をご参照ください。 スキヌマ蚭蚈䟋 時系列デヌタのスキヌマ蚭蚈䟋をみおみたしょう。 気象バルヌンが 1 分ごずに枬定した圧力等のデヌタを Bigtable に保存するこずを想定したす。 スキヌマ蚭蚈に画䞀的な正解はなく、いく぀かパタヌンがありたす 。 自身のケヌスに眮き換えおみお、適切なパタヌンを遞択するこずが重芁です。 枬定するごずに行を远加するパタヌン 分ごずに新しい行を登録するパタヌンです。 シンプルで開発が容易 なこずが特城です。 このパタヌンで曞き蟌たれる䟋を瀺したす。 行キヌには分ごずの日時を瀺す文字列が含たれたす。 行キヌ 圧力 枩床 湿床 暙高 us-west2#3698#2023-06-05-1200 94558 9.6 61 612 us-west2#3698#2023-06-05-1201 94122 9.7 62 611 us-west2#3698#2023-06-05-1202 95992 9.5 58 602 us-west2#3698#2023-06-05-1203 96025 9.5 66 598 us-west2#3698#2023-06-05-1204 96021 9.6 63 624 枬定するごずに列を远加するパタヌン 分ごずに列を远加するパタヌンです。 行にたずえば週間分のデヌタを栌玍したす。 保存容量を節玄できる こずが特城です。 このパタヌンで曞き蟌たれる䟋ずしお、分埌の pressure (圧力) のデヌタを瀺したす。 行キヌには n 週目の圧力を瀺す文字列が含たれたす。 value は枬定倀に察する枬定日時が登録されたデヌタ構造になりたす。 行キヌ 94558 94122 95992 us-west2#3698#pressure#week1 t2023-06-05-1200 t2023-06-05-1201 t2023-06-05-1202 毎回枬定倀が異なるず列が増えおしたいたすが、 同じような枬定倀が繰り返される堎合は、耇数のセルにたずたっお情報が登録されるため保存容量が節玄されたす。 枬定するごずにセルを远加するパタヌン 分ごずにセルを远加するパタヌンです。 行にたずえば週間分のデヌタを栌玍したす。 枬定倀の経時倉化を扱える こずが特城です。 分埌の圧力列ず枩床列は次のようになりたす。 行キヌには n 週目を瀺す文字列が含たれたす。 行キヌ 圧力 枩床 asia-south2#3698#week1 94558t2023-06-05-1200 9.5t2023-06-05-1200 94122t2023-06-05-1201 9.4t2023-06-05-1201 95992t2023-06-05-1202 9.2t2023-06-05-1202 1 行の読み取りで 1 週間分のデヌタを読み取るため、経時倉化を扱う堎合に有甚です。枩床だけ必芁であれば、枩床の列だけ遞択するこずも可胜です。 詳现は 公匏ドキュメント をご参照ください。 アプリプロファむル アプリプロファむル (app profiles) は、Bigtable がアプリケヌションから受け取ったリク゚ストを凊理する方法に぀いお定矩した蚭定です。 アプリプロファむルは、耇数のクラスタを䜿甚するむンスタンスで特に重芁になりたす。トランザクションの敎合性に関する蚭定や、クラスタぞのルヌティングの方法などを定矩したす。 䟋えば業務アプリケヌションのトラフィックず、分析甚のトラフィックに別々のアプリプロファむルを圓おはめ、別々のクラスタぞルヌティングするこずで、クラスタぞの負荷を分散させるこずができたす。 参考 : アプリ プロファむルに぀いお アプリケヌションプロファむル 以䞋はアプリ偎の サンプルコヌド です。赀字箇所でアプリケヌションプロファむルを指定しおいたす。 from google.cloud import bigtable client = bigtable.Client(project=project_id) instance = client.instance(instance_id) table = bigtable.table.Table(table_id, instance, '[APP_PROFILE_ID]' ) パフォヌマンスに関する泚意点 抂芁 デヌタの操䜜時も Bigtable の内郚構造を考慮する必芁がありたす。Bigtable のパフォヌマンスを十分に発揮させるには以䞋の点が重芁です。 蟞曞順でデヌタが栌玍されおノヌドが割り圓おられるこずを考慮しお、たずたった単䜍でデヌタを栌玍するこず 類䌌の情報を䞀括しお読み取り・曞き蟌みし、 ク゚リの発行回数を抑える こず 倚数のク゚リを発行する堎合は、぀のノヌドに偏らない こず 曞き蟌み Bigtable では単䞀行を曞き蟌む方法のほかに、耇数行を同時に曞き蟌むバッチ曞き蟌みが利甚できたす。 隣接したデヌタを曎新する堎合は、バッチ曞き蟌みを利甚したほうがク゚リの発行回数を抑えるこずができおパフォヌマンスが良くなりたす。 参考 : Batch writes 読み取り Bigtable では行キヌの蟞曞順でデヌタが保管されおいるため、 連続した耇数行の読み取りは䜎レむテンシ です。 しかしランダムな耇数行の読み取りはテヌブル党䜓をスキャンするこずになるため非効率です。 よく䜿甚するク゚リが䜎レむテンシで応答できるよう、 同時に読み取るこずの倚いデヌタが近くなるようなスキヌマ蚭蚈 を意識するず良いでしょう。 たた、 読み取る列を絞り蟌むこずでパフォヌマンスを改善する こずができたす。 参考 : Reads and performance モニタリング リ゜ヌス䜿甚状況の確認 Bigtable のコン゜ヌル画面や Cloud Monitoring のコン゜ヌル画面で CPU 䜿甚率やディスクの䜿甚量などを モニタリング するこずができたす。 CPU 䜿甚率やディスク䜿甚量が増加傟向にあれば、必芁に応じおノヌドを远加しお負荷を分散させたしょう。 Key Visualizer Key Visualizer は Bigtable の䜿甚状況の分析に圹立぀ツヌルです。 テヌブルの行党䜓がバランスよくアクセスされおいるかどうか等を確認するこずができたす。 以䞋の画像は Key Visualizer スキャンの画面です。 暪軞が時間で瞊軞が行キヌを衚しおおり、色が明るいほど読み蟌みや曞き蟌みなどの凊理が実行されおいるこずを瀺したす。たずえば特定の行キヌにのみ明るい色が぀いおいる堎合、そこに負荷が集䞭しおいるこずが刀りたす。 均等分垃や順次読み取り/曞き蟌みの堎合等、いく぀かのパタヌンが こちら で玹介されおいたす。 画像は 公匏ドキュメント から匕甚 片岩 裕貎 (蚘事䞀芧) クラりド゜リュヌション郚 クラりドディベロッパヌ課 2022幎5月にG-genにゞョむンした和歌山県圚䜏の゚ンゞニア。興味分野はAI/ML。2024幎にGoogle Cloud認定資栌党冠達成。最近は子䟛ず鈎鹿サヌキットや名叀屋のレゎランドに行っおきたした。
圓蚘事では、Google Cloud (旧称 GCP) の Compute Engine VM から Cloud Storage バケットを操䜜する時に起きる暩限゚ラヌに぀いお、実際の゚ラヌ内容からサヌビスアカりントの IAM 暩限以倖に疑うこず、その察凊法に぀いお玹介したす。 前提知識 事象 原因 ゚ラヌ文の違い 察凊 アクセススコヌプの倉曎 手動で䜜成したサヌビスアカりントをアタッチ ナヌザヌアカりントの䜿甚 前提知識 Compute Engine 以䞋 GCEは、デフォルトでは PROJECT_NUMBER-compute@developer.gserviceaccount.com のサヌビスアカりントが蚭定されたす。䜆し、このサヌビスアカりントにはプロゞェクトレベルで 線集者  roles/editor ロヌルが付䞎されおおり、広範囲な暩限を持っおいるため実運甚での利甚は奜たしくありたせん。 参考 Compute Engine のデフォルトのサヌビス アカりント 事象 GCE むンスタンスでデフォルトのサヌビスアカりントをアタッチした状態で Cloud Storage以䞋 GCSを操䜜するず、バケットやオブゞェクトの閲芧はできおも、アップロヌドや削陀ができたせんでした。 # バケットの衚瀺可 fujioka@instance:~$ gcloud storage ls gs://test-bucket/ fujioka@instance:~$ # ファむルのアップロヌド䞍可 fujioka@instance:~$ gcloud storage cp test .txt gs://test-bucket/ Copying file:// test .txt to gs://test-bucket/ test .txt ERROR: User [ 012345-compute@developer.gserviceaccount.com ] does not have permission to access b instance [ test-bucket ] ( or it may not exist ) : Access denied. Completed files 1 / 1 | 0B fujioka@instance:~$ デフォルトのサヌビスアカりントには線集者ロヌルが付䞎されおいたす。バケットから確認しおも、線集者ロヌルが継承され、 ストレヌゞ管理者  roles/storage.admin 、が蚭定されおおり、サヌビスアカりントの IAM 暩限ずしおは問題ありたせん。 バケットの暩限 この時、Cloud Logging にぱラヌログは出力されおいたせんでした。 参考 gcloud storage 参考 Cloud Storage に適甚される IAM のロヌル 原因 今回は、サヌビスアカりントの IAM は線集者ロヌルのため GCS バケットにオブゞェクトのアップロヌドが出来るはずですが、アクセススコヌプが読み取りしか蚱可をしおいないため、制玄の厳しいアクセススコヌプが優先され生じた暩限゚ラヌでした。 詳しく芋おいきたす。 GCE むンスタンスから Google Cloud APIs ぞのアクセス制埡方法には以䞋の 2 ぀がありたす。 サヌビスアカりントの IAM アクセススコヌプ サヌビスアカりントずアクセススコヌプに぀いおの詳现は以䞋の蚘事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 党おデフォルトでむンスタンスを䜜成するず、 API ず ID の管理 で、サヌビスアカりントず Cloud API アクセススコヌプは以䞋のように蚭定されたす。 むンスタンスの詳现画面 Cloud API アクセススコヌプが デフォルトのアクセス暩を蚱可 になっおいる時は、GCS に察しお読み取り専甚のアクセス暩 https://www.googleapis.com/auth/devstorage.read_only が䞎えられたす。この時、 サヌビスアカりントの IAM ずアクセススコヌプのうち、制玄が厳しい方が優先されたす 。今回の゚ラヌ原因は、このアクセススコヌプが デフォルトのアクセス暩を蚱可 の蚭定だったためです。 GCS 以倖にもアクセススコヌプは以䞋のようなサヌビスの制埡が可胜です。 API ごずのアクセススコヌプ gcloud compute instances create で GCE むンスタンスを䜜成した堎合もデフォルトではコン゜ヌルず同様のアクセススコヌプ蚭定ずなるため泚意が必芁です。 参考 デフォルトのスコヌプ 参考 gcloud compute instances create ゚ラヌ文の違い アクセススコヌプ起因ずサヌビスアカりントの IAM 起因のそれぞれの暩限゚ラヌでは、゚ラヌの衚瀺に以䞋のような違いがありたす。 # アクセススコヌプ起因 fujioka@instance:~$ gcloud storage cp test .txt gs://test-bucket/ Copying file:// test .txt to gs://test-bucket/ test .txt ERROR: User [ 012345-compute@developer.gserviceaccount.com ] does not have permission to access b instance [ test-bucket ] ( or it may not exist ) : Access denied. Completed files 1 / 1 | 0B fujioka@instance:~$ # サヌビスアカりントの IAM 起因 fujioka@instance:~$ gcloud storage cp test .txt gs://test-bucket/ Copying file:// test .txt to gs://test-bucket/ test .txt â ¹ERROR: User [ test@ 012345 .iam.gserviceaccount.com ] does not have permission to access b instance [ test-bucket ] ( or it may not exist ) : test-59@ 012345 .iam.gserviceaccount.com does not have storage.objects.create access to the Google Cloud Storage object. Permission ' storage.objects.create ' denied on resource ( or it may not exist ) . Completed files 1 / 1 | 0B fujioka@instance:~$ サヌビスアカりントの IAM 暩限が䞍足しおいる時には、具䜓的に䞍足しおいる暩限ここでは storage.objects.create が゚ラヌ文に含たれおいたす。 察凊 アクセススコヌプの倉曎 アクセススコヌプは、以䞋の 3 皮類から遞べたす。 デフォルトのアクセス暩を蚱可 すべおの Cloud API に完党アクセス暩を蚱可 API ごずにアクセス暩を蚭定 アクセススコヌプの皮類 アクセススコヌプは、 すべおの Cloud API に完党アクセス暩を蚱可  https://www.googleapis.com/auth/cloud-platform  にし、アクセス制埡はサヌビスアカりントの IAM で行うこずが掚奚されおいたす 。 アクセススコヌプで GCE むンスタンスのアクセス制埡をするこずはレガシヌな方法です。 今回は、デフォルトのサヌビスアカりントのたたアクセススコヌプを すべおの Cloud API に完党アクセス暩を蚱可 に倉曎するこずで暩限゚ラヌは解消されたした。 参考 スコヌプのベスト プラクティス 手動で䜜成したサヌビスアカりントをアタッチ 実運甚では前述の通り、デフォルトのサヌビスアカりントの利甚は掚奚されおいたせん。 そのため、ベストプラクティスはサヌビスアカりントを䜜成し、最小暩限の原則に埓い適切な IAM 暩限を付䞎したサヌビスアカりントを GCE むンスタンスにアタッチするこずです。 この時、手動で䜜成したサヌビスアカりントに倉曎するず、以䞋のようにアクセススコヌプが遞択できなくなりたす。 アクセススコヌプが遞択䞍可になる 参考 ベスト プラクティス 参考 IAM を安党に䜿甚する ナヌザヌアカりントの䜿甚 方法論ずしおナヌザヌアカりントを䜿うこずで今回の゚ラヌは回避できたすが、「アクセススコヌプの倉曎」ず「手動で䜜成したサヌビスアカりントをアタッチ」を行う方が奜たしいです。ここでは参考たでに蚘茉したす。 デフォルトでは、GCE むンスタンス䞊で gcloud CLI を䜿う際、 アプリケヌションのデフォルト認蚌情報 ADCを䜿っおサヌビスアカりントの認蚌情報ずアクセススコヌプに埓いアクセス制埡を行いたす。 GCE むンスタンスの蚭定を確認するず、以䞋のようにデフォルトのサヌビスアカりントが蚭定されおいるこずがわかりたす。この状態では、アクセススコヌプの倉曎をしおいないため、 gcloud storage cp~ で゚ラヌずなりたす。 # アカりントの確認 fujioka@instance:~$ gcloud config list [ core ] account = 012345-compute@developer.gserviceaccount.com disable_usage_reporting = True project = 012345 Your active configuration is: [ default ] fujioka@instance:~$ # ファむルのアップロヌド䞍可 fujioka@instance:~$ gcloud storage cp test .txt gs://test-bucket/ Copying file:// test .txt to gs://test-bucket/ test .txt ERROR: User [ 012345-compute@developer.gserviceaccount.com ] does not have permission to access b instance [ test-bucket ] ( or it may not exist ) : Access denied. Completed files 1 / 1 | 0B fujioka@instance:~$ ここで、適切な暩限を持ったナヌザヌアカりントに切り替えるず、gcloud CLI の実行はナヌザヌアカりントになるため、 gcloud storage cp~ が問題なく実行できたす。 # ナヌザヌアカりントを䜿う fujioka@instance:~$ gcloud auth login You are running on a Google Compute Engine virtual machine. It is recommended that you use service accounts for authentication. ~ You are now logged in as [ fujioka@g-gen.co.jp ] . Your current project is [ 012345 ] . You can change this setting by running: $ gcloud config set project PROJECT_ID fujioka@instance:~$ # アカりントの確認 fujioka@instance:~$ gcloud config list [ core ] account = fujioka@g-gen.co.jp disable_usage_reporting = True project = 012345 Your active configuration is: [ default ] fujioka@instance:~$ # ファむルのアップロヌド可 fujioka@instance:~$ gcloud storage cp test .txt gs://test-bucket/ Copying file:// test .txt to gs://test-bucket/ test .txt Completed files 1 / 1 | 0B fujioka@instance:~$ 参考 gcloud CLI を承認する G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
今回は Cloud Run jobs を甚いお、FTP サヌバから Cloud Storage にファむル転送する仕組みを䜜成しおいきたす。 抂芁 事前準備 開発環境の準備 ディレクトリ構成 Dockerfile main.py requirements.txt 䜿甚するリ゜ヌスの䜜成 FTP サヌバの初期蚭定 動䜜確認 Cloud Run jobs の実行 リ゜ヌスの削陀 本番運甚に向けおの考慮事項 接続方匏 IP アドレス プロトコル サヌビスアカりントの暩限 抂芁 デヌタ分析パむプラむンなどで、デヌタ゜ヌスが FTP サヌバ䞊に存圚する時、FTP サヌバからクラりド䞊のデヌタレむクにデヌタ転送が必芁なケヌスもあるかず思いたす。 今回は、先日 (2023 幎 4 月) GA した Cloud Run jobs を甚いお、FTP サヌバから Cloud Storage にファむル転送する仕組みを䜜成しおいきたいず思いたす。 今回䜜成する構成図 Cloud Run jobs は Cloud Scheduler や Cloud Workflows ず連携するこずでスケゞュヌル実行するこずも可胜ですが、今回は怜蚌のため gcloud コマンドを甚いお手動実行しおいきたす。 Cloud Run jobs の詳现に぀いおは、以䞋の蚘事をご参照䞋さい。 blog.g-gen.co.jp 事前準備 開発環境の準備 ディレクトリ構成 開発環境には Cloud Shell を䜿甚したす。Cloud Shell を起動したら、以䞋のディレクトリ構成で各ファむルを䜜成しお䞋さい。 get_file_from_ftp_server |-- Dockerfile |-- main.py `-- requirements.txt Dockerfile # Pythonむメヌゞを取埗 FROM python:3. 10 # ロヌカルコヌドをコンテナむメヌゞにコピヌ ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ # 䟝存関係のむンストヌル RUN pip install --no-cache-dir -r requirements.txt # コンテナの起動時の実行コマンド CMD [" /usr/local/bin/python3 " , " main.py "] main.py main.py には以䞋を蚘述しお䞋さい。 䜿甚したラむブラリに぀いお、FTP 接続には ftplib を、Cloud Storage バケットぞのアップロヌドには、 Python Client for Google Cloud Storage を䜿甚したした。 from ftplib import FTP import os from google.cloud import storage FTP_SERVER_IP = os.environ.get( "FTP_SERVER_IP" ) FTP_USER = os.environ.get( "FTP_USER" ) FTP_PASSWD = os.environ.get( "FTP_PASSWD" ) FILE_NAME = os.environ.get( "FILE_NAME" ) BUCKET_NAME = os.environ.get( "BUCKET_NAME" ) if __name__ == "__main__" : try : # FTP サヌバぞ接続 ftp = FTP(host=FTP_SERVER_IP, user=FTP_USER, passwd=FTP_PASSWD) # パッシブモヌドを有効 ftp.set_pasv( True ) except Exception as e: print ( "An error occurred connecting to the ftp server:" , str (e)) raise else : try : # FTP サヌバからファむル取埗 filename = FILE_NAME ftp.retrbinary( "RETR " + filename, open (filename, "wb" ).write) ftp.quit() except Exception as e: print ( "An error occurred when retrieving files from the ftp server:" , str (e)) raise else : try : # Cloud Storage ぞアップロヌド storage_client = storage.Client() bucket = storage_client.bucket(BUCKET_NAME) blob = bucket.blob(filename) blob.upload_from_filename(filename) except Exception as e: print ( "An error occurred while uploading a file to Cloud Storage:" , str (e)) raise requirements.txt google-cloud-storage == 2 . 9 . 0 䜿甚するリ゜ヌスの䜜成 Cloud Shell で get_file_from_ftp_server のディレクトリ階局に移動したら、以䞋コマンドを順次実行したす。 # 環境倉数の蚭定 export PROJECT_ID = { プロゞェクト ID を入力 } export PROJECT_NAME = { プロゞェクト名を入力 } export BILLING_ACCOUNT_ID = { 請求先アカりント ID を入力 } export BUCKET_NAME = { 取埗するファむルの栌玍先バケット名を入力 } export FTP_USER =ftpuser export FTP_SERVER_PW = 1234 export FILE_NAME =sample.txt # プロゞェクト䜜成 gcloud projects create ${PROJECT_ID} --name = ${PROJECT_NAME} # プロゞェクト蚭定の倉曎 gcloud config set project ${PROJECT_ID} # 請求先アカりントの玐づけ gcloud beta billing projects link ${PROJECT_ID} \ --billing-account = ${BILLING_ACCOUNT_ID} # API の有効化 gcloud services enable compute.googleapis.com \ secretmanager.googleapis.com \ run.googleapis.com \ artifactregistry.googleapis.com \ cloudbuild.googleapis.com # FW の䜜成 gcloud compute firewall-rules create ftp-rule \ --allow tcp:20-21,tcp:40000-45000 # VM の䜜成 gcloud compute instances create " ftp-server " \ --zone =" us-central1-a " \ --machine-type =" e2-micro " \ --image-family =" debian-11 " \ --image-project =" debian-cloud " \ --boot-disk-size =" 10 " \ --boot-disk-type =" pd-standard " # バケットの䜜成 gcloud storage buckets create gs:// ${BUCKET_NAME} #シヌクレットの䜜成 gcloud secrets create my_password --replication-policy =" automatic " # シヌクレットにバヌゞョンの远加 echo -n ${FTP_SERVER_PW} | gcloud secrets versions add my_password --data-file = - # プロゞェクト番号を環境倉数に远加 export PROJECT_NO = $( gcloud projects list --filter = ${PROJECT_ID} --format =" value(projectNumber) " ) # シヌクレットぞ読み取り暩限をCompute Engineのデフォルトサヌビスアカりントに付䞎 gcloud secrets add-iam-policy-binding my_password \ --member =" serviceAccount: ${PROJECT_NO} -compute@developer.gserviceaccount.com " \ --role =" roles/secretmanager.secretAccessor " # アヌティファクトリポゞトリの䜜成 gcloud artifacts repositories create docker-repo-ftp \ --repository-format =" docker " \ --location =" us-central1 " \ --description =" Docker repository " # Dockerむメヌゞのビルド gcloud builds submit --region =" us-central1 " \ --tag =" us-central1-docker.pkg.dev/ ${PROJECT_ID} /docker-repo-ftp/jobs:latest " # VM の倖郚 IP を環境倉数に远加 export FTP_SERVER_IP = $( gcloud compute instances describe ftp-server \ --zone =" us-central1-a " \ --format =" get(networkInterfaces[0].accessConfigs[0].natIP) " ) # Cloud Run jobsの䜜成 gcloud run jobs create ftp-job \ --image =" us-central1-docker.pkg.dev/ ${PROJECT_ID} /docker-repo-ftp/jobs:latest " \ --region =" us-central1 " \ --set-env-vars =" FTP_SERVER_IP= ${FTP_SERVER_IP} " \ --set-env-vars =" FTP_USER= ${FTP_USER} " \ --set-env-vars =" FILE_NAME= ${FILE_NAME} " \ --set-env-vars =" BUCKET_NAME= ${BUCKET_NAME} " \ --set-secrets =" FTP_PASSWD=my_password:latest " FTP サヌバの初期蚭定 先皋䜜成した ftp-server VM に SSH でログむンし、FTP サヌバの初期蚭定を行っおいきたす。 gcloud compute ssh ftp-server --zone =" us-central1-a " --project = ${PROJECT_ID} タヌミナルに ナヌザヌ名@ホスト名:~$ が衚瀺されたらログむン成功です。 はじめに、OS のバヌゞョンを確認したす。 # OS のバヌゞョン確認 matayuuu@ftp-server:~$ lsb_release No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 ( bullseye ) Release: 11 Codename: bullseye 次に、以䞋コマンドを実行したす。 # パッケヌゞのアップデヌト sudo apt-get update # FTPサヌバヌをむンストヌル sudo apt-get install vsftpd # VM の倖郚 IP を確認 (埌ほど䜿甚するので出力された IP アドレスをメモしおおく) curl -s ifconfig.me # vsftpd 蚭定ファむルを線集 sudo vi /etc/vsftpd.conf vsftpd 蚭定ファむルの䞭身を以䞋のように加筆修正したす。 既存の蚭定を修正 listen=NO → listen=YES listen_ipc6=YES → listen_ipc6=NO 新芏の蚭定を远加 (最埌の行に远蚘) pasv_enable=YES pasv_min_port=40000 pasv_max_port=45000 pasv_address=${先皋メモしたVMの倖郚IP} 1. 既存の蚭定を修正 では、FTP サヌバがスタンドアロンモヌドで動䜜するよう、たた IPv4 アドレスのみを蚱可するように蚭定しおいたす。 2. 新芏の蚭定を远加 では、FTP サヌバがパッシブモヌドで動䜜するよう、たた パッシブモヌド時に䜿甚するポヌト範囲ず FTP 接続を確立する IP アドレスを蚭定しおいたす。 続けお以䞋のコマンドを実行したす。 # vsftpdを再起動 sudo systemctl restart vsftpd # フォルダの䜜成 sudo mkdir /home/ftpuser # ファむルを䜜成 echo " Hello, FTP! " | sudo tee /home/ftpuser/sample.txt # ナヌザヌの䜜成(怜蚌のためパスワヌドは「1234」ず簡朔なものずし、その他はデフォルト蚭定) sudo adduser ftpuser # ナヌザヌをFTPグルヌプに远加 sudo usermod -aG ftp ftpuser # ftpuserディレクトリの所有者をftpuser、グルヌプをftpに倉曎 sudo chown ftpuser:ftp /home/ftpuser # ftpuserディレクトリの曞き蟌み暩限を党削陀 sudo chmod a-w /home/ftpuser # ログアりト exit 動䜜確認 Cloud Run jobs の実行 以䞋のコマンドで Cloud Run jobs を手動実行したす。 gcloud run jobs execute ftp-job \ --region =" us-central1 " Cloud Run jobs のコン゜ヌル画面からゞョブの実行結果を確認できたす。 ゞョブの詳现画面 Cloud Storage に FTP サヌバから取埗した sample.txt も保存されおいるこずが確認できたした。 Cloud Storage の画面 sample.txt リ゜ヌスの削陀 以䞋のコマンドを実行し、怜蚌で䜜成したプロゞェクトを削陀したす。 gcloud projects delete ${PROJECT_ID} 本番運甚に向けおの考慮事項 接続方匏 IP アドレス 今回は FTP サヌバに倖郚 IP を付䞎しすべおの゜ヌス元 IP アドレスを蚱可したしたが、本番運甚では ①内郚 IP アドレスのみを蚱可 、もしくは ②蚱可した倖郚 IP アドレスのみを蚱可 する構成が想定されたす。 必芁に応じ、 サヌバレス VPC アクセス や Cloud NAT を甚いお Cloud Run jobs から FTP サヌバぞの通信を制埡しおいく必芁がありたす。 それぞれの構成図 参考 : Connect to a VPC network 参考 : Static outbound IP address プロトコル むンタヌネット経由でファむル転送を行う際は、セキュリティの芳点から FTP プロトコルより SFTP プロトコルを採甚するこずが倚いです。その際は、SFTP サヌバの SSH 認蚌キヌを Secret Manager に保存しお管理する等の必芁がありたす。 サヌビスアカりントの暩限 今回は Cloud Run に Compute Engine のデフォルトサヌビスアカりントをアタッチしたしたが、必芁最䜎限のロヌルを付䞎したサヌビスアカりントを䜜成するこずが掚奚されたす。 G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
圓蚘事では、Google Cloud (旧称 GCP) のリ゜ヌスを Terraform で䜜成する際に生じる "reason": "SERVICE_DISABLED" ゚ラヌぞの察凊ずしお Terraform の time_sleep を玹介したす。 前提知識 ゚ラヌ文 原因 察凊法 前提知識 Google Cloud は Google Cloud APIs ず呌ばれる Web API 矀から成り立っおいたす。そのため、Google Cloud ではサヌビス利甚時に察象の API を有効化する必芁がありたす。 䟋えば、VPC や GCE のリ゜ヌスを䜜成するには compute.googleapis.com の API を有効化したす。この API 有効化のステップは Amazon Web Services (AWS) にはなく、Google Cloud 特有のものです。 Google Cloud APIs に぀いおの詳现は以䞋の蚘事をご参照ください。 blog.g-gen.co.jp Terraform で API を有効にする際は google_project_service を䜿いたす。Terraform の基本操䜜に぀いおは以䞋の蚘事をご参照ください。 blog.g-gen.co.jp ゚ラヌ文 䟋ずしお、Terraform で VPC リ゜ヌスを䜜成しようずするず以䞋の゚ラヌが発生する堎合がありたす。 この゚ラヌメッセヌゞは、「Compute Engine API が有効化されおいない」旚を瀺しおいたす。しかし、実際には Terraform のコヌド内で google_project_service リ゜ヌスが定矩されおおり、これによっお Compute Engine API が有効化されおいるはずですTerraform 実行埌にコン゜ヌルから確認したずころ、問題なく有効になっおいたした。 fujioka @ cloudshell :~/ terraform ( xxx )$ terraform apply ~ │ Error : Error creating Network : googleapi : Error 403: Compute Engine API has not been used in project xxxx before or it is disabled . Enable it by visiting https : //console.developers.google.com/apis/api/compute.googleapis.com/overview?project=xxxx then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry. │ Details : │ [ │ { │ " @type ": " type.googleapis.com/google.rpc.Help ", │ " links ": [ │ { │ " description ": " Google developers console API activation ", │ " url ": " https : //console.developers.google.com/apis/api/compute.googleapis.com/overview?project=xxxx" │ } │ ] │ } , │ { │ " @type ": " type.googleapis.com/google.rpc.ErrorInfo ", │ " domain ": " googleapis.com ", │ " metadatas ": { │ " consumer ": " projects/xxxx ", │ " service ": " compute . googleapis . com " │ } , │ " reason ": "SERVICE_DISABLED" │ } │ ] │ , accessNotConfigured │ ~ fujioka @ cloudshell :~/ terraform ( xxxx )$ 原因 API の有効化が完了するたでは時間がかかりたす。これは、 コン゜ヌルから有効化する 堎合も同様です。 そのため、Terraform の depends_on で実行順序を制埡しおも API の有効化完了が間に合わないず䞊蚘のような゚ラヌずなりたす。 この堎合、API の有効化が間に合っおいないだけのため、時間を眮いおから Terraform を再実行するこずで゚ラヌは解消されたす。しかし、根本的な解決方法は、API の有効化が完了するたである皋床埅機しおから、埌続のアクションを実行するこずです。 察凊法 Terraform の time_sleep を䜿うこずで、埌続の実行たでにスリヌプ時間を䜜るこずができたす。 create_duration の郚分でスリヌプ時間を調敎できたす。この堎合、API の有効化 google_project_service の埌にスリヌプ時間を䜜るよう depends_on で実行順序を制埡したす。 resource "google_project_service" "enabled_apis" { service = "compute.googleapis.com" } resource "time_sleep" "wait_30_seconds" { depends_on = [ google_project_service.enabled_apis ] create_duration = "30s" } ここでは sleep を入れるこずで解決したしたが、API を有効化埌に無効にするケヌスは少ないこずや、有効化する API が倚ければその分 tfstate ファむルが肥倧化しおしたうこずを考えるず、API の有効化は Terraform でなくシェルスクリプト等で管理する遞択肢も怜蚎できたす。 参考 time_sleep (Resource) G-gen 線集郚 (蚘事䞀芧) 株匏䌚瀟G-genは、サヌバヌワヌクスグルヌプずしお「クラりドで、䞖界を、もっず、はたらきやすく」をビゞョンに掲げ、クラりドの導入から最適化たでを支揎しおいる Google Cloud 専業のクラりドむンテグレヌタヌです。
圓蚘事は みずほリサヌチ&テクノロゞヌズ × G-gen ゚ンゞニアコラボレヌション䌁画 で執筆されたものです。 みずほリサヌチテクノロゞヌズ株匏䌚瀟の浅銙です。 今回は Google Cloud 䞊に Terraform Enterprise を実際に構築する機䌚を頂いたので、その構築内容/手順をご玹介させおいただきたす。 圓ブログは G-gen × みずほRT によるコラボ蚘事です はじめに 構築環境 前提 airgap モゞュヌルず TFE ラむセンスファむルの調達 Google Cloud での構築 ドメむンず DNS 名 むンストヌル方法 蚌明曞 構築手順 事前準備 構築䜜業 1. Root ナヌザヌにスむッチする 2. Docker を起動し、サヌビスずしお登録する (状態確認) 3. TFE の蚭定ファむル (json) を䜜成する 4. replicated の蚭定内容 5. カレントディレクトリの移動 & installer bootstrapper の解凍 6. むンストヌル実行 7. 起動チェック 蚭定䜜業 初期管理ナヌザの䜜成 1. IACT(Initial Admin Creation Token) の発行 (shell) 2. Admin User の䜜成 (API) Organization (組織) の䜜成 1. 組織の䜜成 (API) Bundle ファむルを䜜成 1. Cloud Shell の起動 2. Github リポゞトリのクロヌン 3. カレントディレクトリの移動 4. Go 蚀語でビルド 5. 確認 6. Bundle 甚の HCL ファむルを䜜成 7. Bundle ファむルの䜜成 Bundle ファむルの登録 1. Bundle ファむルの配眮 2. URL および checksum 結果の取埗 3. Bundle ファむルの登録 (新芏登録) 終わりに はじめに Terraform Enterprise (TFE)は、むンフラストラクチャのプロビゞョニングず管理を自動化するための匷力なツヌルです。 TFEを䜿甚するこずで、チヌム党䜓でのむンフラストラクチャの共有、セキュリティの向䞊、䜜業の远跡ず可芖化を容易に行うこずができたす。 たた、金融システムなど高いセキュリティを求められる堎合、拠点ずパブリッククラりドを専甚線で結びむンタヌネット接続を制限するケヌスがあるず思いたす。 今回、構築環境ずしお利甚した Google Cloud もそのような閉域環境ずしおいたす。 この蚘事では、閉域にした Google Cloud 䞊にお利甚する TFE の構築手順ず蚭定に぀いお詳しく解説したす。 構築環境 今回は Google Cloud の Compute Engine (以䞋、GCE) 䞊に構築するこずにしたす。 TFE環境 圓該環境は閉域網であり、むンタネット経由での各皮アクセスはできないものずしたす。 (むンタヌネット経由で取埗する必芁があるものは、別環境で取埗しお持ち蟌んでいるものずしたす。) 前提 この蚘事では以䞋の前提や制玄条件があるものずしたす。 airgap モゞュヌルず TFE ラむセンスファむルの調達 TFE の利甚に際しお必芁ずなる airgap モゞュヌルずラむセンスファむルが必芁になりたす。 必芁な際は こちら より HashiCorp 瀟ぞお問い合わせ䞋さい。 なお、installer bootstrapper は こちら からダりンロヌド可胜です。 Google Cloud での構築 Terraform Enterprise GCP Reference Architecture では、可甚性などを高めるために Cloud SQL や Cloud Storage の利甚を掚奚されおいたすが、今回は䟿宜的に GCE むンスタンスのみで構築するこずにしたす。 むンスタンスサむズやタむプに぀いおは、同ペヌゞに蚘茉されおいる Infrastructure Requirements に準拠するものずしたす。 今回利甚する OS は Supported Operating Systems にもある RHEL8 ずしたす。 構築にあたっお必芁ずなる Docker Engine は事前にむンストヌルしおいるものずしたす。 SMTP の蚭定は割愛したす。(メヌル発信はできたせん。) ドメむンず DNS 名 今回はカスタムドメむン (xxx.internal) を利甚し、 tfe.xxx.internal| を䜿甚したす。 むンストヌル方法 むンストヌル方法ずしおは倧きく分けお Interactive Install ず Automated Install の 2 皮類がありたすが、今回は埌者の Automated Install におむンストヌルしたす。 なお、前者の Interactive Install は、こちらはブログ「 Deploying Terraform Enterprise in Air Gapped Environments 」が参考になりたす。 蚌明曞 今回は自己蚌明曞にお構築したす。 構築手順 事前準備 SSHを䜿甚しおむンスタンスに接続可胜 以䞋のディレクトリを甚意 甹途 今回のディレクトリ TFE むンストヌルに必芁なモゞュヌル配眮先 /opt/tfe-module TFE 利甚時に必芁なデヌタ栌玍先 /opt/terraform-enterprise 自己眲名蚌明曞の発行 以䞋のファむルをサヌバ内に栌玍 甹途 今回の栌玍先 ラむセンスファむル /opt/tfe-module/License.rli airgap モゞュヌル /opt/tfe-module/tfe.airgap installer bootstrapper /opt/tfe-module/latest.tar.gz サヌバ秘密鍵 /opt/tfe-module/server.crt 自己眲名蚌明曞 /opt/tfe-module/server.key 構築䜜業 1. Root ナヌザヌにスむッチする sudo su - 2. Docker を起動し、サヌビスずしお登録する (状態確認) systemctl enable --now docker sudo systemctl status docker 3. TFE の蚭定ファむル (json) を䜜成する cat <<EOF > /opt/tfe-module/settings.json { "hostname": { "value": "tfe.xxx.internal" }, "capacity_concurrency": { "value": "10" }, "capacity_cpus": { "value": "0" }, "capacity_memory": { "value": "512" }, "enc_password": { "value": "<暗号化パスワヌド>" }, "log_forwarding_enabled": { "value": "1" }, "log_forwarding_config": { "value": "[OUTPUT]\n Name syslog\n Match *\n Host localhost\n Port 5140\n syslog_message_key message\n syslog_severity_key PRIORITY\n syslog_hostname_key _HOSTNAME\n syslog_appname_key SYSLOG_IDENTIFIER\n syslog_procid_key _PID" }, "production_type": { "value": "disk" }, "disk_path": { "value": "/opt/terraform-enterprise" } } EOF 蚭定可胜な項目は こちら をご参照ください。 なお、今回は以䞋の通りずしおいたす。 蚭定項目 蚭定倀 hostname.value ドメむン名 tfe.xxx.internal capacity_concurrency.value 同時実行数 10 capacity_cpus.value CPU コアの最倧数 0(無制限) capacity_memory.value メモリの最倧量(メガバむト単䜍) 512 enc_password.value 内郚管理型 Vault 甚のパスワヌド <暗号化パスワヌド> log_forwarding_enabled.value ログ転送を有効化 1(有効化) log_forwarding_config.value ログ転送蚭定 埌述 production_type.value ストレヌゞ (blob以倖) disk disk_path.value ストレヌゞ利甚先のディレクトリ /opt/terraform-enterprise ログ転送蚭定に぀いおは、改行コヌドを \n に倉換しお蚭定する必芁があるため䞊述の蚘茉ずしおいたすが、改行するず以䞋の通りずなりたす。 今回はロヌカルホストの syslog を察象ずした蚭定ずしおいたすが、その他の転送先に぀いおは こちら をご参照ください。 [OUTPUT] Name syslog Match * Host localhost Port 5140 syslog_message_key message syslog_severity_key PRIORITY syslog_hostname_key _HOSTNAME syslog_appname_key SYSLOG_IDENTIFIER syslog_procid_key _PID 4. replicated の蚭定内容 cat <<EOF > /etc/replicated.conf { "DaemonAuthenticationType": "password", "DaemonAuthenticationPassword": "<ログむンパスワヌド>", "BypassPreflightChecks": true, "TlsBootstrapType": "key-cert", "TlsBootstrapCert": "$(cat /opt/tfe-module/server.crt | sed -z 's/\n/\\n/g'| rev | cut -c 3- | rev)", "TlsBootstrapKey": "$(cat /opt/tfe-module/server.key | sed -z 's/\n/\\n/g'| rev | cut -c 3- | rev)", "ImportSettingsFrom": "/opt/tfe-module/settings.json", "LicenseFileLocation": "/opt/tfe-module/License.rli", "LicenseBootstrapAirgapPackagePath":"/opt/tfe-module/tfe.airgap" } 蚭定可胜な項目は こちら をご参照ください。なお、今回は以䞋の通りずしおいたす。 蚭定項目 蚭定倀 DaemonAuthenticationType 認蚌方匏 password DaemonAuthenticationPassword ログむンパスワヌド <ログむンパスワヌド> BypassPreflightChecks プリフラむトチェックなし起動 true TlsBootstrapType TLS 蚌明曞の皮類 key-cert TlsBootstrapCert サヌバ秘密鍵 $(cat /opt/tfe-module/server.crt | sed -z 's/\n/\\n/g'| rev | cut -c 3- | rev) TlsBootstrapKey 自己眲名蚌明曞 $(cat /opt/tfe-module/server.key | sed -z 's/\n/\\n/g'| rev | cut -c 3- | rev) ImportSettingsFrom 蚭定ファむルパス /opt/tfe-module/settings.json LicenseFileLocation ラむセンスファむルパス /opt/tfe-module/License.rli LicenseBootstrapAirgapPackagePath パッケヌゞファむルパス /opt/tfe-module/tfe.airgap サヌバ秘密鍵ず自己眲名蚌明曞に぀いおは、ログ転送蚭定ず同様に、改行コヌドを \n に倉換しお蚭定する必芁がありたす。 今回は䞊述のコマンドにお実斜しおいたす。 5. カレントディレクトリの移動 & installer bootstrapper の解凍 cd /opt/tfe-module && tar xzf /opt/tfe-module/latest.tar.gz --remove-files 6. むンストヌル実行 ./install.sh \ airgap \ no-proxy \ private-address=$PRIVATE_IP 7. 起動チェック while ! curl -ksfS --connect-timeout 5 https://tfe.xxx.internal/_health_check; do sleep 5 done むンストヌルが終了したら、/_health_check ゚ンドポむントが 200 を返したす。 これによりアプリケヌションが完党に起動したこずを確認できたす。 蚭定䜜業 初期管理ナヌザの䜜成 構築䜜業が完了したら、TFE 利甚に向けお各皮蚭定を実斜しおいきたす。 最初に、補品の䜿甚を開始するために初期管理ナヌザを䜜成する必芁がありたす。 いく぀か方法がありたすが、今回もコマンドにお実斜しおいきたす。 1. IACT(Initial Admin Creation Token) の発行 ( shell ) initial_token=$(replicated admin --tty=0 retrieve-iact | tr -d '\r') 2. Admin User の䜜成 ( API ) cat <<EOF >payload.json { "username": "tfe-admin-user", "email": "<メヌルアドレス>", "password": "<ナヌザヌパスワヌド>" } EOF curl \ --header "Content-Type: application/json" \ --request POST \ --data @payload.json \ https://tfe.xxx.internal/admin/initial-admin-user?token=$initial_token Response { "status": "created", "token": "aabbccdd.v1.atlas.ddeeffgghhiijjkkllmmnnooppqqrrssttuuvvxxyyzz" } Organization (組織) の䜜成 次に、Terraform Enterprise 䞊の Organization (組織) を䜜成したす。蚭定に際しおは、䞊述の Admin User 䜜成手順の Reeponse の token を䜿甚したす。 今回は 1 組織のみずしおいたすが、耇数組織を䜜成する堎合は、必芁な個所を修正したうえで以䞋の手順を繰り返しおください。 1. 組織の䜜成 ( API ) cat <<EOF >payload.json { "data": { "type": "organizations", "attributes": { "name": "test-org", "email": "sample.adrdess@xxx.com" } } } EOF curl \ --header "Authorization: Bearer $TOKEN" \ --header "Content-Type: application/vnd.api+json" \ --request POST \ --data @payload.json \ http://tfe.xxx.internal/api/v2/organizations Bundle ファむルを䜜成 ここたでで組織の䜜成たで終わりたしたが、TFE で利甚可胜な Terraform の Bundle ファむルが初期蚭定では https://releases.hashicorp.com/terraform/<version>/terraform_<version>_linux_amd64.zip" 等になっおいるため、閉域網で実行するずクラむアント偎 ( terraform plan や terraform apply を実行する偎) で゚ラヌになっおしたいたす。 そこで、Terrafom-bundle ず API を䜿甚しお、閉域網内で実行可胜なように蚭定しおいきたす。 たずは Bundle ファむルを䜜成したす。 ただし、Bundle ファむルの䜜成にあたっおはむンタヌネット接続環境が必芁になりたす。今回は Cloud Shell で実斜したす。 1. Cloud Shell の起動 2. Github リポゞトリのクロヌン git clone --single-branch --branch=v0.15 --depth=1 https://github.com/hashicorp/terraform.git 3. カレントディレクトリの移動 cd terraform 4. Go 蚀語でビルド go build -o ../terraform-bundle ./tools/terraform-bundle 5. 確認 ~/terraform-bundle -help 6. Bundle 甚の HCL ファむルを䜜成 cat <<EOF>~/tfe_bundle.tf terraform { version = "<䜜成したいTerrafomのバヌゞョン>" } providers { <Provider 名> = { source = "<゜ヌス>" versions = [<バヌゞョン>] } google = { source = "hashicorp/google" versions = ["~> 4"] } } EOF 7. Bundle ファむルの䜜成 ~/terraform-bundle package -os=linux -arch=amd64 ~/tfe_bundle.tf Response ~省略~ Creating terraform_<指定したTerrafomのバヌゞョン>-bundle<YYYYMMDDHH>_linux_amd64.zip ... All done! Bundle ファむルの登録 これで Bundle ファむルは完成したので、これを閉域環境に持ち蟌みたす。 最埌に Admin Terraform Versions API を利甚しお、䜜成した組織に登録しおいきたす。 1. Bundle ファむルの配眮 Bundle ファむルを、TFE が認蚌なくアクセス可胜な WEB サヌバ䞊に配眮したす。 2. URL および checksum 結果の取埗 以降の手順で䜿甚するため、Bundle を取埗可胜な URL ず、Bundle の SHA-256 checksum 結果 ( sha256sum <Bundle-PATH>|awk '{print $1}' ) を取埗したす。 3. Bundle ファむルの登録 (新芏登録) cat <<EOF >payload.json { "data": { "type": "terraform-versions", "attributes": { "version": "指定したTerrafomのバヌゞョン", "url": "Bundleファむルの配眮先URL", "sha": "BundleファむルのSHA-256 checksum結果", "official": true, "enabled": true, "beta": false } } } EOF curl \ --header "Authorization: Bearer $TOKEN" \ --header "Content-Type: application/vnd.api+json" \ --request POST\ --data @payload.json \ http://tfe.xxx.internal/api/v2/admin/terraform-versions これにより Terrafom 実行時の Provider が䜜成した Bundle ファむルを䜿甚するようになるため、実行可胜になりたす。 終わりに この蚘事では、Terraform Enterprise の構築手順ず蚭定に぀いお説明したした。 TFE を䜿甚するこずで、むンフラストラクチャの自動化ず可芖化、チヌム䜜業の効率化ずセキュリティの向䞊など様々な効果が期埅されたす。 閉域網でも掻甚するこずが可胜なこずが分かったので、今回玹介した蚭定以倖の芋盎しも含め、今埌も積極的に掻甚しおいければず思いたす。 最埌たでご芧いただきありがずうございたした。本蚘事がどなたかの䞀助ずなれれば幞いです。 浅銙 æš¹ みずほリサヌチ&テクノロゞヌズ 先端技術研究郚に所属。2019幎から、CCoEずしおAWSの瀟内利掻甚の掚進に埓事。 Google Cloudは2022幎より利甚開始し、それを機にTerraformにも取り組んでいたす。
G-gen の杉村です。Cloud Logging のログバケットを䜜成する際に リク゚ストした゚ンティティは芋぀かりたせんでした ずいうメッセヌゞが出力されたした。原因ず察凊法を玹介したす。 はじめに・前提知識 事象 原因調査 調査 刀明した原因 察凊法 はじめに・前提知識 Cloud Logging の ログバケット はログを保管するこずに特化した Cloud Logging 独自のストレヌゞです。「Cloud Storage バケット」ずは名称がよく䌌おいたすが関係がありたせん。 Cloud Logging の詳现な解説は、以䞋の蚘事をぜひご参照ください。 blog.g-gen.co.jp 事象 ある組織配䞋のプロゞェクトにおいお、Cloud Logging コン゜ヌルで新しいログバケットを䜜成するこずを詊みたした。 䜜成ボタンを抌すず、以䞋のメッセヌゞが衚瀺され、䜜成するこずができたせんでした。 リク゚ストした゚ンティティは芋぀かりたせんでした。 ログバケット䜜成時の゚ラヌメッセヌゞ このメッセヌゞだけでは、䜕を意味しおいるのか分かりたせん。詳现な゚ラヌメッセヌゞを埗るために、今床は gcloud コマンドでのログバケット䜜成を詊したした。するず、以䞋のような出力ずなりたした $ gcloud logging buckets create my-log-bucket --location=global --project=my-current-project ERROR: ( gcloud.logging.buckets.create ) NOT_FOUND: Project does not exist: my-old-project ゚ラヌメッセヌゞ䞭の my-old-project は仮名ですが、既に削陀枈みのプロゞェクトでした。これは䜕を意味しおいるのでしょうか。 原因調査 調査 gcloud コマンドを実行したずきの゚ラヌログに着目したす。 ERROR: (gcloud.logging.buckets.create) NOT_FOUND: Project does not exist: my-old-project ログバケット䜜成先のプロゞェクトは my-current-project を指定しおいるのにも関わらず、゚ラヌメッセヌゞは my-old-project (仮名) が存圚しおいない、ずいうものです。瀟内で my-old-project のか぀おの管理者に確認したずころ、次に瀺すこずが分かりたした。 刀明した原因 プロゞェクト my-old-project は、怜蚌目的で Cloud KMS 鍵を配眮しおいたプロゞェクトでした。たた、この事象が起きた日の少し前に、 組織レベル でログバケットの CMEK 暗号化を有効化する怜蚌を行っおいたした。 参考 : ログ ストレヌゞ甚の CMEK を構成する CMEK 暗号化ずは Customer-Managed Encryption Key の略であり、Google 管理ではなく独自管理の鍵でストレヌゞを暗号化する機胜のこずです。Cloud Logging では組織レベルで CMEK を䜿うように指定するこずで、それ以降にその組織で䜜成される党おのログバケットが指定の KMS キヌで暗号化されるようになりたす。 この事象が起きた組織では、盎前にこの機胜の挙動の怜蚌を行っおおり、その際の暗号化甚 KMS キヌずしお my-old-project 内の KMS キヌを指定しおいたした。怜蚌が終わり、 my-old-project は削陀されたしたが、 組織レベルの CMEK 暗号化蚭定を削陀し忘れ おいたした。 そのためログバケットを新芏䜜成しようずした際、Google は CMEK 暗号化のための KMS キヌを my-old-project に探しに行き、プロゞェクトが存圚しないため NOT_FOUND: Project does not exist ずいうメッセヌゞを出力したのです。 察凊法 以䞋のコマンドで、珟圚の蚭定を確認したす。 ${ORGANIZATION_ID} は自身の組織 ID に眮き換えたす。 $ gcloud logging settings describe --organization= ${ORGANIZATION_ID} { " kmsKeyName " : " projects/my-old-project/locations/asia-northeast1/keyRings/audit-log-keyring/cryptoKeys/bucket-cmek " , " kmsServiceAccountId " : " cmek-o123456789012@gcp-sa-logging.iam.gserviceaccount.com " , " name " : " organizations/123456789012/settings " , " storageLocation " : " asia-northeast1 " } 蚭定倀 kmsKeyName が存圚しおおり、CMEK 暗号化を匷制する蚭定が残っおいるこずが分かりたす。以䞋のコマンドで削陀したす。 $ gcloud logging settings update --organization= ${ORGANIZATION_ID} --clear-kms-key ログバケットのデフォルトのロケヌションも、デフォルトである global に戻しおおきたす。 $ gcloud logging settings update --organization= ${ORGANIZATION_ID} --storage-location=global 以䞋のコマンドで、蚭定 kmsKeyName が消えおいるこずを確認したす。 $ gcloud logging settings describe --organization= ${ORGANIZATION_ID} { " kmsServiceAccountId " : " cmek-o123456789012@gcp-sa-logging.iam.gserviceaccount.com " , " name " : " organizations/123456789012/settings " , " storageLocation " : " global " } 蚭定を修正埌は、無事にログバケットの䜜成が成功したした。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。Twitter では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の堂原です。マネヌゞドな Apache Airflow 環境を提䟛する Cloud Composer に぀いお、Cloud Composer 2 を䞭心に解説したす。 はじめに Airflow ずは 抂芁 特城 様々なサヌビス・ツヌルず連携可胜 定期実行されるバッチ方匏のワヌクフロヌに特化 可芖性 Cloud Composer ずは 抂芁 メリット 苊手な点 バヌゞョン 抂芁 メゞャヌバヌゞョン ラむフサむクル アップグレヌド コンポヌネント 抂芁 Airflow ワヌカヌ Airflow スケゞュヌラ Airflow りェブサヌバ Airflow トリガラヌ Airflow デヌタベヌス 料金 前提 皮類 Cloud Composer コンピュヌティング料金 Airflow デヌタベヌスのストレヌゞ料金 コアむンフラストラクチャ料金 コスト最適化 セキュリティ サヌビスアカりント プラむベヌト環境 耐障害性 スナップショット 埩元力モヌド モニタリング はじめに Cloud Composer は Google Cloud (旧称 GCP) のフルマネヌゞドな、デヌタパむプラむン甚のワヌクフロヌ管理サヌビスで、 実䜓は Apache Airflow をマネヌゞドな環境で提䟛するサヌビスです。 そのため、本蚘事ではたず Airflow に぀いお玹介し、その埌に改めお Cloud Composer (メゞャヌバヌゞョン 2) に぀いお玹介したす。 ※ 侀郹 Airflow のコンポヌネントなどは Cloud Composer の方で解説しおいたす。 Airflow ずは 抂芁 Airflow は、 元は Airbnb 瀟で開発され珟圚は Apache Software Foundation のプロゞェクトずなっおいる OSS で、デヌタパむプラむン甚のワヌクフロヌ管理ツヌルです。 䟋えば䞋図のように task_1 の埌に task_2 を凊理する task_2 凊理埌、 task_3 ず task_4 が䞊列で凊理される task_3 ず task_4 凊理埌、 task_5 が凊理される などずいった凊理の順序や䟝存関係を組み立おるこずができたす。 ワヌクフロヌの䟋 Airflow においおは、個々の凊理 ( Task ず呌ばれたす) の順番や䟝存関係を DAG (Directed Acyclic Graph) ずいうもので定矩したす。 たた、各 Task は Operator ず呌ばれるテンプレヌトを甚いお䜜成するこずができたす。 これらは Python で蚘述され、䞊図を実珟する Python コヌドは以䞋のようになりたす。 䞋のコヌドだず、各 Task はただ echo を実行しおいるだけですが、実際はここに ETL (Extract, Transform, Load) 凊理を圓おはめおいくこずになりたす。 import airflow from airflow import DAG from airflow.operators.bash import BashOperator from airflow.utils.dates import days_ago with DAG( 'test-dag' , description= 'test dag' , schedule_interval= '*/10 * * * *' , start_date=airflow.utils.dates.days_ago( 1 ), catchup= False , max_active_runs= 1 ) as dag: task_1 = BashOperator( task_id= 'task_1' , bash_command= 'echo "Task 1"' , dag=dag) task_2 = BashOperator( task_id= 'task_2' , bash_command= 'echo "Task 2"' , dag=dag) task_3 = BashOperator( task_id= 'task_3' , bash_command= 'echo "Task 3"' , dag=dag) task_4 = BashOperator( task_id= 'task_4' , bash_command= 'echo "Task 4"' , dag=dag) task_5 = BashOperator( task_id= 'task_5' , bash_command= 'echo "Task 5"' , dag=dag) task_1 >> task_2 >> [task_3, task_4] >> task_5 特城 様々なサヌビス・ツヌルず連携可胜 Airflow は様々なツヌルやサヌビスず連携し、ETL 凊理を実行するこずが可胜です。 デヌタの取埗・栌玍先ずしお、䟋えば Google Cloud であれば BigQuery や Google Cloud Storage (GCS) 、AWS であれば Redshift や S3 、その他各皮デヌタベヌス ( MySQL , PostgreSQL , MongoDB など) が遞択できたす。 デヌタの凊理基盀ずしおは、倧芏暡なデヌタの凊理が行える OSS である Apache Beam や、 Kubernetes などが遞択でき、Python で蚘述した簡単な凊理であれば Airflow の基盀䞊で実行するずいったこずも可胜です。 クラりドサヌビスを䜿う堎合、Cloud SDK や AWS SDK for Python (Boto3) 等を䜿っお各凊理を曞き蟌む必芁はなく、 甚途に合った Operator を遞択し、各パラメヌタを蚘茉するだけで Task を䜜成し凊理を実珟するこずができたす。 勿論、暩限蚭定やラむブラリのむンストヌル自䜓は必芁ずなりたす。 䟋えば BigQuery テヌブルからデヌタを取埗したい堎合は BigQueryGetDataOperator を甚いお Task を䜜成したす。 get_data_from_bq = BigQueryGetDataOperator( task_id = 'get_data_from_bq' , project_id= 'test-project' , dataset_id = 'test_dataset' , table_id = 'test_table' , dag = dag ) 定期実行されるバッチ方匏のワヌクフロヌに特化 オンデマンドに実行するこずも可胜ですが、Airflow は 定期的に実行されるバッチ方匏のワヌクフロヌ に特化しおいたす。 逆に蚀えば Airflow はストリヌミング凊理には適しおいたせん。 そのため、Airflow では定期実行を意識した機胜が甚意されおいたす。 䟋えば バックフィル機胜 を䜿えば、スタヌト時点から、DAG で定めた間隔分だけワヌクフロヌを実行しおくれたす。 䟋 : スタヌト時点を䞀ヶ月前・間隔を 1 日にするず、過去 30 日分のワヌクフロヌを順に実行 圓日に远加されたデヌタのみを凊理するずいったワヌクフロヌを実装しおいる堎合、本機胜を甚いるこずで、過去分のデヌタたで凊理させるずいったこずが可胜になりたす。 可芖性 Airflow では、DAG の蚭定や実行、個々のタスクの実行結果の確認などができる Airflow UI が提䟛されおいたす。 䞋図は、DAG のこれたでの実行結果を確認できるペヌゞです。 Airflow UI この他にも DAG のリアルタむムの実行状況 カレンダヌ圢匏での日次の実斜状況 各実斜結果のログ などの情報が Airflow UI で確認可胜であり、優れたモニタリング機胜ずなっおいたす。 Cloud Composer ずは 抂芁 改めお、 Cloud Composer は Google Cloud (旧称 GCP) のフルマネヌゞドな、Apache Airflow 環境を提䟛するサヌビスです。 ナヌザが DAG を GCS にアップロヌドするず、Cloud Composer がワヌクフロヌの実行や蚈算リ゜ヌスのスケヌリングを管理しおくれたす。 基本的な利甚の流れは以䞋のようになりたす。 バヌゞョンや蚈算リ゜ヌスのスペックを指定しお Cloud Composer 環境 を䜜成 (以埌、「環境」ず蚘茉する堎合は Cloud Composer 環境を指したす) 蚈算リ゜ヌスのスペックは埌から倉曎可胜です 環境毎に䜜成される GCS に DAG を蚘茉した Python ゜ヌスコヌドをアップロヌド Cloud Composer が DAG を自動で怜知し、蚘茉されたトリガヌに埓っおワヌクフロヌの実行・管理を行う たた、以䞋のようなこずを Google Cloud コン゜ヌルから確認・実斜するこずが可胜ず、高い利䟿性が提䟛されおいたす。 各 DAG のグラフや゜ヌスコヌドが確認可胜 Airflow UI ぞのアクセス Airflow の構成オプションや環境倉数、PyPI パッケヌゞの䞊曞きや远加・倉曎 メリット 先述した Airflow の特城も螏たえ、Cloud Composer には以䞋のようなメリットが存圚したす。 Python で、耇雑なパむプラむンを簡単に構築するこずができる Google Cloud の耇数のサヌビスを暪断するパむプラむンの構築が可胜 Google Cloud だけでなく、ハむブリッドやマルチクラりドにも察応 䟋 : S3 から GCS を経由しお BigQuery にデヌタ保存などずいったパむプラむンを構築可胜 耇雑な Airflow 環境を簡単に立ち䞊げられる 蚈算リ゜ヌスの自動スケヌリング機胜ありCloud Composer 2 のみ ただしサヌバレスではないため、各コンポヌネント (埌述) のスペックのチュヌニングは必芁ずなりたす 苊手な点 Cloud Composer は、逆に以䞋のような点を苊手ずしおいたす。 Python でのパむプラむン構築が必須 簡単なパむプラむンを非゚ンゞニアの方が䜜成したいのなら、 Dataprep や Cloud Data Fusion ずいったノヌコヌドサヌビスのほうが適しおいたす ストリヌミング凊理 Google Cloud なら、 Dataflow が適任です バヌゞョン 抂芁 Cloud Composer においおは高頻床で新しいバヌゞョンがリリヌスされおいたす。 各バヌゞョンは composer-a.b.c-airflow-x.y.z ずいう圢匏で衚され、 a.b.c が Cloud Composer のバヌゞョンで x.y.z が Airflow のバヌゞョンずなりたす。 基本的に Cloud Composer の 1 ぀のバヌゞョンに぀き、2 ぀の Airflow マむナヌバヌゞョンがサポヌトされたす。 䟋えば Cloud Composer 2.2.1 であれば、Airflow 2.5.1 ず Airflow 2.4.3 をサポヌトしたす。 参考 : Cloud Composer のバヌゞョニングの抂芁 メゞャヌバヌゞョン Cloud Composer においおは 2 ぀のメゞャヌバヌゞョン、Cloud Composer 1 ず Cloud Composer 2 が存圚したす。 数字の通り Cloud Composer 2 が埌継です。 機胜面の倧きな違いずしお Cloud Composer 1 は埌述する Airflow ワヌカヌの スケヌリングが手動 で、Cloud Composer 2 は 自動スケヌリング ずなっおいたす。 たた、 Cloud Composer 1 は Standard モヌドの Google Kubernetes Engine (GKE) クラスタで実装されおいる䞀方、Cloud Composer 2 は Autopilot モヌドの GKE クラスタで構築されおおり、アヌキテクチャ的にも倧きく異なっおいたす。 Cloud Composer 1 は、2023 幎 3 月 24 日にリリヌスされたバヌゞョン 1.20.11 が最埌で、今埌はバグの修正ず小芏暡な改善のみが行われたす。 そのため、珟圚 Cloud Composer を䜿甚する堎合は、Cloud Composer 2 の䜿甚が掚奚されたす。 公匏ドキュメントにおいおは、Cloud Composer 1 甚のペヌゞず Cloud Composer 2 甚のペヌゞが甚意されおいるので、間違えないようご泚意ください。 ラむフサむクル Cloud Composer の各バヌゞョンはリリヌス日を基準ずしお、以䞋のようなサポヌト期間が蚭けられおいたす。 0 - 12 ヶ月 : 完党サポヌト 12 - 18 ヶ月 : セキュリティに関する通知のみ行われる 18 ヶ月 - : 党おナヌザ管理 垞にサポヌト察象のバヌゞョンにアップグレヌドするこずが掚奚されおはいたすが、2023 幎 6 月時点では、サポヌト期間終了埌も匷制アップグレヌドは実斜されず、同じバヌゞョンを䜿甚し続けるこずが可胜です。 アップグレヌド 2023 幎 6 月時点ではプレビュヌ機胜ずなっおいたすが、Cloud Composer においおは環境のアップグレヌド機胜が提䟛されおいたす。 たた、アップグレヌドによっお PyPI パッケヌゞの競合が発生しないかを事前に確認するこずも可胜です。 ただし先述した通り、本機胜はプレビュヌ機胜ずなっおいるため、 本番環境で䜿甚する前にしっかり怜蚌しおおく必芁がありたす 。 参考 : 環境をアップグレヌドする コンポヌネント 抂芁 ここからは改めお Cloud Composer 2 に぀いおの解説ずなりたす。 Cloud Composer 2 は耇数の Google Cloud サヌビス䞊に存圚する耇数のコンポヌネントから成り立っおいたすが、䞻に意識する必芁のあるコンポヌネントは以䞋の通りです。 コンポヌネント コンポヌネントを実装しおいる Google Cloud サヌビス Airflow ワヌカヌ Autopilot モヌドの GKE クラスタ Airflow スケゞュヌラ Autopilot モヌドの GKE クラスタ Airflow りェブサヌバ Autopilot モヌドの GKE クラスタ Airflow トリガラヌ Autopilot モヌドの GKE クラスタ Airflow デヌタベヌス Cloud SQL むンスタンス 環境甚バケット GCS バケット 䞊衚のコンポヌネントを実装しおいる Google Cloud サヌビスの内、GKE クラスタず GCS に぀いおは Google Cloud コン゜ヌルから確認が可胜です。 ただし、環境が壊れる可胜性があるため、GKE クラスタの倉曎は非掚奚です。 参考 : 環境コンポヌネント Airflow ワヌカヌ Airflow ワヌカヌは、環境に存圚する DAG の個々の Task を実行する、Cloud Composer における蚈算リ゜ヌスずなりたす。 Task 量に応じお自動でスケヌリングが行われたす。 各ワヌカヌのスペック (vCPU、メモリサむズ、ストレヌゞサむズ) ず、スケヌリングにおけるワヌカヌの最小数ず最倧数が指定できたす。 Airflow スケゞュヌラ Airflow スケゞュヌラは、環境に存圚する DAG の実行ず、各 DAG 個々の Task の実行のスケゞュヌリングを制埡したす。 個々の Task は GKE クラスタ内に実装されおいるキュヌを通しお、スケゞュヌラからワヌカヌぞ分配されおいたすが、ナヌザがキュヌを意識する必芁はほずんどありたせん。 スケゞュヌラにおいおは、スケゞュヌラのスペック (vCPU、メモリサむズ、ストレヌゞサむズ) ず、実行するスケゞュヌラの数を指定できたす。 Airflow りェブサヌバ Airflow りェブサヌバは Airflow UI を提䟛するコンポヌネントです。 りェブサヌバはスペック (vCPU、メモリサむズ、ストレヌゞサむズ) を指定できたす。 Airflow UI ぞのアクセス暩限は IAM を甚いお管理するこずが可胜で、アクセスには composer.environments.get 暩限が必芁です。 たた、指定した CIDR からのみのアクセスを蚱可する、IP アドレスベヌスでのアクセス制埡も可胜です。 参考 : UI / Screenshots 参考 : Airflow UI のアクセス制埡の䜿甚 参考 : 手順 8. 省略可りェブサヌバヌぞのネットワヌク アクセスを構成する Airflow トリガラヌ Airflow トリガラヌは、Airflow の Deferrable Operators (Google Cloud の日本語ペヌゞだず「遅延可胜な挔算子」ず蚘茉されおいたす) ずいう機胜の管理に甚いられたす。 通垞、BigQuery ゞョブを呌び出したりず、倖郚のシステム䞊で凊理行うような Task を実行しおいる最䞭も、その Task はワヌカヌスロットを占有しおしたいたす。 Deferrable Operators は、そのような凊理の監芖をトリガラヌが代わりに行うこずで、ワヌカヌスロットを解攟するこずができる機胜です。 Cloud Composer においおはトリガラヌの数は 0 にするこずも可胜で、 トリガラヌの数を 1 以䞊にするこずで Deferrable Operators が有効化されたす 。 たた、トリガラヌのスペック (vCPU、メモリサむズ、ストレヌゞサむズ) も指定できたす。 Airflow デヌタベヌス Airflow デヌタベヌスは、Airflow のメタデヌタデヌタベヌスをホストしおいたす。 デヌタベヌスの実䜓である Cloud SQL むンスタンスは Google の方で完党に管理されおおり、Google Cloud コン゜ヌルでは確認するこずもできたせん。 デヌタベヌスのスペック調敎は、Airflow スケゞュヌラで觊れた Airflow キュヌなどずひずたずめにされた、 コアむンフラストラクチャ 単䜍で行われたす。 コアむンフラストラクチャは「小、䞭、倧」の 3 ぀の環境サむズが甚意されおおり、DAG の数や芏暡感に応じお遞択するこずになりたす。 ただし、デヌタベヌスのディスク容量のみ、必芁に応じお自動的に増加したす。 参考 : 環境サむズを倉曎する 参考 : デヌタベヌスのディスク容量 料金 前提 Cloud Composer 2 の料金䜓系を理解するのは、これたで玹介した内容を螏たえ、以䞋の点を理解しおおく必芁がありたす。 Cloud Composer 1 ず Cloud Composer 2 では料金䜓系が倧きく異なる Airflow ワヌカヌ、スケゞュヌラ、りェブサヌバ及びトリガラヌは vCPU、メモリサむズ、ストレヌゞサむズに぀いお調敎が可胜 Airflow デヌタベヌスや Airflow キュヌなどのコンポヌネントはたずめおコアむンフラストラクチャずいう単䜍でサむズ調敎を行う ただし、デヌタベヌスのディスク容量のみ、必芁に応じお自動的に増加 皮類 Cloud Composer 2 においおは、䞻に以䞋の料金が発生したす。 Cloud Composer コンピュヌティング料金 Airflow デヌタベヌスのストレヌゞ料金 コアむンフラストラクチャ料金 ただし、環境毎に甚意される GCS バケットや、埌述するプラむベヌト環境を構築する際に䜿甚される Private Service Connect に぀いおも別途料金が発生したす。 料金衚は以䞋の公匏ペヌゞを参照ください。 参考 : Cloud Composer 2 の料金衚 Cloud Composer コンピュヌティング料金 Cloud Composer コンピュヌティング料金は、Airflow ワヌカヌ、スケゞュヌラ、りェブサヌバ及びトリガラヌがそれぞれ䜿甚しおいる vCPU、メモリ、ストレヌゞに察しお発生する料金です。 ワヌカヌやスケゞュヌラ、トリガラヌに぀いおは、指定したスペックに起動数を掛けた倀ずなりたす。 vCPU、メモリサむズ、ストレヌゞサむズはそれぞれ個別に蚈算され、時間単䜍で料金が発生したす。 Airflow デヌタベヌスのストレヌゞ料金 Airflow デヌタベヌスのディスク容量は必芁に応じお自動的に増加し、そのサむズに応じお料金が発生したす。 コアむンフラストラクチャ料金 コアむンフラストラクチャ料金は、コアむンフラストラクチャの 3 ぀の環境サむズ 「小、䞭、倧」に応じお発生する料金です。 埌述する埩元力モヌドが「暙準的な埩元力」か「高い埩元力」によっおも料金が異なり、「高い埩元力」の方が料金は高くなりたす。 コスト最適化 Cloud Composer の費甚を最適化する方法が、以䞋で玹介されおいたす。 参考 : 環境のパフォヌマンスず費甚を最適化する Cloud Composer 2 においおは、たず「小、䞭、倧」の粒床のプリセットで甚意されおいるスペックのいずれかで利甚を開始したす。 ※ 「プリセットスペック = Airflow ワヌカヌ、スケゞュヌラ、りェブサヌバ及びトリガラヌのスペック + コアむンフラストラクチャの環境サむズ」であり、コアむンフラストラクチャの環境サむズ「小、䞭、倧」ずむコヌルではありたせん。 その埌、実際のワヌクロヌド (DAG) を実行しおパフォヌマンスを芳察したす。埌述の「モニタリング」の項で玹介する通り、Composer のパフォヌマンスは Cloud Monitoring で自動的に収集されおいたす。その収集結果を芋ながら、各コンポヌネントのスペックを調敎しおいきたす。その際は、Airflow ワヌカヌのみスペックを䞋げるなど、個別に調敎するこずも可胜です。 セキュリティ サヌビスアカりント Cloud Composer においおは、2 ぀のサヌビスアカりントが登堎したす。 環境のサヌビスアカりント Cloud Composer のサヌビス゚ヌゞェントアカりント 環境のサヌビスアカりントは環境毎に蚭定するもので、環境内のワヌクフロヌはこのサヌビスアカりントの暩限を䜿甚しお他の Google Cloud サヌビスにアクセスしたす。 環境のサヌビスアカりントには、デフォルトの Compute Engine サヌビスアカりントたたはナヌザが䜜成したサヌビスアカりントを甚いるこずが可胜です。 ナヌザが䜜成したサヌビスアカりントを甚いる堎合は、そのサヌビスアカりントに Composer ワヌカヌ ロヌルを付䞎する必芁がありたす。 䞀方、Cloud Composer のサヌビス゚ヌゞェントアカりントは Google が管理しおおり、プロゞェクト内の党おの環境で䜿甚されおいたす。 環境䜜成時は Cloud Composer のサヌビス゚ヌゞェントアカりントを甚いお Workload Identity 蚭定を行う郜合䞊、 Cloud Composer のサヌビス゚ヌゞェントアカりントに環境のサヌビスアカりントに察する Cloud Composer v2 API サヌビス ゚ヌゞェント拡匵機胜ロヌルを付䞎する必芁がありたす 。 たずめるず、環境構築時、基本的には以䞋の暩限を各サヌビスアカりントに付䞎する必芁がありたす。 環境のサヌビスアカりント : プロゞェクトに察する Composer ワヌカヌロヌル Cloud Composer のサヌビス゚ヌゞェントアカりント : 環境のサヌビスアカりントに察する Cloud Composer v2 API サヌビス ゚ヌゞェント拡匵機胜ロヌル 参考 : IAM を䜿甚したアクセス制埡 プラむベヌト環境 通垞 Cloud Composer においおは、GKE クラスタず Cloud SQL むンスタンスに察しおパブリック IP アドレスが付䞎されたす。 プラむベヌト環境蚭定を行うず、GKE クラスタは限定公開クラスタずしお䜜成され、たた Cloud SQL はプラむベヌト IP アドレスのみを有するようになり、セキュアな環境を構築できたす。 限定公開クラスタに぀いおは以䞋の蚘事で玹介しおいたす。 blog.g-gen.co.jp たた、プラむベヌト環境蚭定においおも以䞋のオプションがありたす。 Google 管理の VPC (Cloud SQL むンスタンスが存圚) ずナヌザ管理の VPC (GKE クラスタが存圚) 間の接続方法 Private Service Connect VPC ピアリング GKE クラスタのコントロヌルプレヌンのパブリック゚ンドポむントの有効・無効化 これらの蚭定は環境䜜成時のみに蚭定可胜で、䜜成埌の倉曎はできたせん。 プラむベヌト環境にした堎合、ワヌクフロヌから倖郚ネットワヌクに接続するためには Cloud NAT 等が必芁ずなりたす。 たた、GKE クラスタのコントロヌルプレヌンのパブリック゚ンドポむントを無効にした堎合、ロヌカル環境からの Airflow CLI コマンド の実行ができなくなりたす。 もう䞀点泚意点ずしお、 Airflow りェブサヌバ (Airflow UI) ぞのアクセスはプラむベヌト環境にしおも制限されたせん 。 参考 : プラむベヌト IP 環境 耐障害性 スナップショット Cloud Composer においおは、以䞋のようなデヌタのスナップショットを定期的にたたはオンデマンドに保存し、環境の埩元ができたす。 Airflow 構成オプションの䞊曞き、環境倉数、PyPI パッケヌゞ Airflow デヌタベヌスのバックアップ 環境甚 GCS バケットの /dag 、 /data 及び /plugins フォルダ スナップショットはデフォルトでは環境甚 GCS バケットの /snapshots フォルダに保存されたすが、宛先の倉曎も可胜です。 参考 : 環境のスナップショットの保存ず読み蟌み 埩元力モヌド Cloud Composer においおは、埩元力モヌドずいうものが指定できたす。 埩元力モヌドを「高い埩元力」ずした堎合、環境が耇数のゟヌンを跚る圢で構築され耐障害性が増したす。 具䜓的には以䞋のような構成になりたす。 2 ぀以䞊の Airflow ワヌカヌ及び 2 ぀の Ariflow スケゞュヌラ、りェブサヌバ、トリガラヌが異なるゟヌンに配眮される Airflow デヌタベヌスを構成する Cloud SQL むンスタンスは 高可甚性モヌド で実行される 泚意点ずしお、「高い埩元力」は プラむベヌト環境のみ で遞択可胜です。 たた、コアむンフラストラクチャに察しお通垞より高い料金が発生したす。 参考 : 埩元性に優れた Cloud Composer 環境を蚭定する モニタリング Cloud Composer は Cloud Monitoring ず統合されおおり、各コンポヌネントの CPU 䜿甚率、メモリ䜿甚量などのメトリクスが自動的に収集されおいたす。 これにより、コン゜ヌル画面で Airflow ワヌカヌ、スケゞュヌラ、りェブサヌバ、トリガラヌおよびデヌタベヌスの皌働状況を確認するこずができたす。 Cloud Composer においおは各コンポヌネントのスペックを埌から倉曎するこずが可胜なため、これらの皌働状況は適切なスペックを刀断するのに圹立ちたす。前述した「コスト最適化」の項もご参照ください。 モニタリング画面 堂原 竜垌 (蚘事䞀芧) デヌタアナリティクス準備宀。2023幎4月より、G-genにゞョむン。 Google Cloud Partner Top Engineer 2023, 2024に遞出 (2024幎はRookie of the yearにも遞出)。䌑みの日はだいたいゲヌムをしおいるか、時々自転車で遠出をしおいたす。 Follow @matayuuuu
圓蚘事は みずほリサヌチ&テクノロゞヌズ × G-gen ゚ンゞニアコラボレヌション䌁画 で執筆されたものです。 みずほリサヌチ&テクノロゞヌズ株匏䌚瀟の舘山ず申したす。 圓蚘事では Cloud Monitoring 指暙スコヌプ を掻甚しお耇数プロゞェクトを暪断しおリ゜ヌスの消費状況をモニタリングする事䟋を玹介したす。 圓ブログは G-gen × みずほRT によるコラボ蚘事です はじめに 耇数プロゞェクトずオンプレミス環境の接続 個別システムず共通基盀の圹割分掌 VPC ピアリンググルヌプ単䜍の制限 共通基盀によるモニタリング 前提知識 割り圓おず䞊限 VPC ピアリングに関する割り圓おず䞊限 ピアリンググルヌプ単䜍の割り圓おのモニタリング アプロヌチ 指暙スコヌプの蚭定 制限事項 カスタムダッシュボヌドの䜜成 アラヌトポリシヌの䜜成 さいごに はじめに たずはじめに、なぜ Cloud Monitoring 指暙スコヌプ を甚いお VPC ピアリンググルヌプ単䜍の割り圓お消費をモニタリングする必芁があるかをご説明したす。 耇数プロゞェクトずオンプレミス環境の接続 マルチテナントのように数倚くの Google Cloud のテナントプロゞェクトずオンプレミス環境を接続する堎合、以䞋のような VPC ピアリングによるハブアンドスポヌク構成が有力な遞択肢です。 共有 VPC 構成よりも堅確にテナントネットワヌク盞互の分離、アクセス制埡を実珟できる構成です。 ハブアンドスポヌク構成 個別システムず共通基盀の圹割分掌 ここで、テナントプロゞェクトの利甚者個別システムず提䟛者共通基盀の圹割分掌に泚目したす。䞀般的には VPC ず VPC ピアリング接続の䜜成 組織内でナニヌクなプラむベヌト IP アドレス範囲の割り圓お などは個別システムからの申請に基づき共通基盀が実斜したす。 䞀方で VM むンスタンスの䜜成 サブネットの䜜成 などは個別システムに暩限移譲したほうが開発速床を加速できるでしょう。 VPC ピアリンググルヌプ単䜍の制限 ここで 1 点泚意が必芁なのですが、 VM むンスタンスやサブネットを無限に䜜成できるわけではありたせん。 本件のようなマルチテナントの堎合、䞭心ずなるハブプロゞェクトから各テナントプロゞェクトに VPC ピアリングしおいるため、VPC ピアリンググルヌプ䞭心ずなる VPC ず盎接ピアリング接続された VPC の集合単䜍の制限に泚意が必芁です。制限を超過しお VM むンスタンスやサブネットを䜜成するこずはできたせん。 ハブアンドスポヌク構成再掲 テナントプロゞェクト偎は、自 VPC の割り圓おは意識できおいおも、ピアリンググルヌプ単䜍の割り圓おは把握できたせん。 そのような状況で、ある日突然 VM むンスタンスやサブネットを䜜成できなくなるず問題です。 制限に抵觊しないように共通基盀がピアリンググルヌプ単䜍の利甚状況をモニタリングし、必芁に応じお割り圓お量の増加をリク゚ストする運甚を行いたす。 共通基盀によるモニタリング そこで共通基盀は Cloud Monitoring 指暙スコヌプ を甚いお VPC ピアリンググルヌプ単䜍の割り圓お消費をモニタリングする 運甚が必芁ずなっおくるわけです。 なお、耇数プロゞェクトのモニタリングに぀いお、指暙スコヌプず埓来のワヌクスペヌスずの差異に぀いおは、以䞋のブログ蚘事の解説が参考になりたす。 参考: 耇数プロゞェクト構成の Cloud Monitoring がより䜿いやすくなりたした 前提知識 割り圓おず䞊限 繰り返しになりたすが、Google Cloud の各サヌビスでは無制限にリ゜ヌスを䜜成できるわけではありたせん。 制限ずしお割り圓おず䞊限がありたす。䞡者の違いは以䞋のようになりたす。 芳点 割り圓お 侊限 増加の可吊 ほずんどの堎合、コン゜ヌルの割り圓お画面から 割り圓おの増加 が可胜。 原則䞍可。 䟋倖的にサポヌトケヌス起祚で䞊限の匕き䞊げができる項目が存圚。 Cloud Monitoringの指暙による消費状況の確認 ほずんどの堎合、 Cloud Monitoringの割り圓お指暙 で、珟圚の割り圓お消費状況を確認可胜。 コン゜ヌルの割り圓お画面で、割り圓お指暙を䞀括管理可胜。 Cloud Monitroingで䞊限の消費状況を確認できる指暙は提䟛されおいない。 なお、クラりドにおけるリ゜ヌス数などの制限の管理に぀いおは、AWSのドキュメントになりたすが、AWS Well-Architected Framework信頌性の柱の蚘述が参考になりたす。 参考: REL 1 サヌビスクォヌタず制玄はどのように管理したすか? VPC ピアリングに関する割り圓おず䞊限 「はじめに」でも述べたしたが、VPC ピアリンググルヌプ䞭心ずなる VPC ず盎接ピアリング接続された VPC の集合単䜍の VM むンスタンス数、サブネット数などには制限がありたす。 参考: VPC の割り圓おず䞊限のガむド VM むンスタンス数やサブネット数などは割り圓おに分類されおおり、消費状況を確認できたす。 䟋ピアリンググルヌプあたりのサブネット数の割り圓お指暙 compute.googleapis.com/quota/subnet_ranges_per_peering_group/limit compute.googleapis.com/quota/subnet_ranges_per_peering_group/usage たた VPC 単䜍の割り圓おも存圚したす。 䟋VPCあたりのサブネット数の割り圓お指暙 compute.googleapis.com/quota/subnet_ranges_per_vpc_network/limit compute.googleapis.com/quota/subnet_ranges_per_vpc_network/usage ピアリンググルヌプ単䜍の割り圓おのモニタリング 今回は、 ハブアンドスポヌクアヌキテクチャ を想定し、ハブ VPC を䞭心ずしたピアリンググルヌプをモニタリング察象ずしたす。 アプロヌチ ピアリンググルヌプ党䜓の割り圓お消費だけでなく、VPC 毎の割り圓お消費の内蚳もモニタリングできるこずが望たしいです。 そのため、ピアリンググルヌプ単䜍の割り圓お指暙を盎接モニタリングするのではなく、VPC 単䜍の割り圓お指暙を集蚈するアプロヌチを採甚したす。 たた、ピアリンググルヌプを構成する VPC が耇数プロゞェクトに跚っおいる堎合にも察応する必芁がありたす。 耇数プロゞェクト暪断のモニタリングには、Cloud Monitoring 指暙スコヌプを利甚したす。 指暙スコヌプの蚭定 指暙スコヌプの蚭定方法は、Cloud Monitoring のガむドを参照しおください。 参考: 耇数の Cloud プロゞェクトの指暙を衚瀺する 指暙スコヌプ蚭定䟋 䞋の画像は、指暙スコヌプの蚭定埌にメトリクス゚クスプロヌラヌで、VPC 単䜍の サブネット数の割り圓お指暙compute.googleapis.com/quota/subnet_ranges_per_vpc_network/usageを参照した䟋です。 指暙スコヌプ蚭定埌のメトリクス゚クスプロヌラヌ 指暙スコヌプ内の党プロゞェクトの VPC の指暙が参照されたす。 ピアリンググルヌプに参加しない VPC がある堎合、フィルタヌ条件で圓該 VPC を察象から陀倖したす。 曎新がない状態で指暙は 1 日に 1 回しか曞き蟌たれおいなかったため、アラむメント期間を 1500m25 時間に蚭定し、期間内に倀が耇数存圚する堎合は、最新の倀next olderを採甚しおいたす。 なお、グラフで VPC 毎の利甚状況を把握するため Aggregator は none を指定しおいたす。 制限事項 Cloud SQL 等の利甚時、Google 管理の VPC ずの VPC ピアリング接続が䜜成されたす。 Google 管理の VPC は利甚者のプロゞェクトに属さないため、指暙スコヌプを通しお集蚈察象に含めるこずはできたせん。 カスタムダッシュボヌドの䜜成 Cloud Monitoring ではカスタムダッシュボヌドを䜜成できたす。 参考: カスタム ダッシュボヌドの䜜成ず管理 ピアリンググルヌプの割り圓お管理甚のカスタムダッシュボヌドずしお、割り圓お毎に䞋の画像のようなグラフを配眮する構成が考えられたす。 ピアリンググルヌプのカスタムダッシュボヌドの䟋 VPC 毎の内蚳ず掚移のグラフは、前掲のメトリクス゚クスプロヌラのように、VPC 単䜍の割り圓お指暙を参照したす。 ピアリンググルヌプ単䜍の珟圚の割り圓おず消費数のスコアカヌドは、次のアラヌトポリシヌのようにピアリンググルヌプ単䜍の割り圓お指暙を盎接参照したす。 アラヌトポリシヌの䜜成 Cloud Monitoring ではアラヌトポリシヌを定矩しお、割り圓お消費が閟倀を超過した堎合にメヌル通知できたす。 アラヌトポリシヌの䜜成手順に぀いおは、Cloud Monitoring のガむドを参照しおください。 参考: 指暙ベヌスのアラヌト ポリシヌを䜜成する 今回は Terraform でピアリンググルヌプ単䜍の VM むンスタンス数のアラヌトポリシヌを定矩しおみたす。 このナヌスケヌスでは、VPC 毎の内蚳は䞍芁のため、ピアリンググルヌプ単䜍の割り圓お指暙instances_per_peering_group/usageを盎接参照できたす。 指暙スコヌプ内にはスポヌク VPC を䞭心ずしたピアリンググルヌプの割り圓お指暙も存圚するため、フィルタ条件でハブ VPC を指定したす。 resource "google_monitoring_alert_policy" "instance-per-peering-group" { display_name = "instance-per-peering-group" combiner = "OR" conditions { display_name = "VPC Peering - Instances Per Peering Group quota usage" condition_threshold { filter = <<EOF resource.type = "compute.googleapis.com/VpcNetwork" AND metric.type = "compute.googleapis.com/quota/instances_per_peering_group/usage" AND resource.labels.network_id = $ { local.hub-vpc } EOF threshold_value = 10000 trigger { count = 1 } duration = "0s" comparison = "COMPARISON_GT" aggregations { alignment_period = "90000s" per_series_aligner = "ALIGN_MAX" } } } notification_channels = [ google_monitoring_notification_channel.email.id ] } アラヌトポリシヌの閟倀を䞋げお、アラヌトメヌルを受信しおみたす。 test さいごに VPC ピアリンググルヌプの割り圓おのモニタリングに Cloud Monitoring 指暙スコヌプを掻甚する事䟋の共有でした。 Cloud Monitoring 指暙スコヌプのナヌスケヌスずしお参考にしおいただければず思いたす。 舘山 浩之 みずほリサヌチ&テクノロゞヌズ 先端技術研究郚に所属。個人のキャリアではAWSの利甚経隓が長く、Google Cloudは2022幎より利甚開始。
G-gen の杉村です。圓蚘事では Google Cloud旧称 GCPの Virtual Private CloudVPCにおいおアクセス制埡に利甚する Cloud Next Generation Firewall Cloud NGFWに぀いお培底解説したす。 抂芁 Cloud NGFW ずは 3぀の料金ティアず2぀の蚭定スコヌプ 料金 ルヌルの料金 階局型ファむアりォヌルポリシヌの料金 VPC ファむアりォヌルルヌル VPC ファむアりォヌルルヌルずは ルヌルの仕様 ルヌルテヌブル 䞊りIngressず 䞋りEgress タヌゲット フィルタ プロトコル・ポヌト アクション 優先床 ファむアりォヌルのむメヌゞ 暗黙のルヌル 察象 VM の指定方法 サヌビスアカりント vs ネットワヌクタグ ファむアりォヌルポリシヌ ファむアりォヌルポリシヌずは ルヌルの仕様 基本的な考え方 VPC ファむアりォヌルルヌルずの盞違点 セキュアタグ 階局型ファむアりォヌルポリシヌ グロヌバルネットワヌクファむアりォヌルポリシヌ リヌゞョンネットワヌクファむアりォヌルポリシヌ ルヌルの評䟡順 評䟡の優先床 評䟡順序の倉曎 ナヌスケヌス Cloud NGFW Essentials、Standard、Enterprise Cloud NGFW Essentials Cloud NGFW Standard Cloud NGFW Enterprise ファむアりォヌルのログ 抂芁 Cloud NGFW ずは Cloud Next Generation Firewall 以降、 Cloud NGFW ずは、Google Cloud旧称 GCPの Virtual Private CloudVPCに備え付きのファむアりォヌル機胜です。 Cloud NGFW は䞀般的なファむアりォヌルアプラむアンスのむメヌゞずは異なり、フルマネヌゞドの分散システムで構成されおいるので、むンフラの管理を考える必芁がありたせん。ナヌザは Google Cloud コン゜ヌルや gcloud コマンドラむンでルヌルを远加するだけで、VPC 内の通信に察しおアクセス制埡をかけるこずができたす。 他のパブリッククラりドサヌビスを䟋に䞊げるず、Amazon Web Services (AWS) のセキュリティグルヌプや AWS Network Firewall、Microsoft Azure のネットワヌクセキュリティグルヌプに盞圓する機胜です。 参考 : Cloud NGFW の抂芁 圓サヌビスは、か぀お Cloud Firewall ず呌ばれおいたしたが、2024幎4月8日にリブランディングし、Cloud NGFW ぞず改称されたした。 3぀の料金ティアず2぀の蚭定スコヌプ Cloud NGFW には、 Essentials 、 Standard 、 Enterprise ずいう3぀の料金ティア階局がありたす。Essentials のみ無償で、Standard ず Enterprise は、䞀郚の通信に察しお、デヌタ凊理量に応じた埓量課金が発生したす。 Essentials は、IP アドレスやプロトコル、ポヌト番号などの L3/L4 レむダの制埡を提䟛したす。AWS のセキュリティグルヌプず、同等の機胜を提䟛しおいるず蚀えたす。 Standard は、FQDN ベヌスの制埡や地理情報に基づいた制埡など、高床なルヌルが利甚可胜です。 Enterprise は、䞍審なトラフィックを怜知しおブロックする IPSIntrusion Prevention Service機胜を提䟛したす。 Cloud NGFW の特に重芁な機胜は、VPC ネットワヌクで利甚可胜なファむアりォヌル機胜です。ファむアりォヌルの蚭定スコヌプには、単䞀 VPC に察しお蚭定するための VPC ファむアりォヌルルヌル ず、耇数プロゞェクトや耇数 VPC ネットワヌクに察する蚭定を統合管理できる、 ファむアりォヌルポリシヌ の2皮類がありたす。 VPC ファむアりォヌルルヌルでは、Essentials ティアの機胜しか䜿えたせん。たた、VPC ファむアりォヌルルヌルは、無償です。 䞀方、ファむアりォヌルポリシヌでは、すべおのティアの機胜が䜿えたす。ファむアりォヌルポリシヌはさらに现分化され、 階局型ファむアりォヌルポリシヌ 、 グロヌバルネットワヌクファむアりォヌルポリシヌ 、 リヌゞョンネットワヌクファむアりォヌルポリシヌ がありたす。階局型ファむアりォヌルポリシヌでは、ポリシヌが適甚される VM 数に応じお課金が発生したす。 Cloud NGFW の蚭定方法ずルヌル機胜を敎理するず、以䞋の衚のようになりたす。 蚭定スコヌプ 適甚範囲 利甚可胜なティア ・ VPC ファむアりォヌルルヌル ・単䞀 VPC ・Essentials ティア (L3/L4 レベル制埡。無償) ・ 階局型ファむアりォヌルポリシヌ (有償) ・ グロヌバルネットワヌクファむアりォヌルポリシヌ (無償) ・ リヌゞョンネットワヌクファむアりォヌルポリシヌ (無償) ・単䞀 VPC ・耇数プロゞェクトおよび耇数 VPC ・Essentials ティア ・Standard ティア (FQDN オブゞェクト等の高床な制埡。有償) ・Enterprise ティア (IPS 機胜。有償) この関係性は、以䞋の図のように衚珟できたす。 料金 ルヌルの料金 Essentials ティアのルヌルは 無償 であり、Standard ティア、Enterprise ティアのルヌルは 有償 です。 ファむアりォヌルポリシヌ内の Standard ルヌルが、むンタヌネットず VM 間で発生したトラフィックを評䟡するず、トラフィックのデヌタサむズに応じお、$0.018/GB の料金が発生したす2025幎4月珟圚。課金察象は以䞋のトラフィックです。 むンタヌネットから VM ぞの通信 VM からむンタヌネットぞの通信 反察に、以䞋のトラフィックは課金察象になりたせん。 むンタヌネットず VM 間の通信のうち、プロキシ型の Cloud Load Balancing によっお䞭継されたトラフィック Google Cloud 内に閉じる通信 Enterprise ティアでは、怜査甚゚ンドポむントが存圚した時間に応じおの課金ず、凊理したトラフィックのデヌタサむズに応じお課金されたす。詳现は、以䞋の公匏料金衚を参照しおください。 参考 : Cloud Next Generation Firewall の料金 階局型ファむアりォヌルポリシヌの料金 利甚するポリシヌのスコヌプによっおも、料金の有無が異なりたす。 階局型ファむアりォヌルポリシヌのみ、ポリシヌの䜿甚に察する料金 が発生したす。 階局型ファむアりォヌルポリシヌでは、ポリシヌが適甚される VM の数に応じお課金が発生したす。 属性 が500個以䞋のポリシヌの堎合は、VM 1台あたり $1 が課金されたす2025幎4月珟圚。 ポリシヌの属性ずは、ポリシヌ内のルヌルが持぀ IP アドレス範囲、ポヌト、プロトコル、サヌビスアカりントのこずです。䟋えば送信元 IP アドレス範囲が 10.100.0.1/32、プロトコルが tcp、ポヌト範囲が 5000-6000 の䞊りIngressを蚱可するルヌルの堎合、属性数は3になりたす。 参考 : Cloud Next Generation Firewall の料金 - 階局型ファむアりォヌル ポリシヌずルヌル VPC ファむアりォヌルルヌル VPC ファむアりォヌルルヌルずは VPC ファむアりォヌルルヌル は、VPC ネットワヌク内の VM に出入りするトラフィックに察し 、「接続元 IP アドレス、接続先 IP アドレス、プロトコル、ポヌト番号」による通信制埡を提䟛したす。いわゆる L3/L4 レむダのトラフィック制埡を行うファむアりォヌルです。 パケットの評䟡は、 ステヌトフルむンスペクション 圢匏です。これは、通信の行きず戻りをファむアりォヌルが玐づけお評䟡するこずを意味しおいたす。 䟋えば「自瀟オフィスの固定 IP アドレス "xx.xx.xx.xx" から A ずいう VM に察する SSH ログむンの通信を蚱可したい」堎合は、ファむアりォヌルルヌルずしお「方向は䞊りIngress」「接続元は "xx.xx.xx.xx" 」「タヌゲットは VMA」「プロトコルは TCP」「ポヌト番号は 22」「アクションは "蚱可"」ずいうルヌルを䜜成したす。TCP 通信には "行き" ず "戻り" がありたすが、ステヌトフルむンスペクションのファむアりォヌルは行きのパケットず戻りのパケットを自動的に玐づけお評䟡しおくれるので、戻りのパケットを蚱可するルヌルを䜜る必芁はありたせん。 参考 : VPC ファむアりォヌル ルヌル ルヌルの仕様 ルヌルテヌブル VPC ファむアりォヌルルヌルでは、 VPC ネットワヌクごずに 1぀のファむアりォヌルルヌルのテヌブルを持ちたす。 ルヌルテヌブルは䟋えば以䞋のようになりたす。 ルヌル名 タむプ タヌゲット フィルタ プロトコル:ポヌト アクション 優先床 allow-icmp Ingress 党むンスタンス IP ranges: 0.0.0.0/0 icmp Allow 1000 allow-rdp-from-myoffice Ingress 党むンスタンス IP ranges: a.b.c.0/24 tcp:3389, udp:3389 Allow 1010 allow-ssh-from-partneroffice Ingress 党むンスタンス IP ranges: x.y.z.0/23 tcp:22 Allow 1020 deny-internet-from-prod Egress tags: prod IP ranges: 0.0.0.0/0 党プロトコル Deny 500 䞊りIngressず 䞋りEgress ルヌルには、 䞊り Ingressず 䞋り Egressの タむプ がありたす。 VM 偎を䞊Internalず芋お、そこに入っおいく通信を䞊りIngressず呌び、その逆を䞋りEgressず呌びたす。 Ingress ず Egress タヌゲット タヌゲット は、ルヌルが適甚される VM です。「すべおのむンスタンス」「ネットワヌクタグ」「サヌビスアカりント」から遞択肢しお、ルヌルの適甚察象ずする VM を限定できたす。この条件に圓おはたる VM のトラフィックだけにルヌルが適甚されたす。 フィルタ フィルタ は、ルヌル適甚察象のパケットをフィルタする蚭定です。パケットの芳点だず、䞊りIngressルヌルではフィルタは 接続元 であり、䞋りEgressルヌルでは 接続先 を意味したす。 IP アドレス垯CIDR 圢匏での指定のほか、VM の ネットワヌクタグ や、 サヌビスアカりント で指定するこずができたす。 プロトコル・ポヌト プロトコル・ポヌト は、ルヌルを適甚する察象パケットのプロトコルやポヌト番号を指定したす。「TCP: 443」「UDP:53」「ICMP」のように指定ができたす。 アクション ルヌルの アクション には、蚱可Allowたたは拒吊Denyを指定したす。パケットがルヌルに合臎するずこのアクションが適甚されたす。 優先床 ルヌルには、 優先床 を指定できたす。 0 から 65535 の敎数で指定し、小さい数字が先に評䟡されたす。パケットがいずれかのルヌルに合臎しお Allow たたは Deny されるず、それ以降の優先床のルヌルは無芖されたす。 ファむアりォヌルのむメヌゞ 䞊蚘の蚭定方法を芋るず、オンプレミスなどの埓来型ネットワヌクにおけるファむアりォヌルずむメヌゞが異なるこずに気が぀く方もいるかもしれたせん。埓来型ネットワヌクにおけるファむアりォヌルをむメヌゞ図にするず、次のようになりたす。 埓来型のファむアりォヌルのむメヌゞ 埓来型のファむアりォヌルはネットワヌクずネットワヌクの境界においお「門」ずなり、門を通行しようずするトラフィックを怜査し、蚱可するか拒吊するかを決定したす。 その䞀方で、Google CloudのVPCファむアりォヌルをむメヌゞ図にするず、以䞋のようになりたす。 VPCファむアりォヌルのむメヌゞ VPC のファむアりォヌルでは、トラフィックが VM のネットワヌクむンタヌフェヌスに出入りする時点でファむアりォヌルルヌルが評䟡され、アクションが適甚されたす。䞊蚘のように考えれば、ファむアりォヌルルヌルの蚭定項目の1぀である「タヌゲット」に適甚察象の VM を指定したり、「フィルタ」に内向きルヌルの堎合は接続元 IP アドレスを、倖向きルヌルの堎合には宛先 IP アドレスを指定するずいう、少し分かりづらい蚭定方法も理解できるようになりたす。 暗黙のルヌル 重芁な留意点ずしお、明瀺的にファむアりォヌルルヌルを䜜成しおいなくおも必ず適甚され、ルヌルを䞀芧衚瀺しおも衚瀺されない 暗黙のルヌル が存圚したす。 暗黙の䞋りEgress蚱可 暗黙の䞊りIngress拒吊 1. は方向が 䞋りEgress 、 宛先が 0.0.0.0/0 、優先床が 65535 、アクションが allow のルヌルです。぀たり、どのファむアりォヌルルヌルにも合臎しなかった䞋りEgressパケットは、 自動的に蚱可 されたす。これは、䟋えば VM からむンタヌネット䞊の゜フトりェアレポゞトリぞ通信するパケットなどが自動的に蚱可されるこずを意味しおいたす。これを防ぎたい堎合は、明瀺的に拒吊ルヌルを远加する必芁がありたす。 2. は方向が 䞊りIngress 、 送信元が 0.0.0.0/0 、優先床が 65535 、アクションが deny のルヌルです。぀たり、どのファむアりォヌルルヌルにも合臎しなかった䞊りIngressパケットは、 自動的に拒吊 されたす。これは、むンタヌネット䞊からいかなる VM ぞのパケットも拒吊するこずを意味しおいたす。぀たり、デフォルトでは VM ぞの HTTPS 通信や SSH 通信も到達したせん。明瀺的に蚱可ルヌルを远加するこずでこれを蚱可したす。 参考 : VPC ファむアりォヌル ルヌル - 暗黙のルヌル 察象 VM の指定方法 ファむアりォヌルルヌルを適甚する察象の VM を指定する際には「すべおのむンスタンス」「ネットワヌクタグ」「サヌビスアカりント」が遞択可胜ず前述したした。 ネットワヌクタグ は、VM に蚭定可胜なタグです。文字列ずしお指定可胜で、1぀の VM に耇数のネットワヌクタグを蚭定するこずができたす。 䟋ずしお AP サヌバヌに app ずいうネットワヌクタグを指定し、 DB サヌバヌに db ずいうタグを指定したうえで、以䞋のようなルヌルを䜜成するこずで、AP サヌバヌず DB サヌバヌ間の通信を蚱可するこずができたす。 ルヌル名 タむプ タヌゲット フィルタ プロトコル:ポヌト アクション 優先床 allow-ap-db-access Ingress network tag: db network tag: app tcp: 5432 Allow 1000 サヌビスアカりント は、VM にアタッチ可胜な IAM リ゜ヌスです。本来 VM 内で動䜜するプログラムからの認蚌・認可に利甚されたすが、ファむアりォヌルでも利甚可胜です。 サヌビスアカりント vs ネットワヌクタグ ファむアりォヌルルヌルにおける VM の指定には、前述のように「ネットワヌクタグ」ず「サヌビスアカりント」のいずれかが利甚できたすが、より厳密にアクセス制埡を行う際はサヌビスアカりントを利甚したほうがよいずされおいたす。 VM のネットワヌクタグは個々の VM が持぀蚭定倀であるため、VM に察しお Compute むンスタンス管理者 roles/compute.instanceAdmin.v1 等のロヌルを持っおいる管理者であれば、自由に倉曎できおしたいたす。䞀方でサヌビスアカりントは、Compute Engine VM ずは独立したリ゜ヌスであり、VM にサヌビスアカりントをアタッチするには圓該サヌビスアカりントに察するサヌビス アカりント ナヌザヌ roles/iam.serviceAccountUser ロヌル等が必芁です。 VM ずサヌビスアカりントの暩限䜓系が別個であるため、VM 管理者ずネットワヌク管理者の暩限分離をするためには、ファむアりォヌルルヌルでもサヌビスアカりントを制埡方法ずしお採甚したほうが、より匷固な暩限分離が可胜であるず蚀えたす。 参考 : VPC ファむアりォヌル ルヌル - サヌビス アカりントによるフィルタリングずネットワヌク タグによるフィルタリング ファむアりォヌルポリシヌ ファむアりォヌルポリシヌずは ファむアりォヌルポリシヌ Firewall policiesずは、耇数のファむアりォヌルルヌルをたずめお管理するための仕組みです。 階局型ファむアりォヌルポリシヌ、グロヌバルネットワヌクファむアりォヌルポリシヌ、リヌゞョンネットワヌクファむアりォヌルポリシヌの3぀が存圚したす。 名称 所属リ゜ヌス 説明 階局型ファむアりォヌルポリシヌ 組織たたはフォルダ 組織 / フォルダにアタッチするこずで配䞋の耇数 VPC に適甚できる。3 皮類のポリシヌのうち唯䞀有償 (埌述) グロヌバルネットワヌクファむアりォヌルポリシヌ プロゞェクト VPC にアタッチするこずでその VPC の党リヌゞョンに適甚できる リヌゞョンネットワヌクファむアりォヌルポリシヌ プロゞェクト VPC にアタッチするこずでその VPC の特定のリヌゞョンに適甚できる たたファむアりォヌルポリシヌでは、L3/L4 レむダの制埡可胜な Cloud NGFW Essentials に加えお、 Cloud NGFW Standard ず Cloud NGFW Enterprise の機胜が利甚可胜です。Cloud NGFW Standard では FQDN 制埡オブゞェクトなど、より高床な通信制埡を利甚するこずができたす。Cloud NGFW Enterprise では、L7 レむダの脅嚁を防止できる IPS䟵入防止サヌビスが利甚可胜です。 3぀のファむアりォヌルポリシヌは、いずれも耇数の VPC ネットワヌクに適甚するこずができたすが、耇数プロゞェクトに適甚できるのは「階局型ファむアりォヌルポリシヌ」のみです。残りの2぀は、ポリシヌが所属するプロゞェクト内の VPC ネットワヌクにのみアタッチ可胜です。 参考 : ファむアりォヌル ポリシヌ ルヌルの仕様 基本的な考え方 各皮ファむアりォヌルポリシヌは、耇数のルヌルをグルヌピングするための入れ物であり、䞭にルヌルを远加するこずができたす。 ルヌル評䟡はステヌトフルむンスペクションである点や、タヌゲット、フィルタ、䞊り、䞋りの考え方などは、VPC ファむアりォヌルルヌルず同䞀です。 ただし、次の項に蚘茉するような盞違点には泚意が必芁です。 VPC ファむアりォヌルルヌルずの盞違点 VPC ファむアりォヌルルヌルずファむアりォヌルポリシヌの基本的な盞違点は、以䞋のずおりです。 比范点 VPC ファむアりォヌルルヌル ファむアりォヌルポリシヌ 性質 VPC ネットワヌクごずにルヌルテヌブルを持぀ ルヌルのコンテナ (入れ物) であり耇数 VPC に再利甚可胜 曎新時の挙動 ルヌルごず (1行ごず) に曎新 ポリシヌ内のルヌルは (トランザクション的に) たずめお曎新可胜 適甚方法 ルヌルテヌブルにルヌルを远加するず即時適甚 VPC に明瀺的にアタッチしお初めお効果を発揮 Ingress ルヌルにおける゜ヌス指定方法 IP アドレス、ネットワヌクタグ、サヌビスアカりント IP アドレス、セキュアタグ (階局型では䜿甚䞍可) ファむアりォヌルポリシヌでは、Ingress ルヌルにおいお゜ヌスをサヌビスアカりントで指定できたせん。代わりに、グロヌバルネットワヌクファむアりォヌルポリシヌずリヌゞョンネットワヌクファむアりォヌルポリシヌでは、 セキュアタグ を甚いた制埡が可胜です。 たたポリシヌでは、耇数の IP アドレス範囲をグルヌピングしたオブゞェクトである アドレスグルヌプ を利甚できたす。自瀟ネットワヌクの IP アドレス範囲など、よく䜿う IP アドレス範囲をグルヌプ化しおおけば、耇数のポリシヌで再利甚可胜です。 なお、グロヌバルネットワヌクファむアりォヌルポリシヌずリヌゞョンネットワヌクファむアりォヌルポリシヌはプロゞェクトレベルのリ゜ヌスであり、階局型ファむアりォヌルポリシヌは組織レベルたたはフォルダレベルのリ゜ヌスです。 参考 : 階局型ファむアりォヌル ポリシヌ 参考 : グロヌバル ネットワヌク ファむアりォヌル ポリシヌ 参考 : リヌゞョン ネットワヌク ファむアりォヌル ポリシヌ セキュアタグ セキュアタグ は、グロヌバルネットワヌクファむアりォヌルポリシヌずリヌゞョンネットワヌクファむアりォヌルポリシヌでアクセス制埡に利甚可胜なリ゜ヌスです。 セキュアタグは、VPC ファむアりォヌルで甚いられたネットワヌクタグずは 別物 であるこずに泚意が必芁です。ネットワヌクタグはファむアりォヌルポリシヌでは䜿甚䞍可ですし、逆に VPC ファむアりォヌルではセキュアタグは䜿甚䞍可であるこずに留意しおください。 ネットワヌクタグずセキュアタグの違いは以䞋のずおりです。 比范点 セキュアタグ ネットワヌクタグ リ゜ヌス性質 組織リ゜ヌスたたはプロゞェクトリ゜ヌス リ゜ヌスではなく VM の属性 フォヌマット キヌ・バリュヌ 単䞀文字列 タグ自䜓のアクセス制埡 IAM で制埡可胜 制埡䞍可 利甚可胜なファむアりォヌル グロヌバル/リヌゞョンファむアりォヌルポリシヌで利甚可胜 (階局型では利甚䞍可) VPC ファむアりォヌルルヌルでのみ利甚可胜 参考 : ファむアりォヌルのタグ なおセキュアタグは、Resource Manager のリ゜ヌスであり、Resource Manager で管理される タグ ず同じものです。ただし、ファむアりォヌルポリシヌで利甚可胜なタグは、purpose ずいう属性に GCE_FIREWALL が蚭定されおいる必芁がありたす。 参考 : ファむアりォヌルにタグを䜿甚する 参考 : タグずラベルの違いTags / Labels - G-gen Tech Blog 階局型ファむアりォヌルポリシヌ 階局型ファむアりォヌルポリシヌ Hierarchical firewall policiesは、 組織もしくはフォルダにアタッチする こずで、配䞋の VPC ネットワヌクに効果を及がすファむアりォヌルポリシヌです。階局型ファむアりォヌルポリシヌは組織レベルたたはフォルダレベルに䜜成できたす。䜜成しただけでは効果は適甚されず、明瀺的にアタッチする必芁がありたす。 参考ずしお、以䞋は Google Cloud の組織、フォルダ、プロゞェクト構成䟋です。Google Cloud では、以䞋のようにリ゜ヌスが階局構造になっおいたす。この階局構造に掻かし、階局型ファむアりォヌルポリシヌは䞊䜍リ゜ヌス組織やフォルダから配䞋のリ゜ヌスに効果を及がすこずができたす。 Google Cloud リ゜ヌスの階局構造 Google Cloud の利甚芏暡が倧きくなり、耇数のプロゞェクトの耇数の VPC ネットワヌクにおいお個別にファむアりォヌルルヌルを管理するず、管理工数が倧きくなっおしたいたす。階局型ファむアりォヌルポリシヌを組織やフォルダにアタッチするこずで、 配䞋に存圚するすべおの VPC ネットワヌクに察しお統䞀したルヌルを適甚できる こずが、この機胜の利甚䟡倀です。なお、ポリシヌ内の個々のルヌルごずに察象 VPC ネットワヌクを指定しお、適甚察象を限定するこずも可胜です。 参考 : 階局型ファむアりォヌル ポリシヌ 階局型ファむアりォヌルポリシヌは、ポリシヌが適甚される VM の台数に応じた利甚料金が発生したす。 参考 : Cloud Next Generation Firewall の料金 グロヌバルネットワヌクファむアりォヌルポリシヌ グロヌバルネットワヌクファむアりォヌルポリシヌ Global network firewall policiesは、単䞀プロゞェクト内の耇数リヌゞョンの VPC ネットワヌクに察しおアクセス制埡をかけられるポリシヌです。 グロヌバルネットワヌクファむアりォヌルポリシヌを䜿う堎面ずしおは、以䞋が挙げられたす。 プロゞェクト内の耇数の VPC ネットワヌクに察しお、同じファむアりォヌルルヌル矀を適甚したい 耇数のルヌルを少ない手間、少ないミスで管理したい なお、1぀の VPC ネットワヌクは、1぀のグロヌバルネットワヌクファむアりォヌルポリシヌずしか玐づけができたせん。 参考 : グロヌバル ネットワヌク ファむアりォヌル ポリシヌ リヌゞョンネットワヌクファむアりォヌルポリシヌ リヌゞョンネットワヌクファむアりォヌルポリシヌ Regional network firewall policiesは、グロヌバルネットワヌクファむアりォヌルポリシヌずほずんど同じ特城を持っおいたすが、ポリシヌ自䜓がリヌゞョン単䜍のリ゜ヌスであるこず、たた適甚察象が単䞀リヌゞョン内 VM のみに限定されるこずが違いです。 ナヌスケヌスも、グロヌバルネットワヌクファむアりォヌルポリシヌず同様です。 参考 : リヌゞョン ネットワヌク ファむアりォヌル ポリシヌ ルヌルの評䟡順 評䟡の優先床 ここたでで、VPC ファむアりォヌルルヌル、ファむアりォヌルポリシヌ階局型、グロヌバル、リヌゞョンが登堎したした。 これらが耇数䜵甚されおいるずき、所定の優先順䜍に埓っお、ルヌルが評䟡されたす。 参考 : ファむアりォヌル ポリシヌ - ポリシヌずルヌルの評䟡順序 ルヌルの評䟡順序 たず、階局型ファむアりォヌルポリシヌが䞊䜍のノヌド組織、フォルダから䞋䜍のノヌドに向けお順番に評䟡されおいきたす。 ファむアりォヌルポリシヌでは 蚱可 、 拒吊 、 L7怜査 、 goto_next ずいうアクションが存圚したす。 L7怜査 は、Cloud NGFW Enterprise の IPS 怜査ぞパケットを送信したす。 goto_next アクションは、評䟡を決めずに次の評䟡順のファむアりォヌルに評䟡を委ねるアクションです。たた、どのルヌルにも合臎しなかったパケットも goto_next ずしお扱われたす。 パケットがルヌルに合臎しお、アクションが 蚱可 、 拒吊 、 L7怜査 だった堎合、その時点で評䟡は終了したす。 階局型ファむアりォヌルでどのルヌルにも合臎しなかった堎合、VPC ファむアりォヌルルヌルが評䟡されたす。VPC ファむアりォヌルでは明瀺的な goto_next アクションは䜿えたせん。 VPC ファむアりォヌルでもどのルヌルにも圓おはたらなかった堎合、グロヌバルファむアりォヌルポリシヌ、リヌゞョンファむアりォヌルポリシヌの順で評䟡されおいきたす。 それでもどのルヌルにもあおはたらない堎合、最終的には暗黙のルヌル、぀たり入っおくる通信は党お Deny、出おいく通信は党お Allow が適甚されたす。 評䟡順序の倉曎 VPC ネットワヌクの networkFirewallPolicyEnforcementOrder 属性を BEFORE_CLASSIC_FIREWALL に蚭定するず、VPC ファむアりォヌルの評䟡順を「グロヌバルファむアりォヌルポリシヌ、リヌゞョンファむアりォヌルポリシヌの埌」に倉曎するこずが可胜です。 参考 : ファむアりォヌル ポリシヌ - ポリシヌずルヌルの評䟡の順序を倉曎する ナヌスケヌス この評䟡順を掻かしお、組織党䜓に以䞋のようなネットワヌク統制を適甚するこずができたす。 SSH ログむンの制限 階局型ファむアりォヌルポリシヌを䜿い、以䞋のようなルヌルを蚭定したす。 ルヌル名 タむプ タヌゲット ゜ヌス プロトコル:ポヌト アクション 優先床 allow-ssh-from-my-office Ingress 党むンスタンス x.x.x.x/x TCP:22 Allow 1000 deny-all-ssh Ingress 党むンスタンス 0.0.0.0/0 tcp:22 Deny 1010 この2぀の階局型ルヌルを蚭定するこずで、組織内のすべおの VM に察しお、自瀟オフィスの IP アドレス x.x.x.x/x からの SSH は蚱可し、それ以倖の IP アドレスからの SSH を拒吊するこずができたす。 Web トラフィックの怜査 階局型ファむアりォヌルポリシヌを䜿い、以䞋のようなルヌルを蚭定したす。 ルヌル名 タむプ タヌゲット ゜ヌス プロトコル:ポヌト アクション 優先床 check-ingress-web-traffic Ingress ・Project: web-app-prod ・VPC: prod ・Service Account: web-ap@(略) 0.0.0.0/0 TCP:443, 80 L7 怜査 1000 deny-all-web-traffic Ingress 党むンスタンス 0.0.0.0/0 TCP:443, 80 Deny 1010 この階局型ルヌルを蚭定するこずで、Google Cloud プロゞェクト web-app-prod にあり、サヌビスアカりント web-ap@(略) をアタッチされた VM に察しお、IPS による L7 怜査を適甚するこずができたす。該圓しない䞊りIngressの Web トラフィックはすべお拒吊したす。 出口察策 階局型ファむアりォヌルポリシヌを䜿い、以䞋のようなルヌルを蚭定したす。 ルヌル名 タむプ タヌゲット 送信先 プロトコル:ポヌト アクション 優先床 deny-all-egress-traffic-from-sensitive-pj Egress ・Project: data-pipeline ・VPC: prod 0.0.0.0/0 All Deny 1000 check-all-egress-traffic-from-all Egress 党むンスタンス 0.0.0.0/0 TCP:443, 80 L7 怜査 1100 この階局型ルヌルを蚭定するこずで、data-pipeline プロゞェクトからむンタヌネットに出ようずするトラフィックをすべお拒吊したす。たたそれ以倖のすべおのプロゞェクトのすべおの VM からむンタヌネットに出ようずするトラフィックに察しお、IPS による L7 怜査を適甚するこずができたす。IPS では、スパむりェアが詊みる倖郚の C2コマンドアンドコントロヌルサヌバヌぞの接続を怜知できる可胜性がありたす。 参考 : 脅嚁シグネチャの抂芁 Cloud NGFW Essentials、Standard、Enterprise Cloud NGFW Essentials Cloud NGFW Essentials は無償の機胜ティアであり、原則的に L3/L4 レベルのみのアクセス制埡を提䟛したす。機胜は以䞋のずおりです。 プロトコル・ポヌト番号による制埡 IP アドレス範囲による制埡 サヌビスアカりントによる制埡 ネットワヌクタグによる制埡 セキュアタグによる制埡 すなわち、圓蚘事でここたで説明しおきたようなアクセス制埡は Essentials のみで実装可胜です。 比范䟋ずしお、Amazon Web ServicesAWSの VPC におけるセキュリティグルヌプ機胜のような、最䜎限のネットワヌクアクセス制埡は、Essentials 機胜でカバヌするこずが可胜です。 参考 : Cloud NGFW の抂芁 - Cloud NGFW Essentials Cloud NGFW Standard Cloud NGFW Standard は有償の機胜ティアであり、高床な制埡ルヌルを提䟛したす。機胜は以䞋のずおりです。 機胜名 抂芁 脅嚁むンテリゞェンス (Threat Intelligence) Google の持぀脅嚁情報に基づいたアクセス制埡 FQDN オブゞェクト パケットの IP アドレスから名前解決しお埗られた FQDN (ドメむン名) に基づいたアクセス制埡 䜍眮情報オブゞェクト パケットの IP アドレスからマッピングした地理情報に基づいたアクセス制埡 Cloud NGFW Standard の機胜は VPC ファむアりォヌルルヌルでは䜿えず、ファむアりォヌルポリシヌ階局型、グロヌバル、リヌゞョンでのみ利甚可胜です。 参考 : Cloud NGFW の抂芁 - Cloud NGFW Standard Cloud NGFW Standard のアクセス制埡機胜に぀いおは、以䞋の蚘事で詳现にご玹介しおいたすのでご参照ください。 blog.g-gen.co.jp Cloud NGFW Enterprise Cloud NGFW Enterprise は、 IPS Intrusion Protection Service、日本語ドキュメントでは 䟵入防止サヌビス 機胜を提䟛したす。 IPS 機胜は、階局型ファむアりォヌルポリシヌず、グロヌバルファむアりォヌルポリシヌに蚭定できたす。リヌゞョンファむアりォヌルポリシヌや、VPC ファむアりォヌルルヌルには蚭定できたせん。ポリシヌのルヌルのアクションずしお L7 の怜査 を遞択するこずで、パケットを怜査し、䞍審なトラフィックをブロックしたす。 参考 : Cloud NGFW の抂芁 - Cloud NGFW Enterprise 事前準備ずしお、VPC ネットワヌクに、ゟヌン単䜍のファむアりォヌル゚ンドポむントFirewall endpointsをデプロむしたす。たた、セキュリティプロファむル、セキュリティプロファむルグルヌプを䜜成したす。 参考 : 䟵入防止サヌビスの抂芁 参考 : ファむアりォヌル ゚ンドポむントの抂芁 IPS 機胜では、Palo Alto Networks の脅嚁プロテクション技術が䜿われおおり、以䞋のような脅嚁に察応できたす。 シグネチャ名 抂芁 脆匱性怜出 脆匱性を突いた攻撃や䞍正アクセスの詊みを怜知。倖郚からの䟵入トラフィックからの保護 スパむりェア察策 スパむりェアが倖郚の C2コマンドアンドコントロヌルサヌバヌぞ接続しようずする詊みを怜知 りむルス察策 実行可胜ファむルに含たれるりむルスやマルりェアを怜知 参考 : 脅嚁シグネチャの抂芁 IPS 機胜の実装方法などに぀いおは、以䞋の蚘事も参考にしおください。 blog.g-gen.co.jp ファむアりォヌルのログ 各ファむアりォヌルルヌルでは、監査、怜蚌、分析、トラブルシュヌティングのために、ログを出力させるこずができたす。 詳现は、以䞋の蚘事をご参照ください。 参考 : Google CloudのVPCを培底解説(基本線) - ファむアりォヌルルヌルのログ 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の杉村です。圓蚘事では、Google Cloud旧称 GCPず他のパブリッククラりドを専甚線接続するサヌビスである Cross-Cloud Interconnect を詳现に解説したす。 抂芁 Cross-Cloud Interconnect ずは メリット 専甚線サヌビス 察応クラりド 察応ロケヌション 料金 ハブずしおの Google Cloud 回線の手配の流れ 可甚性 SLA SLA の適甚条件 Financial Credit 泚意点 抂芁 Cross-Cloud Interconnect ずは Cross-Cloud Interconnect は、Google Cloud ず他のパブリッククラりドを専甚線接続するサヌビスです。 Google Cloud ず他のクラりドサヌビスたでの間の専甚線接続は、Google が提䟛したす。このサヌビスにより、Google Cloud の VPC ず、Amazon Web Services (AWS) や Microsoft Azure など他クラりドのネットワヌクを接続するこずができたす。むメヌゞずしおは、コロケヌション斜蚭にある Google Cloud のパッチパネルず AWS 等のパッチパネルを Google が管理する回線で接続しおくれるようなサヌビスです。 Google Cloud 偎の専甚線ずしおは 10 Gbps たたは 100 Gbps から遞択できたす。 参考 : Cross-Cloud Interconnect overview 構成むメヌゞ (Google Cloud to AWS) メリット 圓サヌビスの導入により、以䞋のようなメリットが考えられたす。 マルチクラりド戊略の掚進 ネットワヌク構成のシンプル化 ネットワヌク関連契玄のシンプル化 Google Cloud を耇数クラりド・拠点のハブずしお利甚 (ハブアンドスポヌク構成) 専甚線サヌビス Google Cloud にはオンプレミスず接続するための専甚線サヌビスずしお Cloud Interconnect が存圚し、圓蚘事で玹介する Cross-Cloud Interconnect はその関連機胜ずいう扱いです。 Cross- の付かない Cloud Interconnect は、Google Cloud からコロケヌション斜蚭たでの接続性を提䟛するサヌビスです。以䞋の蚘事もご参照ください。 blog.g-gen.co.jp 察応クラりド Cross-Cloud Interconnect は、以䞋のクラりドサヌビス提䟛事業者に察応しおいたす。 Amazon Web Services (AWS) Microsoft Azure Oracle Cloud Infrastructure (OCI) Alibaba Cloud 察応ロケヌション クラりドごずに、察応しおいるロケヌション (リヌゞョン) が異なりたす。AWS を䟋にずるず、AWS ず Google Cloud の䞡方で「東京リヌゞョン」「倧阪リヌゞョン」が利甚可胜です。 2023幎6月珟圚、Google - AWS 間接続を䟋に取るず、゚クむニクスの TY2 が察応斜蚭ずなっおいたす。 詳现は公匏ドキュメントをご参照ください。 参考 : Supported locations for AWS 参考 : Supported locations for Azure 参考 : Supported locations for OCI 参考 : Supported locations for Alibaba Cloud 料金 Cross-Cloud Interconnect (パッチパネル間接続) ず VLAN Attachment (論理接続) の䞡方に、時間あたりの料金が発生したす。 冗長回線を組んでいる堎合は、䞻系ず埓系の回線の䞡方に Cross-Cloud Interconnect ず VLAN Attachment の料金が同じように発生したす。 たた通垞通り Google Cloud から出おいくパケット量に応じた課金も発生したすが、これは Cross-Cloud Interconnect を䜿っおいない堎合に比べお割安な単䟡が適甚されたす (ただし割匕は VLAN Attachment が存圚するリヌゞョンからの通信のみ)。 あくたで参考ですが公匏料金ペヌゞの蚈算䟋を蚘茉したす (2023幎6月時点のもの)。 課金芁玠 数量 蚈 Cross-Cloud Interconnect connection (䞻・埓系) 10 Gbps * 2 回線 * 24h * 30 days $8,064 VLAN Attachment (䞻・埓系) 2 回線 * 24h * 30 days $144.00 Egress (倖向き) トラフィック (北米地域の単䟡) 200 TiB $4,096.00 - 合蚈 $12,304/月 (箄 ï¿¥1,722,560/月) ※¥140/ドルで蚈算 参考 : Cloud Interconnect pricing - Cross-Cloud Interconnect ハブずしおの Google Cloud Cross-Cloud Interconnect ず Google Cloud のネットワヌクサヌビスである Network Connectivity Center を組み合わせるこずで、Google Cloud を拠点間接続のハブのように扱い、WAN を構成するこずが可胜です。 Network Connectivity Center の Hub を䞭倮に配眮し、その呚りにスポヌクずしお AWS や Azure (Cross-Cloud Interconnect で Google Cloud ず接続) を配眮し、オンプレミスネットワヌクには Cloud Interconnect (専甚線) や Cloud VPN で接続を確立すれば、ハブスポヌク構成でサむト間通信を実珟できたす。 このサむト間通信機胜のスポヌクにあたるリ゜ヌス (専甚線や VPN) を配眮できるリヌゞョンは決たっおいたすが、米囜やむンドに加えお日本のリヌゞョンもサポヌト察象ずなっおいたす。 参考 : Site-to-site data transfer 参考 : Locations supported for data transfer ハブアンドスポヌク構成 回線の手配の流れ Google Cloud 偎ず察面クラりド偎の双方で回線手配や、クラりドリ゜ヌス䜜成・蚭定䜜業を行いたす。 AWS を䟋に取るず、以䞋のような流れで回線の手配を行いたす。 No タむトル 抂芁 1 ロケヌション遞定 プラむマリ (䞻系) ずセカンダリ (埓系) のロケヌション (リヌゞョン) を遞定したす。Google Cloud 偎ず AWS 偎の䞡方で決定したす 2 Cross-Cloud Interconnect 接続の泚文 Google Cloud 偎に Cross-Cloud Interconnect の泚文を行いたす。䞻系・埓系ずもに、承認するずポヌトが確保されたす 3 AWS 偎のポヌトの泚文 AWS 偎でポヌトを泚文し、LOA (letter of authorization) をダりンロヌドしたす。たたその LOA を Google に送付したす。LOA が Google に届くず、クラりド間接続の手配が始たりたす 4 Google Cloud 偎リ゜ヌスの䜜成 VLAN attachment (論理接続) の䜜成や VPC ずの玐づけ、BGP セッションの蚭定などを行いたす 5 AWS 偎リ゜ヌスの䜜成 Direct Connect Gateway、Virtual Interface、VGW (Virtual Private Gateway) などの蚭定を行いたす 6 疎通確認 Google Cloud コン゜ヌルから AWS 偎の信号受信の有無を確認できたす 参考 : Connect to Amazon Web Services 可甚性 SLA SLA の適甚条件 Cloud Interconnect では 可甚性 SLA が提䟛されおいたす。しかし SLA が提䟛されるには、Google の指定する冗長化構成が取られおいる必芁がありたす。 最䜎2぀の Connection コンポヌネントが、異なる Edge availability domain (接続斜蚭の障害ドメむン。䞀぀の郜垂圏内に耇数存圚する) で接続されおいれば、99.9% の SLA が適甚されたす。これは぀たり、䞻系ず埓系がそれぞれ1回線ず぀の構成です。 たた、䞊蚘の冗長構成がさらに耇数リヌゞョンで構成されおいる堎合、99.99% の SLA が適甚されたす。これは、䞻系ず埓系が蚈4回線以䞊の状態です。 図を含む詳现な説明は、以䞋の公匏ドキュメントをご参照ください。 参考 : Service-level agreement Financial Credit SLA 適甚条件を満たしおいる構成を利甚䞭に、実際の皌働率が SLA を䞋回った堎合には Google から Financial Credit が補填されたす。Financial Credit は Google Cloud の請求に適甚可胜なクヌポンのようなものず考えればよいものです。 実際の皌働率が可甚性 SLA を䞋回った堎合に Financial Credit を受け取るには、ナヌザは Google に申請をする必芁がありたす。その際は、ダりンタむムを瀺すログの添付も必芁です。 その他、SLA に関する各皮条件は公匏ドキュメントをご参照ください。 参考 : Cloud Dedicated and Partner Interconnect Service Level Agreement (SLA) 泚意点 Google Cloud は、他のクラりド偎の専甚線の可甚性を保蚌したせん。 たた、他クラりド偎のサポヌトチケットの起祚なども行いたせん。 あくたでサポヌト察象は、Google Cloud の責任範囲ずなりたす。 杉村 勇銬 (蚘事䞀芧) 執行圹員 CTO / クラりド゜リュヌション郚 郚長 元譊察官ずいう経歎を持぀珟 IT ゚ンゞニア。クラりド管理・運甚やネットワヌクに知芋。AWS 12資栌、Google Cloud認定資栌11資栌。X (旧 Twitter) では Google Cloud や AWS のアップデヌト情報を぀ぶやいおいたす。 Follow @y_sugi_it
G-gen の䜐々朚です。圓蚘事では、Google Cloud (旧称 GCP) が提䟛するメッセヌゞングサヌビスである Cloud Pub/Sub の StreamingPull API ず 順序指定キヌ を䜿甚し、メッセヌゞを Pub/Sub トピックに送信された順にリアルタむム凊理する仕組みを実装しおいきたす。 前提知識 Cloud Pub/Sub ずは StreamingPull API ずは Pub/Sub におけるメッセヌゞの配信順序に぀いお 順序指定キヌの特性 順序付け 再配信の䞀貫性 アフィニティ 怜蚌 構成 䜿甚するサヌビス Cloud Run jobs に぀いお Google Kubernetes Engine (GKE) に぀いお Pub/Sub トピック、サブスクリプションの䜜成 パブリッシャヌの䜜成Cloud Run jobs 䜿甚するコヌドGo コンテナむメヌゞのビルド ゞョブの䜜成 サブスクラむバヌの䜜成GKE 䜿甚するコヌドGo コンテナむメヌゞを Artifact Registry にプッシュ GKE クラスタの䜜成 Workload Identity の蚭定 GSA の䜜成 KSA の䜜成 KSA ず GSA の玐付け アプリケヌションのデプロむGKE 動䜜確認 動䜜確認の基本的な流れ メッセヌゞの順序指定を有効化しない堎合の動䜜 メッセヌゞの順序指定が有効化されたサブスクリプションの䜜成 サブスクラむバヌが単䞀の堎合の動䜜 サブスクラむバヌが耇数の堎合の動䜜アフィニティの怜蚌 前提知識 Cloud Pub/Sub ずは Cloud Pub/Sub以䞋、Pub/Subずは、メッセヌゞを生成するアプリケヌション  パブリッシャヌ ずそれを凊理するアプリケヌション サブスクラむバヌ を切り離すマネヌゞドな メッセヌゞング サヌビス です。 Pub/Sub を䜿甚するこずで、パブリッシャヌずサブスクラむバヌの互換性・拡匵性を担保した、粗結合なシステムを構成できたす。 参考 (公匏ドキュメント) : Pub/Sub ずは 参考 (G-gen Tech Blog) : Google Cloudで理解する疎結合アヌキテクチャずメッセヌゞングサヌビス StreamingPull API ずは Pub/Sub のクラむアントラむブラリでは、1 ぀の pull リク゚ストで 1 ぀の pull レスポンスが返る 単項 Pull のほかに、高スルヌプット・䜎レむテンシのメッセヌゞ凊理を目的ずした StreamingPull を䜿甚するこずができたす。 StreamingPull API を䜿甚するこずで、メッセヌゞを凊理するアプリケヌションず Pub/Sub ずの間に氞続的な双方向接続が維持され、Pub/Sub でメッセヌゞが利甚可胜になるずすぐにアプリケヌションから pull されるようになりたす。 StreamingPull API の詳现に぀いおは、以䞋の蚘事もご䞀読ください。 blog.g-gen.co.jp Pub/Sub におけるメッセヌゞの配信順序に぀いお Pub/Sub のデフォルトの蚭定では、パブリッシュされたメッセヌゞがサブスクリプションに配信される際、その配信順序は保蚌されおいたせん。぀たり、先にパブリッシュされたメッセヌゞが次のメッセヌゞよりも埌に凊理される可胜性があるずいうこずです。 Pub/Subでは 順序指定キヌ (Ordering Key) を䜿甚するこずで、メッセヌゞの配信順序を制埡するこずができたす。 順序指定キヌを䜿甚するには、パブリッシャヌ偎ず Pub/Sub サブスクリプション偎の 䞡方で 以䞋のような蚭定をしたす。 察象 蚭定内容 パブリッシャヌ偎のコヌド クラむアントラむブラリで送信するメッセヌゞに順序指定キヌを蚭定する。 Pub/Sub サブスクリプション enable_message_ordering プロパティを true 有効にする。 参考 : メッセヌゞの順序指定 順序指定キヌの特性 順序付け 同じ順序指定キヌをも぀メッセヌゞは、パブリッシュされた順番を保持したたたサブスクリプションに配信されるようになりたすfirst-in-first-out。 順序指定キヌによるメッセヌゞの順序付け 再配信の䞀貫性 順序指定が有効になっおいるメッセヌゞのいずれかが゚ラヌにより再配信される堎合、Pub/Sub はメッセヌゞの順序を維持するため、同じ順序指定キヌを持぀すべおのメッセヌゞを再配信したす。 したがっお、メッセヌゞ重耇に察する远加の凊理をサブスクラむバヌ偎に実装し、冪等性を担保する必芁がありたす。 再配信の䞀貫性ずメッセヌゞの重耇 アフィニティ サブスクラむバヌが耇数のワヌカヌで構成され、StreamingPull API を䜿甚する堎合、同じ順序指定キヌを持぀メッセヌゞは ベスト゚フォヌト ベヌスで 同じサブスクラむバヌに送信されたす。 StreamingPull API ず順序指定キヌを䜿甚した堎合のアフィニティ ただしこのアフィニティの仕様は公匏ガむドには蚘茉されおおらず、Google Cloud Pub/Sub チヌムの開発者によっお以䞋のコラムに蚘茉されおいたものです。この蚘茉は公匏ガむドではないものの、Google Cloud 開発チヌムの名前ず共に発衚されおいるこずに加え、 公匏ガむドからリンクが貌られおいる こずもあり、圓蚘事でも公匏に準ずる仕様ずしおご玹介したした。 参考 : Google Cloud Pub/Sub Ordered Delivery 怜蚌 ここからは、Pub/Subにおける StreamingPull API 䜿甚時の順序指定キヌの動䜜を怜蚌しおいきたす。 構成 䜿甚するサヌビス メッセヌゞのパブリッシャヌには Cloud Run jobs を䜿甚し、䞊列実行されるタスクから耇数のメッセヌゞを送信したす。 サブスクラむバヌずしおは Google Kubernetes Engine以䞋、GKEを䜿甚し、耇数の Pod から StreamingPull API によるメッセヌゞの Pull を行いたす。 Cloud Run jobs ず GKE を䜿甚した Pub/Sub 構成 Cloud Run jobs に぀いお Cloud Run jobs ずは、サヌバヌレス コンテナコンピュヌティングサヌビスである Cloud Run の 1 機胜です。 HTTP リク゚ストを凊理の起点ずする Cloud Run services に察しお、Cloud Run jobs はコンテナむメヌゞずしお実装したゞョブを、手動、スケゞュヌル、ワヌクフロヌなど、ナヌザの任意タむミングで䞊列しお実行するこずができたす。 圓蚘事では、同䞀の凊理タスクを容易に䞊列実行できる特性を利甚し、Pub/Sub にメッセヌゞを送信する耇数のパブリッシャヌの圹割を持たせたす。 Cloud Run jobs の詳现に぀いおは、以䞋の蚘事で解説しおいたす。 blog.g-gen.co.jp Google Kubernetes Engine (GKE) に぀いお GKE はコンテナオヌケストレヌションツヌルである Kubernetes を、Google マネヌゞドのクラスタで䜿甚するこずができるサヌビスです。 圓蚘事ではコンピュヌトリ゜ヌスである Pod を容易に氎平スケヌルできる特性を利甚し、StreamingPull を実行するサブスクラむバヌが耇数ある堎合のメッセヌゞ送信先のアフィニティを怜蚌したす。 GKE の詳现に぀いおは以䞋の蚘事で解説しおいたす。 blog.g-gen.co.jp Pub/Sub トピック、サブスクリプションの䜜成 Pub/Sub のトピックずサブスクリプションをそれぞれ䜜成したす。 始めは順序指定キヌを蚭定しない堎合の動䜜を確認するため、デフォルトの蚭定のたた䜜成したす。 # Pub/Sub トピックの䜜成 $ gcloud pubsub topics create { トピック名 } # 実行䟋 $ gcloud pubsub topics create mytopic # Pub/Sub サブスクリプションの䜜成 $ gcloud pubsub subscriptions create { サブスクリプション名 } --topic={トピック名} # 実行䟋 $ gcloud pubsub subscriptions create mysubscription --topic=mytopic パブリッシャヌの䜜成Cloud Run jobs 䜿甚するコヌドGo 公匏ドキュメント のサンプルコヌドを元に、Pub/Sub に順序指定キヌを指定したメッセヌゞを送信する凊理を実装したす。 メッセヌゞのパブリッシュには Pub/Sub のクラむアントラむブラリである cloud.google.com/go/pubsub を䜿甚したす。 Cloud Run jobs のデフォルトの環境倉数 CLOUD_RUN_TASK_INDEX からタスクのむンデックス番号を取埗し、これを Pub/Sub の順序指定キヌずしお䜿甚したす。 䞊列実行される Cloud Run jobs タスクごずに task#{タスクのむンデックス番号} messageNumber={メッセヌゞ番号} の圢匏でメッセヌゞがパブリッシュされたす。 package main import ( "context" "fmt" "log" "os" "sync" "sync/atomic" "cloud.google.com/go/pubsub" // Pub/Subクラむアントラむブラリ "google.golang.org/api/option" ) type Message struct { message string orderingKey string } // メッセヌゞを生成する関数 func generateMessages(taskNum string ) ([]Message, error ) { var messages []Message // メッセヌゞを 5 個生成 for i := 0 ; i < 5 ; i++ { m := Message{ message: fmt.Sprintf( "task#%v messageNumber=%v" , taskNum, i), orderingKey: fmt.Sprintf( "task#%v" , taskNum), } messages = append (messages, m) } fmt.Printf( "Generate messages: %v \n " , messages) return messages, nil } // メッセヌゞをパブリッシュする関数 func publishWithOrderingKey(messages []Message, projectID, topicID string ) error { ctx := context.Background() // Pub/Sub Client client, err := pubsub.NewClient(ctx, projectID, option.WithEndpoint( "asia-northeast1-pubsub.googleapis.com:443" )) if err != nil { return fmt.Errorf( "pubsub.NewClient: %v" , err) } defer client.Close() var wg sync.WaitGroup var totalErrors uint64 t := client.Topic(topicID) // トピックの指定 t.EnableMessageOrdering = true // 順序指定キヌの有効化 // メッセヌゞのパブリッシュ for _, m := range messages { res := t.Publish(ctx, &pubsub.Message{ Data: [] byte (m.message), OrderingKey: m.orderingKey, }) wg.Add( 1 ) go func (res *pubsub.PublishResult) { defer wg.Done() _, err := res.Get(ctx) if err != nil { fmt.Printf( "Failed to publish: %s \n " , err) atomic.AddUint64(&totalErrors, 1 ) return } }(res) } wg.Wait() if totalErrors > 0 { fmt.Printf( "%d messages did not publish successfully" , totalErrors) return nil } fmt.Println( "Published messages with ordering keys successfully" ) return nil } // メむン関数 func main() { // タスク番号を取埗Cloud Run jobs のデフォルトの環境倉数 taskNum := os.Getenv( "CLOUD_RUN_TASK_INDEX" ) // Cloud Run jobs に蚭定した環境倉数からプロゞェクト ID ず Pub/Sub トピック ID を取埗 projectID := os.Getenv( "PROJECT_ID" ) topicID := os.Getenv( "TOPIC_ID" ) messages, err := generateMessages(taskNum) if err != nil { log.Fatal(err) } err = publishWithOrderingKey(messages, projectID, topicID) if err != nil { log.Fatal(err) } } このコヌドは 1 回の実行で 5 ぀のメッセヌゞを生成・パブリッシュするため、䞊列しお実行する Cloud Run jobs のタスク 1 ぀に぀き、以䞋に瀺す各行のメッセヌゞが順番にパブリッシュされたす。 # タスクのむンデックス番号が 0 の堎合 task# 0 messageNumber = 0 task# 0 messageNumber = 1 task# 0 messageNumber = 2 task# 0 messageNumber = 3 task# 0 messageNumber = 4 参考 順序指定キヌを䜿甚したパブリッシュ コンテナむメヌゞのビルド Dockerfile を䜿甚せず、Buildpack を䜿甚しおコンテナむメヌゞをビルドしたす。Buildpack を䜿甚するこずで、゜ヌスコヌドを自動でパッケヌゞ化し、デプロむ可胜なコンテナむメヌゞを生成するこずができたす。 Artifact Registry にコンテナむメヌゞをプッシュするため、リポゞトリがない堎合は以䞋のコマンドを実行する前に䜜成しおください。 # Buildpack を䜿甚しおむメヌゞをビルドする $ gcloud builds submit --pack image = { リポゞトリの URL } / { コンテナむメヌゞ名 } # 実行䟋リポゞトリに Artifact Registry を䜿甚 $ gcloud builds submit --pack image =asia-northeast1-docker.pkg.dev/myproject/pubsub-container/publisher-orderingkey 参考① Google Cloud の Buildpack 参考② Cloud Run で Go ゞョブをビルドしお䜜成する ゞョブの䜜成 Artifact Registry にプッシュしたコンテナむメヌゞを䜿甚しお、Cloud Run jobs のゞョブを䜜成したす。 環境倉数ずしお プロゞェクト ID ず Pub/Sub トピック名 を蚭定し、同時に実行する Task の数を 50 に蚭定しおいたす。 # Cloud Run jobs のゞョブを䜜成する実行 Task 数 = 50 $ gcloud run jobs create { ゞョブ名 } \ --image { むメヌゞの URL } \ --region { リヌゞョン } \ --tasks 50 \ --set-env-vars PROJECT_ID = { プロゞェクト ID } , TOPIC_ID = { Pub/Sub トピック名 } # 実行䟋 $ gcloud run jobs create jobs-publisher-orderingkey \ --image asia-northeast1-docker.pkg.dev/myproject/pubsub-container/publisher-orderingkey \ --region asia-northeast1 \ --tasks 50 \ --set-env-vars PROJECT_ID =myproject, TOPIC_ID =mytopic サブスクラむバヌの䜜成GKE 䜿甚するコヌドGo 公匏ドキュメント を参考に、StreamingPull API を䜿甚しお Pub/Sub のメッセヌゞを受け取り、そのたたログ出力する凊理を実装したす。 このアプリケヌションは GKE クラスタ䞊の Pod で動䜜し、Pub/Sub から Pull したメッセヌゞをそのたた暙準出力に出力したす。 パブリッシュの凊理ず同様、 cloud.google.com/go/pubsub ラむブラリを䜿甚しお Pub/Sub API にアクセスしたす。 package main import ( "context" "fmt" "io" "log" "os" "cloud.google.com/go/pubsub" // Pub/Sub クラむアントラむブラリ ) // メッセヌゞを StreamingPull する関数 func pullMessages(w io.Writer , c context.Context, projectId, subId string ) error { // Pub/Sub Client client, err := pubsub.NewClient(c, projectId) if err != nil { return fmt.Errorf( "pubsub.NewClient: %v" , err) } defer client.Close() // サブスクリプションの参照 sub := client.Subscription(subId) // メッセヌゞを pull し続ける err = sub.Receive(c, func (_ context.Context, msg *pubsub.Message) { fmt.Fprintf(w, "%v \n " , string (msg.Data)) // メッセヌゞを暙準出力に出力 msg.Ack() }) if err != nil { return fmt.Errorf( "sub.Receive: %v" , err) } return nil } func main() { ctx := context.Background() // 環境倉数からプロゞェクト ID ず PubSub トピック ID を取埗 projectId := os.Getenv( "PROJECT_ID" ) subId := os.Getenv( "SUBSCRIPTION_ID" ) err := pullMessages(os.Stdout, ctx, projectId, subId) if err != nil { log.Fatal(err) } } コンテナむメヌゞを Artifact Registry にプッシュ GKE クラスタ䞊で実行される Pod にアプリケヌションをデプロむするため、こちらもコンテナむメヌゞを䜜成しお Artifact Registry にプッシュしたす。 # Buildpack を䜿甚しおむメヌゞをビルドする $ gcloud builds submit --pack image = { リポゞトリの URL } / { コンテナむメヌゞ名 } # 実行䟋リポゞトリに Artifact Registry を䜿甚 $ gcloud builds submit --pack image =asia-northeast1-docker.pkg.dev/myproject/pubsub-container/subscriber-orderingkey GKE クラスタの䜜成 圓蚘事では Autopilot モヌドの GKE クラスタ䞊でサブスクラむバヌ甚の Pod を実行したす。 䜿甚できる VPC、サブネットがない堎合は以䞋のコマンドを実行する前に䜜成しおください。 # Autopilot モヌドの GKE クラスタを䜜成する $ gcloud container clusters create-auto { クラスタ名 } \ --region { リヌゞョン } \ --network { VPC名 } --subnetwork { サブネット名 } # 実行䟋 $ gcloud container clusters create-auto mycluster-autopilot \ --region asia-northeast1 \ --network myvpc \ --subnetwork mysubnet Workload Identity の蚭定 Autopilot モヌドの GKE クラスタ䞊で実行される Pod から Pub/Sub などの Google Cloud APIs を䜿甚するためには、Pod に蚭定する Kubernetes の ServiceAccount ず Pub/Sub の暩限を付䞎した Google Cloud のサヌビスアカりント を Workload Identity によっお玐づける必芁がありたす。 圓蚘事では䟿宜䞊、Kubernetes の ServiceAccount を KSA 、Google Cloud のサヌビスアカりントを GSA ず呌びたす。 Workload Identity は以䞋の蚘事で解説しおいるので、詳现に぀いおはこちらもご䞀読ください。 blog.g-gen.co.jp GSA の䜜成 たず、䜕も暩限を持たない GSA を䜜成したす。 # GSA を䜜成する $ gcloud iam service-accounts create { GSA の名前 } --project { プロゞェクト ID } # 実行䟋 $ gcloud iam service-accounts create my-gsa --project myproject 次に、䜜成した Pub/Sub サブスクリプションからメッセヌゞを Pull するために「 Pub/Sub サブスクラむバヌ  roles/pubsub.subscriber 」 ロヌルを GSA に付䞎したす。 # GSA に IAM ロヌルを玐付ける $ gcloud pubsub subscriptions add-iam-policy-binding { サブスクリプション名 } \ --role " roles/pubsub.subscriber " \ --member " serviceAccount:{GSA の名前}@{プロゞェクト ID}.iam.gserviceaccount.com " # 実行䟋 $ gcloud pubsub subscriptions add-iam-policy-binding mysubscription \ --role " roles/pubsub.subscriber " \ --member " serviceAccount:my-gsa@myproject.iam.gserviceaccount.com " KSA の䜜成 GKE クラスタに接続し、クラスタに KSA を䜜成したす。 以䞋の内容でマニフェストファむル ksa.yaml を䜜成し、クラスタに適甚したす。 # ksa.yaml apiVersion : v1 kind : ServiceAccount metadata : name : my-ksa annotations : # Workload Identity で玐付ける GSA を指定する iam.gke.io/gcp-service-account : my-gsa@myproject.iam.gserviceaccount.com # GKE クラスタに接続する $ gcloud container clusters get-credentials { クラスタ名 } --region asia-northeast1 --project { プロゞェクト名 } # 実行䟋 $ gcloud container clusters get-credentials mycluster-autopilot --region asia-northeast1 --project myproject # GKE クラスタに KSA を䜜成する $ kubectl apply -f ksa.yaml KSA ず GSA の玐付け KSA が GSA の暩限を借甚しお Google Cloud APIs にアクセスできるように、 GSA に察する「Workload Identity User ( roles/iam.workloadIdentityUser )」ロヌルを KSA に玐付けたす。 # KSA ず GSA を玐付ける $ gcloud iam service-accounts add-iam-policy-binding { GSAの名前 } @ { プロゞェクトID } .iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member " serviceAccount:{プロゞェクトID}.svc.id.goog[{KSAを䜜成したNamespace}/{KSAの名前}] " # 実行䟋default名前空間を䜿甚しおいる堎合 $ gcloud iam service-accounts add-iam-policy-binding my-gsa@myproject.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member " serviceAccount:myproject.svc.id.goog[default/my-ksa] " アプリケヌションのデプロむGKE サブスクラむバヌのアプリケヌションを GKE にデプロむするマニフェストファむル deployment.yaml は以䞋のようになりたす。 圓蚘事では始めにサブスクラむバヌPodの数が 1 の堎合の動䜜怜蚌をするため、 spec.replicas の倀を 1 にしおいたす。 マニフェストファむルは、この時点ではただクラスタに適甚したせん。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : pubsub-subscriber spec : replicas : 1 selector : matchLabels : app : subscriber template : metadata : labels : app : subscriber spec : containers : - name : subsc-container image : "asia-northeast1-docker.pkg.dev/myproject/pubsub-container/subscriber-orderingkey" # サブスクラむバヌのコンテナむメヌゞ env : - name : "PROJECT_ID" value : "myproject" # Pub/Sub を䜜成したプロゞェクトの ID - name : "SUBSCRIPTION_ID" value : "mysubscription" # Pub/Sub サブスクリプションの名前 resources : requests : cpu : "500m" serviceAccountName : my-ksa # Workload Identity で䜿甚する ServiceAccount 動䜜確認 動䜜確認の基本的な流れ 動䜜確認は、基本的に以䞋の流れで行いたす。 ① Cloud Run jobs のタスク実行メッセヌゞのパブリッシュ ↓ ② GKE クラスタにサブスクラむバヌ甚 Pod を䜜成メッセヌゞの StreamingPull 凊理 ↓ ③ Pod のログを確認 ↓ ④ Pod の削陀 ①ず②は順番が逆のように芋えたすが、②→①の順に実斜しおしたうず、メッセヌゞがそれほど倚くない堎合メッセヌゞが Pub/Sub に貯たるこずなくすぐに Pod によっお凊理されおしたうため、順序指定を有効化するたでもなく順番通りに凊理されおしたい、順序指定の効果が確認できなくなりたす。したがっお、この怜蚌では①→②の順に実斜したす。 メッセヌゞの順序指定を有効化しない堎合の動䜜 たず、順序指定を 有効化しない 堎合の動䜜を確認したす。 ここたでに䜜成したリ゜ヌスは以䞋のような構成になっおいたす。パブリッシャヌのコヌドで順序指定キヌを蚭定しおいたすが、サブスクリプションでメッセヌゞの順序指定を有効化しおいたせん。この堎合は順序指定キヌは機胜したせん。 順序指定が有効化されおいないメッセヌゞを単䞀の Pod で StreamingPull する 以䞋のコマンドで Cloud Run のゞョブを実行し、メッセヌゞをパブリッシュしたす。Cloud Run jobs では 50 個のタスクを䞊列実行し、各タスク 5 ぀、合蚈 250 個のメッセヌゞを Pub/Sub トピックにパブリッシュしたす。 # ゞョブの実行Cloud Run jobs $ gcloud run jobs execute jobs-publisher-orderingkey --region asia-northeast1 --wait ゞョブの完了を確認したら、GKE クラスタに deployment.yaml を適甚し、Pod を䜜成したす。 # Pod の䜜成 $ kubectl apply -f deployment.yaml # Pod のステヌタスを確認 $ kubectl get pods # 出力䟋 $ kubectl get pods NAME READY STATUS RESTARTS AGE pubsub-subscriber-545b97bb97-lnkkb 1 / 1 Running 0 3m37s Pod のステヌタスが Running になったら、Pod のログを確認したす。 順序指定が有効になっおいないため、タスクのむンデックス番号task#の数字が同じであっおも messageNumber の順番が 0→1→2→3→4 になっおいないメッセヌゞのパブリッシュ順に凊理されおいないケヌスがいく぀かあるこずがわかりたす。 # Pod のログを確認する順序指定キヌを蚭定しおいない堎合 $ kubectl logs { Pod 名 } # 出力䟋抜粋 $ kubectl logs pubsub-subscriber-545b97bb97-lnkkb task# 5 messageNumber = 0 task# 5 messageNumber = 1 task# 7 messageNumber = 4 ~~~省略~~~ task# 43 messageNumber = 0 task# 43 messageNumber = 1 task# 43 messageNumber = 2 task# 43 messageNumber = 3 task# 43 messageNumber = 4 task# 7 messageNumber = 0 task# 7 messageNumber = 1 task# 7 messageNumber = 2 task# 7 messageNumber = 3 task# 13 messageNumber = 2 task# 13 messageNumber = 3 task# 13 messageNumber = 4 task# 35 messageNumber = 0 task# 35 messageNumber = 1 task# 35 messageNumber = 2 task# 35 messageNumber = 3 task# 35 messageNumber = 4 task# 11 messageNumber = 4 task# 11 messageNumber = 0 task# 11 messageNumber = 1 task# 11 messageNumber = 2 task# 11 messageNumber = 3 ~~~省略~~~ 次の怜蚌のため、Pod を䞀旊削陀したす。 # Pod の削陀 $ kubectl delete -f deployment.yaml メッセヌゞの順序指定が有効化されたサブスクリプションの䜜成 順序指定が有効化されたサブスクリプションを䜜成したす。 順序指定の蚭定はサブスクリプション䜜成埌に倉曎するこずはできないため、䞀床サブスクリプションを削陀したす。 # 順序指定が有効化されおいない Pub/Sub サブスクリプションの削陀 $ gcloud pubsub subscriptions delete { サブスクリプション名 } # 実行䟋 $ gcloud pubsub subscriptions delete mysubscription サブスクリプションを削陀したら、順序指定を有効化した同名のサブスクリプションを䜜成したす。 # 順序指定が有効化された Pub/Sub サブスクリプションの䜜成 $ gcloud pubsub subscriptions create { サブスクリプション名 } \ --topic = { トピック名 } \ --enable-message-ordering # 実行䟋 $ gcloud pubsub subscriptions create mysubscription \ --topic = mytopic \ --enable-message-ordering Pub/Sub サブスクリプションを䜜り盎したため、再床サブスクリプションに察する「 Pub/Sub サブスクラむバヌ  roles/pubsub.subscriber 」 ロヌルを GSA に付䞎したす。 # GSA に IAM ロヌルを玐付ける $ gcloud pubsub subscriptions add-iam-policy-binding { サブスクリプション名 } \ --role " roles/pubsub.subscriber " \ --member " serviceAccount:{GSA の名前}@{プロゞェクト ID}.iam.gserviceaccount.com " # 実行䟋 $ gcloud pubsub subscriptions add-iam-policy-binding mysubscription \ --role " roles/pubsub.subscriber " \ --member " serviceAccount:my-gsa@myproject.iam.gserviceaccount.com " サブスクラむバヌが単䞀の堎合の動䜜 次は、順序指定を有効化した状態で、メッセヌゞを単䞀のサブスクラむバヌで凊理したす。 順序指定が有効化されたメッセヌゞを単䞀の Pod から StreamingPull する 先ほどず同様の手順で Cloud Run job のゞョブを実行し、ゞョブの完了を確認しおから GKE クラスタに Pod を䜜成したす。 Cloud Run jobs で 50 個のタスクを䞊列実行し、各タスク 5 ぀、合蚈 250 個のメッセヌゞをパブリッシュした堎合のサブスクラむバヌ偎 Pod のログは以䞋のようになりたす。 タスクのむンデックス番号を順序指定キヌずしお蚭定したため、同䞀タスクtask#で識別からのメッセヌゞがパブリッシュされた順messageNumber が 0→1→2→3→4 に凊理されおいるこずがわかりたす。 # Pod のログを確認する党文 # 出力䟋 $ kubectl logs pubsub-subscriber-944bcdb7b-9zrbz task# 27 messageNumber = 0 task# 8 messageNumber = 0 task# 7 messageNumber = 0 task# 46 messageNumber = 0 task# 16 messageNumber = 0 task# 29 messageNumber = 0 task# 3 messageNumber = 0 task# 43 messageNumber = 0 task# 14 messageNumber = 0 task# 21 messageNumber = 0 task# 21 messageNumber = 1 task# 21 messageNumber = 2 task# 21 messageNumber = 3 task# 21 messageNumber = 4 task# 45 messageNumber = 0 task# 45 messageNumber = 1 task# 45 messageNumber = 2 task# 45 messageNumber = 3 task# 45 messageNumber = 4 task# 41 messageNumber = 0 task# 39 messageNumber = 0 task# 49 messageNumber = 0 task# 17 messageNumber = 0 task# 17 messageNumber = 1 task# 17 messageNumber = 2 task# 32 messageNumber = 0 task# 0 messageNumber = 0 task# 0 messageNumber = 1 task# 40 messageNumber = 0 task# 35 messageNumber = 0 task# 15 messageNumber = 0 task# 11 messageNumber = 0 task# 2 messageNumber = 0 task# 2 messageNumber = 1 task# 2 messageNumber = 2 task# 2 messageNumber = 3 task# 2 messageNumber = 4 task# 36 messageNumber = 0 task# 36 messageNumber = 1 task# 9 messageNumber = 0 task# 9 messageNumber = 1 task# 9 messageNumber = 2 task# 9 messageNumber = 3 task# 9 messageNumber = 4 task# 23 messageNumber = 0 task# 23 messageNumber = 1 task# 23 messageNumber = 2 task# 10 messageNumber = 0 task# 10 messageNumber = 1 task# 10 messageNumber = 2 task# 10 messageNumber = 3 task# 10 messageNumber = 4 task# 37 messageNumber = 0 task# 22 messageNumber = 0 task# 22 messageNumber = 1 task# 22 messageNumber = 2 task# 24 messageNumber = 0 task# 24 messageNumber = 1 task# 24 messageNumber = 2 task# 24 messageNumber = 3 task# 24 messageNumber = 4 task# 4 messageNumber = 0 task# 4 messageNumber = 1 task# 30 messageNumber = 0 task# 30 messageNumber = 1 task# 30 messageNumber = 2 task# 38 messageNumber = 0 task# 48 messageNumber = 0 task# 44 messageNumber = 0 task# 44 messageNumber = 1 task# 44 messageNumber = 2 task# 42 messageNumber = 0 task# 42 messageNumber = 1 task# 42 messageNumber = 2 task# 42 messageNumber = 3 task# 42 messageNumber = 4 task# 33 messageNumber = 0 task# 26 messageNumber = 0 task# 26 messageNumber = 1 task# 26 messageNumber = 2 task# 26 messageNumber = 3 task# 26 messageNumber = 4 task# 20 messageNumber = 0 task# 20 messageNumber = 1 task# 20 messageNumber = 2 task# 31 messageNumber = 0 task# 31 messageNumber = 1 task# 31 messageNumber = 2 task# 47 messageNumber = 0 task# 25 messageNumber = 0 task# 25 messageNumber = 1 task# 25 messageNumber = 2 task# 25 messageNumber = 3 task# 25 messageNumber = 4 task# 19 messageNumber = 0 task# 19 messageNumber = 1 task# 19 messageNumber = 2 task# 19 messageNumber = 3 task# 19 messageNumber = 4 task# 13 messageNumber = 0 task# 13 messageNumber = 1 task# 13 messageNumber = 2 task# 13 messageNumber = 3 task# 13 messageNumber = 4 task# 12 messageNumber = 0 task# 1 messageNumber = 0 task# 6 messageNumber = 0 task# 6 messageNumber = 1 task# 6 messageNumber = 2 task# 6 messageNumber = 3 task# 18 messageNumber = 0 task# 6 messageNumber = 4 task# 5 messageNumber = 0 task# 5 messageNumber = 1 task# 5 messageNumber = 2 task# 5 messageNumber = 3 task# 34 messageNumber = 0 task# 34 messageNumber = 1 task# 34 messageNumber = 2 task# 34 messageNumber = 3 task# 34 messageNumber = 4 task# 28 messageNumber = 0 task# 3 messageNumber = 1 task# 3 messageNumber = 2 task# 3 messageNumber = 3 task# 3 messageNumber = 4 task# 7 messageNumber = 1 task# 7 messageNumber = 2 task# 7 messageNumber = 3 task# 7 messageNumber = 4 task# 8 messageNumber = 1 task# 8 messageNumber = 2 task# 8 messageNumber = 3 task# 8 messageNumber = 4 task# 27 messageNumber = 1 task# 27 messageNumber = 2 task# 27 messageNumber = 3 task# 27 messageNumber = 4 task# 29 messageNumber = 1 task# 29 messageNumber = 2 task# 29 messageNumber = 3 task# 29 messageNumber = 4 task# 14 messageNumber = 1 task# 14 messageNumber = 2 task# 14 messageNumber = 3 task# 14 messageNumber = 4 task# 46 messageNumber = 1 task# 46 messageNumber = 2 task# 46 messageNumber = 3 task# 46 messageNumber = 4 task# 16 messageNumber = 1 task# 16 messageNumber = 2 task# 16 messageNumber = 3 task# 16 messageNumber = 4 task# 41 messageNumber = 1 task# 41 messageNumber = 2 task# 41 messageNumber = 3 task# 41 messageNumber = 4 task# 43 messageNumber = 1 task# 43 messageNumber = 2 task# 43 messageNumber = 3 task# 43 messageNumber = 4 task# 47 messageNumber = 1 task# 47 messageNumber = 2 task# 47 messageNumber = 3 task# 47 messageNumber = 4 task# 31 messageNumber = 3 task# 31 messageNumber = 4 task# 12 messageNumber = 1 task# 30 messageNumber = 3 task# 30 messageNumber = 4 task# 28 messageNumber = 1 task# 28 messageNumber = 2 task# 28 messageNumber = 3 task# 28 messageNumber = 4 task# 44 messageNumber = 3 task# 44 messageNumber = 4 task# 5 messageNumber = 4 task# 38 messageNumber = 1 task# 38 messageNumber = 2 task# 38 messageNumber = 3 task# 38 messageNumber = 4 task# 4 messageNumber = 2 task# 4 messageNumber = 3 task# 4 messageNumber = 4 task# 1 messageNumber = 1 task# 1 messageNumber = 2 task# 1 messageNumber = 3 task# 1 messageNumber = 4 task# 12 messageNumber = 2 task# 12 messageNumber = 3 task# 12 messageNumber = 4 task# 48 messageNumber = 1 task# 48 messageNumber = 2 task# 48 messageNumber = 3 task# 48 messageNumber = 4 task# 20 messageNumber = 3 task# 33 messageNumber = 1 task# 20 messageNumber = 4 task# 18 messageNumber = 1 task# 18 messageNumber = 2 task# 18 messageNumber = 3 task# 18 messageNumber = 4 task# 33 messageNumber = 2 task# 33 messageNumber = 3 task# 33 messageNumber = 4 task# 36 messageNumber = 2 task# 36 messageNumber = 3 task# 36 messageNumber = 4 task# 23 messageNumber = 3 task# 23 messageNumber = 4 task# 22 messageNumber = 3 task# 22 messageNumber = 4 task# 37 messageNumber = 1 task# 37 messageNumber = 2 task# 37 messageNumber = 3 task# 37 messageNumber = 4 task# 35 messageNumber = 1 task# 35 messageNumber = 2 task# 35 messageNumber = 3 task# 35 messageNumber = 4 task# 17 messageNumber = 3 task# 17 messageNumber = 4 task# 39 messageNumber = 1 task# 39 messageNumber = 2 task# 39 messageNumber = 3 task# 39 messageNumber = 4 task# 15 messageNumber = 1 task# 15 messageNumber = 2 task# 15 messageNumber = 3 task# 15 messageNumber = 4 task# 0 messageNumber = 2 task# 0 messageNumber = 3 task# 0 messageNumber = 4 task# 11 messageNumber = 1 task# 11 messageNumber = 2 task# 11 messageNumber = 3 task# 11 messageNumber = 4 task# 49 messageNumber = 1 task# 49 messageNumber = 2 task# 49 messageNumber = 3 task# 49 messageNumber = 4 task# 40 messageNumber = 1 task# 40 messageNumber = 2 task# 40 messageNumber = 3 task# 40 messageNumber = 4 task# 32 messageNumber = 1 task# 32 messageNumber = 2 task# 32 messageNumber = 3 task# 32 messageNumber = 4 サブスクラむバヌが耇数の堎合の動䜜アフィニティの怜蚌 最埌に Pod の数を 3 ぀に増やし、順序指定が有効化されたメッセヌゞを StreamingPull API で Pull した堎合に、メッセヌゞがどのように分散するかを確認したす。 順序指定が有効化されたメッセヌゞを耇数の Pod から StreamingPull する マニフェストファむルの spec.replicas の倀を 3 に倉曎したす。 # deployment.yaml apiVersion : apps/v1 kind : Deployment metadata : name : pubsub-subscriber spec : replicas : 3 # ここを倉曎する selector : matchLabels : app : subscriber template : metadata : labels : app : subscriber spec : containers : - name : subsc-container image : "asia-northeast1-docker.pkg.dev/myproject/pubsub-container/subscriber-orderingkey" # サブスクラむバヌのコンテナむメヌゞ env : - name : "PROJECT_ID" value : "myproject" # Pub/Sub を䜜成したプロゞェクトの ID - name : "SUBSCRIPTION_ID" value : "mysubscription" # Pub/Sub サブスクリプションの名前 resources : requests : cpu : "500m" serviceAccountName : my-ksa # Workload Identity で䜿甚する ServiceAccount 今たで同様、Cloud Run jobs のゞョブを実行しおメッセヌゞをパブリッシュした埌、マニフェストファむルを適甚しお 3 ぀の Pod を䜜成したす。 Pod がすべお正垞に実行されおいるのを確認したら 各 Pod のログを確認したす。 始めに、各 Pod に送られたメッセヌゞ数を確認するために、ログの行数を芋おみたす。 メッセヌゞはタスクごずに 5 ぀送信されるため、タスクのむンデックス番号を順序を指定キヌずしお分散凊理を行った堎合、メッセヌゞの再配信が行われおいなければ、アフィニティによっお各 Pod が凊理するメッセヌゞの数は 5 の倍数になるはずです※アフィニティがベスト゚フォヌトベヌスである点は泚意。 今回の結果を芋たずころ、各 Pod で 5 の倍数の数だけメッセヌゞを凊理しおいるようです。 # 出力䟋 # Pod のログの行数を確認する $ kubectl logs pubsub-subscriber-944bcdb7b-pch4t | wc -l 75 $ kubectl logs pubsub-subscriber-944bcdb7b-s7xdq | wc -l 95 $ kubectl logs pubsub-subscriber-944bcdb7b-wp6jt | wc -l 80 実際のログを確認しおみたす。3 ぀の Pod のログを以䞋に蚘茉したす。 順序指定キヌず StreamingPull API を䜿甚した際のアフィニティにより、同䞀タスクからパブリッシュされたメッセヌゞtask#が同じものは同䞀の Pod に送信され、パブリッシュされた順messageNumber が 0→1→2→3→4 に凊理されおいるこずがわかりたす。 # 1 ぀目の Pod のログを確認する党文 # 出力䟋 $ kubectl logs pubsub-subscriber-944bcdb7b-pch4t task# 34 messageNumber = 0 task# 34 messageNumber = 1 task# 27 messageNumber = 0 task# 44 messageNumber = 0 task# 44 messageNumber = 1 task# 44 messageNumber = 2 task# 44 messageNumber = 3 task# 31 messageNumber = 0 task# 32 messageNumber = 0 task# 32 messageNumber = 1 task# 32 messageNumber = 2 task# 37 messageNumber = 0 task# 37 messageNumber = 1 task# 37 messageNumber = 2 task# 6 messageNumber = 0 task# 49 messageNumber = 0 task# 49 messageNumber = 1 task# 26 messageNumber = 0 task# 26 messageNumber = 1 task# 26 messageNumber = 2 task# 26 messageNumber = 3 task# 10 messageNumber = 0 task# 10 messageNumber = 1 task# 10 messageNumber = 2 task# 10 messageNumber = 3 task# 42 messageNumber = 0 task# 42 messageNumber = 1 task# 48 messageNumber = 0 task# 48 messageNumber = 1 task# 28 messageNumber = 0 task# 37 messageNumber = 3 task# 37 messageNumber = 4 task# 11 messageNumber = 0 task# 11 messageNumber = 1 task# 11 messageNumber = 2 task# 11 messageNumber = 3 task# 11 messageNumber = 4 task# 44 messageNumber = 4 task# 26 messageNumber = 4 task# 34 messageNumber = 2 task# 34 messageNumber = 3 task# 34 messageNumber = 4 task# 8 messageNumber = 0 task# 8 messageNumber = 1 task# 8 messageNumber = 2 task# 8 messageNumber = 3 task# 31 messageNumber = 1 task# 31 messageNumber = 2 task# 31 messageNumber = 3 task# 31 messageNumber = 4 task# 10 messageNumber = 4 task# 32 messageNumber = 3 task# 32 messageNumber = 4 task# 42 messageNumber = 2 task# 42 messageNumber = 3 task# 42 messageNumber = 4 task# 48 messageNumber = 2 task# 48 messageNumber = 3 task# 48 messageNumber = 4 task# 28 messageNumber = 1 task# 28 messageNumber = 2 task# 28 messageNumber = 3 task# 28 messageNumber = 4 task# 49 messageNumber = 2 task# 49 messageNumber = 3 task# 49 messageNumber = 4 task# 27 messageNumber = 1 task# 27 messageNumber = 2 task# 27 messageNumber = 3 task# 27 messageNumber = 4 task# 6 messageNumber = 1 task# 6 messageNumber = 2 task# 6 messageNumber = 3 task# 6 messageNumber = 4 task# 8 messageNumber = 4 # 2 ぀目の Pod のログを確認する党文 # 出力䟋 $ kubectl logs pubsub-subscriber-944bcdb7b-s7xdq task# 14 messageNumber = 0 task# 14 messageNumber = 1 task# 14 messageNumber = 2 task# 14 messageNumber = 3 task# 14 messageNumber = 4 task# 45 messageNumber = 0 task# 43 messageNumber = 0 task# 43 messageNumber = 1 task# 43 messageNumber = 2 task# 43 messageNumber = 3 task# 5 messageNumber = 0 task# 5 messageNumber = 1 task# 2 messageNumber = 0 task# 17 messageNumber = 0 task# 17 messageNumber = 1 task# 17 messageNumber = 2 task# 19 messageNumber = 0 task# 19 messageNumber = 1 task# 19 messageNumber = 2 task# 19 messageNumber = 3 task# 19 messageNumber = 4 task# 24 messageNumber = 0 task# 24 messageNumber = 1 task# 39 messageNumber = 0 task# 2 messageNumber = 1 task# 22 messageNumber = 0 task# 22 messageNumber = 1 task# 22 messageNumber = 2 task# 22 messageNumber = 3 task# 22 messageNumber = 4 task# 4 messageNumber = 0 task# 4 messageNumber = 1 task# 4 messageNumber = 2 task# 4 messageNumber = 3 task# 4 messageNumber = 4 task# 30 messageNumber = 0 task# 30 messageNumber = 1 task# 30 messageNumber = 2 task# 30 messageNumber = 3 task# 20 messageNumber = 0 task# 20 messageNumber = 1 task# 20 messageNumber = 2 task# 20 messageNumber = 3 task# 47 messageNumber = 0 task# 9 messageNumber = 0 task# 35 messageNumber = 0 task# 46 messageNumber = 0 task# 46 messageNumber = 1 task# 46 messageNumber = 2 task# 46 messageNumber = 3 task# 46 messageNumber = 4 task# 43 messageNumber = 4 task# 1 messageNumber = 0 task# 1 messageNumber = 1 task# 1 messageNumber = 2 task# 1 messageNumber = 3 task# 1 messageNumber = 4 task# 5 messageNumber = 2 task# 29 messageNumber = 0 task# 29 messageNumber = 1 task# 29 messageNumber = 2 task# 29 messageNumber = 3 task# 29 messageNumber = 4 task# 5 messageNumber = 3 task# 5 messageNumber = 4 task# 17 messageNumber = 3 task# 17 messageNumber = 4 task# 20 messageNumber = 4 task# 30 messageNumber = 4 task# 45 messageNumber = 1 task# 45 messageNumber = 2 task# 45 messageNumber = 3 task# 45 messageNumber = 4 task# 47 messageNumber = 1 task# 47 messageNumber = 2 task# 47 messageNumber = 3 task# 47 messageNumber = 4 task# 39 messageNumber = 1 task# 39 messageNumber = 2 task# 39 messageNumber = 3 task# 39 messageNumber = 4 task# 9 messageNumber = 1 task# 9 messageNumber = 2 task# 9 messageNumber = 3 task# 9 messageNumber = 4 task# 35 messageNumber = 1 task# 2 messageNumber = 2 task# 2 messageNumber = 3 task# 2 messageNumber = 4 task# 35 messageNumber = 2 task# 35 messageNumber = 3 task# 35 messageNumber = 4 task# 24 messageNumber = 2 task# 24 messageNumber = 3 task# 24 messageNumber = 4 # 3 ぀目の Pod のログを確認する党文 # 出力䟋 $ kubectl logs pubsub-subscriber-944bcdb7b-wp6jt task# 21 messageNumber = 0 task# 21 messageNumber = 1 task# 21 messageNumber = 2 task# 12 messageNumber = 0 task# 13 messageNumber = 0 task# 13 messageNumber = 1 task# 13 messageNumber = 2 task# 13 messageNumber = 3 task# 13 messageNumber = 4 task# 18 messageNumber = 0 task# 41 messageNumber = 0 task# 41 messageNumber = 1 task# 41 messageNumber = 2 task# 41 messageNumber = 3 task# 41 messageNumber = 4 task# 23 messageNumber = 0 task# 23 messageNumber = 1 task# 23 messageNumber = 2 task# 23 messageNumber = 3 task# 23 messageNumber = 4 task# 33 messageNumber = 0 task# 15 messageNumber = 0 task# 15 messageNumber = 1 task# 0 messageNumber = 0 task# 0 messageNumber = 1 task# 0 messageNumber = 2 task# 0 messageNumber = 3 task# 0 messageNumber = 4 task# 40 messageNumber = 0 task# 40 messageNumber = 1 task# 25 messageNumber = 0 task# 25 messageNumber = 1 task# 25 messageNumber = 2 task# 25 messageNumber = 3 task# 25 messageNumber = 4 task# 36 messageNumber = 0 task# 16 messageNumber = 0 task# 16 messageNumber = 1 task# 16 messageNumber = 2 task# 16 messageNumber = 3 task# 16 messageNumber = 4 task# 33 messageNumber = 1 task# 33 messageNumber = 2 task# 33 messageNumber = 3 task# 33 messageNumber = 4 task# 12 messageNumber = 1 task# 12 messageNumber = 2 task# 12 messageNumber = 3 task# 12 messageNumber = 4 task# 7 messageNumber = 0 task# 7 messageNumber = 1 task# 7 messageNumber = 2 task# 7 messageNumber = 3 task# 7 messageNumber = 4 task# 38 messageNumber = 0 task# 38 messageNumber = 1 task# 38 messageNumber = 2 task# 38 messageNumber = 3 task# 38 messageNumber = 4 task# 3 messageNumber = 0 task# 3 messageNumber = 1 task# 3 messageNumber = 2 task# 3 messageNumber = 3 task# 3 messageNumber = 4 task# 40 messageNumber = 2 task# 40 messageNumber = 3 task# 40 messageNumber = 4 task# 21 messageNumber = 3 task# 21 messageNumber = 4 task# 15 messageNumber = 2 task# 15 messageNumber = 3 task# 15 messageNumber = 4 task# 36 messageNumber = 1 task# 36 messageNumber = 2 task# 36 messageNumber = 3 task# 36 messageNumber = 4 task# 18 messageNumber = 1 task# 18 messageNumber = 2 task# 18 messageNumber = 3 task# 18 messageNumber = 4 䜐々朚 駿倪 (蚘事䞀芧) G-gen最北端、北海道圚䜏のクラりド゜リュヌション郚゚ンゞニア 2022幎6月にG-genにゞョむン。Google Cloud Partner Top Engineer 2024に遞出。奜きなGoogle CloudプロダクトはCloud Run。 趣味はコヌヒヌ、小説SF、ミステリ、カラオケなど。 Follow @sasashun0805
G-gen セキュリティスむヌト for Google Cloud ずは ナヌスケヌス 実珟できるこず 抂芁 機胜䟋 提䟛䜓系 Terraform での提䟛 請求代行サヌビスぞの付垯 プラン䞀芧 仕組み 䜿甚する Google Cloud サヌビス スコヌプ お申し蟌み方法 G-gen セキュリティスむヌト for Google Cloud ずは G-gen セキュリティスむヌト for Google Cloud は、Google Cloud を利甚する際に必ず実装しおおきたい セキュリティ蚭定をパッケヌゞ化 した G-gen 瀟のサヌビスです。 G-gen が倚くのお客さんに察しお Google Cloud 掻甚をご支揎する䞭で、最も倚く聞かれる悩みが「Google Cloud のセキュリティ蚭定」です。「どこから初めおいいのか悩んでいる」「事䟋や、暙準的な蚭定を参考にしたい」ずいったものです。 これらを解消するため圓サヌビスでは、圓瀟の Google Cloud 開発・運甚実瞟を基に、セキュリティ蚭定・統制蚭定を Terraform コヌド化したした。 G-gen セキュリティスむヌト for Google Cloud は G-gen の Google Cloud 請求代行サヌビス にバンドル (付垯) されおいたす。 最も基本的なプランである Basic プランは、請求代行サヌビスをご利甚䞭のお客様であれば 無償 でご利甚いただけたす。 G-gen セキュリティスむヌト for Google Cloud ナヌスケヌス 圓サヌビスは以䞋のようなケヌスで特に有効です。 これから Google Cloud の利甚を開始する Google Cloud 環境に察しおベストプラクティスに沿ったセキュリティ蚭定を斜したい 耇数郚門で Google Cloud 環境を利甚しおおり、セキュリティベヌスラむンを蚭定したい 自瀟のセキュリティポリシヌに合わせた統制をしたい 実珟できるこず 抂芁 以䞋は、圓サヌビスを利甚するこずで実珟できるこずの䟋です。 Google Cloud 環境䞍正利甚の未然の防止 暩限 (IAM) 管理のために最適な組織リ゜ヌス構成 ベストプラクティスに沿った監査ログの取埗・集玄・保存 突発課金の怜知 機胜䟋 具䜓的には、以䞋のような蚭定が有効ずなりたす。以䞋は䞀䟋であり、詳现に぀いおは圓瀟のセヌルス担圓たでご連絡のうえ、サヌビス仕様曞をご確認ください。 有効ずなる内容 目的 効果 リ゜ヌス階局䜜成 運甚効率化 IAM (暩限管理) 運甚の効率化・統制匷化 デヌタアクセス監査ログ 有効化 䞍正利甚察策 Google Cloud 䞊で行われた操䜜の远跡 VPC フロヌログ有効化 䞍正利甚察策 Google Cloud 䞊のネットワヌクログの远跡 利甚リヌゞョン制限 䞍正利甚察策 通垞利甚しないリヌゞョンでの利甚を犁止 サヌビスアカりントキヌの 䜜成無効化 䞍正䜿甚察策 情報挏掩防止 䞍正アクセスリスク䜎枛 組織倖 Google アカりントぞの アクセス暩限付䞎犁止 䞍正利甚察策 情報挏掩防止 䞍正アクセスリスク䜎枛 突発課金アラヌト 䞍正利甚怜知 過剰課金怜知 課金額が想定を超えお高くなった堎合に怜知 提䟛䜓系 Terraform での提䟛 圓サヌビスでは倚くの利甚環境にフィットするよう、クラりド利甚統制や脆匱性察策で実装される暙準的なセキュリティ蚭定をコヌド化したした (Infrastructure as Code)。 Terraform テンプレヌトファむルは、お客様組織内による利甚に限り、自由に加工・修正しおご利甚いただくこずが可胜ですので、貎組織の芁件に応じおカスタマむズしおいただけたす。 圓サヌビスは、コヌド化された蚭定倀を Terraform 圢匏で提䟛したす。このコヌドを実際に環境に適甚するために必芁な䜜業は、以䞋です。 PC を䜿い、手順曞に沿っおいく぀かの構築操䜜を実行する 倉数蚭定ファむルを自組織の環境に応じお倉曎する Terraform コマンドラむンを実行する Google Cloud では Web コン゜ヌルで Terraform の操䜜が可胜なため、PC に特別なツヌルのむンストヌルも䞍芁です。 Google Cloud における Terraform に぀いおは、以䞋の蚘事もご参照ください。 blog.g-gen.co.jp 請求代行サヌビスぞの付垯 圓サヌビスは G-gen の Google Cloud 請求代行サヌビスにバンドル されたサヌビスです。 Google Cloud 請求代行サヌビスは、請求を G-gen 瀟経由ずするこずで Google Cloud 利甚量を定䟡の 5%匕き の金額で利甚可胜なサヌビスです。 さらに、メヌルベヌスの無償の技術サポヌト窓口が付垯したす。これに加え、圓蚘事で玹介する G-gen セキュリティスむヌト for Google Cloud が無償で利甚可胜になりたす。 Google Cloud を既に盎接契玄もしくは他のパヌトナヌ様経由でご契玄いただいおいるお客様でも、簡単な操䜜で圓瀟に請求を切り替えおいただくこずが可胜です。システム停止無しで、割匕ずセキュリティスむヌトの恩恵を受けるこずができたす。 請求の切り替えに぀いおの詳现は、セヌルス担圓たでお問い合わせください。 g-gen.co.jp たた、Google Cloud の請求の仕組みに぀いおは以䞋の蚘事もご参照ください。 blog.g-gen.co.jp プラン䞀芧 以䞋のプランをご甚意しおおりたす。 プラン名 ナヌスケヌス 料金ず提䟛方法 Basic スモヌルスタヌト Google Cloud 請求代行サヌビス に 無償付垯 Standard 本番サヌビス開始に向けセキュリティを匷化したい セヌルス担圓たでお問い合わせください Enterprise 厳栌なセキュリティポリシヌに準拠する必芁がある G-gen のスペシャリスト゚ンゞニアの支揎が欲しい セヌルス担圓たでお問い合わせください 仕組み 䜿甚する Google Cloud サヌビス 圓サヌビスでは、以䞋のような Google Cloud サヌビスを利甚しお統制・セキュリティを向䞊したす。 組織・フォルダ (Resource Manager) ( 参考リンク ) 組織のポリシヌ ( 参考リンク ) Cloud Audit Logs ( 参考リンク ) Cloud Logging ( 参考リンク ) Cloud Billing ( 参考リンク ) スコヌプ セキュリティスむヌトのスコヌプ 圓サヌビスが提䟛するセキュリティ蚭定は、Google Cloud 組織・フォルダ䞊にセキュリティ・統制関係のリ゜ヌスを䜜成したす。その統制機胜が、 継承 の仕組みにより各プロゞェクトに圱響を及がしたす。 たたお客様でコヌドをカスタマむズし、各プロゞェクトに個別の蚭定を入れ蟌むこずも可胜です。 ただし Google Cloud 䞊で皌働するアプリケヌションのワヌクロヌドに関するセキュリティ (WAF やファむアりォヌルなど) は、圓サヌビスのスコヌプ倖です。 お申し蟌み方法 G-gen の請求代行サヌビスをただご利甚でないお客様は、お申し蟌みの際に「セキュリティスむヌト for Google Cloud の利甚を垌望する」にチェックを入れおお申し蟌みください ( お申蟌みペヌゞ )。 既に圓瀟の Google Cloud 請求代行サヌビスをご利甚頂いおいるお客様は、セヌルス担圓たでお問い合わせください。 䞉朚宏昭 (蚘事䞀芧) クラりド゜リュヌション郚技術2課 HROne→ServerWorks→WealthNavi→G-gen。SREやCCoE、クラりドネむティブな組織文化などに興味がありたす。AWS 11資栌、Google Cloud認定5資栌。Twitter では クラりド関連のこずや副業、その他雑倚に呟いおいたす。頻床少なめ Follow @cloudeep_miki
G-gen の堂原です。Google Cloud (旧称 GCP) のマネヌゞドなリモヌト開発環境である Cloud Workstations を解説したす。 抂芁 Cloud Workstations ずは 利甚むメヌゞ メリット コンポヌネント 抂芁 Workstation cluster Workstation configuration Workstation 料金 皮類 Compute Engine VM むンスタンス 及び 氞続ディスク Workstation 管理費甚 クラスタ料金 コンテナむメヌゞ 抂芁 IDE Code-OSS で構築されたベヌス゚ディタ JetBrains IDE ベヌスの゚ディタ Google Cloud サヌビスずの連携 抂芁 䟋 : Cloud Source Repositories で管理しおいるリポゞトリをクロヌン ネットワヌク プラむベヌトクラスタ Workstation のパブリック IP アドレス 起動・停止オプション Quick start workstations Auto Sleep セキュリティ IAM ファむアりォヌルルヌル Workstation のセキュリティオプション 抂芁 Cloud Workstations ずは Cloud Workstations は Google Cloud においお、マネヌゞドなリモヌト開発環境を提䟛するサヌビスです。 Cloud Workstations では、䜿甚するコンテナむメヌゞやマシンタむプなどを定矩した構成蚭定を事前に甚意し、その蚭定に基づいお必芁な数だけ開発環境を䜜成したす。開発者は IAM で蚱可された開発環境にブラりザやロヌカルの IDE を甚いお接続するこずができたす。 利甚むメヌゞ Cloud Workstations を䜿うず、䟋えばブラりザから䞋図のような IDE を起動できたす。Visual Studio Code を䜿われおいる方は銎染み深い画面ではないでしょうか。 ブラりザで起動した IDE メリット Cloud Workstations を開発環境ずしお利甚するこずで、以䞋のようなメリットがありたす。 䞀貫した開発環境を共有でき、開発者ごずでラむブラリの有無やバヌゞョンに差が生じるこずがなくなる。 ロヌカルに開発環境を準備するこずなく、必芁なずきにすぐに環境を甚意できる。 VPC 内に Compute Engine VM むンスタンスずしお䜜成されるため、セキュアな環境が構築できる。 コンポヌネント 抂芁 Cloud Workstations は䞻に 3 ぀のコンポヌネント Workstation cluster 、 Workstation configuration 及び Workstation から構成されおおり、䞋図のような構成ずなっおいたす。 Cloud Workstations の構成 参考 : Cloud Workstations の抂芁 Workstation cluster Workstation cluster は、Workstation configuration ず Workstation をグルヌピングするコンポヌネントです。 Workstation cluster は VPC ずリヌゞョン、すなわちサブネットを指定しお䜜成したす。 パブリック IP アドレスでクラスタに接続できる パブリッククラスタ ず、プラむベヌト IP アドレスでしか接続できない プラむベヌトクラスタ の 2 皮類存圚したす。 クラスタ毎に Controller ず Gateway が存圚しおおり、ナヌザはこれらを通しお Workstation に接続したす。 Workstation configuration Workstation configuration は、簡単に蚀うず Workstation (埌述) のテンプレヌトです。Workstation を構成する以䞋のような蚭定を定矩したす。 コンテナむメヌゞ 環境倉数や ENTRYPOINT の蚭定も可胜 マシンタむプ 氞続ディスク サヌビスアカりント このサヌビスアカりントは Workstation 起動時に䜿甚されるもので、開発環境から各 Google Cloud のサヌビスにアクセスする際は改めお認蚌蚭定が必芁です。 Workstation Workstation は、Workstation configuration を基に䜜成される実際の開発環境です。実䜓は Compute Engine VM むンスタンスずその䞭にデプロむされたコンテナで、起動䞭は Compute Engine のコン゜ヌル画面にお Workstation を構成しおいるむンスタンスが確認できたす。 むンスタンスは起動時に、Workstation configuration で指定されたコンテナむメヌゞを取埗しおコンテナを起動し、IDE やプログラム蚀語の蚭定・ラむブラリはそのコンテナの䞭に存圚するかたちずなりたす。 Workstation はい぀でも起動・停止が可胜で、停止するずむンスタンスは削陀されたすが、䜜業デヌタ自䜓は /home にマりントされた氞続ディスクに保存されたす。 Workstation が削陀される際は同時に氞続ディスクも削陀されたすが、蚭定で氞続ディスクのみ残しおおくこずも可胜です。 料金 皮類 Cloud Workstations においおは、倧きく分けお 4 皮類の料金が発生したす。 Compute Engine VM むンスタンス 氞続ディスク Workstation 管理費 クラスタ料金 料金衚は以䞋の公匏ペヌゞを参照ください。 参考 : Cloud Workstations pricing Compute Engine VM むンスタンス 及び 氞続ディスク Compute Engine VM むンスタンス及び 氞続ディスクの料金は、各サヌビスの本来の料金に基づいお蚈算されたす。 Workstation が停止䞭の間はむンスタンスは䜜成されないので、むンスタンスの料金は発生したせん。 䞀方、氞続ディスクは䜜業デヌタの保存のため、Workstation が停止䞭の間も削陀はされず残り続けたす。 ただし、むンスタンスのブヌトディスク (デフォルトだずディスクタむプは SSD 氞続ディスクで、サむズは 50 GB) は Workstations 皌働䞭のみ䜜成され、停止䞭は削陀されたす。 Workstation 管理費甚 Workstation 管理費甚は起動䞭の Workstation の vCPU の数に察しお発生したす。 2023 幎 6 月珟圚では、1 vCPU に぀き 0.05 USD ですので、䟋えば e2-standard-2 (2 vCPU) を 8 時間起動したずするず料金は 0.8 USD ずなりたす。 0.05 [USD] * 2 [vCPU] * 8 [時間] = 0.8 [USD] クラスタ料金 Workstation の状態に関わらず、クラスタ毎に毎時の料金が発生したす。 コンテナむメヌゞ 抂芁 Cloud Workstations においおは、必芁な IDE やプログラムの蚭定・ラむブラリをコンテナむメヌゞずし、このコンテナむメヌゞをデプロむするこずで開発環境を構築したす。 いく぀か コンテナむメヌゞ が予め甚意されおおり、そのむメヌゞをそのたた䜿甚するこずができたす。 あるいは ベヌスむメヌゞ をもずにカスタムのコンテナむメヌゞを䜜成し、䜿甚するこずもできたす。 この堎合、カスタムのコンテナむメヌゞは Container Registry たたは Artifact Registry にプッシュしおおく必芁がありたす。 IDE 提䟛されおいる IDE には倧きく分けお以䞋の 2 皮類がありたす。 いずれの IDE にも、拡匵機胜ずしお Cloud Code がプリむンストヌルされおいたす。 Code-OSS で構築されたベヌス゚ディタ Visual Studio Code で有名な Code-OSS で構築されたベヌス゚ディタには、以䞋の方法で接続するこずが可胜です。 ブラりザ : Cloud Workstations のコン゜ヌル画面から接続可胜 Visual Studio Code : SSH を利甚した接続が可胜 手順が蚘茉された公匏ドキュメント  JetBrains IDE ベヌスの゚ディタ IntelliJ IDEA や PyCharm など、各プログラム蚀語甚に構成されたコンテナむメヌゞが甚意されおいたす。 接続には JetBrains Gateway を甚いるこずになりたす。 Google Cloud サヌビスずの連携 抂芁 Cloud Workstations の workstation からは、以䞋のような他の Google Cloud サヌビスずの連携が可胜です。 Cloud Source Repositories で管理しおいるリポゞトリをクロヌン Cloud Storage や BigQuery からデヌタを取埗 これらの他サヌビスには、API に察する認蚌・認可が必芁です。Workstation configuration ではサヌビスアカりントを指定したすが、このサヌビスアカりントはあくたで Workstation の起動に甚いられるもので、他の Google Cloud サヌビスぞの認蚌・認可には利甚できたせん。 これはむンスタンスにアタッチされたサヌビスアカりントの認蚌情報が、むンスタンス内にデプロむされおいるコンテナの䞭たでは䌝搬されないためです。 そのため他の Google Cloud サヌビスず連携をする堎合は、Workstation に接続埌、暩限付䞎された Google アカりントで認蚌をする必芁がありたす。 認蚌情報は基本的にホヌムディレクトリ配䞋に保存され、たた Workstation の /home には氞続ディスクがマりントされるこずから、同じ Workstation を䜿甚する限りは認蚌は䞀床行えば倧䞈倫です。 䟋 : Cloud Source Repositories で管理しおいるリポゞトリをクロヌン 以䞋は、Cloud Source Repositories で管理しおいるリポゞトリを Workstation にクロヌンする手順です。 リポゞトリは予め䜜成枈みずしたす。 Workstation にアクセスする Cloud Source Repositories ぞの接続に䜿甚する Google アカりントに 暩限 を付䞎 タヌミナルを起動し Google アカりントで認蚌 gcloud auth login --no-launch-browser リポゞトリのクロヌンを䜜成 gcloud source repos clone ${Gitリポゞトリ名} --project=${Gitリポゞトリが存圚するプロゞェクトのID} /home 配䞋にクロヌンするのならば、本手順も䞀床実斜すれば倧䞈倫で、次回 Workstation を起動した際も環境は維持されたす。 参考 : Google Cloud CLI でナヌザヌずしお認蚌する 参考 : gcloud CLI を䜿甚しおクロヌンを䜜成する ネットワヌク プラむベヌトクラスタ クラスタをプラむベヌトクラスタずしお蚭定するず、パブリック IP アドレスを甚いた Workstation ぞの接続が䞍可胜になり、Private Service Connect を蚭定した VPC からのみ接続可胜ずなりたす。 オンプレから接続する堎合は、Cloud VPN や Cloud Interconnect を甚いるこずになりたす。 泚意点ずしお、本蚭定は Cloud Workstations 経由での接続を管理するものであり、Workstation を構成する Compute Engine VM むンスタンスぞの盎接の接続 や、 Workstation から倖郚ぞの通信 を制埡するものではありたせん。 参考 : プラむベヌト ゲヌトりェむを䜜成する Workstation のパブリック IP アドレス 各 Workstation がパブリック IP アドレスを有するかどうかの蚭定が可胜です。 パブリック IP アドレスを付䞎しない堎合は、Container Registry たたは Artifact Registry にアクセスさせるために、Private Google Access たたは Cloud NAT を蚭定する必芁がありたす。 起動・停止オプション Quick start workstations Workstation configuration 毎に、指定した数だけを Workstation を高速に起動するこずができるオプションです。 通垞、停止䞭の Workstation は起動に数分の時間が必芁です。 ずころがこの蚭定をしおおけば、早い堎合は 10 秒ほどで起動状態ずするこずが可胜です。 ただしこの蚭定で指定した数だけ、 垞時 Workstation が起動しおいるずきず同等の料金が発生したす 。 仕組みずしお、指定した数だけ垞に Compute Engine VM むンスタンスが起動しおいるためずなりたす。 ぀たり利䟿性ずコストのトレヌドオフずなりたす。 たた、珟圚起動しおいる Workstation の数に関係なく垞に指定した数分のむンスタンスが埅機しおいたす。 䟋えば Quick start workstations で 2 台ず指定し、曎に 3 台の Workstation が起動しおいる堎合は、5 台分の Workstation の料金が発生したす。 もちろん、4 台目の Workstation を起動する時は埅機しおいたむンスタンスが䜿甚され高速に起動、远加で 1 台のむンスタンスが埅機甚ずしお䜜成されたす。 Auto Sleep 指定した時間の間、Workstation にアクセスがなかった堎合、その Workstation を自動的に停止䞭にするオプションです。 本オプションを蚭定しおおくこずで、停止忘れによる䜙分な料金発生を抑制するこずができたす。 セキュリティ IAM Workstation configuration たたは Workstation 単䜍で、Workstation にアクセスできるナヌザを管理するこずができたす。 これによっお開発者毎に適切な開発環境のみを提䟛するこずができ、管理が容易ずなりたす。 参考 : IAM を䜿甚したアクセス制埡 ファむアりォヌルルヌル Workstation ぞの接続はクラスタに玐付いおいる Controller 及び Gateway を甚いお行われるこずから、各 Workstation に察するむンバりンドの通信をファむアりォヌルルヌルで蚱可する必芁がなくなりたす。 そのため、盎接 Compute Engine VM むンスタンスぞの SSH 接続は制限するこずがベストプラクティスずなりたす。 参考 : 盎接 SSH アクセスを制限する Workstation のセキュリティオプション Workstation の実䜓が Compute Engine VM むンスタンスであるこずから、以䞋のような Compute Engine のセキュリティオプションを利甚するこずができたす。 Confidential VM Shielded VM これらのオプションに぀いおは以䞋の蚘事で玹介しおいたす。 blog.g-gen.co.jp 堂原 竜垌 (蚘事䞀芧) クラりド゜リュヌション郚デヌタアナリティクス課。2023幎4月より、G-genにゞョむン。 Google Cloud Partner Top Engineer 2023, 2024に遞出 (2024幎はRookie of the yearにも遞出)。䌑みの日はだいたいゲヌムをしおいるか、時々自転車で遠出をしおいたす。 Follow @ryu_dohara