(レポート) AWSモバイル/IoTサービス徹底攻略!!「API Gateway / Lambda / Kinesis を使ったストリーミングなバッチ実行基盤の実装」 #cmdevio

(レポート) AWSモバイル/IoTサービス徹底攻略!!「API Gateway / Lambda / Kinesis を使ったストリーミングなバッチ実行基盤の実装」 #cmdevio

Clock Icon2015.11.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、オペブの半瀬です。

11/21(土)に目黒のAWSJにて開催された「AWSモバイル/IoTサービス徹底攻略!!〜Developers.IO Meetup番外編〜」のレポートです!

イベント概要

本勉強会は、基本的な内容のBasic Track、応用的な内容のAdvanced Track、実際に試すことの出来るHands Onの3トラックに分けてAWSのモバイルサービスや、サーバーレスアーキテクチャ、IoTのお話をするというものです。

ご登壇者様・タイトル

株式会社リブセンス 篠田 健 様
API Gateway / Lambda / Kinesis を使ったストリーミングなバッチ実行基盤の実装 IMG_6855
(遠目からの撮影となり申し訳ありません。。 )

セッションの内容

ある賃貸不動産メディアの事例

伝統的なバッチジョブ構成

  • 毎日400万件程度のデータが入ってくる
  • 物件情報データ → バッチ処理 → バッチ → バッチ → 各種DB/画像サーバーに
  • 立ち上げはしやすい
  • 学習コストも高くない
  • 実行速度もそこそこ
  • サービス拡大傾向が読めない

様々な課題

  • 各社で違うフォーマット
  • ジョブがお割らない
  • 物件数の増大によるデータが大きくなる
  • サーバーメンテの複雑化
  • バッチによりサービス内容の劣化

Lambdaで置き換えてみる!

  • スケーラビリティを確保したい
  • サーバのプロビジョニングをできるだけしないようにしたい
  • 各ジョブをステートレスにしたい
    • 他のジョブに左右されない
    • 入出力を同じにする
    • エンティティ単位
  • リアルタイム処理に移行したい

スケーラビリティの確保

  • 物件数の拡大に耐える
  • 運用負荷の軽減する
    • 物件数は季節変動するもの

サーバーのプロビジョニングをできるだけしない

  • プロビジョニングコードのメンテ負荷の低減する
    • スケールできる基盤の仕組みをそのまま使う
    • サーバ構成を見る時間を減らす
  • 各社のフォーマット対応でサーバーごとの差異を出さないようにする

各ジョブをステートレスにする

  • 他のジョブの実行結果を意識せず処理を組めることが必要

設計段階での全体構成案の推移

案1:Elastic Benastalkのwokerで実装してみると。。

  • pros
    • EBで利用言語が比較的自由
    • プロビジョニングは最低限ですむ
  • cons
    • 処理分散単位がS3のオブジェクト単位になる

案2: 単純にLambdaを入れてみる:中間処理結果を残さず、つなぐ

  • pros
    • サーバーのプロビジョニングは不要
    • EBで利用言語が比較的自由
    • プロビジョニングは最低限ですむ
  • cons
    • Lambdaの多段処理のテストが大変
    • Lambdaごとにリポジトリを分けないとCI/CDが大変

案3: Lambda API GateWay Kinensis(採用)

  • pros
    • 案2の利点を享受できる
    • レイヤを意識させることができ、アプリケーションの複雑化を抑制
    • 書き込み部分はバッチ性能に合わせて、Kinesisで調整可能
  • cons
    • Lambdaの多段処理のテストが大変
    • Lambdaごとにリポジトリを分けないとCI/CDが大変
    • 案2と同じ

達成できたこと

スケーラビリティ

  • データの分割と処理の多重化
    • 処理を非同期で呼び出すことでスケールする
    • 全入力データ多段で分割し, 個別処理をする
  • 次段の呼び出し粒度でLambdaの多重度を制御する
    • Lambdaに不向きな処理
    • 全データの処理分割に時間がかかる

ステートレス

  • ステートレスな構成を維持して拡張性を残す
    • 間にKinesisを入れるLambdaの追加だけで処理拡張を可能にする

データストアへの流し込みを集約

  • 書き込み順の問題
    • すべてのデータが確実に揃っていることを前提に作らないことにした

開発にあたって難しかったこと

  • Lambda外から値を渡せない
  • node.jsが古い
  • 結合テストが大変
  • 共通処理が大変
  • リポジトリがたくさんできてしまう

さいごに

"伝統的な"バッチ処理構成を、「API Gateway」「Lambda」「Kinesis」を使うことでどのように課題を解決したかについて、実際の事例をもとにご紹介いただきました。導入にあたっての、採用案にたどり着くまでの経緯、開発段階での課題など、とても参考となるセッションでした。大変勉強になりました。
<会場の様子>
IMG_6853 篠田様 ありがとうございました!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.