マイクロサービスにおける 非同期アーキテクチャ
Download as PPTX, PDF6 likes49,296 views
Rails Developers Meetup #5 https://techplay.jp/event/631406
マイクロサービスにおける 非同期アーキテクチャ
- 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
- 29. • microserviceでは非同期処理を多用する • 非同期処理の移り変わりとともに紹介 microservice ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
- 32. delayed_job https://github.com/collectiveidea/delay ed_job • RDBのテーブルをQueueとして使う • 1 job=1 recordとして保存する • RDB以外を用意・運用する必要無い(redisとか) • 優先度や時刻指定など一通りの機能がある • RDBに書き込むのでJobは永続化される FiNCでは最初期から採用
- 34. 便利(o゜▽゜)
- 35. しかしある日…
- 38. ＼(^o^)／
- 44. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに
- 45. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ
- 46. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ よって打つ手がなくなる
- 47. 😇 😇 😇
- 51. 大移行時代
- 55. 巨大な処理
- 56. 巨大な処理 クリティカルかどうかで場合分け • クリティカル • ユーザ作成時の初期化処理 • 再実行が難しい処理 • クリティカルではないもの • フォロー数の再計算 • 検索用キャッシュのアップデート • 簡単に再実行可能なやつ
- 57. 巨大な処理 重要度に応じて処理わけ • クリティカル • 信頼度が重要なので引き続きdelayed_job • クリティカルではないもの • 後からの再実行が容易 • 基本的に別バックエンドへ移動 • delayed_jobのjob数を減らす
- 60. sidekiq redisをバックエンドに使うJob Queue • スレッドベース • redisなので並列度は上げやすい • リトライ機構あり 他のmicroserviceで採用していたり、 社内に経験者がいる的なのでこれ
- 62. 😆
- 63. ここまでのまとめ • 巨大な処理 • クリティカルなもの • 安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
- 64. イベントアーキテクチャ時代
- 65. ここからの話 • 巨大な処理 • クリティカルなもの • 安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
- 69. 🤔
- 73. 複数サービスへの連携 Lifelog Ranking StepsCampaign Point Steps Update Event • 条件を満たすと対応するEventを送信 • 受け取り側はEventを受信したら処理する
- 74. 複数サービスへの連携 Lifelog Ranking StepsCampaign Point Steps Update Event • 条件を満たすと対応するEventを送信 • 受け取り側はEventを受信したら処理する 送信側と受信側の結合度が減る
- 75. 良さそう(o゜▽゜)
- 76. 具体的な内容
- 77. イベント送信 AWSのSNS(Simple Notification Service)を利用 (Pub/Subメッセージングしてくれるサービス) 送る側はSNSにデータを送るだけ Lifelog AWS SNSSteps Update
- 78. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) Lifelog Ranking AWS SNS AWS SQSSteps Update
- 79. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) SNSをsubscribeすると、 eventがキューにコピーされる Lifelog Ranking AWS SNS AWS SQS Steps Update
- 80. イベント受信 SNSは複数のSQSに同時にコピーしてくれる 各サービスは自分のSQSを作り、SNSをsubscribe Lifelog Ranking Point AWS SNS AWS SQS Steps Update Steps Update
- 84. 🍺🍺🍺優勝🍺🍺🍺
- 85. …
- 86. SNS/SQSには癖がある • 冪等である必要がある • SQSは1回以上取り出す事を保証 • 同じjobが2回実行される場合がある • 実行済みの時、並列実行の時に気をつける • 従量課金 • 送ったデータ数・サイズ課金 • 大量に送りまくる使い方だと課金死
- 87. SNS/SQSには癖がある • SNSが遅い • 同リージョンで40msぐらいかかる • delayed_jobやsidekiqと比べると遅い • もっと早いという噂も聞くので設定かも • 依存設定がAWSのコンソールに集中 • 変更履歴無い • 依存関係がわかりにくい
- 91. 両方移行しないといけない 良さそうだがmicroservice間の通信の事なので、 送信側・受信側共に移行する必要がある →簡単に移行できないとみんな移行しない Lifelog Ranking AWS SNS AWS SQS
- 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の自動設定
- 96. まとめ • イベントっぽいもの • イベント駆動アーキテクチャ • SNS/SQS • イベントでは無いもの • クリティカルなもの • 安全なバックエンド • (delayed_job) • クリティカルでは無いもの • 並列処理に問題がないバックエンド • (sidekiq)
- 98. おまけ
- 99. delayed_jobの障害対応 障害が起きてしまった場合は、 • 手動でDBの行の一部をファイルに書き出す • 書き出した行を削除 • queueの件数が減るのでまともに動く • queueが減ってきたら待避したのを戻す と、頑張れば何とかなります（つらい）
- 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. 会場Q&A