最近マイクロサービスをゴリ押しされてるマスタカです
ちょっとマイクロサービスを勉強しないとまずいと思ってたところ
Sam Newmanが有名だと聞き本書の存在を知る
そんなわけで本書を読んでみた
以下、内容
・本書の内容
モノリシックをマイクロサービスにどうやって移行するかというだけでなく
そもそもなんでマイクロサービスでやるのかから解説した本
モノリシックの利点も説明しているし
マイクロサービスの悪い点も説明しているので
かなり広範囲に概要を説明していてる本です
サーバーサイドのとっかかりとして最適な本になってます
・1章と2章
マイクロサービスの概要説明
マイクロサービスへの移行計画
この中で面白かったことを書いてていく
・マイクロサービスとは
ビジネスドメインごとに独立してデプロイできる状態のこと
・マイクロサービスはゴールじゃない
既存のシステム構成で達成できないことをやるために
マイクロサービスにするイメージ
・アーキテクチャを採用するに当たっての質問
何を達成したいか？
マイクロサービス以外の選択肢を考慮したか？
正しい方向に進んでいるか知る方法があるか？
マイクロサービスにする目的がないと
どこからどうやって分割するかが決まらない
・独立してデプロイするには
密結合にならないようにする
例えば共有DBとかだとまずい
・分割する単位
APIとUIみたいな分け方だけでなく
顧客画面-顧客api-顧客DBのようにビジネスドメインでdeployできる様にする必要がある
そのため、分割はドメインごとに行う
そして、ドメインを勘違いするとコストが高くなり
最終的に分けたサービスをマージしてモノリシックに戻すことになる
そしてドメイン理解が進んだら再度分割する
・共有DBではなくAPI経由で共有する
これによりDBの中の何を共有するかを考えることができる
なのでインタフェースは変えてはいけない
・共有DBではなく公開するデータだけ共有する
MySQLのViewを使って特定のカラムだけ共有する
これなら特定のカラムだけ維持すればよい
この方法はバッチ系に対して有効な方法
・モノリシックの利点
監視
トラブルシューティング
E2Eテスト
コードの再利用
モノリシックだから悪いわけではなく
場合によってはモノリシックに作っても良い
・モノリシックの利点2
マイクロサービスだとインタフェースを変えるは難しいが
モノリシックなら楽勝
・モノリシックのリリース
Release Trainという方式になる
モノリシックの場合は一度に全部リリースすることになるので
日付を決めて、その日までに入ったものをdeployする
・マイクロサービスの利点1
マイクロサービスでチームごとに責任範囲を持つ様になると
他人を待たなくてよくなるので生産性が上がる
チームが自立するということ
中央集権では生産性は上がらない
・マイクロサービスの利点2
サーバーの増強時に必要な箇所だけ増強すれば良いので、コスト効率がよい
モノリシックでも、モノリシックをそのままコピーして増やせばとりあえず増強できる
・マイクロサービスでの注意点
各サービスでコードの再利用をすると
変更しようとした場合両方のコードを変更する必要があり運用コストが高くなる
・パッケージソフトウェアとマイクロサービス
マイクロサービスは悪いアイデア
k8sを顧客が運用できるわけがない
・言葉の説明
ロバストネス：サーバーが死んだときにロードバランスするような予期した振る舞いにすること
レジリエンス：想定してない障害時にも許容できるように動かすこと
・決断には二種類ある
以前の状態に戻ることができない決断(Type1)と
以前の状態に戻ることができる決断(Type2)
Type2はすぐに決断しちゃってよい
・チームとスキル
個別のスキルを出してチームのスキルを可視化し
マイクロサービスを担っていけるスキルがあるか確認できる
足りなければ人を入れよう
長くなるので続くよ
