フェイルオーバー失敗回避へ、故障検知と処理引き継ぎの確実性を高める方法

フェイルオーバー失敗回避へ、故障検知と処理引き継ぎの確実性を高める方法
渡辺 享靖 日経BP総合研究所
https://xtech.nikkei.com/atcl/nxt/column/18/01435/100600004/

『サーバーやネットワークの冗長化は情報システムの信頼性を高めるための常套手段だ。しかしシステム障害を防ぐはずの二重化が正常に機能しないという事態は多くの大規模システムで発生しうる。なぜフェイルオーバーに失敗するのか。有効な自衛手段はあるのか。日経コンピュータの過去の障害事例記事を基に、失敗の要因や対策を明らかにしていく。最終回の今回は、フェイルオーバー処理の失敗の防止策を取り上げる。

 フェイルオーバー処理で失敗しないためには、「故障検知」と「処理の引き継ぎ」のそれぞれで確実性を高める必要がある(図1)。

図1●ユーザー企業における四つの自衛策

故障検知と処理引き継ぎの確実性を高めることで、自動フェイルオーバー失敗の可能性を減らすことができる
[画像のクリックで拡大表示]

 故障検知においては、検知対象を広げることがポイントになる。ERP(統合基幹業務システム)ならトランザクション、Webサーバーならレスポンスタイムなどサービスの品質を監視することで、ハードの異常も見抜きやすくなる。

 将来発生しうる故障を事前に発見するソフトの活用も方策の一つだ。サービスの稼働状況やパフォーマンスなどを学習し、それを基に異常値を検知して障害発生の予兆を事前に予測してくれる。

 ネットワーク機器は故障検知のレベルが装置により異なる。例えばポートのリンクの状態だけでなく、指定アドレスに定期的にpingを発行し応答を確認する製品もある。

 処理引き継ぎの信頼性を上げるには、システム導入時の障害テストを手厚くしたい。電源断やケーブル引き抜きによるフェイルオーバーの確認でテストを済ますケースもあるが、タイムアウト設定などの非機能要件についてもテストで確認しておくことが大切だ。

 構成情報管理も徹底したい。冗長構成を組むサーバーは同じ設定でなければならない。ところがネットワーク構成の変化などで設定変更を繰り返すうちにサーバー間で差分が生じ、フェイルオーバーに失敗するケースも多いという。

 故障検知の失敗には、製品のバグに絡むものもある。定期的な改修版の適用が理想だが、適用にはシステムの一時停止が必要だ。提供するサービスや業務とバランスをとって判断したい。

ストレージの対策には限界も

 一方でユーザー側の対策に限界があるのも事実だ。特にストレージの自動フェイルオーバー機能は製品仕様であり、ユーザーが手を加える余地はない。冗長化の設計やテストでユーザーが果たす役割はサーバーなどに比べ限定的だ。製品ベンダーは、より高い可用性を担保する仕組みの提供に取り組んでおり、ユーザーとしては製品選択で信頼性を上げることが現実的だ。

 ハイエンドのストレージ製品では、全プロセッサが同じアドレステーブルを保有し、いずれかが故障してもテーブルの書き換えなしで別のプロセッサがI/O処理を引き継ぐ機能や、複数経路からそれぞれの死活監視をすることで故障検知の精度を上げる機能などを実装するものもある。コストは高くつくが、重要な業務に対してはこうした製品を採用するのも手だ。

 業務データを扱うストレージでユーザーが取れる対策としては、基本的なことだが万が一に備えたバックアップが挙げられる。バックアップを取得したうえで、システムがダウンしても早期に業務復旧できるようリストア手順を整備しておくのだ。

 富士フイルムでは2012年1月の障害を受け、データロスなどの重大障害発生時の業務フローを整備した(図2)。障害発生時は解析・復旧チームとデータリストアのチームに分かれて作業する。ポイントは障害解析・復旧を一旦諦め、データのリストアに取り掛かるタイミングの設定だ。同社では平日の日中帯の場合、3~4時間以内に復旧のメドが立たなければ、バックアップデータをリストアする判断を下す。リストアするデータの順番も業務の優先度に応じあらかじめ決めてある。

図2●富士フイルムが新たに整備した業務フロー
システムの優先度に応じたデータリストアなど、緊急策に移行するためのフローと判定ポイントを新たに作成した
[画像のクリックで拡大表示] 』

東証システム障害の一部始終と残る疑問、NAS故障と切替設定の不備が重なる

東証システム障害の一部始終と残る疑問、NAS故障と切替設定の不備が重なる
山端 宏実、岡林 凛太郎、長倉 克枝、金子 寛人 日経クロステック/日経コンピュータ
https://xtech.nikkei.com/atcl/nxt/column/18/00001/04708/

