はじめのProfessional Cloud Developer認定取得講座⑤Cloud Run パフォーマンス改善ガイド、Cloud Run と Firestore を安定させる設計、Google Cloud エミュレータ活用術を説明します！

クラウド

Professional Cloud Developer 試験では、クラウド環境で安定して動作するアーキテクチャを設計する能力が求められます。

特に重要になるのが、次の3つのテーマです。

  • Cloud Run のスケーリング特性を理解したパフォーマンス最適化
  • Firestore を利用した効率的なデータ取得とキャッシュ設計
  • Google Cloud エミュレータを活用したローカル開発とテスト戦略

これらは試験対策として重要であるだけでなく、実際のクラウドネイティブ開発でも頻繁に登場する設計パターンです。

この記事では、Professional Cloud Developer を目指す開発者向けに、Google Cloud におけるパフォーマンス設計・データアクセス最適化・ローカル開発環境のベストプラクティスを整理します。

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

Cloud Run パフォーマンス改善ガイド

Cloud Run はサーバーレス環境であり、リクエスト数に応じて自動的にインスタンスが増減（オートスケーリング）します。しかし、この「魔法のようなスケーリング」も、適切な設定がなければ高負荷時に牙を剥きます。

1. オートスケーリングの仕組みを正しく理解する

Cloud Run のスケーリングは、「1インスタンスあたりの最大同時実行数（Concurrency）」に基づいています。

  • スケーリングのトリガー：既存のインスタンスが受け入れ可能なリクエストの上限に達すると、Cloud Run は新しいインスタンスを起動しようとします。
  • 遅延の原因：新しいインスタンスが起動する際の「コールドスタート」が積み重なると、全体のレスポンスタイムが悪化します。
  • エラーの原因：インスタンスの起動が追いつかない、あるいは上限設定によって新しいインスタンスが作れない場合、システムはリクエストを拒否し、エラーを返します。

2. トラブルシューティングの4つのステップ

高負荷時のボトルネックを特定するために、以下の順序で確認を行います。

ステップ A：最大インスタンス数（max-instances）の確認

最も単純かつ頻度の高い原因は、max-instances（最大インスタンス数） の制限に達していることです。

  • 症状：Cloud Monitoring で「Instance Count」が設定した上限に張り付いており、同時に 429 (Too Many Requests) または 503 (Service Unavailable) エラーが発生している。
  • 対策：インフラのクォータ（プロジェクト全体のCPU制限など）や、バックエンド（データベース）の許容負荷を確認した上で、max-instances の値を引き上げます。

ステップ B：同時実行数（Concurrency）の最適化

デフォルトの最大同時実行数は「80」ですが、これがアプリケーションの特性に合っていない場合があります。

  • 同時実行数が多すぎる場合：1つのインスタンスで処理するリクエストが多すぎて、CPUやメモリを奪い合い、結果として個々のリクエストが遅くなります（スラッシング）。
  • 同時実行数が少なすぎる場合：すぐに新しいインスタンスが起動してしまい、コールドスタートの発生頻度が高まり、全体のレイテンシが増大します。
  • 対策：負荷テストを行い、1インスタンスが最も効率よく処理できるスルーセットを見極めて設定します。

ステップ C：CPU割り当て設定の再考

Cloud Run には、CPUがいつ割り当てられるかという2つのモードがあります。

  1. リクエストの処理中のみ CPU を割り当てる（デフォルト）：リクエストがない間はCPUがほぼゼロになるため、バックグラウンド処理がある場合にエラーや遅延の原因となります。
  2. CPU を常に割り当てる：インスタンスが起動している間は常にCPUパワーを確保します。起動時のオーバーヘッドを減らし、高負荷時の安定性を高めるのに有効です。

ステップ D：起動時間の短縮（コールドスタート対策）

高負荷時にインスタンスが次々と立ち上がる際、アプリケーションの初期化コードが重いと、リクエストがタイムアウトします。

＜対策＞
Startup CPU Boost：インスタンス起動時のみ一時的にCPUを増強し、初期化を高速化します。
最小インスタンス数（min-instances）：常に数台を待機（ウォームアップ）させておくことで、急激なスパイクに対応します。

3. 試験で狙われる「エラーコード」の識別

PCD試験では、エラーコードから原因を特定させる問題が出ます。

  • HTTP 429：Cloud Run 側のスケーリング上限（max-instances）に達した。
  • HTTP 503：インスタンスの起動が間に合わない、あるいはコンテナがクラッシュしてリクエストをさばけていない。
  • HTTP 504 (Gateway Timeout)：アプリケーションが request-timeout 設定内にレスポンスを返せなかった。

Cloud Run パフォーマンス改善ガイドのまとめ

