1日300万件のレコードを処理するアーキテクチャ構成　保育士さんの負担はDesign for Failureな「午睡チェック」でサポート

自己紹介

赤沼寛明氏（以下、赤沼）：よろしくお願いしますみなさまこんばんは。ユニファでCTOをしています、赤沼と言います。

今日はAWS Startup Tech Meetupということで、弊社ではプロダクトをすべてAWS上で構築しているんですが、その中でも「ルクミー午睡チェック」というサービスがありまして。その中でDynamoDBやSQSというのを活用してるところがあるので、主にそのあたりにフォーカスして紹介したいと思っております。

まず簡単に自己紹介します。私は6年前、2015年に1人目の正社員エンジニアとしてユニファに入社して、2016年からCTOという肩書きで務めています。現在は、自分で直接プロダクトの実装はほぼやってないんですが、主に組織マネジメントや採用などに注力しているポジションになっています。

ルクミーの事業とプロダクトについて

簡単に弊社の事業についても紹介します。弊社では、主に保育施設向けにプロダクトを展開していて、ルクミーというブランド名で複数のプロダクトを展開しています。

今のところスライドの6個のプロダクトを提供してる感じですが、その中で、2020年の9月に行われたAWSのStartup Architecture of the Year 2020の日本の決勝で優勝したのが、今日紹介するルクミー午睡チェックというプロダクトになります。

弊社が対象としている保育者の業務の1つに、お昼寝中の園児の見守り業務がありますが、それをサポートするためのプロダクトです。

従来、保育士の方が見守り業務をどうやってやっていたかというと、保育士の方が5分おきに園児一人ひとりの体の向きを確認して、手書きでチェック表を作成しているものになります。

実際は見るだけではなく、一人ひとりの体を触って、呼吸なども確認していて、要は、これによって長時間うつ伏せ寝になることを防いだり、呼吸が停止してることに早く気づけるようにしているということです。しかし、なにしろ5分おきにやらなきゃいけないので、業務負荷としてもかなり高かったものになっています。こういったところをサポートしていくのが、午睡チェックのプロダクトになっています。

午睡チェックのプロダクト概要

プロダクトの概要としましては、園児一人ひとりにつけたセンサーデバイスとiPadアプリが連携することで、自動的に体の向きを判別してチェック表を作成するというものになっています。

うつ伏せ寝などが発生した場合には、アプリにアラートを出して、保育士の方にもすぐに気づいてもらえるようになっているものです。

あとチェック業務は自治体からの監査対象にもなっていて、チェック実績の提出を求められることがあるので、そういった際に提示したり印刷する画面、Webの管理画面も提供しています。

こちらが実際にプロダクトを使っていただいている様子です。チェック内容を確認しているところと、あと他の業務と並行して午睡チェックの業務を行っている様子になっています。

実績としては、これまでに3,200以上の施設に導入いただいています。プロダクトの特性としても、信頼性や、運用上の優秀性といったような点が求められるものになっています。

アーキテクチャ検討時に想定されていた課題

では、具体的なアーキテクチャの話に入っていきたいと思います。まずアーキテクチャ検討時に、想定された課題としてどんなところがあるかですが。

アクセス特性としては、各施設でお昼寝が行われる時間はだいたい決まっているので、ピークタイムに集中的に利用されるというところ。あと、5分のチェックタイミングごとに一斉にiPadアプリからデータが送られてくる点があります。

あとデータ量としても、当初目標とした施設数で想定すると最大で、1日で300万件以上のレコードが作成される点があったので、こういった点を考慮してアーキテクチャを検討したものになってます。

アーキテクチャの概要

Overviewですが、センサーからiPadにBLE （Bluetooth Low Energy） でデータが送られて、iPadアプリ上で作成された午睡チェックデータが、API Gatewayを経由して、EC2インスタンス上で稼働しているAPIサーバーで処理され、それがDynamoDBに記録されていきます。

