tech.guitarrapc.cóm

Technical updates

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

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

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

アジェンダ

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

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

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

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

順に紹介します。

APM として盤石な New Relic

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

newrelic.com

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

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

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

neue cc - Http, SQL, Redisのロギングと分析・可視化について

知っている限り.NET にとって最強のAPMの1つだと思います。

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

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

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

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

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

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

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

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

Sumo Logic の利用と課題

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

www.sumologic.com

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

neue cc - ASP.NETでの定期的なモニタリング手法

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

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

Sumo Logic の利点

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

www.sumologic.com

www.sumologic.com

  • 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 (過去何日分保持するかの期間) がその決定要素です。

www.sumologic.com

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

グラニが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 もこんなにきれいに表示されます。

www.sumologic.com

しかし、ビジュアライズされた結果やクエリの実行結果を他のサービスのダッシュボードに埋め込んだり、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 でした。

cloud.google.com

議論のなかで行った、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 では負荷が高くなったりすることもありベストな回答にはなりません。

Fluentd | Open Source Data Collector | Unified Logging Layer

github.com

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

www.slideshare.net

tech.tanaka733.net

課題の解決

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:クエリ実行は早いが正義