はじめに – Vol.14
本記事では、IPA が公開する 非機能要求グレード の
「C.1 通常運用」に含まれるバッチ処理関連の小項目を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。
筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含め解説します。
シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。
C.1 通常運用
中項目「C.1 通常運用」では、監視やバックアップなど定常的に行う運用の要件を定義します。
下表は、大項目「C 運用・保守性」-中項目「C.1 通常運用」を抜粋したものです。
表: 「C.1 通常運用」の小項目とメトリクス(折りたたんでいます)
大項目 | 中項目 | 小項目 | メトリクス(〇: 重要項目) |
---|---|---|---|
C 運用・保守性 | C.1 通常運用 | C.1.1 運用時間 | C.1.1.1 ○ 運用時間(通常) C.1.1.2 ○ 運用時間(特定日) |
〃 | 〃 | C.1.2 バックアップ | C.1.2.1 データ復旧範囲 C.1.2.2 ○ 外部データの利用可否 C.1.2.3 ○ バックアップ利用範囲 C.1.2.4 ○ バックアップ自動化の範囲 C.1.2.5 ○ バックアップ取得間隔 C.1.2.6 ○ バックアップ保存期間 C.1.2.7 バックアップ方式 |
〃 | 〃 | C.1.3 運用監視 | C.1.3.1 ○ 監視情報 C.1.3.2 ○ 監視間隔 C.1.3.3 システムレベルの監視 C.1.3.4 プロセスレベルの監視 C.1.3.5 データベースレベルの監視 C.1.3.6 ストレージレベルの監視 C.1.3.7 サーバ(ノード)レベルの監視 C.1.3.8 端末/ネットワーク機器レベルの監視 C.1.3.9 ネットワーク・パケットレベルの監視 |
〃 | 〃 | C.1.4 時刻同期 | C.1.4.1 時刻同期設定の範囲 |
以降、小項目ごとに解説します。
C.1.1 運用時間 (オンと同様)
メトリクス内容(折りたたんでいます)
小項目 | メトリクス(〇: 重要項目) |
---|---|
C.1.1 運用時間 システム運用を行う時間。利用者やシステム管理者に対してサービスを提供するために、システムを稼動させ、オンライン処理やバッチ処理を実行している時間帯のこと。 |
C.1.1.1 〇 運用時間(通常) C.1.1.2 〇 運用時間(特定日) |
項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
---|---|
C.1.1.1 〇 運用時間(通常) |
0: 規定無し 1: 定時内(9時~17時) 2: 夜間のみ停止(9時~21時) 3: 1時間程度の停止有り(9時~翌朝8時) 4: 若干の停止有り(9時~翌朝8時55分) 5: 24時間無停止 【メトリクス】 |
C.1.1.2 〇 運用時間(特定日) |
0~5: レベルは A.1.1.1 と同
【メトリクス】 |
- 「C.1.1 運用時間」のメトリクスは、「A.1.1 運用スケジュール」と重複しています。
そのため、片方の小項目には具体的な内容を記述し、もう片方は参照の記述のみにとどめることを推奨します。
C.1.2 バックアップ
小項目 | メトリクス(〇: 重要項目) |
---|---|
C.1.2 バックアップ システムが利用するデータのバックアップに関する項目。 |
C.1.2.1 データ復旧範囲 C.1.2.2 〇 外部データの利用可否 C.1.2.3 〇 バックアップ利用範囲 C.1.2.4 〇 バックアップ自動化の範囲 C.1.2.5 〇 バックアップ取得間隔 C.1.2.6 〇 バックアップ保存期間 C.1.2.7 〇 バックアップ方式 |
メトリクス内容(折りたたんでいます)
項番 メトリクス |
備考の【メトリクス】の抜粋、レベル |
---|---|
C.1.2.1 データ復旧範囲 |
データバックアップ以外に、システムバックアップも必要 0: 復旧不要 1: 一部の必要なデータのみ復旧 2: システム内の全データを復旧 ※一部の必要なデータとは、業務継続性の要求を満たすために必要となるデータ |
C.1.2.2 〇 外部データの利用可否 |
外部データとは、当該システムの範囲外に存在するシステムの保有するデータ 0: 全データの復旧に利用できる 1: 一部のデータ復旧に利用できる 2: 外部データは利用できない |
C.1.2.3 〇 バックアップ 利用範囲 |
マルウェア等によるデータ損失への備えや、監査のためのログの退避など、セキュリティ観点のバックアップも考慮すること。 0: バックアップを取得しない 1: 障害発生時のデータ損失防止 2: ユーザエラーからの回復 3: データの長期保存(アーカイブ) |
C.1.2.4 〇 バックアップ 自動化の範囲 |
0: 全ステップを手動で行う 1: 一部のステップを手動で行う 2: 全ステップを自動で行う |
C.1.2.5 〇 バックアップ 取得間隔 |
0: バックアップを取得しない 1: システム構成の変更時など、任意のタイミング 2: 月次で取得 3: 週次で取得 4: 日次で取得 5: 同期バックアップ |
C.1.2.6 〇 バックアップ 保存期間 |
主に可用性の観点で実施されるバックアップの世代管理とは別に、 ここではデータ保全という観点でバックアップデータの保存期間を検討する。 0: バックアップを保存しない 1: 1年未満 2: 3年 3: 5年 4: 10年以上有限 5: 永久保存 |
C.1.2.7
バックアップ |
0: バックアップ無し 1: オフラインバックアップ ※システム(あるいはその一部)を停止させて行う 2: オンラインバックアップ ※システムを稼働中の状態で行う方式 3: オフラインバックアップ+オンラインバックアップ |
メトリクス内容:全文(長文です)
項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
---|---|
C.1.2.1 データ復旧範囲 |
0: 復旧不要 1: 一部の必要なデータのみ復旧 2: システム内の全データを復旧 【メトリクス】 |
C.1.2.2 〇 外部データの利用可否 |
0: 全データの復旧に利用できる 1: 一部のデータ復旧に利用できる 2: 外部データは利用できない 【メトリクス】 |
C.1.2.3 〇 バックアップ 利用範囲 |
0: バックアップを取得しない 1: 障害発生時のデータ損失防止 2: ユーザエラーからの回復 3: データの長期保存(アーカイブ) 【メトリクス】 |
C.1.2.4 〇 バックアップ 自動化の範囲 |
0: 全ステップを手動で行う 1: 一部のステップを手動で行う 2: 全ステップを自動で行う 【メトリクス】 |
C.1.2.5 〇 バックアップ 取得間隔 |
0: バックアップを取得しない 1: システム構成の変更時など、任意のタイミング 2: 月次で取得 3: 週次で取得 4: 日次で取得 5: 同期バックアップ |
C.1.2.6 〇 バックアップ 保存期間 |
0: バックアップを保存しない 1: 1年未満 2: 3年 3: 5年 4: 10年以上有限 5: 永久保存 【メトリクス】 |
C.1.2.7
バックアップ |
0: バックアップ無し 1: オフラインバックアップ 2: オンラインバックアップ 3: オフラインバックアップ+オンラインバックアップ 【レベル】 |
純バッチとオン中バッチは別物
- オンラインと別に、バッチとしてもバックアップ要件を定める必要があります。
- 純バッチは、最悪でもバッチ処理開始時点の静止点のバックアップから再処理できるため、比較的単純な復旧設計が可能です。
- 一方、オン中バッチは、バッチ処理の結果やステータスをオンライン用DBに反映することが多く、ファイルとDBの整合性を考慮してバックアップを取得する必要があります。
オンラインと同様の観点
- なお、オンライン編に記載した以下のポイントは、バッチに対しても必要となります。
- バックアップ取得対象データごとにバックアップ要件を記述
- スナップショット機能の活用
- 📌ランサムウェア対策
- また、バックアップ要件をもとに具体的な方式や取得タイミングを設計する際には、
通常、リストア時間は、バックアップ時間の2倍強となることを踏まえて、
RTO(目標復旧時間)と整合性のとれた設計を行う必要があります。 - 参考:
バックアップ媒体として、それまでのテープ装置に代わり、2010年代よりHDDベースのニアラインストレージが普及していましたが、近年以下の特性が再評価されテープ装置復活の兆しがあります- シーケンシャルアクセスはHDDより高速(リワインド時間は必要)
- 保管コストの安さ(電力効率、体積あたり記憶容量、長期保存)
- ランサムウェア耐性
C.1.3 運用監視
小項目 | メトリクス(〇: 重要項目) |
---|---|
C.1.3 運用監視 システム全体、あるいはそれを構成する ハードウェア・ソフトウェア (業務アプリケーションを含む) に対する監視に関する項目。 セキュリティ監視については本項目には |
C.1.3.1 〇 監視情報 C.1.3.2 〇 監視間隔 C.1.3.3 システムレベルの監視 C.1.3.4 プロセスレベルの監視 C.1.3.5 データベースレベルの監視 C.1.3.6 ストレージレベルの監視 C.1.3.7 サーバ(ノード)レベルの監視 C.1.3.8 端末/ネットワーク機器レベルの監視 C.1.3.9 ネットワーク・パケットレベルの監視 |
メトリクス内容(折りたたんでいます)
項番 メトリクス |
備考の【メトリクス】の抜粋、レベル |
---|---|
C.1.3.1 〇 監視情報 |
監視とは情報収集を行った結果に応じて適切な宛先に発報すること 発報先は「C.4.5.2 監視システムの有無」 本項目は、監視対象としてどのような情報を発信するべきかを決定する 【レベル】 0: 監視を行わない 1: 死活監視を行う ※対象のステータスがオンラインの状態にあるか 2: エラー監視を行う ※対象が出力するログ等にエラー出力が含まれているか 3: エラー監視(トレース情報を含む)を行う ※トレース情報を含む場合は、どのモジュールでエラーが発生しているのか詳細についても判断することができる 4: リソース監視を行う ※CPUやメモリ、ディスク、ネットワーク帯域といったリソースの使用状況 5: パフォーマンス監視を行う ※業務アプリケーションやディスク I/O、ネットワーク転送等の応答時間やスループット |
C.1.3.2 〇 監視間隔 |
0: 監視を行わない 1: 不定期監視(手動監視) 2: 定期監視(1日間隔) 3: 定期監視(数時間間隔) 4: リアルタイム監視(分間隔) 5: リアルタイム監視(秒間隔) |
以降のレベルは同じ |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う 監視情報と監視間隔を個別に確認する必要がある。 レベル1の一部とは、重要度の高いもののみを対象に監視を行うことを想定 |
C.1.3.3 システム レベルの監視 |
業務アプリケーションも含め、そのシステムを構成する複数のサーバ等の状態確認結果から、システムとして機能する状態にあるかどうか バックアップの監視やジョブの監視など |
C.1.3.4 プロセス レベルの監視 |
アプリケーションやミドルウェア等のプロセスが正しく機能しているかどうか プロセスの情報(死活、CPU使用率、メモリ使用率など) |
C.1.3.5 データベース レベルの監視 |
DBMSの機能として提供される情報を確認 ログ出力内容やパラメータ値、ステータス情報、領域使用率等 |
C.1.3.6 ストレージ レベルの監視 |
ディスクアレイ等の外部記憶装置に関して、状態を確認 ディスク使用率等の他、ファームウェアが出力するログ情報など |
C.1.3.7 サーバ(ノード) レベルの監視 |
対象のサーバがOSレベルで正しく機能しているか ハートビート監視など |
C.1.3.8 端末/ネットワーク機器 レベルの監視 |
クライアント端末やルータ等のネットワーク機器に関して状態を確認 ハートビート監視の他、個別のファームウェア等が出力する情報に基づく監視など |
C.1.3.9 ネットワーク・パケット レベルの監視 |
ネットワーク上を流れるパケットの情報を確認 パケットロスやネットワーク帯域の使用率などの監視など |
メトリクス内容:全文(長文です)
項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
---|---|
C.1.3.1 〇 監視情報 |
0: 監視を行わない 1: 死活監視を行う 2: エラー監視を行う 3: エラー監視(トレース情報を含む)を行う 4: リソース監視を行う 5: パフォーマンス監視を行う 【メトリクス】 |
C.1.3.2 〇 監視間隔 |
0: 監視を行わない 1: 不定期監視(手動監視) 2: 定期監視(1日間隔) 3: 定期監視(数時間間隔) 4: リアルタイム監視(分間隔) 5: リアルタイム監視(秒間隔) |
C.1.3.3
システム |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】システムレベルの監視とは、 |
C.1.3.4
プロセス |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】プロセスレベルの監視とは、 |
C.1.3.5
データベース |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】データベースレベルの監視とは、 |
C.1.3.6
ストレージ |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】ストレージレベルの監視とは、 |
C.1.3.7
サーバ(ノード) |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】サーバ(ノード)レベルの監視とは、 |
C.1.3.8
端末/ネットワーク機器 |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】端末/ネットワーク機器レベルの監視とは、 |
C.1.3.9
ネットワーク・パケット |
0: 監視を行わない 1: 一部監視を行う 2: 全て監視を行う
【メトリクス】ネットワーク・パケットレベルの監視とは、 |
すぐに結果が見えないことへの備え
- バッチは、処理直後にその妥当性を即時に把握しにくいという特性を持つため、オンラインと異なる固有の運用監視要件が求められます。
特に、重要業務では、「期待どおり動いたか?」 を能動的に監視することが必要です。
バッチ処理の監視タイミングと確認ポイント
-
処理開始前:処理要求件数の異常検知
- 異常に少ない ⇒ 上流処理の不具合など、処理可能なデータが揃っていない可能性
- 異常に多い ⇒ バッチ処理完了時限を超え、問題が後続処理に波及する恐れ
-
処理途中:処理の進捗状況
- 複雑なジョブネットでは、複数のチェックポイントを設け、
各通過時刻や処理件数が設計想定内に収まっているか監視
- 複雑なジョブネットでは、複数のチェックポイントを設け、
-
処理終了後:処理結果の妥当性確認
- 空振りしていないか(例:0件処理)
- 件数は正常でも内容が業務的に失敗していないか(エラー多発、実行結果不整合(※)など)
※ 金融の業務システムでは、人のようにミスなどしないはずのシステムに対しても、バグやオペミスなどの対策として、異なる観点で集計した数字を突合するなど、けん制機能として整合性検証処理をアプリケーションとして作成するのが一般的です。
オンラインと同様の観点
- なお、メトリクスの観点、およびオンライン編に記載した以下のポイントは、バッチに対しても必要となります。
- 監視要件の記述
- 📌閾値は予兆検知とセットで2段階
- 📌リソース監視は1~5秒間隔
C.1.4 時刻同期(特になし)
メトリクス内容(折りたたんでいます)
小項目 | メトリクス(〇: 重要項目) |
---|---|
C.1.4 時刻同期 システムを構成する機器の時刻同期に関する項目。 |
C.1.3.1 時刻同期設定の範囲 |
項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
---|---|
C.1.4.1
時刻同期設定の範囲 |
0: 時刻同期を行わない 1: サーバ機器のみ時刻同期を行う 2: サーバおよびクライアント機器について時刻同期を行う 3: ネットワーク機器も含めシステム全体で時刻同期を行う 4: システム全体を外部の標準時間と同期する 【レベル4】 |
バッチとして特筆すべき事項はありません。
Vol.6 オンライン編-C1通常運用 C.1.4 時刻同期を参照ください。
あったら怖い本当の話
※ 実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。
😱言われて気づいても炎上後
- キャンペーン期間中、ポイント管理システムは特に異常なく稼働していました。
敗因
- 該当ポイントの関連処理を調査したところ、1週間前、オペレーションミスにより、複数ある「ポイント付与ファイル反映」バッチのうち一つのジョブを常駐し忘れていました。
その結果、当該ファイルに計上されているポイントが付与されていませんでした。 - 未処理ファイルのバッチ処理を実行して復旧したものの、既に悪評が炎上しキャンペーンは逆効果となりました。
- 他のジョブはポイントを反映しており、ジョブの起動漏れのためエラーメッセージも出なかったため、能動的にオペミスに気付くことができませんでした。
再発防止
けん制機能として、上流システムが付与した総ポイント数と、反映した総ポイント数を突合していれば、すぐにジョブ起動し忘れに気付けた という反省を踏まえて、以下の運用改善を実施しました。
- 業務運用に 「締め」の概念を導入(まずは日単位の日締め)
- 日締めのタイミングで、接続する各システム間で、総件数と、ポイント数などの総数の情報を交換し、相互に突合し、齟齬があればアラート発報するようにしました。
補足:
日本の銀行は、毎日、締め上げ てます。(いい意味です)
窓口を閉めたあと、店単位–>全店–>全行 へと段階的に、1円のズレもなく勘定があっていることを確認(御明算)する様を締め上げといいます。
A店が単独に御明算でも、B店が御明算にならない原因がA店の締めミスにある可能性があるため、全行の御明算を確認できるまで、全営業店の行員は帰宅できません。
銀行は信用が命なので、銀行業の事務処理やシステムのあらゆるところにけん制機能を組み込んでいます。
まとめ
本記事では、バッチ処理に関わる通常運用は、バッチ処理直後にその妥当性を把握しづらいことを考慮する必要があることを説明しました。
最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。
[募集要領]
[NTTデータ 金融分野の取り組み]
Views: 0