初めてのAWS Lambdaによるプロダクト開発譚〜オブラブカレンダー配布会2019

初めての
AWS Lambda による
プロダクト開発譚
平成31年(2019年) 4月 10日
e.mattsan

GMail: e.mattsan
Twitter, idobata: emattsan
GitHub: mattsan
はてなブログ: E_Mattsan
平成25(2013年) 4月から中の人
松本栄二 (emattsan)

平成28年(2016年) 3月開始
平成31年(2019年) 1月完了
およそ 3年間、プロジェクトに参加
そのうちおよそ半分の期間を AWS
Lambda で開発を行う
プロジェクト

書類で蓄えていたデータを電子化した大規
模なデータベース
このデータに基づいてエンドユーザに関わ
る設定を自動的に行う
ユーザはデータが登録されたら自動的に利
用環境が整う
プロジェクト

第0段階
Ruby on Rails
第1段階
Ruby on Rails
AWS Lambda (Node.js)
第2段階
AWS Lambda (Node.js)
プラットフォーム

基盤DB
バックエンドApp（開発担当）
基盤DBからデータを取り込む
ユーザに必要な形式のデータに加工する
フロントエンドに送信する
フロントエンドApp
ユーザにサービスを提供する
第0段階

5分ごと/2時間ごとにDBにデータが投入され
るが、データの加工に時間がかかってフロン
トエンドにデータを送るのが数時間に一回と
いうペース
「投入したデータがすぐに利用できるように
なる」というサービスの根幹に関わる問題
第0段階
「データを取り込んでからフロントエンドに
送るまでに一回あたり数時間かかる」

もともと書類で管理されていたデータを
DBに置き換えたものなので、DBの構造が
データを活用するようにできていない
設計がよくなかったというのもある
第0段階
「データを取り込んでからフロントエンドに
送るまでに一回あたり数時間かかる」

push App
基盤DBのデータ取り込みに専念
扱いやすくするためのデータを付加する
レコードの更新をSNSで通知する
pull App
リクエストされたデータを返すことに専念
AWS Lambda
データの加工に専念
更新が通知されたレコードをpull Appからデータを得る
データを加工しフロントエンドに送る
第1段階

AWS Lambda
データの加工に特化
更新が通知されたデータの直接の依存関
係しか考慮しない
データを処理する順序が影響する
第1段階

Lambdaがひっきりなしにリクエスするた
めpull Appがさばき切れず落ちる
インスタンスを増強したが増強分のCPUは
遊ぶだけで問題は解決しない
第1段階
「pull Appが詰まる」

問題は接続数
データは事前にある程度加工していあるのでpull
Appは関連するデータを連結して返せばよい
CPUはあまり利用していなかった
インスタンスを小さくして数を増やし、それぞれ
のインスタンスの接続数も増やした
第1段階

処理するデータの順序が影響するので、フロ
ントエンドは単一のインスタンスで受信して
いた
受信で詰まるとサービスも固まる
受信専用のインスタンスを用意した
インスタンスを超強力にした
第1段階
「フロントエンド Appが詰まる」

それぞれが、それぞれの処理に特化した結
果、リカバリが難しくなった
フロントエンドにデータが届かないことが
起こると、欠けたデータだけを送り直して
も回復しない
データを送る順序が影響する
第1段階
「イベントが失われると大変」

フロントエンドのインスタンスを超強力に
してもたびたび失敗する
正しく送信できていた時点を特定し、push
Appでそれ以降に取り込んだデータを更新
して強制的にイベントを再生成
第1段階

push Appとpull Appはインフラチームが担
当することになりてを離れる
対応するアプリケーションを再開発
開発はLambda部分に注力
第2段階

push AppのDBを更新してイベント再生成という
方法が使えなくなる
SNSのイベントをすべてDynamoDBに一旦登録
し、LambdaはDynamoDBのイベントを利用する
ようにした
イベントの再生成が必要なときはDynamoDBのデ
ータを更新して実現
第2段階

一回のLambdaの呼び出しでDynamoDBのイベント
が複数届く
スループットを上げるための重要な仕組みだけれ
ども、今回のケースではイベントを個別に処理し
たいので逆に困る
バッチサイズを1にする
一回の呼び出しでイベント一つ
第2段階
「イベントがまとめてやってくる」

時間当たりのリクエスト数に制限が設定される
従来はアプリケーションの都合に合わせてチュー
ニングしていたものの、それができなくなった
同時実行数を設定して、その数以上は同時には実
行されないようにする
イベントの増減の影響を吸収
第2段階

立てるのも簡単、増やすのも簡単
呼び出し頻度を気にかけないで済む
Lambdaはスケールするが、利用するリソ
ースが着いてこられるとは限らない
第2段階

平成30年(2018年) 11月、AWS LambdaがRuby
をサポートすることが発表される
「今からでもRubyで書き直さないか？」
年末年始の世間がお休みの間にシステムを入
れ替える
1月末にはプロジェクトから抜ける
…というタイミングだった
そしてRubyのサポート

新たにプロジェクトに参加
平成31年(2019年) 2月
今度こそRubyで開発、のはず
その後のLambda

プロジェクトを移って最初の本格的な開発
AWS Lambda + Embulk (Java)
プラグインはRubyのgemの形で提供
情報が少なく悪戦苦闘
結果的にEC2よりも簡単にすんだ
その後のLambda

と、いうわけで。
まだAWS Lambda+Rubyの組み合わせの開
発は実現していない
RailsエンジニアがRubyでLambdaを使える
ようになったら、きっといいことがあるに
違いない
その後のLambda

ありがとうございました

初めてのAWS Lambdaによるプロダクト開発譚〜オブラブカレンダー配布会2019

More Related Content

Featured

初めてのAWS Lambdaによるプロダクト開発譚〜オブラブカレンダー配布会2019