7. The Role of Measurement in Software Architecture
計測をソフトウェアアーキテクチャに組み込む方法、品質特性の計測と推定のためのアプローチ、どのように始めればいいか、よくある落とし穴について。
7.1 Adding Measurement to Software Architecture
定義、設計、構築、デプロイの継続的なプロセスの中に計測を組み込み、その計測値を元にサイクルを繰り返す。
計測の種類
| | 作成物の計測 | 運用の計測 | | — | — | — | | 外部計測 | PCI/DSS準拠, GDPR準拠、ベストプラクティスへの準拠など | レスポンスタイム、スループット、障害復旧時間、1ヶ月あたりの障害数など | | 内部計測 | コードの複雑さ、モジュールの結合度、DBスキーマ要素の数など | メモリ使用量、インデックスの増加率など |
- 作成物の計測 (Artifat measurements): デリバリープロセスで生成されるアーティファクトに対する計測
- 運用の計測 (Operational measurements): 運用環境で動作するシステムに対する計測
- 外部計測: デリバリーや運用を行うチーム以外の人が受ける影響の計測
- 内部計測: デリバリーや運用を行うチームが受ける影響の計測
7.2 Measurement Approaches
測定のアプローチ
- アプリケーションとインフラの実行時計測。ログ、トレース、メトリクス
- ソフトウェア分析
- 設計分析
- 見積もりとモデル
- 適応度関数
7.3 Measuring System Qualities
システム品質の計測
- パフォーマンス
- スケーラビリティ
- 可用性
- セキュリティ
各計測の際の考慮事項とよくある問題点
| 計測の際の考慮事項 | 計測時のよくある問題点 | |
|---|---|---|
| パフォーマンス | レスポンスタイムの分布を計測し、平均値、中央値、標準分布を使用して特性を評価する。これを対応する要件と比較してアーキテクチャに注意を払う必要があるかを判断。コストとのトレードオフにもなる。 | テスト環境と本番環境の違い。再現が難しい断続的なパフォーマンス問題は無視したくなるけど学ぶチャンスと捉えよう。ログの欠損、多すぎるログ。 |
| スケーラビリティ | 一定のリソースの元、許容されるパフォーマンスレベルでどのくらいのワークロードを処理できるか。コストもスケーラビリティの一因。システムの運用面でも必要な人員数などのスケーラビリティを計測することも重要。 | 予測不能なボトルネック。予測不能な非線形な挙動。複数のリソースの組み合わせが必要になる。(例: メモリだけでなく、CPUやディスクI/Oも考慮する必要がある) |
| 可用性 | MTBF, MTTR。目標復旧時点(Recovery Point Objective: RPO): 許容するデータ損失量。目標復旧時間(Recovery Time Objective: RTO): 障害発生後にデータの復旧を待てる最大時間。MTTRとはシステムの復旧、RTOはデータの復旧。 | MTBFは実際に故障が発生しないと推定できない。MTTR, MTBF, RPO, RTOを組み合わせて、自身のシステムに応じて全体の計測基準を決める。 |
| セキュリティ | よく使われるのはセキュリティインシデントの数、それ以外にも静的解析、動的解析、インフラストラクチャスキャニングをセキュリティの代理指標として計測。 | テスト環境と本番環境をできるだけ同じ設定にする。偽陽性は計測に含めない。セキュリティリスクに対してどのように重み付けするかは難しい。テストが十分であることを知るのは難しい。 |
7.4 Getting Started / 7.5 Hypothetical Case Study / 7.6 Pitfalls
計測を始めるときのアドバイス、計測を適用するときの落とし穴
- 小さく始める。とりあえず全部計測だと手間と時間がかかる。
- やりやすいものではなく重要なことを計測する。正確性よりも有用性。
- 継続の結果から次のアクションにつなげる。
- 初期の段階から計測を取り入れる。
- 計測をデリバリーサイクルにいれる。