【AWSログ収集】CloudWatchLogsからS3へ、データ変換と振り分け。やってみたら意外と簡単だった。

Jey

2023.12.13

バックエンド

この記事について
- 使用技術
- こんな人におすすめ
前段
ログを収集するにあたって
なにはともあれ構成を見てみよう
Kinesis Data Firehoseの設定
- レコードを変換および転換
- 動的パーティショニング
感想

この記事について

使用技術

AWS: Kinesis,Lambda,CloudWatchLogs,S3

Lambda: Node.js

こんな人におすすめ

ログ収集を始めたい人けど、どんな手段ややり方があるんだろう？という方や

その中で、なんとなくKinesisとか使えそうだなぁくらいの感覚の方に向けています。

そこで、Kinesisで出来る「レコード変換」と「動的パーティショニング」が便利だったので、この二つを使うことでこういうことができるよという紹介をしています。

前段

こんにちは、ソニックムーブ開発部のJeyです、普段はCOMSBIという自社サービスの開発を担当しています。

※COMSBIの概要はこちら

昨今のサービスは、ただ作るだけではなくその先までを見通す「データ分析」までが必須と言っていいほどになってきていると思います。

COMSBIでもありがたいことにそういったご要望が増えていることを日々実感しています。

さて、そんな中で実際にCOMSBIでログ収集をしようとなった時に、なるべく簡単に始められないだろうかと調べていたところ、今回のお題に辿り着きました。

実際すごく簡単に出来たので、やり方を紹介していきます！

ログを収集するにあたって

COMSBIにはサービスの中にクライアント様毎の環境が存在します。
クライアント様が増えるたびにログ集計の環境を増やすみたいなことをしたくないので

「ひとつのCloudWatchLogsにこっちで決めた形式のログを吐き出したら勝手に集計してクライアント様毎のS3に行ってくれないかなぁ」

という思いがありました。

なにはともあれ構成を見てみよう

例 ↓このログがCloudWatchLogsにPUTされたとします。

{"client": "A", "data": "hoge"}
{"client": "B", "data": "fuga"}

				1
2
3

						{"client": "A", "data": "hoge"}
{"client": "B", "data": "fuga"}

レコード変換と動的パーティショニングを経て、最終的には
・S3bucket/clientA/2023/08/30/data_file
・S3bucket/clientB/2023/08/30/data_file
というS3にそれぞれ振り分けられます

Kinesis Data Firehoseの設定

今回設定するのは画像中の「レコードを変換および転換」と「送信先の設定」の部分になります

※画像の画面はAWSのサービスのKinesisから画像中の左メニューでアクティブになっている「Data Firehose」を選択し、対象の配信ストリームを開いた状態です

レコードを変換および転換

ここにLambda関数を挟めるわけですね
ちなみに、Lambdaも関数の作成からKinesis用のテンプレートがあるので簡単に作れます

画像の98,99行目が1レコードなので、100行目のリターンの間にデータの整形などの処理を書いて、100行目のreturnに設定してあげるという感じです。

今回のreturnの内容
{
    data: encodedData,
    result: 'Ok',
    recordId: recId,
    metadata: { 'partitionKeys': {
        client: data.client,
        year: year #date頑張ってyearにして,
        month: month　#date頑張ってmonthにして,
        day: day #date頑張ってdayにする
    }}
}

今回のreturnの内容

{

data: encodedData,

result: 'Ok',

recordId: recId,

metadata: { 'partitionKeys': {

client: data.client,

year: year #date頑張ってyearにして,

month: month　#date頑張ってmonthにして,

day: day #date頑張ってdayにする

}}

}

この変換の時に返すpartitionKeysが大切

動的パーティショニング

https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/dynamic-partitioning.html

KinesisからS3に振り分ける時に、S3バケットのプレフィックスを指定するのですが、つまりここに指定するのが先ほどLambdaでreturnしてあげたpartitionKeysになるわけですね

!{partitionKeyFromLambda:client} partitionKeyFromLambdaでLambdaで設定したpartitionkeyを使う
clientの部分はキー名

こうすることで、送信する先のS3のプレフィックスが指定したpartitionkeyのバリューになる
今回はclientA/2023/08/30とclientB/2023/08/30と振り分けられます。

便利ですね

感想

・こんなのがAWS Consoleでぽちぽちしたらできたっていう衝撃がすごかったです

・Lambda挟まなくてもインラインで解析ができるので、本当にちゃんとログの形式が決まってて集計したいだけならLambda挟む必要もないかもしれない

https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/dynamic-partitioning.html

・サーバーみる必要もなくてLogsにPUTすればいいだけっていうのがすごい楽

・1点、CloudWatchLogsでのPUTのリミットに引っかかりました。今回はログ収集の選択肢の一つとして検証をしていたものだったので、特別理由がなく使っていましたが、必要に応じて検討したほうが良いかもしれません。

PutLogEvents の最大バッチサイズは 1 MB です。

リージョンごと、アカウントごとに、毎秒 800 トランザクション。ただし、クォータがリージョンごと、アカウントごとに、毎秒 1,500 トランザクションである米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) リージョンは除きます。Service Quotas サービスを使用して、1 秒あたりのスロットリングクォータの引き上げをリクエストできます。

PutLogEvents の最大バッチサイズは 1 MB です。

リージョンごと、アカウントごとに、毎秒 800 トランザクション。ただし、クォータがリージョンごと、アカウントごとに、毎秒 1,500 トランザクションである米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) リージョンは除きます。Service Quotas サービスを使用して、1 秒あたりのスロットリングクォータの引き上げをリクエストできます。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html