前回（東証システム障害とITシステム）の続きです。続きを書くつもりは無かったが、あまりに赤面な発言を見てしまったので。
10/2に以下記事が出ていた。国民民主党党首の玉木氏の変なツイートを指摘し、会見を行った東証のトップを評価した、非常にまともな記事と思う。
問題の玉木氏のツイートはこちら。記事と重複ながらツッコミを入れたい。
世界３位の時価総額を誇る東証の終日取引停止はIT先進国とは言えない事態。日本の株式市場に対する世界からの信頼が損なわれかねず速やかな復旧を求めたい。他の取引所にも拡大しておりサーバー型ではなくシステムのブロックチェーン化など分散化を進める必要もあると思う。 https://t.co/LJutd1rjG0
— 玉木雄一郎（国民民主党代表） (@tamakiyuichiro) 2020年10月1日
- 政治家が技術の専門家でないのは当然だ。専門用語が多少不正確でも仕方ない。しかし流行りの用語のしったかぶりは、軽薄で読む方が赤面するのでカンベンして欲しい。判らないなら「分散化を進める必要もあると思う」だけで良いのだ。
- ブロックチェーンは仮想通貨（暗号資産）用の技術だ（実際の経緯はビットコイン登場が先でブロックチェーンは後だが。）善意で解釈すれば「証券システムは今後は仮想通貨もサポートすべき」かもしれないが、それでは「分散化」と関係が無く意味不明だ。（通貨の種類と、証券売買システムの信頼性は関係ない。）
- 「サーバー型ではなく」も意味不明だ。「サーバー」はソフトウェア上の役割分担であるクライアント・サーバーモデルの片側で、そこから転じてサーバー向けのコンピュータ、更には従来型のコンピュータ（メインフレーム/オフコン/スパコン等）との対比で使用されている用語だが、どの意味でも「分散化」との対比にはならない。むしろ「サーバー＝分散システム（日本ではオープンシステムとも）」と呼ばれている。善意で解釈すれば「1箇所に設置のシステムではなく、システムとリスクを分散」との趣旨かと思うが、やはり「サーバー型」では意味不明だ。
繰り返すが、政治家が技術用語が多少不正確でも仕方ない（お互い様）。しかし訳がわからないなら普通の言葉、例えば「故障しても業務影響が限定できるシステムも検討すべきだ」とかと言って欲しい。
思わず夜中に予定外のブログを書いてしまった。カンベンしちくり（八つ当たり）
（追記）既に以下ツイートされているようですが...
本tweetに対し多くの専門家からのリプをいただき勉強になりました。高速取引にはブロックチェーン技術は遅すぎるとか、ブロックチェーンを使ったからといってリスク分散できるわけではないとか、いろいろ教えていただき感謝です。今後生半可な知識での話は慎みますので皆さん懲りずにご指導ください。 https://t.co/66vuFJ07s9
— 玉木雄一郎（国民民主党代表） (@tamakiyuichiro) 2020年10月2日
そして「分散化」は別に高度な話ではない。以下は一般論ですが、
- 統合した大証や名古屋/札幌/福岡を別システムに分離。基本設計共通化なら全体費用圧縮もできる。分離の上で東京/大阪の相互バックアップ/災対も有力。取引所間連携は疎結合(MQなどの非同期キューイング)も組み合わせ可。
- 1システムでも大手銀行のように内部2系統化。この場合も今回同様にデータベースがネックになるが、ここはクラスタリング（メインフレームのSysplex、分散システムのORACLE RAC）またはDISK装置側のメトロミラー、あるいはタイムラグはあるがDBログ反映など。（しかし恐らくこれらを比較検討した結果、オンメモリDBとDISK装置2台の自動切替になったと思われるが）。
- 単純にDISK装置障害対応なら、仮にRAID-5ならRAID-10化、各DISK装置筐体に対してミラーのバックアップDISK装置筐体を付ける、など。処理速度とのトレードオフだが。
- 運用改善。今回、2019年11月更改時のテストではDISK装置自動切替は機能していたらしい。以後の再確認テストは不明だが、しかし特にDISK装置のファームウェアは毎月でも更新すべきだし、更新後は無影響確認が望ましく、他の作業時の人為的誤設定混入リスクも常にある。四半期ごとに災害訓練（稼働確認）していれば業務停止時間帯時に早期発見でき、原因混入時期も絞れたた可能性もある（定常業務以外の実施リスク、保守時間帯、運用負荷などとのトレードオフだが。）
以上は全て20年前から一般的な技術/手法だ。ファームウェアによるハードウェア故障の早期検知レベルなど向上した個々の技術要素も多いが、障害対策（高可用性設計）は確立した1分野で、アーキテクトなら必須で、営業/政治目的などで最新技術アジデータに陥ってはならない。
（了）
