NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.6 オンライン編-C1通常運用

Junichiroh Hirose
に公開
金融
運用
オンライン
非機能
基幹システム
tech

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

全体構成

「非機能要求グレードの歩き方」シリーズ全体の構成は、「非機能要求グレードの歩き方 Index」を参照ください。
本記事では、オンラインシステムにおける「C.1 通常運用」に焦点を当てて解説します。

使用率の解像度

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時間無停止

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

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

A.1.1 運用スケジュール と同じ

  • 「C.1.1 運用時間」のメトリクスは、「A.1.1 運用スケジュール」と重複しています。
    そのため、片方の小項目には具体的な内容を記述し、もう片方は参照の記述のみにとどめる    ことを推奨します。
  • サービス提供日時(運用時間帯)を定義します。
    具体的には、システムサービスの起動・停止単位ごとに、以下の項目について明記する必要があります。
    • 通常日の運用時間帯[C.1.1.1]
    • 特定日の運用時間帯[C.1.1.2]
    • 計画停止の運用時間帯[A.1.1.3]　※メトリクスは未記載

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: システム内の全データを復旧

【メトリクス】
システムを障害から復旧するためには、データバックアップ以外に、
OSやアプリケーションの設定ファイル等を保管するシステムバックアップも
必要となることが考えられる。
システムバックアップの取得方法や保管方法についても、同時に検討すべきである。
【レベル1】
一部の必要なデータとは、業務継続性の要求を満たすために必要となるようなデータを想定している。
【重複項目】A.2.6.2。
可用性ではデータをどこまで保全するかという観点で、運用ではデータをどこまで復旧させるかという観点で本項目が必要となり、重複項目としている。
C.1.2.2
〇
外部データの利用可否		 0: 全データの復旧に利用できる
1: 一部のデータ復旧に利用できる
2: 外部データは利用できない

【メトリクス】
外部データとは、当該システムの範囲外に存在するシステムの保有するデータを指す（開発対象のシステムと連携する既存システムなど）。
外部データによりシステムのデータが復旧可能な場合、システムにおいてバックアップ設計を行う必要性が減るため、検討の優先度やレベルを下げて考えることができる。
C.1.2.3
〇
バックアップ
利用範囲		 0: バックアップを取得しない
1: 障害発生時のデータ損失防止
2: ユーザエラーからの回復
3: データの長期保存（アーカイブ）

【メトリクス】
マルウェア等によるデータ損失への備えや、監査のためのログの退避など、セキュリティ観点のバックアップも考慮すること。
【レベル2】
ユーザエラーからの回復の場合、システムとしては正常に完了してしまった処理を元に戻さなければならないため、複数世代のバックアップの管理や時間指定回復（Point in Time Recovery）等の機能が必要となる場合が考えられる。
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: オフラインバックアップ+オンラインバックアップ

【レベル】
オフラインバックアップとは、システム（あるいはその一部）を停止させてバックアップを行う方式、
オンラインバックアップとはシステムを停止せず稼働中の状態でバックアップを行う方式を指す。
【重複項目】A.2.6.1。
バックアップ方式は、システムを停止するかどうかの検討が含まれるため、
可用性の観点でも考慮する必要があり、重複項目となっている。

バックアップ要件の記述

  • 小項目の「バックアップ」全体として要件を記述します。
    具体的には、バックアップ取得対象データごとに[C.1.2.1～2]、以下の項目について明記する必要があります。
    • バックアップデータの利用目的[C.1.2.3]
    • バックアップ取得方法（自動化、取得間隔、保存期間、方式）[C.1.2.4～7]
  • バックアップ取得対象データによってレベルが異なるため、メトリクスのレベル選択だけで要件を表現することはできません。
    メトリクスのレベルを選択する場合は、視認性を向上させるための参考情報として、レベル内で最も高いレベルを選択します。

