AWS用途特化DB本番運用Vol5｜Neptune・DocumentDB・Timestream

1. この記事について — なぜ用途特化データベースを選ぶのか

1-1. 本記事のゴール

本記事は「AWS Database 本番運用」シリーズのVol5として、用途特化データベース4種—Amazon Neptune(グラフ)・Amazon DocumentDB(ドキュメント)・Amazon Keyspaces(ワイドカラム)・Amazon Timestream(時系列)—を対象にします。AWS re:Invent 2024でのアップデートと2025年の新機能を反映しており、各DBの最新のGA機能に基づいた情報を提供します。特にNeptune AnalyticsのベクトルサーチとGraphRAG、DocumentDB 8.0、TimestreamのInfluxDB 3対応は2025年における重要な変更点です。

リレーショナルデータベース(RDS/Aurora)やKVS(DynamoDB)が対象とするのは、行・列・主キーという構造化されたデータモデルです。これに対しVol5が扱う4つのDBは、「データの形がリレーショナルに合わない」場面で真価を発揮します。グラフ構造の関係性・半構造化ドキュメント・時系列の連続値・疎なワイドカラム、それぞれ特化したエンジンを選ぶことで、スキーマ設計の複雑さを排除しクエリ性能を最大化できます。

本記事を読み終えた時点で、ワークロードのデータ構造から適切なDBを選定し、Serverlessスケーリング・ベクトル検索・Multi-Region Replicationといった2025年時点の最新機能を本番環境へ適用できる状態に到達します。

本記事は以下の3つを一貫して意識して執筆しています。第一に「選定根拠の明示」—なぜこのDBを選ぶのかをデータモデルとクエリパターンで説明します。第二に「最新仕様の正確な反映」—2025年現在のGA機能のみを解説対象とし、廃止予定の機能については明記します。第三に「本番運用まで見通した設計」—PoC段階の検証から、可用性・セキュリティ・コスト最適化まで含む運用視点で解説します。

各DBの解説は、機能概要→CLIによる構築例→クエリ例→本番運用ポイントの順に展開します。一部のサービスでは構築からクエリまでを連続して試せるよう、具体的なコマンド例を掲載しています。ローカル環境から試せるものはAWS CLIv2とPython 3.10以上があれば実行できます。

なお、本記事のコード例はすべて教育目的のサンプルです。プロダクション環境で使用する際は、VPCエンドポイント・セキュリティグループ・KMS暗号化・バックアップ設定・マルチAZ配置などを必ず検討してください。各サービスのAWS公式ドキュメントとセキュリティベストプラクティスガイドも合わせて参照することを推奨します。

本記事で取り上げる4つのDBはすべてAWSのWell-Architected Frameworkの「パフォーマンス効率の柱」に記載されているデータベース選定の考え方と一致しています。適切なデータベースを選ぶことは、スケーラビリティ・コスト・開発生産性の全てに影響を与える設計判断であり、後から変更するコストが高いアーキテクチャの根幹を形成します。本記事がその判断の参考になれば幸いです。本シリーズのVol1-Vol4で学んだリレーショナルDBの知識を土台に、用途特化DBを適材適所で組み合わせることで、より堅牢で効率的なデータアーキテクチャを構築できます。

用途特化DBへの移行や新規採用を検討する際は、まず現行システムのデータモデルとクエリパターンを整理するところから始めることを推奨します。スキーマ設計・アクセスパターン・書き込みQPS・読み込みレイテンシ要件を書き出すことで、どのDBが最適かが自然に絞り込まれます。

各DBの詳細は次節以降で解説します。まずはデータモデルの制約が最も厳しいグラフDB(Neptune)から始め、以降のDBへと展開していきます。

1-2. 読者像

本記事の対象読者は、リレーショナルDBでは設計上の無理が生じるワークロードを抱えるアーキテクトおよびデータエンジニアです。

たとえば、ソーシャルグラフや不正検知のためにRDSで複雑な自己結合を書き続けてパフォーマンス限界に直面している方、MongoDBをオンプレで運用しAWSへ移行先を探している方、IoTセンサーデータや運用メトリクスをリレーショナルDBに蓄積して時間窓クエリが遅くなっている方、Cassandraクラスターの運用負荷を下げたい方が該当します。

AWSの基本的なネットワーク・IAM・CLIの操作経験があれば、データベースの専門知識がない状態からでも本記事の内容を実践できます。Vol1(RDS/Aurora/DynamoDB)の基礎知識があるとより理解が深まりますが、必須ではありません。

本記事が特に役立つ場面は以下の通りです。新しいサービスのデータモデルを検討していて「RDS/DynamoDBで本当に良いのか」と迷っている場面、既存の自己管理型OSSデータベース(MongoDB/Cassandra/Neo4j/InfluxDB)をAWSのマネージドサービスに移行する計画を立てている場面、そして生成AIシステムのRAG基盤にグラフ構造を活用したい場面です。

各§はそれぞれ独立して読めるように構成しています。Neptune(§2)・DocumentDB(§3)・Keyspaces(§4)・Timestream(§5)のうち、担当するサービスのみを優先して読み進めても問題ありません。最後の§6-§8はシリーズ全体の選定マトリクス・移行パターン・詰まりポイントをまとめており、複数のDBを検討中の方に特に有用です。

本記事の前提条件は以下の通りです。AWSアカウントが取得済みであり、VPCとサブネットが作成されていることを前提とします。CLIコマンドはAWS CLIv2を使用しており、aws configure でリージョンとクレデンシャルが設定済みであることを想定します。Neptuneのサブネットグループ・セキュリティグループは事前に作成するか、CLIコマンドの --db-subnet-group-name 部分を実際のリソース名に置き換えて使用してください。各コマンドのリソースID(sg-xxxxxxxx等)は環境に応じて読み替えてください。

AWSコンソールからの操作も可能ですが、本記事ではIaC(Infrastructure as Code)を意識してCLIコマンドを中心に解説します。本番環境ではTerraformまたはAWS CDKを使ったDB構築が再現性・バージョン管理の観点から推奨されます。CloudFormationテンプレートについても各サービスが対応しており、コンソール操作からテンプレートをエクスポートして再利用できます。

運用面では、本番環境での用途特化DBの初期導入にはPoCを推奨します。小規模なデータセットで性能・コスト・運用の3点を検証し、目標値を達成した後に本番移行する手順が安全です。特にNeptuneのグラフデータモデル設計とKeyspacesのパーティションキー設計は、後から変更するコストが高いため、初期設計に十分な時間をかけることが重要です。

1-3. 本シリーズの位置づけと既存記事との棲み分け

AWS Database 本番運用シリーズは、データモデル軸でボリュームを区切っています。Vol1はリレーショナル(RDS/Aurora)とKVS(DynamoDB)を、Vol2は移行(DMS)とグローバルレプリケーション(Aurora Global)を、Vol3はキャッシュ(ElastiCache/DAX/MemoryDB)を、Vol4は分散SQLトランザクション(Aurora DSQL/Limitless)を扱いました。

本Vol5の位置づけは「データモデルが行・列・KVに収まらない用途特化DB」の本番運用です。グラフDB(Neptune)はノード間の関係性そのものをデータとして扱い、JOIN不要でグラフ横断クエリを実行します。ドキュメントDB(DocumentDB)はJSONドキュメントを柔軟なスキーマで格納し、MongoDB互換APIでアプリケーション側の書き換えを最小化します。ワイドカラムDB(Keyspaces)はApache Cassandra互換のCQLで大規模な分散書き込みを処理します。時系列DB(Timestream)はIoT・メトリクス・ログの連続値を効率的に格納・集計します。

Vol1-4で扱ったリレーショナル/KVSはほぼ全てのワークロードの基盤となりますが、用途特化DBをサブシステムとして組み合わせることで、アーキテクチャ全体の性能とコストを最適化できます。本Vol5はその「組み合わせ設計」の視点で解説します。

用途特化DBを採用する動機として最も多いのは、「既存のリレーショナルDBで限界に達したから移行する」というケースです。しかし理想的には、要件定義の段階でデータモデルを整理し、どのDBが最適かを先に判断することが重要です。後から移行するコストはゼロから設計するコストの数倍になることがあるため、プロジェクト開始時点でのDB選定が長期的なコストに大きく影響します。本記事はその初期設計判断をサポートすることを目的の一つとしています。

データモデル別の選択フロー

選択の基本方針は「データの形」と「クエリのパターン」で決まります。データ間の関係性(エッジ)をトラバースするならNeptune、スキーマレスJSONならDocumentDB、高スループット書き込みと疎なカラムならKeyspaces、タイムスタンプ付き連続値の集計ならTimestreamを選びます。どれにも該当しない場合は、Vol1のRDS/Aurora/DynamoDBに立ち返るのが原則です。

リレーショナルDBとの境界線は「JOINとスキーマ変更コスト」にあります。数ホップ以上の関係トラバーサルでJOINコスト増加が顕著な場合はNeptune、スキーマ変更の多いネストしたドキュメントはDocumentDB、書き込みスループット最優先かつスパースなカラム構造ならKeyspaces、タイムスタンプが主キーになる連続値ならTimestreamという判断軸で選定できます。

リレーショナルDBとの役割分担

実際のシステムでは、リレーショナルDBと用途特化DBを併用するケースが多くあります。たとえばECサイトでは、注文・決済・在庫の管理にRDS/Aurora(リレーショナル)を使いながら、レコメンドエンジンのグラフ処理にNeptune、商品カタログの柔軟なスキーマにDocumentDB、センサー連動の価格変動ログにTimestreamを組み合わせることができます。

