本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
読み書きの分割と負荷分散が重要な理由
📈 主な課題
● プライマリノードの過負荷: 読み込みが重いワークロードは、重要な書き込み操作を遅らせる。
● 高コストのスケーリング: 手動でのトラフィックルーティングにはコードの再構築やダウンタイムが必要。
● ダウンタイムのリスク: 単一障害点が事業継続性を脅かす。
🔥 なぜApsaraDB for MongoDB ConnectionStringURI + readPreferenceなのか？
✅ 少なくとも2倍の読み取りスループット: 自動的に読み取りトラフィックをセカンダリおよびReadOnlyノードに振り分け、ほぼ線形のパフォーマンススケーリングを実現。
✅ ゼロダウンタイムフェイルオーバー: シームレスなプライマリ-セカンダリ切り替え。
✅ コード変更不要: 5分で一度設定すれば良い — DevOpsの大規模な変更は不要。
1. アーキテクチャ: インテリジェントなトラフィックルーティングの仕組み
ApsaraDB for MongoDB レプリカセットアーキテクチャでは、複数のノードを使用して高可用性と読み書きの分離を実現します。
ApsaraDB for MongoDB レプリカセットにおけるノードの役割と責任
| ノードタイプ | 機能 |
|---|---|
| Primary | 強いデータ一貫性を持つ専用書き込みノード。デフォルトで全ての読み書きリクエストを処理。 |
| Secondary | リアルタイムデータ同期を行い、障害時にはプライマリに昇格。 |
| Hidden | セカンダリおよびReadOnlyノードのためのディザスタリカバリノード。 |
| ReadOnly | 専用読み込みノード。ReadOnly接続文字列URI経由でトラフィックを分散。 |
接続アドレスの比較と選択ガイド
本番環境では、ConnectionStringURIアドレスを使用してインスタンスにアクセスし、負荷分散と高可用性を確保することが企業のベストプラクティスです。一定のビジネス規模を持つ環境では通常、読み取り専用ノードが存在するため、ReadOnly Connection String URIアドレスを設定して読み取り専用アプリケーションにアクセスすることが推奨されます。
| アドレスタイプ | 含まれるノード | 機能 | 使用例 | 利点 |
|---|---|---|---|---|
| ConnectionStringURI | 全てのノード | 読み書き両方の操作をサポート | 一般的な本番ワークロード | 高可用性、読み書きの分割 |
| ReadOnly Connection String URI | ReadOnlyノードのみ | 読み取り専用操作に使用 | 分析/レポート | 100%の読み取り分離 |
接続アドレス形式
mongodb://:@:,:,...,:/?replicaSet=[&authSource=][&readPreference=][&readPreferenceTags=]
例:
mongodb://root:PassWard@dds-3nse3296743324f42.mongodb.rds.aliyuncs.com:3717,dds-3nse3xxxxxxxxxxxxx.mongodb.rds.aliyuncs.com:3717,dds-3nse3xxxxxxxxxxxxy.mongodb.rds.aliyuncs.com:3717,dds-3nse3xxxxxxxxxxxxz.mongodb.rds.aliyuncs.com:3717/admin?replicaSet=mgset-87961907
接続アドレスを取得する手順
- インスタンスリストにアクセスし、リージョンを選択して目的のインスタンスを見つけます。
- インスタンスIDをクリックし、詳細ページに入り、ホワイトリストを設定します。
注意: 本番環境では0.0.0.0/0を使用しないでください。
- インスタンス詳細ナビゲーションバーから「データベース接続」をクリックすると、エンドポイントオプションが表示されます。コンソール上で以下のすべての接続アドレスとサンプル接続文字列を見ることができます。
推奨される接続方法
● プログラムによる接続（MongoDBドライバ使用）: 推奨！公式のMongoDBドライバ（Node.js、Python、Javaなど、以下参照）を使用することで、必要なパラメータをすべて含む接続が可能となり、本番環境でのMongoDBデータベースとのより効果的で効率的なやり取りが実現されます。
● Mongo Shell接続: 非推奨。ReadOnly ConnectionStringURIでreadPreferenceやreadPreferenceTagsなどの特定のパラメータをサポートしていないため。
Mongo Shellが非推奨である理由:
-
本番利用向けではない:
Mongo Shellは主に開発および管理タスク用のコマンドラインクライアントであり、パフォーマンス最適化や大規模な設定が必要な本番環境向けには設計されていません。 -
接続文字列オプションの制限:
Mongo Shellはデータアクセスとパフォーマンスを最適化するための重要な接続文字列URIパラメータをサポートしていません。例えば、readPreferenceはMongoDBクライアントがレプリカセットのメンバーにどのように読み取り操作をルーティングするかを定義します。このオプションがない場合、プライマリ、セカンダリ、その他のメンバーからの読み取り指定ができず、潜在的なパフォーマンス問題が発生します。 -
リソースの非効率な使用:
readPreferenceを設定できない場合、クエリは常にプライマリノードにルーティングされ、そのノードの負荷が増加し、他のノードは活用されません。これはスケーラビリティと耐障害性のために設計された分散データベースシステムの目的に反します。 -
読み取りのバランス調整:
複数のレプリカセットメンバーが存在する環境では、readPreferenceによりクライアントは異なるノード間で読み取りリクエストを分散でき、パフォーマンスが向上しレイテンシが減少します。Mongo Shellの制限は不均衡なワークロードやボトルネックにつながります。 -
タグベースの読み取り優先度:
readPreferenceTagsがない場合、ユーザーは属性（タグ）に基づいてどのセカンダリノードから読み取るかを制御できません。この機能は、データのローカリティや地理的位置、ノード容量などの要件に基づいて操作をルーティングするのに便利です。 -
堅牢なエラーハンドリングの欠如:
Mongo Shellは多くの操作を実行できますが、アプリケーション向けの完全なMongoDBドライバやライブラリにあるような高度なエラーハンドリングや接続管理機能は備えていません。
Pythonによる読み書きの分割と負荷分散の例
-
PyMongoドライバをインストールします。
pip install pymongo
アプリケーションの読み書きエラーを監視する
プライマリを手動で切り替えた際、すべての書き込みと読み取りが自動的にリダイレクトされ、エラーはゼロであることが確認できます。ConnectionStringURIを使用することで、操作はプライマリ・セカンダリの切り替えに影響を受けず、ビジネスの継続性とパフォーマンスの向上が保証されます。
結論
ConnectionStringURIを使用してApsaraDB for MongoDBにアクセスすることで、ビジネスの継続性、高い安定性、およびパフォーマンスの向上が確保され、これが企業にとって最良のプラクティスとなります。
4. 実世界への影響
理想的なシナリオ
● 🛒 イーコマースのフラッシュセール: トラフィックの急増時にクエリトラフィックを分離し、チェックアウトシステムを保護します。
● 📊 リアルタイム分析: 複雑な集計処理をReadOnlyノードにオフロードします。
● 🌍 グローバルアプリケーション: readPreferenceTagsを使用して地理的に局所化された読み取りを行います。
5. 次のステップ
ApsaraDB for MongoDB を活用して、データベース操作の全潜在能力を引き出しましょう。システムの信頼性と速度を向上させ、初期コストは一切かかりません。今すぐ無料トライアルにサインアップし、当社のソリューションがどのようにビジネス運営を変革できるかをご確認ください。または、次のステップに進む準備が整っている場合は、特定のニーズに合わせたソリューションについてお問い合わせください。