マイクロサービスに関するメモ２
前回の続き
モノリスの分解方法
- そもそも分解するべきか
- 分解する場合
- コードの改修するときの御作法。うまく動作しない時に戻せるように修正しようよ。
- 新しいサービス用のプロキシ作ってそれだけでまずデプロイして確認する。
- 移行する範囲は変更を許可しないことが楽。そのためにも、小さく移行を進めようね。
- フロントでもUI合成などで、一部ずつ移行することが可能。
- フィーチャブランチでなく、抽象ブランチを使う。（わかるようなわからんような。。）
- 新しいサービスの機能とモノリスの機能を両方使い、新しいサービスの機能を検証したり、システム全体の機能を増やすという手もある。
- モノリスは変更しないで、モノリスとクライアントのやりとりを傍受してプロキシを介して新しいサービスを呼び出す。（ただし、新サービスに必要な情報が足りなかったりすると、モノリスを変えるしかない。）
- データベースの変更をトリガーとして、新サービスに情報を送ることも可能だが、管理が難しくなる可能性があるため非推奨。
データベースの分割について
- そもそもマイクロサービスはビジネスドメインごとにサービスを分けるアーキテクチャであり、データベースも各ビジネスドメインのサービスに分ける必要がある。（共有データベースとすることは、マイクロサービスの利点を潰す可能性が高い）
- まずはデータベースをラップするサービスを作る方法がある。それからモノリスや各サービスに情報を送ることで、サービスに応じて必要な情報のみを送ることができる（情報の隠蔽）
- 上記方法の場合、APIで各サービスに情報を送ることが考えられる。しかし、分析用のサービスなどを用意する場合、直接データベースに繋ぎたい要望が出てくる。この場合、真のDBをマッピングした（必要に応じて情報を隠蔽し）読み取り専用のDBを設けることで解決できる。
- マイクロサービスによりデータが分割された場合、データの同期には検討が必要になる。例えば上記分析用サービスも毎日夜にその日のマッピングをしたとすると、一日分のラグが生じている。サービスとしてそれを許容するのかという検討が必要になる。情報源を段階的に同期をするトレーサー書き込みなど。
- サービス間のデータの読み込みと書き込みがクロスする場合には、トラブルが起こりやすいため、サービス境界の見直しや処理フローの再検討が望ましい。
コードを先に分割するかデータベースを先に分割するか
- パフォーマンスの懸念やデータの一貫性に関する懸念が生じている場合には、スキーマを分割することを考える、
- 上記以外の場合には、先にコードを分割することでデータの所有権にどのような影響が出るか考える、
- 多分だけど、通常アーキテクチャがビジネスロジックごとに綺麗に分かれていないと、コードのリファクタとかが先にくると思う。
その他
- 分散トランザクションは避ける。
- 各サービスが順番に処理される場合に、どこかのサービスで転けたときのロールバックについて考える必要がある。転けたときの影響がでかいものを先に持ってくることや、転け方に応じてロールバックの方法を変えるなどの工夫が必要。
感想
- 「モノリスからマイクロサービスへ」一通り読んだけど、特別不思議なことはしてなくて、まぁサービス分けようと思うとそういうこと考えなきゃいけなそうだようねといった感じ。
- 面白そうだけど、今まで既に動いている大きいサービスをいじるっていう経験がないから、やるとなったら結構怖そうだなーと思った。副作用も大きいから、既に大きな問題があってマイクロサービス化で解決できるという強い確信がないと提案しずらそう。。
- この手の本としては結構読みやすい方だったと思う。
