こんにちは、Tunnelでエンジニアをしている熊谷です。
気持ち安らぐログ収集基盤に向けて
サービス向上のためにログ収集はとても大切だと思いますが、RoomClipでも日々、様々なログを収集しており、今回のKinesisで取り扱ってるログだけでも30種類近くあります。
ログデータの性質として、当たり前ですがデータ量がひたすら蓄積し続け、サービス拡大やキャンペーン・広告などで流量が爆発的に増えることもあります。その都度、サーバーが停止したり、ネットワークにトラブルが起きたりして対応を迫られるのは極力避けたいものです。
RoomClipでは、ユーザー数増加、サービス拡充につれ、これまでのFluentdでのログ収集基盤では辛くなってきたため、話題奮闘中(?)のAWS Kinesis&Lambdaを取り入れた構成に変更することになりました。また構成を変更するにあたり、トラブルやデータロス無く安定的に動作することはもちろんですが、よりスケーラブルで汎用的な構成を目指しました。
先に結果を言いますと、Kinesis&Labmdaの導入により、ログを安定的に収集することができるようになり、新しいログを追加する際も簡単に安心して行うことができるようになりました。
Kinesis&Lambdaによるログ基盤の考察
Kinesisを利用したログ収集についてネットで調べてみると、基本的な構成として以下のようなフローがよく見つかると思います。
(1) td-agent -> Kinesis -> labmda -> S3
さらにログをクエリで分析するために、Redshift(or Elasticserch)にもデータを入れたいとなると以下のようなフローが見つかります。(この場合、Kinesis Firehoseを導入すれば簡単にできると思います)
(2) td-agent -> Kinesis -> labmda -> S3 -> Lambda -> Redshift (or Elasticsearch)
ただ、取り扱いたいログが1種類の場合であれば上記の構成でいいと思いますが、数十種類のログを扱う場合、ログごとに同じ構成を用意するのは非常に手間で冗長なので、どこかでルーティング処理をいれようとなると思います。その場合の構成は以下のようになります。(ルーティング処理をいれれる箇所はいくつか考えられますが、Redshift手前のLabmdaで処理する場合で考えてみます)
(3) td-agent -> Kinesis -> labmda -> S3 -> Lambda(ルーティング処理) ─> Redshift(table A) └──> Redshift(table B)
上記の構成であればルーティング規則に則ったログをtd-agentに流し込みさえすれば、自動的にそれぞれのテーブルにデータが挿入されるようになります。
ただ問題点としては、ログ流量が多く、RedshiftへのCOPYが頻発した場合は詰まってしまいます。これらはLambdaでの処理を工夫したりBatchSizeを変更することで多少は上限を引き上げられるかもしれませんが、いずれにせよ、GZIPファイルの数だけRedshift COPY(with JSON GZIP Options)コマンドが走るため、トランザクションが重複し(テーブルロックがかかるため)、クエリ待ちが多発してしまいました。
対応策して、RedshiftのCOPY Manifestを使うような構成に変更しました。(コマンドでいうと「COPY JSON GZIP」から「COPY JSON GZIP MANIFEST」へ)。要は、ログ集約されたデータをさらにManifestで集約することで、大幅な負荷軽減&高速化をしようということです。これならば、どれだけGZIPファイルが増えても1クエリで叩けるようになります。構成は少し複雑で以下のようになりました。
(4) td-agent -> Kinesis -> labmda1 -> S3(バッファ用Bucket) -> Lambda2 -> S3(マニフェストファイル用Bucket) & S3(アーカイブ用Bucket) -> Lambda3 -> Redshift
現在のRoomClipのログ収集基盤
現在、RoomClipのログ収集基盤は上記(4)の構成で運用しています。流れをもう少し詳細に説明すると以下の通り。
- td-agentは、ログを集約してKinesisに送信する。
- Lambda1は、(KinesisのPUTをトリガーとして起動し)、Kineisからログデータを取得(PULL)して、S3バッファ用バケットに保管する。
- Lambda2は、(定期実行により起動し)、S3バッファ用バケットにある全てのファイルをログの種類ごとにS3アーカイブ用バケットに階層化して移動させる(ルーティング処理)。同時に、ログの種類ごとにマニフェストファイルを作成してS3マニフェスト用バケットに保存する。
- Lambda3は、(マニフェストファイル作成(S3:PUT)をトリガーとして起動し)、Redsfhitに「COPY Manifest」を実行する。
ポイントとしては、
- S3ルーティング処理の切り離し
- Redshift用マニフェストファイルの生成
になるかと思います。
Kinesis&Lambdaを導入してみて
まだ全てのログをKinesisに移行はできておらず、これからログ流量もまだまだ増えると思いますが、それらを考慮しても、Kinesisのシャード数上限やLambdaの同時実行数の制限にもまだまだ余裕があるので、しばらくはこの構成で耐えれるのかなと思います。
この先、また新しく画期的なサービス・アーキテクチャが続々と生まれ、ログ収集の形も大きく変わる可能性は大いにありうるので、その辺の動向も追いつつキャッチアップしていけたらと思います。
また、せっかく頑張ってログ収集しても、そのログデータを活用できなければ意味がないと思いますので、ログデータ可視化〜問題発見・解決にも力を入れていき、より良いサービスへとつなげていたけらと思います。
参考サイト
この記事を書いた人：rkumagai
熊です。RoomClipのインフラ〜サーバーサイドを担当しています。