AWSで高可用性システムを構築するためのオプション。 仕事の中断を克服する。 パート2

このパートでは、AWSに基づいた高可用性システムを構築するための次のオプションを検討します。

• AWSアベイラビリティーゾーン間で高可用性システムを構築する
• AWSリージョン間で非常に手頃なシステムを構築する
• 異なるクラウドとホスティングプロバイダーの間でアクセスしやすいシステムを構築する

最初の部分はこちらです。



AWSアベイラビリティーゾーン間で高可用性システムを構築する

Amazonアクセスゾーンは、同じリージョン内の独立した独立したデータセンターです。 アベイラビリティーゾーンは相互に安定したネットワーク接続を持っていますが、あるゾーンの問題が他のゾーンの可用性に影響を与えないように設計されています（独立した電源、冷却、セキュリティシステムがあります）。 以下の図は、リージョン（青で示されている）内のアクセシビリティゾーン（紫で示されている）の既存の分布を示しています。





Amazon Simple Storage Service（S3）、Amazon SimpleDB、Amazon Simple Queue Service（SQS）、Amazon Elastic Load Balancing（ELB）などのほとんどの高レベルAmazonサービスには、フォールトトレランスと高可用性を提供するためのメカニズムが組み込まれています。 Amazon Simple Storage Service（S3）、Amazon SimpleDB、Amazon Simple Queue Service（SQS）、Amazon Elastic Load Balancing（ELB）などのコアインフラストラクチャサービスは、Elastic IP、イメージスナップショット、可用性ゾーンなどの機能を提供します。 これらの機能を使用し、正しく使用するには、各フォールトトレラントでアクセスしやすいシステムが必要です。 システムの信頼性と手頃な価格を実現するには、AWSクラウドに展開するだけでは不十分です。アプリケーションが複数の可用性ゾーンで動作するように設計する必要があります。 アベイラビリティーゾーンは異なる地理的領域にあるため、複数のゾーンを使用すると、特定の領域の問題からアプリケーションを保護できます。 次の図は、複数のアベイラビリティーゾーンを使用して設計する必要があるさまざまなレベル（ソフトウェアの例を含む）を示しています。



1つのゾーンが動作不能である場合、アプリケーションが別のゾーンで障害やデータ損失なしに動作し続けるためには、異なるゾーン（同じリージョン内と異なるリージョンの両方）で互いに独立したアプリケーションソフトウェアスタックを持つことが重要です。 システム設計の段階で、アプリケーションのどの部分がゾーンに関連付けられているかをよく理解する必要があります。

例：

典型的なWebアプリケーションは、DNS、ロードバランサー、Webサーバー、アプリケーションサーバー、キャッシュ、データベースなどのレベルで構成されています。 以下に説明するように、これらのレベルはすべて、2つ以上のアクセスゾーンに分散して展開できます。



また、ほとんどのAWS組み込みユニットは、最初はマルチゾーンの可用性をサポートするように設計されています。 アプリケーションの設計段階でAWSユニットを使用するアーキテクトと開発者は、組み込み機能を使用して高可用性を実現できます。



AWS Embedded Unitsを使用した高可用性システムの設計：

• オブジェクトおよびファイルストレージ用のAmazon S3
• コンテンツ配信システム用のAmazon CloudFront
• 負荷分散のためのAmazon ELB
• EC2を自動的にスケーリングするAmazon AutoScaling
• モニタリング用のAmazon CloudWatch
• メッセージングサービス用のAmazon SNSおよびSQS

これらのブロックは、Webサービスとして使用できます。 これらのブロックは、最初は可用性が高く、信頼性が高く、スケーラブルです。 組み込みの互換性と、複数のアクセスゾーンで動作する機能を備えています。 たとえば、S3は、年間99.999999999％の安全性と99.99％のオブジェクトの可用性を提供するように設計されています。 これらのブロックは、単純な呼び出しを使用してAPIを介して操作できます。 それらにはすべて独自の長所と短所があり、システムを構築および運用する際にそれらを考慮する必要があります。 これらのブロックを適切に使用することで、複雑なインフラストラクチャの開発と作成のコストを劇的に削減でき、インフラストラクチャの作成と保守ではなく、製品に集中できます。



AWSリージョン間で非常に手頃なシステムを構築する

