再起動！？ [雑感]
少し前の10月1日東京証券取引所（東証）のシステムで障害が発生、「午前8時54分にネットワークを遮断し、取引を停止した」と報道されている。
翌日には復旧して取引を普通に開始したけれど、当事者の東証とこのシステム「arrowhead（アローヘッド）」を開発した富士通はたっぷり冷や汗をかいた事だろう。それに、同類のシステムに関わっている鉛筆土方（システムエンジニアの別称）も「明日は我が身」と感じているのではないだろうか。
今回の件は国内メディアからすれば「記事にすれば確実に売れるトラブル」だろうから大喜びで書き立ててるし、メディア以外でもあちこちで色々書かれている。 複数の報道に依れば、直接の原因は「共有ディスク装置内のメモリ故障」だったらしい。
本来なら障害発生で自動切替の筈なのに今回は何故か切り替わらず、手動で切り替えるとなるとシステムの再起動が必要だという。しかし、証券会社から既に発注データを受信していた為にシステム再起動するとその発注データ全てが消滅してしまうという理由から、丸一日システム停止という対策を選んだ、という。
これだけを読んでみると「あぁ、そうなの」でお終いなのだが、拙者は非常に強い違和感を覚えてしまうのである。
ネット上で、arrowheadのようなシステムは「富士通と日立しか作れない」と断言する記事もあったけれど、拙者から見ればこの物言いは視野狭窄というか「何を指して2社しか作れむと言ふ？」と感じてしまう。
今回のarrowheadのみならず、銀行の勘定系システム・生産管理システム・列車運行管理システム・公にはその存在を含め一切公表されない某システムなど、一度動かしたら簡単には止められないシステムというのは幾らでもある。コンピュータシステムでは無いけれど、人工呼吸器などもそういった類の機器の一つだ。
一般的には、止まっては困るシステムは、fault tolerant（フォールトトレラント）な設計にする事が多い。
フォールトトレラントとは、簡単に言えば「何処かが故障しても自動的に故障部分を回避してシステムを止めないようにする事」である。システム設計上、全ての機能をフォールトトレラントにすると凄まじいコストが掛かるので、必要最小限の範囲をフォールトトレラントとする事が多い。
この手のシステム製品は結構数が出ているけれど、一般的ではないので鉛筆土方でも知っている人は限られる。
当然ながら、arrowheadも何かしらフォールトトレラント設計になっていると思われる。
でっ、一番最初に違和感を感じたのは「再起動が必要」と言う点である。
今回故障の原因となった共有ディスク装置も含めて、入出力装置をシステムに組み入れる場合、一般的には単純な操作で終わる筈なのである。
例えば、Microsoftのパソコン用OSであるWindows等は、OSの更新・ソフトのインストール等、何かに付けてシステムの再起動を要求してくるから、「再起動」という単語にはあまり違和感を感じないかも知れない。Microsoft製品は個人向けで元々から「システム構成変更時は再起動する前提」のシステムだからであって、業務で使われるシステムでは再起動という作業はあまり一般的ではない。
「記憶装置の切り替えに再起動が必要」と聞くと「記憶デバイスのドライバをカーネルにぶち込んでるんかぃ！？モノリシックで随分と不思議なシステムじゃね？」「ひょっとしてベースは大型メインフレーム使ってるん？」...なんて書くと「何じゃそれ？」と思われる人が殆どだろうが、誰にでもある程度分かるように説明しようとしたら、それこそ大学レベルの講義内容かそれ以上になっちゃって大変なので、あえて説明はしない。A(^^;)gomen-chai...
パソコンなら再起動させてもせいぜい数分程度だが、大型のシステムとなると1時間以上かかるのは珍しくない。だからこそ「再起動」という作業は極力やらないようにするのがシステム設計では当たり前だったりする。
もう一つ、違和感を感じたのは「共有ディスク装置の障害」である。
機械である以上は故障は避けられない。だからこそ色々な対策を施すのだが、その対策方法によって構築コストが大幅に変わってくる。富士通がどのような設計をしたのかは知らないが、最低でも障害発生時に自動切換えになるようにはしていた筈だと思う。
システム完成時には、当然マニュアルクラッシュ（あっ、業界用語！？か...わざと障害を発生させるシステム・テストの事）などで何度も動作確認している筈だし、万が一自動で切り替わらなかったとしても代替手順を用意している筈。「何で切り替わらなかったん？まさか...（以下、略）。」
更にもう一つ違和感を感じたのが「再起動すると発注データが消える」という点である。
発注データは外部から受信したデータだから、一時的に何処かに蓄える仕組みになっていると思われる。が、再起動で消えてしまうとなると、システム内部のどこかに貯めてあるだけで、何処にもコピーを保存していないという事になる。「それって、適正なシステムなん？」と思わずにはいられないのである。
発注データの構造にも依るけれど、単純に考えれば発注を受ける部分のサブ・システムだけを切り離して動かした状態にしておき、メイン・システムの正常稼働を確認してから再接続すれば済む話。それが出来ないシステム構造にしなければならない理由は見当たらないように思うのだが、果たして...？？？
拙者は部外者だし、メディアの流しているどこまで正確なのか分からない情報のみで推測しているので、どこからどこまでが正しいのかも不明だが、少なくともシステム設計上に何かしらの不具合があるのでは？と思う。
今後どう対応したかについても報道があるかも知れないが、システム内部を知られないようにする為にも、恐らく具体的な処置については言及が無いだろうと思う。
少し前にMicrosoftのOffice関係のシステム（？）が障害か何かで止まってしまい、色んな方面で影響が出たらしいけれど、東証のシステムとなると海外投資家などにも影響を与えてしまうので、重要度のレベルは段違いで「止まってはいけない」のに、止まってしまった。
今回のトラブルは上辺だけを見れば「システムの障害」である。が、その原因を深堀りすると「技術者の給与水準が低い」と言う国内特有の事情に行き当たるのでは？と勘繰るのは考え過ぎだろうか。
翌日には復旧して取引を普通に開始したけれど、当事者の東証とこのシステム「arrowhead（アローヘッド）」を開発した富士通はたっぷり冷や汗をかいた事だろう。それに、同類のシステムに関わっている鉛筆土方（システムエンジニアの別称）も「明日は我が身」と感じているのではないだろうか。
今回の件は国内メディアからすれば「記事にすれば確実に売れるトラブル」だろうから大喜びで書き立ててるし、メディア以外でもあちこちで色々書かれている。 複数の報道に依れば、直接の原因は「共有ディスク装置内のメモリ故障」だったらしい。
本来なら障害発生で自動切替の筈なのに今回は何故か切り替わらず、手動で切り替えるとなるとシステムの再起動が必要だという。しかし、証券会社から既に発注データを受信していた為にシステム再起動するとその発注データ全てが消滅してしまうという理由から、丸一日システム停止という対策を選んだ、という。
これだけを読んでみると「あぁ、そうなの」でお終いなのだが、拙者は非常に強い違和感を覚えてしまうのである。
今回のarrowheadのみならず、銀行の勘定系システム・生産管理システム・列車運行管理システム・公にはその存在を含め一切公表されない某システムなど、一度動かしたら簡単には止められないシステムというのは幾らでもある。コンピュータシステムでは無いけれど、人工呼吸器などもそういった類の機器の一つだ。
一般的には、止まっては困るシステムは、fault tolerant（フォールトトレラント）な設計にする事が多い。
フォールトトレラントとは、簡単に言えば「何処かが故障しても自動的に故障部分を回避してシステムを止めないようにする事」である。システム設計上、全ての機能をフォールトトレラントにすると凄まじいコストが掛かるので、必要最小限の範囲をフォールトトレラントとする事が多い。
この手のシステム製品は結構数が出ているけれど、一般的ではないので鉛筆土方でも知っている人は限られる。
当然ながら、arrowheadも何かしらフォールトトレラント設計になっていると思われる。
今回故障の原因となった共有ディスク装置も含めて、入出力装置をシステムに組み入れる場合、一般的には単純な操作で終わる筈なのである。
例えば、Microsoftのパソコン用OSであるWindows等は、OSの更新・ソフトのインストール等、何かに付けてシステムの再起動を要求してくるから、「再起動」という単語にはあまり違和感を感じないかも知れない。Microsoft製品は個人向けで元々から「システム構成変更時は再起動する前提」のシステムだからであって、業務で使われるシステムでは再起動という作業はあまり一般的ではない。
「記憶装置の切り替えに再起動が必要」と聞くと「記憶デバイスのドライバをカーネルにぶち込んでるんかぃ！？モノリシックで随分と不思議なシステムじゃね？」「ひょっとしてベースは大型メインフレーム使ってるん？」...なんて書くと「何じゃそれ？」と思われる人が殆どだろうが、誰にでもある程度分かるように説明しようとしたら、それこそ大学レベルの講義内容かそれ以上になっちゃって大変なので、あえて説明はしない。A(^^;)gomen-chai...
パソコンなら再起動させてもせいぜい数分程度だが、大型のシステムとなると1時間以上かかるのは珍しくない。だからこそ「再起動」という作業は極力やらないようにするのがシステム設計では当たり前だったりする。
機械である以上は故障は避けられない。だからこそ色々な対策を施すのだが、その対策方法によって構築コストが大幅に変わってくる。富士通がどのような設計をしたのかは知らないが、最低でも障害発生時に自動切換えになるようにはしていた筈だと思う。
システム完成時には、当然マニュアルクラッシュ（あっ、業界用語！？か...わざと障害を発生させるシステム・テストの事）などで何度も動作確認している筈だし、万が一自動で切り替わらなかったとしても代替手順を用意している筈。「何で切り替わらなかったん？まさか...（以下、略）。」
発注データは外部から受信したデータだから、一時的に何処かに蓄える仕組みになっていると思われる。が、再起動で消えてしまうとなると、システム内部のどこかに貯めてあるだけで、何処にもコピーを保存していないという事になる。「それって、適正なシステムなん？」と思わずにはいられないのである。
発注データの構造にも依るけれど、単純に考えれば発注を受ける部分のサブ・システムだけを切り離して動かした状態にしておき、メイン・システムの正常稼働を確認してから再接続すれば済む話。それが出来ないシステム構造にしなければならない理由は見当たらないように思うのだが、果たして...？？？
今後どう対応したかについても報道があるかも知れないが、システム内部を知られないようにする為にも、恐らく具体的な処置については言及が無いだろうと思う。
少し前にMicrosoftのOffice関係のシステム（？）が障害か何かで止まってしまい、色んな方面で影響が出たらしいけれど、東証のシステムとなると海外投資家などにも影響を与えてしまうので、重要度のレベルは段違いで「止まってはいけない」のに、止まってしまった。
今回のトラブルは上辺だけを見れば「システムの障害」である。が、その原因を深堀りすると「技術者の給与水準が低い」と言う国内特有の事情に行き当たるのでは？と勘繰るのは考え過ぎだろうか。
ハッキングって可能性はないでしょうか?
by ガバチョ (2020-10-06 22:30)
ガバチョさん
可能性はゼロじゃないけど（詳細は書けませんが）実際には非常に難しいでしょうね。
内部からなら、攻撃はかなり楽でしょうけど。
by Rifle (2020-10-06 22:55)