はじめに
ダイニーは All in One Restaurant Cloud. として今後幅広い事業へと進出していきます。事業が増えたとしても、 ダイニーPOS はそれらの中心に存在し、全てのソフトウェアの基盤となる重要な存在です。
オンライン POS に分類される ダイニーPOSレジ は、全ての端末が常時インターネットを介してサーバーと通信を行う方式を採用しているため、特別オンラインのリソースに依存している構成になっています。この構成はサービス全体のアーキテクチャをシンプルにし、急速な成長を続けるための検証のサイクルを回しやすくしていますが、オフライン対応を進める上でいくつかの課題がありました。
オフライン対応とは
オンラインリソースへの依存度が高い ダイニーPOSレジ では、サーバーやインターネット接続に問題が発生した場合にシステムが普段通り動作しなくなってしまいます。ダイニーPOSレジ では会計処理だけではなく注文の管理も POS サービス上で行っているため、 ダイニーPOSレジ が停止してしまうと最悪の場合、その日の営業を中止せざるを得ない状況に陥る可能性もあります。
サーバーやインターネット接続に問題が発生しても会計処理や注文管理を行えるようにするのがオフライン対応です。前回の記事でレジのオフライン対応について一部ご紹介しました。 ダイニーPOSレジ のオフライン対応はレジのみに留まらず、他の店内端末との連携への対応も行っています。
追加設定なしのローカル通信を目指す
ネットワークがオフラインな環境であっても店内の端末同士が通信・連携できるようにするには、まず端末同士が相互に認識できる必要がありました。しかしダイニーの場合は各端末の設定がオンライン前提であり、オフラインでの相互認識をすぐにできる状態ではありませんでした。
解決策の一つに追加の設定をしてしまうというものがあります。しかし、すでに展開済みの端末に対して追加設定が必要になると、機材準備や機材設置に関する業務を行っているチームがこの追加設定に時間を取られてしまいます。すると以下の理由によりビジネスの成長スピードに影響を与えてしまうかもしれません。
- 新規店舗が運用を決めてからダイニーのサービスを開始するまで長い期間待つことになる
- 通常業務に支障の出ない範囲で取り組んだとしても、本来であれば業務のカイゼンに充てることのできたリソースが消耗されてしまう
そこでダイニーでは、追加設定なしでのオフライン連携の実現を達成しています。これにより既存店舗への訪問を大幅に削減することができ、新規導入時のセットアップコストも従来通りのものを維持することができました。
今回はキッチンプリンターとハンディについて、それぞれレジとの連携をどのように行ったのかご紹介します。
1. キッチンプリンター：「ゴリ押し総当たり作戦」
キッチンプリンターは普段モバイルオーダーからの注文をキッチンに伝える手段として利用されています。オフラインのときであってもプリンターを識別して伝票を的確に印刷することが求められます（例：焼鳥の伝票は焼き場へ、ビールの伝票はドリ場へ）。オフライン時はレジに注文が集約されるため、レジからプリンターに印刷指示を飛ばします。
キッチンプリンターを認識するために以下の方法を採用しています。
- オンライン時に取得した設定情報を利用
- ローカルネットワーク内のプリンターに対して総当たりで設定内容の取得を試行
- MAC アドレスと設定内容の対応表をキャッシュとして保持
設定内容を取得するリクエストに必要な情報はオンライン時に取得することができました。しかしどのプリンターに対してどの情報を使えば良いのかは設定内容が取得できるまでわかりません。幸い、SDK によってローカルネットワーク内にあるプリンターの IP アドレスと MAC アドレスの一覧までは取得できているため、プリンターが存在する IP アドレスにのみリクエストを送ること自体は可能でした。そこで、手元にあるリクエストのための情報がそれぞれのプリンターに適合するまで総当たりで確かめていくことにしました。 IP アドレスは可変ですが MAC アドレスは不変なのでキャッシュのキーとして有効に働いてくれるため、一度でも取得できれば次回以降はピンポイントで設定内容を取得しにいくことが出来ます。
総当たりで試すということは設定内容取得に必要な情報が不正な端末にも送信される可能性があることを意味しますが、以下の理由から許容できるリスクという評価をしています。
- SDK によって対応しているプリンター端末のみをリクエスト送信の対象にしている
- 設定内容取得に必要な情報自体はそのプリンターに物理的に触ることができれば入手できるため、秘匿の必要性がそこまで高くない
- 通常は店内端末用の Wi-Fi は来店客に開放していない
2. ハンディとの連携：「mDNS でスマート解決」
ハンディとは飲食店のホールスタッフが手元から注文を入力したり卓の状況を確認できたりする端末のことです。オフライン時はレジに注文を集約させるため、ハンディはレジに対して注文を直接送信する必要があります。そのため、ハンディが的確なレジ端末を発見する方法が必要になりました。プリンターと異なり、レジとハンディ両方に追加の実装を行うことができたため多くの選択肢がありましたが、今回は mDNS （マルチキャスト DNS）を利用しました。
mDNS は、ローカルネットワーク内でホスト名を解決するためのプロトコルです。 IP アドレスの他に追加のペイロードを付与することができるため、自身が対応している機能の宣言をすることができます。 Apple の AirPlay には音楽の再生やスクリーンミラーリングなどの機能がありますが、それぞれに対応しているものだけをデバイス一覧に表示できるのは mDNS （あるいは類似の仕組み）のおかげです。
ダイニーでは以下のように mDNS を利用しています。
- レジが店舗 ID を含む mDNS レコードを登録
- ハンディ端末が mDNS クエリを使用して同じ店舗のレジの IP アドレスを特定
- 特定した IP アドレスに対して TCP 接続を確立
これにより、ハンディがレジを発見するために追加のリソースを必要とせず、完全にローカルネットワーク内に完結した状態で通信を確立できるようになりました。
まとめ
ダイニーでは既存のインフラを活用しつつ、追加設定なしのローカル通信を実現しました。同一ローカルネットワークに属していない端末との連携ができないため、店内の配線に手を加える必要が生じた店舗もありましたが、追加設定がある場合と比較するとコストを大きく減らすことができました。中には泥臭い方法もありましたが、ビジネスのスピードを落とさないための工夫であれば、多少効率が悪くても許容するべきかもしれません。
We’re hiring!
ダイニーでは技術的なアプローチからビジネスを支えたいというエンジニアを募集しています！
Discussion