« 【AWS発表】 間もなく登場! SSDによる高性能なI/Oを提供するI2インスタンスタイプ | メイン | 週刊AWS - 2013年11月11日 »

【AWS発表】 Amazon Kinesis – ストリームデータのリアルタイム処理

新しいデータが毎日24時間、毎週7日間、連続したストリームで送られてくる状況を想像してみて下さい。そのデータをキャプチャし、処理し、何らかのアクションを伴う結論へとできるだけ早く、できれば数秒の間に導く必要があります。データレートや分析に必要なコンピュートパワーは、単位時間あたりのデータ量によって異なります。従来のバッチ処理の方式では、こうした場面であまりうまくいきません。

Amazon Kinesisビッグデータのリアルタイム・ストリームを扱うために設計されたマネージドサービスです。どんな量のデータも、どんな数のソースも受け付け、必要に応じてスケールアップ・ダウンさせることができます。

Kinesisは大規模でリアルタイムなデータ投入と処理が必要とされる、あらゆる場面で使うことが出来ます。サーバーなどのIT基盤のログ、ソーシャルメディアやマーケットのデータフィード、ウェブクリックストリームのデータ、「いいね」のようなものは、Kinesisで処理することにとても向いている一例です。

それではKinesisを詳しく見て行きましょう。

重要なコンセプト
アプリケーションは信頼性の高いデータのキャプチャ・格納・転送を行うKinesisストリームをいくつでも作ることが出来ます。ストリームそのものにはキャパティやレートの制限はありません。入ってくる全てのデータは、高可用性担保のため複数のAWSアベイラビリティゾーンにまたがって複製されます。各ストリームは複数のリーダーとライターを持つことが出来ます。

ストリームを作成したら、シャード(分割)に関するキャパシティを指定します。各シャードは、1000書き込みトランザクション(1秒あたり1MBまで)と20読み取りトランザクション(1秒あたり2MBまで)の処理能力を持ちます。ストリームのスケールアップ・ダウンは、シャードを足したり減らしたりすることで、処理スループットやダウンタイムへの影響を与えずにいつでも行うことができ、数分以内に利用開始いただけます。価格は現存するシャードの数および実行する書き込みの数に応じて決まります。

Kinesisクライアント・ライブラリは、アプリケーションにとって重要なコンポーネントです。ロードバランシング、調整、エラーハンドリングの具体的な部分を司ります。クライアント・ライブラリはヘビー・リフティング時の対応も行います。 アプリケーションはデータが利用可能になり次第、データを処理することに集中できます。

アプリケーションはストリームに対してデータレコードを読み書きします。レコードは最長50KBで、パーティションキーデータBLOBから構成され、双方とも順番が変わらないバイトとして扱われます。 レコードのパーティションはどのシャードがデータBLOBを扱うかを決定しますので、データBLOBには一切手を加えられません。 データ投入時に、各レコードにシーケンス番号が付加されます。レコードは24時間後に自動的に破棄されます。

Kinesisの処理モデル
アプリケーションの「生産者側」のコードではPutRecord関数を使ってストリームのデータを格納します。その際ストリーム名、パーティションキー、データBLOBを渡します。パーティションキーはMD5ハッシュ関数で分散され、128ビットの値がストリーム中のシャードを識別するために使われます。

アプリケーションコードの「消費者側」はシーケンシャルにシャード内のデータを最後まで読みます。データを読み始めるまでに2つのステップがあります。まず、アプリケーションはシャードのどこからデータを読み始めたいかを指定するためにGetShardIteratorを使います。 GetShardIteratorはどこからストリームを読み始めるかを指定するために次のオプションを持っています。:

  • AT_SEQUENCE_NUMBERは与えられたシーケンス番号からはじめます。
  • AFTER_SEQUENCE_NUMBERは、与えられたシーケンシャル番号の後からスタートします。
  • TRIM_HORIZONは最も古くに保存されたレコードからスタートします。
  • LATEST到着した新しいレコードからスタートします。

次に、アプリケーションは、シャードイテレータを使って秒間最大2メガバイトのデータを取得するためにGetNextRecordsを使います。 GetNextRecordsを使う最も簡単な方法は、シャード内で利用可能になったデータを全て取得するために、定期的に、GetNextRecordsを呼び出すループを作成することです。これらのインターフェースはローレベルのインターフェースとしては非常に良い考え方ですが、多くのアプリケーションはKinesisクライアント・ライブラリにより提供される、よりハイレベルな関数を活用したいのではないかと思います。

クライアント・ライブラリはフェイルオーバー、リカバリ、ロードバランス等をはじめ多種多様な考慮すべき事項を扱ってくれます。IRecordProcessorインターフェースを使うだけで、クライアント・ライブラリは新しいレコードが利用できる状態になり次第「プッシュ」してくれます。

レコードの処理を行ったら、消費者側のコードは他のKinesisストリームへ渡したり、Amazon S3バケットやRedshiftのデータウェアハウス、DynamoDBのテーブルに書き込んだり、単純に破棄することが出来ます。

スケーリングとシャーディング
スケーラビリティに関して2つの異なる要素について考慮する必要があります – 処理能力とシャーディングです。レコードの流れに追いつけるだけの十分な処理能力を持っていることを確認して下さい。また、シャードの数を管理する必要があります。

