冗長化とは

冗長化とは、システムに何らかの障害が発生した場合に備えて、障害発生後でもシステム全体の機能を維持し続けられるように予備の装置を平常時からバックアップとして配置し運用しておくことである。一瞬の停止も許されないシステムで採用され、冗長化の手法には、サーバの二重化による「サーバの冗長化」、「ストレージの冗長化」、回線経路の二重化による「ネットワークの冗長化」などの複数の手法がある。

冗長化はなぜ必要か？

一般的に、システムの障害には次のようなものがある。

• ハードウェアの故障
• 基本ソフトウェアの停止・誤作動
• アプリケーションの停止・誤作動
• ネットワークの故障や混雑
• リソースの不足

これらの障害を完全に防止しようと思うと、非常に高価なハードウェアを準備したり、故障や誤作動が発生しないソフトウェアを製作するといった対応が必要となり、膨大なコストがかかってしまう。また、リソースの不足については、あらかじめ予測することが難しく、必要以上の能力を準備するには高いコストを払う必要がある。こうした問題に対応するために、冗長化という方法が使われる。

冗長化のメリット

冗長化することには、様々なメリットがある。

• 障害対応が自動的に行える

  システムが冗長化されていないと、ソフトウェアのバグ、ハードウェアの故障、災害などでシステムが停止したときに、バックアップからシステムを再構築するにはかなりの時間がかかる。また、夜間や休日に緊急の事案が発生した場合には、対応体制を整えることが難しい。しかし、冗長化されたシステムでは、障害対応は自動的に行われる。ダウンタイムが最小化できるとともに、対応コストは大幅に低下する。

• 負荷を分散することができる

  システムに大きな負荷が掛かった時に、冗長化されていないシステムではシステムのリソースを使い切ってしまいサービスを継続できなくなる事態が発生することがある。しかし、システムが冗長化されている場合には、処理を分散し、サービスを継続することができる。

• メンテナンスしやすい

  冗長化されていないシステムでは、セキュリティの問題などでソフトウェアをバージョンアップしたり、ハードウェアの交換が必要になった時には、システムを停止したり、再起動したりする必要がある。冗長化されていないシステムでは、利用者が少ない休日や夜間に作業を行うことが多くなる。しかし、冗長化されていれば、部分的に停止してメンテナンスを行うことができる。

• エンジニアの働き方改革につながる

  冗長化されていないシステムでは、システムのメンテナンスを休日や夜間に行わなければならい場合がある。また、障害が発生すると復旧までに多大な労力が必要になる。やはり休日や夜間に行わなければならなくなる可能性が高い。しかし、システムが冗長化されていれば、夜間や休日に無理に対応する必要がなくなり、緊急の対応が大きく減少する。そのため、エンジニアの働き方改革につながる。

冗長化のデメリット

冗長化を行なうデメリットは、なんといってもコストが掛ることである。一般的には倍以上のコストが必要になる。

冗長化と可用性

冗長化を行うことで、システムの可用性が向上する。可用性とは、簡単に言えば、止まらずに動く性能のことである。コンピュータを使ってシステムを作ると、障害などのためにサービスが停止してしまう可能性がある。この停止時間が少ないシステムのことを、可用性が高いシステムという。

可用性の指標としては、稼働率を用いることが多い。稼働率は、次のように計算することができる。

この式からも分かるように、可用性を高めるには、次のような対処が必要である。

• システム障害の要因をできるだけ減らし、できるだけ停止しないようにする
• 停止した場合のダウンタイム（修理時間）を最小限にする

システムの冗長化は、この2つの目標を達成するために用いられる手法である。

• 高可用性とクラスタ

冗長化の仕組みの例

冗長化は、ネットワークやサービスなどの様々なポイントで行われる。以下は、代表的な冗長化の仕組みの例である。

STP 〜スイッチ経路の自動切替〜

STPは、スイッチなどで構成されるネットワークを冗長化するためのプロトコルである。通常、ネットワーク上に複数の到達経路を作ると、ネットワーク上でパケットがループしてしまう。STPでは、経路の重複を自動的に検知して、適切な経路のみを使うようにパケットのループをブロックする。もし、何らかの原因で経路が利用できなくなった場合には、それを検出して経路を切り替える。

VRRP 〜サービス用のIPアドレスの切り替え〜

VRRPは、ルーターなどを冗長化する仕組みである。STPが経路を冗長化するのに対して、VRRPはゲートウェイなどのIPアドレスを冗長化すると言い換えることもできる。VRRPに参加する複数の機器（ノード）が協調し、サービスで利用する代表IPアドレスを割り当てるノードを決定する。もし、代表のノードが故障した場合には、自動的に検知し他のノードに切り替えが行われる。

ボンティング 〜NICの多重化〜

ボンディングとは、1台のサーバに複数のNICを搭載し、それらのNICを一つの仮想的なNICとして扱い、障害時の切り替えや負荷分散を行う仕組みである。サーバとスイッチやネットワークの間を冗長化するのに利用する。

プロキシ・ロードバランサ 〜サーバの振り分け〜

サービスを提供するサーバを何台か用意し、ロードバランサー（負荷分散装置）を使って処理を振り分けることによってサービスの冗長化を実現する仕組みである。

