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

はじめに 本ブログリレーについて

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の4日目のエントリです。昨日はKitano Yuichiによる「Amazon SES」でございました。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう!という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

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

目次

Amazon DocumentDBとは

高速でスケーラブルかつ高可用性な完全マネージド型のMongoDB互換ドキュメントデータベースサービスです。
と、これだけ聞いても¯\_(ツ)_/¯って感じですよね。各要素について、もう少し詳細に説明します。

ドキュメント(指向)データベース

RDBでいうところの各レコード(ドキュメントデータベースではドキュメントと言います)にJSONライクなデータを格納するデータベースのことを指します。
RDBでいうテーブル(ドキュメントデータベースではコレクションと言います)の各レコード(ドキュメント)のJSONの構造は同じである必要はありません。またレコード(ドキュメント)を更新する際も、元と同じ構造を維持する必要もなく、新しい要素(フィールドと言います)を追加したり、逆に削除したりしても構いません。RDBのように厳密にスキーマを管理する必要がないので、より柔軟に利用することができます。

(補足:ややこしいのでRDBとの用語対応表を貼っておきます)
RDB ドキュメントデータベース(MongoDB)
データベース データベース
テーブル コレクション
行(レコード) ドキュメント
列(カラム) フィールド
PK(プライマリキー) ObjectId

DocumentDB開発者ガイドより引用(一部追加、抜粋)

例:ふたつのドキュメントが格納されていますが、その構造は同じではありません

{
    "_id" : ObjectId("5d18760d11a12c05cac220e1"),
    "name" : "kazue",
    "age" : 32,
    "like" : [
        "music",
        "soccer"
    ]
}
{
    "_id" : ObjectId("5d18765911a12c05cac220e2"),
    "name" : "yamada",
    "age" : 25,
    "job" : "sales",
    "birthplace" : "Osaka"
}

例:各ドキュメントは要素(フィールド)を自由に追加、削除できます

{
    "_id" : ObjectId("5d18760d11a12c05cac220e1"),
    "name" : "kazue",
    "age" : 32,
    "like" : [
        "music",
        "soccer"
    ]
}

"age" 削除、 "blood-type" 追加↓

{
    "_id" : ObjectId("5d18760d11a12c05cac220e1"),
    "name" : "kazue",
    "like" : [
        "music",
        "soccer"
    ],
    "blood-type" : "b"
}

MongoDB互換

MongoDBはドキュメント指向データベースの中で最もメジャーな製品です。
DocumentDBはMongoDB(MongoDB Community Edition3.6)との互換性があるので、各言語に存在するMongoDBを扱うためのSDKやライブラリがそのまま使用できます。
また、AWS DMS(AWS Database Migration Service)を使ってEC2上で稼働しているMongoDBを容易にDocumentDBに移行することもできます。

高速&スケーラブル

データ読み込みに関しては、リードレプリカを最大15台まで増やしていくことができ、最大秒間100万リクエストが実行可能になります。
一方データ書き込みに関しては、プライマリインスタンスのメモリ容量を数分以内にスケールアップすることができます。最大メモリ容量は768GBです。
また、今回は説明を割愛しますが、ストレージレイヤがAuroraと同様のアーキテクチャになっており、非常に高速に動作します。かつ、ストレージは自動拡張します。そのためストレージのサイジングを行う必要がありません。ストレージは最大64TBまで拡張可能です。

高可用性

  • 99.99% の可用性を備えるように設計されています。
  • インスタンスに障害が発生した場合、自動的にインスタンスと関連プロセスを再起動します。インスタンスの再起動時間は通常 30 秒以下です。
  • さらに、インスタンス再起動後もキャッシュをそのまま保持します。
  • マスターインスタンスに障害が発生した場合、リードレプリカを作成している場合はいずれかのリードレプリカに自動的にフェイルオーバーします。
  • ストレージボリュームは3AZに、かつ各AZで2箇所ずつ、つまり2×3=6箇所にレプリケートされます。データベースの書き込み性能に影響を与えることなく最大 2 つ、読み込み性能に影響を与えることなく最大 3 つのデータコピーの損失を透過的に処理します。
  • スナップショットは自動でS3に保存されます。S3の耐久性は99.999999999%です。

DocumentDBのメリット

JSONのまま、かつスキーマレスにデータ格納できる、というのが最大のメリットかと思います。

