２０２３年４月２６日
e-お菓子ねっと会員企業各位
富士通Ｊａｐａｎ株式会社
ｅ-お菓子ねっとサービス 新基盤移行に伴う障害について（お詫びとご報告）
謹啓 貴社益々ご清栄の事とお慶び申し上げます。平素は格別のご高配を賜り、厚く御礼申し上げます。
掲記の障害につきまして、委員様および会員の皆様に多大なるご迷惑をお掛けしましたことを深くお詫び申し上げます。
本障害の顛末と根本原因及び抜本対策につきまして、下記の通りご報告申し上げます。今後この様なことの無いよう、鋭意努めて参りますので、相変わらぬご愛顧を賜りますよう、何卒よろしくお願い申し上げます。
謹白記
１．今回サービス基盤移行のいきさつ
これまでにもサービス基盤の移行は６～７年に一度行ってまいりましたが、今回のサービス基盤移行も旧来のｅ-お菓子ねっとサービス専用に構築していたハードウェア・ソフトウェアのサポート期限を迎えることに伴い、より安全で高性能な環境への刷新を行うものになります。刷新においては、旧来の専用に環境を構築する手法ではなく、クラウド環境上に構築環境を移植することで安全性・性能の向上に加え、構成の拡張性／可用性を向上しつつ現行サービス料金の範囲内で実現することを目的として、弊社主体で検討し、取り組んでまいりました。
■移行実施に至るまでのいきさつ
・2022 年 10 月 24 日（月）移行で当初予定しておりました。
・2022 年 10 月 6 日（木）の移行判定時に、旧基盤でのインターネット回線不足による通信遅延が発生し、同様の課題が新基盤でも発生した場合の対策が不十分であることが判明しました。
そのため、2022 年 11 月 21 日（月）に移行作業を延期しました。
・2022 年 11 月 21 日（月）に移行作業を実施しましたが、移行データの抽出に想定よりも時間を要し、予定時間内に完了しなかったため、移行を中止しました。
・想定を超える負荷テストについて再チェックし、改めて負荷テスト内容を見直しました。
想定以上のデータ（ピーク時 90 分間のデータを 30 分で投入）を使用して再度実施し、システムの多重設定や他の最終見直し、不測事態におけるシステム変更の臨時手順を整備し、2023 年 3 月 13 日の移行に臨んでおりました。
２．障害発生日時
２０２３年３月１３日（月）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 130 分）
２０２３年３月１４日（火）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 118 分）
２０２３年３月２０日（月）１０：００～１２：００ ピーク時のデータ配信レスポンス劣化（最大 79 分）※上記期日以外でも最大で 20 分程度かかっておりました。（3 月 15 日～3 月 23 日）（以下次葉）

（前葉より）
３．障害内容と影響（１）「配信格納」の遅延
発注データ等の業務データの配信が大幅に遅延し、業務に遅れを生じさせました（遅納・欠品の発生）（２）「集配信状況処理更新」の不具合
以下の２つの事象により、正しい処理状況と処理結果が確認できず、業務の混乱を招きました。
a.集配信状況照会の更新遅延
b.集配信状況照会更新不具合（配信完了しているのに「未配信」から変更されない）４．原因と対処（１） 主な事象と原因①「配信格納」の遅延→新基盤で新たに導入したプログラム（Ｗeb-API）の処理能力について事前の確認が不十分でした。
→特定のサーバの処理負荷が上がることにより全体の遅延が発生していました。
②「集配信状況照会」の更新遅延→旧基盤の未配信データの移行処理の不具合③「集配信状況照会」の更新不具合→状況照会の更新処理と集配信情報の登録処理のタイミングがずれ、適切に更新されませんでした。
（２）上記原因の対処①「配信格納」遅延に対する対処状況
・滞留の大きかったジョブの多重度を最適化し、滞留を軽減（3/14 反映）
・CPU の増強による処理能力 UP、ジョブ多重度と処理内容の見直しを実施（3/15 反映）→遅延短縮
・Web-API の変更（3/22 反映）→遅延短縮
・全体のジョブ多重度の更なる最適化（3/22～3/31 継続的に実施）→遅延短縮
・サーバ負荷分散（3/25 反映）→遅延短縮（従来サービスでの処理時間相当へ復旧）
・クラウド上に専用サーバを増設（4/1 反映）→遅延解消②「集配信状況照会」の更新遅延
・エラーリトライ数を是正しリトライ処理待ち時間を削減し負荷を軽減（3/14 反映）→遅延短縮
・クラウド上に専用サーバを増設（4/1 反映）→遅延解消（従来サービスでの処理時間相当へ復旧）③「集配信状況照会」の更新不具合
・エラーリトライ数を最適化し更新不具合を改善（3/22 反映）
・更新プログラムを修正し更新漏れ発生を改善（4/1 反映）→状況照会の更新不具合を解消（以下次葉）

