tech.guitarrapc.cóm

Technical updates

トップ > BigQuery > なぜ私たちはSumo Logicを捨ててBigQueryを選んだのか
最終更新日

なぜ私たちはSumo Logicを捨ててBigQueryを選んだのか

BigQuery Logging Observability C#

ログ分析サービスはアプリケーションのインフラであり、サービス開発/運用の中で重要な位置を占めます。グラニでは、今年に入って利用しているログ分析サービスを、 Sumo LogicからGoogle BigQueryに完全移行しました、

本記事は、グラニで議論された「ログ分析サービスとしてのSumoLogicとBigQuery」のまとめを推敲、転載したものです。これからログ分析サービスを検討される方々にとって、議論の内容が少しでも参考になることを願い公開します。

アジェンダ

まずは文脈を整えるためにアジェンダから。

日常的なアプリケーション監視フロー

グラニのアプリケーション監視は、Application Performance Management(APM)とログ分析サービスの2つに分類できます。それぞれのサービスを以下のように使い分けています。

サービス 用途 利用頻度
APMサービス 普段のアプリケーション監視 常時
ログ分析サービス アプリケーションが吐いたログの詳細分析分析 必要に応じて

順に紹介します。

APM として盤石なNew Relic

グラニではアプリケーションの稼働状況を開発者自身が常に見ており、パフォーマンスの劣化やエラーを含めて「自分の書いたコードが本番で異常なく動いているかNew Relicを見ていれば検知できる」ようにしています。デプロイ後のアプリケーションの応答状況、どんな例外がどのコードで発生したかなどなど、アプリケーションが正常に挙動しているかの確認に必要なほとんどはNew Relicセンセーが教えてくれます。

https://newrelic.com/

New Relicはさまざまなプログラミング言語に対応しており、PHPだったころから現在のC# でも愛用しています。よくRubyやPythonでの利用をスライドで見ますが、.NETに関してもインストールするだけで様々なメトリックを深いレイヤーから取得してくれます。*1

  • ASP.NET MVCのプロファイリング
  • リアルタイムエラー検知
  • ASP.NETから呼び出したデータベースのパフォーマンス
  • 外部サービス (CDN / API) パフォーマンス
  • サーバーパフォーマンスに関する各種メトリック

標準的なプロファイラー以外にもAPIやCustom DashBoard機能をもっており、アプリケーションから監視したい内容を任意でなげることもできます。このあたりは @neueccが過去に紹介しています。

https://neue.cc/2013/07/30_420.html

ログ分析サービスによるアドホックなログ分析

グラニでは、本番環境でもSQLやRedisのコマンド発行状況をログ取得しています。そのため、実際に実行されたクエリなど、アプリケーションの詳細な挙動はログの収集～分析によっていつでも把握できます。ログ分析サービスを利用するのは、まさにこの収集したログの分析するためです。*2

ログ分析サービスを利用することで「サービス全体」だけでなく「個別のサーバー単位」でも横断的にログを分析します。例えば、指定した時間帯での「サービス全体の特定のSQLの実行件数とAvgの実行時間」「サーバーごとの同結果」などは同じデータソースから抽出してボトルネックはどこにあるのか、どの程度実際に実行されているのかを把握しています。

ログ分析サービスに求めること

グラニはログ分析サービスには、5つの役割があると考えています。

用途 概要
アドホックなクエリ実行
(オンデマンド) 		全サーバーから収集したログに対するクエリ実行。
定常的なログ監視 クエリ化されたログ監視をスケジューリング実行することで、ログからアプリケーションの状態を監視、異常の検出が可能です。
分析結果のビジュアライズ 分析結果のビジュアライズによりログの傾向が一目でわかります。主に監視用途に利用されエラーの予見に役立ちます。
ログ集積 ログは過去データとの比較が重要です。蓄積、リテンション(一定期間だけ保持)機能が求められます。
ログ分析API ログ分析基盤として連携するため、外部から分析クエリを投げて結果を返してくれることが求められます。

グラニにとって定常的なログ監視(Log Monitoring) はNew Relicによってなされていることを利用フローでも触れました。

