はじめのProfessional Cloud Developer認定取得講座⑦Cloud Run から Redis へ接続する方法、CI/CDパイプライン最適化戦略、数百万件のGCSオブジェクトを削除する最適化ガイドを説明します！

クラウド

Professional Cloud Developer 認定試験では、単なるサービス理解だけでなく「実践的な設計力」と「最適化の判断力」が問われます。

本記事では、Cloud Run から Redis（Memorystore）への高効率な接続方法、CI/CD パイプラインの高速化戦略、そして数百万件規模の GCS オブジェクト削除の最適化手法について解説します。いずれも、パフォーマンス・運用効率・コストの観点で重要なテーマであり、実務にも直結する内容です。

試験対策としてだけでなく、現場で使える設計力を身につけるためのポイントを整理していきます。

是非、最後までご覧いただけると嬉しいです。

Cloud Run から Redis へ接続する方法

Cloud RunからVPC内のリソースへアクセスする手法は進化しました。最新の「ダイレクト VPC エグレス」を利用することで、従来のコネクタによるボトルネックを解消し、真のサーバーレスなネットワーク統合が可能になります。

1. ダイレクト VPC エグレスとは？

従来の「サーバーレス VPC アクセス コネクタ」は、VPC内に小さなVMインスタンスを立てて橋渡しをする仕組みでした。これに対し、ダイレクト VPC エグレスは、Cloud Runのインスタンスが直接VPCネットワーク内にインターフェースを持つような仕組みです。

主なメリット

  • 低レイテンシ：中間パス（コネクタ）を介さないため、Redisへの応答速度が向上します。
  • 運用の簡素化：コネクタの管理やスケーリングの設定、IPアドレス範囲の予約が不要になります。
  • 高スループット：ネットワーク性能が向上し、大規模なトラフィックにも柔軟に対応できます。

2. Memorystore for Redis の準備

まず、アクセス先となるRedisインスタンスを作成します。

  1. VPC ネットワーク：Cloud Runを接続する予定のVPCネットワークを選択します。
  2. 接続モード：「プライベート サービス アクセス」を選択します。事前に作成していない場合は、この手順で作成します。
  3. IPアドレス：作成後に割り当てられるプライベートIPアドレス（例: 10.x.x.x）をメモしておきます。

3. Cloud Run でダイレクト VPC エグレスを設定する

Cloud Run サービスをデプロイ、または更新する際に以下のネットワーク設定を行います。

手順

  1. Cloud Run の「コンテナをデプロイ」画面を開きます。
  2. [ネットワーキング] タブを選択します。
  3. [アウトバウンド トラフィック用の VPC に接続する]を有効にし、[VPC に直接トラフィックを送信する]でVPCとサブネットを選択します。

4. アプリケーションからの接続実装

ダイレクト VPC エグレスを設定すると、Cloud Run上のコードからは、あたかも同じネットワーク内にRedisがあるかのようにプライベートIPで接続できます。

Pythonによる接続例

<Python>

import redis
import os

# Memorystore のプライベートIPを環境変数などで管理
REDIS_IP = os.environ.get('REDIS_IP', '10.0.0.3')
REDIS_PORT = 6379

def connect_redis():
    # ダイレクト VPC エグレスにより、このプライベートIPへ直接到達可能
    r = redis.StrictRedis(host=REDIS_IP, port=REDIS_PORT, decode_responses=True)
    r.set('status', 'connected via Direct VPC Egress')
    return r.get('status')

5. 重要な注意点

IAM権限

Cloud Runの実行サービスアカウント（デフォルトでは Compute Engine のデフォルトサービスアカウント）に、VPCネットワークを操作するための適切な権限は通常自動で付与されますが、カスタムサービスアカウントを使用する場合は注意が必要です。

リージョンの整合性

Cloud Run サービス、VPCサブネット、および Memorystore インスタンスは、パフォーマンスと接続の安定性のために、同じリージョンに配置することを強く推奨します。

セキュリティグループとファイアウォール

VPC内のファイアウォールルールで、Cloud Runが使用するサブネットのIP範囲から、Redisのポート（6379）への下り（Egress）および上り（Ingress）トラフィックが許可されていることを確認してください。

Cloud Run から Redis へ接続する方法のまとめ

ダイレクト VPC エグレスにより、Cloud Run から VPC 内リソースへ直接接続でき、従来のコネクタ方式の課題を解消できます。
これにより、低レイテンシ・高スループット・運用簡素化という3つの大きなメリットが得られます。
Memorystore for Redis はプライベート IP を用いて、同一ネットワーク内のようにシンプルに接続可能です。
設定は Cloud Run 側のネットワーク構成変更が中心で、アプリケーションコードの変更は最小限で済みます。
ただし、IAM・リージョン統一・ファイアウォール設定といった基本要件の確認が安定運用の鍵となります。

CI/CDパイプライン最適化戦略

