クラウド運用管理

AWSの可用性について考える ~AZ構成やAuto Recoveryなどの仕組みを解説~

アベイラビリティゾーン(Availability Zone:以降、AZと略す)構成やインスタンスを自動復旧するAuto Recoveryなど、アマゾン ウェブ サービス(Amazon Web Services:以降、AWSと略す)が提供する可用性の仕組みを解説した記事です。これからシステムをクラウドに移行する方に向けて、さまざまな障害からシステムを守るためのポイントをまとめました。

本記事はこんな方にお勧めします

  • オンプレミスのシステムをAWSに移行しようとしている
  • オンプレミスでは可用性設計をしていたけど、AWSではどのようにすれば良いか分からない
  • そもそもAWSの可用性が良く分からない

止められないシステムのクラウド移行を検討するとき、どのように可用性を担保するかの考慮は非常に重要です。
本記事では、AWSが提供するAZ構成やAuto Recoveryなどの仕組みを解説します。また、より可用性の高いシステムにするための課題とその解決策を提案します。

図1:本記事で説明するクラウドの構成要素

図1:本記事で説明するクラウドの構成要素

1. コンピュートサービスの障害に備える

1.1 インフラストラクチャーの障害

AWSは、全世界33のリージョンにある105のAZで運用されています(2024年2月時点)。各リージョンは、1つの地理的エリアにある複数のAZで構成されています。AZは1つ以上から成るデータセンター群で、各AZ間は互いに数kmから100kmほど離れており、低レイテンシーのネットワークで接続されています。各AZには電力源や冷却システム、物理的セキュリティーが備えられており、アプリケーションを複数AZ上で稼働させることで停電や落雷、竜巻、地震などから保護できます。

図2:アベイラビリティゾーンの概念図

図2:アベイラビリティゾーンの概念図

1.2 仮想サーバーの障害

Amazon Elastic Compute Cloud(Amazon EC2)では、インスタンスと呼ばれるスケーラブルな仮想コンピューティング環境が提供されています。Amazon EC2インスタンスは、任意のリージョンならびにAZを選択して起動することができます。また、プレイスメントグループというオプションを利用すると、グループ内のインスタンスを異なるハードウェアに分散配置できるので、物理サーバー障害時に複数のAmazon EC2インスタンスが同時に影響を受ける確率を軽減できます。
Amazon CloudWatchアラームでは、Amazon EC2をモニタリングし、復旧アクションを追加することで障害時に自動復旧(Auto Recovery)できます。検出できる障害は、ネットワーク接続や電源、物理サーバーといったインフラストラクチャー層で発生するものとなります。Auto Recoveryは、同一AZ内にある他物理サーバーでAmazon EC2インスタンスを再起動することで復旧を試行します。しかし、AZ全体に障害が発生した場合などは復旧できないため、複数AZにAmazon EC2インスタンスの配置を検討する必要があります。また、障害時の書き込みタイミングによってはデータの保証はされないため業務レベルでの復旧ができず、手動によるリカバリーや環境のリストアが必要になる可能性があります。
Auto Recoveryの利用に追加料金は必要ありません。

図3:Auto Recoveryによる復旧イメージ

図3:Auto Recoveryによる復旧イメージ

1.3 仮想ストレージの障害

Amazon EC2がサポートするストレージには、以下のようなものがあります。

ストレージ 特長
Amazon EC2インスタンスストア
  • ブロックレベルの一時ストレージ(揮発性)
  • バッファーやキャッシュなど、一時コンテンツを扱う場合に選択
Amazon Elastic Block Store(Amazon EBS)
  • ブロックレベルのストレージ(不揮発性)
  • データベースなど、更新頻度が高いデータを扱う場合に選択
Amazon Elastic File System(Amazon EFS)
  • ファイルストレージ
  • ビッグデータと分析、コンテンツ管理などを扱う場合に選択
Amazon Simple Storage Service(Amazon S3)
  • オブジェクトストレージ
  • バックアップやデータアーカイブなどを扱う場合に選択

図4:Amazon EC2と各ストレージオプションの関係

図4:Amazon EC2と各ストレージオプションの関係

中でも、データに永続性があってAmazon EC2 インスタンスから最も低いレイテンシーでデータにアクセスできるAmazon EBSは、受発注などの止められないシステムに必要不可欠です。
Amazon EBSでは、ボリュームのデータは、同じAZ内の複数インスタンスにレプリケートされており、1つのコンポーネントに障害が発生してもデータが失われることはありません。ただし、Amazon EBS間でデータをレプリケートすることはできないため、可用性確保のためにAZを跨いでAmazon EC2を配置した場合は、AZ間でデータの共有が可能なAmazon EFSなど、別の仕組みを検討する必要があります。また、Amazon EFSとAmazon EBSでは、レイテンシーの違いを考慮する必要があります。
レプリケートにかかる追加料金はありません。

図5:Amazon EBSの可用性

図5:Amazon EBSの可用性

2. マネージドサービスの障害に備える

