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

ota42y
2017/09/28
Rails Developers Meetup #5
マイクロサービスにおける
非同期アーキテクチャ

• ota42y
• ゲームクライアントエンジニア
→サーバエンジニアに転職(1年ぐらい前)
• rubyとかgoとかC++とか
• twitterとかgithubとか
自己紹介

• twitter凍結したらこちらへ
– https://ota42y.com/
– ネタとして入れたら今朝になって現実味が…
あとでツイート全削除かな…
–
凍結されそう

• 外から見たときは一つのアプリ
• 内部的にはドメイン事に別々のサーバ
microservice
ダイエット家庭教師
FiNCモール
FiNC アプリ
lifelog 法人向けchat
ranking main

• 各サーバは独立しており、API経由で連携
• 非同期に連携処理も多数含まれる
• 巨大かつ複雑になりやすい→知見
microservice
FiNCモール
FiNC アプリ
ranking main

処理の完了を待たずに次の処理を実行し、
メインの流れとは別にその処理が進行する
今回の文脈では待ち時間を減らすためにす
ぐレスポンスを返し、別プロセス等で処理
非同期処理

今回は特にJob Queueの話
Mail
Server
Rails
user

Mail
Server
Rails
user
Oh！

Mail
Server
Rails
user
Slowly…

Mail
Server
Rails
user
Queue

Mail
Server
Rails
user
Queue
Fast！

Mail
Server
Rails
user
Worker
Queue

Mail
Server
Rails
user
Worker
Queue
Oh！

Rails
Queue
Job Queueを抽象化したActiveJobは
Railsに標準搭載
Rails環境での非同期処理では一般的な構成

• microserviceでは非同期処理を多用する
• 非同期処理の移り変わりとともに紹介
microservice
FiNCモール
FiNC アプリ
ranking main

牧歌的時代
〜何でもdelayed_jobに突っ込む〜

delayed_job
https://github.com/collectiveidea/delay
ed_job
Railsで最も簡単に導入できるJob Queue

delayed_job
https://github.com/collectiveidea/delay
ed_job
• RDBのテーブルをQueueとして使う
• 1 job=1 recordとして保存する
• RDB以外を用意・運用する必要無い(redisとか)
• 優先度や時刻指定など一通りの機能がある
• RDBに書き込むのでJobは永続化される
FiNCでは最初期から採用

delayed_job
delayメソッドに続けて本来のメソッドを呼ぶだけ
• 関連する情報がシリアライズされてDBへ
• workerがデータを取り出して復元・実行

🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥
🔥🔥🔥突然の大障害🔥🔥🔥
🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥

delayed_jobが遅くなる
アプリのメインのサービスで障害が…
delayed_jobがjobを実行するのが急激に遅くなる
queueが処理されずにどんどん積まれていく
1時間たっても非同期処理が実行されず、
先に進めなくなるユーザや表示が変に…

delayed_jobが遅くなる
delayed_jobではjobの同時実行を防ぐ機構がある
制御用カラムにworkerの識別子を書き、
カラムのupdateに成功(=実行権の取得)
した場合に処理を実行し、同時実行を防いでいる

MySQLの例
こんなupdate文で実行権を取得して処理を実行
(delayed_jobに:optimized_sql を設定した場合)

MySQLの例
実行可能なjobの中で、最も優先度の高いやつ1つ
に対して自分の識別子をupdate
成功したら実行権を取得したとしてjobを実行する
他workerが実行権を得るとwhere句から外れる
そのため、実行権を重複して得ることはない

地獄への急行列車
indexが効かないwhere句の絞り込み&ソート
→テーブルロック

indexが効かないwhere句の絞り込み&ソート
→テーブルロック
whereの条件は、queueのだいたい全部が対象
(未実行のqueueが対象なので)
→未実行jobが増えるとupdate時間が延びる
→実行権取得に時間がかかり、処理速度の低下

処理速度が低下し処理速度 < 増加速度になる
→未実行jobが増加しさらに処理速度が遅く
→無限に遅くなる負のループに

処理のほとんどがupdate待ち
→並列数を増やしても待ってるworker増えるだけ

処理のほとんどがupdate待ち
→並列数を増やしても待ってるworker増えるだけ
よって打つ手がなくなる

最大のボトルネックに
新規ユーザ登録や既存ユーザの行動に応じて、
非同期のjobが作られる
→ユーザ数が増えるとjobが詰まりやすくなる

