Google App Engine

解決する課題

• サーバー（VM）や OS のパッチ・スケール設定を管理したくないが、Web アプリ／API を本番運用したい
• 負荷に応じて自動でスケールしてほしい（アクセス急増時の増設、アイドル時の縮退）
• インフラ構築よりアプリのコードに集中したい（PaaS で土台を任せる）
• HTTPS 公開・ロードバランシング・バージョン管理・段階的リリースを標準で備えた基盤が欲しい

App Engine は、コードと最小限の設定ファイルを渡すだけでこれらを引き受ける PaaS です。AWS で言えば Elastic Beanstalk に近く、「環境を作ってコードを上げると裏でよしなに動く」という体験を提供します。

主要概念と用語

• アプリケーション: プロジェクトに 1 つ作成する App Engine の最上位の入れ物。リージョンは作成時に決まり、後から変更できない
• サービス（Service）: アプリを構成する論理単位。マイクロサービスごとに分割でき、既定の default サービスが必ず存在する
• バージョン（Version）: サービスをデプロイするたびに作られるスナップショット。複数バージョンを同居させ、トラフィックを割り当てられる
• インスタンス（Instance）: バージョンを実際に処理する実行単位。負荷に応じて自動増減する
• 標準環境（Standard）: 言語ごとのサンドボックスで動く環境。起動が速く、アクセスが無ければインスタンス0まで縮退できる
• フレキシブル環境（Flexible）: コンテナ（Docker）として Compute Engine 上で動く環境。任意のランタイムや常駐プロセスに対応し自由度が高い
• app.yaml: ランタイム・スケーリング・環境変数などを定義する設定ファイル。これを置いてデプロイするのが基本操作
• トラフィック分割（Traffic Splitting）: 複数バージョンへ割合でリクエストを振り分け、カナリアリリースや A/B テストを行う仕組み

仕様・制限・クォータ

• 環境は 2 種類: 標準環境は対応言語が限定される代わりに高速起動・ゼロスケール、フレキシブル環境はコンテナで自由だが常時最低1インスタンス稼働が前提になりやすい
• リージョンは固定: アプリ作成時に選んだリージョンは変更不可。移したい場合は新規プロジェクトで作り直す
• リクエストタイムアウト: 標準環境はオンライン（HTTP）リクエストに比較的短いタイムアウト上限があり、長時間処理には向かない。フレキシブル環境はより長い処理を許容しやすい
• ローカルディスクは一時的: インスタンスのファイルシステムは永続化されない前提で設計する（状態は Cloud Storage / データベースへ）
• 同時接続数・インスタンス数・デプロイ回数などにクォータがあり、必要に応じて引き上げ申請ができる

数値は環境・言語・時期で変動するため、最新の上限は公式ドキュメントで確認してください。

内部の仕組み

App Engine では、デプロイした各バージョンに対してリクエスト量に応じたインスタンスを Google 側が自動でプロビジョニングします。利用者はサーバーの台数やスケールの仕組みを意識せず、app.yaml でスケーリング方針（自動・基本・手動）を宣言するだけです。

標準環境は、各言語向けに最適化されたサンドボックス上でコードを実行します。インスタンス起動が速く、トラフィックが無ければ0 までスケールインするため、アイドル時のコストを抑えられます。一方のフレキシブル環境は、アプリを Docker コンテナにパッケージし、内部的には Compute Engine の VM 上で動かします。任意のライブラリやシステムパッケージを使える反面、起動はやや遅く、最低1インスタンスが常駐しがちです。

複数バージョンを同居させられるのも特徴で、新バージョンへトラフィックを段階的に移すことで、無停止のカナリアリリースや即時ロールバックが可能です。

設計パターン / ベストプラクティス

• ステートレス設計を徹底する。セッションやファイルはインスタンスに持たせず、Cloud Storage・Memorystore・データベースへ外出しする
• 速い起動とゼロスケールが欲しければ標準環境、特殊なランタイムや常駐処理が要るならフレキシブル環境を選ぶ
• サービス分割でマイクロサービス化し、デプロイ単位とスケール特性を分ける
• バージョン＋トラフィック分割でカナリアリリースとロールバックを運用に組み込む
• コールドスタートが問題なら最小インスタンス数を1以上に設定し、不要時はコスト優先で0に戻す
• 重い非同期処理は App Engine 内で抱えず、Cloud Tasks / Pub/Sub などに逃がす

運用・監視

• Cloud Monitoring / Cloud Logging でリクエスト数・レイテンシ・インスタンス数・エラー率を監視。標準出力／標準エラーのログは自動収集される
• デプロイ後に問題が出たら、直前バージョンへトラフィックを戻すだけでロールバックできる
• 古いバージョンは課金やクォータの観点から不要分を削除して整理する
• 起動失敗時は、app.yaml のランタイム指定・依存関係・エントリポイント・リッスンポートを確認する

コスト

• 課金は基本的に**インスタンスの稼働時間（インスタンス時間）**に基づく。標準環境はゼロスケールによりアイドル時の課金を抑えやすい
• フレキシブル環境は裏で VM が動くため、最低稼働分の費用が発生しやすく、常時アクセスのある常駐型に向く
• アウトバウンド通信・関連サービス（Cloud Storage、データベース等）の利用料は別途かかる
• コスト最適化の要点は、最小／最大インスタンス数の調整と不要バージョンの削除

具体的な料金は変動するため、見積もりは公式の料金ページと料金計算ツールで確認してください。

セキュリティ

• アプリには専用のサービスアカウントを割り当て、付与する IAM 権限は最小限にする（AWS の IAM ロール相当）。鍵ファイルのハードコードは避ける
• シークレットはSecret Manager で管理し、環境変数やコードへ直書きしない
• 公開範囲は IAM や Identity-Aware Proxy（IAP） で制御し、社内向けアプリは認証必須にする
• 送信ファイアウォールルールや Serverless VPC Access を用い、内部リソースへのアクセス経路を絞る

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: インフラ管理を Google に委ねることで運用負荷を下げ、コードとデプロイに集中できる。バージョン管理とトラフィック分割により、安全な変更とロールバックを標準で運用に組み込める

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) アプリを作成（リージョンは後から変更不可。最初に決める）
gcloud app create --region=asia-northeast1

# 2) app.yaml を用意（例: Python 標準環境・自動スケーリング）
#    runtime: python312
#    instance_class: F2
#    automatic_scaling:
#      min_instances: 0
#      max_instances: 10

# 3) コードと app.yaml があるディレクトリでデプロイ
gcloud app deploy app.yaml

# 4) 新バージョンへ段階的にトラフィックを移す（カナリア 10%）
gcloud app services set-traffic default \
  --splits=VERSION_NEW=0.1,VERSION_OLD=0.9 \
  --migrate=false

# 5) ブラウザでアプリを開く / ログを確認
gcloud app browse
gcloud app logs tail -s default