お世話になります。
こちらのサイトにて、
https://xtech.nikkei.com/atcl/nxt/column/18/01157/092200045/
みずほ銀行の障害の記録が詳細に描かれており、インフラエンジニアにとって大変参考になる情報でしたので、個人用メモに図示してみました。
あくまでエンジニアとして技術的視点からの障害対策のシナリオの勉強用のため、特定の団体・人物に対して精神的苦痛を惹起するような意図は一切ありません。
万一、問題があれば修正いたしますのでご連絡ください。
誤りがありましたらコメントご指摘いただけますと助かります。
概要
みずほ銀行で2021年8月20日、営業店の窓口業務が全面停止するトラブルが発生した。前日の19日午後8時53分ごろに営業店端末と勘定系システムをつなぐサブシステムで、データベース（DB）サーバーがディスク装置の故障をきっかけに停止したためだ。待機系DBサーバーへの切り替えも失敗、副データセンター（DC）に処理を切り替えた。
想像図
トラブル発生
システム障害の発端は8月19日午後7時40分、業務チャネル統合基盤のデータベース（DB）サーバーのディスク装置が1台故障したことだった。
DBサーバーのディスクはミラーリングしてあるので、すぐにミラーディスクに切り替わった。また新しいミラーディスクを作るために、スペアディスクへのデータコピーも始まった。
二次障害発生
しかし午後8時52分、ミラーディスクも故障してしまう。まだスペアディスクへのデータコピーは完了していなかったため、ディスクからデータを読み出せなくなり、DBサーバーが停止した。
みずほ銀行はこのDBサーバーを冗長構成にしていた。稼働系から待機系にトランザクションログを常時転送してDBを二重化する仕組みだ。本来であれば稼働系が停止すると、待機系に自動的に切り替わるはずだった。
しかし今回の障害では、稼働系のディスク故障によって待機系へのログ転送が停止し、待機系のデータの最新性を保証できないとシステムが判断したため、稼働系から待機系への自動切り替えが失敗した。DBサーバーの障害によって業務チャネル統合基盤が全面停止し、営業店端末が使えなくなった。
（注）ここは業務基盤上のVM全体ではなく、DBのフェイルオーバーのことだと思いますが、スペース的な理由でこのような絵になっています。
待機系からの復旧への挑戦
みずほ銀行は勘定系システムを東京・多摩にある正データセンター（DC）で運用し、災害対策用システムを千葉の副DCで運用している。千葉DCにもDBサーバーの稼働系と待機系があり、多摩DCからログを転送してDBを二重化していた。後から分かることだが、千葉DCにある待機系DBサーバーだけは、多摩DCのDBサーバーが停止した後も正常に稼働していた。
しかしみずほ銀行は事前に決めていた手順に従い、多摩DCでDBサーバーの再稼働を目指した。手順ではDBサーバーの自動切り替えに失敗した後は、（1）稼働系と待機系を手動で切り替える、（2）待機系単独でDBサーバーを復旧する、との順番だった。
まず午後10時37分から、待機系を手動で稼働系へ切り替え始めた。しかし待機系のDBサーバーを再起動しても、システムの設定が待機系のまま変わらなかったため、切り替えに失敗した。
午後11時57分からは稼働系DBサーバーの電源を強制的にオフにする作業を始めた。手動切り替えに失敗した理由として、稼働系のOSが正常に終了できていないことが考えられたためだ。しかし8月20日午前1時12分、稼働系の電源を強制的にオフにしたうえで待機系を再起動しても、切り替えはできなかった。
さまざまな試行錯誤
少し前の午前0時29分、富士通が新しい復旧策を提案した。稼働系DBサーバーの物理ディスクを直接抜き差しするとの手法だ。富士通は「他社実績を踏まえれば短時間で着手でき、復旧する可能性がある」と述べていた。そこでみずほ銀行は午前1時50分、当初考えていた（2）の待機系単独での復旧を試す前に、物理ディスクの抜き差しを試すと決定した。
午前2時26分、みずほ銀行は物理ディスクの抜き差しではなく、待機系単独での復旧を目指す方針に切り替えた。物理ディスクの抜き差し後の同期処理に、さらに1時間半を要すると分かったためだ。
午前3時4分、待機系DBサーバーは単独で起動したが、システムは復旧しなかった。APサーバーが異常終了してしまったためだ。午前4時12分、APサーバーが異常終了した理由が「停止している稼働系DBサーバーに接続しようとしているため」だと判明した。そこでAPサーバーの設定変更を試みたが、これにも失敗する。
午前6時45分、富士通から稼働系で物理ディスクを抜き差ししても復旧できなかったとの報告があった。もはや多摩DCで復旧できる望みは完全に絶たれた。そこでみずほ銀行は午前7時10分、ようやく千葉DCへの切り替えを決定し、作業に着手した。
災害対策DCからの復旧へ
午前9時45分、千葉DCで業務チャネル統合基盤が復旧した。これによって営業店端末などが利用できるようになった。午前11時58分、業務チャネル統合基盤で日替わり処理が完了し、システムが全面的に復旧した。
感想
・災害リカバリ用のDCへ基盤全体を移行する手順がなかったにも関わらず、数時間で手順書を作成して、VMクローンふくめ3時間程度で復旧というのは早いと思いました。
・ディスクのAB列がほぼ同時に壊れるというのが不思議ですが、ハードウェアRAIDの障害でしょうか。同じく、稼働系のOS（またはハイパーバイザ）が古いディスクをホールドしてしまっているというのもRAIDやSANといった物理機器の不具合の可能性？
・それをふまえると、今後はオンプレではHCIのような、DAS（筐体内ディスク）をソフトウェア的に定義するストレージ（SDS）が主流になっていくと感じました。
・もちろんクラウドであればこのような低層設計が不要になります。北陸銀行が勘定系ふくめ全てAzureに移行したというニュースがありましたが驚きました。https://ascii.jp/elem/000/001/980/1980111/