NTT DATA TECH
😱

非機能要求グレードの歩き方 Vol.17 B4性能品質保証

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

はじめに - Vol.17

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

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

Vol.17 過負荷制御

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

B.4 性能品質保証　（オン含む）

下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.4 性能品質保証」を抜粋したものです。
なお、「性能品質保証」には、「〇：重要項目」はありません。

表: 「B.2 性能目標値」の小項目とメトリクス（折りたたんでいます）
大項目 中項目 小項目 メトリクス(〇: 重要項目)
B 性能・拡張性 B.4 性能品質保証 B.4.1 帯域保証機能の有無 B.4.1.1 　 帯域保証の設定
〃 〃 B.4.1 HWリソース専有の有無 B.4.1.2 　 HWリソース専有の設定
〃 〃 B.4.2 性能テスト B.4.2.1 　 測定頻度
B.4.2.2 　 確認範囲
〃 〃 B.4.3 スパイク負荷対応 B.4.3.1 　 トランザクション保護

B.4.1 帯域保証機能の有無

小項目 メトリクス(〇: 重要項目)
B.4.1 帯域保証機能の有無
ネットワークのサービス品質を保証する機能の導入要否およびその程度。
伝送遅延時間、パケット損失率、帯域幅をなんらかの仕組みで決めているかを示す。回線の帯域が保証されていない場合性能悪化につながることがある。
 B.4.1.1 　 帯域保証の設定
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
B.4.1.1
　
帯域保証の設定		 0: 無し
1: プロトコル単位で設定
2: 各サーバ毎に設定
3: アプリケーションのエンドツーエンドで検証・保証

ベストエフォートの考え方

  • 小項目「B.4.1.1 帯域保証機能の有無」では、ベストエフォート型ネットワークの利用を許容する際に、帯域保障とコスト削減のトレードオフに対する考え方を定めます。

B.4.1 HWリソース専有の有無

小項目 メトリクス(〇: 重要項目)
B.4.1 HWリソース専有の有無
サーバのリソース（CPUやメモリ）を専有するか、共有するかを示す。HWリソースを他のサーバと共有する場合、他のサーバの影響を受けて、性能悪化につながることがある。
 B.4.1.2 　 HWリソース専有の設定
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
B.4.1.2
　
HWリソース専有の設定		 0: 無し（共有）
1: 有り（専有）

クラウド対応項目

  • 小項目「B.4.1.2 HWリソース専有の有無」では、クラウドや仮想化基盤の利用を許容する際に、性能保証とリソース共有によるコスト削減のトレードオフに対する考え方を定めます。

    本項目は、2018年の改定版で追加されました。
    MUFGがクラウドファースト戦略を掲げた2017年[3]の翌年であることからも、クラウド利用を想定した項目であることがわかります。

Noisy Neighbor 問題

  • 仮想化環境やクラウド環境において、同じ物理リソースを共有する他のユーザーが過剰にリソースを消費することで、自分のシステムのパフォーマンスが低下する現象を「Noisy Neighbor（うるさい隣人）」といいます。
  • HWリソース共有の影響は、以下のようなリソース統計から把握できます。
    リソース 統計(Linuxコマンド)
    CPU CPU %steal（top, vmstat, sar など）
    メモリ メモリ使用率（top, vmstat, perf, free など）
    メモリ帯域（numastat など）(※)
    NW IO NW帯域（iftop, netstat, ss など）

    ※ NUMA (Non-Uniform Memory Access)
    CPUとメモリを、複数のノード（CPU＋ローカルメモリ）で構成するアーキテクチャ。
    各CPUが自分に近いメモリ（ローカルメモリ）に高速アクセスできる一方、遠いメモリ（リモートメモリ）へのアクセスは遅くなる。
    近年、大量のマルチコアプロセッサの普及に伴い、リモートメモリアクセスに伴う性能劣化の影響を無視できなくなっている。

B.4.2 性能テスト

小項目 メトリクス(〇: 重要項目)
B.4.2 性能テスト
構築したシステムが当初/ライフサイクルに渡っての性能を発揮できるかのテストの測定頻度と範囲。
 B.4.2.1 　 測定頻度
B.4.2.2 　 確認範囲
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
B.4.2.1
　
測定頻度		 0: 測定しない
1: 構築当初に測定
2: 運用中、必要時に測定可能
3: 運用中、定常的に測定
B.4.2.2
　
確認範囲		 0: 確認しない
1: 一部の機能について、目標値を満たしていることを確認
2: 全ての機能について、目標値を満たしていることを確認

本番相当の負荷試験環境

  • 小項目「B.4.2 性能テスト」には、大項目 「B 性能・拡張性」要件に対する要求品質を定めます。
    本項目は「〇：重要項目」ではありませんが、重要項目の「C.4.2 試験用環境の設置」と整合性をとる必要があります。

    大項目「A 可用性」の要求品質は「A.4.2 可用性確認」で定めます。

    • 開発フェーズ:
      実機で実施する、性能テストおよび拡張性試験の実施方針を定めます。
    • 運用保守フェーズ:
      性能問題や性能拡張が必要となった際の性能テストの実施方針を定めます。
      特に、本番相当負荷試験の必要性と試験環境確保方法について、開発着手時にユーザと開発者間で合意しておく必要があります。

B.4.3 スパイク負荷対応

