AWS入門ブログリレー2024〜 Amazon DocumentDB 編〜

Amazon DocumentDB について 2024 年時点の情報をまとめてみました。AWS サービス入門記事として是非ご活用下さい。

AWS再入門2024

#Amazon DocumentDB

#MongoDB

#AWS

emi

2024.03.31

コーヒーが好きな emi です。

当エントリは弊社 AWS 事業本部による『AWS 入門ブログリレー 2024』の 7 日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今回のテーマは『Amazon DocumentDB』です。

Amazon DocumentDB 概要

Amazon DocumentDB は、MongoDB との互換性を持つマネージド型のドキュメント指向データベースです。

Mongo DB とは？

MongoDB は、オープンソースのドキュメント指向データベースです。多くの開発者に利用されており、DocumentDB はこの MongoDB との互換性を持っています。

ドキュメント指向とは？

本ブログの主題です。DocumentDB は MongoDB との互換性を持つドキュメント指向データベースであることをご理解いただければ、あとはほぼ Amazon Aurora と同じアーキテクチャです。お時間の無い方はこの「ドキュメント指向とは？」の部分だけでもおさえていただければ幸いです。ではいってみましょう。

ドキュメント指向とは、NoSQL データベースの一種です。

クライアントとアプリケーション間のデータのやり取りは JSON 形式で行われることが多く、この JSON 形式のデータをリレーショナルデータベース（RDB）に適切に格納するためには ORM（Object-Relational Mapping、オーアールマッパー）が必要です。
ORM は、オブジェクト指向プログラミングとリレーショナルデータベースの間のデータ変換を行うためのプログラミング手法です。簡単に言うと、JSON データをリレーショナルデータベースで使えるように変換するツールです。

ORM を使うと JSON データをリレーショナルデータベースのスキーマ（構造）に合わせて変換し、テーブル格納することが可能になりますが、対応コストがかかります。

一方、MongoDB に代表されるドキュメント指向データベースでは、BSON（Binary JSON）と呼ばれる JSON 形式に似た（JSON-like）データ構造を持っています。そのため、クライアントから受け取ったデータとの整合性を取る必要が最小限であり、柔軟なデータ格納が可能です。

リレーショナルデータベースとドキュメント指向データベースのデータモデルの違い

リレーショナルデータベース（RDB）と DocumentDB の主な違いはデータモデルとデータの構造化方法にあります。RDB では、データはテーブルに構造化され、各テーブルは事前に定義されたスキーマ（カラムの名前とデータ型）に従います。一方 DocumentDB では、データは JSON 形式のドキュメントとして格納され、各ドキュメントは独自の構造を持つことができます。

以下に、RDB と DocumentDB の用語の違いを記載します。

RDB	DocumentDB
テーブル	コレクション
レコード（行）	ドキュメント
カラム（列）	フィールド
プライマリキー	オブジェクト ID
ネストされたテーブルまたはオブジェクト（Nested table or object）	埋め込まれたドキュメント（Embedded document）

RDB の例として、MySQL だと以下のように表形式のデータが格納されます。各行のデータはすべて name、age、hobbies などの共通の項目を持っています。

-- usersテーブルからすべてのレコードを取得
MySQL [sampledb]> SELECT * FROM users;
+----+-------+------+-------------------+---------------------+
| id | name  | age  | occupation        | hobbies             |
+----+-------+------+-------------------+---------------------+
|  1 | Alice |   25 | Software Engineer | reading, traveling  |
|  2 | Bob   |   30 | Sales Manager     | music, sports       |
|  3 | Carol |   27 | Data Analyst      | photography, hiking |
+----+-------+------+-------------------+---------------------+
3 rows in set (0.004 sec)

MySQL [sampledb]>

ドキュメント指向データベースである DocumentDB では、以下のように JSON-like なデータが格納されます。2 つのドキュメント（ドキュメント指向データベースではレコードのことをドキュメントと呼びます）が格納されていますが、その構造は同じではありません。ドキュメントごとに項目が違っていてもデータを格納できることが分かります。

