前回に続き GCP。今回は Google App Engine こと GAE。
スケーリングが柔軟なWebアプリケーションの PaaS で、Azure でいうと Web Apps、AWS では AWS Elastic Beanstalk のはず。
Heroku を卒業したサービスが仮想マシンベースのサービスに引っ越すか、このへんに引っ越すイメージ。
Google App Engine
料金
全般
App Engine の料金 | App Engine Documentation | Google Cloud Platform
価格 - App Service | Microsoft Azure
GAE の料金体系は、インスタンス(CPU+メモリ)とデータストア、ネットワークトラフィック、あとはコンポーネントによって定義されており、見積もり泣かせな細かい設定となっている。
GAE の料金体系はかなり細かいので、インスタンスとデータストアくらいしか見積もり困難じゃないかな。あとは案件によってデータ通信量を入れるかどうか。 https://t.co/LrwBkhKtvX
— kheiakiyama (@kheiakiyama) 2018年2月4日
GAE、東京で最小の 128MB インスタンスが月$51.24と、特に安いわけではないな。
— kheiakiyama (@kheiakiyama) 2018年2月4日
Azure の Web App 同様、強力なプラットフォームを利用できる代わりにベースの料金はそれなりにかかる模様。
(Azure App Servie ではCPU時間リミットがある無料プランや、プロダクションでは月1万円欠けるスタンダードプランなどがある)
(B or F) + 数字 の組み合わせでインスタンスが表現される。
数字が CPU 性能で 4_1G 以外は CPU 性能に合わせてメモリ量が増える。
B と F の違いはこの後出てくるスケーリングのタイプによって変わる。
カスタマイズしたインスタンス
フレキシブル環境は自分でCPUとメモリ配分を決められるってことか。
— kheiakiyama (@kheiakiyama) 2018年2月4日
フレキシブル環境という仕組みがあり、CPU とメモリのサイズをアプリケーションに合わせてカスタマイズできる。
無料枠
各リソースごとに無料枠が設定されており、たとえばフロントエンドインスタンスは 1日28時間分が無料となっているため、1インスタンスで足りるサービスならインスタンスについては無料でサービスできる。
なにかサービスつくりたい。
開発
全般
GAE ではアプリケーションに関する設定は各種 yaml
ファイルで定義する。
app.yaml によるアプリの設定 | App Engine flexible environment for Java docs | Google Cloud Platform
このあたりは GCP の哲学としてコードに残すのだ、という意志を感じる。
Azure の対抗は Web App かな。Azure が GUI でいろいろできるのはアプリとインフラの担当が分かれるケースが多いためか。とはいえアプリ担当が全部できる範囲という気もする。GCP は Infrastructure as a Code を地で行っている感じ。
— kheiakiyama (@kheiakiyama) 2018年2月4日
スケーリング
オートスケール
インスタンスクラスでいうところの F について。
GAE にはスケーリングのパターンがいくつかある。
オーソドックスな CPU 使用率トリガー以外に、レイテンシの時間をトリガーにできる。
リクエストを受けたキューがインスタンスに流す待ち時間が 500ms を超えたらスケールアウトするなど。
スケールインも細かい制御ができるのが他のクラウドと比べたときの特徴。
インスタンス数をロックするのも可能だが、無料枠の恩恵を受けられないので個人のサービスとしては迷うところか。
マニュアルスケール
オートスケールせずにインスタンス数を固定するのも可能。
この場合は B のインスタンスクラスとなる。
参考
App Engine Scaling Config - Qiita
上がまとまっていて参考になった。
動かすアプリケーションによって経験則による設定値がありそう。
デプロイ
デプロイはわりと時間がかかる。
オーソドックスな以下の app.yaml
でも 10分〜15分くらいはかかった印象。
runtime: nodejs env: flex
ログ見てる限りだと、 `gcloud app deploy ` したときに docker build + docker push してるのかな。
— kheiakiyama (@kheiakiyama) 2018年2月4日
あとはスケーリングの変更を行った場合のデプロイは反映されるまでにかなり時間がかかったので詳しい動きを知りたい。
デフォルト設定で負荷をかけて10台くらいにスケールした後、manual_scaling
で2台にするのにかなり時間がかかった。元の設定のスケールイン値に基いて2台になるのかも。
ホスティング
なるほど。http://(project_name).appspot.com にデプロイされると。そして https も受けてくれる。
— kheiakiyama (@kheiakiyama) 2018年2月4日
よくある Web の PaaS と同じ。
プロジェクトに複数のサービスがある場合は個別に FQDN が払い出される。
gcloud app deploy app.yaml service1.yaml service2.yaml
でデプロイ。
サービスは http://(service_name)-dot-(project_name).appspot.com/ にデプロイされると。
— kheiakiyama (@kheiakiyama) 2018年2月4日
カスタムドメインも普通に使える。
GAE のカスタムドメインが上手くいかないと思ったら、お名前.com ではなくて Route53 に移管してたからだった。。。
— kheiakiyama (@kheiakiyama) 2018年2月4日
よくわかってないところ
シークレット情報としての環境変数
環境変数は app.yaml
に書く以外の方法が用意されていない。
API Token などのシークレット情報をどこに置けばいいかがわからない。
Azure Web App や Heroku だとクラウドリソースのメタデータとして設定するが、yaml
以外に設定値を持たない GAE でどうすればいいかがわからない。
調べた限りだと Data Store を使ったり、Cloud Storage を使っている 回避策を取っている模様。
app.yaml
を .gitignore
するのはなしだろうなあ。
GAE は歴史が長いサービスなので、機能がないということはきっとこの先も機能提供されないのだろう。
サービスの落とし方
デフォルトのサービス消せないけど、どうしたらいいんだろう。1インスタンスは無料だから無効にして放置しろってことかな。
— kheiakiyama (@kheiakiyama) 2018年2月4日
よくわかりませんでした。
アプリケーションを無効にして、インスタンスを削除すればOKですかね。
請求を後で確認。
最後に
基本的な部分を触っただけなので、まだ試したいことがいろいろ残っている感じ。
思いつくだけでも
- 複数ドメイン利用するプロジェクトでどうアプリケーションコードを分割するのか
- スケジューリングジョブ
npm
やComposer
,Nuget
などのデプロイジョブ- 継続的デプロイ
ここまで個別にサービスを見てきたけど、どこかで小さいアプリケーション書いて動かしたほうが足りない部分がわかってよさそう。
時間を取れるときにやりたい。