JX通信社シニア・エンジニアの@shinyorke（しんよーく）です.
ちょっと前のお話になりますが, JX通信社のニュース速報アプリ「NewsDigest」で, 「AIワクチン接種予測」という新機能の提供を開始しました.
「自分がいつコロナワクチンを接種できるか?」を簡単に予測できるサービスです. 使っていただけると嬉しいです🙏
大変ありがたい事に,「AIワクチン接種予測」はリリース後多くの反響を頂いていまして,
- リリースから約半月で利用回数が100万回を突破（プレスリリース）.
- 同じく, リリースから半月で20本以上ものTV番組で紹介
と, 多くのユーザーさんにお使いいただきました. ありがとうございます🙏
これだけ多くの方に使っていただくとなると,
- リクエスト数・ユーザー数の増減に合わせたコンピューティングリソースの配分
- 特に, 「TV経由で認知したユーザーさんが一気にやってくる」という急激なトラフィックの増加（いわゆるTV砲）に耐える構造と運用
が重要となってくるのですが,
「AIワクチン接種予測」はGoogle App Engine（GAE）の基本的な設定でTV砲のアクセス増から無事サービスを守りきりました.
私はこのプロジェクトにおいて, プロダクトマネージャー兼エンジニアをさせていただきましたが, ひとまずこの山を乗り越えてホッとしています.
このエントリーでは,
- 「AIワクチン接種予測」のざっくりなアーキテクチャ
- 「TV砲をさばく」ためにやったこと
を可能な限り紹介します.
TL;DR
瞬間風速でやってくるトラフィックはApp Engineの基礎を知っていればいい感じにさばけます
おしながき
このエントリーで扱うこと（扱わないこと）
このエントリーでは「AIワクチン接種予測」の以下の話について扱います
- Google Cloud Platform（GCP）まわりのアーキテクチャ話
- Google App Engine（GAE）に関するTips
上記の話題に関して網羅的に扱います.
また, 以下の件については後日公開予定（もしくは非公開）とさせてください.
- フロントエンド関連の話題
- 予測モデルの内容および運用に関する全般的な話題
ご了承ください🙇♂️
AIワクチン接種予測のアーキテクチャ
全体像
AIワクチン接種予測のプロダクトは,
- Next.js + TypeScript（フロントエンド）
- Flask, Fast API（バックエンド）
- App Engine（一部Cloud Run）
で構成されています.
ざっくりな全体像はこちらです.
ホントはストレージやCDNなど, 「一般的なWebサービスでいるもの」も当然いますが図では割愛しています🙇♂️
ポイントとしては,
GAE（一部Cloud Run）の採用により, スケールしやすい構成を取ったことです.
この構成のおかげでTV砲対策（一時的なインスタンス増加）がすごくやりやすくなりました.
App Engineを全力で使う
AIワクチン接種予測のプロジェクトではGCP, 特にGAEを全面的に採用しました.
サービス構成を決めるにあたり, 社内で何人かのメンバーに相談した結果,
- シンプルなアプリケーションになりそうなので, 全力でサーバレスを前提としたアーキテクチャに乗っかれそう
- 一時的な負荷増に対する対策（例えばメディアに取り上げられるなど）とかも楽にできるといいよね
という視点で考えた結果, チーム内で提案（と使いたい要望）があったGAEに決まりました.
私も, 以前在籍したベンチャーでGAEを運用した経験があり, GAEの利点（と辛み）を理解していた（かつ私もメッチャGAEを使いたかった）のでアッサリとGAE採用を決めました*1.
構成図の通り, フロントエンドとバックエンドの主要サービスはGAEにしたのですが, バックエンドの処理の一部（画像生成など）でGAEでやるにはややこしい部分*2があったので一部の処理をCloud Runで構築するなどしました.
実践・TV砲対策
実際のTV砲対策を（話せる範囲で）紹介します.
「AIワクチン接種予測」はNewsDigestのイチ機能としての提供であるため,
- AIワクチン接種予測本体（GAE + Cloud Run）の負荷対策
- 接種予測に至るまでの導線を提供する, NewsDigest（のバックエンド）の負荷対策
- 広報, セールス等を含めたTV出演情報の共有（メディア対策もあるが障害時のエスカレも含む）
これらを出演の度に行いました.
App EngineとCloud Runの負荷対策
GAEとCloud Runの対応は,
TV出演でトラフィックが増えそうな時間帯に限り, インスタンスの数で押し切る（&トラフィックが落ち着いたら元に戻す）
というシンプルな対策で乗り切りました*3.
より具体的には公式ドキュメントを参考に,
- TV出演の前に, GAEの
app.yamlのmin_instancesおよびmax_instancesの数を増やす - TV出演が終わり, トラフィックが落ち着いた頃合いで上記パラメータを元に戻す
これらを愚直にやりました.
なお作業はシンプルで, 定義値を変更したapp.yaml を含んだアプリをデプロイする. たったこれだけでした.
基本的には公式ドキュメントを読んで,設定を決めて対応しました*4.
また, Cloud Runの負荷対策も似たような感じで,
- Cloud Runのコンソールでインスタンス数（最小・最大）を適切な値に設定
- 上記を再デプロイ（ボタン一発）
これで終わりました.
私が携わるプロジェクトでCloud Runを採用したのは初めてでしたが, GAE同様違和感なく対応できてよかったです.
NewsDigestの負荷対策
AIワクチン接種予測に訪れるユーザーさんは必ずNewsDigestの導線を通ることになるので, NewsDigestの負荷対策も重要なタスクの一つでした.
以前はNewsDigestの構成を知っているメンバーが負荷対策をしていたのですが, TVでの露出が多くなると知ってる人に頼るのもどうかなー？と, SREのたっち(@TatchNicolas)さんに相談した結果,
- 負荷対策の手作業オペレーションを社内ツール化して半自動化. 具体的には手元でスクリプトを叩けばOKぐらいに簡略化
- 上記の社内ツールを担当者（今回は私）にハンズオンして引き継ぎ
...といった事を爆速で行ってくれました（圧倒的感謝）.
このおかげで今まではNewsDigestの負荷対策を中身を知ってるメンバーにお願いしてたのですが, 私自身がコマンド一発でできるようになりました.
これぞDevOpsの醍醐味ですね, 素晴らしい.
ちなみにこの話を相談したのがリリースした2/15から間もない頃で, 翌日には爆速で仕組みができあがっていたので, 流石に驚きました.
TV出演スケジュール管理
今回はTVに連続して出る, という状況が続いたのでスケジュール管理が重要でした.
スケジュール管理はCTOの柳さんを中心にトライアルで導入を進めている, 今流行りのNotionを活用しました.
具体的な利用・感想については, AIワクチン接種予測に色々協力いただいた藤井さんが背景も含めた素晴らしいnoteにまとめていただいたのでこちらをご覧いただけると幸いです.
Notionの該当ページを見たら「出演時間」「内容」「負荷対策やってますか?」的な内容・チェックリストが確認できる仕組みだったのでとても楽でした.
結び
今回は「AIワクチン接種予測」の, 主にインフラやTV露出対策をどうしたか?というお話を紹介しました.
AIワクチン接種予測のプロダクト単体で言えば, 「GAE採用してよかった」というオチになるのですが,
- NewsDigest本体の負荷対策をカイゼンしてくれたり
- Notionを中心とした情報共有・オペレーションの最適化をしたり
といった, チーム力が生きたと思いますし, これが何よりもの「TV砲対策をらくらくにした真の理由」だったのかなと思っています.
また, 今回のプロジェクトではフロントエンド・サーバーサイド両方でエンジニアインターンの皆さんが活躍してくれました（圧倒的感謝）.
JX通信社ではインターンの皆さんもユーザーさんに直接価値を届けるような開発タスクができます, ご興味ある方はぜひカジュアル面談来てください.
最後までお読みいただきありがとうございました！