この設計パターンでは、各DBへのアクセスをAPIゲートウェイまたはマイクロサービス境界で分離し、データの所有者を1つのサービスに限定することが重要です。Neptuneに格納するグラフデータの属性情報をRDSに残しておき、グラフはIDと関係性のみを持つ軽量な形式にするといった分担が典型的な設計です。

EventBridgeを使って各DBへの書き込みを非同期で伝播させることで、リレーショナルDBと用途特化DBの整合性を保ちながら書き込みパスを分離できます。たとえばユーザー登録イベントをRDSに保存した後、EventBridgeルールでNeptuneにユーザーノードを作成し、DocumentDBにプロファイルドキュメントを格納するといったイベント駆動の連携パターンが実践的です。このパターンはトランザクション境界をAPIレイヤーに持たせ、各DBは最終的な整合性で連携します。

コスト比較の視点

用途特化DBの導入を検討する際は、既存のリレーショナルDBで無理に対応した場合のコストと比較することが重要です。たとえばMySQLでグラフ構造を再帰CTEやアプリ側のループで実現した場合、クエリコスト・インデックスサイズ・開発工数の合計がNeptuneの月額コストを大幅に上回るケースがよくあります。

Neptune Serverless・DocumentDB I/O-Optimized・Keyspacesのオンデマンド容量モードなど、各DBには利用量に応じた課金モデルが用意されています。初期は小規模から始め、トラフィック増加に合わせてスケールアップできるため、PoC段階での初期投資を抑えた評価が可能です。

AWSコストエクスプローラーで各DBのコストを可視化し、Cost Anomaly Detectionで急増を早期検知することを推奨します。用途特化DBの大部分はストレージ料金が月次で増加するため、データ保持期間ポリシーとアーカイブ戦略(S3への定期エクスポート)を最初から設計しておくことが重要です。TimestreamはStorage Tiers(Memory/Magnetic)を自動で切り替えてストレージコストを最適化しますが、NeptuneとDocumentDBは保存データ量に応じてコストが直線的に増加するため、不要データの定期削除ポリシーを設定します。

用途特化DBの採用コスト試算は、単体のDB費用だけでなくアプリケーション側の開発工数・テスト工数・ドライバー互換性の検証コストも含めて評価することが重要です。たとえばNeptune(Gremlin)を採用する場合、開発チームのGremlinスキル習得・クエリテスト・既存アプリの改修コストを加えると、初年度の総コストはインスタンス費用の数倍になることがあります。一方で、リレーショナルDBでは実現困難なグラフクエリを数行のGremlinで記述できる開発効率向上は、中長期的に大きな価値を生みます。

2025年時点の注目アップデート

2025年に入り、各用途特化DBで重要なアップデートがあります。NeptuneはGraphRAGツールキット(2025年1月)と65,000次元ベクトル検索を追加し、生成AIのナレッジグラフ基盤としての用途が広がっています。DocumentDB 8.0はMongoDB 6.0/7.0/8.0からの移行を正式サポートし、Elastic ClustersのシャーディングがGAになっています。KeyspacesはMulti-Region ReplicationでUDT(ユーザー定義型)のマルチリージョン対応を2025年3月に追加しました。TimestreamはInfluxDB 3(Apache Arrow/DataFusion)への対応を進め、LiveAnalytics(旧Timestream)は2025年6月20日以降の新規受付を終了しています。

これらのアップデートを踏まえ、各§でそれぞれの最新仕様を詳しく解説します。

セキュリティ設計の共通原則

用途特化DBを本番運用する際のセキュリティ設計は、リレーショナルDBと共通する原則が多くあります。最小権限のIAMポリシーを適用し、データへのアクセスはVPC内のプライベートサブネットに限定します。静止データの暗号化はKMSマネージドキーを使用し、転送中データはTLS 1.2以上を強制します。

CloudTrailでAPIアクセスを記録し、GuardDutyで異常なクエリパターンを検知する体制を整えることで、リレーショナルDBと同等のセキュリティ水準を用途特化DBにも適用できます。各サービス固有のセキュリティ設定（NeptuneのIAM認証・DocumentDBの役割ベースアクセス制御・KeyspacesのCassandraロール）については各§で詳述します。

本記事で使用するサンプルアーキテクチャ

本記事を通じて、以下のサンプルアーキテクチャを参照します。マルチテナントのSaaSプラットフォームを想定し、ユーザー・組織・プロジェクトの関係性をNeptune(グラフ)で管理し、プロジェクト設定ドキュメントをDocumentDB(ドキュメント)に格納し、アクティビティログをKeyspaces(ワイドカラム)に大量書き込みし、メトリクス時系列をTimestream(時系列)で集計します。

このアーキテクチャはVPC内のプライベートサブネットに全DBを配置し、AppSync/APIゲートウェイ経由でフロントエンドからアクセスします。DynamoDB(KVS)はセッション管理に使用し、RDS/Aurora(リレーショナル)は課金・請求レコードに使用します。各§では、このアーキテクチャにおける設計判断と本番運用の実践を解説します。

基礎編：Database Vol1(RDS×Aurora×DynamoDB)を読む
分散SQL編：Database Vol4(Aurora DSQL×Limitless)を読む

2. Amazon Neptune — グラフデータベース

Amazon Neptuneは、AWSが提供するフルマネージドのグラフデータベースサービスです。ノード(頂点)とエッジ(辺)で構成されるグラフ構造のデータを高速に格納・クエリします。ソーシャルネットワーク・レコメンドエンジン・不正検知・ナレッジグラフなど、エンティティ間の関係性を多段階でたどる必要があるユースケースに適しています。

Neptuneはリレーショナルデータベースのような行・列ではなく、プロパティグラフ(Property Graph)またはRDF(Resource Description Framework)という2つのデータモデルをサポートしています。プロパティグラフにはGremlinとopenCypherというクエリ言語を、RDFにはSPARQLを使用します。1つのNeptuneクラスターで複数のグラフモデルを混在させることはできず、作成時にモデルを選択します。グラフモデルの選択は後から変更できないため、ユースケースとチームの既存知識を考慮して慎重に選定することが重要です。

2-1. Neptune Database と Neptune Analytics・Serverless

Neptune Database(OLTP・トランザクショナルグラフ)

Neptune Databaseは、トランザクショナルなグラフワークロード向けのメインサービスです。書き込みと読み込みを同時並行で処理し、ACIDトランザクションをサポートします。プライマリインスタンスと最大15台のリードレプリカで構成するクラスター構成をとり、Aurora同様の分散ストレージ(6コピー・3AZ)でデータを保護します。

クラスターのエンドポイントは書き込み用(クラスターエンドポイント)と読み込み用(リーダーエンドポイント)に分かれています。接続にはボルトプロトコル(openCypher)またはWebSocket(Gremlin)を使用し、HTTPエンドポイント経由でREST形式のクエリも実行できます。フェイルオーバー時はAWSが自動的にリードレプリカをプライマリに昇格させ、クラスターエンドポイントへの参照は変更不要のまま接続が継続します。

# Neptune クラスター作成(CLI)
aws neptune create-db-cluster \
  --db-cluster-identifier my-graph-cluster \
  --engine neptune \
  --engine-version 1.3.2.1 \
  --vpc-security-group-ids sg-xxxxxxxx \
  --db-subnet-group-name my-neptune-subnet-group \
  --storage-encrypted

# インスタンス追加
aws neptune create-db-instance \
  --db-instance-identifier my-graph-instance \
  --db-instance-class db.r6g.large \
  --engine neptune \
  --db-cluster-identifier my-graph-cluster

Neptune Serverless — 最大90%のコスト削減

Neptune Serverlessは2022年にGAとなった自動スケーリング機能で、ワークロードに応じてNeptune Capacity Units(NCU)を自動的に増減します。トラフィックがゼロに近い時間帯はNCUを最小値まで絞り込み、ピーク時には設定した上限まで自動的に拡張します。AWS公式のユースケース比較では、間欠的なワークロードで最大90%のコスト削減を達成できるとされています。

Serverlessを利用するには、クラスター作成時に --serverless-v2-scaling-configuration を指定し、最小・最大NCUを設定します。最小NCUを0に設定するとほぼゼロスケーリングが有効になり、初回接続時に起動レイテンシが発生しますが、開発環境や利用頻度の低い本番サブシステムでコストを大幅に抑制できます。

# Neptune Serverless クラスター作成
aws neptune create-db-cluster \
  --db-cluster-identifier my-serverless-graph \
  --engine neptune \
  --engine-version 1.3.2.1 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=64 \
  --vpc-security-group-ids sg-xxxxxxxx \
  --db-subnet-group-name my-neptune-subnet-group

# Serverless インスタンス追加(db.serverless クラス指定)
aws neptune create-db-instance \
  --db-instance-identifier my-serverless-instance \
  --db-instance-class db.serverless \
  --engine neptune \
  --db-cluster-identifier my-serverless-graph

Neptune Analytics — グラフ分析とベクトル検索

Neptune Analyticsは2023年にGAとなった分析特化型のエンジンで、Neptune Databaseとは独立したサービスです。インメモリグラフ処理エンジンを持ち、数十億エッジのグラフでも高速な分析クエリを実行できます。openCypherを使用し、グラフアルゴリズム(PageRank・コミュニティ検出・最短経路など)をSQLライクな構文で記述できます。

Neptune Analyticsの最大の特徴は、ベクトル検索との統合です。グラフのノードプロパティとして最大65,000次元のベクトルを格納し、類似度検索(ANN: Approximate Nearest Neighbor)を処理できます。これにより、埋め込みベクトル(Embedding)を持つノード間の意味的な類似性検索と、グラフトラバーサルを組み合わせた検索が可能になります。

# Neptune Analytics グラフ作成(最大65,000次元ベクトル対応)
aws neptune-graph create-graph \
  --graph-name my-analytics-graph \
  --provisioned-memory 16 \
  --vector-search-configuration dimension=1536 \
  --replica-count 1

