Docs Menu
Docs Home
/ /
Atlas Architecture Center
/

Atlas の高可用性に関するガイダンス

このページを参照して、エンタープライズのコスト管理とアクセス ニーズに合わせて、可用性とパフォーマンスを最適化するための適切なクラスター構成を計画しましょう。

Atlas で新しいクラスターを起動すると、Atlas は最小の 3 ノードレプリカセットを自動的に構成し、それを配置するリージョンに分散します。プライマリ ノードで停止時が発生すると、 MongoDBデータベース は自動的にこの障害を検出し、セカンダリ ノードを代替ノードとして選択し、このセカンダリ ノードを新しいプライマリ ノードに昇格させます。その後、Atlas は障害ノードを復元または置換して、クラスターができるだけ早くターゲット構成に戻るようにします。MongoDBクライアントドライバーも、すべてのクライアント接続を自動的に切り替えます。選択とフェイルオーバーのプロセス全体は 秒以内に発生し、手動による介入はありません。MongoDB は、障害を検出し、新しいプライマリを選択するために使用されるアルゴリズムを最適化し、フェイルオーバー間隔を短縮します。

単一のリージョン内に配置するクラスターは、そのリージョン内のアベイラビリティーゾーン全体に分散されるため、読み取りや書き込みの可用性を中断することなく、リージョンの部分的な停止時に耐えられます。

希望リージョンで常に書込み操作を維持することが優先順位が高い 場合は、少なくとも 2 つの選出可能なMongoDBが希望リージョン内の少なくとも 2 つのアベイラビリティーゾーンに含まれるようにクラスターを配置することをお勧めします。

グローバル配置で最高のデータベース パフォーマンスを得るため、ユーザーはロケーション認識型シャーディングを使用して読み取りと書込みのレイテンシを最小限に抑えるグローバルクラスターを構成できます。地理的ストレージ要件がある場合は、Atlas が特定の地理的領域にデータを保存するようにすることもできます。

3 ノードを含む単一リージョンのトポロジー(1 つのプライマリと 2 つのセカンダリ)。

このトポロジーは、低レイテンシが必要であるが、高可用性の要件が単一リージョンに限定されている場合に適しています。このトポロジーは、1 ノードのあらゆる障害に耐え、リージョン内のセカンダリの過半数の書込み保証 (write concern) を容易に満たすことができます。これにより、ノードに障害が発生した場合でも、優先リージョンにプライマリが維持され、コストが抑えられ、アプリケーション アーキテクチャの観点から最も簡単です。このトポロジーのセカンダリからの読み取りと書き込みは、希望するリージョンで低レイテンシを実現します。

しかし、このトポロジーはリージョンの停止時を許容できません。

次の推奨事項を使用して、Atlas の配置とバックアップを高可用性し、障害からの回復を迅速化します。

災害への計画と対応方法に関する詳細は、Atlas 障害復旧ガイダンスをご覧ください。

クラスターを新規作成する場合、専用、フレックス、または無料の配置タイプで利用可能なクラスター階層範囲から選択できます。

アプリケーションサイズに推奨されるクラスター層を決定するには、 「Atlas クラスター サイズ ガイド」 を参照してください。

プライマリを選出するには、利用可能な投票レプリカセット ノードの過半数が必要です。投票権のあるレプリカセット ノードの数が奇数のレプリカセットを作成することをお勧めします。投票権のあるレプリカセット ノードの数を偶数にしても利点はありません。Atlasには 3、5、7 ノードが必要なため、Atlas はデフォルトでこの要件を満たしています。

フォールト トレランスとは、プライマリ選挙に十分な数のノードが参加できる状態にもかかわらず、使用できなくなるレプリカセット ノードの数です。4 ノードのレプリカセットのフォールト トレランスは、3 ノードのレプリカセットのフォールト トレランスと同じです。どちらも単一ノードの停止時に耐えられるからです。

