システムに障害が発生した際に、HAクラスター構成の待機系ノードでのフェールオーバーがスムーズに行われ、問題なく業務が継続できたとしても「結果オーライ」では済まされません。システムのどの箇所にどんな障害が発生し、どのようにフェールオーバーしたのか。障害の原因と復旧のプロセスをしっかり検証し、システムに内在する問題点があれば改善する必要があります。クラウド上にHAクラスター構成を導入し、適切に運用していくための勘所を紹介します。
HAクラスターの運用管理責任はユーザーにある
システムをオンプレミスからクラウドに移行するメリットとして、「システム運用管理からの解放」がよく挙げられます。
しかし、本稿の第1回 でも述べたように、クラウド事業者が責任を持って対処してくれるのは、ホストサーバーやネットワーク、ゲストOSのレイヤーで起こる障害までに限られます。定期的なpingなどによってゲストOSの応答を確認し、死活状態を監視していますが、アプリケーションに潜在している不具合（バグ）や設定ミス、操作ミスによる障害までは検知することができません。
これを補うために必要となるのがHAクラスター構成というわけです。クラウド環境においても重要システムに対してHAクラスター構成を組むことで、幅広い障害の検知ならびに短時間でのフェールオーバーが可能となります。ただし、HAクラスター構成はユーザーが独自に持ち込むものである以上、「その運用管理の責任はユーザー自身にある」ということを、しっかり認識しておかなければなりません。
システムに障害が発生した際に、仮に待機系ノードでのフェールオーバーがスムーズに行われ、問題なく業務が継続できたとしても「結果オーライ」では済まされません。たとえクラウド環境であっても、運用基盤がブラックボックス化するのを避ける必要があります。この取り組みが、ふたたび同じ障害が発生することを回避し、システムのサービスレベルや可用性をより高めていくことにつながります。
障害の原因追及で必須のログ取得
オンプレミスであれ、クラウドであれ、HAクラスター構成の透明性を確保し、ガバナンスを確保する上で重要となるのが「ログ（履歴情報）」です。サーバーのログ、OSのイベントログ、アプリケーションログのほか、できれば、セキュリティログ、マネージャーログなども取得しておくのが理想的です。
平時からこうしたログを取得しておくことで、万一システムに障害が発生した際にも、どの箇所にどんな障害が発生したのか、どのようにフェールオーバーしたのかなどをトレースし、障害の原因と復旧のプロセスを確認することができます。また、有事の際にはシステムダンプを取得した上で解析することにより、システム障害が生じた要因を突き止めることができる可能性があります。
もっとも、これらのログを人間の管理者が目視でトレースしたり、分析したりすることはきわめて困難です。そこで運用管理ツールに備わっている監視機能やレポーティング機能、分析機能、ダッシュボードなどを活用することになります。
こうした運用ノウハウを捨て去ることなく、最大限に活用していく意味でも、クラウドに移行する際にはオンプレミスで利用していたのと同じHAクラスター製品を持ち込んで利用することをお勧めします。
Chefとの連携でインフラから操作ミスを排除
さらにクラウド上での障害発生のリスクを下げる、障害が発生した場合でもその原因追及をよりやりやすくするという観点からお勧めしたいのが、HAクラスター製品とChefの連携利用です。
背景にあるのは、「設定ミスなど、人的要因によるシステム障害を削減する」という狙いです。保守などを除いた計画外のシステム停止時間の中で、ハードウェアの故障やシステムソフトウェアの不具合といったテクノロジー的要素を原因とするものよりも、アプリケーションの不具合を原因とするものや、オペレーション（運用）上の作業ミスのような人的要因によるものの方が多いと言われています。
今後、クラウドの信頼性がさらに向上していくにつれ、テクノロジーを原因とするシステム障害はますます減少していく一方、相対的な意味で上記のような人的要因によるシステム障害の割合はさらに増加していくと考えられます。
そこでなぜChefなのか――。Chefは、「Infrastructure as Code」というコンセプトに基づいて開発された自動化フレームワークであり、あたかもRuby言語でプログラミングをするように、インフラの構成管理をコードによって行うことを可能とします。
社内標準のインフラ定義（レシピ）を作成するとともに、その実行までのすべてをChefに任せることができるのです。従来のような複雑な手順書を作成したり、属人化したノウハウや経験に頼ったりすることがなく、均質なインフラ構築を自動化することができます。
こうした自動化によって、人為的な作業ミスを排除することができ、システムダウンにつながるさまざまなトラブルのリスクが軽減します。また、すでに安定したHAクラスター構成をオンプレミスで運用しているのであれば、そこから抽出した構成情報を使って、HAクラスター構成をより容易にクラウドに移行することができます。
次回は、クラウドにおけるSPOFのリスクについて考えます。
