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

Amazonのようなクラウド業界のモンスターでさえ、ハードウェアの問題を抱えています。 米国東部1データセンターの作業が最近中断されたため、この記事が役立つ場合があります。



AWSで高可用性システムを構築するためのオプション。 停止の克服



フォールトトレランスは、すべてのクラウドシステムの主要な特性の1つです。 毎日、この機能を考慮せずに多くのアプリケーションが設計され、AWSにデプロイされます。 この動作の理由は、フォールトトレラントシステムを適切に設計する方法の技術的な無知から、AWSサービスの一部として完全な高可用性システムを作成するための高コストにまで及びます。 この記事では、プロバイダーの機器の中断を克服し、AWSインフラストラクチャ内でより適切なソリューションを作成するのに役立ついくつかのソリューションを取り上げます。

一般的なインターネットアプリケーションの構造は、DNS、ロードバランサー、Webサーバー、アプリケーションサーバー、データベース、キャッシュのレベルで構成されています。 このスタックを取り上げて、アクセスしやすいシステムを構築する際に考慮しなければならない主なポイントを詳細に検討してみましょう。

• AWSで高可用性システムを構築する
• Webサーバー/アプリケーションサーバーレベルでの高可用性
• 負荷分散/ DNSレベルでの高可用性
• データベースレベルでの高可用性
• AWSアベイラビリティーゾーン間で高可用性システムを構築する
• AWSリージョン間で非常に手頃なシステムを構築する
• 異なるクラウドとホスティングプロバイダーの間でアクセスしやすいシステムを構築する

パート2



Webサーバー/アプリケーションサーバーレベルでの高可用性



コンポーネントを単一障害点（SPOF）から除外するには、EC2仮想サーバーの2つ以上のインスタンスでWebアプリケーションを実行するのが一般的です。 このソリューションは、単一のサーバーを使用するよりも高い耐障害性を可能にします。 アプリケーションサーバーとWebサーバーは、ステータスチェックを使用する場合と使用しない場合の両方で構成できます。 以下は、ヘルスチェックを使用した高可用性システムの最も一般的なアーキテクチャソリューションです。









そのようなシステムを構築する際に注意する重要なポイント：

• 現在のAWSインフラストラクチャはアプリケーションレベルでマルチキャストプロトコルをサポートしていないため、データは通常のユニキャストTCPを使用して同期する必要があります。 たとえば、Javaアプリケーションの場合、JGroups、Terracotta NAM、または同様のソフトウェアを使用して、サーバー間でデータを同期できます。 最も単純な場合、rsyncを使用して一方向の同期を使用できます。より普遍的で信頼性の高いソリューションは、GlusterFSなどのネットワーク分散ファイルシステムを使用することです。
• Memcached EC2、ElastiCache、またはAmazon DynamoDBを使用して、ユーザーデータとセッション情報を保存できます。 信頼性を高めるために、ElastiCacheクラスターをさまざまなAWSアベイラビリティーゾーンにデプロイできます。
• ElasticIPを使用してサーバーを切り替えることは、非常に重要なシステムには推奨されません。このプロセスには最大2分かかることがあるためです。
• ユーザーデータとセッションはデータベースに保存できます。 このメカニズムは注意して使用する必要があり、データベースへの読み取り/書き込み操作中に発生する可能性のある遅延を評価する必要があります。
• ユーザーがダウンロードしたファイルとドキュメントは、NFS、Gluster Storage Pool、Amazon S3などのネットワークファイルシステムに保存する必要があります。
• セッションが単一のリポジトリ、データベース、または他の同様のメカニズムを介して同期されない場合、セッションコミットポリシーはAmazon ELBまたはリバースプロキシレベルで有効にする必要があります。 このアプローチは高可用性を提供しますが、アプリケーションレベルでのフォールトトレランスは提供しません。

負荷分散/ DNSレベルでの高可用性



DNS /ロードバランシングレイヤーは、Webアプリケーションの主要なエントリポイントです。 DNSおよびLBレベルで高度にアクセス可能なシステムを構築せずに、アプリケーションおよびデータベースレベルで複雑なクラスター、重い複製Webファームを構築しても意味がありません。 ロードバランサーが単一障害点である場合、その障害によりシステム全体にアクセスできなくなります。 以下は、ロードバランサレベルで高可用性を提供するための最も一般的なソリューションです。







