MongoDB Atlasを使い始める (MongoDB as a Service)

概要

MongoDB Atlasは、MongoDB社自身が提供するMongoDBのDBaaSです。
https://www.mongodb.com/cloud/atlas

Atlasを使うと、簡単にMongoDBのクラスタを作って、各種管理を行えます。
性能や機能は限定されるものの、無料で使える種類のクラスタもあります。

この記事では、MongoDB自体ではなくAtlas固有の部分についてまとめていきます。

下準備

Atlasのユーザーアカウントを作る

Webサイトにてメールアドレスなどを入力して進んでいくだけです。
アカウントを作ると早速、クラスタ作成の画面に誘われたりしますが、とりあえずキャンセルしてもOK。
有料のクラスタを作らないうちは、クレジットカード番号の入力などは不要です。

ここで作るユーザーとは、DBaaSであるAtlasのユーザーです。
これはAtlasのWebサイトにログインするためのユーザーであり、アプリケーションなどがMongoDBにアクセスする際のユーザーとは別物です。
この記事ではそれぞれAtlasユーザー、MongoDBユーザーと呼ぶことにします。
インフラ関連の作業をしないチームメンバーなどに対しては、必ずしもAtlasユーザーのアカウントは作らなくても良いでしょう。

Google AuthenticatorやSMSによる2FAを設定できますので、忘れないうちにやっておきましょう。

Atlasの管理単位

Atlasは、Organization > Project > Clusterという階層の管理単位で構成されています。
OrganizationとProjectが、元々のMongoDBには無いAtlas固有の単位です。
Atlasユーザーのアカウントを作ると、適当なデフォルト名のOrganizationとProjectが一つずつ用意されています。

Organizationは、一言で言うと支払いの単位です。

• 名前はいつでも変更できます。
• あるAtlasユーザーは、複数のOrganizationに所属できます。
• 2FA必須などの設定ができます。

Projectは、MongoDBユーザー定義やセキュリティ設定などをまとめる単位です。
「サービスAの本番環境、サービスAのステージング環境、サービスBの・・・」といった単位で作るとよいでしょう。

• 名前はいつでも変更できます。
• あるOrganizationに所属するAtlasユーザーは、その中の複数のProjectに所属できます。
• 無料のM0というクラスタは、1つのProjectに1つしか作れません。

Atlasユーザーの権限を管理する

AtlasユーザーはOrganization単位でロールを持ち、Project単位でもロールをもちます。
ロールによって、Atlasに関する操作の権限管理をします。

また、別の切り口としてTeamという単位もあります。
これは、Atlasユーザーをグルーピングして、特定のProjectに対してまとめて所属させるためのものです。（Organizationには所属済みの）Atlasユーザーを一人ずつProjectに所属させたり、Projectロールを設定する手間を省くために使います。

このあたりの運用は、会社やチームの方針によりけりかと思います。
詳細は公式ドキュメントを眺めつつ、自分たちにあったやり方を決める必要があります。

https://docs.atlas.mongodb.com/reference/user-roles/
https://docs.atlas.mongodb.com/tutorial/manage-users/

MongoDBにアクセスする

クラスタを作る

下準備ができたら、Projectの下にMongoDBのクラスタを作ります。
名前以外は後から変更できますので、とりあえず適当に作ってもOKです。

1. どこに作るかを、AWS/GCP/Azureの中から選びます。
2. 更に、どこのリージョンに作るかを選びます。
3. Cluster Tierを選びます。ハードウェアのスペックや、利用できる追加機能が定められた種類のことで、料金に直結します。リージョンによって選べるTierが異なり、例えば東京リージョンでは無料のM0は選べません（今のところ）。
4. マネージドなバックアップを有効化するかなど、各種追加機能の設定をします。
5. クラスタの名前を決めます。アプリケーションなどからMongoDBにアクセスする際のURLなどに影響します。

MongoDBユーザー、接続元ホワイトリストを設定する

