実践！AWS環境でのMongoDB構築・設定ガイド

By /

はい、承知いたしました。「実践！AWS環境でのMongoDB構築・設定ガイド」の詳細な説明を含む記事を、約5000語のボリュームで直接出力します。

実践！AWS環境でのMongoDB構築・設定ガイド

はじめに：MongoDBとAWS環境で構築する意義

近年、様々なアプリケーション開発において、柔軟性とスケーラビリティに富んだデータベースが求められています。リレーショナルデータベース（RDB）が長らく主流でしたが、非構造化データや半構造化データの増加、高いスケーラビリティ要件、アジャイルな開発スタイルへの適合性から、NoSQLデータベースの利用が広がっています。

NoSQLデータベースの中でも、MongoDBはドキュメント指向データベースとして広く認知されています。JSONライクなBSON形式でデータを保存するため、スキーマの変更が容易で、アプリケーションの変更に柔軟に対応できます。また、豊富な機能（レプリカセットによる高可用性、シャーディングによる水平スケーラビリティ）を備えており、小規模な開発から大規模な本番環境まで対応可能です。

一方、クラウドコンピューティングプラットフォームであるAWS (Amazon Web Services) は、高い信頼性、スケーラビリティ、豊富なサービス群を提供しています。データベースを含む様々なインフラストラクチャをオンデマンドで利用でき、運用負荷を軽減するためのマネージドサービスも充実しています。

MongoDBをAWS環境で構築することで、MongoDBの柔軟性とAWSの堅牢性・スケーラビリティを組み合わせ、高性能かつ可用性の高いアプリケーション基盤を構築できます。しかし、AWS上でMongoDBをどのように構築し、適切に設定・運用していくかについては、いくつかの選択肢と考慮すべき点があります。

この記事では、AWS環境でMongoDBを構築・設定するための実践的なガイドを提供します。特に、AWSの各種サービス（EC2, VPC, Security Group, EBSなど）を活用したセルフマネージドなMongoDBの構築方法に焦点を当てつつ、AWSが提供するマネージドサービスやMongoDB社が提供するクラウドサービスについても触れ、それぞれのメリット・デメリットや選択肢について解説します。対象読者は、AWSの基本的な操作経験があり、AWS上でMongoDBを構築・運用したいと考えているエンジニアの方々です。

AWS上でMongoDBを構築する方法の選択肢

AWS上でMongoDBを構築するには、主に以下の3つの方法があります。それぞれの方法にはメリット・デメリットがあり、アプリケーションの要件、運用体制、コストなどを考慮して選択する必要があります。

  1. セルフマネージド (Self-Managed) on EC2
    AWSの仮想サーバーサービスであるAmazon EC2インスタンスを準備し、その上に自身でMongoDBソフトウェアをインストール、設定、運用管理を行う方法です。

    • メリット:
      • 高いカスタマイズ性: OSの選択、MongoDBのバージョン、ストレージ構成、ネットワーク設定など、環境を細かく制御できます。
      • 既存の構築・運用ノウハウを活用しやすい: オンプレミス環境や他のクラウド環境でMongoDBの構築・運用経験があれば、その知識を活かせます。
      • 特定のバージョンやプラグインが必要な場合に適しています。
      • 場合によっては、マネージドサービスよりもコストを抑えられる可能性があります（ただし、運用コストは別途かかります）。
    • デメリット:
      • 運用負荷が高い: OSやMongoDBのインストール、設定、パッチ適用、バックアップ、監視、スケーリング、高可用性の維持など、多くの運用タスクを自身で行う必要があります。
      • 専門知識が必要: MongoDBやOS、AWSインフラに関する深い知識が求められます。
      • 構築に時間がかかる可能性があります。

  2. Amazon DocumentDB (with MongoDB compatibility)
    AWSが提供するマネージドなドキュメントデータベースサービスです。MongoDBと互換性のあるAPIを提供しており、既存のMongoDBアプリケーションを変更せずに利用できることを目指しています。

    • メリット:
      • 運用負荷の大幅な軽減: AWSがインフラの管理、パッチ適用、バックアップ、スケーリング、高可用性の維持などを担当します。
      • 高い可用性と耐久性: デフォルトで複数AZにレプリケーションされ、ストレージは自動的に拡張・縮小されます。
      • スケーラビリティ: リードレプリカを容易に追加でき、必要に応じてインスタンスサイズを変更できます。
      • セキュリティ: VPC内にデプロイされ、IAMとの統合も可能です。
    • デメリット:
      • MongoDBとの完全な互換性はない: MongoDBの全ての機能やコマンドがサポートされているわけではありません。特に、バージョンアップされたばかりのMongoDBの機能や、特定の管理コマンド、ストレージエンジンに関する機能はサポートされていない場合があります。
      • カスタマイズ性の制限: OSやMongoDBの設定、ストレージエンジンの選択などに制約があります。
      • セルフマネージドに比べてコストが高くなる場合があります。
      • リアルタイム性の高い変更ストリーム機能（Change Streams）などに一部制約がある場合があります。

  3. MongoDB Atlas (on AWS)
    MongoDB社が提供するフルマネージドなクラウドデータベースサービスです。AWS、Azure、GCPなどの主要なクラウドプラットフォーム上で利用できます。

    • メリット:
      • MongoDBの公式サービス: 最新のMongoDBバージョンと全ての機能を利用できます。
      • 運用負荷の大幅な軽減: インフラ管理、バックアップ、スケーリング、パッチ適用などをMongoDB社が担当します。
      • マルチクラウド対応: 将来的に他のクラウド環境に移行する可能性がある場合に柔軟に対応できます。
      • 豊富な追加機能: 統合監視ツール、自動スケーリング、高性能検索機能 (Atlas Search)、データレイク機能 (Atlas Data Lake) など、MongoDB Atlas独自の機能を利用できます。
    • デメリット:
      • コスト: 一般的に、セルフマネージドやDocumentDBに比べて高価になる傾向があります。
      • AWSのサービスとの連携に一部制約がある場合がある（例えば、VPCピアリングやPrivateLinkの設定が必要）。
      • ベンダーロックイン: MongoDB Atlas独自の機能に深く依存すると、他の環境への移行が難しくなる可能性があります。

