タイトルでは

知っておくべきこと と書きましたが、簡潔に結論を書くと 仕様のドキュメントをちゃんと読めば問題なし となります。ドキュメント読むの大事ですね。

そして普段からちゃんと読んでる人はハマらないので、なんの気づきもない可能性があります。

実現したいこと

みんな大好きLambdaですが、Lambda関数の数が多くなり出力されるLogの量が多くなってくると、CloudWatch Logsのマネジメントコンソール上での検索が大変になってきました。

CloudWatch Logsのマネジメントコンソール上では、ログストリーム間のイベントを横断検索することはできますが、ロググループ間の横断検索や検索結果の直感的な可視化などを行うことができません。

これを構築と運用の手間をなるべくかけずに実現して、Lambda関数から出力されたLogを普通に検索して可視化したいわけです。

Lambda関数をまたいでLogを検索する必要がない！という場合は必要ない仕組みになります。

実現方法

実現するにために以下のサービスを連携して利用することを考えました

AWS Lambda
Amazon CloudWatch Logs
Amazon Kinesis Firehose
Amazon S3
Amazon Athena
Amazon QuickSight

具体的には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

マネジメントコンソールから設定を行えるサブスクリプションは以下の2種類
- AWS Lambda
- Amazon Elasticsearch Service

サブスクリプションとしては以下の2種類も利用可能
- Amazon Kinesis Streams
- Amazon Kinesis Firehose

マネジメントコンソールから設定できないものについてはAWS CLI等で設定する

Amazon CloudWatch LogsのサブスクリプションでAmazon Kinesis Firehoseと連携する場合、すでにgizpで圧縮された状態で送信される

Amazon Kinesis Firehoseとの連携の場合はすでにgzipで圧縮された状態で送信されるとは知りませんでした・・・ドキュメントをしっかり読んで理解していれば、今回悩むことはなかったかもしれません

ここまでがAmazon CloudWatch Logsについて知っておくべきことになります

Amazon Kinesis Firehose

Amazon Kinesis FirehoseでAmazon S3に転送されたデータには改行がなく1行
Amazon Kinesis Firehose Data Transformationを利用して改行を追加する

Amazon Kinesis Firehoseの設定で"CompressionFormat" : "UNCOMPRESSED"とした場合には、ファイルには拡張子が付与されない

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に出力する必要がある

ファイルの拡張子が*.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上のファイルとローカルにダウンロードしたファイルで状態に差異が出ることになり、大いに悩む原因の１つになりました

ここまでが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サポート。利用する立場が違うと評価も違うのかもしれませんが、エンドユーザーとして利用することが多いので毎回非常に助かっています！いつもありがとうございます。

以上になります。

uchimanajet7のメモ

LambdaのLogをCloudWatch LogsからKinesis Firehoseを利用しAthena＋QuickSightで可視化する際に知っておくべきこと #aws #jawsug