Cloud Run のパフォーマンスを安定させるには、オートスケーリングの仕組みを理解し、適切な設定を行うことが重要です。特に max-instances や 同時実行数（Concurrency） の設定は、スケーリング挙動とレスポンスタイムに大きく影響します。
また、CPU割り当てモードや min-instances、Startup CPU Boost を活用することで、コールドスタートによる遅延を軽減できます。高負荷時のトラブルシューティングでは、Cloud Monitoring のメトリクスを確認しながらボトルネックを特定することが重要です。
さらに、HTTP 429・503・504 などのエラーコードから原因を判断できるようにしておくことが、Professional Cloud Developer 試験対策としても重要なポイントです。

Cloud Run と Firestore を安定させる設計

小売システムにおいて、ユーザーが製品一覧をスクロールする際、バックエンドでは大量のデータが動きます。今回のトラブル例は、「一度に大量のドキュメントをメモリ上に展開しようとしたこと」と、「頻繁すぎるデータベースアクセス」に着目して解説します。

1. メモリ不足の真犯人：全件取得とオフセットの罠

Cloud Runのインスタンスがメモリ上限を超える主な理由は、Firestoreから取得した大量のドキュメント（JSONオブジェクト）をリスト化してメモリに保持しようとするためです。

  • 問題点：数千、数万の製品データを get() で一度に取得すると、コンテナ内のヒープメモリが瞬時に圧迫されます。
  • オフセット（Offset）の弊害：offset(1000).limit(20) のようなクエリは、最初の1000件をスキップするために内部でデータを読み取ります。これはパフォーマンスを低下させるだけでなく、読み取りコストも発生させます。

2. 解決策：クエリカーソル（Query Cursors）によるページネーション

Firestoreのベストプラクティスにおいて、大量のデータを安全に読み取るための標準的な手法がクエリカーソルです。

  • 仕組み：前回のクエリの最後のドキュメント（または特定のフィールド値）を「しおり」として使用し、次のリクエストはその「しおり」の直後から開始します。
  • 実装のメリット
    • 定数時間のメモリ使用量：常に limit(20) など少量のデータのみをメモリに読み込むため、製品数が増えてもCloud Runのメモリ使用量は一定に保たれます。
    • コスト最適化：スキップされたドキュメントに対する読み取り料金が発生しません。
  • 主要メソッド：startAt(), startAfter(), endAt(), endBefore()。
試験のポイント：「ページネーションの実装」を問われたら、offset ではなく startAfter（カーソル）を選択するのがPCDとしての正解です。

3. Firestore クエリ数を減らすためのキャッシング戦略

Firestoreへのアクセス集中を抑えるには、データの鮮度要件に応じたキャッシュレイヤーの導入が不可欠です。

  • Memorystore (Redis) の導入：製品一覧のように「頻繁に閲覧されるが、秒単位での更新は不要」なデータは、Redisにキャッシュします。Cloud RunからFirestoreへ行く前にRedisを確認することで、Firestoreの読み取りコストと負荷を劇的に削減できます。
  • Cloud CDN の活用：Web UIが製品一覧を表示する場合、APIレスポンスをエッジサーバー（CDN）でキャッシュすることで、Cloud Run自体へのトラフィックも軽減できます。

4. Firestore ベストプラクティスの適用

ドキュメントの設計レベルでも最適化が必要です。

  • 必要なフィールドのみを返す：製品一覧画面で「製品の詳細説明」や「高解像度画像データ」が必要ない場合、それらを別コレクションに分ける（非正規化）か、クライアントに返す前にフィルタリングして、メモリ転送量を最小限にします。
  • 読み取りの統合：Firestoreの SnapshotListener はリアルタイム性に優れますが、高トラフィックのWebサイトではコネクション数とコストが増大します。今回のケースのような「閲覧」メインの用途では、明示的な get() 要請に基づく取得の方が適しています。

Cloud Run と Firestore を安定させる設計のまとめ

Cloud Run と Firestore を安定して運用するには、大量データの取得方法を適切に設計することが重要です。特に Firestore の 全件取得や offset を使ったページネーションは、メモリ消費や読み取りコストの増加につながるため注意が必要です。その代わりに クエリカーソル（startAfter など）を用いたページネーションを採用することで、メモリ使用量とパフォーマンスを安定させることができます。
さらに、Memorystore（Redis）や Cloud CDN を活用したキャッシュ戦略を導入することで、Firestore へのアクセス負荷を大幅に削減できます。
これらのベストプラクティスを理解し、効率的なデータ取得とキャッシュ設計を行うことが、Professional Cloud Developer に求められる重要なポイントです。

Google Cloud エミュレータ活用術

モダンなクラウド開発では、デプロイして初めて動作確認をする「デプロイ・アンド・プレイ」は非効率です。Google Cloud が提供するエミュレータ群を活用することで、ローカル環境で本番に近い挙動を再現し、「シフトレフト（テストの早期化）」を実現します。

1. Bigtable エミュレータ：高額コストをゼロにする

