30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。
※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。
本記事では、オンラインシステムにおける「B.3 リソース拡張性」に焦点を当てて解説します。
 |
 |
B.3 リソース拡張性
リソースの拡張性要件は、中項目「B.3 リソース拡張性」で定義します。
下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.3 リソース拡張性」を抜粋したものです。
| 項番 | 中項目 | 小項目 | メトリクス (〇: 重要項目) |
レベル0/1/2/3/4/5 |
|---|---|---|---|---|
| B.3.1.1 | リソース拡張性 | CPU拡張性 | 〇CPU利用率 | 0: 80%以上 1: 50%以上80%未満 2: 20%以上50%未満 3: 20%未満 |
| B.3.1.2 | 〃 | 〃 | 〇CPU拡張性 | 0: 1倍（拡張要求なし） 1: 1.5倍の拡張が可能 2: 2倍の拡張が可能 3: 4倍の拡張が可能 4: 8倍以上の拡張が可能 |
| B.3.2.1 | 〃 | メモリ拡張性 | 〇メモリ利用率 | CPU利用率と同じ |
| B.2.3.2 | 〃 | 〃 | 〇メモリ拡張性 | CPU拡張性と同じ |
| B.3.3.1 | 〃 | ディスク拡張性 | ディスク利用率 | CPU利用率と同じ |
| B.3.3.2 | 〃 | 〃 | ディスク拡張性 | CPU拡張性と同じ |
| B.3.4.1 | 〃 | ネットワーク | ネットワーク機器設置範囲 | 0: 無し/1: フロア内のLAN 2: 同一拠点(ビル)内のLAN 3: 社内複数拠点間の接続(LAN、WAN) 4: 社外拠点との接続 |
| B.3.5.1 | 〃 | サーバ処理能力増強 | スケールアップ | 0: スケールアップを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 |
| B.3.5.2 | 〃 | 〃 | スケールアウト | 0: スケールアウトを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 |
以降、重要項目がある小項目の順に、やらかしがちな利用率と拡張性の観点から解説します。
B.3.1 CPU拡張性
| 小項目 B.3.1 CPU拡張性 | |
|---|---|
| 説明 | CPUの拡張性を確認するための項目。 CPU利用率は、将来の業務量の増加に備え、どれだけCPUに余裕をもたせておくかを確認するための項目。 CPU拡張性は、物理的もしくは仮想的に、どれだけCPUを拡張できるようにしておくかを確認するための項目。 CPUの専有の有無については「B.4.1 HWリソース専有の有無」で確認する。 |
| メトリクス | B.3.1.1: CPU利用率 B.3.1.2: CPU拡張性 |
📌リソース利用率はレスポンス順守率から逆算する
CPUのようなランダムに発生する処理要求に伴って一時的に利用するリソース(※)の利用量は、業務処理量のようにポアソン分布に近い特性があります。
※ メモリやネットワーク帯域も同様の特性があります。なお、ディスク容量には該当しません。
- これらのリソース利用率高騰は、オンライン処理のレスポンス遅延に直結します。
そのため、安定稼働に必要なリソース利用率は、オンライン性能要件から定まります。 - オンライン性能要件は、主に、スループット、レスポンスとその順守率(%ile) から成り、
単位時間(１時間or１分or1秒)を明確にして定義することが重要です。
（Vol.2 B.2.1 オンラインレスポンス 参照） - 特に、リソース利用率は、レスポンスの順守率(%ile)に大きく影響します。(下表と下図参照)
（余談：リソースの性能（スピード）は、レスポンス時間に大きく影響します）
| 1分間の平均リソース利用率 | レスポンス順守率の目安(レスポンス:0.5sec、スループット:80rps) |
|---|---|
| 90% | 97% |
| 80% | 99.5% ※下図 |
| 70% | 99.97% |
| 60% | 99.9995% |
B.3.2 メモリ拡張性
| 小項目 B.3.2 メモリ拡張性 | |
|---|---|
| 説明 | メモリの拡張性を確認するための項目。 メモリ利用率は、将来の業務量の増加に備え、どれだけメモリに余裕をもたせておくかを確認するための項目。 メモリ拡張性は、物理的もしくは仮想的に、どれだけメモリを拡張できるようにしておくかを確認するための項目。 メモリの専有の有無については「B.4.1 HWリソース専有の有無」で確認する。 |
| メトリクス | B.2.3.1: 通常時処理余裕率 B.2.3.2: ピーク時処理余裕率 B.2.3.3: 縮退時処理余裕率 B.2.1.3: 縮退時レスポンス順守率 |
「B.3.2 メモリ拡張性」の説明は、「B.3.1 CPU拡張性」「B.3.3 ディスク拡張性」の説明と、メモリをCPU・ディスクに差替えただけの同じ説明が記載されています。
ここでは、これらを 「リソース」 と総称して記述します。
📌 取引量とリソース利用量の相関分析の必要性
小項目の説明に、利用率は「将来の業務量の増加に備え、どれだけリソースに余裕をもたせておくかを確認するため」、また、拡張性は拡張余力を確認するため、と記載されています。
商用利用開始時点に向けて
商用利用開始時点での目標リソース利用率を決定するには、業務量の増加予測に、同一業務量あたりの必要リソース量の変化を加味する必要があります。
-
業務量の増加予測には、将来の業務量予想モデルの作成が必要となります。
詳細は「Vol.1 オンライン編-B.1.2 業務量増大度」を参照ください。 - 同一業務量あたりの必要リソース量の変化には以下のような様々な要因があります。
・アプリケーションの修正による影響
・データ量の増加による負荷変動
・連続運転によるゴミの蓄積などによる影響（参考：以下の「あったら怖い本当の話」）
しかし、これらを定量的に予測することは難しく、リスクとして一定の余裕率を加味する、拡張に必要な期間を考慮した拡張余力を確保するなどの対応が適切と考えられます。
商用利用開始後の保守運用
商用利用開始後は、リソース利用量が想定以上に増大していないかを確認するために、定期的に以下の保守運用を行う必要があります。
- 月次など定期的に業務量とリソース利用量を確認し、予測に収まっているか検証する。
- 業務量や必要リソース量、またはその相関が 予測モデルと異なった場合は、原因を究明する。
- 原因に応じて、業務運用対処、予測モデルの変更、リソース増強など必要な対応を行う。
あったら怖い本当の話
※ 実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。
拡張性要件
・ 利用期間 : 初期構成のまま5年間（＋予備2年）拡張せずに利用可能であること。
・ 業務量予測 : 最大は7年目の111ではなく4年目の特異日117となる。（Vol.1と同じモデル）
・ スループット: 1ヵ月以内に初期構成の2倍に拡張できること。（クラウド環境を利用）
拡張性設計
・ ライフサイクル内の最大業務量117（4年目）において、
リソース利用率80%（安定稼働の上限値）で動作するように設計した。
😱予測どおりの業務量なのにリソース不足
敗因
同一業務量あたりのリソース利用量が連続運転期間に比例して増加する構造がありました。
・ 2年目までは年1回ペースで再起動 していたため、増加傾向の検出はできませんでした。
・ 3年目以降は連続運転したため、4年目の特異日 で リソース利用量が安定稼働80%を大幅に超過する事態となりました。
もし、4年目時点で業務量あたりの必要リソース量が増えていることを把握できていれば、特異日が到来する前にリソース増強や再起動などの必要な対応を行い、障害を未然に防げたはずです。
再発防止
- 業務量とリソース利用量の相関を確認する月次運用を確立。（予測とのギャップから評価）
- 予測と異なる傾向が観測された場合には、原因を究明し、その内容応じて必要な対応を行う。
まとめ
本記事では、オンライン処理に関わるリソースの拡張性は、業務量予測とオンライン性能要件（特にレスポンス順守率(%ile)）から導く必要があることを説明しました。
最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。
[募集要領] [NTTデータ 金融分野の取り組み]
-
IPA: 独立行政法人 情報処理推進機構 (Information-technology Promotion Agency, Japan) ↩︎
-
非機能要求グレード:
参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の 06‗活用シート.xls
↩︎
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。
Discussion