App Engineのapp.yamlでWebサイトを設定する

Google App Engineのapp.yamlファイルは、アプリケーションの設定情報を記述するためのファイルです。
yaml（ヤムル）形式のファイルであり、人間が読みやすい形式で記述されます。
App Engineは、このファイルを参照して、アプリケーションをどのようにデプロイし、どの環境で実行するかを決定します。

たとえば、app.yamlファイルにはアプリケーションのランタイム（つまり、使用するプログラミング言語やバージョン）を指定する項目があります。
また、アプリケーションが依存する外部ライブラリやモジュールを記述することもできます。
さらに、URLマッピングの設定も行うことができ、どのURLパスに対してどのハンドラー（処理プログラム）を割り当てるかを指定できます。

また、app.yamlファイルにはスケーリングの設定も含まれており、アプリケーションのトラフィックに応じてインスタンスを自動的に増減させる方法を指定できます。
これが重要なんですよ。
要するに自分でサーバのスペックみたいなものを自由に調整できるのです。
この仕組みがあることで、アプリケーションが高負荷のときにもスムーズに動作するように調整が行われることになります。

このように、app.yamlファイルは、Google App Engine上でアプリケーションを実行するための重要な設定情報を提供するファイルであり、アプリケーションの動作環境や動作方法を細かく制御する役割を持っているのです。

app.yaml構文の詳説

app.yamlの構文では、URLやファイルパスのパターンを記述する際に、POSIX拡張正規表現を使用するので、使いやすい文字列パターンの指定が可能です。
また、グループ化したパターンを後で参照する機能や、Perl拡張の特殊文字（例:\wや\d）もサポートされています。
要するに、より柔軟で詳細なパターンマッチングができるということです。

ここで、yamlの事例を見てみましょう。


runtime: python312
instance_class: F2
env_variables:
BUCKET_NAME: "example-gcs-bucket"
handlers:
# Matches requests to /images/... to files in static/images/...
- url: /images
static_dir: static/images
- url: /.*
secure: always
redirect_http_response_code: 301
script: auto

App Engine app.yaml リファレンスも参考にして頂けるとよろしいかと。
このyaml構文を詳しく説明すると、次のようになります。


# アプリケーションのランタイム環境を指定します。この場合は Python 3.12 を使用します。
runtime: python312

# インスタンスのクラスを指定します。F2 は、適度なパフォーマンスとリソースを提供するクラスです。
instance_class: F2

# 環境変数を指定します。アプリケーション内で使用する設定値を管理します。
env_variables:
# Google Cloud Storage バケットの名前を指定します。
BUCKET_NAME: "example-gcs-bucket"

# リクエストを処理するためのハンドラーを定義します。
handlers:
# /images で始まるURLパスに対して、静的ディレクトリ static/images 内のファイルをマッピングします。
# 例えば、/images/logo.png は static/images/logo.png にマッピングされます。
- url: /images
static_dir: static/images

# すべてのリクエストに一致させます。/.* はすべての URL パスにマッチする正規表現です。
- url: /.*
# HTTP を HTTPS にリダイレクトします。secure: always は常に HTTPS を使用することを示します。
secure: always
# HTTP リダイレクトのレスポンスコードを 301（永久的なリダイレクト）に設定します。
redirect_http_response_code: 301
# スクリプト自動設定を使用します。script: auto は自動的に適切なスクリプトを選択することを示します。
script: auto

yaml構文を全て学ぼうとするとキリがないでしょう。
しかしApp Engineを使う場合、Googleの公式ドキュメントに記載されている範囲内の情報くらいは把握しておくとラクです。

ランタイムとアプリの要素

app_engine_apis

※必ずしも設定する必要はありません。

これはApp Engineの最新の環境で昔からあるサービスを使いたい場合、この設定を「true」にする、という意味です。
App Engineの中に、「App Engine APIs」という、アプリが利用するためのさまざまな機能やサービスを含むAPIがあります。
2025年1月現在、App Engineの最新のランタイム環境は第2世代ランタイムです。─ ランタイム：アプリケーションが実行される環境のこと ─ 一方、以前からある複数の機能やサービスをまとめて提供する従来のバンドルサービスは、第1世代から存在しています。
このフィールドを「true」に設定することで、従来のバンドルサービスを第2世代ランタイムで使えるということです。

App Engineの従来のバンドルサービスには、次のような機能やツールが含まれています。

Memcache: 高速のキャッシュサービス。アプリのパフォーマンス向上に役立ちます。
Mail: アプリケーションからメールを送信するためのサービス。
XMPP: メッセージング用プロトコルを使って、リアルタイム通信を可能にするサービス。
Blobstore: 大量のデータ（画像や動画など）を保存するためのサービス。
Users: ユーザー認証を簡単に行うためのサービス。

これらのサービスはアプリケーション開発のさまざまなニーズに対応するためのものですね。
第1世代からずっと使われている定番の機能です。
第2世代ランタイムでもこれらを使いたい場合には、上記の説明のように、yamlファイルで設定を「true」にする必要があります。

build_env_variables

※必ずしも設定する必要はありません。

