Kinesis Client Libraryを実案件でつかってみて

Kinesis Client Libraryをつかってみて

Kinesis Client Library(KCL)って？

Amazon Kinesisはストリーム処理を行うことができるサービスで、
Kinesis StreamはMessage Queueのような働きをします。
Kinesis Client Libraryは、Amazon Kinesisを利用する上で気を付けなければいけない部分を薄くラップしてくれる便利なライブラリです。

Checkpointを利用したデータのトランザクション処理、再送処理や、
リシャーディングにあわせた処理の並列化などをサポートしてくれます。

詳細はこちら ⇒ Kinesis Client Library

実案件で感じたKinesisを使うメリット

1. データを取得するConsumer側のペースにデータの流入を調整できるため、バックエンドの負荷を調節しやすくなった。
   もともと、秒間数千アクセスを10台以上で捌いていたが、導入後は、4台でさばけるようになった。

2. 安い小規模なデータストリームだとかなり安いと思います。

デメリット

サービスなのでもし通信障害になるとどうしようもなくなる。
producer側も何かしらの方法でデータの再送などを検討する必要がある。

めんどくさいところ

1. シャードの数をコマンドでしか変更できないため、自分でsplitしてあげないといけない。
   shardのsplitやmergeが実行あれるとき、Kinesisのデータを取得できなくなる。
   この間は、数分かかることもあるのできをつけないといけない。（バッチの時間に間に合わないとかならないように）
   kinesis-scaling-utilsを利用すれば、Shardのsplit, mergeを自動で実行してくれます。
   ただし、Shardの数の変更中(UPDATEING)は、KCLのStreamからのデータの取得が
   停止しますので、そこを注意する。

2. シャードの数=データのキャパシティ+並列度
   1秒間に1MB以上を投入し続けるのは結構な負荷がかかっている状況です。
   秒間3000とかならshard数１～２でもやっていけます。
   ですが、Shard一つに対してConsumerプロセスが一個あてがわれるため、
   このプロセスが秒間に1MB以上捌けないと、データの内容がどんどん遅れていくことになります。1秒間でどれくらいさばけるのかもShardの数を決定する基準になるかも？
   （そんな重い処理はしないですかね・・・）

データの重複について

データの重複は、Kinesisを使っていると簡単に発生します。
１Shardにつき秒間500 ~1000ほどのレコードを捌いていますが、
このデータリストのDBへの書き込みに失敗するとか・・・。
バックエンドのシステムの経路に障害が発生して伝送できないとか・・・。
こういったことが起こると、kinesisから取得したデータのリスト丸々を再送するのか、どうかといったエラーハンドリングが必要になる。
kinesisのshardからは、リストで取得するため、フィルタリングをしっかりしないと、すべてのデータがエラーに巻き込まれていきます。

重複データの対策

今回は、kinesisに投入されるデータにユニークなKeyを追加して流し、バックエンドのHive/prestoでgroup byをすることでデータの重複を無理やりなくす方法にしました。
データの再送を許可し、Hadoop/prestoにDISTINCT的な処理をさせることで、重複してしまったデータが存在しても集計が正しくなるようにしました。
重複をしないアーキテクチャを考え、実装するよりもあとから重複をなくすほうがよっぽど楽です。prestoやHiveが数千件のリクエストログがふえたところでなんてことない。
ただし、データの順序が必要だったり、過去データからの累積を行っているようなデータには使えませんが・・・。

その他

Kinesisには直接関係ないのですが、ELBもやはり裏はEC2だからなのか、突然、
HealthCheckの挙動がおかしくなることがあるようです。
バックエンドがまったく正常なのに１～２分ほどELBが5XXステータスを返し、
データがまったく送信できないときがありました。
ELBも冗長化するべき？

Kinesis クライアントってEC2とLambdaどっちがいいの？

最近、簡単な集計処理、ストリームデータのS3バケットへ配置処理などはLambdaで行っています。
感覚的に、よっぽどな高速なレスポンスが必要でない限りはLambdaで十分やっていけてます。
EC2の方がtmpファイル的なものを作りやすいことでしょうか。（単位時間データを種類ごとにファイルに書き出しておくとか）

・実装が楽
・冗長化考えなくていい
・でも、出力ファイルがバラバラになりがち

まとめ

• Kinesisを利用するなら、KCLをおすすめ。
• kinesis-scaling-utils　shardのスケーリングするのにおすすめ
• エラーハンドリングがめんどくさい