MongoDB Atlas を含む AWS ランディングゾーンを構築する - AWS 規範ガイダンス
概要前提条件と制限アーキテクチャツールエピック関連リソース

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

MongoDB Atlas を含む AWS ランディングゾーンを構築する

Igor Alekseev (Amazon Web Services)

Anuj Panchal (MongoDB)

概要

このパターンでは、MongoDB Atlas クラスターと統合された AWS ランディングゾーンを構築する方法について説明します。インフラストラクチャは Terraform スクリプトを使用して自動的にデプロイされます。

ランディングゾーンと呼ばれるよく構造化されたマルチアカウント AWS 環境は、特に企業にスケーラビリティとセキュリティを提供します。これは、ワークロードとアプリケーションを迅速にデプロイするための基盤として機能し、セキュリティとインフラストラクチャの信頼性を確保するのに役立ちます。ランディングゾーンを構築する場合は、アカウント構造、ネットワーク、セキュリティ、アクセス管理などの技術的およびビジネス上の要因を慎重に検討する必要があります。これらの考慮事項を、組織の将来の成長とビジネス目標に一致させる必要があります。

このパターンのユースケースには、次のようなものがあります。

  • エンタープライズ SaaS および PaaS プラットフォーム: で実行されるマルチテナント Software as a Service (SaaS) アプリケーションおよび Platform as a Service (PaaS) プラットフォーム AWS は、この設定を使用して、パブリックインターネット経由でデータを公開することなく、MongoDB Atlas への安全なプライベートアクセスを提供できます。

  • 規制の厳しい業界: Health Insurance Portability and Accountability Act (HIPAA)、Payment Card Industry Data Security Standard (PCI DSS)、System and Organization Controls 2 (SOC2)、一般データ保護規則 (GDPR) などの基準に厳密に準拠する必要がある銀行、金融サービス、医療、政府機関のワークロードには、以下によるメリットがあります。

    • を介した暗号化されたプライベート接続 AWS PrivateLink

    • MongoDB レプリカセットのマルチ AZ 高可用性

  • 安全な AI/ML ワークロード: Amazon Bedrock、Amazon SageMaker AI、またはカスタム AI モデルのトレーニングパイプラインまたは推論パイプラインは、PrivateLink 経由で MongoDB Atlas にデータを安全に取得して保存できます。

  • ディザスタリカバリとビジネス継続性: マルチ AZ 設計により、単一のアベイラビリティーゾーンの障害によってワークロードが中断されることはありません。アベイラビリティーゾーン間で設定された Atlas レプリカにより、自動フェイルオーバーが保証されます。これは、金融技術 (フィンテック) アプリ、デジタルバンキング、医療モニタリングなどの常時稼働サービスにとって重要です。

前提条件と制限

前提条件

  • Atlas API キーを作成するための、MongoDB Atlas への組織所有者アクセス権。この要件の詳細については、MongoDB ドキュメントの「組織のアクセス管理」を参照してください。

  • アクティブな AWS アカウント。

  • インストールおよび設定済みの Terraform。

  • MongoDB バージョン 6.0 以降で作成された MongoDB Atlas クラスター。

  • MongoDB および MongoDB Atlas に精通していること。詳細については、MongoDB Atlas のドキュメントをご参照ください。

制限事項

アーキテクチャ

次のリファレンスアーキテクチャ図は、MongoDB Atlas プライベートエンドポイントと統合された AWS ランディングゾーンのデプロイ設定を示しています。このリファレンスアーキテクチャは、MongoDB Atlas と統合された安全でスケーラブルで可用性の高い AWS ランディングゾーンを確立する方法を示しています。マルチ AZ 配置、最小特権のセキュリティコントロール、プライベート接続などの AWS ベストプラクティスを組み合わせることで、組織は最新のアプリケーション向けに堅牢な環境をプロビジョニングできます。

MongoDB Atlas と統合された AWS ランディングゾーンのマルチ AZ アーキテクチャ。

このアーキテクチャは以下の要素で構成されます。

VPC

  • 単一の仮想プライベートクラウド (VPC) が 3 つのアベイラビリティーゾーンをカバーしています。

  • この VPC は、アベイラビリティーゾーンごとのサブネットとして分割されます。これらのサブネットは、ワークロードを分散して高可用性を実現します。

インターネットアクセス

  • インターネットゲートウェイは、アプリケーションや踏み台ホストなど、インターネット接続を必要とするリソースのアウトバウンドインターネット接続を提供します。

  • パブリックサブネットには NAT ゲートウェイを格納できます。こうすることにより、プライベートサブネットワークロードは更新、パッチ、その他の必要なパッケージを、パブリックインターネットに直接公開することなくダウンロードできるようになります。

