[レポート] Amazon DocumentDB deep dive #DAT326 #reinvent

2020.01.30

こんにちは、岩城です。

セッション「Amazon DocumentDB deep dive」を聴講しましたのでレポートします。

概要

Developers have adopted the flexible schema and expressive query language of the MongoDB API because it enables them to build and evolve applications faster. However, some developers find that managing databases can be time-consuming, complicated, and challenging to scale. Amazon DocumentDB (with MongoDB compatibility) provides a fast, reliable, fully managed MongoDB-compatible database service that eliminates time-consuming setup and management tasks, allowing developers to focus on building high-performance, scalable applications. Join us to learn more about Amazon DocumentDB and how you can run MongoDB workloads at scale.

Google翻訳

開発者は、MongoDB APIの柔軟なスキーマと表現力豊かなクエリ言語を採用しました。これにより、アプリケーションをより迅速に構築および進化させることができるからです。 ただし、一部の開発者は、データベースの管理に時間がかかり、複雑であり、拡張が難しいことに気付いています。 Amazon DocumentDB(MongoDB互換)は、高速で信頼性が高く、完全に管理されたMongoDB互換のデータベースサービスを提供し、時間のかかるセットアップと管理タスクを排除し、開発者が高性能でスケーラブルなアプリケーションの構築に集中できるようにします。 Amazon DocumentDBの詳細と、MongoDBワークロードを大規模に実行する方法について学びましょう。

  • Session Type:Session
  • Topic:Databases
  • Session Level:300 - Advanced

スピーカー

  • Antra Grover
    • Software Development Engineer 2, Amazon Web Services
  • Joseph Idziorek
    • Principal Product Manager, Amazon Web Services

レポート

Agenda

  • DocumentDBの目的とは?
  • DocumentDBはどのような顧客の問題を解決するのか?
  • 顧客のユースケースと学習:Amazonによるフルフィルメント
  • 今年顧客に提供したものは何か?
  • What's Next?

専用データベース

いつDocumentDBを選択するか?

  • Relational
  • Key value
  • Document
  • In-memory
  • Graph
  • Search
  • Time series
  • Leder

なぜドキュメントデータベースなのか?

  • JSONは柔軟な形式
  • JSONは標準API出力
  • JSONでのデータモデリング
  • JSONデータをネイティブに保存、クエリ、インデックス付けする

ドキュメントデータベースを使用する必要がある場合とは?

  • JSONデータ
  • 高速反復のための柔軟なスキーマ
  • アドホッククエリ機能
  • 柔軟なインデックス付け
  • 運用及び分析のワークロード

他のデータベースがより適切なのはいつか?

  • Relational
    • 参照整合性
  • Key value
    • 既知の主キー検索の静的アクセスパターン
  • Amazon S3
    • 大きなバイナリデータ
  • In memory
    • 超レイテンシー、短命データ
  • Graph
    • 高度に接続されたソーシャルデータセット
  • Search
    • ログ分析、全文検索

ドキュメントデータベースの顧客のユースケース

  • Product catalog
  • FinTech
  • Content management

ドキュメントデータベースに関する顧客の課題

  • 自己管理が困難
    • 高可用性の実現
    • バックアップ
    • 耐久性の達成
    • 操作性、専門知識が必要
    • 保護
    • パッチ適用
  • スケーリングが困難
    • 読み取りスケーリング
    • 書き込みスケーリング
    • ストレージのスケーリング
    • シャーディング

Amazon DocumentDB (with MongoDB compatibility)

  • フルマネージド
    • AWSが管理
    • ハードウェアプロビジョニングなし
    • 自動パッチ、クイックセットアップ、安全な自動バックアップ
  • スケーラブル
    • コンピューティングとストレージの分離により、両方のレイヤーを独立して拡張可能
    • 数分で15個のリードレプリカにスケールアウト
  • MongoDB互換
    • MongoDB 3.6と互換性があり
    • 同じSDK、ツール、およびアプリケーションを使用
  • クラウド固有のデータベースアーキテクチャ

フルマネージド

  • 自動障害回復およびフェイルオーバー
    • レプリカは基本的にプライマリに昇格される
  • 自動パッチ適用
    • 最新パッチを適用
  • AWSサービスとの統合
    • CloudWatch
    • CloudTrail
    • CloudFormation
    • Secrets Manager
    • VPC
    • IAM
    • CLI
  • 連続バックアップ
    • デフォルト有効化
    • 最大35日間のPITR
  • 顧客の声
    • freshop
      • エンジニアチームはバックアップスクリプト、スケールテスト、高可用性の管理などに費やす時間を短縮し、代わりにお客様の新しい機能の開発に集中することができている。
  • Safe defaults
    • VPC only
    • 暗号化して保管
    • TLS通信を利用
    • 高可用性と耐久性を持つ
    • バックアップ可能
    • 認証
    • Compliant
    • 削除保護

