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