Pedia

Amazon DynamoDB

あまぞんだいなもでぃーびー

Amazon DynamoDB(ダイナモディービー)は、Amazon Web Services(AWS)が提供するフルマネージド型のNoSQLデータベースサービスである。極めて高いスケーラビリティと一貫した低遅延を実現し、データ量やアクセス頻度の増大に関わらずミリ秒単位の応答速度を維持するよう設計されている。Key-Valueおよびドキュメントデータモデルをサポートし、エンタープライズ規模のウェブアプリケーションやゲーム、IoTバックエンドなど、予測不可能なトラフィックを扱う現代的なワークロードに最適化されたデータベースソリューションである。

最終更新:

由来・歴史的背景

Amazon DynamoDBのルーツは、Amazon.comが大規模なECサイトを運営する過程で直面した課題、すなわち、極度のアクセス集中時にもシステムの可用性とパフォーマンスを維持するという要求に応えるために開発された内部システムにある。2007年にAmazonが論文として発表した分散Key-Valueストア(KVS)である「Dynamo」がその基礎となっている。このDynamoは、可用性を最大化するために、結果整合性(Eventually Consistent)を許容する設計思想を採用し、大規模な分散環境におけるデータ永続化の新たなアプローチを提示した。

DynamoDBは、このDynamoの設計哲学をベースとし、クラウドサービスとして一般向けに提供される形で2012年にローンチされた。これにより、世界中の開発者は、Amazon.comと同等の高スケーラブルかつ高可用なデータベース基盤を、サーバー管理の負荷を負うことなく利用できるようになった。サービス名に「Dynamo」を冠するのは、その堅牢なルーツを示している。

アーキテクチャとデータモデル

DynamoDBは、リレーショナルデータベース(RDB)とは異なり、柔軟なデータ構造を持つNoSQL(Not only SQL)データベースに分類される。主にKey-Valueストアおよびドキュメントストアのデータモデルを採用している。

Key-Valueデータモデル

DynamoDBの基本はKey-Valueストアであり、データを一意に識別するための主キー(Primary Key)に基づいて格納および取得を行う。主キーは、パーティションキー(Partition Key)とソートキー(Sort Key)の複合で構成されることが多い。

  1. パーティションキー: データがどの物理的なストレージノード(パーティション)に格納されるかを決定するために使用される。このキーがデータの分散(シャーディング)を担い、スケーラビリティの基盤となる。
  2. ソートキー: 同一パーティションキーを持つデータ項目(アイテム)内での順序を決定するために使用され、範囲検索や効率的なデータ取得を可能にする。

スケーラビリティの実現

DynamoDBがデータ量の増加やトラフィックの急増に関わらず性能を維持できるのは、データが自動的に多数のパーティションに分散されるためである。AWSは、ユーザーが指定したスループット(読み書きキャパシティ)やアクセス負荷に応じて、バックグラウンドで自動的にリシャーディング(パーティションの再配分)を行う。ユーザーはサーバーの追加やクラスター構成の調整といった管理作業を行う必要がない。

また、アクセス負荷の予測が難しいワークロードに対しては、オンデマンドキャパシティモードを選択することで、アプリケーションのトラフィック増加に瞬時にスケールできる柔軟な環境が提供される。

セカンダリインデックス

DynamoDBは主キーによるアクセスが最も効率的だが、それ以外の属性に基づいてデータを検索したい場合に「セカンダリインデックス」を使用する。

  • LSI (Local Secondary Index): パーティションキーは主キーと同じだが、ソートキーが異なるインデックス。
  • GSI (Global Secondary Index): 主キーとは独立したパーティションキーとソートキーを持つインデックス。GSIを適切に設計することで、特定のアクセスパターンに最適化された柔軟なクエリが可能となるが、整合性やコスト管理において慎重な考慮が必要とされる。

具体的な使用例・適用シーン

DynamoDBは、その高いスループットと低レイテンシの特性から、特にトラフィックが変動しやすく、リアルタイム性が求められるシステムで活用される。

大規模なゲームアプリケーション

モバイルゲームやオンラインゲームでは、数百万人の同時ユーザーのステータス、装備、スコア、セッション情報などを常に読み書きする必要がある。DynamoDBは、この高頻度で予測不能なI/O負荷に耐え、プレイヤー体験を損なわない一貫した高速応答を提供できるため、ゲームバックエンドの定番のデータストアとなっている。特にランキング機能の実装において、ソートキーを活用した効率的な取得が可能である。

IoTデータストリーム処理

数多くのセンサーやデバイスから秒間数千、数万といったペースで発生する時系列データ(ログ、メトリクス)の収集と格納において非常に有効である。IoTプラットフォームはデータインジェクション(データの取り込み)がボトルネックになりやすいが、DynamoDBの高い書き込み耐性はこれを解消する。データは一旦DynamoDBに格納された後、分析のために他のデータウェアハウスに連携されることが多い。

サーバーレスアプリケーションのバックエンド

