GASのモックから作り直した社内向けWebシステムをIAP付きCloud Runで運用

社内向けに、スプレッドシートをデータソースにした小規模なWebシステムを運営しています。最初はGoogle Apps Script（GAS）のHtmlServiceで画面や操作感を確認するためのモックを作り、データ取得もgoogle.script.run経由で試していました。

ただ、このモックの段階でGAS特有の制約に何度か当たりました。画面はサンドボックスiframeの中で動くので、alert()やconfirm()はブロックされ、確認ダイアログひとつでも自前でUIを組むことになります。またGASにはユーザーごとの同時実行数が30、スクリプト全体では1,000という上限があり、本番で使うならここも気になるところでした。

そこで、モックで固めた見た目や操作感は活かしつつ、コンテナで動かせる構成に本番用として作り直すことにしました。そのデプロイ先としてCloud Runを選んでいます。

• Google Apps Script（GAS）のHtmlServiceによるウェブアプリ機能

• GASのサンドボックス制約（alert()やconfirm()が使えないなど）を受けずにフロントを実装できるか
• 同時実行数を自分たちで調整できるか
• モックで作った見た目や操作感をどこまで活かせるか
• コンテナベースで動かせて、保守運用の手間が小さいか

Dockerベースのアプリケーションをそのまま動かせるので、GASのランタイム制約から離れられます。フルマネージドなので運用の手間も小さく、リクエストがない時間はゼロまでスケールインしてくれるためコストも抑えられます。モックの画面をほぼそのまま持ち込めて、作り直しの手間が小さくて済んだのも決め手になりました。

GASのサンドボックス制約がなくなったことで、モーダル表示やフィルタリングなど、モックの段階では実装しづらかったUIをそのまま作れるようになりました。同時実行数についても、固定の上限に縛られるのではなく、コンテナあたりの最大同時リクエスト数や最大インスタンス数を自分たちで設定できるようになっています。本番化してからは大きな障害もなく、安定して稼働しています。

今回は社内向けのWebシステムを題材にしましたが、コンテナをそのまま動かせるので用途はこれに限りません。インフラの運用に手をかけずにアプリケーションを動かしたい場合に向いていて、アクセスが一定しない用途ならゼロまでスケールインする分コストも抑えられます。アクセス制御をIAPに任せるか、アプリケーション側で持つかは先に決めておくと、認証まわりの手戻りが少なくなると思います。