8
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

RailsをGoogle App Engine(Flexible Environment)で動かしてみた感想

Posted at

2018年末に仕事でGoogle App Engine(GAE)のRailsアプリをリリースしました。

個人としても会社としてもGAEでRailsアプリをリリースするのは初めてだったので、動かしてみた感想などを共有したいと思います。

利点

  • 手軽に始められる
  • httpsのアプリで動かせる(オレオレ証明書とか必要ない)
  • デプロイの安定感が高い(イミュータブルデプロイメント)

手軽に始められる

なんといってもこれが大きいです。
基本Flexible Environment(FE)はdockerで動くようにコードを書いてれば動くので、app.yamlという設定ファイルだけ用意してdeployすればすぐ動いてくれます。

app.yaml
env: flex
runtime: custom
service: default
automatic_scaling:
  min_num_instances: 1

お手軽さはherokuとほぼ変わらず、GCPの事前知識不要でだいたい動かせるのが魅力です。
(最近のherokuを使っていないので、比較はできないですけども...)

httpsで動かせる

ローカルでの開発ではオレオレ証明書とか色々考えないといけません。
が、GAEはhttpsのドメインを払い出してくれるので特に考えずにhttpsにできます。

プロジェクトではfrontendにReact.js、backendにRailsという構成で、それぞれ別の人が開発するスタイルだったのですが、それぞれhttps対応するのに手間がかからなかったので結合もスムーズにいけました。

デプロイの安定感が高い

イミュータブルデプロイメントというらしいですが、GAEはバージョンごとに不変な環境を構築し、トラフィックの向き先をバージョンに割り当てられるようになっているため、安定したデプロイがしやすかったです。

スクリーンショット 2019-03-01 11.33.29.png

既存で動いている環境を上書きしたりしないので、新しいバージョンにバグがあってもすぐトラフィックを前のバージョンに戻すことが出来たり、そもそもバージョンごとにURLが割り当てられるので、出す前のバージョンの動作確認をしてから切り替えることができました。

ブルー・グリーンデプロイメントに似てますが、ブルー・グリーンの2環境だけでなくバージョンの数だけ環境を持つことができる点ではこちらの方がより柔軟性が高いです。

またトラフィックを流す割合も設定できるので、カナリアリリースやA/Bテスト的な使い方もできるのも良さそうです(実際にはまだ試していないですが)。

欠点

いいところもありますが、もちろん欠点もあります。

  • FEはdeploy超遅い。10分弱かかる
  • SSHはできるけど、ちょっとの修正がめんどくさい
  • 一番弱いインスタンスだと、rails consoleがメモリ不足でたまに落ちる
  • トラフィックを受けないプロセスを動かすのはややこしい

deploy遅い & ちょっとの修正が面倒

これが割とつらいです。やばいミスった直そうというときにdeployに時間かかってしまって開発のスピードが出ません。
Standard Environmentは早いらしいんですが、FEだと時間がかかることが多いようです。

上で書いたイミュータブル環境なおかげで(?)SSHで入っても書き換えで再構築ができないので、再deployする必要があって10分ほど待たされてしまいます。

rails consoleメモリ問題

単純に少しいいインスタンス使えばいいとは思いますが、rails server起動した状態でrails consoleやろうとするとメモリ不足で立ち上がってくれなかったりしました。

トラフィックを受けないプロセスを動かすのはややこしい

web serverのプロセスはGAEと相性がいいですが、例えばsidekiqなどのバッチのプロセスなどとはちょっと相性が悪そうです。

当たり前ですが、単純に起動しているインスタンスがある=プロセスが動いてます。

そのため、画面上トラフィック割り当てされてなくてもインスタンスさえ起動していれば、過去のバージョンであっても動いてしまっています。

特にsidekiqなどはredisのキューを見てプロセスが順次処理を実施していくので、過去のバージョンが残ってしまっているとたまにコード修正したのに直ってない!みたいな罠に陥ることがあります。

ということでバージョンを停止してからdeployすると、今度は一時的にダウンタイムが発生してしまうことになってしまいます。

トラフィック切り替えのように厳密に切り替わるわけではないので、重複期間を許すか、ダウンタイムを許すかはプロセスやサービスの仕組みごとに考えるほうが良さそうです。

というかそもそもGAEと相性が悪そうですね。

まとめ

最初始めるのはいいですが、慣れてきたらCI/CDがうまくできる環境に移行していくと開発のスピードを維持できそうです。

一方デプロイはやりやすいので、本番でうまく使うのは良さそうですね。

8
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?