2-2. クエリ言語(Gremlin/openCypher/SPARQL)とベクトル検索/GraphRAG

プロパティグラフ: Gremlin

GremlinはApache TinkerPop準拠のグラフトラバーサル言語です。グラフをステップ単位でたどるため、複数ホップの関係性を直感的に記述できます。

// Gremlin: ユーザー "alice" の友人の友人を検索(2ホップ)
g.V().has('User', 'name', 'alice')
  .out('FRIEND').out('FRIEND')
  .dedup()
  .values('name')

// Gremlin: レコメンド — aliceが購入した商品を他ユーザーも購入している場合
g.V().has('User', 'name', 'alice')
  .out('PURCHASED').in('PURCHASED')
  .where(neq('alice'))
  .out('PURCHASED')
  .dedup()
  .limit(10)
  .values('productName')

// Gremlin: 不正検知 — 同一IPから作成されたアカウントのネットワーク
g.V().has('IPAddress', 'address', '203.0.113.1')
  .in('REGISTERED_FROM')
  .out('TRANSFERRED_TO')
  .path()

プロパティグラフ: openCypher

openCypherはNeo4j由来のグラフクエリ言語で、SQLに近い宣言型構文を持ちます。Neptune AnalyticsではopenCypherを使用します。

// openCypher: ユーザー "alice" の友人を検索
MATCH (u:User {name: 'alice'})-[:FRIEND]->(friend:User)
RETURN friend.name

// openCypher: 最短経路(2人のユーザー間)
MATCH p = shortestPath(
  (a:User {name: 'alice'})-[*]-(b:User {name: 'bob'})
)
RETURN p

// openCypher: レコメンド — aliceが閲覧した商品カテゴリの人気商品
MATCH (u:User {name: 'alice'})-[:VIEWED]->(p:Product)-[:IN_CATEGORY]->(c:Category)
MATCH (c)-[:IN_CATEGORY]-(rec:Product)
WHERE NOT (u)-[:VIEWED]->(rec)
RETURN rec.name, count(*) AS score
ORDER BY score DESC
LIMIT 10

RDF: SPARQL

RDFデータモデルではトリプル(主語・述語・目的語)でデータを表現し、SPARQLでクエリします。ナレッジグラフや標準化された語彙(Schema.org/OWL)を扱う場合に適しています。プロパティグラフに比べてデータの相互運用性と標準準拠が重視されるユースケース、たとえば医療・製造・公共データの統合基盤での採用実績があります。

# SPARQL: 製品と製造メーカーの関係を検索(CONSTRUCT で RDF グラフとして結果取得も可能)
PREFIX ex: <http://example.org/>
SELECT ?product ?manufacturer
WHERE {
  ?product ex:manufacturedBy ?manufacturer .
  ?manufacturer ex:country "Japan" .
}
LIMIT 100

ベクトル検索とGraphRAG(2025年最新)

Neptune Analyticsはベクトルをノードのプロパティとしてネイティブに格納し、グラフトラバーサルと組み合わせた複合検索が可能です。2025年1月に公開されたGraphRAGツールキットは、Bedrockと連携してグラフ構造に基づいたRAG(検索拡張生成)を実現します。

通常のベクトル検索(意味的類似度)だけでなく、グラフの関係性を考慮した検索が可能なため、「類似した文書を見つけ、かつその文書と特定の関係にあるエンティティ」という複合クエリを実行できます。たとえば、論文の埋め込みベクトルで類似論文を検索し、引用関係グラフをたどって関連研究者を特定するといったユースケースに対応します。

// openCypher + ベクトル検索: 類似ノードを検索し関連エッジを取得
CALL neptune.algo.vectors.topKByNode(
  {nodeId: 'node-001', topK: 5, embeddingProperty: 'embedding'}
)
YIELD node, score
MATCH (node)-[:RELATED_TO]->(related)
RETURN node.title, score, related.title
ORDER BY score DESC

GraphRAGの利用にはNeptune AnalyticsのグラフにBedrockで生成した埋め込みベクトルをロードし、GraphRAGツールキットのPython SDKを使って推論パイプラインを構築します。Bedrock + Neptuneの組み合わせにより、構造化された関係性情報をLLMの文脈として与えるRAGが実現できます。

Neptune Database vs Analytics — 使い分け判断表

実際のシステムでは両者を組み合わせるパターンが多くあります。トランザクショナルな書き込みはNeptune Databaseに行い、定期的(日次・週次)にデータをS3経由でNeptune Analyticsにエクスポートして分析・推論に使用します。この構成により、OLTPとOLAPを分離しつつ最新のベクトル検索・GraphRAG機能を活用できます。

Neptune の本番運用ポイント

NeptuneはVPC内のプライベートサブネットに配置し、セキュリティグループで接続元を制限します。エンドポイントへのアクセスにはIAM認証またはVPCエンドポイントを使用します。バックアップは自動スナップショット(最大35日保持)とクラスタースナップショットで対応します。

モニタリングはCloudWatchメトリクス(GremlinRequestsPerSec・BufferCacheHitRatio・FreeableMemory)を中心に設定し、応答時間の劣化はクエリのトラバーサル深度とインデックス設計を見直します。Neptune Loaderを使ったS3からのバルクロードは、大規模グラフの初期投入に最適で、インクリメンタルな更新はStreamsを介してLambdaやKinesisと連携できます。CloudWatch Alarmで BufferCacheHitRatio が80%を下回った場合は、インスタンスサイズのスケールアップまたはキャッシュ効率を上げるクエリ改善を検討します。FreeableMemoryが1GB未満になった場合もスケールアップの目安とし、Serverlessではmax NCUの上限を引き上げることで対応します。

Neptuneのインデックスはグラフ構造に基づいており、リレーショナルDBのように任意のカラムにインデックスを張る概念とは異なります。Gremlinクエリの性能を上げるには、頂点プロパティに対するインデックスを schema.config() で定義し、頂点ラベルとプロパティの組み合わせを最適化します。openCypherの場合はノードプロパティのインデックスを CREATE INDEX 構文で作成できます。

大規模なグラフでトラバーサルが遅い場合は、クエリの起点となる頂点の選択を見直すことが効果的です。たとえばGremlinで g.V() から始めるフルスキャンは避け、g.V().has('label', 'key', 'value') のように有インデックスのプロパティで絞り込んでから関係をたどる設計にします。

Neptuneのバージョン管理はAWSによるマネージドアップデートに従います。メジャーバージョンアップグレードは手動でクラスターを更新し、マイナーバージョンは自動更新または手動適用を選択できます。本番環境では自動マイナーアップデートを有効にしつつ、メジャーバージョンアップは開発・ステージング環境での検証後に適用する運用が標準的です。稼働中のクラスターに対するインプレースアップグレードも可能で、クラスターを削除・再作成する必要はありません。メンテナンスウィンドウを低トラフィック時間帯に設定し、リードレプリカのローリングアップデートで無停止のアップグレードを実現できます。アップグレード後はGremlin/openCypherのクエリ動作に変更がないことをステージング環境で確認してから本番適用することを推奨します。エンジンバージョンの互換性情報はAWSリリースノートとNeptuneのアップグレードガイドで事前に確認できます。

Neptuneのバージョン1.3以降ではSparQL 1.1のフル仕様をサポートし、RDFデータの外部ストアとのフェデレーションクエリも可能になっています。GraphRAGとRDFの組み合わせにより、標準化されたオントロジーを持つナレッジグラフを生成AIに接続するエンタープライズユースケースが広がっています。

# Neptune ログ有効化(スロークエリ確認)
aws neptune modify-db-cluster--db-cluster-identifier my-graph-cluster--cloudwatch-logs-export-configuration EnableLogTypes=slowquery--apply-immediately

# Neptureクラスターのバックアップ確認
aws neptune describe-db-cluster-snapshots--db-cluster-identifier my-graph-cluster--query 'DBClusterSnapshots[*].[DBClusterSnapshotIdentifier,Status,SnapshotCreateTime]'--output table

3. Amazon DocumentDB — ドキュメントデータベース

3-1. MongoDB 互換と DocumentDB 8.0

Amazon DocumentDBはMongoDB互換のドキュメント型データベースです。ワイヤプロトコルはMongoDB 3.6/4.0/5.0/8.0に対応しており、既存のMongoDBドライバをそのまま利用できます。

2024年にリリースされたDocumentDB 8.0では、MongoDB 6.0/7.0/8.0との高い互換性が確保されており、移行に必要なコード変更を最小限に抑えられます。

接続には標準的なMongoDBドライバを使用します。

import os
import pymongo

uri = (
 f"mongodb://{os.environ['DOCDB_USER']}:{os.environ['DOCDB_PASS']}"
 "@cluster.docdb.amazonaws.com:27017/"
)
client = pymongo.MongoClient(uri, tls=True, tlsCAFile="global-bundle.pem", retryWrites=False)
db = client["mydb"]

db["products"].insert_one({"name": "Widget A", "price": 1200, "stock": 50})
doc = db["products"].find_one({"name": "Widget A"})
print(doc)
client.close()

const { MongoClient } = require("mongodb");

const uri = `mongodb://${process.env.DOCDB_USER}:${process.env.DOCDB_PASS}@cluster.docdb.amazonaws.com:27017/`;
const client = new MongoClient(uri, { tls: true, tlsCAFile: "global-bundle.pem", retryWrites: false });

client.connect().then(async () => {
  const col = client.db("mydb").collection("products");
  await col.insertOne({ name: "Widget A", price: 1200, stock: 50 });
  const doc = await col.findOne({ name: "Widget A" });
  console.log(doc);
  client.close();
});