スナップショット機能の活用

  • ユーザーエラーからの回復[C.1.2.3 レベル2]の要件に対して、スナップショット機能を持つファイルシステム[3]やストレージを採用することで、バックアップを取得せずに対応可能です。
    この場合、バックアップ取得作業を行わないことがありますが、小項目「バックアップ」の要件として記述します。
  • 同期レプリケーションの切り離しなどを活用することで、無停止で静止点のバックアップを1世代取得することができるストレージやファイルシステムがあります。
    さらに、切り離した静止点を基にバックアップを取得し、複数世代のバックアップを保持することで、スナップショットを適切に管理することが可能です。
    なお、最近では、ランサムウェア対策を兼ねたスナップショットを複数世代取得できるストレージも登場しています。

📌ランサムウェア対策

  • ランサムウェア対策が必要な場合、バックアップ要件にその旨を明記することが必要です。
  • 近年、ランサムウェア[4]の被害が増加しています。
    従来は金銭目的の攻撃が中心でしたが、地政学的リスクの増大に伴い、データ破壊を目的とする攻撃も増えています。
  • ランサムウェア攻撃は、容易にデータを復旧できないように、バックアップデータを含めて攻撃（暗号化）します。
    その対策として、バックアップデータやスナップショットは、元データのあるネットワークから隔離された場所に退避し、攻撃による同時破壊を防ぐ必要があります。

C.1.3 運用監視

小項目 メトリクス(〇: 重要項目)
C.1.3 運用監視
システム全体、あるいはそれを構成する
ハードウェア・ソフトウェア
（業務アプリケーションを含む）
に対する監視に関する項目。

セキュリティ監視については本項目には
含めない。
「E.7.1 不正監視」で別途検討すること。		 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.4.5.2 監視システムの有無」 で確認すること。
【レベル】
死活監視とは、対象のステータスがオンラインの状態にあるかオフラインの状態にあるかを判断する監視のこと。
エラー監視とは、対象が出力するログ等にエラー出力が含まれているかどうかを判断する監視のこと。トレース情報を含む場合は、どのモジュールでエラーが発生しているのか詳細についても判断することができる。
リソース監視とは、対象が出力するログや別途収集するパフォーマンス情報に基づいてCPUやメモリ、ディスク、ネットワーク帯域といったリソースの使用状況を判断する監視のこと。
パフォーマンス監視とは、対象が出力するログや別途収集するパフォーマンス情報に基づいて、業務アプリケーションやディスク I/O、ネットワーク転送等の応答時間やスループットについて判断する監視のこと。
【運用コストへの影響】
エラー監視やリソース監視、パフォーマンス監視を行うことによって、障害原因の追求が容易となったり、障害を未然に防止できるなど、システムの品質を維持するための運用コストが下がる。
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: 全て監視を行う

【メトリクス】プロセスレベルの監視とは、
アプリケーションやミドルウェア等のプロセスが正しく機能しているかどうかを判断するものである。
主にOSコマンドによるプロセスの情報（死活、CPU使用率、メモリ使用率など） を監視するものを想定している。
【レベル】監視を行う場合は、プロセスレベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システム上で稼動する複数のプロセス（アプリケーションおよびミドルウェア）のうち、
重要度の高い一部のプロセスのみを対象に監視を行うことを想定している。
C.1.3.5

データベース
レベルの監視		 0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う

【メトリクス】データベースレベルの監視とは、
DBMSの機能として提供される情報を確認し、正しく機能しているかを判断するものである。
ログ出力内容やパラメータ値、ステータス情報、領域使用率等の監視を想定している。
【レベル】監視を行う場合は、データベースレベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システム上で稼動する複数のデータベースのうち、
重要度の高い一部のデータベースのみを対象に監視を行うことを想定している。
C.1.3.6

ストレージ
レベルの監視		 0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う

【メトリクス】ストレージレベルの監視とは、
ディスクアレイ等の外部記憶装置に関して、状態を確認し、正しく機能しているかを判断するものである。
OSコマンドによって確認できるディスク使用率等の他、ファームウェアが出力するログ情報などの監視を想定している。
【レベル】監視を行う場合は、ストレージレベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システムに接続される複数のストレージのうち、
重要度の高い一部のストレージのみを対象に監視を行うことを想定している。
C.1.3.7

サーバ（ノード）
レベルの監視		 0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う

