【GCP】Cloud RunとApp Engineの比較

背景

これまでクラウドの経験は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は有力な選択肢となってきそうです。