この記事では、最もカスタマイズ性が高く、AWSインフラの理解を深める上で有益な「セルフマネージド (Self-Managed) on EC2」の方法を中心に、その詳細な構築・設定手順と運用について解説します。DocumentDBやMongoDB Atlasについても、後半で簡単な概要と比較検討のポイントを補足します。

セルフマネージド MongoDB on EC2 構築

ここでは、単一インスタンスでの構築から始め、高可用性を実現するためのレプリカセット構成までをステップバイステップで解説します。

前提知識と準備

  • AWSアカウント: AWSのサービスを利用するためのアカウントが必要です。
  • VPC (Virtual Private Cloud): 仮想ネットワーク環境。MongoDBサーバーを配置するVPCを準備します。
  • サブネット: VPC内のネットワーク区画。可用性を高めるために、複数のアベイラビリティゾーン (AZ) に跨がるプライベートサブネットに配置することを推奨します。
  • セキュリティグループ (Security Group): インスタンスレベルのファイアウォール。MongoDBへのアクセスを制御するために設定します。
  • EC2インスタンスの基本操作: インスタンスの起動、停止、SSH接続などの操作ができる必要があります。
  • SSHクライアント: EC2インスタンスに接続するためのツール（Tera Term, RLogin, OpenSSHなど）。

1. VPCとサブネットの設計

セキュリティと可用性の観点から、MongoDBサーバーはインターネットから直接アクセスできないプライベートサブネットに配置するのが一般的です。アプリケーションサーバーなどが配置されているサブネット、または管理用の踏み台サーバーが配置されているサブネットからのみアクセスできるように設計します。

  • VPC: アプリケーションが使用するVPC内に構築します。
  • サブネット: 少なくとも2つ、理想的には3つ以上の異なるAZに跨がるプライベートサブネットを用意します。レプリカセットを構成する際に、各メンバーを異なるAZに配置することで、1つのAZ障害が発生してもサービスを継続できるようにします。
  • ルートテーブル: プライベートサブネットからのアウトバウンド通信（OSアップデートやMongoDBリポジトリへのアクセスなど）が必要な場合は、NAT GatewayやNAT Instanceを経由するように設定します。インターネットからのインバウンド通信は原則として許可しません。

2. セキュリティグループの設定

MongoDBサーバーへのアクセスを厳密に制御するセキュリティグループを作成します。デフォルトのMongoDBポートは27017です。

  • インバウンドルール:
    • タイプ: カスタムTCPルール
    • ポート範囲: 27017
    • ソース: MongoDBにアクセスする必要があるリソース（例: アプリケーションサーバーが配置されているセキュリティグループ、管理用踏み台サーバーのIPアドレスまたはセキュリティグループ、開発者のIPアドレスなど）。0.0.0.0/0 (どこからでも) を許可するのは絶対に避けてください。
    • 説明: (任意) ルールの目的を記述します。
  • アウトバウンドルール:
    • 通常は全てのトラフィックを許可 (0.0.0.0/0) しますが、必要に応じて制限することも可能です。例えば、他のMongoDBメンバーへの通信や、外部リポジトリへの通信などを許可します。レプリカセットを組む場合は、メンバー間の27017ポートでの通信を許可する必要があります（通常は同じセキュリティグループをソースに指定することで実現）。

このセキュリティグループを、MongoDBサーバーとして起動するEC2インスタンスに適用します。

3. EC2インスタンスの準備

MongoDBサーバーとして使用するEC2インスタンスを起動します。レプリカセットを構成する場合は、複数のインスタンス（通常は3つ以上）を起動し、それぞれ異なるAZのプライベートサブネットに配置します。

  • AMI (Amazon Machine Image): OSを選択します。MongoDBの公式ドキュメントでサポートされているOS（Amazon Linux 2/2023, Ubuntu LTS, RHEL, CentOSなど）を選択することをお勧めします。ここでは、例としてAmazon Linux 2023を使用することを想定します。
  • インスタンスタイプ: CPU、メモリ、ネットワーク性能などを考慮して選択します。MongoDBはメモリを積極的に使用するため、十分なメモリを持つインスタンスタイプ（例: r6g, m6g, m5, c5ファミリーなど）が良いでしょう。データベースの負荷に応じて適切なサイズを選択してください。
  • ストレージ (EBS Volume): データベースのデータファイルやジャーナルファイルが保存されるため、I/O性能が重要です。
    • ボリュームタイプ:
      • gp3 (General Purpose SSD): 汎用的なワークロードに適しており、ベースライン性能に加えて追加のIOPS/スループットをプロビジョニングできます。多くの場合、これで十分です。
      • io2 (Provisioned IOPS SSD): 高いI/O性能が求められるミッションクリティカルなデータベースワークロードに適しています。プロビジョニングしたIOPSとスループットが保証されますが、コストは高くなります。
      • st1 (Throughput Optimized HDD) や sc1 (Cold HDD) は、データベースには一般的に不向きです。
    • 容量: 保存するデータ量に加えて、将来の増加分、ジャーナルファイル、OSやMongoDBソフトウェアの領域などを考慮して決定します。
    • 構成: データの永続性とパフォーマンスのために、ルートボリュームとは別に、専用のEBSボリュームをアタッチし、それをMongoDBのデータディレクトリ (dbPath) およびジャーナルディレクトリに使用することを強く推奨します。これにより、OSとデータベースI/Oを分離できます。ジャーナルファイルを別のディスクに配置することもパフォーマンス向上に繋がる場合がありますが、多くの場合はデータファイルと同じディスクで問題ありません。
    • 暗号化: 機密性の高いデータを扱う場合は、EBSボリュームの暗号化を有効にすることを検討してください。KMS (Key Management Service) と連携して容易に設定できます。
  • キーペア: SSH接続のために必要です。既存のものを使用するか、新しく作成します。
  • ユーザーデータ (Optional): インスタンス起動時に自動実行されるスクリプトを記述できます。OSの初期設定や、MongoDBのインストールコマンドなどを自動化するのに役立ちます。

