re:Invent 2024: AWSチームがDocumentDBの進化と新機能を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Deep dive into Amazon DocumentDB and its innovations (DAT324)
この動画では、Amazon DocumentDBの主要な機能とアーキテクチャについて詳しく解説しています。ComputeとStorageを分離した構造により、高可用性と信頼性を実現する仕組みや、Global Clustersを活用したManaged FailoverとManaged Switchoverの機能について具体的に説明しています。また、2024年に導入された新機能として、IAM認証やVector Search、JSON Schema validationなどが紹介され、特にドキュメント圧縮機能では、8キロバイトのページサイズに対して最大3対1の圧縮率を実現し、I/Oを30%削減できることが示されています。DocumentDBチームがお客様のフィードバックを基に開発を進め、2025年に向けてさらなる機能拡張を予定していることも明らかにされています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon DocumentDBの概要と2024年の新機能
みなさん、こんにちは。ご参加いただきありがとうございます。re:Inventを楽しんでいただけていることを願っています。特に後ろの列の方々は、私たちの声がよく聞こえるように、今すぐヘッドフォンを装着してください。聞こえる方は親指を立てていただけますか？素晴らしいですね。みなさん聞こえていますか？これは良いことですよ。まず、正しい場所にいらっしゃることを確認させていただきます。こちらはDAT 324です。Amazon DocumentDBとそのイノベーションについて深く掘り下げていきます。
これは300レベルのコースですので、みなさんがDocumentDBについて既にご存知で、実際に使用された経験があり、できれば本番環境でワークロードを実行されているということを前提としています。DocumentDBで本番環境のワークロードを実行している方はいらっしゃいますか？素晴らしいですね。完璧です。マーケティング資料についてはみなさんご存知でしょうから、アーキテクチャとその構築理由について直接お話ししていきましょう。DocumentDBの魔法は、そのアーキテクチャと、それを構成するすべてのコンポーネントにあるのです。
DocumentDBは2019年1月からサービスを開始し、AWSで最も急成長しているデータベースサービスの1つです。2023年の前回のre:InventからDocumentDBを使用している方はいらっしゃいますか？2022年から使用している方は？2019年からは？私はAWS社員に昇進する前はAWSのお客様で、DocumentDBを最初に使い始めたお客様の1人でした。サービスリリース以来、私たちが作成したすべての機能はお客様からのフィードバックに基づいています。常にお客様と協力して、エンタープライズ向けドキュメントデータベースに求められる機能を構築してきました。
過去5年間で大きな機能とリリースを行ってきましたが、2024年は恐らく最大の年になると感じています。まずは今年行ったこと、2024年に注力してお客様と共にリリースした主要な機能について説明します。その後、それらの機能のいくつかを詳しく見ていき、DocumentDBでの災害対策の方法、これらの機能がコスト削減とパフォーマンス向上にどのように役立つか、そして最後にリリースしたプログラマビリティ機能とAPIについてお話しします。
まず自己紹介させていただきます。私はCody Allenです。Principal DocumentDB Solutions Architectとして働いています。このチームには約4年在籍しており、サービス開始時から使用しています。一緒にいるのは紹介の必要のない方ですが、ご本人から自己紹介していただきましょう。ありがとう、Cody。私はVin Yuです。DocumentDBを率いるProduct Managerの1人で、このサービスに3年半携わっています。Seattleを拠点としており、この1年間で私たちが発表したことを今日みなさんと共有できることをとても楽しみにしています。
DocumentDBのアーキテクチャと Global Clusters の進化
まずはサービスアーキテクチャについてお話しします。すでにご利用の方にはお馴染みかもしれませんが、このサービスの基盤となっているのは、上層のComputeと下層のStorageを分離した構造です。この分散ストレージボリュームがあることで、高可用性と信頼性を確保するために、ローカルストレージに依存する必要がありません。従来のデータベースエンジンでは、データの永続性を確保するために、各インスタンスのローカルストレージにトランザクションを書き込む必要がありました。DocumentDBでは、プライマリインスタンスだけがWrite-ahead Logをストレージに送信するため、余分な通信が不要になります。
永続性はストレージレイヤーで処理されるため、単一インスタンスのDocumentDBクラスターでも、ストレージレイヤーでの永続性と高可用性を確保できます。そのようなトレードオフを考える必要はありません。レプリケーション、ログ処理、バックアップなどの作業はすべてストレージレイヤーで処理されます。さらに、各レプリカインスタンスは独自のバッファキャッシュを管理しており、インスタンス間でバッファキャッシュを汚すことはありません。ドキュメントを更新すると、それはプライマリに送られ、分散レイヤーに送信されます。プライマリは次に、ドキュメントを更新するようにセカンダリにWrite-ahead Logを送信します。セカンダリはそれを確認し、キャッシュにある場合は更新し、必要ない場合は単に更新を確認します。このように、キャッシュは互いに独立して保持されています。
新機能について確実にカバーし、これらの機能すべてを説明したいので、そのComputeレイヤーについてもう少し詳しくお話ししましょう。これは特に、エンタープライズのお客様のドキュメントデータベースワークロードを実行するためにクラウド向けに特別設計されたAmazon DocumentDBを議論する際に重要です。
私たちには、Rappiのようなデジタルネイティブなお客様、Capital Oneのような大手企業のお客様、そしてゲームや金融業界のお客様など、幅広いお客様がいらっしゃいます。Amazon.comのフルフィルメントやAmazon.comもAmazon DocumentDB上で稼働しています。もしまだご覧になっていない方は、ぜひCustomersページをチェックしていただきたいと思います。今年新たに追加されたものを含め、これらのユースケースについて詳しく説明している素晴らしいお客様の事例がございます。
それでは楽しい部分に移りましょう。Vinが2024年の新しいイノベーションについてご説明します。ありがとう、Cody。素晴らしい簡潔な復習と紹介でした。お客様とそのユースケースについてお話を伺うのは、いつも大変有意義です。サービスチームとして私たちにとって非常に重要なのは、お客様と協力してフィードバックをいただけることです。実際、今年リリースした多くの機能は、お客様とのパートナーシップによって実現したものです。
このスライドは写真を撮っておくことをお勧めします。セッション中にすべての機能を詳しく説明する時間はありませんが、セッション後に気になる機能があれば、ドキュメントで詳細を確認することができます。上から順に見ていくと、ドキュメント圧縮や接続制限の引き上げなどのパフォーマンスとスケールに関する機能強化、予測可能なI/O価格を提供するI/O Optimizedによるコスト最適化への投資が分かります。また、AI/MLや、Global Clustersの管理されたスイッチオーバーやフェイルオーバーなど、高可用性に関する機能も導入しています。
セッションの残りの時間では、これらの機能の中でも特に星印が付いているものについて深く掘り下げ、その仕組みと実際の環境での実装方法についてお話ししていきます。最初に取り上げたいのはIAM認証です。多くのお客様がAWSリソース全体で認証メカニズムを一元化する傾向にあり、Amazon DocumentDBでもその要望が多く寄せられていました。 IAM認証では、クライアントはまずAWS IAM、具体的にはSecurity Token Serviceにアクセスしてトークンを取得し、そのトークンを使ってAmazon DocumentDBに対して認証を行います。
注意点として、 IDはAmazon DocumentDBクラスター内で作成され、外部データベースで管理される必要があります。IAMを使用する前にこの設定を行わないと、Amazon DocumentDBクラスターはトークンを適切に処理できません。この設定方法については、ドキュメントにステップバイステップの手順が用意されています。また、既存のRBACロールやユーザーの上にIAM認証を重ねて使用することも可能です。例えば、データベース1とデータベース2にアクセスできるユーザー1がいる場合、IAMエンティティをその上にマッピングすることで、IAMでログインする際にもそれらのデータベースにアクセスできるようになります。
管理者として、 CloudWatchを通じてIAM認証リクエストを監視することができます。これはIAMを使用する方々にとって非常に重要な機能で、IAMリクエストを完全にコントロールし、可視化することができます。次に説明したい機能はVector Searchです。 ユースケースについては、今朝のDAT320「Supercharging App Intelligence using Gen AI」セッションで詳しく説明されたので、ここでは触れません。もしそのセッションを見逃した方は、このスライドを撮影しておいてください。re:Inventのすべてのブレイクアウトセッションは録画されており、後でアクセスできるようになります。これは2025年以降も私たちが継続的に投資していく分野です。
次は、Global Clusterの改善点、特にManaged FailoverとManaged Switchoverについて見ていきましょう。 Global Clustersに馴染みがない方のために、これから頻繁に言及することになるので簡単に説明させていただきます。Global Clustersを使用すると、クラスターを複数のAWSリージョンにまたがって展開できます。これには2つの主要なメリットがあります。1つ目は災害復旧で、災害が発生した場合に備えて別のリージョンにデータのコピーを持つことができます。2つ目はデータのローカリティで、別のリージョンにデータのコピーがあることで、非常に低いレイテンシーでそのデータにクエリを実行できます。
Managed Failover と Switchover の仕組みと実装
Global Clusterの2つの主要なメリットと設定方法についてご説明します。例えば、North Virginia（US-East-1）にDocumentDBクラスターがあり、そこにアプリケーションが接続されているとします。その場合、AWS ConsoleやCLIで別のリージョンを追加します。これは非常に簡単で、ほぼワンクリックで完了します。ここで注目していただきたいのは、ストレージ層でレプリケーションサービスがデータを複製しているということです。これは大きな利点となります。なぜなら、2つのインスタンス間でデータを複製する計算処理をインスタンスで行う代わりに、ストレージ層で実行されるため、アプリケーションはデータベースを最大限に活用できるからです。また、セカンダリーインスタンスに2つ目のアプリケーションを接続することも可能です。
ここで注意したいのは、各クラスターに3つのインスタンスが表示されていますが、これは固定ではないということです。ビジネスニーズに応じて、インスタンスの数を増減したり、サイズを大きくしたり小さくしたりすることができます。例えば、1つのインスタンスだけでも、より小さいインスタンスでも構いません。実際、私たちが「ヘッドレスセカンダリー」と呼ぶ、インスタンスがゼロの状態にすることも可能です。これによりコストを節約できますが、フェイルオーバーシナリオのためにこの設定を使用する場合は注意が必要です。事前にインスタンスを起動する必要があり、それには7〜10分ほどかかります。そのため、セカンダリーリージョンにインスタンスを用意していない場合、フェイルオーバープロセス全体の所要時間に影響します。
新機能の1つであるManaged Failoverについてお話ししましょう。この機能の主な目的は、データ損失なしでセカンダリーをプライマリーに昇格させることです。このデータ損失がないという点が、Managed SwitchoverとManaged Failoverの重要な違いとなります。Managed Switchoverは管理された状況で使用することをお勧めします。まず、メンテナンス目的で使用できます。例えば、単一のリージョンでメンテナンスを実行する場合、まずデータ損失なしで切り替えを行い、メンテナンスを実施し、その後元に戻すことができます。また、複数のタイムゾーンや複数のリージョンにまたがるアプリケーションで低レイテンシーの書き込みが必要な、フォロー・ザ・サン型のアプリケーションにも使用できます。最後に、非常に一般的なシナリオとして、Managed Failoverと組み合わせて使用することができます。フェイルオーバー後のフェイルバック方法として、データ損失ゼロの手段として活用できます。
ここで注意したいのは、切り替えには数分かかる場合があるということです。その理由を説明しましょう。ここにGlobal Cluster用に設定された2つのクラスターがあります。切り替えを実行すると、まずGlobal Clusterへの書き込みが無効化されます。これは、プライマリーリージョンのクラスターからセカンダリーリージョンへのデータのシーディングを可能にするためです。すべてのデータが同期されると、昇格プロセスに進みます。ここでは、OregonにあるUS-West-2をプライマリーに昇格させ、その後新しいリージョンに対して書き込みを継続できるようになります。
2つ目の機能であるManaged Failoverの主な目的は、セカンダリーをプライマリーに昇格させることですが、最も重要な目標はクラスターのダウンタイムを最小限に抑えることです。これは、事業継続性に関するイベントや、リージョンで完全なサービス停止が発生した場合、あるいは深刻な問題が発生した場合に使用することをお勧めします。SwitchoverとFailoverの両方について注意したい点は、トポロジーが維持されるということです。クラスターがオンラインに戻ると、DocumentDBサービスは自動的にそれをGlobal Clusterに追加し、手動での事後クリーンアップが不要なようにシーディングを行います。
この仕組みがどのように機能するか見ていきましょう。North VirginiaとOregonの間でセットアップを行い、North Virginiaで何か問題が発生し - これは非常にまれなケースですが - クラスターがダウンした場合を想定します。セカンダリーリージョンをプライマリーに昇格させるためにフェイルオーバーを実行したいと思います。ここで注意すべき点は、進行中のトランザクションがある場合、シードされているデータが失われる可能性があるということです。ただし、フェイルオーバーの目的はダウンタイムを最小限に抑え、Global Clusterの全体的なアップタイムを最大化することを忘れないでください。US-East-1が復旧したとき、クラスターは正常な状態ではない可能性があり、そのデータの状態も不明なため、プライマリーからセカンダリーにデータをシードし直すことになります。プライマリークラスターからセカンダリークラスターへのデータ転送の仕組みを見ていきましょう。
シーディングプロセスが進行中でも、アプリケーションがOregonのクラスターに接続する方法を確認します。クラスターが完全にシードされると、エンドポイントが開放され、接続が確立できるようになります。
スイッチオーバーとフェイルオーバーの両方において、重要な考慮事項の1つは、これらのプロセスを簡単にする一方で、アプリケーションが接続する必要のある異なるクラスターエンドポイントが存在することです。フェイルオーバーやスイッチオーバーを実行する際、アプリケーションの接続文字列を変更する必要があるかもしれません。ただし、一般的な解決策としてRoute 53のHosted Zoneを実装する方法があります。この方法を使用すると、アプリケーションの変更を避けることができます。アプリケーションを直接変更する代わりに、グローバルドメインを指定することができます。
例えば、Oregonのプライマリークラスターで読み取りと書き込みの両方を実行するAPP 1を考えてみましょう。Route 53のエントリは、すべてのトラフィックをOregonクラスターにリダイレクトします。スイッチオーバーやフェイルオーバーを実行する場合、アプリケーションのトラフィックをセカンダリーリージョンにリダイレクトすることで、アプリケーションの変更ではなく、そのエントリを更新するだけで済みます。
デモンストレーションに進みましょう。Managed Failoverを開始する方法がいかに簡単かをお見せしたいと思います。まず、私のセットアップについて説明します。US East 1とIrelandにクラスターがあり、両方がGlobal Clusterの一部となっています。毎秒書き込みを挿入するアプリケーションがあり、これはハートビートとして機能します。さらに、Global Clusterとアプリケーションのアクティビティをモニタリングするアプリケーションがあり、現在のプライマリークラスターや書き込み操作の発生元などの詳細を表示します。
次にフェイルオーバーを開始し、アプリケーションも移行します。アプリケーションは Ireland でも同じように動作を継続し、ハートビートとして1秒ごとにデータを挿入し続けます。 1秒ごとのドキュメント挿入が途切れている箇所があれば、それが全体のダウンタイムを表しています。 AWS コンソールでは、2つのリージョンにまたがる Demo Cluster というクラスターがあります。US East 1 クラスターが現在のプライマリで、EU West 1 の Ireland クラスターがセカンダリとして機能しています。
モニタリングアプリケーションを見てみましょう。 グラフには時間経過に伴うドキュメントの挿入数が表示されており、アプリケーションのハートビートとして1秒ごとの挿入が示されています。右側の地図には、プライマリの場所を示す DocumentDB アイコンが North Virginia 上に表示されています。フェイルオーバー時には、このアイコンが Ireland に移動するはずです。画面には現在時刻と最新の挿入ドキュメントが表示されており、ページの更新により約1-2秒の遅延があります。また、書き込み操作のアプリケーションの場所とプライマリ DocumentDB サーバーの URL も表示されており、現在は US East 1 を示しています。
AWS コンソールに戻って、フェイルオーバーを開始しましょう。Demo Cluster を選択し、 Actions から Switch Over または Fail Over をクリックします。ここでスイッチオーバーかフェイルオーバーのオプションが表示されるので、フェイルオーバーを選択します。 フェイルオーバーの主な目的は Global Cluster の稼働時間を最大化することですが、進行中のトランザクションではデータ損失の可能性があることを覚えておいてください。 Ireland クラスターをプライマリクラスターとして選択し、進行中のトランザクションでのデータ損失の可能性を承認してアクションを確定します。
一番上のバナーに、「Ireland-Cluster を Global Cluster のプライマリに切り替え中」と表示され、ステータスでもフェイルオーバー中であることが確認できます。モニタリングアプリケーションに戻って、この動作を確認してみましょう。小さな途切れが見えることに注目してください。これは、その時点でデータベースへの書き込みができなかったことを示しています。約2つのバーが表示されており、これは全体のフェイルオーバーのダウンタイムがわずか2秒程度だったことを意味します。US から Ireland への大陸間のフェイルオーバーがわずか2秒のダウンタイムで実現できました。アイコンが Ireland 上に表示されているのが分かります。また、アプリケーションの場所が現在 EUS1 で、URL も EUS1 となっており、メインのプライマリが Ireland にあることを示しています。
コンソールに戻って、Global Cluster 内の2つのクラスターのステータスについてもう一つ確認したいことがあります。 ここではまだフェイルオーバー中であることが分かります。AWS コンソールページの更新ボタンをクリックしてステータスを更新してみましょう。ここで、Ireland クラスターが現在プライマリクラスターとなり、USA East One クラスターは再同期状態にあり、データが逆方向に伝播されていることが分かります。数分後には、完全な同期が完了して利用可能になります。
DocumentDBのパフォーマンス最適化：ドキュメント圧縮の威力
いくつかの重要なポイントをご紹介します - これらのポイントすべてを説明することはしませんが、ぜひ写真を撮っておいてください。これらは、皆さんの組織でGlobal Clustersの導入を検討する際の要点やメモとしてお持ち帰りいただけるものです。また、これらの情報の多くは私たちのドキュメントにも記載されています。それでは、パフォーマンスとコストについて詳しく説明するCodyに引き継ぎたいと思います。
JSONとドキュメントデータモデルの素晴らしい点は、その柔軟性にあります。従来、リレーショナルデータベースで新しいアプリケーションを作成する場合、まずテーブル、主キー、外部キーを定義することから始めます。純粋な結合テーブルを作成し、アプリケーションに触れる前に、これらの厳格なリレーショナルデータベーステーブルの関係と構造を構築します。しかし、アプリケーションの作業を始めると、変更が必要だと気づきます。ドキュメントデータベースモデルとJSONモデルは、この順序を変えることを可能にします。今では、アプリケーションから始めることで、データベース構造やCollectionとNamespaceがどのようになるかを定義します。
私たちの目標はエンドユーザーエクスペリエンスであり、アプリケーションから始めることでそれを向上させたいと考えています。アプリケーションが成長し、より多くのユーザーを獲得すると、取得したい新しいフィールドが出てきます。文字列は配列になり、それらは埋め込みドキュメントに変わっていきます。データ構造全体が進化とともに変化し、成長していきます。開発から本番環境、そして後のリリースに移行するにつれて、異なるドキュメントモデルがよりパフォーマンスを発揮することに気づくでしょう。アプリケーションに新機能を追加し、ユーザーエクスペリエンスが向上し、より良いクエリとより良い結果が得られるようになります。
フィールドを追加するにつれてドキュメントサイズは大きくなり、さらに新しいユーザーを獲得したり、アプリのダウンロード数が増えたり、他社との合併や買収を行ったりすると、ドキュメント数が大幅に増加します。先ほどDocumentDBのストレージレイヤーについて説明しましたが、このサービス全体が必要に応じてスケールできるように設計されています。ストレージレイヤーがそれを処理し、コンピュートレイヤーでは、ワークロードの成長に応じてインスタンスサイズを増やしたり、インスタンスを追加したりできます。CloudWatchとのネイティブ統合により、CloudWatchアラーム、Lambda、EventBridgeを使用して自動的にスケールアップとダウンを設定することもできます。
これは異種混合サイジングであることに注目してください - すべてのインスタンスが全く同じサイズである必要はありません。Readerを Primaryより大きくしたり、Primaryを Readerより大きくしたりすることができます。そうする理由とそうしない理由がありますが、それは別の機会に話すことにしましょう。この分散ストレージレイヤーは成長していきます。ストレージの増加に応じて10ギガバイトずつ増加し、NamespaceやCollection、データベースを削除すると、同様に縮小もします。これは素晴らしいことです - スケールする能力は素晴らしいのですが、私たちは
また、環境への配慮も重要です。スケーリング能力は素晴らしいものですが、効率的である必要があります。コストとパフォーマンスについて考慮する必要があります。
これを支援するための設計上の実装方法があります。重要な考慮事項の1つは、キーサイズを削減することです。JSONは人間が読みやすく解析しやすい形式ですが、そうである必要はありません - アプリケーションが読めれば良いのです。ドキュメント内の1文字1文字が、ディスク上のスペースとインデックス内のスペースを使用することになり、これはワーキングセットやキャッシュにも影響を与える可能性があります。例えば、先ほど見たこのドキュメントを変更してみましょう。 これらの簡単な変更を加えることで、67バイトを節約することができました。データ自体は同じままで、キー名を変更しただけです。約457バイトから約385バイトに減少し、1つのドキュメントで約15%の節約になります。
ここではバイト単位の話をしています。一見大したことないように見えますが、データレイヤーやドキュメントが成長するにつれて、これは非常に大きな意味を持つようになります。50億のドキュメントにスケールアップすると、300ギガバイト以上の節約になる可能性があります。 200億以上のドキュメントにスケールアップすると、1テラバイト以上の節約になります。これは顧客でよく見られるケースです - ドキュメントの大部分がフィールド自体ではなく、キーで占められているのです。これは不要なスペースの無駄遣いです。この方法に移行し、アプリケーション層で抽象化レイヤーを作成して変換を行う顧客もいます。
先ほどまたは昨日のDAT 417セッションに参加された方はご存知かもしれませんが、2023年にこれらのドキュメント変更以外にも支援機能を追加しました。 Andy Jassyはここでは非常に重要な人物です。彼はAmazonのCEOです。AWS CEOだった時、彼は「経験に対する圧縮アルゴリズムは存在しない」という言葉を残しました。しかし、皆さんが知らないかもしれないのは、彼の言葉は途中で切れてしまったということです - マイクが切れる前の完全な引用は「DocumentDBに対する圧縮アルゴリズムは存在しない」でした。でも、私たちはそれを変えました。今ではDocumentDBに圧縮機能があります。
DocumentDBの圧縮を理解するために、データがどのように保存されているかについて説明しましょう。私たちはドキュメントを保存するために8キロバイトのページを使用しています。理想的な状況では、24キロバイトのドキュメントがあるとすると、それらは1つのページにきれいに収まります。 アプリケーションが1つのドキュメントだけを必要とする場合、または2つのドキュメントが必要で、それらが同じページにある場合、1回のIOで済みます - 2つのドキュメントを取得するのに1回のIOだけで済むのです。しかし、ドキュメントが4キロバイトを超える場合はどうなるでしょうか？例えば5キロバイトの場合。 DocumentDBはその5キロバイトのドキュメントをそのページに保存しますが、他の用途に使用できない未使用のスペースが残ります。つまり、実質的に無駄になってしまうのです。
つまり、DocumentDBから2つのドキュメントを取得する必要がある場合、少なくとも2回のIOが必要になることが保証されており、そのためのコストがかかります。ディスクにアクセスしてデータを取得する必要がある場合、追加のIOと追加のネットワークトラフィックが発生し、IOに対して料金が発生します。そのため、パフォーマンスと課金の両面でコストがかかります。これについては、DAT 417セッションで詳しく説明しています。木曜日に再度開催されますので、まだご覧になっていない方はぜひお越しください。ページの保存方法や圧縮がどのように役立つかについてお話しします。
JSON Schema Validation：データ整合性とセキュリティの強化
大規模なワークロードではどのような影響があるか想像してみてください。例えば、7メガバイトのサイズのドキュメントがあったとします。DocumentDBのJSONファイルサイズの制限は16メガバイトですが、7メガバイトのドキュメントであっても、8キロバイトのページに完璧に収まるとすると、1つのドキュメントに875ページも必要になります。そこで圧縮が重要になってきます。2023年に、この問題に対処するために圧縮機能を導入しました。7メガバイトのドキュメントの場合、2対1の圧縮率があれば、圧縮を有効にするだけでIOを50%削減できます。
ここまでは単純明快です。圧縮は有効で、小さいものより大きいものの方が圧縮効果が高いということです。しかし、私たちはDocumentDBから可能な限り最高のパフォーマンスとコスト効率を引き出そうとしています。2023年にドキュメント圧縮をリリースした時、デフォルトの圧縮サイズは2キロバイトでした。つまり、2キロバイトを超えるドキュメントは圧縮されることになります。しかし、このアプローチには制限がありました。
ドキュメントがそのしきい値を下回る場合、たとえ1.9999キロバイトであっても圧縮されませんでした。今年の圧縮機能では、圧縮のしきい値を設定できるようになりました。128バイトから8キロバイトまでの範囲で設定可能です。つまり、1.5キロバイトのドキュメントがあり、3対1で圧縮できる場合、500バイトまで圧縮できます。これは、1ページに5つしか収まらなかったものが、今では16個収まるようになり、IOが減少することを意味します。
1000個のドキュメントがある場合を考えてみましょう。ドキュメントが大きかった時は200回のIO操作が必要でしたが、今では63回で済みます。これは、コストの削減、IOスレッドの減少、Amazon DocumentDBインスタンスのCPU使用率の低下につながり、結果としてパフォーマンスが向上します。これを実証するために、いくつかのテストを実施しました。最初のテストでは、レート制限を設けた上で、5キロバイトのドキュメントと1.5キロバイトのドキュメントについて、圧縮ありと圧縮なしの両方のワークロードを実行しました。1秒あたりの挿入数を固定し、一定期間実行して、すべてのワークロードで同じ数のドキュメントが挿入されるようにしました。
結果は、大きなドキュメントでI/Oが30%減少し、1.5キロバイトの小さなドキュメントでは11%のI/O減少を示しました。また、CPU使用率の低下によるパフォーマンスの向上も確認されました。圧縮を有効にするとCPUに悪影響を与えるという誤解がよくありますが、これは計算レイヤーがドキュメントの圧縮と解凍を行う必要があるためです。しかし、これらのレート制限のあるワークロードでは、書き込みIOPSの減少によってI/O操作に必要なCPUスレッドが少なくなるため、実際にはCPUは減少します。 ただし、サイバーマンデーのセールやNikeのスニーカーの抜き打ち発売のような状況を想定した2番目のテストでは、トレードオフが発生することが分かりました。
DocumentDBインスタンスをネットワーク容量の限界まで押し上げると、I/Oが増加し、1秒あたりのトランザクションと挿入が増えます。しかし、これによりI/Oスレッドが増えるため、CPU使用率が上昇します。これは大多数のワークロードではめったに遭遇しない異常な状況ですが、通常の日常的なワークロードでは圧縮が有益である一方で、スパイク時にはCPU使用率が上昇する可能性があることを理解しておくことが重要です。 ここまでの議論をまとめると、JSONは宣言するだけでアプリケーションを進化させスキーマを変更できるため優れており、圧縮は潜在的な成長を最適化し、より少ないスペースで済むため優れています。
しかし、時にはこれ以上のものが必要になります。アプリケーションが好きなときにスキーマ設計を自由に変更できるというわけにはいきません。 特に金融業界では、制御が必要です。新しいデータタイプを許可しながらも、整合性とセキュリティを維持しながらデータを保護するためのガードレールが必要です。 口座番号は必ず10桁でなければならず、取引額はゼロや負の値であってはならず、規制要件によって特定のフィールドがドキュメントに必須となります。また、データの問題をコレクションに入る前に検出することで、エラーを防ぐ必要もあります。
これは、DocumentDBにJSONスキーマバリデーションを導入したときに、お客様から寄せられた声です。このバリデーションにより、 DocumentDBにトランザクションが入るたびに従わなければならないルールを設定できます。ほとんどのワークロードは、データベース層だけでなくアプリケーション層でもバリデーションを実行します。例えば、API層では、URIパラメータ、クエリ文字列、ヘッダーが存在し適切にフォーマットされていること、ペイロードがJSONリクエストメソッドと一致することを確認します。ベストプラクティスは、 アプリケーション層とデータベース層の両方でこれを行うことです。API層では早期に問題を検出でき、データベース層では、データの出所に関係なく、また直接のデータベースアクセスからも保護することで、データの整合性を確保できます。
これにより、カスタマイズされた即時のフィードバックとエラー処理をお客様に提供できます。 誰かがMongoシェルコマンドを実行している場合でも、同時にアクセスする可能性のある複数のアプリケーション間での一貫性を確保できます。
これは素晴らしい機能ですが、お客様からは開発プロセスにおいて速度低下を引き起こす可能性があるとの声をいただきました。新機能の開発時に、これらのバリデーションルールによって制約を受けてしまうのです。より多くのフィールドを追加したい場合に、本番環境と同じ開発環境を持つことができないという課題がありました。この課題に対応するため、JSON Schema validationに対してbypassDocumentValidationパラメータを導入しました。 これにより、バリデーションルールが定義されているコレクションにドキュメントを挿入または更新する際に、それらのバリデーションルールをスキップすることができます。例えば、大量のレガシーデータを移行する場合、このパラメータを使用して一時的にバリデーションをバイパスすることができます。お客様と新機能の開発を進める際にスキーマを変更したい場合、この機能により開発プロセスをより迅速に進めることができます。また、緊急の修正が必要な場合にも、このパラメータを使ってバイパスすることができます。
2025年に向けたDocumentDBの展望と開発者向けリソース
2024年は私たちにとって非常に忙しい年でした。ここでご紹介したのは、リリースした機能の一部に過ぎません。残念ながらこのリストに含めることができなかったロードマップ上の機能もいくつかあります。それらは間もなくリリースされる予定で、Finnに叱られるかもしれませんが、Amazon DocumentDBには近々大きな機能が追加される予定です。今日ご紹介したすべての機能は、お客様あってこそ実現できたものです。Solutions Architectとして、私はお客様と直接お話しし、どのように使用されているか、何が必要か、どの機能が重要かを理解します。そして、エンジニアと協力してこれらの機能をリリースし、追加の機能をご提供しています。
2025年に向けて、私たちはこのイノベーションのペースを維持していきます。2024年以上に多くのリリースが2025年には予定されています。しかし、その過程でも引き続きお客様と協力して開発を進めていきたいと考えています。JSON Schema validationは、お客様との緊密なパートナーシップの良い例です。お客様と密接に協力することで、リリースを効率化し、まさにお客様が必要とする形で構築することができました。この協力関係により、開発期間を数ヶ月短縮できたと思います。
私たちは、お客様のユースケース、必要な機能、そしてイノベーションを促進し、コストを削減し、Amazon DocumentDBでのワークロードの全体的なパフォーマンスを向上させるための機能について、ぜひお客様からのご意見をお待ちしています。 ぜひチェックしていただきたいものがいくつかあります - 写真を撮るかスキャンしてください - DocumentDB deployment scannerがあります。これは、クラスターを確認し、簡単に実装できる最適化がないかを確認する方法です。また、compression reviewerもあり、圧縮が有効になっていないDocumentDBクラスターで圧縮がどの程度効果があるかを確認できます。これらは単純なPythonスクリプトで、約100行の非常にシンプルで実行しやすいものです。
これらをチェックして、フィードバックをお寄せください。スクリプトに追加してほしい機能があれば、ぜひお知らせください。Amazon DocumentDBに特化した新しいデータモデリングのebookもリリースしました。データモデリングの方法や最適化のための高度なヒントが記載されています。また、トレーニング認定チームと協力して、DocumentDBの包括的なコースガイドラインを作成しました。入門から、コストとパフォーマンスのチューニング、データモデリングまで学べ、実践的に取り組むことができます。ご参加いただき、ありがとうございました。引き続きre:Inventをお楽しみください。木曜日のDAT417 ではページとDocumentDBについての詳細な深掘りセッションがありますので、ぜひセッションの評価をお願いいたします。皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion