シンプルなシステム構成のまま、大規模アクセスにも対応する ー テックリードが明かす失敗経験から学んだ『仮想待合室』の裏側

2020年以降、コロナ禍を通して各団体でDXが推進されたことで、kintoneとFormBridgeを利用いただく自治体や大企業が増加しています。
利用方法は、ワクチン接種の予約フォームや助成金の申請フォーム、企業のキャンペーンフォームなど大人数からの急なアクセスが見込まれるケースも多々ありました。

そういったスパイクを伴う大規模なアクセスにより発生する課題点を改善するためリリースした「仮想待合室」の裏側について、テックリードの北川さんに話を聞いてみました。

ーそもそも仮想待合室とはどんなサービスなのでしょうか。

ユーザーに混雑状況と待ち時間の目安を表示し、順番が来たら自動的に目的のページに案内するシステムです。
細かい部分はサービスごとに異なりますが、当社のサービスは最初にアクセスした時点で順番が決まり、再読み込みしたり接続が切れても1時間は最初の順番を維持することが出来る仕様になっています。

サービス特設サイトはこちら：https://www.kintoneapp.com/step-up/waiting-room

ーサービスをリリースするきっかけを教えて下さい。

簡単に言うと、コロナワクチンに関する案件で想定以上のアクセスが来たことによりFormBridgeがシステムダウンしたことがきっかけでした。インフラを拡張させたり、マンパワーも使って残業も発生しながら対処したのですが、力及ばずで顧客にとっても当社にとっても機会損失があり、それを乗り越えるための仮想待合室リリースとなりました。
過去の実績ではシステムダウンしたことがなかった、かつ当時は大量アクセスに対するオプションの事前申請もあったため大丈夫だろうという、今思えば甘い想定だったと思います。

ーシステムダウンを背景に『仮想待合室』のリリースとなったわけですね。

そうですね。詳しく話すと3点にまとめられます。

1点目は顧客の機会損失。
分間アクセスを制限の仕組みは元からあり、制限の中でも時間をかけさえすればエンドユーザーが回答仕切れる想定でした。
しかし、コロナワクチン予約フォームなどの受付開始と同時にアクセスが殺到するシステムでは想定をはるかに超えるアクセスがあり、サーバーで予期せぬ事象が次々発生しました。最悪の場合、ページの表示もできない可能性がありました。

2点目は運用コスト。
コロナのピーク時は事前にアクセスが集中する時間を検知し、安定稼働できるようにサーバーをスケールアウトさせるという工程を週に何度も行っていました。当時は4名体制という大規模アクセスの運用としては少ない人員で、かつ手動の作業を行っていたので、かなり時間も手間もかかっていました。
手動でのスケールアウトは様々なサーバーリソースを拡充する繊細な作業なので、当然ミスした場合の影響範囲も大きく、神経をすり減らしながらの作業でした。

この件をきっかけにインフラ作業を自動化する仕組みを積極的に取り入れるようになりました。

3点目はエンドユーザー体験の見直し。
元からあったアクセス制限の仕組みに関して、エンドユーザーの体験として良くなかった点も挙げられます。
制限中はエラーとしてページが表示されますが、フォーム提供者の契約条件によりアクセスを許可できないという旨が伝わらず、障害が起こっているように見えていました。
これも仮想待合室では改善をされている点になります。

ー『仮想待合室』のリリースが決まり、テックリードとしてプレッシャーなどはありましたか。

正直プレッシャーはほぼ感じていなかったですね。
あいまいな記憶ですが、新サービスに挑戦できる楽しさだったり、これまでの手作業がなくなるのであれば楽になるというような感情を抱いていた気がします。

その一方で、責任者として当社のFormBridgeを選んでくれた顧客の期待に応えられなかったというネガティブな気持ちにもなりましたね…

ーリリースまでの道のりを教えて下さい。

前提として、当社ではデザインドックをベースに開発を進めています。今回の仮想待合室も同様に、PdMが要件定義と仕様の草案を決め、各項目ではなぜそうしたかの意思決定の記録を残しながら進める流れです。具体的には技術検証、アーキテクチャ設計、基本設計(データ構造、API仕様、負荷試験設計など)、詳細設計(各機能の細部についてのHowが多め)、実装、テストと進めました。

開発にあたっては、トヨクモとして初めてかつユーザーインパクトの大きいサービスのため、CTOと私を含むテックリード2名で動くことに決まりました。
進め方としては3名が各々役割があり、会議の場で持ち寄って議論する形で、私は骨格部分の技術的な調査、選定、実現性の検討、コストとのバランスを担当しました。

ー最も困難だったことはなんでしょうか。

初期段階が一番難しい部分でした。
技術検証とどんなアルゴリズムで仮想待合室を実現するかとアーキテクチャ設計の段階で、特に設計の部分は3名でレビュー会を何度も行いました。
具体的には自社サービスであるFormBridgeとの連携を加味し、通常とは異なる要件を実装することが困難を感じたポイントでした。会議は2,3時間続くときもあり、リリースまで3名で頭を悩ませながら議論をした記憶があります。

この3名で何か1つのことをするって初めてのことだったんですけど、立場関係なく互いに同列で話をしてうまくチームワークを発揮できたと思います。


ー開発者から見た、トヨクモ仮想待合室の推しポイントはなんでしょうか。

エンジニア目線だと、複雑で高難度な処理を自分で書かずに、AWSリソースを適材適所で使い分け比較的誰にでも運用しやすい構成になっている点かと思います。
AWSのサービスの特性を生かし、複数機能（ElastiCache, Lambda, CloudFront Functions, SQS, API Gatewayなど）を組み合わせることで複雑で高難度なサービスの実現と運用面の改善が可能になりました。

顧客目線で言えば、Cookieに保存された待ち状況を保存しているのでリロードしても順番の並び直しなどの状況変化が起きないように実装している点です。引き続き多くの顧客に利用してもらう中で発見される問題点も出てくると思うので、より良いサービスとなるよう改善し続ける予定です。

ー最後に今後の展望を教えて下さい。

仮想待合室は安定的により大規模な案件に対応可能にしていくことです。

個人としては待合室の開発・運用を別の人に委譲することですかね。なので中身は出来るだけシンプルにすることを意識し、日々設計をしています。

自分がいなくなっても誰かが仕事を引き継ぎやすい状況を作り続けるのが良い仕事ぶりだなと思います。