サーバダウンに備えよう - 可用性を高める運用のポイントを解説

企業のITインフラやさまざまなITサービスを実現するうえで「サーバ」は欠かせない存在で、企業が求めるIT人材として知っておきたい必須知識の1つでもあります。

本連載では、「サーバとはいったいどのようなものか？」に始まり、利用方法や種類などの基礎的な知識とともに、セキュリティ対策や仮想化、サーバレスなど効率的にサーバを利用・管理するうえでのポイントといった、情報システム担当者の実務に役立つ話題を紹介していきます。

連載第9回は、キンドリルジャパンの佐藤創太郎さんに、主にオンプレミス環境を想定したサーバダウンを防ぐための可用性確保と復旧のポイントについて解説してもらいます。

サーバの耐用年数はどれくらい? 信頼性を高める方法は?

サーバの耐用年数は、「製品の保証期間」で決まります。保証期間内であれば、ハードウェアの故障が起こっても数日で交換してもらえます。一般的に保証期間は3年もしくは5年で、この保証期間をハードウェアの耐用年数と考えれば良いでしょう。

ただし、耐用年数には、そのサーバで動かすシステムのソフトウェアの寿命も考慮しなければなりません。ソフトウェアの寿命とは、メーカーやベンダーのサポート期間を指します。つまり、セキュリティ対策などのアップデートが行われ、システムを安全に動かすことができる期間です。

利用するソフトウェアには、OS、仮想化ソフト、データベースソフトなど、さまざまなものがあります。サポート期間は製品ごとに異なりますが、多くがリリースから2年から10年程度です。

現在は、利用するソフトウェアのサポートが終わったタイミングに合わせて、ハードウェアを含めてシステム全体を新しいものに更改するケースが多いようです。サーバの耐用年数は、ソフトウェアのサポート終了期間も含めてきちんと記録し、考慮しておく必要があります。

それでは、サーバはどれくらいの頻度で故障するものなのでしょうか？

指標の1つに、「可用性＝availability」があります。システムが故障などトラブルを起こさず、持続的に稼働できる能力・性能を示したものです。可用性が高いものほど、故障時間が少なく、信頼性が高いシステムとされています。

サーバの故障頻度は、一般的な機械の故障率曲線(バスタブ曲線)に従いますが、故障が多くなるタイミングもあります。まず、サーバ購入後のセットアップ時、ストレス試験実施時などに判明することが多いです。実際の運用が始まると、散発的なハードディスク故障などは発生するものの、頻度は低下します。ただし、最初に説明したハードウェアの耐用年数を超えてサーバを利用し続ければ、故障頻度も増えます。

サーバを活用し、サービスを安定的に提供するためには、システムの可用性に関する知識が重要です。IPA(情報処理推進機構)の情報処理技術者試験でも出題される可用性の計算式では、可用性が1.0の時、システムはどのような場合も100%利用可能になるとしています。ところが、複数の機能を直列に接続して構成したシステムは、全体の可用性が低下するのに対し、同種のサービスを並列に配置すると可用性が向上します。この原則はサーバを含むシステム全体を構成するうえで、ぜひ押さえておきたいポイントです。

• システムの可用性の基本と計算式

例えば、Webサーバを並列に配置し、可用性を向上させる場合、並列化するためのロードバランサーがSPOF(Single Point Of Failure、単一障害点)になっていないかなど、注意する必要があります。

コストに配慮した「適切な冗長化」の考え方

サーバダウンの原因はさまざまで、複数の原因が重なることもあります。主な原因は、ハードウェア障害や、熱・ほこり・結露など環境原因によるものです。また、ソフトウェア障害、人的ミス、メモリの容量不足などのパフォーマンス・キャパシティ障害が原因でサーバはダウンします。

ソフトウェア更新に伴う再起動やライセンス失効による機能停止にも気を付ける必要があります。他方で、法定点検で建物が停電するなど、運用上欠かせないサーバストップもあります。

• サーバダウンの主な原因

サーバダウンの有効な対策が「冗長化」です。冗長化とは、同じ機能、役割をあらかじめ複数用意しておくことで、異常が発生した時に肩代わりできるよう待機させておくことを指します。

