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

2021/2/26に行われた【オンライン開催】銀座Rails#30@リンクアンドモチベーションで使用した資料です。

https://ginza-rails.connpass.com/event/202036/

2020/10/1に起きた東証のシステム障害により終日取引停止となった件について報告書が11/30に発表されました。証券会社のシステムを0から構築した経験があるエンジニア目線でみた東証の障害と対応について検証してみたいと思います。

Transcript

1. (元)FinTechエンジニアが 読み解く 東証障害報告書 2021.02.26(Fri.) 銀座Rails#30 @free_world21
2. ▪ ⼩林 ノエル ▪ 職業︓フリーランスソフトウェアエンジニア ▪ 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
3. 今回のお話 • 2020/10/01: 東京証券取引所が システムトラブルにより終⽇売買停⽌ • 同⽇16:30: 記者会⾒ • エンジニア界隈からは「誠実な 記者会⾒だった」と話題に • 2020/11/30: 調査委員会による報告書が 公開される https://www.jpx.co.jp/corporate/news/news-releases/0020/20201130-03.html
4. 東証（東京証券取引所）とは 株式会社 ⽇本取引所グループ @⽇本橋兜町 持株会社 東証1部上場 8697 株式会社 東京証券取引所 @⽇本橋兜町 ⾮上場 株式会社 ⼤阪取引所 @⼤阪市中央区北浜 ⾮上場
5. ⾦融業は規制産業 免許制 ▪ 法律等に書かれている要件を満たしても、最終判断は⾏政がする – 銀⾏︓銀⾏法 – 保険会社︓保険業法 – ⾦融商品取引所︓⾦融商品取引法 登録制 ▪ 法律等にかかれている要件を満たらしたら、⾏政は登録を受け付けなくてはいけな い – ⾦融商品取引業（証券会社）︓⾦融商品取引法 – 貸⾦業︓貸⾦業法 – 電⼦決済等代⾏業（家計簿サービスなど）︓銀⾏法 – 仮想通貨交換業者︓資⾦決済法 東証が持ってる免許 ⼩林ノエルがエメラダ(株)で 経験した業登録
6. JPXは世界で3番⽬の規模 5.1兆ドル（530兆円） || ⽇本のGDP
7. ArrownetとArrowhead • インターネットとは独⽴した専⽤ネットワーク • 基本はプライマリセンタのみで業務を⾏う • ⼤規模災害等でプライマリが稼働できない時は セカンダリを24時間以内に⽴ち上げる • プライマリ、セカンダリ共に関東圏 • セカンダリの関⻄圏移⾏計画が実施されている • 証券会社等は専⽤線でArrownetに接続
8. Arrowheadシステム構成図（2010年） • 2010年10⽉に東証が発表している資料 • https://www.ipa.go.jp/files/000005223.pdf • すべて富⼠通製 • 2010/1: 初代Arrowhead稼働開始 • 2015/9: 2代⽬Arrowhead稼働開始 • 2019/11: 3代⽬Arrowhead稼働開始
9. 時間帯別注⽂・約定件数 • 注⽂受付は8時から • 売買開始は9時から
10. Arrohead spec（初代） • 3代⽬Arrowheadは初代の7倍の処理能⼒ • ＝3億2000万件/⽇ • 注⽂受付応答時間200マイクロ秒
11. 「すごすぎてきよくわかんないから ジョジョに例えて」
12. 閑話休題
13. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 2020/10/1に起こったこと Arrowhead 死 活 監 視
14. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと 07:04 NAS1号機の異常を⽰すエラーが発⽣ （実際はmemory故障） 本来は⾃動でNAS2号機に切り替わるは ずが切り替わらなかった。 Arrowhead
15. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと 07:06 ⼀部端末で売買監理画 ⾯、運⽤管理画⾯へログ イン不可となる Arrowhead
16. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと 07:10 富⼠通に連絡。共同で障 害対応や影響範囲の調査 を開始する。 Arrowhead
17. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead ~07:30 本来実施されているべき処理が 実施されていないことが確認 （経路維持電⽂、通信開始電 ⽂、銘柄情報の更新など）
18. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと 07:37 横⼭ JPX CIOを本部⻑とする障 害対策本部を設置。 システム運⽤部⾨から東証社内 に障害に関するメールを送信。 Arrowhead
19. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 07:37 (1) IT 開発部において障害の原因及びその影響範囲について調査中であったこと (2) 起動できない端末が⼀部にとどまっており、通常の売買監理業務を⾏うことは 可能と考えられたこと (3) 相場情報の配信についても回復策の検討が⾏われていたこと から、注⽂受付開始前に売買を停⽌させることまでは必要ではないと判断した。 （報告書の原⽂、ほぼまま）
20. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 08:00 証券会社から注⽂が送られてく る。Arrowheadはこれらの注⽂ の受付処理は正常に処理でき た。 〜08:00 すべての端末で売買監理、運⽤ 管理画⾯の操作ができなくなる
21. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead
22. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 08:00過ぎ 08:30までに相場情報配信システムが復旧しない場合は 09:00からの売買は停⽌する。 ただし、当⽇中の早期の売買再開を⽬指す。
23. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 08:36 08:30までに相場情報配信が回復しな かったので全銘柄の売買停⽌を決定。 08:37 取引参加者（証券会社）に通知。 ただ、この時点では当⽇中の再開を⽬指 している。
24. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 1. 株式部による売買停⽌処理（売買管理画⾯から⾏う操作） 2. システム運⽤部による市場停⽌処理（運⽤管理画⾯から⾏ う操作） 3. 通常の売買停⽌ができない場合の緊急⽤売買停⽌処理（IT開 発部が操作） 上記操作はすべてNASに依存する操作だったため失敗に終わ る。
25. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 08:54 証券会社と Arrowheadのロードバランサとの 接続を強制遮断
26. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 09:00 証券会社との接続は切ったものの、 約定処理などは停⽌できていなかったの で08:54までに受け付けていた注⽂にたい して売買処理が実⾏されてしまう。 またこの時これらの約定情報が⼀部情報 配信ゲートウェイから配信されてしまう
27. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 09:11 相場情報配信側のロードバランサも遮断。 配信された約定情報は無効である旨を相場 情報ユーザに通知
29. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （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に⾏った指⽰を条件を変えて 実⾏→失敗
30. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead （たぶん）09:00過ぎくらい 物理的なケーブル抜線による対応を⾒据え、 機器保守員のサーバ室への⼊室準備を進める ことと並⾏して、富⼠通との間で、NAS2号機 への強制切替(1号機の状態に関わらず制御を 奪い取る)が可能となるコマンドの試⾏を継続 的に⾏った。 09:23 富⼠通の製品担当から提供されたコマ ンドを試⾏したが、こちらも失敗した。
31. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 09:26 09:23に実⾏したコマンドにオプション を付加することによりNAS2号機への切り替え が成功した︕
32. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead （たぶん）09:30ごろ 相場情報配信における各種処理、売買監理お よび運⽤管理画⾯の利⽤が可能となった
33. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （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)しか⽅法はない
34. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 当⽇再開に向けて - Arrowhead⾃体はリセットすれば当⽇の朝の まっさらな状態に戻る - ⼀⽅、証券会社側のシステムでは各注⽂ごとに ステータス管理をしているのが⼀般的 - Arrowheadをリセットした場合は証券会社側が 再度注⽂を送る必要があった - 証券会社にヒアリングをした結果 - 対応可能︓38%（外資系証券のみ） - わからない︓中堅・準⼤⼿ - 無理︓ネット証券 仮に再開しても⼀部の外資系証券しか参加できな い市場になってしまう
35. 相場情報を 利⽤する会社 証券会社 注⽂売買系ネットワーク 運⽤系ネットワーク 参加者 ゲートウェイ トレーディング サーバ 情報配信 ゲートウェイ 売買監視 サーバ 運⽤管理 サーバ ディスク （1号機⽤） ディスク （2号機⽤） 共有ディスク装置(NAS)2号機 cpu memory 制御機構 共有ディスク装置(NAS)1号機 cpu memory 制御機構 死 活 監 視 2020/10/1に起こったこと Arrowhead 当⽇再開に向けて - 11:00~ 清⽥ JPX CEO、東証宮原社⻑なども交え て議論 - 11:45 JPXウェブサイト上に終⽇取引停⽌の旨を 公表
36. なぜNAS1号機から2号機へ切り替えが起こらなかっ たのか︖
37. ETERNUS NR 1000 seriesに対する東証（と富⼠通） の認識 ▪ 標準テイクオーバー⽅式︓⽣存を知らせる電⽂(⽣存通知電⽂)が途絶した場合15秒後 に処理の引き継ぎが⾏われる⽅式 ▪ 即時テイクオーバー⽅式︓相⼿⽅装置から機能停⽌を知らせる電⽂(パニック通知電 ⽂)を受信した場合、即時に処理の引継ぎが⾏われる⽅式 ▪ パニック通知電⽂受信時のパラメータ(on_panic)設定値によるマニュアルに記載され ていた仕様 – True︓即時テイクオーバー有効 – False︓即時テイクオーバー無効 – 標準テイクオーバーはTrue/Falseのいずれかに関わらず有効 ▪ しかし実際の仕様は2015年以降以下の通りだった – True︓即時テイクオーバー有効 – False︓即時テイクオーバー無効に加え、⽣存通知電⽂の途絶に先⽴ってパニッ ク通知電⽂を受信した場合には標準テイクオーバーも無効 ▪ 東証は初代Arrowhead導⼊時(2010)よりon_panic=Falseで運⽤していた
38. 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秒以内に切り替わること』が満たされる ため初期値のまま東証に納品した。
39. 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を遮断し標準テイクオーバーがおきるこ とを確認した
40. ▪ 2019年 3代⽬初代Arrowhead導⼊時のNASはONTAP9 – NetApp社から富⼠通に納品された仕様書にはon_panic設定値に関する記載 の変更がなかった – よって富⼠通製品担当社員のon_panic設定値に関する認識は引き続き ONTAP7のままだった – 東証も引き続きその認識で、引き続きon_panic=Falseのまま納品されその まま運⽤していた ▪ このバグ（︖）は5年間Arrowheadの中に潜んでいた🥶 on_panic=Falseで運⽤していた経緯
41. ▪ メモリ故障によりNAS1号機から2号機にパニック通知電⽂が送られる ▪ on_panic=Falseだったため、即時テイクオーバー、標準テイクオーバー共に実 ⾏されなかった ▪ 0.5秒おきに実⾏されるNAS1号機⇔2号機の死活監視も以降途絶える。しかしこ れに先⽴ってパニック通知電⽂を受け取っていたため、標準テイクオーバーも 発動しなかった ▪ 結果、1号機から2号機への切り替えは実施されず、NASは利⽤不可能となった 2020/10/01 当⽇に起こったこと
42. 2020/10/19 富⼠通からの『⼤切なお知らせ』
43. ▪ NASの運⽤に関して – 基本的には不備のあるマニュアルを作成してしまった富⼠通の責任は重い – 東証と共同で実施した導⼊時のテストにおいて、網羅的なケースを洗い出しそれ をテストできなかったのは東証にも⼀定程度責任がある – NAS2号機への⼿動切替に時間を要した（1時間半）のは『引継ぎが正常に⾏われ なかった場合の対処コマンドの 事前準備が⼗分ではなかった』 ▪ 事故当⽇の対応に関して – 8時から注⽂を受け付けたことは、8時前の状況としては妥当な判断である – 『08:30までに復旧しなければ売買停⽌とする』という判断も妥当 ▪ しかしこれは事故当⽇の状況下で判断された基準であり元々あったルールではない。 売買停⽌に⾄る判断ポイントは今後明確化しておくべき。 ▪ ロードバランサ遮断を余儀なくされたのはArrowheadの設計に問題あるのでは – 『緊急停⽌⽤売買処理』は緊急時（システム障害等）に実⾏されることを想定し ているのに、緊急時に動かなかったのは問題である 調査委員会の⾒解
44. ▪ 東証の『終⽇売買停⽌』という判断は妥当 – Arrowheadをリセットすると証券会社側が対応できなかったのでしょうがない ▪ 通常でない売買停⽌が⾏われたあとの売買再開の⼿続き等をもう少し考慮しておくべ きだった 調査委員会の⾒解
45. ▪ NASをはじめ、あらゆる機器の設定値の⾒直し・点検 ▪ 切り替え機構を有する機器においてはマニュアルによる切り替え⼿段・⼿順を整備す る ▪ 継続的・網羅的なテスト及び訓練の実施 ▪ 売買停⽌⼿段の拡充（緊急⽤売買停⽌処理は緊急時にちゃんと動くようにしましょ う） ▪ 注⽂受付停⽌・売買停⽌ルールの整備 ▪ 市場再開のルールの整備 調査委員会の⾒解︓再発防⽌策
46. ▪ 調査報告書はとても参考になった（厳正な調査が⾏われたと思う） ▪ コンティンジェンシープランの重要性 – 起こりうる障害を予めざっくり想定しておくこと ▪ 他社起因︓連携する外部API、クラウドインフラの障害、CI、githubなどなど ▪ ⾃社起因︓アプリが落ちた、管理画⾯が開けない、カスタマーサポートの疾⾛などなど – 障害発⽣時の対応を妄想しておくこと ▪ 誰が対応にあたるのか、どのような⼿順で対応するのか ▪ マニュアル対応を想定しておく ▪ Alternativeを⽤意しておくこと – 「AWSが落ちたのでどうしようもできません」が通じなくなってきてる ▪ システムを⽌めることを想定しておく – 被害の拡⼤を⽌めるためにシステムを⽌めることも必要 ▪ 開発・テストに対する適切なリソース配分 – ベンチャーとかでは開発全振、障害対応は努⼒と根性になりがち 我々は何を学ぶべきか
48. 終劇 @free_world21 ご清聴ありがとうございました