1）Amazon Elastic Load Balancerを高可用性のロードバランサーとして使用する。 Amazon ELBは、アプリケーションの負荷を複数のEC2サーバーに自動的に分散します。 このサービスにより、アプリケーションの通常のフォールトトレランス以上を実現できます。これにより、着信トラフィックの強度に応じて負荷を分散するリソースを徐々に増やすことができます。 これにより、数千の同時接続にサービスを提供すると同時に、負荷を増やしながら柔軟に拡張できます。 ELBは本質的に、作業中の障害を個別に修正できるフェールセーフユニットです。 負荷が増加すると、追加のELB EC2仮想マシンがELBレベルで自動的に追加されます。 これにより、一部のELB EC2仮想マシンに障害が発生した場合でも、単一障害点の存在が自動的に排除され、ロードバランシングメカニズム全体が引き続き機能します。 また、Amazon ELBは、負荷を分散するために必要なサービスの可用性を自動的に判断し、問題が発生した場合は、利用可能なサーバーにリクエストを自動的に送信します。 Amazon ELBは、サービスのステータスを確認せずにラウンドロビンのランダム分散を使用するロードバランシングと、セッションの保護とステータスを確認するメカニズムの両方を使用するように設定できます。 セッション同期が実装されていない場合、セッション固定を使用しても、サーバーの1つに障害が発生し、ユーザーが使用可能なサーバーにリダイレクトされたときにアプリケーションエラーが発生することはありません。



2）アプリケーションには以下が必要になる場合があります。

-キャッシュ機能を備えた複雑な負荷分散（ワニス）

-負荷分散アルゴリズムの使用：

-最小接続-アクティブな接続が少ないサーバーはより多くのリクエストを受信します

-より少ないアクティブ接続とより多くの電力を持つ加重最小接続サーバーとの最小接続は、より多くの要求を受け取ります

-ソース別の配布（宛先ハッシュスケジューリング）

-受信者による配布（ソースハッシュスケジューリング）

-場所と最小接続に基づく配信（ローカリティベースの最小接続スケジューリング）-受信者のIPアドレスを考慮に入れて、アクティブな接続が少ないサーバーがより多くの要求を受信します。

-負荷の大きな短期バーストでの動作を保証する

-ロードバランサーでの固定IPアドレスの存在



上記のすべてのケースで、Amazom ELBの使用は適切ではありません。 Nginx、Zeus、HAproxy、Varnishなどのサードパーティバランサーまたはリバースプロキシを使用することをお勧めします。 ただし、単一障害点が存在しないようにする必要があります。この問題の最も簡単な解決策は、複数のバランサーを使用することです。 Zeusリバースプロキシには、クラスターで動作する機能が既に組み込まれています。他のサービスでは、ラウンドロビンDNSラウンドロビン分散を使用する必要があります。 このメカニズムをさらに詳しく見てみましょうが、最初に信頼性の高いAWSロードバランシングシステムを構築する際に考慮すべきいくつかの重要なポイントを定義します。

• いくつかのNginxまたはHAproxyサービスは、AWSで高可用性を提供するように構成できます;これらのサービスは、サービスの可用性を判断し、利用可能なサーバー間でリクエストを分散できます
• NginxまたはHAproxyは、アプリケーションが状態の可用性チェックをサポートしていない場合に、負荷を周期的に分散するように構成できます。 また、これらのサービスはセッション固定メカニズムを使用した作業をサポートしますが、セッション同期が適切に保証されない場合、1つのサーバーに障害が発生したときにアプリケーションレベルでエラーがないことを保証しません。
• 垂直スケーリングのロードバランサーの水平スケーリング。 水平スケーリングは、バランシング機能を実行する個々のマシンの数を増やし、単一障害点の存在を排除します。 NginxやHAproxyなどのロードバランサーをスケーリングするには、独自のスクリプトとシステムイメージを開発する必要があります;この場合、スケーリングにAmazon AutoScalingを使用することはお勧めしません。
• バランサーサーバーの可用性を判断するには、Amazon CloudWatchモニタリングシステムまたはNagios、Zabbix、Icingaなどのサードパーティのモニタリングサービスを使用できます。EC2制御用のスクリプトおよびコマンドラインユーティリティを使用してサーバーの1つが利用できない場合は、数分以内にバランサーの新しいサーバーインスタンスを起動します。

