店舗システムのクラウドに関する考察

本記事では、店舗 PC／ストアコンピューターや POS といった店舗に配置されているワークロードを、AWS で稼働させるにあたってのメリットやワークロードの特性から考えられる構成と、実現に向けてどういった検討が求められるかについて、店舗 PC／ストアコンピューターが AWS で稼働する場合の可用性と応答性能に焦点をあてて考察します。

はじめに：店舗システム

店舗では、様々な業務が行われていて、そのための情報システムが利用されています。商品の販売時点の情報を管理する POS や、商品の発注・廃棄登録、店舗スタッフのシフト・出退勤管理といったシステムが挙げられますが、主要な店舗業務のシステムは、店舗に設置されている店舗 PC ／ストアコンピューターで動作しているケースは多くあります。

ストアコンピューターは、独立して動作しているわけではありません。クラウドやオンプレミスのデータセンターで動作するシステムと連携しています。例えば、商品発注に基づく物流システムとの連携や、商品や顧客分析といった情報系システムとの連携があります。

ストアコンピューターが利用されている場合の概念的なシステムの配置は以下の通りとなります。文字通りストアコンピューターは店舗毎に設置されるため、コンビニエンスストアやスーパーマーケットなど多店舗展開している小売業では、多くのストアコンピューターが配置されています。

店舗システムをクラウドで稼働することのメリットと懸念

近年のクラウドコンピューティングの技術進歩によって、クラウドで動作させようとするシステムの対象は拡大していますが、店舗システムも例外ではありません。ストアコンピューターをクラウド化することによって、ハードウェアが不要になることによるコスト削減や、システム集約化による運用の効率化、データ活用のし易さによる機能の高度化といったメリットが考えられます。その一方で、各店舗に分散配置されていたシステムが、クラウドに集約されて配置されることで、障害発生時の影響範囲を全体に波及させないための可用性や信頼性の設計、これまでの店舗内で完結していたワークロードがクラウドにアクセスされることによる応答性能について対策を講じる必要があります。

メリット
- コスト削減（ストアコンピューターレス）
- 運用効率化（システム集約化、ハードウェアライフサイクルからの解放）
- 機能の高度化（データ活用のし易さ、ハードウェアリソース制約からの解放）
懸念
- 可用性、信頼性（障害時発生影響）
- 性能（応答性能）

補足：店舗システムは、クレジットカードをはじめとした決済機能を持つので、決済系のネットワークとの接続について考慮する必要がありますが、本記事の冒頭の述べている通り、決済については扱わず、ストアコンピューターについて考察します。

懸念に対する対策

これら懸念について、可用性や信頼性の対策としては冗長化があります。AWS グローバルインフラストラクチャは、あらゆるアプリケーションに対応し、最も安全で、拡張性の高いインフラストラクチャを提供しているので、要件に応じたシステム構成を実現できます。例えば、今や生活に欠かすことのできないコンビニエンスストアや薬を扱うドラッグストアでは、災害発生時においても、生活インフラとして営業を継続することが期待されます。そのためには、システムも DR サイトを構築して備えておくことは考えられますが、AWS ではマルチリージョン構成を取ることにより実現できます。

システムとしての可用性や信頼性を高める対策は他にもあります。店舗の POS や端末に、店舗業務を実施する上で最小限のデータを保持する、いわゆるキャッシュさせておくことで、ネットワークやクラウドが一時的に利用不可となった場合でも店舗業務を継続することができます。反対に、POS データのような店舗で発生するデータについて、リアルタイムなデータ活用のため継続的にクラウドに送りストリーミングデータとして扱うことが期待されますが、バッファリングや再送を組み込むことによって店舗業務を継続できます。

補足：障害の典型的なパターンはネットワーク通信が不可能になる場合ですが、決済について、ネットワーク通信が不可欠な決済手段については機能を停止するといった機能切り替えは必須となります。

キャッシュのメカニズムは、性能についても効果的です。頻繁にアクセスされるデータを都度クラウドにアクセスしないことで応答性能は短縮されます。一貫性のある応答性能を実現するために、店舗とクラウドのネットワーク接続について、インターネットを利用しない接続形態が期待されるケースがありますが、広域通信網（WAN）と AWS Direct Connect を組み合わせたネットワークを実現することもできます。

マルチリージョンによる冗長化や、端末側にキャッシュなどを取り入れた場合の構成イメージは以下の通りです。

店舗システムのクラウド化実現にあたって検討が必要なこと

具体的に店舗システムのクラウド化を実現していくにあたっては、インプットとなる可用性や信頼性、性能の要件はもちろんですが、ワークロードの特性に応じた適切なクラウドサービスの選択、キャッシュ等の端末の実装について検討が必要です。また、マルチリージョン構成による DR サイトを構築する場合は、切り替え方針についても考えなければなりません。

