AWS および Azure での高可用性に関する考慮事項

108831

Created On 09/25/18 15:12 PM - Last Modified 06/15/23 22:35 PM

Resolution

お客様が VM シリーズを使用してパブリッククラウド内のビジネスクリティカルなアプリケーションやデータを保護し始めると、「AWS または Azure で高可用性をサポートするか」という質問が発生します。元11月2016のポスト (下) の質問には明らかに答えていない。答えは yes で、エンタープライズアプリケーションの展開に必要な高可用性と復元性を実現する、AWS および Azure 上の VM シリーズを使用してアーキテクチャを展開できます。しかし、悪魔は実装の詳細にあります。

AWS での VM シリーズのアクティブ-パッシブ高可用性

aws では、vm シリーズは、単一の aws アベイラビリティーゾーン内にデプロイされた2つの vm シリーズファイアウォール (アクティブおよびパッシブ) を使用して、アクティブ/パッシブの高可用性をサポートします。障害が発生した場合は、アクティブな vm シリーズのファイアウォールにリンクされている AWS ENI がパッシブ vm シリーズファイアウォールに移動されます。ENI の移動は、通常は60秒を要するが、時には長くなる AWS への API 呼び出しによって行われます。遅延は、AWS ファブリックの機能の副産物であり、VM シリーズによって制御されるわけではありません。その間、一部のセッションが失われることがありますが、状態は維持されます。

この方法でアクティブなパッシブを使用すると、従来の定義で高可用性を実現できます。フェイルオーバーのラグタイムに加えて、このアクティブなパッシブ HA は、ENI の移動が AZs にまたがることを許可しないという AWS の制限により、複数のアベイラビリティーゾーンにまたがることはできません。さらに、VM シリーズの両方のライセンスは、実行中の AWS リソースと同じようにアクティブになるため、経費に関する考慮事項が生じます。

AWS 高可用性ドキュメントの VM シリーズ

AWS での VM シリーズ高可用性 (自動スケーリング & ELB 統合を使用したインバウンド)

データセンターレベルの高可用性を実現する別のアプローチとして、クラウドファブリックを使用して、複数の AZs を展開にまたがることができる HA を構築する方法があります。VM シリーズの自動スケーリングと ELB 統合により、受信トラフィックの最終目標を達成することができます。

AWS の VM シリーズの自動スケーリングは、VPC 内の2つのアベイラビリティーゾーンに複数のファイアウォールを展開します。vm シリーズのファイアウォールのいずれかが失敗すると、次の2つのことが起こります。まず、AWS ロードバランサーは、障害を検出し、残りの正常な VM シリーズファイアウォールへのトラフィックを転換します-これは通常、正常性の設定に応じて数秒で発生します。次に、AWS オートスケーリンググループは、異常なファイアウォールを自動的に削除し、完全に構成され、ライセンスを取得し、トラフィックを処理する準備ができている新しいブートストラップ VM シリーズファイアウォールに置き換えます。

パフォーマンスとコストの感度のバランスに応じて、正常性チェックと自動スケーリンググループは、失敗したコンポーネントの検出と置換について非常に攻撃的または非常に保守的であるように調整できます。これにより、展開を設計する際に、独自のコスト/メリットの決定を下すことができます。VM シリーズは、自動的に拡大/縮小されるだけでなく、複数のアベイラビリティーゾーンにわたって総合的で可用性の高いソリューションを提供する自己修復機能でもあります。

AWS デプロイメントリソースの VM シリーズの自動スケーリング

AWS Lightboard の VM シリーズの自動スケーリング

AWS での VM シリーズ高可用性 (ラムダ関数を使用したマルチ AZ)

