Google Cloud FunctionsとApp Engineの連携
はじめに
最近、Google Cloudのサービスは大きな進化を遂げています。特に、App Engine（アプリエンジン）からCloud Functions（クラウドファンクションズ）へと移行することが注目されています。App Engineはかつて、アプリケーションをホストするための唯一の選択肢でしたが、現在ではCloud FunctionsやCloud Runが登場し、選択肢が広がりました。本記事では、App EngineのユーザーがどのようにCloud Functionsを活用できるのかについて詳しく解説します。
App EngineとCloud Functionsの違い
App Engineは、使いやすくカスタマイズしやすいプラットフォームですが、近年のマイクロサービスの概念やイベント駆動型のアーキテクチャの台頭により、アプリケーションの設計が変わりつつあります。Cloud Functionsを使用することで、特に小規模なアプリケーションを簡素化し、コードや展開の負担を軽減することが可能です。
- 小規模アプリ：単一機能アプリはマイクロサービスとして扱うことができ、特定のイベントに応じて動作するAPIエンドポイントとして機能します。
- 大規模アプリ：モノリスなアプリケーションは、機能を分解してマイクロサービス化することで、それぞれのコンポーネントを再利用可能にします。
Cloud Functionsへの移行ステップ
App EngineからCloud Functionsへの移行を考える際に、以下のステップを踏むことが推奨されます。
- レガシーサービスの切り離し：DatastoreやTaskqueue、Memcache、Blobstoreなどの古いサービスから脱却します。
- ランタイムのアップグレード：Python 3、Java 11、PHP 7など、Cloud Functionsがサポートする現代のランタイムへの移行を行います。
- アプリの分割：モノリスなアプリを独立した複数のファンクションに分割します。必要に応じて、アプリをコンテナ化してCloud Runに移行することも検討できます。
変更が必要な点
Cloud Functionsに適応するためには、次のような変更が必要です。
- 不要な設定の削除
- ウェブフレームワークおよびルーティングコードの削除
- それぞれのファンクションに適切な名前を付け、受け取るリクエストオブジェクトをインストールします。
特に最後のポイントでは、1つのファンクションに複数の「エンドポイント」を持たせることが可能です。これにより、ルーティングを他のファンクションに処理させることができます。大量のファンクションがある場合、全てのエンドポイントに対して個別にファンクションを用意するのは煩雑になるため、適切に管理することが重要です。
移行の実践例
実際の移行について説明します。Python 2からのマイグレーションを想定し、まずはapp.yamlファイルを削除します。その後、Flaskのリソースをほとんど排除し、テンプレートレンダラーの部分は残すようにします。全てのアプリルートも削除し、Flaskアプリオブジェクトのインスタンス化も行わないようにします。最後に、メインファンクションはvisitme()に名称を変更し、リクエストオブジェクトを引数として追加します。
移行の進行状況を確認するためのコードの「diff」も用意されており、具体的な効果を把握する手助けとなります。
今後のステップ
もし、Cloud Functionsへの移行に興味がある場合、公式のコーディングラボを試してみることをお勧めします。このラボでは、実際の作業をステップバイステップで行えるように設計されています。また、移行に関するすべてのモジュールや動画、チュートリアルは、GitHubの移行リポジトリで確認することができます。
未来の更新に期待しつつ、App Engine、Cloud Functions、Cloud Runでコードを変更せずに動作させることが可能である点も覚えておくと良いでしょう。これからのサーバーレスアプリケーションを現代化する際の参考になれば幸いです。