// usersコレクションからすべてのドキュメントを取得
rs0 [direct: primary] test> db.users.find()
[
  {
    _id: ObjectId('6605ed165689bca78a1852b9'),
    fullName: 'Alice Smith',
    age: 25,
    nickname: 'Ally',
    city: 'New York',
    hobbies: [ 'reading', 'traveling' ]
  },
  {
    _id: ObjectId('6605ed285689bca78a1852ba'),
    name: 'Bob',
    age: 30,
    occupation: 'Sales Manager',
    interests: [ 'music', 'sports' ]
  }
]
rs0 [direct: primary] test>

ドキュメント指向データベースはドキュメントごとに構造が違っていても格納できるので、RDB と比べてスキーマの変更が容易です。例えば上記のデータに、身長体重、電話番号、出身地などの項目をどんどん追加することができます。

このように、ドキュメント指向データベースはアプリケーションの要件に応じてデータモデルを容易に進化させることができます。ドキュメント指向は複雑なデータ構造や階層的なデータに適しています。

ユースケース

ドキュメント指向データベースは要件に応じて柔軟に、高速にデータモデルを更新できます。この特徴を生かし、以下のようなユースケースで利用できます。

ユーザープロファイル
- 柔軟なスキーマと階層構造のサポートにより、ユーザーごとに異なる属性を持つデータを自然に表現でき、スケーラビリティにより大量のユーザーデータを効率的に管理できます。
リアルタイムアプリケーション
- ゲームやソーシャルメディアなど、低レイテンシーが求められるアプリケーションに適しています。
コンテンツ管理システム
- ブログ記事やユーザーコメントなど、柔軟なスキーマが必要なコンテンツを管理するのに適しています。
カタログとインベントリ管理
- 製品情報や在庫管理など、階層的なデータ構造を持つアプリケーションに適しています。

以下のようなケースでは RDS の利用を検討するのが良いです。

トランザクションを使って信頼性の高いクエリを実行したい
事前に定義したスキーマに従って利用したい
MySQL、PostgreSQL などのエコシステムを使いたい

DocumentDB のアーキテクチャ

DocumentDB には「インスタンスベースのクラスター」と「エラスティッククラスター」の 2 種類のクラスターがあります。エラスティッククラスターは少々特殊な用途で使うものになりますので本項目の最後で少し取り上げます。

インスタンスベースのクラスターのアーキテクチャ

DocumentDB インスタンスベースのクラスターのアーキテクチャは Amazon Aurora によく似ています。

DocumentDB クラスターは VPC のサブネット内に作成します。クラスターはプライマリインスタンス・レプリカインスタンスと、1 つのクラスターストレージボリュームで構成されます。プライマリインスタンスは 1 台、読み込みのみサポートするレプリカは最大 15 台まで配置可能です。
すべての書き込みはプライマリインスタンスを介して行われ、プライマリインスタンスとレプリカインスタンスは読み込みをサポートします。
クラスターのデータはクラスターボリュームに保存され、3 つの異なるアベイラビリティーゾーン（以降、AZ）にそれぞれ 2 つずつ、計 6 つのコピーが保存されます。

このように、クラスターの中でインスタンスを含むコンピュートレイヤーと、ボリュームを含むストレージレイヤーに分かれているのが特徴です。
クエリ処理や API の受け付けが間に合わない場合はコンピュートレイヤーのみスケーリングし、データを格納する空き容量が足りなければストレージレイヤーのみスケーリングをおこなうことができます。よりアプリケーションに合わせて柔軟にスケーリングができるというわけです。

Elastic クラスターの特徴

Elastic クラスターはペタバイト規模のストレージ容量を使用して、1 秒あたり数百万の読み書きにデータベースをスケールできます。インスタンスを選択、管理、アップグレードする必要がありません。

Elastic クラスターは MongoDB 互換のシャーディング API をサポートします。

大規模な MongoDB の構成ではシャーディングが行われることがあります。シャーディングとは大規模なデータセットを複数のマシンに分散させることで、パフォーマンスとスケーラビリティを向上させる手法です。シャーディングを使用すると、単一のサーバーの容量を超えるデータを扱うことができます。