※ まあ、当分は揉めるだろう…。

※ この記事で言われていることは、そもそも「実際には、NASのファームウエアの切り替え用設定値に誤りがあり、メモリー故障に起因する障害パターンが発生した際はNASの冗長化が機能しなくなっていた。」という事実が、「大抜かり」ではないのか、という「システムの運用・管理」の手際(てぎわ)に関する批判が一つ…。

※ もう一つは、その場合に「終日取引停止」とした「総合的判断」への批判だ…。

※ 関係各方面に「ヒアリング」した結果、「そっちの方が、傷は浅い、と判断した。」ということなんだが、その「ヒアリング」自体が、「適正手続きを踏んだもの」だったのか…。早速、「オレのところには、問い合わせが来て無いぞ。」という話しが、出ているようだ…。

※ 話しは、「証券各会社」間の競争へとも広がって行くような様相も見せている…。そういう「東証のシステム障害」をも、織り込んだ「料金設定」「顧客への事前通知・承諾の体制」となっているのかどうか…。そこら辺も、含んでの「競争力」「証券会社間の優劣」だろ…、という話しだ…。「護送船団方式」じゃないんだから、という話しだ…。

『 東証の売買システム「arrowhead(アローヘッド)」で取引に支障をきたす大規模なシステム障害が発生したのは2018年10月以来。システム障害により全銘柄の売買を終日停止する事態は東証が取引を全面的にシステム化した1999年以降初めてだ。

 これにより、3兆円規模の売買機会が失われた。影響は東証だけにとどまらず、arrowheadを使用している名古屋・札幌・福岡の各証券取引所でも10月1日の取引が全銘柄で終日にわたり停止となった。

設定不備で切り替えできず
 同社が最初に異常を検知したのは、午前9時の取引開始を約2時間後に控えた午前7時4分だ。arrowheadを構成する運用系ネットワーク内で、同社が「共有ディスク装置」と呼ぶNAS(Network Attached Storage)1号機のメモリーに故障が発生した。

NASは、arrowheadの複数のサブシステムが共通で使用する認証用のデータなどを格納している。1号機と2号機をActive-Active構成で運用しているが、1号機の障害発生時に2号機のみの運用へ自動で切り替える機能が正常に働かなかった。

 この影響で、本来はarrowheadのサブシステムの1つである「情報配信ゲートウエイ」を通じ、同日午前7時0分に送信すべき電文の送信ができなかった。別のサブシステムである「売買監視サーバー」や監視端末へのログインも不可能になるなど、NASの停止による影響はarrowheadを構成する複数のサブシステムに広がった。

 証券会社など外部に異変を通知したのは約1時間後の午前8時1分。さらに午前8時30分すぎに、午前9時からの取引を停止すると通知。午前8時54分には障害の影響が東証以外のシステムに波及しないよう、arrowheadと証券会社間の発注系経路を遮断。

原因究明と復旧作業を進めたが、結局午前11時45分に終日売買停止を発表した。原因となったメモリーが載った基板を同日中に交換したうえでシステムを再起動し、翌10月2日午前9時から売買を再開した。

 その後の調査で、富士通が納入したNASのファームウエアの設定不備が大規模障害につながったことが判明した。2台構成のNASの1台で障害が発生しても、本来はもう1台のみの運用に自動で切り替えてarrowhead全体の運用に支障が出ない設計だった。

 しかし実際には、NASのファームウエアの切り替え用設定値に誤りがあり、メモリー故障に起因する障害パターンが発生した際はNASの冗長化が機能しなくなっていた。

東証はarrowheadを2019年11月に刷新する際、事前のテストで2台のNASの死活監視を途絶えさせて、自動で切り替わることを確認していた。だがその際、今回の設定不備は見抜けなかった。設定作業そのものは富士通が実施していたという。

 東証と富士通は2020年10月4日までにファームウエアの設定を修正したが、なぜNASのファームウエアの設定不備を見抜けなかったのかが今後の焦点となりそうだ。

終日停止の東証判断は適切なのか
 今回のシステム障害では別の問題も浮き彫りとなった。実は午前9時26分の段階で、共有ディスク装置2号機への強制切り替えを完了しており、システムを再起動すればarrowheadを復旧できる状態となっていた。しかし東証は再起動を見送り、午後0時30分からの午後の取引もせずに終日取引停止とすることを正午前に発表した。

 同日夕方の会見で東証の宮原幸一郎社長はこの判断について「複数の市場関係者と協議した結果、(仮に取引時間中に復旧できても)システムを再起動すると(証券会社などから送信済みの注文の扱いなどを巡り)投資家などに混乱が生じることが想定され、終日売買停止することにした」と説明した。

