App Engine と Cloud Functions の言語サポートのライフサイクルについて
TL;DR
App Engine (standard) と、Cloud Functions で新しくランタイムのライフサイクルとサポートのポリシーが定められました。
App Engine 第 1 世代、または、App Engine 第 2 世代で稼働する、EoL を過ぎた、または近い将来 EoL になる言語バージョンを利用している場合、2024 年 1 月以降に順次 EoS(サポート終了)になります。
EoS までに、各言語で GA となっているバージョンにアップグレードする、または、アプリをコンテナ化して Cloud Run へ移行する必要があります。App Engine のバンドル サービスを利用している場合、改修が必要なサービスもあります(Cloud Run に移行する場合は対応が必須)。
Cloud Functions については、Deprecation(非推奨)となる日付が定義されましたが、Decommissioned(廃止)になるまではサポートされます。ただ、廃止日までに同様の対応(バージョンアップ or 移行)をする必要があります。
App Engine について
Google Cloud の PaaS(Platform as a Service)として利用可能な App Engine は、2008 年にリリースされた歴史のあるプロダクトです。
App Engine には大きく分類して、2 つの環境があります。スタンダード環境とフレキシブル環境です。フレキシブル環境ではコンテナアプリが実行可能ですが、スタンダード環境の方がマネージドの範囲が広く、スケール性能も優れています。
また、スタンダード環境は第 1 世代と第 2 世代に分かれます。第 2 世代のランタイムでは、App Engine の機能が大幅に改善され、第 1 世代のランタイムのいくつかの制限が取り除かれています。また、利用可能な API の相違点などがあります。
第 1 世代から使われていた、App Engine のバンドル サービスについても、2021 年 9 月には、大半が第 2 世代のランタイムで利用可能になりました。ただし、言語によって利用可能なサービスに差分がある点に注意が必要です。対応していない場合、Google Cloud で提供している同等機能のプロダクトに移行するか、代替となるサービスを構築する必要があります。
Cloud Functions について
Google Cloud の FaaS(Function as a Service)として利用可能なプロダクトです。プロダクト間での、ある程度小さな処理や、イベント駆動での処理に主に利用されます。
こちらも第 1 世代と第 2 世代があり、昨年、第 2 世代が GA になりました。第 2 世代では Cloud Run を基盤として関数が実行され、第 1 世代よりも多くの CPU やメモリを割り当てることができたり、1 インスタンスで複数の同時リクエストを処理できるようになりました。
今回のアップデート内容
ここから今回のアップデート内容を書いていきます。App Engine と Cloud Functions では公式ドキュメントの内容に差分があるため、それぞれ分けています。
後述で使われる用語について、少し触れておきます。
GA = 該当プロダクトや機能が、Google Cloud SLA の対象となります。Google は通常、プロダクトや機能を、API、CLI、Google Cloud コンソールを通じてサポートしています。
EoS = End of Support。App Engine で言語のランタイムのメンテナンスやサポートがされなくなります。
EoL = End of Life。プログラミング言語に対しては、それ以上継続して使用すべきでないとされる使用期限を意味します。
App Engine
各言語のバージョンが、それぞれのコミュニティによってサポートされなくなった場合(≒ EoL)、その言語のランタイムのメンテナンスとサポートの提供を停止します(= EoS)。
サポート終了日はドキュメントで事前に確認できますが、それとは別にアプリケーションのサポートが終了する 90 日前に通知があるので、どちらかで気付けるようにしておきましょう。
サポート終了日に達した時、次のようになります。
- Google は、ランタイム環境のコンポーネントにセキュリティ アップデートやパッチを適用しなくなります。
- アプリケーションは引き続き実行され、トラフィックを受信します。
- サポートされていないランタイム上でアプリケーションを作成、更新できなくなります。
- サポートされていないランタイムの使用によって発生する問題は、テクニカル サポートの対象外です。
GA、EoS、Deprecated、Decommissioned のサポートの差分は、以下になります。最新情報は公式ドキュメントを参照してください。
GA | EoS(サポート終了) | Deprecated(非推奨) | Decommissioned(廃止) | |
---|---|---|---|---|
作成と再デプロイ | 可 | 不可 | 不可 | 不可 |
プロジェクト構成の更新 | 可 | 可 | 不可 | 不可 |
既存のワークロードの実行(アプリケーションが引き続き実行され、トラフィックを受信する) | 可 | 可 | 可 | 不可 |
UI と CLI の警告 | あり | あり | なし | なし |
言語パッチ | 自動 | 自動更新なし | 自動更新なし | 自動更新なし |
API と SDK のパッチ適用 | 自動 | 自動更新なし | 自動更新なし | 自動更新なし |
OS へのパッチ適用 | 自動 | 自動更新なし | 自動更新なし | 自動更新なし |
カスタマーサポート | GA レベルのサポート | ランタイム サポートなし | ランタイム サポートなし | ランタイム サポートなし |
また、各言語のバージョンのサポート終了時期は以下に記載されています。必要あれば、言語のアップグレード、または移行について準備しましょう。直近の EoS は 2024 年 1 月 30 日です。
Cloud Functions
Cloud Functions は比較的シンプルで分かりやすく、廃止になるまでに対応すれば良さそうです。
- 積極的に保守されない言語のバージョンになると、Cloud Functions としても非推奨になり、最終的にはランタイムが削除される可能性があります。
- ランタイム サポートは、GA 後に Deprecated(非推奨)となり、その後期間を経て Decommissioned(廃止)になります。
- Deprecated 〜 Decommissioned の間は関数の作成と更新が可能ですが、スケジュールは事前に出ているため、非推奨になる前に移行スケジュールは計画した方が良いでしょう。
- 非推奨期間でも稼働中の関数は動きますが、廃止になると無効化される可能性があります。
GA | Deprecated(非推奨) | Decommissioned(廃止) | |
---|---|---|---|
作成と再デプロイ | 可 | 可 | 不可 |
既存のワークロードの実行 | 可 | 可 | 不可 |
カスタマーサポート | 可 | 可 | 不可 |
Cloud Run への移行
Cloud Run への移行が唯一の解ではないですが、言語のバージョンに依存しない形で、シンプルにサーバーレス アプリケーションが移行可能です。
もちろん、App Engine のバンドルサービスにより移行が困難な場合、App Engine 第 2 世代で最新の言語バージョンを利用するのも良いと思います。
Cloud Run にアプリを移行するメリットの一例として、以下が考えられます。
- 言語やバージョンなどに依存しない、コンテナ アプリケーションがデプロイ可能
- バッチ処理に特化した、Cloud Run jobs という機能もあり、サーバーレスでバッチ処理が可能
- 内部 HTTP(S) ロードバランサや、リージョン外部 HTTP(S) ロードバランサを前段に置くことが可能(2023.02 時点では、まだプレビュー)
- App Engine や Cloud Functions と同様に、グローバル外部 HTTP(S) ロードバランサも前段に置くことが可能
- タイムアウトが 60 分と比較的長い(App Engine standard は 1 分、Cloud Functions 第 1 世代は 9 分)
アプリのコンテナ化にフォーカスすると、通常コンテナを作成するために Dockerfile を記述してビルドするのが一般的ではありますが、App Engine や Cloud Functions を利用してきた場合、Dockerfile の運用を避けたいかもしれません。
その場合、Buildpacks という OSS があります。こちらを利用すると(各言語によってルールは多少あるものの)Dockerfile を記述しなくてもアプリをコンテナ化することが出来ます。
Buildpacks が対応している言語バージョンと、App Engine や Cloud Functions のサポートバージョンは、必ずしも一致するとは限らないので注意してください。
コンテナイメージを Container Registry、または、Artifact Registry に配置できたら、Cloud Run サービスのデプロイは画面からポチポチでデプロイできます。コンソール画面における操作やオプション内容は、以下の記事を参考にしてみてください。
まとめ
一般的に、言語のバージョンは継続的にアップデートし続ける必要がありますし、開発を行う上で健全なライフサイクルを保つのが良いと思います。
コンテナを動かす基盤であれば、EoL になったバージョンでもアプリを稼働させることは出来ると思いますが、言語バージョンが古いことで対応されないライブラリがあったり、パッチが当たらないことで脆弱性を含むこともあったりするので、言語は定期的にアップデートを行うことをお勧めします。
App Engine や Cloud Functions などの PaaS や FaaS といったサービスは、ソースコードを管理してデプロイするだけで運用可能な、非常に有用なプロダクトですが、それとセットで言語のバージョンアップも意識するようにしましょう。
Discussion