cloudpackにおけるLookerの活用事例

ツール導入前の課題

弊社ではMSPとして24時間365日稼働するクラウド環境のサポートサービス、cloudpackというサービスを提供しています。サービスを運用していくうえで品質向上のため日常的に応対速度や発生した障害の原因などを継続的にモニタリングしています。

（参考：クラウド導入実績 国内トップレベルのcloudpack【クラウドパック】）

cloudpackでは1万台以上のサーバ環境をモニタリングしており、24時間365日発生する障害情報をPagerDutyに集約して管理し、分析用にAmazon S3にも蓄積しています。 蓄積したデータはデータカタログとしてAmazon Athenaで検索できるようになっており、障害情報の分析が可能となっています。

※なお、具体的なcloudpackの運用についてはFindy株式会社様のオフィスで開かれたPagerDuty Japan Community Meetup Vol.4にて、弊社MSPのメンバーが説明しています。

モニタリングのために弊社では分析環境としてECS Fargate（AWS）にセルフホストしたRedashを採用しており、MSP開発セクションがRedashでダッシュボードを作成、MSPセクションがダッシュボードを閲覧するという体制をとっていました。その過程で多くの課題を抱えていました。主な課題としては下記のとおりです。

運用面

• Redash環境で定期的に障害が発生していたため、使いたい時に利用できないことがあった
• 分析環境はできるだけマネージドが良い（運用コストへの削減）

開発面

• MSP開発セクションで分析ダッシュボードを作成し、MSPセクションに提供している状態
• 分析環境の仕様を知っている人ならクエリを作成できるような状態（属人的）
• Redashで実行しているクエリはバージョン管理がされていないため、過去の修正を追跡できない

どのような状態を目指していたか

分析環境のための運用を極力減らし、MSP開発セクション以外のメンバーでも分析ができるような状態を目指しました。

• Redash
• Databricks
• BigQuery

MSPセクションからの依頼をベースにMSP開発セクションが分析ダッシュボードを作成して提供するスタイルからのチェンジ、cloudpackの運用者目線でダッシュボードを作り、個々人が運用状況を把握できるような環境の構築を念頭に置いて移行を検討しました。

Redashのセルフホストを移行する先としてはDatabricksを採用することが多いですが、分析規模が大きい場合においてフィットする場合が多く、オーバースペックだと判断したため今回は採用を見送りました。 ※Databricksで扱える分析はRedash互換であり、昨今ではMLとの連携もしやすいため、運用までのビジョンが見えるのであれば、とてもオススメできます。

データ分析基盤としてBigQueryについても導入の検討を進めましたが、データ移行がネックとなり採用を見送りました。※ただし、データ移行の目処があるようであれば採用をオススメします。

ゆえに今回はLookerで小さく始めて分析するように検討を進めました。

選定理由の決め手になったポイントとしては下記のとおりです。

• 分析環境の運用保守
• クエリのバージョン管理
• LookMLによるクエリ管理

従来の大きな課題としては分析環境の障害対応と実行クエリのバージョン管理です。 まず、たびたび発生している障害について、エラー情報からどのように対応すれば良いかの資料を作成して対応していましたが、障害のたびに未知のエラーに遭遇することが多く、対応に苦慮していました。 （エラーの多くは記録済みのエラーであり、既知のエラーとして対応できることもありました。）

つぎにRedashではバージョン管理の仕組みがありません。GitHubから自動デプロイしてRedashにクエリを共有するなどの仕組みを構築することも可能でしたが、すでにいくつかのクエリがAmazon RDSに保存されているため、GitHubから自動デプロイするような方法で開発環境をマイグレーションすることは難しいと判断しました。

また、Redashの場合はクエリそれぞれにコメントを残すなどの工夫とドキュメントをしっかり書く必要がありました。Lookerの場合はLookMLを使うことでデータをモデリングすることが可能になり、定義だけでなく、データソース内にある各項目の説明も兼ねることができました。

改善したかった課題はどれくらい解決されたか

クエリ作成の属人化を除いてほぼすべて改善されました。クエリ作成の属人化についてはLooker Studioで可視化するような対応にしました。なお、一番大きな改善としては下記のとおりです。

移行後に一度も障害で落ちることなくそして運用することなく分析環境が利用できるようになりました。

どのような成果が得られたか

主な成果としては以下のとおりです。

• （クエリの追加・修正/ダッシュボードの操作を除いて）分析環境の運用がなくなりました
• 実行クエリをGitベースでバージョン管理ができるようになりました
• LookMLを使うことによってクエリの再利用性が向上し、開発効率が上がりました

また、課題の解決とは別に以下の2点についても成果がありました。具体的な内容については活用方法に記載しています。

• SlackとLooker APIを連携した内製ツールの開発（notify-looker-reportの開発）
• MSPセクション内で気軽に相談できるチャンネルの作成

データソースに関すること

弊社の運用分析ではAWSをメインとしているため、データソースへのクエリはAmazon Athenaを採用しています。多くのケースにおいてLookerのデータソースはBigQueryにすることが一般的かもしれませんが、長年蓄積してきたデータをBigQueryに移行しながら今回の課題を解決するのは難しいと判断したため、既存の資産（Amazon Athenaのクエリ）を使いながらマネージドに実行する必要がありました。

現在はAWSのIAMからアクセスキーを発行し、Lookerに接続するようにしています。 具体的な手順は弊社のメディア、iret.mediaに記載がありますのでご興味のある方は参照していただけますと幸いです。

LookerとAmazon Athenaを接続してみた - iret.media

LookMLモデルの設計

クエリを実行する際、LookerではデータソースをLookMLモデルに落とし込む必要があります。 このLookMLモデルを作成する際にどのようなViewを作成すべきかまた、Lookerに最適化するにはどのようにモデルを構築すべきかがとても難易度の高いところでした。

LookMLとは何かについてはiret.mediaにブログを投稿していますので詳細については以下のブログを参照いただけたらと思います。

• 用語を整理しながら学ぶLooker | iret.media
• Lookerの派生テーブルをLookMLで作成するコツ | iret.media

これから導入を検討されている場合については先々のデータ移行についても検討をした上で導入したほうが良いと思います。ただし、トライアルの段階であれば、最小限のライセンスを購入して試してみるのもありです。Lookerはデータを保存しないプラットフォームであるため、Amazon Athenaのように互換性のあるサービスととりあえず連携して利用できるかどうかを検討してみると良いです。

今後の展望としてはLookerユーザの増員とGoogle Cloudのサービスと密に連携、生成AIを活用した新しい分析を検討しています。具体的には以下のとおりです。

• Lookerライセンスを増やし、ダッシュボードの参照ができるユーザを増やすこと
• LookerAPIを活用した取り組みを増やすこと
• Lookerと生成AIを組みわせた活用を布教していくこと（Looker Explorer Assistantの導入すること）
• BigQueryの活用、一部のデータを移行して検証すること