非機能要求グレードの歩き方 Vol.8 C2保守運用(後半)

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

全体構成

「非機能要求グレードの歩き方」シリーズ全体の構成は、「非機能要求グレードの歩き方 Index」を参照ください。
本記事(vol.8)では、Vol.7と併せて、「C.2 保守運用」に焦点を当てて解説します。

C.2 保守運用（Vol.7再掲）

中項目「C.2 保守運用」では、システムを維持するために必要な保守作業の要件を定義します。
下表は、大項目「C 運用・保守性」-中項目「C.2 保守運用」を抜粋したものです。

表: 「C.2 保守運用」の小項目とメトリクス（折りたたんでいます）

大項目	中項目	小項目	メトリクス(〇: 重要項目)
C 運用・保守性	C.2 保守運用	C.2.1 計画停止	C.2.1.1 ○ 計画停止の有無 C.2.1.2 　 計画停止の事前アナウンス
〃	〃	C.2.2 運用負荷削減	C.2.2.1 ○ 保守作業自動化の範囲 C.2.2.2 　 サーバソフトウェア更新作業の自動化 C.2.2.3 　 端末ソフトウェア更新作業の自動化
〃	〃	C.2.3 パッチ適用ポリシー	C.2.3.1 　 パッチリリース情報の提供 C.2.3.2 　 パッチ適用方針 C.2.3.3 　 パッチ適用タイミング C.2.3.4 　 パッチ検証の実施有無
〃	〃	C.2.4 活性保守	C.2.4.1 　 ハードウェア活性保守の範囲 C.2.4.2 　 ソフトウェア活性保守の範囲
〃	〃	C.2.5 定期保守頻度	C.2.5.1 　 定期保守頻度
〃	〃	C.2.6 予防保守レベル	C.2.6.1 　 予防保守レベル

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

以降、小項目ごとに解説します。
なお、中項目「C.2 保守運用」で1万文字を大幅に超えるため、2つの記事に分割しました。
前半の小項目「C.2.1」「C.2.2」「C.2.3」については、Vol.7を参照ください。

C.2.4 活性保守

小項目	メトリクス(〇: 重要項目)
C.2.4 活性保守 サービス停止の必要がない 活性保守が可能なコンポーネントの範囲。	C.2.4.1 　 ハードウェア活性保守の範囲 C.2.4.2 　 ソフトウェア活性保守の範囲

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

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.2.4.1 　 ハードウェア活性保守の範囲	0: 活性保守を行わない 1: 一部のハードウェアにおいて活性保守を行う 2: 全てのハードウェアにおいて活性保守を行う 【メトリクス】 ハードウェア活性保守とは、システムを停止せずにハードウェア交換やファームウェア更新といった保守作業を実施することである。 【レベル1】 一部のハードウェアとは、特定のサーバやストレージのみ活性保守を可能とするようなケースを指す。
C.2.4.2 　 ソフトウェア活性保守の範囲	0: 活性保守を行わない 1: 一部のソフトウェアにおいて活性保守を行う 2: 全てのソフトウェアにおいて活性保守を行う 【メトリクス】 ソフトウェア活性保守とは、システムを停止せずにOSやミドルウェア、アプリケーションのパッチ適用を実施することである （例：マルチサーバ環境におけるローリングアップグレードなど）。 【レベル1】 一部のソフトウェアとは、特定のソフトウェアのみ活性保守を可能とするようなケースを指す。

HW・SWに限らず記述

• 小項目の「活性保守」では、活性保守全般に関する要件を定義します。
  なお、システム構成策定に必要な要件ではなく、設計前提として必要な要件のため、「〇: 重要項目」はありません。

• 具体的には、以下の違いを考慮して活性保守のサービスへの影響が異なるグループを定義し、グループごとに要件を定めます。

  違いの観点	違いの代表例
  レイヤの違い	アプリケーション／ミドルウェア／ＯＳ／ハードウェア／データ
  機能の違い	NW機器／APサーバ／DBサーバ／ストレージ
  活性保守手法の違い	活性保守対応したHWの交換／ロードバランス構成のローリングアップデート／正副冗長化構成のスタンバイ機を保守
  発生頻度の違い	年数回発生（SPOF対応したHWの故障、パッチ適用、APデプロイ）／ ライフで数回発生（SPOF対応が難しい箇所の故障）
  活性保守時のサービスへの影響	縮退の有無／障害発生リスク／切戻し要否
  活性保守失敗リスクの考慮	システムの利用状況に関わらず実施／夜間など換算時間帯に実施／非稼働系に対して実施

• メトリクスとして、ハードウェア(HW)とソフトウェア(SW)の活性保守のレベルが定められています。 これは、以下の経緯を踏まえて明示されているにすぎません。
  ・初版(2009年)当時は、HWの活性保守が普及してたことから、メトリクスはHWのみ
  ・第二版の更新時(2018年)は、コンテナの普及を踏まえて、メトリクスにSWを追加

C.2.5 定期保守頻度

小項目	メトリクス(〇: 重要項目)
C.2.5 定期保守頻度 システムの保全のために必要なハードウェア またはソフトウェアの定期保守作業の頻度。	C.2.5.1 　 定期保守頻度

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

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.2.5.1 　 定期保守頻度	0: 定期保守を実施しない 1: 年1回 2: 半年に1回 3: 月1回 4: 週1回 5: 毎日

保守運用作業ごとに記述