Bigtable は非常に強力な NoSQL ですが、開発初期段階でインスタンスを立てっぱなしにすると、コストが跳ね上がります。

  • エミュレータの利点：インメモリで動作するため、実際のノード費用が発生しません。スキーマ設計（テーブル構造やインデックスの考え方）の妥当性を、コストを気にせず何度でも検証できます。
  • セットアップ：gcloud components install bigtable-emulator で導入し、起動後は環境変数を設定するだけでアプリケーションから接続可能です。
  • 注意点：エミュレータはインメモリであるため、再起動するとデータは消去されます。テストデータの投入スクリプトもセットで用意するのが PCD 的な作法です。

2. Pub/Sub エミュレータ：メッセージングのデバッグを加速

非同期通信のデバッグは、メッセージの順序や Ack/Nack の挙動など、複雑になりがちです。

  • ローカル完結の検証：ピックの作成、サブスクリプションの購読、メッセージのパブリッシュをすべてローカル PC 内で完結させられます。インターネット接続すら不要なため、オフライン開発も可能です。
  • 環境変数の魔法：アプリケーション側で PUBSUB_EMULATOR_HOST 変数を検知するように実装しておけば、コードを一行も変えずに「ローカル接続」と「クラウド接続」を切り替えられます。
  • 試験のポイント：サブスクライバーのプッシュ先（Push Endpoint）をローカルでテストする場合、localhost へのルーティング設定が必要になる点に注意しましょう。

3. Cloud Run のローカル開発：コンテナの一貫性を保つ

Cloud Run へのデプロイを繰り返すと、ビルド時間とデプロイ待ち時間が開発者の集中力を削ぎます。

  • Cloud Code の活用：VS Code や IntelliJ のプラグインである「Cloud Code」を使用すると、ローカルのミニクラスター（minikube 等）上で Cloud Run と同等の環境をエミュレートできます。
  • ホットリロード：コードを保存するたびにコンテナが自動でビルド・再起動されるため、ブラウザを確認しながらの迅速な UI/API 修正が可能です。
  • コンテナ化の恩恵：ローカルで動いたコンテナは、そのまま Google Cloud 上でも動きます。環境差異による「私のマシンでは動いた」という言い訳を過去のものにします。

4. 戦略：最小限の機能（MVP）をどう実装するか？

開発スピードを最大化するためのベストプラクティスを整理します。

  1. 疎結合の維持：Pub/Sub を介してサービス間を繋ぐことで、個々のマイクロサービスを独立してテスト可能にします。
  2. Testcontainers の利用：Java (Spring Boot) 等の開発では、Testcontainers ライブラリを使用して、テストコード実行時だけ Docker 上でエミュレータを立ち上げ、終わったら捨てるという「クリーンなテスト」が推奨されます。
  3. モック vs エミュレータ：単体テストは「モック」、統合テストは「エミュレータ」という使い分けを明確にします。エミュレータは実際の API 挙動を模倣するため、より信頼性の高いテストが可能です。

Google Cloud エミュレータ活用術のまとめ

Google Cloud のエミュレータを活用することで、クラウドへデプロイする前にローカル環境で本番に近い動作検証を行うことができます。Bigtable や Pub/Sub のエミュレータを利用すれば、コストをかけずにデータモデルやメッセージング処理のテストが可能になります。また、Cloud Run のローカル開発環境を整えることで、コンテナの挙動を確認しながら効率的にアプリケーションを改善できます。
さらに、エミュレータを活用したテスト戦略を取り入れることで、サービス間の疎結合を保ちながら開発スピードを高めることができます。
このようなローカル検証とテストの自動化を取り入れることが、Professional Cloud Developer に求められるモダンな開発スタイルです。

まとめ

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

  1. Cloud Run パフォーマンス改善ガイド
  2. Cloud Run と Firestore を安定させる設計
  3. Google Cloud エミュレータ活用術

今回の記事では、Professional Cloud Developer として理解しておくべき Cloud Run とデータ処理設計の重要ポイントを整理しました。

Cloud Run のパフォーマンスを安定させるためには、オートスケーリングの仕組みを理解し、max-instances や Concurrency、CPU割り当てなどの設定を適切に調整することが重要です。また、高負荷時にはエラーコードや Cloud Monitoring のメトリクスを確認し、ボトルネックを特定する力も求められます。

さらに、Firestore を利用するアプリケーションでは、大量データを安全に処理するためにクエリカーソルによるページネーションやキャッシュ戦略を導入することが重要です。これにより、メモリ使用量や読み取りコストを最適化できます。

加えて、Google Cloud エミュレータを活用することで、Bigtable や Pub/Sub などのサービスをローカル環境で検証でき、開発スピードと品質を向上させることが可能になります。

Professional Cloud Developer 試験では、これらのサービスを単体で理解するだけでなく、パフォーマンス・コスト・開発効率を考慮した最適な設計を選択できるかが問われます。今回紹介したベストプラクティスを整理しておくことが、試験合格と実務でのクラウド開発力向上につながるでしょう。

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

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

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