WEBサービスなどで障害が多くて困っている運営側が考えるべき障害予測の話

これまで、大小様々なシステム障害を経験してきた、ユゲタです。 毎年12月はサーバー障害が多い月って、知ってましたか？ もちろん12月は、いろいろなECサイトでの年末商戦、クリスマス商戦という年内で最も金が動くタイミングでもあるので、その影響かとも思いがちですが、 それ以外にも、12月は年末ということで、いろんな会社がシステムのアップデートを行ったり、 会社の期締めのタイミングという事で、やっつけでシステム構築作業を完了させたりする、様々な要因が含まれているんですが、 活発に動く月であるということが原因と考えて良いかもしれません。 まあそれはそうとして、Webサービスなどを公開している会社では、年間通して、何かしらのサービス障害が発生して、 裏ではエンジニアが四苦八苦しているという現状も、ユゲタは痛いほどよく理解しています。 そして、そんなエンジニアの事を我が身のように痛み分けしているつもりです。 社長などの経営者から、「いーかげんに障害をなくしてくれ」と上から目線で怒鳴りつけられながら、 意味のわからないネットワーク障害やら、カーネルパニックやら、遅延対応やら、意味わからないサーバーダウンなどの原因をさぐるために、/var/logフォルダとにらめっこをしているエンジニアの人。 少し思考を変えると障害って結構なくなるという事を学習してみてもいいかもしれませんね。

これまで味わった、意味のわからない障害集

これは、ユゲタがこれまで実際に経験してきた意味のわからない障害をいくつか紹介してみます。

1. ロードバランサーの誤作動

サービスの全てのパケットを一手に請け負うロードバランサーは、障害を起こしてしまうと、サービス全体が大ゴケしてしまうとんでもない大災害に見舞われます。 その時には、中堅クラスのA1というメーカーのロバラを使っていたんですが、ある時（夜中の2時頃だったと記憶してます）いきなり通信ができなくなり、サービスが停止してしまいました。 色々調査していくうちに、どのサーバーでもエラーが出ておらず、ネットワークがロバラ直前まで疎通されていたので、それを疑ってメーカー問い合わせをしてみた所、 エラーログが発見されたとの返信をもらって、ビックリ。 もちろん、保証対象の領域なのですが、A1という世界的に製品販売しているその製品では、初めて発動した障害だったようで、「前例が無い」という返答でそのまま泣き寝入りをすることになりました。 それから10年以上使って、同じ事象は一度も発生していないので、その時行ったシステムアップデートで直ったんだろうと思っていますが、個人的には、ロバラシステムがやらかしてくれたんだと思い出すたびに思っています。

2. システム設定ファイルが別の場所に移動していた

それは、あるwebサービスを運用していた時に、ユーザーから問い合わせが入って、一部分で、サービスが機能していないというクレームでした。 確認してみると、確かにエラーになっていて、システムが正常に機能していない。 内部構造を調べていくうちに、そのシステムの設定ファイルと呼ばれるファイルが、入っているべきフォルダのとなりのフォルダに移動していることが判明。 直近でアップデートを行ったであろうエンジニアに問い合わせてみても、「知らぬ存ぜぬ」の一点張り。 会社側には、原因不明のシステム障害としてレポートを提出しておいたんですが、ユゲタは、そのアップデートを行ったエンジニアが、FTPソフトでそのファイルを無意識に移動させてしまっていたのではないかと疑っています。 操作手順や、彼のオペレーションのずさんさを考えると、チーム内の誰もがそれが原因だと分かっている様子で、それをしらばっくれている彼には心底腹が立ったのですが、 結果的に、それ以来、彼が周囲から信頼を失ったのは言うまでもありません。

3. cronが正常に起動しない障害

