2018-12-17 Microservices Monday

south37 commented 5 years ago

2018-12-17 19:00~20:00

Microservices Mondayは、マイクロサービスに関連する話を気軽に共有する会です。毎週月曜日に開催されます。

社外からの参加を想定しているため、レポジトリはpublicになっています。

次のようなポリシーを掲げて開催しています。

事前の準備をがんばらない
途中参加・途中退席は自由
毎週やる

話したい・聞きたいネタを書いていきます ✏️

ネタに困ったときは

Kubecon/CloudNativeCon のリストを眺める
Microservice Weekly を眺める

ハッシュタグ #microservices_monday

south37 commented 5 years ago

etcd の cluster upgrade の話 by @potsbo

izumin5210 commented 5 years ago

「サービス間でDB共有するのはなんでダメなんだっけ」 by @Altech
ダメな実例はいくらでも挙げられるんだけど，本質的にだめな理由は？

c.f. https://microservices.io/patterns/data/database-per-service.html

discussion

- したくなる気持ちはわかる・最初は楽 - 設計的にはやめてほしい - インフラ視点 - 依存が複雑だと辛い・どこに影響があるのかわからない - 権限周り - どのテーブルを誰が使っているのか - アプリエンジニア視点 - マイグレーションするときにむずかしい - 変更の影響範囲わからん - ちゃんと設計すればなんないでしょｗ - 一方で，分散システム的なことを考えるとコストが高いよね - 実装もむずかしくなるよね - private なメソッドを外から呼んでいる気持ちになる - （直感的に）凝集性がさがりそう - なんでさがったらだめなんだっけ - → 分断されたモノリスになる https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f - 管理画面はどうなんだろう？ - bigquery は？ - （ログ基盤・解析用途的には）すべてが bigquery にあると非常に利便性が高い - アプリから直接読むんじゃなくて，アプリが読みやすい形に変形して使うイメージがある - ふつうの DB みたいに書いた瞬間に読むことはしない - 書いたデータをいつ読むかのタイムスパン - recommendation とか，バッチで計算してどこかにストアして… - 登録した瞬間に recommend したくなったら？ - https://okachimachiorz.hatenablog.com/entry/20180716/1531728760 - HTAP っていうアイデアがある - 「DB」の定義？ - 「自分たちが普段からテーブルだけでプログラミングをしているのか」冷静に考えてほしい - （WEB アプリケーションつくりはじめってほとんどDB周りの処理だよね） - enum とか computed attr 的なものとか - 保存前後のフックとか一貫性の担保とか - テーブルを共有しちゃうと↑みたいなのが書く意味なくなる - だって自分以外のサービスでは上記の「モデル」が反映されていない - 「振る舞い」をモデルに書かなくなる - → 複雑なものが作れなくなる - why :「特定の場所に積み重なっていく」ができない - e.g. プライバシー設定とかやばい - 人間の認知能力を考えると，規模が増えるたびに現実的じゃなくなっていく - from “Microservices Architecture” - 「DB共有だと振る舞いの共有に関して何もしないから変更のコストが高く、大量の回帰テストなどが必要になるので避けた方が良い」 - 変更容易性 - API に抽象化しておけば，あとからストレージを別の実装に差し替えられる - e.g. RDB → KVS, Graph DB - メソッドのリネームは簡単だけど，カラムのリネーム・ドロップは超大変 - DB がマイクロサービスとしてみなせるような機能があれば… - 実は read は共有してもいいのでは？ - 変更容易性的にはムリ - state を持ったりすると，実質読み込みにもロジックが存在することになる - キャッシュ - 「本来のデータ」がある - キャッシュを適切に管理するためには？ - read / write に intercept できる必要がある - パージしないと https://paper.dropbox.com/doc/DB--AT0gMPYIIGLfzgXQXKcVBnzsAQ-euSCUHP5LkwdbL5fIJO5S

south37 commented 5 years ago

マイクロサービスアーキテクチャの 4.3 章「共有データベース」でもDB共有のアンチパターンについて説明されてます。

ざっと読んでまとめると、「DB共有だと 振る舞いの共有 に関して何もしないから変更のコストが高く、大量の回帰テストなどが必要になるので避けた方が良い」と言っているように見える。

私や私の同僚がこの業界で目にする圧倒的に一般的な統合形態は、データベース（DB）統合です。この世界では、あるサービスが別のサービスからの情報を入手したい場合、データベースにアクセスします。また、情報を変更したい場合もデータベースにアクセスします。統合について初めて考えるときにはこの方法がとても簡単であり、手始めとしては最も高速な統合形態でしょう。おそらくその為にデータベースは人気があるのでしょう。。

図4-1は、データベースで直接 SQL 操作を実行して顧客を作成する登録UIを表しています。また、データベースで SQL を実行して顧客データの閲覧と編集を行うコールセンターアプリケーションも表しています。倉庫は、データベースをクエリして顧客注文に関する情報を更新します。これは十分に一般的なパターンですが、困難を伴います。

まず、外部の関係者が内部実装詳細を閲覧したり内部実装詳細に統合したりできるようにしています。DB に格納しているデータ構造は全てに対して公平です。データベースにアクセスできる他の全ての関係者とデータ構造全体を共有します。スキーマを変更してデータをさらに適切にデータを表現したり、システムを保守しやすくしたりすることにしたら、コンシューマを壊す可能性があります。DBは事実上とても大規模な共有 API で、かなり脆弱でもあります。。。<中略>通常、このような状況では大量の回帰テストが必要になります。

次に、コンシューマが特定の技術選択に縛られてしまいます。...<中略>すでに述べたように本当は実装の詳細をコンシューマから隠し、時間とともに内部がどのように変わってもサービスにある水準の自律性を持たせるようにしたいのです。疎結合よ、さようなら。

最後に、少しの間振る舞いについて考えてみましょう。顧客の変更方法に関するロジックがあるとしたら、そのロジックはどこにあるのでしょうか。コンシューマが DB を直接操作している場合には、コンシューマが関連するロジックを持たなければなりません。。。<中略>凝集性よ、さようなら。

以前触れた優れたマイクロサービスの背後にある主な原則を覚えているでしょうか。データベース統合では、強い凝集性と疎結合の両方を失います。データベース統合ではサービスがデータを共有しなくなりますが、 振る舞いの共有 に関して何も行いません。。。<中略>必然的に変更一つでも恐れをなすようになります。いかなる代償を払っても避けてください。

izumin5210 commented 5 years ago

microservices の非同期連携のはなし（まだちゃんとおってない） https://microservices.io//microservices/general/2018/11/08/mucon.html https://microservices.io/patterns/data/saga.html