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.2k
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
650
現実のRuby/Railsアップグレード
takeyuweb
4
12k
Shinjuku.rb #95 LT会!心の技術書を紹介しよう!
takeyuweb
0
65
リモートワークへの招待
takeyuweb
2
530
OSSにみるレールの外側
takeyuweb
0
220
Rails meets Content Security Policy
takeyuweb
1
660
Rails受託会社を作っている話
takeyuweb
0
120
社長が書いたクソコードたち
takeyuweb
0
1.9k
Rails 考古学:WebAPIを取り巻く環境の変化とRailsの対応について
takeyuweb
0
98
Other Decks in Programming
See All in Programming
理論と実務のギャップを超える
eycjur
0
140
One Enishi After Another
snoozer05
PRO
0
120
Le côté obscur des IA génératives
pascallemerrer
0
150
実践Claude Code:20の失敗から学ぶAIペアプログラミング
takedatakashi
15
5.8k
Devoxx BE 2025 Loom lab
josepaumard
0
100
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
3.4k
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
200
CSC509 Lecture 05
javiergs
PRO
0
300
はじめてのDSPy - 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み
masahiro_nishimi
3
660
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1.1k
アメ車でサンノゼを走ってきたよ!
s_shimotori
0
230
エンジニアインターン「Treasure」とHonoの2年、そして未来へ / Our Journey with Hono Two Years at Treasure and Beyond
carta_engineering
0
340
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
Producing Creativity
orderedlist
PRO
347
40k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Optimizing for Happiness
mojombo
379
70k
Documentation Writing (for coders)
carmenintech
75
5.1k
Unsuck your backbone
ammeep
671
58k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
10
600
BBQ
matthewcrist
89
9.8k
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のここで困ってるがどうしてる?
そのほか 質問や意⾒などあれば!