プライベートサブネットとルートテーブル

  • アプリケーションコンポーネント、マイクロサービス、またはその他の機密性の高いリソースは通常、プライベートサブネット内に置かれます。

  • 専用ルートテーブルはトラフィックフローを制御します。プライベートサブネットから NAT ゲートウェイに直接アウトバウンドトラフィックをルーティングして、Egress-Only の安全なインターネットアクセスを実現します。

  • インターネットからのインバウンドリクエストは、パブリックサブネット内の伸縮性のあるロードバランサーまたは踏み台ホスト (使用する場合) を経由し、プライベートサブネットリソースに適切にルーティングされます。

PrivateLink を介した MongoDB Atlas 接続

  • このアーキテクチャでは、(VPC エンドポイントを介して) PrivateLink を使用して、データをパブリックインターネットに公開することなく MongoDB Atlas に安全に接続します。

  • リクエストは AWS バックボーンネットワークに残ります。転送中のデータには PrivateLink 暗号化の利点があり、パブリックインターネット経由でルーティングされることはありません。

  • MongoDB Atlas 専用 VPC は、プライマリノードとセカンダリノードをホストし、安全で隔離された環境をマネージドデータベースクラスターに提供します。

マルチ AZ 配置

  • 重要なインフラストラクチャコンポーネント (NAT ゲートウェイやアプリケーションサブネットなど) は、少なくとも 3 つのアベイラビリティーゾーンに分散されます。アベイラビリティーゾーンで機能停止が発生した場合、このアーキテクチャにより、残りのアベイラビリティーゾーンのワークロードが引き続き動作します。

  • MongoDB Atlas は、レプリカセットを通じた高可用性をデフォルトで提供し、データベースレイヤーの耐障害性を維持します。重要なインフラストラクチャが少なくとも 3 つのアベイラビリティーゾーンに分散されることいより、レジリエンスを実現します。

ツール

AWS のサービス

  • AWS Secrets Manager を使用すると、認証情報 (パスワードを含む) をコード内にハードコードする代わりに、プログラムによってシークレットを取得する API コールを使用できます。

その他の製品とツール

  • MongoDB Atlas は、MongoDB データベースをクラウドにデプロイおよび管理するためのフルマネージド型 Database as a Service (DbaaS) です。

  • 「Terraform」は、HashiCorp の infrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。このパターンでは、Terraform を使用してスクリプトを実行し、 AWS と MongoDB Atlas に必要なリソースのデプロイを容易にします。

コードリポジトリ

このパターンのコードは、GitHub の AWS and MongoDB Atlas Landing Zone リポジトリで入手できます。

エピック

タスク説明必要なスキル

主要なステークホルダーを識別

ランディングゾーンプロジェクトに関与するすべての主要なステークホルダーとチームメンバーを特定します。これには、次のようなロールが含まれる可能性があります。

  • データベース管理者 (DBA)

  • DevOps エンジニア

  • アプリケーションデベロッパー

  • アプリケーションアーキテクト

移行リード

構造ブループリントを作成

AWS と MongoDB Atlas 対応ランディングゾーンの必要な構造を概説する設計図を作成します。

移行リード

アーキテクチャプランを作成

アプリケーションアーキテクトと協力して要件を分析し、耐障害性と回復力に優れたアーキテクチャを設計します。このパターンは、参照用のスターターアーキテクチャテンプレートを提供します。このテンプレートは、組織のセキュリティとインフラストラクチャのニーズに合わせてカスタマイズできます。

クラウドアーキテクト

セットアップとデプロイを計画

すべてのステークホルダーと共に、アーキテクチャのデプロイ方法、セキュリティ対策の実装方法、その他の側面を決定し、組織の利益とリクエスト元のチームの利益を合致させます。

移行リード、DevOps エンジニア、DBA
タスク説明必要なスキル

リポジトリのクローン作成

コマンドを実行して、GitHub リポジトリからコードをクローンします。

git clone https://github.com/mongodb-partners/AWS-MongoDB-Atlas-Landing-Zone
アプリ開発者、DevOps エンジニア

Atlas 組織 ID を取得

  1. MongoDB Atlas アカウントをお持ちでない場合は、サインアップしてください。

  2. MongoDB ドキュメントの手順に従って、組織を作成します。

  3. 組織 ID をコピーします。

DBA

Atlas 組織レベルの API キーを生成

Atlas で組織レベルの API キーを生成するには、MongoDB ドキュメントの指示に従います。

DBA

でシークレットを作成します AWS Secrets Manager。

前のステップで生成された MongoDB Atlas API キーを、キーと値のシークレットとして Secrets Manager に保存します。手順については、Secrets Manager のドキュメントを参照してください。

DevOps エンジニア

Atlas クラスター層を選択

Atlas クラスター層を適切に選択するには、MongoDB のドキュメントの指示に従ってください。

DBA
タスク説明必要なスキル

Terraform スクリプトを変更

GitHub リポジトリのローカルコピーで、Modules/mongodb-atlas/main.tf ファイルのシークレット名 (12 行目) を更新し、Terraform がデプロイ中に Secrets Manager から認証情報を取得できるようにします。

DevOps エンジニア

AWS アクセスキー ID とシークレットキーを作成します。