これに対しauカブコム証券の斎藤正勝社長は「当社にそのような(協議の)問い合わせは来ていない。当社はイレギュラー対応でデータを修正すれば注文の失効手続きができる。平常時の手数料だけでなく障害対応も含めてサービス品質だ」とする。

 そのうえで斎藤社長は、証券会社はシステム障害が起こりうると見越してイレギュラー対応で迅速に取引再開できるよう、システム投資や事業継続計画(BCP)の整備を進めるべきだと指摘する。

 「一部の証券会社が障害への備えを怠り、東証もそうした一部証券会社に合わせて再開を見合わせるならば、BCPは画餅と化す。対応可能な証券会社だけでも早期に市場を再開させることこそ、東証が投資家に対し提供すべきサービスではないか」と疑問を呈する。』

「切り替え失敗」はよくある 東証システム障害の真因

https://www.nikkei.com/article/DGXMZO64611290V01C20A0000000/?n_cid=DSREA001

 ※ 貴重な、現場の状況をよく知っている方のご意見だと思うぞ…。大体、あまりご存じない方に限って、騒ぎ立てるモンだからな…。ご本人は、義憤にかられて、「多くの人々の見解・意見を代表している」ものと思って、発言していることが多い…。しかし、大体は、「的が外れている場合」が殆んどだ…。
 こういう意見・見解は、「本質思考」「問題解決思考」に基づいていると思われる点で、「建設的」だ…。

 ※ オレの「組み立て」の方の状況は、やっとこインターネットへの接続がうまく行った…。ルーターに入って、「IDとパスワードの直か打ち(じかうち)」で、解決した…。
 最初は、回線の工事業者が置いていった「接続キット一式」という段ボール箱に入っていた「簡単接続ソフト」なるものを、使って設定した…。CD-ROMかなんかで、提供されているものだ…。しかし、これが「トラップ」なんだよ…。ルーターに入って見てみると、何故か「正確に入力されていない」んだ…。全然違う「文字配列」になっていた…。どういうことなのか…。まあいい…。原因究明は、後回しだ…。

 今日は、「主要ソフト」の「ユーザー・データ」の移行に取りかかる予定だ…。これがまた、大変だ…。大体、「ユーザー・データ」がどこに「保存」されているかなんて、普段それほど注意して見ていないからな…。「まとめて」「フォルダ毎」「ドライブ毎」バックアップを取っている場合が殆んどだ…。しかし、今回のようなケースだと、データの移行は、「外付けHDD」+USB2とかでやることになった(詳しい説明は、省略する。また、語ることもあろう…)。そうすると、「デカいデータ」だと、「莫大な時間」がかかることになる…。それで、「ユーザー・データ」いちいち探して、チマチマ移転することにした…。
 そんなこんなで、ヒマなジジイの「人生」は、潰れて行くわけだ…。「ヤレヤレ…」かつ「トホホ…」だ…。

「切り替え失敗」はよくある 東証システム障害の真因
https://www.nikkei.com/article/DGXMZO64611290V01C20A0000000/?n_cid=DSREA001

『本当の問題はメモリーの故障でも、切り替え機能が作動しなかったことでもない――。東京証券取引所で10月1日に発生した大規模システム障害を筆者なりに分析するとこうなる。

真因はどこにあるのか。東証のシステム問題について、2005年のシステム障害、旧ジェイコム株の誤発注問題、06年の「ライブドア・ショック」による売買停止、12年のシステム障害と、継続的に取材してきた立場から検証してみる。』
『■午前9時過ぎには2号機に切り替わっていた

今回のトラブルの引き金は機器の故障だった。10月1日午前7時過ぎに東証の取引システム「arrowhead(アローヘッド)」で共有ディスク装置のメモリー障害を検知した。

共有ディスクは2台あり、通常なら故障した1号機の役割がもう1台の2号機に切り替わるはずだった。だが、自動で切り替える「フェイルオーバー」機能がうまく作動しなかった。相場情報の配信や売買監視の業務ができず、円滑な売買ができないと判断し、東証は売買停止を決めた。

午前9時過ぎには共有ディスク2号機への強制切り替えを完了していたが、売買を再開するにはシステムを再起動する必要があった。受け付け済みの売買注文が失効となるなど影響が大きいことから、東証は再開を断念。正午前に終日売買停止を発表した。

「東京証券取引所の役割は、公平で信頼でき、使いやすく分かりやすい市場を提供することです」。東証のウェブサイトにはこう書いてある。取引の場、つまりプラットフォームの提供が証券取引所の最大の使命であり、この使命を丸1日にわたり果たせなかったという点で、東証の責任は重い。

