Open12
ソフトウェアアーキテクチャの基礎を読む
りんソフトウェアアーキテクチャの基礎 - エンジニアリングに基づく体系的なアプローチ
を読んでのメモ
りん1章
ソフトウェアアーキテクチャの関心領域
ソフトウェアアーキテクチャの定義
- 構造
- アーキテクチャ特性
- アーキテクチャ決定
- 設計指針
アーキテクトへの期待
- アーキテクチャ決定
- 技術的決定のガイドをする
- アーキテクチャの継続的分析
- imo 継続的な分析 = 事業、システムの存続のための基準と分析手法を持つことが求められる
- 最新のトレンドの把握
- 決定の順守の徹底
- 多様なものに広く触れる
- 事業ドメインの知識を持つ
- 対人スキル
- 政治を理解し、舵取りをする
アーキテクチャと交わるもの
- 開発プロセスとエンジニアリングプラクティス
- 開発プロセスとエンジニアリングプラクティスは分けて考えるべき
- アーキテクチャとしてエンジニアリングプラクティスにフォーカスすることは重要
- q 個人的にはプロセスとエンジニアリングプラクティスは重要な関連性を持っている感覚があるが、なぜ分けて考えるべきなのか？
- 進化的なアーキテクチャ
- 適応度関数 -> アーキテクチャ適応度関数という考え方
- アーキテクチャ特性の整合性を客観に評価するもの
- imo 適応度を測る基準と仕組みを作ることの重要性が自分の関心とマッチしているので刺さった
この本での法則(見るべきポイント)
- トレードオフ
- アーキテクチャを決定した理由
りん2章
アーキテクチャと設計
アーキテクチャと設計の境界は存在しない
imo なぜその主張をしたいのか分からない
トレードオフの分析
- キューとトピック(サブ/パブ)
- メリット分析
- トピックの方が疎結合
- キューの方が個々にデータフィールドの調整、スケーリングの調整が可能
- デメリット分析
- トピックはクライアントごとの調整が不可
- キューは密結合
- メリット分析
- imo まだ自分は開発観点しか持ててないことが分かった。アーキテクチャ決定をするためには「アーキテクチャ特性」という視点を常に維持して切り替える能力が必要だと感じた。
りん3章 モジュール性
imo 理解が難しく、どれだけ有用かも分かりづらい
- 主系列からの距離というメトリクスは不安定だと抽象度から求められる
- q 距離のプロットはどのように求めるのか？
りん4章 アーキテクチャ特性
- 本書でのアーキテクチャ特性 ≒非機能要件
- 要件 = アプリケーションが何をすべきか
- アーキテクチャ特性 = アプリケーションが成功するために必要な運用と設計の基準
- 要件をどう実装するか、なぜその方法が選ばれたか
りん5章 アーキテクチャ特性を明らかにする
-
アーキテクチャ特性に優先度はつけようとしない方が良い
- より良い方法は、最終的なリフトから最も重要な上位3つの特性を選んでもらうこと
-
アーキテクトとビジネスサイドの翻訳
-
ドメイン知識から導かれる要件(およびアーキテクチャ特性)
- 大学生用のシステムの可用性考慮の上で、登録期限ギリギリのアクセスが集中するだろうというドメイン知識
-
アーキテクチャ・カタ
-
シリコンサンドイッチのカタから分かるアーキテクチャ特性
- スケーラビリティと弾力性
- サードパーティとの連結点による信頼性
- アクセシビリティは設計に営業
- 場所によるカスタマイズ性をアーキテクトで解決するか、設計で解決するか…トレードオフを考慮しよう
- 安い労働力 -> ユーザビリティに繋がる(ただしこれは設計上の関心事)
りん6章 アーキテクチャ特性の計測と統制
- アーキテクチャ適応度関数
- 循環依存
- コードのモジュール性をチェックする
- メトリクスツールのJDepend
- パッケージ間の依存関係をチェックし、循環関係がある場合にテストを失敗させる
- 主系列からの距離
- これをテストすることもできる
- レイヤー統制
- 別テストフレームワークでテストできる
imo こういうのがある事を知っていれば選択できる
りん7章 アーキテクチャ特性のスコープ
- アーキテクチャ量子をスコープとして特性を定める
- 独立してデプロイ可能
- 高い機能的凝集性を持つ
- 同期処理における運用特性の同一性を持った繋がりが可能
- Going, Going, Goneカタにおける量子
- 入札ストリームと入札の動画ストリームを包含している
- ライブの競売人
- オンラインの入札者と入札
りん8章 コンポーネントベース思考
- コンポーネント = モジュールが物理的にパッケージ化されまもの
- G, G, G におけるコンポーネント分割
- 最初は入札キャプチャコンポーネントは入札者、競売人の両方から共通して利用されていたが、アーキテクチャ特性に照らし合わせると、それぞれのアクターのためにコンポーネントを用意することになっていた。
りん9章 基礎
- 分散コンピューティングに対する誤信から学ぶ
- ネットワークの信頼性は低い。
- レイテンシーは必ずある。レイテンシーのパーセンタイルを把握する。
- 帯域の利用量を把握して分割すること。
- ネットワークは安全では無い。
- ネットワークのトポロジー(接続形態。ルーターやファイアウォールなどすべて)は変化する。アプリケーションのデプロイを行なっていなくとも、「軽微な」ネットワークアップデートのせいでレイテンシーの前提条件を無効にしてタイムアウトやサーキットブレーカーを誘発する例も。
- ネットワーク管理者は一人では無い。
- 転送費用が存在する。
- ネットワークは均一では無い。ベンダー間での連携があった場合など。
りん10〜17 アーキテクチャスタイル
印象的な部分をまとめる
- レイヤードアーキテクチャ
- 評価は高くなく、小規模なアプリケーションに向いているとされる
- q このスタイルと他のスタイル(マイクロサービスなど)は共存しないのか？
- パイプラインアーキテクチャ
- imo 関心事項をはっきりと分割できる&アプリケーションが用意するユースケースが少ない場合に有用
- モノリシックなデプロイによって耐障害性が低い
- マイクロカーネルアーキテクチャ
- コアシステムとプラグインで構成される
- Eclipse などのIDEが良い例
- レイヤードアーキテクチャなどと組み合わせることも可能
- サービスベースアーキテクチャ
- サービスはマイクロだが、データベースが単一のモノリシック
- データベースの拡張性がネックになる
- 費用、コストと柔軟性のバランスが良い
- イベント駆動アーキテクチャ
- 高度にスケーラブルで高パフォーマンスな分散非同期型のアーキテクチャ
- imo メッセージブローカーやメディエーター(ワークフローの管理・制御)など他アーキテクチャでは見ないトポロジーが存在するので、学習コストが高い
- imo ネットワークの理解を必要とするので学習コストが高い
- 非同期的でリアルタイム性が高い
- imo エラー処理に関しても考慮すべき事項が多いので学習コストが高い
- データロスの懸念が常にある
- スペースベースアーキテクチャ
- 高いスケーラビリティ、弾力性、高い同時実効性 -> 同時接続ユーザー数が変動して予測できないよつなアプリケーションにも有効
- メモリを活用した高速なI/Oとデータベースねの非同期送信によってデータベースのボトルネックを解消する
- imo イベント駆動アーキテクチャ以上に学習コストが高い
- オーケストレーション駆動サービス指向アーキテクチャ
- 今は不要なアーキテクチャ
- マイクロサービスアーキテクチャ
- データベースの分離が特徴
- 粒度を小さくしすぎることにも注意が必要
- 運用面での共通の関心ごと(モニタリングなど)はサイドカーパターンで、各サービス内に置きつつサービス外のサービスプレーンによって一貫したインターフェースを形成する方法が取れる
- コストや(全体を通した)シンプルさに難あり
りん18章以降について
18章以降はアーキテクチャ決定に関する内容で、現在の自分のキャリア的に早すぎる情報のためスキップする。