定期バッチなどを運用する時に、Linuxシステム上で動いているのであれば、大概はcronでのバッチ起動をやっていると思いますが、 ある時、朝会社に行ってみると、そのバッチ処理が正常に終了しておらず、障害報告がされていることがありました。 調べていくうちに、バッチ内に複数の処理が書かれていて、上位の処理でエラーが発生して、バッチ進行がストップしていることが原因だとわかりました。 複数の処理というのは、３つほどのサービスが起動していて夜中にそれぞれのサービスのログなどのデータ集計を行う処理をバッチで行っていたんですが、 2番めのサービスが、前日のアップデートに伴いエラーになって停止してしまったんですね。 そのおかげで、3番めのサービスは、正常にバッチ処理が完了していなかった事から、関係者みんなに、袋叩きに合うレベルの罵声を浴びせられ、 結果的に責任は2番めのサービス担当者だったのだが、原因が明確化した時の翌日にその3番目サービス担当者は、辞表を会社に提出していたという結末に至りました。

障害は災害ではなく人災と考えよ

サーバーのハードウェア障害のために、サービスがダウンするのは仕方が無いことですか？ いいえ、サーバーがダウンしたときのために、コールドスタンバイしたサーバーを容易しておくべきだし、サービスを瞬間でも止めないために、ホットスタンバイにしておく必要があります。 ネットワーク障害が発生したら、サービスは継続していなくてもいいかというと、別回線を設けて冗長化を図っておくのも、有償サービスを運営している側からすると、当たり前です。 サービスが頻発する会社では、こうした障害発生予測が十分にできていないという事が往々にしてあります。 これまで発生してきた障害に関しては、その都度対応してきた経験から、同じ障害が発生してきても、すぐに対応できると考えているとしたら、大間違いで、 同じ障害は2回発動させてはダメなんですよね。 メモリオーバーが原因で、アクセスが集中する時間帯に、ハラハラドキドキしながら監視サービスのグラフとにらめっこしている場合じゃないですよ。 どのくらいのアクセス数で、メモリをどのくらい消費するのかを、ちゃんと計算して論理監視を行わないといけないという事です。

障害検知テクニック

障害を検知するには、ハッキリ言って、スキルが必要です。 それは「障害予測」がどのくらい正確にできるかという、占い師などのような曖昧ではなく、論理的にです。 そして、障害予測は、そのくらいの深度で行うか、そういったジャンルで検討されているか、という最も幅広く考えて、それに対する対応を事前に検討できているかどうかというスキルになります。 Webシステムのテクニックで言うと、まず、ネットワーク構成図を作り、端末、回線など全ての機器や配線、経路などに、バツが付いた場合に、どのように対応するかを、事前に思考してみます。 こうすることで、いきなり障害発生したときでも、事象によってどの部分の障害かを見極めるスピードが格段に早くなるでしょう。 そして、その端末やシステムなどの内部構成のハードウェア、ソフトウェアなどをどんどん深堀りしていって、次々にバツを付けていきます。 こうすることで、発生する障害に対してナンバリングをしていくことができ、その後発生した障害が、ナンバリングされていない事象で合った場合、障害予測スキルが足りていないと自覚すると良いでしょう。 もちろん、これは経験によってスキルアップしますが、こおうしたドキュメントを残しておかない限り、スキルとして蓄積しないし、 会社で運用しているサービスであったとしたら、チーム内共有や、新しく入った人への教育など、全く出来ない状態であると考えましょう。

障害の考えるべき、内部と外部

もっと突っ込んで考えてみると、障害には「内部障害」と「外部障害」というのがあります。 自分たちでプログラミングしたシステムでの障害は内部障害ですが、周囲のネットワークが停止してしまうことによる障害は外部障害として考えられます。 では、DDOS攻撃などの時のシステムアクセス過多障害は、内部障害でしょうか？外部障害でしょうか？ これは、基本的に内部障害です。 アクセス過多防衛策が練られていない事から発生した障害と考えられます。 このように、障害を深堀りして、堅牢なシステムにしていくということも、システムエンジニアにとっては重要な作業であると考えると、 論理的障害予測ができるようになりますよ。 どれもこれも、結局は経験がモノを言うわけですけどね。