関連サイト
本書の関連ページが用意されています。
内容紹介
ソフトウェアの計画・設計における意思決定の原則とその適用法を考察
本書では、まず5つの質問と7つの原則を提示します。これらは、さまざまな不確実性やリスクがある中で、アーキテクチャを取り巻く状況の理解を助け、適切な意思決定を行うための道標として機能するものです。
その後、パフォーマンスやUXのほか、マクロアーキテクチャの各技術分野の知識を取り上げ、意思決定のポイントを解説します。
最後に全体を俯瞰し、開発者が効率的に仕事を進められるようにリーダーがどのようにすべきかを説明します。
総合的な判断力を高め、優れたアーキテクチャを実現するためにアーキテクトや上級エンジニア、テクニカルリーダーの方たちにぜひ手に取っていただきたい内容となっています。
※本書は『Software Architecture and Decision-Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』の翻訳書です。
書誌情報
- 著者: Srinath Perera(著), 島田 浩二(訳)
- 発行日: 2024-12-11 (紙書籍版発行日: 2024-12-11)
- 最終更新日: 2024-12-11
- バージョン: 1.0.0
- ページ数: 304ページ(PDF版換算)
- 対応フォーマット: PDF, EPUB
- 出版社: インプレス
対象読者
ソフトウェアエンジニア、アーキテクト、テクニカル リーダー
著者について
Srinath Perera
これまで20年間ほどApacheオープンソース開発者として活動。Apache Axis2、Apache Airavata、WSO2 CEP、WSO2 Choreoのアーキテクチャにおいて主要な役目を担う。さまざまなプロジェクトでSOAPエンジンの設計のほか、構築支援、コミッターなどを務める。博士号を取得した後、2009年にオープンソーステクノロジープロバイダーWSO2に入社。10以上のプロジェクトと100以上のリリースでアーキテクチャレビューを行う。そのほか、何百もの顧客のソリューションアーキテクチャとデプロイメントをレビュー。40以上の査読付き研究論文を発表し、他の研究論文からの参照数は数千に上る。
島田 浩二
1978年、神奈川県生まれ。電気通信大学電気通信学部卒業。2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事も務める。訳書に『スタッフエンジニアの道』『ソフトウェアアーキテクチャメトリクス』『ソフトウェアアーキテクチャ・ハードパーツ』『ソフトウェアアーキテクチャの基礎』『ユニコーン企業のひみつ』『Design It!』『進化的アーキテクチャ』『エラスティックリーダーシップ』『プロダクティブ・プログラマ』（オライリー・ジャパン）、『Rubyのしくみ』（オーム社）、『なるほどUnixプロセス』（達人出版会）、共著者に『Ruby逆引きレシピ』（翔泳社）がある。
目次
献辞
はじめに
目次
第1章 ソフトウェアリーダーシップ入門
- 1.1 判断力が果たす役割
- 1.2 本書の目的
- 1.3 パート1：はじめに
- 1.4 パート2：最も重要な背景
- 1.5 パート3：システム設計
- 1.6 パート4：すべてをまとめる
第2章 システム、設計、アーキテクチャを理解する
- 2.1 ソフトウェアアーキテクチャとは
- 2.2 システムを設計する方法
- 2.3 5つの質問
- 2.3.1 質問1：市場投入に最適なタイミングはいつか？
- 2.3.2 質問2：チームのスキルレベルはどの程度か？
- 2.3.3 質問3：システムパフォーマンスの感度はどれくらいか？
- 2.3.4 質問4：システムを書き直せるのはいつか？
- 2.3.5 質問5：難しい問題はどこにあるか？
- 2.4 7つの原則：包括的なコンセプト
- 2.4.1 原則1：ユーザージャーニーからすべてを導く
- 2.4.2 原則2：イテレーティブなスライス戦略を用いる
- 2.4.3 原則3：各イテレーションでは、最小の労力で最大の価値を加え、より多くのユーザーをサポートする
- 2.4.4 原則4：決定を下し、リスクを負う
- 2.4.5 原則5：変更が難しいものは、深く設計し、ゆっくりと実装する
- 2.4.6 原則6：困難な問題に早期に並行して取り組むことで、エビデンスに学びながら未知の要素を排除する
- 2.4.7 原則7：ソフトウェアアーキテクチャの凝集性と柔軟性のトレードオフを理解する
- 2.5 オンライン書店の設計
- 2.6 クラウド向けの設計
- 2.7 まとめ
第3章 システムパフォーマンスを理解するためのモデル
- 3.1 計算機システム
- 3.2 パフォーマンスのためのモデル
- 3.2.1 モデル1：ユーザーモードからカーネルモードへの切り替えコスト
- 3.2.2 モデル2：命令階層
- 3.2.3 モデル3：コンテキストスイッチのオーバーヘッド
- 3.2.4 モデル4：アムダールの法則
- 3.2.5 モデル5：ユニバーサルスケーラビリティ法則
- 3.2.6 モデル6：レイテンシーと使用率のトレードオフ
- 3.2.7 モデル7：最大有用利用（MUU）モデルを使用したスループット設計
- 3.2.8 モデル8：レイテンシー制限の追加
- 3.3 最適化のテクニック
- 3.3.1 CPU最適化テクニック
- 3.3.2 I/O最適化テクニック
- 3.3.3 メモリ最適化テクニック
- 3.3.4 レイテンシー最適化テクニック
- 3.4 パフォーマンスへの直感的な理解
- 3.5 意思決定における考慮事項
- 3.6 まとめ
第4章 ユーザーエクスペリエンス（UX）を理解する
- 4.1 アーキテクト向けの一般的なUXの考え方
- 4.1.1 UXの原則1：ユーザーを理解する
- 4.1.2 UXの原則2：必要最小限のことをする
- 4.1.3 UXの原則3：良いプロダクトにはマニュアルが要らない。良いプロダクトは使い方が自明
- 4.1.4 UXの原則4：情報交換の観点から考える
- 4.1.5 UXの原則5：シンプルなものをシンプルにする
- 4.1.6 UXの原則6：実装より前にUXをデザインする
- 4.2 設定のためのUXデザイン
- 4.3 APIのためのUXデザイン
- 4.4 拡張機能のためのUXデザイン
- 4.5 意思決定における考慮事項
- 4.6 まとめ
第5章 マクロアーキテクチャ：はじめに
- 5.1 マクロアーキテクチャの歴史
- 5.2 現代のアーキテクチャ
- 5.3 マクロアーキテクチャのビルディングブロック
- 5.3.1 データマネジメント
- 5.3.2 ルーターとメッセージング
- 5.3.3 エグゼキューター
- 5.3.4 セキュリティ
- 5.3.5 通信
- 5.3.6 その他
- 5.4 意思決定における考慮事項
- 5.5 まとめ
第6章 マクロアーキテクチャ：コーディネーション
- 6.1 アプローチ1：クライアントからフローを駆動する
- 6.2 アプローチ2：別のサービスを利用する
- 6.3 アプローチ3：集中型ミドルウェアを使用する
- 6.4 アプローチ4：コレオグラフィを導入する
- 6.5 意思決定における考慮事項
- 6.6 まとめ
第7章 マクロアーキテクチャ：状態の一貫性の保持
- 7.1 なぜトランザクションなのか
- 7.2 なぜトランザクションを超える必要があるのか
- 7.3 トランザクションを超えていく
- 7.3.1 アプローチ1：問題を再定義して必要な保証を減らす
- 7.3.2 アプローチ2：補償を使う
- 7.4 ベストプラクティス
- 7.5 意思決定における考慮事項
- 7.6 まとめ
第8章 マクロアーキテクチャ：セキュリティへの対応
- 8.1 ユーザー管理
- 8.2 相互作用のセキュリティ
- 8.2.1 認証の手法
- 8.2.2 認可の手法
- 8.2.3 相互作用のセキュリティを確保するための一般的なシナリオ
- 8.3 ストレージ、GDPR、その他の規制
- 8.4 セキュリティ戦略とアドバイス
- 8.4.1 パフォーマンスとレイテンシー
- 8.4.2 ゼロトラストアプローチ
- 8.4.3 ユーザー提供コードを実行する際の注意
- 8.4.4 ブロックチェーンの話題
- 8.4.5 その他の話題
- 8.5 意思決定における考慮事項
- 8.6 まとめ
第9章 マクロアーキテクチャ：高可用性とスケーラビリティへの対応
- 9.1 高可用性を加える
- 9.1.1 レプリケーション
- 9.1.2 高速リカバリー
- 9.2 スケーラビリティを理解する
- 9.3 現代のアーキテクチャのためのスケーリング：基本的なソリューション
- 9.4 スケーリング：取引のツール
- 9.4.1 スケール戦術1：何も共有しない
- 9.4.2 スケール戦術2：分散させる
- 9.4.3 スケール戦術3：キャッシュする
- 9.4.4 スケール戦術4：非同期に処理する
- 9.5 スケーラブルなシステムの構築
- 9.5.1 アプローチ1：逐次的にボトルネックを解消していく
- 9.5.2 アプローチ2：シェアードナッシングな設計をする
- 9.6 意思決定における考慮事項
- 9.7 まとめ
第10章 マクロアーキテクチャ：マイクロサービスアーキテクチャでの考慮事項
- 10.1 決めること1：共有データベースの扱い
- 10.1.1 解決策1：特定のサービスだけがデータベースを更新する
- 10.1.2 解決策2：2つのサービスがデータベースを更新する
- 10.2 決めること2：各サービスのセキュリティ
- 10.3 決めること3：サービス間のコーディネーション
- 10.4 決めること4：依存性地獄の避け方
- 10.4.1 後方互換性
- 10.4.2 前方互換性
- 10.4.3 依存関係グラフ
- 10.5 マイクロサービスの代替としての緩く結合されたリポジトリベースのチーム
- 10.6 意思決定における考慮事項
- 10.7 まとめ
第11章 サーバーアーキテクチャ
- 11.1 サービスの作成
- 11.2 サービスの作成におけるベストプラクティスを理解する
- 11.3 高度なテクニックを理解する
- 11.3.1 代替I/Oとスレッドモデルの使用
- 11.3.2 コーディネーションのオーバーヘッドを理解する
- 11.3.3 ローカルの状態を効率的に保存する
- 11.3.4 トランスポートシステムの選択
- 11.3.5 レイテンシーへの対応
- 11.3.6 読み取りと書き込みの分離
- 11.3.7 アプリケーションでロック（とシグナリング）を使う
- 11.3.8 キューとプールの使用
- 11.3.9 サービス呼び出しの取り扱い
- 11.4 テクニックの実践
- 11.4.1 CPU性能律速型アプリケーション（CPU>>メモリ、I/Oなし）
- 11.4.2 メモリ性能律速型アプリケーション（メモリ>>CPU、I/Oなし）
- 11.4.3 バランス型アプリケーションCPU＋メモリ＋I/O）
- 11.4.4 I/O性能律速型アプリケーション（I/O＋メモリ>CPU）
- 11.4.5 その他のアプリケーション分類
- 11.5 意思決定における考慮事項
- 11.6 まとめ
第12章 安定したシステムの構築
- 12.1 システムはなぜ障害を起こすのか。私たちはそれにどう対処できるのか
- 12.2 既知のエラーに対処する方法
- 12.2.1 予期しない負荷への対処
- 12.2.2 リソース障害への対処
- 12.2.3 依存関係への対処
- 12.2.4 人が行う変更への対処
- 12.3 一般的なバグ
- 12.3.1 リソースリーク
- 12.3.2 デッドロックと遅い操作
- 12.4 未知のエラーに対処する方法
- 12.4.1 可観測性
- 12.4.2 バグとテスト
- 12.5 グレースフルデグラデーション
- 12.6 意思決定における考慮事項
- 12.7 まとめ
第13章 システムの構築と進化
- 13.1 実際にやってみる
- 13.1.1 基本に忠実に
- 13.1.2 設計プロセスを理解する
- 13.1.3 決定を下し、リスクを負う
- 13.1.4 卓越性を求める
- 13.2 設計を伝える
- 13.3 システムを進化させる：ユーザーから学んでシステムを改善していく方法
- 13.4 意思決定における考慮事項
- 13.5 まとめ