[Linux][Windows]クラウド環境で障害対策が必要になるケース

「クラウドでは障害対策は不要」は間違い

• オンプレミスからクラウドにシステムを移行する場合、要件に合わせて障害対策は必要です。ここでは「クラウドの利用形態」と「稼働率」の2つの観点で説明します。

クラウドの利用形態の観点

• 一口に「クラウド」といっても、主に下記の3つの利用形態があり、それぞれクラウド（提供）側とユーザー側の責任範囲が異なります。
  • SaaS（Software as a Service）
    • クラウドにあるソフトウェアをネットワーク経由で使えるようにしているサービス。
    • 利用者が使うアプリケーションまでをサービスプロバイダーが面倒を見てくれるので、ユーザーの方でアプリケーションの障害対策を考える必要はありません。
  • PaaS（Platform as a Service）
    • クラウドにあるプラットフォーム（OSやミドルウェアを含む）を使えるようにしているサービス。
    • 利用者が使うプラットフォームまでをサービスプロバイダーが面倒を見てくれるので、ユーザーの方ではアプリケーションの管理が必要です。
  • IaaS（Infrastructure as a Service）
    • クラウドにあるネットワークやサーバーといったコンピュータリソースを使えるようにしているサービス。（ホスティングに近いイメージ）
    • OSより上位のレイヤ（特にデータベースや基幹系のミドルウェア）については、ユーザーの責任範囲になるので、障害対策が必要になります。
• 実際のオンプレミスからクラウドへの移行案件では、約半数がIaaSへの移行要件です。（当社調べ）
  • 止められないデータベース（Oracle、SQLServer、PostgreSQLなど）や基幹系ミドルウェア（HULFT、JP1、SAPなど）については、しっかりとした障害対策が必要になります。

稼働率の観点

• 各クラウド環境では、SLAとして99.99%の稼働率が掲げられています。稼働率99.99%は、理論上の年間ダウン時間が53分になります。但し、この99.99%がどこに掛かっているのかはチェックが必要です。
• 例えばAWSの場合、稼働率99.99%とされているのは個々のEC2インスタンスではなくて、AZ（Availability Zone）やリージョンを跨いだマルチAZ構成を対象としています。
• 個々のEC2インスタンスの稼働率は、99.95%（理論上の年間ダウン時間が263分）です。
• よって、止められないデータベースや基幹系ミドルウェアであれば、AZを跨いだ構成の検討が必要です。（リージョンを跨ぐ場合は、構成が複雑になり、リージョン間の通信のパフォーマンスやコストが課題になる場合があるので、当社製品ではAZを跨いだ構成を標準としています。）
• 当社製のHAクラスター製品のLifeKeeperは、AZを跨いだ構成を標準構成としており、高い可用性を提供します。