ただ、その責任を果たせなかった原因がどこにあるか、という点について、多くのメディアがうまく整理しきれていないように感じる。10月1日以降、各種メディアが「バックアップが機能しなかった」と繰り返し伝えている。テレビのニュース番組では経済の専門家が「何のためのバックアップなのか」と憤っていた。

システムの設計や信頼性に不備があったかのような指摘は、終日全面停止問題の本質を捉えているとは言えない。

■フェイルオーバーの失敗は珍しくない

ハードウエアの故障は一定の確率で発生する。そこで、信頼性が求められる場合、故障が発生してもシステムが稼働を続けられるよう、故障した機器の役割を待機系など別の機器に自動で切り替えるフェイルオーバー機能を用意しておく。だがフェイルオーバー機能が作動しないトラブルも、実はよくある。IT(情報技術)業界に身を置く人なら実感としてよく分かるのではないか。

例えば19年に発生したアマゾン・ウェブ・サービス(AWS)の大規模障害は、空調設備を管理する制御システムのフェイルオーバー機能が正常に機能しなかった。17年に東京商品取引所の売買システムで発生したシステム障害も、サーバーの部分的な故障をシステムが故障と判別できず、フェイルオーバーに失敗した。このほかにも、フェイルオーバーの失敗による大規模なATM障害などが発生している。

要は確率の問題である。対策を何重に講じても100%安全にはならない。トラブルが発生してから「機械が壊れたのがおかしい」「バックアップ機能が働かなかったのはおかしい」と批判しても、それは建設的な批判とは言えず、再発防止につながりにくい。

こう書くと「システム障害を肯定するのか」と反論されそうだ。もちろん肯定するつもりはない。システム障害の影響が拡大した真因は、フェイルオーバー機能の不具合とは別にあると筆者はみる。それは緊急時における対応の不備だ。

■緊急対応と復旧への準備に問題があった

システム障害の原因は朝のうちに特定でき、共有ディスク装置を交換してシステムを再起動すれば売買を再開できた。だが再起動すると証券会社側で通常と異なる対応が必要になるため、対応が難しいと東証は判断、終日の売買停止を決めた。

もちろん証券会社の意見を聞いて混乱を避けるのは、公正な取引を担う観点から必要な処置だ。東証は非常時の対応についてコンティンジェンシープラン(緊急対応計画)を用意しており、それに基づいて決断を下した。ただ、停止の条件や対応策については決めてあったものの、取引を再開するための取り決めや準備が十分ではなかった。

本来であれば、システムを全面停止せざるを得ない事態が発生した後、復旧に向けた準備が整ったら「証券会社とのやり取りを経て、システムを再起動し、取引所を再開する」といった復旧まで見通したプランを策定しておくべきだった。そのような準備があれば、1999年のシステム化以降初の「終日全面停止」は避けられた可能性がある。

情報システムの世界において「そこが故障したらシステム全体が動かなくなる」という重要な機器を「単一障害点」と呼ぶ。単一障害点に不具合があるとシステムの全面停止を招く。そのため単一障害点をできるだけなくすようにシステムを設計する。もちろん東証もそのような考え方に基づき、銘柄別に売買処理のサーバーを分散したり大量のデータ処理を分散したりする工夫を凝らしている。

それでも単一障害点をゼロにすることは難しい。10月1日にトラブルが発生した共有ディスク装置がまさにそれだ。制御データなど、一部の重要情報は一元管理せざるを得ないからだ。そこで機器の二重化といった対策も施す。

そのうえで、単一障害点が壊れた時のBCP(事業継続計画)を用意し、システム障害を想定した復旧までの訓練をこなすのが理想だ。東証は共有ディスク装置に障害が発生した際に2号機へと切り替えるテストはしていたとするが、2号機への切り替えが失敗してシステム全体が停止した際の取引再開手順まで訓練しておきたかったところだ。

機器の故障とフェイルオーバー機能の不具合によってシステムが全面停止し、復旧と取引再開までの準備不足が重なって影響が拡大。初の終日全面停止に至った。これが東証システム障害の真相とみる。

■稼働率を計算してみると

「言い方はとても難しいのだが、たまには軽微なトラブルが起こったほうが現場の緊張感を維持できる。こんなことは絶対に公の場では言えないが」。ある大手金融機関のシステム責任者がこう言っていたことがある。

東証のアローヘッドは12年のシステム障害以来、約8年にわたり安定稼働を続けていた。システムが安定稼働を続けるほど現場の障害対応力は鈍りやすい。安定稼働と緊急対応力の両立が、東証に課された使命であり、今後の課題だ。

株式取引システムや銀行の勘定系システムなど、社会生活に欠かせない重要なシステムは「99.999%(ファイブナイン)」の稼働率を求められる。ファイブナイン下では24時間稼働するシステムの場合、許されるトラブル停止時間は1年当たり5分強となる。