（前葉より）
５．根本原因（真因）について
今回の障害は、旧基盤から新基盤への移行作業に伴う以下の真因により発生したと認識しております。
（１） 移行設計段階におけるリスク分析不足（クラウド共通機能<Web-API＞利用のリスク分析不足）
クラウド共通機能<Web-API>はクラウド基盤で提供されている共通機能であるため、利用することで通信情報の取得が容易に取得できるメリット面を評価しておりましたが、ピーク時の利用頻度をもとにしたデメリット面の分析・評価が行われておりませんでした。
（２） 負荷テストの不足（新環境における負荷テスト、新基盤への移行テスト項目の漏れ）
富士通 Japan 内部の移行判定において性能面含めてテスト結果に問題なしと評価をしておりましたが外部機能（Web-API）利用のリスクが表面化されていない点から問題潜在の指摘に至っておりませんでした。
①負荷テストにおけるテスト手段の不備（テストデータの多重投入パターンの未実施）
実際のピーク時間帯よりも厳しい条件（30 分で 1250 データ）のテストデータを設計で決定しまし
たが、投入方法についての詳細設計がないまま単一プロセスで順次投入する手段を用いてしまいました。そのため、Web-API 部分の同時起動数制限により、ピーク時間帯に必要な同時処理数が足りなくなる問題が負荷テストで検出されず、問題を発見することができませんでした。
※詳細につきましては別紙１「負荷テストデータ投入方法について」に記載②負荷テストにおけるテスト条件の不備（ピーク時間と同時間帯でのテスト未実施）
負荷テスト実施時間帯を通常のピーク時間に限定していなかったため、一部のクラウド仮想サーバで物理 CPU 負荷時間帯に依存した問題が潜在的に発生する可能性を検出することができませんでした。
※計 4 日間（9:00～10:30／13:00～15:00）でテストを実施。時間は作業都合で決定③データ配信部分の負荷テスト実施不備
負荷テストでは、データが格納されるまでの時間にのみ焦点が当てられ、データ配信（メーカー様への受信）部分の負荷テストが不十分でした。そのため、状況照会の更新対象が一定数を超えた場合に更新異常が発生する状況を検出することができませんでした。
※詳細につきましては別紙２「負荷テスト実施範囲について」に記載
６．再発防止策について
今後、同様の問題を再発させないために、以下の再発防止策を実施いたします。
（１）「移行計画書標準項目」の作成（2023 年 5 月末完了予定）
移行計画書の項目を予め規定したドキュメントを作成し、クラウド共通機能の利用有無およびリスク評価の項目を追加することで、外部機能利用によるリスク評価を確実に行うよう見直します。
今後の開発においては、この移行計画書標準項目をベースに移行計画設計を行うことで、今回のようにリスクの把握および対策がされないまま製造工程へ進むことを防止します。
（以下次葉）

