Medley Developer Blog

株式会社メドレーのエンジニア・デザイナーによるブログです

社内勉強会TechLunchでCLINICSを取りまく監視ツール群について発表しました

皆様こんにちは。
プロダクト開発室 エンジニアの濱中です。

新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、コロナウイルス関連の特集が組まれていますのでぜひご覧ください。

さて先日、社内勉強会TechLunchにて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。

CLINICSの概要と、サービスにおける監視の立ち位置について

公式ページで「クラウド診療支援システム」と銘打っているCLINICSですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの3プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスがCLINICSです。

このうち、電子カルテシステムは、「日医標準レセプトソフト ORCA」という製品を内包する形で提供しており、ORCA自体は独立した環境で動作しています。

当然ながら、ORCA自体がCLINICSとは独立した1プロダクトであるため、CLINICS側に問題がなくてもORCAサーバがパフォーマンス低下や不具合を起こしてしまったり、あるいはCLINICSのwebサーバとの通信がうまくいかなくなるケースも考えられます。

電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます(最悪、患者さんをお待たせしてしまうこともあります)。

そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。

監視ツールあれこれ

ここからは実際にCLINICSで利用しているツールを簡潔にご紹介していきます。

Sentry

https://sentry.io/

弊社の他プロダクト(「ジョブメドレー」、「介護のほんね」)でも利用している監視ツールです。

基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側でcatchしてしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。

CLINICSでは例えばアカウントIDやアクセスしたAPIエンドポイント・パラメータなど渡して、エラー調査に活用しています。

Mackerel

https://mackerel.io/ja/

GUIで簡単に監視設定が可能なサービスです。

前職で使っていた時はGUIでできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。

現在CLINICSにおいては、ORCAインスタンスがそれぞれ独立して動作していますが、MackerelではこのORCAインスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。

AWS CloudWatch & Lambda

https://aws.amazon.com/jp/cloudwatch/

https://aws.amazon.com/jp/lambda/

どちらもAWSの提供するツールです。

CloudWatchは主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICSでは主にLogs, Metrics, Alarmを使用しています。

Logsはその名の通り、主にAWSのツールが発行するログを収集・検索・閲覧する機能で、問題発生時のHTTPリクエストのパラメータを確認する時などに利用しています。

Metricsは、「プロダクト(EC2ならインスタンス, RDSならDBインスタンスなど製品の一単位)」×「メトリクス種別(CPU利用率など)」を一単位として、統計情報を可視化するツールです。

それらに閾値を設け、超えた場合にアラートを発行するのがAlarm…という位置付けです。

対してLambdaは、そもそも監視ツールではありません。定期実行、あるいは何かのイベント(S3に何かアップロードされた、など)をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携(Slack通知などの外部連携も含む)させることも可能です。

CLINICSでは、上記アラート通知のほか、SessionManager経由でインスタンスsshログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。

New Relic

https://newrelic.co.jp/

New Relicは、CLINICSではパフォーマンス評価ツールとして利用しています。

メインとなるのはAPM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。

f:id:medley_inc:20200410183154p:plain

医療機関は時間によって診察ペースが大きく変わるため、1回1回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。

このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。

Sentryのようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。

Firebase Crashlytics

https://firebase.google.com/?hl=ja

Firebaseもまた”多機能な”ツールですが、CLINICSでは監視機能としてCrashlyticsを使っています。

CLINICSでは、患者さんが予約・オンライン診療を行うためのアプリを iOS / Androidで公開しており、医療機関向けのWebアプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのがCrashlyticsです。

Androidの場合はbuild.gradleに設定を追記してアプリをビルド、iOSの場合はcocoapodsで外部ライブラリとしてインストールすることで集計が可能になります。Unityアプリにも対応しているとのことです。

その他、監視ではないですがアプリを利用している端末やOSバージョンなどの統計情報の収集も可能です。

PagerDutyによる監視集約

https://ja.pagerduty.com/

CLINICSではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービスPagerDutyを導入しました。

導入後は、全てのアラートツールはアラートを一旦PagerDutyに集約し、PagerDutyからSlack通知を行うという形式になりました。

 

f:id:medley_inc:20200410183430p:plain

f:id:medley_inc:20200410183455p:plain

また、PagerDutyが出すアラートは、担当者が確認してレスポンスを返す(acknowledge)ことを行わずに一定時間が過ぎた場合、電話やSMSでの通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。

まとめ

CLINICSで利用している監視ツール+αを紹介させていただきました。

これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。

ご覧いただきありがとうございました。