現在、世界中に7つのAWSリージョンがあり、そのインフラストラクチャは毎日成長しています。 次の図は、現在の地域インフラストラクチャを示しています。



複数のリージョンでAWSを使用することは、コールド、ウォーム、ホットスタンバイ、ホットアクティブのカテゴリに分類できます。

ColdとWarmは災害復旧に関心があり、Hot StanbyとHot Activeは異なる地域間でアクセスしやすいシステムを設計するために検討できます。 異なる地域間でアクセスしやすいシステムを設計する場合、次の問題を考慮する必要があります。

• アプリケーションの移行-AWSリージョン間でアプリケーション環境を移行する機能
• データ同期-2つ以上のリージョン間でリアルタイムデータを移行する機能
• ネットワークトラフィック-リージョン間のネットワークトラフィックのフローを制御する機能

次の図は、複数の地域にまたがるシンプルでアクセスしやすいシステムを示しています。



次に、これらの問題を解決する方法を検討します。

アプリケーションの移行。 S3とEBSの両方のAMIイメージは1つのリージョン内でのみ使用できるため、使用する予定のすべてのリージョンで必要な同一のイメージをすべて作成する必要があります。 アプリケーションコードを更新するたびに、関連する更新と変更をすべてのイメージのすべての領域で行う必要があります。 これには自動化スクリプトを使用できますが、PuppetやChefなどの自動構成システムを使用することをお勧めします。これにより、アプリケーションの展開コストを削減および簡素化できます。 AMIイメージに加えて、Amazon Elastic IPなどのサービスがあり、これも同じリージョン内でのみ機能することに注意してください。

データの移行。 各複雑なシステムには、リレーショナルデータベース、非リレーショナルデータベース、キャッシュ、ファイルストレージなど、異なるデータソース間で分散されたデータが含まれています。 以下は、複数の地域で作業する場合に使用することが推奨される技術の一部です。

• データベース：MySQLマスタースレーブレプリケーション、SQL Server 2012 HADR、SQL Server 2008、Programmatic RDS
• ファイルストレージ：GlusterFS分散ネットワークファイルシステム、S3レプリケーション
• キャッシュ：ほとんどの場合、リージョン間のキャッシュの複製は高価なので、各リージョンに個別の加熱キャッシュを保持することをお勧めします。
• 高速ファイル転送には、Asperaなどのサービスをお勧めします。

上記のテクノロジーはすべて非同期レプリケーションであるため、データの損失に注意し、RPO（有効な復旧ポイント）とRTO（有効な復旧時間）の値を忘れずに高可用性を確保する必要があります。

ネットワークストリーム：異なる地域間でネットワークトラフィックフローを提供する機能。 ネットワークストリームを操作する際に考慮する必要があるキーポイントを考慮してください。

• 現在、組み込みのELBロードバランサーはリージョン間のロードバランシングをサポートしていないため、リージョン間のトラフィックの分散には適していません。
• この目的には、リバースプロキシとロードバランサー（HAProxy、Nginxなど）が適しています。 ただし、地域全体が利用できない場合、負荷を分散するサーバーが利用できないか、他の地域にあるサーバーが表示されない可能性があり、アプリケーションエラーが発生する可能性があります。
• 一般的な方法は、DNSレベルで配布管理を使用することです。 UltraDNS、Akamai、Route53 LBRなどのサービスの使用（ルーティング
• 応答時間に基づいて）地域間でトラフィックを再分配できます
• Amazon Route53 LBRを使用すると、異なるリージョン間でトラフィックを切り替えて、より短い応答時間でユーザーリクエストをリージョンにリダイレクトできます。 route53のエンドポイントとして、サーバーのパブリックIPアドレス、Elastic IP、ELB IPを使用できます。
• Amazon Elastic IPは異なるリージョン間で切り替えることはできません。 このようなサービス、FTP、およびアプリケーション間の通信を目的としたその他のIP指向のサービスは、IPアドレスの代わりにドメイン名を使用するように再構成する必要があります。 これは、複数の領域を使用するときに考慮しなければならない重要なポイントです

異なるクラウドとホスティングプロバイダーの間でアクセスしやすいシステムを構築する