この build_env_variables を使って、ビルド時に必要な情報を整理し、アプリケーションを正しく動作させる設定を行います。
ビルド環境変数とはソフトウェアの構築 ─ しばしば「ビルド」と呼ばれる ─ 中に使用される設定情報です。
例えばデータベースの接続情報やAPIキーなど、ビルド時に必要な情報をここで指定します。
buildpacksはプログラムをビルドして実行可能な形式に変換するツールであり、ソースコードを受け取って、それを実行可能なアプリケーションにします。

つまり、app.yamlファイルの中で build_env_variables を使ってビルド環境変数を定義するというのは、ビルド中に必要な情報を指定しておくということです。
少し事例を見てみましょう。


build_env_variables:
DATABASE_URL: "mysql://user:password@localhost:3306/mydatabase"
API_KEY: "your-api-key"

こうやって書くと、ビルド中に DATABASE_URL や API_KEY といった情報が使用されます。

default_expiration

※必ずしも設定する必要はありません。

アプリケーションにある静的ファイル ─ 画像、CSS、JavaScriptなど ─ のキャッシュ期間を設定し、読み込み速度を改善するための設定です。
キャッシュ期間とは、ファイルがブラウザやサーバーに保存される期間のことです。
この期間中に再度そのファイルにアクセスすると、サーバーからではなくキャッシュから読み込まれます。
するとWebコンテンツの表示が早くなります。

キャッシュ期間は、次のような単位の文字列を付け、数値と組み合わせて設定します。

d は日数（days）を表します。
h は時間（hours）を表します。
m は分（minutes）を表します。
s は秒（seconds）を表します。

例えば「4d 5h」と指定すると、そのファイルのキャッシュ有効期限は最初にリクエストされてから4日と5時間後になります。
次に、app.yamlファイルへdefault_expirationを設定した例を示します。


runtime: python312
default_expiration: "4d 5h"
handlers:
# ...以下略

この設定により、静的ファイルのキャッシュ有効期限が4日と5時間に設定されます。
もしdefault_expirationを省略した場合、本番環境ではサーバーが自動的に有効期限を10分に設定します。

entrypoint

※必ずしも設定する必要はありません。

アプリがどうやって起動するかを細かくコントロールできます。
アプリがHTTPリクエスト（ウェブからのアクセス）を受け取るには、ポート8080でリッスンするウェブサーバーを起動する必要があります。─ ポート8080を使って外部からのアクセスを受け付ける準備をしている状態のことです ─
entrypointには、そのためのコマンドを設定します。

当サイトのようにPythonを使っている場合、entrypointを指定しないと、App Engineが自動的にGunicornというウェブサーバーを起動してくれます。─ 詳しく後述します ─
しかし特別な設定やカスタマイズをしたい場合は、自分でentrypointを指定することができます。
例えば独自のサーバーを起動するコマンドを指定する場合は、app.yamlファイルに以下のように記述します。


entrypoint: python my_server.py

すでに上記で簡単に触れましたが、もしentrypointを明示的に指定しなかった場合でも、Google App Engineが内部的にGunicornというウェブサーバーを使用してアプリを起動し、ポート8080でのリクエストを受け付けるようにしてくれます。
Google App Engineがバックグラウンドで必要な設定を自動で行ってくれるので、ポート8080を手動で設定する必要がないわけです。

Gunicorn（Green Unicorn）は、Pythonで書かれたWSGI（Web Server Gateway Interface）サーバーです。
簡単に言えば、Pythonのウェブアプリケーションを効率的に動かすためのサーバーです。

パフォーマンス: 軽量で、高性能なHTTPサーバーとして知られています。
互換性: 多くのPythonフレームワーク（例：Django、Flaskなど）と互換性があります。
簡単な設定: 設定が比較的簡単で、シンプルなコマンドで起動できます。
スケーラビリティ: 複数のプロセスを使用してリクエストを処理するため、高トラフィックにも対応できます。

例えば、FlaskアプリケーションをGunicornで起動する場合は、以下のようにコマンドを実行します。


gunicorn myapp:app

ここで、myappはPythonファイルの名前、appはFlaskアプリケーションのインスタンス名です。

このように既存の動作や設定を上書きして変更することをオーバーライド（override）と言うこともあります。
App Engineが通常自動的に行う設定を変更して、自分で特別なサーバーの起動方法を指定したい場合に、そのコマンドをentrypointで設定することで、App Engineが通常使う方法を「オーバーライド」することができるということです。

env_variables

※必ずしも設定する必要はありません。

Google App Engine (GAE) では app.yaml でアプリの設定を行います。
このファイルの中で、環境変数を定義できます。
環境変数はプログラムにとって重要な情報を外部から渡すための仕組みです。
例えばある設定値をプログラム内で直接書くのではなく、外部からその値を与えることで、プログラムの再利用性が向上したり、設定の変更が容易になります。

App Engineにおける環境変数は、以下のルールに従って定義されます。

キー（変数名）はアルファベットまたはアンダースコア (_) で始まり、その後に英数字またはアンダースコアが続く必要があります。
例:MY_VARIABLE, ANOTHER_VAR123
ただし、GAE で始まる名前は予約されており、使用できません。

具体的には、次のように app.yaml ファイルに環境変数を定義します。


env_variables:
DJANGO_SETTINGS_MODULE: "myapp.settings"

Python では、定義した環境変数を os.environ という辞書を通じてアクセスできます。
例えば、上記の環境変数を読み取るには次のようにします。