【メトリクス】サーバ（ノード）レベルの監視とは、
対象のサーバがOSレベルで正しく機能しているかを判断するものである。ハートビート監視などが該当する。
【レベル】監視を行う場合は、サーバ（ノード）レベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システム上に存在する複数のサーバ（ノード）のうち、
重要度の高い一部のサーバのみを対象に監視を行うことを想定している。
C.1.3.8

端末/ネットワーク機器
レベルの監視		 0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う

【メトリクス】端末/ネットワーク機器レベルの監視とは、
クライアント端末やルータ等のネットワーク機器に関して、状態を確認し、正しく機能しているかを判断するものである。
ハートビート監視の他、個別のファームウェア等が出力する情報に基づく監視などを想定している。
【レベル】監視を行う場合は、端末/ネットワーク機器レベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システム上に存在する複数の端末/ネットワーク機器のうち、
重要度の高い一部の端末/ネットワーク機器のみを対象に監視を行うことを想定している。
C.1.3.9

ネットワーク・パケット
レベルの監視		 0: 監視を行わない　　1: 一部監視を行う　　2: 全て監視を行う

【メトリクス】ネットワーク・パケットレベルの監視とは、
ネットワーク上を流れるパケットの情報を確認し、正しく機能しているかを判断するものである。
パケットロスやネットワーク帯域の使用率などの監視などを想定している。
【レベル】監視を行う場合は、ネットワーク・パケットレベルについての
監視情報と監視間隔を個別に確認する必要がある。
レベル1の一部とは、システム上の複数のネットワーク経路のうち、
重要度の高い一部のネットワーク経路のみを対象に監視を行うことを想定している。

監視要件の記述

  • 小項目「運用監視」では、「監視とは情報収集を行った結果に応じて適切な宛先に発報すること[C.1.3.1]」と定義しています。
    具体的には、監視対象ごと[C.1.3.3～9]に、以下の項目について明記する必要があります。
    • 監視情報[C.1.3.1]
    • 監視間隔[C.1.3.2]
  • 監視対象によってレベルが異なるため、メトリクスのレベル選択のみでは要件を正確に表現できません。
    メトリクスのレベルを選択する際は、視認性を向上させるための参考情報として、監視対象ごとに異なるレベルの中で最も高いレベルを選択します。
  • なお、同じリソース統計情報などを使用する場合でも、キャパシティー管理や障害予兆検知を目的とした定期的な分析に使用する要件は、小項目「C.2.6 予防保守レベル」に記述します。

📌閾値は予兆検知とセットで2段階

  • 発報は、障害や緊急対応が必要となる可能性がある場合に行います。
  • 使用率や件数などの量に応じて発報する場合は、発報用の閾値とは別に予防保守用の閾値を設定し、定期的な保守で閾値チェックし予兆検知に基づいた予防保守を行うことで、より高い信頼性を確保できます。

📌リソース監視は1～5秒間隔

  • CPUやメモリ使用率など、オンライントラフィックに応じて変化するリソースについては、レスポンス時間への影響を把握できるよう、監視間隔をレスポンス時間に相当する粒度で設定する必要があります。
  • マルチコアが一般化し、1秒程度のレスポンス要件が主流となっている現状においては、
    1～5秒程度の監視間隔のリソース利用率に対して閾値設定することが望まれます。
    しかし、多くの監視製品のリソースの監視間隔は1分となっています。

    これは、UNIXが商用システムに利用され始めた1990年代、
    まだサーバコア数が少なく、7秒程度のレスポンス要件が主流だった時代に、
    リソース情報取得の負荷がオンラインレスポンスに大きな影響を及ぼさない範囲で、
    レスポンスへの影響を把握できる最低限の粒度が、1分だったことの名残りと考えられます。

    （参考：あったら怖い本当の話: 敗因）

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】
システム全体を外部の標準時間と同期する場合、外部との接続に異常が発生した場合にシステム内の時刻同期をどうするかといった設計を行う必要がある。
【運用コストへの影響】
時刻同期を行うことで、複数のサーバ機器が出力するログの順序保証が得られるため、障害調査や監査等の作業コストを下げられる可能性がある。

