（元）FinTechエンジニアが読み解く東証障害報告書

by free_world21

Slide 1

Slide 1 text

(元)FinTechエンジニアが読み解く東証障害報告書 2021.02.26(Fri.) 銀座Rails#30 @free_world21

Slide 2

Slide 2 text

■ ⼩林ノエル ■ 職業︓フリーランスソフトウェアエンジニア ■ 2008: フリーランスエンジニアとして独⽴ – 当初はflash/C#/railsあたりの案件を受けていた ■ 2009: ⼤学院修了（情報理⼯学修⼠） ■ 2009: IPA未踏事業に採択される ■ 2016~2020: エメラダ株式会社 ■ 〜現在: フリーランス ■ 得意なこと︓ rails, AWS, nodejs, iOS, Android, pythonとか ■ 趣味︓旅⾏・世界のコワーキングスペースめぐり（ワーケーション的な何か） @free_world21 ANA B777-300 NH11 THE FARM@NY nomad works@NY CARR WORKPLACE@Chicago

Slide 3

Slide 3 text

今回のお話 • 2020/10/01: 東京証券取引所がシステムトラブルにより終⽇売買停⽌ • 同⽇16:30: 記者会⾒ • エンジニア界隈からは「誠実な記者会⾒だった」と話題に • 2020/11/30: 調査委員会による報告書が公開される https://www.jpx.co.jp/corporate/news/news-releases/0020/20201130-03.html

Slide 4

Slide 4 text

東証（東京証券取引所）とは株式会社⽇本取引所グループ @⽇本橋兜町持株会社東証1部上場 8697 株式会社東京証券取引所 @⽇本橋兜町⾮上場株式会社⼤阪取引所 @⼤阪市中央区北浜⾮上場

Slide 5

Slide 5 text

⾦融業は規制産業免許制 ■ 法律等に書かれている要件を満たしても、最終判断は⾏政がする – 銀⾏︓銀⾏法 – 保険会社︓保険業法 – ⾦融商品取引所︓⾦融商品取引法登録制 ■ 法律等にかかれている要件を満たらしたら、⾏政は登録を受け付けなくてはいけない – ⾦融商品取引業（証券会社）︓⾦融商品取引法 – 貸⾦業︓貸⾦業法 – 電⼦決済等代⾏業（家計簿サービスなど）︓銀⾏法 – 仮想通貨交換業者︓資⾦決済法東証が持ってる免許⼩林ノエルがエメラダ(株)で経験した業登録

Slide 6

Slide 6 text

JPXは世界で3番⽬の規模 5.1兆ドル（530兆円） || ⽇本のGDP

Slide 7

Slide 7 text

ArrownetとArrowhead • インターネットとは独⽴した専⽤ネットワーク • 基本はプライマリセンタのみで業務を⾏う • ⼤規模災害等でプライマリが稼働できない時はセカンダリを24時間以内に⽴ち上げる • プライマリ、セカンダリ共に関東圏 • セカンダリの関⻄圏移⾏計画が実施されている • 証券会社等は専⽤線でArrownetに接続

Slide 8

Slide 8 text

Arrowheadシステム構成図（2010年） • 2010年10⽉に東証が発表している資料 • https://www.ipa.go.jp/files/000005223.pdf • すべて富⼠通製 • 2010/1: 初代Arrowhead稼働開始 • 2015/9: 2代⽬Arrowhead稼働開始 • 2019/11: 3代⽬Arrowhead稼働開始

Slide 9

Slide 9 text

時間帯別注⽂・約定件数 • 注⽂受付は8時から • 売買開始は9時から

Slide 10

Slide 10 text

Arrohead spec（初代） • 3代⽬Arrowheadは初代の7倍の処理能⼒ • ＝3億2000万件/⽇ • 注⽂受付応答時間200マイクロ秒

Slide 11

Slide 11 text

「すごすぎてきよくわかんないからジョジョに例えて」

Slide 12

Slide 12 text

閑話休題

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 07:37 (1) IT 開発部において障害の原因及びその影響範囲について調査中であったこと (2) 起動できない端末が⼀部にとどまっており、通常の売買監理業務を⾏うことは可能と考えられたこと (3) 相場情報の配信についても回復策の検討が⾏われていたことから、注⽂受付開始前に売買を停⽌させることまでは必要ではないと判断した。（報告書の原⽂、ほぼまま）

Slide 20

Slide 20 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 08:00 証券会社から注⽂が送られてくる。Arrowheadはこれらの注⽂の受付処理は正常に処理できた。〜08:00 すべての端末で売買監理、運⽤管理画⾯の操作ができなくなる

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 1. 株式部による売買停⽌処理（売買管理画⾯から⾏う操作） 2. システム運⽤部による市場停⽌処理（運⽤管理画⾯から⾏う操作） 3. 通常の売買停⽌ができない場合の緊急⽤売買停⽌処理（IT開発部が操作）上記操作はすべてNASに依存する操作だったため失敗に終わる。

Slide 25

Slide 25 text

Slide 26