アプリケーションがレプリカセット プライマリの障害を処理できるかどうかをテストするには、プライマリ フェイルオーバーをテストのリクエストを送信します。Atlasがフェイルオーバー イベントをシミュレートする場合、Atlasは現在のプライマリをシャットダウンし、新しいプライマリを選出するための選挙を実施します。

レプリカセット ノードの詳細については、「レプリカセット ノード」を参照してください。レプリカセットの選挙と投票の詳細については、「レプリカセットの選挙」を参照してください。

MongoDBは、レプリカセット全体にデータの複数のコピーを保存することで、高可用性を提供します。同じレプリカセットのメンバーが同じリソースを共有しないように、また、データセンターが利用できなくなった場合にレプリカセットがプライマリを選出できるようにするには、少なくとも3つのデータセンターにノードを分散する必要がありますが、少なくとも5つのデータセンターを使用することをおすすめします。

複数のアベイラビリティゾーンをサポートするリージョンにクラスターを展開することで、複数のデータセンターにデータを分散できます。通常、各アベイラビリティーゾーンは1つ以上の個別のデータセンターで構成されており、それぞれが冗長電源、ネットワーキング、接続性を備え、しばしば別々の施設に収容されています。アベイラビリティーゾーンをサポートするリージョンに専有クラスターを配置すると、Atlasは自動的にクラスターのノードをアベイラビリティーゾーンに分割します。たとえば、3つのアベイラビリティーゾーンを持つリージョンにデプロイされた3ノードのレプリカセットクラスターの場合、Atlasは各ゾーンに1つのノードを配置します。これは、同じレプリカセットのメンバーによってリソースが共有されないことを確実にするため、1つのゾーンで停止が発生してもデータベースは引き続き使用できます。

使用データセンターの数を 2 つ以下に絞ることに伴うリスクについて、次の図を用いて説明します。この例ではデータは 2 つのデータセンターに分散されています。

2 つのデータセンターを示す画像: データセンター 1 は 1 つのプライマリ ノードと 1 つのセカンダリ ノードがあり、データセンター 2 は 1 つのセカンダリ ノードのみ

前の図では、データセンター 2 が利用できなくなっても、レプリカセットの過半数のノードが引き続き利用可能で、Atlas はプライマリを選出できます。しかし、データセンター 1 が失われると、3 つのレプリカセット ノードのうち 1 つしか利用できず、過半数ではなくなり、システムは読み取り専用モードに移行します。

以下の図では、3 つのアベイラビリティーゾーンのあるリージョンに配置された 5 ノードのレプリカセットクラスターが示されています。

3つのデータセンターを示す画像: プライマリノードとセカンダリノード、データセンター、、セカンダリノードが2つある2、データセンター 3、セカンダリノードが1つあるデータセンター1
クリックして拡大します

前の図の 2-2-1 のトポロジーは、複数のリージョンにわたって高可用性、パフォーマンス、コストを取るための推奨トポロジーです。このトポロジーでは、いずれかのデータセンターに障害が発生しても、レプリカセットの過半数は引き続き使用可能であり、Atlas は自動フェイルオーバーを実行できます。3 ノード、3 リージョンのトポロジーは1 つのリージョン障害にも許容できますが、1-1-1トポロジーでフェイルオーバーイベントが発生すると、異なるリージョンで新しいプライマリが選出されます。2-2-1トポロジーは、プライマリノードの障害を許容しながら、新しいプライマリを 希望リージョン に維持できます。

次のリージョンは少なくとも 3 つのアベイラビリティーゾーンをサポートしているため、レプリカセットを配置することをお勧めします。

AWS リージョン
ロケーション
Atlas リージョン

us-east-1

米国バージニア州北部

US_EAST_1

us-west-2

米国ワシントン州

US_WEST_2

ca-central-1

カナダ・ケベック州・モントリオール

CA_CENTRAL_1

ca-west-1

カナダ(カルガリー)

CA_WEST_1

us-east-2

Ohio, USA

US_EAST_2

sa-east-1

サンパウロ(ブラジル)

SA_EAST_1