マスターデータなどについてはRDSに書き込みをしているので、DBはハイブリッドの構成になります。Webの管理画面では、午睡チェックデータの参照とか、各種管理画面、各管理業務も行えるようになっています。

ここでコンテナではなく、EC2インスタンスをそのまま使っているという点で、レガシーだと思われる方もいるかと思うのですが、3、4年前の開発時の社内でのコンテナに対する知見や、コンテナに対する環境の充実具合と、実際に開発期間として求められていたもの、それに加えてプロダクトの特性を考えて、できるだけ早く固いプロダクトを提供していくというところでEC2を選択しました。

もちろん今後、余裕があれば、コンテナに置き換えられればなとは思っていますが、現状でも十分に安定的に運用できているところと、他の新しいプロダクトを開発したいという優先順位を考えると、現状の優先度的にはあまり高くないかなと考えています。

DynamoDBとSQSが関わる構成の説明

もう1個ブレイクダウンした構成図がこちらです。

全体としては午睡チェックデータの参照や記録を行うためのオンラインの処理と、データ集計などを行うためのバッチ処理とに分かれています。

今日は、主にDynamoDBとSQSが関わってくる部分について紹介をしたいと思っています。

まず午睡チェックデータの処理ですが、ピークタイムがある程度特定できているので、時間指定でEC2インスタンスをオートスケールしています。

リクエストを受けつけると、その処理順番を担保するために、午睡チェックシートの各セルのステータス情報をフラグとしてElastiCacheに記録することをしています。

午睡チェックデータはSQSに格納されて、それをWorkerが順次取り出して、ElastiCache上のフラグ情報を参照した上でDynamoDBに書き込むことをしています。ここでDynamoDBに直接書き込まずにSQSを利用している理由としては、5分ごとに一斉にデータが送られてくることがあるので、DynamoDBの書き込みが間に合わないことがないようにというものになります。

それと、複数のWorkerで処理が行われると、プロダクトとしては処理の順番が担保されませんが、やはり処理の順番も重要になってくるので、ElastiCacheを使って処理順番が担保されるようにしているものです。

DynamoDBのテーブルは、月別で作成するようにしてます。業務の性質上、過去のテーブルへのアクセスはほぼないかたちになってくるので、もしあった時には同期処理でSQSを介さず、直接アクセスするかたちにしています。

あと、各センサー単位での利用状況を確認するために、データの送信回数やアラートの回数などは、DynamoDB StreamsでLambda Functionによる集計処理を都度実行して、DynamoDBのテーブルに記録するかたちになっています。ちなみに、施設単位のサマリのようなものは、バッチ処理で集計を行っています。

複数のWorkerで処理が行われた場合、DynamoDBのライトキャパシティの設定値を超過してしまうと、スロットリングが発生することになるので、あらかじめElastiCacheにキャパシティの設定値を記録しておき、各Workerは起動時に自分自身の情報を登録するとともに、キャパシティの設定値と他のWorkerの情報を取り出して、書き込み速度を調整することをしています。

これは参考までにという感じですが、2020年9月の上旬の実際のグラフをもってきました。SQSに格納されてから、午睡チェックデータが処理されるまでにかかった時間のグラフになってます。

最大で167秒ということで、ビジネス的な要件としては300秒以内に処理できるようになっているので、いったん十分に満たしているものになってます。ちなみにこのグラフの時間はUTC表示なので、実際は日本時間でいうと10時から14時ぐらいをピークに使われているものになっています。

次のスライドがSQSに格納されたデータ数ですが、最大で17,000件あまりが登録されています。

あと次のスライドがWorkerで処理された数で、処理速度は一定になるので、7,790件あたりで揃っている感じのグラフになっています。

Design for Failureという点では、なんらかの原因で処理に失敗したデータはDLQに格納されて、エンジニアに通知がくるようになっています。

バックアップについてですが、まずCloudWatch EventsでLambda Functionをキックして、DynamoDBのどのテーブルをバックアップするかのリストを作成してSQSに格納することをしています。

