株式会社ヘンリー エンジニアブログ

株式会社ヘンリーのエンジニアが技術情報を発信します

4年モノGoogle Cloudプロジェクトで導入して良かった新機能

Google Cloud SRE

株式会社ヘンリーでSREをしている＠Kengo_TODAです。弊社が提供しているレセコン一体型のクラウド電子カルテサービス「Henry」では4年前からGoogle Cloudを採用しております。 Google Cloudは日々進化しており、弊社サービスでもこの4年間で増えた機能を活用することで様々な恩恵を受けてきました。このブログ記事では採用してよかった新機能を3点紹介します。

Cloud Runのstartup CPU boost

以前の記事 Server-Side Kotlinで書かれたCloud Runサービスのコールドスタートレイテンシを短縮するで紹介済みです。JVMで動くKotlinアプリケーションを高速に起動させるのに有効でした。

cloud.google.com

Cloud RunのVPC direct egress

従来Cloud RunがVPC内のサービスと通信するには、Serverless VPC Access connectorというサービスを併用する必要がありました。Serverless VPC Access connectorはマネージドサービスでありほぼメンテナンスフリーなのですが、運用上の課題がありました：

  • 提供されているメトリックが不十分で、スケールアウトのタイミングを判断しにくい
  • インスタンスを複数台起動していても、すべてのインスタンスが予期しないタイミングで一括再起動してしまう

この再起動がネットワーク瞬断の原因となり、ユーザ体験を損なっていました。アプリケーションでのリトライも可能とは言え、コントロール不能なところで不定期に瞬断が発生するのは望ましい状況ではありません。

ところが昨年8月にDirect VPC egress for Cloud Runがアナウンスされ、Serverless VPC Access connectorそのものが不要となりました。

cloud.google.com

制約もいくつかありますが弊社サービスで利用している範囲では大きな課題とはならず、採用の運びとなりました。 執筆時点ではCloud Run functionsの設定はTerraformで行えないことには注意が必要ですが、ネットワークも安定し、費用も若干ではありますが下がり、良いことづくめでした。

Google Groupと連動したCloud SQLの認証

エンジニアが調査やデータマイグレーションを目的としてCloud SQLに接続する場合、Googleアカウントを使った認証が便利です。Cloud SQLのためだけに認証情報を作成・管理することなく、管理の手間を省けるためです。またGoogleアカウントは退職時の削除手続きが社内的に確立されており、安全性という点からも非常に便利なものでした。

cloud.google.com

一方で個々人に対してTerraformで設定をする必要があり、入社時退職時にTerraformでの .tf ファイル変更やその適用が必要となっていました。 これはこれで手間ですし、手順が漏れてアクセスできるべきエンジニアがアクセスできないという状況もありました。

しかしながら昨年12月にCloud SQL IAM group authenticationがアナウンスされ、この問題から開放されました。 入社時にGoogleアカウントをGoogle Groupへ追加することさえ忘れなければ、Terraform側での作業は不要です。

cloud.google.com

はじめにCloud SQLインスタンスの cloudsql.iam_authentication フラグを立てておく必要があります。 次にグループに対して接続権限を付与するのですが、たとえばTerraformを使った設定は以下のようになるでしょう：

locals {
  group_address = "engineers@example.com"
}

resource "google_sql_user" "api_iam_group" {
  instance = google_sql_database_instance.database.name
  name     = local.group_address
  type     = "CLOUD_IAM_GROUP"
}

resource "google_project_iam_member" "cloudsql_client_group" {
  project = google_sql_database_instance.database.project
  role    = "roles/cloudsql.client"
  member  = "group:${local.group_address}"
}

権限設定をよしなにしたら、Cloud SQL Auth Proxyを使ってプロキシを立てます。こちらの手順は公式ドキュメントに詳しく書かれていますので、参照してください。

たとえば localhost:5432 から対象のインスタンスに接続するときの実行例は以下のようになります。 gcloud auth login する必要はありますが、その分Postgresインスタンスのパスワードを管理・取得する必要はなくるのが魅力的です。

$ cloud-sql-proxy --auto-iam-authn $INSTANCE_CONNECTION_NAME

なお cloud-sql-proxy は2バージョンあり、もし --auto-iam-authn オプションが無く --enable_iam_login オプションはあるバージョンをお手元で使っている場合は、先に更新しておくと良いでしょう。

来年もよろしくお願いいたします

クラウドベンダー各社は活発に開発を進めており、新しく必要な機能にもれなく気づくこと・それを応用することはなかなか難しいところがあります。 Google Cloudは新機能をブログを通じて発信することが多いので、まずはそこをwatchしておくと良さそうです。

この記事が筆者による2024年最後のブログ投稿でした。来年も引き続き弊社で利用している技術についての情報を発信してまいりますので、よろしくお願いいたします。