3-2. Elastic Clusters と I/O-Optimized

Elastic Clustersはシャーディングを利用して大規模データセットを水平分散するDocumentDBのオプションです。MongoDB 5.0ワイヤプロトコルに対応しており、シャードを跨いだreadable secondariesによる読み取りスケールアウトが可能です。また、start/stop機能により、開発環境や検証環境のコストを削減できます。

I/O-OptimizedはI/O料金をクラスターの時間課金に含める仕組みです。I/O集約型のワークロードでは、I/O費用が高騰しやすくなります。I/O-Optimizedを選択することで月次コストの予測が立てやすくなります。一般的にI/O費用がインスタンス費用の25%を超える場合にI/O-Optimizedが有利とされます。

# Elastic Clusters の作成
aws docdb-elastic create-cluster \
  --cluster-name my-elastic-cluster \
  --admin-user-name adminuser \
  --admin-user-password "${DOCDB_ADMIN_PASS}" \
  --shard-capacity 2 \
  --shard-count 2 \
  --vpc-security-group-ids sg-xxxxxxxx \
  --subnet-ids subnet-aaaa subnet-bbbb

# クラスタの停止 (コスト削減)
aws docdb-elastic stop-cluster \
  --cluster-arn arn:aws:docdb-elastic:ap-northeast-1:123456789012:cluster/my-elastic-cluster

# 通常クラスタを I/O-Optimized に変更
aws rds modify-db-cluster \
  --db-cluster-identifier my-docdb-cluster \
  --storage-type iopt1 \
  --apply-immediately

4. Amazon Keyspaces — ワイドカラム(Apache Cassandra 互換)

4-1. Cassandra 互換(CQL)と Serverless 容量モード

Amazon KeyspacesはApache Cassandra互換のマネージドワイドカラムデータベースです。CQL (Cassandra Query Language) でテーブル操作ができ、既存のCassandraドライバをそのまま利用できます。

容量モードはオンデマンドとプロビジョンドの2種類があります。オンデマンドモードはリクエスト単位の従量課金で、トラフィックが不規則なワークロードに適しています。プロビジョンドモードはキャパシティユニットを事前に確保するため、安定したスループットが必要な本番ワークロードでコスト予測が立てやすくなります。

-- キースペースの作成
CREATE KEYSPACE IF NOT EXISTS shop
  WITH REPLICATION = {'class': 'SingleRegionStrategy'}
  AND TAGS = {'env': 'prod'};

-- テーブルの作成
CREATE TABLE IF NOT EXISTS shop.orders (
  order_id  uuid,
  user_idtext,
  createdtimestamp,
  total  decimal,
  PRIMARY KEY (user_id, created)
) WITH CLUSTERING ORDER BY (created DESC);

-- レコードの挿入
INSERT INTO shop.orders (order_id, user_id, created, total)
  VALUES (uuid(), 'user_001', toTimestamp(now()), 4800);

-- クエリ
SELECT order_id, created, total
  FROM shop.orders
  WHERE user_id = 'user_001'
  LIMIT 10;

4-2. Multi-Region Replication

Multi-Region ReplicationはKeyspacesのactive-activeレプリケーション機能です。複数のAWSリージョン間でデータが双方向に同期され、伝播時間は通常約1秒です。

既存のKeyspaceにリージョンを追加する場合、AWS CLIまたはマネジメントコンソールからレプリカ設定を変更できます。UDT (User-Defined Type) のマルチリージョン対応は2025年3月に追加されました。

# 新規 Keyspace をマルチリージョンで作成
aws keyspaces create-keyspace \
  --keyspace-name shop \
  --replication-specification \
 "replicationStrategy=MULTI_REGION_SINGLE_TABLE,regionList=[ap-northeast-1,us-east-1]"

# 既存 Keyspace へのリージョン追加
aws keyspaces update-keyspace \
  --keyspace-name shop \
  --replication-specification \
 "replicationStrategy=MULTI_REGION_SINGLE_TABLE,regionList=[ap-northeast-1,us-east-1,eu-west-1]"

# UDT の作成 (マルチリージョン対応: 2025-03 以降)
# cqlsh で接続後に実行
# CREATE TYPE shop.address (street text, city text, postal_code text);

5. Amazon Timestream — 時系列データベース

5-1. Timestream の現行提供形態(for InfluxDB 主軸)

Amazon Timestreamは、AWSが提供するマネージド時系列データベースサービスです。2025年6月現在、提供形態は大きな転換点を迎えています。

提供形態の現状

Timestream for LiveAnalyticsは、2025年6月20日をもって新規顧客の受付を終了しました。既存顧客は引き続きサービスを継続利用できますが、新規ワークロードへのTimestream for LiveAnalyticsの採用はできません。AWSは既存のLiveAnalyticsユーザー向けにTimestream for InfluxDBへの移行ツールを提供しており、段階的な移行パスが整備されています。

現時点で新規ユーザーが選択するべき時系列データベースは、Timestream for InfluxDB一択です。

Timestream for InfluxDB とは

Timestream for InfluxDBは、オープンソースの時系列データベースInfluxDBをAWSが完全マネージドで提供するサービスです。InfluxDB 2.7とInfluxDB 3(2025年10月対応)の両バージョンに対応しており、既存のInfluxDBユーザーは最小限の変更でAWSマネージド環境に移行できます。

InfluxDB 3では、Apache Arrow・DataFusion・Parquet・Amazon S3との統合が追加されました。Apache ArrowのColumnarメモリフォーマットとRust製クエリエンジンであるDataFusionにより、大量の時系列データをシングルミリ秒(single-digit ms)の低レイテンシで処理します。長期データはParquet形式でAmazon S3に保存され、コールドデータのコスト効率が大幅に向上しています。

主な用途

Timestream for InfluxDBが適するワークロードは次のとおりです。

• IoTセンサーデータ: 工場設備・スマートメーター・車両テレメトリなど、秒〜分単位で収集する計測値の大量蓄積
• インフラメトリクス: AWSコンピュートリソース(ECS・RDSなど)のCPU使用率・メモリ・ネットワークトラフィックの時系列管理
• アプリケーションAPM: APIレスポンスタイム・スループット・エラーレートの可視化・アラート
• 金融データ: 株価・為替レートの高頻度時系列データ管理と集計

Bedrock との棲み分け

Timestream for InfluxDBはIoTセンサー値・インフラメトリクス・アプリケーション計測値といった数値時系列データの蓄積と高速クエリに特化しています。生成AIのファインチューニング・推論・ベクトル埋め込みはAmazon Bedrockが担当します。Timestreamを「Bedrockへの時系列フィーダー」として組み合わせる構成は有効ですが、Timestreamそのものに生成AI機能はありません。IoT異常検知をTimestreamで時系列蓄積してBedrockでパターン解析するアーキテクチャが典型的な連携パターンです。

5-2. InfluxDB 3 の取込・クエリと時系列設計

InfluxDB Line Protocol

Timestream for InfluxDBへのデータ取り込みには、InfluxDB Line Protocolを使用します。Line Protocolは以下の形式でテキストエンコードする軽量なプロトコルです。

measurement[,tag_key=tag_value...] field_key=field_value[,field_key=field_value] [unix_timestamp_ns]

具体例を見てみます。

cpu_usage,host=web-01,region=ap-northeast-1 value=72.5,load_avg=1.23 1748908800000000000
temperature,sensor=TMP-001,location=factory-floor celsius=24.8,humidity=58.2

各部分の役割は次のとおりです。

• measurement: テーブル名に相当する計測名(例: cpu_usage)
• タグ(tag_set): インデックス化されたメタデータ。フィルタリングに使うホスト名・リージョンなど固定値を格納します。カーディナリティの高い値(ユーザーIDなど)はタグに入れないことがInfluxDB設計の鉄則です
• フィールド(field_set): 実際の計測値(数値・文字列・真偽値)
• タイムスタンプ: nanoseconds単位のUnixタイムスタンプ(省略時はサーバー時刻)

InfluxDB CLI による書き込みとバケット管理

# InfluxDB CLIのセットアップ(macOS)
brew install influxdb-cli

# Timestream for InfluxDBエンドポイントへの接続設定
influx config create \
  --config-name prod-timestream \
  --host-url https://<your-timestream-endpoint>:8086 \
  --org my-org \
  --token "<your-api-token>" \
  --active

# バケット作成(生データ用・30日保持)
influx bucket create \
  --name raw-metrics \
  --retention 30d \
  --org my-org

# 長期集計データ用バケット(365日保持)
influx bucket create \
  --name aggregated-metrics \
  --retention 365d \
  --org my-org

# Line Protocolファイルからのデータ書き込み
influx write \
  --bucket raw-metrics \
  --file /tmp/sensor_data.lp \
  --precision ns

# 単一レコードの直接書き込み
influx write \
  --bucket raw-metrics \
  --precision s \
  'cpu_usage,host=app-01,env=prod value=68.3'

InfluxDB 3 SQL クエリ

InfluxDB 3ではDataFusion(Rustベースのクエリエンジン)を採用し、InfluxQLに加えて標準SQLでのクエリが可能になりました。既存のBIツールやデータパイプラインとの統合が容易になっています。

-- 過去1時間のCPU使用率の5分平均(InfluxDB 3 SQL)
SELECT
  DATE_TRUNC('minute', time) AS window_start,
  host,
  AVG(value) AS avg_cpu
FROM cpu_usage
WHERE time >= NOW() - INTERVAL '1 hour'
  AND host = 'app-01'
GROUP BY DATE_TRUNC('minute', time), host
ORDER BY window_start;

# Python influxdb-client を使ったクエリ例
from influxdb_client import InfluxDBClient

with InfluxDBClient(
 url="https://<your-timestream-endpoint>:8086",
 token="<your-api-token>",
 org="my-org"
) as client:
 query_api = client.query_api()
 tables = query_api.query('''
  from(bucket: "raw-metrics")
 |> range(start: -1h)
 |> filter(fn: (r) => r["_measurement"] == "cpu_usage")
 |> filter(fn: (r) => r["host"] == "app-01")
 |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
 ''')
 for table in tables:
  for record in table.records:
print(record.get_time(), record.get_value())

ダウンサンプリングと長期データ管理

高頻度データ(秒単位)はストレージコストが膨大になるため、古いデータを粗い粒度に集約するダウンサンプリングが必須です。InfluxDBのTask機能を使って定期的な集計バケットへのデータ転送を自動化します。

# Flux タスクでダウンサンプリング設定
influx task create --name "downsample-cpu-5m" --every 1h --org my-org \
  --flux '
option task = {name: "downsample-cpu-5m", every: 1h}
from(bucket: "raw-metrics")
  |> range(start: -task.lastSuccessTime)
  |> filter(fn: (r) => r._measurement == "cpu_usage")
  |> aggregateWindow(every: 5m, fn: mean)
  |> to(bucket: "aggregated-metrics", org: "my-org")
'

InfluxDB 3のS3連携(Apache Arrow/Parquet形式)により、集計済みの古いデータをParquet形式でS3に保存し、クエリ時に必要なデータだけをロードするコールドストレージ戦略も利用できます。IoTセンサーデータのような数十億行規模のデータでも、S3連携でコストを大幅に抑えられます。

Telegraf との連携

本番環境では、InfluxDB公式のデータコレクターであるTelegrafを使ったデータ取り込みを推奨します。Telegrafは200以上のプラグインでCloudWatch・Kafka・JMX・SNMPなど多様なソースからメトリクスを収集し、Timestream for InfluxDBに書き込みます。

# telegraf.conf — Timestream for InfluxDB出力設定
[[outputs.influxdb_v2]]
  urls = ["https://<your-timestream-endpoint>:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "my-org"
  bucket = "raw-metrics"

[[inputs.cpu]]
  percpu = false
  totalcpu = true

[[inputs.cloudwatch]]
  region = "ap-northeast-1"
  namespace = "AWS/ECS"
  [[inputs.cloudwatch.metrics]]
 names = ["CPUUtilization", "MemoryUtilization"]
 [[inputs.cloudwatch.metrics.dimensions]]
name = "ClusterName"
value = "*"

Timestream for InfluxDB の主なユースケース

6. データベース選択マトリクスと移行パターン

6-1. データモデル別の選定マトリクス

AWSが提供するデータベースサービスは、データモデルとアクセスパターンで使い分けることが設計の基本です。リレーショナル・KVS・キャッシュ・分散SQL・グラフ・ドキュメント・ワイドカラム・時系列の8種類のモデルが存在し、それぞれに専用サービスが対応しています。

AWSデータベース全体マトリクス

データモデル別の選定指針

グラフデータ → Neptune: データが頂点(ノード)と辺(エッジ)の関係で構成され、「N ホップ先のノードを探索する」「影響範囲を連鎖追跡する」がメインのクエリであればNeptuneを選択します。RDSの再帰CTEやJOINでグラフを表現するのはアンチパターンです。SNSのフォロー/フォロワー・不正検知・ナレッジグラフが典型ユースケースです。

半構造化データ → DocumentDB: JSON/BSON形式でスキーマが可変の半構造化データを扱い、MongoDB互換ドライバを使いたい場合はDocumentDBを選択します。商品カタログ・CMS・ユーザープロファイルがマッチします。RDSでJSONBカラムを多用しているなら移行を検討してください。

大量書き込み・ワイドカラム → Keyspaces: IoTデバイスから毎秒数万TPSの書き込みが発生し、列ファミリー設計(Cassandraモデル)が適するならKeyspacesを選択します。結果整合性を受け入れられる書き込み優先系ワークロードに最適です。

時系列データ → Timestream for InfluxDB: タイムスタンプ付きメトリクス・センサーデータの時系列蓄積・ダウンサンプリング・集計が主要アクセスパターンであればTimestreamを選択します。RDSやDynamoDBで時系列データを扱うのはアンチパターンです。

コスト・運用比較

Data Governance との棲み分け

「どのDBに何のデータがあるか」「誰がどのデータにアクセスできるか」「データの流れ(系譜)を可視化したい」という要件は、データベース選定の問題ではなくデータガバナンスの問題です。AWSではAmazon DataZoneがデータカタログ・アクセス制御・データ系譜を統合的に管理します。複数のDBにまたがるデータ資産の管理・ポリシー適用については、Data Governance Vol1をご参照ください。

6-2. 既存データベースからの移行パターン

既存の自己管理型DBまたは他クラウドのDBをAWSマネージドサービスへ移行する際の主要パターンを解説します。

MongoDB → DocumentDB

MongoDB互換APIを持つDocumentDBへの移行は、アプリケーションのドライバ変更なしで行えるケースが多いです。ただしMongoDBとDocumentDBには機能差異があるため、事前に互換性チェックが必要です。

# mongodump でエクスポート(既存MongoDBから)
mongodump \
  --uri "mongodb://old-server:27017/mydb" \
  --out /tmp/mongo-dump

# TLSを有効にしてDocumentDBへmongorestore
mongorestore \
  --uri "mongodb://docdb-cluster.cluster-xxxx.ap-northeast-1.docdb.amazonaws.com:27017/mydb?tls=true&tlsCAFile=global-bundle.pem" \
  --ssl \
  /tmp/mongo-dump

DocumentDB 8.0はMongoDB 6.0/7.0/8.0からの移行に対応しており、トランザクション・text indexなど従来差異が大きかった機能のギャップが縮小されました。移行前にはAWS公式の互換性チェックスクリプトで非互換API呼び出しを洗い出します。

Apache Cassandra → Keyspaces

CQLスキーマはほぼそのまま再利用できますが、ローカルインデックスや一部のデータ型、Lightweight Transaction(LWT)の動作に差異があります。AWS SCT(Schema Conversion Tool)で事前に互換性を確認します。

# cqlsh で既存Cassandraのスキーマをエクスポート
cqlsh old-cassandra-host 9042 -e "DESCRIBE KEYSPACE mykeyspace;" > schema.cql

# Amazon Keyspacesへの接続(AWS認証・TLS必須)
# cassandra-sigv4 パッケージ経由のAWS認証を使用します
cqlsh cassandra.ap-northeast-1.amazonaws.com 9142 \
  --ssl \
  --auth-provider AmazonKeyspacesAuthProvider \
  -f schema.cql

Keyspacesはプロビジョンドとオンデマンドの2つの容量モードを提供しています。移行初期はオンデマンドモードで始め、トラフィックパターンが安定したらプロビジョンドに切り替えるのがコスト最適化の定石です。

自己管理型 InfluxDB → Timestream for InfluxDB

InfluxDB 2.x/3.xを自己管理している場合、Timestream for InfluxDBへの移行は最もシンプルなパスです。既存のLine ProtocolクライアントやTelegrafの設定は、エンドポイントを書き換えるだけで再利用できます。

# Telegraf設定(エンドポイントをTimestreamに切り替え)
[[outputs.influxdb_v2]]
  urls = ["https://<your-timestream-endpoint>:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "my-org"
  bucket = "metrics-bucket"

InfluxDB CLIのバックアップコマンドでデータをエクスポートし、新エンドポイントにリストアすることで過去データも移行できます。

移行時の共通ベストプラクティス

• Strangler Figパターン: 新旧DBを並行稼働させ、トラフィックを段階的に新DBへ切り替えます。ゼロダウンタイム移行の基本パターンです。
• データ検証: 移行後のレコード数・サンプルデータのサニティチェックを自動化し、移行漏れや変換ミスを検知します。
• ロールバック計画: 移行開始から24〜72時間は旧DBを保持し、異常が発生した場合に素早く切り戻せる状態を維持してください。
• 段階的移行: 全データを一括移行するのではなく、テーブル単位・バケット単位でフェーズを分け、フェーズごとにQCを実施します。

7. 実戦統合パターン — 用途特化DBの本番統合

用途特化データベース(Neptune/DocumentDB/Keyspaces/Timestream)は、単独で使うケースもありますが、既存のリレーショナルDBやKVSと組み合わせた複合アーキテクチャで最大の効果を発揮します。本セクションでは、本番環境でよく使われる複数DB併用パターン、生成AI連携、そして移行・運用の勘所を解説します。

7-1. 複数DB併用アーキと本番導入パターン

パターン1: Neptune + DynamoDB + S3 — レコメンデーションエンジン

ECサイトのレコメンデーションエンジンでは、グラフ・KVS・オブジェクトストレージの3層で役割を分担します。

graph LR
 User[ユーザー] --> API[API Gateway + Lambda]
 API --> Neptune[Neptune Analytics\nグラフ関係 + ベクトル検索]
 API --> DDB[DynamoDB\n商品/ユーザーデータ]
 API --> S3[S3\n画像/動画コンテンツ]
 Neptune -- 購買グラフ --> DDB
 Neptune -- KNN検索 --> Bedrock[Amazon Bedrock\n埋め込みモデル]
 Bedrock -- エンベディング --> Neptune

役割分担は次のとおりです。

• Neptune Analytics: ユーザー間・商品間の購買関係グラフを保持し、協調フィルタリングをグラフトラバーサルで実現します。Bedrock が生成したベクトルも格納して、セマンティックなアイテム類似検索も行います。
• DynamoDB: 商品マスタ・ユーザープロファイルなど、高速なKey-Valueアクセスが必要なデータを担います。GSI でカテゴリ・価格帯の絞り込みにも対応します。
• S3: 商品画像・動画などの大容量バイナリを格納します。Neptune や DynamoDB には S3 URI のみ保持するため、ストレージコストを最小化できます。

以下に AWS CDK (Python) でこのアーキテクチャを構築する例を示します。

from aws_cdk import (
 Stack,
 aws_neptune_alpha as neptune,
 aws_dynamodb as dynamodb,
 aws_s3 as s3,
 RemovalPolicy,
)
from constructs import Construct

class RecommendationStack(Stack):
 def __init__(self, scope: Construct, construct_id: str, **kwargs):
  super().__init__(scope, construct_id, **kwargs)

  # Neptune Serverless クラスター (自動スケール: 1〜32 NCU)
  neptune_cluster = neptune.DatabaseCluster(
self, "RecommendGraph",
vpc=vpc,
instance_type=neptune.InstanceType.SERVERLESS,
serverless_scaling_configuration=neptune.ServerlessScalingConfiguration(
 min_capacity=1,
 max_capacity=32,
),
  )

  # DynamoDB 商品テーブル (PAY_PER_REQUEST)
  product_table = dynamodb.Table(
self, "ProductTable",
table_name="products",
partition_key=dynamodb.Attribute(
 name="productId",
 type=dynamodb.AttributeType.STRING,
),
billing_mode=dynamodb.BillingMode.PAY_PER_REQUEST,
removal_policy=RemovalPolicy.RETAIN,
  )
  product_table.add_global_secondary_index(
index_name="category-price-index",
partition_key=dynamodb.Attribute(
 name="category",
 type=dynamodb.AttributeType.STRING,
),
sort_key=dynamodb.Attribute(
 name="price",
 type=dynamodb.AttributeType.NUMBER,
),
  )

  # S3 メディアバケット
  media_bucket = s3.Bucket(
self, "MediaBucket",
bucket_name=f"product-media-{self.account}",
block_public_access=s3.BlockPublicAccess.BLOCK_ALL,
removal_policy=RemovalPolicy.RETAIN,
  )

パターン2: DocumentDB + ElastiCache — コンテンツ管理

ニュースメディアやブログプラットフォームでは、DocumentDB に記事ドキュメントを格納し、ElastiCache (Redis) で読み取りキャッシュを構成するパターンが有効です。アクセスが集中する記事は Redis に TTL 付きでキャッシュして、DocumentDB への読み取り負荷を大幅に削減できます。

# CloudFormation: DocumentDB 8.0 + ElastiCache Redis
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  DocDBCluster:
 Type: AWS::DocDB::DBCluster
 Properties:
DBClusterIdentifier: content-docdb
MasterUsername: !Sub "{{resolve:ssm:/docdb/master-user}}"
MasterUserPassword: !Sub "{{resolve:ssm:/docdb/master-password:1}}"
EngineVersion: "8.0"
StorageEncrypted: true
EnableCloudwatchLogsExports:
  - profiler
  - audit
  ElastiCacheReplicationGroup:
 Type: AWS::ElastiCache::ReplicationGroup
 Properties:
ReplicationGroupDescription: content-cache-redis
AutomaticFailoverEnabled: true
NumCacheClusters: 2
CacheNodeType: cache.r7g.large
Engine: redis
EngineVersion: "7.1"
AtRestEncryptionEnabled: true
TransitEncryptionEnabled: true

パターン3: Keyspaces + Timestream for InfluxDB — IoT データ基盤

IoT センサーデータの基盤では、Keyspaces にデバイス設定・イベント履歴(ワイドカラム)を格納し、Timestream for InfluxDB にセンサー計測値の時系列データを格納します。ワイドカラムのパーティション設計でデバイスID単位の高速アクセスを実現しつつ、時系列クエリは InfluxDB 3 の Apache Arrow エンジンでシングルミリ秒応答を達成します。Keyspaces では最新状態のルックアップを担当し、Timestream for InfluxDB では過去データの時系列集計と異常検知を担当させると、それぞれの強みを活かした設計になります。

7-2. 生成AI連携 — Neptune ベクトル検索と GraphRAG

Neptune Analytics はベクトル検索(最大65,000次元)とグラフ分析を統合しており、生成AI連携で強力なRAGパターンを実現します。エンティティ間の関係性(グラフ)とセマンティック類似性(ベクトル)を組み合わせることで、従来のベクトル検索単体より高精度な情報検索が可能です。

Neptune ベクトル検索 + Bedrock 連携

Bedrock の埋め込みモデル(Amazon Titan Embeddings v2)でテキストをベクトル化し、Neptune Analytics に格納することで、グラフ構造とセマンティック検索を組み合わせた高精度なレコメンデーションや知識グラフ検索を実現します。

import boto3
import json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
neptune_client = boto3.client("neptune-graph", region_name="us-east-1")

def embed_and_store(graph_id: str, node_id: str, text: str) -> None:
 response = bedrock.invoke_model(
  modelId="amazon.titan-embed-text-v2:0",
  body=json.dumps({"inputText": text}),
 )
 embedding = json.loads(response["body"].read())["embedding"]

 query = """
 MATCH (n {nodeId: $nodeId})
 CALL neptune.algo.vectors.upsert(n, $embedding)
 YIELD success
 RETURN success
 """
 neptune_client.execute_query(
  graphIdentifier=graph_id,
  queryString=query,
  parameters={"nodeId": node_id, "embedding": embedding},
  language="OPEN_CYPHER",
 )

def semantic_search(graph_id: str, query_text: str, top_k: int = 10) -> dict:
 response = bedrock.invoke_model(
  modelId="amazon.titan-embed-text-v2:0",
  body=json.dumps({"inputText": query_text}),
 )
 query_embedding = json.loads(response["body"].read())["embedding"]

 search_query = """
 CALL neptune.algo.vectors.topKByEmbedding(
  $queryEmbedding,
  {topK: $topK, concurrency: 4}
 )
 YIELD node, score
 RETURN node.nodeId AS nodeId, node.title AS title, score
 ORDER BY score DESC
 """
 return neptune_client.execute_query(
  graphIdentifier=graph_id,
  queryString=search_query,
  parameters={"queryEmbedding": query_embedding, "topK": top_k},
  language="OPEN_CYPHER",
 )

GraphRAG ツールキット

AWS GraphRAG ツールキット (2025-01 GA) を使うと、Neptune Analytics のグラフデータを RAG ソースとして Bedrock エージェントに接続できます。エンティティ間の関係を活かすことで、ベクトル検索単体よりも文脈を正確に理解した回答生成が可能です。GraphRAG はグラフのホップをたどって関連ノードを収集してから LLM に渡すため、単純なベクトル類似検索では見落とすコンテキストを補完できます。社内ドキュメントや製品情報を GraphRAG で活用することで、カスタマーサポートや社内検索の精度を大幅に向上できます。

7-3. 移行・運用の勘所

MongoDB → DocumentDB 移行

MongoDB からの移行では、AWS Database Migration Service (DMS) が公式サポートされています。事前に互換性マトリクス(MongoDB バージョン vs DocumentDB バージョン)を確認し、非互換オペレーターを使っているコードを洗い出してから進めます。DocumentDB 8.0 では MongoDB 6.0/7.0/8.0 からの移行が可能になり、対応範囲が大きく拡大しました。

#!/bin/bash
MONGO_URI="mongodb://your-mongo-host:27017"
SOURCE_ENDPOINT_ARN="arn:aws:dms:us-east-1:123456789012:endpoint:source"
TARGET_ENDPOINT_ARN="arn:aws:dms:us-east-1:123456789012:endpoint:target"

mongosh "$MONGO_URI" --eval \
 'db.adminCommand({listDatabases: 1}).databases.forEach(function(d) {
  print("DB:", d.name)
 })' --quiet