まずは処理能力の話からはじめましょう。最も簡単な方法は、消費者側のアプリケーションをクライアント・ライブラリを使って実装し、それをオートスケーリンググループに紐付けたAmazon EC2インスタンスでホストすることです。 グループの最小数を1と設定すれば、インスタンス障害時でも復帰することができます。グループの最大数を十分に大きくしておくことで、スケールする幅を大きくすることができます。処理がCPU寄りである場合、CloudWatchのCPU Utilizationメトリックでスケールアップ・ダウンさせても良いでしょう。反対に、処理が比較的軽い場合、Network Traffic Inを基準にしたスケーリングの方が効果的かもしれません。

それでは、シャーディングについてです。予測されるデータレートに応じて、十分なシャード数を持つストリームを作る必要があります。レートの変動に応じて、シャードを増減させることができます。これらの操作はSplitShardMergeShardsのAPIを使って行うことができます。これらの操作を効果的に行うために、パーティションキーがどう働くかについてもう少し詳しく見て行きましょう。

既に述べたとおり、パーティションキーはMD5ハッシュ関数で128ビットの値(0から2127-1まで)が生成されます。各ストリームはこのインターバルを1つ以上の連続したレンジに分割し、各々が個別のシャードに割り当てられます。

シンプルな例でご説明しましょう。1つのストリームが1つのシャードを持ちます。この場合、インターバル全体は1つのシャードに割り当てられます。流量が増えてきて1つのシャードで扱いきれない場面を考えてみましょう。スケールアップを行います! パーティションキーをMD5ハッシュで分散した時に均等に128ビットのインターバルに分散すると確信できるのであれば、単純に最初のシャードを分割します。最初のシャードは0 から263-1まで、新しいシャードは263 から2127-1までを扱います。

現実にはそれほど単純ではなく、パーティションキーのMD5ハッシュ分散は均等ではないかもしれません。そのような場合、下半分のパーティションをさらに分割すると最適化できるかもしれません。あるいは、もっと賢く考えるなら、実際のキー分散の状況に応じて対処しても良いかもしれません。これを適切に行うには、長期間におけるハッシュ分散の傾向をトラックし、それに応じたシャード分割を行う必要があります。

トラフィックが減少した際のオペレーションコストを低減するため、シャードを結合することができます。隣接したシャードを結合することができます。繰り返しになりますが、賢い意思決定が良いパフォーマンスと低コストを維持するコツです。分割と結合の順番を示した図を見て下さい。

Kinesisの価格
Kinesisの価格は単純です。PUTの数とシャード毎のスループットキャパシティに応じた料金を支払います。 モバイルデバイス用のゲームを構築し、ゲームに関連づいたプレイヤーの成績、トップスコアや他のメトリックをリアルタイムに追跡し、トップスコアダッシュボードを更新したいとしましょう。

また、各モバイルデバイスは、2キロバイトのメッセージを5分毎に送信し、ピーク時には、10,000デバイスが同時にKinesisへメッセージを送信するとしましょう。この場合、ストリームのサイズをスケールアップしたりダウンしたりすることができますが、単純にするために、一定量のデータレートであるとします。

このデータを使って、やってくるデータを取り込むのに必要なシャードのキャパシティがどれくらいか計算しましょう。 Kinesisコンソールを使えばウィザードを使って見積ることができますが、ここでは算数をしてみましょう。

10,000 (PUTs per second) * 2 kilobytes (per PUT) = 20 megabytes per second

このデータのストリームを処理するために20のシャードが必要になります。

Kinesisはシンプルに使った分だけの支払いになります。1,000,000 PUT操作あたり、$0.028、1シャード、1時間あたり$0.015になります。 1時間ゲームのデータを収集すると、シャードに対して $0.3、約3600万PUTコールに対して $1.01、合計$1.31程度です。

コンソールからKinesisを使う
You can create and manage Kinesis streams using the [Kinesis APIs], the AWS CLI, and the AWS Management Console. Here's a brief tour of the console support. KinesisストリームはKinesis APIAWS CLI、AWS Management Consoleから作成・管理することができます。以下にコンソールを使った例を示します。

Create Streamボタンを押して始めます。ストリーム名とシャード数を指定するだけで始めることが出来ます。

コンソールには必要なシャード数を計算する機能が備わっています。

ストリームは一覧表示されます。

各ストリームに対するCloudWatchのメトリクスを確認できます。


始めてみましょう
Amazon Kinesisはlimited previewとしてご利用可能です。本日よりアクセスのリクエストを行えます。

-- Jeff;


この記事はAWSシニアエバンジェリスト Jeff Barが綴るAmazon Web Services Blogの記事、 Amazon Kinesis - Real-Time Processing of Streaming Big Dataを大久保が翻訳したものです。

コメント

トラックバック

この記事のトラックバックURL:
http://www.typepad.com/services/trackback/6a00d8341c534853ef019b01100368970b

【AWS発表】 Amazon Kinesis – ストリームデータのリアルタイム処理を参照しているブログ:

Featured Event

2016年3 月

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31