すずけんメモ

技術メモです

AWS Casual Talks #2 で発表してきました #awscasual

aws

AWS Casual Talks#2で発表してきました。主催の @con_mame さん、会場を提供してくださったAWSのみなさま、どうもありがとうございました。

AWS Casual Talks#2 on Zusaar http://www.zusaar.com/event/3817003

今回は新サービスネタということで僕の発表ではAmazon Kinesisについて触れた。内容としては、既存のアーキテクチャにAmazon Kinesisを適用したらどんな感じになるか、ということを検証している内容を踏まえつつ考えをまとめたもの。まだ実際にプロダクションには投入していないので、運用していった時にどういう形になるかはわからない。ただまだ東京リージョンにも来てないし、ある程度検証している内容でもカジュアルに話そうか、というのが今回の発表の趣旨。

要点としては、

  • hot dataを処理するためにバランスよくアーキテクチャを変えてきた。
  • その過程で、Fluentdに役割が集中してきたため、やや弊害がある。より柔軟にするため、うまく役割を分担したい。
  • Amazon Kinesisを現状使うにはまだ工夫が必要で、今とは設計を変える必要がありそう

というような話。Amazon Kinesisについては、現状うちの使っているような用途だとwrite側に工夫が必要そう。具体的には1 recordずつwriteすることになるので、throughputが出しにくい。Fluentdではchunkとしてstreamを処理しているので、ここの相性が悪そう。なのでbatchWriteができると嬉しい、と個人的に感じてる。Consumer（Kinesisからのread）側についてはKCL（https://github.com/awslabs/amazon-kinesis-client）がいろいろやってくれて便利なので、現時点ではこれを使うと良い。特に、チェックポイント周りの管理はこれが楽。チェックポイントというのは、どのシャードをどの時点まで処理したかということを示すもので、例えばWorker側で処理が失敗した場合に処理途中のシャードをどこから再開するか、といったことを知るために使う。KCLだとここをDynamoDBを管理テーブルとして利用するようにいい感じにやってくれる。自前で実装する場合には、DynamoDBであれ他のストアであれ、何らかの手段でこのチェックポイントの管理を設計する必要がある。

ちなみに、

という話については僕もそう思っていて、まぁKafkaなので、あるとメッセージングがロバストになるとか、Consumer側がばりばり複数系統あってfetchしまくって分析してるとか、そういうときだと便利になるとは思います。

他の発表も楽しんで聴けて、@mineroaoki さんのカジュアルなRedshiftのパフォーマンスチューニング話でカジュアル感を感じたり、@hakoberaさんのebflyはElastic Beanstalkにherokuみたいなインタフェースを作っていて楽しそうだなと思ったり、@mikedaさんの話を聞いてCloudSearchはカジュアルだなと思ったりした。それと@yamakatuさんと久々にお会いして、ちらっとSpark話をしたりもできた。

終わった後に有志で飲みに行って、カジュアルウォーターを味わいつつ、ウニをドロップしたり、いろいろカジュアルな飲み会で楽しかった。また飲みに行きましょう。