この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、オペブの半瀬です。
11/21（土）に目黒のAWSJにて開催された「AWSモバイル/IoTサービス徹底攻略！！〜Developers.IO Meetup番外編〜」のレポートです！
イベント概要
本勉強会は、基本的な内容のBasic Track、応用的な内容のAdvanced Track、実際に試すことの出来るHands Onの3トラックに分けてAWSのモバイルサービスや、サーバーレスアーキテクチャ、IoTのお話をするというものです。
ご登壇者様・タイトル
株式会社リブセンス 篠田 健 様
API Gateway / Lambda / Kinesis を使ったストリーミングなバッチ実行基盤の実装
（遠目からの撮影となり申し訳ありません。。 ）
セッションの内容
ある賃貸不動産メディアの事例
伝統的なバッチジョブ構成
- 毎日400万件程度のデータが入ってくる
- 物件情報データ → バッチ処理 → バッチ → バッチ → 各種DB/画像サーバーに
- 立ち上げはしやすい
- 学習コストも高くない
- 実行速度もそこそこ
- サービス拡大傾向が読めない
様々な課題
- 各社で違うフォーマット
- ジョブがお割らない
- 物件数の増大によるデータが大きくなる
- サーバーメンテの複雑化
- バッチによりサービス内容の劣化
Lambdaで置き換えてみる！
- スケーラビリティを確保したい
- サーバのプロビジョニングをできるだけしないようにしたい
- 各ジョブをステートレスにしたい
- 他のジョブに左右されない
- 入出力を同じにする
- エンティティ単位
- リアルタイム処理に移行したい
スケーラビリティの確保
- 物件数の拡大に耐える
- 運用負荷の軽減する
- 物件数は季節変動するもの
サーバーのプロビジョニングをできるだけしない
- プロビジョニングコードのメンテ負荷の低減する
- スケールできる基盤の仕組みをそのまま使う
- サーバ構成を見る時間を減らす
- 各社のフォーマット対応でサーバーごとの差異を出さないようにする
各ジョブをステートレスにする
- 他のジョブの実行結果を意識せず処理を組めることが必要
設計段階での全体構成案の推移
案１：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が大変
- 案２と同じ
達成できたこと
スケーラビリティ
- データの分割と処理の多重化
- 処理を非同期で呼び出すことでスケールする
- 全入力データ多段で分割し, 個別処理をする
- 次段の呼び出し粒度でLambdaの多重度を制御する
- Lambdaに不向きな処理
- 全データの処理分割に時間がかかる
ステートレス
- ステートレスな構成を維持して拡張性を残す
- 間にKinesisを入れるLambdaの追加だけで処理拡張を可能にする
データストアへの流し込みを集約
- 書き込み順の問題
- すべてのデータが確実に揃っていることを前提に作らないことにした
開発にあたって難しかったこと
- Lambda外から値を渡せない
- node.jsが古い
- 結合テストが大変
- 共通処理が大変
- リポジトリがたくさんできてしまう
さいごに
"伝統的な"バッチ処理構成を、「API Gateway」「Lambda」「Kinesis」を使うことでどのように課題を解決したかについて、実際の事例をもとにご紹介いただきました。導入にあたっての、採用案にたどり着くまでの経緯、開発段階での課題など、とても参考となるセッションでした。大変勉強になりました。
＜会場の様子＞
篠田様 ありがとうございました！
2
