Rails on AWSでの非同期

Amazon SQS / SWF / Data Pipeline / AWS Lambdaの紹介
Amazon SQSを使う上でしっておくべき特徴と対策（軽く）

Transcript

1. Shinjuku.rb #37 Theme : ⾮同期処理 タケユー・ウェブ ⽵内雄⼀
2. ⽵内雄⼀ @takeyuweb フリーランスWeb開発者 • 1984年限界集落⽣まれ、⾼専育ち • 2008年独⽴開業 • 上流、下流、運⽤ • Rails 1.1〜4.2受託（ほぼ業務委託） • 地域コミュニティサイト • SNS • ペライチ的なの • 業務管理システム • 動画配信・販売サイト などなど… • 特定の取引先に依存しない働き⽅！ • 2016年6⽉ 法⼈成り予定 • タケユー・ウェブ（株） ロケ地：蒜⼭⾼原
3. ディーゼル気動⾞ on Rails（単線）
4. ディーゼル気動⾞ on Rails（単線）
5. Ruby on Rails on AWS の話
6. ぼくが使ったことある⾮同期っぽいもの • SQS (Simple Queue Service) • SWF (Simple Work Flow) • Data Pipeline（バッチ処理も⾮同期の範疇？） • Lambda（イベント駆動も？）
7. Amazon SQS (Simple Queue Service) • フルマネージドなメッセージキューサービス • 配信管理（排他制御、配信保証、再送 など） • メッセージに含まれるペイロード数で課⾦
8. Amazon SWF (Simple Workflow Service) • スケーラブルなワークフロー実⾏基盤 • ワークフロー実⾏回数、過去の保持件数、実⾏中のタスク等の 数で課⾦
9. Amazon Data Pipeline • 定期的にデータをとってきてまとめて処理して結果を書き出す ようなの • 実⾏頻度で課⾦＋パイプライン中で呼び出されるほかのサービ スの料⾦（EMRとかS3とか）
10. AWS Lambda • AWS上の各種イベントに対して⾮同期実⾏される処理を書ける • リクエスト数、処理時間、使⽤メモリ量で課⾦
11. Amazon SQS を少し詳しく 5分じゃ⾜りないのでせめてSQS
12. Amazon SQS を少し詳しく • 特徴 • 対策 • 監視 • Ruby/Railsでの利⽤
13. Amazon SQS 知っておくべき特徴① • メッセージ（ジョブ）は少なくとも１回 • 必ず１回は配信される（at-least-once） • ２回以上配信される場合がある
14. Amazon SQS 知っておくべき特徴② • メッセージ（ジョブ）は⾃動で削除されない • ジョブ終了時にSQSにメッセージ削除を要求する必要がある • 処理途中でプロセスやサーバが死んでも、完了前なら再配信あり • 削除しない場合、⼀定時間（「可視性タイムアウト」）後配信される
15. Amazon SQS 知っておくべき特徴③ • 可視性タイムアウト • 配信されたジョブがほかのワーカーに配信されない期間 • 繰り返すが at-least-once なので２つ以上のワーカーに同時に配信されることは ある • 「可視性タイムアウト」を経過したら、ほかのワーカーから⾒えるよ うに（再配信） • 「可視性タイムアウト」後はメッセージを削除できず、繰り返し実⾏ されることになる
16. Amazon SQS 知っておくべき特徴④ • 先⼊れ先出し（FIFO）を保証しない • メッセージの配信の順番は当てにならない
17. Amazon SQS 知っておくべき特徴⑤ • メッセージ保持期間を過ぎると消える • デフォルトは４⽇間、キューごとに変更可能 • 最⼩1分 • 最⼤14⽇
18. 「メッセージは少なくとも１回」対策 • 繰り返し実⾏されても壊れないように設計する（冪等性） • 処理中に同時に実⾏されても後から実⾏した⽅を無視する • メッセージ中のパラメータ • SQSによって設定されるメッセージID
19. 「メッセージは⾃動で削除されない」対 策 • 例外を発⽣せず完了した場合はメッセージを削除 • リトライが必要ない例外は例外クラスを指定してrescueした上 で削除するとか
20. 「可視性タイムアウト」対策 • ⻑時間かかるジョブ実⾏中は時々「 ChangeMessageVisibility アクション」で延⻑ • キューのタイムアウト設定が 30秒 • 処理開始20秒時点で終わらなかったら+60秒 とか • 最⼤で処理開始から12時間まで • 別のThreadなりで随時延⻑し続けるのが確実 • 上記がうまく機能せず、繰り返し実⾏される場合の対策 • デッドレターキュー（後述）
21. 「FIFOを保証しない」対策 • 順番が重要な場合はジョブから次のジョブを呼び出すように • 順序情報をメッセージに含めておき、アプリ側でそれをみて制 御 • SWF（ワークフロー）を使う
22. 「メッセージ保持期間」対策 • デッドレターキュー Dead Letter Queue • ｎ回受信して成功しなかったら、メッセージを「デッドレターキュー」に移動 • デッドレターキュー⾃体はふつうのSQSキュー • うまくいかなかったメッセージを⼊れるキューとして使うよってこと • デッドレターキュー処理⽤のワーカーを作る • 管理者に通知 • ⼀時的なものと判断して再実⾏を試す • などお好きなように
23. 監視 • 正常に処理されなかったジョブ • デッドレターキュー • おやワーカーの様⼦が･･･（死んでる、⾜りてない） • CloudWatchで監視 • 処理中のメッセージ数が０･･･動いてないぽい • 取得可能なメッセージ数が減らない･･･動いてないぽい • 取得可能なメッセージ数増えすぎ･･･増えすぎならワーカー⾜りてなくない？
24. Ruby/Railsでの利⽤ • AWS SDK for Ruby V2 gem • 公式 • 実⾏基盤も⾃分で書く必要あり • ワーカー⽤のdaemon • ActiveJobアダプタ など • Shoryuken gem • 割と活発に開発されている • ActiveJobアダプタあり • プラガブルなサーバーミドルウェア • 可視性タイムアウトの⾃動延⻑ • メッセージの⾃動削除 など
25. SQSどうでしょう？ • ほかのやつの⽅がこんなに便利 • SQSこんなによさげだって知らなかった • ⾃分はSQSのここで困ってるがどうしてる？
26. そのほか 質問や意⾒などあれば！