【Google Cloud】App Engineについて整理
はじめに
Google CloudのProfessional Cloud Developerの取得に向けて勉強中です。
今回はApp Engineについて整理します。
App Engineとは
App Engineはフルマネージドなアプリケーション実行環境を提供するPaaSになります。
Google Cloudが一番初めに出したサービスになります。（歴史がありますね。）
2008年リリースということなので、16年くらい稼働しているサービスになります。
App Engineを構成する要素
App Engineはいくつかのコンポーネントから構成されています。
App Engineを構成する要素
アプリケーション
アプリケーションコンポーネントは、App Engineを構成する各コンポーネントの親に相当し、App Engineアプリケーション配下に、サービス、バージョン、インスタンスが階層的に存在します。App Engineはリージョンリソースのため、アプリケーションを作成する際にはどこのリージョンで作成するか求められます。アプリケーション作成時に選択したリージョンは変更することができませんので、注意してください。
サービス
サービスはアプリケーションを論理コンポーネントとして分解できます。単一のサービスを構成することも、複数のサービスを作成しサービス間での通信をすることでマイクロサービスとして構成することも可能です。
各サービスはアプリのソースコードと、対応するApp Engine構成ファイルで構成され、サービスに対してデプロイを行うと後述するバージョンが追加で作成されていきます。
バージョン
バージョンはサービス内で稼働しているアプリの実態です。各サービス内には複数のバージョンが登録され、トラフィックの移行を行うことによって即座にロールバックができたり、テストバージョンに切り替えられたりすることができます。また、トラフィックの分割も行うことができるため、複数のバージョンにトラフィックをルーティングさせることができます。
複数のバージョンで利用されるため、アプリケーションのリクエストURLは以下の仕様で決定されます。
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
インスタンス
インスタンスはサービスの各バージョンが実行されている基盤になります。App Engineの環境によってインスタンスの実行基盤が異なります。スタンダード環境の場合は、ユーザ側の環境ではなくGoogle Cloud側の環境のコンテナインスタンスで実行されます。フレキシブル環境の場合は、ユーザ側の環境のCompute Engine上のDockerコンテナ内で実行されます。
構成ファイル
App Engineはいくつかの構成ファイルが利用できます。
- app.yaml
- App Engineのアプリの設定を行います。
- cron.yaml
- 定義された時刻または一定間隔で動作する定期スケジュールタスクを構成します。
- dispatch.yaml
- 受信リクエストをURLのパスまたはホスト名に基づいて特定のサービスに送信することで、ルーティングのデフォルトルールをオーバーライドします。
- index.yaml
- Datastore クエリを使用する場合に、アプリに必要なインデックスを指定します。
セキュリティ
App Engineファイアウォール
App Engineは、ファイアウォールを設定することができ、指定した範囲のIPアドレスからのリクエストを許可・拒否する一連のルールを使用してApp Engineへのアクセス制限を実施できます。App Engineの場合は、受信トラフィック（内向き）のみ適用されます。デフォルトでは、アプリへのアクセスが全て許可されているので、特定のルールに一致しないリクエストをすべてブロックしたい場合は、デフォルトのルールのアクションをDenyに変更します。
ingress設定
ingress（内向き）設定を行うことで、ネットワークレベルのアクセス制御を行うことができます。
| 設定 | 許可 |
|---|---|
| 内部 | 同じプロジェクトのVM/サーバレスVPCアクセスコネクタ/共有VPC |
| 内部とCloud Load Balancing | 内部設定の許可リスト/外部アプリケーションロードバランサ |
| すべて | インターネットからのすべてのリクエスト |
App Engineの環境
App Engineでアプリケーションを実行する環境として、スタンダード環境とフレキシブル環境の2つがあります。それぞれ特徴がありますので以下にまとめます。
| 機能 | スタンダード環境 | フレキシブル環境 |
|---|---|---|
| インスタンスの起動時間 | 秒 | 分 |
| リクエストの最大タイムアウト | ランタイムとスケーリングのタイプによって異なる | 60分 |
| バックグラウンドスレッド | 〇 （制限付き） | 〇 |
| バックグラウンドプロセス | × | 〇 |
| SSHデバッグ | × | 〇 |
| スケーリング | 手動、基本、自動 | 手動、自動 |
| ローカル ディスクへの書き込み | Python 2.7 と PHP 5.5以外で/tmpへ可能 | VM起動時の初期化されたディスク |
| ランタイムの変更 | × | 〇 （Dockerfile経由） |
| デプロイ時間 | 秒 | 分 |
| Google Cloud APIとサービスへのアクセス | 〇 | 〇 |
| WebSocket | × | 〇 |
| サードパーティ バイナリのインストール サポート | Python 2.7 と PHP 5.5以外で可能 | 〇 |
| 料金 | インスタンス時間 | vCPU、メモリ、永続ディスクの使用量 |
スタンダード環境
App Engineスタンダード環境は迅速なスケーリングに対処する必要があるアプリケーションに向いています。
また、ゼロスケーリングができるので、低コストで運用したい場合も選択肢に入ると思います。
ランタイム
App Engineスタンダード環境では2世代のランタイム環境があります。第一世代のランタイムはすでにサポートが終了しているため、これからApp Engineスタンダード環境を利用する場合は必然的に第二世代のランタイムを利用することになると思います。ここでは第二世代のランタイムのみを記載します。
第二世代のランタイムでサポートされている言語は以下の通りです。
- Python3
- Java11~
- Node.js
- PHP 7/8
- Ruby
- Go 1.12~
スケーリング
App Engineスタンダード環境では3つのスケーリングタイプがサポートされています。
- 自動（デフォルト）
- 基本
- 手動
スケーリングタイプもApp Engine構成ファイルのapp.yamlで指定します。デフォルトでは自動スケーリングが採用されます。
| スケーリング方式 | 説明 |
|---|---|
| 自動スケーリング | リクエスト率、レスポンスのレイテンシなどのアプリケーション指標に基づいてインスタンスを作成する方式 |
| 基本スケーリング | アプリケーションがリクエストを受信したときにインスタンスが作成される方式 |
| 手動スケーリング | 負荷レベルに関係なくユーザ側が実行されるインスタンスの数を指定する方式 |
トラフィック管理
トラフィックの移行
アプリケーションのサービス内にあるバージョン間でリクエストのルーティング先を切り替えて、1つ以上のバージョンから単一の新しいバージョンにトラフィックを移行できます。
スタンダード環境の場合は、トラフィックを段階的に移行するパターンとトラフィックのすぐ移行するパターンを利用することができます。
ウォームアップリクエストを無効にしている場合、トラフィックのバージョンはすぐに移行され、ウォームアップリクエストが有効になっている場合、トラフィックのバージョンを段階的に移行することができます。
トラフィックの分割
トラフィックの配分比率を指定することで、同じサービスの異なるバージョン間でトラフィックを振り分けることができます。この機能によりA/Bテストを実行することができます。トラフィックの分割を行う方法として、2種類の方法から選択することができます。Cookie分割の方がIPアドレス分割よりも正確にルーティングすることができます。それぞれ制約等があるので詳しくは公式ドキュメントを確認してください。
-
IPアドレス分割
送信者のIPアドレスに基づいてアプリケーションへのトラフィックを分割します。IP アドレスを 0～999 の範囲のハッシュ値に変換し、その数値を使用してリクエストをルーティングする仕様になっています。 -
Cookie分割
HTTPリクエストヘッダのGOOGAPPUIDというCookieを利用してトラフィックを分割します。このCookieには0～999 の範囲の値が格納されています。Cookieが存在しない場合は、ランダムにルーティングされます。
ネットワーク
App Engineスタンダード環境はVPCネットワークの外で動作されているため、VPCネットワーク内のリソース（GCE/Cloud SQL MemoryStore）にアクセスする必要がある場合は、サーバレスVPCアクセスコネクタを利用する必要があります。
サーバレスVPCアクセスコネクタを利用する場合は、コネクタ用のインスタンスを別途作成する必要があるためその分管理コストや、料金がかかってしまいます。App Engineフレキシブル環境はVPCネットワーク内で動作するため、VPCネットワーク内のリソースにアクセスする要件がある場合は、App Engineフレキシブル環境も検討してください。
ウォームアップリクエスト
App Engineスタンダード環境では、新しいインスタンスを作成した際に、リクエストの処理に必要なすべてのライブラリとリソースを読み込む必要があります。その際にリクエストに対するレイテンシが遅くなってしまいます。
レイテンシを短縮するためにウォームアップリクエストを利用することができます。
ウォームアップリクエストは、実際のリクエストが行われる前に、インスタンスにアプリケーション コードを事前読み込みする特殊な読み込みリクエストになります。エンドポイントとして /_ah/warmup に対するGETリクエストを利用します。
ウォームアップリクエストは自動スケーリングの場合のみしか利用することができません。
ウォームアップリクエストはapp.yamlへの追記と、/_ah/warmupに対するハンドラをアプリケーションコードに記載する必要があります。
フレキシブル環境
App Engineのフレキシブル環境では、一定したトラフィックを受信する、定期的にトラフィックの変動がある、または徐々にスケールアップやスケールダウンするパラメータを満たすアプリケーションに向いています。
基盤のインスタンスは、メンテナンス等の影響で週次で再起動されてしまうため、こちらの点には注意しておく必要があります。
ランタイム
App Engineフレキシブル環境では、App Engineスタンダード環境と比較して利用できるランタイムが豊富です。
また、カスタムランタイムも利用することが可能なので独自のDockerイメージやOSSのDockerfileでデプロイを行うことが可能です。
App Engineフレキシブル環境のランタイムでサポートされている言語は以下の通りです。
- Go
- Java
- Node.js
- PHP
- Python
- Ruby
- .NET
- カスタムランタイム
スケーリング
App Engineフレキシブル環境では2つのスケーリングタイプがサポートされています。
- 自動（デフォルト）
- 手動
スケーリングタイプはスタンダード環境と同様にApp Engine構成ファイルのapp.yamlで指定します。デフォルトでは自動スケーリングが採用されます。基本スケーリングがないため、インスタンスを0にする（ゼロスケーリング）を行うことができません。
| スケーリング方式 | 説明 |
|---|---|
| 自動スケーリング | リクエスト率、レスポンスのレイテンシなどのアプリケーション指標に基づいてインスタンスを作成する方式 |
| 手動スケーリング | 負荷レベルに関係なくユーザ側が実行されるインスタンスの数を指定する方式。 |
ヘルスチェック
App Engineフレキシブル環境ではヘルスチェックが利用できます。（デフォルトで有効化）ヘルスチェックリクエストを定期的に送信してインスタンスが正常に動作していることを確認します。2種類のヘルスチェックが利用できます。
| ヘルスチェック方式 | 説明 |
|---|---|
| liveness チェック | インスタンスとコンテナが実行中であることを確認する。livenessチェックに失敗するとインスタンスは再起動されます。 |
| 準備チェック | インスタンスがリクエストを受け付けられる準備ができたことを確認する。準備チェックが正常に完了すると使用可能なインスタンスのプールに登録されます。 |
ネットワーク
App Engineフレキシブル環境はVPCネットワーク内で動作するため、VPCネットワーク内のリソース（GCE/Cloud SQL MemoryStore）にアクセスする必要がある場合でも、サーバレスVPCアクセスコネクタを利用する必要がありません。
まとめ
今回はApp Engineについて改めて整理してみました。
最近はApp EngineよりもCloud Runを利用する機会が多いですが、アプリケーションコードがあれば即座にデプロイできる気軽さはApp Engineのメリットに思いました。
Discussion