ソフトウェアアーキテクトのための意思決定術を読んでスキルが一段上がった

ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用
を読んだ

マスタカといえばVPoEと言いつつもアーキテクトも兼ねている
そんなわけで本書を読んでみた

以下、ためになったこと

・本書の内容
意思決定もあるが、技術の話もある
アーキテクトが理解しておくべきってことも併せて解説した本

・リーダーとは
リーダーとは希望を売る商人である

これかっけーな

・意思決定
プロジェクトの成果に重要でないことは移譲する
重要とは、最良と明白な解決策に大きく結果が異なるものを指す
重要で不可逆な決定は、決定しないといけないタイミングを把握する必要がある
感覚値で70%の情報がそろったら判断をすぐに下そう
例は以下
・チームがやるべきことがなくなったとき
・遅れが納期に影響を及ぼすとき

・トランザクション
多くの分散アプリケーションはユーザーリクエストごとに1,2回のサービスの呼び出しを行う
この程度であればコーディネーション層は不要

トランザクションを使わずに適切に回復できるか考える
決済はトランザクションが必要だが動画ストリーミングにトランザクションは不要

可能な限りべき等にする
これによりトランザクションの実装が簡単になる

トランザクションの範囲を限定する
できるなら単一のサービスに限定する

データの読み取りと書き込みは一つのサービスにまとめる

・スケーリング
アプローチ1:逐次的にボトルネックを解消する
アプローチ2:共有を行わないように設計
DBのコピーを各サービスに置く
ロードバランサがサービス層にシャーディングして、各サービスからpub/subでDBにアクセスする
等

・マイクロサービス化の注意点
共有データベースの扱いを決める必要がある
特定のサービスだけが更新する
2つのサービスが更新する
等
当然2つのサービスで更新する場合はトランザクションが難しくなる

・マイクロサービスへのチームの移行
リポジトリを所有するチームがある
異なるチームが所有するコードが同じDBにアクセスすることは禁止する
チームが7-9名になったらリポジトリとチームを分割する

・ボトルネック
CPU性能がボトルネック
科学シュミレーション等
CPUのコア数と同じスレッドにするのが良い

メモリがボトルネック
データベース等
GCがボトルネックになるので気をつける

IOがボトルネック
map reduce等
ノンブロッキングにできるかぎりする

・ボトルネックの解消の意思決定
時期尚早な最適化は行わない
APIに十分な注意を払う
サービスのチューニングをする
安易にマイクロサービスにしない

・負荷対策
オートスケーリング
アドミッション制御：キューに入る数を制限する
重要でない機能を落とす

ソフトウェアアーキテクトのための意思決定術

Pocket

関連記事: