睡眠時無呼吸リスク計測サービス「Sleep Doc」のデータ基盤を支えるAWSサーバレスIoTアーキテクチャ

この記事はグループ会社支援チームブログリレー1日目の記事です。

エムスリーエンジニアリングGグループ会社支援チームの愛宕です。

私たちグループ会社支援チームは、その名の通り、エムスリーの多様なグループ会社が抱える技術的な課題を解決し、事業成長をサポートするというミッションを担っています。

今回はその中の１つ、エムスリーとソニー社のジョイントベンチャーである、会社サプリムが提供する睡眠時無呼吸リスク計測サービス「Sleep Doc」で採用しているIoTアーキテクチャについて、約1年間の運用で得られた学びをお届けしたいと思います。

「Sleep Doc」とは

睡眠障害のひとつである「睡眠時無呼吸症候群」は、実は日本人の6人に1人が潜在患者ともいわれています。しかし、自覚症状があるとは限らず、治療を受けている方はごくわずかです。この状態を放置すると、日中のパフォーマンス低下だけでなく、生活習慣病や交通事故のリスクが高まることも指摘されています。そこで生まれたのが、自宅で手軽に睡眠時無呼吸のリスク計測ができる「Sleep Doc」です。

Sleep Doc専用ウェアラブルデバイスを2日間、睡眠時に装着して計測するだけで、睡眠時無呼吸のリスクを手軽に計測できます。このような、睡眠のリスクを判定するサービスは世の中にいくつかありますが、「Sleep Doc」の特徴として、仮にリスクが高いと判定された場合、必要に応じて専門のクリニックを紹介したり、看護師が電話で相談に乗ったりと、適切な医療に導くためのサポートが受けられるようになっています。これは、医療従事者向けプラットフォームで国内トップクラスの会員数を誇るエムスリーグループだからこそ提供できる大きな強みです。

「Sleep Doc」のアーキテクチャ概要

「Sleep Doc」は、ウェアラブルデバイスから送られてくる大量のデータを、安定的かつ効率的に処理するために、次のようなAWSのマネージドサービスを組み合わせたアーキテクチャを構築しました。デバイスのハードウェア開発はソニーネットワークコミュニケーションズ株式会社のチームが担当し、私たちはそのデバイスから送られてくるデータを受信し処理するクラウド側のソフトウェアを担当しました。（ソフトウェアの中でも「慣性センサ疾患スクリーニング技術」はソニーグループ株式会社のものなので除きます）

データの流れ

LTE通信の機能を備えたデバイス（Sleep Doc専用ウェアラブルデバイス）からAWS IoT Core にセンサーデータがMQTTで送信されます。AWS IoT CoreはフルマネージドのMQTTメッセージブローカーであり、デバイスとの接続とメッセージングを担います。データは一定のサイズのチャンクに分けられて送られてきます。
データは SQS で一度キューイングされます。後続の処理でエラーが発生した場合、リトライの後、デッドレターキュー（DLQ）に送られます。データ損失を防ぎつつ、後から原因調査や再処理を行います。
記録処理（Lambda） がデータをキューから取り出し、時系列データベースである Timestream に記録します。
解析処理（ECS Batch） がTimestreamのデータをクエリーし、独自のアルゴリズムで睡眠状態を分析します。解析には、ソニーグループ株式会社が開発した「慣性センサ疾患スクリーニング技術」を活用しています。デバイスから送られてきた加速度センサーの情報で体の微細な動きを捉え、睡眠時の呼吸状態のリスクを分析する最新技術です。

⠀このアーキテクチャで1年間運用してみて、技術選定が「正解だった」と感じる点と、そして苦労した点が見えてきました。

よかった点(1)：スパイクアクセスに強い

どのユーザーも、大体同じような時間帯に就寝し、起床します。これはつまり、夜から朝にかけての特定の時間帯に、デバイスからのデータ送信と、それに続く記録処理が集中するということを意味します。今回のアーキテクチャでは、AWS IoT Core, SQS, Lambda といったサーバレスのマネージドサービスを全面的に採用しました。これにより、アクセス集中時も自動でスケールするため、コストを最適化しつつ安定したサービス提供が可能になりました。時期によっては、一晩で多数のデバイスが同時に稼働し、一秒に数千行、一晩での数百万行のレコードが送信されてきていますが、今のところ一度もこの部分で障害が起きたことはありません。

