すべてのプロダクト
Search

このプロダクト

    ApsaraDB for MongoDB:チェーンレプリケーションがインスタンスのパフォーマンスに与える影響のテスト

    ドキュメントセンター

    ApsaraDB for MongoDB:チェーンレプリケーションがインスタンスのパフォーマンスに与える影響のテスト

    最終更新日:Apr 04, 2025

    このトピックでは、Elastic Compute Service（ECS）を ApsaraDB for MongoDB レプリカセットインスタンスに接続することで、チェーンレプリケーションがインスタンスのパフォーマンスに与える影響をテストおよび分析する方法について説明します。

    チェーンレプリケーション

    チェーンレプリケーションとは

    MongoDB はチェーンレプリケーションをサポートしています。 チェーンレプリケーションは、レプリカセットのセカンダリノードが別のセカンダリノードからデータを同期するときに発生します。 チェーンレプリケーションはプライマリノードの負荷を軽減できますが、異なるネットワークトポロジではプライマリとセカンダリのレイテンシが長くなる可能性があります。 詳細については、「セルフマネージドチェーンレプリケーション」をご参照ください。

    チェーンレプリケーションは、すべてのノードが単一のチェーン構造を形成する必要があるという意味ではありません。 代わりに、セカンダリノードは、ネットワークの往復時間（RTT）などの情報に基づいて、プライマリノード以外のノードを同期ソースとして選択できます。 5 ノードレプリカセットトポロジを例にとると、次の図に示すネットワークトポロジはすべてチェーンレプリケーションの例です。

    チェーンレプリケーションの構成

    [パラメーター] ページの settings.chainingAllowed パラメーターを調整して、コンソールでチェーンレプリケーションを有効または無効にすることができます。 パラメーターの調整方法については、「データベースパラメーターを設定する」をご参照ください。

    場合によっては、チェーンレプリケーションがプライマリとセカンダリの同期レイテンシを引き起こす可能性があります。 同期パフォーマンスを最適化するために、チェーンレプリケーションを無効にすることができます。

    説明

    セキュリティ上の理由から、ApsaraDB for MongoDB インスタンスで replSetReconfig コマンドを実行する権限はありません。 コンソールから関連するパラメーターを調整してください。

    インスタンスのパフォーマンス影響テスト

    テスト環境

    ECS インスタンスと ApsaraDB for MongoDB レプリカセットインスタンスを作成します。 作成方法については、「レプリカセットインスタンスを作成する」および「ECS インスタンスを使用して ApsaraDB for MongoDB インスタンスに接続する（Express Connect）」をご参照ください。

    • ApsaraDB for MongoDB インスタンスアーキテクチャ：標準レプリカセットトポロジ（3 つのノード。1 つのプライマリノード、1 つのセカンダリノード、1 つの Hidden ノードを含む）、セカンダリノードと読み取り専用ノードを追加することでレプリカセットノードを拡張。

    • ECS インスタンスと MongoDB インスタンス間のネットワーク往復時間：テストインスタンスは同じリージョンとゾーンにあり、平均 RTT（Round-Trip Time）は 0.103 ミリ秒です。

    次の表に、テストで使用した ECS インスタンスと ApsaraDB for MongoDB インスタンスの構成を示します。

    構成項目

    ECS インスタンス

    ApsaraDB for MongoDB ディスクベースインスタンス

    リージョンとゾーン

    中国（北京）ゾーン H

    中国（北京）ゾーン H

    ネットワークタイプ

    仮想プライベートクラウド（VPC）

    仮想プライベートクラウド（VPC）

    インスタンスファミリー

    コンピューティング最適化 c6

    専用

    インスタンスタイプ

    ecs.c6.xlarge(4c8g)

    ecs.c7.xlarge(4c8g)

    ストレージクラス

    ESSD PL0

    ESSD PL1

    イメージバージョン

    Alibaba Cloud Linux 3.2104 LTS 64 ビット

    4.19.91-26.al7.x86_64

    カーネルバージョン

    該当なし

    メジャーバージョン：5.0

    マイナーベースラインバージョン：5.0.30

    テストツール

    テストでは、オープンソースの Yahoo Cloud Serving Benchmark（YCSB）0.17.0 ツールを使用します。

    説明

    YCSB は Java で記述されたパフォーマンステストツールであり、複数のデータベースをサポートしています。 YCSB のインストールと使用方法については、「YCSB」をご参照ください。

    テスト手順

    1. ホワイトリストを追加する。 ECS コンソールにログインし、インスタンス詳細ページの [ネットワーク情報] セクションで ECS インスタンスのプライマリ プライベート IP アドレスを表示し、ECS インスタンスのプライマリ プライベート IP アドレスを ApsaraDB for MongoDB インスタンスのホワイトリストに追加します。

    2. ECS インスタンスに接続する。

    3. YCSB ツールを使用して、テスト用のデータをロードします。

      ./bin/ycsb.sh load mongodb -s -p workload=site.ycsb.workloads.CoreWorkload -p recordcount=5000000 -p mongodb.url="mongodb://test:****@dds-bp13e84d11****.mongodb.rds.aliyuncs.com:3717/admin" -p table=test -threads 8

      パラメーターの説明：

      • recordcount：ApsaraDB for MongoDB インスタンスにロードされたレコードの総数。

      • mongodb.url：ApsaraDB for MongoDB インスタンスの接続アドレス。 このテストでは、データベースアカウントは test、データベースは admin です。 ApsaraDB for MongoDB コンソールにログインし、[データベース接続] ページの [プライベートネットワーク接続 - VPC] セクションで接続アドレスを表示できます。

      • threads：クライアントでの同時スレッド数。

    4. YCSB テスト結果とテストインスタンスのモニタリング情報を表示します。 [モニタリングデータ] ページで、[監視データ][ノードモニタリング] タブをクリックし、このテストに対応する期間を選択して、インスタンスのプライマリノードの [CPU 使用率]、[操作 QPS]、および ノード監視（旧ベーシック監視） メトリックを表示します。 詳細については、「」をご参照ください。

    テスト結果

    パラメーターの説明

    Write Concern：データ永続性の保証レベル。書き込み操作が正常に完了したと見なされるために満たす必要がある条件を決定します。 テスト結果の関連値は次のとおりです。

    • {w:"majority"}：デフォルトの構成。書き込み操作は、レプリカセット内のノードの大部分に複製された後にのみ完了として確認されることを意味します。

    • {w: 1}：プライマリノードのみが完了を確認する必要があることを意味します。

    テスト結果の詳細

    3 ノード

    レプリカセットトポロジ：1 プライマリノード、1 セカンダリノード、1 Hidden ノード。

    WriteConcern は {w:"majority"}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    5277

    5241

    CPU 使用率

    65%

    65%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    Writeconcern は {w:1}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    15075

    14785

    CPU 使用率

    93%

    93%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    7 ノード

    レプリカセットトポロジ：1 プライマリノード、5 セカンダリノード、1 Hidden ノード。

    Writeconcern は {w:"majority"}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    3005

    4312

    CPU 使用率

    56%

    85%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    WriteConcern は {w:1}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    14414

    11492

    CPU 使用率

    91%

    93%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    15 ノード

    レプリカセットトポロジ：1 プライマリノード、5 セカンダリノード、1 Hidden ノード、8 読み取り専用ノード。

    7 つの投票ノードと 8 つの非投票ノードが含まれます（読み取り専用ノードは投票に参加しません）。

    Writeconcern は {w:"majority"}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    2932

    3123

    CPU 使用率

    58%

    91%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    WriteConcern は {w:1}

    比較項目

    チェーンレプリケーション有効

    チェーンレプリケーション無効

    スループット（ops）

    14093

    7500

    CPU 使用率

    90%

    94%

    操作 QPS（回数）

    image.png

    image.png

    平均応答時間 RT（マイクロ秒）

    image.png

    image.png

    パフォーマンスの比較とまとめ

    • 同じノード数の場合、チェーンレプリケーションを無効にすると書き込みパフォーマンスが低下するかどうかは、writeConcern の構成によって異なります。

      WriteConcern は {w:1}

      • 3 ノードインスタンスの場合、チェーンレプリケーションを無効にすることによるパフォーマンスの低下はごくわずかです。

      • 7 ノードインスタンスの場合、チェーンレプリケーションを無効にすると、約 20.3% のパフォーマンス低下が発生します。

      • 15 ノードインスタンスの場合、チェーンレプリケーションを無効にすると、最大 46.8% のパフォーマンス低下が発生し、チェーンレプリケーションを無効にした後、プライマリノードの CPU 使用率が著しく増加することが観察されます。

      Writeconcern は {w:"majority"}

      • 3 ノードインスタンスの場合、チェーンレプリケーションを無効にすることによるパフォーマンスの低下はごくわずかです。

      • 7 ノードインスタンスと 15 ノードインスタンスの場合、チェーンレプリケーションを無効にすると、実際には約 6.5%～43.5% のパフォーマンスが向上する可能性があります。

        パフォーマンス向上の理由：チェーンレプリケーションを無効にすると、レプリカセット内の全体的な同期リンクが短縮され、majority 条件を満たしやすくなるため、単一の書き込み操作のレイテンシが短縮されます。

        非投票ノードの影響：非投票ノードの数が増加するにつれて（投票ノードの数は 7 に固定）、チェーンレプリケーションを無効にすることによるパフォーマンスの向上はそれほど顕著ではなくなります。 これは、プライマリノードのプライマリとセカンダリの同期負荷が高いためです。

    • 同じ chainingAllowed および writeConcern 構成の場合、ノード数が増加するにつれて書き込みパフォーマンスは低下します。 さらに、チェーンレプリケーションを無効にした後、ノード数の増加に伴う書き込みパフォーマンスの低下はさらに顕著になります。

      • デフォルト構成（chainingAllowed:true+writeConcern:{w:"majority"}）では、レプリカセットに含めることができる投票ノードは 7 つまでであるため、majority を満たす条件は変わりません。 したがって、ノード数を 7 から 15 に拡張する場合、書き込みパフォーマンスの低下はそれほど顕著ではありません。

      • チェーンレプリケーションが無効になっているかどうかに関係なく、writeConcern:{w:1} のパフォーマンスは writeConcern:{w:"majority"} よりも大幅に優れています。これは writeConcern の設計と一致しています。

      • writeConcern 構成が固定されている場合、ノード数が増加するにつれて、チェーンレプリケーションを無効にすると、チェーンレプリケーションを有効にした場合と比較して、プライマリノードの CPU 使用率が大幅に増加します。

    ベストプラクティス

    • ノード数が少ない場合は、必要に応じてチェーンレプリケーションを有効または無効にすることができます。 インスタンスの全体的なパフォーマンスは基本的に影響を受けず、CPU 使用率の差はわずかです。

    • ノード数が多い場合：

      • writeConcern が {w:1} の場合は、チェーンレプリケーションを有効にすることをお勧めします。

      • writeConcern が {w: "majority" } の場合は、プライマリノードの負荷（CPU 使用率など）とインスタンスのパフォーマンスの間でさらにトレードオフを行う必要があります。 チェーンレプリケーションを無効にすると、書き込みパフォーマンスは向上しますが、プライマリノードの負荷も大幅に増加します。