IoTシステムでユースケースの追加によりDynamoDBの再設計が必要となった話

若槻龍太

2019.11.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。CX事業本部の若槻です。

今回はAWSのマネージドサービス(IoT Core、Lambda、DynamoDBなど)を利用したIoTシステムの導入にて、追加で発生したビジネス上のユースケースに既存のDynamoDBのテーブル設計では対応ができなくなったため再設計が必要となった、というケースがあったためご紹介します。

どんなシステムか

戸建て住宅の設備（例：玄関の扉）にIoTデバイスを設置し、設備が最後に利用された時刻（例：扉が最後に開閉された時刻）をDynamoDBに記録するサービスを提供するシステムです。

DynamoDBのプロパティは以下のようになります。

placeId（住宅の識別値）
placeName（住宅の名称）
deviceId（IoTデバイスの識別値）
lastOpenCloseAt（最終開閉時刻）

DynamoDBのテーブルには以下のようにデータが格納されます。

placeId	placeName	deviceId	lastOpenCloseAt
place001	住宅A	device001	1574599548
place002	住宅B	device002	1574600014
place003	住宅C	device003	1574519724

キー・インデックスの指定は以下のようになります。ソートキーの指定はないため、プライマリキーはplaceIdのみとなります。

パーティションキー：placeId
ソートキー：なし

DynamoDBでデータが更新されるまでの一連の流れは以下のようになります。

IoTデバイスが玄関扉の開閉を検知する
IoTデバイスからAWSへ開閉時刻が送信される
DynamoDBのテーブルに対してパーティションキーであるplaceIdをもとに更新対象のデータの検索が行われる
更新対象のデータのlastOpenCloseAtが更新される

追加のユースケースと、それによりDynamoDB観点で何が対応できなくなるのか

さて、ここで追加のユースケースとして「表口と裏口の2つの玄関を持つ住宅」に対しても同システムで対応ができるかどうか検討することとなりました。その場合は表口と裏口のそれぞれの玄関にIoTデバイスを設置し、それぞれの最終開閉時刻を記録する必要があります。

当初の想定では、システムの対象となる住宅は１つの玄関（＝１つのIoTデバイス）を持つケースのみであり、placeIdとdeviceIdは１対１の関係であったため、問題なく対応できていました。しかし、追加のユースケースでは１つの住宅に２つの玄関があるため、placeIdとdeviceIdは１対２の関係となります。この場合はどうなるでしょうか？結論から言いますと、既存のテーブル設計では対応は不可となります。

[理想]としては以下のように住宅Cの表口(device003)と裏口(device004)の両方のIoTデバイスのデータが既存のテーブルに登録できると良いでしょう。