Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

マイクロサービスにおける 非同期アーキテクチャ

41,402 views

Published on

Rails Developers Meetup #5
https://techplay.jp/event/631406

Published in: Engineering
  • Be the first to comment

マイクロサービスにおける 非同期アーキテクチャ

  1. 1. ota42y 2017/09/28 Rails Developers Meetup #5 マイクロサービスにおける 非同期アーキテクチャ
  2. 2. • ota42y • ゲームクライアントエンジニア →サーバエンジニアに転職(1年ぐらい前) • rubyとかgoとかC++とか • twitterとかgithubとか 自己紹介
  3. 3. • twitter凍結したらこちらへ – https://ota42y.com/ – ネタとして入れたら今朝になって現実味が… あとでツイート全削除かな… – 凍結されそう
  4. 4. • 外から見たときは一つのアプリ • 内部的にはドメイン事に別々のサーバ microservice ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
  5. 5. • 各サーバは独立しており、API経由で連携 • 非同期に連携処理も多数含まれる • 巨大かつ複雑になりやすい→知見 microservice ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
  6. 6. 処理の完了を待たずに次の処理を実行し、 メインの流れとは別にその処理が進行する 今回の文脈では待ち時間を減らすためにす ぐレスポンスを返し、別プロセス等で処理 非同期処理
  7. 7. 今回は特にJob Queueの話 Mail Server Rails user
  8. 8. 今回は特にJob Queueの話 Mail Server Rails user
  9. 9. 今回は特にJob Queueの話 Mail Server Rails user
  10. 10. 今回は特にJob Queueの話 Mail Server Rails user
  11. 11. 今回は特にJob Queueの話 Mail Server Rails user Oh!
  12. 12. 今回は特にJob Queueの話 Mail Server Rails user
  13. 13. 今回は特にJob Queueの話 Mail Server Rails user Slowly…
  14. 14. 今回は特にJob Queueの話 Mail Server Rails user Queue
  15. 15. 今回は特にJob Queueの話 Mail Server Rails user Queue
  16. 16. 今回は特にJob Queueの話 Mail Server Rails user Queue
  17. 17. 今回は特にJob Queueの話 Mail Server Rails user Queue Fast!
  18. 18. 今回は特にJob Queueの話 Mail Server Rails user Queue
  19. 19. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue
  20. 20. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue
  21. 21. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue
  22. 22. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue
  23. 23. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue
  24. 24. 今回は特にJob Queueの話 Mail Server Rails user Worker Queue Oh!
  25. 25. 今回は特にJob Queueの話 Rails Queue Job Queueを抽象化したActiveJobは Railsに標準搭載 Rails環境での非同期処理では一般的な構成
  26. 26. • microserviceでは非同期処理を多用する • 非同期処理の移り変わりとともに紹介 microservice ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
  27. 27. 牧歌的時代 〜何でもdelayed_jobに突っ込む〜
  28. 28. delayed_job https://github.com/collectiveidea/delay ed_job Railsで最も簡単に導入できるJob Queue
  29. 29. delayed_job https://github.com/collectiveidea/delay ed_job • RDBのテーブルをQueueとして使う • 1 job=1 recordとして保存する • RDB以外を用意・運用する必要無い(redisとか) • 優先度や時刻指定など一通りの機能がある • RDBに書き込むのでJobは永続化される FiNCでは最初期から採用
  30. 30. delayed_job delayメソッドに続けて本来のメソッドを呼ぶだけ • 関連する情報がシリアライズされてDBへ • workerがデータを取り出して復元・実行
  31. 31. 便利(o゜▽゜)
  32. 32. しかしある日…
  33. 33. 🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥 🔥🔥🔥突然の大障害🔥🔥🔥 🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
  34. 34. delayed_jobが遅くなる アプリのメインのサービスで障害が… delayed_jobがjobを実行するのが急激に遅くなる queueが処理されずにどんどん積まれていく 1時間たっても非同期処理が実行されず、 先に進めなくなるユーザや表示が変に…
  35. 35. \(^o^)/
  36. 36. delayed_jobが遅くなる delayed_jobではjobの同時実行を防ぐ機構がある 制御用カラムにworkerの識別子を書き、 カラムのupdateに成功(=実行権の取得) した場合に処理を実行し、同時実行を防いでいる
  37. 37. MySQLの例 こんなupdate文で実行権を取得して処理を実行 (delayed_jobに:optimized_sql を設定した場合)
  38. 38. MySQLの例 実行可能なjobの中で、最も優先度の高いやつ1つ に対して自分の識別子をupdate 成功したら実行権を取得したとしてjobを実行する 他workerが実行権を得るとwhere句から外れる そのため、実行権を重複して得ることはない
  39. 39. 地獄への急行列車 indexが効かないwhere句の絞り込み&ソート →テーブルロック
  40. 40. 地獄への急行列車 indexが効かないwhere句の絞り込み&ソート →テーブルロック whereの条件は、queueのだいたい全部が対象 (未実行のqueueが対象なので) →未実行jobが増えるとupdate時間が延びる →実行権取得に時間がかかり、処理速度の低下
  41. 41. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに
  42. 42. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ
  43. 43. 地獄への急行列車 処理速度が低下し 処理速度 < 増加速度 になる →未実行jobが増加しさらに処理速度が遅く →無限に遅くなる負のループに 処理のほとんどがupdate待ち →並列数を増やしても待ってるworker増えるだけ よって打つ手がなくなる
  44. 44. 😇 😇 😇
  45. 45. 最大のボトルネックに 新規ユーザ登録や既存ユーザの行動に応じて、 非同期のjobが作られる →ユーザ数が増えるとjobが詰まりやすくなる
  46. 46. 最大のボトルネックに 新規ユーザ登録や既存ユーザの行動に応じて、 非同期のjobが作られる →ユーザ数が増えるとjobが詰まりやすくなる サービスが成長すると障害が起きる
  47. 47. 😱なんとかせねば😱 その場は緊急対応で乗り切った
  48. 48. 大移行時代
  49. 49. 非同期処理の整理 何も考えずにdelayしていたので、 そもそもdelayを使って何をしているかを整理
  50. 50. 非同期処理の整理 何も考えずにdelayしていたので、 そもそもdelayを使って何をしているかを整理 • 巨大な処理 対象データが多い 複雑な処理をしている • 複数サービスとのデータ連携
  51. 51. 非同期処理の整理 何も考えずにdelayしていたので、 そもそもdelayを使って何をしているかを整理 • 巨大な処理 対象データが多い 複雑な処理をしている • 複数サービスとのデータ連携
  52. 52. 巨大な処理
  53. 53. 巨大な処理 クリティカルかどうかで場合分け • クリティカル • ユーザ作成時の初期化処理 • 再実行が難しい処理 • クリティカルではないもの • フォロー数の再計算 • 検索用キャッシュのアップデート • 簡単に再実行可能なやつ
  54. 54. 巨大な処理 重要度に応じて処理わけ • クリティカル • 信頼度が重要なので引き続きdelayed_job • クリティカルではないもの • 後からの再実行が容易 • 基本的に別バックエンドへ移動 • delayed_jobのjob数を減らす
  55. 55. バックエンド選定 delayed_jobからの変更先を選定 gemの安定度や経験等を元に以下の2つが候補に • sidekiq • resque
  56. 56. バックエンド選定 delayed_jobからの変更先を選定 gemの安定度や経験等を元に以下の2つが候補に • sidekiq • resque
  57. 57. sidekiq redisをバックエンドに使うJob Queue • スレッドベース • redisなので並列度は上げやすい • リトライ機構あり 他のmicroserviceで採用していたり、 社内に経験者がいる的なのでこれ
  58. 58. sidekiq 移動が簡単で、大量にjobが発行されるものから sidekiqを利用するように変更していく たまたまActiveJobを使っていなかったので、 delayed_jobをActiveJob(+sidekiq)に書き換える (手動で1つずつ)
  59. 59. 😆
  60. 60. ここまでのまとめ • 巨大な処理 • クリティカルなもの • 安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
  61. 61. イベントアーキテクチャ時代
  62. 62. ここからの話 • 巨大な処理 • クリティカルなもの • 安全なバックエンド ( delayed_job ) • クリティカルでは無いもの • 並列処理に問題がないもの( sidekiq ) • delayed_jobのjob数増加を抑える • 複数サービスへの連携
  63. 63. 複数サービスへの連携 microserviceではあるサーバの変更に対応して、 別サーバが対応する処理を行うことが頻繁にある ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
  64. 64. 複数サービスへの連携 microserviceではあるサーバの変更に対応して、 別サーバが対応する処理を行うことが頻繁にある
  65. 65. 複数サービスへの連携 更新時に他サービスに何をさせれば良いのか? を更新側が知る必要があり、結合度が高い
  66. 66. 🤔
  67. 67. やってることの図解 Lifelog Ranking StepsCampaign Point Steps Update
  68. 68. イベント駆動アーキテクチャ これはどうもイベント駆動アーキテクチャっぽい クライアントがリクエストを発 行して処理を依頼する代わりに、 クライアントがある事態が起 こったことを通知し、他者が何 をすべきかを知っていることを 期待します。他の誰かに何をす べきかを指示することは決して ありません。 Sam Newman著,佐藤直生監訳,木下哲也訳(2006)『マイクロサービスアーキテクチャ』,オライリージャパン.
  69. 69. 複数サービスへの連携 Lifelog Steps Update Event • 条件を満たすと対応するEventを送信
  70. 70. 複数サービスへの連携 Lifelog Ranking StepsCampaign Point Steps Update Event • 条件を満たすと対応するEventを送信 • 受け取り側はEventを受信したら処理する
  71. 71. 複数サービスへの連携 Lifelog Ranking StepsCampaign Point Steps Update Event • 条件を満たすと対応するEventを送信 • 受け取り側はEventを受信したら処理する 送信側と受信側の結合度が減る
  72. 72. 良さそう(o゜▽゜)
  73. 73. 具体的な内容
  74. 74. イベント送信 AWSのSNS(Simple Notification Service)を利用 (Pub/Subメッセージングしてくれるサービス) 送る側はSNSにデータを送るだけ Lifelog AWS SNSSteps Update
  75. 75. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) Lifelog Ranking AWS SNS AWS SQSSteps Update
  76. 76. イベント受信 AWSのSQS(Simple Queue Service)を利用 (簡単なqueueシステム) SNSをsubscribeすると、 eventがキューにコピーされる Lifelog Ranking AWS SNS AWS SQS Steps Update
  77. 77. イベント受信 SNSは複数のSQSに同時にコピーしてくれる 各サービスは自分のSQSを作り、SNSをsubscribe Lifelog Ranking Point AWS SNS AWS SQS Steps Update Steps Update
  78. 78. イベント受信 あらたにeventを受け取りたい場合も、 SNSをsubscribeすれば良く、送信側の変更は不要 Lifelog Ranking StepsCampaign Point AWS SNS AWS SQS
  79. 79. 性能も良い SQSは • 大量にキューを積んでも遅くならない • 意図的に消さない限り消えない ので安心ヽ(・∀・)ノ
  80. 80. 性能も良い SQSは • 大量にキューを積んでも遅くならない • 意図的に消さない限り消えない ので安心ヽ(・∀・)ノ 一度10万ぐらいjobを積んだけど、 並列度は簡単に増やせるので大丈夫だった (delayed_jobなら死んでた)
  81. 81. 🍺🍺🍺優勝🍺🍺🍺
  82. 82.
  83. 83. SNS/SQSには癖がある • 冪等である必要がある • SQSは1回以上取り出す事を保証 • 同じjobが2回実行される場合がある • 実行済みの時、並列実行の時に気をつける • 従量課金 • 送ったデータ数・サイズ課金 • 大量に送りまくる使い方だと課金死
  84. 84. SNS/SQSには癖がある • SNSが遅い • 同リージョンで40msぐらいかかる • delayed_jobやsidekiqと比べると遅い • もっと早いという噂も聞くので設定かも • 依存設定がAWSのコンソールに集中 • 変更履歴無い • 依存関係がわかりにくい
  85. 85. 統一フォーマットが必要 自由に送るとフォーマットが違って実装が大変 ある程度フォーマットを決めてやりとり ダイエット家庭教師 FiNCモール FiNC アプリ lifelog 法人向けchat ranking main
  86. 86. 統一フォーマットが必要 こんな感じのフォーマットを決めて運用
  87. 87. 両方移行しないといけない 良さそうだがmicroservice間の通信の事なので、 送信側・受信側共に移行する必要がある Lifelog Ranking AWS SNS AWS SQS
  88. 88. 両方移行しないといけない 良さそうだがmicroservice間の通信の事なので、 送信側・受信側共に移行する必要がある →簡単に移行できないとみんな移行しない Lifelog Ranking AWS SNS AWS SQS
  89. 89. やりとりはgem化 移行を楽にするために • SNSへ送信 • SQSから取得 • イベントのフォーマット統一 のためのgemを作った https://github.com/ota42y/rising_dragon
  90. 90. やりとりはgem化 移行を楽にするために • SNSへ送信 • SQSから取得 • イベントのフォーマット統一 のためのgemを作った https://github.com/ota42y/rising_dragon Lifelog Ranking AWS SNS AWS SQS Steps Update
  91. 91. 欠点 <<< 利点 気をつける所はあるが、利点の方が大きい マイクロサービスではかなり良いアーキテクチャ 癖に対してもいくつか対応中 • イベントをまとめて送りSNS/SQSの費用削減 • AWSの情報を元に依存関係の見える化サービス • 設定ファイルからSNS/SQSの自動設定
  92. 92. まとめ 非同期処理はサーバでは超重要 FiNCでは処理に応じてバックエンドを使い分ける 適切に使い分けると特製をうまく使えてべんり
  93. 93. まとめ • イベントっぽいもの • イベント駆動アーキテクチャ • SNS/SQS • イベントでは無いもの • クリティカルなもの • 安全なバックエンド • (delayed_job) • クリティカルでは無いもの • 並列処理に問題がないバックエンド • (sidekiq)
  94. 94. おまけ
  95. 95. delayed_jobの障害対応 障害が起きてしまった場合は、 • 手動でDBの行の一部をファイルに書き出す • 書き出した行を削除 • queueの件数が減るのでまともに動く • queueが減ってきたら待避したのを戻す と、頑張れば何とかなります(つらい)
  96. 96. delayed_jobいつまで使うの いちおうdelayed_jobと使い分けています サービスが1000万ユーザとかになった場合、 delayed_jobの障害が簡単に起きる状態になる なので最終的には全て捨てる事になりそう… (当面は併用が続く)
  97. 97. どこまでイベントにするか イベントはいつ実行されるか確実ではない 同期的に実行したい場合は、 event/sidekiqは使えないので普通にHTTP通信
  98. 98. 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にまだ来てなかった)
  99. 99. 会場Q&A
  100. 100. キューの分け方どうしてます Q. キューをどういう基準で使い分けているか? A. ほとんど分けずに一つのキューにしている 1分の処理も1秒の処理も同じキュー そっちの方がリソース管理が容易 毎秒数100積まれるようなものがあり、 そういった問題がありそうなものだけ別キュー
  101. 101. AWS Batch Q. AWS Batchという選択肢は…? A. この問題を早急に直さないとサービス止まりまく るので、最小限の変更ですむような解決法にした 一段落したのでそういったものは検討している

×