システムにおける冗長化の種類と構成選択 – 冗長化する理由と目的

はじめに

冗長化とは、機器やネットワークなどシステムで障害が発生した場合でも業務継続できるように予備を用意しておくことです。
例えばサーバを2台用意することで、片方が故障しても残りで業務継続することを指します。

システムの可用性を高め、耐障害性に強いシステムを構築するには冗長化は不可欠です。
ただ冗長化と言っても種類があり、用途や目的を正しく選択する必要があります。

ここでは冗長化の目的と種類、構成について解説します。
非機能要件の検討で必ず出てくる要素なので、クライアントへ提案する機会もあると思います。
その際に、しっかり提案理由を説明できるように理解しましょう。

システム障害発生時の対処については、別記事「システム障害発生時に対応する５つの手順」を参考にしてください。

冗長化の目的

障害発生時の業務継続

冗長化の主目的は業務継続があげられます。
システムが利用できないために業務継続ができなかったり、サービス提供ができなくなると大きな損失につながります。
それが基幹システムや、リアルタイムで利用するようなシステムの場合は致命的です。
それでも、システムはモノなので壊れることもあります。

そのため設備が壊れても業務が継続できるように機器を多重化します。
そうすればシステムトラブルが発生しても業務継続できるうえ、機器を修理する時間を確保することもできます。

メンテナンス運用の効率化

サーバやアプリケーションは定期的にメンテナンスします。
プログラムリリースなどで一時的にサーバやアプリケーションを停止させる場合もあります。
計画的にシステム停止してよい場合もありますが、24時間稼働を求められる場合はメンテナンス作業を行うこともできません。
システム停止してもよいが作業できるのが深夜帯しかい場合、リリースのたびにエンジニアや立ち合い要員が徹夜作業になるので、そのような事態も避けたいものです。

そのためシステムを冗長化させて稼働サーバを切り替えて、業務継続とメンテナンス作業を平行して行うことも可能です。

負荷分散

大量データを扱うシステムの場合、サーバ１台では処理できないケースもあります。
その問題を解決するために負荷分散することを目的にサーバを複数台用意することがあります。

例えば数万人がアクセスするＷｅｂサービスの場合、サーバ１台では負荷が高すぎて処理遅延が発生します。
その問題を回避するためにサーバを複数台用意し、１台あたりに処理するリクエスト数を分散させます。
振り分け方法については色々ありますが、ロードバランサで処理するサーバを振り分ける方法が挙げられます。

ちなみに、この構成であればサーバが１台壊れたとしても、稼働している他サーバで処理することで業務継続させることができます。

ＢＣＰ

業務継続できなくなる原因はサーバ故障だけではありません。
災害や大規模停電など、環境的にシステムが使用できなくなる場合もあります。
またはサーバが格納されている建物が火災や震災で利用できなくなる可能性もあります。
そのような事態が発生したときに、機器やデータを完全にロストすると業務というより事業継続ができなくなります。

それでは困るので、他県などの遠隔地やクラウド上にデータ退避したり、サーバを移転できる仕組みを用意することで事業継続させます。
これをBCP（事業継続計画）と言います。

昔は同じ構成のサーバを西日本と東日本で分けて構築することが多かったのですが、当然コストもかかるため限られたシステムだけ対象となっていました。
ところが近年はクラウドや仮想技術が一般化しているので、これらの環境を利用することでBCP導入の敷居は下がっています。

冗長化の種類

サーバ冗長化

サーバを複数台用意することで、ハードウェア故障や負荷分散につなげます。
ここで複数台用意と言っていますが、これは物理サーバだけでなく仮想サーバでも冗長化構成にすることができます。
サーバを複数台用意する場合、稼働サーバを制御するアプリケーションを活用するのが一般的です。

クラスタソフト

複数のサーバを統合・連携せてサーバ稼働やアプリケーションの起動・停止を制御することで業務継続を実現します。
サーバの故障状態を検知した場合、別サーバに機能を起動したり機能を引き継ぐように設定します。

レプリケーション

稼働中のサーバからリアルタイムで他サーバに複製します。
同じ状態に複製されるため、直近で稼働していたデータを引き継ぎながらシステム再開させることができます。

ロードバランサ

Webアプリケーションへのリクエスト負荷を分散させるために、各サーバに設定した方法でリクエストを割り当てます。
また受け側のサーバが故障した場合、そちらにリクエストを投げないように設定することもできます。

