Amazon Web Services ブログ
vSphere 管理者のための AWS の高可用性とレプリケーションの理解
本記事は 2024 年 7 月 9 日に AWS Cloud Operations Blog で公開された “Understanding AWS High Availability and Replication for vSphere Administrators” を翻訳したものです。
はじめに
vSphere HA は vSphere の基本的かつ頻繁に使用される機能です。いくつかの障害シナリオのいずれかが発生した場合、仮想マシンを再起動します。障害シナリオは、仮想マシンやホストのクラッシュから、応答しないホスト (例えば、ネットワーク分離や停止) まで多岐にわたります。
vSphere High Availability (HA) をパブリッククラウドに移行することは、複雑なプロセスとなる場合があります。一部の概念 (例えば、仮想マシンの自動再起動や 仮想マシン/ホストの健全性監視など) は非常に類似していますが、他の概念 (例えば、アドミッションコントロールなど) はオンプレミス環境とクラウド環境では同じようには適用されません。この記事は、AWS の採用を始めた経験豊富な VMware 管理者の混乱を軽減することを目的としています。ここでは、堅牢な災害復旧計画の基礎となる高可用性とレプリケーションの両方について説明します。
AWS における高可用性
AWS クラウドにおける高可用性を理解するには、AWS のリージョンとアベイラビリティーゾーン (AZ) の概念を理解する必要があります。AWS リージョンは、低レイテンシー、高スループット、高度な冗長ネットワークで接続された物理的に分離され独立した複数のアベイラビリティーゾーンで構成されています。アベイラビリティーゾーンは、1 つ以上の独立したデータセンターで構成され、それぞれが冗長電源、ネットワーク、接続性を備え、別々の施設に収容されています。Amazon Elastic Block Store (Amazon EBS) のような多くの AWS サービスは AZ レベルの可用性を提供し、Amazon Simple Storage Service (Amazon S3) のようなサービスはリージョン全体の可用性を提供します。すべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、Amazon EBS ボリュームをルートとして持ち、追加の Amazon EBS ボリュームを接続することができます。Amazon EC2 インスタンスは、他の形式のストレージ (NFS、CIFS、Amazon S3 バケットなど) も接続できます。Amazon EBS ボリュームはアベイラビリティーゾーン内で耐久性があり、つまりボリュームはアベイラビリティーゾーン内の任意のインスタンスに接続できます。(また、一部の目的では、vSphere の「マルチライター」モードに類似して、同時に複数のインスタンスに接続することもできます。) インスタンスに障害が発生した場合、その Amazon EBS ルートボリュームは起動時に新しいインスタンスに再接続されます。
単一または複数の仮想マシン (インスタンス) の障害が発生した場合、復旧プロセスは非常に似ています。オンプレミスの vSphere 環境であれ、AWS クラウドであれ、同じことが言えます。物理ホストの障害についても同様です。2 つの重要な違いがあります。まず、クラウドでは物理ハードウェアのプロビジョニングが自動的に行われます。次に、いくつかの例外を除いて、AWS サービスはアベイラビリティーゾーン全体で利用可能です。vSAN クラスター (または従来の SAN アレイに基づくデータストア) がデータセンター全体のすべての vSphere ホストにまたがっているような状況を想像してみてください。
パブリッククラウドはオンプレミスのインフラストラクチャとは異なる動作をするため、ステートレスなアプリケーションとステートフルなアプリケーションを区別することが重要です。これは、アプリケーションやサービスの状態によって回復メカニズムが異なるためです。ステートレスなアプリケーションは、ユーザーの過去のインタラクションやセッション状態に関する情報を維持または保存しないアプリケーションです。アプリケーションへの各リクエストは、過去のリクエストやユーザーのコンテキストに関する知識なしに、独立して処理されます。例えば、ロードバランサーの前段にある Apache を実行している VMware 仮想マシンや Amazon EC2 インスタンスのフリートが Web サイトを提供している場合を考えてみましょう。コンピュートインスタンス (仮想マシンであれ Amazon EC2 インスタンスであれ) が何らかの理由でクラッシュした場合、このサービスはステートレスであるため、オンデマンドで再起動できます。ステートレスなアプリケーションの他の例には、RESTful API やサーバーレス関数があります。ステートフルなアプリケーションは、時間の経過とともにユーザーのセッションやインタラクションの状態を維持または「記憶」するアプリケーションです。例としては、Web ブラウザ (cookies、履歴など)、オンラインショッピングカート、電子メールクライアントなどがあります。
ステートフルなアプリケーションの高可用性
まず、ステートフルなケースを考えてみましょう。ステートフルなインスタンスに障害が発生し、簡易自動復旧が有効になっている場合、Amazon EC2 は自動的にインスタンスを再起動します (簡易自動復旧はデフォルトで有効です)。これは vSphere VM に対して、vSphere HA を有効にするのと似ています。より細かい制御を行うには、Amazon CloudWatch アラームを使用して検出と復旧を行うことができます。ここで注目すべきアラームは 2 つあります。1 つ目は「再起動」です。インスタンスがクラッシュすると、ステータスチェックに失敗します。再起動アクションを設定した CloudWatch アラームを構成すると、同じ物理ホスト上でインスタンスが再起動されます。インスタンスのステータスは、コンソール、CLI および PowerShell から確認できます。
2 つ目のアラームは「復旧」で、ホストの障害時にトリガーされます。パブリッククラウドとオンプレミスインフラストラクチャのもう 1 つの重要な違いは、vSphere HA がアドミッションコントロールの対象となることです。障害が発生したインスタンスを再起動する前に、vSphere はクラスター内のいずれかのホストにインスタンスを起動するのに十分なリソースがあるかどうかを判断する必要があります。十分な容量がない場合、インスタンスを起動できません。クラウドでは、容量がオンデマンドであるため、アドミッションコントロールのような概念はサービス自体で実施されます。AWS は、ホストに障害が発生した際に、インスタンスを再起動するのに十分な容量を持つ物理ホストを自動的に決定します。Amazon EC2 サービスは、そのインスタンスのシステムステータスのチェックは失敗させますが、ヘルスチェックは失敗させません。インスタンスがシステムステータスのチェックに失敗した場合、これはインスタンス自体は動作していた可能性がありますが、基盤となるホストに障害が発生したことを示します。インスタンスを再起動するには、復旧アクションを含む CloudWatch アラームを設定します。
図 1 : インスタンスがクラッシュした際にトリガーされる StatusCheckFailed_Instance アラーム；自動再起動後にアラームがクリアされる様子
ステートレスなアプリケーションの高可用性
次にステートレスなアプリケーションの場合について説明しましょう。ステートレスにおいて、AWS で復旧を実装する最も簡単な方法は、Amazon EC2 Auto Scaling グループを使用することです。Auto Scaling グループは、常に特定の数のインスタンスが実行されていることを保証します。負荷が高くなった場合には実行中のインスタンス数を増やし、負荷が減少した場合にはインスタンス数を減らすことができます。基本的な vSphere を置き換えたユースケースでは、Auto Scaling グループの最小、最大、および希望するインスタンス数をすべて 1 に設定できます。これは、Auto Scaling グループが常に 1 つの実行中インスタンスを維持することを意味します。
図 2 : 基本的な 1 台のインスタンスの Auto Scaling グループ
インスタンスに障害が発生した場合、Auto Scaling グループは新しいインスタンスを起動しますが、クラッシュした特定のインスタンスを再起動するわけではありません。Auto Scaling グループは、テンプレートと Amazon Machine Image (AMI) から新しいインスタンスを起動します。従来のオンプレミス仮想化の用語で言えば、AMI は vSphere テンプレートのようなもので、Amazon EBS ボリュームは VMDK に似ています。
Apache を実行してウェブサイトを提供するインスタンスのフリートが、ロードバランサーの背後にある前述の例を考えてみましょう。何らかの理由でインスタンスまたは基盤となるホストがクラッシュした場合、新しいインスタンスに置き換えられます。複数のアベイラビリティーゾーンにまたがる Auto Scaling グループを設定することで、ラックやデータセンターの障害から保護されます。複数のアベイラビリティーゾーンに接続されたサブネットで Auto Scaling グループを構成すると、1 つの AZ のインスタンスに障害が発生した場合、Auto Scaling グループは別のアベイラビリティーゾーンで Amazon EC2 インスタンスを再起動します。インスタンスの前段にロードバランサーがあり、Elastic Load Balancing (ELB) のようなリージョナルサービスである場合、新しいインスタンスは起動してすぐにトラフィックを処理できます。
レプリケーションの概念
私たちは、典型的な「リフト・アンド・シフト」移行のように、vSphere の可用性の概念を Amazon EC2 に直接的に、修正なしで適用することを検討してきました。つまり、オンプレミスの仮想マシンで構成されるワークロードを、クラウドで稼働する同じワークロードを構成する Amazon EC2 インスタンスに 1 対 1 でマッピングするということです。これは、ステートレスなサービスはクラウドでもステートレスのままであり、ステートフルなサービスはステートフルのままであることを意味します。多くのアプリケーションは、簡単な修正によってステートレスにすることができ、それによってスケーラビリティ、パフォーマンス、耐障害性を向上させることができます。アプリケーションをステートレスにする一つの方法は、データベースのようなステートフルなコンポーネントを、可用性の高いクラウドベースのサービスを使用するように変更することです。例えば、Amazon Relational Database Service（Amazon RDS）for MySQL や Amazon DynamoDB のようなフルマネージドのクラウドデータベースを使用することで、データベースの可用性に関する作業を AWS にオフロードすることができます。これには他にもいくつかの利点があります。例えば、あなたのブログが非常に人気になり、コメント数がインスタンスの MySQL の容量を超えた場合、自己管理型 MySQL から Amazon RDS に切り替えることで自動的なスケーラビリティが可能になります。インスタンスのサイズ変更やデータベースのチューニングに時間と労力を費やす代わりに、Amazon RDS の設定を調整するだけで済みます。あるいは、MySQL は問題なく動作しているが Apache が過負荷になっている場合、同様に二つの選択肢があります。より多くの LAMP サーバーを追加して元の MySQL インスタンスに向けることもできますが、これにはより多くのインフラ作業（「差別化されていない重労働」）が必要です。または、データベースと Web サービスの機能を分離して、よりスケーラブルな設計にすることもできます。
次に、異なる AZ またはリージョンへのレプリケーションと復旧について説明します。これはオンプレミスでは vSphere Replication (VR) によって実現されています。vSphere Replication には主に 2 つのユースケースがあります：1 つのデータセンターから別のデータセンターへのローカルレプリケーション、そして異なる地震帯などへの長距離レプリケーションです。RPO と RTO の目標に応じて、レプリケーションに異なる AWS サービスを選択することができます。同期レプリケーション (RPO=0) が目標の場合は、Amazon FSx for NetApp ONTAP を検討してください。RPO が数秒から数分の場合は、AWS Elastic Disaster Recovery を使用します。より緩やかな RPO と RTO 要件の場合、従来のバックアップと復旧が適しています。AWS Backup はスケジューリングやデータ保持ポリシーなどの機能に加え、バックアップの異常検出などの機能も提供します。AWS Backup は Amazon S3に保存され、これは複数のアベイラビリティーゾーンにまたがるリージョナルリソースです。そのため、AWS Backup でバックアップされたリソースは AZ 障害に対して耐性があります。AWS Backup はクロスリージョンレプリケーションで長距離のユースケースもカバーできます。AWS Backup の最小スケジュール時間は 1 時間で、Amazon EBS の増分スナップショットを使用します。これは vSphere の Changed Block Tracking (CBT) に類似しています。AWS Marketplace で入手可能なサードパーティーの ISV 製品も、オンプレミスの vSphere 環境から Amazon Virtual Private Cloud (Amazon VPC) へのフェイルオーバーのためのバックアップと災害復旧機能を提供できます。
図 3 : オンデマンドで AWS Backaup を作成
vSphere Replication での復旧では、vSphere 管理者にとってなじみのある「最近の変更を同期する」と「利用可能な最新のデータを使用する」という 2 つのオプションが提供されます。最初のオプションでは、ソース VM の電源をオフにしてソースとターゲットを同期する必要があります。これはデータセンター間のコールド vMotion と表現できます。AWS でこのパターンを模倣する場合、インスタンスをシャットダウンする必要はありません。ただし、実行中のインスタンスは、稼働し続ける場合、その後の変更が発生する可能性が高いです。クロスリージョンの AWS Backup を設定している場合、最新のバックアップが十分に最近のものであれば使用できます。この場合、ターゲットリージョンで利用可能な最新のバックアップから復元するだけで済みます。これは vSphere の「利用可能な最新のデータを使用する」オプションに相当します。クロスリージョンバックアップを有効にしていない場合は、ボールト内の最新のバックアップを選択し、ターゲットリージョンにコピーすることができます。
図 4 : AWS Backup を異なるリージョンへコピー
オンプレミスのクロスリージョンレプリケーションジョブは、インターネットや VPN の帯域幅、あるいはダークファイバーの高コストによって制約を受けることが多いです。クラウドレプリケーションはインターネットではなく AWS ネットワーク上で実行され、Amazon S3 のレプリケーションには SLA が提供されています。従来、パッシブなディザスタリカバリサイトは非常にコスト効率の悪いアーキテクチャコンポーネントであり、顧客は 2 つの選択肢を迫られていました。1 つは、すべての重要なビジネスアプリケーションをフェイルオーバーするのに十分なアイドル容量を構成し、その費用を支払うことです。もう 1 つは、重要なワークロードの一部をサポートするのに十分な最小限の容量（アイドル状態のもの）に対して支払いを行うことです。AWS をディザスタリカバリサイトとして使用することの経済的利点は、必要な分のアクティブ容量のみを構成し、アイドル状態のリソースに対して支払う必要がないことです。
バックアップおよびリカバリ製品は、通常、データをその製品のネイティブフォーマットで保存します。たとえば、vSphere VM をバックアップすると、VMDK に含まれるデータのコピーが得られます。しかし、VMDK は AWS インフラストラクチャ上でネイティブに起動したり実行したりすることはできません。AWS における vSphere 環境の迅速な復旧のためには、2 つの選択肢があります。1 つは VMware Cloud on AWS に復元すること、もう 1 つは AWS Elastic Disaster Recovery を使用して AWS インスタンスに継続的にレプリケートすることです。RTO (復旧時間目標) の要件がそれほど厳しくない場合は、AWS Backup (またはパートナーのバックアップソリューション) を使用することを検討してください。これらのソリューションは、AWS Import/Export を使用して、オンプレミスの仮想マシンを Amazon EC2 インスタンスに変換します。
まとめ
要約すると、vSphere High Availability と Replication は、パブリッククラウドにおいても類似の機能 (簡易自動復旧、CloudWatch アラーム、Auto Scaling グループ）を持っています。主な違いは、リージョナルサービスからの追加の回復力、自動化の利点、そして「従量課金制」モデルです。AWS に移行した後に仮想マシンを保護する方法がわかった今、試してみることをお勧めします。Auto Scaling グループ、スナップショット、スナップショットレプリケーション、および AWS Backup を使用して、クラウド DR アーキテクチャを先行して進めましょう。
翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文はこちらです。