インスタンスを起動したら、SSHで接続できることを確認します。プライベートサブネットに配置した場合は、踏み台サーバーを経由するか、AWS Systems Manager Session Managerなどの方法で接続します。

4. ストレージの準備とマウント

アタッチしたEBSボリュームをインスタンス内でフォーマットし、適切なディレクトリにマウントします。

  1. アタッチしたボリュームの確認:
    bash
    $ sudo fdisk -l
    # または
    $ lsblk
    /dev/nvme1n1 のようなデバイス名で表示されることが多いです。
  2. ファイルシステムの作成:
    bash
    $ sudo mkfs -t ext4 /dev/nvme1n1 # または xfs など、お好みのファイルシステムで
  3. マウントポイントディレクトリの作成: MongoDBのデータディレクトリとして使用するディレクトリを作成します。
    bash
    $ sudo mkdir /data/db
  4. ボリュームのマウント:
    bash
    $ sudo mount /dev/nvme1n1 /data/db
  5. 起動時の自動マウント設定: /etc/fstab にエントリを追加し、インスタンス再起動時にも自動的にマウントされるようにします。
    まず、ボリュームのUUIDを確認します。
    bash
    $ sudo blkid
    /etc/fstab を編集します。
    bash
    $ sudo vi /etc/fstab
    以下の形式でエントリを追加します（UUIDは取得した値に置き換えてください）。
    UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data/db ext4 defaults,nofail 0 2
    nofail オプションを付けることで、マウントに失敗してもOSの起動が止まらないようにできます。
  6. ディレクトリの所有者変更: MongoDBプロセスが書き込めるように、権限を変更します。デフォルトのMongoDB実行ユーザーは mongod です。
    bash
    $ sudo chown mongod:mongod /data/db
    （mongod ユーザー/グループはMongoDBインストール時に作成されます。インストール前にこのステップを行う場合は、一時的にEC2ユーザーなどで所有権を設定し、インストール後にmongodユーザーに再設定するか、インストール後にこのステップを行ってください。）

5. MongoDBのインストール

使用するOSに合わせて、MongoDBの公式リポジトリを追加し、パッケージマネージャー (apt or yum/dnf) を使用してインストールします。ここではAmazon Linux 2023を例に説明します。他のOSの場合は公式ドキュメントを参照してください。

  1. MongoDB公式リポジトリの設定ファイルを作成:
    bash
    $ sudo vi /etc/yum.repos.d/mongodb-org-6.0.repo
    ファイルの内容を以下のように記述します（バージョンは適宜変更してください。ここでは6.0を例とします）。

    ini
    [mongodb-org-6.0]
    name=MongoDB Repository
    baseurl=https://repo.mongodb.org/yum/amazon/2023/mongodb-org/6.0/x86_64/
    gpgcheck=1
    enabled=1
    gpgkey=https://www.mongodb.org/static/pgp/server-6.0.asc
    注意: Amazon Linux 2023はまだ比較的新しいため、リポジトリのパスやGPGキーが変更される可能性があります。最新の情報はMongoDB公式ドキュメントで確認してください。

  2. MongoDBパッケージのインストール:
    bash
    $ sudo dnf install -y mongodb-org
    これにより、mongod (データベースデーモン)、mongosh (シェル)、各種ユーティリティ (mongodump, mongorestore, mongostat, mongotopなど) がインストールされます。

6. MongoDBの設定 (mongod.conf)

MongoDBの設定は /etc/mongod.conf ファイルで行います。デフォルトの設定ファイルを編集します。

bash
$ sudo vi /etc/mongod.conf

主要な設定項目を以下に示します。

  • storage: ストレージエンジンやデータファイルのパスなどを設定します。
    • dbPath: データベースファイルが保存されるパス。上でマウントしたEBSボリュームのパスを指定します。
      yaml
      storage:
      dbPath: /data/db
      journal:
      enabled: true # ジャーナリングを有効化（データの耐久性向上）
      engine: wiredTiger # ストレージエンジン（デフォルトはWiredTiger）
      # wiredTiger: # WiredTigerエンジンの詳細設定（必要に応じて）
      # engineConfig:
      # cacheSizeGB: <メモリサイズの50%程度を目安に> # キャッシュサイズ
      cacheSizeGB は非常に重要な設定です。サーバーの搭載メモリの約50%を目安に設定することが推奨されています。これにより、MongoDBがインメモリで保持できるデータ量が増え、ディスクI/Oを減らすことができます。
  • systemLog: ログファイルに関する設定。
    • destination: file を指定。
    • path: ログファイルのパス（例: /var/log/mongodb/mongod.log）。
    • logAppend: true に設定すると、サービス再起動時にログを追記します。
      yaml
      systemLog:
      destination: file
      path: "/var/log/mongodb/mongod.log"
      logAppend: true
  • processManagement: プロセス管理に関する設定。
    • fork: true に設定すると、デーモンとしてバックグラウンドで実行されます。systemdを使用する場合は不要またはfalseでOKです。
      yaml
      processManagement:
      fork: false
  • network: ネットワークに関する設定。
    • bindIp: MongoDBが待ち受けるIPアドレス。デフォルトは 127.0.0.1 (localhost) のみ です。外部（同一VPC内のアプリケーションサーバーなど）から接続できるようにするには、MongoDBサーバーのプライベートIPアドレス、または 0.0.0.0 を指定します。セキュリティのため、0.0.0.0 を指定する場合は、必ずセキュリティグループでアクセス元IPアドレスやセキュリティグループを厳密に制限してください。
      yaml
      network:
      port: 27017
      bindIp: <MongoDBサーバーのプライベートIPアドレス>,127.0.0.1 # カンマ区切りで複数指定可
      # bindIp: 0.0.0.0 # 注意！セキュリティグループ必須！
    • port: MongoDBが待ち受けるポート番号（デフォルトは27017）。
  • security: セキュリティに関する設定。本番環境では必須の設定です。
    • authorization: enabled に設定することで、認証・認可を有効化します。これにより、ユーザー名とパスワードなしでのアクセスを禁止します。
      yaml
      security:
      authorization: enabled
    • TLS/SSL暗号化の設定もここで行います。
  • replication: レプリカセットを構成する場合の設定。
    • replSetName: レプリカセットの名前を指定します。レプリカセットに参加する全メンバーで同じ名前を設定する必要があります。
      yaml
      replication:
      replSetName: rs0 # レプリカセット名
  • sharding: シャーディングを構成する場合の設定。
    • clusterRole: シャーディング構成におけるインスタンスの役割を指定します（configsvr または shardsvr）。
      yaml
      sharding:
      clusterRole: configsvr # または shardsvr