これまでの稼働時間やトラブルによる停止時間を基に東証のアローヘッドの稼働率を計算してみると、10月2日時点で99.94%となった。ちなみに終日全面停止が起こる直前、9月30日時点では99.98%だった。障害後もスリーナインは確保するものの、フォーナインはやや遠のいた。なおこの稼働率は筆者による独自の試算であり、東証が内部で管理している稼働率とは定義などが異なる可能性がある。

今後、稼働率をフォーナインつまり99.99%まで回復させるには、単純計算でノートラブルを50年ほど続ける必要がある。ファイブナインはさらに先だ。汚名返上の道のりは長い。

最後に一言だけ付け加えたい。システム障害の原因を説明するために東証が10月1日夕方に開いた記者会見は、聞いていて分かりやすかった。日本取引所グループの最高情報責任者(CIO)としてシステム全体を管轄する東証の横山隆介常務執行役員らが難解な専門用語を極力使わず、冷静かつ簡潔に事実関係を説明していたように感じた。

ネットでも「CIOさん、めちゃめちゃすごい」などの書き込みが目立った。システム障害は残念だったが、危機発生時におけるメディア対応という観点では合格点といえる。

(日経BP総合研究所イノベーションICTラボ 大和田尚孝)

[日経クロステック2020年10月5日付の記事を再構成]』

東証が新事実、ファームウエア設定不備でNASの冗長化が機能せず

https://xtech.nikkei.com/atcl/nxt/column/18/00001/04693/

 ※ 新事実が判明した…。

 ※ 「設定ミス」「単なるヒューマン・エラー」とも、言えない側面もあるようだ…。

 ※ 前の投稿の、「修正」の要素もあるようなんで、上げておく…。

 ※ オレの「PC組み立て」の方は、一応組み終わって、まだバラック状態だが、「OSインストール」は済んだ…。しかし、一部の機能が使えない(ケース前面のUSB2が、使えない…。マザボとの結線、間違ったようだ…。違うところに挿しているようだ…。USB3は、OK)…。それでも、まあまあ動いている…。

 ※ しかし、インターネットへの接続で「てこずって」いる…。詳しい説明は、省略するが、ルーターの設定に起因するかも知れん…。

 ※ 今日は、ルーターに「入って」、手動で設定を試みてみる予定だ…。

 ※ まあ、「ヤレヤレ…」と、「トホホ…」の連続だよ…。

『東京証券取引所で2020年10月1日に起きたシステム障害の全容が徐々に見えてきた。障害の原因は、富士通が納入したNAS(Network Attached Storage)のファームウエアの設定不備にあった。2台構成のNASでメモリー故障に起因する障害パターンが発⽣した際、NASの冗長化が機能しない設定になっていた。

 東証で10月1日に起きたシステム障害は、全銘柄の売買を終日停止するという未曽有の事態を招いた。東証が取引を全面的にシステム化した1999年以降、システム障害で全銘柄の売買を終日止めたのは初めて。これにより、3兆円規模の売買機会が失われた。』
『NASのメモリー故障が発端
 システム障害の発端は、東証の株式売買システム「arrowhead(アローヘッド)」のNASに搭載したメモリーの故障にあった。業務サーバーで使うユーザー情報などを格納するNASは2台あり、Active-Active構成で冗長化していた。このうちの1台のメモリーが故障し、本来なら1台のみの運用に自動で切り替わるはずが、うまくいかなかった。

関連記事:東証システムの「切り替え失敗」は設定値の誤り、テスト行程で見抜けず
 原因はNASのファームウエアの切り替え用設定値の不備にあった。東証はarrowheadを2019年11月に刷新する際、事前のテストで2台のNASの死活監視を途絶えさせて、自動で切り替わることを確認していた。だがその際、今回の設定不備は見抜けなかった。設定作業そのものは富士通が実施していたという。』
『問題の設定を変更し本番適用済み
 テストなどで設定の不備を見つけられなかった理由は今のところ分かっていない。東証の田村康彦IT開発部トレーディングシステム部長は「なぜこの事象を事前のテストで確認できなかったのかは引き続き検証していく」と話す。

 東証は原因判明を受け、ファームウエアの設定を変更。これにより、メモリー故障に起因する障害が起きても、NASの冗長化が機能することを確認済みだ。具体的には、10月3日にセカンダリセンター(バックアップセンター)で検証したうえで、10月4日にプライマリセンターの本番システムに適用した。

 東証の親会社である日本取引所グループは10月5日、システム障害の原因究明や再発防止策の実効性を高めるため、独立社外取締役で構成する「システム障害に係る調査委員会」を設置した。委員長には弁護士で日比谷パーク法律事務所代表の久保利英明氏が就いた。調査委員会では、システム障害の責任の所在も調べる。

 今後の焦点は、今回のシステム障害の原因となったNASのファームウエアの設定不備を見抜けなかった経緯だ。稼働前のテストに不十分な点がなかったかどうかなどを明らかにする必要がある。さらに、東証は証券会社側のさらなる混乱を避けるため、終日売買停止を決めたが、この判断そのものや決定のタイミングが適切だったのかも焦点になりそうだ。』

