ファーストサーバの「Zenlogic」ホスティングサービスの障害、原因や対応などが公開される 26
ストーリー by hylom
どんな設定をやってしまったんだ 部門より
どんな設定をやってしまったんだ 部門より
6月19日から7月10日までの長期に渡って障害が発生していたファーストサーバのホスティングサービス「Zenlogic」だが、同社がこのトラブルに関する報告を同社サポートサイトで公開している。
これによると、障害の発端はストレージシステムにおける「想定を上回る負荷上昇による一時的な高負荷状態」で、この問題への対策のために行ったネットワークトラフィック制限設定の一部が不適切なものになっていたことや、ストレージシステムの増強および設定変更に伴って大量のデータ移行が発生したことが原因でストレージシステムの高負荷状態が長期に渡って続いていたという。
なお、ファーストサーバはヤフーのインフラを使用しており、障害対応やメンテナンスなどの作業はすべてヤフー側で実施されたという。
ボトルネックを解消しようとして (スコア:1)
ボトルネックを解消しようとした対処のせいで、さらにネックを詰まらせてしまった感じ？
Re:ボトルネックを解消しようとして (スコア:1)
直そうとして壊した？
よくある、
サポート；”壊れる前に何かしました？”
ユーザー；”何もしてません。”
素人修理の失敗に玄人でも手こずるレベルに悪化したとか。
なるほどわからん (スコア:0)
不適切な帯域制限をかけてるのに気づかないまま（ネットワーク）ストレージシステムの更新作業をしちゃったので、半月近く時間がかかっちゃったよ(ﾃﾍｯ
って事かな？
＃発防止策を見る限り、「不適切な設定」をしてしまってそれに長時間気づけなかった事が今回の障害の主要因なのかな･･･
Re:なるほどわからん (スコア:1)
ストレージサーバ間の帯域制限のかけ忘れかな？よくわからない。
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
https://www.publickey1.jp/blog/18/zenlogic_1.html [publickey1.jp]
Re: (スコア:0)
不適切な帯域制限はストレージシステムの入れ替え作業後に、設定変更実施だから違うような。
そもそも適切なキャパシティプランに変更していれば発端である事象Aが起こらなかったんじゃないかな。
再発防止策でキャパシティプランの見直しと性能指標の取り方教えてもらってるみたいだし。
問題起きるまでほったらかし管理手法だったんじゃないかな。
# しかし、『システム全体への影響を最小限にするために外部ネットワークとの接続を遮断』って、
# 『毒が全身に回らないようにトドメ刺しといた。何とか瀕死ですんだぜ』みたいな感じかな。
Re: (スコア:0)
> 問題起きるまでほったらかし管理手法だったんじゃないかな。
一番の問題はそこだよね。
この報告が出るまで、公表されている再発防止は「システムが落ちたらまた付け焼き刃でシステム増設する」とかいう絶望的な内容だったし…
Re: (スコア:0)
ストレージ直結の部分の帯域制限はかけたものの、それよりも手前では
制限なしに流れるようにしたからドロップが発生して輻輳したとかいう
オチかもね。
詳細はわからないが、設定ミスがあったってことを半月も特定できない
のはちょっとね～。
中断出来なかったの？ (スコア:0)
設定間違ったのに気づいた時点で中断出来なかったの？
出来なかったとすれば、もしその期間中にストレージに障害起きてたら致命傷だったんじゃない？
出来たはずだったとしたら何でやらなかったの？
Re:中断出来なかったの？ (スコア:1)
中断したらそれこそ致命傷だからでしょ。同期中に停止するとか怖すぎ。
だから、外部と分断してリミッター外してさっさと同期終了させたんだろ。
Re: (スコア:0)
世の中の不具合の半分ぐらいは「知らなかったんです、ごめんなさい」なんだけど
世間はそれをどうするの？
Re: (スコア:0)
その不具合は何百のサイト停止するほど大きな問題の場合はお客さんにどうすんの？
Re: (スコア:0)
わかりやすい障害なら直ぐにわかったかもしれないけど
でも気付きにくいのは、エラーも出ず動いているのなんだよね
ネットの設定も間違い方によってはわかりにくいこともある
なんかわからんけど遅いとか、嫌だなぁww
ヤフー側 (スコア:0)
結局ファストサーバ側に対処能力がなかったから、
風評被害が及ぶのを防ぐためにヤフー側から対応要員を送り込んできたのかな？
Re: (スコア:0)
報告書、ヤフーから報告、ヤフーが追加改修、設定値変更などをヤフー株式会社にて順次実施
と、ヤフーに原因あるかのような書き方ですが事実はどうなんでしょうかね。
高負荷になる程度のストレージシステムの規模を決定したのはヤフーなのかファーストサーバなのか
対応内容のヤフー実施項目は
ファーストサーバの責任において依頼をうけたヤフーが実施したのか
ヤフーの責任においてヤフーが実施したのか
ファーストサーバの責任だけど手に負えない状況を見かねてヤフーが実施したのか
Re: (スコア:0)
責任の所在はともかく、インフラを外注することの弊害が際立って現れたケースですね。
自社の顧客に損害が出ても、対応を待っていることしかできない。
Re: (スコア:0)
ファーストサーバーがちゃんと性能指標を監視して、適切なキャパシティプランに
変更していればそもそも起きなかった。
だから、再発防止策はそれが行えるようにした。と読める。
ヤフーは「契約の範囲内で顧客対応しました。ちょっと作業ミスもありました」じゃないかな。
キャパシティプラン選択の責任はファーストサーバにあると思うし。
ヤフーの一存で契約プラン変えて請求なんて出来ないからね。
Re: (スコア:0)
ファーストサーバは前回の度し難いトラブルや数々のトラブルの
印象から今回のもファーストサーバの技術力云々をディスるコメが
多いけど、ヤフーのIaaS使ってたうえでのトラブルだからヤフーの
責任のほうが大きいような気がするよ。
Amazon 使っていたほうのサービスは影響しなかったわけだし。
ただ、ヤフーの想定していた使い方よりファーストサーバの使い方
（使わせ方）が酷すぎて起きたトラブルだった可能性もあるけど。
今回どこまでファーストサーバが技術的に関われていたのか不明
なのだけど、ヤフーのIaaS環境まで入り込んで作業できたとも
思えないので。
自分のところがやっているサービスだったら、オペレーションミス
でユーザーのデータを大量消去してしまうようなお客さんに、内部
ネットワークまでいじれる権限は渡したくないな。
Re: (スコア:0)
IaaSの上にcephのっけてネットワーク詰まらせたんならファーストサーバ側の責任では。
AWS上の方は多分ストレージは単純にEC2なんでしょ。
大量のデータ移行 (スコア:0)
> ストレージシステムの増強および設定変更に伴って大量のデータ移行が発生したことが原因で
あ～。
分散ストレージって、確かにこういう種類の実装があるのよ。
ストレージ増設すると、容量バランスやり直しになって大量の転送が発生し、高負荷が続くタイプ。
もちろん、そうならないタイプの分散ストレージもあるけど。
負荷に強いことを理由に分散ストレージを使う場合には、この点にも注意して選択した方がいいですね。
Re: (スコア:0)
昔から専門家はいませんでしたよ。
Re: (スコア:0)
専門家は「ファーストサーバって、あのやらかしたファーストサーバか。あの時に比べて今回は微妙だな。」程度の感想しかないでしょう。
関連リンクにそれ関係がないのは編集者が情けをかけたのかなー
Re: (スコア:0)
自称専門家はテキトーなことを言うだけのやつ（Fには技術力がないとかいうだけ）なのでピント外れの悪口書いて満足するんでしょう。
同業者はいつか我が身に類似トラブルが起きた時のことを考えると同情するのみ。
＃いつか自分の身に起きるかもということまで考えない近視眼的な同業者はボロクソに叩くかもね
Re: (スコア:0)
同情するのみはねーわ。
自分とこのシステムで類似の問題が発生しないか再検証するとか、
類似ではなくても今のシステムでどういったトラブルが発生し得るかの棚卸しをするとか、
あるいは想定し得るトラブルが発生した場合の対応策を見直すとか、
他山の石とすべく何かしらやるよ。
Re: (スコア:0)
同業者なら同情よりも対策を急いで被害者をこれ以上増やさないようにする、と信じたい。
ビジネスは楽しさが大事とか主張する方々では？
問題点はありふれた事例のため参考にならない点。
Re: (スコア:0)
専門もクソも
「有効な負荷監視してなかったら過負荷で死んで操作ミスって大惨事」
ってだけの話だから「最初から負荷監視しとけやボケが」で終わりやん。
兆候が見られた時点で過負荷に陥ってるのは分かってたのにこの報告まで負荷監視に関する言及なしで、
一通り収束後の7月13日になってようやく「システム性能監視指標を設定」っていう気の抜けよう。