メモ : 自治体専用IaaSサービス「Jip-Base」障害

メモ

50自治体システム障害はIaaSで使うソフトのバグが原因、復旧メド立たず | 日経 xTECH(クロステック)

ストレージ装置のファームウエアにバグがあり、ディスクの読み書きができなくなったためだった。

自治体専用IaaSシステム「Jip-Base」の障害について | ニュースリリース | 日本電子計算

明確には書かれていないけど、SSDの障害なんだろうな。(追記)関係無いとのコメントが出てきた。

ストレージそのものに障害が発生しても予備システムに切り替えるなどの対策が用意されているとは思うけれど、予備側も同じストレージを用意しているだろうしどうしようもないって事かもしれない。

復旧させるには同一スペックに近い他のストレージを用意するだけでなく、データセンター内の場所や電源やネットワークの用意とデータ移行の方法など問題山積みな気がする。リストアするにしてもスペックの異なる機器に対しては検証を行なっていないだろうし、関係者は大変なことになっているだろう。


自治体専用IaaSサービス「Jip-Base」の障害について(続報) | ニュースリリース | 日本電子計算

IaaSサービス「Jip-Base」の12月9日(月)全面復旧を目指して作業を進めております。

Jip-Baseが9日に復旧したとしても、その上の業務はその後の対応になるだろうから、もうしばらくかかりそうだ。リストア計画がうまく稼働すれば良いのだが。


「HPEのファームバグは無関係」、50自治体システム障害でコメント | 日経 xTECH(クロステック)

日本電子計算の障害とHPEのSSDファームウェアとの関係は無いとのこと。

偶然とはいえストレージのファームウェアの問題が2件発生したことになり、各メーカのサプライヤへの管理が今後厳しくなりそう。


自治体専用IaaSサービス「Jip-Base」障害についてのお詫び(2019年12月9日時点) | ニュースリリース | 日本電子計算

ハードウェアの故障は修復したものの、その後の動作確認において各種データへのアクセス処理が正しく動作しない事象が判明

この表現では詳しいところを窺い知ることができない(わざとだな)が、ファームウェアが正しく動作しないと捉えるのが自然かな。もしかしたらファームウェアを更新すればデータの復旧までできると思い込んでいた可能性もあるけど。

次に発表するときには本当に完全復旧しないと面目丸潰れになってしまうので、慎重な対応を取らざるを得ないよねって事でもうしばらくかかりそう。


復旧中の50自治体システム障害、ストレージメーカーがコメント | 日経 xTECH(クロステック)

ストレージはEMCとのこと。

ファームウエアの修正は完了したが、いまだに読み書きできないデータがあるのも事実

直したけど動かないって事かな。一旦メーカー側のインシデント管理で直したって結論が出ちゃうと継続調査が難しくなったりしないんだろうか。


「Jip-Base」の障害における復旧状況のご報告 | ニュースリリース | 日本電子計算

報告がリリースされたけれども、内容としては「進捗があったかもしれないし、今後は絶望の可能性もあるから覚悟しておけ」って感じられるのは私だけかな?

単純に考えて障害の対応報告は以下の点が必要なんじゃ無いかと思う。

  • なぜこのタイミングで障害が発生したのか。
  • 同様の障害に対して対策はあるのか。

でもこれらは中の人の話なので対外的には以下が必要なんじゃなかろうか。

  • 障害は復旧したのか。
  • サービスはいつ復旧予定なのか。
  • 障害の影響を最小限にするために何を行なっているのか。

発表になったリリースではこれらのシステムについての前提知識が少ない人に向けて設備の種類やそれぞれの仕組みについてなんとか解説しようと頑張っている感があります。マスコミのニュースでも『ストレージと呼ばれる装置……』なんてところから言わなきゃいけないぐらいだし。

なのでこのリリースで全部を説明しようとするのは無理だし、説明しようとすれば資料が多くなりすぎて大変だ。おそらく資料を作成しているのは現場で悪戦苦闘している人なので資料なんて作っている場合じゃ無いってのが本当のところだと思う。一方でリリースしなきゃいけない人は追加質問が来ない程度には丁寧な資料が必要とされているわけで、諸々頑張った結果がこのリリースされた資料だと思う。もちろん公開される資料だからノウハウとして秘密とされている部分や、業務品質上バレてしまっては困る部分にはあえて触れないという選択肢を取らざるを得ないわけだ。

で、システムの概要から今後の見通しまでザックリと含んだこの資料だけど、細かいところは省いたとしても気になるところがいくつかある。

  • 複数の自治体で物理資源を共有していたのか。
  • ストレージの不具合は以前からわかっていた事ではないのか。
  • バックアップが見つからないというのは何を意味しているのか。

