■ 記事の目的
アーキテクチャ設計において"なぜこれなのか？"を説明するのって結構難しいなと思う機会があり、そうした時に拠り所となるのが"実際他所ではどう使われているか"といった実績になると考えた。
AWS アーキテクチャセンターを端から眺めてみて、サービス自体の理解を深めるとともにアーキテクチャパターンを調査してまとめる。

Amazon Location Service

フルマネージドの位置情報サービス(Location Based Service(LBS))。以下の機能がサポート¹^,²。

Maps : 位置情報の視覚化とデータのオーバーレイ
Places : 検索、ジオコーディングとリバースジオコーディング
Routes : 地点間のルート検索
Geofencing : 地理的境界 (ジオフェンス) への出入りを検知
Tracking : 位置情報のトラッキング

Mapsを利用した記事を確認するとデータプロバイダを指定することから裏ではESRIなどのGISデータに強そうなところがところがデータを持っていてそことのAPIのやりとりをラップしているようなイメージで捉えた。

GeofencingやTrackingはIoTと相性が良さそう。
ここではそれらを取り上げたリファレンスアーキテクチャを深掘りしてみる。

アーキテクチャ例 1 : Tracking & Geofencing

位置情報から特定区画への入退出情報やトラッキング情報を生成し、通知や分析を行う際のアーキテクチャ。

アーキテクチャ概要

IoT CoreへMQTTで送られたメッセージから定義されたアクションに基づきAmazon Location Serviceへと位置情報を送信する。おそらく詳細なアーキが省略されているものと思うが、ここは直接送信できるのではなくLambdaなどを嚙ます必要がありそう。現に以下記事でGeofencingを利用したアーキ図上ではLambdaの記載があり、そのコードは公式から拾っているっぽい。

トラッキングした情報を基に区画への侵入を判定し、検出され次第EventBridgeを介して各種連携先のAWSリソースに繋いでいる。

興味深いことに、トラッキング対象のデバイスは必ずしもGPSを搭載していなくともそれ以外の情報から位置情報を特定できる技術があるらしい。→ AWS IoT Core Device Location³
仕組みとしては、WiFiアクセスポイントやIPアドレス情報からおおよその位置情報を割り出したり⁴、4つの人工衛星との距離を基に位置を割り出すGNSS(Global Navigation Satellite System)⁵という手法が用いられている。

ジオフェンスでは、この検出してEventBridgeで各種リソースへ渡すというパターンがよく見られる。(まあそれはそう)

アーキテクチャ例 (Appendix) : Amplify Geo

位置情報を使ったGeofencingなどはテスト大変そうだなと思ったが、こうしたデバイスを大量に仮想的に提供するIoT デバイスシミュレーターというソリューションがあるらしい。

アーキテクチャ概要

S3にホストしたSPAをCloudFront経由で公開し、Cognitoで認証させる。仮想デバイスへの操作はAPI GW - Lambdaのあるある構成で処理する。S3をシミュレーションデータセットの置き場とし、DynamoDBにてデータセットと適用先の仮想デバイスの対応を定義しておき、各種対象の仮想デバイスへの適用をSFnで包含された一連のLambda関数で処理する。
今回のIoT デバイスシミュレーターではデバイスで位置情報をシミュレートするものとしているため、シミュレーション結果をLocationServiceを通してマップ上に重ねて描画することなどを想定し、SPAにそのマップを埋め込んで描画する。

なお、SPAとマップ描画に関してはAmplifyが簡単に地図の描画をサポートしている(Amplify Geo)。本シミュレーションに限らず自前構築したSPAのページ上に地図を描く必要がある場合にも対応できそう。(※ 以下のリンクだと全画面で地図を表示しているが、コンポーネントとして埋め込むこともできるかChatGPTに聞いたところ方法が示されたのでできるんだと思う。そうなると結構自由度は高そう。)

アーキテクチャ例 2 : Maps & Routes

AIを利用した最適なルート計算のアーキテクチャ。

アーキテクチャ概要

上記アーキではGUIはローカル上で構成され、API部分のみが構成されている。
ローカルのSPAからAPIGWを介してLambda関数をキックする。Lambda関数ではLocationServiceにて作成されるルートマトリクスを取得し(図ではここの矢印が省略されている)、SageMakerのエンドポイントにデータを渡すことで最適な経路情報を生成する。結果を返却し、同じくLocationServiceのMapsを用いて該当情報をマップ上に描画する。

Routesでは始点と終点を指定してリクエストすることでルート計算された結果を受け取ることができる。そこに、マトリックスルーティングと呼ばれる機能が加わり、複数の始点・終点を渡すことで各地点間の距離と時間を算出できる。本アーキテクチャではルートマトリクスを取得し、その結果から最適な順列をAIに投げ込む構成になる。
なお、単に経路の断片同士を加算して算出すればいいのであればAIは不要であるが、実際にはこのケースのように、経路を移動する主体(収集車)が複数であり、それぞれの積載可能な荷物量が異なるなど複雑な条件が絡むと、地点間の距離は演算の一つのファクターでしかなくなる。そうした場合に有用なアーキテクチャ。

アーキテクチャ例 3 : Maps & Places & Routes

よくあるルート検索サービスの裏側。系列店の中で一番近いところを割り出すなどではアーキ例2同様にマトリックスルーティングを用いる。

アーキテクチャ概要

(シーケンス通りなので雑に)
ユーザから入力された情報を基にAPIGW-Lambda経由でLocationServiceの地点間のルート検索を実施。APIGWではキャッシュしているが位置情報が完全一致するクエリがくるケースってそんなに多くないのではと思うと有効なのだろうか？