Blogより)」を日本語に訳した記事です。Servicesは、クラウド内に信頼性の高い耐障害で可用性の高いシステムを構築するためのサービスとインフラストラクチャを提供します。耐障害機能は、システムの構築に使用されたコンポーネントの一部に障害が発生しても、システムが動作し続ける能力を定義します。S3、SimpleDB、SQS、ELBなどの上位サービスのほとんどは、耐障害と高可用性を念頭に置いて構築されています。EC2やEBSなどの基本的なインフラストラクチャを提供するサービスは、耐障害で高可用性のシステムが正しく利用して使用する必要がある、可用性ゾーン、柔軟なIPアドレス、スナップショットなどの特定の機能を提供します。Zone(AZ)があり、冗長な配置場所に簡単にアクセスできます。AZは、他のAZの障害から隔離されるように設計された別個の地理的な場所です。リージョンとAZは、地理的にアプリケーションを配布し、マルチサイトソリューションの構築を支援することにより、より大きな耐障害性を実現します。AZは、同じリージョンの他の可用性ゾーンへの安価で低遅延のネットワーク接続を提供します。EC2インスタンスを複数のAZに配置することで、アプリケーションを1つのデータセンターで障害から保護することができます。同一リージョンまたは別のリージョンの複数のAZで独立したアプリケーションスタックを実行することが重要です。そのため、あるゾーンに障害が発生した場合でも、他のゾーンのアプリケーションは引き続き実行できます。Services内のコンピューティング・リソースを提供するWebサービスです。Image(AMI)は、サービスインスタンスを定義するために使用できるテンプレートを提供します。テンプレートは、基本的にソフトウェア構成(OS、アプリケーションサーバー、アプリケーション)を含み、インスタンスタイプに適用されます。AMIには、すべてのソフトウェア、アプリケーション、バンドルされたコードが含まれているか、起動時にインストールするためのブートストラップスクリプトを持つように設定できます。単一のAMIを使用して、異なるインスタンス・タイプのサーバー・リソースを作成し、新しいインスタンスの作成または失敗したインスタンスの置換を開始できます。オートスケーリングオートスケーリングは、定義されたルールに基づいてEC2の容量を自動的に拡大または縮小します。オートスケーリングでは、増加する負荷に対応してさらに多くのインスタンスを追加することもできます。それらのインスタンスがもはや必要でなくなると、自動的に終了します。オートスケーリングを使用すると、置換インスタンスが自動的に起動されることを認識して、サーバーインスタンスを任意で終了できます。オートスケーリングは、AWSリージョン内の複数のAZで機能します。ELBELBは、システムの可用性を向上させる効果的な方法であり、着信トラフィックを複数のEC2インスタンスにわたってアプリケーションに分散します。ELBでは、DNSホスト名が作成され、このホスト名に送信された要求はすべてEC2インスタンスのプールに委任されます。ELBは、ホストのヘルスチェック、複数のアベイラビリティゾーンにわたるEC2インスタンスへのトラフィックの分散、およびロードバランシングローテーションからのEC2ホストの動的追加および削除をサポートしています。Scalingを使用して不健全なインスタンスがシームレスに復元されるまで、トラフィックを正常なインスタンスに自動的に再ルーティングします。オートスケーリングとELBは理想的な組み合わせです。ELBはアドレッシングに単一のDNS名を指定しますが、自動スケーリングでは、正常な数の正常なEC2インスタンスが要求を受け入れることができます。ELBを使用すると、地域の複数のAZのインスタンス間でバランスをとることができます。EIPsElasticIPアドレスは、静的なIPアドレスです。リージョン内のインスタンス間でプログラム的にマップできます。EIPはAWSアカウントに関連付けられており、特定のインスタンスまたはインスタンスの存続期間ではありません。ElasticIPアドレスは、マスタデータベース、中央ファイルサーバー、EC2ホストロードバランサなど、一貫したエンドポイントが必要なインスタンスやサービスに使用できます。ElasticIPアドレスは、実行中の別のインスタンスまたは直前に置換されたインスタンスにアドレスをすぐに再マッピングすることにより、ホストまたは可用性ゾーンの障害を回避するために使用できます。リザーブドインスタンス予約されたインスタンスは、常に低いコストでコンピューティング容量を確保し保証するのに役立ちます。Store(EBS)は、永続的なオフインスタンスストレージボリュームを提供し、インスタンスの存続期間から独立して存続し、インスタンス上のストレージよりも耐久性があります。EBSボリュームはデータを重複して保存し、単一のAZ内で自動的に複製されます。EBSは、EC2インスタンスに障害が発生して交換が必要な場合、EBSボリュームを新しいEC2インスタンスに接続できるフェールオーバーシナリオで役立ちます。重要なデータは、適切なバックアップ、レプリケーション、またはデータの再作成機能がないインスタンス(一時的な)ストレージにのみ格納することはできません。EBSスナップショットEBSボリュームは高い信頼性を備えていますが、障害の可能性をさらに緩和し、耐久性を向上させるために、S3のボリュームにデータを格納するためのポイントインタイムスナップショットを作成し、複数のAZにレプリケートします。スナップショットを使用して、新しいEBSボリュームを作成できます。新しいEBSボリュームは、スナップショットが作成された時点の元のボリュームの正確なレプリカです。スナップショットは、ディスク障害やその他のホストレベルの問題、およびAZに影響を与える問題に対処する効果的な方法を提供します。スナップショットは増分バックアップであり、以前のスナップショット以降の変更のみをバックアップするため、最新のスナップショットを保持することをお勧めします。スナップショットはリージョンに関連付けられ、EBSボリュームは単一のAZに関連付けられます。RDSRDSを使用すると、クラウド内のリレーショナルデータベースを簡単に実行できます。Multi-AZデプロイメントにより、データベースの可用性が向上し、計画外の停止からデータベースが保護されます。フェイルオーバーのシナリオの場合、スタンバイはシームレスにメインに昇格され、データベース操作を処理します。デフォルトで有効になっているデータベースの自動バックアップでは、データベースインスタンスのポイントインタイムリカバリが提供されます。RDSは、データベースとトランザクションログをバックアップし、ユーザー指定の保持期間の両方を格納します。自動バックアップに加えて、明示的に削除されるまで保持される手動RDSバックアップを実行することもできます。バックアップは、誤ったデータ変更などのより高いレベルの障害から、オペレータエラーまたはアプリケーションのバグによって回復します。RDSリードレプリカは、データベースの読み取り専用レプリカを提供し、単一のデータベース配備の容量を超えてスケ​​ールアウトして、読み取り負荷の高いデータベース作業負荷を実現します。RDSリードレプリカはスケーラビリティであり、高可用性ソリューションではありません。S3S3は、耐久性の高い耐障害性で冗長なオブジェクトストアを提供します。Regionの複数の施設にまたがって複数のデバイスに重複してオブジェクトを格納します。S3は、画像、動画、その他の静的メディアなど、静的でもゆっくり変化するオブジェクトでも、優れたストレージソリューションです。CloudFrontサービスと相互作用することによって、これらのアセットのエッジキャッシングおよびストリーミングもサポートします。SQSシンプルキューサービス(SQS)は、耐障害性アプリケーションのバックボーンとして機能する、信頼性の高い分散型メッセージングシステムです。SQSは、すべてのメッセージを少なくとも1回配信するように設計されています。メッセージがキューに送信されることが保証されているメッセージは、最大4日間、またはアプリケーションによって読み取られて削除されるまで保持されます。メッセージは複数のワーカーによってポーリングされ、処理されますが、SQSでは、可視性のタイムアウトと呼ばれる設定可能な時間間隔を使用して、一度に1人のワーカーのみが要求を処理するよう注意します。キュー内のメッセージ数が増加し始めたり、メッセージの平均処理時間が長くなりすぎると、追加のEC2インスタンスを追加するだけで作業者を拡大することができます。ドメインのクエリは自動的に最寄りのDNSサーバーにルーティングされるため、可能な限り最高のパフォーマンスで応答されます。レコード(example.com)が解決されます。CloudFrontCloudFrontは、エッジロケーションのグローバルネットワークを使用して、動的コンテンツ、静的コンテンツ、ストリーミングコンテンツなどのウェブサイトを配信するために使用できます。コンテンツのリクエストは自動的に最寄りのエッジロケーションにルーティングされるため、コンテンツは可能な限り最高のパフォーマンスで配信されます。Webサービスと連携するように最適化されています。CloudFrontは、AWS以外のオリジナルのサーバーとシームレスに連携し、オリジナルの最終バージョンのファイルを保存します。質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。さらなるフィードバック、ディスカッション、修正を可能にします。既存の従来のシステムをAWSに移行すると、移行中に単一障害点であるマスターサーバーが存在することがわかります。マスターサーバーの実装を調べたところ、マイグレーション中に高可用性になるように再設計するための時間が不足していますが、ローカルのMySQLデータベースに状態が保存されていることがわかります。ローカルデータベースを置き換えるためにRDSを選択し、マスターがそれを使用するように構成するための休止時間を最小限に抑えるには、自己修復アーキテクチャを作成するための最善の手順を教えてください。RDSデータベースに移行します。ヘルスチェックを使用して、マスターノードをオートスケーリング・マルチAZに最小1つ、最大1つ配置します(最小1つ、最大1つ)。ローカルデータベースをRDSリードレプリカにレプリケートします。ヘルスチェックを使用して、マスターノードを最小1個、最大1個のクロスゾーンELBに配置します。RDSデータベースに移行します。ヘルスチェックを使用して、マスターノードを最小1個、最大1個のクロスゾーンELBに配置します。(ELBにはMinとMax1の機能はなく、クロスゾーンではインスタンス間のロードの均等な分配が可能です)ローカルデータベースをRDSリードレプリカにレプリケートします。ヘルスチェックを使用して、マスターノードをマルチAZ・オートスケーリンググループに配置します(最小1つ、最大1つ)。(リード・レプリカはHAおよび書き込み機能を提供しません)VPCのインターネット接続を設計しています。Webサーバーはインターネット上で利用できる必要があります。アプリケーションには高可用性アーキテクチャが必要です。(2つの回答を選択)VPCでNATインスタンスを設定します。NATインスタンス経由でデフォルトルートを作成し、すべてのサブネットに関連付けます。Aレコードを設定します。(NATは、プライベートサブネット内のインスタンスのインターネット接続用です)CloudFrontディストリビューションを構成し、WebサーバーのプライベートIPアドレスを指すように起点を構成します。CNAMEレコードをCloudFrontディストリビューションに設定します。すべてのWebサーバーをELBの背後に置きます。CNAMEを設定します。すべてのWebサーバーにEIPを割り当てます。すべてのEIPでRoute53レコードセットを設定します。[PROFESSIONAL]2,4,5および63,4,5および81〜81,3,5および71,2,5および6A社は、登録ユーザーが地元のレストランを評価できるインタラクティブなWebサイトの移行を支援するためにあなたを雇いました。レーティングの更新はホームページに表示され、レーティングはリアルタイムで更新されます。今日のウェブサイトはあまり人気がありませんが、今後数週間で急速に成長すると予想しています。彼らは、サイトの可用性を高くしたいと考えています。WebサーバーとLinux上で動作するMySQLデータベースで構成されています。両方ともオン・ハイ・ハイパーバイザーの内部に存在します。S3バケットにWebファイルをエクスポートします。S3から直接Webサイトを実行します。RDSインスタンスを起動します。RDSにデータをインポートします。Route53を使用し、ELBを指すエイリアスレコードを作成します。R2インスタンスを、us-west-1aでは2つのインスタンスを起動します。WebサーバーにWebファイルをコピーします。RDSインスタンスを起動します。RDSにデータをインポートします。Webサーバーの前にELBを作成します。Route53を使用し、ELBを指すエイリアスレコードを作成します。Image(AMI)を作成します。us-west-1aとus-west-1bの2つのWebサーバを起動するように自動スケーリングを設定します。Service(RDS)インスタンスを起動します。RDSにデータをインポートします。AmazonRoute53を使用して、ホストされたゾーンを作成し、Aレコードをエラスティックロードバランサに向けます。us-west-1aとus-west-1bの2つのWebサーバを起動するように自動スケーリングを設定します。RDSインスタンスを起動します。RDSにデータをインポートします。Webサーバーの前にELBを作成します。53を使用して、ELBを指すAレコードを作成します。(別名レコードを作成する必要があります)あなたの会社はイベント登録サイトに直面している顧客を運営しています。このサイトは、Webおよびアプリケーション層サーバーとMySQLデータベースを備えた3層アーキテクチャで構築されています。アプリケーションには、通常の操作では6つのWeb層サーバーと6つのアプリケーション層サーバーが必要ですが、サーバー容量と1つのMySQLデータベースで最低65%の稼働率が得られます。Cloud)インスタンスを持つ2つのAZに展開されたWeb層、および各AZに3つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBの背後にある自動スケーリンググループ。Service)インスタンスが、他のAZにリードレプリカとともに配置されています。Groupは、2つの他のAZでリードレプリカを展開しています。Cloud)インスタンスを持つ3つのAZに展開されたWeb層。ELBの背後にある自動スケーリンググループ内の各AZに2つのEC2インスタンスを持つ3つのAZに展開されたアプリケーション層。RDS(リレーショナルデータベースサービス)展開。Cloud)インスタンスを持つ2つのAZに展開されたWeb層、および各AZに6つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBの背後にある自動スケーリンググループ。Service)デプロイメントをサポートしています。Cloud)インスタンスを持つ2つのAZに展開されたWeb層と、Auto内の各AZに6つのEC2インスタンスを持つ2つのAZに展開されたアプリケーション層ELBと1つのRDS(リレーショナルデータベースサービス)インスタンスの背後にあるスケーリンググループは、他のAZのリードレプリカで展開されます。Cloud)インスタンスを持つ1つのAZに展開されたWeb層。RDS(リレーショナルデータベースサービス)配備の背後にある自動スケーリンググループ内の6つのEC2インスタンスを持つ同じAZに、第1のAZ内の実行中のインスタンスのいずれかが失敗した場合、他のAZは起動準備が整う。m4の大きなインスタンスを必要とするシステムを設計しています。6つのAZを持つus-east-1地域で高可用性を実現するシステムを設計する場合、企業はフルアベイラビリティゾーンの死を処理できる必要があります。すべてのEC2ノードがELBに適切にリンクされていると仮定して、できるだけ多くのコストを節約するために、サーバーをどのように配布する必要がありますか?あなたのVPCアカウントはus-east-1のAZのa〜fを利用することができます。各AZのa〜cに4つのサーバーリージョナルAWSの全面的な失敗時にオンライン状態を維持するには、DynamoDBに裏付けされたAPIが必要です。大規模な障害イベント中に数分の遅延や低速を許容することはできますが、システムは数分後に通常の操作で復旧する必要があります。[PROFESSIONAL]別のリージョンに1つのスタンバイを持つマスタースタンバイ構成で、DynamoDBクロスリージョンレプリケーションを設定します。DynamoDBが実行されている2つのリージョンのELBの背後に自動スケーリンググループを作成します。2つのリージョンのELBをリソースレコードとして使用して、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードを追加します。(2つのELBとRoute53のフェールオーバーと遅延DNSを持つASGを持つDynamoDBクロスリージョンレプリケーションバージョンを使用してください)DynamoDBマルチリージョンテーブルを設定します。DynamoDBが実行されている2つのリージョンのELBの背後に自動スケーリンググループを作成します。2つのリージョンのELBをリソースレコードとして使用して、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードを追加します。(DynamoDBマルチリージョンテーブルのようなものはありません)DynamoDBマルチリージョンテーブルを設定します。クロスリージョン自動スケーリンググループを指すクロスリージョンELBを作成し、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードをクロスリージョンELBに転送します。(クロスリージョンELBまたはクロスリージョンASGのようなものはありません)別のリージョンに1つのスタンバイを持つマスタースタンバイ構成で、DynamoDBクロスリージョンレプリケーションを設定します。クロスリージョン自動スケーリンググループを指すクロスリージョンELBを作成し、DNSフェイルオーバーを使用してRoute53レイテンシDNSレコードをクロスリージョンELBに転送します。Balancer、EC2&RDSの組み合わせを使用しています。EC2インスタンスを起動し、WordPressをダウンロードして設定ファイルの接続文字列をセットアップして、RDSと通信できるようにします。URLを参照すると何も起こりません。次のうちどれがこの原因ではない可能性がありますか。EC2インスタンスが配置されているセキュリティグループでポート80/443を開くのを忘れてしまった。ELBにはヘルスチェックがあり、存在しないWebページをチェックしています。したがって、EC2インスタンスは稼動していません。AレコードがELBを指すようにALIASを設定していません。HTTPSを使用してサイトにアクセスできなくなります。現在開発中の開発チームは、夜間に6時間のビルドを行っており、大規模でほとんど利用されていないサーバーを使用して、社内で時間をかけて長くなっていますが、同じ日に起動される複数のビルドをAWS上で継続的に展開する統合モデル。コスト、セキュリティ、およびオフサイトでは移動できないLDAPや電子メールサーバーなどの既存のオンプレミスアプリケーションとの統合方法については懸念されています。開発環境にはソースコードリポジトリが必要です。ビルドを実行するためのMySQLデータベースリソースと、QAがビルドをピックアップするための格納場所を持つプロジェクト管理システム。Serviceが含まれます。(BastionはVPN接続用ではない。Gatewayは安全な接続性を提供せず、VPNはまだ必要です。CloudFrontが含まれます。ビルドキューのSQS、ビルドを実行するEC2インスタンスの自動スケーリンググループ、ビルド出力のS3があります。(安全な接続のためにはVPNゲートウェイが必要です。