もう1つの方法は、複数のアベイラビリティーゾーンにまたがる HA を必要とするお客様向けに、Cloudticity によって作成されたコミュニティサポートラムダベースのソリューションを利用することです。このデプロイメントシナリオでは、ラムダ関数は、各 AZ にデプロイされた VM シリーズの正常性を監視します。各 AZ には、トラフィックを処理するためのアクティブなプライマリファイアウォールがあります。vm シリーズのファイアウォールに障害が発生した場合、別のラムダ関数は別の AZ に配置されたセカンダリ vm シリーズのファイアウォールにトラフィックを再ルーティングします。

ラムダリソースを使用したマルチ AZ HA ソリューション

Azure の高可用性における VM シリーズ

Microsoft azure 展開の vm シリーズでは、以下の azure リソースを使用して複数の vm シリーズインスタンスを使用することで、高可用性が実現されます。

Azure での VM シリーズ高可用性 (アプリケーションゲートウェイとロードバランサーの統合を使用した受信)

azure の VM シリーズ高可用性は、アプリケーションゲートウェイとロードバランサーの統合と組み合わせた azure 可用性セットを使用して実現できます。可用性セットは、さまざまなホスト間でワークロードを分散することによって、Azure インフラストラクチャの保守またはシステム障害がビジネスに与える悪影響を最小限に抑えるか、または排除することによって、高可用性と回復性のニーズに対応します。ロードバランサーのサンドイッチとしてデプロイされたアプリケーションゲートウェイは、外部ロードバランサーのフロントエンドとして機能し、ロードバランサーは内部トラフィックの分散メカニズムとして機能し、web アプリケーションにトラフィックを分散します。

トラフィックは、2つの VM シリーズのファイアウォールに配布され、それぞれ異なる可用性セットに割り当てられます。vm シリーズのファイアウォールに障害が発生した場合、トラフィックは Azure App ゲートウェイによって残りの正常な VM シリーズファイアウォールにリダイレクトされます。VM シリーズが (可用性セット機能によって) 修復されると、トラフィックが再分散されます。このアーキテクチャは、スケーラビリティを提供するだけでなく、Azure 可用性セットのサポートによって弾力性と高可用性を実現します。

VM シリーズの拡張性とリカバリ性のデプロイメント・リソース

Azure Tech ブリーフの VM シリーズのスケーラビリティと復元性を読み取る

Azure での VM シリーズ高可用性 (アプリケーションゲートウェイとロードバランサーの統合を使用した受信および送信)

Azure での受信と送信の高可用性の両方の必要性に対処するために、コミュニティベースの ARM テンプレートを使用して、受信トラフィックと送信方向の両方に対して個別の負荷分散ファイアウォールを展開できます。各ファイアウォールは、可用性セット内の2つ以上の VM シリーズファイアウォールで構成されているため、負荷に対応するために個別に管理およびスケーリングすることができます。アプリケーションゲートウェイからの受信トラフィックは、受信 VM シリーズファイアウォールのインスタンスに負荷を分散するインバウンドロードバランサーによって受信されます。ファイアウォールはセキュリティポリシーを適用し、バックエンド web ワークロードのインスタンスに負荷を分散するバックエンドロードバランサーに安全なトラフィックをルーティングします。

Azure の展開リソースでインターネットに直接接続する Web ワークロードをセキュリティで保護する

Azure ホワイトペーパーでインターネットに直接接続する Web ワークロードを保護する

-----------オリジナルポスト:11 月、2016-----------

お客様がアプリケーションやデータをパブリッククラウドに移動するように見えるため、高可用性 (HA) などの従来のデータセンター構成要素に関する質問を聞くことは珍しくありません。問題は、"AWS または Azure で HA をサポートする方法" として提起されることがよくあります。より多くのクラウド中心の方法は、質問を提起する "我々は、パブリッククラウドの HA が必要ですか?"

質問に答えるためには、まず、HA の意味を正確に定義する必要があります。問題が解決しない場合は、パブリッククラウドアプリケーションをセキュリティで保護するための、完全に冗長で可用性の高いソリューションが必要ですか。その答えは間違いなく yes です。しかし、問題が解決しない場合は、プライベートクラウドで行ったのと同じように、汎 OS ステートフル HA フェールオーバーが必要になるかもしれません。

