Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

3 359 vues

Publié le

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

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

Publié dans : Ingénierie
  • Soyez le premier à commenter

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

  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/ – たぶん書きます…たぶん… このへんの話

×