import os

# 環境変数の値を取得
settings_module = os.environ.get('DJANGO_SETTINGS_MODULE')
print(settings_module) # "myapp.settings" と表示されるはずです。

このように環境変数を使うことで、アプリの設定や変更が柔軟に行えるようになります。
つまり、上記のようにapp.yamlファイルに環境変数を定義してからDjangoアプリをPythonで構成、Pythonスクリプト内で os モジュールを使用して環境変数を取得します。
それからApp Engineにアプリをデプロイすると、指定した環境変数の値が読み取られ、"myapp.settings" と表示されるのです。

error_handlers

※必ずしも設定する必要はありません。

エラーハンドラはアプリでエラーが発生したときに表示されるカスタムエラーページを設定するためのものです。
ユーザーがエラーに遭遇したときに見やすくわかりやすいページを提供できます。
設定できる要素として、次のようなものがあります。

error_code: エラーの種類を指定するためのオプションの要素です。次のいずれかを指定できます。; over_quota: アプリがリソースの割り当てを超えたときに表示されます。; timeout: アプリからレスポンスが返される前に時間切れになったときに表示されます。
file: エラーが発生したときに表示される静的ファイル（HTMLファイルなど）のパスを指定します。指定されたファイルが表示され、ユーザーに対してエラーメッセージを提供します。

app.yamlには次のように記述します。


error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html

上記app.yamlだと、次のように動作します。
default_error.html ファイルは、全てのエラーに対するデフォルトのエラーページとして表示されます。
over_quota エラーの場合は、over_quota.html ファイルが表示されます。

注意点として、カスタムエラーページのファイルパスが他の静的ファイルハンドラのパスと重ならないようにすること。
また、カスタムエラーページのデータサイズは10KB未満にする必要があります。
このように設定することで、ユーザーに対してより分かりやすいエラーメッセージを表示することができます。

handlers

※省略可能ではありますが、非常に重要な記述です。

簡単に言うと、URLパターンと処理方法のリストです。
App Engineにおいて特定のURLにアクセスがあったときに、それをどのように処理するかを定義します。

動的コンテンツの処理: ユーザーが特定のURLにアクセスしたとき、プログラムコードを実行して、そのリクエストに応じた内容を返します。
例えば、データベースからの情報を表示するなど。
静的ファイルの提供: 画像や CSS、JavaScriptファイルなど、プログラムコードとは別にアップロードされた静的なファイルをユーザーに提供します。
これらのファイルは、通常、デザインやインタラクティブな要素を実現するために使われます。

つまりhandlersは、どのURLにアクセスがあった場合にどのファイルやプログラムを使って応答するかを決める設定項目になります。
アプリケーションの動作や見た目を柔軟にコントロールするために必要な記述でしょう。

inbound_services

※必ずしも記述する必要はありません。

Google App Engine上でアプリケーションが特定のリクエストを受け取れるようにするための設定です。
これらのサービスを有効にすることで、アプリケーションが適切に動作するようになります。
アプリケーションが受け取るインバウンドリクエストを指定します。─ 外部からのものという意味です。 ─

warmup は特に「ウォームアップリクエスト」を有効にする設定です。
ウォームアップリクエストとは、App Engineが新しいインスタンス（アプリケーションのコピー）を起動する際に、そのインスタンスを事前に準備しておくためのリクエストです。
ユーザーがアクセスする前にインスタンスを温めておき、応答時間を短縮することができます。

inbound_services セクションを使って warmup を有効にするためのコードを見てみましょう。


inbound_services:
- warmup

この設定を行うことで、新しいインスタンスが起動される際に自動的にウォームアップリクエストが送信され、アプリケーションがより迅速に応答できるようになります。

App Engineにおけるインスタンス

App Engine でアプリケーションを実行するために「インスタンス」という単位が使われます。
インスタンスは、実際にアプリケーションコードを実行する環境のことです。
この言葉は非常に重要です。

「inbound_servicesセクションを使ってwarmupを有効にする」説明文中にて、新しいインスタンス（アプリケーションのコピー）という表現を使っています。
この「コピー」という言葉が指しているのは、アプリケーションそのものではなく、アプリケーションの実行環境の複製です。
つまり、同じアプリケーションコードを実行する複数の環境（インスタンス）が存在するという意味です。

アプリケーションが人気で多くのユーザーがアクセスする場合、一つのインスタンスだけでは対応できません。
そのため、App Engine は必要に応じて新しいインスタンスを起動し、負荷を分散させます。
この仕組みがあることで、アクセスが増えてもアプリケーションが速く、安定して動作するようになります。

Googleのものに限らず、クラウドに関連する用語は専門的に感じられることがあります。
ここで、デプロイとインスタンスについておさらいしてみましょう。

デプロイ: ユーザーがアプリケーションを App Engine にアップロードすることを意味します。
インスタンス: デプロイされたアプリケーションを実行するための複数の環境です。
これが「コピー」と言われることもあります。

App Engineについて小話をしてみますね？
例えば、あなたが大人気のレストランを経営しているとしましょう。
一つのキッチン（インスタンス）だけでは全てのお客様に迅速に料理を提供するのが難しいため、複数のキッチン（インスタンス）を用意します。
それぞれのキッチンでは同じメニュー（アプリケーションコード）が作られますが、複数のキッチンがあることで多くのお客様に対応できるようになります。
こんな感じで、App Engine では負荷に応じて新しいインスタンス（キッチン）を起動し、アプリケーションがスムーズに動作するようにしているのです。

