本記事は、Shiny Advent Calendar 2018の14日目の記事です。
2018年ももうすぐ終わりますね。アドベントカレンダーの趣旨とは別に、自分で勝手に今年を振り返ると、今年もいろいろとRとShinyに触れることができた一年でした。useR!2018に参加と発表できたことは仕事とは関係なくともRをもっとやろうと思えて、刺激的でした。
という前置きのまま、、、今年作ったShinyアプリの1つを本記事では紹介します
この記事でわかること
Shinyを使ったログ分析ダッシュボードのケーススタディ （つまり、技術の話はないです）
背景
- Gitlab CIを用いてデータのETL処理のジョブバッチを定期的に行っている
- このようなETL処理のジョブバッチは複数のプロジェクトで、それぞれのデータに応じたパイプラインが存在しており、ジョブの失敗ログを横断的にモニタリングするツールがほしい
- ログをモニタリングするだけだと、OSSのDashboardツールで十分なのだが、分析（例えばメッセージログ同士の類似度に基づいて、クラスタを組み、どのクラスタのログが増えてるかも見たい)をRでやっていると、そのままRのコードからダッシュボード化できたほうがリッチなこともできる
また、GitLab Advent Calendar 2018 のGitlab APIでデータ活用を進めように背景やデータの集め方も書いています
なぜShinyを使った？
- Rでのデータ分析者にとって、分析のために書いたRのコードをすぐにWebアプリケーションとして比較的容易にデプロイすることができ、かつ非常に習得コストも小さい
- 閲覧者が何百人といるわけでなく、開発・分析チームが確認できれば良いので、3 - 最大10人程度が同時閲覧する程度のスケールで十分であった
- つまり、パフォーマンスやスケーラビリティを求めないPoC的なアプリケーションに適している
- 単にShinyが好きだから
どんなアプリ？
（ほとんどモザイクかけてますが）
UI
- プロジェクトを
selectInput(..., multiple = T)で選択 -
dateInputで時間幅(startからend)を選択 -
actionButtonでデータをロードする - 時間粒度(group_by)もリアルタイムに変更できる
シンプルにまとめれるshinydashboardを使っています
Output
-
plotlyを用いて、プロジェクトごとの失敗ジョブ数をbarカウントで表示- クラスタごとの失敗ジョブ数も同様に
- 生ログから確認したい情報を取り出して、
datatableで表示- エラーの文面やJobの詳細URL等
ダッシュボードの効果は？
- プロジェクト全体のCIのJobを集約することで、マネージャークラスが容易にチームの分析ジョブの状況を確認できる = 最近安定して動いてるか？基盤が調子悪くないか？等の問題発見の気付きにもなる
- 日々のジョブの失敗数を1つのKPIにして、分析基盤が安定しているかのアプリケーション指標の1つとしても使える
- 最近失敗JOBが多いかどうかを長期の視点で確認するのが非常に楽。さらに、量子化の程度（時間の集計単位）も選べるので、見た目が良い可視化になるように調整もできる
このように、プロジェクト横断したモニタリングをShinyを用いた話でした（まだ未完成部分もありますが）
課題は？
- 開発時の課題として、RStudioサーバ上で、プロジェクトごとに
packratを用いてライブラリのバージョンを管理しながら、開発している。デプロイする際に、Shinyサーバに開発で使用しているライブラリ群をアプリケーションの中で閉じて使いたい- 開発環境とデプロイ環境で、微妙にライブラリのバージョンが違うためか、謎のエラーによるデバッグが発生した経験があったため
- datatableの行にグループごとに色をつけたい
- クラスタごととか、プロジェクトごとなど
- どんなログの種類（クラスタ）が増えているのかに、ログのクラスタリングをするが、データが更新されるたびに結果が変わるため、結果の再現性を担保しながらクラスタリング結果を保存したデータを蓄積する裏の仕組み
- だんだんと肥大化していくので、こういうのは突貫で作るものではないですね…
おわりに
背景とは別ですが、Rで分析やってると、ふとあれ？これShiny化したら良いかも？と思うことがあったら、速攻でShiny化して、他人もそのデータに触れるようにするのが、Shinyの良い使い方の一つだと思ってShinyやってます
みなさまの現場でも、良いShinyアプリが生まれますように！