東証システムの「切り替え失敗」は設定値の誤り、テスト行程で見抜けず

東証システムの「切り替え失敗」は設定値の誤り、テスト行程で見抜けず
岡林 凛太郎 日経クロステック/日経コンピュータ
(2020.10.06)

https://xtech.nikkei.com/atcl/nxt/news/18/08897/

 ※ オイオイ…、という話しだ…。

 ※『「何らかの原因で実施したテストと同じ事象になっていなかった」』とか、一体何のための「テスト」なんだ…、という話しだ…。

 ※ 結局は、「設定ミス」というヒューマン・エラーか…。「大山鳴動して鼠一匹」…、という話しか…。

『東京証券取引所は2020年10月5日、株式売買システム「arrowhead(アローヘッド)」で10月1日に発生したシステム障害について、メモリー故障が起きた共有ディスク装置1号機を2号機に自動で切り替えられなかった原因を説明した。共有ディスク装置1号機が備える制御機構の設定値の誤りだったと明らかにした。

 東証はアローヘッドの運用系ネットワークで使う共有ディスク装置を、1号機と2号機の構成で運用している。メモリー故障に起因する障害が起きた場合に自動的に2号機に切り替えができない設定値になっていたという。

 共有ディスク装置1号機と2号機の死活監視が切れた場合に自動で共有ディスク装置が切り替わることはテスト行程で確認していた。今回の事象でも共有ディスク装置1号機のメモリーが故障した時に死活監視が切れたと考えられ、自動で2号機に切り替わるはずだったが「何らかの原因で実施したテストと同じ事象になっていなかった」(東証の田村康彦IT開発部トレーディングシステム部長)。

 設定値の誤りをテスト行程で防げなかった理由については現在も調査中という。共有ディスク装置でほかの設定に誤りがないかについては「富士通と検証して問題ないことを(既に)確認している」(同)とした上で、さらに検証を進めるとした。』

富士通社長が謝罪 東証システム障害

富士通社長が謝罪 東証システム障害
「原因究明と再発防止に全力」
https://www.nikkei.com/article/DGXMZO64607090V01C20A0000000/

『富士通の時田隆仁社長は5日、東京証券取引所で1日にシステム障害が発生し、全銘柄の取引が終日停止されたことについて「障害の原因となった機器の納入、システムを構築した企業のトップとして、多くの皆様に多大なるご迷惑をおかけしたことを心よりおわびする」と謝罪した。問題発生以降、時田社長がシステム障害について言及するのは初めて。

自社のデジタルトランスフォーメーション(DX)に向けた取り組みを紹介するオンライン会見の冒頭、システム障害について謝罪の言葉を述べた。「原因究明と再発防止に全力で取り組む」と話し、東証と連携して速やかに再発防止策を講じるとした。

東証で1日に発生したシステム障害は、売買注文を受け付ける基幹システム「アローヘッド」が引き金となった。運用をつかさどる記憶装置のうち1台で、制御用のメモリー(主記憶装置)が故障した。故障が発生すると本来は自動的に代替機に処理が切り替わるはずだったが、機能しなかったという。東証は1日の会見で、「富士通と共同で原因の解明を進めている」と説明した。

東証は2012年にもアローヘッドのシステム障害を起こしている。このときはサーバーで故障が発生し、適切に代替機に処理が切り替わらなかった。富士通は当時も東証と共同で原因究明にあたり、再発防止策を講じた。装置の種類は異なるが、代替機に切り替わらなかった点は今回も共通する。

金融庁は2日、日本取引所グループと東証に対し、金融商品取引法に基づく報告徴求命令を出した。装置の点検が十分だったかや、内部管理体制などについて報告を求める。』

東証売買停止、バックアップに不備 メモリー故障が発端

https://www.nikkei.com/article/DGXMZO64506130R01C20A0EA2000/

※ いろいろ、言われている…。その「共有ディスクシステム」の「コントローラー」が、「完全に死なず、半分死んで「ゾンビ状態」だった(つまり、「オレは、死んだ」というアラートが出なかった)からじゃないか…。」、と言っている人がいた…。