AWS リージョン
ロケーション
Atlas リージョン

ap-southeast-1

香港

AP_SOUTHEAST_1

ap-southeast-2

オーストラリア・ニューウェールズ州シドニー

AP_SOUTHEAST_2

ap-southeast-3

Jakarta, Indonesia

AP_SOUTHEAST_3

ap-south-1

ムバイ(インド)

AP_SOUTH_1

ap-east-1

中国(香港)

AP_EAST_1

ap-northeast-1

Tokyo, Japan

AP_NORTHEAST_1

ap-northeast-2

韓国(ソウル)

AP_NORTHEAST_2

ap-northeast-3

大阪(日本)

AP_NORTHEAST_3

ap-south-2

Hyderabad, India

AP_SOUTH_2

ap-southeast-4

オーストラリア(ビクトリア州メルボルン)

AP_SOUTHEAST_4

AWS リージョン
ロケーション
Atlas リージョン

eu-west-1

アイルランド

EU_WEST_1

eu-central-1

フランクフルト(ドイツ)

EU_CENTRAL_1

eu-north-1

スウェーデンのストックホルム

EU_NORTH_1

eu-west-2

London, England, UK

EU_WEST_2

eu-west-3

フランス・パリ

EU_WEST_3

eu-south-1

ミラノ(イタリア)

EU_SOUTH_1

eu-central-2

チューリッヒ(スイス)

EU_CENTRAL_2

eu-south-2

スペイン

EU_SOUTH_2

AWS リージョン
ロケーション
Atlas リージョン

me-south-1

バーレーン

ME_SOUTH_1

af-south-1

ケープタウン(南アフリカ)

AF_SOUTH_1

il-central-1

Tel Aviv, Israel

IL_CENTRAL_1

me-central-1

UAE

ME_CENTRAL_1

Azure リージョン
ロケーション
Atlas リージョン

centralus

Iowa, USA

US_CENTRAL

eastus

バージニア州(米国東部)

US_EAST

eastus2

Virginia, USA

US_EAST_2

northcentralus

Illinois, USA

US_NORTH_CENTRAL

westus

米国カリフォルニア州

US_WEST

westus2

米国ワシントン州

US_WEST_2

westus3

Arizona, USA

US_WEST_3

southcentralus

Texas, USA

US_SOUTH_CENTRAL

brazilsouth

サンパウロ(ブラジル)

BRAZIL_SOUTH

brazilsoutheast

Rio de Janeiro, Brazil

BRAZIL_SOUTHEAST

canadacentral

トロント(カナダ、オンタリオ州)

CANADA_CENTRAL

Azure リージョン
ロケーション
Atlas リージョン

northeurope

アイルランド

EUROPE_NORTH

westeurope

オランダ語

EUROPE_WEST

uksouth

London, England, UK

UK_SOUTH

francecentral

フランス・パリ

FRANCE_CENTRAL

italynorth

ミラノ(イタリア)

ITALY_NORTH

germanywestcentral

フランクフルト(ドイツ)

GERMANY_WEST_CENTRAL

polandcentral

ワルシャワ(ポーランド)

POLAND_CENTRAL

switzerlandnorth

チューリッヒ(スイス)

SWITZERLAND_NORTH

norwayeast

オスロ(ノルウェー)

NORWAY_EAST

swedencentral

スウェーデン・イェブレ

SWEDEN_CENTRAL

Azure リージョン
ロケーション
Atlas リージョン

eastasia

中国(香港)

ASIA_EAST

southeastasia

香港

ASIA_SOUTH_EAST

australiaeast

オーストラリア・ニューサウスウェールズ州

AUSTRALIA_EAST

centralindia

プネ(インド中部)

INDIA_CENTRAL

japaneast

Tokyo, Japan

JAPAN_EAST

koreacentral

韓国(ソウル)

KOREA_CENTRAL

Azure リージョン
ロケーション
Atlas リージョン

southafricanorth

ヨハネスブルグ(南アフリカ)

