目次
はじめに
こんにちは！ 食べログ開発本部 ウェブ開発1部 FEチームの佐々木です。
私たちが開発している食べログノートは、レストラン向けのオンライン予約台帳です。ネット予約、電話予約、ウォークインの管理、顧客管理、卓管理などを一元的に行えるツールです。
その中でも特に重要な機能がタイムスケジュール画面です。この画面は、食べログノートの中でも最もよく使われる機能です。登録された卓と予約時間を表示し、ドラッグアンドドロップで卓や時間の変更が簡単に行えます。
今回の記事では、このタイムスケジュール画面において、WebSocketを使用せずに（ほぼ）リアルタイム更新を実現した取り組みについて詳しく紹介します。
リアルタイム化の必要性
予約状況のリアルタイムに近い更新は、ユーザーエクスペリエンス（UX）を向上させます。以前の実装では、1分間に1回単純にポーリングを行っていたため、新しい予約が入った際に最大1分間待つか、手動で更新しないと新しい予約が画面に反映されませんでした。これでは今すぐ最新の予約を見たい場面では不便です。
例えば1店舗で複数のiPadを使用して予約の確認・更新をしている場合、それぞれのデバイスでの更新を待ちながら作業する必要があり、とても効率が悪いです。また、食べログノートの導入店舗数が増加し、新機能の導入も見込まれているため、早めにこの問題を解決する必要がありました。
解決策の検討
予約状況の更新に必要な速度を検討
解決策を検討する前に、そもそもどのくらいの更新速度が求められるかについて、企画とエンジニアが共に検討しました。その結果、予約状況の更新が5秒以内に行われることを目標とすることに決定しました。
実装案のブレスト
上記の目標を達成するための実装案を、フロントエンドエンジニア、アプリエンジニア、バックエンドエンジニアがMiro上でブレストし、松、竹、梅の案を出しました。
以下はブレスト時のMiroです。
表にまとめると以下のようになります。
| 案 | 内容 | メリット | デメリット |
|---|---|---|---|
| 松 | GraphQLのSubscription(WebSocket)を利用する | リアルタイム更新が可能 | 実装が複雑 |
| 竹 | 予約状況の表示に必要なデータの最終更新日時を5秒間隔でポーリングして、変わっていたらデータを再取得する | 実装が比較的簡単で、リアルタイムに近い更新が可能 | 完全なリアルタイムではない |
| 梅 | ポーリング間隔を1分間隔より短くする | 定数を修正するだけなので実装が最も簡単 | RDBに高頻度でクエリを実行することになるので負荷がかかる |
採用するアーキテクチャの決定
今回のアーキテクチャ選定において、最もバランスが取れていると判断したため、竹案を採用しました。竹案であれば既存システムに大きな変更を加える必要がなく、実装が比較的簡単である点も魅力的でした。
食べログノートではバックエンドとの通信をGraphQLで行っているため、Subscriptionを利用する松案も検討しましたが、Subscription用のシステムを新たに実装する必要がある点から、必要な要件（更新間隔が5秒以下）に対してコストがかかりすぎると判断しました。ここで重要だったのは、必要な要素（リアルタイム性の程度）を見極めて最適な解決策を選ぶことでした。完全なリアルタイム性が求められていなかったため、竹案が最も適していると判断しました。
実装の詳細
今回の実装を図で説明すると下記のようになります。
バックエンドAPIの動作
- 食べログや食べログノートから予約状況の表示に必要なデータ(予約データや卓データなど)の登録・更新リクエストが来ると、バックエンドAPIはデータベースを更新します。
- 同時にMemcachedに最終更新日時を保存します。
- 予約データの最終更新日時は「店舗ID＋予約日」をキーにして保存します。これはタイムスケジュール画面が日付ごとに予約を表示しているためです。
- その他のデータの最終更新日時は「店舗ID」をキーにして保存します。
Webページ・アプリの動作
- Webページ・アプリは5秒ごとにバックエンドAPIから予約状況の表示に必要なデータの最終更新日時を取得します。
- 取得した最終更新日時とWebページ・アプリが持っている最終更新日時を比較します。
- 異なっていた場合、予約状況の表示に必要なデータを再取得します。
リリース戦略
データの最終更新日時の取得間隔を元の実装と同じ1分から段階的に短くし、最終的に5秒にしました。短くしていくごとにサーバー負荷を確認し、問題ないことを確認しました。
リリースによる効果
5秒以内に予約状況が反映されるようになり、ユーザー体験が大幅に向上しました。企画や営業からも好評で、営業の現場でのデモンストレーションがやりやすくなったとの声が寄せられています。以前は予約を入れてから表示されるまでに1分間待つ必要があり、手動で更新するなどの手間がかかっていました。今回の改善により予約の反映がスムーズになり、自然なデモンストレーションが行えるようになりました。
まとめ
今回は、食べログノートのタイムスケジュール画面における更新速度の最適化について紹介しました。以前の実装では、1分間に1回のポーリングによる更新遅延が発生していました。今回の取り組みにより、5秒間隔のポーリングを導入することで、ほぼリアルタイムの更新を実現しました。これにより、ユーザーがストレスなく予約状況を確認できるようになりました。
また、実装案のブレインストーミングを通じて、必要な要素（リアルタイム性の程度）を見極め、最適な解決策を選ぶことができました。最終的に、既存システムに大きな変更を加えることなく、バランスの取れた解決策を採用できました。
今後も引き続き、ユーザーの利便性を追求し、さらなる機能改善に取り組みます。
最後に
最後まで読んでいただき、ありがとうございました。
食べログではエンジニアを募集しています。気になった方は是非下記の採用リンクをチェックしてみてください！
おまけ（メディア掲載の紹介）
先日、「レバテックフリーランス」にて、Tabelog Tech Blogをご紹介いただきました！
食べログを始め多くの企業のテックブログが紹介されている有益な記事なので、ぜひご覧ください。
これからも開発者の皆さまの役に立つ記事を精力的に執筆してまいりますので、今後ともよろしくお願いします。
