JPX の障害について思う事
前書き
2020年10月1日に起きた JPX（Japan Exchange Group) の東京証券取引所（以降、JPX と表記）での障害について個人的に興味があったので少しだけ調べてみました。それを前提に、思う事を書いていきたいと思います。以下の様な事に触れます。
- JPX と Arrowhead に関する前提知識
- 過去起きた障害とその対応
- 個人的な提案
なお、ここに書いてある事は私の意見・感想であり、所属する会社・団体等とは何ら関係ありません。ネット上で信頼に足ると考えるソースから取得した情報を元に書いていますが、何か事実と異なる情報がありましたらご指摘下さい。また、ネット上で言われている事と現場で見える景色は全然違う、という事はよくあると思います。もし現場の方が違和感を感じられたら、こちらもご指摘下さい。
スーパーまとめ
お忙しい方は、要諦を先に書いておいて欲しいと思われるかもしれませんので、先に重要なトピックを書いておきます。
- 今回の対応は過去起きた障害とそれに対して行われた改善策の積み上げによってもたらされたものと考えており、現 CIO の対応力だけで見るのは近視眼的で、歴史含めて参考にすべきだと考えます。具体的には、元 CIO の鈴木氏の思想と仕事の影響が大きかったのではないかと考えます。
- 客観的に見れば Arrowhead は負けました。自らが提示した定量的な目標を大きく下回るダウンタイムになったからです。
- 報告書はエンジニアに書かせ、過度に抽象化した報告書をやめる事を提案します。
- プロジェクトマネジメントとして、異常系の対応の優先順位の見直しを提案します。
- カオスエンジニアリング（的テスト）の導入を提案します。
JPX と Arrowhead に関する前提知識
JPX ではオンライン取引システムとして、Fujitsu に開発させた Arrowhead と呼ばれるシステムを利用しています。ちなみに私はこういった商流にあまり詳しくないため、実際のところどこのどういった会社の誰が実際にコードを書いているのかなど、これ以上の事については分かりません。
私が調べた限り、Arrowhead は以下の3バージョンがある様です（細かいバージョンアップ等はもっと頻繁に行っていると思いますが、メジャーなものは下記だと思います）。ここでは参照のために v1, v2 などと表現しますが、これは正式なバージョンではないのでご注意下さい。
- 2010年1月4日版（CIO: 鈴木義伯氏, v1）
- 2015年9月24日版（CIO: 澁谷裕以氏, v2）
- 2019年11月5日版（CIO: 横山隆介氏, v3）
約5年ごとにメジャーバージョンアップが行われている様です。それぞれ、参考になりそうな資料を貼っておきました。2010年のリリースを見れば分かる様に、この頃から経営陣が前のめりでシステム開発に関わっている様が見て取れます。ここは個人的な予想であり感想ですが、
arrowhead の開発にあたって鈴木 CIO が強調したのは、「要件定義は発注者である東証が責任を持つ」(SEC journal, 2010, Vol.6 No.2)
とある様に、システム（の、少なくとも要件）については東証が責任を持つというスタイルはこの頃から根付いていた（あるいは鈴木氏が強烈に発信していた）様に思います。現 CEO の Fujitsu への責任は問わないという姿勢は、このあたりの風土から来ているのではないでしょうか。
また、Twitter では CIO の横山氏の対応を称賛する声が多く聞かれましたが、私には少し違和感がありました。というのも、それなりの規模でサービスを運用している会社のリードエンジニアであればあの程度の受け答えはできるな、という感覚があったためです。少なくとも私のまわりにはそういうエンジニアがたくさんいましたし、仮にも数百億規模のシステムを組む会社の情報系のトップがそれくらいの受け答えをできないでどうするの、という感覚でした。
なお、調べた限り、歴代 CIO は下記の様です。
- 2006年2月〜 鈴木義伯氏
- 2015年6月〜 澁谷裕以氏
- 2017年4月〜 横山隆介氏
v2 は澁谷裕以氏が CIO の期間にリリースされた様ですが、この記事（東証、ネバーストップ作戦 5年ぶりシステム刷新）にもある様に実質の開発は鈴木氏在任中に行われていたと見るのが順当な気がします。
調べてみると（次の項で書きますが）2005年の障害があった後、当時社長の西室泰三氏がシステムの改善が急務と判断し、NTT にリクエストを出し結果として鈴木氏が着任したという事の様です。この資料（「経営者が参画する要求品質の確保」の思想を核に新システム開発を成功に導く）を見ると（鵜呑みにすると）、鈴木氏は自ら4000ページにおよぶドキュメントに全て目を通してチェックしていた様です。形だけの CIO とはちょっと違うなと私は感じました。外部に公開されている資料も鈴木氏のものが多いですし、この記事（間違った方向に行きかけたとき、プロジェクトを止める勇気を持てるか）を見ると後進の育成にも熱心な様です。
後は、人を育てていきたいと思っています。とはいえ、育てようと思ってもなかなか人は育ちません。それよりも一緒に仕事をして成果を共有しながら、背中で人を育てていきたいと思っています。とにかく日本郵便の場合は人が足りないので、社員には一人二役をこなせるぐらいの知力を付けてほしいなと思っています。
この様な情報から、私は今の JPX の体制は鈴木氏あってこそだったのではないか？今回の障害対応の立役者は鈴木氏だったのではないか？と思う様になりました。
過去起きた障害とその対応
JPX では過去何度か障害が起きていますが、これについて簡単にまとめてみました。
-
2005年11月1日
- 旧システム
- ダウンタイム：3時間30分
-
2012年2月2日
- Arrowhead v1
- ダウンタイム：2時間30分
-
2018年10月9日
- Arrowhead v2
- ダウンタイム：設定によってはアクセスできたため、評価が困難。通知が出るまではおよそ30分
- 2020年10月1日
- Arrowhead v3
- ダウンタイム 5時間（終日取引不可）
こうして見ると、Arrowhead はどのバージョンでも障害が起きている様ですね。また、Arrowhead は歴代で 99.999%（5年間で10分程度のダウンタイム、と東証は言っている）の可用性を目標として謳っている様です。バージョンごとにどこまで抜本的に変更が入っているのか分かりませんが、すごく単純に計算すると2010年から稼働しているので10年程度稼働しており20分程度のダウンタイムが見込まれます。結果としては合計で10時間弱のダウンタイムとなるので、目標にはだいぶ遠いな、おそらく目標とそれを実現するための施策にだいぶ乖離があるのだろうな、というのが個人的な感覚です。
ダウンタイムについては Twitter などではエンジニアから「致し方ない」「システムは止まるもの」という様な擁護の意見を多く見ましたが、99.999% という目標は誰に言われた訳でもなく東証自身で標榜しているものなので、あくまで客観的に定量的に評価すれば負けだったという事になると考えます。この事は真摯に受け止め、改善していく必要があると思います。だってそれが目標というものですから。目標には置いているけど達成できなかった、うん、残念でした、という事になるのであれば何のために定量的な目標を置いているのか分かりません。ちなみに私もエンジニアの端くれなので、システムを止める事なく運用するのがどれほど難しいのかは理解しているつもりですし、擁護したくなる気持ちもあるのですが、目標として置いた以上それを達成する様にシステムを組むのもエンジニアなのではないでしょうか。
2005年11月の障害
2005年の障害については、報告書を読みましたが意味不明な記述が多く、正直何が起きていたのか全く分かりませんでした。おそらくですが、この報告書を書いたのはそもそもエンジニアではない、もしくはエンジニアが書いたが過度に抽象的な表現を強要され地に足のつかない内容になっている、のどちらかなのではないかと思いました。報告書の解読が非常に困難なのでよく分かりませんが、本番にデプロイする手順が複雑でかつ確認ミスもあり、デプロイが中途半端な状態で行われていたのではないかと思います。また、実際に開発するのは Fujitsu なのに正式デプロイするのは TCS（東証コンピュータシステム）という歪んだ管理構造があった様に見えます。規模によってはそういう事もあるのかもしれませんが、私の感覚では開発したエンジニアでないと適切にデプロイするのは難しいと感じますし、図体が大きすぎて無駄や情報の劣化が多いという様な印象です（正直に書いてしまいましたが角が立つ表現ですみません）。
ただ、責任の所在については2005年の時点から既に開発ベンダーに責任を押し付けるのではなく障害管理体制含めて市場機能を安定的に提供する責任が東証にはあるという認識の様で、現 CEO の発言もこの頃からの文化を継承しているものと思います。
2012年2月の障害
2010年に Arrowhead は運用開始していますので、この障害は既にその体制下で起きたものです。2012年の障害では、保守ベンダー（具体的にどの会社なのかは不明）がハードウェアの障害が起きているにも関わらず運用には問題ないと判断した（おそらく切り替えが自動で行われると判断したのではないかと考えます）ものを東証側が鵜呑みにしてしまいそのまま市場を開こうとしたところ、一部の相場情報が配信できない事が判明したという事の様です。
東証としてはハードウェアに障害があったとしても切り替えができるように要求していたはずだと思いますし、当然そのテストもしていたと思いますし、切り替えが行われるはずだから安全、というのはやや致し方ない判断な様にも思えます。
本システム障害の原因は、サーバーを三重化することによって高い信頼性を確保すること、
障害診断ツールを整備して確実に障害を検知する仕組みを構築すること等、システム稼働前
後の取組みから、システムの信頼性を過信していたため、我が国の証券市場の中心を担う重
要な本システムにハード障害が発生し、業務影響が出る可能性があるにも関わらず、当取引
所職員が主体的にシステムの状態を確認せず、問題なしと判断したことにありました。
とあるのでおそらくそういう事なのだろうなと思いますが、あえて言うなら切り替えが行われた事を早期に確認し、そのサーバーを経由する動作を dry-run する的な事はできたのかもしれないな、とは思います。
再発防止策の一環として障害対応の強化を行っており、「業務影響があると確定した段階で経営陣に報告」だったところ、「業務影響がある可能性がある場合には経営陣に報告」という基準に変更した様です。このあたりの変更もあって、今回の障害では早期に経営陣に情報が共有され、鈴木 CIO も情報収集を早めに開始できた、という事だと思います。ハードウェアもソフトウェアも障害の通知がバンバンくるみたいな状況になるのかもしれませんが、まぁでもトップですからね。しょうがないですね（諦め）。
なお、この期間の CIO は鈴木氏です。
2018年10月の障害
2018年の障害は Arrowhead の v2（2015年リリース版）で起こったものと思います。報告書を見るとメリルリンチ証券側のサーバーが IP アドレスを重複して設定してしまい、それによって再接続の処理が無限ループしてしまったという事の様に思います。これを見てぱっと思いつくのは3点です。
- 接続をする側が Exponential Backoff を行うべきだった
- 接続をされる側が異常な回数の接続要求は弾く様にすべきだった
- その上でロードバランスを行うべきだった
なんとなく API 設計としては基本的な事の様に見えますが、東証・Fujitsu 側としては「まさか身内がそんなスパムみたいな事をするとは…」という事なのだと思います。3 についてはしなかった理由が何かあったのかもしれませんが、分かりませんでした。もしかしたら私が分かっていない初歩的な何かがあるのかもしれませんので、どなたかお分かりでしたらツッコミをお願いします。
個人的な提案
個人的な提案として、以下3つを行いたいです。
- 報告書はエンジニアに書かせ、過度に抽象化した報告書をやめる事を提案します
- プロジェクトマネジメントとして、異常系の対応の優先順位の見直しを提案します
- カオスエンジニアリング（的テスト）の導入を提案します
以下個別に書きます。
報告書のスタイル
2005年の報告書が特にひどく、2018年のものを見ると比較的改善はされているのですが、報告書の内容は「エンジニアが読んで理解できるもの」にすべきだと考えます。おそらく、簡易的に書くには理由があって「お偉いさんはあんまりよく分かっていないから分かる様に書かなければいけない」という様な忖度があるのだと思いますが、分からない人を分かった気持ちにさせるために情報が劣化していて公開したところで何の役にも立たないものになっています。
東証はもはや公共インフラと言える様なシステムですし日本でも有数のシステムな訳ですから、その障害のチャレンジや失敗は他の業界のエンジニアも参考にしやすい形で公開して頂き、日本のエンジニアリング力の底上げに貢献して頂きたいものだと思います。それでお偉いさんが理解できないと言うのであれば内部で通訳を付けてあげて下さい。というか CIO はそれくらいできるべきです。金融庁の人が分からないと言うのであれば金融庁の内部でも通訳ができるくらいのちゃんとしたエンジニアをちゃんと1500万円くらいお金を払って雇って下さい。GASU とか言うんであれば。お願いしますね。
優先順位の見直し
これまでの JPX の資料を見る限り、異常系の優先順位が低い様に見えます。例えば、2010年度版で言えば流動性の確保のための処理の高速化に重点が置かれている様です。2015年版で言えば安全性の向上という事でいくつかの機能が追加されていますがどちらかと言うと想定の範囲内のミスに対応するための施策が多く、「まさかそんなことが起きるとは」という様な障害の対応になる様なものではない様に見えます。2018年のアップデートに至っては異常系の施策はない様に見えます。一日3兆円とも言われる取引高を支えるシステムを「止めないこと」に本気で取り組むのであれば、他を捨ててでも異常系の対応を厚めにやるという戦略的な意思決定が必要ではないかと思います。
いや「まさかそんなことが起きるとは」って言うけど、それが分からないから困るんじゃないか、という反論も聞こえてきそうです。次項で、それに触れたいと思います。
カオスエンジニアリング（的テスト）
上記踏まえて、カオスエンジニアリング的テストの導入を提案します。具体的な手順は以下の通りです。
- 次期 Arrowhead の本番相当の環境を構築する
- 2018年に導入済みのはずの「超高速テスト発注ツール」で運用状態を再現する
- その状態で、エンジニアにハードウェア、ソフトウェア、両面からあらゆる手段でシステムを「壊して」もらう
- システムが停止しない事を確認する
本来はカオスエンジニアリングは本番環境でやるものだという認識はありますが、さすがに東証のシステムでそれをやるのはインパクトからして難しいとは思うので、テスト発注ツールなどを利用してできる限り本番に近い状況にするくらいがせいぜいではないでしょうか。
ハードウェアに関しては実際に物理的に壊すとよいでしょう。さすがに意味のあるユニット単位で壊し方にも色々やり方はありそうですが、その辺は枝葉の話として省略します。やりたいのは、事前に想定したテストでは無理があるので色々な通常考えられない様な手段で実際に壊してみるという事です（もしくは電磁的に誤動作を誘発する）。ハードウェアも高いのでしょうが、300億円とも言われる予算の中では誤差みたいなものでしょう。
そんなことはメーカーが既にやっているのだから無駄という声も聞こえそうですが、そうだったとしても結果として防げなかったのですから、アプローチを変えてみる必要があるのではないでしょうか。私は結構バグが出てくる気がしますけどね。
終わり
以上です。鈴木氏を称賛する様な内容になってしまいましたが、人を育てる事に熱心な鈴木氏からすれば横山氏という CIO が育ってくれて、誇らしい事なのかもしれませんね。
Arrowhead がだいたい5年ごとにアップデートされているのを見ると今まさに開発中なのではないかと思います。上記の様な事を検討されてみてはいかがでしょうか。セキュリティおじさんたちに叩かれそうな記事ですが（笑）、それはそれで参考になりそうなので何かあればご指摘下さい。よろしくお願い致します。
Discussion