Zenn
NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.4 オンライン編-A1継続性(前半)

Junichiroh Hirose
に公開
金融
非機能
可用性
信頼性
基幹システム
tech

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。
※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

本記事（Vol.4）では、Vol.5と併せて、オンラインサービスの「A 可用性」における「A.1 継続性」に焦点を当てて解説します。

A 可用性

中項目「A.1 継続性」の前に、まず、大項目「A 可用性」について解説します。

損失金額と対策費用
可用性要件は、「損失金額（※実線）」と「対策費用（※破線）」のバランスのとれたポイント（※グラフの点）を狙って定めることが望まれます。
特に、業務停止による損失金額が急激に増加する時間（※グラフの点）をターゲットに、RTO（目標復旧時間）を設定することで、適切な要件を策定できます。

📌 信頼性・可用性について

一般的に「信頼性」は「可用性」を内包する広義の概念 として扱われます。
また「可用性」を評価する指標として「稼働率（%）」が広く用いられています。
一方、非機能要求グレードの「可用性」は、JISの「信頼性」に相当すると考えられます。

  • 2009年にIPAに寄贈された 非機能要求グレードでは「可用性」を以下のように定義しており、「信頼性」という独立した項目は存在しません[3]。

    システムサービスを継続的に利用可能とするための要求[4]

  • その後策定された JIS-Z8115:2019[5]では「信頼性」を以下のように定義しています。

    アイテムが，与えられた条件の下で，与えられた期間，故障せずに，要求どおりに遂行できる能力
    注記6 ソフトウェア信頼性は，特定条件下で使用するときのある性能を維持する能力を指す場合がある。

  • 近年パブリッククラウドの普及に伴い、IaaSのSLAやSLOでは「可用性(稼働率(%))」と「堅牢性・耐久性(データ損失リスク(%))」を独立した指標として採用するケースが一般的となっています。
    なお、「信頼性」は、広範な概念であり具体的な測定が難しいため、SLAやSLOには使われていないようです。

  • Reliability(信頼性)の概念は、1970年代にIBMが提唱したRAS[6]に遡ることができ、RASでは「信頼性」と「可用性」を異なる要素 として定義されています。（下表参照）

RASの要素 和訳 代表指標 平たく言うと 非機能要求グレード「A 可用性」の中項目
Reliability 信頼性 MTBF 壊れにくさ A.2.耐障害性
Availability 可用性 稼働率(%) 使える程度 A.1.継続性（小項目: A.1.1.稼働率(%)）
Serviceability 保守性 MTTR 直しやすさ A.4.回復性
- A.3.災害対策

A.1 継続性

オンラインサービスの継続性要件は、中項目「A.1 継続性」で定義します。

下表は、非機能要求グレード 大項目「A 可用性」-中項目「A.1 継続性」を抜粋したものです。
なお、継続性のメトリクスは全て「〇：重要項目」となっています。

表: 「A.1 継続性」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
A 可用性 A.1 継続性 A.1.1 運用スケジュール A.1.1.1 〇 運用時間（通常）
A.1.1.2 〇 運用時間（特定日）
A.1.1.3 〇 計画停止の有無
〃 〃 A.1.2 業務継続性 A.1.2.1 〇 対象業務範囲
A.1.2.2 〇 サービス切替時間
A.1.2.3 〇 業務継続の要求度
〃 〃 A.1.3 目標復旧水準
　　（業務停止時）		 A.1.3.1 〇 RPO（目標復旧地点）
A.1.3.2 〇 RTO（目標復旧時間）
A.1.3.3 〇 RLO（目標復旧レベル）
〃 〃 A.1.4 目標復旧水準
　　（大規模災害時）		 A.1.4.1 〇 システム再開目標
〃 〃 A.1.5 稼働率 A.1.5.1 〇 稼働率

以降、小項目ごとに解説します。
なお、中項目「A.1 継続性」で1万文字を大幅に超えるため、2つの記事に分割しました。
後半の小項目「A.1.4」「A.1.5」については、Vol.5を参照ください。

A.1.1 運用スケジュール

