全4589文字
PR

障害対策では、システムの稼働率を適切に見積もる必要がある。機能によって目標とする稼働率は異なるので注意が必要だ。稼働率を設定した上でAWS上にシステムを構成する手法を解説する。

 障害を前提とした設計の第一歩は、必要なサービスレベルを定義することです。クラウドサービスでは、サービスレベルを達成するための考え方がオンプレミス(自社所有)環境と異なる部分があるので注意が必要です。

稼働率を適切に定める

 絶対に停止しないシステムを作ることはできません。ただし、たとえ障害が発生しても、実質的にユーザーに影響を与えないシステムを作ることは可能です。利用者の観点から、システムに対してどこまでの品質が必要なのか。それを定義したのがサービスレベルです。

 サービスレベルの代表的な指標が稼働率です。例えば稼働率99.9%のシステムでは、全稼働時間の99.9%の期間が正常に利用できる、逆に言えば0.1%の期間は利用できない可能性があることを意味します。

 具体的には1カ月間(30.5日)で44分間、1年間(365日)で8時間45分はシステムを利用できない可能性があることを意味します。この利用できない時間帯は連続する時間とは限りませんし、また必ず発生するものでもありません。

 どんなシステムでも「利用したいと思ったタイミングでシステムが利用できない」ことは望ましくはありませんし、実際に利用できない事態に陥れば多少なりとも被害が発生します。そのため、稼働率は100%に近づけるべきだと考えがちです。

 しかし、稼働率を上げるにはシステムの開発コストや維持コストが増大します。そこで、稼働率で設定された停止期間で復旧するのであれば、ビジネス上の致命的な被害は出ない、あるいはリカバリーが可能と考えます。このように稼働率を適切に定めることで、コストの最適化を図ります。

図 稼働率と停止時間の関係
図 稼働率と停止時間の関係
処理に応じて必要な稼働率を見極める
[画像のクリックで拡大表示]

復旧時間を短縮し稼働率を上げる

 目標とする稼働率を達成するために検討すべきなのがシステムの構成です。アプリケーションが機能的に正しく動くことを前提にすると、その機能が利用できなくなる理由として、サーバーやネットワーク機器のようなハードウエアの故障が挙げられます。オンプレミス環境ではハードウエアの故障率を下げるために構成要素を冗長にしたり、故障検知の機能を組み込んでいたりします。

 一方、AWS(Amazon Web Services)やMicrosoft Azureのようなクラウドサービスは、ハードウエアに汎用的な機材を利用しています。そのため、エンタープライズ企業がオンプレミス環境で使っているような機材と比べると、ハードウエアの障害率が高くなっています。

 例えばAWSの仮想マシンサービス「EC2」では、クラスターを組まないシングルAZ(アベイラビリティーゾーン)構成の場合、SLA(Service Level Agreement)として設定されている稼働率は90%にすぎません。

 ただし、クラウドサービスでも冗長構成を用いれば稼働率を高めることができます。EC2であればマルチAZと呼ばれるクラスター構成を取ることが可能です。マルチAZ状態のSLAは99.99%です。