パブリッククラウドは、すべての共有リソースを活用し、アーキテクチャのどこでも失敗を乗り切ることができるアプリケーションを展開することです。これには次のようなエラーが含まれます。

、仮想ルーター
仮想ファイアウォール
ネットワークスイッチ
アプリケーションインスタンス
ロードバランサーのインスタンス
アベイラビリティーゾーンの障害
地域全体の障害であっても

お客様は、ラップトップ、タブレット、スマートフォンで、何らかの障害が発生したインフラストラクチャを使用しているアプリケーションを数十または数百も使用している可能性があります。時間の 99% と、彼らはそれが起こったのか分からない。一部のロードバランサーまたはスイッチまたはルーティングプロセスは、エラーをバイパスし、アプリケーションはユーザーに対して中断をほとんどまたはまったく行わずに再試行しました。したがって、VM シリーズのファイアウォールセキュリティをパブリッククラウドアプリケーションに統合するためのフォーカスは、自動スケーリンググループ、エラスティックロードバランシング、ルーティングなどのネイティブクラウドサービス上にあり、汎 OS HA では使用できません。

VM シリーズは、AWS の HA をサポートしていますが、一般に、ユーザーがパブリッククラウド移行を使用してアプリケーションを更新して、ネイティブクラウドサービスを利用して稼働時間を最大化する弾力性のあるアーキテクチャを構築する場合には必要ありません。多くのお客様は、従来のデータセンターのハードウェア要件リスト (冗長スイッチ、ルーター、ファイアウォールなど) に準拠したパブリッククラウドへの移行を開始し、クラウドの力を活用する能力を制限する可能性があります。ドライバとしての冗長性のための要件を使用して、その後、クラウド o を活用することができますお客様に: a) アプリケーションのアップタイムを改善し、b) コストを削減します。私はこれが常に可能ではないことを知っているが、後ろに荷物を残してみてください。

レガシアプリケーションをパブリッククラウドに移動するしかないお客様には、AWS 用の ha があり、Azure の ha を調査しています。しかし、それはコストで来る。だけでなく、彼らは、パッシブファイアウォールを必要とするすべての回で実行している (とは、法案) が、パブリッククラウドの HA は、はるかに時間がかかることができる API の呼び出しに依存している我々は、専用のネットワークインフラストラクチャ上のハードウェアで行うことができます。たとえば、AWS では、HA ソリューションは API 呼び出しに依存して、障害が発生したファイアウォールからパッシブファイアウォールにインターフェイス (ENI) を移動します。実際には、これは 30-45 秒かかりますが、時には長くなります。チャンスは、HA が保存するために意図されていたセッションは、すでにその期間内に再確立する必要があります。

その代わりに、負荷分散と動的なルーティングに焦点を当てることができます速くする必要がありますし、アプリケーションのセッションの再確立に対処できるようにします。パブリッククラウドは、IT アプリケーションアーキテクチャの一般的な傾向に合わせて、新しいアーキテクチャパターンを開発しています。

大きな負荷と可用性に対処するために水平方向のスケーリング (別名スケールアウト) の使用。
全体的なステートフルな web/HTTP ベースのアーキテクチャの成長。セッション cookie のような状態情報は、簡単に再構築することも、冗長化することもできます。
マイクロサービスのようなサービス指向アーキテクチャ (SOA) を使用して、多くの場合、コンテナ上に構築された、を分解する。ロードバランサーの背後で独立してスケーリングされた複数の層にまたがるアプリケーションスタック。

