マイクロサービスにおける結果整合性との戦い

ota42y
2018/08/30
microservice meetup 8
マイクロサービスにおける
結果整合性との戦い

• ota42y
• サーバサイドエンジニア
• rubyとかrustとかgoとかC++とか
• Twitter、github → ota42y
• 最近はサーバレスしたりGPUで遊んだり
ElasticSerachしたり色々…
自己紹介

• 技術書典4でマイクロサービス本を出した
– https://ota42y.com/blog/2018/04/10/mi
croservices_yorozu_book/
– 技術書典5で続きを出します
自己紹介

• 今回は次の本で書く内容のチラ見せ
– (訳: あとでちゃんとしたのを本にします…)
自己紹介

• Eventual Consistency
• 途中では整合性が崩れた状態に陥るが、
十分な時間がたったら最終的には整合
性がとれた状態になる
• 分散システムのBASEで語られる
• ACIDと対比されやすい概念
• ACIDは常に一貫した状態を保証する
結果整合性

• Eventual Consistency
• 途中では整合性が崩れた状態に陥るが、
十分な時間がたったら最終的には整合
性がとれた状態になる
• 分散システムのBASEで語られる
• ACIDと対比されやすい概念
• ACIDは常に一貫した状態を保証する
• マイクロサービスアーキテクチャは分散
システムの一種
結果整合性

イベントドリブンアーキテクチャ
• イベントベースで情報をやりとりするアーキテクチャ
• 送り手はイベントを起こすだけで受け手を知らない
• 受け手はイベントの監視だけで送り手を知らない
• 疎結合に組める

• 詳しくは過去の発表資料を…
• マイクロサービスにおける非同期アーキテクチ
• https://www.slideshare.net/ota42y/ss-
80254350
• Rails DMの動画も公開されました
• https://www.youtube.com/watch?v=amsQa
PIajqs

• トランザクションが必要なデータは発行もとで完結
• 購読者がそれを見て処理を行う
• 部分的には正しくない状態が起きる
• Lifelogで投稿したのにPointが”まだ”付いてない

• トランザクションが必要なデータは発行もとで完結
• 購読者がそれを見て処理を行う
• 部分的には正しくない状態が起きる
• Lifelogで投稿したのにPointが”まだ”付いてない
• 十分な時間がたてば各マイクロサービスのデータが
正しくなる
• 結果整合性

結果整合性を担保する

DBに保存
SNSにイベント送信

• ほかサービスへの送信に失敗した場合
Lifelog Ranking

ここで失敗

• リトライするべきかしないべきか
Lifelog Ranking

Lifelog Ranking
• リトライすると
• 送信に成功して結果を受け取れなかった場合に二重
に送ってしまう
data
data再送するよ〜
すでに処理済み…

• リトライしないと
• 送信自体に失敗した場合に整合性が合わなくなる
Lifelog Ranking
data

• リトライ可否を調べる場合
• 他のサービスのロジックを送り手側が把握しないと
いけない
• 受け手側も全ての部分で状態を調べ上げる必要性
Lifelog Ranking
data
Service B
Service A

• 送り手側が適切にリトライ処理を行うのは無理
• マイクロサービスの都合を全部把握するのは無理
• 受け手側でリトライされていても大丈夫に作るべき
• 何度実行されても大丈夫なようにする
• 冪等性
• 防御的なアプローチ

• 元々は数学用語
• 情報工学においては
• 何度同じ操作を行っても同じ結果になるもの
• data.append(1)
• 冪等ではない
• dataの要素が常に1づつ増えていく
• data.size
• 冪等
• data[0] = 1
• これも冪等
冪等性

冪等性万歳
• 同じデータでリトライしても大丈夫になる
• 失敗したら成功するまで常にリトライすれば良くなる
event
event
event
event
再送するよ〜
すでに処理中だけど2通目は無視

そう上手くはいかない

どうやって冪等性を担保するの？
ユーザの投稿(Post)にはデータとして冪等にするた
めのキーはない
関係ないカラムを加えるのはしたくない

ここで失敗
部分的なリトライ
transactionの外なのでロールバックされない
外から見たら失敗なので再実行する
失敗部分だけ再実行したいのにデータが増える

あらゆる所で保証する必要がある
• 冪等性に頼ってとりあえずリトライする方針
• 冪等でない場所があると整合性が崩れる
event
event
event
event
こっちは冪等
ここは冪等じゃないので…
event
とりあえず再送！

あらゆる所で保証する必要がある
• 冪等性に頼ってとりあえずリトライする方針
• 冪等でない場所があると整合性が崩れる
• 多段になってるとマジヤバイ
• 気軽に冪等にできないとつらい
event
event
event
event
event
event
event
event

とりあえずの解決策
• idempotent_transaction
• https://github.com/ota42y/idempotent_transac
tion
• Unique keyを使って冪等性を担保する

• やってることは簡単
• Unique Keyを持ったテーブルと一緒にトランザク
ションしているだけ
• 任意のテーブルに冪統制を簡単に紐付けられる
• Unique Indexを工夫すればパフォーマンスは大丈夫
…Aurora様なら…

ここの間は1回しか保存されない
ここは何度も実行されるが
受け手側で冪等になればOK

未解決の問題が
• 実行したかどうかをDBに保存している
• selectが純粋に1回増える
• Indexは効くが数が増えるとDBが辛そう
• redisにキャッシュすると今度はトランザクションと
状態を合わせるのがつらい
• ロールバックorコミット中にredisが死んだら…
• そもそもまだ整合性を担保できてない
• 非同期処理の順序問題…
• 結果整合性を受け手が満たせない場合どうすんの？
• サーバ超えてトランザクション維持したいときあるよね

• 技術書典5のマイクロサービス本に書く
– https://ota42y.com/blog/2018/04/10/mi
croservices_yorozu_book/
– たぶん書きます…たぶん…
このへんの話

マイクロサービスにおける結果整合性との戦い

More Related Content