AWS LambdaやAmazon API Gatewayといったサーバーレスなサービスと連携する際、DynamoDBは理想的なデータストアとなる。両者ともサーバー管理が不要であり、リクエストに応じて自動的にスケールするため、システム全体を運用管理の負担なく構築できる。ウェブサイトのユーザー認証情報やToDoリスト、簡単なデータカタログなど、多様なサーバーレスワークロードで利用されている。

高速キャッシュとセッション管理

従来のRDBから負荷を分散させる目的や、ECサイトにおける一時的なショッピングカートの状態、セッション情報を保持するために使われる。DynamoDBはインメモリキャッシュほどではないが、ディスクベースのストレージとしては極めて高速であり、可用性が高いため、キャッシュ層としての役割も担う。

メリットとトレードオフ

メリット(強み)

1. 運用の完全自動化(フルマネージド) DynamoDBは、OSのパッチ適用、ハードウェアプロビジョニング、バックアップ、障害対応、レプリケーション管理など、データベース管理者が通常行うすべての作業をAWSが代行する。これにより、組織はデータベースインフラの維持管理ではなく、アプリケーション開発にリソースを集中投下できる。

2. 恒常的な低レイテンシ データ量やアクセス負荷がどれだけ増大しても、読み書きのレイテンシは一貫してミリ秒単位で推移する。これは、大規模なRDBシステムでスケーリングに伴う性能劣化や複雑なシャーディング設計に悩まされることがなくなるという大きな利点である。

3. 高い耐久性と可用性 データは自動的に複数のアベイラビリティゾーン(AZ)に複製されるため、単一AZ障害によるデータ損失のリスクがない。耐久性は99.999999999%(イレブンナイン)と非常に高く、ミッションクリティカルなシステムでの利用に耐えうる。

4. トランザクションサポート 2019年以降、DynamoDBはトランザクション機能(ACID特性の原子性、一貫性、分離性、永続性)をサポートするようになり、複数のアイテムに対する操作のオール・オア・ナッシング(全成功か全失敗)を保証するようになった。これにより、厳密なデータ整合性が求められる金融系の操作などにも対応可能となった。

トレードオフ(考慮すべき点)

1. アクセスパターン駆動型設計の要求 DynamoDBの性能を最大限に引き出すためには、データ構造を設計する前に、アプリケーションが「どのようにデータを読み書きするか」というアクセスパターンを完全に把握する必要がある。RDBのようにデータを正規化してから後で任意のクエリを投げるという柔軟なアプローチは難しく、設計段階での高い専門性と将来のアクセスパターンの予測が求められる。

2. 複雑なクエリの非効率性 RDBが得意とする複雑な多対多のJOIN操作やアドホックな全件検索、複雑な集計処理は、DynamoDBではネイティブに効率よく実行できない。これらの処理を行うには、アプリケーション側での処理を増やすか、DynamoDBのデータを他の分析サービス(例:Amazon EMRやAWS Glue)に連携させる必要がある。

3. データ構造の柔軟性の制限 一つのアイテムのサイズは最大400KBという制限がある。非常に大きなバイナリデータや、巨大なネスト構造を持つドキュメントの格納には不向きであり、これらのデータはS3などのオブジェクトストレージと組み合わせて使用することが推奨される。

関連する概念

Global Table(グローバルテーブル)

DynamoDBのテーブルを複数のAWSリージョン間で自動的に同期・レプリケートする機能である。グローバルテーブルを使用することで、ユーザーは地理的に最も近いリージョンからデータにアクセスでき(低レイテンシ)、また特定のリージョン全体に災害が発生した場合のディザスタリカバリ(DR)戦略を極めて容易に実現できる。

RDB(リレーショナルデータベース)との棲み分け

DynamoDBは、その設計思想により、RDBとは明確に異なる利用領域を持つ。RDB(例:PostgreSQL, MySQL)は、データの整合性が最も重要であり、複雑なリレーションシップやアドホックなクエリが求められる業務システムやデータ分析基盤に適している。一方、DynamoDBは、圧倒的なスケーラビリティと高速なKey-Valueアクセスが求められる、定型化されたアクセスパターンの大規模Webサービスやログ基盤に適している。現代のシステム開発では、これら両者を特性に応じて使い分ける「ポリグロット・パーシステンス」のアプローチが主流となっている。

予約キャパシティとオンデマンドキャパシティ

DynamoDBは、ユーザーが読み書きのキャパシティ(スループット)を事前に予約する「プロビジョニング済みキャパシティ」モデルと、実際の使用量に応じて自動的にスケールし課金される「オンデマンドキャパシティ」モデルを提供している。トラフィックが予測可能な場合はプロビジョニングがコスト効率が高いが、突発的なスパイクが発生する可能性がある場合はオンデマンドキャパシティが運用上のリスクを低減する。

由来・語源

(記述募集中)

使用例

(記述募集中)

関連用語

  • (なし)
TOP / 検索 Amazonで探す