ソリューションアーキテクトの大谷さんと開発マネージャの堀さんによる、Kinesisの詳説です。 Kinesisの開発マネージャの方が解説してくれたこともあり、とても意義あるものでした。

Kinesisの新規ローンチ

• 東京リージョンローンチ
• Fluentdプラグイン https://github.com/awslabs/aws-fluent-plugin-kinesis
• MQTTアダプター https://github.com/awslabs/mqtt-kinesis-bridge

事例紹介

• ガリバー http://221616.com/gulliver/news/press/20140715-13667.html
• Pencil(リアルタイムユーザーモニター)
• SmartInsight(Beaconとの距離をロギング)
• Supercell
• bizo

Kinesis詳細

なぜリアルタイム？

• 測定(Metering)サービス　使った分だけ課金されるという特性　オペレーションを測定しないといけない
• 毎秒数千万レコード
• 毎時数テラバイト
• 数十万のデータ・ソース

• 月末にはオーディターでの100%の正確性

• 毎時数百万のファイル

• スケールの課題
• リアルタイムの要望

• 高い運用コスト

• 要求の変化 毎時か毎日のデータ処理が従来の要求だったが、リアルタイム、早い意思決定、KeepEverything、エラスティックな拡張性、複数の目的に応じて同じデータを並行処理したい、などの新しい要求が出てきた。

Kinesis概要

用途単位でStreamを作成し、Streamは１つ以上のShardで構成される Shardは入力側秒間１MB 1000TPB 出力側2mB, ５TPSのキャパシティ 入力されたデータは複数のAZに２４時間保存 Shardの増減でスケール

データ入力

HTTPS/POSt SDK Fluentd Flume Log4J etc

ProducerがPut Recordするサンプル AWS CLIでできる

Shardへの分配ロジック：　md5でハッシュ化して該当のShardに分配される パーティションキーを何にするかは重要

パーティションキーの数 > shardの数 カーディナリティーの高いパーティションキーを使う

シーケンス番号を使って何度でも読むことができる 何度取得してもシーケンス番号の順番は変わらない:重要

データ取得と処理

API Kinesis Client Library/ConnectorLibrary Storm EMR

どうやって信頼性と拡張性のあるアプリケーションを作るの？

• Kinesis Client Libraryを提供
  • Shardと同じ数のWorker
  • Workerを均等にロードバランシング
  • 障害完治と新しいWorkerの立ち上げ
  • shardの数に応じてWorkerが動作する
  • Autoscaling
  • チェックポインティング、At least once処理

これらの煩雑な処理を意識することなく、ビジネスロジックに集中できる

重複データについて

ネットワーク障害や500レベルエラーはリトライをする リカバリやロードバランシングでデータが最後のチェックポイントからリプレイされる

• ユースケースを理解する
  • 冪等なアプリをつくる
  • 重複を許容する

Kinesis Connector Library

S3, DynamoDB, Redshift 4つのインタフェースを使うと簡単に書ける

1つのデータをいろいろなシステムで プロデューサーの負荷軽減 データの一貫性を保ちたい

Kinesisに全てのデータを１回入力する 必要に応じて新しいアプリを追加していく Agilityを高める

Elasticな拡張性

• Streamは１つ以上のキャパシティで構成　Shardでキャパシティプランニング
• SplitShard API Shardを半分に分割

shardやEC2もキャパシティがある ProvisionedThroughputExceededException

shard１つで14$/month Getトランザクションは無料