instance_class

※省略できますが、明示的に指定しておいたほうが良いでしょう。

ここは「オンプレミスとクラウド」の違いがはっきりと分かる設定ですね。
オンプレミスは、データやシステムを自分の会社のサーバーに置くこと。
クラウドは、インターネットを通じて他の会社のサーバーにデータやシステムを置くこと。
自宅保管と貸し倉庫の違いに似ていますね。

インスタンスクラスは、アプリケーションを動かすためのサーバーの性能や容量を決める設定です。
まるでコンピュータのスペックを選ぶようなものです。
サービスのスケーリングは、アプリケーションのアクセス量に応じてサーバーの数や性能を自動的に増減させる仕組みです。
では、これらの基礎を把握したうえで、App Engineでどのような設定ができるのか、見ていきます。

自動スケーリング

自動スケーリングはアクセスが増えたら自動でサーバーを増やし、減ったらサーバーを減らす仕組みです。
次のようなインスタンスクラスがあります。

F1: 基本的な性能。デフォルトの設定です。
F2: F1の2倍の性能。
F4: F1の4倍の性能。
F4_1G: F4と同じ性能ですが、メモリ容量が多い。

必要に応じて、automatic_scaling要素を使います。
インスタンスの数、レイテンシ（遅延）、同時接続の最小数と最大数などを調整することができます。

把握しておいたほうが良い事柄として、インスタンスクラスをF2以上に設定している場合の設定があるでしょう。
max_concurrent_requests（同時接続数）をデフォルトの10より大きい値に設定するとインスタンスを最適化できます。
この最適な値を見つけるためには、少しずつ値を増やしてアプリケーションのパフォーマンスを監視する必要があります。

基本スケーリングと手動スケーリング

これらは一定の数のサーバーを使う方法です。

基本スケーリング: 一定の数のサーバーを使い、必要に応じて少し自動で調整します。
手動スケーリング: サーバーの数を固定して使います。

インスタンスクラスには次のような種類があります。

B1: 基本的な性能。
B2: B1の2倍の性能。デフォルト設定です。
B4: B1の4倍の性能。
B4_1G: B4と同じ性能ですが、メモリ容量が多い。
B8: B1の8倍の性能。

基本スケーリングや手動スケーリングを使う場合は、それぞれの要素（basic_scaling または manual_scaling）を指定する必要があります。

App Engineに初めて設定する場合は、デフォルトのF1やB2を試してみて、必要に応じて変更するのが良いです。アクセスが変動する場合は自動スケーリング、一定の負荷がかかる場合は基本スケーリングや手動スケーリングを選びましょう。

F1とB1の違い

Fはフロントエンド、Bはバックエンドを意味します。

F（フロントエンド）

Fクラスのインスタンスは、短時間で素早くスケールアップやスケールダウンが必要なアプリケーション向けです。
例えばウェブサイトのフロントエンドや、ユーザーの操作に即座に応じる必要があるサービスに向いています。
基本的にアクセスが増減するタイミングが予測しにくい場合に適しています。

B（バックエンド）

Bクラスのインスタンスは、比較的長時間稼働し続けるアプリケーション向けです。
例えばデータベースのバックエンドや、一定の作業を継続的に行う必要があるサービスに向いています。
アクセスが安定している場合や、特定の時間に負荷が集中する場合に適しています。

基礎的設定であるF1とB1について見てみましょう。

F1: 主に短時間のレスポンスを求められる用途向け; 自動スケーリングでアクセス量に応じて柔軟に対応
B1: 一定時間以上の継続的な稼働を求められる用途向け; 手動スケーリングや基本スケーリングで安定した性能を提供

例えば、人気のイベントなどが開催されているときにアクセスが急増するウェブサイトの場合はF1が適しています。
一方、バックグラウンドでデータを処理し続けるアプリケーションの場合はB1が適しています。

個人サイト領域であれば、静的なWebサイトという形でホスティングすることが多いでしょう。
特に初期のころはF1インスタンスクラスで十分なことが多いです。
自動スケーリングでF1を使用することで、アクセスが増えても柔軟に対応できます。
一方この設定を省略した場合、GoogleはデフォルトでF1を使用します。
つまり、特に指定しなくてもF1が使われるので、基本的には問題ないと言ってよいです。
必要があれば後でインスタンスクラスを変更することもできるので、まずはF1で試してみて、様子を見ながら調整するのが一般的です。

runtime

※これは必須の記述です

ここいらへんで、おさらいの時間を作ります。
私がTwitterを見ている限り、コードを書いた上での個人サイトといえば「HTMLとレンタルサーバー」というキーワードが圧倒的大多数です。
例えばGCPなどクラウドを用いてホスティングしている人は、本当にごくわずかでした。─ 普段から開発系のSEアカウント等は除いて ─

App Engine（アプリケーションエンジン）はGoogleが提供しているクラウドサービスの一つで、ウェブアプリケーションをホスティングするためのプラットフォームです。
app.yamlは、このApp Engineにデプロイするアプリケーションの設定ファイルです。
このファイルには、アプリケーションの動作環境や各種設定を記述します。

