会社のWEBページとブログページで利用しているWebArenaから障害報告が来ました。
Webarenaの障害報告では、「5:30に発生」と報告されていたが、こちらの計測アラート（savamoni）は4:07から発生していた。
アラート検知タイミングが遅いのか、気づいた時間なのか分からないが、とてもレベルの低い検知であることは間違いがないと感じた。
原因はアクセス過多という事しか報告されていないが、正直疑わしい点もあり、詳細が報告されないことも不信感にしか繋がらない。
WebArenaのサーバー運営体制を見る事で改めて、サーバー管理とサーバー監視のあり方を検討できたので、今回のブログとして記事を書きました。
サーバー運営について
サーバー運営をやってきた経験があるエンジニアであれば、誰もが同じ思いだと思うが、障害発生時は、一刻も早く、復旧させたいというのが本心。
各種への報告義務などを作業エンジニアが同時に行うことは不可能なので、報告担当などの運営体制が必須。
（※これができていない会社が多く、トラブル時にアタフタする事が多い）
そして、データ紛失だけは防ぎたいので、ストレージの安全性や、DBのアクセス確認なども行うが、こうした事が手順かされていないと、確認すらできない状態になり、復旧したが、データが正常化どうかは分からずじまいとなる。
VPSはやはりダメなのか？
VPSという特性上、データの中身までは対応仕切れないと思うが、VPSとしてのOSストレージは対象である。
Webarenaは、障害報告のタイミングも遅い上に復旧完了の案内はかなり遅れて送付される。（今回は１時間後ぐらい）
ちなみに途中経過報告タイミングは１時間に１回という体たらくだ。
→サーバー監視レベルで言えば5分おきの自動更新にするべきなのだが、Google社のサーバー稼働状態ページを参考にしてもらいたいものだ。
そして「VPSはSLA対象外」という事は百も承知なのだが、SLAの範囲もいささか管理できていなくても責任を取らないという規約にも見えるので少し引ける。
改めてVPSを使う上で、以下の点が重要であることを認識できた。
・データのバックアップは別環境のストレージにできる限りのタイミングでコピーする。
・プログラム環境もDNSを切り替えればいつでも移動できる体制を随時準備しておく。※ただし、データの上書きや、巻き戻りなどに注意して設計すること。
・監視値も、HTTPやHTTPSだけでなく、直前までのディスク容量、CPU値、OS全体タスクのPROC数、メモリ値（割合）、ユーザーアクセス状態（PV数）などを把握しておく必要がある。
これらの状態を把握する為には、muninなどの監視システムで十分だし、もっと簡易な外部監視サービスでも十分だ。
いち早く原因究明に繋がると共に、サービス切り替え（セカンダリへの）の判断を素早くできることになる。
WebArenaを含め、VPSとの付き合い方
今回のwebarenaの復旧完了は12:30までかかり、発生からの障害期間は7時間ということになる。
※ただし、こちらの計測から考えると８時間を超えている。
この間にどのような対応が行われ、今後に向けてどのような対策がされたのかは報告されずじまい。
NTT-PC WebArena 障害報告
改めて、このサーバーは、フロントサーバーの一つとして、「捨てサーバー要員」として使う事しかできないし、DBなどをおくことは危険と判断せざるを得ない。
ちなみに、このサーバーの障害履歴は以下の通り。
1. 2017/09/25 23:04 - 31:34 (8h 30min)
2. 2017/11/27 23:05 - 26:52 (4h 47min)
3. 2018/1/28 05:42 - 12:57 (7h 15)
だいたい３ヶ月毎の月末に障害を発生させている。
きっと、同じVPSを使っているどう端末ユーザーで障害を起こすサービスをやっているか、中国、ロシアからのbot過多が原因であろうと推測できる。
・・・が、詳細を明かさないので、サーバーエンジニアの凡ミスの可能性もあり、詳細は不明だ。
今の所、さくらインターネット、AWSを切り替えようサーバーとして用意しているので、改めてサービス構築において、こうした対策作りが非常に重要であることを認識できた。
レンサバだろうが、VPSだろうが、オンプレサーバーだろうが、AWSだろうが、どれも障害が起きないわけではありません。
障害の頻度とその対応については、品質として評価する事ができます。
そうした点と、支払っている金額を見比べて総合評価するのがいいでしょうね。
ちなみに、僕がWebArenaに支払っている金額は、月に388円です。
金額なりの品質なんでしょうね・・・orz
0 件のコメント:
コメントを投稿