1 of 25

大学祭のウェブサイトをGoogle App Engineから

Cloud Run

に切り替えた話

市川詩恩

Shion1305

1

2 of 25

root@world~:$ whoami

username: Shion1305

name: Shion Ichikawa

affiliation: 横浜国立大学大学院 環境情報学府 修士1年 (2024/4~)� 大学祭実行委員(昨年: 技術部局長) / Lumos� 情報安全確保支援士合格(登録セキスぺ申請中)

fields: SWE 80% / Security(Web) 10% / ML 5%

interns: 生成系AI開発インターン @ドリコム

SWE @ 松尾研究室 / R&D @ Poetics� ex: メルカリ / ユニクロ / Flatt Security / ちゅらデータ

2

3 of 25

本日の発表は

大学祭実行委員会

公式の発表ではありません

3

4 of 25

  • 清陵祭 (5月)
  • 常盤祭 (10月)

年2回大学祭を開催。�昨年の常盤祭の来場者数は約9500人。

横浜国立大学

大学祭について

4

5 of 25

技術部局

2023年1月に発足!

「年2回の大学祭のHPを作る!!」

+ 大学祭運営に必要なサービスの開発

22年からHP開発自体は行っていて、

現在運用している大学祭HPは4つ。

22清陵祭HP 22常盤祭HP

23清陵祭HP 23常盤祭HP

5

6 of 25

Google App Engineとは?

「アプリケーションをサーバーレスで提供できるサービス」

  • ローカル環境からコマンド一つ打つだけでアップロードできる
    • アプリケーションの実行環境はGoogleが管理してくれる!
  • 一日あたり28インスタンス時間の無料枠
  • アクセス状況に応じてインスタンス稼働数の調整が可能�15分アクセスがない場合はインスタンスが止まる (自動スケーリング)
  • プロジェクトごとに1サービスのみしか作成できない

6

PaaS �(Platform as a Service)

7 of 25

23清陵祭まで...

  • それぞれの大学祭ごとに�プロジェクトを作成
  • それぞれに違うドメインを割り当て�(プロジェクト間で�同一ドメインに対する�リクエストの分散ができない)

7

seiryo22.

ynu-fes.yokohama

tokiwa22.

ynu-fes.yokohama

seiryo23.

ynu-fes.yokohama

8 of 25

23清陵祭まで...

  • それぞれの大学祭ごとに�プロジェクトを作成
  • それぞれに違うドメインを割り当て�(プロジェクト間で�同一ドメインに対する�リクエストの分散ができない)

8

seiryo22.

ynu-fes.yokohama

SEO

毎回別ドメインとなるため、

それぞれがWebsiteとして認識される

Google検索に表示されるまで

時間がかかる

tokiwa22.

ynu-fes.yokohama

seiryo23.

ynu-fes.yokohama

プロジェクトの乱立

9 of 25

23常盤祭では...

  • 大学祭ドメインを統一化
  • 1つのサービス中で�複数のインスタンスを建てて�ルーティング (GAEの機能)

9

