アーキテクチャ - AWS 上の MongoDB

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

アーキテクチャ

AWS CloudFormation は、関連する AWS リソースのコレクションを容易に作成および管理し、整った予測可能な方法でプロビジョニングおよび更新できるようにします。

デフォルトパラメータを使用して新しい VPC にこのクイックスタートをデプロイすると、AWS クラウドで以下の MongoDB 環境が構築されます。


      図 1: AWS での MongoDB のためのクイックスタートアーキテクチャ

図 1: AWS での MongoDB のためのクイックスタートアーキテクチャ

  

以下の AWS コンポーネントは、このリファレンスデプロイの一部としてデプロイおよび設定されます。

  • 3 つのアベイラビリティーゾーンにまたがるパブリックサブネットとプライベートサブネットで設定された VPC。*

  • パブリックサブネットで、プライベートサブネット内のリソース (MongoDB インスタンス) へのアウトバウンドインターネット接続を許可する NAT ゲートウェイ。(詳細については、「」を参照してください。Amazon VPC クイックスタート。 ) *

  • パブリックサブネットで、Elastic IP アドレスが割り当てられ、インバウンドセキュアシェル (SSH) アクセスを許可する、Auto Scaling グループの踏み台ホスト。1 つの踏み台ホストがデフォルトでデプロイされますが、この数は設定可能です (詳細については「Linux 踏み台ホストクイックスタート」を参照)。*

  • AnAWS Identity and Access Managementデプロイプロセスには、AWS サービスへの詳細に調整されたアクセス許可を持つ (IAM) インスタンスロールが必要です。

  • VPC 内での通信を可能にし、必要なプロトコルとポートのみにアクセスを制限するセキュリティグループ。

  • プライベートサブネットで、カスタマイズ可能な MongoDB クラスター (スタンドアロンで実行するかレプリカセットで実行するかは選択可能)、およびカスタマイズ可能な Amazon EBS ストレージ。クイックスタートは、レプリカセットの各メンバーをそれぞれ異なるアベイラビリティーゾーンに起動します。ただし、3 つ以上のアベイラビリティーゾーンを提供しない AWS リージョンを選択した場合、クイックスタートはいずれかのゾーンを再利用して 3 番目のサブネットを作成します。

* 新しい VPC に対してクイックスタートを起動するか、既存の VPC を使用するかを選択できます。クイックスタートを既存の VPC にデプロイするテンプレートは、アスタリスクでマークされたコンポーネントの作成をスキップし、既存の設定を求めます。

クイックスタートは、すべての MongoDB 関連ノードをプライベートサブネットで起動します。そのため、ノードは SSH を使用してアクセスされ、踏み台ホストに接続します。MongoDB インスタンスごとにリモートアクセス CIDR を使用する代わりに、リモートアクセスを一元的に制御できるように、デプロイには踏み台ホストのセキュリティグループ ID が必要です。新しい VPC に対してクイックスタートを起動すると、踏み台セキュリティグループが作成されます。既存の VPC でクイックスタートを起動する場合は、踏み台ホストのセキュリティグループを作成するか、既存のものを使用する必要があります。

MongoDB の構造

リファレンスデプロイで使用される構成要素の例を示します。

レプリカセット。同じデータを保持するmongod インスタンスのグループを指します。レプリケーションの目的は、1 つのサーバーがダウンした際に高可用性を確保することです。このリファレンスデプロイでは 1 つまたは 3 つのレプリカセットをサポートしています。レプリカセットが 3 つの場合、リファレンスデプロイは 3 つのサーバーを 3 つの異なるアベイラビリティーゾーンで起動します (リージョンがサポートしている場合)。実稼働用クラスターでは、3 つのレプリカセット (PrimarySecondary0Secondary1) を使用することが推奨されます。

すべてのクライアントは、通常プライマリノードを操作して読み取りや書き込みのオペレーションを実行します。読み取りオペレーションでは、プリファレンスとしてセカンダリノードを設定できますが、書き込みオペレーションは必ずプライマリノードで行われ、セカンダリノードで非同期にレプリケートされます。読み取りオペレーションでセカンダリノードを選択する場合は、古いデータに注意する必要があります。これは、セカンダリノードがプライマリノードと同期されていない場合があるためです。読み取りオペレーションがどのようにレプリカセットにルーティングされるかについては、MongoDB ドキュメントを参照してください。

開発環境では、1 つのレプリカセットから始めて、本稼働中に 3 つのレプリカセットに移行できます。図 2 にレプリケーション係数 3 の MongoDB リファレンスデプロイを示します。


        3 つのレプリカセットを使用する AWS の MongoDB クラスター

図 2: 3 つのレプリカセットを使用する AWS の MongoDB クラスター

  

プライマリインスタンスに障害が発生した場合、別のアベイラビリティーゾーンのセカンダリインスタンスの 1 つが新しいプライマリノードとなり、自動フェイルオーバーが確実に実行されます。

シャーディング。複数のノードに渡るデータのディストリビューションを指します。複数のノードに渡って異なるデータを保存することで、読み取りや書き込みのパフォーマンスのための水平方向のスケーラビリティが実現します。データセットが大きい場合、単一ノードでは CPU または I/O パフォーマンスによってボトルネックが発生することがあります。シャーディングは、シャードノードが処理するオペレーションの数を減らし、クラスター全体のパフォーマンスを向上させることで、このボトルネックを解決します。このクイックスタートでは、シャーディングは直接サポートされていません。代わりに、起動されたレプリカセットをシャードされたクラスターに参加させるためのパラメータ (ReplicaShardIndex) が用意されています。詳細については、MongoDB のドキュメントを参照してください。

パフォーマンスに関する考慮事項

リファレンス実装ではコンピューティングとストレージの様々な選択肢が示されます。次の表に、コンピューティングの選択肢の例を示します。

インスタンスタイプ vCPU メモリ (GiB) ワークロードタイプ
c3.4xlarge 16 55 コンピューティング最適化
c3.8xlarge 32 60 コンピューティング最適化
c4.8xlarge 36 60 コンピューティング最適化
r3.4xlarge 16 122 メモリ最適化
r3.2xlarge 8 61 メモリ最適化
r3.8xlarge 32 244 メモリ最適化

一般的なガイドラインとして、垂直方向ではなく水平方向にインスタンスを増加させることを検討します。水平方向のスケーリングにより、シングルノードの制限を克服し、単一障害点を回避し、さらにクラスター全体のスループットを潜在的に向上させることができます。

ストレージについては、データベースの要件によって、各ノードにアタッチされるストレージボリュームを変更することができます。Amazon EBS には次の 3 つのボリュームタイプがあります。[汎用 (SSD)]、[プロビジョンド IOPS (SSD)]、[マグネティック]。これらはパフォーマンス特性とコストが異なるため、アプリケーションのニーズに応じて適切なストレージパフォーマンスと料金を選択できます。Amazon EBS ボリュームタイプはすべて、耐久性に優れた同じスナップショット機能を備え、99.999% の可用性を保証します。このリファレンスデプロイは、汎用ストレージボリュームとプロビジョンド IOPS ストレージボリュームをサポートします。

次の表に、各ストレージのタイプのパフォーマンス特性の一部を示します。パフォーマンス要件によっては、ストレージタイプや Amazon EBS プロビジョンド IOPS 容量 (選択している場合) を決定する前にアプリケーションをベンチマークすることが必要な場合があります。

ボリュームタイプ 汎用 (SSD) プロビジョンド IOPS (SSD)
ストレージメディア SSD タイプ SSD タイプ
最大ボリュームサイズ 16 TiB 16 TiB
最大 IOPS/ボリューム 10,000 20,000