そのためログ分析サービスには、蓄積されたログに対する アドホックなクエリ実行 による横断的な集計、計測、抽出に優れていることを求めています。例えば、対象のログ容量が1TB超えであってもクエリ実行時間は30秒程度で完了することが期待されます。

Sumo Logic の利用と課題

これまでログ分析サービスとしてSumo Logicをつかってきました。

https://www.sumologic.com/

CTOやこのブログでも何度か取り上げています。

https://neue.cc/2013/07/20_416.html

https://tech.guitarrapc.com/archive/category/SumoLogic

Sumo Logic利用開始後からアプリケーションの課題を発見、改善してきました。そこで見えたSumo Logicの利点に触れておきます。

Sumo Logic の利点

Sumo Logicが他社に比べて圧倒的な強みとして大きく謳っているのが Log Reduce と Anormaly Detection を活用したログ監視機能です。

https://www.sumologic.com/resource/featured-videos/demo-sumo-logic-log-reduce-next-generation-log-analytics-featured-video/

https://www.sumologic.com/resource/datasheet/anomaly-detection/

  • Log Reduce

クエリで抽出したログ結果をただ表示するのではなく、傾向を分析して大多数のログをまとめあげることで、ログを排除することなくノイズを減らし「意味のあるデータ」を浮かび上がらせる機能です。事実、ノイズが減ることで異常値と考えられる少数のログが抽出されます。これは人の手での分析では難しい機械学習を利用した素晴らしい機能といえます。

133Pも出てしまったクエリ結果があった時に、ここから異常と思われるログを探すのは困難でしょう。

しかし、Log Reduceを実行するだけで、ログの傾向が学習結果に応じてまとめあげられ、見るべき内容が一気に狭まります。

  • Anormaly Detection

機械学習によって、異常と思われるデータを収集ログから自動的に判別してくれます。さらにLog Reduceと併用することで、事前に異常と思われるデータの抽出、分析も可能とする機能です。とてもいい機能なんですが、日本語での紹介がなくてもんにょりしますね！ *3

これらの機能に加えて「可視化されるスケジュールジョブも標準でついてくる」ことから、ログ分析のクエリ速度や機能よりログ監視基盤としての機能に秀でていると言え、本社経営陣もここを強くアピールしていました。

Sumo Logicで発生した課題

しかし、サービス規模の拡大と共にSumo Logicで抱える課題も大きくなり、昨年から今年にかけて「ログ収集基盤の見直し」と「ログ分析サービスの見直し」を行いました。 グラニで発生したSumo Logicの課題は大きく以下の通りです。

  • ログ収集量の限界
  • リアルタイムログ分析としてのクエリ速度
  • ログ分析サービスと他サービスの連携容易性
  • ログコレクターの展開容易性

それぞれの課題は、Sumo Logicの本社経営陣、エンジニアとも協議対応を図りましたが、最終的には解決困難な問題という共通認識となりました。*4

順番に見ていきましょう。

ログ収集量の限界

Sumo Logicの課金体系はログ容量で決まります。具体的には、Data Volume(ひと月のログ収集量) とRetention Period (過去何日分を保持するかの期間) がその決定要素です。

https://www.sumologic.com/pricing/

この「収集できるログ容量の限界が契約価格に直結する」サービス形態が大きな課題として立ちはだかることになりました。

グラニがSumo Logicと取り交わしたのは、100GB/Monthという契約でした。*5

さて、本番環境におけるRedisコマンドやSQLクエリをロギング、収集していると紹介しました。特にRedisはキャッシュ用途で利用されていることもあり、大量のログが生成されます。具体的には、サービス全体で数百GB/DayがRedisだけで生成されます。SQLなども数十GB/Day以上が生成されています。そのため、100GB/Monthという契約内に収集するログ容量を収めるため、Redisログに関しては一部台からのみ収集するという対処を取らざるを得ませんでした。

一部の台からのみログを収集することは、一見問題なさそうですが収集していないサーバーでのログが抜け落ちます。結果、一部の台で発生したスパイクや処理が取得、分析できないことが実際に発生したことで大きな課題と認識されるようになりました。

リアルタイムログ分析としてのクエリ速度

SumoLogicでログ分析する時、クエリ実行時間は対象のログ容量でリニアにスケールします。

ログ容量の小さいIISやWebサーバーのトランザクションログであれば、2分程度で結果が可視化されて返ってきます。

しかし、「Redisログ」や「1か月など長いスパン」など膨大なログに対してクエリ実行すると完了まで15分かかることが頻繁にあり、さらには予告なしにタイムアウトするという仕様もあり、クエリ実行に満足できない事態が頻発しました。具体的には、150000000行以上のレコードに対してクエリを実行すると、1時間たっても完了せずタイムアウトを迎えます。

回避策がないわけではありません。Sumo Logicには、スケジューラー機能があり、特定のクエリを毎分実行できます。これを使うと対象の期間が極めて短いため、瞬時に実行完了します。しかし、グラニは毎回取得したデータがことなるため、アドホック、オンデマンドにログ分析を実行することが殆どで、スケジュール機能による回避は適していませんでした。

ログ分析サービスと他サービスの連携容易性

Sumo Logicは、ログ分析結果を見ることにも秀でており、統合監視ビューとして利用することも売りにしています。実際、Sumo Logicはログ分析結果をビジュアライズしてくれ、AWSのCloud Trailもこんなにきれいに表示されます。

https://www.sumologic.com/application/aws-cloudtrail-log-analyzer-speed-scale-anomaly-detection/

しかし、ビジュアライズされた結果やクエリの実行結果を他のサービスのダッシュボードに埋め込んだり、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によるインストール保証ができないことに加えて、不明な理由でインストール失敗することが多々発生しました。*6 同じインストールでも、新規にサーバーを起動して、同コマンドで失敗することがあるのでとてもストレスでした。

捨てたサーバーのエージェント情報がSumo Logic管理画面から消えず上書きが困難

Sumo Logicは、エージェントの入ったホストをホスト名で管理しており、一度登録したホストと重複したホスト名がエージェントから送られてくると -xxxxxといったランダムな英数文字がついて一意に特定されます。これが、グラニで行っている、Disposableなサーバー運用と相性が悪い結果になりました。

グラニでは、サーバー構成に変化があったりするとサーバーを頻繁に入れ替えています。そのたびにSumo Logicの管理画面上でホスト名が新たに作られ、登録情報を別途管理しないといけないのが自動化していてももんにょりするポイントでした。

Disposableな環境との相性の悪さも課題でした。

課題のまとめ

以上の課題をまとめると表の通りです。無茶に見えますか？ 見えますね。

課題 考えられる対策
ログ収集量の限界 ひと月 TB を超える容量を蓄積できて許容範囲の課金で済むこと*7
リアルタイムログ分析としてのクエリ速度 1TB を超えるログに対するクエリが数十秒で完了する実行速度
ログ分析サービスと他サービスの連携容易性 APIが豊富で、分析APIを投げると抜けなく結果が返ってくること
ログコレクターの展開容易性 インストールの確実性とエージェント管理の不要さ

Sumo Logic と BigQuery の比較

Sumo Logicを使う中で見えてきた課題が顕著になってきたきた時に、@neueccが好感触として採用候補にあげたのがGoogle BigQueryでした。

https://cloud.google.com/bigquery/?hl=ja

議論のなかで行った、Sumo Logicとの比較は次の通りです。

SumoLogic と BigQuery の特徴

SumoLogicとBigQueryを振り返ってみるとそれぞれに強みが異なります。

サービス クエリ実行速度 API 分析結果の他サービスとの連携 課金体系
SumoLogic 分析対象サイズに依存。500GB程度でタイムアウト 分析結果のビジュアライズとダッシュボードの提供 分析結果を他サービスで取得、連携は困難 容量課金
BigQuery 分析対象サイズに非依存。500GBでも30秒程度で完了 ビジュアライズは提供していない BigQuery APIで分析結果を連携可能 クエリ課金

BigQueryが売りとしており、またグラニがログ分析サービスに求める機能である、アドホックなクエリ実行速度を比較してみます。

クエリ実行速度

Sumo Logicで完了できないクエリが以下です。

_sourceCategory=redis
| json "date","group","command"
| count command, group

これを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では、分析対象ログがどれほど大きくても数十秒で完了できます。

