Zenn
NTT DATA TECH
😱

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

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

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

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

A.1 継続性（Vol.4再掲）

大項目「A 可用性」については、Vol.4を参照ください。
中項目「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.1」「A.1.2」「A.1.3」については、Vol.4を参照ください。

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などの細かな要求までは確定せず、
システム再開目標として大まかな復旧時間を設定する。
目標復旧レベルについては、業務停止時の目標復旧水準を参考とする。

📌災対切替(DR)基準を定義

  • 2011年3月11日の東日本大震災を契機に、災害対策の必要性が改めて認識されました。
    現在では、システム復旧要件だけでなく、BCP[3]として、システム停止～段階的復旧の状況と整合性の取れた業務運用の構築が求められています。
  • 本項では、復旧が困難な障害時における災害対策用システムへの切替要件を定義します。
    （注）冗長化ストレージの論理障害（データ喪失）や、冗長構成の長時間停止など、大規模災害時に限らず、災害対策システムへ切り替える条件と目標復旧水準を定義します。
  • 目標復旧水準として、2009年にIPAに寄贈された非機能要求グレードでは、「RPO、RTO、RLOなどの細かな要求は確定せず」とされています。
    しかし、現在ではA.1.3と同様に、RPO、RTO、RLOを網羅して記述する必要があります。（下表参照）
  • 設置場所については、2週間にわたる計画停電によるデータセンタの重油不足という経験を踏まえ、東西で異なる電気周波数の地域を選定することの重要性が認識されました。
    また、データセンターの所在だけでなく、オペレータの所在についても考慮が必要です。
要件定義観点 該当メトリクスなど
RPO（目標復旧地点）
Recovery Point Objective		 静止点バックアップ取得タイミングを定義
非同期レプリケーションの場合、欠損を許容する時間の目安を定義
（計画切替・切戻し時は無欠損）
RTO（目標復旧時間）
Recovery Time Objective		 A.1.4.1 システム再開目標
RLO（目標復旧レベル）
Recovery Level Objective		 データセンタ単位の切替のみか、システム単位切替も可能か定義
接続先システムの切替を考慮した、業務縮退レベルを定義

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%

📌パブクラなら99.9%以下

  • 「稼働率」は、災対切替発動[A.1.4]を除く、計画外停止の目標時間から求めます。
\begin{alignedat}{1} 稼働率 &= 1 - \frac{\text{MTTR}}{\text{MTBF} + \text{MTTR}} = 1 - \frac{\text{計画外停止時間（Σ RTO）}}{\text{計画稼働時間}}　\\ \\ \text{MTBF}&（平均故障間隔）: \text{Mean Time Between Failures}　\\ \text{MTTR}&（平均修理時間）: \text{Mean Time To Repair}　\\ \text{RTO}&（目標復旧時間）: \text{Recovery Time Objective} \end{alignedat}
  • パブリッククラウドのSLAは、月次で清算することが多いため、多くの場合、評価期間は1ヵ月単位となっています。
  • 一方で、システムのSLOは、通常1年間の実績に基づいて評価されます。
    年間目標稼働率に応じて、下表に代表される対策が必要となります。
稼働率
(停止時間)		 HWのSPOF対策
[A.1.2]		 有人対応時の障害復旧
[A.1.3]		 パブクラの
冗長化構成の目安(※)
想定MTBF HW SPOF障害を
年数回想定		 HW SPOF以外の障害を
年1回程度想定
MTTR相当
メトリクス		 A.1.2.2
サービス切替時間		 A.1.3.2
RTO（目標復旧時間）
95%
18.3日/年
(36時間/月)		 オンコール部品交換
年数回×3日=9日
A.1.2.2Lv.0 24時間以上		 オンコール解析
年3回×3日=9日
A.1.3.2Lv.0 1営業日以上		 冗長化不要
バックアップ
から再構築
99%
87.6時間/年
(7.2時間/月)		 3~5回×半日~1日=
3日(72時間)
A.1.2.2Lv.1 24時間未満		 ←左に含む