• 保守作業量がイメージできるよう、保守作業の発生頻度をまとめます。
  （「C.2.6.1 予防保守レベル」に、予兆検出は「定期保守とは別」とありますが、
  　予兆検出作業を行う場合、その頻度もここに記述することをお勧めします。）
• 保守運用作業全体としてではなく、保守運用作業の種類ごとに、頻度を記述します。
  なお、システム構成策定に必要な要件ではなく、設計前提として必要な要件のため、「〇: 重要項目」はありません。

C.2.6 予防保守レベル

小項目	メトリクス(〇: 重要項目)
C.2.6 予防保守レベル システム構成部材が故障に至る前に予兆を検出し、 事前交換などの対応をとる保守。	C.2.6.1 　 予防保守レベル

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

項番 メトリクス	レベル0/1/2/3/4/5 備考
C.2.6.1 　 予防保守レベル	0: 予防保守を実施しない 1: 定期保守時に検出した予兆の範囲で対応する 2: （定期保守とは別に）一定間隔で予兆検出を行い、対応を行う 3: リアルタイムに予兆検出を行い、対応を行う

📌高信頼ほど予兆検知が必要

• 小項目の「予防保守レベル」では、予兆検知に基づく対応に関する要件を定義します。
  なお、システム構成策定に必要な要件ではなく、設計前提として必要な要件のため、「〇: 重要項目」はありません。

• 予防保守は、障害を未然に防ぐ対策ですので、高信頼なシステムほど、網羅性の高い予兆検知と障害に至る前の迅速な予防保守が求められます。

• 予兆検知の観点と具体例

  観点	予兆検知の具体例
  ハードウェアの異常	エラーメッセージ、リトライの増加、スループットの低下
  ソフトウェアの異常	スレッドハングや一時的停止、メモリやCPU使用率の異常上昇
  ネットワークの異常	エラーパケットの増加、帯域使用率の異常上昇
  ログ解析	warning(警告)やInfo(情報)ログの異常上昇、新たなログ
  APパフォーマンス	レスポンス遅延、滞留や多重度の異常上昇、 Application Performance Monitoring (APM)
  業務量	想定外の取引増

  ※ ハードウェア故障やAPMなどの領域では、予兆検知にAIが活用され始めています。

あったら怖い本当の話

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

😱朝から予兆を把握できていれば・・・

ケース1: 内部要因
前日夜間の定期保守により、RDBの統計情報が更新され、一部SQLの実行計画が変更。
これにより、タイムアウトしないものの数10秒のロックが発生するようになっていました。

朝から、体感でたまに遅くなる状態、コールセンタへの問合せも増えていました。
昼休みのピーク時間帯に、ロック待ちによる滞留が性能限界を超え、システムがスローダウン。

14:00には障害原因取引を特定、15:00には当日は問題取引を停止し代替運用を周知、
夕方のピーク時間帯は障害再発を防ぐことができました。

ケース2: 外部要因
その日は、朝から通常時の2倍の取引が発生していました。

昼休みのピーク時間帯に、性能限界を超える取引が発生し、システムがスローダウン。

このままだと、夕方のピーク時間帯でもスローダウンする可能性が高いと予測。
急遽、ピーク時間帯の社内利用を制限し、夕方の障害再発を防ぐことができました。

敗因

どちらのケースも、午前中の時点で予兆を把握できた可能性があります。
そして、障害発生直後(午後)に実施した対策を、未然(午前中)に対処することで、障害発生を回避できたと考えられます。

	予兆検知対策	対策により午前中に把握できた予兆
事例1	1時間毎に予想最大同時処理数 を超えたら発報	・これまで見られなかったレスポンス遅延の発生 ・午前中の取引増とともにレスポンス遅延の悪化
事例2	1時間毎にログ種類毎のログ件数が 予想範囲を超えたら発報(再発防止参照)	・早朝の取引がまだ少ない段階から、通常時の 　2倍の取引が発生

再発防止

以下の予兆検知運用を確立しました。

1. 日毎（通常日と特異日パターンごと）に、1時間毎のログ件数予想と発報条件比率を作成
2. オンライン中に、1時間ごとにログを収集
3. 1時間ごとに以下の観点で評価し、閾値超過時にアラートを発報し対処を促す

• 同時処理数評価
  スパイク的なレスポンス遅延は、単発で発生してもシステム全体への影響は限定的です。
  一方、ロック待ちや滞留などに伴う遅延は、悪循環を引き起こし、システム全体に影響を及ぼす可能性があります。これは、スパイク的な同時処理数の発生傾向を分析することで予兆検知できます。
  【集計方法】全体およびチャネル毎に、取引の開始時刻と終了時刻から同時処理数を算出
  【発報条件】日毎・1時間毎の集計単位ごとに、予想最大同時処理数を超えた場合に発報
• 取引ログ件数評価
  【集計方法】Info(情報)として出力される取引ログを、取引種類ごとに件数を予測
  【発報条件】日毎・1時間毎の集計単位ごとに、以下の比率以上の差が発生した場合に発報
  ・デフォルトは±100%（上限2倍、下限0件）
  　※ 下限0件は、本来発生するはずの定刻取引が行われていない場合の検知に対応
  ・大量取引は、性能限界とピーク時間の取引件数の比率を基準に設定

まとめ

本記事では、活性保守のバリエーションと、高信頼なシステムほど予兆検知と迅速な予防保守が重要となることを説明しました。

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