タイトルでは
知っておくべきこと と書きましたが、簡潔に結論を書くと 仕様のドキュメントをちゃんと読めば問題なし となります。ドキュメント読むの大事ですね。
そして普段からちゃんと読んでる人はハマらないので、なんの気づきもない可能性があります。
実現したいこと
みんな大好きLambdaですが、Lambda関数の数が多くなり出力されるLogの量が多くなってくると、CloudWatch Logsのマネジメントコンソール上での検索が大変になってきました。
CloudWatch Logsのマネジメントコンソール上では、ログストリーム間のイベントを横断検索することはできますが、ロググループ間の横断検索や検索結果の直感的な可視化などを行うことができません。
これを構築と運用の手間をなるべくかけずに実現して、Lambda関数から出力されたLogを普通に検索して可視化したいわけです。
Lambda関数をまたいでLogを検索する必要がない！という場合は必要ない仕組みになります。
実現方法
実現するにために以下のサービスを連携して利用することを考えました
具体的にはAWS Lambdaから出力されたLogがAmazon CloudWatch Logsに蓄積されるので、Amazon CloudWatch Logsのサブスクリプションを利用してAmazon Kinesis Firehoseにリアルタイムで出力しAmazon S3に蓄積する。
Amazon S3に蓄積されたLogをAmazon Athenaでクエリを投げられるようにしてAmazon QuickSightにて可視化を行う。
他の実現方法
上記の方法以外で以下のサービスを使えばもっと手軽に実現できます
- Amazon Elasticsearch Service
Amazon CloudWatch Logsのサブスクリプションを利用してAmazon Elasticsearch Serviceにリアルタイムで出力し、Kibanaにて可視化を行う。
ただしAmazon Elasticsearch Serviceはストレージの容量が無制限ではなく、必要があれば設定や操作をしてストレージを管理しなければならないため今回はこの方法を選択しませんでした。
用途が合えば非常に手軽なのでこちらを選択するのもアリかと思います。
Amazon CloudWatch Logs
Data sent from CloudWatch Logs to Amazon Kinesis Firehose is already compressed with gzip level 6 compression, so you do not need to use compression within your Firehose delivery stream.
Amazon Kinesis Firehoseとの連携の場合はすでにgzipで圧縮された状態で送信されるとは知りませんでした・・・ ドキュメントをしっかり読んで理解していれば、今回悩むことはなかったかもしれません
ここまでがAmazon CloudWatch Logsについて知っておくべきことになります
Amazon Kinesis Firehose
- Amazon Kinesis FirehoseでAmazon S3に転送されたデータには改行がなく1行
- Amazon Kinesis Firehose Data Transformationを利用して改行を追加する
Amazon Kinesis Firehose Data Transformationを利用しなければ改行が追加できないのちょっと残念な感じがします・・・
AWS IoT ルールアクションでFirehose アクションを利用する場合にはseparatorの指定が可能で、これによって改行をした状態でデータが蓄積されます。この機能を通常のAmazon Kinesis Firehoseで利用出来たらいいなぁ
ここまでがAmazon Kinesis Firehoseについて知っておくべきことになります
Amazon Athena
- Amazon Athenaで利用するには1行1レコードの形式にする必要がある
- Amazon AthenaでGZIP圧縮されたファイルを読み込むには、ファイルの拡張子を
*.gzにする必要がある - 実際にGZIP圧縮されたファイルでも拡張子が正しくないと読み込めない
- このためAmazon Kinesis Firehoseの設定で
"CompressionFormat" : "UNCOMPRESSED"として出力されたファイルは拡張子が無いため正しく読み込めない - Amazon Athenaで利用するためには、Amazon Kinesis Firehose Data TransformationにてAmazon CloudWatch Logsから連携されたデータのGZIP解凍を行い、Amazon Kinesis Firehoseの設定で
"CompressionFormat" : "GZIP"とし拡張子の*.gzが付与される形でAmazon S3に出力する必要がある
Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/
ファイルの拡張子が*.gzでないとGZIPファイルを読み込んでくれないのはやっぱりちょっと残念な気が・・・S3オブジェクトのメタデータでContent-Typeを見て処理してくれるとかあるとステキなんだけどなぁ
ここまでがAmazon Athenaについて知っておくべきことになります
Amazon QuickSight
- Amazon QuickSightのSign upを行えるのはIAMアカウント or Rootアカウント
- Roleベースログイン、フェデレーションユーザーには未対応
今回利用していたアカウントがフェデレーションユーザーだったため、処理状態が変化せずに困りました・・・
フェデレーションユーザーでログインしていることは、システム側がわかっているはずなのでフェデレーションユーザーではNGというエラーメッセージが出てくれれば良いのになぁ
ここまでがAmazon QuickSightについて知っておくべきことになります
Amazon S3
- AWS CLIの
aws s3 cpコマンドでのファイル取得とマネジメントコンソール上からのダウンロードでのファイル取得では差異が出ることがある - ブラウザーの機能で
*.gzファイルを自動で解凍してしまう事がある
利用していのはGoogle Chromeでしたが、このように自動解凍しているとは認識していませんでした・・・ 結果的にS3上のファイルとローカルにダウンロードしたファイルで状態に差異が出ることになり、大いに悩む原因の１つになりました
cp — AWS CLI 1.11.74 Command Reference
http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html
ここまでがAmazon S3について知っておくべきことになります
手順
- AWS Lambda関数から必要な情報をログに出力する
- Amazon CloudWatch Logsにログが出力されているロググループを確認する
- そのロググループに対してサブスクリプションとしてAmazon Kinesis Firehoseを指定する
- Amazon Kinesis Firehoseはマネジメントコンソール上では指定できないため、上記のようにAWS CLIを利用して設定した
- Amazon Kinesis FirehoseのDelivery Streamは別途作成する必要がある
- 前述したようにCompressionの設定はGZIPとして、拡張子の*.gzが付与されるようにする
- Data transformationをEnabledとしてLambda関数を指定する
- このLambda関数も別途作成する必要がある
- blueprintのkinesis-firehose-process-record-pythonを利用すれば簡単に作れる
- Amazon S3の指定バケットにAmazon Kinesis Firehoseからファイルが出力されていることを確認する
- ファイルの拡張子は*.gzで、内容はAWS CLIのaws s3 cpコマンドを利用してローカルに取得して１行に１レーコドとなっているかを確認する
- Amazon AthenaにてAmazon S3の該当バケットをTableのData setに指定して新しいテーブルを作る
- 作成したテーブルに投げたいクエリを作成する
- Amazon QuickSightにSign upしてない場合はSign upする
- この際ログインしているアカウント種別によっては処理が先に進まなくなるので気をつける
- Amazon QuickSightにてデータソースにAmazon Athenaを選択し、作成したクエリーを選択すればデータが読み込まれ可視化される
これでAWS Lambdaのログを一元化して可視化することが出来るようになりました。料金には注意が必要ですが、性能や容量に関しては大きな心配はないのではないかなーと。
Amazon QuickSightはAmazon QuickSightだけ閲覧可能なユーザーなんかも作成可能なようなので、より柔軟にデータを見てもらうことができようになるのかなーと
また、各サービスがそれぞれ独立していても利用可能なので例えばAmazon QuickSightの調子が良くない場合でもAmazon Athena利用して確認するといったことも可能となるため、汎用性も高まる気がします。
まとめ
AWS Lambda→Amazon CloudWatch Logs→Amazon Kinesis Firehose→Amazon S3→Amazon Athena→Amazon QuickSightと長い連携でしたが、当初の目的通りに可視化することができました。
最初からしっかりとドキュメントを読んでいれば、余計な手間や迷惑をかけずに実現できていたと思うので、今後は詰まったら基本のドキュメントをしっかり読み込むようにしたいと思います。
一方で今回詰まった部分は、AWS側の標準機能として存在するば迷うこともないのになぁーと思うところもあります。 特に、Amazon Kinesis Firehoseの改行付与と拡張子付与に関しては標準であっても良いかと思いました。
また、Amazon QuickSightのSign upのように、そもそもログインしているアカウント種別でNGの場合はエラーメッセージにその旨出て欲しいです・・・さすがに設定中の状態が延々と続くのはちょっと・・・
ヘルプドキュメントのリンクと共にエラーメッセージに出ていれば自分で原因に気がつけます。
AWSは進化も変化も速いのでこう言った細かいところの改良が進んでいくのを楽しみにしています！
AWSサポート
今回も大変お世話になったAWSサポート。利用する立場が違うと評価も違うのかもしれませんが、エンドユーザーとして利用することが多いので毎回非常に助かっています！いつもありがとうございます。
以上になります。