それを元にして、別のLambda Functionが対象のテーブルのラベル情報を更新して、そのラベルを元にしてAWS Backupでバックアップ対象を特定してバックアックアップを取得しています。

あとDynamoDBやSQSといった観点からは少し離れてしまいますが、Design for Failureという点で、ネットワーク障害などで仮にサーバーに接続できなくなった場合にも、すでに午睡チェックの業務が開始されていれば、センサーとiPadアプリの間だけでも最低限のチェック業務が継続可能になっています。

また、iPadからSORACOM Air Simを使ったセルラー回線を使用しているので、保育園のWi-Fiの安定性の問題などを回避できるというところ。あと、サービス導入時の保育園側でのWi-Fi設定の手間を削減できるようになっています。

午睡チェックのビジネスへの貢献

最後にちょっとビジネスへの貢献についても軽く説明したいと思います。サービス開始から約3年が経過していますが、特に最初の1年で補助金の動向などもあり、一気に導入数が増えた状況になってました。

それに伴ってデータ量もどんどん増えていき、直近では1ヶ月で800万件以上のデータが登録されているというところと、累計では1.2億レコード以上が記録されているという状況になってます。

そうした中でもレスポンスタイムやパフォーマンスの劣化は抑えられているし、サーバーに接続できなくても業務の継続が可能という点でも、安心・安全をサポートするプロダクトという点では、信頼性の向上という点で貢献できているのかなと思っています。

あとセルラー回線を使っていることで、保育園のWi-Fiの環境を気にすることなく、安定的な接続を提供できる点、導入時の手間を削減するということでも、保育園にとってもハードルを下げられているという点で、導入数の増加にも貢献できていると思っています。

主に信頼性と運用上の優秀性といった点が命に関わる業務での安心・安全をサポートするプロダクトにとっては、大きな価値を提供できているかなと思っています。

まさに直近のコロナ禍では、保育現場の価値があらためて見直されているという状況でもあるので、今後もより現場で活用してっもらえるプロダクトを提供していきたいと思っています。

最後に少し宣伝もしたいのですが、6月2日にプレスリリースを出しまして、シリーズDということで約40億円の資金調達を実施しました。

この資金調達をきっかけに、さらに採用にも力入れていくので、興味があればぜひ声をかけてもらえればと思っています。ぜひ一緒に保育をHackしていければと思っているので、よろしくお願いします。私からは以上です。ありがとうございました。

質疑応答：1人目のエンジニアを採用した経緯

司会者：ありがとうございます。ちょっと質問がいくつかきてるので見ていきましょうか。1つ目は、「確実なニーズがあって、とてもいいビジネスだと思いました。創業者の方は、どのような経緯で1人目のエンジニアになることに至ったのでしょうか」経緯的なところの質問ですね。

赤沼：創業者＝1人目のエンジニアというわけではなく。私は創業者ではなく、途中で入ってきた感じなんですが。

弊社の代表はもともとコンサルをやっていて。自分自身が激務だったこともあって、どうしても家族のコミュニケーションに課題があったりする中で、自分で起業することを考えた時に、やはり家族をもっとこう大事にしていきたいと。

自分自身にも課題のあった家族コミュニケーションですね。世界中の家族コミュニケーションを助けていきたいところがあって、このビジネス創業したかたちになっています。

1人目のエンジニアというところでは、私は後から入りましたが、私自身としても社会貢献性の高いビジネスに貢献していきたいところがあったのと、ちょうど会社としてもこれから開発組織立ち上げてこうしっかりプロダクト作っていこうというところでもあったので。いろいろなチャレンジができそうだなというところで、1人目のエンジニアとして参画したというのが経緯になります。ちょっと意図どおりの回答になっているかわからないですが。

司会者：理由はたぶんそんな感じですが、やはりご縁というか、タイミングは正直ある感じですか。

赤沼：そうですね。もうちょっと話すと、弊社は、創業が名古屋です。