小項目 メトリクス(〇: 重要項目)
A.1.1 運用スケジュール
システムの稼働時間や停止運用に関する情報。		 A.1.1.1 〇 運用時間（通常）
A.1.1.2 〇 運用時間（特定日）
A.1.1.3 〇 計画停止の有無
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
A.1.1.1
〇
運用時間（通常）		 0: 規定無し
1: 定時内（9時～17時）
2: 夜間のみ停止（9時～21時）
3: 1時間程度の停止有り（9時～翌朝8時）
4: 若干の停止有り（9時～翌朝8時55分）
5: 24時間無停止

【メトリクス】
運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。
【レベル】
（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。
規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している
（例：障害発生に備えた予備システム、開発・検証用システム等）。
定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。
停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。
24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。
A.1.1.2
〇
運用時間（特定日）		 0~5: レベルは A.1.1.1 と同

【メトリクス】
特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のことを指す。
特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある
（例：「月～金はレベル2だが、土日はレベル0」、
「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。
また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を整合すること。
【重複項目】
C.1.1.2。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。
A.1.1.3
〇
計画停止の有無		 0: 計画停止有り（運用スケジュールの変更可）
1: 計画停止有り（運用スケジュールの変更不可）
2: 計画停止無し

【運用コストへの影響】
計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。
【重複項目】
C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。

📌システムサービス提供日時を定義

  • 「運用スケジュール」では、システムサービスを起動・停止する単位ごとに、サービス提供日時(運用時間)を定義します。
    具体的には、通常日[A.1.1.1]および特定日[A.1.1.2]の運用時間、並びにそれ以外の計画停止[A.1.1.3]について記述します。
  • 「運用スケジュール」は、稼働率[A.1.5]の分母の拠り所となります。
    なお、「C 運用・保守性」でも必要となるため【重複項目】フラグが付いています。

A.1.2 業務継続性

小項目 メトリクス(〇: 重要項目)
A.1.2 業務継続性
可用性を保証するにあたり、要求される業務の範囲とその条件。		 A.1.2.1 〇 対象業務範囲
A.1.2.2 〇 サービス切替時間
A.1.2.3 〇 業務継続の要求度
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
A.1.2.1
〇
対象業務範囲		 0: 内部向けバッチ系業務　　1: 内部向けオンライン系業務　　2: 内部向け全業務
3: 外部向けバッチ系業務　　4: 外部向けオンライン系業務　　5: 全ての業務

【メトリクス】
ここでの対象業務範囲とは、稼働率を算出する際の対象範囲を指す。
【レベル】
内部向けとは対象とするシステム内に閉じた処理（業務）、
外部向けとは他システムとの連携が必要な処理（業務）を表している。
A.1.2.2
〇
サービス切替時間		 0: 24時間以上　　1: 24時間未満　　2: 2時間未満
3: 60分未満　　　4: 10分未満　　　5: 60秒未満

【メトリクス】
サービス切替時間とは、想定できる障害（例えばハードウェアの故障等により業務が一時的中断するケースなど）に対して、対策を施すこと
（例えばクラスタ構成でのサーバの切替えなど）により、業務再開までに要する時間を指す。
【運用コストへの影響】
中断を許容する時間が長くなれば、復旧対策としてはシステムでの自動化から人員による手動での対処に比重が移るため、運用コストへの影響が出てくる。
A.1.2.3
〇
業務継続の要求度		 0: 障害時の業務停止を許容する
1: 単一障害時は業務停止を許容せず、処理を継続させる
2: 二重障害時でもサービス切替時間の規定内で継続する

【メトリクス】
業務継続の要求度とは、発生する障害に対して、どこまで業務を継続させる必要があるかを示す考え方の尺度を示している。
システムを構成する機器や部位には、単一障害点SPOF（Single Point Of Failure）が多数存在し、システム停止となるリスクを多く含んでいる。これらのSPOFを許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目となる。

📌HWのSPOF対策レベルを定義

  • 「業務継続性」では、広義の業務の継続性ではなく、HWのSPOF(Single Point of Failure)対策など年数回起こりうる、よくある障害に限定した信頼性対策を定義します。
    具体的には、冗長化構成による自動復旧、もしくは機械的に手順化された作業で復旧可能な障害に対して、RPO/RTO/RLOを網羅して記述します。
    これらは、冗長化レベルや保守運用レベルなどの拠り所となります。