aws dms create-replication-task \
 --replication-task-identifier mongo-to-docdb \
 --source-endpoint-arn "$SOURCE_ENDPOINT_ARN" \
 --target-endpoint-arn "$TARGET_ENDPOINT_ARN" \
 --migration-type full-load-and-cdc \
 --table-mappings '{
  "rules": [{
"rule-type": "selection",
"rule-id": "1",
"rule-name": "select-all",
"object-locator": {"schema-name": "%", "table-name": "%"},
"rule-action": "include"
  }]
 }'

Cassandra → Keyspaces 移行

Apache Cassandra からの移行は、Cassandra Data Migrator (CDM) ツールを使います。CQL スキーマはほぼそのまま移行できますが、Cassandra 固有の User-Defined Functions (UDF) や、Keyspaces でサポートされていない機能は事前に代替実装を検討します。Multi-Region Replication を活用する場合は、移行先のリージョン構成も合わせて設計します。

#!/bin/bash
CASSANDRA_HOST="your-cassandra-host"
KEYSPACES_HOST="cassandra.us-east-1.amazonaws.com"

cqlsh "$CASSANDRA_HOST" \
 -e "DESCRIBE KEYSPACE your_keyspace;" > schema_export.cql

cqlsh "$KEYSPACES_HOST" 9142 \
 --ssl \
 -u "ServiceUserName" \
 -p "ServiceUserPassword" \
 -f schema_export.cql

java -jar cassandra-data-migrator.jar \
 --source-host "$CASSANDRA_HOST" \
 --target-host "$KEYSPACES_HOST" \
 --source-keyspace your_keyspace \
 --target-keyspace your_keyspace \
 --batch-size 500 \
 --consistency-level LOCAL_QUORUM

8. 詰まりポイント・アンチパターン・まとめ

用途特化データベースは機能が多彩な分、設計・運用で詰まりやすい箇所も多いです。実際の本番運用で繰り返し遭遇する詰まりポイントとアンチパターンを整理します。

8-1. 詰まりポイント

詰まり1: Neptune Serverless の NCU が急増してコストが跳ね上がる