『東京証券取引所で1日起きた売買の終日停止は、システムのバックアップが機能しなかったことが主因だ。きっかけは基本的な情報などを格納するディスク内のメモリーが故障したことだが、もう一つのディスクへの切り替えがうまくいかなかった。2012年のシステム障害でもバックアップが機能しない問題が発生しており、同じ要因が繰り返された。システム全体が止まりやすい構造に問題が無いか、究明が必要になる。

【関連記事】
東証社長「市場運営者として責任痛感」 終日売買停止
東証売買停止、投資家に5つの影響
富士通「ご迷惑かけおわび」 東証のシステム障害で

「『ネバーストップ』を合言葉に市場の安定的な運営を心がけてきた。このような事象が起き、深くおわび申し上げる」。東証の宮原幸一郎社長は1日夕の記者会見でこう陳謝した。コンピューターの処理速度だけではなく、安定性と信頼性を重視したシステムを目指してきたが、取引は終日止まってしまった。

東証によると、2010年に導入した高速取引システム「アローヘッド」では、銘柄名やその日の基準値段など基本的な情報を格納しているディスクが2つあり、「共有ディスク装置」と呼ばれる。今回は午前7時4分に1号機のディスクの故障を検知。通常は、1号機と同じ情報を書き込んでいる2号機に自動的に切り替わるが、バックアップがうまくいかなかった。

システムのバックアップを巡っては、東証では12年2月にも情報配信システムで障害が発生している。1台のサーバーに障害が発生し、別のサーバーに処理を切り替えたつもりだった。ところが、実際には失敗しており、同日午前中の一部銘柄の取引停止につながった。

今回、故障した機器はわかっていたため、ディスクを交換してシステムを手動で再起動をすれば売買再開は可能だった。ただ証券会社からの注文を受け付けていたため、再起動した場合、こうした注文がリセットされてしまう。

注文を出す証券会社側でも通常とは異なる処理が発生する可能性が高かった。そのため「大手や外資、ネット証券など市場参加者の意見を聞いて、混乱を回避するために終日の売買停止を決めた」(株式売買を担当する川井洋毅執行役員)。

原因の究明はこれからだ。故障したディスクやメモリーは富士通製。東証でシステム部門を統括する横山隆介常務執行役員は「ハードの故障自体は想定している。富士通に機器を持ち込み、なぜ自動的に2号機に切り替わらなかったのかという点を調べる」と話した。

富士通は、アローヘッドの設計・開発を一貫して手がけてきた。約350台のサーバーで構成する大規模システムで、今回故障したディスク装置や、正常に作動しなかった2号機への切り替えシステムも手がけていた。

共有ディスク装置は、アローヘッドを刷新した19年11月に導入したものだ。メモリーの故障が発生したのは今回が初めてという。「テストでは正常に切り替えができていた」(東証の横山氏)が、1日は作動しなかった。

【関連記事】
東証システム障害、取引一極集中の危うさ露呈
東証、3兆円の取引機会失う 売買停止で
東証、情報開示に遅れ 投資家への説明も不足

まだ原因は判明していない。ただ、情報処理推進機構ソフトウェア・エンジニアリング・センターの元所長の鶴保征城氏は「重要システムにとって、障害を早期に見つける機能の信頼性確保は最後の課題だ」と指摘。「切り替えがきちんと動作するか、頻繁にテストしなければならない。その意味では残念ながら東証の怠慢と言わざるをえない」と話す。

東証では明日からの取引再開を目指すが、当面はディスク装置を人手で監視して、強制的に切断するなど取引に影響が起こらないように対応するという。東証の宮原社長は、富士通に損害賠償は求めない方針を示した。

富士通は1日、「当社の納入したハードウエアに障害が生じて多くの関係者の皆様に多大なるご迷惑をおかけしたことを、おわびいたします」とコメントした。

金融の大規模システムの設計に詳しい技術者は「障害を発生させないようにする設計が時代遅れだ」と話す。一部の機能が故障しても取引が止まらないように設計すべきだと指摘している。』

ライブ映像 東証でシステムトラブル 全銘柄で取引停止 宮原幸一郎社長ら記者会見

