ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ

20章アーキテクチャ上のリスクを分析する

すべてのアーキテクチャには、可用性、スケーラビリティ、データ完全性などに関するリスクがある。アーキテクチャのリスクを分析することは、アーキテクチャに関する重要な活動の1つだ。リスクを継続的に分析することで、アーキテクトはアーキテクチャ内の欠陥に対処し、リスクを軽減する措置を取れる。この章では、リスクを限定し、リスクアセスメントを作成し、リスクストーミングを通してリスクを特定していくための主要なテクニックとプラクティスを紹介する。

20.1　リスクマトリックス

アーキテクチャのリスクを評価する際に最初に発生する問題は、リスクを高・中・低どれに分類すべきかを決定することだ。通常、こういったリスク評価には主観が多く入り込む。そのため、アーキテクチャのどの部分のリスクが本当に高く、どのリスクが中程度なのかについて混乱が生じてしまう。幸いなことに、アーキテクトはリスクマトリックスを活用することで、主観の度合いを減らし、アーキテクチャの個別の領域に関連するリスクを限定できる。

アーキテクチャのためのリスクマトリックス（図20-1）では、リスクの全体的な影響度とそのリスクが発生する可能性という2つの側面を用いてリスクを限定する。それぞれの側面には、低（1）、中（2）、高（3）の評価がある。これらの数値をマトリックスの各グリッド内で掛け合わせることで、そのリスクを表す客観的な数値が得られる。1〜2は低リスク（緑）、3〜4は中リスク（黄色）、6〜9は高リスク（赤）とされている。

図20-1　アーキテクチャリスクを設定するためのマトリックス

リスクマトリックスの使用方法を見ていこう。アプリケーションで使用する中央のプライマリデータベースについて、可用性の懸念があるとする。アーキテクトはまず、影響度について考える。データベースがダウンしたり、利用できなくなったりした場合の全体的な影響はどの程度になるだろうか。アーキテクトは、その影響度は高いと判断し、リスクを3（中）、6（高）、9（高）のどれかと評価する。しかし、次の側面（リスクが発生する可能性）を考えると、データベースはクラスター化され可用性の高いサーバー上に構築されていることから、データベースが利用できなくなる可能性は低いことに気づく。そうすると、影響度の高さと可能性の低さの交点から、総合的なリスク評価は3（中リスク）となる。 ...