ここでは、多くのケースでは検討されるであろう以下について、それぞれ解説します。

ストアコンピューターのクラウド配置方式（集約・分離単位）
冗長化の対象範囲と DR サイトの切り替え方式
端末のキャッシュやバッファリング実現方式

1. ストアコンピューターのクラウド配置方式（集約・分離単位）

ストアコンピューターには店舗業務のための様々な機能やデータが店舗単位で管理されているので、ストアコンピューターをクラウドで動かす場合には店舗や機能の集約・分離単位といった配置方式を考える必要がありますが、分離の考え方として、店舗単位と機能単位があります。

ストアコンピューターの配置構成をクラウドで実現している店舗単位の分離と異なり、機能単位で分離しているパターンは、機能に変更が生じた場合に店舗毎にリリースする必要はありません。また、機能毎の要件に応じた冗長化構成を用意できるので、店舗単位で分離する場合と比較して、リソース面と運用面において集約化による効率化がより期待できます。

その一方で、何らかの障害によってある機能が利用できなくなった場合、店舗単位で分離しているパターンの影響範囲は店舗に限定されますが、機能単位で分離しているパターンの影響範囲は全店舗となります。

店舗単位で分離しているパターンは、ストアコンピューターの配置構成をクラウドで実現しているため、機能単位で分離するパターンと比較すると運用の変化は少ないですが、店舗の事業形態としてフランチャイズ制を取り入れている場合のシステムの利用料といった技術面以外も含みます。

それぞれの配置方式の特徴は以下になります。一方のメリットは、もう一方のデメリットになるのでメリットについて記載しています。

店舗単位で分離
- ストアコンピューターの配置構成を実現しているので運用の変化が少ない
- 何らかの障害における影響範囲が該当店舗に限定される
機能単位で分離
- 機能毎の要件に応じた構成を用意できる
- リソース面や運用面において集約化による効率化がより期待できる

それぞれの特徴と何を優先させるかについて、両方の組み合わせも含めて検討し、この後に解説している冗長化の対象範囲について考えていきます。

2. 冗長化の対象範囲と DR サイトの切り替え方式

冗長化については、前述の通り可用性や信頼性の要件がインプットとなりますが、ハイレベルでは想定する災害と、システムの影響範囲に基づいて構成が決定されます。

想定する災害（例）	影響範囲	対策の方向性
落雷による停電	AZ	異なるAZとの間でどう構成を組むか
関東一帯が影響を受ける災害	リージョン	大阪リージョンを含む別リージョンとの間でどう構成を組むか
日本国内の大部分が影響を受ける災害	リージョン	国外のリージョン（例：シンガポール）との間でどう構成を組むか

検討にあたっては、業務の BCP に基づきシステムの冗長化を整備していく必要があります。店舗での発注が、下図のように、発注推奨量の確認→注文→取引先との連携というステップで行われ、それぞれのステップで別々のシステムが用意されているとします。注文システムだけ DR サイトが構築されている状況で災害が発生した場合、発注推奨量は確認することができないものの注文することはできますが、取引先と連携できないので発注は完了しません。取引先との連携システムに DR サイトを用意すると発注は完了できますが、商品が店舗に届くためには、物流網が途切らせないための整備も進めていく必要があります。

冗長化として、AWS でマルチリージョン構成をとる場合、復旧要件である目標復旧時間（RTO）や目標復旧時点（RPO）からアクティブ / パッシブと、アクティブ / アクティブといった構成を決定します。

どの構成でもいざという時に DR サイトにリカバリーできなければなりません。Amazon Route 53 Application Recovery Controller を使用すると、マルチリージョン構成に限らず、マルチ AZ 構成においてもリカバリの準備状況チェックと自動化によって運用がシンプルになり、結果信頼性が高くなります。

Amazon Route 53 Application Recovery Controller を含む、Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズムについては、ブログ：Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズムにて、以下のメカニズムの原則など詳しく解説しています。

データプレーン機能を使用する
スタンバイリージョンからフェイルオーバーを制御する
依存関係を理解して減らし、フェイルオーバーの信頼性を高める
重要なコンポーネントを事前にプロビジョニングする
認証方法を確認する
定期的にテストする

3. 端末のキャッシュやバッファリング実現方式

クラウドに配置したシステムの冗長化について考察しましたが、障害が発生することを前提とした Design for Failure という考えのもとでシステムを設計すると、店舗側で対策を講じておくことは、より可用性や信頼性の高い店舗システムを実現する上で重要です。また、対策であるキャッシュやバッファリングの実装は、応答性能の短縮についても効果があります。

キャッシング：デバイスとバックエンドでデータを同期してオフライン操作を処理する

店舗の POS や端末がバックエンドの一時的な利用不能によってオフラインの時も、店舗の営業を継続するために必要なデータにアクセスし、参照や作成、変更をしなければなりませんが、多数のデバイスとクラウドの間でデータを同期し、オフライン操作を処理することはアプリケーションを開発するにあたって最も難しいタスクです。