Slide 26 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 09:00 証券会社との接続は切ったものの、約定処理などは停⽌できていなかったので08:54までに受け付けていた注⽂にたいして売買処理が実⾏されてしまう。またこの時これらの約定情報が⼀部情報配信ゲートウェイから配信されてしまう

Slide 27

Slide 27 text

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 07:55 富⼠通から「NAS1号機における制御機構のダウンである」という旨の通知を受ける 08:16 NAS1号機に対して強制電源断指⽰ →失敗 08:26 NAS1号機からNAS2号機に制御を遷移させる指⽰→失敗 08:28 1号機と2号機の通信断の状況を作り出すためポートの閉鎖（死活監視） →ポート閉鎖は成功するが制御は移⾏せず 08:42 08:26に⾏った指⽰を条件を変えて実⾏→失敗

Slide 30

Slide 30 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead （たぶん）09:00過ぎくらい物理的なケーブル抜線による対応を⾒据え、機器保守員のサーバ室への⼊室準備を進めることと並⾏して、富⼠通との間で、NAS2号機への強制切替(1号機の状態に関わらず制御を奪い取る)が可能となるコマンドの試⾏を継続的に⾏った。 09:23 富⼠通の製品担当から提供されたコマンドを試⾏したが、こちらも失敗した。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 当⽇再開に向けて (1) Arrowheadを再⽴ち上げして再開（リセット） (2) Arrowheadを再⽴ち上げせずに再開という2つの⽅針を検討 (2)は現実的ではないことがすぐに判明 - 08:37に売買停⽌を発表している - よって09:00移⾏に実施された約定処理をなかったことにする必要がある - 正常な処理として約定処理をなかったことにする⽅法はないよって(1)しか⽅法はない

Slide 34

Slide 34 text

相場情報を利⽤する会社証券会社注⽂売買系ネットワーク運⽤系ネットワーク参加者ゲートウェイトレーディングサーバ情報配信ゲートウェイ売買監視サーバ運⽤管理サーバディスク（1号機⽤）ディスク（2号機⽤）共有ディスク装置(NAS)2号機 cpu memory 制御機構共有ディスク装置(NAS)1号機 cpu memory 制御機構死活監視 2020/10/1に起こったこと Arrowhead 当⽇再開に向けて - Arrowhead⾃体はリセットすれば当⽇の朝のまっさらな状態に戻る - ⼀⽅、証券会社側のシステムでは各注⽂ごとにステータス管理をしているのが⼀般的 - Arrowheadをリセットした場合は証券会社側が再度注⽂を送る必要があった - 証券会社にヒアリングをした結果 - 対応可能︓38%（外資系証券のみ） - わからない︓中堅・準⼤⼿ - 無理︓ネット証券仮に再開しても⼀部の外資系証券しか参加できない市場になってしまう

Slide 35

Slide 35 text

Slide 36

Slide 36 text

なぜNAS1号機から2号機へ切り替えが起こらなかったのか︖

Slide 37

Slide 37 text

ETERNUS NR 1000 seriesに対する東証（と富⼠通）の認識 ■ 標準テイクオーバー⽅式︓⽣存を知らせる電⽂(⽣存通知電⽂)が途絶した場合15秒後に処理の引き継ぎが⾏われる⽅式 ■ 即時テイクオーバー⽅式︓相⼿⽅装置から機能停⽌を知らせる電⽂(パニック通知電⽂)を受信した場合、即時に処理の引継ぎが⾏われる⽅式 ■ パニック通知電⽂受信時のパラメータ(on_panic)設定値によるマニュアルに記載されていた仕様 – True︓即時テイクオーバー有効 – False︓即時テイクオーバー無効 – 標準テイクオーバーはTrue/Falseのいずれかに関わらず有効 ■ しかし実際の仕様は2015年以降以下の通りだった – True︓即時テイクオーバー有効 – False︓即時テイクオーバー無効に加え、⽣存通知電⽂の途絶に先⽴ってパニック通知電⽂を受信した場合には標準テイクオーバーも無効 ■ 東証は初代Arrowhead導⼊時(2010)よりon_panic=Falseで運⽤していた

Slide 38

Slide 38 text

on_panic=Falseで運⽤していた経緯 ■ ETERNUS NR 1000 seriesはアメリカのNetApp社（報告書では『A社』と記載）のOEM 製品。OSはONTAP。 ■ 2010年初代Arrowhead導⼊時のNASはONTAP7 – ONTAP7⾃体の仕様が『標準テイクオーバーはon_panicのTrue/Falseのいずれかに関わらず有効』であり、on_panicの初期設定値はFalseだった – 東証に納品されたマニュアルにもそのように記載されていた。初期設定値の Falseのままでも東証の要件である『30秒以内に切り替わること』が満たされるため初期値のまま東証に納品した。

Slide 39

Slide 39 text