Cloud Runへのデプロイは、大きく分けて「ビルド（イメージ作成）」と「デプロイ（インスタンス起動）」の2つのフェーズがあります。この両方を最適化することで、デプロイ時間は劇的に短縮されます。

1. ビルドフェーズの最適化（Cloud Build）

多くの場合、デプロイ時間の大部分を占めるのはコンテナイメージのビルドです。ここをいかに「サボらせるか」が鍵となります。

キャッシュを最大限に活用する

ビルドを毎回ゼロから行うのは時間の無駄です。そのため、以下の方法を活用します。

Dockerレイヤーキャッシュ（--cache-from）の活用

Cloud BuildでDockerイメージをビルドする際、--cache-from オプションを使うことで、以前のビルドで作成されたイメージをキャッシュとして参照し、変更のないレイヤーの再構築をスキップできます。ビルド前にArtifact Registryから既存イメージをpullし、そのレイヤーをキャッシュソースとして指定するのが基本的なパターンです。

ビルドマシンのスペックを上げる

Cloud Buildのデフォルトの仮想マシン（e2-standard-2：2 vCPU / 8GB RAM相当）は、大規模なアプリケーションのビルドには力不足な場合があります。

  • 高スペックマシンの指定：cloudbuild.yaml の options 内で machineType を指定することで、並列コンパイルなどが高速化されます。指定できる値はCloud Build専用の列挙値である e2-highcpu-8、e2-highcpu-32 などです。

不要なファイルをアップロードしない (.gcloudignore)

ローカルからソースを送信してビルドする場合、node_modules やバイナリ、Git履歴などの巨大なファイルを送信していませんか？

  • .gcloudignore ファイルを適切に設定し、ビルドコンテキストを最小限に抑えることで、アップロード時間を数秒〜数十秒短縮できます。

2. コンテナイメージの軽量化

イメージが重ければ、Artifact Registryへのプッシュも、Cloud Runへのプルも遅くなります。

マルチステージビルドの徹底

ビルドに必要なツール（SDKやコンパイラ）を最終的な実行イメージに含めてはいけません。

  • ビルド用ステージ：コンパイルや静的ファイルの生成を行う。
  • 実行用ステージ：dist ファイルやバイナリだけを、軽量なベースイメージ（alpine や distroless）にコピーする。

これにより、イメージサイズが数百MBから数十MBに削減され、デプロイ時の「イメージ取得時間」が圧倒的に短縮されます。

3. デプロイフェーズの最適化（Cloud Run）

イメージが完成した後の「リリース」プロセスの工夫です。

「ソースからデプロイ」より「イメージをデプロイ」

gcloud run deploy --source は便利ですが、内部で毎回 Cloud Build を動かします。

  • CI/CD（GitHub Actionsなど）で先にビルドを完了させ、Cloud Runには完成したイメージのURLを渡して gcloud run deploy --image を実行する方が、プロセスの分離と高速化が図れます。

同一リージョン内でのパイプライン構築

Artifact Registry と Cloud Run は必ず同じリージョンに配置してください。リージョンを跨ぐイメージの転送は、ネットワーク遅延とコストの増加を招きます。

起動時 CPU ブーストの活用

これはデプロイそのものの時間ではありませんが、デプロイ後に「新しいリビジョンがリクエストを受け付けられるようになるまで」の時間を短縮します。

  • Startup CPU Boost：インスタンスの起動中だけ一時的にCPU割り当てを増やす機能です。JavaやNode.jsなど、起動時の初期化処理が重いアプリケーションでは、Ready状態になるまでの時間が大幅に改善されます。

CI/CDパイプライン最適化戦略のまとめ

CI/CDの高速化は、ビルドとデプロイの両面から最適化することで大きな効果を発揮します。特にCloud Buildではキャッシュ活用とマシンスペック調整がビルド時間短縮の鍵となります。加えて、コンテナイメージの軽量化により転送・起動時間も大幅に改善できます。
デプロイではイメージベースの運用とリージョン統一が効率化に直結します。これらを組み合わせることで、安定かつ高速なCI/CDパイプラインを実現できます。

数百万件のGCSオブジェクトを削除する最適化ガイド

数百万件のオブジェクトを削除する処理は、一見シンプルに見えて、実際には時間・コスト・運用負荷のすべてに影響する重要な作業です。
「削除が終わらない」「API制限に引っかかる」「思わぬコストが発生する」といった問題に直面した経験がある方も多いのではないでしょうか。

本記事では、Google Cloud Storage（GCS）における大量オブジェクト削除を効率化するために、用途別に最適な3つの戦略を解説します。

1. 究極の「全消し」：バケットごと削除する

もし、バケット内のすべてのデータが不要で、バケット名自体にもこだわりがない（あるいは後で作り直せばいい）のであれば、バケットそのものを削除するのが圧倒的に最速です。