これらの環境では、セッションデータは amazon DynamoDB や amazon ElastiCache のような信頼性の高いデータベースサービスに格納され、アプリケーションサーバーで共有します。たとえば、ショッピングカートサービスでは、ユーザーの cookie セッションが web サーバー間で sync'ed/格納され、1つの web サーバーの障害がユーザーエクスペリエンスに影響を与えないようにすることができます。パブリッククラウドとオンプレミスのプライベートクラウドにおける新しいアーキテクチャの焦点は、サービスの信頼性であり、セッションの信頼性ではありません。

AWS の VM シリーズの自動スケーリングを使用して HA を達成する

前述のように、すべての AWS デプロイメントは、インフラストラクチャコンポーネントの障害によって発生する可能性がある悪影響を排除するために、弾力性のために設計する必要があります。障害が発生した場合、ソリューションは障害を検出してルーティングできる必要があります。これは、ソリューションのセキュリティにも当てはまります。AWS の VM シリーズの自動スケーリングは、ネイティブクラウドサービスを使用して HA を提供します。

AWS の VM シリーズの自動スケーリングでは、VPC 内の2つ以上のアベイラビリティーゾーンにわたって複数のファイアウォールが展開されます。vm シリーズのファイアウォールのいずれかが失敗すると、次の2つのことが起こります。まず、AWS ロードバランサーは障害を検出し、残りの正常な VM シリーズファイアウォールへのトラフィックを転換します。次に、AWS オートスケーリンググループは、異常なファイアウォールを自動的に削除し、完全に構成され、トラフィックを処理する準備ができている新しいブートストラップ VM シリーズファイアウォールに置き換えます。

パフォーマンスとコストの感度のバランスに応じて、正常性チェックと自動スケーリンググループは、失敗したコンポーネントの検出と置換について非常に攻撃的または非常に保守的であるように調整できます。これにより、展開を設計する際に、独自のコスト/メリットの決定を下すことができます。VM シリーズは、ワークロードとは無関係に自動的にスケールイン/アウトするだけでなく、複数のアベイラビリティーゾーンにわたって全体的で可用性の高いソリューションを提供する自己修復機能でもあります。

VM シリーズの Azure アプリケーションゲートウェイとロードバランサーの統合を使用して
HA を達成する

VM シリーズでは、ロードバランサー「サンドイッチ」を使用して、インバウンド web アプリケーションのワークロードトラフィック用のマネージスケールアウトソリューションをデプロイできます。アプリケーションゲートウェイは、外部ロードバランサーとして機能し、フロントはアプリケーションを終了し、サービス全体のインターネットゲートウェイとして提供されます。これは、サービスとしてアプリケーション配信コントローラ (ADC) を提供し、SSL オフロードやコンテンツベースのルーティングなどの機能と共に、HTTP と HTTPS のレイヤ7負荷分散を含みます。アプリケーションゲートウェイの背後にデプロイされた VM シリーズのファイアウォールは、既知および未知の脅威による攻撃から Azure 展開を保護する、次世代のセキュリティを完全に提供します。ファイアウォールによるセキュリティ検査後、トラフィックは、web アプリケーションにトラフィックを分散する内部ロードバランサーとして動作する Azure ロードバランサーに送信されます。このアーキテクチャは、スケーラビリティを提供するだけでなく、Azure 可用性セットのサポートによって弾力性と高可用性を実現します。

アプリケーションゲートウェイとロードバランサーは、あらゆるトラフィックの中断を処理し、可用性セットによって、Azure インフラストラクチャの計画的および予期しない保守に対する保護を提供します。これにより、さまざまなホスト間でワークロードを分散することによって、Azure インフラストラクチャの保守またはシステム障害がビジネスに与える悪影響を最小限に抑えるか、または排除することによって、復元性と可用性のニーズに対応できます。

参照

スライド 45-AWS re: 発明 2013- Amazon VPC (ARC202) の高可用性アプリケーションアーキテクチャ |...
ページ 11-アマゾンウェブサービス-クラウドのための設計: ベストプラクティス- https://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf