ども、id:kazuph1986 です。この記事は、Akerun Advent Calendar 2018 の1日目の記事です。
今回は弊社のログの活用をするためにサクッとElasticsearchを導入して業務改善を行った話をします。
背景
弊社では利用関連のデータはすべてDBに保持しており、データをRails consoleやRedashを用いて確認・分析を行っております。
ですが、IoT機器自体のログをすべてDBに含めるのは（負荷・量・金銭コスト的に）無理があったため、そのままサーバーのログとして吐き出しているだけのものもあります。
弊社ではログの収集については、
リアルタイムにCloudWatchLogsに送信
日次でS3に送信
しており、それぞれ
という分け方をしていました。
サポートのために弊社のカスタマーサポート（以下、CS）のメンバーと一緒にエンジニアが調査を行うことも多いのですが、このCloudWatchLogsの方のデータについては、クエリや集計の弱さ、AWS Conosleの権限の中にエンジニア以外が含まれてくる煩雑さ（IAM）等の理由により、そのままではCSメンバーには提供してませんでした。そのためエンジニアが調査作業のたびにCSから依頼を受け、AWS のconsoleを開きログの確認をせざるを得ない状況になっていました。
解決方法
そ・こ・で！どうしようと思っていた時にAWS のCloudwatchLogsがElasticsearchへの吐き出しに標準で対応していると知り、
「もしかして一瞬でできる？？」
と思いやってみたのでした。
結果的に1日くらいの工数 で構築できたので、もし似たようなケースであれば、かなりおすすめです。
しかも僕はハマってしまったので1日でしたが、わかっていれば1, 2時間くらいで終わると思います。
はまりポイントは以下でした。最も時間がかかったのが地味に一番上のやつです。AWS 力を上げないとなと思いました。
デフォで生成されるvpc *********.comのURLがPrivate IPのを返却していると気づいてなかった（EC2のような感覚でネットワークパスを通そうとしてしまった）
弊社のログがLTSV形式だったのでLambda側のパースの処理でちょっと試行錯誤が必要だった
Elasticsearch自体のindexの概念の学習コスト
それでは実際にやってみましょう！
1. Elasticsearchのインスタンス を立ち上げる
AWS は「Amazon Elasticsearch Service(以下、ES)」というフルマネージドなサービスを提供しています。
ESの画面に行ったら「新しいドメイン の作成」からサクッと作成できます。
AWS Console ES
次の画面で、ドメイン 名とESのバージョンの指定ができます。
次へを押すと、インスタンス タイプ等の設定画面に行きます。最初はt2系で立てたのですが、インスタンス のタイプ毎にストレージ上限が決まっているため、容量が必要になるたびに増やす必要があります。ただ一旦低いので立てておいて、あとからスケールアップするのは簡単だったので、お試しではt2でも問題ないかもしれません。ちなみにt2系はすべて35Gが上限です。
docs.aws.amazon.com
次にネットワーク構成を選択します。ほとんどの場合社内利用だと思いますので、VPC アクセスで問題ないと思います。
次に認証ですが、AWS のCognitoを挟むこともできますし、単にVPC でのアクセス制限もできます。今回は「IAM認証情報を使用した署名リクエス トを要求しない」にしました。
これで必須のものを全部選択して、確認画面に行き、「確認」を押すことでインスタンス の生成がはじまります。
2. CloudWatchLogsとの連携
連携は非常に簡単です。ESへのストリーミングを開始を押し、
先程作成したESのクラスタ とログの形式を指定します。
右下の「ストリーミングを開始」ボタンを押すと即刻連携がはじまります。
簡単ですね^^
3. (必要なら)Lambdaを編集する
上記まで完了するとLambdaの関数も自動で作成されます。
そうです、実は、連携と言って起きながら、AWS さんはそれを実現するためのLambdaを作成しているだけなのでした。
Lambdaですので、普通のソースを編集できます（JS）。
弊社ではログをLTSVで出力しているため、これをES様に変換するスクリプト に修正します。
100行目くらいにある buildSource を少し修正します。
function buildSource(message, extractedFields) {
var log={} ;
message
.split(/\t/ )
.map(function (s) {
var res = s.match(/(.+?):(.*?)$/ );
return [ res[ 1] , res[ 2]] ;
} ).map(function (ary){
log[ ary[ 0]] = ary[ 1]
} );
log[ 'time' ] = moment.parseZone(log[ 'time' ] , 'DD:hh:mm:ss' ).toISOString();
log[ 'size' ] === '-' ? -1 : parseInt(log[ 'size' ] )
log[ 'reqtime' ] === '-' ? -1.0 : parseFloat(log[ 'reqtime' ] )
return log;
...
}
型が合わないとES側で適切に検索・集計ができないので、おそらくここで試行錯誤することになります。
基本的に今回はストリームを想定しているので、過去分を間違って登録してしまった場合は、ES側のデータを全部吹っ飛ばすなどしてやり直しましょう。
逆に過去分を全部集計するような場合は、またS3＋Athenaが向いていると思うので、それは別途書きます。
4. ESのkibanaを見れるようにする
上記までがうまくいっていると、実際にESの方で可視化ができるようになります。
AWS で構築するESには最初からkibanaというビジュアライゼーションツールが入っているので、こちらを利用しましょう（AWS だからというかESについている）。
kibanaのURLもESの管理画面から確認できます。
ですが、冒頭言ったように、普通にこのvpc 〜のURLをクリックしても、VPC 内のPrivateなIPを返すため、会社などのPCからはそのままでは閲覧できません。
VPC に対してVPN を張るか、プロキシサーバーやLBを追加する必要があります。
弊社では、社内閲覧のために以下の2種類の方法を使っています。
Route53 + ALBで見えるようにする
プロキシサーバーを構築して見えるようにする
ALBを利用する方法については、クラスメソッドさんの記事が詳しいです。
dev.classmethod.jp
本当の意味でPublicにするかは設定次第で、弊社では社内IPからのみ許可するようにALBのセキュリティグループを設定しています。
Route53にてわかりやすいドメイン をつけることで、社内での利用がしやすくなっています。
またプロキシサーバーについてはsquid を用いてサクッと構築してます。
こちらについても、プロキシサーバー自体の記事を別日程で書く予定なので、そちらを待ちください。
というわけでこんな感じでKibanaが見れるようになるので、あとはKibanaのビジュアライゼーションツールによって様々なグラフが生成できます。
またAPI も充実しているので、IN/OUTで色々な用途に利用できそうです。
まとめ
DBにないログの情報を活用するためにESを構築する方法を紹介しました。
構築もAWS のUIに則って作業することで、半自動で構築が可能です。
すごい便利ですね。
実は、これをやるにあたり、目黒のAWS Loftにいるソリューションアーキテクトの方に相談に乗ってもらいました。
最初はAthenaでやるつもりで相談したら、ESの方法を紹介してもらい、そこまで便利そうならということで、ESを選択しましたが大正解でした。
こんな感じで、単に質問に答える以上に提案ももらえるのはありがたいことです。
東京にいるならサクッと相談できるLoftの利用は最高に便利です。AWS を利用しているのであれば誰でも入れますので、気軽に行ってみてくださいね！
aws.amazon.com
それでは。
弊社ではデータ分析に興味があるWebエンジニアの方も募集しております。
詳しくを以下を御覧ください。
採用情報 | 株式会社フォトシンス Photosynth Inc.
