ビジネスを止めないIaaSの冗長化、どんな種類がある？　まずは“サービスの品質目標”を考える

　IaaS障害対策の基本は冗長化――エンジニアはもちろん、企業の経営者でもそのように理解している人は多いだろう。冗長化とは、システムに障害が発生したとしても、予備の装置を用意してシステム全体の機能を維持するための仕組みだ。

　しかし、一口に冗長化と言ってもさまざまな手段がある。そして、いずれの手段をとるかは、エンジニアの判断だけでなく、経営上の背景やリスクを考えた上で決定する必要がある。IaaSがシステムのインフラである以上、経営者も障害対応に必要な情報を理解するべきだ。

　今回は、冗長化の手法とそれぞれのメリット、デメリットについて、さくらインターネットでクラウド事業本部の副本部長を務める大久保修一氏に話を聞いた。

冗長化には規模がある

　冗長化の基本は、同じものを2つ用意することにあり、どの手法でもそれは大きく変わらない。違いは何を2つ用意するかだ。

サーバの冗長化

　最も小規模なのがサーバの冗長化だ。サーバは情報を処理するメインのハードウェアであり、何らかの障害で停止してしまうと、どうしてもダウンタイムが発生する。そのダウンタイムをいかに短くするかが勝負だ。バックアップがなければ、サーバを再起動するまでの間ずっとサービスを止めないといけない。

　対策は簡単だ。別途バックアップ用のサーバを用意して、何かあったときにスイッチすればいい。

　「サーバの冗長化は日常的に発生するハードウェアの故障に対応できます。IaaS障害の大半はこれで対処できる上、技術的な難しさもあまりありません」（大久保氏）

ストレージの冗長化

　データを保存するストレージも、ハードウェアの故障で障害の原因になることがある。しかしこちらはたいていの場合、IaaSを提供する事業者側で冗長化の対応をとるため、ユーザー側でわざわざ冗長化する必要はないという。

　こうしたサーバやストレージの冗長化は、これ以降で紹介する手法ほど技術的にも難しくないのがメリットだが、データセンターそのものがダウンしてしまうと、バックアップも含めてストップしてしまう。「空調の故障でデータセンター内のサーバ全体がダウンした」「データセンターの電源が落ちた」といったトラブルには対応できない。

アベイラビリティゾーンで分ける

　それらの障害に対応したい場合はアベイラビリティゾーン（AZ）のレベルで冗長化を検討することになる。「アベイラビリティゾーン」という言葉の用法はIaaS事業者によって違うが、ここでは「独立した電源を持つデータセンター」とする。サーバを2倍に増やすのは同じだが、それぞれを別のデータセンターに配置する手法だ。

　AZは同じ敷地内に複数ある場合もある。例えば、さくらインターネットの石狩データセンターには3つの建屋があり、それぞれが分かれる形でAZを構成している。それぞれの建屋は独立した電源と空調設備を備えているため、1カ所がダウンしてもサーバが全部停止することはない。

　しかしこれでもまだ不安が残る。AZを2つ使っても、場所がほぼ同じなら自然災害で全てのAZが影響を受ける可能性があるからだ。個別に電源があっても全て一気にダウンすれば当然バックアップにはならない。

リージョンを分ける

　最終手段が、地域を分ける手法だ。東京都と大阪府など地理的に離れた場所にあるAZを使って冗長化する方法で、自然災害にも対応できる。東京リージョンと大阪リージョンが両方ダウンする場合はまずない。

　しかし、この手法にはハードルもある。冗長化の基本は同じものを2つ用意することだが、離れた場所に同じものを用意するのは技術的に難しい。情報を同期するには双方で通信しないといけないが、同期の失敗が障害の原因にもなり得るのだ。

　「CAP（PACELC）定理といって、地理的に離れた2地点で冗長化するとき、一貫性と可用性は両立できないという法則があります」と大久保氏。離れた場所の間の冗長化を図ろうとするとパフォーマンスが落ちるだけでなく、応答性も悪くなる。こうしたメリットとデメリットを考えつつ、冗長化を検討する必要がある。

バックアップ側を動かしておくか止めておくか

　冗長化の手法には規模の他に、バックアップ側の動かし方の軸がある。こちらは大きく分けて「ホットスタンバイ」「コールドスタンバイ」の2種類だ。ホットは実際に稼働している状況、コールドは稼働準備段階にある状況を指す。

　障害が発生したとき、バックアップのマシンにすぐに切り替えられることを「アクティブ・ホットスタンバイ構成」という。逆に、平時は稼働しておらず、障害が起きたときにサブマシンを一から起動しなければならない場合を「アクティブ・コールドスタンバイ構成」という。

　アクティブ・ホットスタンバイ構成は即座に対応できるのがメリットだが、常にハードを稼働状態にさせておく必要があり、通信費などのコストが増加する要因となる。逆にアクティブ・コールドスタンバイ構成では、切り替えに時間がかかるのがデメリットだが、ハードウェア運用のコストは低くなる。

冗長化を考える基準はSLO

　このように、冗長化にはさまざまな手法がある。どの手法をとるか考える際に基準となるのが「SLO」（Service Level Objective）とコストだ。

　「費用対効果を考えつつ、適切なSLOを見定めるのが大事です」（大久保氏）

　SLOとは「サービスの品質目標」という意味。例えば「サービスの稼働率は99.9％を目指す」など、可用性、性能、サポートなどの品質目標を定めたものだ。

　冗長化しなくてもSLOを満たせるなら、新たに冗長化を検討する必要はない。例えば、すでにSLOを満たしているのに、東京大阪間でリージョンを分けて冗長化するのはどう考えてもコストの無駄だ。

　障害が与えるビジネスインパクトと冗長化にかかるコストも考慮して、どの程度の品質を保てばいいのかをエンジニアと経営者が判断しSLOとしてまとめるのが重要になる。

　冗長化を検討する際には、無駄を出さないよう、まず自社のサービスを見直すのが大切だ。

この記事の著者

関連記事

• 

  IaaS障害はどこでどうやって起きるのか？　ユーザー企業が受けるサービスダウン以外の影響とは

• 

  IaaS障害、ユーザー企業はどう対処すればいい？　クラウドベンダーが教える対応法と振り返り

• 

  設定ミス→漏えいの影に潜む“クラウドへの誤解”　いま理解したい「責任共有モデル」

• 

  「クラウドは信頼できない」は本当か？　AWS、Office 365、自治体IaaSの障害を経て、私たちが知っておくべきこと