Amazon Aurora リードレプリカが遅れて再起動された理由は何ですか?

AuroraReplicaLag は、プライマリ Aurora DB インスタンスから Aurora DB クラスターのリーダーノードに更新をレプリケートするときの遅延の測定値 (ミリ秒単位) です。Aurora レプリカは、プライマリ DB インスタンスと同じストレージボリュームに接続し、読み取りオペレーションのみをサポートします。プライマリノードとリーダーノードの間の遅延は、Amazon CloudWatch の AuroraReplicaLag メトリクスを使用して測定できます。

Aurora PostgreSQL DB クラスターの場合、AuroraReplicaLag メトリクスは、プライマリ DB インスタンスのページキャッシュと比較した Aurora レプリカのページキャッシュの遅延を示します。つまり、データがクラスターボリュームに書き込まれた後は、ライターノードとリーダーノードの両方からほぼリアルタイムにアクセスできます。

変更がリーダーノード間で伝達されるようにするには、読み込み整合性のためにキャッシュされたデータを無効にする必要があります。場合によっては、リーダーノード間で変更を伝達するときに遅延が生じることがあります。これは、CloudWatch の AuroraReplicaLag メトリクスを増やすことで確認できます。最終的には再起動を行います。

Aurora MySQL の場合、次のように INFORMATION_SCHEMA.REPLICA_HOST_STATUS テーブルを使用して AuroraReplicaLag に関するほぼリアルタイムのメタデータを測定できます。

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  |
+---------------------+--------+-------------------+
| primary-instance    | writer |                 0 |
| reader-node-02      | reader | 5.150000095367432 |
| reader-node-03      | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

Aurora PostgreSQL の場合は、aurora_replica_status() 関数を呼び出し、次のように結果をフィルタリングします。

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

  server_id   |  role  | aurorareplicalag 
--------------+--------+---------------------
 read-node-01 | Reader |                 71
 read-node-02 | Reader |                 79
 primary-node | Writer |                    

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

読み取りノードの DB インスタンスクラス設定がライター DB インスタンスより弱い場合、変更ボリュームが大きすぎて、リーダーがキャッシュで無効化して追いつくことができません。このシナリオでは、Aurora クラスター内のすべての DB インスタンスの仕様が同じであることを確認することをお勧めします。

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

リーダーノードでは、複数のセッションが同時に実行されているときに遅延が発生することがあります。Aurora レプリカは、利用可能なリソースがないため、マスターから必要な変更を適用するのに時間がかかることがあります。CPUUtilization、DBConnections、NetworkReceiveThroughput、および ActiveTransactions などのメトリクスを使用して視覚化できます。

Aurora PostgreSQL の場合は、ActiveTransactions の代わりに ReadIOPS メトリクスを使用します。拡張モニタリング を 5/1 秒以上、有効にすることで、リーダーノードの使用状況を把握できます。Performance Insights を使用してワークロードを視覚化することもできます。

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

既に書き込みが多い本稼働クラスターで書き込みアクティビティが急激に急増すると、ライター DB インスタンスの過負荷が発生する可能性があります。急増によって生じるストレスが増えると、リーダーノードが遅れることがあります。これは、Amazon CloudWatch を使用して可視化できます。Amazon CloudWatch では、DMLThroughput、DDLThroughpu、および Queries メトリクスの急激なバーストを確認できます。

Aurora PostgreSQL の場合、WriteThroughPut メトリクスを使用して可視化できます。

さらに長くなる履歴リストの長さ (HLL) を調べる (Aurora MySQL)

MySQL の InnoDB エンジンには、デフォルトでマルチバージョンの同時実行制御 (MVCC) が組み込まれています。トランザクションの長さを通じて影響を受けるすべての行で発生したすべての変更を追跡する必要があります。長時間実行されるトランザクションが完了すると、パージスレッドアクティビティの急増が始まります。長時間実行されるトランザクションによって作成されるバックログのボリュームが原因で、突然のパージにより Aurora レプリカが遅れることがあります。

1.19.2 および 2.06 の時点で、Aurora MySQL には 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 ストレージレイヤーの間で一時的なネットワーク通信障害が発生する可能性があります。リーダーノードは、ネットワーキングの短時間の中断により、遅れたり、再起動したりすることがあります。Aurora レプリカは、大量の変更、または AZ 間パケット損失の短い瞬間により、ネットワークの飽和が原因で遅れることがあります。この問題を回避するには、DB インスタンスのサイズとネットワーク機能を考慮する必要があります。

考慮すべき重要な注意事項

Aurora MySQL 1.x には、1.17.4 以降で注意が必要な注目すべき機能がいくつかあります。

• aurora_enable_replica_log_compression は、レプリケーションペイロードの圧縮を有効にして、マスターと Aurora レプリカ間のネットワーク帯域幅使用率を向上させるクラスターパラメータです。これは、ネットワークの飽和が明らかである場合に便利です。

• aurora_enable_zdr は開いている接続を維持し、Aurora レプリカの再起動時にそれらを保持するために利用できるクラスターパラメータです。

• aurora_enable_staggered_replica_restart は、Aurora レプリカがずらされた再起動スケジュール通りにクラスターの可用性を高めることができるクラスターパラメータです。