多くの人は、複数のクラウドプロバイダーとホスティングプロバイダーを使用して、アクセスしやすいシステムを構築することについて話します。 企業が人工物の点で複雑なこれらのシステムを使用する理由は、次のとおりです。

• 自分のデータセンターの構築やプロバイダーのデータセンターでの物理機器のリースに既に多くのお金を投資している大企業は、メインデータセンターに問題が発生した場合に災害復旧にAWSを使用したいと考えています。 すでにユーカリ、オープンスタック、クラウドスタック、またはvCloudに基づいた独自のプライベートクラウドを独自のデータセンターにインストールしており、災害復旧にAWSを使用したい企業。 Eucalyptusには、APIレベルの互換性があるため、AWSとの互換性が最大になります。 ほとんどのワークロードは、AWSとEucalyptusの間​​で統合できます。 たとえば、エンタープライズにEucalyptusプライベートクラウドのAWS APIを使用するAmazon EC2用の一連の開発済みスクリプトがあるとします。フォールトトレランスが必要な場合、このクラウドは簡単にAWSに移行できます。 会社がOpenStackまたはプライベートクラウドの別のプロバイダーを使用している場合、スクリプトを書き換え、新しい環境で動作できるように適合させる必要があります。 これは、複雑なシステムでは経済的に不利になる可能性があります。
• インフラストラクチャをスケーラビリティや高可用性に適さないと考えている企業は、AWSをプライマリサイトとして使用し、データセンターを災害復旧のセカンダリとして使用できます。
• 現在のパブリッククラウドプロバイダーの安定性と信頼性に満足していない企業は、多くのクラウド構造を使用したい場合があります。 現在、このケースは最もまれですが、将来的に重大になる可能性があります。

いくつかのAWSリージョンのセクションで説明されているソリューションのほとんどは、この場合に適しています。

さまざまなクラウドプロバイダーまたはさまざまなデータセンター間でアクセスしやすいシステムを設計する場合、次のキーポイントを慎重に決定する必要があります。

データ同期。 通常、使用するクラウドプロバイダーごとにデータウェアハウスをインストールして展開できる場合、この手順は大きな問題ではありません。 データベースソフトウェア、データベースを操作するためのツールおよびユーティリティの互換性は、簡単にインストールできる場合、異なるプロバイダー間のデータ同期の問題を解決するのに役立ちます。

ネットワークストリーム。

• アカマイ、Route53、UltraDNSなどのマネージドDNSサービスを使用して、複数のプロバイダーを切り替えることができます。 これらのソリューションはクラウドプロバイダー、リージョン、およびアベイラビリティゾーンから独立しているため、データセンターとプロバイダー間でネットワークトラフィックを切り替えて高可用性を確保するために効果的に使用できます。
• 一部のクラウドプロバイダーは現在、仮想マシンに固定IPを提供できませんが、データセンターまたはホスティングプロバイダーによって固定IPアドレスを提供できます。 これはボトルネックになる可能性がありますが、クラウドプロバイダー間で高可用性を提供します。
• 非常に多くの場合、クラウド間で機密データを移行するには、クラウドプロバイダーであるデータセンター間でVPN接続を確立する必要があります。 一部のクラウドプロバイダーでは、このサービスの構成、実装、およびサポートに問題がある可能性があります。 この点は設計時に考慮する必要があります。

ワークロードの移行：

Amazon AMIイメージは、他のクラウドプロバイダーが利用できない場合があります。 データセンターまたはプロバイダーごとに仮想マシンの新しいイメージを作成する必要があるため、追加の時間と費用が発生する可能性があります。

Amazon APIを使用した複雑な自動化スクリプトは、適切なAPIを使用してクラウドプロバイダーごとに書き換える必要があります。 一部のクラウドプロバイダーは、独自のインフラストラクチャ管理APIも提供していません。 これにより、メンテナンスがより複雑になります。

オペレーティングシステムの種類、ソフトウェア、ハードウェアの互換性、これらすべてを設計で分析し、考慮する必要があります。

RightScaleなどのツールを使用しない場合、異なるプロバイダーを使用する場合、統合インフラストラクチャ管理は大きな問題になる可能性があります。



もとの記事： harish11g.blogspot.in/2012/06/aws-high-availability-outage.html

投稿者：Harish Ganesan