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

ServerlessConf

はじめに

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

serverless-lambda-kinesis

発表資料

動画

スライド

見当たらず

セッション概要

  • なぜサーバーレスなのか
  • 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を触ったことがない方も、一度試されてはいかがでしょうか?