いくら仮想サービスとはいっても自治体というある程度は機密性が求められる設備であるので、物理的なアクセスを制限するのは普通に考えられる仕組みだと思う。もちろん、個別の自治体ではなくJip-Base全体で管理される事で予算が抑えられる選択もあるだろうから、このシステム全体の成り立ちから知らないと口を出せないところなのかもしれない。

おそらく一般的には最も忘れ去られやすいものの、現場の面々が恐々としているのはストレージのファームウェアの問題に気づけなかったのはなぜなのかという点。12月4日の11時ごろに障害が発生してから翌日の5時に問題が突き止められ、おそらく同時に対策のファームウェアも提供されているというのは早すぎると感じる。おそらく既に問題への対策ファームウェアはリリースされていたものの、システムの停止が必要になるなどの条件から対策版ファームウェアの適用が先送りになっていたのではないだろうか。もしくは全く気にしていなかったのかもしれない。なぜなら、対策版のファームウェアがあったのであれば、障害の発生条件なども判明していたはずで、それに合わせて障害が発生しないように回避策が講じられていて然るべきだからだ。

さて、謎が謎を呼んでいるのがバックアップの在り方。いうまでもなくバックアップは障害が発生したときにリカバリすることを目的にしているので、本来であれば見つからないということはあり得ない。今回発生したのは自治体のシステムであるのでバックアップをとっていないなんてことはあり得ない。
バックアップは毎日もしくは毎週といった単位で採取されていると考えるのが自然で、さらに保管期間を定めていることは間違いない。
ではなぜバックアップが見つからないのか。もしかしたら同様のストレージ上にバックアップを取っていたのではないか。いうまでもなくこれでは障害に備えるというバックアップの意味がない。とは言いつつも、実際のところではバックアップを元々の仮想イメージファイルが壊れた時に備えれば良いという程度の考えで適度に空いているストレージに保存してしまいがちだ。というのも、バックアップを行う時間はできるだけ短時間で済ませたいし、保存する場所をわざわざ確保するのは面倒でコストもかかるから。

余談になるけれどもバックアップを行っている時はシステムになんらかの制限がかかることはあり得る話なので、できるだけ短時間で終わらせたいとの希望がある。バックアップ以外にも多くのメンテナンスが予定されているので時間の取り合いになるわけだ。ここで業務に使用されている高価で高速のストレージをバックアップ先に使用すれば時間の短縮ができるってことは想像に難くない。しかしこれではストレージの故障に耐えられないので、業務用とは異なるストレージにバックアップを行えば良い。幸にも複数のストレージが動いているようなので、例えば業務Aのバックアップを業務Bのストレージに行って、業務Bのバックアップを業務Aのストレージに行うといった具合。ただ、これでは高価なストレージをバックアップの保存に使うことになってコストパフォーマンスが悪化すると思われるかもしれないが、わざわざバックアップ用に低コストのバックアップ用ストレージなんて用意しないのが実情だ。業務用ストレージは予算をかけられるので十分余裕があり、「バックアップなんて空いてる所に入れとけば?」っていう理論な訳だ。リムーバブルな媒体への記録なんて運用にかかる費用が大きくてやってられない。

で、複数の業務用ストレージに障害が発生するとバックアップを含めて壊滅的な被害が発生するという具合。

とにかく、早く復旧することを願うばかりだ。


「Jip-Base」の障害における復旧状況のご報告(第2報) | ニュースリリース | 日本電子計算

復旧困難な物が残り4%に減少。そもそもパーセントで表せるのかも疑問なんだけれど、発表するにはそれなりに数値化しておかないと理解しにくいから仕方ないのかな。

お客様保有の業務データによって復旧できたもの

これはバックアップとかログとかが残っていたってことかな。

ログが残っていて更新作業を行ったというのならなかなかに大変な作業だったことだろう。

バックアップが残っていたというのであれば、どういう意図でバックアップを取っていたのだろう?業務外でバックアップをしていたのなら問題だし、業務としていたのなら意味がないと思われていたことをしたわけだし。

新たなご利用環境を構築することで復旧できたもの

リストアできなかった原因は不明だけれど、新環境を立て直したらリストアできたってことかな?リストアできない環境ってのが困った物で再発の可能性は低いとはいえ復旧策の見直しが必要じゃないか。

なんにしても年末年始返上が決まりな事案になっちゃったな。

2020/1/16 追記

「Jip-Base」の障害における復旧状況のご報告(第3報) | ニュースリリース | 日本電子計算

新たに発見できたバックアップデータ

しれっと書いているけどバックアップが適切に管理できていなかったってことかな? それとも、システムのバックアップはなかったけれども、いくつかの作業履歴的な物をバックアップデータと呼んで復旧させているって事だろうか。

残りに0.5%はほぼ絶望的ってことかも。こういう行政サービスってどこまで記録を復元できるものなんだろう。

コメント

タイトルとURLをコピーしました