次に、バランサーの上にあるレベル-DNSについて説明します。 Amazon Route 53は、可用性が高く、信頼性が高く、スケーラブルなDNSサービスです。 このサービスは、AWSインフラストラクチャの外部だけでなく、EC2、S3、ELBなどのすべてのAmazonサービスにユーザーリクエストを効果的に配信できます。 Route 53は基本的にフェールセーフDNS管理サーバーであり、コマンドラインインターフェイスまたはWebコンソールを使用して構成できます。 このサービスは、負荷の周期的分散と重み分散の両方をサポートし、バランサーに含まれる個々のEC2サーバーとAmazon ELBの間でリクエストを分散できます。 循環配布を使用する場合、サービスの可用性と使用可能なサーバーへの要求の切り替えのチェックは機能せず、アプリケーションレベルに移行する必要があります。



データベースレベルでの高可用性



データはあらゆるアプリケーションの最も価値のある部分であり、データベースレベルでの高可用性の設計は、アクセス性の高いシステムにおける最優先事項です。 データベースレベルで単一障害点をなくすには、複数のデータベースサーバーを使用して、それらの間でデータを複製するのが一般的です。 これは、クラスターを使用することも、マスタースレーブを使用することもできます。 AWSのフレームワークでこの問題に対する最も一般的なソリューションを見てみましょう。







1）マスタースレーブレプリケーションを使用します。

1つのEC2サーバーをプライマリ（マスター）として使用し、1つ以上をセカンダリサーバー（スレーブ）として使用できます。 これらのサーバーがパブリッククラウドにある場合、ElastcIPを使用する必要がありますが、プライベートクラウド（VPC）を使用する場合、サーバー間のアクセスはプライベートIPアドレスを介して実行できます。 このサーバーモードでは、データベースは非同期レプリケーションを使用できます。 メインデータベースサーバーに障害が発生した場合、独自のスクリプトを使用してセカンダリサーバーをマスターモードに切り替えて、高可用性を確保できます。 Active-to-ActiveモードまたはActive-to-Passiveモードでサーバー間のレプリケーションを開始できます。 前者の場合、書き込み操作、中間書き込みおよび読み取り操作はプライマリサーバーで実行し、読み取り操作はセカンダリサーバーで実行する必要があります。 2番目の場合、すべての読み取りおよび書き込み操作はプライマリサーバーでのみ実行し、セカンダリサーバーがマスターモードに切り替わった後にプライマリサーバーが使用できない場合にのみセカンダリサーバーで実行する必要があります。 ディスクレベルでの信頼性と安定性を確保するために、EC2データベースサーバーにEBSイメージを使用することをお勧めします。 パフォーマンスとデータの整合性を高めるために、AWS内のさまざまなRAIDオプションでEC2データベースサーバーを設定できます。



2）MySQL NDBCluster

データを保存するための2つ以上のMySQL EC2サーバーをSQLDおよびデータノードとして構成し、1つのMySQLサーバーを管理してクラスターを作成できます。 クラスター内のすべてのデータノードは、非同期レプリケーションを使用して、互いにデータを同期できます。 読み取りおよび書き込み操作は、すべてのデータストレージノード間で同時に分散できます。 クラスター内のストレージノードの1つに障害が発生すると、もう1つがアクティブになり、すべての着信要求を処理します。 パブリッククラウドを使用する場合、クラスター内の各サーバーにElasticIPアドレスが必要です;プライベートクラウドを使用する場合、内部IPアドレスを使用できます。 ディスクレベルでの信頼性と安定性を確保するために、EC2データベースサーバーにEBSイメージを使用することをお勧めします。 パフォーマンスとデータの整合性を高めるために、AWS内のさまざまなRAIDオプションでEC2データベースサーバーを設定できます。



3）RDSでのアベイラビリティーゾーンの使用

データベースレベルでAmazon RDS MySQLを使用する場合、1つの可用性ゾーンに1つのマスターサーバーを作成し、別の可用性ゾーンに1つのホットスタンバイサーバーを作成できます。 さらに、複数のアクセスゾーンに複数のセカンダリリードレプリカサーバーをモデムで接続します。 プライマリおよびセカンダリRDSノードは、それらの間で同期データ複製を使用でき、リードレプリカサーバーは非同期複製を使用します。 マスターRDSサーバーが使用できない場合、ホットスタンバイは数分以内に同じアドレスで自動的に使用可能になります。 すべての書き込み、中間読み取り、および書き込み操作はマスターサーバーで実行する必要があり、読み取り操作はリードレプリカサーバーで実行できます。 すべてのRDSサービスはEBSイメージを使用します。 また、RDSサービスは自動バックアップを提供し、それを使用して特定のポイントからデータを復元でき、RDSはプライベートクラウドで動作できます。



残りの項目については、第2部で説明します。

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

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

投稿者：Harish Ganesan