Neptune Serverless は負荷に応じて自動スケールしますが、デフォルト設定で max_capacity を高く設定すると、想定外のグラフトラバーサルや集計クエリで Neptune Capacity Units (NCU) が急増することがあります。対策として、CloudWatch の ServerlessDatabaseCapacity メトリクスを監視し、開発環境では max_capacity を小さく(例: 4 NCU)に制限します。本番環境では段階的に上限を引き上げながら負荷テストを行い、適切な上限値を決定します。Neptune クエリプロファイラーを有効にして、スキャン範囲が広いクエリを特定して最適化します。スコープを絞り込んだトラバーサル(インデックス活用・limit 付き)に書き直すだけで NCU 消費量が数十倍改善するケースもあります。

詰まり2: DocumentDB と MongoDB の互換性ギャップが本番リリース直前に発覚する

DocumentDB は MongoDB 互換を謳いますが、全オペレーターを網羅しているわけではありません。例えば $lookup の外部パイプライン構文、$unionWith、$out の S3 への書き込みは非対応の場合があります。移行前に AWS 公式の互換マトリクスを必ず確認し、非互換部分はアプリ側の集計処理や Lambda 関数に置き換えます。DocumentDB 8.0 では MongoDB 6.0/7.0/8.0 からの移行対応が追加されましたが、移行元バージョンとのギャップを表で整理してから移行計画を立てることが重要です。テスト環境で全クエリを実行して動作確認してから本番移行に進むことを強く推奨します。

詰まり3: Keyspaces のデフォルト読み取り整合性で古いデータが返ってくる

Amazon Keyspaces はデフォルトの読み取り整合性が LOCAL_ONE (結果整合性) です。書き込み直後のデータを必ず最新で読みたい場合は、読み取り時に SERIAL 一貫性レベルを指定しますが、レイテンシの増加というトレードオフがあります。ユーザー設定変更・在庫更新など正確性が重要なクリティカルパスでは SERIAL を使い、その他のユースケースでは LOCAL_ONE のまま高スループットを維持するという使い分けが重要です。設計段階でアクセスパターンごとに必要な整合性レベルを明示しておくことで、後からの変更コストを減らせます。

詰まり4: Timestream for LiveAnalytics を 2025-06-20 以降に新規で申し込もうとしてエラーになる

Amazon Timestream for LiveAnalytics は 2025-06-20 以降、新規顧客の受付を終了しています。コンソールで LiveAnalytics を選択しても申し込みできなくなっています。古いドキュメントや書籍に LiveAnalytics が記載されていても、新規採用は不可です。新規の時系列ワークロードには必ず Timestream for InfluxDB を選択してください。既存顧客は継続利用できますが、AWS から Timestream for InfluxDB への移行ツールが提供されているため、早期移行を検討することを推奨します。InfluxDB 3 (2025-10 対応) では Apache Arrow / DataFusion エンジンによりクエリ性能が大幅に向上しています。

詰まり5: Keyspaces のパーティション設計ミスでホットパーティションが発生する

Keyspaces (Cassandra 互換) では、パーティションキーに偏りがあると特定のパーティションにアクセスが集中し、スロットリングが発生します。例えば status や type のような低カーディナリティの列をパーティションキーにすると、数パターンのパーティションに全書き込みが集中します。パーティションキーには高カーディナリティの列(ユーザーID、デバイスIDなど)を選び、必要に応じてバケットハッシュでデータを均一に分散させます。設計前にアクセスパターンと書き込み分布を分析することが根本的な対策です。

詰まり6: Neptune ベクトル検索の次元数設計を誤る

Neptune Analytics のベクトル検索がサポートする最大次元数は 65,000 です。最新の大規模言語モデルのエンベディング次元数はこの上限を超えるケースはほとんどありませんが、次元数が大きくなるほどインデックス作成時間とメモリ使用量が増加します。実用上は 1,536 次元 (Titan Embeddings v2) や 3,072 次元 (Claude系) など、ユースケースに見合った次元数のモデルを選択します。ベクトルを格納するノード数が増えるにつれて KNN 検索の応答時間が増加するため、Neptune Analytics のキャパシティを適切に設定し、インデックス作成が完了しているかを確認してからベンチマークを行います。

詰まり7: DocumentDB Elastic Clusters の start/stop で接続プールが切断される

DocumentDB Elastic Clusters は start/stop 操作をサポートしており、開発環境のコスト削減に便利です。ただし、stop 後に start した際、アプリケーションの接続プールが古い接続を保持したまま再利用しようとして接続エラーを起こすことがあります。対策として、接続プールライブラリに KeepAlive と自動再接続を設定し、接続エラー発生時にプールを再初期化するリトライロジックを実装します。本番環境では start/stop を使わず常時稼働させます。また Elastic Clusters は Standard Clusters とは互換性が一部異なる(MongoDB 5.0 wire protocol ベース)ため、アプリ側の MongoDB ドライババージョンを適合させます。

詰まり8: Timestream for InfluxDB の InfluxDB 2.7 と InfluxDB 3 の差異を無視した実装をする

Timestream for InfluxDB は InfluxDB 2.7 と InfluxDB 3 の両方をサポートしていますが、クエリ言語と API が大きく異なります。InfluxDB 2.7 は Flux クエリ言語、InfluxDB 3 は SQL / InfluxQL をサポートします。InfluxDB 3 では Apache Arrow / DataFusion エンジンが採用されており、InfluxDB 2.7 のコードをそのまま流用するとクエリが動作しません。新規実装では InfluxDB 3 を選択し、SQL インターフェースで実装することを強く推奨します。既存の Flux クエリは SQL へ段階的に移行する計画を立てます。

詰まり9: Neptune でグラフ探索クエリが全件スキャンになってタイムアウトする

Gremlin や openCypher でグラフを探索する際、起点ノードの絞り込みや探索深度の制限を設定しないと、グラフ全体を走査する全件スキャンになってタイムアウトが発生します。g.V().out().out().values('name') のような無制限トラバーサルは危険です。g.V().hasLabel('User').has('userId', 'u123').out('purchased').limit(100).values('productName') のように、開始頂点の絞り込みフィルタ・探索深度制限・limit() を組み合わせることで効率的なクエリになります。Neptune クエリの実行計画は explain() や profile() ステップで確認できます。

8-2. アンチパターン → 正解変換

アンチパターン1: リレーショナルDBでグラフ関係を無理に表現する

関係性を自己結合テーブル (例: user_id, friend_id) で表現し、フォロワーを5ホップ辿るような再帰クエリを書いてしまうパターンです。RDS では N 次関係の探索は JOIN が指数的に増加し、実用的なレスポンスタイムを得られません。クエリが複雑化するにつれてメンテナンスコストも増大します。

正解: データモデルをグラフ構造で考え直し、Neptune に移行します。頂点と辺の関係性を自然に表現でき、10ホップ以上の深いトラバーサルも数ミリ秒で実行できます。フォロワー関係、不正検知の関係グラフ、製品の部品構成(BOM)などが代表的な Neptune への移行候補です。

アンチパターン2: 時系列データを RDS のタイムスタンプ付きテーブルに蓄積する

IoT センサーや APM ログなどの時系列データを RDS の単一テーブルに蓄積し、パーティショニングで対処しようとするパターンです。データ量が増えると書き込みスループットが低下し、時系列集計クエリも遅くなります。

正解: Timestream for InfluxDB を採用します。時系列データに最適化された Line Protocol でのデータ取り込み、InfluxDB 3 の Apache Arrow エンジンによる高速集計クエリ、データライフサイクル管理(ホットストレージ/コールドストレージ自動移行)を標準で提供します。

アンチパターン3: Timestream LiveAnalytics を前提に新規システムを設計する

2025-06-20 以降、Timestream for LiveAnalytics は新規顧客の受付を終了しています。にもかかわらず、古いドキュメントや書籍を参照して LiveAnalytics を前提とした設計をするパターンが見られます。コンソールで申し込もうとしてエラーになったり、API が呼べなかったりと、実装フェーズで初めて問題に気付くケースが多いです。

正解: 新規の時系列ワークロードは全て Timestream for InfluxDB を採用します。InfluxDB 3 エンジンは LiveAnalytics より高いクエリ性能を持ち、オープンソース InfluxDB との高い互換性も利点です。

アンチパターン4: Keyspaces でセカンダリインデックスを多用して高速化しようとする

RDB の思考で「条件に合わせてインデックスを増やせばクエリが速くなる」と考え、Keyspaces のテーブルに多数のセカンダリインデックスを定義してしまうパターンです。Keyspaces のセカンダリインデックスはパフォーマンスオーバーヘッドが大きく、多用すると書き込み性能が著しく低下します。さらに、セカンダリインデックスへのクエリは全パーティションにブロードキャストされるため、データ量が増えると検索速度も低下します。

正解: Cassandra / Keyspaces では「クエリ駆動設計」が基本です。先にアクセスパターン(どのような WHERE 条件でクエリするか)を確定させてから、そのパターンに最適化したパーティションキーとソートキーを持つテーブルを設計します。クエリパターンごとに専用テーブルを用意する「テーブルの非正規化」が Keyspaces では正解です。

アンチパターン5: DocumentDB に MongoDB のコードをそのまま移植して完全動作すると思い込む

MongoDB ドライバとの接続互換性は高いですが、アプリ実装が MongoDB 固有の集計演算子や Change Streams の全機能を使っている場合、移行後にエラーが発生します。特に $lookup の外部パイプライン、$unionWith、カーソルへの allowDiskUse 等は DocumentDB バージョンによって対応状況が異なります。移行テストを省略して本番移行すると、リリース後の障害につながります。

