僕の高度情報処理試験・勉強日誌～ITSM編！！ 第２４回 H22/問2・設問2。
さて、問2です。
前回は回答の理由を考えるところの難しさを記録しましたが、実は今回はもっと・・・
という事で、
◆設問読む。
と書きましたが、あまりに短い設問で、
要は、障害時に手順があって、最初の手順aは何かという事らしい。
それはわかるが、図2のaを見ても、まったく見当がつかない。
そのため、キーワードを抜き出してみる。
①Webサーバ障害時
②復旧手順→図2
③a → 障害状況確認 → 再起動
である。
①のWebサーバの事を知るためにはサーバ環境が書かれているところ
を見つけるため、リードバックすると、
図1のシステム構成で、以下の状況が判明。
Webサーバとは、Webサーバ１とWebサーバ２の事。
なぜ２つあるのかは、LBで負荷分散しているからで、
サーバ稼働状態を５分毎に監視し、正常な方に要求を振り分けている。
・・という事です。
◆回答へのアプローチ
さて、これらの情報で回答を考えてみます。
まず図２で、１で実施した後に障害状況を確認しています。
きっとここは結構重要なポイントかもなと思いました。
なぜ、障害時なんだったら、当然真っ先に障害状況を確認するんじゃ？って
思ったら、それは２番目に行う事で、実際は、それよりも大事なことが１番目という事です。
さて、それは？
シンキングタ～イッム。
こういう時は、実際にWebサーバ障害なんだから、Webサーバ１を故障した事にします。そしたら、いったいどういう手順対処がいいのかな？というシミュレーションです。
では、Webサーバ１故障・・・・でもWebサーバ２があるんだから大丈夫なんじゃ・・・ん！ってここで、閃くべきなんです。
（実際問題解いた僕はそうならなかったのでここは反省ですから、今から書くのは結果論ですが、閃いたと仮定したら・・・です）
この図のような状態と考えます。
そうすると、図2の手順を再度見ます。
１、a
２、Webサーバ（１）の障害状況確認
３、対処後にWeサーバ（１）を再起動
となります。
Web1が壊れてどうしようもないのに、障害状況確認よりも先決、最優先に行わなければいけない事は何でしょうか？という点で問われているという事に気づけば解答は得られます。
つまり、障害時に再優先となるのは、やはり可用性の観点であるという事です。
前回問われていた可用性の観点は、システムを停止させないという事でしたね。
その観点だとちょっと厳しいので、もうひとつの観点、すぐに使える状況であるか？です。
上のイメージ図を見てみますと、
Web２に振り分けられれば、ユーザの要求は青い方向となり問題なくレスポンスが返ってくるでしょう。
しかしながら、Web１に振り分けられてしまったら、赤い方向となり、レスポンスは返ってこなく、タイムオーバーとなるかもしれませんよね。
つまり、そうならないようにするための手順を１として行う必要があるというわけです。
このそうならないようにする。というのは、もう少し詳細に書くと、
まぁタイムオーバーにならないようにするのではなく、もっと根本的な、Web１に振り分けられてしまう（処理割当て）事が無いようにするのです。
という事は、振り分けているもの、そうLBの存在をなんとかしなくてはいけないという事です。具体的に言うと、Web１が使えない今はLBは不要なのです。
しかしながら、LBを除去したり取っ払うとWeb１（当該Webサーバ）がふっきゅうしたらまた戻すのが大変そうです。
そんなわけで、LBの設定を変更するという手順になっているようです。
したがって、模範解答は以下となります。
LBの設定を変更し当該Webサーバへの処理割当てを取りやめる。
という事です。
◆所感
ここで気づいたことは、問題のアプローチです。
今までは、下線aとかだと、下線スキップやその下線のリードバックとかしていたらよかったが、今回は、まったく近辺にヒントもなく、しかもリードバックをするとしたら、結果的に該当チャプタよりも４つも前の〔予約方式1の処理概要〕まで遡らなければなく、なかなか今までの方法では厳しいアプローチとなったなぁと感じました。
◆アプローチ考察
今回のような問題のアプローチですが、
まず、Webサーバの障害。という起きた事を想定しながら、そのために必要な情報が書かれているのは、図1であり、クライアント要求からWebサーバまでの間にLBがあり、LBの説明が書かれているのが、〔予約方式1の処理概要〕であるとキーワードサーチで判明したため、当該チャプタ内に書かれている概要と図１から、上記イメージのような状況を考えて、Web1壊れてるのにLBは律儀？にも要求割当やってるぞ、やばいやん。という風に考えるフットワークが必要なのかなという事です。
以上、次回、設問３。
