主要な指標の耐久性をためしてどこで壊れるかを確かめよ

アプリケーション設計の概要は、初期状態では、ビジネス上の要件、既存のあるいは新しく選択されたテクノロジー、パフォーマンスの許容範閉、予想されるデータ量、ビルド/デプロイ/運用に必要な資金などによって決まります。どんなものであれ、およそソリューションであれば、現状の環境のもとで要求された内容に合致するかそれ以上のものになり、うまく動作するはずです(そうでなければ、まだソリューションになっていません)。

この段階のソリューションについて、さらに耐久性を試してどこで壊れるかを確かめておきましょう。

このテストは、たとえば、システムが爆発的な人気を集めて、予想をはるかに超える顧客が使うようになった場合、処理している製品の1日あたりのトランザクションが増えた場合、初期仕様の1週間分ではなく6か月分のデータを保存しなければならなくなった場合などに、設計がどこまで耐えられるかを調べておくということです。指標はまず個別に負担を重くしていき、次に組み合わせテストも行って、初期設計からは見えない限界を引き出すのです。

主要な指標に対して耐久テストを行うと、アーキテクトは、次のような形でソリューションをチェックすることができます。

• 予定しているインフラが数値の上昇に対応できるかどうか、限界がどこにあるかがわかる。インフラが壊れるようなものなら、これでシステムの弱点がはっきりしますのでそれをアプリケーションのオーナーに強調することができます。あるいは、予定しているインフラを買うときに、アップグレードの道筋を考えに入れておくことができます。
• 予定したスループットで処理をしたとき、日中に十分余裕を残して処理が終わり、「繁忙期」や復旧後の「追い上げ」にも対応できるかどうかを確かめられる。その日のうちに処理を終わらせることができず、通常よりも余裕のある週末が頼りになるようなシステムは、長持ちしません。
• システムがスケールアップしても、選択したデータアクセスの方法が有効かどうかを確かめられる。1週間分のデータでは動作するシステムでも、6か月分のデータでは使い物にならない場合があります。
• ハードウェアの追加投資(必要な場合)の前後でアプリケーションの負荷拡大のペースがどのように変わるか、負荷の拡大とともにハードウェアをどのように増強していくべきかを確認できる。アプリケーションをデプロイする前に将来の変化を確認しておくと、格納されるデータやその構造に影響が及ぶ場合があります。
• データ量が増えたり、追加されたインフラの間でデータが分割されても、アプリケーションを復旧できるかどうかを確かめられる。

このようなテストをすると、再設計を必要とするような問題のある要素が見つかる場合があります。設計がまだ流動的で、技術的な選択が確定されておらず、ビジネスデータがまだレポジトリに格納されていない間なら、再設計にかかるコストは安くで済みます。