時刻同期要件の記述

  • 小項目の「時刻同期」では、通常のntp(ネットワークタイムプロトコル)の精度(ミリ秒)では不足するなどの特別な要件がある場合、明記する必要があります。
  • 現在、インターネットと完全に切り離されたシステムは少なく、「レベル4: システム全体を外部の標準時間と同期する」の要件が標準的な対応となっています。
    そのため、特別な要件がない場合は、レベルの選択のみで十分です。

あったら怖い本当の話

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

要件と実装

・性能要件: ピーク時1時間
　　スループット: 100rps(1時間平均、集中1分間120rps、集中1秒間140rps）
　　レスポンス　: 1秒(99%ile)
・監視
　　要件：CPU、メモリ、IO帯域などのリソース監視を行う
　　実装：監視製品のデフォルト値(1分)間隔でリソース情報を取得し閾値で発報
　　　　CPU使用率の場合、閾値(80%)越えで発報

😱まだ1分間隔

新システムは年内最大のピーク日を含め半年ほど安定稼働していました。

敗因

  1. CPUリソース不足を把握できなかった
    12ヵ月目の障害を契機に、原因調査のため1秒単位でリソース統計を取得したところ、RPA実行中の数十秒間、CPU使用率が100% 近くに張り付く状態が確認されました。
    監視製品が対応する1分間隔の監視情報しか取得していなかったため、1秒越えの原因となる数十秒間のCPUリソース不足を把握できませんでした。（参考: 📌リソース監視は1～5秒間隔）
    使用率の解像度

  2. 利用方法の変化を把握できなかった
    7ヵ月目から、ビジネス部門で業務効率化のためにRPAを導入していました。
    RPAの適用範囲が拡大するにつれ、レスポンス遅延の頻度が増加する構造がありました。
    7ヵ月目のクレーム時点で、RPAを実行するとレスポンス遅延が発生する構造を把握できていれば、ビジネス部門とシステム部門が連携することにより、RPA活用に適切な対応を取ることができた可能性があります。

再発防止

  1. 監視インターバルの見直し

    • 社内のガイドラインに、CPUやメモリなど細かく変化するリソースについては、オンラインレスポンスへの影響を把握できるよう、監視インターバルをレスポンス相応に短くすることを定めました。
    • しかし、導入している監視製品の監視インターバルの変更はできなかったため、1秒ごとにリソース統計を取得し、閾値超過時に発報用のエラーログを出力するスクリプトを、監視製品とは別に作成しました。

  2. 利用方法の変化把握、予兆検知

    • 保守作業の月次レポート作成時に、1秒ごとのリソース統計を分析し、保守用閾値チェックを実施。これにより、予兆検知に基づく予防保守運用を確立しました。
    • 具体的な対応フロー
      1. システム部門: 保守作業の月次レポート作成時に、1秒ごとのリソース統計に対して保守用閾値越えをチェック。
        閾値越えが確認された場合、過去最大3年間のリソースピーク動向を調査し、取引量との相関を分析。
      2. ビジネス部門: 月次レポートに対する業務運用面からの見解をレポート。
      3. 翌月の月次レポート確認時: ビジネス部門とシステム部門間で、前月の保守用閾値超過の原因と対策を共有し、必要な予防保守対応を実施。

まとめ

本記事では、オンライン処理に関わるリソースの監視間隔は、多くの監視製品で採用されている1分間隔では長すぎることを説明しました。

最後に、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. スナップショット機能を持つファイルシステム: ZFS, Btrfs, LVM, NTFSなど ↩︎

  4. ランサムウェア: ファイルを暗号化したり、システムをロックしたりして、ユーザーがデータにアクセスできなくする攻撃、復号キーの提供と引き換えに金銭を要求するケースが多い ↩︎

  5. RPA: Robotic Process Automation（ロボティック・プロセス・オートメーション）
    日本では2010年代半ばから普及した、業務プロセスを自動化するための技術。
    特に反復的でルーチン的な作業を自動化することで、効率化やコスト削減を期待できる。 ↩︎

NTT DATA TECH
NTT DATA TECH

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

設定によりコメント欄が無効化されています