はじめに - Vol.13
本記事では、IPA[1] が公開する 非機能要求グレード[2] の
「B. 性能・拡張性」に含まれるバッチ処理関連の小項目を対象に、
金融 IT 基盤に 30 年以上携わって得た知見をもとに “やらかしがちな” 技術課題と対策を解説します。
筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含め解説します。
シリーズ全体の構成は 👉 非機能要求グレードの歩き方 Index をご覧ください。
B.1 業務処理量
オンラインと同様バッチ処理も業務処理量と増大度を定めます。
共通する事項は、Vol.1 オンライン編-B1業務処理量を参照ください。
表: 大項目「B:性能・拡張性」-中項目「B.1 業務処理量」の小項目とメトリクス
表: 「B.1 業務処理量」の小項目とメトリクス（折りたたんでいます）
| 大項目 | 中項目 | 小項目 | メトリクス(〇: 重要項目) |
|---|---|---|---|
| B 性能・拡張性 | B.1 業務処理量 | B.1.1 通常時の業務量 | B.1.1.1 ○ ユーザ数 B.1.1.2 ○ 同時アクセス数 B.1.1.3 ○ データ量 B.1.1.4 ○ オンラインリクエスト件数 B.1.1.5 ○ バッチ処理件数 B.1.1.6 業務機能数 |
| 〃 | 〃 | B.1.2 業務量増大度 | B.1.2.1 ○ ユーザ数増大率 B.1.2.2 ○ 同時アクセス数増大率 B.1.2.3 ○ データ量増大率 B.1.2.4 ○ オンラインリクエスト件数増大率 B.1.2.5 ○ バッチ処理件数増大率 B.1.2.6 業務機能数増大率 |
| 〃 | 〃 | B.1.3 保管期間 | B.1.3.1 ○ 保管期間 B.1.3.2 対象範囲 |
B.1.1 通常時の業務量
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.1.1 通常時の業務量 性能・拡張性に影響を与える業務量。 該当システムの稼働時を想定し、合意する。 それぞれのメトリクスに於いて、単一の値だけでなく、前提となる時間帯や季節の特性なども考慮する。 |
B.1.1.1 ○ ユーザ数 B.1.1.2 ○ 同時アクセス数 B.1.1.3 ○ データ量 B.1.1.4 ○ オンラインリクエスト件数 B.1.1.5 ○ バッチ処理件数 B.1.1.6 業務機能数 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.1.1.1 ○ ユーザ数 |
0: 特定ユーザのみ 1: 上限が決まっている 2: 不特定多数のユーザが利用 【重複項目】 F.2.1.1。ユーザ数は性能・拡張性を決めるための前提となる項目であると共にシステム環境を規定する項目でもあるため、性能・拡張性とシステム環境・エコロジーの両方に含まれている。 【レベル】 前提となる数値が決められない場合は、類似システムなどを参考に仮の値でも良いので決めておくことが必要。 |
| B.1.1.2 ○ 同時アクセス数 |
0: 特定利用者の限られたアクセスのみ 1: 同時アクセスの上限が決まっている 2: 不特定多数のアクセス有り 【メトリクス】 同時アクセス数とは、ある時点でシステムにアクセスしているユーザ数のことである。 |
| B.1.1.3 ○ データ量 |
0: 全てのデータ量が明確である 1: 主要なデータ量のみが明確である 【レベル1】 主要なデータ量とは、システムが保持するデータの中で、多くを占めるデータのことを言う。 例えば、マスター系テーブルや主なトランザクションデータの一次保存分などがある。 主要なデータ量しか決まっていない場合、後工程に於いて、検討漏れデータの出現などによるディスク追加などが発生するリスクがある。 |
| B.1.1.4 ○ オンラインリクエスト件数 |
0: 処理毎にリクエスト件数が明確である 1: 主な処理のリクエスト件数のみが明確である 【メトリクス】 オンラインリクエスト件数は単位時間を明らかにして確認する。 【レベル1】 主な処理とはシステムが受け付けるオンラインリクエストの中で大部分を占めるものを言う。 例えば、住民情報システムの転入・転出処理やネットショッピングシステムの決済処理などがある。 主なリクエスト件数しか決まっていない場合、後工程に於いて、検討漏れリクエストの出現などによるサーバ能力不足などのリスクがある。 |
| B.1.1.5 ○ バッチ処理件数 |
0: 処理単位毎に処理件数が決まっている 1: 主な処理の処理件数が決まっている 【メトリクス】 バッチ処理件数は単位時間を明らかにして確認する。要件定義時には主な処理（特に該当システムでクリティカルとなる処理）では処理件数のおおよその目安は決まっているはずであり、それを元に性能や拡張性の検討を進める。要件定義時に明確になっていない場合は、確定度合も含め、想定しておく。 【レベル1】 主な処理とはシステムが実行するバッチ処理の中で大部分の時間を占める物をいう。 例えば、人事給与システムや料金計算システムの月次集計処理などがある。 主なバッチ処理件数しか決まっていない場合、後工程に於いて、検討漏れ処理の出現などによるサーバ能力不足などのリスクがある。 |
| B.1.1.6 業務機能数 |
0: 業務機能が整理されている 1: 確定した業務機能一覧が作成されている 2: 業務機能一覧はあるが、確定していない 【メトリクス】 要件定義時には業務機能一覧はレベルの差があっても決まっているはずであり、それを元に性能や拡張性の検討を進める。要件定義時に明確になっていない場合は、確定度合も含め、想定しておく。 |
B.1.2 業務量増大度
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.1.2 業務量増大度 システム稼動開始からライフサイクル終了までの間で、開始時点と業務量が最大になる時点の業務量の倍率。 必要に応じ、開始日の平均値や、開始後の定常状態との比較を行う場合もある。 |
B.1.2.1 ○ ユーザ数増大率 B.1.2.2 ○ 同時アクセス数増大率 B.1.2.3 ○ データ量増大率 B.1.2.4 ○ オンラインリクエスト件数増大率 B.1.2.5 ○ バッチ処理件数増大率 B.1.2.6 業務機能数増大率 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.1.2.1 ○ ユーザ数増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.1.2.2 ○ 同時アクセス数増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.1.2.3 ○ データ量増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.1.2.4 ○ オンラインリクエスト件数増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【メトリクス】 オンラインリクエスト件数は単位時間を明らかにして確認する。 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.1.2.5 ○ バッチ処理件数増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【メトリクス】 バッチ処理件数は単位時間を明らかにして確認する。 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.1.2.6 業務機能数増大率 |
0: 1倍、1: 1.2倍、2: 1.5倍、3: 2倍、4: 3倍、5: 10倍以上 【レベル】 業務機能数増大率を評価する際は、機能の粒度（1機能あたりの見積規模、サービス範囲など）は具体的数値を示すことが望ましい。 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
B.1.3 保管期間
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.1.3 保管期間 システムが参照するデータのうち、OSやミドルウェアのログなどのシステム基盤が利用するデータに対する保管が必要な期間。 必要に応じて、データの種別毎に定める。 保管対象のデータを選択する際には、対象範囲についても決めておく。 |
B.1.3.1 ○ 保管期間 B.1.3.2 対象範囲 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.1.3.1 ○ 保管期間 |
0: 6ヶ月 1: 1年 2: 3年 3: 5年 4: 10年以上有期 5: 永久保管 【レベル】 対象が複数あり、それぞれの保管期間が異なる場合は、それぞれの対象データについて決めること。 【レベル0】 保管期間の制約が短い場合は6ヶ月で代用する。 |
| B.1.3.2 対象範囲 |
0: オンラインで参照できる範囲 1: アーカイブまで含める 【メトリクス】 保管対象のデータを配置する場所を決める。保管場所によっては参照するための手間がかかる場合がある。また、バックアップの取得方法などへの配慮が必要になる。 |
📌長時間バッチの業務処理量の偏りリスク
- 一般に、バッチ処理時間は業務処理量に比例するため、処理時間短縮の手法として多重化（並列処理） が用いられます。
- しかし、多重化の単位となる最小処理単位には、しばしば業務処理量の偏りが存在します。
単に n 分割するだけでは、処理負荷が集中した「長時間ジョブ」 が残り全体の処理時間が遅延する事態が生じがちです。 - ついては、並列処理により 1/n に近い時間で処理するよう設計できるように、最小処理単位とその処理量のばらつき（特に高負荷な要素）を定量的に示すことが重要です。
B.2 性能目標値
本項では、バッチと帳票印刷に関する小項目について解説します。
オンラインについては、Vol.2 オンライン編-B2性能目標値を参照ください。
下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.2 性能目標値」を抜粋したものです。
表: 「B.2 性能目標値」の小項目とメトリクス（折りたたんでいます）
| 大項目 | 中項目 | 小項目 | メトリクス(〇: 重要項目) |
|---|---|---|---|
| B 性能・拡張性 | B.2 性能目標値 | B.2.1 オンラインレスポンス | B.2.1.1 ○ 通常時レスポンス順守率 B.2.1.2 ○ ピーク時レスポンス順守率 B.2.1.3 縮退時レスポンス順守率 |
| 〃 | 〃 | B.2.2 バッチレスポンス（ターンアラウンドタイム） | B.2.2.1 ○ 通常時レスポンス順守度合い B.2.2.2 ○ ピーク時レスポンス順守度合い B.2.2.3 縮退時レスポンス順守度合い |
| 〃 | 〃 | B.2.3 オンラインスループット | B.2.3.1 通常時処理余裕率 B.2.3.2 ピーク時処理余裕率 B.2.3.3 縮退時処理余裕率 |
| 〃 | 〃 | B.2.4 バッチスループット | B.2.4.1 通常時処理余裕率 B.2.4.2 ピーク時処理余裕率 B.2.4.3 縮退時処理余裕率 |
| 〃 | 〃 | B.2.5 帳票印刷能力 | B.2.5.1 通常時印刷余裕率 B.2.5.2 ピーク時印刷余裕率 B.2.5.3 縮退時印刷余裕率 |
B.2.1 オンラインレスポンス
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.2.1 オンラインレスポンス オンラインシステム利用時に要求されるレスポンス。 システム化する対象業務の特性をふまえ、どの程度のレスポンスが必要かについて確認する。ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に順守率を決める。具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。（例：Webシステムの参照系/更新系/一覧系など） |
B.2.1.1 ○ 通常時レスポンス順守率 B.2.1.2 ○ ピーク時レスポンス順守率 B.2.1.3 縮退時レスポンス順守率 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.2.1.1 ○ 通常時レスポンス順守率 |
0: 順守率を定めない、 1: 60%、 2: 80%、 3: 90%、 4: 95%、 5: 99%以上 【レベル】 具体的な目標値や約束値がある場合、各処理の順守率を規定する。 レベルに示した順守率はおおまかな目安を示しており、具体的にはレスポンスと順守率について数値で合意する必要がある。 |
| B.2.1.2 ○ ピーク時レスポンス順守率 |
0: 順守率を定めない、 1: 60%、 2: 80%、 3: 90%、 4: 95%、 5: 99%以上 【レベル】 具体的な目標値や約束値がある場合、各処理の順守率を規定する。 レベルに示した順守率はおおまかな目安を示しており、具体的にはレスポンスと順守率について数値で合意する必要がある。 |
| B.2.1.3 縮退時レスポンス順守率 |
0: 縮退をしない[3]、 1: 60%、 2: 80%、 3: 90%、 4: 95%、 5: 99%以上 【レベル】 具体的な目標値や約束値がある場合、各処理の順守率を規定する。 レベルに示した順守率はおおまかな目安を示しており、具体的にはレスポンスと順守率について数値で合意する必要がある。 |
B.2.2 バッチレスポンス（ターンアラウンドタイム）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.2.2 バッチレスポンス（ターンアラウンドタイム） バッチシステム利用時に要求されるレスポンス。 システム化する対象業務の特性をふまえ、どの程度のレスポンス（ターンアラウンドタイム）が必要かについて確認する。 更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に順守率を決める、具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：日次処理/月次処理/年次処理など） |
B.2.2.1 ○ 通常時レスポンス順守度合い B.2.2.2 ○ ピーク時レスポンス順守度合い B.2.2.3 縮退時レスポンス順守度合い |
メトリクス内容（折りたたんでいます）
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.2.2.1 ○ 通常時レスポンス順守度合い |
0: 順守度合いを定めない 1: 所定の時間内に収まる 2: 再実行の余裕が確保できる 【レベル1】 所定の時間には再実行は含まない。 |
| B.2.2.2 ○ ピーク時レスポンス順守度合い |
0: 順守度合いを定めない 1: 所定の時間内に収まる 2: 再実行の余裕が確保できる 【レベル1】 所定の時間には再実行は含まない。 |
| B.2.2.3 縮退時レスポンス順守度合い |
0: 縮退をしない 1: 所定の時間内に収まる 2: 再実行の余裕が確保できる 【レベル1】 所定の時間には再実行は含まない。 |
バッチのレスポンス(TAT)は処理時間
- 小項目「B.2.2 バッチレスポンス（ターンアラウンドタイム:TAT）」には、バッチ処理時間の要件を記述します。
- 具体的には、処理開始時刻と、後続処理の開始時刻にあたる処理完了時限を定め、RTO(※)を考慮して、以下の計算から処理時間要件を導出します。
※ RTO： A.1.3.2 RTO（目標復旧時間） 参照
- 既存システムの実績値がある場合、参考情報としての記載を推奨します。
（注）「現行踏襲」という記載だけでは要件として認められません。あくまで参考情報の位置づけとなります。
B.2.3 オンラインスループット
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.2.3 オンラインスループット オンラインシステム利用時に要求されるスループット。 システム化する対象業務の特性をふまえ、単位時間にどれだけの量の作業ができるかを確認する。 更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に処理余裕率を決める、具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：データエントリ件数/時間、頁めくり回数/分、TPSなど） |
B.2.3.1 通常時処理余裕率 B.2.3.2 ピーク時処理余裕率 B.2.3.3 縮退時処理余裕率 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.2.3.1 通常時処理余裕率 |
0: 1倍 (余裕無し) 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 ここでの余裕率は、システム全体で処理できるトランザクション量を示す。例えば、レベル3（2倍）であれば、2倍のトランザクションを処理できることを言う。 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.3.2 ピーク時処理余裕率 |
0: 1倍 (余裕無し) 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 ここでの余裕率は、システム全体で処理できるトランザクション量を示す。例えば、レベル3（2倍）であれば、2倍のトランザクションを処理できることを言う。 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.3.3 縮退時処理余裕率 |
0: 縮退をしない 1: 通常時の1/2の処理が出来る 2: 通常時と同様に処理が出来る |
B.2.4 バッチスループット
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.2.4 バッチスループット バッチシステム利用時に要求されるスループット。 システム化する対象業務の特性をふまえ、どの程度のスループットを確保すべきか確認する。 更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に処理余裕率を決める。具体的な数値は特定の機能またはシステム分類毎に決めておくことが望ましい。 （例：人事異動情報一括更新処理、一括メール送信処理など） |
B.2.4.1 通常時処理余裕率 B.2.4.2 ピーク時処理余裕率 B.2.4.3 縮退時処理余裕率 |
メトリクス内容（折りたたんでいます）
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.2.4.1 通常時処理余裕率 |
0: 1倍 (余裕無し) 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.4.2 ピーク時処理余裕率 |
0: 1倍 (余裕無し) 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.4.3 縮退時処理余裕率 |
0: 縮退をしない 1: 通常時の1/2の処理が出来る 2: 通常時と同様に処理が出来る |
B1業務処理量 B22処理時間から導出
- 小項目「B.2.4 バッチスループット」は、業務処理量(※1)と処理時間(※2)から導出できるため、「〇：重要項目」となっていません。
※1 業務処理量：Vol.1 オンライン編-B1業務処理量 参照
※2 処理時間：B.2.2 バッチレスポンス（ターンアラウンドタイム） 参照
B.2.5 帳票印刷能力
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.2.5 帳票印刷能力 帳票印刷に要求されるスループット。 業務で必要な帳票の出力時期や枚数を考慮し、どの程度のスループットが必要かを確認する。 更に、ピーク特性や、障害時の運用を考慮し、通常時・ピーク時・縮退運転時毎に余裕率を決める。具体的な数値は特定の帳票や機能毎に決めておくことが望ましい。 |
B.2.5.1 通常時印刷余裕率 B.2.5.2 ピーク時印刷余裕率 B.2.5.3 縮退時印刷余裕率 |
メトリクス内容（折りたたんでいます）
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.2.5.1 通常時印刷余裕率 |
0: 1倍 （余裕無し） 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.5.2 ピーク時印刷余裕率 |
0: 1倍 （余裕無し） 1: 1.2倍 2: 1.5倍 3: 2倍 4: 3倍 5: 10倍以上 【レベル】 レベルに示した倍率はおおまかな目安を示しており、具体的には数値で合意する必要がある。 |
| B.2.5.3 縮退時印刷余裕率 |
0: 縮退をしない 1: 通常時の1/2の印刷が出来る 2: 通常時と同様に印刷が出来る |
性能に限らず印刷全般の要件を記述
- 小項目「B.2.5 帳票印刷能力」には、メトリクスにある印刷速度だけでなく、印刷に関する要件を記述します。
紙への出力に限らず、ICタグ、プラスチックカードやComputer Output Microfilm（COM）など、媒体への出力全般が対象です。 - 一方、印刷用データ作成まではバッチとして扱い、本項の対象外です。
- なお、本項は「B. 性能・拡張性」に属しますが、ほかに帳票に関する項目がないため、以下のような性能以外の観点も参考として記述することを推奨します：
- 改ざん防止のために帳票データにメッセージダイジェストを付与
- QRコード印字など外部連携情報の有無
B.3 リソース拡張性 （特になし）
オンラインと同様バッチ処理もリソースの必要量と拡張性を定めること以外に、バッチとして特筆すべき事項はありません。Vol.3 オンライン編-B3リソース拡張性を参照ください。
表: 大項目「B:性能・拡張性」-中項目「B.3 リソース拡張性」の小項目とメトリクス
表: 「B.3 リソース拡張性」の小項目とメトリクス（折りたたんでいます）
| 大項目 | 中項目 | 小項目 | メトリクス(〇: 重要項目) |
|---|---|---|---|
| B 性能・拡張性 | B.3 リソース拡張性 | B.3.1 CPU拡張性 | B.3.1.1 ○ CPU利用率 B.3.1.2 ○ CPU拡張性 |
| 〃 | 〃 | B.3.2 メモリ拡張性 | B.3.2.1 ○ メモリ利用率 B.3.2.2 ○ メモリ拡張性 |
| 〃 | 〃 | B.3.3 ディスク拡張性 | B.3.3.1 ディスク利用率 B.3.3.2 ディスク拡張性 |
| 〃 | 〃 | B.3.4 ネットワーク | B.3.4.1 ネットワーク機器設置範囲 B.3.5.1 スケールアップ B.3.5.2 スケールアウト |
| 〃 | 〃 | B.3.5 サーバ処理能力増強 | B.3.5.1 スケールアップ B.3.5.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拡張性 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.3.1.1 ○ CPU利用率 |
0: 80%以上 1: 50%以上80%未満 2: 20%以上50%未満 3: 20%未満 【メトリクス】 CPU利用率は単位時間に、実行中のプログラムがCPUを使用している割合を示している。単位時間をどの程度にするか、また、動作するプログラムの特性によって数値は大きく異なる。 【レベル】 レベルに示した利用率はおおまかな目安を示しており、具体的な数値で合意する必要がある。 【運用コストへの影響】 CPU利用率が大きい場合、少しの業務量増大で機器増設などの対策が必要になる。 |
| B.3.1.2 ○ CPU拡張性 |
0: 1倍 （拡張要求なし） 1: 1.5倍の拡張が可能 2: 2倍の拡張が可能 3: 4倍の拡張が可能 4: 8倍以上の拡張が可能 【運用コストへの影響】 CPU拡張性がない場合、機器自体の増設や、環境や契約の変更が必要になる場合がある。 |
B.3.2 メモリ拡張性
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.3.2 メモリ拡張性 メモリの拡張性を確認するための項目。 メモリ利用率は、将来の業務量の増加に備え、どれだけメモリに余裕をもたせておくかを確認するための項目。 メモリ拡張性は、物理的もしくは仮想的に、どれだけメモリを拡張できるようにしておくかを確認するための項目。 メモリの専有の有無については「B.4.1 HWリソース専有の有無」で確認する。 |
B.3.2.1 ○ メモリ利用率 B.3.2.2 ○ メモリ拡張性 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.3.2.1 ○ メモリ利用率 |
0: 80%以上 1: 50%以上80%未満 2: 20%以上50%未満 3: 20%未満 【メトリクス】 メモリ利用率は単位時間に、実行中のプログラムがメモリを使用している割合を示している。単位時間をどの程度にするか、また、動作するプログラムの特性によって数値は大きく異なる。 【レベル】 レベルに示した利用率はおおまかな目安を示しており、具体的な数値で合意する必要がある。 【運用コストへの影響】 メモリ利用率が大きい場合、少しの業務量増大でメモリや機器の増設が必要になる。 |
| B.3.2.2 ○ メモリ拡張性 |
0: 1倍 （拡張要求なし） 1: 1.5倍の拡張が可能 2: 2倍の拡張が可能 3: 4倍の拡張が可能 4: 8倍以上の拡張が可能 【運用コストへの影響】 メモリ拡張性がない場合、機器自体の増設や、環境や契約の変更が必要になる場合がある。 |
B.3.3 ディスク拡張性
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.3.3 ディスク拡張性 ディスクの拡張性を確認するための項目。 ディスク利用率は、将来の業務量の増加に備え、どれだけディスクに余裕をもたせておくかを確認するための項目。 ディスク拡張性は、物理的もしくは仮想的に、どれだけディスクを拡張できるようにしておくかを確認するための項目。 |
B.3.3.1 ディスク利用率 B.3.3.2 ディスク拡張性 |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.3.3.1 ディスク利用率 |
0: 80%以上 1: 50%以上80%未満 2: 20%以上50%未満 3: 20%未満 【レベル】 レベルに示した利用率はおおまかな目安を示しており、具体的な数値で合意する必要がある。 【運用コストへの影響】 ディスクに空きが無い場合、単純増加ファイルの監視等が必要になる。 |
| B.3.3.2 ディスク拡張性 |
0: 1倍 （拡張要求なし） 1: 1.5倍の拡張が可能 2: 2倍の拡張が可能 3: 4倍の拡張が可能 4: 8倍以上の拡張が可能 【運用コストへの影響】 ディスク拡張性がない場合、機器自体の増設や、環境や契約の変更が必要になる場合がある。 |
B.3.4 ネットワーク
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.3.4 ネットワーク システムで使用するネットワーク環境の拡張性に関する項目。 既存のネットワーク機器を活用する場合は既存ネットワークの要件を確認するために利用する。 ネットワークの帯域については「B.4.1 帯域保証機能の有無」で確認する。 |
B.3.4.1 ネットワーク機器設置範囲 B.3.5.1 スケールアップ B.3.5.2 スケールアウト |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.3.4.1 ネットワーク機器設置範囲 |
0: 無し 1: フロア内のLAN 2: 同一拠点(ビル)内のLAN 3: 社内複数拠点間の接続(LAN、WAN) 4: 社外拠点との接続 |
| B.3.5.1 スケールアップ |
0: スケールアップを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 【メトリクス】 あらかじめ余剰リソースを用意しておくことで速やかにスケールアップを行う等、スケールアップの迅速性についても検討する。 また、スケールアップしている状態は、コスト増に繋がる場合があるため、必要に応じてスケールダウンの迅速性についても考慮する。 【レベル1】 オンライントランザクション処理のような更新系の割合が多いシステムでアプリケーションサーバをスケールアップする場合を想定。 【レベル2】 レベル1に加え、DBサーバのスケールアップを追加する場合を想定。 |
| B.3.5.2 スケールアウト |
0: スケールアウトを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 【メトリクス】 スケールアップと同様、スケールアウトの迅速性についても検討する。 また、必要に応じて、スケールインの迅速性についても検討する。 【レベル1】 Webサーバと負荷分散装置などフロント部分を複数台用意する場合を想定。 【レベル2】 レベル1に加え、バックエンドのサーバを複数台用意する場合を想定。 |
B.3.5 サーバ処理能力増強
メトリクス内容（折りたたんでいます）
| 小項目 | メトリクス(〇: 重要項目) |
|---|---|
|
B.3.5 サーバ処理能力増強 サーバ処理能力増強方法に関する項目。 将来の業務量増大に備える方法（スケールアップ/スケールアウト）をあらかじめ考慮しておくこと。どちらの方法を選択するかはシステムの特徴によって使い分けることが必要。 スケールアップは、より処理能力の大きなサーバとの入れ替えを行うことで処理能力の増強を行う。 スケールアウトは同等のサーバを複数台用意し、サーバ台数を増やすことで処理能力の増強を行う。 |
B.3.5.1 スケールアップ B.3.5.2 スケールアウト |
| 項番 メトリクス |
レベル0/1/2/3/4/5 備考 |
|---|---|
| B.3.5.1 スケールアップ |
0: スケールアップを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 【メトリクス】 あらかじめ余剰リソースを用意しておくことで速やかにスケールアップを行う等、スケールアップの迅速性についても検討する。 また、スケールアップしている状態は、コスト増に繋がる場合があるため、必要に応じてスケールダウンの迅速性についても考慮する。 【レベル1】 オンライントランザクション処理のような更新系の割合が多いシステムでアプリケーションサーバをスケールアップする場合を想定。 【レベル2】 レベル1に加え、DBサーバのスケールアップを追加する場合を想定。 |
| B.3.5.2 スケールアウト |
0: スケールアウトを行わない 1: 一部のサーバのみを対象 2: 複数のサーバを対象 【メトリクス】 スケールアップと同様、スケールアウトの迅速性についても検討する。 また、必要に応じて、スケールインの迅速性についても検討する。 【レベル1】 Webサーバと負荷分散装置などフロント部分を複数台用意する場合を想定。 【レベル2】 レベル1に加え、バックエンドのサーバを複数台用意する場合を想定。 |
あったら怖い本当の話
※ 実際に起きたことを、脱色・デフォルメしたフィクションにして紹介します。
バッチ処理概要
以下の運転スケジュールとなっていました。(Vol.12と同じ)
- 20:00～21:00（通常1時間） 商品マスター更新（バッチ処理）
- 0:00～6:00（通常4時間） 夜間バッチ処理（※）
- 8:00～9:00（通常1時間） オンライン事前開放（予約取引登録）
- 9:00～ オンライン本開放
※ 夜間バッチ処理時間のうち2時間を占める 「バッチ処理A」は、商品群ごとのジョブを並行処理することにより処理時間を短縮。
😱動き始めてからでは手遅れ…
- その日のオンラインは、いつもより少し取引が多く発生していました。
敗因
- 特定商品に対する想定外の取引増により、1ジョブが長時間化し、RTO(2時間)を超える5時間以上処理が継続。
- 特定商品への取引増に伴う処理時間増リスク対策が不十分でした。
再発防止
-
業務運用対応：
商品ごとの取引数に、以下の2段階の閾値を設定し、オンライン中に業務運用対処。-
1段階目の閾値：想定ピーク件数
⇒ 閾値を越えアラート発報を契機に、業務側で取引抑制対応を開始。 -
2段階目の閾値：2時間を超える可能性のある件数
⇒ 閾値越え商品はバッチ処理から除外し、BCP（事業継続計画）対応を実施。
-
1段階目の閾値：想定ピーク件数
-
システム対応：
多重度数の割算で処理時間が短くなるように、取引数の多い商品から先に処理するよう修正
※ 長時間ジョブが残り全体の処理時間が延びることを回避
まとめ
本記事では、重たいバッチ処理については、最小処理単位とその処理量のばらつき（特に高負荷な要素）を定量的に示すことの重要性を説明しました。
最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。
[募集要領] [NTTデータ 金融分野の取り組み]
-
IPA（独立行政法人 情報処理推進機構, Information-technology Promotion Agency, Japan） ↩︎
-
非機能要求グレード:
参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の 06‗活用シート.xls ↩︎ -
「レベル0:縮退をしない」は、障害時サービス停止すると捉えると、レスポンス順守率としては考慮不要となるので、最も容易なレベル0としていることを理解できます ↩︎
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。
設定によりコメント欄が無効化されています