はじめまして。BRIGHT VIEでサーバサイドのエンジニアをしている @lemonade14 です。
今年弊社として初めてAdvent Calendarに参加しており、
BRIGHT VIE エンジニア Advent Calendar 2016の2日目の記事となります。
今回は、弊社の案件でナースコールシステムを介護現場に導入した際に
AWSのAPI Gateway＋Lambda＋DynamoDB＋SNSを利用して構築したお話を簡単にさせて頂きます。
介護現場とナースコール
今回担当させて頂いた介護の現場では、ナースコールが呼ばれるとPHSで受信し、
その連絡を受けて各担当者が利用者様のもとへ急行している状況でした。
そのため、いつだれがどのような場所でナースコールを利用されているのかのなどのログを介護記録として残すことが出来ず、
記載をすることが出来たとしても現場の方々が落ち着いたタイミングで記録するような現状がありました。
また、人材配置や利用者様の巡回の最適化、引き継ぎ資料としての記録なども行えておらず、
現場方々の知見により運用でカバーされている状況であり、
少しでもそれらの負担を軽減できる仕組みとして導入したいとの思いがありました。
iPadの導入とナースコールのPush通知化
今回、ある施設のナースコールや介護システムのリニューアル化に伴い
通常のナースコール処理に加えて、ナースコール受信時に外部APIへ送信するように調整頂き、
また介護現場にiPadの導入もされたことから、
AWSを利用したナースコールシステム基盤の構築を行いました。
AWSにナースコールのログを蓄積し、「いつ」「誰が」「どこから」「どのような要件」で呼ばれたのかを自動連携し、
今後のデータを活用した現場改善最適化のための基盤の構築に取り組みました。
API Gateway -> Lambda -> DynamoDB -> SNSを利用した基盤づくり
2015年の年末に取り掛かったシステムであるため
当時話題となっていた「サーバレスアーキテクチャー」を採用しました。
常に稼働しておく必要はないが、リクエスト数に応じたスケールが必要なシステムであったため
Lambdaの採用が最適であると感じました。
またDBに関しては色々な情報を扱うにあたって、NoSQLの採用を検討していたため、
「Lambda×DynamoDB」の組み合わせで実施することにしました。
要件としては、
- ナースコールの通知ログを保存する
- 各利用者様の担当者にPush通知を送信する
- 受信したナースコールの呼び出し元などから各利用者様の担当を特定する
- ナースコールが「対応開始前」なのか「対応完了後」なのかをログとして閲覧できるようにする
図にすると下記のような形です。
システム構築で困ったこと
API Gateway編
-
SSL/TLS通信において、「Extension: server_name」の指定がないと接続エラーになる
- server_nameは、SSL/TLS通信において、バーチャルホストの機能を実現するための拡張機能
- API Gatewayは、SNI（Server Name Indication）を利用したサーバ証明書を使用（AWS サポート問い合わせより）
- IPアドレスが複数のユーザのエンドポイント名として設定されている
- そのためクライアントから送信される、「SSL Client Hello」 メッセージの中に 「Extenstion: server_name」 として接続先のホスト名が明記されている必要がある
-
POST送信時の「Content-Type:application/x-www-form-urlencoded」問題
- API Gatewayは、「Content-Type: application/json」が基本
- 連携システム上どうしても上記のContent-Typeで送る必要があった
- 参考
Lambda
- 特になし、便利だ！
- API Gatewayでは悩んだけどLambdaでは特に...
- Nodejsで記載したが、必要なモジュールを入れてZip圧縮してアップロードすれば楽
- ローカルの開発環境が整えられればスムーズな気がするが環境構築が少しネック
DynamoDB
-
定期的なログの退避
- ある一定数のログが貯まるとデータが取得できなくなるため定期的に過去ログを退避させている
- 期間をインデックスとして貼れていないので、インデックス設計が大きな問題
- データを取得する処理で工夫しているが退避も並行して実施中...
- ある一定数のログが貯まるとデータが取得できなくなるため定期的に過去ログを退避させている
-
インデックスの概念の把握
- ハッシュ値とレンジ値、プライマリキーとセカンダリインデックスが理解できれば比較的難易度は引い
- データ管理として複数データをキーとしてデータを特定する場合命名でカバーする必要があった
- 一意にデータを特定するキーが定まっていれば便利かも
- 複数条件で検索したい要件が出てきた場合のために、インデックスの値を検索しやすいように
- DynamoDBでの最適なデータ設計が難しい...
SNS
- 特になしだが、設定は複雑
- Pub/Subの仕組みがようやく理解できたので良かった
- ユニット単位でPush通知を送信するが、そのユニット単位にサブスクライブさせれば良いのでPushの設定は楽
最後に
AWSでナースコールの基盤を導入することでいつ誰がどのくらいナースコールが呼ばれているかを可視化することが出来ました。
既存の仕組みにアドオンする形で今回対応させて頂きましたが、
まだまだ運用における課題も多く、最適化までは取り掛かれていないので
今後も情報集約、情報の活用を中心に基盤を構築し、現場改善の力になれればと思っております。