小項目 メトリクス(〇: 重要項目)
B.4.3 スパイク負荷対応
通常時の負荷と比較して、非常に大きな負荷が短時間に現れることを指す。業務量の想定されたピークを超えた状態。
特にB2Cシステムなどクライアント数を制限できないシステムで発生する。システムの処理上限を超えることが多いため、Sorry動作を実装し対策する場合が多い。
 B.4.3.1 　 トランザクション保護
メトリクス内容（折りたたんでいます）
項番
メトリクス		 レベル0/1/2/3/4/5
備考
B.4.3.1
　
トランザクション保護		 0: トランザクション保護は不要である
1: 同時トランザクション数の制限機能
2: 同時トランザクション数の制限機能に加え、Sorry動作
3: 独立したSorry動作を行うサーバの設置

過負荷対策

  • 小項目「B.4.3.1 スパイク負荷対応」では、過負荷に対する対応方針を定めます。

    クライアント数を制限できないシステムにおいては、ポアソン過程相当のスパイクは想定業務量の一環として捉える必要があります。
    （「B.2.3 オンラインスループット」の「📌１分は１時間の1/60ではない」参照）
    ですので、小項目の説明に含まれる、スパイク＝「業務量の想定されたピークを超えた状態。」の表現は不正確です。

過負荷（スパイク負荷）の定義

  • スパイク負荷には以下のような発生原因があります。
    まず、こういったスパイクに対して、どこまでを想定業務量に含めるかを定めます。
    代表的なスパイク負荷の発生原因 影響処理方式 スパイクの扱い
    ポアソン過程相当の負荷のゆらぎ
    クライアント数を制限できないオンライン処理    		 オン特有 想定内
    上流の一括処理
    Robotic Process Automation (RPA) や API 利用など    		 オン特有 要件次第
    障害影響
    上流システムの障害などに伴う滞留の解消    		 オン＆バッチ 要件次第
    想定外業務量
    時限を目指したアクセス、利用者の新たな行動など    		 オン＆バッチ 想定外

過負荷対策方針

  • 想定業務量の定義をもとに、想定を超える負荷 （過負荷）の際にシステム全面停止することなく、想定内業務量を処理しながら、超過業務量を制御・遮断する制御（過負荷対策）の対応方針を定めます。

    過負荷対策例 対応システム例
    Sorry
    ロードバランサなどにより過負荷をSorry表示サーバに降り分ける    		 参照系Webシステム
    入場規制
    認証・認可段階で、処理能力内のユーザのみ認可し、過負荷を避ける    		 チケット予約・販売
    仕掛中優先
    処理完結に複数画面を必要とする場合、2画面目以降を優先する    		 申込受付、事務支援
    チャネル毎流量規制
    チャネル毎に上限流量を定め、重要チャネルを優先する    		 基幹業務システム
    Microservices Architecture (MSA) &
    Single Page Application (SPA)
    Webページ内の表示部品を、マイクロサービス単位とすることにより、
    特定のマイクロサービスが過負荷でスローダウンしても、
    それ以外の機能の利用に支障を及ぼさないようにする    		 ECサイト
    • これらは、非機能要件（性能・拡張性と可用性）の実現手段ですが、入場規制やSPAなど、機能要件に影響する可能性があるため、要件定義段階で対応方針を定める必要があります。
    • 特に、基幹系業務のオンライン処理要求は、業務継続のために必要不可欠な処理のため、処理しなければ未処理が滞留し負荷が増え続ける悪循環に陥ります。
      このため、想定業務量の処理を確保することで負荷の悪循環を防ぐ設計が重要です。

Vol.17 過負荷制御

あったら怖い本当の話

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

😱重要業務がスパイクでスローダウン

  • そのシステムは、多数の提携企業に情報を配布するシステムでした。
  • 定刻（夕方）の重要情報配布タイミングにスパイク的にアクセスが集中します。
    定刻スパイクの過去実績に成長率と安全率を考慮して、性能要件を定めていました。
  • 添付ファイルに制限を設けるには、提携企業の合意を要する業務で、
    特段の制限は設けていませんでした。

その日は、一部の配布資料に複数の大容量ファイルが添付されていました。

敗因

  • 性能要件を超える過負荷の際にはスローダウンするアーキテクチャとなっていました。
  • 利用企業は、添付ファイルを入手できるまで、残業して繰り返しダウンロード処理要求を行っていました。
  • 過負荷状態でも、処理能力の範囲でダウンロードできていれば、過負荷は短時間に収まったと想定されます。

再発防止

  1. 喫緊の対策として、サーバリソースを増強しました。
  2. 提携企業と再発防止策を検討し、レジリエンス強化の位置づけで、添付ファイル数・サイズの上限を業務ルールとして明文化し、チェック機能を実装しました。
  3. システム更改の際に過負荷制御機能を実装し、想定外の過負荷が生じても悪循環に陥らないアーキテクチャとしました。

まとめ

本記事では、性能・拡張性要件は、その要求品質によっては機能要件に影響するため、要件定義段階から要求品質とその実現方針を合意する必要があることを説明しました。

最後に、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. MUFGクラウドファースト戦略発表:
    2017年9月11日「デジタルトランスフォーメーション戦略」説明会の
    プレゼンテーション資料 P31-35「6. ITアーキテクチャ戦略」 ↩︎

NTT DATA TECH
NTT DATA TECH

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

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