全3970文字
PR

クラウド上では、障害の発生を前提にインフラを構築する必要がある。うまく設計するには、可用性、保守性、回復性という3つの観点が欠かせない。スケールアップやスケールアウトなど各種手法の強み、弱みを解説する。

 今回は、クラウドサービスに障害が発生する前提に立ったうえで、障害に負けないサービスの設計手法を説明します。主に、以下の3つの観点を意識する必要があります。

  • 個別インフラ要素の可用性を高める
  • インフラ構成の保守性を高める
  • サービスの回復性を高める

インフラ要素の可用性を高める

 個別インフラ要素の障害対策で重要なのが可用性の向上です。可用性は、障害が発生してもサービスそのものへの影響を発生しにくくする能力のことで、代表的な指標としては稼働率が知られています。一般的な手法の1つが冗長構成です。その名の通りインフラ要素を冗長に構成し、1つのノードに障害が発生しても、別のノードがあることでインフラ要素全体として障害の影響を最小化することができます。

 AWS(Amazon Web Services)では、AZ(アベイラビリティーゾーン)を複数利用する「マルチAZ構成」が冗長構成として提供されています。AZ同士は物理的に個別のデータセンターにあるため、それらにインフラ要素を分散配置することで可用性を高めています。例えばリレーショナルデータベースサービスの「Amazon RDS」の場合、マルチAZ構成を有効にすると、プライマリーDBインスタンスが生成されると同時に、異なるAZにスタンバイインスタンスが生成されます。アプリによってプライマリーDBのデータが更新されると、レプリケーション機能やミラーリング機能を利用して、データがスタンバイインスタンスへ同期されます。

 前述の通り、それぞれのインスタンスは異なるAZにあるため、物理的に独立したサーバーやストレージを利用しています。プライマリーDBになんらかの障害が発生し、処理提供が困難になった場合には自動でフェールオーバーが発生し、スタンバイインスタンスがプライマリーに昇格します。この処理は1~2分間で完了します。

 ただし、この状態ではアプリとデータベースが異なるAZに配置された状態になっています。異なるAZ間は物理的に距離があるため、データベースへのアクセスに時間がかかります。そのため元のAZでインスタンスが復旧したらフェールバックを行なって、元の構成に戻します。フェールバックにも停止が発生します。

 また、この仕組みを利用してデータベースのメンテナンス(OSバージョンアップなど)や性能変更(スケールアップもしくはスケールダウン)における停止時間を短くすることが可能です。シングルAZ構成の場合、データベースのメンテナンスや性能変更をしようとすると、再起動する必要があるので5~10分間程度の停止が発生します。マルチAZ構成の場合、まずスタンバイインスタンスが再起動され、新たなバージョンのノードになります。その後、フェールオーバーを発生させ、1~2分間の停止でデータベースが利用可能になります。ただし、この状態ではプライマリーDBがセカンダリーのAZに配置されているため、フェールバックさせて元に戻します。

 このようにクラウドサービスが備える高可用性機能を利用することでサービスの停止を最小化できます。

図 RDBMSサービス「Amazon RDS」の例
図 RDBMSサービス「Amazon RDS」の例
マルチAZで可用性を高める
[画像のクリックで拡大表示]