パスワードを忘れた? アカウント作成
13650260 story
インターネット

ファーストサーバの「Zenlogic」ホスティングサービスの障害、原因や対応などが公開される 26

ストーリー by hylom
どんな設定をやってしまったんだ 部門より

6月19日から7月10日までの長期に渡って障害が発生していたファーストサーバのホスティングサービス「Zenlogic」だが、同社がこのトラブルに関する報告を同社サポートサイトで公開している。

これによると、障害の発端はストレージシステムにおける「想定を上回る負荷上昇による一時的な高負荷状態」で、この問題への対策のために行ったネットワークトラフィック制限設定の一部が不適切なものになっていたことや、ストレージシステムの増強および設定変更に伴って大量のデータ移行が発生したことが原因でストレージシステムの高負荷状態が長期に渡って続いていたという。

なお、ファーストサーバはヤフーのインフラを使用しており、障害対応やメンテナンスなどの作業はすべてヤフー側で実施されたという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ボトルネックを解消しようとした対処のせいで、さらにネックを詰まらせてしまった感じ?

  • by Anonymous Coward on 2018年07月18日 19時27分 (#3445026)

    不適切な帯域制限をかけてるのに気づかないまま(ネットワーク)ストレージシステムの更新作業をしちゃったので、半月近く時間がかかっちゃったよ(テヘッ
    って事かな?

    #発防止策を見る限り、「不適切な設定」をしてしまってそれに長時間気づけなかった事が今回の障害の主要因なのかな・・・

    • by Anonymous Coward on 2018年07月18日 20時05分 (#3445043)

      ストレージサーバ間の帯域制限のかけ忘れかな?よくわからない。

      ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 - Publickey
      https://www.publickey1.jp/blog/18/zenlogic_1.html [publickey1.jp]

      親コメント
    • by Anonymous Coward

      不適切な帯域制限はストレージシステムの入れ替え作業後に、設定変更実施だから違うような。
      そもそも適切なキャパシティプランに変更していれば発端である事象Aが起こらなかったんじゃないかな。
      再発防止策でキャパシティプランの見直しと性能指標の取り方教えてもらってるみたいだし。
      問題起きるまでほったらかし管理手法だったんじゃないかな。

      # しかし、『システム全体への影響を最小限にするために外部ネットワークとの接続を遮断』って、
      # 『毒が全身に回らないようにトドメ刺しといた。何とか瀕死ですんだぜ』みたいな感じかな。

      • by Anonymous Coward

        > 問題起きるまでほったらかし管理手法だったんじゃないかな。
        一番の問題はそこだよね。
        この報告が出るまで、公表されている再発防止は「システムが落ちたらまた付け焼き刃でシステム増設する」とかいう絶望的な内容だったし…

    • by Anonymous Coward

      ストレージ直結の部分の帯域制限はかけたものの、それよりも手前では
      制限なしに流れるようにしたからドロップが発生して輻輳したとかいう
      オチかもね。

      詳細はわからないが、設定ミスがあったってことを半月も特定できない
      のはちょっとね~。

  • by Anonymous Coward on 2018年07月18日 20時13分 (#3445052)

    設定間違ったのに気づいた時点で中断出来なかったの?

    出来なかったとすれば、もしその期間中にストレージに障害起きてたら致命傷だったんじゃない?
    出来たはずだったとしたら何でやらなかったの?

    • by Anonymous Coward on 2018年07月18日 23時13分 (#3445149)

      中断したらそれこそ致命傷だからでしょ。同期中に停止するとか怖すぎ。
      だから、外部と分断してリミッター外してさっさと同期終了させたんだろ。

      親コメント
    • by Anonymous Coward

      世の中の不具合の半分ぐらいは「知らなかったんです、ごめんなさい」なんだけど
      世間はそれをどうするの?

      • by Anonymous Coward

        その不具合は何百のサイト停止するほど大きな問題の場合はお客さんにどうすんの?

    • by Anonymous Coward

      わかりやすい障害なら直ぐにわかったかもしれないけど
      でも気付きにくいのは、エラーも出ず動いているのなんだよね

      ネットの設定も間違い方によってはわかりにくいこともある
      なんかわからんけど遅いとか、嫌だなぁww

  • by Anonymous Coward on 2018年07月18日 23時06分 (#3445144)

    結局ファストサーバ側に対処能力がなかったから、
    風評被害が及ぶのを防ぐためにヤフー側から対応要員を送り込んできたのかな?

    • by Anonymous Coward

      報告書、ヤフーから報告、ヤフーが追加改修、設定値変更などをヤフー株式会社にて順次実施
      と、ヤフーに原因あるかのような書き方ですが事実はどうなんでしょうかね。
      高負荷になる程度のストレージシステムの規模を決定したのはヤフーなのかファーストサーバなのか
      対応内容のヤフー実施項目は
      ファーストサーバの責任において依頼をうけたヤフーが実施したのか
      ヤフーの責任においてヤフーが実施したのか
      ファーストサーバの責任だけど手に負えない状況を見かねてヤフーが実施したのか

      • by Anonymous Coward

        責任の所在はともかく、インフラを外注することの弊害が際立って現れたケースですね。
        自社の顧客に損害が出ても、対応を待っていることしかできない。

      • by Anonymous Coward

        ファーストサーバーがちゃんと性能指標を監視して、適切なキャパシティプランに
        変更していればそもそも起きなかった。
        だから、再発防止策はそれが行えるようにした。と読める。

        ヤフーは「契約の範囲内で顧客対応しました。ちょっと作業ミスもありました」じゃないかな。
        キャパシティプラン選択の責任はファーストサーバにあると思うし。
        ヤフーの一存で契約プラン変えて請求なんて出来ないからね。

    • by Anonymous Coward

      ファーストサーバは前回の度し難いトラブルや数々のトラブルの
      印象から今回のもファーストサーバの技術力云々をディスるコメが
      多いけど、ヤフーのIaaS使ってたうえでのトラブルだからヤフーの
      責任のほうが大きいような気がするよ。

      Amazon 使っていたほうのサービスは影響しなかったわけだし。

      ただ、ヤフーの想定していた使い方よりファーストサーバの使い方
      (使わせ方)が酷すぎて起きたトラブルだった可能性もあるけど。

      今回どこまでファーストサーバが技術的に関われていたのか不明
      なのだけど、ヤフーのIaaS環境まで入り込んで作業できたとも
      思えないので。

      自分のところがやっているサービスだったら、オペレーションミス
      でユーザーのデータを大量消去してしまうようなお客さんに、内部
      ネットワークまでいじれる権限は渡したくないな。

      • by Anonymous Coward

        IaaSの上にcephのっけてネットワーク詰まらせたんならファーストサーバ側の責任では。
        AWS上の方は多分ストレージは単純にEC2なんでしょ。

  • by Anonymous Coward on 2018年07月19日 13時05分 (#3445438)

    > ストレージシステムの増強および設定変更に伴って大量のデータ移行が発生したことが原因で

    あ~。
    分散ストレージって、確かにこういう種類の実装があるのよ。
    ストレージ増設すると、容量バランスやり直しになって大量の転送が発生し、高負荷が続くタイプ。
    もちろん、そうならないタイプの分散ストレージもあるけど。

    負荷に強いことを理由に分散ストレージを使う場合には、この点にも注意して選択した方がいいですね。

typodupeerror

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

読み込み中...