AWS アクセスキー ID とシークレットキーを作成するには、 AWS 「re:Post」の記事AWS 「アクセスキーの作成方法」の手順に従います。

必要な最小特権でポリシーを割り当てるのがベストプラクティスですが、この場合は AdministratorAccess ポリシーを選択します。

アクセスキーを作成したら、「IAM でのセキュリティのベストプラクティス」を読み、アクセスキーを管理するためのベストプラクティスを確認してください。

DevOps エンジニア

Elastic IP アドレスの割り当て

少なくとも 2 つの Elastic IP アドレス ID を割り当てます。手順については、Amazon Virtual Private Cloud (Amazon VPC) のドキュメントを参照してください。

DevOps エンジニア

S3 バケットを作成する

Amazon Simple Storage Service (Amazon S3) ドキュメントの手順に従って、Terraform デプロイの状態を保存する S3 バケットを作成します。

DevOps エンジニア

ストレージ用に S3 バケットを更新する

前のステップで作成したバケットの名前とリージョンと一致するように、ローカルバージョンの environments/development/main.tf の S3 バケット情報を更新し、キープレフィックスを指定します。例えば、次のようになります。

terraform {
       ...
  backend "s3" {
    bucket = "startup-name-product-terraform"
    key    = "network/dev"
    region = "ap-southeast-1"
  }
}

この例では、キープレフィックス network/dev を使用して Terraform 状態ファイルを整理するように Terraform を設定できます。値は、作成する環境に合わせて prod または staging に変更できます。複数の環境を使用する方法については、このセクションの最後のステップを参照してください。

Amazon S3 キープレフィックスの詳細は、Amazon S3 ドキュメントの「プレフィックスを使用してオブジェクトを整理する」を参照してください。

DevOps エンジニア

Terraform 変数を設定

このサンプルランディングゾーンは、Terraform 変数定義ファイルを使用して入力変数値を定義します。

変数ファイルは environments/development/variables.tf にあります。変数値は environments/development/terraform.tfvars ファイル内で設定できます。GitHub リポジトリの Readme ファイルの説明に従って、これらの変数を設定します。

DevOps エンジニア

環境変数の設定

ローカルマシンで Terraform スクリプトを実行する予定がある場合は、次の環境変数を設定します。

  • AWS_ACCESS_KEY_ID: AWS アクセスキー ID

  • AWS_SECRET_ACCESS_KEY: AWS シークレットアクセスキー

  • AWS_DEFAULT_REGION: AWS リージョン

  • TF_LOG: Terraform ログレベル (DEBUG または INFO)

環境変数の設定の詳細は、AWS Command Line Interface (AWS CLI) ドキュメントを参照してください。

DevOps エンジニア

VPC 設定の確認

が推奨するベストプラクティスに従うには AWS、組織のニーズに合わせて Terraform スクリプトで VPC とサブネット CIDRs、NAT ゲートウェイ、ルート、ルートテーブルを設定します。詳細は、GitHub リポジトリの Readme ファイルを参照してください。

DevOps エンジニア

リソースのタグ付け

AWS リソースにタグを付けて、Terraform スクリプトによってデプロイされたときにモニタリングできます。例については、GitHub リポジトリの Readme ファイルを参照してください。コスト、使用状況などのタグによるリソースのモニタリングについては、 AWS Billing ドキュメントの「ユーザー定義のコスト配分タグのアクティブ化」を参照してください。

DevOps エンジニア

複数の環境の使用

GitHub リポジトリは development 環境フォルダを提供します。環境フォルダに独自の環境を追加することもできます。

環境を追加するには、development フォルダを、environments の下位の新しいフォルダ (prod や staging など) にコピーします。その後、terraform.tfvars ファイルを新しい値で更新できます。

DevOps エンジニア
タスク説明必要なスキル

Terraform 作業ディレクトリの初期化

作業ディレクトリを初期化し、必要なパッケージをダウンロードするには、次のコマンドを実行します。

terraform init
DevOps エンジニア

実行プランの作成

実行プランを作成し、Terraform がインフラストラクチャに加える変更を視覚化するには、次のコマンドを実行します。

terraform plan
DevOps エンジニア

変更のデプロイ

コードの説明に従ってインフラストラクチャに変更を実装するには、次のコマンドを実行します。

terraform apply
DevOps エンジニア

デプロイの検証

Terraform がインフラストラクチャで作成または変更したコンポーネントを検証します。

セットアップをテストするには、 または VPC にアタッチされたコンピューティングリソース (Amazon EC2 インスタンスや AWS Lambda 関数など) をプロビジョニングします。

DevOps エンジニア、アプリケーションデベロッパー
タスク説明必要なスキル

クリーンアップ

テストが完了したら、次のコマンドを実行して、Terraform がインフラストラクチャにデプロイしたリソースを破棄します。

terraform destroy
DevOps エンジニア

関連リソース

発見と評価

MongoDB Atlas と AWS 環境のセットアップ

ランディングゾーンのデプロイ