Clusters > Securityの画面から、MongoDBユーザーを作ったり、接続元ホワイトリストの設定をします。
基本的に画面に従っていけばOKです。

ユーザー作成の画面にて、Atlas adminというAtlas独自の権限が選択肢にあります。
ざっくり言うと、各種ロールを盛りまくった最強の権限です。開発用の環境などで使い道がありそうです。
公式ドキュメントの該当箇所はこちら。

クラスタに接続する

無事にクラスタが動き出すと、こんな画面になります。

これで、アプリケーションや各種MongoDBクライアントからクラスタに接続できるようになります。
CONNECTボタンを押すと、色々と案内してくれる画面が表示されるので、それに従えばOKです。

AltasのWebサイトからもアクセスできる

より手軽な手段として、COLLECTIONSボタンを押すと、Webサイトの画面（Data Explorer）からデータを直接読み書きできます。
使い勝手はさほど良くないですが、クライアントの事前準備が不要です。

Data Explorerには以下の特徴があります。

• MongoDBユーザーやホワイトリストは関係ありません。Data Explorerが使えるかどうかは、Atlasユーザーのロールによって制御されます。
• 操作の履歴が、Project毎のAlertsの画面 > All Activityのところに記録されます。

マネージドなバックアップ機能（有料）

（Atlasではなく）MongoDBが備えているmongodumpなどのコマンドを使えば、自力でバックアップをすることもできますが、Atlasにはマネージドなバックアップ機能もあります（有料）。

2種類の方式があり、どちらかを選択して使います（選び方のコツはあまり分かっておらず）。

• Continuous Backup
• Cloud Provider Snapshots（後発）

Continuous Backup

バックアップデータの地理的な保存場所はこちらに載っています。
東京リージョンにクラスタを作ると、バックアップはアイルランドに置かれるようです。

料金はこちらに載っています。
月に1GB以内のバックアップなら無料だそうですが、バックアップデータを上記の保存場所に送る際の通信料金は別途かかります。

Cloud Provider Snapshots

AWSなどが提供するスナップショットの機能を利用したものがこちらです。
今のところ、GCPではまだ利用できません。

こちらの方がリストアの所要時間が早いとのこと。
バックアップデータは、クラスタと同じリージョンに保存されます。

セキュリティ機能あれこれ

AWSならVPCピアリングできる

AWSにクラスタを作った場合、所望のVPCとピアリングができます。
MongoDBを利用するアプリケーションが存在するVPCとピアリングしておけば、通信がパブリックなネットワークを経由しなくなるので、よりセキュアになります。
VPCピアリングをしておくと、ホワイトリストにセキュリティグループIDを指定できるようにもなります。

設定はAtlasのWebサイトを起点に行います。

1. Security > Peeringの画面へ。
2. ピアリング相手となるAWSアカウントやVPC IDなどを入力していく。
3. 一通りの操作を終えてしばらくすると、入力したAWSアカウント宛てにVPCピアリングのリクエストが飛んでくる。
4. AtlasのWebサイトを離れ、AWSコンソールなどでリクエストを承認する。

テンポラリのMongoDBユーザー、ホワイトリスト項目

MongoDBユーザーを作成する画面にSave as temporary userというチェックボックスがあり、一定時間後に自動的に削除されるMongoDBユーザーを作れます。地味に便利。
ホワイトリストにも同様のチェックボックスがあります。

保存されたデータの暗号化

Atlasでは、ディスク暗号化はデフォルトで行われています。
公式ドキュメントのこちらやFAQで述べられています。

それに加えて、ファイル暗号化を行う有料オプションもあります。

まとめ

Atlasを使うことで、冗長化されたクラスタの作成、MongoDBユーザーの管理、バックアップ設定などの作業を自前で行わずに済み、便利です。

東京リージョンでは選べなかったり、追加機能が制限されるものの、M0のクラスタなら無料で使えます。用途が限られますが、無料はありがたいです。

AWSのVPCピアリングができたり、ディスク暗号化はデフォルトでついていたりと、セキュリティ面のかゆいところに手が届くようになっています。