このページには次のものが含まれます
- 既存のMongoDBのデプロイをMongoDB Atlasに持ち込み、管理することはできますか?
- AtlasはクラスタにMongoDBのどのバージョンを使用していますか?
- リージョンをまたいでマイグレーションすることは出来ますか?
- リージョンをまたいだデプロイをサポートしていますか?
- AtlasはAWSのどのリージョンをサポートしていますか?
- MongoDB Atlasはどのように高可用性を実現しますか?
- クレジットカードがなくてもMongoDB Atlasの支払いは可能でしょうか?
- MongoDB Atlasプロジェクトには自分のVPCを指定できますか?
- MongoDB Atlasを使用すべきでしょうか? もしくは Cloud Managerを使用すべきでしょうか?
- 既存のMongoDB Cloud Managerのアカウントを持っていますが、新規MongoDB Atlasプロジェクトを作るにはどうしたら良いでしょうか?
- 既存のAtlasのアカウントを持っていますが、新規Atlasプロジェクトを作るにはどうしたら良いでしょうか?
- デプロイでSSL/TLSを無効化することはできますか?
- プロジェクトを削除するにはどうすれば良いでしょうか?
- Atlasクラスタを一時停止や停止することはできますか?
- アラートを変更するにはどうすれば良いでしょうか?
- MongoDB Atlasではoplogを読込めますか?
- MongoDB Atlasは24以上のシャードを持つクラスタをデプロイできますか?
- Atlasはどのようにしてデータを暗号化しますか?
- Atlasのシャードされたクラスタ内のチャンクを事前に分けることはできますか?
- MongoDB Cloudのシステムステータスをどこで見ることができますか?
- MongoDB 3.2.で実行しているクラスタがあります。今後のEOLでどのような影響を受けるでしょうか?
- AtlasはどのバージョンのTLSをサポートしていますか?
- Atlasクラスタのサポートはどのようにして受けられますか?
- 私のAtlasユーザアカウントを削除する方法を教えてください
既存のMongoDBのデプロイをMongoDB Atlasに持ち込み、管理することはできますか?
いいえ。しかしながら、既存のMongoDBのデプロイのデータをMongoDB Atlasにアップロードすることは可能です。
- AtlasのLive Migrate機能を使用すれば、ソースレプリカセットからAtlasのレプリカセットクラスタへ移行できます。
- AtlasのLive Migrate機能を使用すれば、移行元のシャードされたクラスタをAtlasのシャードされたクラスタに移行できます。
- mongomirrorを使用すれば、既存のMongoDBレプリカセットのデータからMongoDB Atlasに移行できます。
- mongodumpおよびmongorestoreを使用することで、既存のスタンドアロン、レプリカセット、およびシャードされたクラスタから取り出したデータを元にして、新規のMongoDB Atlasクラスタをデプロイし、使用を開始することができます
情報として、こちら(Import Data into Cluster)をご覧ください。
公式のMongoDBサポートドライバを使用してスクリプトを作成することもできます。
AtlasはクラスタにMongoDBのどのバージョンを使用しますか?
Atlasでは、M10以上の有料プランで以下のバージョンのMongoDBをサポートしています。
- MongoDB 3.4
- MongoDB 3.6
- MongoDB 4.0
MongoDB Server 3.2は、2018年9月でサポート終了予定です。AtlasはMongoDB 3.2のクラスタのデプロイサポートを2018年3月で終了しました。
2018年4月23日以降、M0(無料プラン)およびM2/M5の共有型クラスタではMongoDB 3.6のみサポートします。
新規のメンテナンスリリースが使えるようになると、Atlasはクラスタの可用性維持のために、ローリングプロセスを経て自動的にこのようなリリースにアップグレードします。
リージョンをまたいでマイグレーションすることは出来ますか?
はい。使用しているクラスタは、同じクラウドプロバイダーの中で、異なるリーションに変更することができます。MongoDB Atlasは、元のリージョンから新しいリージョンにノードを移動させるためにローリングマイグレーション戦略を使用して、クラスタの可用性を維持します。
AWSのみ:
Amazon Web Services (AWS) Virtual Private Cloud (VPC)のピアリング接続はリージョン特有になります。指定したAWSリージョン内のAWS VPCに既存のVPCピアリング接続を利用しているクラスタは、異なるAWSリージョンに移動させるとピアリング接続へのアクセスができなくなります。AWSは異なるリージョン間のVPCピアリング接続をサポートしておりません。ドキュメント一式はこちら(Set up VPC Peering Connection)をご参照ください。
異なるCloud サービスプロバイダー上のリージョンをまたがるデータをマイグレーションする必要がある場合、次が可能です:
- ライブマイグレーションを実行する
- mongomirrorを使用してマイグレーションする
- mongorestoreを使用して移行先クラスタにシードする
- 移行元クラスターから移行先クラスターへバックアップを復元する
こちらもご参照ください: Import Strategies for Common Cluster Configurations
リージョンをまたいだデプロイをサポートしていますか?
はい。デプロイを作成またはスケーリングする時に、可用性を高めたりローカルで読み込めるよう追加のリージョンを指定できます。
Atlasはクラウドサービスプロバイダーをまたがったデプロイをサポートしておりません。
AtlasはAWSのどのリージョンをサポートしていますか?
Atlasは中国およびUS GovCloud以外の、全てのAWSのリージョンをサポートをしております。詳細はこちら(Amazon Web Services)をご覧ください。
MongoDB Atlasはどのように高可用性を実現しますか?
Atlasクラスターは、MongoDBのレプリケーション機能を使用し、高可用性を提供します。全てのAtlasクラスターは、レプリカセットかシャードされたクラスタであり、それぞれのシャードはレプリカセットになります。MongoDBレプリカセットおよびレプリケーションに関するドキュメントはこちら(Replication)をご参照ください。
Atlasはローリングアップグレード戦略を使用して、セキュリティパッチを適用したり、Atlasクラスタをスケールアップするようなメンテナンスもしくはインフラ操作を実行します。ローリングアップグレード戦略では、ほとんどのメンテナンスまたはインフラ操作のためのクラスタの読込み、書込み処理を保証します。ローリングアップグレード手順の中で以下のようなことが行われます:
- Atlasは変更箇所をクラスタ内のそれぞれのセカンダリノードに適用します。
- Atlasはプライマリノードをセカンダリステートに下げ、新しいプライマリの選出を引き起こします。
- クラスタが一旦新しいプライマリを持つと、Atlasはその変更箇所を前のプライマリノードに適用します。
クラスタが新しいプライマリを選出している間は、書込み操作をしてはいけません。クラスタはこの間に、セカンダリの読込み操作を処理し続けることができます。通常、Atlasクラスタにおける選出は数秒内で完了します。ネットワーク遅延といった要因は、レプリカセット選定の完了までに要する時間を引き延ばすかもしれません。これはクラスタがプライマリなしで運用する時間に影響を及ぼすことになります。これらの要因は、ご自身の(特定の)クラスタアーキテクチャによって異なります。
MongoDB 3.6における再試行可能な書込み
MongoDB 3.6以降では、ドライバが特定の書込み操作を一度だけ自動で再試行できます。再試行可能な書込みにより、自動的なフェイルオーバーと選出のビルドイン処理が用可能となります。再試行可能な書込みをサポートするには、クラスタはMongoDB 3.6もしくはそれ以上を実行していなくてはいけません。再試行可能な書込みに関するドキュメントや条件はこちら(retryable writes)をご参照ください。
この機能を有効化するには、Atlas URI コネクションストリングに「retryWrites=true」を追記してください。URIコネクションストリングを使用するAtlasクラスタに接続する詳細に関しては、こちら(Connect via Driver)をご参照ください。
M10以上のAtlasは、アプリケーションがレプリカセットの選出を適切に検知し対応するように設計されているかどうか、アプリケーション開発者が確認できるTest Failover 機能を提供しています。レプリカセットの選択をシームレスに処理できるアプリケーションを設計することで、開発者はクラスタで発生する基本的なメンテナンスについて心配する必要がなくなりました。
Atlasのメンテナンス作業には、MongoDB データベースそのものに対するOSパッチやメンテナンスパッチ(例えば、v3.6.3 から v3.6.4)が含まれます。インフラ運用には、障害のあるインフラを置き換えるために必要な修復作業、およびクラスタサイズの変更と言った予定されたインフラの置き換えが含まれます。
MongoDB Atlasを最適な可用性で使用できるようアプリケーションを設計するためのヘルプが必要な場合は、Atlasサポートにお問い合わせください。
クレジットカードがなくてもMongoDB Atlasの支払いは可能でしょうか?
クレジットカード決済以外でのAtlasご購入方法に関しましては、MongoDB Inc.までご連絡ください。(訳注: 日本国内のお客様は、クリエーションライン(株)窓口 までお問い合わせください)
MongoDB Atlasプロジェクトには自分のVPCを指定できますか?
いいえ、できません。 Atlasプロジェクトとそのクラスタは、リージョン特有の仮想プライベートクラウド(VPC)に関連付けられます。
AtlasはM10 以上の有料クラスタを、特定の指定したプロバイダーおよびリージョンに初めてデプロイする時にVPCを作成します。マルチリージョンクラスタの場合、Atlasはもしそのリージョンに既にVPCが存在しなければ、リージョンごとに1つのVPCを作成します。
Atlasはまた、AWS VPCへのVPCピアリング接続を作成すると、VPCを作成します。(AWSでのデプロイのみに限ります。)Atlasは、ピアVPCと同じリージョンにVPCを作成します。
異なるVPC(例えば、お客様自身のクラウドインフラストラクチャアカウント)を使用するには、MongoDB Cloud ManagerまたはOps Managerを使用する必要があります。
MongoDB Atlasを使用すべきでしょうか? もしくは Cloud Managerを使用すべきでしょうか?
Atlasは管理され、簡素化されたユーザ体験をご提供します。Atlasユーザーは、各種設定の厳選された各種設定およびインフラ上でMongoDBを利用することができます。利用できるAtlasの設定やインフラオプションは、一部のユーザーが必要とする柔軟性が得られない場合があるかもしれません。例えば、Atlasはクラスタ接続にTLSを必要とし、TLSを無効化するオプションはありません。Atlasは、管理が必要になるパーツの移動を減らし、開発者とデータベース管理者の生産性を向上させたいユーザーに最適です。
MongoDB Cloud Managerは、より多くの設定オプションを公開することで、ユーザーが選んだインフラにより詳細な制御が設定できます。Cloud Managerユーザーは、高度な操作およびより高いレベルの制御へのアクセスが可能ですが、インフラのライフサイクル全体を管理する必要があります。Cloud Managerは、MongoDB クラスタに対してより高度な制御をかけたいユーザーに最適です。
企業のニーズにどのMongoDBサービスが最適かアドバイスが必要でしたら、こちらにお問い合わせください。(訳注: 日本国内のお客様は、クリエーションライン(株)窓口までお問い合わせください)
既存のMongoDB Cloud Managerのアカウントを持っていますが、新規MongoDB Atlasプロジェクトを作るにはどうしたら良いでしょうか?
Cloud Managerの「Context」 ドロップダウンから 「New Project」を選択します。
「Create a New Project」画面で、AtlasプロジェクトかCloud Managerプロジェクトのどちらを作るか選択できます。「MongoDB Atlas」を選択し、プロジェクトの作成を続けます。
既存のAtlasのアカウントを持っていますが、新規Atlasプロジェクトを作るにはどうしたら良いでしょうか?
Cloud Managerの「Context」 ドロップダウンから 「New Project」を選択します。
「Create a New Project」画面で、AtlasプロジェクトかCloud Managerプロジェクトのどちらを作るか選択できます。「MongoDB Atlas」を選択し、プロジェクトの作成を続けます。
デプロイしたMongoDB AtlasクラスタのSSL/TLSを無効化することはできますか?
いいえ、できません。
プロジェクトを削除するにはどうすれば良いでしょうか?
プロジェクトが次の条件であれば削除が可能です
- 削除しようとしているユーザが「プロジェクトオーナー」ロールを持っている
- 未払いの請求書が発行されていない
- アクティブなクラスタがない
組織内のプロジェクトを削除するには、その組織の「Project」ビューまたはプロジェクトの「Project Setting」ビューで削除可能です。詳細はこちら(Delete a Project)をご参照ください。
Atlasクラスタを一時停止や停止することはできますか?
M10以上の有料クラスタは、一度に最長7日間停止することができます。Atlasは7日後に自動的にクラスタを再スタートします。この件に関するドキュメントをご覧になりたければこちら(Pause a Cluster)をご参照ください。
アラートの変更をするにはどうすれば良いでしょうか?
既存のアラート設定を変更するには、「Alerts」から「Alert Setteings」を選択します。省略符号「...」をクリックし、アクティブなアラートの設定を編集(編集、複製、無効化、削除)します。
MongoDB Atlasではoplogを読込めますか?
はい。oplogにアクセスするには、データベースのユーザーがローカルのデータベースに読込みアクセス権を持つ必要があります。ユーザーへローカルの読込みアクセス権を付与する方法は次の通りです:
- 「Clusters」をクリックし、「Security」をクリックする
- 「Add New User」をクリックしユーザー名を入力する。例えば”oploguser”など。
- 「Show Advanced Options」をクリックし、「read」ロールと「local」データベースを選択する。ここでユーザーのローカルデータベースの読込み操作を制限します。
- パスワードを入力し「Add User」をクリックする
注:
クラスタのoplogのサイズを増やすには、Atlasナビゲーションウィンドウの「Support」をクリックし、次の情報を入力したヘルプチケットを発行します:
- Atlasクラスタの名前およびURL
- ご希望のoplogサイズ、および
- より大きいoplogを必要とするユースケース
MongoDB Atlasは24以上のシャードを持つクラスタをデプロイできますか?
MongoDB Atlasは難しい設定なしですぐに最大24シャードを選出することができますが、24以上のシャードをご希望のお客様はMongoDBにお問合せください。
Atlasはどのようにしてデータを暗号化しますか?
Atlasはクラスタデータやそのデータのバックアップを含む全ての保存したデータに、全ボリューム(ディスク)暗号化を使用します。
Atlasはまた、クライアントデータおよびクラスタ内ネットワークでの通信にTLS暗号化を必要とします。
Atlas暗号化に関するより詳しい情報は、Atlasサポートまでお問合せください。Atlasプロジェクトまたはクラスタのビューからは、左側のナビゲーションバーの「Support」をクリックしてください。
Atlasのシャードされたクラスタ内のチャンクを事前に分けることはできますか?
「Atlas Admin」MongoDBユーザーロールには、空のシャードされたコレクション内のチャンクを事前に分けるのに必要な権限が含まれています。
シャードされたクラスタのチャンク作成および管理に関するドキュメントはこちら(Create Chunks in a Shaded Cluster)をご参照ください。
MongoDB Cloudのシステムステータスをどこで見ることができますか?
AtlasおよびCloud Managerを含むMongoDBのステータスを見るには、 https://status.cloud.mongodb.com へアクセスしてください。
お好みのRSSリーダーを使用して、MongoDB Cloudステータスページの「RSS feed」を購読することも可能です。
MongoDB 3.2.で実行しているクラスタがあります。今後のEOLでどのような影響を受けるでしょうか?
(訳注: 下記の通り MongoDB 3.2は2018年9月でEOL(End of Life, サポート終了)となっています。2018年11月現在MongoDB AtlasではMongoDB 3.2でクラスタを構築することはできません。お客様環境におけるMongoDB 3.2以前の環境をMongoDB Atlasに移行する際の技術支援については、各提供ベンダにお問い合わせください)
MongoDB Server 3.2は、2018年9月でサポート終了予定です。AtlasはMongoDB 3.2のクラスタのデプロイサポートを2018年3月で終了しました。
Atlasは2018年9月に、MongoDB 3.2で実行されている全てのクラスタをMongoDB 3.4に自動的にアップグレードします。2018年9月以前でも、プロジェクトオーナーはいつでもMongoDB 3.2クラスタをアップグレードすることができます。
クラスタをMongoDB 3.2からMongoDB 3.4、もしくはそれ以上にアップグレードするには、次を行ってください:
- MongoDB Server 3.4の「Release Notes」を読んでください
- MongoDB Server 3.4の「Compatibility Changes」を読んでください
- ご使用のアプリケーションのMongoDBドライババージョンが、MongoDB 3.4と互換性があるか確認してください。
- ご使用のアプリケーションのMongoDBドライバが、MongoDB 3.4をサポートする最新のバージョンになるようアップグレードしてください。
- 「Test Failover」機能を使用して可用性テストを実行し、アプリケーションが正しく動作し、クラスタリーダーの変更に正しく追随できることを確認してください。主要なMongoDBのバージョン変更を実行する際に、Atlasはローリング戦略を採用し、クラスタの高可用性をサポートします。ローリングアップデートではレプリカセットあたり最低1回リーダーエレクションが実行されます。
主要なバージョン変更のアップグレードをご自身で実行する場合は、MongoDBが推奨している手順であるこちら(Atlas Major Version Change Procedure)を参照してください。この手順は、新しいMongoDBバージョンのアプリケーション、クラスタのパフォーマンスおよび機能性をテスト、検証することを目的としたステージングクラスタの作成を含みます。
3.2のEOLおよび計画されているアップグレードに関するご質問、コメント、ご相談でAtlasのサポートとコンタクトを取りたい方は、Atlas UIの左側のナビゲーションにある「Select」を選択してください。
AtlasはどのバージョンのTLSをサポートしていますか?
2018年7月以降に作成されたAtlasのデプロイは、デフォルトではTransport Layer Security (TLS)プロトコルバージョン1.1および1.2のみサポートします。2018年7月以前に作成されたAtlasのデプロイは、デフォルトではTLSプロトコルバージョン1.0、1.1、1.2をサポートします。Atlasは2018年8月以降、デフォルトではすべてのAtlasクラスタのTLS 1.1および1.2のみサポートします。
TLS 1.0を非推奨とすることにより、転送中のデータセキュリティが向上し、業界のベストプラクティスと合わせることができます。TLSが有効な時に、MongoDB 4.0がTLS 1.1もしくはそれ以降のバージョンが必要なのはこのためです。AtlasはすべてのAtlasクラスタに対してTLS接続を必要とするため、MongoDB 4.0で実行しているAtlasクラスタでは、デフォルトでTLS 1.1もしくはそれ以降が常に使用されます。
変更に関するタイミングや理由に関しては、「Payment Card Industry (PCI)」および「National Institute of Standards and Technology (NIST)」をご覧ください。
TLSサポートに関するご質問または2018年8月下旬までにご使用のアプリケーションをTLS1.1またはそれ以降のバージョンをサポートするためのアップデートができない場合は、Atlasサポートまでお問合せください。
「Atlas support ticket」を開くには、Atlasアカウントにログインしてください。Atlas UIにある「Support」リンクをクリックし、必要事項を記入してください。
使用しているアプリケーションが TLS 1.1またはそれ以降をサポートしているかを、どうやって確かめられますか?
TLS 1.1は2006年4月に策定されました。基になるプログラミング言語またはセキュリティライブラリがTLS 1.1以前のアプリケーションは、TLS1.1もしくはそれ以降に対応するよう、より新しいバージョンにアップデートすることが必要です。アプリケーションホストオペレーティングシステムもまた、TLS 1.1もしくはそれ以降に対応するようアップデートが必要です。
MongoDBおよびAtlasは、外部のアプリケーションがどのTLSバージョンをサポートしているか監査するサービスは提供しておりません。「howsmyssl.com」のようなサードパーティサービスでは、上記に対する適切なツールを提供しています。MongoDBは前述のサービスを推奨するわけではなく、あくまで情報として提示しています。あなたの会社の規定に従い、監査のための適切なベンダやアプリケーション監査サービスを選定し、TLS1.0が無効になっているかを確認してください。
クラスタをTLS 1.1もしくはそれ以上にアップデートするためには何をすれば良いでしょうか?
2018年8月下旬以降、Atlasは既存のクラスタがTLS 1.1 もしくはそれ以降のみサポートするよう自動的にアップデートします。考慮すべき点は、ご使用のアプリケーションがTLS 1.1もしくはそれ以降をサポートするよう監査するすること、そしてTLS 1.1もしくはそれ以降をサポートしていないテクノロジースタックのコンポーネントをアップデートするということです。
TLS 1.0を強制的に有効化することはできますか?
Atlasは、ユーザがクラスタの生成中およびクラスタの編成中に手動にてTLS 1.0を有効化することが可能です。
Atlas クラスタに対してTLS 1.0を有効化することは、重大なリスクを伴います。TLS 1.0を有効化することは、ご使用のアプリケーションスタックがTLS 1.1以降をサポートするようにアップデートする間のみ有効にするようにしてください。
Atlasのストレージ制限に達した場合、何が起こりますか?
Atlasのどの料金プランをご利用になっているかによって、ストレージ制限に達した場合の結果が異なります。
- 共有クラスタ(M0、M2、M5 )では、最大ストレージはハードリミットであり超えることはできません。専用クラスタ(M10+)にアップグレードすることにより、ストレージの追加が可能です。共有クラスタのストレージ制限をAtlasでどうやって計算しているかの詳細は、FAQのこちらをご参照ください。
- デフォルトでは、M10以上の有料クラスタはディスク使用率のしきい値に基づいてストレージを自動的に拡張します。この設定をストレージ制限が固定されるように変更したい場合、こちら(Modify a Cluster)のページをご参照ください。
書込み操作をしようとする際に、この書込み操作用の容量を持たない共有クラスタに書込もうとすると、Atlasは次のようなエラーメッセージを表示します:
WriteResult({
"writeError": {
"code": 8000,
"errmsg": "you are over your space quota, using 513 MB of 512 MB"
}
})
共有クラスタと専用クラスタ間の違いに関する詳しい情報は、こちら(Atlas M0(Free Tier), M2, and M5 Limitations)をご参照ください。
TIP:
割り当てられたストレージが、指定された基準値に達した時に動作するアラートを設定することができます。Atlasは「dbStats」コマンドで返されるメトリクスを使用して、割り当てられたストレージを計算しています。ストレージのアラートに関する情報は、こちら(DB Storage alert conditions)をご参照ください。
Atlasは共有クラスタのストレージ制限をどうやって計算していますか?
Atlasはデータ使用量に基づいて共有クラスタのストレージ制限を計算します。これは、非共有クラスタ(圧縮を含む)で使用されるstorageSizeメトリクスとは対照的です。AtlasはクラスタのdataSizeとindexSizeを合計することによりデータ使用量を決定しています。db.stats()メソッドを発行して、これらのフィールド値を表示することができます。
Atlasクラスタのサポートはどのようにして受けられますか?
(訳注: 以下の方法は英語のみサポートされています。日本語によるサポートを希望される場合は各提供ベンダにお問い合わせください)
Atlasは、サービス自体の使用をサポートしています。データベースそのものの開発やパフォーマンスに関わるサポートは、MongoDBのサブスクリプションが必要になります。詳細はこちらをご参照ください。
Atlas UIからサポートチケットを発行できます。Atlasアカウントにログインし、ご質問、コメント、懸念をお持ちの組織あるいはプロジェクトに進みます。「navigation bar」から「Support」をクリックしてサポートチケットフォームを開いてください。必要な情報を入力すれば、Atlas テクニカルサポートエンジニアからご連絡差し上げます。
私のAtlasユーザアカウントを削除する方法を教えてください
Atlasのサポートチケットを起票してください。