正解: 移行前に AWS の公式互換マトリクスと自社コードベースの MongoDB 機能使用状況を突き合わせた「互換性棚卸しシート」を作成します。非互換箇所はアプリ側での代替実装または DocumentDB 8.0 へのアップグレードで対応します。全クエリを DocumentDB テスト環境で実行して動作確認してから本番移行に進みます。

アンチパターン6: Neptune を RDB の代替として全データを格納してしまう

グラフDBが注目されているからといって、本来リレーショナルで表現すべきデータ(売上トランザクション、在庫管理、マスタデータなど)を Neptune に格納してしまうパターンです。グラフの利点が活かせないうえに、集計クエリや JOIN がグラフトラバーサルより非効率になります。

正解: Neptune を選ぶ判断軸は「エンティティ間の多対多の関係性を辿るクエリが中心か」です。フォロワー・フォロー、不正検知の関係グラフ、ナレッジグラフ、レコメンデーションエンジンなど、関係性の探索が核心となるユースケースに適しています。トランザクションや集計が中心なら RDS/Aurora を継続します。

8-3. 監視と運用ポイント

用途特化データベースを本番で安定稼働させるには、DB固有の監視メトリクスと運用ポイントを押さえておくことが重要です。

Neptune の監視

Neptune は CloudWatch で以下のメトリクスを重点監視します。

• ServerlessDatabaseCapacity: Neptune Serverless の現在NCU数。max_capacity の 80% を超えたらアラートを設定します。
• GremlinRequestsPerSec / openCypherRequestsPerSec: クエリスループット。急増は意図しない全件スキャンのシグナルです。
• MainRequestLatency: クエリレイテンシ。99パーセンタイルが 1 秒を超えたらクエリチューニングを検討します。
• BufferCacheHitRatio: ページキャッシュヒット率。90% を下回る場合はインスタンスタイプのアップグレードを検討します。

Neptune のバックアップは自動スナップショット(保持期間 1〜35 日)とポイントインタイムリカバリ(PITR)で管理します。本番環境では保持期間を 7 日以上に設定します。

DocumentDB の監視

• DatabaseConnections: 接続数。接続プールの最大値に近づいたら接続プールの設定を調整します。
• BufferCacheHitRatio: バッファキャッシュヒット率。90% 未満はメモリ不足のサインです。
• Throughput / ReadLatency / WriteLatency: IO スループットとレイテンシ。I/O 集約型ワークロードでは I/O-Optimized ストレージへの切り替えを検討します。
• OpcountersInsert / OpcountersUpdate / OpcountersDelete: CRUD オペレーションカウント。急増するオペレーションタイプを特定してインデックス最適化に役立てます。

DocumentDB プロファイラーを有効にして、スロークエリ(デフォルト: 100ms以上)をログに記録します。

# DocumentDB スロークエリログの有効化 (AWS CLI)
aws docdb modify-db-cluster-parameter-group  --db-cluster-parameter-group-name my-docdb-params  --parameters ParameterName=profiler,ParameterValue=enabled,ApplyMethod=immediateParameterName=profiler_threshold_ms,ParameterValue=100,ApplyMethod=immediate

Keyspaces の監視

• SystemErrors: スロットリングエラー数。急増時はキャパシティの見直しまたはオンデマンドモードへの切り替えを行います。
• ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits: 消費RCU/WCU。プロビジョンドモードでは設定値の 80% を超えたら増量します。
• ReadThrottleEvents / WriteThrottleEvents: スロットリング発生件数。特定のパーティションキーへのアクセス偏りがあればパーティション設計を見直します。

Keyspaces はフルマネージドのため、インスタンス管理は不要です。ただし、テーブル単位のキャパシティ設定とパーティション設計が運用品質を大きく左右します。Multi-Region Replication を使用している場合は、レプリケーション遅延もモニタリングします。

Timestream for InfluxDB の監視

• インスタンスの CPU/メモリ使用率: CloudWatch コンソールまたは CLI でメトリクスを監視します。
• InfluxDB 組み込みダッシュボード: InfluxDB 3 には Web UI が付属しており、クエリレイテンシ・書き込みスループット・ストレージ使用量をリアルタイムで確認できます。
• データ保持ポリシー: retention period を設定してホットストレージのコストを管理します。コールドデータは S3 に自動アーカイブされます。

# Timestream for InfluxDB インスタンスへの接続確認
aws timestream-influxdb list-db-instances --region us-east-1

# インスタンス状態の確認
aws timestream-influxdb get-db-instance  --identifier my-influxdb-instance  --region us-east-1  --query 'dbInstanceType,status,endpoint'

CloudWatch アラーム設定例

各データベースにアラームを設定し、SNS トピックと連携して担当チームへ自動通知します。閾値超過時に Systems Manager OpsCenter へのインシデント作成も自動化できます。

# Neptune Serverless — キャパシティ監視アラーム(max_capacity の 80% で発火)
aws cloudwatch put-metric-alarm \
  --alarm-name neptune-capacity-high \
  --metric-name ServerlessDatabaseCapacity \
  --namespace AWS/Neptune \
  --comparison-operator GreaterThanThreshold \
  --threshold 24 \
  --evaluation-periods 2 \
  --period 60 \
  --statistic Average \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:ops-alert" \
  --dimensions Name=DBClusterIdentifier,Value=my-serverless-graph

# Keyspaces — 書き込みスロットリング監視アラーム(1件以上でアラート)
aws cloudwatch put-metric-alarm \
  --alarm-name keyspaces-write-throttle \
  --metric-name WriteThrottleEvents \
  --namespace AWS/Cassandra \
  --comparison-operator GreaterThanThreshold \
  --threshold 0 \
  --evaluation-periods 1 \
  --period 60 \
  --statistic Sum \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:ops-alert" \
  --dimensions Name=TableName,Value=device_events

# DocumentDB — バッファキャッシュヒット率監視(90% 未満でアラート)
aws cloudwatch put-metric-alarm \
  --alarm-name docdb-cache-hit-low \
  --metric-name BufferCacheHitRatio \
  --namespace AWS/DocDB \
  --comparison-operator LessThanThreshold \
  --threshold 90 \
  --evaluation-periods 3 \
  --period 300 \
  --statistic Average \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:ops-alert" \
  --dimensions Name=DBClusterIdentifier,Value=content-docdb

アラームの設計は「警告 → 対応アクション」の対応表を事前に整備しておくと、インシデント対応時の判断が迷わずに済みます。Neptune の場合は NCU 増加への対処方法(クエリ最適化か max_capacity 引き上げか)を、Keyspaces の場合はスロットリングへの対処方法(キャパシティ増量かパーティション設計見直しか)を判断する基準を運用手順書に記載しておくことを推奨します。

コスト最適化のポイント

• Neptune: Serverless を活用し、ピーク外の時間帯は NCU を自動縮小させます。長期間使用しないグラフは別途バックアップしてから削除します。
• DocumentDB: Elastic Clusters の start/stop で開発環境コストを削減します。本番は RI (Reserved Instance) で最大 60% 削減できます。
• Keyspaces: アクセスパターンが安定したらオンデマンドからプロビジョンドに切り替えて節約します。Auto Scaling を有効にして需要変動に自動対応します。
• Timestream for InfluxDB: インスタンスは稼働時間課金です。本番以外では必要なときだけ起動してコストを削減します。

8-4. まとめ

本記事では、AWS の用途特化データベース 4 種(Neptune/DocumentDB/Keyspaces/Timestream)の特性と本番設計を解説しました。各データベースの特性をまとめます。

• Amazon Neptune: グラフデータベース。フォロワー関係・不正検知・レコメンデーションなど、エンティティ間の関係性探索に最適です。Neptune Analytics のベクトル検索と GraphRAG で生成AI連携も実現でき、Neptune Serverless で自動スケールして最大90%のコスト削減が可能です。
• Amazon DocumentDB: MongoDB 互換ドキュメントDB。スキーマレスな JSON ドキュメントを高速に読み書きしたいユースケース向けです。DocumentDB 8.0 で MongoDB 8.0 互換が拡大し、Elastic Clusters でシャーディングによる大規模対応も可能です。
• Amazon Keyspaces: Apache Cassandra 互換のワイドカラムDB。大量書き込みが必要な IoT/時系列ログ・ユーザー行動履歴などで高スループットを発揮します。Serverless と Multi-Region Replication による active-active 構成に対応します。
• Amazon Timestream for InfluxDB: InfluxDB マネージドサービス。IoT センサーデータ・APM メトリクスなど時系列データの取り込みと高速集計に特化しています。InfluxDB 3 の Apache Arrow / DataFusion エンジンでシングルミリ秒クエリを実現します。なお Timestream for LiveAnalytics は 2025-06-20 以降、新規顧客の受付を終了していますので、新規採用時は for InfluxDB を選択してください。

用途特化データベースを選ぶ判断軸は「データモデル」と「アクセスパターン」です。グラフ関係を辿るなら Neptune、JSON ドキュメントを柔軟に扱うなら DocumentDB、大量書き込みのワイドカラムなら Keyspaces、時系列集計なら Timestream for InfluxDB を選択します。既存のリレーショナルDB・KVS と組み合わせた複合アーキテクチャを採用することで、各データベースの強みを最大化できます。

Vol1-4 で解説したリレーショナル/移行/キャッシュ/分散SQL と、本 Vol5 の用途特化DBを組み合わせることで、AWS のデータベースサービス全体を俯瞰したシステム設計が可能になります。

基礎編：Database Vol1(RDS×Aurora×DynamoDB)を読む
移行・レプリカ編：Database Vol2(DMS×Aurora Global)を読む
キャッシュ編：Database Vol3(ElastiCache×DAX×MemoryDB)を読む
分散SQL編：Database Vol4(Aurora DSQL×Limitless)を読む