Jip-Baseの事例に学ぶクラウドサービスの障害対策

2019年12月4日に発生した自治体向けIaaS「Jip-Base」のサービス障害が長期化しています。本記事を投稿した2019年12月14日現在も復旧しておらず、Webサイトや業務システムが停止したままの自治体もあるようです。

今まで公開されている情報を元に、クラウドサービスの大規模障害に対してどのような対策が行えるか考えてみます。

[注意事項]
本記事は、筆者が独自に考察した内容が含まれています。関係各社の公式発表ではないのでご注意ください。

障害内容

原因

「Jip-Base」のサービス提供元である日本電子計算は、本障害をストレージのファームウェア不具合に起因したものと発表しています。 (※1)

想定される障害発生箇所

「Jip-Base」は、VMware製品をベースとしたIaaS基盤のようです。(※2) また、複数台の仮想ホストで、Dell EMC Unity 500を共有ストレージとして使用している模様です。 (※1)

上記の情報から、「Jip-Base」は以下の図のようなシステム構成と障害箇所が考えられます。

[参考資料]

クラウドサービスにおける登場人物

IaaSをはじめとしたクラウドサービスには、以下の3種類の登場人物(組織)が登場します。(各組織の名称は便宜上付けているものなので一般的ではないかもしれません)
機器保守ベンダは約款で定められた保守サービスを提供するので対策しようがありません。サービス事業者とサービス利用者のそれぞれの立場で、実現可能な対策を検討してみます。

  • サービス事業者(本件における、「Jip-Base」を運営する日本電子計算)
  • サービス利用者(本件における、「Jip-Base」を利用する地方公共団体)
  • 機器保守ベンダ(本件における、「Jip-Base」のストレージ装置を保守する企業)

サービス事業者が取るべき対策

サービス事業者と保守ベンダの責任区分の明確化

一般的には、クラウドサービスの基盤で障害が発生した場合、サービス事業者は被疑箇所を切り分けて、機器の保守ベンダに以下の対応を依頼します。

  • 機器の正常性確認
  • 機器異常が認められる場合の復旧依頼

今回の事例では、保守サービスを提供していると思われるEMCジャパンから対応状況のコメントが発表されています。 (※3)
要約すると、以下の内容です。

  • ストレージ装置に故障が発生したことを認める
  • ファームウエアを修正するなどしてストレージの修復作業は完了した
  • 日本電子計算で業務復旧作業中

それに対して、日本電子計算は「いまだに読み書きできないデータがあるのも事実で、復旧に至っていない。」 (※3)とコメントを発表しています。

ここからは憶測ですが、EMCジャパンが定義している保守の責任区分は「ストレージ装置としてデータの読み書きができること」であり、同内容が確認できたEMCジャパンは同社責任区分の修復完了宣言をしているものと思われます。
機器としては正常であるものの、データに論理障害が発生しているためシステムとしては復旧していない状況、という可能性があります。

この様に、保守ベンダの提供サービスには必ず責任区分が存在します。責任区分を超える範囲は、サービス事業者側で障害対策を講ずる必要があります。

ストレージ装置に保管されているデータの完全性が保守ベンダの責任区分外である場合は、別筐体へのデータレプリケーションや、ファイルの定期バックアップを行い、障害発生時は迅速にサービス復旧できるよう運用フローを整備しておく必要があります。

[参考資料]

サービス事業者とサービス利用者の責任区分の明確化

前述の一方で、サービス事業者とサービス利用者の責任区分も明確にしておく必要があります。
サービス基盤障害時のデータ完全性はサービス事業者が保証するが、仮想マシンのOSより上位の障害やサービス利用者の誤操作によるデータ消失は対応しない、といった規定を事前に用意しておくことで、両者で備えておくべき対応が明確になります。

クラウドサービス大手のAWA(Amazon Web Service)は、この辺りの規約を明確に定めているので参考になります。 (※4)

[参考資料]

サービス利用者が取るべき対策

SLAを過信しない

GoogleやAmazonのような大企業のクラウドサービスであっても、過去何度も大規模障害が発生しています。いくらSLAを定めていても、必ず予期せぬ障害は発生するものです。
SLAは、「定められたサービス停止時間を超過した場合に課金額を返金する規程」くらいの認識に留めておくべきです。

[参考:SLA規定値ごとの月間サービス停止時間]

  • 99.9% : 月間43.8分以上停止しないことを保証
  • 99.99% : 月間4.38分以上停止しないことを保証
  • 99.999% : 月間26.28秒以上停止しないことを保証

サービス停止時のDR対策

万が一SLAを大幅に超過するサービス停止が発生した場合にどの様な対応を行うか、サービス利用者側でDR対策を講ずる必要があります。
ここで気を付けるべきは、DRに掛けるコストとシステムの重要度のバランスを取ることです。SLA超過で返金さえされればよいということであれば、敢えて復旧まで待つのもありです。反対に、絶対に停止できないシステムであれば、そもそも1つのクラウドサービスに依存しないマルチクラウド環境を構築する必要があります。
対策としては、以下のような選択肢が考えられます。

  • サービス停止を許容して復旧するまで待つ
  • サービスにDRオプション機能がある場合は、それを利用する
  • 別サービスを併用してマルチクラウド環境を用意しておく

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です