大阪市基幹システム障害の詳報
大阪市基幹システム障害の詳報が日経 xTECHにより報道されています。
大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜むバグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。
一通り目を通しましたので、考察を行っておきたいと思います。
考察
この障害は結局はデータベースバックアップの戻しを行い回復しています。これは運用設計上想定内だったと思います。いくら冗長性を実装したとしても、両方が壊れることは防ぐことができません。今回はそのケースだったために、リストアを行い戻した。しかもバックアップは正常に取られていて、トランザクションログも残っていたことから障害発生の10分前までデータを戻せています。運用設計的にも運用手順的にも素晴らしい仕事だと思います。
一方で、この冗長構成にて可用性を上げるということについては、たくさんの人は誤解をしていると思います。冗長構成とは、同じ機能のものを２つ用意し、１つ停止しても動き続けるというものです。こうやって表現すると、止まらない気がしてきます。しかし、そうではありません。止まるのです。私は冗長構成のものが何度も止まるのを目にしてきました。なぜ止まるのかは、意外とシンプルなのでお話ししておきます。
冗長構成を構築する際は、何らかの「切り替わる仕組み」が必要です。
アクティブ－スタンバイ構成ならば、どちらかが動いていてどちらかは寝ています。動いているほうが止まった場合、寝ている方が動き出します。言うだけなら簡単です。しかし、この切り替わる仕組みはきちんと実装しないといけません。
いや、それは、スタンバイ側がアクティブ側を監視し、アクティブ側が停止したらスタンバイ側が動き出せばいいと思うでしょう。しかしそれは不完全です。アクティブ側が常に全面停止してくれたらまだいいです。しかし現実に壊れるときは、完全停止しないものです。例えばPINGは応答するのにプロセスはハングアップしているだの、ある機能だけが動かないだの、不完全に停止するのです。そのために「何を持って稼働状態とするか」という定義をして、その条件に当てはまった時に切り替えの仕組みを動かします。
しかし、まだ問題があります。切り替えの仕組みが動いたとして、スタンバイがアクティブになるのはまだ簡単です。しかしアクティブな側が本当に停止してくれるかはまた不安定要素があります。正常に止まらないケースです。パソコンやスマホを使っていて、シャットダウンしたいのに操作ができないケースはありませんか？。こういったとき、機械は止まっているかと言えば動き続けている場合があります。その場合に、スタンバイ側が稼働しはじめると、結果として、両方とも稼働状態となってしまい、資源（ハードディスクやネットワーク）を奪い合ってしまうことが起こりえます。
このように、「切り替わる仕組み」とはプログラムであり、しかもその仕組み自体は冗長化されていないのです。シングルパスとも呼びますが、いくら同じものを２つ用意しても、それを結ぶ橋は１つしかないのです。
そのため、良く起こるのです。冗長構成にしているけれども、きちんと切り替わりませんでした、という話です。自動的に切り替わるというのは、かなり高度な技術であるという風に認識しています。しかもあまり普段起こることではないので、いろんな条件に対応できるかも未知数の部分があるのです。
ここまで、アクティブ－アクティブ構成については触れてきませんでした。ORACLE RACはこの構成が組めることが有名で、エンタープライズシステムにおいてはかなりのシェアを持っています。ORACLE RACだから絶対に無停止かというとこれも言い切れません。今回のように、両系が同時に障害になることは可能性としてあります。結局のところ、アクティブ－アクティブな状態のもので、半分が停止したときというのは、これは「切り替えの仕組み」は同様に必要です。状態が変わるわけですからその変わった状態へ遷移が正常に働く必要があります。これもまた高度な話で、何を持って切り離すか。また切り離したあと正しく切り離せるかは、シングルパスです。また今回のように両系が同時に壊れる場合は無力です。
どんな冗長構成であっても、状態遷移に冗長性はないということです。状態遷移が100%動くという保証はできません。ですから、冗長化部分でも壊れるときは壊れるという心構えが必要です。
まとめ
このように、冗長化だから停止しないはず、というのは運用の現場からすると誤解であるという認識です。冗長化したとしても壊れる。壊れたら運用設計と運用手順に基づいてリカバリーする。これは大阪市基幹システム障害においては正しく稼働しており、素晴らしいオペレーションだと感心しています。
もちろん、ORACLE RACの内在バグが今回の「切り替える仕組み」を無力化し両系障害を発生させたのは事実だとは思います。だからといって、常に最新パッチを適用する運用が最適かというと、パッチ適用による障害ということも起こりえます。一概に最新パッチを適用せよ、で防げることもありますが新しいリスクもあります。
少なくとも今回の事例は、
・「冗長化＝必ず動く」ではないこと。
・冗長化していても、両系が壊れたら、停止すること。
・壊れた場合のリカバリー手順を確立し、非常時に実際に対応できること。
この３つを頭に入れておく必要があり、これらが発生した際の今回の対応は100点であったことが言えると思います。