よかった点(2)：開発スピードを加速させたTimestream

膨大な睡眠データを記録するために、我々は時系列データに特化したデータベースである Amazon Timestream を採用しました。私は別のサービスでもTimestreamを使ったことがあるのですが、こうしたケースで普通のRDBMSを使わずTimestreamを使うのは非常に理にかなった選択だったと思います。もし汎用的なデータベースで時系列データを扱おうとすると、「どうすれば効率的にデータを格納できるか？」「どうすれば高速なクエリを実現できるか？」といったテーブル設計やチューニングに、多くの時間を費やすことになります。 Timestreamは、最初から時系列データの扱いに最適化されているため、そうした悩みがほとんどありませんでした。開発者はデータベースの運用管理に頭を悩ませることなく、本来やるべきアプリケーションのロジック開発に集中できたのです。これは、特にスピーディな開発が求められる新規事業において、非常に大きなメリットでした。

ちなみに、私たちが2024年7月に現行のSleep Docをリリースした際に採用したのは、「Timestream」のサービスの中で現在「Timestream for LiveAnalytics」と呼ばれているものです。2025年10月現在、こちらは新規の受付を停止しているため、もし今から同様のシステムを構築する場合は、後継の「Timestream for InfluxDB」を検討することになるかと思います。どちらのサービスを利用するにせよ、IoTデバイスから送られてくる膨大な時系列データを扱う上で、汎用的なデータベースではなく、時系列データに特化したデータベースを選択することは非常に有効なアプローチだと考えています。

苦労した点：IoTデータにおけるトラブルシューティングの壁

サーバレスアーキテクチャは強力ですが、物理デバイスから送られてくる大量のデータを扱うIoTならではの、トラブルシューティングの難しさにも直面しました。開発中、特定のデバイスから送られてきた想定外のデータが原因で、Timestreamへの書き込み処理でエラーが発生しました。開発中なのでまだ良かったですが、これが本番だったんらば、一晩で数百万行ものレコードが処理される中で、「一体どのデバイスから、どのタイミングで送られた、どのデータチャンク」が問題を引き起こしているのかを特定しなければならず、これはとても困難なことです。この課題を解決するため、私たちは追加の仕組みを実装しました。具体的には、IoT CoreからSQSにデータを渡すメインの経路とは別に、CloudWatch Logsにチャンクごとの生データを記録するようにしました。さらに、各チャンクと、そこから生成されるTimestreamのレコード群にユニークなIDを付与し、両者を紐づけられるようにしたのです。

この改修により、エラーが発生した際にレコードのIDから問題の生データをすぐに特定できるようになり、トラブルシューティングの時間が劇的に短縮されました。IoTシステムを開発する際は、こうしたトレーサビリティを確保するためのログ設計がいかに重要かを痛感した出来事でした。

こういったいくつかの苦難はあったものの、例えばMQTTのプロトコルに関わる問題など低レイヤーをあまり意識することがなく、そのあたりはすべて AWS IoT Core がうまく吸収してくれていました。おかげで私たちは、より上位のアプリケーションレイヤーの課題解決に集中できました。

まとめ

今回は、Sleep Docの裏側を支えるAWSアーキテクチャについて、1年間の運用経験を元にお話ししました。

Pros:
- サーバレスアーキテクチャは、利用時間に偏りがあるSleep Docのユースケースに最適だった。
- Timestreamは、時系列データを扱うサービスの開発速度を間違いなく加速させてくれる。
Cons/Learnings:
- トレーサビリティは大事（全然IoTに限った話ではないですが）

⠀私自身は今回が初めてのIoTプロダクト開発でしたが、IoT Coreなどのおかげで、これまでのサーバレスやアプリケーション開発の知識を応用して乗り越えることができました。この記事が、IoTプロダクトに挑戦しようとしている誰かの背中を少しでも押せたら幸いです。