非機能要求グレードの歩き方 Vol.12 バッチ編-A1継続性

はじめに - Vol.12

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

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

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

---

A.1 継続性

バッチ処理の継続性要件は、中項目「A.1 継続性」で定義します。
オンライン処理および処理方式に依らない事項については、
A.1.1～3 は、Vol.4 オンライン編-A1継続性(前半) を、
A.1.4～5 は、Vol.5 オンライン編-A1継続性(後半) を参照ください。

下表は、非機能要求グレード 大項目「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 〇 稼働率

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

以降、小項目ごとに解説します。
なお、メトリクスは、Vol.4、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。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。

📌要件はオンラインと別に定義

• 「運用スケジュール」として、オンラインと同様、システムサービスを起動・停止する単位（バッチの場合、一連のジョブネット）ごとに、サービス提供日時(運用時間)を定義します。
  オン中バッチや夜間バッチなども、異なるバッチとして各々の運用時間を定義する必要があります。
• オンラインと別に、バッチ処理を実行する時間帯を定義します。
  オンライン処理とバッチ処理の稼働時間を区別しないシステム構成とすることはありますが、それは設計した結果であり、要件としては分けて定義する必要があります。
• 例）1:00と3:00に起動するバッチ処理が通常30分を要し、5:00までに処理完了が求められる場合　⇒　運用時間は、1:00～5:00
  　- 開始時刻: 上流システムから必要な情報がそろい、最初に処理を開始するタイミング
  　- 終了時刻: 後続システムに最後の処理結果を渡す時限

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を許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目となる。

📌切替時間はAP再処理時間を含む

• バッチ処理は、障害などで内部的に停止しても、利用者は「処理結果が届かない」ことでしか障害を認識できません。そのため、バッチの可用性要件は「バッチ処理の終了見込み時刻」と「最終処理終了時限」から逆算して定まります。
• 「A.1.2.2 サービス切替時間」で想定できる障害対策として、バッチジョブがエラー停止した際の再処理に要する時間を考慮する必要があります。
• 要件例）
  • 障害発生時に、すべて再処理できるよう、バッチ処理時間帯の半分の時間でバッチ処理を完了すること（例：0:00～5:00の夜間バッチ処理は、障害がなければ2.5時間以内に完了）
  • 障害で中断した箇所から再開できること（例：ジョブネットの当該ジョブから再開、大量更新ジョブは中断時点のデータから再開）

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対象業務範囲で定義する継続性が要求される業務などを指す。

📌バッチのRTOは時限順守レベル

• バッチ処理は障害で停止しても即座に業務が止まるわけではなく、処理終了時限を超過した時点が事実上の業務停止に相当します。
• したがって、目標復旧時間（RTO）の要件は、「バッチ処理終了時限をどの程度まで超過して許容できるか」を時間で表すことで定義します。

A.1.4 目標復旧水準（大規模災害時）

小項目	メトリクス(〇: 重要項目)
A.1.4 目標復旧水準（大規模災害時） 大規模災害が発生した際、どれ位で復旧させるかの目標。 大規模災害とは、火災や地震などの異常な自然現象、あるいは人為的な原因による大きな事故、破壊行為により生ずる被害のことを指し、 システムに甚大な被害が発生するか、電力などのライフラインの停止により、システムをそのまま現状に修復するのが困難な状態となる災害をいう。	A.1.4.1 〇 システム再開目標

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

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.1.4.1 〇 システム再開目標	0: 再開不要　　　　　1: 数ヶ月以内に再開　　2: 一ヶ月以内に再開 3 :一週間以内に再開　4: 3日以内に再開　　　5: 1日以内に再開 【メトリクス】 大規模災害としては、RPO、RTO、RLOなどの細かな要求までは確定せず、 システム再開目標として大まかな復旧時間を設定する。 目標復旧レベルについては、業務停止時の目標復旧水準を参考とする。

• オンラインと別にバッチ固有の目標復旧水準を定めること以外に、バッチとして特筆すべき事項はありません。
• なお、バッチ処理途中状態からの復旧には、中間ファイルを災対センターに転送することが必要となるため、一般的には オンラインと整合性のとれた「バッチ処理開始時点」へロールバックして復旧することを要件とします。

A.1.5 稼働率