「OSSのプロキシ/ロードバランサのソフトウェア比較18選」へ

QoS 〜サービス品質の確保〜

QoSとは、パケットの種類を判別して遅延やパケットロスが許されないものを優先的に処理することで、ネットワークの混雑を回避する仕組みである。

RAID 〜ハードディスクの冗長化〜

RAIDとは、複数のハードディスクをまとめて一台の装置として管理することで、ハードディスクの耐障害性を高める仕組みである。

RAID 0, RAID 1, RAID 5, RAID 6などが使われているが、冗長化できるのはRAID 1（ミラーリング）、RAID 5（ミラーリング＋ストライピング）、RAID 6（ミラーリング＋ストライピング＋予備ディスク）である。RAID 0は、性能改善のためだけに使われる。

アプリケーションレベルの冗長化

これらの方法は、ネットワークや機器のトラブルに対応するためのものである。一方で、OS上で動作するアプリケーションが停止してしまう場合も想定され、アプリケーションレベルでの冗長化も考慮する必要がある。アプリケーションレベルで対策を行うためには、専用のソフトウェアが必要である。代表的なソフトウェアとしては、次のようなソフトウェアが知られている。

Heartbeat 〜アプリケーションレベルの対策〜

Heartbeatとは、クラスタリングを実現するためのソフトウェアである。クラスタリングは、複数台のシステムを組み合わせて1つのシステムに見せることで、システムの一部の機能に障害が発生しても機能が停止しないようにする仕組みである。メールサーバやWebサーバ、データベースサーバなど、様々なサービスの冗長化に利用できる。

Pacemaker 〜アプリケーションレベルの対策〜

Pacemakerとは、Heartbeatの後継バージョンであり、Heartbeatからリソース制御の機能を独立させたものである。Heartbeatから独立することにより、Pacemakerは対応するサービスが増え、「crmシェル」の実装により簡単に動作するようになった。

DRBD 〜データの同期〜

DRBDとは、HAクラスタを構築するために設計されたブロックデバイスシステムで、ネットワークを介して2台のサーバのハードディスクをミラーリングすることができるソフトウェアである。専用のディスクやインタフェースを必要とせず、Heartbeatと連携する事で、データベース、nfs、sambaなどのHAクラスタを安価（共有ストレージ無し）に実現する事が可能である。

Keepalived 〜IPアドレスの切り替え〜

Keepalivedとは、VRRPを実装するソフトウェアである。LinuxのLVSという機能を利用してロードバランサー（負荷分散装置）として動作させることもできる。また、それをGUIで管理するソフトウェアなども公開されている。

冗長化の方法や構築の事例

冗長化の対象になるのは、重要で停止することができないシステムである。例えば、航空管制のシステムや銀行のオンラインシステムなど、重要なシステムではサーバだけでなく、ネットワーク回線、ネットワーク機器など、関係しているすべての要素を冗長化しようとする。

近年は、インターネットのシステムでの冗長化を行う場合が多くなっている。ここでは、その例について解説する。

WEB-DBサーバの冗長化の方法

メールサーバの冗長化の方法

構築事例：DHCPサーバ冗長化（IPv6対応）

構築事例：OpenLDAPによるLDAPサーバのマルチマスタ構成

データーベースサーバ（MySQL）

「MariaDB MaxScale〜OSSのデータベース向け負荷分散ソフトウェア〜」へ

データーベースサーバ（Postgres）

監視サーバ

DNSサーバ

NFSサーバ

ファイルサーバ

仮想サーバやクラウド上のシステムの冗長化

VMWareのような仮想システムは、障害が発生すると自動的に他のノードに処理をマイグレーション（移動）する機能を持っているものがある。これも冗長化の機能の一つである。また、一般的にAWSのようなIaaSやPaaSなどのクラウドシステムも冗長性を考えて設計されていることが多い。

しかし、これらの冗長化は、あくまで仮想ハードウェアレベルでの冗長化である。つまり、アプリケーションの停止までは担保されていないし、担保することも不可能である。そのため、仮想サーバやクラウド上に重要なサービスを配置する場合には、PacemakerやDRBDなどの冗長化を行うソフトウェアを利用して、アプリケーションレベルの冗長化を担保する必要がある。実際に、AWS上でPacemakerを利用して冗長化を行っている事例も多い。

デージーネットの冗長化の軌跡

デージーネットは創業以来、15年以上に渡ってシステムの冗長化に取り組んできた。特に、クラスタサーバの構築では、数多くの実績を持っている。

デージーネットでは、2005年までは、UnixWare Reliant HAなどの商用製品を利用してクラスタサーバを構築してきた。しかし、こうした製品は非常に高コストで、インターネットサーバの構築には見合わなかった。しかし、2005年にオープンソースソフトウェアのHeartbeatとDRBDを使った冗長化に成功し、国内では他社に先駆けて、OSSを使ったクラスタサーバ構築サービスの提供を開始した。その後、RedHat Cluster、Pacemaker、corosyncなどのクラスタソフトウェアでもサービスを開始し、用途や予算に応じて、様々な冗長構成を提案することができる体制を築いている。現在では、年間100セット以上のクラスタサーバを構築している。また、「クラスタ.jp」というクラスタの情報を集めたサイトを運営している。