https://www3.nhk.or.jp/news/realtime/rt0003680.html?utm_int=all_contents_realtime_001

 ※ まだ会見は続いている…。

 ※ 原因について、語ったことを要約すると、次のような内容のようだ…。

 ※ ここのシステムは、大きく分けて、「売買を処理するシステム」と「取り引き情報を顧客に配信するシステム」に分かれている。今回のトラブルは、後者の「配信システム」の「ハード」に生じたらしい…。

 「共有ディスクシステム」というハードがある…。そこの「コントロール・システム」に「故障」が発生した…。
 この「コントロール・システム」は、「マザボ」「CPU」「メモリ」などから成り立っている…。
 どうも、そのうちの「メモリ」に故障が発生したようだ…。

 それで、そういう「ハード」に故障が発生した場合には、「バックアップ」システムのほうに「自動で切り替わる」体制にしてある…。しかし、今回なぜか「自動で切り替わらなかった」…。
 その原因は、現在ハードの納入業者(富士通らしい)を呼んで、解析してもらっている(どうも、乗っかっている「ファームウエア」が原因じゃないか…、というような話しになっているらしい…)。

 それで、「バックアップ体制」に自動で切り替わらなかったんで、顧客に取り引き情報を配信できない状態になった…。さらに、「故障したハード」を交換して、システム全体を「再起動」するとなると、相当の時間が掛かってしまう…。
 中途半端に「取り引き」を行うよりも、「終日取り引き停止」の処置を取る方が、却って「傷は浅くて済む」と総合的に判断した…、というような話しだった…。

 なお、ログの解析(常時、観察している)などから、「サイバー攻撃」の可能性は低い…、と判断しているということだった…。

東証、終日売買停止 システム障害で初

https://www.nikkei.com/article/DGXMZO64460870R01C20A0I00000/

 ※『東証関係者によると、「外部からのハッキングなどが原因ではない」としている。』と言うことだ…。

 ※『東証のシステムには、売買注文を付け合わせる基幹システムの「アローヘッド」のほか、株価情報などを配信する情報系システムがある。今回は情報系のシステム部分に障害が発生したとみられる。アローヘッドを設計・開発した富士通は「東証と共同で状況を確認している」としている。』と言うことだ…。

『東京証券取引所は1日、株価など相場情報の配信が停止していることを受けて終日取引を取りやめると発表した。午前9時の取引開始から全ての銘柄で売買を停止していた。復旧のめどはたっておらず、原因を調査している。東証で株式の売買が終日停止されるのは、1999年の取引のシステム化以降初めて。

先物など金融派生商品(デリバティブ)を取り扱う大阪取引所は通常通り動いている。ジャパンネクスト証券などが運営する私設取引システム(PTS)上でも取引が行われており、複数の個別銘柄の取引が成立している。

東証の株価など相場情報を配信するシステムに障害が発生している。復旧のめどはたっておらず、原因を調査している。東証関係者によると、「外部からのハッキングなどが原因ではない」としている。

【関連記事】
東証売買停止 市場に不安の声「朝から何もできない」
官房長官、東証システム障害「大変遺憾」

障害は1日の取引開始前に判明。投資家の注文を取引所につなぐ証券会社などに全銘柄の売買を停止すると通知し、8時30分ごろにホームページ上でも公表した。

名古屋証券取引所は1日、東証で発生した障害に伴い名証での全銘柄の売買を停止すると発表した。札幌証券取引所、福岡証券取引所も同様に全銘柄の売買を停止した。名証などは東証のシステムを利用しているため障害により取引ができなくなる。

日経平均株価や東証株価指数(TOPIX)など各種株価指数は算出できていない。上場投資信託(ETF)やインフラファンド、新株予約権付社債(転換社債=CB)も取引が止まっている。

投資信託協会は1日、緊急対策委員会を開き、主に日本株に投資する投信について、同日分の設定・解約を停止する方針を決めた。基準価格に対する影響を重視し、純資産総額に対して日本株を2割以上組み入れている投信について設定・解約を停止する。

東証は旧ライブドアへの家宅捜索を機に売買が急増した06年1月に、システムダウンを避けるため自主的な判断で全銘柄の売買を停止したことがある。

東証のシステムには、売買注文を付け合わせる基幹システムの「アローヘッド」のほか、株価情報などを配信する情報系システムがある。今回は情報系のシステム部分に障害が発生したとみられる。アローヘッドを設計・開発した富士通は「東証と共同で状況を確認している」としている。

複数の取引所やPTSでの取引が可能な米国などと違い、日本の場合は現物株の取引の9割程度が東証に集中している。東京証券取引所などの売買停止を受け、私設取引システム(PTS)では日本取引所グループや、株式売買の基幹システムを開発した富士通の株価が下落している。

 東証の売買停止に関連して、日経平均株価が1日午前9時時点で前日終値に比べ19銭安の2万3184円93銭と配信されている。これは同日の銘柄入れ替えに伴う除数の変更を9月30日終値に反映した値。1日の日経平均は算出されていない。』

東証の売買停止に関する続報はなし 原因や再開見込みは依然不明

https://www.nikkei.com/article/DGXLASFL01HDE_R01C20A0000000/

『東京証券取引所などでの全銘柄の売買停止について、本来であれば午前の取引時間が終了する11時30分時点で、東証を傘下に持つ日本取引所グループ(8697)から原因や取引再開の見通しなど新たな発表はない。』