要件定義観点 該当メトリクスなど
RPO（目標復旧地点）　: Recovery Point Objective (暗黙に、ゼロ: 障害発生時点)
RTO（目標復旧時間）　: Recovery Time Objective A.1.2.2 サービス切替時間
RLO（目標復旧レベル）: Recovery Level Objective A.1.2.1 対象業務範囲
  • 冗長化方式は、サービス切替時間[A.1.2.2]に応じて、ある程度限定されます。（下表参照）
切替時間の目安 冗長化方式 備考
1日程度
Lv.1: 24時間未満		 故障部品交換（冗長化なし） ・CE対応を含む有人対応
1時間程度
Lv.2: 2時間未満		 予備機への手切替 ・常駐要員による有人対応
30～15分程度
Lv.3: 60分未満		 コールドスタンバイ構成 ・OSを含むの自動再起動（再配置を含む）
・仮想化基盤やクラウドに多い
5～1分程度
Lv.4: 10分未満		 ホットスタンバイ構成（HA構成） ・待機系OSへの切替、ミドルウェア起動、
共有ストレージ等の排他リソース切替など
を伴う重たいHA構成
1分未満
Lv.5: 60秒未満		 ホットスタンバイ構成（HA構成）
両現用構成（Act-Act）		 ・あらかじめミドルウェアを起動した
待機系への経路切替のみの軽いHA構成
・両現用構成の場合でも検知～切替の間
滞留や停止が発生する
・滞留の影響を無視できなくなるため
負荷の下で切替時間の検証が必要

  • また、輻輳、半死に（スプリットブレイン、HW障害時の冗長化機能不全など）などにも自動復旧を求めることは、「A.1.2.3 のレベル2: 二重障害時でもサービス切替時間の規定内で継続」に該当します。
    しかし、このレベルの対策は非常に高度であり、まずは実現方式のフィージビリティを確認する必要があります。そのうえで、非機能要件を実現するために必要な制御系の機能要件を定め、実現可能な要件へ具体化していく必要があります。

  • なお、ロードバランシング構成などを採用した場合における性能縮退については、「B.2 性能目標値」に記述します。

A.1.3 目標復旧水準（業務停止時）

小項目 メトリクス(〇: 重要項目)
A.1.3 目標復旧水準（業務停止時）
業務停止を伴う障害が発生した際、何をどこまで、
どれ位で復旧させるかの目標。		 A.1.3.1 〇 RPO（目標復旧地点）
A.1.3.2 〇 RTO（目標復旧時間）
A.1.3.3 〇 RLO（目標復旧レベル）
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
A.1.3.1
〇
RPO
（目標復旧地点）		 0: 復旧不要
1: 5営業日前の時点（週次バックアップからの復旧）
2: 1営業日前の時点（日次バックアップからの復旧）
3: 障害発生時点　 （日次バックアップ+アーカイブからの復旧）

【メトリクス】
RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務再開の整合性の確認は別途必要となる。
【レベル3】
障害発生時点とは、障害が発生する直前のトランザクションなどの処理が完了している時点のことを指し、障害発生時点まで復旧するためには、発生直前の完了した処理のジャーナルログが保証されていることが前提となる。
またジャーナルログをアーカイブすることで、障害発生までの任意の時点への復旧に対応することを想定している。
A.1.3.2
〇
RTO
（目標復旧時間）		 0: 1営業日以上　　1: 1営業日以内　　2: 12時間以内
3: 6時間以内　　　4: 2時間以内

【メトリクス】
サービス切替時間（A.1.2.2）での復旧時間と異なり、RTOでの復旧時間は、業務の継続対策を実施していない （業務停止となる）ケースでの障害での復旧時間を指している。
RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務再開の整合性の確認は別途必要となる。
A.1.3.3
〇
RLO
（目標復旧レベル）		 0: システムの復旧　　1:特定業務のみ　　2:全ての業務
【メトリクス】
業務停止を伴う障害が発生した際、何を復旧の対象とするかのレベルを示す。
【レベル0】システムの復旧は、ハードウェアの復旧だけでなくデータのリストアまでを対象とする。
【レベル1】特定業務とは、例えばA.1.2.1対象業務範囲で定義する継続性が要求される業務などを指す。