設定ファイルを編集・保存したら、MongoDBサービスが使用するディレクトリの権限を確認します。
bash
$ sudo chown -R mongod:mongod /data/db # データディレクトリ
$ sudo chown -R mongod:mongod /var/log/mongodb # ログディレクトリ
（mongodb ユーザーはディストリビューションによって mongod の場合があります。id mongod などで確認してください。）

7. MongoDBサービスの起動と確認

設定が完了したら、MongoDBサービスを起動し、ステータスを確認します。

bash
$ sudo systemctl daemon-reload # 設定ファイルを変更した場合に実行
$ sudo systemctl enable mongod # システム起動時に自動起動するように設定
$ sudo systemctl start mongod # サービスを起動
$ sudo systemctl status mongod # ステータスを確認

systemctl status mongod の出力で active (running) と表示され、エラーが出ていないことを確認します。ログファイル (/var/log/mongodb/mongod.log) も確認し、起動プロセスでエラーが発生していないか確認します。

8. 初期設定：認証の有効化と管理者ユーザーの作成 (重要!)

security.authorization: enabled を設定した場合、サービス起動直後は認証が有効になっていますが、まだユーザーがいません。管理シェル (mongosh) でローカルホストから接続し、管理者ユーザーを作成する必要があります。これはセキュリティのために最も重要なステップの一つです。

  1. mongosh でローカルホストとして接続: 設定ファイルで bindIp: 127.0.0.1 が含まれていること、またはローカルホストからの接続が許可されていることを確認します。
    bash
    $ mongosh
    （認証が無効な状態なので、認証なしで接続できます）

  2. 管理者ユーザーを作成: admin データベースに切り替え、ユーザーを作成します。ユーザー名、パスワード、ロールを指定します。
    javascript
    > use admin
    > db.createUser(
    {
    user: "myAdminUser",
    pwd: passwordPrompt(), // パスワードを安全に入力
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
    }
    )
    passwordPrompt() を使用すると、パスワード入力時にターミナルに表示されません。userAdminAnyDatabase ロールはユーザー管理権限を、readWriteAnyDatabase ロールは全てのデータベースに対する読み書き権限を与えます。本番環境では、必要な権限のみを持つユーザーを作成することを推奨します。

  3. 接続を終了:
    javascript
    > exit

  4. 認証を有効化した状態で再接続を試す: 作成した管理者ユーザーで認証して接続できるか確認します。
    bash
    $ mongosh -u "myAdminUser" -p --authenticationDatabase "admin"
    Enter password:
    パスワードを入力し、正しく接続できれば認証設定は成功です。以降、全ての接続はこのように認証情報を付けて行う必要があります。

9. レプリカセットの構築 (高可用性)

単一インスタンスでは障害発生時にサービスが停止してしまいます。高い可用性を実現するために、複数のMongoDBインスタンスでレプリカセットを構成します。最低3つのメンバー（うち1つはPrimary、残りはSecondary）が必要です。メンバーは異なるAZに配置します。

  1. レプリカセットメンバーの準備:
    上記の手順1〜8を繰り返し、レプリカセットを構成する全てのEC2インスタンスを準備します。各インスタンスでMongoDBをインストールし、/etc/mongod.conf の replication.replSetName に同じレプリカセット名を設定します。また、各インスタンスの network.bindIp には、他のメンバーからアクセス可能なプライベートIPアドレスを含める必要があります。

  2. 最初のメンバー (Primary候補) でレプリカセットを初期化:
    いずれか1台のメンバー（以降、初期化メンバーと呼びます）に認証付きで接続し、レプリカセットを初期化します。
    bash
    $ mongosh -u "myAdminUser" -p --authenticationDatabase "admin"
    > rs.initiate()
    rs.initiate() コマンドは、自身をPrimaryとする新しいレプリカセットを開始します。設定オブジェクトを引数に渡すこともできますが、まずはデフォルト設定で初期化し、後からメンバーを追加するのが簡単です。

  3. 他のメンバーをレプリカセットに追加:
    初期化が成功したら、他のメンバーをレプリカセットに追加します。初期化メンバーに接続した mongosh シェルで以下のコマンドを実行します。
    javascript
    > rs.add("<SecondaryメンバーのプライベートIPアドレス>:<ポート番号>")
    例:
    javascript
    > rs.add("10.0.1.10:27017")
    > rs.add("10.0.2.10:27017")
    メンバー追加後、rs.status() コマンドでレプリカセットの状態を確認します。
    javascript
    > rs.status()
    全てのメンバーが stateStr: "PRIMARY" または stateStr: "SECONDARY" となっていることを確認します。SECONDARYメンバーは、Primaryからデータを同期するまで時間がかかる場合があります。

  4. クライアントからの接続:
    アプリケーションなどのクライアントからは、レプリカセット内の複数のメンバーのホスト名（またはIPアドレス）を指定して接続します。これにより、Primaryが切り替わっても自動的に新しいPrimaryに接続できるようになります。
    接続URI例:
    mongodb://myAdminUser:password@<メンバー1のIP>:27017,<メンバー2のIP>:27017,<メンバー3のIP>:27017/?replicaSet=rs0&authSource=admin
    DNSホスト名を使用することをお勧めします。AWSではプライベートDNSホスト名が自動的に割り当てられます。

10. シャーディングの構築 (水平スケーラビリティ)

データ量の増加や高負荷に対応するために、シャーディング構成を検討します。シャーディングはデータを複数の独立したクラスター（Shard）に分散させることで、水平スケーラビリティを実現します。レプリカセット構成よりも複雑な構成となります。

シャーディング構成は以下の主要なコンポーネントから成ります。
* Shard Replica Set: 実際にデータを保持するレプリカセットです。データはシャーディングキーに基づいてこれらのShardに分散されます。複数のShard Replica Set が必要です。
* Config Server Replica Set: クラスターのメタデータ（どのデータがどのShardにあるか、シャーディングの設定情報など）を保持するレプリカセットです。常に3つのメンバーを持つレプリカセットである必要があります。
* Mongos: クエリルーターとして機能します。クライアントはMongosに接続し、Mongosがクエリを適切なShardにルーティングします。アプリケーションサーバーと同じインスタンスや、独立したインスタンスで実行します。複数のMongosインスタンスを配置することで高可用性を実現します。

構築の大まかな流れ:

  1. Config Server Replica Set の準備:

    • 3台のEC2インスタンスを異なるAZに準備します。
    • 各インスタンスにMongoDBをインストールし、/etc/mongod.conf で sharding.clusterRole: configsvr と replication.replSetName: <Config Serverのレプリカセット名> を設定します。
    • いずれか1台のインスタンスで mongosh に接続し、rs.initiate() でレプリカセットを初期化し、残りの2台をメンバーに追加します。

  2. Shard Replica Set の準備:

    • 必要な数のShard Replica Set を準備します。各Shardは独立したレプリカセット（通常3メンバー以上）です。
    • 各メンバーとなるEC2インスタンスにMongoDBをインストールし、/etc/mongod.conf で sharding.clusterRole: shardsvr と replication.replSetName: <このShardのレプリカセット名> を設定します。
    • 各Shard Replica Set ごとに、レプリカセットの初期化とメンバー追加を行います。

  3. Mongos インスタンスの準備:

    • クライアントからの接続を受け付けるMongosインスタンスを準備します。高可用性のため複数台が良いでしょう。
    • MongosインスタンスにMongoDBをインストールし、/etc/mongod.conf に Config Server Replica Set の情報を記述します。
      yaml
      sharding:
      configDB: <Config Serverのレプリカセット名>/<メンバー1のIP>:<ポート>,<メンバー2のIP>:<ポート>,<メンバー3のIP>:<ポート>
    • mongos サービスを起動します。systemctl enable mongos, systemctl start mongos, systemctl status mongos

  4. シャーディングの有効化とコレクションのシャード化:

    • Mongosインスタンスに接続し、mongosh でシャーディングの設定を行います。
    • sh.addShard() コマンドで各Shard Replica Set をクラスターに追加します。
    • 対象のデータベースに対してシャーディングを有効化し、シャーディングキーを決定した上で、sh.shardCollection() コマンドでコレクションをシャード化します。

シャーディングの設計（シャーディングキーの選定）はパフォーマンスに大きな影響を与えるため、慎重な検討が必要です。構築手順も複雑になるため、詳細はMongoDBの公式ドキュメントや専門書籍を参照することをお勧めします。

運用と管理

セルフマネージドでのMongoDB運用には、監視、バックアップ、パッチ適用、パフォーマンスチューニングなど、継続的な作業が必要です。

1. 監視

MongoDBインスタンスやEC2リソースの状態を継続的に監視することは、問題を早期に発見し、サービス停止を防ぐために不可欠です。

  • AWS CloudWatch:
    • EC2インスタンスの基本的なメトリクス（CPU使用率、ネットワークI/O、ディスクI/O、ステータスチェック）を監視します。
    • EBSボリュームのメトリクス（Read/Write IOPS, スループット, Queue Length）を監視し、ストレージ性能がボトルネックになっていないか確認します。
    • CloudWatch Agentを使用して、OSレベルの詳細なメトリクス（メモリ使用率、ディスク使用率）や、MongoDBの特定のメトリクス（カスタムメトリクスとして送信）を収集・監視できます。
  • MongoDB独自のツール:
    • mongostat: MongoDBインスタンスのリアルタイムな稼働状況（挿入/クエリ数、接続数、メモリ使用量、I/O待ちなど）を表示します。
    • mongotop: データベースの各コレクションに対して、どのくらいの時間が読み書きに費やされているかを表示します。
    • serverStatus コマンド: mongosh から実行し、インスタンスの詳細な状態や統計情報を取得します。
  • 外部監視ツール:
    • Prometheus + Grafana: 広く利用されているオープンソースの監視・可視化ツールスタックです。MongoDB Exporterを使用することで、MongoDBの詳細なメトリクスを収集し、Grafanaでダッシュボードを作成して監視できます。
    • MongoDB Cloud Manager / Ops Manager: MongoDB社が提供する管理ツールです。Cloud ManagerはSaaSとして、Ops Managerはオンプレミスやプライベートクラウドにデプロイして使用します。詳細な監視、バックアップ、自動化された運用（パッチ適用、スケーリングなど）機能を提供します。セルフマネージドながらマネージドサービスに近い運用をしたい場合に非常に有効です。

