Google App Engineで広告なしサイト作成

Google App Engineは、あなたのWebサイトやアプリをインターネット上に簡単に公開できるサービス。
プログラムを書いたら、Googleのサーバーで動かせるようにしてくれます。
個人サイトを作りたいと思ったら、大きく分けて次の2つが考えられます。

既存のホームページ作成サービスを使う
HTMLを初めとするソースコードが書ける場合、クラウドを使う選択肢が出てくる

ここでお話しするのは、主に後者です。

Google App Engineの仕組み

上記でGoogleのサーバーと書いたけど、App Engineはサーバーとはまた少し違うんですよね。

App Engineアプリの設定ファイル: App Engineを使うアプリには、app.yamlという設定ファイルが必要です。
これはアプリの動作を指示する重要なファイルです。
runtimeエントリ: app.yamlファイルには、少なくとも「runtime（実行環境）」という設定が必要です。
これはどのプログラミング言語を使うかを指定します。
各サービスの設定: アプリが複数の機能（サービス）を持っている場合、各サービスに専用のapp.yamlファイルが必要です。
これがそのサービスの設定を行います。
defaultサービスの設定: まず最初にアプリの「default（デフォルト）サービス」に対してapp.yamlファイルを作成します。
その後、追加のサービスに対してもそれぞれapp.yamlファイルを作成します。

runtime（実行環境）

アプリケーションを実行するために必要な特定の設定や環境のことです。
これには使うプログラミング言語やフレームワークが含まれます。

上述しましたが、App Engineは通常のサーバーとは少し違います。
普通のサーバーは自分で設定や管理をする必要がありますが、App EngineはGoogleが提供する「マネージドサービス」と呼ばれるもので、サーバーの設定や管理をGoogleが行います。
ユーザーはアプリケーションのコードと設定ファイルを用意するだけで、App Engineが自動的にリソースを割り当ててアプリケーションを実行してくれます。

簡単に言うと、runtimeを使って「私はこの言語（例えばPythonやJava）でアプリを動かします」とApp Engineに教えることで、App Engineがその言語に合った環境を準備してくれるのです。

Pythonランタイムでウェブサイトをホスティングする

App Engine では、pythonランタイムを指定しても静的ウェブサイト（HTMLファイル、CSS、JavaScriptなど）をホスティングできます。
私のWebサイトはこの仕組みを使っています。
App Engineは柔軟なアプリケーションホスティングプラットフォームと表現することも可能ですよね。

静的ファイルのホスティング: App Engine は、静的ファイル（HTML、CSS、JavaScript、画像など）を効率的に配信する機能があります。; app.yaml ファイルで静的ファイルのディレクトリを指定することで、これらのファイルをアプリの一部として公開できます。
ディフォルトのサービス提供: Pythonランタイムを指定しても、特に Pythonコードが含まれていない場合、静的ファイルをそのまま提供できます。; つまり、Pythonランタイムを使っているという指定は、特定のサーバーサイドコードを実行するためのものであり、静的コンテンツの提供に影響を与えません。

ここで、シンプルな app.yaml の例を示してみましょう。


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

この構成では、/static ディレクトリ内のファイルを静的コンテンツとして配信し、その他のURLに対しては自動的にPythonスクリプトを実行します。
このようにして、App Engine を使用して静的ウェブサイトを簡単にホスティングすることが可能です。

このサイトの場合、Pythonランタイムを指定しているものの、実際には静的なファイルだけを公開している状態です。
Pythonのコードが実行されていないため ─ 例外はあるけれど ─、Pythonランタイムの設定は単に環境として存在しているだけとなっているんですよね。
つまり、App EngineではPythonランタイムを指定することで、必要な場合にPythonコードを実行するための環境が用意されますが、実際に提供されているのは静的なファイルということになります。
この設定の利点は、将来的に動的なPythonコードを追加したい場合にすぐ対応できる柔軟性がある点です。

App Engine の静的ファイル配信機能

App Engine は静的ファイルを効率的かつ安全に配信することができるのです。

