概要

とある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にお任せできて、なおかつ設定が楽そうだという点だ。