まとめると次のようになります。

App Engine: Googleのウェブアプリケーションホスティングサービス。
app.yamlファイル: アプリケーションの設定ファイル。
ランタイム環境（runtime）: アプリケーションを実行するためのプログラミング言語とそのバージョン。
例（runtime: python312）: Python 3.12の言語でアプリケーションを動かす設定。─ 他の言語でも良いです。後述します。 ─

「runtime」という項目は、「ランタイム環境」を指定するためのものです。
ランタイム環境とは、アプリケーションを実行するためのプログラミング言語やそのバージョンのことを指します。
たとえば、以下のように設定します。


runtime: python312

この例では、「python312」と指定しています。
これは、「Python 3.12」というバージョンのプログラミング言語を使用することを意味しています。
つまり、App Engine上でこのアプリケーションを実行する際に、Python 3.12が使われるということです。

App Engineにはさまざまなランタイム環境があります。
よく聞く代表例は次のようなものがありますね。

Python: python310、python311
Java: java8、java11
Node.js: nodejs16、nodejs18
Go: go116、go118
PHP: php74、php80
Ruby: ruby30、ruby31

これらのランタイム環境を使用して、対応するプログラミング言語とバージョンでアプリケーションを実行することができます。
設定ファイルに指定することで、App Engineが自動的に適切なランタイムを使用してアプリケーションをデプロイ・実行する仕組みです。

service

※サービスを作成する場合には必須です。default サービスでは省略できます。

App Engineではウェブアプリケーションを「サービス」として管理します。
このサービスには名前を付ける必要があります。
サービスの設定は、アプリケーションの異なる部分を分けて管理するのに役立つでしょう。
とりあえず一つのサービスを「default」として設定できます。
この場合、特に名前を付ける必要はありません。
サービス名やバージョン名には次のようなルールがあります。

使える文字: 数字（0-9）、英字（a-z、A-Z）、ハイフン（-）
長さの制限: VERSION-dot-SERVICE-dot-PROJECT_ID という形式で、全体の長さが63文字以内にする必要があります。
ハイフンの位置: 名前の先頭や末尾にハイフンは使えません。
名前の一意性: 各サービスとバージョンには一意の名前を付ける必要があります。同じ名前を使ってはいけません。

app.yamlには次のように書きます。


service: service-name

この例では、サービス名として「service-name」を設定しています。
この名前が他のサービス名やバージョン名と重複しないようにする必要があります。

service_account

※必ずしも設定する必要はありません。

特定のバージョンに関連付けられたサービスアカウントを指定するために使われます。
このサービスアカウントは、他のGoogle Cloudサービスにアクセスする際に使われます。
サービスアカウントを指定することで、アプリケーションが適切な権限でGoogle Cloudサービスにアクセスできるようになります。
この設定はオプションですが、セキュリティや権限管理の観点から非常に重要です。
例えば、データベースへのアクセスや、他のAPIを利用する際に必要な認証情報として機能します。
形式は次の通りです。

[SERVICE_ACCOUNT_NAME]@[PROJECT_ID]
.iam.gserviceaccount.com

SERVICE_ACCOUNT_NAME：サービスアカウントの名前
PROJECT_ID：プロジェクトのID

yamlには次のように指定します。


service_account: my-service-account@my-project-id.iam.gserviceaccount.com

この例では、「my-service-account」という名前のサービスアカウントを「my-project-id」というプロジェクトに関連付けています。

vpc_access_connector

※必ずしも設定する必要はありません。

vpc_access_connector（PCアクセスコネクタ）は、アプリケーションが仮想プライベートクラウド（VPC）ネットワークの内部リソースにアクセスできるようにするための設定です。サーバーレス環境（例えばGoogle CloudのApp Engine）で、この設定を使ってネットワークリソースにリクエストを送信することができます。設定項目は次の通りです。

name

これは、サーバーレスVPCアクセスコネクタの完全修飾名です。
形式は "projects/PROJECT_ID/locations/REGION/
connectors/CONNECTOR_NAME" です。

PROJECT_ID: プロジェクトのID
REGION: リージョン（地域）
CONNECTOR_NAME: コネクタの名前

yamlでは、次のように書きます。


vpc_access_connector:
  name: "projects/my-project/locations/us-central1/connectors/my-connector"

egress_setting

これはオプションで省略可能なんですよね。
デフォルトは private-ranges-only です。
設定値は次の通りです。

private-ranges-only (デフォルト): 内部IPアドレスへのリクエストはVPCネットワークに送信され、外部IPアドレスへのリクエストは公共のインターネットに送信されます。
all-traffic: すべてのリクエストがVPCネットワークに送信されます。

yamlには、次のように書きます。


vpc_access_connector:
  name: "projects/my-project/locations/us-central1/connectors/my-connector"
  egress_setting: all-traffic

要は vpc_access_connector の設定を使うことで、サーバーレスアプリケーションがVPCネットワークの内部リソースにアクセスできるようになるのです。
特に内部システムやデータベースにアクセスする場合に役立ちます。

ハンドラ要素

ここで、いったんまとめてみましょう。
Google App Engine の app.yaml ファイルは、アプリケーションの設定を管理する重要なファイルです。
このファイルには、アプリケーションがどのように動作するか、どのURLがどのように処理されるかなどが記載されています。

