QUESTION

Amazon RDS for MySQL の DB インスタンスには、BI ツールの集計クエリを実行するリードレプリカが 1 つあります。BI ツールの利用者から、夜間の一括更新の後は集計結果に直近の注文が含まれていない旨の報告が届いています。CloudOps エンジニアは、リードレプリカのデータがソースより 10 分以上古くなったときに、Amazon SNS トピックで通知を受け取る必要があります。 運用上のオーバーヘッドを最小限に抑えながら、この要件を満たすソリューションはどれですか。

1 / 1
回答を選択してください
正解C

解説

リードレプリカのデータの遅れが一定の時間を超えたら通知する

  • 1「集計結果に直近の注文が含まれていない」リードレプリカへのレプリケーションが遅れている症状です。
  • 2「ソースより 10 分以上古くなったとき」レプリケーションの遅れの大きさ (秒数) をしきい値で判定する必要があります。
  • 3「運用上のオーバーヘッドを最小限に抑えながら」遅れを自分で集める仕組みより、RDS が送る組み込みのメトリクスを使う方法を選びます。
A不正解

RDS のイベント通知で、リードレプリカを発生元とする read replica カテゴリのイベントをサブスクライブし、トピックに通知する。

RDS のイベント通知の read replica カテゴリは、レプリケーションの停止やエラー、再開などの出来事を知らせます。

しかし、レプリケーションが動いたまま遅れているだけの状態を知らせるイベントはありません。10 分以上の遅れを検知するには、遅れの秒数を表すメトリクスを監視します。

B不正解

リードレプリカの ReadLatency メトリクスに、しきい値を 600 秒とする Amazon CloudWatch アラームを作成し、トピックに通知する。

ReadLatency は、ディスクの読み取り I/O 1 回あたりの平均時間を表すメトリクスです。

データがソースからどれだけ遅れているかは表さないので、リードレプリカのデータが古くなっても、この値が 600 秒に達することはありません。

C正解

リードレプリカの ReplicaLag メトリクスに、しきい値を 600 秒とする Amazon CloudWatch アラームを作成し、トピックに通知する。

ReplicaLag は、リードレプリカがソースの DB インスタンスから遅れている時間 (秒) を表す Amazon RDS のメトリクスです。MySQL では、SHOW REPLICA STATUS の Seconds_Behind_Master の値が報告されます。

リードレプリカの ReplicaLag に、しきい値が 600 秒のアラームを作成すれば、10 分以上の遅れを検知して SNS トピックに通知できます。RDS が自動で送信するメトリクスなので、収集の仕組みを作る必要はありません。

D不正解

AWS Lambda 関数で SHOW REPLICA STATUS を定期的に実行し、Seconds_Behind_Master をカスタムメトリクスとして送信する。そのメトリクスにアラームを作成し、トピックに通知する。

Lambda 関数で取得した Seconds_Behind_Master をカスタムメトリクスにすれば、遅れの秒数でアラームを作成できます。

しかし、この値は RDS が ReplicaLag メトリクスとして自動で送信しています。関数とスケジュール、DB への接続情報を自社で管理することになり、運用上のオーバーヘッドが大きくなります。

ポイント

リードレプリカの状態は、遅れと停止を分けて監視します。
・遅れ — ReplicaLag メトリクス (秒) です。ソースからどれだけ遅れているかを表し、しきい値のアラームで通知できます。MySQL と MariaDB では Seconds_Behind_Master の値です。
・停止やエラー — RDS のイベント通知の read replica カテゴリです。レプリケーションが動いていないと ReplicaLag は -1 になるので、遅れのアラームだけでは気づけません。
・ReadLatency や WriteLatency はディスクの I/O にかかった時間で、レプリカがどれだけ遅れているかは表しません。