要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

IPAの非機能要求グレードの小項目を理解する(No6/119:サーバ)

[No1][A.2.1]可用性>耐障害性>サーバ

今回は、耐障害性(サーバ)について紹介する。耐障害性とは、サーバやコンポーネント(部品)が故障しても、予備の系統に切り替えるなどして稼働を継続し、どのくらい障害に耐えられるのかを示す度合いのことを指す。

耐障害性(サーバ)に関して決めるべき項目は2点存在する。

  1. 冗長化(機器)
  2. 冗長化コンポーネント

以下、順に説明する。

冗長化(機器)

機器の冗長化とは、サーバーを複数用意することを意味する。サーバーも色々あるので、特定のサーバーだけ複数用意するのか、それとも全サーバー複数用意するのかについて議論が必要だ。下記図に、冗長化のイメージを示す。

f:id:req-definer:20220214212134j:plain

冗長構成

当たり前だが、冗長化をするとコストに跳ね返ってくる。業者に見積をしてもらって、どこまでサーバーを冗長化するのかを決めるとよい。

冗長化コンポーネント

コンポーネント冗長化とは、サーバー内部の部品を複数用意することを意味する。コンポーネントとは筐体を構成する部品(ディスク、電源、FAN、ネットワークカード等)のことだ。よくある例は、ディスクの冗長化(RAID - Wikipedia)だ。部品の冗長化に関しても色々なパターンが存在するので、メリットデメリットを見極めて冗長化の検討をする必要がある。

耐障害性(サーバ)に関するまとめ

f:id:req-definer:20220214213240j:plain

[No6][A.2.1]サーバ

今回は耐障害性(サーバ)について紹介した。障害を経験したことが無い者が、耐障害性について事前検討するというのはなかなか難しい。障害が起こったときに初めてありがたみがわかるからだ。正直、顧客側はどのくらいの冗長化をするべきかイメージがわきにくいかもしれない。会話におけるポイントは、障害が起こってシステムが止まったらどのくらい困るのか?である。障害が起こってシステムが止まったら大変困るのであれば、冗長化の検討をすべきである。以下を顧客とベンダで会話しておこう。

  1. サーバーをどこまで冗長化(※1)すべきか
  2. サーバーの部品(ディスクや電源など)をどこまで冗長化(※1)すべきか

※1 筐体を複数用意することを意味する

結論:非機能要件として、サーバーの冗長性について合意しよう