2017年09月09日
障 害 発 生 の お 知 ら せ
さくらインターネット株式会社
平素よりさくらインターネットをご利用いただき、誠にありがとうございます。
9月9日より、ご提供サービスにおきまして、以下の通り障害が発生いたしました
が、収束いたしました。
ご利用中のお客様には大変ご迷惑をおかけいたしましたことを深くお詫び申し上
げます。
障害が収束いたしましたので、本障害について報告書として下記にご説明いたし
ます。
＜ 記 ＞
発生日時 : 2017年9月9日10時27分
影響範囲 : さくらのクラウド（オブジェクトストレージ）
障害内容 : バケットに接続しにくくなる障害が発生いたしました
---------------------------------------------------------------------
2017年10月11日
さくらのクラウドサービスにおける
オブジェクトストレージ障害に関する御報告
御利用いただいておりますさくらのクラウドサービスにおけるオブジェクトストレージ
障害につきまして、多大な御迷惑をおかけしましたこと、深くおわび申し上げます。
本件に関しまして、下記の通り御報告させていただきます。
－ 記 －
1.内容
さくらのクラウドサービスにおけるオブジェクトストレージにおいて、機器故障への
対応中に内部負荷が増大し、外部からの接続が困難となる事象が発生いたしました。
2.発生日時
2017年9月9日（土）10時27分頃
3.対象
対象サービス ：さくらのクラウドサービス オブジェクトストレージ
対象バケット ：全て
4.現在の状況
外部からの接続が困難となる事象は収束いたしましたが、環境の安定稼働を担保する
ため、以下の制限を継続させていただいております。
・新規バケットの作成
5.原因
ストレージノード（以下、ノード）が追加された状態において、適切ではない設定が
有効であったために膨大なシステムエラーが発生しました。その結果エラーログがあ
ふれ、システム運用に必要な常駐プログラム（以下、デーモン）が停止したことが、
本障害の原因です。
以下、前提となる情報に続き、障害発生の流れを御説明いたします。
■前提
(1)「オブジェクトストレージのシステム構成」について
オブジェクトストレージは、主にフロントサーバー、コントローラー、ノード
にて構成されます。フロントサーバーにて受け取ったデータはコントローラー
にて分割され、複数のノードにオブジェクトとして格納されます。
このオブジェクトには、データを復元する際に各オブジェクトをひも付ける
ために必要なメタデータ情報も付加されています。（図.1参照）
図.1 オブジェクトストレージの仕組みのイメージ
(2)「機器故障への対応における作業工程」について
オブジェクトストレージのシステムを運用するに当たり、構成機器のノードや
ノードに搭載のディスクにおいて故障が発生した際は、以下の工程にて対象の
機器を交換する作業を実施しております。（図.2参照）
①交換対象機器の切離しに備えて、一時的にシステムのストレージ容量を拡大
させておく必要があるため、ノード単位での機器増設を実施
②工程「①」が完了後、交換対象の機器に関してシステムからの切離しを実施
③工程「②」が完了後、システム内部の自動処理にてデータの再配置を実施
④工程「③」が完了次第、一連の機器故障への対応作業が終了
図.2 機器故障への対応における作業工程
(3)「既存ラックの収容状況とデータ分散に関する設定状況」について
既存のラックAとラックBについては、ノード20台ずつ合計40台を収容しており
ました。また、この40台は同一のデータ分散先のグループ（以下、グループ）
として設定しておりました。なお、オブジェクトストレージ全体の空き領域が
減少してきており、ノードの追加を行う必要がございました。既存ラックが埋
まっていることから、新規ラックに収容することにいたしました。（図.3参照）
図.3 既存ラックの収容状況とデータ分散の設定状況
(4)「データ分散に関する設定」について
コントローラーにて分割されたデータは、まずグループ単位で分散され、その
後ラック配下の複数のノードへ分散格納されます。分散先として複数のグルー
プがあった場合、分割されたデータは各グループに対して均等になるように分
散されます。
この動作は、ノード単位だけでなく、グループ単位でも分散されるため冗長度
の向上が見込まれます。このグループ単位の分散は、初期設定状態で有効とな
っておりますが、無効にすることも可能であり、その場合はノード分散のみの動作となります。（図.4参照）
図.4 グループ単位の分散について
■障害発生に至る流れ
(1) ラック及びノードの追加作業
当初、20台のノード増設を計画しており、その20台すべてをラックCに収容する
予定でした。
しかしながら、増設するノードが既存とは異なる機種であったため、各ノード
の消費電力やラックの積載重量を考慮し、1ラック18台までの収容とし、残りの
2台はラックDへ収容することといたしました。その後、一部のノードにハード
ウェア上の問題が見つかったため、最終的にラックCに14台、ラックDに2台の搭
載となり（図.5参照）、この作業は8月23日に完了いたしました。
図.5 ノード増設前後のラックの搭載状況
(2) 増設したノードへのデータ分散に関する設定
今回増設したノードのデータ分散に関する設定については、既存と同様に初期
設定状態であるグループ単位の分散が有効となっておりました。また、ラック
CとラックDは、それぞれ既存とは異なるグループに設定しておりました。
図.6 データ分散に関する設定
これら一連の対応により、各グループのリソースは図.7のように不均衡な状態となりました。
図.7 各グループのリソース状況
(3) 障害の発生
ラックとノードの追加が完了した後、過去に故障していたノードの交換作業を
実施いたしました。図.2の工程に沿って、9月7日に故障ノードの切離しを行い、
収容データの再配置処理が実施されました。その際、図.8の「分散グループ③」
にリソース枯渇が発生し、分散失敗のエラーが大量に発生したため、エラーロ
グが大量に出力される事態に至りました。このエラーログがあふれ、システム
運用に必要なデーモンが停止したことで、本障害が発生いたしました。
図.8 障害発生時のリソース状況
6.対応
当障害の発生直後から、サービスの復旧に向けて以下の諸対応を実施いたしました。
(1) 停止していた複数のデーモン（事象に対して直接影響していたデーモン、及び
間接的なエラー発生要因となっていたその他のデーモン）に対して再起動を実
施し、機能の復旧を図りました。
あわせて、エラーログが大量に出力されてシステムのリソースを圧迫している
状態を改善するため、エラーログデータの削除作業を行いました。
（9月9日から継続中）
(2) 予期しないデーモン停止の発生を抑止するため、複数のデーモンの再起動及び
エラーログの削除作業について、自動処理の仕組みを投入しました。
（9月11日から継続中）
(3) システムの高負荷状態を起因とした保存データの消失リスクを低減するために、
一定期間GETリクエストやPUTリクエスト等の受け付けを制限させていただきま
した。（9月20日）
(4) グループ単位の分散を無効にし、システム全体の動作の安定化を図りました。
（9月21日～9月27日頃）
(5) 上述(1)から(4)の処置を実施することにより、システム内部の自動処理である
データの再配置の作業が円滑に実行できる状態としました｡（9月27日）
7.対応の長期化に関して
前項に記載いたしました通り、障害発生直後からシステム状態の更なる悪化の抑止と、
システム機能の復旧に向け対応を続けてまいりました。また、システムの高負荷を起
因とした保存データの消失リスクを低減させるために、一定期間GETリクエストやPUT
リクエスト等の受け付けを制限させていただきました。
しかしながら、以下のそれぞれの対応に時間を要してしまう結果となりました。
(1) 障害原因特定のため、まずシステム稼動を正常な状態に保つことへの対応
(2) システムログ分析により関連要因の排除、原因の特定作業
(3) システム及びオブジェクトの正常性確認、内部負荷の消化
(1) 障害原因特定のため、まずシステム稼動を正常な状態に保つことへの対応に
ついて
9月9日の障害発生直後から散発的に発生した、デーモンが停止状態になったこ
とによるエラーの発生により、原因の分析が困難な状況であったことから、稼
動を正常な状態に保つために過剰に増大したエラーログの削除、デーモン自動
再起動の強化を行い、ログ内容を評価できる状態とすることへの対応を行いま
した。
また、リクエスト処理滞留によるオブジェクトのデータ保全性への影響を避け
るためアクセスの一部制限を行いました。
(2) システムログ分析による関連要因の排除、原因の特定作業について
複数のエラー事象が確認されたため、それぞれの関係性及び要因とシステム設
定が与える影響の分析調査に時間を要しました。
また、特定した原因に対する設定変更の有効性検討及び実施後の効果が適切な
ものかの確認にも、同様に時間を要しました。
(3) システム及びオブジェクトの正常性確認、内部負荷の消化について
障害により既存オブジェクトのデータが正常な状態にあることの確認及び設定
変更による内部負荷とシステム安定性の状況確認を十分に行うため、アクセス
を制限した状態で評価及び内部負荷の消化を進め、万全を期すため段階的なサー
ビス再開を進めることとなり時間を要しました。
9月9日の障害発生以降、以上のような対応経緯の中で当報告書の提示が大変遅くなり
ましたことを、重ねて深くおわび申し上げます。
8.対策
本障害の再発を防止するために、以下の対策を実施いたします。
・今後のノード追加計画について、その時どきのシステム状態に応じて適切な方法を
採るために、事前に複数の手法案を作成し、その手法案は定期的に見直しを実施い
たします。
・ノード追加作業時の状況変化に応じて、速やかな対応を可能とするための手順の見
直しと手順書のレビューの徹底実施、並びに作業実施体制の見直しと拡充を行いま
す。
・システムの安定稼働や性能の変化に影響を与える作業の実施に際しては、事前に予
測される効果の精査を十分に行い、作業実施後の環境状態の変化について細やかに
監視できるよう体制を強化します。
9.改善策
システム安定性を強化するために、以下の改善策を実施いたします。
・システム内部の負荷状況及びシステム稼働状況の迅速な把握のために、システムを
構成するハードウェア/ソフトウェアについて、より詳細な項目の情報を収集できる
よう監視項目の拡充を実施します。
・システム内部負荷の偏りの解消と、システム全体の稼働性能の最適化のため、シス
テム環境の各種設定の再調整を実施します。
・システムの性能低下を予防する対応の迅速化のため、システム運用における監視の
強化とシステム内部で発生した事象への対応作業の自動化を進めます。
このたびは多大な御迷惑をおかけいたしましたこと、重ねて深くおわびいたします。
以上
別添：時系列経緯