監視すべき主要なメトリクス:
* CPU使用率、メモリ使用率
* ディスク使用率、IOPS、スループット、キュー長
* ネットワーク送受信量
* MongoDB接続数
* クエリ実行時間、スロークエリ
* OpLog遅延 (レプリカセット)
* キャッシュ使用率、ページフォルト
* ロック率

2. バックアップとリカバリ

データの損失を防ぐために、定期的なバックアップと、障害発生時に迅速にデータを復旧できる体制を構築することが不可欠です。

  • EBSスナップショット:
    • アタッチしているデータボリュームのEBSスナップショットを定期的に取得します。整合性のため、スナップショット取得前にMongoDBを一時停止（またはファイルシステムをフリーズ）するのが理想ですが、レプリカセット構成の場合はSecondaryメンバーでスナップショットを取得するなどの方法で、サービス停止時間を最小限に抑えられます。
    • スナップショットから新しいボリュームを作成し、インスタンスにアタッチすることで復旧できます。
    • AWS Backupサービスを利用すると、複数のAWSサービスのバックアップを一元管理・自動化できます。
  • mongodump / mongorestore:
    • mongodump コマンドでデータベース全体の論理バックアップを取得します。BSON形式またはJSON形式で出力できます。
    • mongorestore コマンドでバックアップからデータを復旧します。
    • 大きなデータベースの場合、バックアップとリカバリに時間がかかる可能性があります。また、バックアップ取得中にデータの整合性を保つのが難しい場合があります（特にシャードされた環境）。レプリカセットの場合は、Primaryへの影響を避けるためSecondaryメンバーで実行することが多いです。
  • Point-in-Time Recovery (PITR):
    • EBSスナップショットとOpLogを組み合わせることで、特定の時点までデータを復旧する手法です。レプリカセットのOpLogは全ての書き込み操作の履歴を記録しているため、OpLogをバックアップしておけば、スナップショット取得時点から任意の時点までの変更を適用することでPITRが可能になります。
    • mongodump の --oplog オプションを使用して、バックアップ時点でのOpLogを同時に取得することが一般的です。
  • MongoDB Cloud Manager / Ops Manager: 自動化された連続バックアップ機能を提供しており、PITRも容易に実現できます。

バックアップデータの保管場所、世代管理、リカバリ手順のテストなどを計画に含める必要があります。バックアップデータは、元の環境とは別のAWSリージョンやS3バケットなどに保管することで、リージョン規模の障害にも備えることができます。

3. パッチ適用とアップグレード

OSとMongoDBソフトウェアのセキュリティパッチ適用や、新しいバージョンへのアップグレードは、システムの安定性とセキュリティを維持するために重要です。

  • OSパッチ適用: 定期的にOSのパッケージをアップデートし、セキュリティ脆弱性に対応します。
    bash
    $ sudo dnf update -y # Amazon Linux / RHEL / CentOS
    $ sudo apt update && sudo apt upgrade -y # Ubuntu / Debian
    アップデート後、必要に応じてインスタンスの再起動を行います。
  • MongoDBバージョンアップグレード:
    • メジャーバージョンアップグレード (例: 5.0 -> 6.0) は、非互換性の変更が含まれる可能性があるため、事前にドキュメントをよく確認し、テスト環境で十分に検証を行う必要があります。
    • レプリカセット環境では、ローリングアップグレードが可能です。これにより、サービスを停止せずにアップグレードできます。手順は以下の通りです。
      1. Secondaryメンバーを1台停止し、新しいバージョンをインストール、設定ファイルを更新して起動します。
      2. 起動したメンバーがレプリカセットに再参加し、Primaryと同期を完了するのを待ちます。
      3. 全てのSecondaryメンバーに対して1, 2の手順を繰り返します。
      4. 最後にPrimaryメンバーを停止し、新しいバージョンをインストール、設定ファイルを更新して起動します。新しいPrimaryが他のメンバーから選出され、役割を引き継ぎます。

4. パフォーマンスチューニング

MongoDBのパフォーマンスは、インフラ構成、スキーマ設計、クエリ、設定など、様々な要素に影響されます。

  • インデックス設計: クエリ性能に最も大きく影響します。適切なインデックスを作成することで、データスキャンを減らし、クエリ実行時間を大幅に短縮できます。explain() メソッドを使用してクエリの実行計画を確認し、ボトルネックとなっている箇所を特定します。
  • クエリ最適化: 非効率なクエリ（巨大なドキュメントの取得、不要なフィールドの取得、インデックスを使用しないソートなど）を見つけて修正します。スロークエリログを有効化し、遅いクエリを特定します。
  • ハードウェアリソース: CPU、メモリ、ディスクI/Oがボトルネックになっていないか監視し、必要に応じてインスタンスタイプやEBSボリュームの種類/サイズ/IOPSを見直します。特にメモリが不足していると、キャッシュミスが増加し、ディスクI/Oが増えてパフォーマンスが低下します。
  • ストレージエンジンの設定: WiredTigerストレージエンジンのキャッシュサイズ設定 (storage.wiredTiger.engineConfig.cacheSizeGB) は非常に重要です。適切に設定することで、メモリ効率を向上させられます。
  • シャーディングキーの選定: シャーディング環境では、シャーディングキーの選定がデータ分散とクエリルーティングの効率に直結します。カーディナリティが高すぎず低すぎず、データが均等に分散されるようなキーを選択することが重要です。

5. セキュリティ対策