最大のボトルネックに
新規ユーザ登録や既存ユーザの行動に応じて、
非同期のjobが作られる
→ユーザ数が増えるとjobが詰まりやすくなる
サービスが成長すると障害が起きる

😱なんとかせねば😱
その場は緊急対応で乗り切った

非同期処理の整理
何も考えずにdelayしていたので、
そもそもdelayを使って何をしているかを整理

非同期処理の整理
何も考えずにdelayしていたので、
そもそもdelayを使って何をしているかを整理
• 巨大な処理
対象データが多い
複雑な処理をしている
• 複数サービスとのデータ連携

巨大な処理
クリティカルかどうかで場合分け
• クリティカル
• ユーザ作成時の初期化処理
• 再実行が難しい処理
• クリティカルではないもの
• フォロー数の再計算
• 検索用キャッシュのアップデート
• 簡単に再実行可能なやつ

巨大な処理
重要度に応じて処理わけ
• クリティカル
• 信頼度が重要なので引き続きdelayed_job
• クリティカルではないもの
• 後からの再実行が容易
• 基本的に別バックエンドへ移動
• delayed_jobのjob数を減らす

バックエンド選定
delayed_jobからの変更先を選定
gemの安定度や経験等を元に以下の2つが候補に
• sidekiq
• resque

sidekiq
redisをバックエンドに使うJob Queue
• スレッドベース
• redisなので並列度は上げやすい
• リトライ機構あり
他のmicroserviceで採用していたり、
社内に経験者がいる的なのでこれ

sidekiq
移動が簡単で、大量にjobが発行されるものから
sidekiqを利用するように変更していく
たまたまActiveJobを使っていなかったので、
delayed_jobをActiveJob(+sidekiq)に書き換える
(手動で1つずつ)

ここまでのまとめ
• 巨大な処理
• クリティカルなもの
• 安全なバックエンド ( delayed_job )
• クリティカルでは無いもの
• 並列処理に問題がないもの( sidekiq )
• delayed_jobのjob数増加を抑える
• 複数サービスへの連携

イベントアーキテクチャ時代

ここからの話
• 巨大な処理
• 安全なバックエンド ( delayed_job )
• 並列処理に問題がないもの( sidekiq )
• delayed_jobのjob数増加を抑える
• 複数サービスへの連携

複数サービスへの連携
microserviceではあるサーバの変更に対応して、
別サーバが対応する処理を行うことが頻繁にある
FiNCモール
FiNC アプリ
ranking main

microserviceではあるサーバの変更に対応して、
別サーバが対応する処理を行うことが頻繁にある

更新時に他サービスに何をさせれば良いのか？
を更新側が知る必要があり、結合度が高い

やってることの図解
Lifelog Ranking
StepsCampaign
Point
Steps
Update

イベント駆動アーキテクチャ
これはどうもイベント駆動アーキテクチャっぽい
クライアントがリクエストを発
行して処理を依頼する代わりに、
クライアントがある事態が起
こったことを通知し、他者が何
をすべきかを知っていることを
期待します。他の誰かに何をす
べきかを指示することは決して
ありません。
Sam Newman著,佐藤直生監訳,木下哲也訳(2006)『マイクロサービスアーキテクチャ』,オライリージャパン.

Lifelog
Steps
Update
Event
• 条件を満たすと対応するEventを送信

Lifelog Ranking
StepsCampaign
Point
Steps
Update
Event
• 受け取り側はEventを受信したら処理する

Lifelog Ranking
StepsCampaign
Point
Steps
Update
Event
• 受け取り側はEventを受信したら処理する
送信側と受信側の結合度が減る

イベント送信
AWSのSNS(Simple Notification Service)を利用
(Pub/Subメッセージングしてくれるサービス)
送る側はSNSにデータを送るだけ
Lifelog
AWS SNSSteps
Update

イベント受信
AWSのSQS(Simple Queue Service)を利用
(簡単なqueueシステム)
Lifelog Ranking
AWS SNS AWS SQSSteps
Update

イベント受信
AWSのSQS(Simple Queue Service)を利用
(簡単なqueueシステム)
SNSをsubscribeすると、
eventがキューにコピーされる
Lifelog Ranking
AWS SNS AWS SQS
Steps
Update

イベント受信
SNSは複数のSQSに同時にコピーしてくれる
各サービスは自分のSQSを作り、SNSをsubscribe
Lifelog Ranking
Point
AWS SNS
AWS SQS
Steps
Update
Steps
Update