handlers 要素: handlers 要素は、URLパターンとそれに対する処理方法のリストを提供します。
例えば、「/home」というURLが来たときに、それをどう処理するかを決めるのがこの要素です。
アプリケーションコード: アプリケーションのコードを実行したり、画像、CSS、JavaScriptなどの静的ファイルを提供する役割があります。
パターンの評価: app.yaml ファイルの記述は上から下へ順に評価されます。
例えば、最初に一致するURLパターンが見つかったら、それがリクエストの処理に使用されます。

改めてapp.yaml の具体例を見てみます。


handlers:
- url: /static
static_dir: static
- url: /.*
script: auto

この例では、2つのハンドラーが定義されています。

静的ファイルハンドラー: url: /static は、URLが "/static" で始まる場合に、static ディレクトリ内の静的ファイルを提供することを指定しています。
スクリプトハンドラー: url: /.* は、上記以外のすべてのURLに対して、アプリケーションコードを実行することを指定しています。; script: auto は、自動的にスクリプトを実行するよう指定しています。

では、各構文の説明へ戻ります。

auth_fail_action

※必ずしも記述する必要はありません。

アプリケーションにログインが必要な場合に、ユーザーがログインしていない時にどのような動作をするかを指定する設定です。
この設定は次の2つの値のいずれかを持つことができます。

redirect（リダイレクト）:: これはデフォルトの動作です。; ユーザーがログインしていない場合、GoogleのログインページまたはOpenID認証を使用している場合は /_ah/login_required ページにリダイレクトされます。; ログイン後、ユーザーは元のアプリケーションURLにリダイレクトされます。
unauthorized（認証されていない）:: ユーザーのリクエストを拒否し、HTTP 401ステータスコードとエラーメッセージを返します。; これにより、ユーザーはログインページにリダイレクトされず、直接アクセスが拒否されます。

具体的に言うと、例えば auth_fail_action: unauthorized を設定した場合、ログインが必要なページにユーザーがログインしていない状態でアクセスすると、ログインページにリダイレクトする代わりに、アクセスが拒否されます（HTTP 401エラーが返されます）。
このように、auth_fail_action を使うことで、アプリケーションが特定のディレクトリ（例えば /profile/ ）にログインを要求するか、または（例えば /admin/ ）に管理者のログインを要求するなどの動作をカスタマイズすることができます。

expiration

※必ずしも記述する必要はありません。

静的ファイル（例えば画像、スタイルシート、JavaScriptファイルなど）をウェブプロキシやウェブブラウザでどれくらいの間キャッシュに保存するかを決める設定項目です。
キャッシュに保存すると、ユーザーが次回そのファイルをリクエストする際に、インターネットからではなく、ローカルのキャッシュから読み込むため、読み込み速度が速くなります。

設定方法

expirationの設定は、数値と単位をスペースで区切って指定します。
単位には次の4種類があります。

d : 日数
h : 時間
m : 分
s : 秒

例えば、4d 5h と指定すると、キャッシュの有効期限はそのファイルが最初にリクエストされてから 4日と5時間後になります。

コードの具体例

1d : 1日（24時間）
12h : 12時間
30m : 30分
3600s : 3600秒（1時間）

もし expiration を省略した場合、アプリケーションの default_expiration（デフォルトの有効期限設定）が使用されます。
これで指定がない場合でも適切な有効期限が設定されるようになります。

PWA（プログレッシブ・ウェブ・アプリ）の場合、サービスワーカーを使ってキャッシュを管理することが一般的です。
そのため、app.yamlファイルのexpiration設定を省略しても問題ありません。
サービスワーカーはキャッシュの制御を詳細に行えるため、アプリケーションのパフォーマンスを向上させることができます。

http_headers

※必ずしも記述する必要はありません。

レスポンスにカスタムのHTTPヘッダーを追加するための設定です。
特定のヘッダー情報をクライアント（例えばブラウザ）に送ることができます。

HTTPヘッダーは、クライアント（例えばブラウザ）とサーバー間の通信におけるメタデータのようなもので、通信の挙動や設定を制御する役割を持ちます。
次のような状況で役立ちますが、各々にちょっと説明が必要ですね。

セキュリティ強化

特定のHTTPヘッダーを追加することで、セキュリティを向上させることができます。
例えば、Content-Security-Policy (CSP) ヘッダーを追加することで、クロスサイトスクリプティング（XSS）攻撃や他の潜在的な脆弱性からの防御が強化されます。
CSP を YAML 設定ファイルに追加する方法として、次のようなコードが考えられます。


handlers:
- url: /images
static_dir: static/images
http_headers:
Content-Security-Policy: "default-src 'self'; img-src 'self' https://example.com; script-src 'self' 'unsafe-inline'"
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...

この設定では、次のポリシーを適用しています。

default-src 'self': デフォルトのすべてのコンテンツソースを自身のオリジンに限定します。
img-src 'self' https://example.com: 画像のソースを自身のオリジンおよび https://example.com に限定します。
script-src 'self' 'unsafe-inline': スクリプトのソースを自身のオリジンおよびインラインスクリプトに限定します。
注意: unsafe-inline の使用は避けるべきですが、特定の状況で必要な場合に使用されます