SOUTH_AFRICA_NORTH

Azure リージョン
ロケーション
Atlas リージョン

uaenorth

Dubai, UAE

UAE_NORTH

qatarcentral

Qatar

QATAR_CENTRAL

israelcentral

イスラエル

ISRAEL_CENTRAL

GCPリージョン
ロケーション
Atlas リージョン

us-central1

Iowa, USA

CENTRAL_US

us-east4

ノースバージニア州(米国)

US_EAST_4

us-east5

オハイオ州コロンバス(米国)

US_EAST_5

northamerica-northeast1

モントリオール(カナダ)

NORTH_AMERICA_NORTHEAST_1

northamerica-northeast2

トロント(カナダ)

NORTH_AMERICA_NORTHEAST_2

southamerica-east1

サンパウロ(ブラジル)

SOUTH_AMERICA_EAST_1

southamerica-west1

サンティアゴ(チリ)

SOUTH_AMERICA_WEST_1

us-west1

米国ワシントン州

WESTERN_US

us-west2

Los Angeles, CA, USA

US_WEST_2

us-west3

ユタ州ソルトレイクシティ(米国)

US_WEST_3

us-west4

Las Vegas, NV, USA

US_WEST_4

us-south1

Dallas, TX, USA

US_SOUTH_1

GCPリージョン
ロケーション
Atlas リージョン

asia-east1

台湾

EASTERN_ASIA_PACIFIC

asia-east2

中国(香港)

ASIA_EAST_2

asia-northeast1

Tokyo, Japan

NORTHEASTERN_ASIA_PACIFIC

asia-northeast2

大阪(日本)

ASIA_NORTHEAST_2

asia-northeast3

Seoul, Korea

ASIA_NORTHEAST_3

asia-southeast1

香港

SOUTHEASTERN_ASIA_PACIFIC

asia-south1

ムバイ(インド)

ASIA_SOUTH_1

asia-south2

デリー(インド)

ASIA_SOUTH_2

australia-southeast1

オーストラリア、シドニー

AUSTRALIA_SOUTHEAST_1

australia-southeast2

メルボルン(オーストラリア)

AUSTRALIA_SOUTHEAST_2

asia-southeast2

Jakarta, Indonesia

ASIA_SOUTHEAST_2

GCPリージョン
ロケーション
Atlas リージョン

europe-west1

ベルギー

WESTERN_EUROPE

europe-north1

フィンランド

EUROPE_NORTH_1

europe-west2

London, UK

EUROPE_WEST_2

europe-west3

フランクフルト(ドイツ)

EUROPE_WEST_3

europe-west4

オランダ語

EUROPE_WEST_4

europe-west6

チューリッヒ(スイス)

EUROPE_WEST_6

europe-west10

ベルリン(ドイツ)

EUROPE_WEST_10

europe-central2

ワルシャワ(ポーランド)

EUROPE_CENTRAL_2

europe-west8

ミラノ(イタリア)

EUROPE_WEST_8

europe-west9

フランス・パリ

EUROPE_WEST_9

europe-west12

トリノ(イタリア)

EUROPE_WEST_12

europe-southwest1

スペイン、マドリード

EUROPE_SOUTHWEST_1

GCPリージョン
ロケーション
Atlas リージョン

me-west1

Tel Aviv, Israel

MIDDLE_EAST_WEST_1

me-central1

Doha, Qatar

MIDDLE_EAST_CENTRAL_1

me-central2

サウジアラビア、ダンマーム

MIDDLE_EAST_CENTRAL_2

クライアントがシャーディングされたクラスターに接続する場合は、接続 URI に複数の mongos プロセスを、カンマで区切って含めることをお勧めします。詳細については、「MongoDB 接続文字列の例」を参照してください。この設定により、負荷分散のために操作を異なる mongos インスタンスにルーティングできますが、障害復旧にも重要です。