ひとつ目、JSONのままデータ格納できるという点について。フロントエンド⇆バックエンドの連携時に、データをJSON型にしてやりとりするというのは昨今よくある構成です。ここでバックエンドから操作するデータベースとして、RDBを採用することを想定してみましょう。
フロント⇆バックエンド間のやりとりはJSONを介して行われます。一方、バックエンド⇆DBのやりとりはSQLを介してですね。間にOR Mapperも利用するかもしれません。いずれにせよデータ格納処理では、JSONデータをアプリケーション内でリレーショナルなテーブルの形に変換してからデータ格納する必要があります。特に、ネストした構造のJSONを変換するのは面倒な作業になるでしょう。
逆のデータ参照も然りで、リレーショナルなテーブルのデータをJSONに変換してクライアントに渡す必要があります。
DocumentDBをはじめとするドキュメント指向データベースを使う場合、DBに格納するデータ型はJSON(ライク)なままで良いので、データ型の変換処理をアプリケーション層でゴリゴリ書く必要性は減るでしょう。これがJSONのままデータ格納できるというメリットです。

続いてふたつ目のメリット、スキーマレスについてです。
テーブル(コレクション)単位でスキーマを定義する必要はなく、行(ドキュメント)ごとに別々のスキーマを持てるので、扱うデータの形を決めきれない時にDocumentDBは便利です。
そういう意味で、要件が変化していくアジャイル的な開発現場ではより有用なデータベースと言えるでしょう。

DocumentDBのユースケース

Webアプリケーションのバックエンドとして

前述の通り、JSONでデータ連携することが多い昨今のWebアプリケーションにおいて、JSONのままデータ格納できるというのは大きなアドバンテージです。その中でもスキーマレスな以下のようなデータを扱う際に特に役立つでしょう。

  • ユーザーのプロフィールデータ(ユーザーごとに保存したい情報が異なる)
  • ECサイトの商品情報(異なる種類の商品の場合は記載項目を変えたい)
  • CMS(どんな項目が必要かは個々のコンテンツ次第)

すでにEC2上でMongoDBを利用している

こういった場合はぜひDocumentDBを利用されることをご検討された方が良いでしょう。 DocumentDBはマネージドサービスですので、煩わしい管理業務をAWSに任せてアプリケーション最適化に集中できます。

他DBとの使い分け

DocumentDB(MongoDB)とRDS・DynamoDB間との位置付けは、以下の弊社菊池のスライドがわかりやすいと思います。

RDSとの使い分け

トランザクション処理が求められるケースではRDSを使うのが良いでしょう。DocumentDBは現在トランザクション処理をサポートしておりません。(MongoDBでは4.0でトランザクションがサポートされましたがあくまで補助的なもの。そしてDocumentDBはMongoDB3.6互換です)

また、かっちりスキーマを決められるデータを扱う場合もRDSを使う方がシンプルで良いでしょう。DocumentDBの良さを活かすことができません。またDocumentDBの場合各レコード(コレクション)ごとにスキーマ情報も持つ必要があるため、RDSよりデータ量が大きくなりがちです。

DynamoDBとの使い分け

スケーリング性能でいえばDynamoDBの方が高いです。DocumentDBの優位性は柔軟にクエリが書ける点にあります。ですのでアクセスパターンが複数ある、もしくは読み切れない場合にはDocumentDBの方が便利です。またネストしたJSONのフィールドにもインデックスを貼ることができる、というのもDocumentDBの強みです。

やってみよう

開発者ガイドに開始方法についてのページがありますので、こちらを参考に一度クラスターの作成からmongoシェルを介してのデータ操作を試してみてください。

Amazon DocumentDB 開発者ガイド 開始方法

こちらのガイドで紹介されているデータ操作は、挿入、検索、更新、削除のみですが、以下のページにそれ以外の操作方法についてもまとめられています。余力があればこれらの操作もお試しください。

Amazon DocumentDB 開発者ガイド ドキュメントでの作業

DocumentDBは決してお安いサービスではないので、お試しになられたあとはクラスターを削除することをお勧めいたします。継続的にお試しされるのであれば、以下エントリを参考に一時停止&再開をご検討ください。

[アップデート] DocumentDB がクラスターの停止と起動をサポートするようになりました!

まとめ

DocumentDBについてご紹介しました。私は先日AWS Summit Tokyo、AWS Summit Osakaに参加した際、AWSのデータベース系サービスをまとめて紹介するセッションを聴講しました。その中でスピーカーのAWSの方が引用されていたのは「万能なデータベースは存在しない」という amazon.com CTOの Werner Vogelsさんの言葉です。それぞれのサービスの特性を理解して、適材適所で利用することが肝要です。本エントリにてDocumentDBの特性を理解いただき、データベース選定の際にDocumentDBを選択肢の一つに加えていただければ幸いです。

参考情報

再入門シリーズ 明日(7/5)は

もきゅりんの「AWS Step Functions」編です。お楽しみに!!