店舗システムのクラウド化に向けた考察3 – AWS IoT によるマルチリージョンアーキテクチャ

前回の記事では、AWS クラウド移行後のアーキテクチャとして、店舗に留まらない、多様で変化する顧客ニーズに統一的な体験を提供するユニファイドコマースの取り組みと、段階的に組み立てていくコンポーザブルアプローチについて紹介しました。
今回の記事は、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末（エッジ）と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介します。

エッジの運用と AWS の連携をシンプルにする AWS IoT

店舗で利用する機器については以下を実現することが求められています。

状態監視やリモート管理により故障やその兆候を確認した際に迅速な対応を取る
セキュリティ管理、ソフトウェアのアップデートにより安全な状態を保つ
機器とクラウドの間でデータを連携する

国内に多店舗展開している小売業では、多くの POS や各種端末を有しているので、実現にあたってのスケーラビリティは必要不可欠です。AWS IoT は、何十億ものデバイスを接続、管理する IoT（モノのインターネット）サービスとソリューションを提供しているので、シンプルに実現することができます。

ディザスタリカバリ（DR）を実現するマルチリージョンアーキテクチャ

前々回の記事でも取り上げましたが、災害対策におけるシステムの冗長化構成については、想定する災害と、システムの影響範囲について構成が決定されます。

AWS グローバルインフラストラクチャは、あらゆるアプリケーションに対応し、最も安全で、拡張性の高いインフラストラクチャを提供しているので、要件に応じたシステム構成を実現できます。災害対策に限らない、システムに関する障害対策として、マルチアベイラビリティゾーン（マルチ AZ）構成から検討するのは良い出発点です。

想定する災害（例）	影響範囲	冗長化構成
落雷による停電	アベイラビリティーゾーン（AZ）	マルチ AZ 構成
関東一帯が影響を受ける災害	リージョン	マルチリージョン構成（東京 – 大阪など）
日本国内の大部分が影響を受ける災害	リージョン	マルチリージョン構成（東京 – シンガポールなど）

表1：想定する災害と冗長化構成の例

国内でチェーン展開している小売業においては、災害発生時、災害の影響を受けている地域については店舗の営業は困難となりますが、それ以外の地域では営業を継続することが期待されます。例えば、今や生活に欠かすことのできないコンビニエンスストアや薬を扱うドラッグストアでは、災害発生時においても、生活インフラとして営業を継続することが期待されます。

図 1：大規模災害発生時における DR サイトへのフェイルオーバー

この場合、システムについては、DR サイトを用意して災害発生時にフェイルオーバーすることによってシステムを稼働することが期待されますが、AWS グローバルインフラストラクチャにおいては、マルチリージョンアーキテクチャにより実現できます。

アーキテクチャの紹介

POS を例にしたアーキテクチャを図 2 に示します。AWS IoT Device SDK で構築された POS が AWS IoT Core と接続することで、機器の管理に加えて、データの利用用途に応じたクラウドサービスとの連携と、MQTT ベースでの双方向通信を実現します。AWS IoT Core は、業務アプリケーションとデバイス管理の用途に応じて、メッセージを振り分けてデータを管理します。

災害発生時のオペレーションをできる限りシンプルにするために、セカンダリリージョンの AWS IoT Core にも事前に機器登録をします。事前登録の例としては、AWS IoT のモノの登録や、プライマリとセカンダリで共通の証明書を発行してデバイスへの組み込み、があります。

プライマリリージョンの利用不能時は、Amazon Route 53 により接続先をセカンダリリージョンに切り替えることで、デバイス側の設定を変更することなく切り替えができます。データについて、Amazon DynamoDB グローバルテーブルにより、プライマリリージョンの更新がセカンダリリージョンに自動的にレプリケートされます。

図 2：アーキテクチャ

ユースケース

POS で想定される業務アプリケーションの以下ユースケースを例に、アーキテクチャを解説します。

POSのトランザクションを連携する
モバイルオーダーからの注文により在庫がないことを通知する

POSのトランザクションを連携する

顧客の会計時に取得した POS データは、各店舗で連続的に発生します。また、リアルタイムな購買動向の把握や在庫管理のためストリーミングデータとして扱うことが期待されます。

図 3：POS トランザクションの連携

処理の流れについては以下の通りです。

POS データは、POS から AWS IoT Core に暗号化された MQTT プロトコルを使用して AWS IoT Core に送信されます。
AWS IoT Core は AWS IoT ルールアクションにより、Amazon Kinesis Data Streams に MQTT メッセージのデータを書き込みます。
AWS Lambda 関数は、Amazon Kinesis Data Stream のレコードを処理し、Amazon DynamoDB で管理する在庫情報を更新します。