（前葉より）（２）「テスト計画書標準項目」の作成（2023 年 5 月末完了予定）
以下の 4 つの観点を規定することで、テスト観点の漏れにより今回のような性能問題が負荷テストで検出されないことがないよう改善します。
① ピーク情報調査の明記（データ同時発生状況／ピーク時間帯）② 負荷テスト条件の明記（データ投入多重度／テスト日時）
・テストデータは必ず複数プロセスでの同時投入とし、①で規定した処理多重度と比較・評価します。
・負荷テストの実施は①で規定したピーク時間帯と同じ時間帯で設定します。
③ データ集配信部分のテスト実施範囲の明確化（集信／配信でのテスト範囲規定）・配信（メーカ様受信）部分の負荷テストも必須として規定します。
④ 並行ランニング試験での性能計測実施評価の明記
・移行元／移行先の環境の互換性を計画時に評価した内容を記載します。
・互換性が低いと判断する場合は、データを新環境へ転送する並行ランニング試験の実施を明記します。
７．更なるサービス向上について（会員企業様からのご意見・ご要望に対する取り組み）
今回の障害に対する会員企業の皆様方からの貴重なご意見・ご要望に対し、以下の通りサービス向上・改善施策に全力で取り組んで参ります。
（１）障害発生時の情報提供【ご意見】
障害時に提供するべき情報・状況の対応内容・役割分担の取り決めが曖昧である。
→障害運用（遅延含む）
・訓練などの場で検討見直しする場が設定されていない。
【改善施策】
会員企業様への情報提供内容とルールを作成します。（2023 年 5 月末完了予定）①緊急事態対応ガイドラインにて情報提供内容と条件を定義する項目を追加します。
今回のような性能問題のケースに限らず、想定される全体障害パターンを洗い出し、それぞれのパターンで情報提供のために提供するべき情報と提供方法を予め規定します。
これにより障害発生時に情報提供する内容の統一と公開までの時間短縮を行います。
②情報提供内容とルールについて定期見直しを行う運用とします。（年１回）
障害訓練の中で新たな障害パターンや、情報提供における改善箇所の検討・見直しを行うようにいたします。
（２）障害定義の見直し【ご意見】
緊急事態対応ガイドラインにおける障害の閾値設定が今回の事態と乖離している。
（現在は、対象とする不測の事態を「サービス停止予測時間 1 時間以上の障害」と設定している）【改善施策】
障害発生時の初動運用フローおよび閾値の見直し→業務実態を調査の上、実態に即した初動運用フローと閾値になるよう見直しを行います。

以上別紙１：負荷テストデータ投入方法について（１）今回負荷テスト実施でのデータ投入方法
データ集信後処理を実際のピーク時間帯の発生よりも厳しい30分間で1250回起動する形で負荷テストを実施いたしました。
ただデータ投入（集信後処理起動）方法は全1250回を順次起動する手順になっていたことでWebAPI部分の問題が顕在化しませんでした。
集信後処理起動イメージ
起動1
起動2
起動3･･･
起動1250

通信情報取得
Web
API

40多重

40多重

40多重

集信後処理

EDI処理

配信処理

データ

データ

データ

データ

データ

データ

データ

WebAPI

集信後処理
集信後処理
集信後処理
集信後処理
集信後処理
集信後処理
集信後処理
集信後処理
集信後処理

20多重の制限（２）本来実施すべき負荷テスト実施でのデータ投入方法
データ集信後処理はほぼ同時に動作することがピーク時間には発生しているため、その状況に近づけるような投入方法であるべきでした。
起動1
･･
起動100

集信後処理起動イメージ

起動101･･
起動200
起動301
･･
起動400

40多重

40多重

40多重

集信後処理

集信後処理

EDI処理

配信処理

集信後処理
集信後処理

通信情報取得Web
API
20多重の制限データ

WebAPI

データ

データ

データ

データ

データ

データ

集信後処理

集信後処理
集信後処理
集信後処理
集信後処理
集信後処理

集信後処理

eお菓子ねっと の今後の負荷テストとして必ず同時処理多重の状況をみてそれに近づけるデータ投入方法での実行を行います。

別紙２：負荷テスト実施範囲について（１）今回負荷テスト実施範囲
データ集信／データ配信部分はクラウド基盤での通信キャパシティで担保される範囲であるため負荷テスト対象外としておりました。
今回テスト範囲としては下記の赤枠①の範囲のみを実施しておりました。
対象外①負荷テスト実施範囲
対象外
送信元

データ

送信先
通信ソフト

集信後処理

振分

データ

データ

受信後処理を大量に同時起動してテスト実施(30分で1250ファイル）

配信処理

EDI処理

データ

データ

通信ソフト

データ

データ
送信先

データ

データ

データ

データデータ
データ

データ

送信先

データ

（２）不足していた負荷テスト実施範囲
データ送信完了の情報を取得して集配信状況照会を更新にいく専用処理があるため、データ送信が一斉にされる負荷テストが必要でした
送信元

通信ソフト

集信後処理

配信処理

EDI処理

通信ソフト

送信先

データ
送信先

データ
データ

送信先

状況照会更新

一度の取得数が大量になったことで更新異常が発生していました

情報取得
ステータス更新②負荷テスト実施範囲（不足していた範囲）

eお菓子ねっと の今後の負荷テストとして必ず（１）（２）の範囲実施をいたします。

ダミー受信
1250
ファイル