【レポート】IoT を活用した見守りサービス “otta” #AWSSummit
はじめに
こんにちは、おおはしりきたけです。 みなさん AWS Summit Online 楽しんでいますでしょうか。
本記事は IoT を活用した見守りサービス “otta"のレポートとなっています。
セッション概要
スピーカー
- 株式会社 otta CEO/代表取締役社長 山本 文和 氏
- カラビナテクノロジー株式会社 プログラマ 吉村 拓人 氏
概要
otta 見守りサービスは、お子様や高齢者の方々など大切な方の位置情報履歴を、 無料スマホアプリやメールを通じて保護者様にお伝えするサービスです。 本セッションでは地域の見守りを支える Otta 位置情報基盤のご紹介や、 Otta 位置情報系における非機能要件に対して、 Amazon DynamoDB を活用した課題解決ポイントやその効果についてご紹介します。
セッション視聴のリンクは こちら。
セッションレポート
前半は、山本様からottaの会社概要とサービス説明、後半はカラビナの吉村様からサービスのAWS構成などの内容のお話となります。
アジェンダ
- ottaについて
- otta会社概要
- ottaサービス概要
- システム概要と開発チーム
- ottaサービス構成について
- カラナビテクノロジー会社概要
- otta = 位置情報
- otta × AmazonDynamoDB
- ある日のotta
- まとめ
### otta会社紹介 - 福岡を拠点にしているスタートアップ - 2014年10月設立 - スマート見守りサービスの開発・運営を行っている - Visionは「子どもから高齢者まで安心して暮らせる(活動できる)スマート見守りシティをつくり、不慮の事件や事故に遭う人を無くす」
ottaサービス概要
- IoTを活用した地域型のタウンセキュリティサービスを提供している
- 街中に沢山の見守りのネットワークを地域の皆さんと作っていく
ottaタウンセキュリティーサービス
- ビーコン技術の端末を、見守り地域のお子様に基本的に無償で提供
- 学校や公園、通学路など見守りが必要な場所に重点的に見守りスポットを作る
- 見守りアプリをインストールしたタクシーやスマホ(見守り人)とすれ違うと位置情報が記録される
- 思いに共感してくれた会社や自治体
- JapanTaxi(現在はMobility Technologies):タクシーのタブレットに搭載
- 東急リバブル:社員のスマホ
- 大阪府箕面市:ゴミ収集車に搭載
- 新サービス「otta.g」
- 位置と声でつなぐ親子の安全と安心
- ボイスメッセージが双方向で行えるサービス
システム概要と開発チーム
ottaタウンセキュリティシステムの概要
- 見守り端末からでるBluetoothの信号をアクセスポイントが取得
- アクセスポイントからAWSにデータを送信
- 保護者のアプリに位置情報を届ける
システム基盤の移行
- 創業当時の2014年~2017年夏までPaaS基盤でシステム稼働していた
- 利用者数の増加とシステム拡張を想定した場合、細かいパフォーマンス調整や拡張が可能なフルマネージドサービスが必要
- 2017年夏以降にAWS基盤上でシステム稼働を行うことにした
- 開発チームは、専門領域をもつパートナー企業と連携してサービス開発を実現している
- システム開発・運用領域:カラビナテクノロジー、アルディート
- プロダクト開発領域:アイ・オー・データ機器
カラビナテクノロジー会社概要
- 福岡市に本社を構えるシステム開発会社
- プログラマー以外にデザイナーも多数所属
- 2018年より、ottaのシステム開発を担当している
- 2019年より、同システム保守を担当している
otta = 位置情報
Ottaのシステム概要
- 大きく4つのサブシステムで構成されている
- 保護者用アプリ
- 位置情報システム
- 契約管理サイト
- 運用管理システム
- 本セッションでは、位置情報システムを中心に説明
Ottaにおける位置情報の特徴
- 多くはお子さん(児童)の移動履歴
- 学校のスケジュールによる規則性がある
- 一日のデータ量のピークが重複する。学校のスケジュールにより影響を受ける
- 社会情勢における変化がある
- 新型コロナの臨時休校や台風などの臨時休校によって影響を受ける
- 専用デバイス
- 見守りデバイスの無償配布などを実施しており、稼働デバイス = データ量が年々増加している
Otta位置情報システムの非機能要件
- 登校時のピーク性能:4万台
- データ量の増減に対するコスト最適化
- 移動のないときはデータ量の発生が極端に減る
- データ増減に対してコスト最適化が必要
- 稼働デバイス増加に対応できる拡張性
- コストパフォーマンスの高い専用デバイスにより、最大の受信データが増加
Otta位置情報システムの概要(構成要素)
- EC2:前身となったプログラムが、Linux上で動くJavaで動いていたためそのまま移植できる汎用性の高い基盤として利用
- RDS:複雑な情報が関連しているので、最終的にはRDSに格納している
- SQS:遅延書き込みのキューイングに利用している
- DynamoDB:デバイス向けの1次DB
Otta位置情報システムの概要(処理フロー)
- APIサーバーが位置情報を受信
- デバイスマスタ(DynamoDB)にチェック処理を行う
- 位置情報一次DB(DynamDB)に位置情報を登録
- キューイングサーバーが位置情報取得/削除を行い、マスタの更新を行い、SQSにタスクを登録
- 位置情報処理サーバーが位置情報を最終的にRDSに記録
- 位置情報を受信してから概ね1分程度で処理が完了する
- 前半の高速な処理と、後半の複雑な処理を分けるためDynamoDBを利用している
otta × AmazonDynamoDB
ottaにおける位置情報の予測
- 予測しやすいデータ量の増減
- 学校というライフサイクルによる1日周期の変化が分かりやすい
- 1日のピークは平日の午前8時の登校時間
- 1時間あたりのデータ量が多いのは午後4時の下校時間
- 稼働デバイス以上にデータが増えない
- 学校というライフサイクルによる1日周期の変化が分かりやすい
- 予測しにくいデータ量の増減
- 台風などの臨時休校
- 緊急事態宣言による学校閉鎖
- 学校再開後の集団下校
- 全体を考えるとキャパシティを立てやすい
DynamoDBのキャパシティ設定
- 読み込み/書き込みキャパシティモード
- プロビジョニングモード:こちらを採用している
- オンデマンドモード
- プロビジョニングモードのメリット/デメリット
- メリット
- 無料枠がある
- 利用料がオンデマンドモードより安価
- デメリット
- 実際の利用料ではなく事前の設定値で課金
- プロビジョニングが必要
- メリット
- ottaのDynamoDBのテーブルは、全てプロビジョニングモードを採用している
DynamoDBのプロビジョニング設定
- AutoScaling設定とBurstCapcity設定を組み合わせて不意のリクエストに対応できるようにしている
AWS CLIによるキャパシティスケジューリング
- プロビジョニング設定の変更
- コンソールでは時間による変更が出来ないので、CLIのapplication-autoscalingコマンドを利用
- ピーク時は多めに、それ以外は少なく、夜間はさらに少なくしている
ある日のotta
- 赤い線はプロビジョニング済みのキャパシティ
- 青い線は実際に消費したキャパシティ
- この当日(主に福岡市)は、緊急事態宣言の解除で通常とは異なる推移
- 設定による定時拡張は行っていた
- 70%に達したのでAutoScaleによる拡張が行われた
- 午後の山は、特殊な集団下校が発生した。通常より早いタイミングで帰宅
- 元々予定していたキャパシティが超えた
- BurstCapacityを使って正しく処理された状態
まとめと今後の展望
- 重要なポイントは余裕を持ったプロビジョニング設定が大切
今後の展望
- AWS Lambdaや、AWS Fargateなどマネージドサービスへの移行し運用負荷を下げる
- 安心安全を届けるために、Amazon AthenaやAmazon Elasticserch Serviceなど位置情報分析系サービスの充実
感想
「誰もが安心して暮らせるスマートシティをつくる」をビジョンのもと、ottaは見守りサービスとして提供されており、デバイスや見守りアプリなどからの大量のリクエストに答えられるようAWSを利用し、さらにDynamoDBをうまく利用し、高速な処理と複雑な処理を分離しているのは非常に参考になりました。これからますます利用者が増えると思いますので、今後の展望にあるマネージドサービスを利用することにより、運用負荷を下げより、otta自体のプロダクト価値に特化できるようになっていくと良いなと思いました。