特徴

ボリュームの自動スケール

DocumentDB のクラスターボリュームは 10 GB ごとに最大 128 TiB まで自動スケールします。ボリュームサイズを決める必要はありません。

インスタンスのスケール

インスタンスタイプを変更することによりスケールアップが可能です。
また、レプリカは Auto Scaling が可能です。

高可用性

プライマリインスタンスで障害が発生するとフェイルオーバーがトリガーされ、既存のレプリカの 1 つがプライマリに昇格します。

また、データを 3 AZ に 2 つずつ、合計 6 つコピーしますので、AZ 障害が発生してもデータは守られます。

バックアップとリストア

1 ～ 35 日間の自動バックアップをサポートしています。内部的にはストリーミングバックアップという継続的なバックアッププロセスが実行されており、Point in time recovery（PITR）で任意の時間に復元することが可能です。

Aurora ではトランザクションログを 5 分おきに取得している関係で復旧させたい時間は 5分おきにしか指定できませんが、DocumentDB は復旧させたい時点を秒単位で指定することができます。

セキュリティ

DocumentDB 管理 API の認証・認可は IAM ユーザー、IAM ロール、IAM ポリシーによって提供されます。
DocumentDB データベースの認証は、Salted Challenge Response Authentication Mechanism (SCRAM) を備えた標準の MongoDB ツールおよびドライバーによって行われます。SCRAM は MongoDB 向けのデフォルトの認証メカニズムで、この仕組みが DocumnetDB でも利用できます。

ログ

監査ログとスロークエリログを CloudWatch Logs に出力することができます。

MongoDB との互換性

DocumentDB は MongoDB 4.0 や MongoDB 5.0 などの MongoDB 互換性をサポートしています。現在 MongoDB データベースを使用しているアプリケーション、ドライバ、ツールの大部分を DocumentDB でもほぼ変更することなく使用できます。MongoDB 同様 mongo shell（モンゴシェル）での DB 操作も可能です。

一部機能的な違いもあります。MongoDB から DocumentDB に移行する前にこれらの違いについてよく確認してください。

料金

DocumentDB は以下 4 つの要素で料金が設定されています。

オンデマンドインスタンス
データベース I/O
データベースストレージ
バックアップストレージ

1. オンデマンドインスタンス

クラスターのコンピューティングインスタンスのスペックと使用時間によって課金されます。最低 10 分の 1 秒あたりの料金です。

2023/3/31 時点の東京リージョンの料金
メモリ最適化インスタンスの料金例

メモリ最適化インスタンス	Standard (時間あたりの料金)	I/O 最適化 (時間あたりの料金)
db.r6g.large	0.317USD	0.349USD
db.r6g.xlarge	0.635USD	0.698USD
db.r6g.2xlarge	1.269USD	1.396USD
db.r6g.4xlarge	2.538USD	2.792USD

汎用インスタンスの料金例

汎用インスタンス	Standard (時間あたりの料金)	I/O 最適化 (時間あたりの料金)
db.t4g.medium	0.115USD	0.127USD
db.t3.medium	0.119USD	0.131USD

2. データベース I/O

クラスターのストレージボリュームに対してデータの読み書きを行うときに使用される I/O の量によって課金されます。100 万 I/O あたりの料金です。

2023/3/31 時点の東京リージョンの料金

	Standard	I/O 最適化
I/O 料金	100 万リクエストあたり 0.24USD	利用料に含まれる

3. データベースストレージ

クラスターのストレージボリュームに保存されているデータの量によって課金されます。GB/月あたりの料金です。

2023/3/31 時点の東京リージョンの料金

	Standard	I/O 最適化
ストレージ料金	1 か月あたり 0.12USD/GB	1 か月あたり 0.36USD/GB

4. バックアップストレージ

1 つのリージョンにおいて DocumentDB クラスターのストレージ合計の 100% を超えるまで、バックアップストレージに対する追加料金は発生しません。また、バックアップ保持期間が 1 日で、保持期間を超えた手動スナップショットがない場合も、バックアップストレージに対する追加料金はかかりません。