ログ分析サービスはアプリケーションのインフラであり、サービス開発/運用の中で重要な位置を占めます。謎社では、今年に入って利用しているログ分析サービスを、 Sumo Logic から Google BigQuery に完全移行しました、
本記事は、謎社で議論された「ログ分析サービスとしての SumoLogic と BigQuery」のまとめを推敲、転載したものです。これからログ分析サービスを検討される方々にとって、議論の内容が少しでも参考になることを願い公開します。
アジェンダ
まずは文脈を整えるためにアジェンダから。
- 日常的なアプリケーションの監視フロー
- ログ分析サービスに求めること
- Sumo Logic の利用と課題
- Sumo Logic と BigQuery の比較
- BigQuery への移行
日常的なアプリケーション監視フロー
謎社のアプリケーション監視は、Application Performance Management(APM) と ログ分析サービス の2つに分類できます。それぞれのサービスを以下のように使い分けています。
| サービス | 用途 | 利用頻度 |
|---|---|---|
| APMサービス | 普段のアプリケーション監視 | 常時 |
| ログ分析サービス | アプリケーションが吐いたログの詳細分析分析 | 必要に応じて |
さっそく、謎社で行っているアプリケーションの監視フローを紹介します。
APM として盤石な New Relic
謎社では、アプリケーションの稼働状況を開発者自身が常に見ており、パフォーマンスの劣化やエラーを含めて「自分の書いたコードが本番で異常なく動いているか New Relic を見ていれば検知できる」ようにしています。デプロイ後のアプリケーションの応答状況、どんな例外がどのコードで発生したかなどなど、アプリケーションが正常に挙動しているかの確認に必要なほとんどは New Relic センセーが教えてくれます。
New Relic はさまざまなプログラミング言語に対応しており、PHPだったころから現在の C# でも愛用しています。よく Ruby や Python での利用をスライドで見ますが、.NET に関しても インストールするだけで様々なメトリックを深いレイヤーから取得してくれます。*1
- ASP.NET MVC のプロファイリング
- リアルタイムエラー検知
- ASP.NET から呼び出したデータベースのパフォーマンス
- 外部サービス (CDN / API) パフォーマンス
- サーバーパフォーマンスに関する各種メトリック
標準的なプロファイラー以外にも API や Custom DashBoard 機能をもっており、アプリケーションから監視したい内容を任意でなげることもできます。このあたりは @neuecc が過去に紹介しています。
知っている限り.NET にとって最強のAPMの一つだと思います。
ログ分析サービスによるアドホックなログ分析
謎社では、本番環境でも SQL や Redis のコマンド発行状況をログ取得しています。そのため、実際に実行されたクエリなど、アプリケーションの詳細な挙動はログの収集～分析によっていつでも把握できます。ログ分析サービスを利用するのは、まさにこの収集したログの分析を行うためです。*2
ログ分析サービスを利用することで「サービス全体」だけでなく「個別のサーバー単位」でも横断的にログを分析します。例えば、指定した時間帯での「サービス全体の特定の SQLの実行件数と Avgの実行時間」、「サーバーごとの同結果」などは同じデータソースから抽出してボトルネックはどこにあるのか、どの程度実際に実行されているのかを把握しています。
ログ分析サービスに求めること
謎社はログ分析サービス には、5つの役割があると考えています。
| 用途 | 概要 |
|---|---|
| アドホックなクエリ実行 (オンデマンド) |
全サーバーから収集したログに対するクエリ実行。 |
| 定常的なログ監視 | クエリ化されたログ監視をスケジューリング実行することで、ログからアプリケーションの状態を監視、異常の検出が可能です。 |
| 分析結果のビジュアライズ | 分析結果のビジュアライズによりログの傾向が一目でわかります。主に監視用途に利用されエラーの予見に役立ちます。 |
| ログ集積 | ログは過去データとの比較が重要です。蓄積、リテンション(一定期間だけ保持)機能が求められます。 |
| ログ分析API | ログ分析基盤として連携するため、外部から分析クエリを投げて結果を返してくれることが求められます。 |
謎社にとって定常的なログ監視(Log Monitoring) は New Relic によってなされていることを利用フローでも触れました。
そのためログ分析サービスには、蓄積されたログに対する アドホックなクエリ実行 による横断的な集計、計測、抽出に優れていることを求めています。例えば、対象のログ容量が1TB 超えであってもクエリ実行時間は30秒程度で完了することが期待されます。
Sumo Logic の利用と課題
これまでログ分析サービスとして Sumo Logic をつかってきました。
CTO やこのブログでも何度か取り上げています。
利用開始後から多くの場面で Sumo Logic でアプリケーションの課題を発見、改善してきました。そこで見えた Sumo Logic の利点に触れておきます。
Sumo Logic の利点
Sumo Logic が他社に比べて圧倒的な強みとして大きく謳っているのが Log Reduce と Anormaly Detection を活用したログ監視機能です。
- Log Reduce
クエリで抽出したログ結果をただ表示するのではなく、傾向を分析して大多数のログをまとめあげることで、ログを排除することなくノイズを減らし「意味のあるデータ」を浮かび上がらせる機能です。事実、ノイズが減ることで異常値と考えられる少数のログが抽出されます。これは人の手での分析では難しい機械学習を利用した素晴らしい機能といえます。
133P も出てしまったクエリ結果があった時に、ここから異常と思われるログを探すのは困難でしょう。
しかし、Log Reduce を実行するだけで、ログの傾向が学習結果に応じてまとめあげられ、見るべき内容が一気に狭まります。
- Anormaly Detection
機械学習によって、異常と思われるデータを収集ログから自動的に判別してくれます。さらに Log Reduce と併用することで、事前に異常と思われるデータの抽出、分析も可能とする機能です。とてもいい機能なんですが、日本語での紹介がなくてもんにょりしますね！(私は紹介しません
これらの機能に加えて「可視化されるスケジュールジョブも標準でついてくる」ことから、ログ分析のクエリ速度や機能よりログ監視基盤としての機能に秀でていると言え、本社経営陣もここを強くアピールしていました。
Sumo Logicで発生した課題
しかし、サービス規模の拡大と共に Sumo Logic で抱える課題も大きくなり、昨年から今年にかけて「ログ収集基盤の見直し」と「ログ分析サービスの見直し」を行いました。 謎社で発生した Sumo Logic の課題は大きく以下の通りです。
- ログ収集量の限界
- リアルタイムログ分析としてのクエリ速度
- ログ分析サービスと他サービスの連携容易性
- ログコレクターの展開容易性
それぞれの課題は、Sumo Logic の本社経営陣、エンジニアとも協議対応を図りましたが、最終的には解決困難な問題という共通認識となりました。*3
順番に見ていきましょう。
ログ収集量の限界
Sumo Logic の課金体系は、Data Volume(ひと月のログ収集量) と Retention Period (過去何日分保持するかの期間) で決まります。
この「収集できるログ容量の限界が契約価格に直結する」サービス形態が大きな課題として立ちはだかることになりました。
謎社がSumo Logic と取り交わしたのは、100GB/Month という契約でした。*4
さて、本番環境におけるRedis コマンドや SQL クエリをロギング、収集していると紹介しました。特にRedis はキャッシュ用途で利用されていることもあり、大量のログが生成されます。具体的には、サービス全体で 数百GB/Day が Redis だけで生成されます。SQLなども 40GB/Day以上 が生成されています。そのため、100GB/Month という契約内に収集するログ容量を収めるため、Redis ログに関しては一部台からのみ収集するという対処を取らざるを得ませんでした。
一部の台からのみログを収集することは、一見問題なさそうですが大きな問題があります。ログが抜け落ちるため、一部の台で発生したスパイクや処理が取得、分析できないことが実際に発生したからです。
リアルタイムログ分析としてのクエリ速度
SumoLogic でログ分析する時、クエリ実行時間は対象のログ容量でリニアにスケールします。
ログ容量の小さいIISやWebサーバーのトランザクションログであれば、2分程度で結果が可視化されて返ってきます。
しかし、「Redisログ」や「1か月など長いスパン」など膨大なログに対してクエリ実行すると完了まで15分かかることが頻繁にあり、さらには予告なしにタイムアウトするという仕様もあり、クエリ実行に満足できない事態が頻発しました。具体的には、150000000行以上のレコードに対してクエリを実行すると、1時間たっても完了せずタイムアウトを迎えます。
回避策がないわけではありません。Sumo Logic には、スケジューラー機能があり、特定のクエリを毎分実行することができます。これを使うと対象の期間が極めて短いため、瞬時に実行完了します。しかし、謎社は毎回取得したデータがことなるため、アドホック、オンデマンドにログ分析を実行することが殆どで、スケジュール機能による回避は適していませんでした。
ログ分析サービスと他サービスの連携容易性
Sumo Logic は、ログ分析結果を見ることにも秀でており、統合監視ビューとして利用することも売りにしています。実際、Sumo Logic はログ分析結果をビジュアライズしてくれ、AWS の Cloud Trail もこんなにきれいに表示されます。
しかし、ビジュアライズされた結果やクエリの実行結果を他のサービスのダッシュボードに埋め込んだり、APIで取得する機能はありませんでした。そのため、ログ分析基盤として Sumo Logic を使って、分析結果を独自Webページに埋め込むということも難しくSumo Logic から先の連携が困難でした。
ログ分析の統合ソリューションとしてはいいと思うのです。実際にSumo Logic の経営陣やエンジニアが目指すのもそうでした。しかし、New Relic で普段の監視を完結させ、ログ分析サービスには分析を投げて結果を他でも利用したいと思っていた謎社には課題として目に映りました。
ログコレクターの展開容易性
SumoLogic は、ログ分析対象とするログを集積する方法がを エージェント方式 と HTTPソース方式 から選択できます。
| 方式 | 概要 |
|---|---|
| エージェント方式 | Sumo Logicエージェントを Windows サービス や Linux デーモンとしてインストールできます。あとは収集対象を JSONフォーマットで指定することで自動的にSumo Logic に定期取得されます。 |
| HTTPソース方式 | S3 においたログを自動的に Sumo Logic に収集されます。 |
謎社では、エージェント方式を利用していました。これは、HTTP ソース方式では自前でログアップロードのリトライ管理などが必要なことを嫌ったためです。
一方で、エージェント方式では以下の問題がありました。
インストールが失敗することがある
エージェントのインストールはコマンドラインからできましたが、.exe だったため .msi によるインストール保証ができないことに加えて、不明な理由でインストールが失敗することが多々発生しました。*5 同じインストールでも、新規にサーバーを起動して、同コマンドで失敗することがあるのでとてもストレスでした。
捨てたサーバーのエージェント情報がSumo Logic管理画面から消えず上書きが困難
Sumo Logic は、エージェントの入ったホストをホスト名で管理しており、一度登録したホストと重複したホスト名がエージェントから送られてくると -xxxxx といったランダムな英数文字がついて一意に特定されます。これが、謎社で行っている、Disposableなサーバー運用と相性が悪い結果になりました。
謎社では、サーバー構成に変化があったりするとサーバーを頻繁に入れ替えています。そのたびにSumo Logic の管理画面上でホスト名が新たに作られ、登録情報を別途管理する必要があるのが自動化していてももんにょりするポイントでした。
Disposable な環境との相性の悪さも課題でした。
Sumo Logic と BigQuery の比較
Sumo Logic を使う中で見えてきた課題が顕著になってきたきた時に、@neuecc が好感触として採用候補にあげたのが Google BigQuery でした。
議論のなかで行った、Sumo Logic との比較は次の通りです。
SumoLogic と BigQuery の特徴
SumoLogic と BigQuery を振り返ってみるとそれぞれに強みが異なることが分かります。
| サービス | クエリ実行速度 | API | 分析結果の他サービスとの連携 | 課金体系 |
|---|---|---|---|---|
| SumoLogic | 分析対象サイズに依存。500GB程度でタイムアウト | 分析結果のビジュアライズとダッシュボードの提供 | 分析結果を他サービスで取得、連携は困難 | 容量課金 |
| BigQuery | 分析対象サイズに非依存。500GBでも30秒程度で完了 | ビジュアライズは提供していない | BigQuery APIで分析結果を連携可能 | クエリ課金 |
謎社がログ分析サービスに求める機能である、アドホックなクエリ実行速度を比較してみます。
クエリ実行速度
Sumo Logicで完了できないクエリをBigQuery で実行してみましょう。
クエリ対象 : 3327964712 (X87GB) in 3.47 sec.
SELECT command, group, COUNT(command) as Count FROM [diagnostics.Redis_2014MMDD] GROUP BY command, group
たとえ GROUP EACH BY を使っても 10secで完了します。 (GROUP EACH BY は遅くなるクエリといわれています。)
SELECT key, group, COUNT(key) as Count FROM [diagnostics.Redis_2014MMDD] GROUP EACH BY key, group ORDER BY Count desc LIMIT 100
クエリ速度がログ容量に依存しないのはとても重要です。BigQuery では、分析対象ログがどれほど大きくても数十秒で完了できます。
BigQuery への移行
- クエリの実行が完了すること
- クエリ課金のため全台からログ収集しても容量制限がない*6
この2点は、Sumo Logic で抱えていた最大の課題を解決しました。ただし、BigQuery はエージェントを持っていないため、ログ収集という課題が発生しました。
Linux であれば、Fluentd という手が一般的ですが、Windows では負荷が高くなったりすることもありベストな回答にはなりません。
Fluentd | Open Source Data Collector | Unified Logging Layer
そこで、謎社では SLAB (Semantic Logging Application Block) を利用して、Event Tracing for Windows 経由で BigQuery にストリーミングインサートしています。
Windows からどのようにして BigQuery にログを送っているかは、@neuecc のスライドや @tanaka_733の記事に詳しいです。
www.slideshare.net
まとめ
自分たちの環境にとって、ログ分析サービスに何を求めるのか。この記事が役に立てば望外の喜びです。
私たちは、NewRelic をベースとした体制を考えたときに、クエリ実行が快適に完了するアドホックなログ分析基盤を求め、Sumo Logic よりもBigQuery が適正していると判断しました。いくつかの技術的なハードがあったものの、SLAB を利用した体制にすることで、NLog の脱却も果たしています。
アドホックにクエリを実行する機会が多く、ログ送信もSLAB などで容易に行える環境にはBig Queryをおすすめします。Linux などは特に Fluentd があるのでハードルは低いでしょう。
一方で、Sumo Logic の画面でログ分析から可視化されたグラフまで常にスケジューリングして閲覧するなら、Sumo Logic がいいでしょう。*7
結び
この議論をブログで公開することを認めてくれた、チームメンバーとCTO の@neuecc に深く感謝します。
さようなら Sumo Logic、こんにちは BigQuery。クエリ実行は早いが正義です。
*1:実際に直接 New Relic の .NET エンジニアとやり取りをしてもすさまじい技量を持っていることが分かります
*2:New Relic では全サーバーから収集されているログを収集することもデータとして抽出、分析することもできません。
*3:協議の詳細はNDAのため語れません....
*4:これでもそれなりの価格だったため、これ以上の容量増大は望ましくありませんでした
*5:Linux では安定していました
*6:容量課金がそれほど問題にならない
*7:今回の記事で書いた課題のいくつかはいくつかのフィードバックやPrivate BetaをSumo Logicと行って改善を確認しているのでGAされれば化けるでしょう。いつかは知りませんしまだ公開されてないので詳細は言えません。