AWSではデータベースやバッチ処理など、さまざまなマネージドサービスが提供されています。
例えば、フルマネージドなリレーショナルデータベースであるAmazon Relational Database Service(Amazon RDS)では、可用性とパフォーマンスを向上させるための2つのレプリケーションオプションがあります。
マルチAZ配置では、プライマリーデータベースインスタンスとスタンバイデータベースインスタンスを別のAZに配置し、同期的にレプリケートします。そして、障害時はスタンバイデータベースインスタンスに自動フェイルオーバーします。
Amazon RDSリードレプリカでは、ソースデータベースインスタンスのレプリカを複数作成し、データを非同期的にレプリケートします。アプリケーションは書き込みリクエストをプライマリーデータベースインスタンスに送信し、読み取りリクエストをリードレプリカでロードバランスできます。また、リードレプリカをプライマリーに昇格させることもできるため、ソースデータベースインスタンスとは別のリージョンに配置することで、ディザスタリカバリーを見据えた環境を構築できます。
マルチAZ配置やAmazon RDSリードレプリカの使用には、追加料金が必要です。

図6:可用性とパフォーマンスを向上させるためのレプリケーションオプション

図6:可用性とパフォーマンスを向上させるためのレプリケーションオプション

3. より可用性の高いシステムにするための課題

AWSのコンピュートサービスやマネージドサービスでは、可用性を高める仕組みが提供されています。しかし、データや業務アプリケーションなどの可用性は、ユーザーが責任を持たなければなりません。
このため、以下のような課題について検討する必要があります。

  • データをどのように保護するのか検討が必要です(ディスクを複製する、あるいは手動でリカバリーするなど)。それは、AZが異なると共有ディスクを利用できないため、Auto Recoveryではデータの保証はされず、業務レベルでの復旧ができないことが考えられるためです。
  • 業務アプリケーション、ソフトウェア、OS異常時は、別途これらの異常を検知する方法を検討し、構築する必要があります。それは、Auto Recoveryの監視範囲はインフラストラクチャーのみのため、業務アプリケーション、ソフトウェア、OS異常時は、復旧できないためです。
  • AZ全体に影響のある大規模障害が発生する場合、どのようにして別のAZを使用してリカバリーを実施するのか検討が必要です。それは、Auto Recoveryの仕組みでは、障害発生時には同一のAZの別のサーバーでインスタンスを再起動して復旧を試みるので、AZ全体に影響のある大規模障害が発生すると復旧できないためです。

このような課題を考慮して構築しないと、重要なシステムで業務が止まってしまい、システムの利用者に大きな迷惑をお掛けすることも考えられます。

4. HAクラスタソフトウェアでより可用性の高いシステムを実現

HAクラスタソフトウェアを活用することで、より可用性の高いシステムにすることができます。

  • データが保証されるため、手動のリカバリーや環境のリストア無しに、業務を再開・復旧できる
  • システム全体を監視し、業務アプリケーション、ソフトウェア、OS異常時も復旧できる
  • AZ全体に影響のある大規模障害が発生しても復旧できる

HAクラスタソフトウェアとして、多くのお客様を長年支えてきた実績のあるFujitsu Software PRIMECLUSTER(以降、PRIMECLUSTERと略す)での課題解決方法を紹介します。

  • データの引継ぎ
    PRIMECLUSTERではネットワーク経由でローカルディスクを複製(サーバー間ミラーリング)することで、データを保護します。
  • 業務アプリケーション、ソフトウェア、OS異常
    PRIMECLUSTERでは、すべての階層を監視でき、障害時には待機系サーバーに即時切替えができるため、業務停止時間を最小限に抑えることができます。
  • AZ障害
    PRIMECLUSTERでは、障害時には他のAZの待機系サーバーに即時切替えができるため、業務停止時間を最小限に抑えることができます。

図7:PRIMECLUSTERの構成図

図7:PRIMECLUSTERの構成図

5. まとめ

サービス停止が許容されない重要なシステムは、クラウドのインフラの可用性に加えて、データやアプリケーションの可用性が必要です。システムトータルでの可用性の検討をお勧めします。

インフラの可用性

AWSが提供するAZ構成やAuto Recoveryなどの仕組みを使用できます。

  • AZ構成とは
    AWSのAZは数kmから100kmほど離れており、各AZには物理的セキュリティが備えられており、アプリケーションを複数AZ上で稼働させることで可用性を高めることができます。
  • Auto Recoveryとは
    Auto Recovery とは、Amazon CloudWatchアラームでAmazon EC2をモニタリングし、障害時に自動復旧する機能です。検出できる障害はインフラストラクチャーで発生するもので、同一AZ内にある他物理サーバーでAmazon EC2インスタンスを再起動することで復旧を試行します。

データと業務アプリケーションの可用性

HAクラスタソフトウェアを活用することで、下記が実現できます。

  • データが保証されるため、手動のリカバリーや環境のリストア無しに、業務を再開・復旧できる
  • 業務アプリケーション、ソフトウェア、OS異常時も復旧できる
  • AZ全体に影響のある大規模障害が発生しても復旧できる

データと業務アプリケーションの可用性を高める方法を以下のページで解説します。

解決への次のステップ

  • 備考
    Amazon Web Services、AWS、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3)、Amazon Relational Database Service (Amazon RDS)は、Amazon.com, Inc. またはその関連会社の商標です。
    記載されている会社名、システム名、製品名、サービス名などの固有名詞は一般に各社の登録商標または商標です。
    また、本文および図表中に記載されている会社名、システム名、製品名、サービス名などには必ずしも「TM」、「®」を付記しておりません。

本コンテンツに関するお問い合わせ

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)

0120-933-200

受付時間:9時~12時および13時~17時30分
(土曜日・日曜日・祝日・当社指定の休業日を除く)

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