上記のサーバを複数台用意する方法とは別に、ＦＴサーバ（無停止型サーバ）という選択肢もあります。
FTサーバはサーバの構成部品（CPUやメモリ）が２重化されており、部品が故障してもサーバ稼働できる仕組みです。
ＦＴサーバは物理サーバ１台で冗長化できるため、サーバを２台購入するよりコストは低いのがメリットです。
ただしサーバ１台であるため、メンテナンスでサーバを止める場合に稼働サーバを切り替える運用は出来ないので注意です。

ネットワーク冗長化

ネットワークで使用しているルータやスイッチ、サーバに取り付けられているNIC（ネットワークインターフェイスカード）の故障で通信障害が発生します。
誤ってLANケーブルが抜かれる事故も考えられます。
このような問題に対処するためネットワーク機器を冗長化します。

ネットワークの冗長化はネットワークのレイヤごとに検討します。

レイヤ１：物理層
NICやLANケーブルなどを物理的に増やして冗長化します。

レイヤ２：データリンク層
NICの設定（チーミング）やスイッチ設定を冗長化します。

レイヤ３：ネットワーク層
ルータなどの中継器を冗長化します。

レイヤ４：トランスポート層／レイヤ７：アプリケーション層
ロードバランサやファイアウォール、リバースプロキシなど。

ストレージ冗長化

データ格納するストレージを冗長化します。
DBのデータファイルや、業務的に記録を保持しなければいけない操作ログなど、重要データがディスク障害でロストしないための対策です。

一般的にはRAID構成のストレージ機器を導入し、ディスク破損時にディスク交換により復旧させます。
RAID構成には複数種類ありますが、ディスクアクセスの速度重視、容量重視、コスト重視などシステム要件によって選択が変わってきます。

電源冗長化

サーバ電源の冗長化です。
サーバの筐体には電源プラグが２つ付いており、どちらか一方が抜けても稼働する仕組みになっています。
片方のコンセントから電源供給が止まっても、残りの方から給電することができます。

UPSやATSの導入で停電に強い構成を検討することも大切ですが、少なくとも挿すコンセントが分電盤まで分かれていることは確認しましょう。
間違っても同じタップにコンセントを挿す、なんてことがないように注意してください。

冗長化構成

アクティブ／スタンバイ

稼働系サーバと待機系サーバの２台を用意します。
通常は稼働系サーバで処理を行いますが、サーバ故障が発生したときに待機系サーバに切り替えて業務継続します。

このアクティブ／スタンバイにも２種類があります。

ホットスタンバイ

待機系のサーバも常に電源が入っている状態です。
稼働系と待機系の両方をクラスタ化しておき、サーバ故障時に稼働系から待機系に自動的に切り替えることができます。

メリット
・システム故障を検知して自動的に切り替わるため、サービス停止時間が短い
・手動で稼働系と待機系を切り替えることができるため、プログラムリリース時に系切り替えを行いながらメンテナンスできる

デメリット
・クラスタ化するため、サーバ構築のコストが高い
・電源を入れっぱなしにするため、電気代がかかる

コールドスタンバイ

待機系のサーバは電源を落としている状態です。
トラブル発生時、まず稼働系の電源を落としてから、待機系の電源を入れて利用するため、切り替えに時間がかかります。
ちなみに待機系の設定は、IPアドレス含めて稼働系と同じです。

メリット
・クラスタ化しないため、ホットスタンバイに比べて構築費用が少ない
・電源が入っていないため、電気代がかからない

デメリット
・電源を入れるところから人手が必要のため、利用できるまで時間がかかる。
・プログラムをリリースする場合、稼働系サーバを停止してから待機系を起動するなど手間と時間がかかる

ホットスタンバイとコールドスタンバイの選択は、停止時間がどれくらい許容されるのかがポイントになります。
停止可能時間やサービス利用時間と、構築・ランニングコストを比較して検討します。

アクティブ／アクティブ

負荷分散することを想定した構成で、全て稼働系サーバです。
サーバ故障時は、故障サーバに割り振らないようにロードバランサを設定することで業務継続することができます。

メリット
・負荷分散を考慮することができる
・サーバ故障しても割り当てから除外することで業務継続できる

デメリット
・ロードバランサなど構築するためコストがかかる
・アプリケーションも複数サーバが同時並行するため排他処理が複雑になる

マスタ／スレーブ

複数サーバを連動して動かす場合、サーバ間の制御を行うマスタサーバと、その指示を受けて稼働するスレーブサーバとします。
もしマスタサーバが故障した場合、他のスレーブサーバが変わりのマスタサーバとなります。
この構成はメリット／デメリットではなく、要件としてサーバ間の制御が必要になる場合に利用されます。