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
58
リモートワークへの招待
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
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
150
Go1.25からのGOMAXPROCS
kuro_kurorrr
1
820
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
620
iOSアプリ開発で 関数型プログラミングを実現する The Composable Architectureの紹介
yimajo
2
220
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
230
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
600
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.7k
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
0
130
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
110
GoのGenericsによるslice操作との付き合い方
syumai
3
690
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
670
Benchmark
sysong
0
280
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.3k
Music & Morning Musume
bryan
46
6.6k
Navigating Team Friction
lara
187
15k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
KATA
mclloyd
30
14k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
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のここで困ってるがどうしてる?
そのほか 質問や意⾒などあれば!