はじめに

AI 在庫管理のフロントエンドの開発を主に担当している鳥海です。今回は AI 在庫管理のフロントエンドでシングルページアプリケーション (以下、SPA) における強制リロード戦略を考え、実装したので、 AI 在庫管理での強制リロードの仕組みについて、変遷を交えながらご紹介させていただければと思います。

なぜリロード戦略が必要なのか？: SPA におけるアセットが変わらない問題

よく知られている問題だと思うのですが、SPA ではページに再訪するか、リロードしない限り、クライアントで利用されるアセットが更新されない問題があります。これによって下記のような問題が発生する可能性があります。

障害時に、フロントエンドのコードを修正したのに、復旧したバージョンをすぐに利用してもらえない
新規機能リリース後に、新規機能が入ったバージョンをすぐに利用してもらえない

リロード戦略 v1: 一斉に強制リロード

リロードの仕組み

リロード戦略 v1 では、下記仕組みで強制リロードを実施していました。

feature flag の情報として、最小バージョンを取得
feature flag のバージョン情報とクライアント側で利用しているアプリのバージョン情報を照合
feature flag のバージョン情報の方が新しいバージョン情報の場合に強制リロードを発動

強制リロードについては、上記の発動条件に合致し次第発動される形となっています。イメージは、下記画像のようになっています。

見えてきた課題

1 年ほど、この方法で運用していたのですが、下記課題がしだいに見えてきました。

課題 ①: 日中帯に障害が起こり、復旧時に強制リロードをかけるとバックエンドに負荷が集中する
課題 ②: 新機能がリリースされているにもかかわらず、ユーザーによっては使われていない可能性がある

これらの課題が見えてきたので、強制リロード戦略として、今回検討した方法についてご紹介していきたいと思います。

リロード戦略 v2: 緊急時の分散強制リロード + 定期リロード

前述の課題 ①,② から、それぞれを解決する形でリロードの発動ロジックについて検討してみました。

緊急時の分散強制リロード

まず、課題 ① に上がっていた負荷が集中する問題については、ユーザー毎に保持している ID をうまく利用することによって発動タイミングを分散させる方針としました。発動タイミングの分散方法については、下記手順となっています。

最大リロード待機時間を設定
ID と最大リロード待機時間を用いて、ユーザー毎の待機時間を計算
計算されたユーザー毎の待機時間後に強制リロードを発動

このイメージは下記のような形となっています。

定期リロード

次に、課題 ② に関してですが、こちらはサインアウト時にリロードされる仕組みにしています。アプリケーション毎にセッションタイムアウトまでの時間が設定されているので、定期的に実行されるかつ、サインアウト時はリロードしてもユーザーへの影響が比較的軽微なことから、このタイミングで実行されるように実装しています。

まとめ

今回は B2B サービスにおける強制リロード戦略の一例として、ご紹介しました。現状、この戦略については問題なく運用されているので、うまく改善できたのではないかと考えています。また、これからユーザーとの対話を通じて、アップデートしてさらに良い仕組みとしていければと思っています。定期的なサービスアップデートと同時に、緊急時の安全な復旧をするための強制リロードの戦略するためには、このような検討事項もありそうだとご参考になれば幸いです。最後まで読んでいただき、ありがとうございました。