冗長化のレベルはさまざまで、例えば電子回路には冗長符号を付与したECC(Error Checking and Correcting)メモリを採用することも対策となります。ネットワークアダプタおよびケーブルの故障対策には、サーバがネットワークに接続するケーブルを二重化し、それぞれを異なるネットワークスイッチに接続すれば、ネットワークスイッチの障害およびそのメンテナンスに伴う停止にも対応し、可用性向上になります。

冗長化は不可欠ですが、余分にコストがかかることから、過剰な冗長化を避け、コストに配慮しつつ適切な冗長化を行う必要があります。

例えば、AWS(Amazon Web Services)などのメガクラウドで多数のサーバを運用する場合、サーバのネットワークケーブルをそれぞれ冗長化するのもひとつの方法ですが、別なやり方もあります。１つのネットワークスイッチに接続される複数のサーバを１セットとして、そのセットを冗長化し、サーバ内コンポーネントの冗長化を省略するといった設計です。

高可用性が求められるシステムは、構成要素にSPOFが生じないよう、適切なレベルで冗長化を行い、全体の可用性が向上するよう配慮します。

• サーバのネットワーク冗長化の例

計画的なダウンタイムも発生しますが、運用管理者は、災害対策トレーニングとして東京のデータセンターを停止して大阪に切り替える、といった訓練も実施するべきです。なぜなら、切り替えには多くの手動の手順が介在するので、定期的な訓練と手順確認が必要だからです。

また、比較的短期間に、ともすればユーザの関知しない間に機能更新が行われるクラウドなどの環境に対しては、スタンバイ切り替えなどが導入当初の目的どおりに動作するか、定期的に確認する機会を持ちましょう。冗長化対策を行っていたものの、切り替えが上手く動作せず、大規模障害につながるケースは多いです。

サーバ復旧の3パターン - データ復元で押さえたい注意点とは?

冗長化を行っていても、システムを稼働していればサーバ停止は起こり得ます。その場合、サーバの復旧作業を行います。復旧作業には次の3つのパターンがあります。

1. 故障／不具合の解消
故障したのがメモリ、CPUであれば交換。パフォーマンス不足によるネットワーク輻輳の場合はネットワーク機器を増強。ハードディスク容量枯渇の場合は不要なファイルを削除してハードディスクの容量を確保。
2. スタンバイ機に切り替える
スタンバイ用のWebサーバを起動してサービスを回復する。災害対策用の遠隔地でサービスを再開する。異なるクラウドベンダーでサービスを再開する。正常稼働時のサーバとスタンバイ機のデータ同期方法をよく確認する。
3. バックアップから復元する
ユーザデータの消失はバックアップからデータを復元して回復する。OSの構成情報等のシステム部分は、利用可能な場合はシステムバックアップから復元して回復する構築手順が整備されていればシステムを再構築して復元も可能。

サーバダウンの原因が機器の故障であれば、サーバメーカーに連絡し故障した機器を交換します。機器の交換には数日掛かる場合があるので、その間は必要に応じて故障サーバ上のサービスをスタンバイ機に切り替えて運用します。

RAID構成のハードディスクの故障など、サーバ内の一部の機器の故障も起こります。その場合、サービス停止という形で故障が検知できないため、機器を冗長化する場合は、その中の一部が故障したことを検知するための監視が必要になります。

機器が故障する、あるいはその他の理由でサーバ上のデータが消失した場合は、必要に応じてデータのバックアップをサーバに復元します。サーバ上のデータは一般に２種類に分けることができます。ファイルサーバ上の利用者が日々の業務などで活用するユーザデータと、OSなどを構成するシステムデータの2種類です。

ユーザデータは通常、バックアップ以外の方法では復元不可能で、日常的にバックアップを取得することが大変重要です。システムデータの復旧は、いわゆるシステムバックアップを定期的に実施し、そこから復元する方法と、システムの初期構築手順などを基に再構築する方法があります。利用するOS、ソフトウェアにシステムバックアップと復元の機能が備わっているか事前に確認し、最適な復旧方法を選択します。

サーバを冗長化するにあたり、アクティブ機とスタンバイ機の間でのデータ同期では困難な問題が起こりがちです。データ同期の方式は、利用する製品や機能によりさまざまで、システムを運用するにあたり、それぞれのデータがどのように同期、バックアップされているかをきちんと把握しておきましょう。

また、障害発生時の迅速な対応のために連絡窓口、連絡網の整備は普段から心掛けておくべきポイントです。サーバ担当者の変更があった場合などには、連絡網を見直すことも忘れないようにしましょう。