以下の図では、シャーディングされたクラスターが3 つのデータセンターに分散されていることが示されています。アプリケーションはリモート ロケーションからクラスターに接続します。データセンター 3 が利用できなくなった場合でも、アプリケーションは他のデータセンターの mongos プロセスに引き続き接続できます。

3 つのデータセンターを示す画像: データセンター 1 は 1 つのプライマリシャードと 2 つの mongos があり、データセンター 2 はセカンダリシャードと 2 つの mongos があり、データセンター 3 はセカンダリシャードと 2 つの mongos があります。アプリケーションは合計 6 つの mongos インスタンスのすべてに接続します。
クリックして拡大します

再試行可能な読み取り再試行可能な書き込みを使用すると、mongos 構成に必要なエラー処理を簡素化できます。

MongoDBは、書込み保証 (write concern) を使用して、書き込み操作に要求される確認応答のレベルを指定できます。たとえば、書込み保証 (write concern)がmajorityの3ノードのレプリカセットがある場合、書き込み (write) 操作を実行したドライバに完了の確認が送信される前に、すべての書き込み (write) 操作を2つのノードに永続化する必要があります。地域ノードの停止を保護するための最善の方法として、書込み保証をmajorityに設定することをお勧めします。

majority書込み保証 (write concern)を使用すると、書込み保証 (write concern)1 と比較して書込みレイテンシが増加しますが、レプリカセットがプライマリを失った場合でもデータセンターは書込み操作を実行し続けることができるため、majority書込み保証 (write concern)を使用することを推奨します。