なぜ速いのか？

個別のオブジェクトを1つずつ消していくのではなく、Google Cloudのバックエンドでコンテナごと破棄するため、ユーザー側のオーバーヘッドがほぼゼロになります。

  • 実行方法
    gcloud storage rm --recursive gs://[BUCKET_NAME]
  • 注意点：削除したバケット名は、その後しばらく（数分〜数時間）再利用できない場合があります。また、誤って削除すると二度と復元できません。

2. 最も「賢い」方法：オブジェクト ライフサイクル管理 (OLM)

バケットは残したい、あるいは特定の条件（例：作成から30日経過したもの）に合うものだけを消したい場合に、最も推奨される方法です。

メカニズム

バケットに「ライフサイクル ルール」を設定すると、Google Cloud側がバックグラウンドで非同期にオブジェクトをスキャンし、条件に一致するものを自動的に削除します。

OLMのメリット

  • 管理コストゼロ：スクリプトを監視したり、タイムアウトを気にしたりする必要がありません。
  • APIコストの節約：大量削除リクエストを送る必要がないため、オペレーション料金を抑えられる可能性があります。
  • 非同期実行：ルールを設定した後は、寝て待つだけです。
⚠️ 注意
OLMは即時実行ではありません。ルールを適用してから実際にオブジェクトが消え始めるまでに、通常 24時間以内 のタイムラグが発生します。急ぎでない場合は、これが「正解」です。

3. 「今すぐ」消したい：gcloud storage による並列削除

「明日の朝まで待てない、今すぐ消したい」という場合は、Google Cloud SDKの最新コマンド gcloud storage を使用します。従来の gsutil よりも大幅に高速化されています。

並列処理の力

数百万件を消す際、逐次処理（1つずつ消す）は厳禁です。gcloud storage はデフォルトで並列処理を強力にサポートしています。

  • 基本コマンド
    gcloud storage rm -r gs://[BUCKET_NAME]/[PREFIX]/**
  • 高速化のコツ：gcloud は内部的にマルチスレッド/マルチプロセスを最適化して実行するため、ユーザーは複雑なフラグを考えずとも、従来の gsutil -m rm 以上のパフォーマンスを享受できます。

比較表：どの方法を選ぶべきか？

特徴バケット削除ライフサイクル管理 (OLM)gcloud storage rm
実行速度最速（一瞬でリクエスト完了）低（完了まで最大24h+）中〜高（並列数に依存）
手間最小設定のみスクリプトの実行・監視が必要
コスト無料無料（オペレーション課金なし）APIリクエスト課金あり
柔軟性全消しのみ期間やプレフィックスで指定可自由自在
推奨シーンバケットごと不要な時大量のオブジェクトを定常的に消す時特定のサブフォルダを即座に消す時

実践的なアドバイスと注意点

1. 削除前に「シミュレーション」を

数百万件を消す際、一番怖いのは「消してはいけないものまで消すこと」です。

2. IAM権限の確認

削除を実行するアカウントには、storage.objects.delete 権限（「ストレージ オブジェクト作成者」や「ストレージ管理者」ロールなど）が必要です。OLMを設定する場合は、バケットの編集権限が必要になります。

3. バージョニングの落とし穴

バケットでオブジェクトのバージョニングが有効になっている場合、単純に削除しただけでは「非現行バージョン」としてデータが残り続け、ストレージ料金が発生します。

  • OLMを使用して「非現行バージョンの保持期間」を設定し、過去のバージョンも確実に消し去るようにしましょう。

数百万件のGCSオブジェクトを削除する最適化ガイドのまとめ

大量のGCSオブジェクト削除では、目的に応じた手法の選択が重要です。バケットごと不要な場合は削除が最速ですが、実際の処理は非同期で進行します。
継続的な削除には、運用負荷の低いライフサイクル管理（OLM）が最適です。即時削除が必要な場合は、gcloud storage の並列処理を活用することで効率化できます。
これらを使い分けることで、時間・コスト・リスクを最小限に抑えた運用が実現できます。

まとめ

今回は、下記３点について説明しました。

  1. Cloud Run から Redis へ接続する方法
  2. CI/CDパイプライン最適化戦略
  3. 数百万件のGCSオブジェクトを削除する最適化ガイド

本記事で解説した3つのテーマはいずれも、「クラウドをどう使いこなすか」という本質に直結しています。ネットワーク設計ではシンプルかつ高速な接続、CI/CDでは継続的な改善による効率化、大量データ処理では目的に応じた最適手法の選択が重要です。これらを適切に組み合わせることで、高性能かつ運用しやすいシステムを実現できます。Professional Cloud Developer に求められるのは、個々の知識ではなく、状況に応じた最適解を導く力です。本記事の内容をもとに、ぜひ実務での設計力向上につなげてください。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログで！

スポンサーリンク
タイトルとURLをコピーしました