(レポート)[ServerlessConf London] 「Real-time Data Processing Using AWS Lambda」 #serverlessconf

はじめに

本レポートは2016年10月27日(木)〜28日(金)に開催されたServerlessConf Londonのセッション「Real-time Data Processing Using AWS Lambda」のレポートです。 本セッションのスピーカーはAWS Solutions ArchitectのKen Payneさんです。

発表資料

動画

スライド

見当たらず

セッション概要

• なぜサーバーレスなのか
• AWS LambdaとAWS Kinesis Streamsを使ったリアルタイムデータ処理方法について
• デモ

なんでFunction as a Service(FaaS)?

• ロジック
• Framework
• Dependencies
• OS
• Hardware

というレイヤーがある。

2006年にS3、EC2とリリースしてから、その上にマネージド・サービスを構築してきた。 AWS Lambdaは最上位のレイヤーで、エンドユーザーに直接価値を届けるところを関数化したサービス。 AWS Lambdaを利用すると、開発者は、サーバ管理ではなく、コアビジネスに注力出来る。

Serverless Compute Manifesto

AWSの考えるサーバーレス

• Functions are the unit of deployment and scaling.
• No machines, VMs, or containers visible in the programming model.
• Permanent storage lives elsewhere.
• Scales per request. vUsers cannot over- or under-provision capacity.
• Never pay for idle (no cold servers/containers or their costs).
• Implicitly fault-tolerant because functions can run anywhere.
• BYOC – Bring your own code.
• Metrics and logging are a universal right.

データ処理アーキテクチャ

• アーキテクチャは大きく分けて2種類ある
• バッチ処理:generate -> store -> analyse - > share
• ストリーム処理:generate -> stream processing -> share
• 本セッションは後者について、AWS Kinesis Streamsと AWS Lambdaを連携させると、驚くほど簡単に構築できることを紹介。
• ダッシュボードのように、データが生成されたら即時に処理したいサービスに向いている。
• 処理したデータを可視化するといった share の要素は本セッションのスコープから外し、ストリーム処理に絞って解説

AWS Lambda概要

• AWS Lambda は function as a service(FaaS)
• エベントを契機にLambda関数が呼び出される。
• S3にオブジェクトが追加された呼び出せる。
• 最近の興味深い例では、音声入力をトリガーにLambda関数を呼び出すこともできる(Amazon Alexa)

サーバーレスな AWS Lambda のメリット

• VM やコンテナの管理が不要
• スケールする
• Lambda関数を多段で呼び出す(cascading Lambda functions)
• 好きなコードを実行出来る

Kinesis Streams概要

• Kinesis Streams
• ストリームデータを好きに処理できるサービス
• Kinesis Firehose
• 大量のデータをS3,Redshiftに放り込むようなよくあるケースに特化したサービス -Kinesis Analytics
• ストリームデータをSQLで絞り込んで抽出されたデータを別サービスに連携
• ストリーム・イン、ストリーム・アウト

Kinesisのメリット

• フルマネージドで高可用
• シャードを増やせばいくらでもスケールする

KinesisとLambdaはどう連携する?

• Lambda関数が定期的に呼び出されれ、たまっていたレコードがまとめてLambdaに渡される。
• シャード単位でシーケンスにデータ処理される
• VM 管理は不要
• KinesisストリームとLambda関数は1対多、多対1、多対多といった組み合わせが可能。
• 用途毎にLambda関数を用意する

デモ

AWS管理画面を操作し、Kinesis-Lambda連携をスクラッチから構築する。

• Kinesisストリームの作成
• Lambda関数の作成
• Kinesisストリーム連携をサクッと試すためのブループリントが用意されている
• データソースとして作成したKinesisストリームを指定する
• バッチサイズは重要。一度に処理する最大数を指定する。指定したレコードが貯まるまでイベントが呼び出されないわけではない。指定数より少なくても、溜まっているレコード数だけでLambdaが呼び出される。
• ペイロードには任意のデータを突っ込める。JSON、XMLなどなんでもOK.受け取り時にデータ型に応じて処理する。
• シェルからAWS CLIを使ってKinesisストリームへデータ登録
• partition keyの選択は重要。
• partition keyをキーにしてシャード振り分けされる
• シェルスクリプトではpartition keyを固定しているので、特定のシャードに偏って振り分けられる。
• Lambdaの呼び出しの確認
• しばらくすると、Lambdaのメトリクスから呼び出されていることを確認できる。
• CloudWatch Logsへのログ出力の確認
• CloudWatchでKinesis/Lambdaのメトリクスを確認

以上のように、さくっとリアルタイム処理基盤を作成できた。

注意点

• Lambdaを使わなければ、Kinesisクライアントを自分で書き、定期的にKinesisストリームからデータ引っ張るロ ジックも書かなければいけないが、Lambdaを使えば、データ取得後の処理ロジックだけを掛けば良い
• シャード単位でレコードが登録順に処理される
• Kinesisのシャード分割とパティションキーのおかげで水平スケールがかんたん
• Lambdaのバッチサイズが大きくすると、呼び出し毎の処理レコード数も増えるのでLambdaの処理時間にも影響する
• バッチサイズとレコードあたりの処理時間から、シャード毎の処理能力を計算できる
• Lambda処理のエラー発生時には、exponential backoffしつつリトライする仕組みも備わっている。
• Lambda のメトリクス
• CLoudWatchやCloudWatch LogsからRAM使用量、処理時間などがわかる

ベストプラクティス

• Kinesisの処理能力が足りないときは、シャードを増やして並列度を上げる
• 用途ごとにLambda関数を用意すれば、同じレコードを何通りにも処理できる
• Kinesisへのデータ登録時にはシャード毎にデータが偏らないようにする
• S3 連携はKinesis Firehoseを使うと簡単。
• Lambda関数のエラーやスロットリングはモニターすること
• Kinesisストリームのスロットルはモニターすること
• OSSでKinesisストリームをスケールイン・アウトさせるライブラリもある。
• https://github.com/awslabs/amazon-kinesis-scaling-utils
• Kinesis Streamをすでにつかっているユーザー向けに、LambdaでFirehoseにつなぐライブラリもある。
• https://github.com/awslabs/lambda-streams-to-firehose

Q&A

• AWS Kinesis StreamsとAWS SNSをどう使い分ければ良い?
• Kinesis Streamsは一定期間、データが永続化される。

まとめ

AWS Kinesis と AWS Lambdaを使ってリアルタイム分析を始めたい人向けのセッションでした。 データの流れを作るところまでは非常にかんたんにできます。

ユースケース毎に

• Kinesis Streamsへのデータ送信
• Kinesis が受け取ったデータの処理(Lambda)

をカスタマイズすれだけで実案件に適用できます。

Kinesisを触ったことがない方も、一度試されてはいかがでしょうか?