キャッシュ機能: 静的ファイルは一度リクエストされると、App Engine がそれをキャッシュに保存します。
次回のリクエスト時には、キャッシュから高速に配信するため、ロード時間が短縮されます。
圧縮: App Engine は静的ファイルを自動的に圧縮し、配信の効率を上げます。
ユーザーのデータ転送量が減り、ページの読み込み速度が向上します。
CDN（コンテンツ配信ネットワーク）統合: App Engine は Google の広範なCDNネットワークを活用して、世界中のユーザーに対して低遅延でファイルを配信します。
地理的に遠くにいるユーザーにも高速にコンテンツを提供できます。
セキュリティ: 静的ファイルはHTTPS（SSL/TLS）で配信されるため、データの盗聴や改ざんから守られます。
自動スケーリング: トラフィックが急増してもApp Engine が自動的にリソースをスケーリングして対応します。
大量のアクセスにも耐えられるようになります。
静的ファイルのマッピング: app.yaml ファイルで静的ファイルのディレクトリを指定することで、特定のURLパスにファイルを簡単にマッピングできます。
たとえば、 /static フォルダ内のすべてのファイルを /static/* のURLでアクセスできるように設定することができます。

個人サイト向けのapp.yaml設定

App Engineの「app.yaml」ファイルは、Google App Engineアプリケーションのデプロイや動作に関する重要な情報をまとめて管理するためのものです。
このファイルには、アプリケーションの動作に関するさまざまな設定が含まれています。

参考サイト

yaml.org

ランタイムの指定

使用するプログラミング言語やランタイム環境を指定します。
app.yamlファイルでは、アプリケーションがどのプログラミング言語やランタイム環境を使うかを指定することができます。
これをもって、Google App Engineがアプリケーションを正しく実行するための環境を準備することになります。

プログラミング言語

アプリケーションが書かれている言語です。
例えば、Python、Java、Node.jsなどです。

ランタイム環境

アプリケーションを実行するためのソフトウェア環境です。プログラミング言語に対応したランタイムが用意されています。
例えば、Pythonを使ってアプリケーションを作成している場合、runtime:として記述されることになるでしょう。
Python 3.9のランタイム環境を使用することを指定すると、Google App EngineはPython 3.9を使ってアプリケーションを実行します。
同じようにnodejs14などを使うこともできます。
このように、app.yamlファイルで使用するプログラミング言語やランタイム環境を指定することで、アプリケーションが正しく動作するように設定します。

ハンドラの設定

URLパスとそれに対応するリクエストハンドラを定義します。
前述のようにapp.yamlは、Google App Engineでアプリケーションの設定を行うためのファイルです。
このファイルの中で、「URLパス」と「リクエストハンドラ」を定義します。

URLパス

ユーザーがウェブブラウザに入力するアドレスの一部です。
例えば、/homeや/aboutなどです。

リクエストハンドラ

特定のURLパスにアクセスがあったときに、そのリクエストを処理するプログラムや関数のことです。
簡単に言うと、app.yamlファイルで「このURLにアクセスがあったら、このプログラムを実行してね」と指示を出している感じです。
例えば、次のような設定があったとします。


# yamlの記述内容
handlers:
- url: /home
 script: home.app
- url: /about
 script: about.app

この場合、ユーザーが/homeにアクセスすると、home.appというプログラムが実行され、/aboutにアクセスすると、about.appというプログラムが実行されます。

インスタンスの設定

インスタンスのスケーリングやクラスを設定します。
app.yamlファイルでインスタンスのスケーリングやクラスを設定することで、アプリケーションのパフォーマンスを最適化し、コストを管理することができます。

インスタンスのスケーリング

アプリケーションの負荷に応じてインスタンスの数を増減させる仕組みです。
例えば、アクセスが多いときにはインスタンスを増やし、少ないときには減らすことで、効率的にリソースを使うことができます。

インスタンスのクラス

インスタンスの性能やコストに関する設定です。
例えば、高性能なインスタンスを使うか、低コストなインスタンスを使うかを選ぶことができます。

例えば、次のようなことを指定していきます。

[instance_class: F2]とすれば、F2クラスのインスタンスを使用することを指定しています。F2クラスは、比較的高性能なインスタンスですね。
[automatic_scaling]とすれば、自動スケーリングの設定です。
[min_instances: 1]とすれば、最低でも1つのインスタンスを常に稼働させることを指定しています。
[max_instances: 5]とすれば、最大で5つのインスタンスまで増やすことができることを指定しています。

環境変数の設定

アプリケーションで使用する環境変数を定義します。
環境変数を使うことで、アプリケーションのコードを変更せずに設定情報を変更することができます。
セキュリティが向上し、設定の管理が簡単になります。

環境変数

アプリケーションが動作する際に必要な設定情報を外部から渡すためのものです。
例えば、データベースの接続情報やAPIキーなど、アプリケーションのコードに直接書きたくない情報を環境変数として設定します。

app.yaml

ファイルで環境変数を定義することで、これらの情報を簡単に管理できます。

例えば、DATABASE_URL: "mysql://user:password@localhost/dbname"としてデータベースの接続情報を指定します。この情報を使って、アプリケーションはデータベースに接続します。
APIについてはAPI_KEY: "your-api-key-here"と書くことで、外部のサービスを利用するためのAPIキーを指定します。このキーを使って、アプリケーションは外部サービスにアクセスします。

静的ファイルとディレクトリを設定する方法

静的ファイルの設定

静的ファイルを提供するためには、app.yamlファイルにstatic_filesまたはstatic_dirを使用してハンドラを定義します。

static_filesの使用例

static_filesを使用すると、特定のファイルパターンに一致するファイルを提供できます。


# yamlの記述内容
- url: /static(.*)
 static_files: static/\1
 upload: static/(.*)

(.*)
これは正規表現のパターンで、任意の文字列（0文字以上）にマッチします。
括弧で囲まれているため、キャプチャグループとして機能します。
つまり、マッチした部分を後で参照できるように保存します。

\1
これはキャプチャグループの参照です。
正規表現のパターンで最初にキャプチャされたグループ（この場合は(.*)）を指します。
\1は最初のキャプチャグループ、\2は2番目のキャプチャグループ、というように続きます。

url: /static/(.*):

/static/に続く任意の文字列にマッチします。
例えば、/static/image.pngや/static/css/style.cssなどです。

static_files: static/\1:

マッチしたURLのパスの部分（(.*)）をstatic/ディレクトリ内の対応するファイルにマッピングします。
例えば、/static/image.pngがリクエストされた場合、static/image.pngファイルが提供されます。

upload: static/(.*):

App Engineにアップロードされるファイルのパスを指定します。
static/ディレクトリ内の任意のファイルがアップロード対象となります。
この設定があることで、/static/に続く任意のパスがstaticディレクトリ内の対応するファイルにマッピングされ、App Engineにアップロードされるファイルも同様に指定されます。

static_dirの使用例

static_dirを使用すると、ディレクトリ全体を静的ファイルとして提供できます。


# yamlの記述内容
- url: /static
 static_dir: static

この例では、/static URLに一致するリクエストがstaticディレクトリ内のファイルにマッピングされます。

app.yamlの構文例

下記コードのコピペはお勧めできません。

Webアプリケーションのレベルやアクセス数によっては費用がかかる可能性がありますよ。
あくまでも私の環境に沿った上でのコードですし、頻繁に変更しています。
ちゃんと意味を理解してから書いた方が良いです。

Google App Engine の app.yaml


runtime: python312
instance_class: F1
env: standard

runtime_config:
  document_root: www

automatic_scaling:
  min_idle_instances: 0
  max_idle_instances: 3
  max_concurrent_requests: 200

handlers:
- url: /
  static_files: www/index.html
  upload: www/index.html

- url: /favicon.ico
  static_files: www/favicon.ico
  upload: www/favicon.ico

- url: /(.*)
  static_files: www/\1
  upload: www/(.*)

YAML 設定ファイルの説明

1. runtime: python312
使用するランタイム環境を指定します。
私の場合、Python 3.12 を使用しています。

2. instance_class: F1
使用するインスタンスのクラスを指定します。
F1 クラスのインスタンスを使用しています。
これは無料の低トラフィック用インスタンスクラスです。

3. env: standard
環境を標準環境として指定します。

4. runtime_config:
ランタイムの設定情報を定義するセクションです。

document_root: www
ドキュメントルートを指定しています。
私の場合、アプリケーションのルートディレクトリが www フォルダです。

5. automatic_scaling:
自動スケーリングの設定を指定するセクションです。

min_idle_instances: 0
最小アイドルインスタンス数を 0 に設定します。
インスタンスがアイドル状態になったとき、それを保持する最小の数です。
max_idle_instances: 3
最大アイドルインスタンス数を 3 に設定します。
インスタンスがアイドル状態になったとき、それを保持する最大の数です。
max_concurrent_requests: 200
1 つのインスタンスで同時に処理できるリクエストの最大数を 200 に設定します。

6. handlers:
URL ハンドラーのリストを定義するセクションです。
各ハンドラーが特定の URL パターンに対してどのような操作を行うかを指定します。

url: /
/ に一致する URL に対するハンドラーを指定します。
- static_files: www/index.html
  静的ファイル www/index.html を提供します。
- upload: www/index.html
  GAE にデプロイするときに www/index.html をアップロードします。
url: /favicon.ico
/favicon.ico に一致する URL に対するハンドラーを指定します。
- static_files: www/favicon.ico
  静的ファイル www/favicon.ico を提供します。
- upload: www/favicon.ico
  GAE にデプロイするときに www/favicon.ico をアップロードします。
url: /(.*)
任意の URL に一致するハンドラーを指定します。
正規表現 (.*) を使用して、どの URL にもマッチさせます。
- static_files: www/\1
  URL に対応するファイルを www フォルダから提供します。
- upload: www/(.*)
  GAE にデプロイするときに www フォルダ内の任意のファイルをアップロードします。

個人サイトをクラウドサービスで公開する

Azureならほとんど専用サービスとも言える「Azure Static Web Apps」というプロダクトがあるんですよね。
HTML、CSS、JavaScriptなどの静的コンテンツを簡単にデプロイし、グローバルに配信するためのサービスとなります。

GCPだと「Firebase Hosting」もあって、これでも良いと思います。
私がひとまずGoogle App Engineを選んだのは、App Engineのほうが歴史が長く、専門書の出版数も多いからです。
FirebaseはGoogleに買収され、その後でFirebase Hostingが導入されたんだよね。

AWSにも「AWS Amplify」というのがありますよ。
静的ウェブサイトやシングルページアプリケーション（SPA）のホスティングを提供し、グローバルCDN、カスタムドメイン、継続的デプロイなどの機能を備えています。

個人サイトについてX（旧Twitter）でよく話題になるhtml・css・JavaScriptというのは、要するにフロントエンドに関するコードなんですよね。
バックエンドは、例えば私がローカルサーバーを立てるのにインストールしたPythonなんかがそうです。
それで、ここでお話ししているクラウドというのは…一言で書くのは極めて難しいですが、インフラと言えば良いでしょうか。
個人サイト作るだけなのにサーバー実機なんか買わないでしょ？

ホスティング先のクラウド選び

まずは料金が安いGoogle Cloudから探してみるのがいいんじゃないかな。
私は次のようにして、ひとまずApp Engineを試しています。

Google Cloudからプロダクトを選択。より詳しくやりたいことが具体的になっている場合はGoogle Cloud プロダクト
大項目を選択する。─ ここではサーバーレスを選択します。なぜサーバーレスなのかですが、アプリケーションホスティングの概要に詳しく書いてあります。いきなりIaaSを検討しなくて良いでしょう。 ─
Cloud Run・Cloud Functions・App Engine・Workflows・API Gatewayをさっと見てから…
AWS サービスや Azure サービスと Google Cloud を比較するで似たようなサービスをそれぞれ調べる。
それらのプロダクトの中から、自分のニーズにあったものを選ぶ。

レンタルサーバー VS クラウドサービス

やってることは似たようなもんだと思うんですけどね。
AWS、GCP、Azureなどのクラウドサービスの台頭は、レンタルサーバー業界に大きな影響を与えています。
これらのクラウドサービスは、スケーラビリティ、柔軟性、コスト効率の面で優れており、多くの企業や個人が従来のレンタルサーバーから移行する要因となっているんですよね。

コストで比べる

クラウドサービスは従量課金制や無料の初期利用枠を提供しており、初期コストを抑えたいユーザーにとって魅力的です。
私なんか思いっきりこのタイプですよ。
クラウドにホスティングすれば、無料で広告無しの自由自在なWebサイトにできるのです。

技術で比べる

クラウドサービスは最新の技術を迅速に取り入れることができ、セキュリティやパフォーマンスの面でも優れています。
さすがにAWS、GCP、Azureのクラウドですからね。

運用の簡便さで比較する

クラウドサービスは、インフラの管理を自動化するツールやサービスを提供しており、ユーザーはより簡単に運用できます。
開発環境を整えるために個人でハイスペックPCを用意する必要がないのですよ。
私はずっとロースペックパソコンでWeb書いてます。

市場の変化

個人サイトを作る人が減少し、SNSやブログサービスの利用が増えていることも影響していますね。
私が「無料＆格安でWebサイトを作る」にてお勧めしている Google Sites はホームページ作成サービス、Blogger はブログサービスです。
それで、イーロンマスクによってXの将来が不透明になってきたから、昔のように個人サイトが注目されるようになってきたという流れです。

おそらく、これからも昔ながらの「レンタルサーバー」は、１つまた１つとサービス終了していくのではないかと。
その頃にはAWS、GCP、AzureなどのクラウドサービスがもっとIT初心者にも使いやすくなっていることでしょう。

App Engine以外でもWebサイトを公開できる

Google Cloud Storageを使用して静的ウェブサイトをホスティングすることもできます。
静的コンテンツ（HTML、CSS、JavaScriptなど）をホストするのに適しており、ウェブサイトのファイルをバケットにアップロードし、公開設定を行うだけで簡単にホスティングできます。

Google Cloudの「Cloud Run」と「App Engine」はどちらもサーバーレスのコンピューティングサービスです。
Cloud Runはコンテナベースで任意の言語やライブラリを使用できます。
リクエストに応じて自動的にスケールし、アイドル状態ではゼロまでスケーリングダウンします。
そのため、使用したリソースに基づいて課金され、アイドル状態のコストは低く抑えられます。

一方、App EngineはPaaS（Platform as a Service）です。
アプリケーションコードをデプロイするだけでインフラの管理をGoogleに任せることができます。
スタンダード環境とフレキシブル環境があります。
スタンダード環境は自動スケーリング、フレキシブル環境はカスタマイズ可能なインフラを提供します。
ソースコードを直接デプロイでき、特定のランタイム環境を選択するだけで動作します。
しかし、インスタンスベースの課金モデルでアイドル状態でも一定のコストが発生します。

静的ウェブサイトのホスティングに関しては、Cloud Runはコンテナを使用します。
静的ファイルを含むコンテナイメージを作成し、それをデプロイすることでホスティングが可能です。
スケーリングの柔軟性とコスト効率の面で優れているんですよね。
一方、App Engineは特にスタンダード環境での静的ファイルのホスティングが簡単で設定も少なく済みます。
しかし、アイドル状態のコストが発生する点に注意が必要です。

とはいえ、標準環境であれば無料枠があるわけです。
総合的に見ると、静的ウェブサイトのホスティングにはCloud Runがより適しているように思えますが、どちらのサービスも優れた機能を持っているため、具体的なニーズに応じて選択することが重要です。

クラウドサービスには無料枠がある

ここで、無料枠の話をしましょう。
静的ウェブサイトのホスティングに関して、例えば上述のGoogle Cloud RunとGoogle App Engineの無料枠を比較する場合、次のような事柄を考慮する必要があります。

Google Cloud Run

CPU時間: 毎月最初の180,000 vCPU秒
メモリ使用量: 毎月最初の360,000 GiB秒
リクエスト数: 毎月最初の200万リクエスト
ネットワーク: 北米内の下り（外向き）トラフィックは1GBまで無料

Google App Engine

インスタンス時間: Standard環境で1日あたり28インスタンス時間
ネットワーク: 下り（外向き）トラフィックが1GB/日
Cloud Storage: 5GBの無料ストレージ

比較ポイント

トラフィック: App Engineは1日あたり1GBの下りトラフィックが無料で、Cloud Runは月あたり1GBです。頻繁にアクセスされるサイトならApp Engineが有利です。
インスタンス時間: App Engineは1日あたり28インスタンス時間が無料で、Cloud RunはCPU時間で計算されます。短時間で多くのリクエストがある場合はCloud Runが有利です。
ストレージ: App Engineには5GBの無料ストレージが含まれていますが、Cloud Runにはストレージが含まれていません。

静的ウェブサイトのホスティングに関しては、アクセス頻度や必要なリソースに応じて選ぶと良いでしょう。

頻繁にアクセスされるサイトならApp Engine
短時間で多くのリクエストがある場合はCloud Run
これは目安に過ぎませんが、私の場合、旬な話題や時事ネタなど、浮き沈みが激しいものは避けています。
よって、App Engineが有利であろうと判断してるんだよね。

サイトマップ

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

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

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

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

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

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

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