気になったニュース
2017年末にあった三菱UFJニコスのシステム障害について、二重引き落としや、コンビニでの納税データが自治体に届かないという被害が広がっているそうです。ITインフラについては知識があるので、推測の範囲も含めてまとめます。
経緯
本件の経緯については、下記の記事が詳しいです。
（影響）
（1）カード会員の利用内容など確認業務に関わるシステムの一時停止
（2）カード発行に関わる業務の遅延
（3）キャッシングサービスの一部利用停止と制限
（4）カード会員への利用代金請求に関わる業務での一部不具合
（5）ポイントサービスにおける不具合
（6）各種送付物の一部遅延（原因）
カード会員や加盟店などとの取引内容を保管しているシステム機器（記憶装置）が故障し、三菱UFJニコスが作成・加工したデータの一部が毀損したこと
ハードディスクは冗長化されていないの？
大事な情報を収めておく領域をストレージと言い、金融機関のシステムなどではストレージサーバーという専用の機器を利用することが多いです。または、サーバー機器の内部のストレージに保管する場合もあります。
どちらにしろ、RAIDという冗長化の技術によって、ハードディスクが故障してもデータが失われないような構成を組むのは必須です。RAIDの説明は専門的になりすぎるので省きます。
冗長化は絶対されていると断言して結構です。
ハードディスクがこわれたときの保守手順は？
データセンターにおいて、ハードディスクが壊れたときの保守手順は、だいたい以下のようなものです。
（１）ハードディスクが壊れたのをサーバー機器が検知すると、そのハードディスクをサーバー機器から自動で切り離します。
（２）サーバーの全面ランプがアラートを知らせます。光り方は機器それぞれで異なりますが、赤かったり黄色かったりして普通じゃないことを知らせてくれます。
（３）保守担当者がサーバーの状態を日々確認するために、機器のチェックを行った時にランプに気がつきます。ただ、この人力監視のやり方だと機器が多すぎると漏れてしまうため、監視センターに自動でアラートを送る仕組みを持っている場合が多いです。とにかく、保守担当者が気が付きます。
（４）保守担当者が、サーバーの保守ベンダーに電話連絡します。保守の契約によっていつディスクを交換してくれるかはいろいろです。交換するディスクを持ったベンダーの作業員がいつ作業するかを調整します。なお、一番手厚い例では、データセンター内にベンダーも常駐しハードディスクも在庫を持ち、すぐに交換してくれます。一番低い保守だと、翌営業日日中帯に、という条件がつきます。
（５）作業員が壊れたディスクを交換します。ディスクを入れるとRAIDの再構成が始まります。これは結構な時間がかかりますが、これが完了するのを待たずに大体は保守の方は撤収します。
こんな形でインフラ技術者、特に保守担当となっている方たちは作業されています。クラウドであってもクラウドの保守側ではこの仕事はあります。したがって、クラウドを使うと、ハードディスクのお守りをしなくてよくなるので、クラウドを使うというメリットは実はものすごくあります。
ではなぜ、今回壊れた？
「ハードディスクが壊れる」という状態を引き起こす原因は、いくつかあります。
（１）電源停止でサーバー機器自体がいきなり停止した時
プレイステーションの電源をいきなり抜くと、次回起動時に「ちゃんとシャットダウンしてよね」と出ますよね。あの状況です。書き込んだとファイルシステムは思っているのに、実際のディスク領域には書き込んでおらず、これが壊れるという状況です。ただ、専用のサーバー機器は、電源が冗長化されていたり（2本コンセントがある）、RAIDカードというディスクの読み書きを行う機器に電池がついたりして、壊れにくいような工夫がいっぱいされています。また電源停止もデータセンターでは滅多に起こりません。
（２）ストレージ機器や、仮想基盤、OSファームウェアのバグ
機械にもファームウェアというソフトウェアが入っています。普通の使い方ならばテスト済で出荷されるので障害など踏まないのですが、昨今、使われ方が多様化しています。ネットワーク越しであったり仮想基盤越しだったり様々です。ある特定用途の際に壊れる、というバグも存在します。
ファームウェアのアップデートを適切に行わないと、いつか踏んでしまいます。ストレージサーバーのお守りが大変な理由がここにあります。
（３）なぜか天文学的な確率でハードディスクが複数台同時に壊れる
RAIDという冗長化の仕組みがあるのをお伝えしましたが、この仕組みがあっても、複数のディスクが同時に壊れた場合は、復旧できない可能性があります。ディスクが壊れる頻度は最近だと「まれ」で、壊れないまま利用を終える場合もあります。なのに、天文学的な数字で、同時ディスク障害がおきます。私もここ２０年で３回ほど体験したことがあります。
何度ベンダーを問いただしても、天文学的な数字で同時に起こりましたという結論になってしまうので、どんなに冗長化を組んでいても、こういうことが起こることは肝に命じた方がよいでしょう。
私の読みとしては、（３）かなあと思います。
バックアップを取ってあったのでは？
障害発生時点までデータベースを戻すというのは、実はなかなかハードルの高い作業です。
もちろんバックアップを１日に１度もしくは数度取る作業は行われていたと思います。また、そのバックアップは、そのストレージ機器ではない別の場所に保管されていたと思います。しかも、最近はデータセンターの外（同時災害を受けない地域）にコピーして逃すような災害対策もしていたと思います。
しかし、バックアップを単にリストアしただけでは、その取得タイミングにデータが戻ってしまいます。したがって、ジャーナル、と呼ばれる、データベースに何をしたかを保管するファイルを使って、リストアしたデータベースを最新の状態に戻します。これをロールフォワードと呼んでいます。
きちんとロールフォワードができれば、データの損失は最低限に抑えられます。しかし、残念ながらロールフォワードに失敗するケースがたまにあるのです。ジャーナルを保管するディスクも一緒に壊れた場合です。ジャーナルまでストレージ機器以外の場所に定期的に保管するのがよい設計ですが、全てのシステムがそうなっているとは限らないと思います。
したがって、さすがにバックアップはあったが、ジャーナルが戻らなくて最新の状態にまで戻せなかった、というのが私の見立てです。
（スーパーはずれかもしれません。推測です）
最新の状態でないので、再度連携バッチとか流すと、二重引き落としとか余裕で起こると推察します。
機械はこわれるもの
ITインフラに携わってきた私からすれば、どんなにどんなに冗長化しようが、機器はこわれます。そこに何重もの予防線を張っても、障害はかいくぐってきます。
そのあたりを目にすると、パブリッククラウドはかなりの投資をしてデータ損失しないように設計しているので、自社で機器を持つのが非常にこわくなりクラウドを使うことの最大の利点と考えています。
クラウド運用事業者側では、機器の交換のためにたくさんのITインフラ技術者が働いていて日夜がんばっていただいているのをありがたく感じながら、利用しています。
それでも、クラウドでも、１００％安全ではないので、バックアップとジャーナルの保管は何重にもしておいた方がよいですね。
バッチの遅延は起きるでしょうね
リカバリーに費やした時間、システムは止まりますので、その結果を待っているシステムの連携が遅延するのは当然かと思います。遅延していけないようなシステムであれば、完全に同じシステムを２重で作って、稼働系がやられたら、待機系に切り替えて使う、またデータベースの複製しておく。そんなシステムにしなければいけないのですが、コストも２倍です。
あと、切り替えの訓練もやらないと、いざ問題が起こった時に使えない、ということもあります。ということで、コストが跳ね上がるという話でした。
なかなか全部のシステムはこうなりませんよね・・・。
ということで、システムに全てを委ねる社会は、こんな裏側があるというお話でした。書いていて胃が痛くなりました。
追記
予想が当たってたので、記事書きました。
三菱UFJニコスのシステム障害原因が判明した件について - orangeitems’s diary