データベースは機密性の高い情報を扱うため、厳重なセキュリティ対策が必要です。

  • ネットワークセキュリティ:
    • セキュリティグループでアクセス元を厳密に制限します。
    • 可能な限りパブリックIPアドレスを使用せず、プライベートIPアドレスとVPC内通信（またはVPCピアリング、Transit Gatewayなど）を利用します。
    • VPCエンドポイントを利用することで、インターネットを経由せずにAWSサービス（例: S3へのバックアップ）にアクセスできます。
  • 認証と認可:
    • security.authorization: enabled を設定し、ユーザー名とパスワードによる認証を必須にします。
    • 必要最小限の権限のみを持つユーザーを作成し、職務に基づいて適切なロールを割り当てます（ロールベースアクセス制御 – RBAC）。
    • デフォルトユーザーや不要なユーザーは削除します。
  • 通信の暗号化:
    • クライアントとMongoDBサーバー間の通信をTLS/SSLで暗号化します。証明書を設定ファイルで指定することで有効化できます。これにより、通信経路での盗聴や改ざんを防ぎます。
  • データの暗号化:
    • EBSボリュームの暗号化を有効にします。保管時のデータの暗号化を提供します。
    • MongoDB Enterprise Advanced版では、ストレージエンジンのレベルでデータの暗号化（Encryption at Rest）をサポートしています。
  • Audit Logging:
    • データベースに対する操作ログ（誰が、いつ、何を、どのIPから実行したか）を記録することで、セキュリティ監査や不正アクセス検知に役立ちます。設定ファイルで有効化できます。
  • OSレベルのセキュリティ:
    • 不要なサービスを停止します。
    • OSのファイアウォール (iptables or firewalld) で、セキュリティグループと合わせて多重に防御します。
    • SSHアクセスはキーペアを使用し、パスワード認証を無効化します。可能な場合はSession Managerなどを使用し、SSHポートを閉鎖します。

マネージドサービス (DocumentDB / MongoDB Atlas) について

セルフマネージドでの構築・運用には多くのメリットがある一方、高い運用負荷が伴います。運用負荷を軽減したい場合や、専門知識を持つエンジニアのリソースが限られている場合は、マネージドサービスの利用を検討する価値があります。

Amazon DocumentDB (with MongoDB compatibility)

AWSが提供するマネージドなドキュメントデータベースです。アーキテクチャはAmazon Auroraに似ており、ストレージとコンピュートが分離されています。

  • 特徴:
    • 高い可用性と耐久性: 複数AZにデータが自動的にレプリケーションされ、6重にコピーが保持されます。ストレージは最大128TBまで自動拡張されます。
    • スケーラビリティ: リードレプリカを最大15個まで作成でき、読み込み性能をスケールアウトできます。インスタンスクラスを変更してコンピュートリソースをスケールアップすることも可能です。
    • 運用管理の自動化: パッチ適用、バックアップ、障害検出・復旧などはAWSが自動で行います。
    • MongoDB互換API: 既存のMongoDB 3.6, 4.0, 5.0, 6.0 用のドライバーやツールを使用して接続できます。
  • 互換性の注意点: MongoDB互換APIを提供しますが、MongoDB自体ではありません。そのため、MongoDBの全ての機能（特定の管理コマンド、JavaScriptエンジンの挙動、一部のデータ型、トランザクション機能の制約など）がサポートされているわけではありません。利用を検討する際は、事前にアプリケーションが使用する機能がDocumentDBでサポートされているか、互換性ドキュメントを十分に確認する必要があります。
  • 料金体系: インスタンス時間、ストレージ使用量、I/Oリクエスト数、バックアップストレージなどに基づいて課金されます。

MongoDB Atlas (on AWS)

MongoDB社が提供する公式のフルマネージドクラウドデータベースサービスです。AWS上でクラスターを簡単にデプロイできます。

  • 特徴:
    • 最新のMongoDBバージョンと全ての機能を利用可能。
    • 高い可用性、スケーラビリティ、セキュリティが組み込まれています。
    • バックアップ、監視、自動スケーリング（M10以上のプラン）、パフォーマンスアドバイザーなど、豊富な運用管理機能を提供。
    • Atlas Search (全文検索)、Atlas Data Lake (S3上のデータに対するクエリ)、Atlas App Services (モバイル/Webアプリバックエンド) など、MongoDBの機能を拡張するサービスも利用可能。
    • AWS Marketplace経由で契約することも可能で、AWSの請求に統合できます。
  • 料金体系: クラスターのティア（インスタンスサイズ）、ストレージ容量、データ転送量、追加機能などに基づいて課金されます。無料枠 (M0) もありますが、機能や性能に制限があります。
  • 選択肢: Shared Cluster (M0, M2, M5), Dedicated Cluster (M10以上), Serverless など、様々なティアがあり、用途や予算に応じて選択できます。

選択の検討ポイント

  • 運用負荷: 運用に割けるリソースが少ない場合は、DocumentDBやAtlasのようなマネージドサービスが有力な選択肢となります。
  • MongoDBとの互換性: 最新のMongoDB機能やEnterprise版独自の機能が必要な場合、または厳密な互換性が求められる場合は、MongoDB Atlasが最適です。DocumentDBは互換性の制限があるため、事前に検証が必要です。
  • コスト: 小規模でアクセスが少ない場合、セルフマネージドでコストを抑えられる可能性があります。大規模になるにつれて、運用コストを含めるとマネージドサービスの方がトータルコストで有利になることもあります。Atlasは高機能ですが、その分コストも高くなる傾向があります。
  • カスタマイズ性: OSやMongoDBの詳細な設定を制御したい場合は、セルフマネージドが唯一の選択肢です。
  • 機能: 監視やバックアップなどの運用機能、検索やデータレイクといった付加価値サービスが必要であれば、Atlasが魅力的な選択肢となります。

コスト