小項目	メトリクス(〇: 重要項目)
A.1.5 稼働率 明示された利用条件の下で、システムが要求されたサービスを提供できる割合。 明示された利用条件とは、運用スケジュールや、目標復旧水準により定義された業務が稼働している条件を指す。 その稼働時間の中で、サービス中断が発生した時間により稼働率を求める。	A.1.5.1 〇 稼働率

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

項番 メトリクス	レベル0/1/2/3/4/5 備考
A.1.5.1 〇 稼働率	0: 95%以下　1: 95%　　　2: 99% 3: 99.9%　　4: 99.99%　 5: 99.999% 【レベル】 24時間365日の稼働の場合、1年間で業務が中断する時間の合計は、それぞれ以下の通りとなる。 95%・・・・・・・・・18.3日 99%・・・・・・・・・87.6時間 99.9%・・・・・・・ 8.76時間 99.99%・・・・・・ 52.6分 99.999%・・・・・ 5.26分 また1日8時間で週5日稼働のシステムではサービス切替時間と稼働率の関係は以下の通りとなる。 週に1時間・・・・97.5% 月に1時間・・・・99.4% 年に1時間・・・・99.95%

📌バッチの稼働率は不要

• バッチ処理は障害で停止しても即座に業務が止まるわけではないので、稼働率の概念はバッチにそぐいません。
• バッチ処理 「環境」の稼働率であれば、バッチ処理時間帯のうちバッチを処理できる時間から算出することはできますが、要件として定義するほどの指標ではありません。
• 要件としてバッチの稼働率を提示する場合、再処理時間などを含まないバッチ処理環境の稼働率など、その算出根拠（数値の定義）を添えて提示する必要があります。

あったら怖い本当の話

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

😱商品マスター配信が全停止を招いた日

以下の依存関係のある運転スケジュールとなっていました。

1. 20:00～21:00（通常1時間） 商品マスター更新（バッチ処理）
   ※翌営業日の商品マスター更新情報を収集・加工し、各システムに配信
2. 0:00～6:00（通常4時間）　夜間バッチ処理
3. 8:00～9:00（通常1時間）　オンライン事前開放（予約取引登録）
4. 9:00～ 　　　　　　　　　　オンライン本開放

• 19:00　ストレージ障害でOA用ファイルサーバが停止。
  　 　　予約情報を収集できず、商品マスター更新（バッチ処理）が開始できない。

1. 3:00　OA用ファイルサーバ復旧　⇒商品マスター更新（バッチ処理）開始
2. 4:00 「商品マスター更新」終了(通常21:00終了から7時間遅延）
   　 　　夜間バッチ処理開始（通常 0:00開始から4時間遅延）
3. 9:00 夜間バッチ終了（時限超過3時間）。
   　 　　オンライン事前開放（8:00～9:00）に間に合わず
4. オンライン事前開放ができなかったため、運用規定に基づき、終日オンライン本開放を停止

敗因

• OA環境のファイル停止が、静的マスター情報更新バッチに連鎖し、オンライン開始に致命的影響を及ぼすリスクを把握していませんでした。

• オンライン開始の前提となる処理を実施するには、以下のRTOを満たす必要がありました。
  今回、OA用ファイルサーバーの19:00～3:00の8時間停止が要件を大幅超過していました。

  処理名	通常 処理時間	通常 処理終了時刻	RTO時限	RTO
  OA用ファイルサーバ	-	20:00	23:00	3時間（※1）
  商品マスター更新（バッチ処理）	1時間	21:00	0:00	2時間（※2）
  夜間バッチ処理	6時間	6:00	8:00	2時間（※3）

  ※1: 20:00のファイル参照を23:00まで許容
  ※2: 障害時最初から再実行要
  ※3: エラー時、エラー箇所から処理再開

再発防止

• バッチ処理やOA環境など、重要業務の前提となる周辺処理を洗い出し、RTOを見直して必要なシステム改修を実施しました。
• レジリエンス対応として、オンライン本サービス開始に必要な条件を最小化。
  例:マスター更新が不可でも前営業日情報でオンライン開放できるよう運用・システムを見直し

まとめ

本記事では、バッチの継続性要件は、オンラインと別に定義する必要があることを説明しました。

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