RoomClip 開発者ブログ

RoomClipのログ収集基盤をKinesis&Lambdaを使って構築してみる

こんにちは、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)の構成で運用しています。流れをもう少し詳細に説明すると以下の通り。

  1. td-agentは、ログを集約してKinesisに送信する。
  2. Lambda1は、(KinesisのPUTをトリガーとして起動し)、Kineisからログデータを取得(PULL)して、S3バッファ用バケットに保管する。
  3. Lambda2は、(定期実行により起動し)、S3バッファ用バケットにある全てのファイルをログの種類ごとにS3アーカイブ用バケットに階層化して移動させる(ルーティング処理)。同時に、ログの種類ごとにマニフェストファイルを作成してS3マニフェスト用バケットに保存する。
  4. Lambda3は、(マニフェストファイル作成(S3:PUT)をトリガーとして起動し)、Redsfhitに「COPY Manifest」を実行する。

ポイントとしては、

  1. S3ルーティング処理の切り離し
  2. Redshift用マニフェストファイルの生成

になるかと思います。

Kinesis&Lambdaを導入してみて

まだ全てのログをKinesisに移行はできておらず、これからログ流量もまだまだ増えると思いますが、それらを考慮しても、Kinesisのシャード数上限やLambdaの同時実行数の制限にもまだまだ余裕があるので、しばらくはこの構成で耐えれるのかなと思います。

この先、また新しく画期的なサービス・アーキテクチャが続々と生まれ、ログ収集の形も大きく変わる可能性は大いにありうるので、その辺の動向も追いつつキャッチアップしていけたらと思います。

また、せっかく頑張ってログ収集しても、そのログデータを活用できなければ意味がないと思いますので、ログデータ可視化〜問題発見・解決にも力を入れていき、より良いサービスへとつなげていたけらと思います。

参考サイト


この記事を書いた人:rkumagai

熊です。RoomClipのインフラ〜サーバーサイドを担当しています。


Tunnelの技術ブログはじめました、よ!

Hello World!
RoomClipを運営するTunnel株式会社の平山です。

ネット上の挨拶は「はじめまして」でも「こんにちわ」でもそぐわないので、書き出しに困りますね。結局「例のワード」に頼りましたが、プログラマの嫌なところが滲み出てないかちょっと心配です。

さて、どんな技術ブログにしようかと、日々悩んでおるのです。
愚直にいえば、Tunnel社のこと、メンバーのこと、RoomClipのことを、多くの人に知ってもらうために始めたのです。 ですが、じゃぁ何を書けばいいのかって言われると、、、中々スッとはでてこないものですね。

言うまでもなく弊社メンバーは技術的にも人間的にも魅力的であり、日々研鑽を怠るものではありません。 経歴や経験も、情報理工系出身の生粋エンジニアからバーテンダー出身まで多岐にわたっており、 彼らの融合によってユニークな発想がでてくることもあります。
それらを公開していくことで、
「他では見られない我々の技術」
に興味を持ってもらうブログというのも、もちろんいいですよね。
目指したいところです。

なのですが、、、
これはとんでもないレッドオーシャンに漕ぎ出すことにもなります。
「技術的にユニークな会社」なんて、吐いて捨てるほどある昨今ですよ。
っていうか、そうでない会社が最近のベンチャーには少ないくらいです。

そうなると、僕らの「面白さ」、「ユニークさ」の根源は、
やっぱりRoomClipそのものにあると思うんですよね。

僕らが置かれている状況だったり、
僕らが目指していることだったり、
つまり、

「RoomClipがどういうことをやろうとして、どういう課題に直面して、どう技術的に解決したのか?」

をしっかり伝えていくことが、
とても大事だったりするじゃないかな、なんて思ったりしています。

これから、このブログを通して色々なストーリーを共有していきたいと思っています。
技術ブログ!って銘打ってますが、
必ずしも「ソフトウェア」や「インフラ」だけの話だけでなく、
プロダクトを作るうえで必要なすべての技術について広範に触れていきます。
オフィスでの僕らの奮闘の様子が伝わるように、丁寧に書いていきますね。
ぜひ末永く、よろしくお願いいたしますm(_ _)m

そして願わくば、そんな物語の中から、
Tunnel社の雰囲気とか、文化とか、そんなものが滲み出ていけば、、、
きっとあなたも「一緒に開発したい」って思ってくれるんじゃないかなとか妄想しながら、、、
:wq


この記事を書いた人:平山知宏

Tunnel株式会社のエンジニア。 インフラからサーバサイド全般担当。 インダストリアル系の家に住みたいと思うけど、子供もできちゃったし危ないから工具とかほっぽっとくのやめようと思っている1985年生まれ。