AWS環境でMongoDBを運用する際のコストは、主に以下の要素によって決まります。

  • EC2インスタンス料金: 使用するインスタンスタイプと稼働時間によって決まります。リザーブドインスタンス (RI) やSaving Plansを利用することで、コストを大幅に削減できます。
  • EBSボリューム料金: ボリュームの種類、容量、プロビジョニングされたIOPS/スループット、およびスナップショットの容量によって決まります。
  • データ転送料金: AWS内外へのデータ転送量によって決まります。リージョン間やインターネットへのデータ転送はコストが高くなる傾向があります。
  • その他のサービス料金: CloudWatch (カスタムメトリクス)、S3 (バックアップ保管)、NAT Gateway、VPCエンドポイントなどの利用料。
  • マネージドサービス料金: DocumentDBやMongoDB Atlasを利用する場合は、それぞれのサービス固有の料金体系に基づきます。通常、インスタンスサイズ、ストレージ、I/O、データ転送などに基づいて課金されます。

コスト最適化のヒント:
* ワークロードに合った適切なインスタンスタイプとEBSボリュームを選択する。
* 開発環境やテスト環境では、より小さなインスタンスタイプや汎用的なストレージを使用する。
* 不要になったインスタンスやボリュームは停止・削除する。
* RIやSaving Plansを利用してEC2コストを削減する。
* データ転送コストを最小限に抑えるようネットワーク設計を考慮する（例: 同じAZ内のリソース間で通信する、VPCエンドポイントを利用する）。
* CloudWatchなどの監視設定を見直し、必要なメトリクスのみを収集する。
* マネージドサービスを利用する場合は、予約容量や長期契約による割引を確認する。

トラブルシューティング

AWS上でMongoDBを運用している際に遭遇しやすいトラブルと、その対処法の概要です。

  • MongoDBに接続できない:
    • セキュリティグループ: クライアントからの接続元IPアドレスやセキュリティグループからのインバウンドルールが、MongoDBサーバーのセキュリティグループで許可されているか確認します。
    • ネットワーク設定: MongoDBサーバーの /etc/mongod.conf の bindIp に、クライアントからの接続元IPアドレスやネットワークインターフェースが指定されているか確認します。
    • 認証: クライアントが正しいユーザー名、パスワード、認証データベースで接続しようとしているか確認します。
    • OSファイアウォール: OSレベルのファイアウォール (iptables, firewalld) がMongoDBポート (27017) をブロックしていないか確認します。
    • MongoDBサービス: systemctl status mongod でMongoDBサービスが起動しているか確認します。
  • パフォーマンスが遅い:
    • 監視: CPU、メモリ、ディスクI/O、ネットワークのメトリクスを確認し、リソースがボトルネックになっていないか確認します。
    • インデックス: 遅いクエリに対する適切なインデックスが存在するか確認し、必要であれば作成します。explain() を使用してクエリ実行計画を分析します。
    • キャッシュ: WiredTigerキャッシュサイズが適切に設定されているか確認します。メモリ不足が発生していないか確認します。
    • スロークエリログ: スロークエリログを確認し、実行に時間のかかっているクエリを特定・最適化します。
  • ディスク容量不足:
    • df -h コマンドでディスク使用率を確認します。
    • MongoDBのデータディレクトリ (dbPath) の容量を確認します。
    • 不要なデータや古いバックアップファイルを削除します。
    • EBSボリュームのサイズを拡張します。オンラインでのサイズ拡張が可能ですが、ファイルシステムのリサイズも必要です。
    • ジャーナルファイルの容量を確認します。
  • レプリカセットの同期問題 (Lag):
    • rs.status() コマンドで各メンバーの状態とOpLog遅延 (oplogWindowSecs, syncSourceId) を確認します。
    • ネットワーク遅延や帯域不足が原因でないか確認します（メンバー間のネットワークメトリクス）。
    • Secondaryメンバーのリソース（特にディスクI/O）がPrimaryの書き込み速度に追いつけていない可能性があります。
    • Primaryが大量の書き込み処理を行っている間に、Secondaryがインデックス構築などの重い処理を行っている場合に発生することがあります。

これらのトラブルシューティングを行う際は、まずシステムログ (/var/log/messages など) やMongoDBのログファイル (/var/log/mongodb/mongod.log) を確認し、エラーメッセージや警告がないか探すことが重要です。

まとめ

この記事では、AWS環境でMongoDBを構築・設定するための実践的なガイドとして、主にEC2インスタンス上にMongoDBをセルフマネージドで構築する方法について詳細に解説しました。単一インスタンスの準備から、データ保存のためのEBSボリューム設定、MongoDBのインストールと mongod.conf による詳細設定、そして高可用性を実現するレプリカセット構成、さらに水平スケーラビリティのためのシャーディング構成まで、その手順と重要な設定項目を説明しました。

セルフマネージドでの構築は、環境に対する高い柔軟性と制御性を得られる一方で、監視、バックアップ、パッチ適用、パフォーマンスチューニング、セキュリティ対策といった、運用管理の全ての責任を自身で負う必要があります。そのため、MongoDBとAWSインフラに関する十分な知識と、それを維持するための運用体制が不可欠です。

また、AWS上でMongoDBを構築する方法としては、Amazon DocumentDBやMongoDB Atlasといったマネージドサービスも存在することを紹介し、それぞれの特徴、メリット・デメリット、セルフマネージドとの比較検討ポイントについても触れました。運用負荷を軽減したい場合や、最新機能の利用、マルチクラウド対応が必要な場合は、これらのマネージドサービスが有力な選択肢となります。

どの構築方法を選択するにしても、データベースはアプリケーションの基盤となる重要なコンポーネントです。データの整合性、可用性、セキュリティ、パフォーマンスといった要素を常に意識し、適切な設計、構築、そして継続的な運用管理を行うことが成功の鍵となります。

この記事が、AWS環境でMongoDBを構築し、安定して運用するための一助となれば幸いです。実践を通じて、それぞれの環境に最適な設定を見つけ出し、MongoDBの強力な機能を最大限に活用してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール