はじめに
システムの要件定義において、インフラエンジニアが特に重要視するべき項目の1つが「可用性」です。
近年では、クラウドサービスの普及によって「システムは止まらないもの」という認識を持たれることも増えています。
しかし実際には、ハードウェア障害、ソフトウェア不具合、人的ミス、災害など、システム停止につながる要因は数多く存在します。
そのため、インフラ要件定義では「どこまで止められるのか」「障害時にどこまで復旧する必要があるのか」を事前に整理しておく必要があります。
そこで役立つのが、IPA（情報処理推進機構）の「非機能要求グレード」です。
非機能要求グレードがそもそも何か？については以下の記事にまとめています。
インフラ要件定義で役立つ「非機能要求グレード」とは？実務で感じたメリットと注意点
今回は、その中でも特に重要な「可用性」にフォーカスし、実務でどのように考えるべきかを解説します。
可用性とは何か
IPAでは、可用性を以下のように定義しています。
システムを継続的に利用可能とするための要求
つまり、「できるだけ止まらず、止まっても素早く復旧できること」を定義するのが可用性です。
ただし、ここで重要なのは「絶対に止めない」ことではありません。
実際のシステムでは、
- どこまで停止を許容するのか
- どの業務を優先的に復旧するのか
- どれだけコストをかけるのか
を現実的に整理する必要があります。
例えば、社内向けの勤怠システムと、24時間365日稼働するECサイトでは求められる可用性はまったく異なります。
可用性とは、「業務に対して適切な止まりにくさ」を決める作業とも言えます。
非機能要求グレードにおける可用性の4分類
IPAの非機能要求グレードでは、可用性は以下の4つに分類されています。
- 継続性
- 耐障害性
- 災害対策
- 回復性
この分類が非常によくできており、実務でも整理しやすいポイントです。
継続性｜まず「どこまで止められるか」を決める
可用性で最初に整理すべきなのが「継続性」です。
ここでは主に以下を決めます。
- 運用時間
- 許容停止時間
- 復旧目標
- 稼働率
特に重要なのが、「システムが稼働している状態」を定義することです。
例えば、
- ログインできれば稼働中なのか
- 一部機能停止でも稼働扱いなのか
- バッチ停止は許容されるのか
によって、求める可用性は変わります。
実務では、お客様が「24時間365日止めたくない」と要望することがあります。
しかし詳しくヒアリングすると、
- 夜間は利用者がいない
- 月次処理だけ止めたくない
- 一部業務だけ継続できればよい
といったケースも多くあります。
ここを整理しないまま設計を進めると、必要以上に高価な構成になりやすいため注意が必要です。
例えば、
- 全サーバ冗長化
- マルチリージョン構成
- 常時レプリケーション
などを採用すると、コストは一気に上昇します。
そのため、まずは「何を守るべきか」を明確にすることが重要です。
耐障害性｜冗長化は“必要な範囲”で考える
継続性を整理した後に検討するのが「耐障害性」です。
ここでは主に、
- サーバ冗長化
- ネットワーク冗長化
- ストレージ冗長化
- 電源冗長化
などを検討します。
実務でよくあるのが、「可用性を高める＝全部冗長化する」という考え方です。
しかし、IPAでも記載されている通り、継続性を考慮せずに耐障害性だけを高めると、過剰設計になるケースがあります。
例えば、
- 重要業務は一部だけ
- 復旧まで数十分許容できる
というシステムで、全サーバを即時切替可能なクラスタ構成にすると、コストに対して効果が見合わない場合があります。
逆に、単一サーバ構成でも最低限必要な対策はあります。
特に見落とされやすいのがストレージです。
「サーバは冗長化しないが、データは守りたい」というケースでは、
- RAID構成
- バックアップ取得
- スナップショット
などは最低限必要になります。
実務でも、「サーバは1台構成だから可用性は不要」と考えてしまうと、データ消失時に復旧できなくなるケースがあります。
耐障害性は、「どこまで壊れても業務継続できるか」を整理する視点が重要です。
災害対策｜クラウドでも必須の検討項目
近年はクラウド利用が一般化し、「クラウドだから災害対策は不要」と誤解されることがあります。
しかし実際には、
- リージョン障害
- 大規模停電
- 通信断
- ランサムウェア
- 誤削除
など、クラウドでも可用性リスクは存在します。
そのため、
- バックアップを別リージョンへ保管するか
- DRサイトを構築するか
- 復旧に何時間許容できるか
を整理する必要があります。
特に重要なのは、「今は不要でも将来必要になる可能性」です。
IPAでも触れられている通り、将来的な遠隔バックアップを想定せずに機器選定をすると、後から構成変更できず、二重投資になるケースがあります。
これはオンプレだけでなくクラウドでも同じです。
例えば、
- 将来的にDR化したい
- 海外リージョン利用を検討したい
- バックアップ保持を強化したい
という可能性があるなら、初期段階から設計余地を持たせておくことが重要です。
回復性｜“復旧できること”まで確認する
可用性では、「止まりにくくする」だけでなく、「復旧できること」も重要です。
これが「回復性」です。
ここでは主に、
- バックアップ復元方式
- リストア手順
- 復旧作業の自動化
- 障害試験
などを整理します。
実務では、「バックアップ取得しているから安心」と考えられがちですが、実際にはリストア試験をしていないケースも少なくありません。
しかし、
- 復元に何時間かかるのか
- 手順書で本当に復旧できるのか
- 障害時に誰が対応するのか
を確認していないと、実障害時に復旧できないことがあります。
特にクラウドでは、構築自動化が進んでいる一方で、「手順を知っている担当者しか復旧できない」ケースもあります。
また、可用性確認試験はコストとのバランスも重要です。
本番相当の障害試験は非常に工数がかかるため、
- どこまで確認するか
- どの障害を対象にするか
を早期に合意しておく必要があります。
可用性設計で最も重要なのは「業務目線」
実務で強く感じるのは、可用性はインフラだけで決めるものではないということです。
例えば、
- 「99.99%必要です」
- 「絶対止められません」
という要望があっても、実際には業務影響を整理すると、そこまでの対策が不要なケースもあります。
逆に、
- 夜間停止OK
- 一部業務停止OK
と思っていたら、実は海外拠点が24時間利用していた、というケースもあります。
つまり、可用性は「技術要件」ではなく「業務要件」です。
そのため、
- 何を止めたくないのか
- どこまで復旧したいのか
- どれだけコストをかけられるのか
を、お客様と認識合わせすることが最も重要になります。
非機能要求グレードは、その会話を整理するための非常に優秀なフレームワークだと感じています。
コメント