読書感想文そろそろ正月気分も抜けてきました。O'Reillyのマイクロサービスアーキテクチャ本感想の第5回です。5章「モノリスの分解」を読んで4章の統合に対し、5章では既存のモノリシックなアプリケーションをどうやって分割していくかの話になります。コンテキスト境界再びモノリシックなアプリケーションを分割するためには、アプリケーションの接合部(seam)を探し出すこと、接合部としてはBC(コンテキスト境界)がわかりやすいのでおすすめとあり、BCを洗い出した後の流れが語られます。※以後繰り返しこのフローによってコードベースを接合部に合わせて整理すると捗るそうです。分解するのかを考えながら行うことが大事モノリスを分解するということは、大理石を削る行為に似ているとし、勢いよく削ろうとすると全体が想定外に割れてしまうと警告があり、そのうえでコードベースをさらに分解する指針として以下が挙げられています。新しいライブラリ、ミドルで最適化が可能になるデータベースは依存関係の塊ですstructure101のようなツールで依存関係をグラフ化すると接合部を見つけるのが捗るぜ、そして大抵の場合はデータベースが最も依存関係の多いポイントだ(意訳)というノリで従来のRDBのあり方に切り込んでいきます。共有テーブルは分割して各サービスに返す(正規化が可能なテーブルだと思う)この節は自分の携わるシステムのDBの思い浮かべながら読んだのですが、アプリケーション側というか、開発者への負担は相当な物になるなあという印象。分割は段階的にやっていこうサービスの分割と、データベース内のスキーマ分割のどちらから行うべきかという話です。適切な順番としては以下としています。理由はアプリケーションコードを一緒にしておくことで、コンシューマに影響を与えることなく変更を戻せるためです。(アプリケーション側にも変更は必要のはずで、DBへのクエリだけ変えると理解した)トランザクションはマイクロサービスでは大変だ分散システムでのトランザクションの担保は、2フェーズコミットやリトライ、ロールバックなど考慮すべき点が多いとし、結論としては以下3点に集約されます。本当に単一のトランザクションで行う必要のある処理かを見直す単一のトランザクションが必要な処理を分割させずに済む方法を探す分割が必要ならトランザクション事態を表す概念を生成する(処理中のhoge、といったステータス)読んでいて"CAP定理"の話だなと思いましたが、"CAP定理"という言葉は出てきませんでした。KPIなどのレポート用データベースの取り扱いよくあるユースケースとして、レポート用のデータベースは複数のデータを結合することが求められますが、どう扱うと良いのかという話です。本章はDB分割のところを大変面白く読みました。コンテキスト境界を意識して大きな枠から分割していくイメージは言葉だけで分かった気になっている感覚があります。DB分割は自分の業務に近いところでもあり、業務を想定しながら具体的な分割方法を検討する良い機会にもなり、そしてそれが非常に苦労する道のりだという知見が得られた章でした。#23に参加してきました月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。