大きくなってきたIoTプロダクトのログ活用について 〜Amazon Elasticsearch Service篇〜

ども、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の画面に行ったら「新しいドメインの作成」からサクッと作成できます。

f:id:photosynth-inc:20181201101452p:plain
AWS Console ES

次の画面で、ドメイン名とESのバージョンの指定ができます。

f:id:photosynth-inc:20181201101920p:plain

次へを押すと、インスタンスタイプ等の設定画面に行きます。最初はt2系で立てたのですが、インスタンスのタイプ毎にストレージ上限が決まっているため、容量が必要になるたびに増やす必要があります。ただ一旦低いので立てておいて、あとからスケールアップするのは簡単だったので、お試しではt2でも問題ないかもしれません。ちなみにt2系はすべて35Gが上限です。

docs.aws.amazon.com

次にネットワーク構成を選択します。ほとんどの場合社内利用だと思いますので、VPCアクセスで問題ないと思います。

f:id:photosynth-inc:20181201102851p:plain

次に認証ですが、AWSのCognitoを挟むこともできますし、単にVPCでのアクセス制限もできます。今回は「IAM認証情報を使用した署名リクエストを要求しない」にしました。

f:id:photosynth-inc:20181201103034p:plain

これで必須のものを全部選択して、確認画面に行き、「確認」を押すことでインスタンスの生成がはじまります。

2. CloudWatchLogsとの連携

連携は非常に簡単です。ESへのストリーミングを開始を押し、

f:id:photosynth-inc:20181201103545p:plain

先程作成したESのクラスタとログの形式を指定します。 右下の「ストリーミングを開始」ボタンを押すと即刻連携がはじまります。

f:id:photosynth-inc:20181201103713p:plain

簡単ですね^^

3. (必要なら)Lambdaを編集する

上記まで完了するとLambdaの関数も自動で作成されます。 そうです、実は、連携と言って起きながら、AWSさんはそれを実現するためのLambdaを作成しているだけなのでした。

f:id:photosynth-inc:20181201104245p:plain

Lambdaですので、普通のソースを編集できます(JS)。

弊社ではログをLTSVで出力しているため、これをES様に変換するスクリプトに修正します。 100行目くらいにある buildSource を少し修正します。

function buildSource(message, extractedFields) {
    var log={};
    
    // LTSVとしてパースする
    message
    .split(/\t/)
    .map(function(s) {
        var res = s.match(/(.+?):(.*?)$/);
        return [res[1], res[2]];
    }).map(function(ary){
        log[ary[0]] = ary[1]
    });

    // 必要に応じて方を合わせる
    // 特にnumber型にしたいが、空となってしまう場合は代替の数字を用意する
    // ES側でindexの修正でも対応できるが、日次でindexを作り直す場合に戻ってしまうので、
    // 出力側で注意する
    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の管理画面から確認できます。

f:id:photosynth-inc:20181201105707p:plain

ですが、冒頭言ったように、普通にこの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で色々な用途に利用できそうです。

f:id:photosynth-inc:20181201110827p:plain

まとめ

DBにないログの情報を活用するためにESを構築する方法を紹介しました。 構築もAWSのUIに則って作業することで、半自動で構築が可能です。 すごい便利ですね。

実は、これをやるにあたり、目黒のAWS Loftにいるソリューションアーキテクトの方に相談に乗ってもらいました。 最初はAthenaでやるつもりで相談したら、ESの方法を紹介してもらい、そこまで便利そうならということで、ESを選択しましたが大正解でした。

こんな感じで、単に質問に答える以上に提案ももらえるのはありがたいことです。 東京にいるならサクッと相談できるLoftの利用は最高に便利です。AWSを利用しているのであれば誰でも入れますので、気軽に行ってみてくださいね!

aws.amazon.com

それでは。


弊社ではデータ分析に興味があるWebエンジニアの方も募集しております。 詳しくを以下を御覧ください。

採用情報 | 株式会社フォトシンス Photosynth Inc.