当時私が転職活動していた時にはまだ名古屋にしかオフィスがなくて。開発組織を立ち上げると同時に、東京オフィスも立ち上げるということで。東京オフィスを立ち上げるというタイミングで、ちょうどユニファ側としてもエンジニアを募集していました。

ちょうどそのタイミングが合ってです。私が代表と面接していた時にはまだ東京オフィスがオープンしていなくて、エージェントの方のオフィス借りて面接したり、そんな状況でした。なので、本当にタイミングはあったかなと思います。

司会者：これは創業期のスタートアップの方はだいたい言える気がしますが、なんだかんだタイミングな気がするので、採用する側はけっこう辛抱強く探しとかなきゃいけないし。行きたいところを探してる方も、最終的にはタイミングなので、いろいろな話を聞いてみるといいんじゃないかなという気がします。

質疑応答：保育園への導入の際の障壁

司会者：ありがとうございます。では次、たぶん保育士さんというよりかは、保育園への導入で障壁とかありましたかという質問ですかね。

赤沼：そうですね。保育士さん、保育園の環境ってまだまだアナログな環境が多くて。最近の若手の方はシステムの導入に積極的な方も多くなってきていますが、もともとすごくアナログなところにこういうシステムを入れるということ自体に一定抵抗感があることもどうしてもあったりして。

実際使ってみてもらうと、そこがだいぶ払拭されてくるというか。機械に任せるのは、ちょっと手を抜いているのではないかという意識になってしまう方もいます。しかし、特に午睡チェックみたいなプロダクトは、単純にその業務効率化というだけではなく、チームで見守る環境を提供できるなど、付加価値になるので。そういった点で注目してもらえると、けっこう積極的に導入してもらえるところはあったかなと思います。

実際、弊社のプロダクト開発の段階でも、実際保育園に何回もお邪魔しまして。センサー自体もそうですが、iPadアプリのUIなども「これだったら使いやすいか」「どこが使いづらいか」とか、いろいろ聞いてUIもちょっと改善して、実際にリリースしたと。

実はお昼寝中という薄暗い中で使われるので、「ちょっと暗い部屋の中でも見やすいUIがいい」とか。そういった希望をもらえたりもするので、現場で実際どうやったら導入してもらえるかは、かなり追求したものではありました。

司会者：おもしろいですね。薄暗い中でも見やすいUIって、確かに現場視点じゃないとわからないですよね。

赤沼：現場だと、普通にiPadとかを使う感覚だとちょっと違うんですよね。

司会者：今いろいろあるとは思いますが、やはり現場からのフィードバックなどを大事にしながらすり合わせていくところが、障壁を取り払う上だとけっこう重要という感じですかね。

赤沼：そうですね。我々は保育の現場、保育士ではないのでちょっとわからないので。正直そこはしっかりインタビューとかをさせてもらうことで、できるだけ障壁がなくなるかと思います。

司会者：ありがとうございます。ちょっと最後の1つにしようかな。

質疑応答：Design for Failureの設計をいつ検討しはじめたのか

司会者：「Design for Failureの設計や概念などは最初から出たのか、どのタイミングから検討された、導入されたのかという観点」。タイミングに関する質問ですね。

赤沼：午睡チェックのプロダクトの時には、最初から考えていました。やはりそのプロダクトの性質上、我々としても万が一があってはいけないということがあったので、極力エラーを拾う仕組みとか、継続的にしっかり業務が行えるようにというところは、最初からかなり考えていました。

なので、先ほど紹介した仕組みは、かなり最初の段階、特にリリース後はよりシステム的にも安定していないところもあるので、そこはより力を入れていたり。

あとはテストなど。QAのメンバーがかなりいろいろがんばってテストしてくれたりもあったので、やはり初期からこのあたりは力入れてましたね。

司会者：ありがとうございます。じゃあそんなところですかね。赤沼さん、ありがとうございました。

赤沼：はい、ありがとうございました。