Amazon DynamoDBのアーキテクチャ、データ配置、結果整合性
Amazon DynamoDBの基本的なアーキテクチャ、データの配置方法、および結果整合性について解説します。
1. DynamoDBのアーキテクチャ
-
分散型NoSQLデータベース:
- DynamoDBは分散型の設計で、データの高可用性と高スループットを提供します。
-
基本構造:
- テーブル: データを格納する基本単位。
- アイテム: テーブル内の1行に相当。
- 属性: アイテム内のフィールド。
2. データ配置
パーティションの仕組み
- DynamoDBはデータを複数のパーティションに分散して保存します。
- パーティションキー（主キーの一部）を使用して、データを均等に分散。
パーティション設計のポイント
- 一意性を保つキーを選択することで、データとトラフィックを均等に分散。
- 適切な例: ユーザーID、日付の組み合わせ。
- 不適切な例: 固定値や偏りのある値。
パーティションの利点
- スケーラビリティ: 各パーティションが独立して処理を行うため、大量のデータを効率的に処理。
- コスト効率: データアクセスパターンに基づいた設計で無駄なコストを削減。
3. 結果整合性
読み取り整合性のタイプ
-
結果整合性 (Eventually Consistent Reads):
- デフォルトの読み取り整合性。
- データ変更後、数ミリ秒の遅延で最新データが反映。
- 高スループットと低コストを実現。
-
強整合性 (Strongly Consistent Reads):
- 最新データを即座に返す。
- パフォーマンスよりもデータの正確性が重要な場合に使用。
-
トランザクション読み取り (Transactional Reads):
- 複数アイテムを一貫性を保って操作。
- ACID特性をサポート。
整合性の選択ポイント
-
結果整合性:
- 高トラフィックで一時的なデータ遅延が許容される場合に適応。
-
強整合性:
- 正確なデータが必要なシステム（例: 金融や注文処理）で使用。
-
トランザクション読み取り:
- 複数アイテムを確実に更新・取得したい場合に最適。
まとめ表
| 特徴 | 説明 | 主な用途 |
|---|---|---|
| アーキテクチャ | 分散型NoSQLデータベース。テーブル、アイテム、属性で構成。 | 高可用性と高スループットが必要なアプリケーション |
| データ配置 | パーティションキーに基づきデータを分散。 | 均等なデータ分散とスケーラビリティの向上。 |
| 結果整合性 | デフォルトの整合性モデル。更新後すぐには反映されない場合があるが、高スループットを提供。 | データ遅延を許容するアプリケーション。 |
| 強整合性 | 最新データを即座に読み取るモデル。 | データ正確性が重要な場合。 |
| トランザクション整合性 | 複数アイテムの一貫性を保証。ACID特性を提供。 | 複雑な操作や安全性が求められる場合。 |
ユースケース例
-
結果整合性:
- ソーシャルメディアのフィード。
- ユーザーランキングのリアルタイム更新。
-
強整合性:
- 金融取引や注文処理。
- インベントリ管理。
-
トランザクション整合性:
- 複数テーブルをまたがる注文更新。
- バッチ処理。
Amazon DynamoDBのキー属性とインデックス
Amazon DynamoDBでは、効率的なデータ管理とクエリ実行のためにキー属性とインデックスを利用します。
1. キー属性
1.1 主キー（Primary Key）
- DynamoDBテーブルでアイテムを一意に識別するための属性。
-
主キーの種類:
-
単一キー (Simple Primary Key):
- パーティションキー（Partition Key）のみを使用。
- 各アイテムは一意のパーティションキーを持つ。
- 例: ユーザーID。
-
複合キー (Composite Primary Key):
- パーティションキーとソートキー（Sort Key）の組み合わせ。
- パーティションキーが同じでも、異なるソートキーを持つことで一意性を保つ。
- 例: 注文テーブルで、ユーザーID（パーティションキー）と注文日（ソートキー）。
-
単一キー (Simple Primary Key):
1.2 主キー設計のポイント
-
パーティションキーの選択:
- 均等にデータを分散する値を選ぶ。
- 偏りがあると特定のパーティションが過負荷になる。
-
ソートキーの活用:
- 時系列データや範囲クエリを活用する場合に便利。
2. インデックス
2.1 グローバルセカンダリインデックス（GSI: Global Secondary Index）
-
特徴:
- パーティションキーとソートキーを独立して指定可能。
- テーブルの主キーとは異なる組み合わせでクエリを実行。
-
用途:
- 異なる属性で柔軟な検索を実現。
- 例: メールアドレスをキーとしてユーザーを検索。
2.2 ローカルセカンダリインデックス（LSI: Local Secondary Index）
-
特徴:
- テーブルのパーティションキーを共有し、異なるソートキーを指定。
- テーブル作成時にのみ設定可能（後から追加不可）。
-
用途:
- 同じパーティションキー内で異なる属性でソートする場合。
- 例: ユーザーIDで検索し、ソートキーを日付順に並べる。
2.3 インデックス設計のポイント
-
GSI:
- 柔軟なクエリが可能。
- 読み取り/書き込みキャパシティを個別に設定可能。
-
LSI:
- パーティションキー依存の範囲クエリに最適。
- テーブルのデザイン段階で慎重に設定が必要。
3. 主キーとインデックスの比較表
| 種類 | 特徴 | 主な用途 |
|---|---|---|
| 単一キー | パーティションキーのみでアイテムを識別。 | ユニークIDでデータを一意に管理。 |
| 複合キー | パーティションキーとソートキーの組み合わせでアイテムを識別。 | 時系列データや特定の属性でのクエリ。 |
| グローバルセカンダリインデックス (GSI) | 主キーとは異なるパーティションキーとソートキーを設定可能。 | 柔軟な検索パターンを実現。 |
| ローカルセカンダリインデックス (LSI) | 主キーのパーティションキーを共有し、異なるソートキーでクエリ可能。 | 同じパーティションキー内で異なる属性でのソート。 |
4. ユースケース例
-
単一キー:
- ユーザー情報をユーザーIDで検索。
-
複合キー:
- ユーザーIDと日付を組み合わせて注文履歴を検索。
-
GSI:
- メールアドレスやその他のユニーク属性で検索。
-
LSI:
- ユーザーIDごとのイベント履歴を日付順にソート。
Amazon DynamoDBのキャパシティユニット
Amazon DynamoDBでは、データの読み取りおよび書き込みのパフォーマンスを設定するためにキャパシティユニットを使用します。
1. キャパシティモード
DynamoDBでは、2種類のキャパシティモードを提供しています。
1.1 オンデマンドキャパシティモード
-
特徴:
- 自動スケーリングでトラフィックに応じて必要なキャパシティを調整。
- 使用したリクエスト数に応じて料金が発生。
-
適したユースケース:
- トラフィックが予測困難なアプリケーション。
- 開発環境や小規模アプリケーション。
1.2 プロビジョンドキャパシティモード
-
特徴:
- 読み取りおよび書き込みキャパシティを手動で設定。
- ステーブルなトラフィックを持つアプリケーションに最適。
-
スケーリング方法:
- 自動スケーリング機能を使用してキャパシティを調整可能。
-
適したユースケース:
- トラフィックが一定で予測可能なアプリケーション。
2. キャパシティユニットの種類
2.1 読み取りキャパシティユニット (RCU: Read Capacity Unit)
-
1 RCUの定義:
- 1秒間に最大4KBのデータを1回の結果整合性読み取りで処理可能。
- 強整合性読み取りでは2倍のRCUが必要。
- トランザクション読み取りでは4倍のRCUが必要。
2.2 書き込みキャパシティユニット (WCU: Write Capacity Unit)
-
1 WCUの定義:
- 1秒間に最大1KBのデータを1回の書き込みで処理可能。
- トランザクション書き込みでは2倍のWCUが必要。
3. キャパシティの最適化
3.1 アクセスパターンの分析
- アプリケーションの読み取り/書き込み頻度を把握し、適切なキャパシティモードを選択。
3.2 キャッシュの活用
- DynamoDB Accelerator (DAX) を使用して、高速でキャッシュされた読み取りを実現。
3.3 パーティション設計
- パーティションキーを適切に設計して、負荷を均等に分散。
4. 主なユースケース
| キャパシティモード | 特徴 | 主な用途 |
|---|---|---|
| オンデマンドキャパシティ | 自動スケーリングで柔軟な対応が可能。 | 不規則なトラフィック、開発環境、小規模アプリ。 |
| プロビジョンドキャパシティ | 手動でキャパシティを設定し、予測可能なトラフィックに対応。 | 一定のトラフィックを持つアプリケーション。 |
Amazon DynamoDBのAPIと主要パラメータ
DynamoDBの主要APIとそのパラメータを以下にまとめます。
| API名 | 説明 | 主なパラメータ |
|---|---|---|
| PutItem | テーブルにデータを追加または更新。 |
TableName, Item, ConditionExpression, ReturnValues
|
| GetItem | 主キーを指定してデータを取得。 |
TableName, Key, ProjectionExpression, ConsistentRead
|
| Query | パーティションキーを基準に条件を満たすアイテムを取得。 |
TableName, KeyConditionExpression, ExpressionAttributeValues, ProjectionExpression, ScanIndexForward
|
| Scan | テーブル全体をスキャンして条件を満たすアイテムを取得。 |
TableName, FilterExpression, ExpressionAttributeValues, ProjectionExpression, Limit
|
| UpdateItem | 既存のアイテムを更新。 |
TableName, Key, UpdateExpression, ExpressionAttributeNames, ExpressionAttributeValues, ReturnValues
|
| DeleteItem | 主キーを指定してアイテムを削除。 |
TableName, Key, ConditionExpression, ReturnValues
|
| BatchWriteItem | 複数のアイテムを一括で書き込みまたは削除。 |
RequestItems, ReturnConsumedCapacity
|
| BatchGetItem | 複数のアイテムを一括で取得。 |
RequestItems, ProjectionExpression, ConsistentRead
|
| CreateTable | 新しいテーブルを作成。 |
TableName, AttributeDefinitions, KeySchema, ProvisionedThroughput
|
API活用のポイント
-
条件式を活用:
-
ConditionExpressionを使用して、データ競合や誤った更新を防止。
-
-
効率的なデータ取得:
-
ProjectionExpressionを活用して必要な属性のみ取得し、コストを最適化。
-
-
バッチ操作:
- 一括操作（BatchWriteItem, BatchGetItem）を活用して効率化。
その他機能
| 機能名 | 概要 | 主なユースケース |
|---|---|---|
| TTL (Time to Live) | アイテムに有効期限を設定し、自動で削除する機能。 | セッションデータ、キャッシュの自動クリア。 |
| DAX | DynamoDB専用のインメモリキャッシュで読み取り操作を高速化。 | 高頻度の読み取り操作、ランキングや商品カタログの表示。 |
| DynamoDB Streams | テーブルのデータ変更をリアルタイムでキャプチャ。 | データ変更ログの監視、レプリケーション、リアルタイム通知。 |
| Triggers | DynamoDB StreamsとLambdaを組み合わせてデータ変更イベントを処理。 | リアルタイム通知、変更データの同期や集計処理。 |
| グローバルテーブル | マルチリージョン間でデータを同期し、低レイテンシと高可用性を提供。 | グローバルアプリケーション、リージョン障害のフェイルオーバー対策。 |