こうすることで、外部ソースからの不正なスクリプト実行やコンテンツの読み込みを防ぐことができます。
セキュリティポリシーは、必要に応じてさらにカスタマイズできます。
例えば、スタイルシートやフォントに関するポリシーを追加する場合、次のようなコードが考えられます。


http_headers:
Content-Security-Policy: "default-src 'self'; img-src 'self' https://example.com; script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline'; font-src 'self'"

整理しましょう。
このコードは HTTP レスポンスヘッダーに Content-Security-Policy (CSP) を設定しています。
CSP ヘッダーは、ブラウザにどのリソースをどのソースから読み込むべきかを指示し、ウェブアプリケーションのセキュリティを強化します。
各ポリシーの意味を説明してみますね。

default-src 'self': デフォルトのソースポリシーを指定します。
上述のコードの場合、自身のオリジン（ドメイン）からのリソースのみを許可しています。
この指定により、他のソースからのコンテンツ読み込みがデフォルトで禁止されます。
img-src 'self' https://example.com: 画像のソースポリシーを指定します。
上述のコードの場合、自身のオリジンおよび https://example.com からの画像のみを許可しています。
他のソースからの画像読み込みは許可されません。
script-src 'self' 'unsafe-inline': スクリプトのソースポリシーを指定します。
上述のコードの場合、自身のオリジンおよびインラインスクリプトを許可しています。
ただし、unsafe-inline を許可することはセキュリティリスクがあるため、可能な限り避けるべきです。
style-src 'self' 'unsafe-inline': スタイルシートのソースポリシーを指定します。
上述のコードの場合、自身のオリジンおよびインラインスタイルを許可しています。
インラインスタイルもまたセキュリティリスクがあるため、注意が必要です。
font-src 'self': フォントのソースポリシーを指定します。
上述のコードの場合、自身のオリジンからのフォントのみを許可しています。
他のソースからのフォント読み込みは許可されません。

このように、各リソースに対して許可するソースを細かく設定することで、ウェブサイトが外部の不正なリソースを読み込むことを防ぎ、セキュリティを強化します。
必要に応じて、さらにポリシーをカスタマイズすることも可能です。
より包括的なセキュリティ強化が可能になりますね。

コンテンツネゴシエーション

Vary ヘッダーを使用して、クライアントがどのようなコンテンツを受け入れられるかを指定することができます。
コンテンツネゴシエーションとは、サーバーが異なるクライアントの要求に応じて最適なコンテンツを提供する仕組みです。
クライアントがどのコンテンツを受け入れられるかを指定し、サーバーが適切なバージョンのコンテンツを返すことができます。

Vary ヘッダーは、レスポンスがどのリクエストヘッダーに基づいて異なるかをサーバーがクライアントに伝えるために使用されます。
たとえば、ブラウザが画像をリクエストする場合、異なる解像度やフォーマット（WebP, PNGなど）に応じて最適な画像を返すことができます。

Vary ヘッダーを YAML 設定ファイルに追加する方法を書いてみます。


handlers:
- url: /images
static_dir: static/images
http_headers:
Vary: Accept, Accept-Encoding
X-Foo-Header: foo
X-Bar-Header: bar value
Content-Security-Policy: "default-src 'self'; img-src 'self' https://example.com; script-src 'self' 'unsafe-inline'"
# ...

この設定では、次の Vary ヘッダーがレスポンスに追加されます。

Accept: クライアントがどのMIMEタイプを受け入れられるかを指定します。
Accept-Encoding: クライアントがどの圧縮エンコーディングを受け入れられるかを指定します。

これでサーバーはクライアントの要求に応じて最適なコンテンツを提供し、効率的な通信が可能になります。
ここでのポイントは、Vary ヘッダーにリクエストヘッダー（例: Accept や Accept-Encoding）を指定することで、サーバーがそのリクエストヘッダーを考慮してレスポンスを生成することを示していることです。

例えば、クライアントが次のようなリクエストを送信した場合はどうなるでしょう。


GET /images/sample.png HTTP/1.1
Host: example.com
Accept: image/webp,image/apng,image/*,*/*
Accept-Encoding: gzip, deflate, br

サーバーはリクエストの Accept ヘッダーを基に、クライアントが受け入れ可能な画像形式（例: WebP 形式）を選び、Accept-Encoding ヘッダーを基に適切な圧縮形式（例: gzip 圧縮）を選びます。

Vary ヘッダーは、そのリクエストヘッダーに基づいてレスポンスを変える必要があることを示しているので、実際のレスポンス生成においてどのリソースを返すかはサーバー側のロジックによるものです。
そのため、Vary ヘッダー自体には具体的な MIME タイプやエンコーディング形式を書かなくても良いのです。

具体的な例として、以下のようにサーバーがリクエストに応じて異なるレスポンスを返すシナリオを考えてみます。

クライアントが Accept: image/webp を送信した場合
サーバーは WebP 形式の画像を gzip 圧縮して返します。
クライアントが Accept: image/png を送信した場合
サーバーは PNG 形式の画像を gzip 圧縮して返します。