on_panic=Falseで運⽤していた経緯 ■ 2015年 2代⽬Arrowhead導⼊時のNASはONTAP8 – on_panic=False時に『即時テイクオーバー無効に加え、⽣存通知電⽂の途絶に先⽴ってパニック通知電⽂を受信した場合には標準テイクオーバーも無効』という仕様変更が⼊り、初期値もTrueに変更された。 – NetApp社から富⼠通に納品された仕様書には初期設定値がFalseからTrueになった旨だけが記載されていた – NetApp社の真意は「基本的には初期設定値Trueのまま使ってください。Falseは障害テストなどの検証⽬的のためのものです」 – しかし富⼠通製品担当社員は初期値変更の旨だけを知らされていたため、標準テイクオーバーはONTAP7と同様に起きると思っていた。 – テストではon_panic=True時に⽚⽅でパニックを起こし即時テイクオーバーが発⽣する＆on_panic=False時に⽚⽅のNASを遮断し標準テイクオーバーがおきることを確認した

Slide 40

Slide 40 text

■ 2019年 3代⽬初代Arrowhead導⼊時のNASはONTAP9 – NetApp社から富⼠通に納品された仕様書にはon_panic設定値に関する記載の変更がなかった – よって富⼠通製品担当社員のon_panic設定値に関する認識は引き続き ONTAP7のままだった – 東証も引き続きその認識で、引き続きon_panic=Falseのまま納品されそのまま運⽤していた ■ このバグ（︖）は5年間Arrowheadの中に潜んでいた🥶 on_panic=Falseで運⽤していた経緯

Slide 41

Slide 41 text

■ メモリ故障によりNAS1号機から2号機にパニック通知電⽂が送られる ■ on_panic=Falseだったため、即時テイクオーバー、標準テイクオーバー共に実⾏されなかった ■ 0.5秒おきに実⾏されるNAS1号機⇔2号機の死活監視も以降途絶える。しかしこれに先⽴ってパニック通知電⽂を受け取っていたため、標準テイクオーバーも発動しなかった ■ 結果、1号機から2号機への切り替えは実施されず、NASは利⽤不可能となった 2020/10/01 当⽇に起こったこと

Slide 42

Slide 42 text

2020/10/19 富⼠通からの『⼤切なお知らせ』

Slide 43

Slide 43 text

■ NASの運⽤に関して – 基本的には不備のあるマニュアルを作成してしまった富⼠通の責任は重い – 東証と共同で実施した導⼊時のテストにおいて、網羅的なケースを洗い出しそれをテストできなかったのは東証にも⼀定程度責任がある – NAS2号機への⼿動切替に時間を要した（1時間半）のは『引継ぎが正常に⾏われなかった場合の対処コマンドの事前準備が⼗分ではなかった』 ■ 事故当⽇の対応に関して – 8時から注⽂を受け付けたことは、8時前の状況としては妥当な判断である – 『08:30までに復旧しなければ売買停⽌とする』という判断も妥当 ■ しかしこれは事故当⽇の状況下で判断された基準であり元々あったルールではない。売買停⽌に⾄る判断ポイントは今後明確化しておくべき。 ■ ロードバランサ遮断を余儀なくされたのはArrowheadの設計に問題あるのでは – 『緊急停⽌⽤売買処理』は緊急時（システム障害等）に実⾏されることを想定しているのに、緊急時に動かなかったのは問題である調査委員会の⾒解

Slide 44

Slide 44 text

■ 東証の『終⽇売買停⽌』という判断は妥当 – Arrowheadをリセットすると証券会社側が対応できなかったのでしょうがない ■ 通常でない売買停⽌が⾏われたあとの売買再開の⼿続き等をもう少し考慮しておくべきだった調査委員会の⾒解

Slide 45

Slide 45 text

■ NASをはじめ、あらゆる機器の設定値の⾒直し・点検 ■ 切り替え機構を有する機器においてはマニュアルによる切り替え⼿段・⼿順を整備する ■ 継続的・網羅的なテスト及び訓練の実施 ■ 売買停⽌⼿段の拡充（緊急⽤売買停⽌処理は緊急時にちゃんと動くようにしましょう） ■ 注⽂受付停⽌・売買停⽌ルールの整備 ■ 市場再開のルールの整備調査委員会の⾒解︓再発防⽌策

Slide 46

Slide 46 text

■ 調査報告書はとても参考になった（厳正な調査が⾏われたと思う） ■ コンティンジェンシープランの重要性 – 起こりうる障害を予めざっくり想定しておくこと ■ 他社起因︓連携する外部API、クラウドインフラの障害、CI、githubなどなど ■ ⾃社起因︓アプリが落ちた、管理画⾯が開けない、カスタマーサポートの疾⾛などなど – 障害発⽣時の対応を妄想しておくこと ■ 誰が対応にあたるのか、どのような⼿順で対応するのか ■ マニュアル対応を想定しておく ■ Alternativeを⽤意しておくこと – 「AWSが落ちたのでどうしようもできません」が通じなくなってきてる ■ システムを⽌めることを想定しておく – 被害の拡⼤を⽌めるためにシステムを⽌めることも必要 ■ 開発・テストに対する適切なリソース配分 – ベンチャーとかでは開発全振、障害対応は努⼒と根性になりがち我々は何を学ぶべきか