AWS 上でモバイルとウェブアプリケーションの開発を加速するための、各種のツールやサービスで構成される AWS Amplify の Amplify DataStore では、開発者がデータへの変更を書き込み、読み取り、監視するための永続的なオンデバイスストレージリポジトリを提供しています。スタンドアロンのローカルデータストアとして使用できるだけでなく、ネットワーク接続が利用可能な場合は、サーバーレスの GraphQL および Pub/Sub API サービスである AWS AppSync API と透過的にデータを同期し、AWS AppSync を使用してクラウドで競合の検出と解決も実装します。

オフライン操作の処理は、AWS IoT を使用して実現することもできます。AWS IoT Core では、オフラインから再接続時のメッセージの送信と、双方向コミュニケーションを可能にするので、他の AWS サービスと組み合わせることによって、デバイスである POS や端末からのクラウドにあるデータベースへの更新だけでなく、他のデバイスなどによる更新の受信により、ローカルデータストアを用意することができます。

バッファリング：デバイスで発生するデータを継続的にクラウドに送る

デリバリサービスとの在庫連携や、販促キャンペーン追加施策判断など、POS データをリアルタイムに分析したいニーズは高まっていますが、ストリーミングデータとして扱い活用する用途として、Amazon Kinesis や Amazon Managed Streaming for Apache Kafka を利用できます。可用性と性能に関わるリトライ処理や期間、送信レコードサイズはもちろん指定できます。

Kinesis エージェントを使用すると、ローカルのファイルを監視して新しいデータを継続的に送信することもできます。ファイルのローテーション、チェックポイント、失敗時の再試行を処理します。POSでは Windows OS が多く利用されていますが、Kinesis エージェントは Windows 向けにも提供されています。

この他、キャッシングと同様に、AWS IoT を使用しても実現できます。オープンソースのエッジランタイムである AWS IoT Greengrass のストリームマネジャーを使用するとオフライン時に、エッジでデータをキャッシュし、コネクションが再接続したタイミングでクラウドに送信することができます。

ストリームデータは、AWS の豊富な分析サービスと連携して、リアルタイムなデータ活用に役立てることができます。例えば、リアルタイムに在庫を管理し、在庫切れに対するアラートを通知したり、ダッシュボードを用意するといった用途があります。

近年、消費者の購買形態は多様化しており、EC サイトやフードデリバリー経由で店舗で提供する商品を注文するというニーズもありますが、POS データと同様に Amazon Kinesis で処理することで対応することができます。リアルタイムにデータを活用できるので、調理を要する商品をモバイルオーダーした際のモバイルアプリへのプッシュ通知や、店内ディスプレイへの注文ステータスの更新といった用途も実現できます。

まとめ

本記事では、ストアコンピュータや、POS といった店舗に配置されているワークロードを AWS で稼働させるにあたってのメリットや懸念を挙げた上で、懸念に対する対策としてストアコンピューターのクラウド配置方式やマルチリージョン構成といったサーバー側の対策や、キャッシュやバッファリングといった端末側の対策について説明し、実現にあたり役立つ考え方や AWS のサービスについて紹介しました。

実現にあたっての検討事項として 2 つ取り上げましたが、現実は数多くあります。業務機能単位に依存性を排除する分散型のシステム、いわゆるマイクロサービスにすることで、店舗業務の変革に素早く対応することが求められるかもしれません。他には、デバイスの制約に対して考慮が必要になるケースもがあります。例えば、端末側の制約によってネットワーク接続にあたって名前解決ができない、IP アドレスで指定しなければならない場合は、可用性の設計について対策が必要になるかも知れません。コンビニエンスストアですと、多数の店舗からの同時アクセスが急増した場合のスケーラビリティや、システムのメンテナンスを取り入れつつも 24 時間営業を支えるための運用について、緻密に考える必要があるかもしれません。

これらの検討課題について、200 を超える多種多様な AWS のサービスを組み合わせて活用いただくことで解決を図っていただくことはできますが、Amazon で培われたより実践的なノウハウについてまとめている The Amazon Builders’ Library や、多くの技術的問題やビジネス上の問題を解決できる AWS ソリューションライブラリも参考にしていただくことができます。例えば、Guidance for Traditional POS Checkout on AWS では、小売業者が POS システムを AWS で実現する際の方法について、在庫管理や注文処理といった周辺システムとの連携も含めて包括的なガイダンスを提供しています。

店舗システムを AWS クラウドで稼働することによってコストを削減しつつ、機能の高度化により今までできなかったことを実現するため、今後も情報発信していく予定です。是非、ご期待ください。

第二弾として、AWS クラウドに移行後のアーキテクチャと、実現に向けたアプローチについて紹介しています。

Amazon Web Services ブログ