このように、Vary ヘッダーはサーバーがどのリクエストヘッダーに基づいて異なるレスポンスを生成するかを指定するためのものです。
ここではapp engineのyamlに限定して書いているため、少々分かりにくいかもしれません。
mdn web docsの「開発者向けのウェブ技術 > HTTP > コンテンツネゴシエーション」に詳しい資料があります。

キャッシュ制御

Cache-Control ヘッダーを追加することで、ブラウザや他のクライアントがリソースをどのようにキャッシュするかを制御し、リソースの効率的な管理とパフォーマンスの最適化が可能になります。
YAML 設定ファイルに Cache-Control ヘッダーを追加する方法の例を見てみます。


handlers:
- url: /images
static_dir: static/images
http_headers:
Cache-Control: public, max-age=3600
Vary: Accept, Accept-Encoding
Content-Security-Policy: "default-src 'self'; img-src 'self' https://example.com; script-src 'self' 'unsafe-inline'"
# ...

この設定では、次の Cache-Control ヘッダーがレスポンスに追加されます。

public: リソースがパブリックキャッシュ（例：CDN）にキャッシュされることを許可します。
max-age=3600: リソースがキャッシュされる最大時間（秒単位）を指定します。この例では、1時間（3600秒）です。

この設定により、クライアントはリソースを1時間キャッシュし、その間同じリソースを再リクエストする際にはキャッシュされたコピーを使用します。
これでサーバーの負荷が軽減され、ユーザーエクスペリエンスが向上します。

キャッシュ制御の設定は、必要に応じてさらにカスタマイズできます。
変更されたリソースをすぐに反映させるために no-cache を使用する場合、次のようなコードが考えられます。


http_headers:
Cache-Control: no-cache

これでクライアントは毎回サーバーに対して新鮮なコピーをリクエストし、キャッシュを使用しません。

次の設定は/images URLに対応する静的ファイルディレクトリにアクセスする場合に、いくつかのカスタムHTTPヘッダーを追加するものです。


handlers:
- url: /images
static_dir: static/images
http_headers:
X-Foo-Header: foo
X-Bar-Header: bar value
vary: Accept-Encoding
# ...

この例では、以下のHTTPヘッダーがレスポンスに追加されます。

X-Foo-Header に foo
X-Bar-Header に bar value
vary に Accept-Encoding

CORS サポート

CORS（クロスオリジンリソースシェアリング）は、異なるドメインからのリソースアクセスを許可する仕組みです。
この機能が特に役立つのは、たとえば、あるアプリケーションが自分のドメインとは異なるドメインにあるリソースにアクセスしたい場合です。
ゲームアプリとアセットの例で詳しく説明しましょう。

たとえば、ゲームアプリ（mygame.uc.r.appspot.com）があります。
このアプリは自分のドメインにホストされているリソース（画像、音声ファイルなど）だけでなく、別のドメイン（myassets.uc.r.appspot.com）にホストされているアセット（リソース）にもアクセスしたい場合があります。
ここでは、Google App Engineを使って、/images URLパスにリクエストがあった場合に静的ファイルを返す静的ファイルハンドラを設定し、その際にCORSのレスポンスヘッダーを返す方法について説明します。


handlers:
- url: /images
static_dir: static/images
http_headers:
Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com
# ...

この設定では、次のことが行われます。

/images パスに対するリクエストには、static/images ディレクトリ内の静的ファイルが返されます。
http_headers セクションで指定されたHTTPヘッダーがレスポンスに追加されます。

CORSのレスポンスヘッダーについては、次の説明となるでしょう。

Access-Control-Allow-Origin: https://mygame.uc.r.appspot.com ヘッダーは、mygame.uc.r.appspot.com ドメインからのリソースアクセスを許可します。
これで、ゲームアプリがアセットをホストしている別のドメインからリソースにアクセスできるようになります。
もし全てのドメインからのアクセスを許可したい場合は、ワイルドカード（*）を使用することができます。

この設定の意味は、mygame.uc.r.appspot.com からのリクエストに対して static/images ディレクトリ内のリソースを返すとともに、CORSを利用して他のドメインからのリソースアクセスを許可するということです。
この設定方法が必要な理由は、セキュリティの観点から、通常ブラウザは異なるドメイン間でのリソース共有を制限しているためです。
CORSを設定することで、特定のドメインからのアクセスを許可することができます。

サイトマップ

全ページをリスト化したサイトマップも用意していますが、けっこうなページ数があります。
下記の「カテゴリー分けサイトマップ」のほうが使いやすいでしょう。

アナザーエデン関連ページ・サイトマップ

アナザーエデンの強敵戦やストーリーコンテンツのリスト、お勧めバッジなどを掲載したコーナーです。
期間限定のない普通のRPGですので、初心者でも安心して続けていけるゲームとなっています。
もっとも重要なグラスタについては、場所別に網羅した表があります。

個人サイトのホスティングとコンテンツ作成

個人でウェブサイトを作るにはどうすればいいか。
HTML・CSS・JavaScriptの書き方はもちろん、無料かつ広告なしでホームページを作る方法を掲載したコーナーです。
Webデザインやレイアウトについても書いてあります。

魚釣りなどアウトドアのエリア

ゲームとパソコンだけじゃなく、アウトドアも趣味なんです。
このコーナーでは魚釣りの記録とか、魚料理のレシピ、はたまたサイクリングなどなど。
アウトドアに関連するコンテンツが詰め込まれています。