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.

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

6,870 views

Published on

Microservices Meetup vol.8 Lightning Talks Battle!
で話した内容です

https://microservices-meetup.connpass.com/event/99190/

Published in: Engineering
  • Be the first to comment

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

  1. 1. ota42y 2018/08/30 microservice meetup 8 マイクロサービスにおける 結果整合性との戦い
  2. 2. • ota42y • サーバサイドエンジニア • rubyとかrustとかgoとかC++とか • Twitter、github → ota42y • 最近はサーバレスしたりGPUで遊んだり ElasticSerachしたり色々… 自己紹介
  3. 3. • 技術書典4でマイクロサービス本を出した – https://ota42y.com/blog/2018/04/10/mi croservices_yorozu_book/ – 技術書典5で続きを出します 自己紹介
  4. 4. • 今回は次の本で書く内容のチラ見せ – (訳: あとでちゃんとしたのを本にします…) 自己紹介
  5. 5. 結果整合性
  6. 6. • Eventual Consistency • 途中では整合性が崩れた状態に陥るが、 十分な時間がたったら最終的には整合 性がとれた状態になる • 分散システムのBASEで語られる • ACIDと対比されやすい概念 • ACIDは常に一貫した状態を保証する 結果整合性
  7. 7. • Eventual Consistency • 途中では整合性が崩れた状態に陥るが、 十分な時間がたったら最終的には整合 性がとれた状態になる • 分散システムのBASEで語られる • ACIDと対比されやすい概念 • ACIDは常に一貫した状態を保証する • マイクロサービスアーキテクチャは分散 システムの一種 結果整合性
  8. 8. イベントドリブンアーキテクチャ • イベントベースで情報をやりとりするアーキテクチャ • 送り手はイベントを起こすだけで受け手を知らない • 受け手はイベントの監視だけで送り手を知らない • 疎結合に組める
  9. 9. • 詳しくは過去の発表資料を… • マイクロサービスにおける 非同期アーキテクチ • https://www.slideshare.net/ota42y/ss- 80254350 • Rails DMの動画も公開されました • https://www.youtube.com/watch?v=amsQa PIajqs イベントドリブンアーキテクチャ
  10. 10. イベントドリブンアーキテクチャ • トランザクションが必要なデータは発行もとで完結 • 購読者がそれを見て処理を行う • 部分的には正しくない状態が起きる • Lifelogで投稿したのにPointが”まだ”付いてない
  11. 11. イベントドリブンアーキテクチャ • トランザクションが必要なデータは発行もとで完結 • 購読者がそれを見て処理を行う • 部分的には正しくない状態が起きる • Lifelogで投稿したのにPointが”まだ”付いてない • 十分な時間がたてば各マイクロサービスのデータが 正しくなる • 結果整合性
  12. 12. 結果整合性を担保する
  13. 13. DBに保存 SNSにイベント送信 結果整合性を担保する
  14. 14. 結果整合性を担保する • ほかサービスへの送信に失敗した場合 Lifelog Ranking
  15. 15. ここで失敗 結果整合性を担保する
  16. 16. 結果整合性を担保する • リトライするべきかしないべきか Lifelog Ranking
  17. 17. Lifelog Ranking 結果整合性を担保する • リトライするべきかしないべきか • リトライすると • 送信に成功して結果を受け取れなかった場合に二重 に送ってしまう data data再送するよ〜 すでに処理済み…
  18. 18. 結果整合性を担保する • リトライするべきかしないべきか • リトライしないと • 送信自体に失敗した場合に整合性が合わなくなる Lifelog Ranking data
  19. 19. 結果整合性を担保する • リトライ可否を調べる場合 • 他のサービスのロジックを送り手側が把握しないと いけない • 受け手側も全ての部分で状態を調べ上げる必要性 Lifelog Ranking data Service B Service A
  20. 20. 結果整合性を担保する • 送り手側が適切にリトライ処理を行うのは無理 • マイクロサービスの都合を全部把握するのは無理 • 受け手側でリトライされていても大丈夫に作るべき • 何度実行されても大丈夫なようにする • 冪等性 • 防御的なアプローチ
  21. 21. つらい…
  22. 22. 冪等性
  23. 23. • 元々は数学用語 • 情報工学においては • 何度同じ操作を行っても同じ結果になるもの • data.append(1) • 冪等ではない • dataの要素が常に1づつ増えていく • data.size • 冪等 • data[0] = 1 • これも冪等 冪等性
  24. 24. 冪等性万歳 • 同じデータでリトライしても大丈夫になる • 失敗したら成功するまで常にリトライすれば良くなる event event event event 再送するよ〜 すでに処理中だけど2通目は無視
  25. 25. (o゜▽゜)
  26. 26. そう上手くはいかない
  27. 27. どうやって冪等性を担保するの? ユーザの投稿(Post)にはデータとして冪等にするた めのキーはない 関係ないカラムを加えるのはしたくない
  28. 28. ここで失敗 部分的なリトライ transactionの外なのでロールバックされない 外から見たら失敗なので再実行する 失敗部分だけ再実行したいのにデータが増える
  29. 29. あらゆる所で保証する必要がある • 冪等性に頼ってとりあえずリトライする方針 • 冪等でない場所があると整合性が崩れる event event event event こっちは冪等 ここは冪等じゃないので… event とりあえず再送!
  30. 30. あらゆる所で保証する必要がある • 冪等性に頼ってとりあえずリトライする方針 • 冪等でない場所があると整合性が崩れる • 多段になってるとマジヤバイ • 気軽に冪等にできないとつらい event event event event event event event event
  31. 31. つらいわ…
  32. 32. とりあえずの解決策 • idempotent_transaction • https://github.com/ota42y/idempotent_transac tion • Unique keyを使って冪等性を担保する
  33. 33. とりあえずの解決策 • やってることは簡単 • Unique Keyを持ったテーブルと一緒にトランザク ションしているだけ • 任意のテーブルに冪統制を簡単に紐付けられる • Unique Indexを工夫すればパフォーマンスは大丈夫 …Aurora様なら…
  34. 34. とりあえずの解決策 ここの間は1回しか保存されない ここは何度も実行されるが 受け手側で冪等になればOK
  35. 35. 未解決の問題が • 実行したかどうかをDBに保存している • selectが純粋に1回増える • Indexは効くが数が増えるとDBが辛そう • redisにキャッシュすると今度はトランザクションと 状態を合わせるのがつらい • ロールバックorコミット中にredisが死んだら… • そもそもまだ整合性を担保できてない • 非同期処理の順序問題… • 結果整合性を受け手が満たせない場合どうすんの? • サーバ超えてトランザクション維持したいときあるよね
  36. 36. • 技術書典5のマイクロサービス本に書く – https://ota42y.com/blog/2018/04/10/mi croservices_yorozu_book/ – たぶん書きます…たぶん… このへんの話

×