Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ルクミー午睡チェックができるまで

322 views

Published on

睡眠✕IoT! NeuroSpace & UniFa Engineer Meetup!で使用した資料です。

Published in: Internet
  • Be the first to comment

  • Be the first to like this

ルクミー午睡チェックができるまで

  1. 1. ルクミー午睡チェックが できるまで 2019/9/25 ユニファ株式会社 田渕 梢
  2. 2. はなす人。 田渕 梢(たぶち こずえ) プロダクト開発部 部長 2015年8月 UniFa入社。 Webエンジニア。 それまではソニー系列のシステム子会社や アクセンチュアでBtoCサービス、 輸出入管理サービスなどを担当。
  3. 3. Agenda 1. 事業背景 2. ルクミー午睡チェックとは 3. 全体システム構成 4. 利用園数推移とリクエストの特徴 5. データ保存周りの拡大構成 6. 本番で起こした失敗 7. 原因と対策 8. まとめ
  4. 4. 午睡とは/事業背景 ● 保育施設での死亡事故の約77%は睡眠中 ○ その中で、仰向け寝が推奨されているにも関わらず40%はうつ伏せ寝で 死亡事故が発生しているというデータ(※1)がある。 ● 午睡チェックとは ○ 保育園における乳幼児のお昼寝(午睡)時に実施するチェック ○ 発熱や呼吸異常等、園児の異常の早期発見、SIDS(乳幼児突然死症候群) の発生防止が目的。 ○ 「5分に一度、体の向きと呼吸の有無を確認し、うつぶせ寝となってい る場合は仰向けに変更する。」といった内容を全園児に対して実施。 ○ 行政よりチェックの実施と実施結果記録の提出が求められている。 (※1 平成29年5月12日 内閣府子ども・子育て本部 公表 「平成28年教育・保育施設等における事故報告集計」から算出)
  5. 5. ルクミー午睡チェック 午睡=お昼寝の時間に使うアプリ https://lookmee.jp/gosui/ 加速度センサーを利用して、 園児の体の向き、体動の有無を検知。 タブレット上で複数人分同時に確認が出来る。 2018年4月正式サービス開始 導入園数2000施設以上(利用園児数二万人以上) →2018年度一年で大きな成長を遂げる。 衣服に センサーを装着。
  6. 6. 午睡チェックの全体構成 AWS 園 RDB ログ (S3) 園児情報など 後の解析用。 5分ごとのデータ 160m秒ごとのデータ Dynamo DB 160m秒ごと のデータ 負荷、量、価格を 考慮し一部を DynamoDBに。 Bluetooth SORACOM のSIM
  7. 7. 利用園数推移とリクエストの特徴 サービス 提供開始 午睡チェックはどの園も5分に一回 可能な限り、リアルタイムにサーバーに 反映されて欲しいという現場要望 (当たり前だが)今後利用者数はどんどん 増えていく。 <センサー提供数実績> 負荷の分散が出来ない + 処理可能リクエスト数について 制御機構が必要
  8. 8. データ保存周り拡大概略構成(同期処理ケース) 午睡 AWS LB Dynamo DB ①午睡チェック データ送信 ③順次保存 ⑤矢印を表示 ④処理が終 わったこと を通知 <処理の流れ> ①午睡チェックデータを送信 ②Webサーバでリクエストを受付 ③順番にDBにデータを保存 (Dynamo DB) ④処理が終わった旨をアプリ側に返信。 ⑤矢印が表示される Web 1 Web 2 ②受付
  9. 9. 本番で起こした失敗 午睡 AWS LB Dynamo DB ①午睡チェック データ送信 ②処理詰まり ③受付不能 ⑤矢印表示な し ④通知来 ず <処理の流れ> ①いつもより多いデータが飛んでくる。 ②Dynamo上のテーブルが読み取り処理 上限により処理詰まり ③処理が進まずWebサーバのリクエスト 上限突破→リクエスト受付不能に。 ④午睡チェックアプリへの返信が遅れる、 あるいは返事がない状態に。 ⑤午睡チェックアプリ上で徐々に矢印が 表示されなくなる。 ⑥気づいた園より、問い合わせが殺到 Web 1 Web 2
  10. 10. 原因と対策 ● 原因 ○ ビジネスサイドとの連携不足により、一気に利用園数が増えるタイミン グをシステム側が把握していなかった。(そもそも、フローが整備され ていなかった。) ■ このトラブルの起こった日は一気に90園が増えた日だった。 ○ 応答処理速度の監視など、一部の監視が行われていなかったことで、事 態に気づくのが遅れた。(問い合わせで発覚。) ● 対策 ○ DynamoDBの設定を固定からOnDemandモードに変更 ○ 監視機構の再整備、時間帯によるサーバー台数増減実施
  11. 11. まとめ ● IoTサービスであっても、サーバーサイドは当たり前のことを当たり前にやれ ばサービスの開始と運用は可能 ● 利用シーンが一般のブラウザベースのWebサービスと異なるため、サービス 特性をよく考え、事前に負荷の予測をある程度実施しておく必要がある。 ○ とはいえ、世に存在しないサービスであることも多いので、実際の勝負 はサービスが実稼働してから。 ○ 早い時期での監視機能の整備は必須。 ○ 想定外は起こる前提で計画、間違いに気づいてから、いかに早く軌道修 正や対策を行うことが出来るかが大事 ○ 早期に軌道修正可能な環境(組織的な部分も含めて)にしておくことが 大切

×