データ指向アプリケーションデザイン §1.4 - 1章まとめ

『データ指向アプリケーションデザイン――信頼性、拡張性、保守性の高い分散システム設計の原理』(https://www.oreilly.co.jp/books/9784873118703/)の「§1.4 メンテナンス性 - 1章まとめ」の要約です。研究室の輪講で使用した資料です。

Transcript

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