orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

ニフクラのオブジェクトストレージ障害を考える

f:id:orangeitems:20180309154837j:plain

※エンジニア個人の感想です。

 

ニフクラの件

日経BPの記事で知った。ニフクラでオブジェクトストレージ障害が発生していたのか。

tech.nikkeibp.co.jp

富士通クラウドテクノロジーズのクラウドサービス「ニフクラ」で障害が発生。オブジェクトストレージのサービスが利用できなくなった。原因はアプライアンス製品のソフトの不具合。全面復旧に1カ月以上を要した。障害への対応に利用企業から不満の声も挙がった。 

1カ月に渡る対応というのはなかなか大きな話なので深掘りしてみたい。

スポンサーリンク

 

公式発表

まずは公式発表を確認する。

オブジェクトストレージ障害復旧のお知らせ - ニフティクラウド Information

この記事の中に報告書がある。

概要

■影響範囲:ニフクラ オブジェクトストレージ 東日本リージョン(障害お知らせ通知番号:T002396)

■発生事象:以下の事象が発生しておりました

2018 年 1 月 19 日(金)17:40~1 月 28 日(日)16:41
① オブジェクトストレージ API利用不可
② ニフクラ コントロールパネルにあるエクスプローラの利用不可

2018 年 1 月 28 日(日)16:41~2 月 26 日(月)15:30
③ オブジェクトストレージWrite不可

 10日間はオブジェクトストレージに何もできなくなり、そこから1カ月は読み取りしかできない状態だったということだ。※西日本のオブジェクトストレージを代替機としたらしい。

運用設計に組み込んでいたシステムはこの期間かなり対応を迫られただろう。また障害が復旧したからといってすぐに元に戻せたりもしないだろう。

発生原因

ニフクラ オブジェクトストレージで使用しているディスク装置のソフトウェア不具合。 ソフトウェアの不具合によりオブジェクト管理情報のアクセス性能が低下し、プロセスダウンおよびシステム全体の処理能力低下を引き起こしました。

最近は、ハードウェアよりソフトウェアがインテリジェンスになっていって、ハードウェアが壊れていなくてもソフトウェアの不具合でトラブルが起きるというケースは多い。その場合、ソフトウェアを修正しないと同じ条件が起きれば必ず再現してしまう。ハードウェア破損であれば代替部品を交換すればいいがソフトウェアだと修正パッチもしくはアップデートを行わないといけない。

 

オブジェクトストレージについて調査

ニフクラのオブジェクトストレージがどの製品を使っていたかについては、レポートには記載されていないが調べればすぐにわかる。

www.fujitsu.com

インターネット社会の可能性を切り開いてきたニフティ。同社はIoT時代のニーズに応えるべく、2016年6月29日から容量無制限、GB単価5円の「ニフティクラウド オブジェクトストレージ」のサービスを開始しました。サービスの基盤にはOSSの分散ストレージ技術Ceph採用のETERNUS CD10000 S2を導入。

上記の通りFUJITSU Storage ETERNUS CD10000 S2 ハイパースケールストレージである。特にこのページの導入事例の項目は教材となると思う。

先日の楽天カード事例でも思ったが、先進のシステムに入れ替えてから2年間は気を抜けないと思う。というのは、サービスインした直後はキャパシティーに対して余裕があるためだ。だんだん利用率が増えていき、ある閾値を超えた直後に、思っても見ない症状に見舞われる・・。これは私も数度経験した障害パターンだ。今回のオブジェクトストレージも、サービスインから1年半の出来事である。

大事なことが書いてあると思う。

CephがOSSであることも重要なポイントでした。「お客様に提供するサービスに対して自分たちで責任を持つことを大切にしています。システム障害が発生したときブラックボックスではベンダーに任せるしかありませんが、OSSであれば当社で原因を追求することが可能です。またCephのコミュニティは活発に活動しており将来性も期待できます」

実際は報告書の通り、現象発生から修正パッチの作成まで8日かかっている。おそらく関係者(特に富士通)は不眠不休で取り組んだろうと思う。私はOSSであることはかえってリスクであると考えており結局はベンダー保守が非常に大事だと考えている。製造者責任という言葉まで落とし込めばわかりやすいと思う。私はOSSよりベンダークローズドなコードの方が安心だと思っている。

また、ストレージについては、修正パッチ適用からリカバリーまで20日ほどかかっていることからわかる通りいくらソフトウェアが修正されてもすぐに利用可能にならない怖さがある。ストレージとは本当に厄介であるとともに無くてはならぬサービスで、私個人としては二度とオンプレミスのストレージサーバーに関わりたくない。データはこわい。

 

考察

オンプレミスにしろパブリッククラウドにしろ、ストレージと名のつくサービスを安定的に運用するということは、非常に社会的責任が重い仕事だと思う。ペタバイト級のデータ、と簡単には言うが、この情報資産としての価値が日々日々高まっていると言わざるを得ない。

この状況のもと、システム構築において、ストレージサーバーの選択は命を握る選択だと思う。どんなシステムでも捨てるデータはどんどんなくなっている。消すぐらいならオブジェクトストレージに転送し、ビッグデータとして活かすという発想はもはやエンジニアのみならず経営者まで考えるようになった。この器として選択する機器は、私個人の意見としては、OSSではなく、実績・シェアのあるベンダーの既製品を時間をかけて採用していったほうがいいと思っている。ニフクラにしてみれば富士通一択しかなかったとは思うけれども。

今回の件で学ぶこととしては、

・大容量ストレージ周りは復旧までかなりの時間を要すること

・ストレージの選定については、高くついたとしてもかなり慎重に選択したほうがいい

・特定のサービスが壊れても大丈夫なようにバックアップ体制を組むこと

ということになると思う。冒頭の日経BPの記事に、不満に思うというユーザーの声があったが、何とも中のエンジニアのことを思うといたたまれないと思った今回の件だ。