/23/tokiwa/*

ynu-fes.yokohama/23/tokiwa

/stg/23/tokiwa/*

それ以外

本番環境

開発用環境

robots.txt などサイト共通のファイル

10 of 25

23常盤祭では...

  • 大学祭ドメインを統一化
  • 1つのサービス中で�複数のインスタンスを建てて�ルーティング (GAEの機能)

10

/23/tokiwa/*

ynu-fes.yokohama/23/tokiwa

/stg/23/tokiwa/*

それ以外

本番環境

開発用環境

robots.txt などサイト共通のファイル

複数インスタンスを建てた

ことで課金が発生。

クラウド料金が高額に...

11 of 25

Google Cloud Runとは?

「コンテナをサーバーレスで稼働できるサービス」

  • 毎月240,000 vCPU秒まで無料 (=66vCPU時間)
  • アプリケーションをコンテナ化してデプロイする必要がある
  • 100ミリ秒単位でインスタンスのOn/Offが切り替わる
    • インスタンス起動時に「コールドスタート」が発生するため�レスポンスが遅くなる可能性

11

PaaS �(Platform as a Service)

IaaS �(Infrastructure as a Service)

の中間

12 of 25

Cloud Runに対する懸念

12

Google Cloud Run

Google App Engine

インスタンスの

管理方法

100ms単位で�起動状態が切り替わる

15分リクエストがない時に�スケールダウン�(→ピーク時は稼働し続ける)

デプロイ方法

デプロイする際に�アプリケーションを�コンテナ化する必要がある

実行環境は用意されるので�ソースコードのみあれば良い

13 of 25

Cloud Runに対する懸念

13

Google Cloud Run

Google App Engine

インスタンスの

管理方法

100ms単位で�起動状態が切り替わる

15分リクエストがない時に�スケールダウン�(→ピーク時は稼働し続ける)

デプロイ方法

デプロイする際に�アプリケーションを�コンテナ化する必要がある

実行環境は用意されるので�ソースコードのみあれば良い

引継ぎ

コスト大

Dockerの知識が必要。

手順が複雑だとミスに繋がる

レスポンス

時間の懸念

コールドスタートによる

影響が懸念

14 of 25

14

コンテナ化

アプリケーションを

そのままデプロイ

コンテナをデプロイ

様々な設定項目が存在。

コンソール画面上で�全て可視化されている

App Engine

Cloud Run

15 of 25

Cloud Run導入結果

レスポンス時間

コールドスタートによる影響はほぼなし。�初期レスポンス時間 < 150ms以内

コンテナ化による技術的ハードル(引継ぎコスト)

設定を全てGitHubのレポジトリ上で管理することで「見える化」し、�デプロイ作業を全てGitHub Actionsで完結させたことで�開発体験が大幅に向上した

15

コスト削減

サイトが増えても�デプロイ対象のコンテナは一つ。

16 of 25

Cloud Runの構成

16

/23/tokiwa/*

/23/seiryo/*

/24/seiryo/*

その他

23清陵祭HP

23常盤祭HP

24清陵祭HP

静的ファイルなど

本番環境

全体で�1つのコンテナ

17 of 25

Cloud Runの構成

17

/23/tokiwa/*

/23/seiryo/*

/24/seiryo/*

その他

23清陵祭HP

23常盤祭HP

24清陵祭HP

静的ファイルなど

本番環境

/23/tokiwa/*

/23/seiryo/*

/24/seiryo/*

その他

23清陵祭HP

23常盤祭HP

24清陵祭HP

静的ファイルなど

開発環境�(全体)

Cloud Runに移行して�1 プロジェクト内で�多数サービスを稼働でき、�になり、開発体験が向上。

Pull Requestごとのデプロイ

18 of 25

Cloud Run GitHub Actions

18

設定ファイルを全てGitHub上に。�PushするだけでコンテナのBuild & Deploy

Push

Build & Push

Container image

Update

Pull

19 of 25

Cloud Run GitHub Actions

19

変更を

Push

Cloud Runの設定は全てYAMLファイルに。�GitHub上で管理し自動反映。

自動反映

20 of 25

Cloud Run GitHub Actions (PR Review)

20

デプロイ完了次第、�ActionsがPRにリンクを自動投稿

それぞれのリソースを

Actionsから自動作成

21 of 25

Cloud Run GitHub Actions (PR Closed)

21

PRがMergeされたら

GitHub Actionsが�PR作成時に生成したリソースを全て消去

削除に失敗したらPRに通知

22 of 25

Cloud Run GitHub Actions

22

Main / Release

へのPushで更新

自動更新

開発環境�本番環境

23 of 25

Cloud Runへの移行結果

23

App Engineの�インスタンス料金

Cloud Runの�ネットワーク料金

Cloud Runの�インスタンス料金�0

24 of 25

まとめ

24

Cloud Run

(+ GitHub Action)

最高!!!

25 of 25

まとめ

25

  • 同一ドメイン内での複数のサービスの安定的な運用を実現することができた。
  • App Engineの「アプリケーション単位」という制約から抜け出せたことで柔軟な運用が可能となった。
  • サービスの設定をGitHubで全て一元管理し、�全て「Pull Request」経由で行うことでレビュー体制を確立できた!