スケーラブル

  • 数分でスケールアウト
    • 15のリードレプリカ、数百万のリードにスケール
  • 数分でスケールアップ
    • 16~768 GiB または RAM
  • 自動でストレージがスケール
    • ストレージは10GBから64TBに自動的にスケール
  • 負荷分散
    • レプリカ全体で読み取りをスケーリングする
  • 顧客の声
    • Iron
      • DocumentDBを使用すると、データサイズに関係なく、数分で追加またはスケーリングできる。

従来のデータベースアーキテクチャによる変更

  • 既存のアーキテクチャの課題は何か
    • モノリシックであること
    • モノリシックユニット全体を正しくスケールするのは難しい
    • ノリシックユニット全体を正しく障害回復するのは難しい
    • レプリカを追加したくても、数日〜数週間掛かる

クラウドネイティブデータベースアーキテクチャ

  • ストレージとコンピューティングを分離
    • 分離することにより各々独立してスケーリング可能
  • 3つのAZで10GBセグメントを6つに分け保持
    • 仮に1つのセグメントを失っても残っているセグメントで回復

DocumentDBのアーキテクチャ

  • プライマリインスタン障害時のレプリカインスタンスがプライマリに昇格するまでに掛かる時間は30秒未満
  • レプリカインスタンスの起動に掛かる時間は8~10分
  • ストレージは10GBから64TBまで自動スケール

なぜシャーディングしないのか

  • シャーディングする動機
    • 読み取りをスケール
    • 書き込みをスケール
    • ストレージをスケール
  • DocumentDBのアプローチ
    • 最大15個のリードレプリカを追加する
    • 非常に低い影響で垂直にスケーリング
    • ストレージは自動的に64TBまで拡張可能

ユースケース:Amazonのフルフィルメントサービス

在庫管理プラットフォーム

  • 一元管理された在庫状態の情報(Single Source of Truth)
  • リアルタイムのサーバーレスストリーム処理
  • 在庫の調整および集約されたビュー
  • 多数のユースケースと成長
  • リアルタイムクエリを含む複数のデータ販売チャネル

以前のデータストアの課題

  • 毎秒多くのトランザクション
  • 大規模なデータセット
  • ヘビーリソースとヘビーコンピュート
  • 高コスト
  • 高度なオペレーション
  • クライアント要件の異なる複雑な性質

DocumentDBを選択する理由

  • MongoDB API
  • 柔軟なスキーマ
  • 拡張性
  • ストレージとコンピューティングの分離
  • クライアント隔離
  • インスタンス分離
  • シームレスなAWS統合
  • 徹底的な監視
  • 可用性と信頼性
  • バックアップとポイントインタイムリカバリ

実装したアーキテクチャとその結果

  • More client onboarding avenues
  • 便利なピーク負荷テスト
  • アップストリームに対する検証
  • 少ないオペレーション
  • より良いリソース利用
    • 96 hostsから2 DocumentDBインスタンスへ
  • パフォーマンス向上
    • 平均レイテンシが66%向上
  • CPU使用率19%の向上
  • コスト削減
    • 45%削減

教訓:書き込みスケーリング

  • コレクション間で書き込みを分割する
  • 重複排除、高速更新
  • コールドデータをアーカイブする
  • 更新と置換を評価する
  • 条件付き更新の処理

教訓:読み込みスケーリング

  • リーダーエンドポイントではなくレプリカセットとして接続する
  • 長時間実行中のオペレーション
  • 使用後にカーソルをクローズする

教訓:インデックスの定義

  • リーダーのインスタンスタイプを選択する
  • 複合インデックスではなく単一インデックス
  • 書き込みを有効にする前にインデックスを定義する
  • フォアグラウンドインデックスではなくバックグラウンドインデックスを作成する
  • トレードオフを評価する

ベストプラクティス

  • アクセスを制限する
  • パフォーマンステストする
  • コードを分離する
  • mongodumpを使用してS3にバックアップする
  • スタート/ストップ機能を使用してお金を節約する

期待していること

  • 変更ストリーム
  • パイプラインの集約
  • クエリをプロファイリングして自動アラート

ここで、ユースケースの紹介は終わり。

Working backward

  • Working backward
    • ユーザーが求める求める者からサービスや機能を生み出すという考え方

Federated Query for Amazon Athena (Preview)

  • 複数のデータストアにまたがるデータに対してSQLクエリを実行する
  • クラウドとオンプレを対象にある、リレーショナル、非リレーショナル、オブジェクト、またはカスタムデータソースにSQLクエリを実行
  • 一般的なデータソース用のオープンソースコネクタ
  • カスタムデータソースへのコネクタを構築
  • Lambdaでコネクタを実行することも可能

マイグレーションガイド

  • DMSを無料(6ヶ月間)で使用してDocumentDBを移行可能
    • DMSを利用したオンライン移行
    • ほぼゼロのダウンタイムで移行可能

公式ドキュメント:Amazon DocumentDB への移行

おわりに

案件でDocumentDBを構築したことがあったこともあり、本セッションを聴講しました。
DocumentDBがどういう思いで作られていて、どういった機能があるのか、Amazon.comでのユースケースとそこから得られた教訓を知ることができて勉強になりました。

本エントリがどなたかのお役に立てれば幸いです。