📌有人対応時の障害復旧を定義

  • 「目標復旧水準（業務停止時）」では、「A.1.2 業務継続性」による復旧が困難な場合、つまり基本的に有人判断を伴い、かつ「A.1.4 目標復旧水準（大規模災害時）」には該当しないケースにおけるシステム復旧要件を定義します。
    この復旧要件は、HWのSPOFだけでなく、アプリケーションのバグ、オペレーションミス、データ破壊、半死になどの二重障害を含む、広範な障害への対応を考慮します。
    具体的には、復旧対応作業パターンごとに、A.1.2と同様に、RPO/RTO/RLOを網羅して記述します。

  • 目標復旧水準を実現するために必要となる対応は、基本的に有人対応となるため、「C 運用・保守性」にまとめます。
    また、代替運用(BCP)については、メトリクス「代替業務運用の範囲[A.4.1.2][C.3.1.2]」を持つ小項目「回復性」に記述します。

あったら怖い本当の話

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

可用性要件

・「社会的影響が極めて大きいシステム」と同等

😱チーム間連携不足で障害長期化（2日停止）

新システムへの移行作業は順調に進み、朝から新システムが稼働し始めました。

敗因

  1. 試験シナリオ不足：十分なカバレッジの試験を実施していましたが、特定データのときにのみ踏むバグだったため、すり抜けました。もし、本番データを使った試験をしていれば、未然に検出できていました。
  2. 障害対応態勢(備え): AP有識者を1日目に、業務影響把握とAP改修方針の検討に専念させていました。
    AP有識者が、原因究明チームの解析状況を適宜聞いてコメントしていれば、4時間程度で原因究明し、1日目の日中に復旧できた可能性がありました。
  3. 実績の軽視: 1日目の緊急AP修正は、業務影響が少ないものの稼働実績のない仕様でした。業務影響は大きいものの稼働実績のある対応案もあり、そうしていれば2日目に復旧できた可能性がありました。

再発防止

  1. 試験シナリオ不足対策： ロジックに着目した、ホワイトボックス/ブラックボックステストに加えて、データに着目した、本番データを使ったリグレッション試験を必須としました。
  2. 障害対応態勢(備え)対策: 障害対応ガイドラインに、以下のガイドを加え、それが必要となるよう障害訓練シナリオを見直しました。
    • 障害時コミュニケーションガイドの整備（障害原因がわからない状態の場合のチーム分けと作業優先度の判断基準、チーム間コミュニケーション基準（2時間毎に、AP有識者は、対策本部と15分、障害解析チームと15分を目安に情報連携時間を割く など））
    • 判断に必要な情報収集作業の手順化
  3. 実績の軽視対策: 障害対応ガイドラインに、以下を定めました。
    • 原則、実績のないオペレーションを行わないこと。
    • 実績のないオペレーションを行なわざるを得ない場合は、実績のあるコンティンジェンシープランを用意すること
    • オペレーショナルレジリエンスとして、予め網羅的にコンティンジェンシープランを整備しておくこと

まとめ

本記事では、オンライン処理に関わる可用性(信頼性)を確保するには、２重化等のシステム基盤の対応だけでなく障害対応態勢(備え)が必要となることを説明しました。

最後に、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
    ↩︎

  3. 信頼性：2018年改定版の追加項目「A 可用性 - A.2.耐障害性 - A.2.4 ネットワーク」の説明文に「ネットワークの信頼性を向上させるための要求。」と使われているのみ ↩︎

  4. 可用性の定義: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の 01_利用ガイド解説編.pdf 14枚目 P14 表 1.3.2.1 非機能要求グレードの 6 大項目 ↩︎

  5. JIS-Z8115:2019『ディペンダビリティ（総合信頼性） (Glossary of Terms Used in Reliablity)』 https://kikakurui.com/z8/Z8115-2019-01.html P10 192-01-24 用語「信頼性」の定義より ↩︎

  6. RAS: ウィキペディア「RASIS」参照 ↩︎

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

Discussion