背景
これまでクラウドの経験はAWSだけでしたが、GCPにも関わるようになりました。
最近とあるシステムのインフラを検討することがあり、GCPのサーバーレスサービスを調べる中でCloudRunが最近アツいということを知りました。
そこでAppEngineを比較対象としてメリデメを自分なりにまとめてみました！
AppEngineとの比較
メリット
-
コスト面
-
GAEは最後のリクエスト処理してから15分後にインスタンス終了するため、その間リクエストはないのに課金される。 -
CloudRunはリクエスト時間で純粋に従量課金。 - そのためリクエスト頻度が少ないケースではCloudRunの方が安くなる可能性が高い。
- ※ コールドスタート（後述）には注意。
-
-
スケールの速度
-
CloudRunはコンテナベースで高速スケーリングする。 -
GAEはVM上でビルドされるため、デプロイ及びバースト時のスケーリングが遅い。 - よって、スパイクが発生するようなシステムでは
CloudRunの方がHTTP503など起きづらくて安心。
-
-
ランタイム依存
-
GAEスタンダード環境では提供ランタイムに制限あるため、GCP側の提供ランタイム変更に影響を受ける恐れあり。 -
CloudRunはDockerfileによりコンテナビルドできる限りランタイム制約無いため、影響なし。 - よって言語やバージョンをGCP側に制約されない
CloudRunがグッド。
-
-
ローカル開発効率
-
GAEスタンダード環境ではdev_appserver.py（ローカル開発用サーバー）を実行する。（Python使用時のみ？） -
Cloud RunではDockerfileを実行し、cloud_sql_proxyを使用してCloudSQLに接続。 - よって
Cloud Runによるコンテナベースでの開発の方が、なじみがあるエンジニアが多く開発効率高いと思われる。
-
-
その他運用面
-
移行時の柔軟性
CloudRunはKnativeがベースとなっており、仮に他インフラ（GKEなど）へのアプリケーションの移行が発生してもスムーズに対応可能。 -
サービス自体の勢い
CloudRun自体に勢いがあり機能拡張されており、またコンテナイメージからのデプロイ用に周辺ツールが整備されているため、今後エコシステムの恩恵を受けやすそう。
-
移行時の柔軟性
懸念点（デメリット）
-
実行タイムアウト
-
CloudRunはタイムアウトはデフォルト５分だが、最大60分まで延長可能。
→ 相当重いワークロードでは無い限り、タイムアウトが制約となる場合はほぼなさそう。制約大きく解消しつつある。
-
-
ファイルの永続化
-
CloudRunではメモリ上でファイル操作するため、ファイルの永続化不可。 -
GAEではCloud Storageなど利用可能。
-
-
コールドスタート（回避可能）
-
CloudRunでは一定時間アクセスがないと自動的にコンテナが終了し0になり、再アクセス時にコールドスタートするためレスポンスが遅延する。（言語やアプリケーションによるが数秒程度？） - 参考：遅延時間について
- ただ、最小インスタンス数を1以上にしてコールドスタート対策も可能。（※ 常時起動するためコストは上がる。）
- （コンテナでなくVMで起動するAppEngineの方がコールドスタート遅いかと思いきや、公式ブログ見た限りはかなり早そう。。このあたり詳しい方いれば教えてほしいです。）
-
-
レスポンス後の処理（回避可能）
-
CloudRunではレスポンス後にCPU割り当てが解放されるため、非同期処理等ができないという点がつらみとしてあった。しかしAlways on CPU機能が実装されたため、この点は解消された。 - 参考：サーバーレス コンテナ Cloud Run に待望の新機能 Always on CPU が登場しました
-
まとめ
- 2019年に発表されて以来、日が浅いうちはつらみも多かったようですがアップデートを重ねてかなり使いやすいサービスとなりました。
- GCP的にも
CloudRunを推しているようで、機能拡張はもちろん他サービスとの統合もどんどん進められており多彩なアーキテクチャを組めるようになっています。 - 今後インフラを検討する上で
CloudRunは有力な選択肢となってきそうです。