概要

とあるWebサービスのアクセスログの集計をどうするか、という話です。

やりたいこと

一日毎に、アクセスログを対象に集計を行いたい。

必須条件

• 漏れなく、ダブりなくログが集計できること
• 安心、安全にログが集計できる環境であること
• なるべく楽をすること
• ログサイズが大きくなっても問題なく対応できること

現在の状況整理

• 集計対象になり得るログ
  • リクエストURLが取得できるログなら何でもOKなので、ELB、Apacheログあたりか。
• 一日のログサイズ
  • Apacheログ：約3GB。ELBも同じくらい。

調査

Saasのログサービスを見てみる

ポイントは、

• 値段 (お金は無限ではない...)
• API (ログを検索または集計するAPIがないと話にならない)

LogEntries

値段はお手頃だし、様々なログのインポート方法に対応しているが、
ログを検索するAPIのクエリが乏しい。
集計対象のログは、前日のログなのだが、パラメータで指定するtimestampはログのtimestampではなく、ログをインポートした時刻なので、ログのインポートに時差がある場合は、前日のログを検索で絞りこむことが出来ない。
不便そうなので見送る。

PaperTrail

実際にFreeプランを利用してみた。
Freeプランは100MB/monthで、２日間のログ検索期間がつく。
ログをインポートする方法はとても簡単だし、指定したログがあったらアラートを飛ばしてくれるし、
実業務ではなく、個人でサービスを作って運用しているレベルならめちゃくちゃ使える。
ただ、今回のログサイズからすると、料金が高すぎる。
250GB/monthで3日間のログ検索期間を設けるとすると、$585もする！

Loggly

こちらもFreeプランに登録して動かしてみたが、
動きが・・・遅い・・・・・一個一個のアクセスに・・・・時間・・かかりすぎ・・・・・・
値段はまあまあだが、なんだか信用できなくなってしまった。
今回は見送る。

NewRelic

ログの解析・集計というよりも、アプリケーションモニタリングなので、今回は見送る。

SumoLogic

肝心のsearchAPIなのだが、Enterpriseプランのみ利用可能。→Enterpriseプランはいくらかな？→「contact sales」
ハードルが高いので今回は見送る。

仕方ない、他の方法を考えよう

EC2でログを集計するスクリプトを動かす

実は、アクセスログを（日本時間での）一日分にマージしたファイルを、S3に置くというスクリプトをdailyで回している。
生成されたファイルをS3から取得→集計→DBにインポートするスクリプトを、上記のスクリプトが置いてあるEC2でdailyでクーロン実行する方法が考えられる。
では、そこで生まれる懸念点を洗い出そう。

• EC2が落ちないかどうか不安
  • →EC2の監視
• クーロンがちゃんと実行されるか不安
  • →クーロンの監視
• ログを一日分にマージするスクリプトにエラーが起きないか不安
  • →スクリプトのエラー監視
• ログ集計を行うスクリプトにエラーが起きないか不安
  • →スクリプトのエラー監視

「安心安全」という言葉がつくと、コードの実装だけではなく監視がまとわりついてくる。
なおかつ監視しているだけではダメで、リトライを行わせたりすることを考えると、自分たちで実装する部分が多くなってしまう。
なるべく監視が少なくすむ方法を、もう少し考える。

lambda経由でELBログをElasticSearchにインポートする

• lambdaの処理が5分で終わるか不安
  • ElasticSearchのbulkAPIを利用すれば、ログのインポートは早くなる。1ファイル1MB ~ 2MBの場合なら10 ~ 15秒程で処理が終わるらしい。要件証。
• S3からElasticsearchにログをインポートするlambda関数にエラーが起きないか不安
  • →lambdaのエラー監視
• Elasticsearchの容量オーバーでログがインポートされなくなってしまう不安
  • cloudwatchのアラート監視

１つめは、検証結果次第では不安はなくなる。
２つめは、lambdaのログを見れるcloudwatchが大変見づらいので、エラー監視でエラー内容を素早くチェックできるかが肝。
３つめは、ElasticSearchのFree Strage Space(うろ覚え)を、あるしきい値でアラート設定すればOK。また、SNSとlambdaを利用して、自動でElasticSearchのストレージをアップすることができれば、アラートに気づかないという不安を解消できる。

さっきよりもぐっと、監視の数を減らすことができた。
lambdaでELBログをElasticSearchにインポートする事例は、ネット上で沢山転がっているし実現性があるだろう。

fluentdを利用してEC2のApacheログをElasticSearchにインポートする

• fluentdが落ちないか不安
  • →fluentdの監視
• Elasticsearchの容量オーバーでログがインポートされなくなってしまう不安
  • →cloudwatchのアラート監視

１つめは、mackerelの監視を付ければ簡単にslack等にアラートをながせる。実際に落ちた時は、すぐに立ち上げるという方法しか今のところ取れないが・・・。
２つめは、上と同じなので割愛する。

決定

もう一度、要件を復習する。

• 漏れなく、ダブりなくログが集計できること
• 安心、安全にログが集計できる環境であること
• なるべく楽をすること
• ログサイズが大きくなっても問題なく対応できること

Saas系のログサービスを利用したログ集計の構築については、今回は要件に合わなかったので全て見送った。
以下の３つが候補に残ったわけだが、

• EC2でログを集計するスクリプトを動かす
• lambda経由でELBログをElasticSearchにインポートする
• fluentdを利用してEC2のApacheログをElasticSearchにインポートする

最低限の要件は満たせている中で、一番「楽」ができそうなのが「fluentdを利用してEC2のApacheログをElasticSearchにインポートする」だと考える。

選定理由は、fluentdの安定感と、監視をmackerelにお任せできて、なおかつ設定が楽そうだという点だ。