イベント受信
あらたにeventを受け取りたい場合も、
SNSをsubscribeすれば良く、送信側の変更は不要
Lifelog Ranking
StepsCampaign
Point
AWS SNS
AWS SQS

性能も良い
SQSは
• 大量にキューを積んでも遅くならない
• 意図的に消さない限り消えない
ので安心ヽ(・∀・)ノ

性能も良い
SQSは
• 大量にキューを積んでも遅くならない
• 意図的に消さない限り消えない
ので安心ヽ(・∀・)ノ
一度10万ぐらいjobを積んだけど、
並列度は簡単に増やせるので大丈夫だった
(delayed_jobなら死んでた)

🍺🍺🍺優勝🍺🍺🍺

SNS/SQSには癖がある
• 冪等である必要がある
• SQSは1回以上取り出す事を保証
• 同じjobが2回実行される場合がある
• 実行済みの時、並列実行の時に気をつける
• 従量課金
• 送ったデータ数・サイズ課金
• 大量に送りまくる使い方だと課金死

SNS/SQSには癖がある
• SNSが遅い
• 同リージョンで40msぐらいかかる
• delayed_jobやsidekiqと比べると遅い
• もっと早いという噂も聞くので設定かも
• 依存設定がAWSのコンソールに集中
• 変更履歴無い
• 依存関係がわかりにくい

統一フォーマットが必要
自由に送るとフォーマットが違って実装が大変
ある程度フォーマットを決めてやりとり
FiNCモール
FiNC アプリ
ranking main

統一フォーマットが必要
こんな感じのフォーマットを決めて運用

両方移行しないといけない
良さそうだがmicroservice間の通信の事なので、
送信側・受信側共に移行する必要がある
Lifelog Ranking
AWS SNS AWS SQS

両方移行しないといけない
良さそうだがmicroservice間の通信の事なので、
送信側・受信側共に移行する必要がある
→簡単に移行できないとみんな移行しない
Lifelog Ranking
AWS SNS AWS SQS

やりとりはgem化
移行を楽にするために
• SNSへ送信
• SQSから取得
• イベントのフォーマット統一
のためのgemを作った
https://github.com/ota42y/rising_dragon

やりとりはgem化
移行を楽にするために
• SNSへ送信
• SQSから取得
• イベントのフォーマット統一
のためのgemを作った
https://github.com/ota42y/rising_dragon
Lifelog Ranking
AWS SNS AWS SQS
Steps
Update

欠点 <<< 利点
気をつける所はあるが、利点の方が大きい
マイクロサービスではかなり良いアーキテクチャ
癖に対してもいくつか対応中
• イベントをまとめて送りSNS/SQSの費用削減
• AWSの情報を元に依存関係の見える化サービス
• 設定ファイルからSNS/SQSの自動設定

まとめ
非同期処理はサーバでは超重要
FiNCでは処理に応じてバックエンドを使い分ける
適切に使い分けると特製をうまく使えてべんり

まとめ
• イベントっぽいもの
• イベント駆動アーキテクチャ
• SNS/SQS
• イベントでは無いもの
• 安全なバックエンド
• (delayed_job)
• 並列処理に問題がないバックエンド
• (sidekiq)

delayed_jobの障害対応
障害が起きてしまった場合は、
• 手動でDBの行の一部をファイルに書き出す
• 書き出した行を削除
• queueの件数が減るのでまともに動く
• queueが減ってきたら待避したのを戻す
と、頑張れば何とかなります（つらい）

delayed_jobいつまで使うの
いちおうdelayed_jobと使い分けています
サービスが1000万ユーザとかになった場合、
delayed_jobの障害が簡単に起きる状態になる
なので最終的には全て捨てる事になりそう…
(当面は併用が続く)

どこまでイベントにするか
イベントはいつ実行されるか確実ではない
同期的に実行したい場合は、
event/sidekiqは使えないので普通にHTTP通信

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にまだ来てなかった）

キューの分け方どうしてます
Q.
キューをどういう基準で使い分けているか？
A.
ほとんど分けずに一つのキューにしている
1分の処理も1秒の処理も同じキュー
そっちの方がリソース管理が容易
毎秒数100積まれるようなものがあり、
そういった問題がありそうなものだけ別キュー

AWS Batch
Q.
AWS Batchという選択肢は…？
A.
この問題を早急に直さないとサービス止まりまく
るので、最小限の変更ですむような解決法にした
一段落したのでそういったものは検討している

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

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

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

More from ota42y

More from ota42y (11)

Recently uploaded

Recently uploaded (7)