Sumo Logic のクエリ速度がBigQuery より遅い理由

Sumo Logicのクエリが遅いのは、ログをクエリ実行時に都度パースしているためです。逆に、BigQueryが高速な理由の一因は、ログが投入時に構造化されているためです。

Sumo Logicに収集したログが構造化されることに関しては、Sumo Logicエンジニアとクエリコアに手を入れて違いを確認しています。逆にいうと、Sumo Logicはこのクエリ速度を改善できる可能性があります。

BigQuery への移行

最大の課題である、容量とクエリ速度がBigQueryを利用することで解決しました。

ただし、BigQueryはエージェントを持っていないためログ収集という課題が発生しました。Linuxであれば、Fluentdという手が一般的ですが、Windowsでは負荷が高くなったりすることもありベストな回答にはなりません。

https://www.fluentd.org/

https://github.com/kaizenplatform/fluent-plugin-bigquery

そこで、グラニではSLAB (Semantic Logging Application Block) を利用して、ETW*8 経由でBigQueryにストリーミングインサートしています。具体的に、WindowsからどのようにしてBigQueryにログを送っているかは、@neueccのスライドや@tanaka_733の記事に詳しいです。

https://www.slideshare.net/neuecc/bigquery-in-Windows

https://tech.tanaka733.net/entry/2014/07/25/EnterpriseLibrary6-SLAB-Out-of-Process

課題の解決

SLABを使って「構造化ログ」と「Out-Of-Process Sink」の導入によってログ収集問題が解決しました。Sumo Logicの課題は以下のように解決されています。

課題 考えられる対策
ログ収集量の限界 クエリ課金のため全台からログ収集しても容量制限がなく、容量課金もS3以下の単価です
リアルタイムログ分析としてのクエリ速度 1TB だろうとログ容量に関わらずクエリが数十秒で完了します
ログ分析サービスと他サービスの連携容易性 Google BigQuery APIはWebコンソール同様に処理が可能で、APIを投げると抜けなく結果が返ります
ログコレクターの展開容易性 エージェントが存在しないため、移行時にSLABを使って BigQuery-Sink を作成して対応

まとめ

私たちは、NewRelicをベースとした体制を考えたときに、クエリ実行が快適に完了するアドホックなログ分析基盤を求め、Sumo LogicよりもBigQueryが適正していると判断しました。いくつかの技術的なハードルがあったものの、SLABを利用した体制にすることで、NLogの脱却も果たしています。

アドホックにクエリを実行する機会が多く、ログ送信もSLABなどで容易に行える環境にはBig Queryをおすすめします。Linuxなどは特にFluentdがあるのでハードルは低いでしょう。

一方で、「ログ分析から可視化されたグラフまで常にスケジューリングして閲覧する」統合的なログ分析サービスを求めるならSumo Logicがいいでしょう。

最後に、今回の記事で書いた課題のほとんどは「Sumo Logic経営陣とエンジニアにフィードバックを送り、Private BetaをSumo Logicと行って改善を確認」しています。もし採用されて、サービスにてGAが公開されればSumo Logicは化けるでしょう。真剣にフィードバックを聞き入れてくれたSumo Logicには心から感謝をしています。*9

読まれた方々が「ログ分析サービスに何を求めるのか」を考える時にこの記事が役に立てば望外の喜びです。

結び

この議論をブログで公開することを認めてくれた、チームメンバーとCTOの@neueccに深く感謝します。

さようならSumo Logic、こんにちはBigQuery。*10

*1:実際に直接New Relicの .NETエンジニアとやり取りをしてもすさまじい技量を持っていることが分かります

*2:New Relicでは全サーバーから収集されているログを収集することもデータとして抽出、分析できません。

*3:私は紹介しません

*4:協議の詳細はNDAのため語れません....

*5:これでもそれなりの価格だったため、これ以上の容量増大は望ましくありませんでした

*6:Linuxでは安定していました

*7:S3レベルの単価

*8:Event Tracing for Windows

*9:フィードバックが採用される予定はあるのか。されてもいつかは知りませんし、まだ公開されてないので詳細は言えませんが...

*10:クエリ実行は早いが正義