タイトルはデスノートとかで有名なセリフですが、今回のコイツはもちろんサーバのことです。
もっと詳細にお話すると、冗長構成(HA構成)の時のサーバ切り替え時に何を以て故障と判断し、切り替え処理を行うかという点のお話です。

今回なぜこの話を書こうと思ったかと言えば、先月(2020年10月)に起こった東証のシステムがバックアップに切り替わらずサービス停止したのをみて、思うところがあったからです。

▼障害原因はメモリ故障

同じサービスの運用者として東証の対応がどうだった、富士通がどうだったという話にも勿論興味はあるのですが、すでに方々で語り尽くされている内容だと思いますし、私はそこまで事情を把握しているわけでもないので、その辺りは他の方にお任せするとして、私が注目したのはバックアップに切り替わらなかった原因が「メモリ故障」だったということです。

この連載では何度もお話しておりますが、サーバやネットワーク機器は経年劣化等で必ず故障しますし、ネットワークは繋がらなくなります。

それは周知の事実として、問題はその壊れ方です。

▼運用試験でどこまで試験できるか

私が担当するシステムの自動切り替え機能は運用試験を実施するのですが、例えばデータベースサーバ(DBサーバ)の自動切り替えの試験は、下記のいずれかで切り替えが実施されるかを確認しています。

1. 主拠点DBサーバのRDBを停止して、副拠点DBがアクティブになる。
2.主拠点DBサーバ自体の電源を落とし、副拠点DBがアクティブになる。
※もちろん主・副を逆にして切り戻しが実施されるかも試験します。

また、主拠点DBサーバに対し、副拠点DBサーバは複数要素を用いたチェックで誤作動での切り替えが実施されないよう工夫がされています。

① 副拠点DBが主拠点DBサーバのRDBのデータに定期アクセス
　→運用系DBが利用できる状況であることを確認
② 主拠点側WEBサービスに定期アクセス
　→①だけの判断では拠点間ネットワーク障害の際にも切り替えが実施されてしまうので、主拠点DBを参照している主拠点WEBが利用できることをWEBアクセスを用いてチェック。

上記①②がいずれも3分間で3回連続してエラーとなった場合のみ、
運用DBサーバの自動切り替えが実施されます。

ここで注目していただきたいのは、「サーバのメモリが故障する」等の機器の一部の故障状態での試験は実施できないということです。

私が過去経験したハードウェア故障には下記のような事象がありました。

・DBサーバのディスクが書き込みができない。
　ただし、読み取りは可能。
・DBサーバのディスク書き込み速度が異常に遅くなる。
　ただし、書き込みができないわけではない。

ポイントはもちろん太字で記載した箇所で、必ずしも運用試験で実施した状況と同じ壊れ方をしてくれるわけではないという点です。

実際上記の事象が発生した際は、明らかに異常な状況となっているものの、サーバの動きが切り替えプログラムでは想定していないものとなっていたため、結局手動での切り替えを実施してことなきを得るといったことがありました。

この半死にの状態を如何に検知して切り替えるプログラムをつくっていくかが運用と開発の力の見せ所かなと思います。

▼自動切り替え判定改善案

一つの案として、定期的に「ダミーデータでデータベースを更新するプログラム」を作成しておき、そのダミープログラムがデータベース更新出来なかったらサーバに障害があるとして切り替えを実施する等が挙げられます。

また、上記プログラムで書き込み速度についても測定しておき、正常値と比較して明らかに処理時間が遅い場合はこちらも異常として切り替えを実施するとしてはどうでしょう。
※こちらを実施する場合は普段の処理速度を把握しておく必要があるので、
　DevOps環境を構築し、常時どれぐらいの書き込みスピードが出ているかを把握しておく必要があります。

こういった実際の壊れ方ばかりは長年システム運用に関わってきた人間だけがわかるところなので、自動切り替えプログラムをつくることになった開発チームの方は、是非運用者に話を聞いて普段の処理速度や今まで起こった故障事例を聞くなどしてノウハウとためていただければと思います。

開発は実際の運用に即したものを作れるのが一番です。
運用者は求められればしっかり情報開示しますので、品質の高いプログラムをつくるために、ぜひ頼ってあげてください。

それでは今日はこの辺で。