数値書込み書込み保証 (write concern)(書込み保証 (write concern)よりも majority書込み保証 (write concern)を使用する利点を理解するには、2-2-1トポロジー( 42 つのノードがあるリージョンのいずれかが使用できなくなった場合、4 つのノードでデータを保持できないため、書込み操作を完了できません。majority を使用すると、少なくとも 2 つのノードにデータを保持する場合に書込み操作を継続でき、データの冗長性と書込み継続性を維持できます。

頻繁にデータをバックアップすることは、ビジネスの継続と障害復旧のために重要です。頻繁にバックアップを行うことで、災害やサイバー攻撃によって通常の運用が中断された場合でも、データ損失やダウンタイムを最小限に抑えることができます。

次のことを推奨します。

  • 貴社のビジネス継続性の目標に合わせてバックアップ頻度を設定してください。継続的なバックアップが必要なシステムもあれば、スナップショットの頻度が少ない方が望ましいシステムもあります。

  • バックアップは、ソース データとは異なる物理的なロケーションに保存してください。

  • バックアップ復元プロセスをテストして、バックアップが再現性のある、時間制限のある方法で復元できることを確認してください。

  • 復元時の互換性を確保するために、クラスターが同じ MongoDB バージョンを実行することを確認してください。

  • バックアップコンプライアンスポリシーを設定して、バックアップスナップショットの削除、スナップショット保持期間の短縮などを防ぎます。

詳細なバックアップの推奨事項については、Atlas のバックアップに関するガイダンスを参照してください。

リソースキャパシティーの問題を回避するには、リソースの使用率をモニターし、定期的にキャパシティープランニング セッションを保持することをお勧めします。MongoDBプロフェッショナル サービスはこれらのセッションを提供します。

過剰使用されたクラスターは失敗し、障害が発生する可能性があります。システム CPU とシステム メモリの使用率が 60%+ を超える場合は、使用率が定期的に定常状態でアラートを発行している場合は、クラスターをより高い階層にスケールアップします。

リソース使用率を表示するには、「 リアルタイム パフォーマンスのモニタリング 」を参照してください。Atlas Administration APIを使用してメトリクスを表示するには、「 モニタリングとログ 」を参照してください。

リソース使用率に関するアラートとモニタリングのベストプラクティスについては、Atlas のモニタリングとアラートのガイダンスを参照してください。

リソース キャパシティーの問題が発生した場合は、「リソース キャパシティーの問題」を参照してください。

最新のMongoDBバージョンを実行することをお勧めします。これにより、新機能を活用し、以前のバージョンと比較してセキュリティ保証が強化されます。

MongoDB のメジャー バージョン アップグレードは、現在のバージョンのサポートが終了する前に実行するようにしてください。

Atlas UIを使用してMongoDBのバージョンをダウングレードすることはできません。このため、メジャー バージョン アップグレードを計画して実行するときは、アップグレード プロセス中に発生する可能性のある問題を回避するために、 MongoDBプロフェッショナルまたはテクニカル サービスと直接連携することをお勧めします。

MongoDBでは、クラスターのメンテナンスウィンドウを構成することができ、Atlasがクラスターで週次メンテナンスを開始する時刻を設定できます。カスタムメンテナンスウィンドウを設定すると、ビジネスクリティカルな時間外に、レプリカセットごとに少なくとも1つのレプリカセットの選挙を必要とするメンテナンスをスケジュールできます。

また、プロジェクトに保護時間を設定することもできます。これは、標準更新では開始できない日次の時間枠を定義します。標準更新には、クラスターの再起動や再同期は含まれません。

次の例では、Atlas のオートメーション用ツールを使用して、単一リージョン、3 ノード レプリカセット / シャード配置トポロジーを構成します。

これらの例では、次のようなその他の推奨される構成も適用されます。

  • 開発およびテスト環境用にクラスター階層が M10 に設定されました。クラスター サイズ ガイドを使用して、アプリケーションのサイズに合った推奨クラスター階層を確認してください。

  • 単一リージョン、3 ノード レプリカ セットまたはシャード配置トポロジー。

当社の例では、AWSAzure、および Google Cloud を互換的に使用します。これら 3 つのクラウド プロバイダーのいずれかを使用できますが、クラウド プロバイダーに一致するようにリージョン名を変更する必要があります。クラウドプロバイダーとそのリージョンに関する詳細は、「クラウドプロバイダー」をご覧ください。

  • 中規模アプリケーション用のクラスター階層が M30 に設定されました。クラスター サイズ ガイドを使用して、アプリケーションのサイズに合った推奨クラスター階層を確認してください。

  • 単一リージョン、3 ノード レプリカ セットまたはシャード配置トポロジー。

当社の例では、AWSAzure、および Google Cloud を互換的に使用します。これら 3 つのクラウド プロバイダーのいずれかを使用できますが、クラウド プロバイダーに一致するようにリージョン名を変更する必要があります。クラウドプロバイダーとそのリージョンに関する詳細は、「クラウドプロバイダー」をご覧ください。

注意

Atlas CLI を使用してリソースを作成する前に、次の手順を実行する必要があります。

開発環境およびテスト環境では、プロジェクトごとに次のコマンドを実行します。ID と名前を変更して、 値を使用します。

atlas clusters create CustomerPortalDev \
--projectId 56fd11f25f23b33ef4c2a331 \
--region EASTERN_US \
--members 3 \
--tier M10 \
--provider GCP \
--mdbVersion 8.0 \
--diskSizeGB 30 \
--tag bu=ConsumerProducts \
--tag teamName=TeamA \
--tag appName=ProductManagementApp \
--tag env=Production \
--tag version=8.0 \
--tag [email protected] \
--watch

ステージング環境と本番環境において、各プロジェクトごとに次の cluster.json ファイルを作成します。ID と名前を変更して、自分の値を使用します。

{
"clusterType": "REPLICASET",
"links": [],
"name": "CustomerPortalProd",
"mongoDBMajorVersion": "8.0",
"replicationSpecs": [
{
"numShards": 1,
"regionConfigs": [
{
"electableSpecs": {
"instanceSize": "M30",
"nodeCount": 3
},
"priority": 7,
"providerName": "GCP",
"regionName": "EASTERN_US",
"analyticsSpecs": {
"nodeCount": 0,
"instanceSize": "M30"
},
"autoScaling": {
"compute": {
"enabled": false,
"scaleDownEnabled": false
},
"diskGB": {
"enabled": false
}
},
"readOnlySpecs": {
"nodeCount": 0,
"instanceSize": "M30"
}
}
],
"zoneName": "Zone 1"
}
],
"tag" : [{
"bu": "ConsumerProducts",
"teamName": "TeamA",
"appName": "ProductManagementApp",
"env": "Production",
"version": "8.0",
"email": "[email protected]"
}]
}

cluster.json ファイルを作成した後、各プロジェクトで次のコマンドを実行します。このコマンドは、cluster.json ファイルを使用してクラスターを作成します。

atlas cluster create --projectId 5e2211c17a3e5a48f5497de3 --file cluster.json

その他の構成オプションとこの例に関する情報については「atlas clusters create」を参照してください。

注意

Terraform でリソースを作成する前に、次の手順を実行する必要があります。

開発環境およびテスト環境では、アプリケーションと環境のペアごとに次のファイルを作成します。各アプリケーションと環境ペアのファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。

# Create a Project
resource "mongodbatlas_project" "atlas-project" {
org_id = var.atlas_org_id
name = var.atlas_project_name
}
# Create an Atlas Advanced Cluster
resource "mongodbatlas_advanced_cluster" "atlas-cluster" {
project_id = mongodbatlas_project.atlas-project.id
name = "ClusterPortalDev"
cluster_type = "REPLICASET"
mongo_db_major_version = var.mongodb_version
replication_specs {
region_configs {
electable_specs {
instance_size = var.cluster_instance_size_name
node_count = 3
}
priority = 7
provider_name = var.cloud_provider
region_name = var.atlas_region
}
}
tags {
key = "BU"
value = "ConsumerProducts"
}
tags {
key = "TeamName"
value = "TeamA"
}
tags {
key = "AppName"
value = "ProductManagementApp"
}
tags {
key = "Env"
value = "Test"
}
tags {
key = "Version"
value = "8.0"
}
tags {
key = "Email"
value = "[email protected]"
}
}
# Outputs to Display
output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv }
output "project_name" { value = mongodbatlas_project.atlas-project.name }
# Atlas Organization ID
variable "atlas_org_id" {
type = string
description = "Atlas Organization ID"
}
# Atlas Project Name
variable "atlas_project_name" {
type = string
description = "Atlas Project Name"
}
# Atlas Project Environment
variable "environment" {
type = string
description = "The environment to be built"
}
# Cluster Instance Size Name
variable "cluster_instance_size_name" {
type = string
description = "Cluster instance size name"
}
# Cloud Provider to Host Atlas Cluster
variable "cloud_provider" {
type = string
description = "AWS or GCP or Azure"
}
# Atlas Region
variable "atlas_region" {
type = string
description = "Atlas region where resources will be created"
}
# MongoDB Version
variable "mongodb_version" {
type = string
description = "MongoDB Version"
}
# Atlas Group Name
variable "atlas_group_name" {
type = string
description = "Atlas Group Name"
}
atlas_org_id = "32b6e34b3d91647abb20e7b8"
atlas_project_name = "Customer Portal - Dev"
environment = "dev"
cluster_instance_size_name = "M10"
cloud_provider = "AWS"
atlas_region = "US_WEST_2"
mongodb_version = "8.0"
# Define the MongoDB Atlas Provider
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
required_version = ">= 0.13"
}

