Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Rails on AWSでの非同期
Search
Yuichi Takeuchi
May 25, 2016
Programming
0
2.1k
Rails on AWSでの非同期
Amazon SQS / SWF / Data Pipeline / AWS Lambdaの紹介
Amazon SQSを使う上でしっておくべき特徴と対策(軽く)
Yuichi Takeuchi
May 25, 2016
Tweet
Share
More Decks by Yuichi Takeuchi
See All by Yuichi Takeuchi
現実のRuby/Railsアップグレード外伝 ~そして僕はforkした~
takeyuweb
0
530
現実のRuby/Railsアップグレード
takeyuweb
4
11k
Shinjuku.rb #95 LT会!心の技術書を紹介しよう!
takeyuweb
0
57
リモートワークへの招待
takeyuweb
2
530
OSSにみるレールの外側
takeyuweb
0
210
Rails meets Content Security Policy
takeyuweb
1
630
Rails受託会社を作っている話
takeyuweb
0
120
社長が書いたクソコードたち
takeyuweb
0
1.9k
Rails 考古学:WebAPIを取り巻く環境の変化とRailsの対応について
takeyuweb
0
87
Other Decks in Programming
See All in Programming
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
150
エンジニア向け採用ピッチ資料
inusan
0
170
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
170
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
510
ReadMoreTextView
fornewid
1
480
Team operations that are not burdened by SRE
kazatohiei
1
260
Deep Dive into ~/.claude/projects
hiragram
9
1.6k
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
4
1k
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
110
GoのGenericsによるslice操作との付き合い方
syumai
3
690
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
380
関数型まつりレポート for JuliaTokai #22
antimon2
0
160
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
800
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Fireside Chat
paigeccino
37
3.5k
Facilitating Awesome Meetings
lara
54
6.4k
Building Applications with DynamoDB
mza
95
6.5k
Practical Orchestrator
shlominoach
188
11k
Music & Morning Musume
bryan
46
6.6k
Building Adaptive Systems
keathley
43
2.6k
How STYLIGHT went responsive
nonsquared
100
5.6k
Git: the NoSQL Database
bkeepers
PRO
430
65k
RailsConf 2023
tenderlove
30
1.1k
Making Projects Easy
brettharned
116
6.3k
Transcript
Shinjuku.rb #37 Theme : ⾮同期処理 タケユー・ウェブ ⽵内雄⼀
⽵内雄⼀ @takeyuweb フリーランスWeb開発者 • 1984年限界集落⽣まれ、⾼専育ち • 2008年独⽴開業 • 上流、下流、運⽤ •
Rails 1.1〜4.2受託(ほぼ業務委託) • 地域コミュニティサイト • SNS • ペライチ的なの • 業務管理システム • 動画配信・販売サイト などなど… • 特定の取引先に依存しない働き⽅! • 2016年6⽉ 法⼈成り予定 • タケユー・ウェブ(株) ロケ地:蒜⼭⾼原
ディーゼル気動⾞ on Rails(単線)
ディーゼル気動⾞ on Rails(単線)
Ruby on Rails on AWS の話
ぼくが使ったことある⾮同期っぽいもの • SQS (Simple Queue Service) • SWF (Simple Work
Flow) • Data Pipeline(バッチ処理も⾮同期の範疇?) • Lambda(イベント駆動も?)
Amazon SQS (Simple Queue Service) • フルマネージドなメッセージキューサービス • 配信管理(排他制御、配信保証、再送 など)
• メッセージに含まれるペイロード数で課⾦
Amazon SWF (Simple Workflow Service) • スケーラブルなワークフロー実⾏基盤 • ワークフロー実⾏回数、過去の保持件数、実⾏中のタスク等の 数で課⾦
Amazon Data Pipeline • 定期的にデータをとってきてまとめて処理して結果を書き出す ようなの • 実⾏頻度で課⾦+パイプライン中で呼び出されるほかのサービ スの料⾦(EMRとかS3とか)
AWS Lambda • AWS上の各種イベントに対して⾮同期実⾏される処理を書ける • リクエスト数、処理時間、使⽤メモリ量で課⾦
Amazon SQS を少し詳しく 5分じゃ⾜りないのでせめてSQS
Amazon SQS を少し詳しく • 特徴 • 対策 • 監視 •
Ruby/Railsでの利⽤
Amazon SQS 知っておくべき特徴① • メッセージ(ジョブ)は少なくとも1回 • 必ず1回は配信される(at-least-once) • 2回以上配信される場合がある
Amazon SQS 知っておくべき特徴② • メッセージ(ジョブ)は⾃動で削除されない • ジョブ終了時にSQSにメッセージ削除を要求する必要がある • 処理途中でプロセスやサーバが死んでも、完了前なら再配信あり •
削除しない場合、⼀定時間(「可視性タイムアウト」)後配信される
Amazon SQS 知っておくべき特徴③ • 可視性タイムアウト • 配信されたジョブがほかのワーカーに配信されない期間 • 繰り返すが at-least-once
なので2つ以上のワーカーに同時に配信されることは ある • 「可視性タイムアウト」を経過したら、ほかのワーカーから⾒えるよ うに(再配信) • 「可視性タイムアウト」後はメッセージを削除できず、繰り返し実⾏ されることになる
Amazon SQS 知っておくべき特徴④ • 先⼊れ先出し(FIFO)を保証しない • メッセージの配信の順番は当てにならない
Amazon SQS 知っておくべき特徴⑤ • メッセージ保持期間を過ぎると消える • デフォルトは4⽇間、キューごとに変更可能 • 最⼩1分 •
最⼤14⽇
「メッセージは少なくとも1回」対策 • 繰り返し実⾏されても壊れないように設計する(冪等性) • 処理中に同時に実⾏されても後から実⾏した⽅を無視する • メッセージ中のパラメータ • SQSによって設定されるメッセージID
「メッセージは⾃動で削除されない」対 策 • 例外を発⽣せず完了した場合はメッセージを削除 • リトライが必要ない例外は例外クラスを指定してrescueした上 で削除するとか
「可視性タイムアウト」対策 • ⻑時間かかるジョブ実⾏中は時々「 ChangeMessageVisibility アクション」で延⻑ • キューのタイムアウト設定が 30秒 • 処理開始20秒時点で終わらなかったら+60秒
とか • 最⼤で処理開始から12時間まで • 別のThreadなりで随時延⻑し続けるのが確実 • 上記がうまく機能せず、繰り返し実⾏される場合の対策 • デッドレターキュー(後述)
「FIFOを保証しない」対策 • 順番が重要な場合はジョブから次のジョブを呼び出すように • 順序情報をメッセージに含めておき、アプリ側でそれをみて制 御 • SWF(ワークフロー)を使う
「メッセージ保持期間」対策 • デッドレターキュー Dead Letter Queue • n回受信して成功しなかったら、メッセージを「デッドレターキュー」に移動 • デッドレターキュー⾃体はふつうのSQSキュー
• うまくいかなかったメッセージを⼊れるキューとして使うよってこと • デッドレターキュー処理⽤のワーカーを作る • 管理者に通知 • ⼀時的なものと判断して再実⾏を試す • などお好きなように
監視 • 正常に処理されなかったジョブ • デッドレターキュー • おやワーカーの様⼦が・・・(死んでる、⾜りてない) • CloudWatchで監視 •
処理中のメッセージ数が0・・・動いてないぽい • 取得可能なメッセージ数が減らない・・・動いてないぽい • 取得可能なメッセージ数増えすぎ・・・増えすぎならワーカー⾜りてなくない?
Ruby/Railsでの利⽤ • AWS SDK for Ruby V2 gem • 公式
• 実⾏基盤も⾃分で書く必要あり • ワーカー⽤のdaemon • ActiveJobアダプタ など • Shoryuken gem • 割と活発に開発されている • ActiveJobアダプタあり • プラガブルなサーバーミドルウェア • 可視性タイムアウトの⾃動延⻑ • メッセージの⾃動削除 など
SQSどうでしょう? • ほかのやつの⽅がこんなに便利 • SQSこんなによさげだって知らなかった • ⾃分はSQSのここで困ってるがどうしてる?
そのほか 質問や意⾒などあれば!