今回は実際のWebサイトにおける障害をもとに、その状況や対処についてお話をしていきます。
Webサイトを開発した後に、運用を行うのであれば、いつどのようなトラブルが起こるかわかりません。
今回のお話は、その際の参考にして頂ければと考えています。
対象システム
まず今回、紹介する障害が発生したWeb サイトのシステムの構成を簡単に説明します。
Web サイトの概要については、WordPressを利用した記事の公開サイトとなっています。
サーバーの構成としては、Webサーバーが3台冗長化されており、その後ろにDB サーバーが3台冗長化されているという構成になっています。
WebサーバーとDB サーバーはそれぞれでLBにて負荷分散（ラウンドロビン）されています。
ユーザーは、Web サーバーへアクセスを行うと、記事情報をDBサーバーより取得してその内容をWebサーバーから返却するという仕組みになっています。
障害の状況
今回の障害の事象を説明します。
まず、はじまりとして、URL監視のアラートが発報されました。
これは、状況としては、URLアクセスにて画面を開こうとした際に、正常に画面のデータが取得できないという事象が発生していました。
ただ、全てのアクセスにてそれが発生するわけではなく、何度かに1度のアクセスで発生するという事象でした。
画面が開けることもあれば、開けないこともあるというような状況です。
また、同時に別のアラートも発報されていました。
それはDBサーバ3号機のCPU使用率がとても高まっているという内容でした。
障害に対しての原因調査
上記のアラートより、Webサイトの運用メンバーにて事象の調査をはじめました。
その結果、結論から言うとプログラムのバグではなく、DBサーバー3号機におけるハード問題ではないかという見解です。
その判断をしたポイントは以下です。
・DBサーバは3台とも同じスペックで同じ設定が行われていること
・DBサーバへのリクエストに偏りがなかったこと
このことから、基本的にはDBサーバについては3台ともに同様の負荷がかかるはずです。
1台だけに異常値が発生することはDBサーバのハードの問題ということが高いということにいきつきました。
ユーザーがアクセスした際に、WEBサーバを経由して、DBサーバ3号機よりデータ取得しようとした場合、レスポンスが返らず（遅延するなど）で、正常にユーザーに対して該当の画面を表示できていなかったということです。
DBサーバ1号機、DBサーバ2号機より取得されたアクセスについては、正常に画面を返している為、全てのアクセスにて事象が発生するわけではないということでした。
障害への暫定対処
ハードの問題であれば、機器の修理や交換の対応ということを行っていかなければなりません。
ただ、それには即座に対応できるものではありません。
今、現時点でサービスに影響が発生しているため、こちらを暫定的にでも対応しなければなりません。
いくつかの対応方針はあるかと思いますが、今回対処した方法としては、DBサーバ3号機をLBより切り離すという方法をとりました。
現在のアクセス量では、DBサーバは2台構成であっても問題なくリクエストをさばけると判断し、根本的な対処（ハードの修理か交換）が完了するまで、一時的にDBサーバ1号機とDBサーバ2号機での2台構成での運用を行うという方針にて進めることとなりました。
LBより問題のDBサーバ3号機を切り離しを行いました。
このことにより該当のURL監視アラートは発報されなくなり、ユーザーアクセスについても全て正常に戻りました。
まとめ
今回はWebサイトでの実際の障害、その状態とそれに対しての暫定対処についてお話をしてきました。
内容は以下でした。
Webサイトは、ユーザーが常にアクセスしておりシステムも24時間365日動作しています。
その中では、様々なトラブルが発生します。
それをどのように検知して、どのように判断して、対処していくか。
それはシステムをどのように運用しているかにより変わってきます。
システムを安定的に動かして、サービスを提供していくには、この運用という部分がとても大切になってきます。
今回の障害については一例となりますが、参考にしていただけると幸いです。
以上です。
コメント