ファイルを作成した後、各アプリケーションと環境ペアのディレクトリに移動し、次のコマンドを実行して Terraform を初期化します。

terraform init

Terraform プランを表示するには、次のコマンドを実行します。

terraform plan

次のコマンドを実行して、アプリケーションと環境のペアに対して 1 つのプロジェクトと 1 つのデプロイメントを作成します。コマンドは、ファイルと MongoDB & HashiCorp Terraform を使用して、プロジェクトとクラスターを作成します。

terraform apply

プロンプトが表示されたら、yes を入力し、Enter を押して設定を適用します。

ステージング環境と本番環境において、各アプリケーションと環境のペアごとに以下のファイルを作成します。各アプリケーションと環境のペアごとに、それぞれのディレクトリ内でファイルを配置します。ID と名前を変更して、自分の値を使用します。

# Create a Group to Assign to Project
resource "mongodbatlas_team" "project_group" {
org_id = var.atlas_org_id
name = var.atlas_group_name
usernames = [
"[email protected]",
"[email protected]"
]
}
# Create a Project
resource "mongodbatlas_project" "atlas-project" {
org_id = var.atlas_org_id
name = var.atlas_project_name
# Assign the Project the Group with Specific Roles
team_id = mongodbatlas_team.project_group.team_id
role_names = ["GROUP_READ_ONLY", "GROUP_CLUSTER_MANAGER"]
}
# Create an Atlas Advanced Cluster
resource "mongodbatlas_advanced_cluster" "atlas-cluster" {
project_id = mongodbatlas_project.atlas-project.id
name = "ClusterPortalProd"
cluster_type = "REPLICASET"
mongo_db_major_version = var.mongodb_version
replication_specs {
region_configs {
electable_specs {
instance_size = var.cluster_instance_size_name
node_count = 3
}
priority = 7
provider_name = var.cloud_provider
region_name = var.atlas_region
}
}
tags {
key = "BU"
value = "ConsumerProducts"
}
tags {
key = "TeamName"
value = "TeamA"
}
tags {
key = "AppName"
value = "ProductManagementApp"
}
tags {
key = "Env"
value = "Production"
}
tags {
key = "Version"
value = "8.0"
}
tags {
key = "Email"
value = "[email protected]"
}
}
# Outputs to Display
output "atlas_cluster_connection_string" { value = mongodbatlas_advanced_cluster.atlas-cluster.connection_strings.0.standard_srv }
output "project_name" { value = mongodbatlas_project.atlas-project.name }
# Atlas Organization ID
variable "atlas_org_id" {
type = string
description = "Atlas Organization ID"
}
# Atlas Project Name
variable "atlas_project_name" {
type = string
description = "Atlas Project Name"
}
# Atlas Project Environment
variable "environment" {
type = string
description = "The environment to be built"
}
# Cluster Instance Size Name
variable "cluster_instance_size_name" {
type = string
description = "Cluster instance size name"
}
# Cloud Provider to Host Atlas Cluster
variable "cloud_provider" {
type = string
description = "AWS or GCP or Azure"
}
# Atlas Region
variable "atlas_region" {
type = string
description = "Atlas region where resources will be created"
}
# MongoDB Version
variable "mongodb_version" {
type = string
description = "MongoDB Version"
}
# Atlas Group Name
variable "atlas_group_name" {
type = string
description = "Atlas Group Name"
}
atlas_org_id = "32b6e34b3d91647abb20e7b8"
atlas_project_name = "Customer Portal - Prod"
environment = "prod"
cluster_instance_size_name = "M30"
cloud_provider = "AWS"
atlas_region = "US_WEST_2"
mongodb_version = "8.0"
atlas_group_name = "Atlas Group"
# Define the MongoDB Atlas Provider
terraform {
required_providers {
mongodbatlas = {
source = "mongodb/mongodbatlas"
}
}
required_version = ">= 0.13"
}

ファイルを作成した後、各アプリケーションと環境ペアのディレクトリに移動し、次のコマンドを実行して Terraform を初期化します。

terraform init

Terraform プランを表示するには、次のコマンドを実行します。

terraform plan

次のコマンドを実行して、アプリケーションと環境のペアに対して 1 つのプロジェクトと 1 つのデプロイメントを作成します。コマンドは、ファイルと MongoDB & HashiCorp Terraform を使用して、プロジェクトとクラスターを作成します。

terraform apply

プロンプトが表示されたら、yesと入力し、Enterを押して設定を適用してください。

この例に関するその他の設定オプションや情報については、「MongoDB & HashiCorp Terraform」およびMongoDB Terraform のブログ記事をご覧ください。

戻る

信頼性

項目一覧