A.1.3.2Lv.1 1営業日以内		 シングルAZ
IaCより再構築
99.9%
8.76時間/年
(43.2分/月)		 年数回×10分=
約30分
A.1.2.2Lv.3 10分未満		 解析を伴う復旧×1~2回=
8時間
A.1.3.2Lv.3 6時間以内		 マルチAZ
99.99%
52.6分/年
(4.32分/月)		 年数回×5~1分程度=
約10分
A.1.2.2Lv.4 10分以内		 常駐オペレータ対応1回=
約40分
A.1.3.2Lv.4+ 2時間以内		 マルチリージョン
自動切換え
99.999%
5.26分/年
(約26秒/月)		 年数回×1分=2~3分
A.1.2.2Lv.5 60秒未満
A.1.2.3Lv.2 二重障害自動復旧		 年数回×1分=2~3分
HW SPOF以外も自動復旧
有人対応発生時は不達		 マルチリージョンや
マルチクラウドの
両現用

※ システムが10個程度のクラウドサービス(PaaS,IaaS)を使うとすると、[4]
　　シングルAZのサービス(99.9%)を10個使うと99%
　　マルチAZのサービス(99.99%)を10個使うと99.9%となる

あったら怖い本当の話

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

要件

・セミクローズド型会員制ポータルサイト
・パブリッククラウドを利用し、アジリティと拡張性を向上
・信頼性: 可用性 99.9%(APバグ等を除くHW障害に対して)
・性能: ピーク時1時間平均100rps、レスポンス 1秒(99%ile)
・運用保守: 24/365、月1回以下の休日深夜に2時間程度の計画停止を許容

可用性設計

・SLA/SLOが99.99%～99.95%のマルチAZ対応PaaSを使った下図の構成により、
　システム全体として99.9% を確保

\begin{alignedat}{1} 稼働率（99.9％） &= 1- ((1-99.99％)×5+(1-99.95％)×1 )\\ &= 1 - (0.01％×5+0.05％×1) \\ 99.99％：&5個（FW,LB,DB,File,分散キャッシュ） \\ 99.95％：&1個（コンテナ） \end{alignedat}

😱99.9%のはずが99%

負荷試験、疑似障害試験、新システムへの移行作業なども問題なく順調に進み、
運用開始から1週間、安定稼働していました。

敗因

  1. 障害が発生するたびに、クラウドベンダのサポートに確認したところ、「1分未満のストール（一時的無応答）は正常稼働の範疇」 との回答がありました。
    SLA/SLOの定義では、稼働時間を累計する単位を1分としており、1分未満のストールは稼働時間に含まれる仕様となっていました。
    そもそも、1分(1時間の1.6%)の停止を許容する基盤では、レスポンス1秒(99%ile)の実現は困難でした。

    • 反省点:
      稼働率のみの表面的なサービスレベルしか確認せず、
      サービスレベルの定義の確認が不十分      だったことが問題でした。

  2. 3週目の障害発生時、同時間帯にマルチAZ対応のストレージサービスでも障害が報告されていました。
    この障害に伴い、クラウドベンダ側では
    PaaS内で「ストールを1分未満に収め、かつ同時に複数AZに影響しないようにストレージライブマイグレーション（OSを収容するストレージをOS無停止で移動）」を実施していたと推測されます。
    しかし、本システムのような、数十秒のストールを障害として検知してAZ分離し、シングルAZ構成に縮退する利用形態を想定した運用になっていなかったと考えられます。

    • 反省点
      類似システム構成の稼働実態を確認できていませんでした。
      もし確認していれば、もしくはベストプラクティスが提示されていれば、轍を踏むことを避けられたと考えられます。

再発防止

  1. 当該クラウドサービスを使う際には、1分間のストール多発を許容すること を周知徹底しました。
  2. 自社のパブリッククラウド活用方針を定め、
    活用方針に即したシステム特性毎に、クラウドベンダ提示のベストプラクティスもしくは類似システム構成の稼働実態を確認し、
    クラウドベンダの使い分け方針をガイドラインとして整備しました。

まとめ

本記事では、オンライン処理に関わる可用性(信頼性)を確保するには、可用性のSLAやSLOの数字だけでなく正常状態の実態を確認することの重要性を説明しました。

最後に、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. BCP（事業継続計画）: Business Continuity Planの略で、企業などが「自然災害や感染症など緊急事態が発生した際、重要な事業を継続させること、もし中断しても可能な限り短い期間で復旧させるための方法や体制を示す計画」のことです。想定される事象は災害だけではなく、感染症やテロ、システム障害なども含まれます。 ↩︎

  4. Amazon Web Services (AWS)のSLA一覧(2023/3/8付): https://dev.classmethod.jp/articles/202303-aws-service-sla/ ↩︎

NTT DATA TECH
NTT DATA TECH

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

Discussion