STAY KOBE

[SolutionArchitect Pro] AWS RDS マルチAZ & リードレプリカ

Atsushi Marumo

RDS マルチAZ & リードレプリカ

マルチAZ　デプロイ

RDS のマルチAZフェイルオーバープロセス

リードレプリカ

リードレプリカの作成

リードレプリカ削除 と DB フェイルオーバー

リートレプリカストレージおよびコンピュート要件

リードレプリカの機能と制限

リードレプリカの使用例

AWS認定試験の練習問題

  1. AWS で成功した多層 Web アプリケーションを実行している場合、マーケティング部門では、アプリケーションにレポート層を追加するように求められています。レポート層は、Web アプリケーションデータベースに格納されているユーザーが生成した情報から、30分ごとにステータスレポートを集計および発行します。現在、データベース層のマルチ AZ RDS MySQL インスタンスを実行しています。また、アプリケーション層とデータベース層の間のデータベースキャッシュ層として ElastiCache を実装しています。データベースへの影響をできるだけ少なくして、レポート層を正常に実装できるようにする答えを選択してください。
    1. マスタデータベースから S3 バケットにトランザクションログを継続的に送信し、S3 バイト範囲要求を使用して S3 バケットからレポートを生成します。
    2. マルチ AZ によって維持された同期的にレプリケートされたスタンバイ RDS MySQL インスタンスを照会してレポートを生成する (スタンバイインスタンスをスケーリングソリューションとして使用することはできません)
    3. マルチ AZ マスタデータベースに接続された RDS リードレプリカを起動し、リードレプリカを照会してレポートを生成します。
    4. ElastiCache データベースキャッシュ層にクエリを実行してレポートを生成します。(ElasticCache は完全なデータを維持せず、単なるキャッシング・ソリューションです)
  2. 企業は、AWS に新しい2層 web アプリケーションを展開しています。同社は、限られたスタッフを持っており、高可用性を必要とし、アプリケーションは複雑なクエリとテーブルの結合が必要です。会社の要件に対するソリューションを提供する構成はどれですか。
    1. MySQL は、単一のアベイラビリティーゾーン内の2つの Amazon EC2 インスタンスにインストールされます (ハイアベイラビリティをすぐに使用することはできません)。
    2. マルチ AZ の Amazon RDS（MySQL）
    3. Amazon ElastiCache (単なるキャッシュソリューション)
    4. Amazon DynamoDB (複雑なクエリや結合には適さない)
  3. あなたの会社は、AWS のソーシャルメディアサイトの主要な公開発表を行う準備をしている。Web サイトは、マルチ AZ RDS MySQL エクストララージ DB インスタンスを使用して複数のアベイラビリティーゾーンにデプロイされた EC2 インスタンスで実行されています。このサイトでは、1秒あたりの小さな読み取りと書き込みの数が多いため、最終的な整合性モデルに依存します。包括的なテストの後には、RDS MySQL の読み取り競合があることがわかります。これらの要件を満たすために最適なアプローチはどれですか。(2 つの回答を選択)
    1. 各アベイラビリティーゾーンで実行中の ElastiCache インメモリキャッシュを展開する
    2. 複数の RDS MySQL インスタンスに負荷を分散するシャーディングを実装する (これは読み取り競合のみで、書き込みは正常に動作します)
    3. RDS MySQL インスタンスサイズを増やし、プロビジョニングされた IOPS を実装します (スケーラブルではありませんが、これは読み取り競合のみで、書き込みは正常に動作します)
    4. 各アベイラビリティーゾーンに RDS MySQL リードレプリカを追加する
  4. あなたの会社は、本社を東京に、世界中の支社を持ち、日本、ヨーロッパ、米国の AWS に複数の地域で展開したロジスティクスソフトウェアを使用しています。ロジスティック・ソフトウェアには3層アーキテクチャがあり、現在はデータ永続化に MySQL 5.6 を使用しています。各地域は独自のデータベースを展開しています。本社地域では、すべてのリージョンからのデータを読み取る時間ごとのバッチ処理を実行して、すべてのオフィスに電子メールで送信されるクロスリージョンレポートを計算しますこのバッチ処理は、できるだけ迅速にロジスティクスを最適化するために完了する必要があります。要件を満たすためにデータベースアーキテクチャを構築するにはどうすればいいですか。
    1. 各リージョンの展開について、リージョン内のマスタと RDS MySQL を使用し、HQ リージョンのリードレプリカを使います。
    2. 各リージョンの展開について、リージョンのマスターと共に EC2 で MySQL を使用し、1時間ごとに EBS スナップショットを HQ リージョンに送信します。
    3. 各リージョンの展開について、リージョン内のマスターと共に rds MySQL を使用し、1時間ごとの RDS スナップショットを HQ リージョンに送信します。
    4. 各リージョンの展開について、リージョンのマスターと共に EC2 で MySQL を使用し、S3 を使用してデータファイルを HQ リージョンに1時間ごとにコピーします。
    5. ダイレクトコネクト接続を使用して、すべてのリージョンの MySQL 展開を HQ リージョンに接続し、バッチ処理のネットワーク待ち時間を削減します。
  5. プライマリ DB インスタンスに障害が発生した場合、RDS (リレーショナルデータベースサービス) のマルチアベイラビリティゾーンの展開はどうなりますか。
    1. プライマリ DB インスタンスの IP は、スタンバイ DB インスタンスに切り替わります。
    2. 新しい DB インスタンスがスタンバイアベイラビリティーゾーンに作成されます。
    3. 標準名レコード (CNAME) は、プライマリからスタンバイに変更されます。
    4. RDS (リレーショナルデータベースサービス) DB インスタンスが再起動します。
  6. お客様のビジネスは、RDS MySQL データベース上の顧客データベース全体を格納する新しいアプリケーションを構築しており、様々なアプリケーションとは、さまざまな目的のためにそのデータを照会するユーザーがあります。データベース上の大規模なアナリティクスジョブは、タイムアウトになる前に、他のアプリケーションが必要なクエリ結果を取得できない可能性があります。また、データが増加するにつれて、これらの分析ジョブはより多くの時間がかかり、他のアプリケーションへの悪影響が高まります。同じデータのこれらの異なるワークロード間の競合の問題をどのように解決しますか。
    1. RDS インスタンスでマルチ AZ モードを有効にする
    2. ElastiCache を使用して分析ジョブデータをオフロードする
    3. 分析作業用の RDS リードレプリカの作成
    4. 可能な最大サイズで RDS インスタンスを実行する
  7. スタンバイ RDS インスタンスは、プライマリと同じアベイラビリティーゾーンにありますか。
    1. Oracle RDS タイプのみ
    2. はい
    3. 起動時に設定されている場合のみ
    4. いいえ
  8. 別のリードレプリカのリードレプリカ作成はサポートされていますか？
    1. 特定のリージョンでのみ
    2. MySQL ベースの RDS のみ
    3. Oracle RDS タイプのみ
    4. いいえ
  9. ユーザーは、RDS のマルチ AZ 機能をセットアップすることを計画しています。次の条件のうちマルチAZ機能を利用しない条件はどれですか？
    1. アベイラビリティーゾーンの停止
    2. フェイルオーバー・オプションを使用した再起動による DB インスタンスの手動フェイルオーバー
    3. リージョンの停止
    4. ユーザーが DB インスタンスのサーバーの種類を変更すると
  10. マルチ AZ 配置として DB インスタンスを実行すると、”___” によってデータベースの書き込みと読み取りが機能します。
    1. セカンダリ
    2. バックアップ
    3. スタンバイ
    4. プライマリ
  11. DB インスタンスをマルチ AZ 展開として実行する場合、読み取りまたは書き込み操作にスタンバイを使用できますか。
    1. はい
    2. MySQL ベースの RDS のみ
    3. Oracle RDS タイプのみ
    4. いいえ
  12. リードレプリカは、トランザクションストレージエンジンを必要とし、_________ ストレージエンジンでのみサポートされています
    1. OracleISAM
    2. MSSQLDB
    3. InnoDB
    4. MyISAM
  13. ユーザーは、RDS DB のマルチ AZ 機能を構成しています。ユーザーは、この RDS DB が AWS テクノロジーを使用しないことを知るようになりましたが、サーバーミラーリングを使用してレプリケーションを実現しています。ユーザーが現在使用している DB はどれですか。
    1. MySQL
    2. Oracle
    3. MS SQL
    4. PostgresSQL
  14. マスター DB インスタンスに複数のリードレプリカがある場合、そのうちの1つをプロモートすると、残りのリードレプリカはどうなりますか。
    1. 残りのリードレプリカは、引き続き古いマスタ DB インスタンスからもレプリケートされます
    2. 残りのリードレプリカは削除されます
    3. 残りのリードレプリカは、1つのリードレプリカに結合されます。
  15. マルチ AZ 配置を選択した場合、プライマリ DB インスタンスの計画的または予期しない停止が発生した場合、Amazon RDS は自動的にスタンバイレプリカに切り替わります。自動フェールオーバーメカニズムは、メイン DB インスタンスの ______ レコードを、スタンバイ DB インスタンスを指すように変更するだけです。
    1. DNAME
    2. CNAME
    3. TXT
    4. MX
  16. 自動フェールオーバーが発生すると、Amazon RDS は DB インスタンスイベントを生成して、自動フェールオーバーが発生したことを通知します。、_________ を使用して、DB インスタンスに関連するイベントに関する情報を返すことができます。
    1. FetchFailure
    2. DescriveFailure
    3. DescribeEvents
    4. FetchEvents
  17. リードレプリカをプロモートするときに作成される新しい DB インスタンスは、バックアップ期間を保持します。
    1. 真
    2. 偽
  18. 自動フェイルオーバーが発生したときにアラートが表示されますか？
    1. SNSが設定されている場合のみ
    2. いいえ
    3. はい
    4. Cloudwatchが設定されている場合のみ
  19. MySQL マルチ AZ DBインスタンスの展開で強制フェイルオーバーを開始できますか？
    1. 特定のリージョンでのみ
    2. VPCでのみ
    3. はい
    4. いいえ
  20. ユーザーがアプリケーションから RDS にアクセスしています。ユーザーは、MS SQL RDS DB でマルチ AZ 機能を有効にしました。計画的な停止中に AWS は、DB からスタンバイレプリカへのスイッチがアプリケーションへのアクセスに影響しないようにする方法を確認します。
    1. RDS には、新しい DB へのすべての要求をリダイレクトする内部 IP があります。
    2. RDS は、DNS を使用して、シームレスな移行のためにスタンバイレプリカに切り替えます。
    3. スイッチオーバーによりハードウェアが変更されるため、RDS はアクセスを心配する必要はありません。
    4. RDS は両方の DB を独立して実行し、ユーザーは手動で切り替える必要があります。
  21. マルチ AZ Amazon リレーショナルデータベースサービス (RDS) インスタンスのフェールオーバープロセスの一部は、次のうちどれですか。
    1. 失敗した RDS DB インスタンスが再起動します。
    2. プライマリ DB インスタンスの IP は、スタンバイ DB インスタンスに切り替わります。
    3. RDS エンドポイントの DNS レコードは、プライマリからスタンバイに変更されます。
    4. 新しい DB インスタンスがスタンバイアベイラビリティーゾーンに作成されます。
  22. マルチ AZ RDS インスタンスがフェールオーバーする理由はどれですか？
    1. アベイラビリティーゾーンの停止
    2. DB インスタンスの手動フェールオーバーは、フェールオーバーによる再起動を使用して開始されました
    3. より高いインスタンスクラスに自動スケールするには (リンクを参照)
    4. Master データベースの破損が発生する
    5. プライマリ DB インスタンスが失敗する
  23. RDS の展開を拡張する必要があります。あなたのログに基づいて、10% の書き込みと 90% の読み取りで動作しています。どのように最高の簡単な方法でこれをスケーリングできますか?
    1. 2番目のマスター RDS インスタンスを作成し、RDS グループをピアします。
    2. CloudFront を使用して、読み取り側のすべてのデータベース応答をキャッシュします。
    3. 負荷がほとんど読み取りのため、RDS のリードレプリカを作成します。
    4. マルチ AZ RDS のインストールを作成し、読み取りトラフィックをスタンバイにルーティングします。
  24. Amazon RDS マルチアベイラビリティゾーンモデルはどのように動作しますか?
    1. 2番目のスタンバイデータベースは、同期レプリケーションを使用して、master とは別のアベイラビリティーゾーンに配置および保守されます。(リンク参照)
    2. 2番目のスタンバイデータベースは、非同期レプリケーションを使用してマスターから別のアベイラビリティーゾーンに配置および保守されます。
    3. 2番目のスタンバイデータベースは、非同期レプリケーションを使用してマスタとは別のリージョンにデプロイおよび保守されます。
    4. 2番目のスタンバイデータベースは、同期レプリケーションを使用してマスタとは別のリージョンにデプロイおよび保守されます。
  25. お客様は、米国西部 (北カリフォルニア) 地域でアプリケーションを実行しており、アジア太平洋地域 (シンガポール) の災害復旧フェイルオーバーをセットアップしたいと考えています。お客様は、Amazon RDS マルチ AZ MySQL データベースインスタンスの低復旧ポイント目標 (RPO) を達成することに関心を持っています。このニーズに最適なアプローチはどれですか。
    1. 同期レプリケーション
    2. 非同期レプリケーション
    3. Route53 健康チェック
    4. RDS 増分スナップショットのコピー
  26. ユーザーは、小さな MySQL RDS DB を使用しています。マルチ AZ 機能により、ユーザーの待ち時間が長くなっています。以下のオプションのうち、このような状況でユーザーを助けることができないものはどれか?
    1. 非稼働時間で自動バックアップをスケジュールする
    2. 大規模またはそれより大きいサイズのインスタンスを使用する
    3. PIOPS を使う
    4. スタンバイレプリカからスナップショットを取得する
  27. リザーブドインスタンスはマルチAZ配備に使用できますか？
    1. クラスター計算インスタンスの場合のみ
    2. すべてのインスタンスタイプで出来る
    3. M3インスタンスタイプのみ
  28. マルチ AZ のフェイルオーバー後に “スタック” が表示され、ソース DB インスタンスから更新を取得または適用できません。何をしますか？
    1. 読み取りレプリカを削除して、それを置き換えるために新しい複製物を作成する必要があります。
    2. DB エンジンの関連付けを解除し、再関連付けする必要があります。
    3. インスタンスを単一の AZ にデプロイしてから、再びマルチ AZ に移動する必要があります。
    4. DB インスタンスを削除し、それを置き換える新しいデータベースを作成する必要があります。
  29. プライマリとスタンバイの間でデータをレプリケートする際に発生するデータ転送の料金は何ですか。
    1. 無料です。それは自由である。
    2. 標準データ転送料金を2倍にする
    3. 標準データ転送料金と同じ
    4. 標準データ転送料金の半分
  30. ユーザーは、MS SQL RDS データベースサーバーでマルチ AZ 機能を有効にしています。以下のステートメントのうち、ユーザーがマルチ AZ 機能をよりよく理解できるようになるのはどれですか。
    1. マルチ AZ では、AWS は2つの DB を並行して実行し、レプリカコピーにデータを非同期的にコピーします。
    2. マルチ AZ では、AWS は2つの DB を並行して実行し、レプリカコピーにデータを同期的にコピーします。
    3. マルチ AZ では、AWS は1つの DB だけを実行しますが、データを同期的にスタンバイレプリカにコピーします。
    4. AWS MS SQL はマルチ AZ 機能をサポートしていません
  31. 会社は、RDS MySQL インスタンスで実行されているメイントランザクション DB 上で、1時間ごとにバッチ分析を実行して、Redshift で実行されている中央データウェアハウスを作成します。バッチの実行中に、トランザクションアプリケーションは非常に低速です。バッチが完了したら、新しいデータを使用してトップ管理ダッシュボードを更新する必要があります。パフォーマンスの問題を解決し、可能な限りプロセスを自動化するために、このシナリオをどのように最適化しますか。
    1. RDS をバッチ分析および SNS 用の Redshift に置き換えて、社内システムにダッシュボードを更新するように通知します。
    2. RDS をバッチ分析と SQS に置き換えて、ダッシュボードを更新するためのメッセージをオンプレミスシステムに送信します。
    3. バッチ分析および SNS 用の RDS リードレプリカを作成し、ダッシュボードを更新するためにオンプレミスシステムに通知します。
    4. バッチ分析および SQS 用の RDS リードレプリカを作成し、ダッシュボードを更新するために社内システムにメッセージを送信します。

Jayendra’s Blog

この記事は自己学習用に「AWS RDS Replication – Multi-AZ & Read Replica – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。