非機能要求グレードの歩き方 Vol.16 A3災害対策/A4回復性

はじめに - Vol.16

本記事では、IPA^[1] が公開する 非機能要求グレード^[2] の「A.3 災害対策」と「A.4 回復性」を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。

筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。

---

A.3 災害対策
A.4 回復性

中項目「A.3 災害対策」では、いわゆる災害対策に関連する要件を定めます。
「A.4 回復性」では、A.4.1で障害対応について、A.4.2で可用性に関する試験品質についての要件を定めます。

非機能要件は、「小項目」ごとに、文章で「レベル」が分かるよう具体的に記述しましょう！
(再掲、大事なことなので繰り返し言います。詳細Vol.1を参照ください）

下表は、大項目「C 運用・保守性」-中項目「A.3 災害対策」「A.4 回復性」の抜粋です。

表: 「A.3 災害対策」「A.4 回復性」の小項目とメトリクス（折りたたんでいます）

大項目	中項目	小項目	メトリクス(〇: 重要項目)
A 可用性	A.3 災害対策	A.3.1 システム	A.3.1.1 　 復旧方針
〃	〃	A.3.2 外部保管データ	A.3.2.1 　 保管場所分散度 A.3.2.2 　 保管方法
〃	〃	A.3.3 付帯設備	A.3.3.1 　 災害対策範囲
〃	A.4 回復性	A.4.1 復旧作業	A.4.1.1 　 復旧作業 A.4.1.2 　 代替業務運用の範囲
〃	〃	A.4.2 可用性確認	A.4.2.1 ○ 確認範囲

以降、小項目ごとに解説します。

A.3.1 システム

小項目	メトリクス(〇: 重要項目)
A.3.1 システム 地震、水害、テロ、火災などの大規模災害時の業務継続性を満たすための要求。	A.3.1.1 　 復旧方針

メトリクス内容（折りたたんでいます）

項番 メトリクス

レベル0/1/2/3/4/5 備考

A.3.1.1 　 復旧方針

0: 復旧しない 1: 限定された構成でシステムを再構築 2: 同一の構成でシステムを再構築 3: 限定された構成を DR サイトで構築 4: 同一の構成を DR サイトで構築 【メトリクス】 大規模災害のための代替の機器として、どこに何が必要かを決める項目。 【レベル】 レベル1および3の限定された構成とは、復旧する目標に応じて必要となる構成（例えば、冗長化の構成は省くなど）を意味する。 レベル2および4の同一の構成とは、復旧後も復旧前と同じサービスレベルを維持するため、本番環境と同一のシステム構成を必要とすることを意味する。 レベル1および2のシステムを再構築を選択する場合、被災後の再構築までを契約の範囲として考えるのではなく、被災したサイトあるいは共用センターなどの設備を利用して、あくまでシステムを再構築する方針とすることを要求するものである。 一方レベル3および4の DR サイトで構築は、指定された DR サイトに復旧用のシステムを構築するところまでを含む。

Disaster Recovery (DR)サイト

• 小項目「A.3.1 システム」には、システムに対する災害対策を記述します。
• DR サイトを設ける場合、以下の要件を定めます。
  • RTO（目標復旧時間）
  • RPO（目標復旧時点）
  • RLO（目標復旧レベル）
  • DR発動基準（災害時、回線障害時、システム復旧の見込みがない時など）

A.3.2 外部保管データ

小項目	メトリクス(〇: 重要項目)
A.3.2 外部保管データ 地震、水害、テロ、火災などの大規模災害発生により被災した場合に備え、データ・プログラムを運用サイトと別の場所へ保管するなどの要求。	A.3.2.1 　 保管場所分散度 A.3.2.2 　 保管方法

メトリクス内容（折りたたんでいます）

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.3.2.1 　 保管場所分散度	0: 外部保管しない 1: 1ヵ所 2: 1ヵ所 (遠隔地) 3: 2ヵ所 (遠隔地)
A.3.2.2 　 保管方法	0: 媒体による保管 1: 同一サイト内の別ストレージへのバックアップ 2: DR サイトへのリモートバックアップ

データに対する災害対策

• 小項目「A.3.2 外部保管データ」には、データに対する災害対策を記述します。

• 主に以下の3分類のデータについて、保管期間、保管世代数、保管媒体、遠隔地保管対策、ネットワーク隔離対策などの保管方針を示す必要があります。

  データの分類	保管媒体の例	遠隔地対策の例	ネットワーク隔離対策の例
  1. 業務データ	バックアップ 専用ストレージ	正センタ、 DRセンタ	世代毎に別ボリュームとし、 バックアップ取得時のみ 使用ボリュームをマウント
  2. 業務アプリケーション	〃	〃	バックアップ取得時のみ マウント
  3. システム設定	可搬媒体 (テープ、DVDなど)	正センタ 本社システム部門	媒体保管庫に保管

• 一般に上記の順にデータ損失の影響が大きく、復旧も難しくなるため、重要なデータには、複数の対策が必要となります。

  被災（例）	有効な対策
  機器（火災、テロ）	別媒体に保管
  広域災害（地震、水害）	遠隔地に保管
  サイバー攻撃（ランサムウェア）	ネットワークから隔離した媒体に保管

A.3.3 付帯設備

小項目	メトリクス(〇: 重要項目)
A.3.3 付帯設備 各種災害に対するシステムの付帯設備での要求。	A.3.3.1 　 災害対策範囲

メトリクス内容（折りたたんでいます）

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.3.3.1 　 災害対策範囲	0: 対策を実施しない 1: 特定の対策を実施する 2: 想定する全ての対策を実施する 【メトリクス】 付帯設備については、システム環境・エコロジーにおいてF.4.1.1の耐震震度、F.4.4.4の停電対策で、災害対策の一部として要求を具体化している。 【レベル】 想定する災害対策としては、以下が考えられる。 　・地震対策 　・瞬電・停電対策 　・火災対策 　・漏電対策 　・雷対策 　・水害対策 　・電界・磁界対策

災害対策用設備（ファシリティ）

• 小項目「A.3.3 付帯設備」には、災害対策に用いる設備（ファシリティー） の要件を記述します。
• データセンタなどの設備は、システム毎に導入するケースは少なく、通常、既存設備や外部リソースを活用します。
  • 既に定めている設備を利用する場合は、その利用条件を明示する必要があります。
  • クラウドサービスなどの外部リソースを利用する場合は、満たすべき条件、もしくは認定サービスを具体的に示す必要があります。
• 大項目「F.システム環境・エコロジー」にもファシリティ要件の項目があります。
  DR サイトについては「F.」に記載し、それ以外の設備については本項にまとめることをお勧めします。

A.4.1 復旧作業

小項目	メトリクス(〇: 重要項目)
A.4.1 復旧作業 業務停止を伴う障害が発生した際の復旧作業に必要な労力。	A.4.1.1 　 復旧作業 A.4.1.2 　 代替業務運用の範囲

メトリクス内容（折りたたんでいます）

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.4.1.1 　 復旧作業	0: 復旧不要 1: 復旧用製品は使用しない手作業の復旧 2: 復旧用製品による復旧 3: 復旧用製品＋業務アプリケーションによる復旧 【重複項目】 C.3.1.1。復旧作業は、可用性と運用・保守性に共通して含まれている。運用・保守性では、復旧目標の運用への影響という観点でその作業を確認するが、可用性は、それを実現するための手段として確認する。 【レベル】 自作ツールを利用するケースは手作業に含む。 復旧用製品とは、バックアップ・リカバリを行う製品を指す。復旧用製品による復旧を行う場合、どこまで自動化するか（自動リカバリー機能充足率など）を定義するケースもあるが、可用性としては、復旧用製品を使用するかしないかでギャップが発生するため、この観点でレベルを検討する。
A.4.1.2 　 代替業務運用の範囲	0: 無し 1: 一部の業務について代替業務運用が必要 2: 全部の業務について代替業務運用が必要 【重複項目】 C.3.1.2。復旧作業は、可用性と運用・保守性に共通して含まれている。運用・保守性では、復旧目標の運用への影響という観点でその作業を確認するが、可用性は、それを実現するための手段として確認する。 【メトリクス】 代替業務運用とは、障害によりシステムが復旧不可能となった場合に、代替業務でカバーすることが可能な運用手段（代替機あるいは人手による運用）を指す。

障害時のシステム対応とBCP

• 小項目「A.4.1 復旧作業」では、システム面(A.4.1.1)と業務運用面(A.4.1.2)について、以下の3つの障害レベル毎に復旧対応方針を定めます。

  1. 一時的な業務停止時: サービス切替時間(※1)内のシステム停止時
  2. システム障害時　　: サービス切替時間を超える業務停止時(※2)
  3. DR 発動時　　　　: 「A.3 災害対策」発動時
  重複項目の「C.3.1 復旧作業」には、 「A.4.1 復旧作業」参照　と記載することを推奨します。

  本項目「A.4.1 復旧作業」（「A 可用性 > A.4 回復性」の小項目）は、
  「C.3.1 復旧作業」（「C 運用・保守性 > C.3 障害時運用」の小項目）と重複項目です。
  運用保守フェーズにおける対応事項という観点もありますが、
  要件としては信頼性要件の方が明確であるため、本項目に具体的に記述し、
  「C.3.1 復旧作業」には　「A.4.1 復旧作業」参照と記載することを推奨します。

  ※1
  サービス切替時間とは、想定できる障害対策（例えばクラスタ構成でのサーバの切替えなど）により、業務再開までに要する時間
  「A.1.2 業務継続性」のメトリクス「A.1.2.2 サービス切替時間」の補足説明より

  ※2
  「C.3.1 復旧作業」の記事「📌高信頼ならベーシックリカバリ(BR)が必要」参照

A.4.2 可用性確認

小項目	メトリクス(〇: 重要項目)
A.4.2 可用性確認 可用性として要求された項目をどこまで確認するかの範囲。	A.4.2.1 ○ 確認範囲

メトリクス内容（折りたたんでいます）

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.4.2.1 ○ 確認範囲	0: 実施しない。または単純な障害の範囲 1: 業務を継続できる障害の範囲 2: 業務停止となる障害のうち一部の範囲 3: 業務停止となる障害の全ての範囲 【レベル】 レベル2および3の確認範囲には、レベル1で定義した内容を含む。

可用性確認試験・訓練の実施方針

• 小項目「A.4.2 可用性確認」では、大項目 「A 可用性」要件に対する要求品質を定めます。

  大項目「B 性能・拡張性」の要求品質は「B.4.2 性能テスト」で定めます。

  • 開発フェーズ：
    実機もしくは机上で障害を起こして実施する、可用性確認試験の実施方針を定めます。
  • 運用保守フェーズ：
    障害対応訓練の有無や実施範囲も本項に記載します。

  可用性要件は非機能に分類されますが、システム制御機能や運用支援機能などの機能とその運用によって実現されます。そのため、理論上は機能要件と同様に、試験によって品質を確認できます。
  しかし、すべての故障パターンを網羅することや、業務処理状態を網羅した障害試験を実施することは困難であるため、可用性確認試験の実施方針を、開発着手前に合意しておく必要があります。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

😱 DR サイト切替は成功したが…

• 災害対策として、オンラインDBの非同期レプリケーションによるDR サイトを保有。
  ただし、DR サイトは機能縮退があり、大幅残業を伴う。
• DR 発動ポリシー： RTO 3 時間超過の見込み、かつDR発動で復旧が見込める場合
  ・災害等で正センタから3時間以上サービスを提供できない状態となった場合、速やかに
  ・システム基盤の障害発生後 2 時間の時点で、RTO 3 時間以内の復旧が見込めない場合

その日は、ピーク日相当の取引が発生していました。

オンライン処理のタイムアウト多発により、システムがスローダウン。
1時間で、DBサーバの応答遅延が原因と特定、ベーシックリカバリ手順を発動し冗長構成のDBサーバ両系を再起動。
2時間後、一時的に復旧したが30分程度で再発したため、DR発動を判断。
3時間後、DR サイトからサービス再開。

しかし、DR サイトからの正センタへの切戻し手順の試験をしていませんでした。
手順確認試験を実施して切戻すまでの3ヵ月間、業務部門・システム部門双方に連日大幅残業を強いることとなってしまいました。

障害原因

• DBの非同期レプリケーション用のDB更新ログバッファ領域があふれると、規定回数リトライした後レプリケーションを停止しますが、リトライの間DB更新ログ出力が待たされる仕様となっていました。
• DBレプリケーションに用いる回線帯域が不足しており、断続的にログバッファがあふれたことにより、DBサーバの応答遅延を引き起こしていました。

敗因

• 非同期レプリケーション用の回線帯域不足がレスポンスに影響するとは思っていませんでした。
  性能試験は、DR サイトを使っていたため、試験で問題を認識することもありませんでした。
• DR発動は災害時など容易に復旧できない状況を念頭に置いていました。
  数日で切り戻す運用が必要となるとは考えておらず、切戻しは机上で技術的に可能なことは確認していたものの、実機で切戻し手順の試験を実施していませんでした。

再発防止

社内ガイドラインとして、DR サイトを設けるシステムを対象に以下を徹底しました

• 性能試験は、DR サイトへの連携機能を含めて実施すること。
  （基本的に、構築時に商用解放前の本番昇格環境で実施）
• 構築時にDR切替手順＆切戻し手順を試験し、RTOの充足を確認すること。

まとめ

本記事では、災害対策、システム復旧作業、BCPについてと、可用性品質レベルは試験方針で示すことを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。

[募集要領]
https://nttdata-career.jposting.net/u/job.phtml?job_code=1172
[NTTデータ 金融分野の取り組み]
https://www.nttdata.com/jp/ja/industries/finance/

脚注

1. IPA（独立行政法人 情報処理推進機構, Information-technology Promotion Agency, Japan）

2. 非機能要求グレード:
   参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
   活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls