Downloaded 24 times
![[CEDEC 2021] 運用中タイトルでも怖くない！ 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2021-210825103749-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DO07] マイクロサービスに必要な技術要素はすべて Spring Cloud にある](https://cdn.slidesharecdn.com/ss_thumbnails/do07-170620022806-thumbnail.jpg?width=640&height=640&fit=bounds)
![[AC05] マイクロサービスは分割がキモ！基幹システムのためのドメイン駆動設計](https://cdn.slidesharecdn.com/ss_thumbnails/ac05-170602093650-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Cloud OnAir ] #03 No-ops で大量データ処理基盤を簡単に構築する](https://cdn.slidesharecdn.com/ss_thumbnails/cloudonair03no-ops-171102093529-thumbnail.jpg?width=640&height=640&fit=bounds)
マイクロサービスにおける 非同期アーキテクチャ
- 1. ota42y 2017/09/28 Rails Developers Meetup#5 マイクロサービスにおける 非同期アーキテクチャ
- 2. • ota42y • ゲームクライアントエンジニア →サーバエンジニアに転職(1年ぐらい前) •rubyとかgoとかC++とか • twitterとかgithubとか 自己紹介
- 3. • twitter凍結したらこちらへ – https://ota42y.com/ –ネタとして入れたら今朝になって現実味が… あとでツイート全削除かな… – 凍結されそう
- 6. • 外から見たときは一つのアプリ • 内部的にはドメイン事に別々のサーバ microservice ダイエット家庭教師 FiNCモール FiNCアプリ lifelog 法人向けchat ranking main
- 7. • 各サーバは独立しており、API経由で連携 • 非同期に連携処理も多数含まれる •巨大かつ複雑になりやすい→知見 microservice ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29. • microserviceでは非同期処理を多用する • 非同期処理の移り変わりとともに紹介 microservice ダイエット家庭教師 FiNCモール FiNCアプリ lifelog 法人向けchat ranking main
- 30.
- 31.
- 32. delayed_job https://github.com/collectiveidea/delay ed_job • RDBのテーブルをQueueとして使う • 1job=1 recordとして保存する • RDB以外を用意・運用する必要無い(redisとか) • 優先度や時刻指定など一通りの機能がある • RDBに書き込むのでJobは永続化される FiNCでは最初期から採用
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44. 地獄への急行列車 処理速度が低下し 処理速度 <増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに
- 45. 地獄への急行列車 処理速度が低下し 処理速度 <増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ
- 46. 地獄への急行列車 処理速度が低下し 処理速度 <増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ よって打つ手がなくなる
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. 巨大な処理 クリティカルかどうかで場合分け • クリティカル • ユーザ作成時の初期化処理 •再実行が難しい処理 • クリティカルではないもの • フォロー数の再計算 • 検索用キャッシュのアップデート • 簡単に再実行可能なやつ
- 57. 巨大な処理 重要度に応じて処理わけ • クリティカル • 信頼度が重要なので引き続きdelayed_job •クリティカルではないもの • 後からの再実行が容易 • 基本的に別バックエンドへ移動 • delayed_jobのjob数を減らす
- 58.
- 59.
- 60. sidekiq redisをバックエンドに使うJob Queue • スレッドベース •redisなので並列度は上げやすい • リトライ機構あり 他のmicroserviceで採用していたり、 社内に経験者がいる的なのでこれ
- 61.
- 62.
- 63. ここまでのまとめ • 巨大な処理 • クリティカルなもの •安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
- 64.
- 65. ここからの話 • 巨大な処理 • クリティカルなもの •安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74. 複数サービスへの連携 Lifelog Ranking StepsCampaign Point Steps Update Event • 条件を満たすと対応するEventを送信 •受け取り側はEventを受信したら処理する 送信側と受信側の結合度が減る
- 75.
- 76.
- 77.
- 78. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) LifelogRanking AWS SNS AWS SQSSteps Update
- 79. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) SNSをsubscribeすると、 eventがキューにコピーされる LifelogRanking AWS SNS AWS SQS Steps Update
- 80. イベント受信 SNSは複数のSQSに同時にコピーしてくれる 各サービスは自分のSQSを作り、SNSをsubscribe Lifelog Ranking Point AWS SNS AWSSQS Steps Update Steps Update
- 81.
- 82.
- 83.
- 84.
- 85.
- 86. SNS/SQSには癖がある • 冪等である必要がある • SQSは1回以上取り出す事を保証 •同じjobが2回実行される場合がある • 実行済みの時、並列実行の時に気をつける • 従量課金 • 送ったデータ数・サイズ課金 • 大量に送りまくる使い方だと課金死
- 87. SNS/SQSには癖がある • SNSが遅い • 同リージョンで40msぐらいかかる •delayed_jobやsidekiqと比べると遅い • もっと早いという噂も聞くので設定かも • 依存設定がAWSのコンソールに集中 • 変更履歴無い • 依存関係がわかりにくい
- 88.
- 89.
- 90.
- 91.
- 92. やりとりはgem化 移行を楽にするために • SNSへ送信 • SQSから取得 •イベントのフォーマット統一 のためのgemを作った https://github.com/ota42y/rising_dragon
- 93. やりとりはgem化 移行を楽にするために • SNSへ送信 • SQSから取得 •イベントのフォーマット統一 のためのgemを作った https://github.com/ota42y/rising_dragon Lifelog Ranking AWS SNS AWS SQS Steps Update
- 94. 欠点 <<< 利点 気をつける所はあるが、利点の方が大きい マイクロサービスではかなり良いアーキテクチャ 癖に対してもいくつか対応中 •イベントをまとめて送りSNS/SQSの費用削減 • AWSの情報を元に依存関係の見える化サービス • 設定ファイルからSNS/SQSの自動設定
- 95.
- 96. まとめ • イベントっぽいもの • イベント駆動アーキテクチャ •SNS/SQS • イベントでは無いもの • クリティカルなもの • 安全なバックエンド • (delayed_job) • クリティカルでは無いもの • 並列処理に問題がないバックエンド • (sidekiq)
- 98.
- 99. delayed_jobの障害対応 障害が起きてしまった場合は、 • 手動でDBの行の一部をファイルに書き出す • 書き出した行を削除 •queueの件数が減るのでまともに動く • queueが減ってきたら待避したのを戻す と、頑張れば何とかなります（つらい）
- 100.
- 101.
- 102. SQSのFIFOキューは AWS SQSのFIFOキューは https://aws.amazon.com/jp/blogs/news/new-for-amazon-simple-queue-service-fifo-queues-with-exactly- once-delivery-deduplication/ メッセージが送信順に 1回だけ、重複なく処理さ れることを保証するように設計されています。 というキュー ただ、1秒当たりの最大取得数があるので、 大量に積んだときの処理に不安があり採用見送り （あとTokyoにまだ来てなかった）
- 103.
- 104.
- 105.