『データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理』(https://www.oreilly.co.jp/books/9784873118703/)の「§1.4 メンテナンス性 - 1章まとめ」の要約です。研究室の輪講で使用した資料です。
データ指向アプリケーションデザイン§1.4 メンテナンス性 - まとめSSチーム輪講 2021-03-04 03-10 高橋 (M2)
View Slide
このスライドについて『データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理』の「§1.4 メンテナンス性 - 1章まとめ」の要約です。
1.4 メンテナンス性
1.4 メンテナンス性● ソフトウェアのコストは、初期の開発コストではなく、運用中のメンテナンスのコストが支配的● メンテナンスの例○ バグ修正、運用の継続、障害の調査、新しいプラットフォームへの適用、新しいユースケースのための修正、技術的負債の返済、新機能の追加● 残念なことに、多くの人はいわゆるレガシーシステムのメンテナンスが嫌い● すべてのレガシーシステムは何らかの点で嫌なものなので、一般的に言える対処方法はない
1.4 メンテナンス性● しかし、メンテナンス中の苦痛が最小限で、自分自身でレガシーシステムを作らないようにするソフトウェアの設計は、可能なことでありするべきこと● この目的のために、本書では3つの原則に注目する○ 運用性(operability)○ 単純性(simplicity)○ 進化性(evolvability)運用性(operability)単純性(simplicity)進化性(evolvability)
1.4 メンテナンス性● 運用性(operability)○ システムをスムーズに動作させるために運用チームを楽にすること● 単純性(simplicity)○ システムから複雑さを可能な限り削減して、新しいエンジニアがシステムを簡単に理解できるようにすること● 進化性(evolvability)○ 将来の変更時にエンジニアを楽にすること○ 拡張性(extensibility)、修正の容易性(modifiability)、可塑性(plasticity)とも言う運用性(operability)単純性(simplicity)進化性(evolvability)
1.4.1 運用性: オペレータの生活を楽にする● 「よい運用は悪い(不完全な)ソフトウェアの制約を回避できるが、悪い運用では優れたソフトウェアも信頼性を保って動作できない」[12]● 運用の一部は自動化できるものでするべきだが、自動化のセットアップと正しい動作は依然として人間が行うもの運用性(operability)
1.4.1 運用性: オペレータの生活を楽にする● よい運用チームは以下のような責務を担っている○ システムの健全性を監視し、異常があれば速やかにサービスを復旧する○ システム障害や性能劣化などの問題の原因を追求する○ セキュリティパッチを含むプラットフォームの継続的な更新をする○ システムの相互関係に注目し、問題がありそうな変更を事前に回避する○ キャパシティプランニングなどで将来の問題を予測して事前に解決する○ デプロイと設定管理の優れたプラクティスやツールを確立する○ プラットフォーム間のアプリケーション移動などの複雑なメンテナンスタスクを実行する○ 設定変更時にセキュリティのメンテナンスをする○ 運用を予測可能にするためのプロセスを定義し、本番環境を安定させる○ 人の出入りがあってもシステムに関する組織の知識を保持する運用性(operability)
1.4.1 運用性: オペレータの生活を楽にする● よい運用性○ 運用チームが価値の高いタスクに集中できるようにするためにルーチンタスクを楽にすること● ルーチンタスクを楽にするためにデータシステムができること○ ランタイムの挙動やシステム内部の可視化の機能を提供する○ 自動化とツールとの結合をサポートする○ 個別のマシンへの依存を避ける(メンテナンス時にマシンを停止させても全体としての動作を続けられるようにする)運用性(operability)
1.4.1 運用性: オペレータの生活を楽にする● よい運用性○ 運用チームが価値の高いタスクに集中できるようにするためにルーチンタスクを楽にすること● ルーチンタスクを楽にするためにデータシステムができること○ すぐれたドキュメントと理解しやすい運用モデルの提供○ デフォルトの挙動をよいものにしつつ、管理者がそれをオーバーライドできるようにする○ 適切な場合には自己回復できるようにしつつ、管理者が手動でも制御できるようにする。○ 予想可能な挙動にして、予想外のことを最小限にする運用性(operability)
1.4.2 単純性: 複雑性を管理する● 単純性(simplicity)○ プロジェクトが大きくなると複雑性が増して理解しにくくなり、メンテンスコストが増大する■ 複雑性にまみれたソフトウェア=「巨大な泥の玉」(big ball ofmud)○ 複雑性の症状の例■ 状態空間の爆発、モジュール間の密結合、依存関係のもつれ、一貫性のない命名、パフォーマンスのためのハック、特殊ケースへの対応など○ メンテナンスの難しさがもたらす結果■ 予算とスケジュールの超過、バグ混入リスク増大、予想外の動作の見逃しなど単純性(simplicity)
1.4.2 単純性: 複雑性を管理する● 単純性(simplicity)○ 複雑性を減らすとメンテナンス性が大きく改善される○ 単純にする=偶発的な複雑性(accidental complexity)を取り除く■ Moseley & Marks[32]による偶発的な複雑性の定義「ソフトウェアが解決する問題ではなく、実装のみから生じている複雑性」● 抽象化(abstraction)○ 偶発的な複雑性を削減する最も優れた手法の1つ○ 再実装を減らせるため効率的なだけでなく、品質の向上につながる■ 抽象化の例: 高レベルプログラミング言語、SQL○ 分散システムにおける優れた抽象化のパッケージ方法は明らかではない○ 本書では、優れた抽象化に注目してゆく単純性(simplicity)
1.4.3 進化性: 変更を楽にする● 進化性(evolvability)○ システムの要求は永久に変わらないことはまずなく、常に流動的に変化する可能性が高い■ 変化の原因: 新しい事実の学習、過去に予想されなかったユースケースの出現、ビジネスの優先度の変化、ユーザーからの新機能の要求、プラットフォームの変化、法的な要求の変化、アーキテクチャの変更など○ 変化に対処できる組織のプロセスとしてアジャイル(agile)がテスト駆動開発やリファクタリングを開発してきた進化性(evolvability)
1.4.3 進化性: 変更を楽にする● 進化性(evolvability)○ 従来の手法は小さなローカルのスケールに焦点を当ててきたが、本書では、さまざまな特徴を持つ複数のアプリケーションやサービスから構成される大規模システムのアジャイル性を高める方法を追求する○ データシステムへの変更と変化への適応がらくになるかどうかは、データシステムの単純性と抽象化に密接に関係する○ 非常に重要な概念なので、本書では、データシステムレベルでののアジャイル性を進化性という別の言葉で呼ぶ進化性(evolvability)
1章 まとめ● アプリケーションには機能的要求と非機能的要求がある○ 本書では、非機能的な要求の一部である信頼性・スケーラビリティ・メンテナンス性の3つに注目する
1章 まとめ● 信頼性○ フォールトがあってもシステムが正しく動作できること○ フォールトはハードウェア・ソフトウェア・人間に起こる○ 耐障害性の手法により、エンドユーザーから隠蔽できる
1章 まとめ● スケーラビリティ○ 負荷が増大しても優れたパフォーマンスを発揮できること○ 正しく議論するためには負荷とパフォーマンスを定量的(quantitative, 具体的な数値として計測できること)に表現することが必要■ 負荷とパフォーマンスの例:■ 負荷: Twitterのホームタイムラインの表示■ パフォーマンス: レスポンスタイムのパーセンタイル
1章 まとめ● メンテナンス性○ 本質は、エンジニアと運用のチームの仕事を楽にすることにある○ 抽象化(abstraction)と運用性(operability)が重要○ 優れた抽象化■ 複雑性に対処して変更が容易になる○ 優れた運用性■ システムの健全性をよく可視化でき、効果的に管理できるようになる
1章 まとめ● 信頼性・スケーラビリティ・メンテナンス性を簡単に改善できる方法はない○ しかし、アプリケーションが異なっていても繰り返し現れる特定のパターンやテクニックは存在する● この本の2章以降の数章では○ データシステムの例をいくつか見てゆく○ 信頼性・スケーラビリティ・メンテナンス性という目的のために、データシステムの動作について分析してゆく● また、第III部では、図1-1のような複数コンポーネントが協調するシステムのためのパターンを見てゆく
shuuji3
hirotokirimaru
maimux2x
kazumura
manfredsteyer
nearme_tech
syumai
konpay
umizaru
honma12345
alli83
pangmoo
yucamm124
keavy
orderedlist
holman
kastner
brianwarren
revolveconf
aleyda
tanoku
zakiwarfel
philhawksworth
davidbonilla
bkeepers