Amazon Aurora リードレプリカが遅れ、再起動されたのはなぜですか。

簡単な説明

AuroraReplicaLag は、Aurora DB クラスター内のライター Aurora DB インスタンスからリーダーインスタンスに変更をレプリケーションする際の遅延をミリ秒単位で測定したものです。Aurora レプリカは、ライターインスタンスと同じストレージボリュームに接続します。ライターインスタンスとリーダーインスタンスの間の遅延を測定するには、Amazon CloudWatch の AuroraReplicaLag メトリクスを使用します。

Aurora DB クラスターでは、AuroraReplicaLag メトリクスが、ライター DB インスタンスに対する Aurora レプリカのデータキャッシュの遅延を示します。データキャッシュには、バッファープールまたはページキャッシュが含まれます。変更は共有ストレージボリュームに同期して書き込まれます。ただし、変更はリーダーインスタンスに非同期で書き込まれ、変更に関連するメモリにキャッシュされたすべてのデータは読み取りの整合性のために無効化されます。場合によっては、リーダーインスタンス全体で変更を伝播するときに遅延が生じることがあります。この遅延は CloudWatch の AuroraReplicaLag メトリクスの増加として発生し、最終的に再起動を引き起こす可能性があります。

AuroraReplicaLag に関するほぼリアルタイムのメタデータを測定できます。

Amazon Aurora MySQL - 互換エディションの場合、INFORMATION_SCHEMA.REPLICA_HOST_STATUS の表から選択します。

mysql> select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID','writer', 'reader') as Role, 
replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

+---------------------+--------+-------------------+
| Instance_Identifier | Role   | AuroraReplicaLag  |
+---------------------+--------+-------------------+
| myamscluster-aza-1  | writer |                 0 |
| myamscluster-azb-1  | reader | 5.150000095367432 |
| myamscluster-aza-2  | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

Amazon Aurora PostgreSQL - 互換エディションの場合は、aurora_replica_status() 関数を呼び出して、その結果をフィルタリングします。

postgres=> select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, 
replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

server_id          | role   | aurorareplicalag
-------------------+--------+------------------
myapgcluster-aza-1 | Reader | 19.641
myapgcluster-azb-1 | Reader | 19.752
myapgcluster-aza-2 | Writer |
(3 rows)

**注:**この記事で説明する解決方法は、Amazon Aurora シングルリージョンおよびグローバルデータベースのプライマリクラスターに関するものであり、グローバルデータベースのセカンダリクラスターには適用されません。

解決方法

クラスター内のすべてのインスタンスの仕様が同じであることを確認する

リーダーインスタンスの DB インスタンスクラスの設定が、ライター DB インスタンスよりも弱い場合、変更のボリュームが大きすぎる可能性があります。この場合、リーダーインスタンスはキャッシュ内で無効化してから追いつくことはできません。そのため、Aurora クラスター内のすべての DB インスタンスの仕様を同じにすることがベストプラクティスです。

メトリクスと拡張モニタリングを使用したセッションのモニタリング

リーダーインスタンスでは、複数のセッションが同時に実行されているときに遅延が発生することがあります。Aurora レプリカは、利用可能なリソースがないため、ライターから必要な変更を適用するのに時間がかかることがあります。この遅延は、CPUUtilization、DBConnections、および NetworkReceiveThroughput などのメトリクスで確認することができます。1 秒または 5 秒の粒度で拡張モニタリングを有効にして、リーダーのリソース使用量を把握することもできます。Performance Insights を使用してワークロードを視覚化することも可能です。さらに、Aurora PostgreSQL - 互換の場合のみ、ReadIOPS メトリクスを使用します。

CloudWatch を使用して書き込みアクティビティを視覚化する

既に書き込み負荷が高いプロダクションクラスターでの書き込みアクティビティの急激な増加は、ライター DB インスタンスに過剰な負荷がかかる原因となり得ます。サージによって引き起こされる追加の負荷が、1 つ以上のリーダーインスタンスの遅れを引き起こす場合があります。これは、DMLThroughput、DDLThroughput、および Queries メトリクスの急増が示される CloudWatch で確認できます。

Aurora PostgreSQL の場合は、WriteThroughput メトリクスでこれを確認できます。

増大化が進む History List Length (HLL) を調べる (Aurora MySQL - 互換)

MySQL InnoDB エンジンには、デフォルトで MVCC (multi-version concurrency control) が組み込まれています。これは、トランザクションの全体を通じて、影響を受けるすべての行で発生したすべての変更を追跡する必要があることを意味します。長時間実行されるトランザクションが完了すると、パージスレッドアクティビティの急増が始まります。長時間実行されるトランザクションによって作成されるバックログの量が原因で、この突然のパージが Aurora レプリカの遅延を引き起こす場合があります。

Aurora MySQL には、バージョン 1.19.2、および 2.06 以降から RollbackSegmentHistoryListLength メトリクスが含まれています。このパージは、CloudWatch でこのメトリックスを使用して確認できます。これは、SHOW ENGINE INNODB STATUS の出力や、または以下のように情報スキーマをクエリすることで表示することもできます。

mysql> select NAME AS RollbackSegmentHistoryListLength, 
COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

+----------------------------------+-------+
| RollbackSegmentHistoryListLength | COUNT |
+----------------------------------+-------+
| trx_rseg_history_len             |   358 |
+----------------------------------+-------+
1 row in set (0.00 sec)

このメトリクスを監視する CloudWatch アラームをセットアップして、その数値が高くなりすぎないようにしてください。リレーショナルデータベースでは、長時間実行されるトランザクションを避けることがベストプラクティスです。

短時間のネットワークの中断を防ぐ

まれではありますが、ライターインスタンスとリーダーインスタンスの間、またはインスタンスと Aurora ストレージ層の間で、一時的なネットワーク通信障害が発生する場合があります。リーダーインスタンスは、ネットワークにおける短時間の中断により、遅れたり、再起動したりすることがあります。また、Aurora レプリカは、大量の変更によってインスタンスのネットワーク帯域幅が飽和状態になることが原因で遅れる可能性があります。この問題を回避するベストプラクティスは、DB インスタンスのサイズ、ひいてはそのネットワーク機能を検討することです。

---

関連情報

DB クラスターに Aurora レプリカを追加する

Amazon Aurora MySQL を使用したシングルマスターレプリケーション

Amazon Aurora クラスターのメトリクスのモニタリング