モバイルオーダーからの注文により在庫がないことを通知する

モバイルオーダーから店舗の商品が注文されるようになると、一見在庫があるように見えても既にモバイルオーダーで購入されている可能性が生じます。モバイルオーダーの在庫を別で管理するといったオペレーションも選択肢ですが、シンプルに一緒に管理するニーズもあります。このようなケースでは、最新の在庫情報はシステムで管理されているため、在庫がなくなったことを、システムから店舗に通知する必要があります。顧客体験として改善の余地はありますが、先に注文票を持っていくケースや先に注文する飲食のケースの場合、会計時に POS に通知されている情報を元に購入できないことを伝えることで、在庫以上に購入されることを防げます。

図 4：POS へのメッセージ送信

処理の流れについては以下の通りです。

在庫情報の変更情報は、DynamoDB Streams によりキャプチャされます。
AWS Lambda 関数は、ストリームレコードを処理します。在庫がなくなった（あるいはある閾値に達した）ことを検知すると、MQTT クライアントインスタンスを作成して、AWS IoT Core にリクエストを転送します。
AWS IoT Core は、POS に MQTT リクエストを転送します。
POS アプリケーションで、転送されたリクエストを処理します。

DR サイトへの切り替え

災害発生時における DR サイト切り替えの流れを説明する前に、通常の状態について補足します。

通常の状態

プライマリリージョンとスタンバイリージョンの切り替えを、デバイス側の設定を変更することなく実施するため、AWS IoT Core はカスタムドメインを作成します（図 5 における iot.example.com）。Amazon Route 53 は、プライマリとスタンバイリージョンの AWS IoT Core エンドポイントに対して、フェイルオーバールーティングを設定します。

その他、Amazon Kinesis Data Stream や AWS Lambda 関数、DynamoDB Streams もデプロイしておきます。

図 5：通常状態（図 2 と同じ）

災害発生時

災害発生時における DR サイトへの切り替えは、業務も含めた被害状況に基づく意思決定により行われます。DR サイト切り替えの意思決定が下されると、オペレーターは、Amazon Route 53 Application Recovery Controller のルーティングコントロールを変更して POS からの接続先を DR サイトに切り替えます。

図 6：災害発生時における DR サイト切り替え

災害からの復旧（切り戻し）

基本的には、災害発生時のオペレーションと同じく、POS からの接続先の切り替えます。一例として、以下のような手順も考えられます。

Amazon Route 53 Application Recovery Controller のルーティングコントールを変更して POS からの接続先を DR サイトからプライマリサイトに切り替える
AWS IoT Core から順次特定の POS にメッセージを送り再接続を指示する
該当の POS は再接続をしてプライマリーに戻る

閉域接続の場合

一貫性のある応答性能を実現するために、店舗とクラウドのネットワーク接続を広域通信網（WAN）と AWS Direct Connect を組み合わせている場合もあります。本記事で紹介しているアーキテクチャは、そのようなネットワーク構成においても実現できます。

図 7：閉域接続の場合におけるネットワーク構成

災害発生時における AWS Direct Connect の障害影響を考慮して、AWS Direct ロケーションを複数用意します。本記事では詳しく取り上げませんが、AWS Direct Connect の高い回復性を実現するアーキテクチャについては、AWS Direct Connect の回復性に関する推奨事項で詳しく解説しています。

まとめ

本記事では、店舗 PC／ストアコンピューターが AWS で稼働する場合の、POS や各種端末と AWS の連携について、可用性に焦点を当てて AWS IoT によるマルチリージョンアーキテクチャについて紹介しました。AWS IoT により、多店舗展開する小売業で期待されるデバイス管理のスケーラビリティの実現と、AWS で稼働する店舗システムとシンプルに連携することができます。

実際のユースケースは、取り上げた 2 つのユースケース以外にもありますが、今回紹介したアーキテクチャをベースにアーキテクチャを検討することができます。例えば、POS データを分析したい場合は、Amazon S3 に POS データを蓄積することが期待されますが、Amazon Kinesis Data Streams のストリームデータを Amazon Kinesis Data Firehose でキャプチャして、Amazon S3 に配信できます。また、POS がローカルに管理する商品マスタの配信については、AWS IoT Core から POS にデータ連携することにより実現できます。この他、災害対策に対する戦略として、DR サイトを用意する必要がなければ、プライマリリージョンを対象として紹介したアーキテクチャを活用していただけます。

本記事が、皆さまの店舗システムの将来アーキテクチャの検討に役立てられれば幸いです。

Amazon Web Services ブログ