サーバ冗長環境構築
冗長化とは
冗長化とは、システムに何らかの障害が発生した場合に備えて、障害発生後でもシステム全体の機能を維持し続けられるように予備の装置を平常時からバックアップとして配置し運用しておくことです。一瞬の停止も許されないシステムで採用され、冗長化の手法には、サーバの二重化による「サーバの冗長化」、「ストレージの冗長化」、回線経路の二重化による「ネットワークの冗長化」などの複数の手法があります。
冗長化はなぜ必要か？
一般的に、システムの障害には次のようなものがあります。
- ハードウェアの故障
- 基本ソフトウェアの停止・誤作動
- アプリケーションの停止・誤作動
- ネットワークの故障や混雑
- リソースの不足
これらの障害を完全に防止しようと思うと、非常に高価なハードウェアを準備したり、故障や誤作動が発生しないソフトウェアを製作するといった対応が必要となり、膨大なコストがかかってしまいます。また、リソースの不足については、あらかじめ予測することが難しく、必要以上の能力を準備するには高いコストを払う必要があります。こうした問題に対応するために、冗長化という方法が使われています。
冗長化の
メリットとデメリット
メリット
・障害対応が自動的に行える
システムが冗長化されていないと、ソフトウェアのバグ、ハードウェアの故障、災害などでシステムが停止したときに、バックアップからシステムを再構築するにはかなりの時間がかかります。また、夜間や休日に緊急の事案が発生した場合には、対応体制を整えることが困難になります。しかし、冗長化されたシステムでは、障害対応は自動的に行われるため、ダウンタイムが最小化できるとともに、対応コストを大幅に削減することができます。
・負荷を分散することができる
システムに大きな負荷が掛かった時に、冗長化されていないシステムではシステムのリソースを使い切ってしまいサービスを継続できなくなる事態が発生することがあります。しかし、システムが冗長化されている場合には、処理を分散し、サービスを継続することができます。
・メンテナンスしやすい
冗長化されていないシステムでは、セキュリティの問題などでソフトウェアをバージョンアップしたり、ハードウェアの交換が必要になった時には、システムを停止したり、再起動したりする必要があります。その上、冗長化されていないシステムでは、利用者が少ない休日や夜間に作業を行うことが多くなります。しかし、冗長化されていれば、部分的に停止してメンテナンスを行うことができます。
・エンジニアの働き方改革につながる
冗長化されていないシステムでは、システムのメンテナンスを休日や夜間に行わなければならない場合があります。また、障害が発生すると復旧までに多大な労力が必要になります。しかし、システムが冗長化されていれば、夜間や休日に無理に対応する必要がなくなり、緊急の対応が大きく減少します。そのため、エンジニアの働き方改革につながります。
デメリット
冗長化を行なうデメリットは、コストが掛ることです。一般的には倍以上のコストが必要になります。
冗長化と可用性
冗長化を行うことで、システムの可用性が向上します。可用性とは、簡単に言えば、止まらずに動く性能のことをいいます。コンピュータを使ってシステムを作ると、障害などのためにサービスが停止してしまう可能性があり、この停止時間が少ないシステムのことを、可用性が高いシステムといいます。
可用性の指標としては、稼働率を用いることが多いです。稼働率は、次のように計算することができます。
MTBF=稼働時間の合計÷故障回数
MTTR=修理時間の合計÷故障回数
稼働率=MTBF÷（MTBF+MTTR）
この式から分かるように、可用性を高めるには、次のような対処が必要になります。
・システム障害の要因をできるだけ減らし、できるだけ停止しないようにする。
・停止した場合のダウンタイム（修理時間）を最小限にする。
システムの冗長化とは、この2つの目標を達成するために用いられる手法です。
冗長化の仕組みと例
冗長化は、ネットワークやサービスなどの様々なポイントで行われています。以下、代表的な冗長化の仕組みの例をご紹介します。
STP
〜スイッチ経路の自動切替〜
STPは、スイッチなどで構成されるネットワークを冗長化するためのプロトコルです。通常、ネットワーク上に複数の到達経路を作ると、ネットワーク上でパケットがループしてしまいますが、STPでは、経路の重複を自動的に検知して、適切な経路のみを使うようにパケットのループをブロックします。もし、何らかの原因で経路が利用できなくなった場合には、それを検出して経路を切り替えます。
VRRP
〜サービス用のIPアドレスの
切り替え〜
VRRPは、ルーターなどを冗長化する仕組みです。STPが経路を冗長化するのに対して、VRRPはゲートウェイなどのIPアドレスを冗長化すると言い換えることもできます。VRRPに参加する複数の機器（ノード）が協調し、サービスで利用する代表IPアドレスを割り当てるノードを決定します。もし、代表のノードが故障した場合には、自動的に検知し他のノードに切り替えが行われます。
ボンティング
〜NICの多重化〜
ボンディングとは、1台のサーバに複数のNICを搭載し、それらのNICを一つの仮想的なNICとして扱い、障害時の切り替えや負荷分散を行う仕組みのことをいいます。サーバとスイッチやネットワークの間を冗長化するのに利用します。
プロキシ・ロードバランサ
〜サーバの振り分け〜
サービスを提供するサーバを何台か用意し、ロードバランサー（負荷分散装置）を使って処理を振り分けることによってサービスの冗長化を実現する仕組みのことをいいます。
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で管理するソフトウェアなども公開されています。
アプリケーションレベルの冗長化
VMWareのような仮想システムは、障害が発生すると自動的に他のノードに処理をマイグレーション（移動）する機能を持っているものがあります。これも冗長化の機能の一つです。また、一般的にAWSのようなIaaSやPaaSなどのクラウドシステムも冗長性を考えて設計されていることが多いです。
しかし、これらの冗長化は、あくまで仮想ハードウェアレベルでの冗長化です。つまり、アプリケーションの停止までは担保されておらず、担保することも不可能です。そのため、仮想サーバやクラウド上に重要なサービスを配置する場合には、PacemakerやDRBDなどの冗長化を行うソフトウェアを利用して、アプリケーションレベルの冗長化を担保する必要があります。実際に、AWS上でPacemakerを利用して冗長化を行っている事例も多数あります。
