TL

Cloud Service

Amazon Neptune

プロパティグラフとRDFに対応したフルマネージドなグラフDB。関係をたどる問い合わせを高速に処理する。

中級SAA-C03パフォーマンス効率
最終更新: 2026-06-13公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.ノードとエッジで関係を表現し、つながりをたどる検索が得意なグラフDB。
  • 2.プロパティグラフとRDFの両方に対応し、運用はフルマネージド。
  • 3.計算とストレージを分離し、マルチAZ複製とリードレプリカで拡張する。

解決する課題

  • レコメンドやSNSのように、データ同士のつながりをたどる検索を高速に行いたい
  • リレーショナルDBでは多段のJOINが増えて遅くなる関係データを扱いたい
  • 不正検知やナレッジグラフなど、経路探索や関連性分析を運用負担なく実現したい

主要概念と用語

  • グラフデータベース: データを点(ノード/頂点)と線(エッジ/関係)で表現し、つながりをたどって問い合わせるDB
  • プロパティグラフ: ノードとエッジに属性(プロパティ)を持たせるモデル。クエリ言語はGremlinやopenCypher
  • RDF: 主語・述語・目的語の三つ組(トリプル)で事実を表す標準モデル。クエリ言語はSPARQL
  • Gremlin / openCypher / SPARQL: それぞれのモデルに対応するグラフ用クエリ言語
  • クラスター: ライター(書き込み用プライマリ)とリーダー(読み取り用レプリカ)、共有ストレージで構成される単位
  • エンドポイント: 書き込み用のクラスターエンドポイントと、読み取り分散用のリーダーエンドポイント
  • Neptune Serverless: 負荷に応じて容量を自動で増減するモード
  • Neptune Analytics: 大規模なグラフ分析を高速に実行するための分析向け機能

仕様・制限・クォータ

  • 1つのクラスターはプロパティグラフかRDFのどちらかを主に扱う(Gremlin/openCypherはプロパティグラフ、SPARQLはRDF)
  • ストレージは利用量に応じて自動拡張し、複数のアベイラビリティゾーンへ自動複製される
  • 読み取りスケール用にリードレプリカを複数追加でき、レプリカはフェイルオーバー先にもなる
  • 具体的なレプリカ上限やストレージ上限などの数値は変動するため、最新値は公式ドキュメントで確認する

内部の仕組み

Neptuneはストレージ層を計算ノードから分離した構成を採り、書き込みデータを複数のアベイラビリティゾーンへ自動複製して耐久性を高めます。リーダー(レプリカ)はライターと同じ共有ストレージを参照するため、レプリケーション遅延が小さい状態で読み取りを分散できます。ライターに障害が起きた場合はレプリカが昇格してフェイルオーバーします。クエリは指定したノードを起点に、関係をたどって近傍やパスを探索する処理に最適化されており、リレーショナルDBで多段JOINになるような問い合わせを効率良く実行できます。

モデルの選び方

プロパティグラフ(Gremlin/openCypher)はアプリ開発で扱いやすく、RDF(SPARQL)は標準語彙やオントロジーを使うナレッジグラフ向け。先に必要なクエリ言語を決めてからモデルを選ぶと迷いません。

設計パターン / ベストプラクティス

  • レコメンド、ソーシャルグラフ、不正検知、ナレッジグラフなど関係探索が中心の用途で採用する
  • 読み取りが多い場合はリーダーエンドポイント経由でレプリカに分散する
  • 負荷の変動が大きく予測しにくい場合はServerlessで容量を自動調整する
  • 大量データの初期投入は1件ずつ書くのではなく、まとめて取り込むバルクローダーを使う
  • アプリ側は個別インスタンスではなくエンドポイントへ接続し、フェイルオーバーを吸収する

運用・監視

  • CloudWatchでCPU使用率、メモリ、接続数、レプリカの遅延などを監視する
  • 自動バックアップとスナップショットで復旧点を確保し、ポイントインタイムリカバリで任意時点へ戻す
  • 遅いクエリはクエリ内容やインデックス対象の見直しで改善し、読み取り過多はレプリカ追加で緩和する
  • メンテナンスやフェイルオーバー時はエンドポイント経由の接続なら自動で切り替わる

コスト

  • 主なコストはインスタンスの稼働時間、消費したストレージとI/O、バックアップストレージ、データ転送
  • 定常的な負荷ではプロビジョンドインスタンス、変動が大きい負荷ではServerlessが有利になりやすい
  • 不要なリードレプリカを減らす、開発環境は停止するなどで最適化する
  • 料金は変動するため、最新の単価は公式の料金ページで確認する

セキュリティ

  • クラスターはVPC内に配置し、プライベートサブネットからのアクセスに限定する
  • 保存データはKMSで暗号化でき、通信はTLSで保護する
  • 認証・認可はIAMで制御し、最小権限の原則に従ってアクセスを付与する
  • セキュリティグループでネットワーク到達範囲を絞り込む

Well-Architected の観点

  • パフォーマンス効率: 関係探索に特化したエンジンとリードレプリカで、つながりをたどる検索を高速かつスケーラブルに処理する
  • 信頼性: マルチAZ自動複製と自動フェイルオーバーで可用性を確保する
  • コスト最適化: Serverlessや適切なレプリカ数で需要に合わせて費用を調整する

試験で問われるポイント

頻出
  • 関係(つながり)をたどる検索が中心ならグラフDB=Neptuneを選ぶ
  • プロパティグラフはGremlin/openCypher、RDFはSPARQL
  • リレーショナルDBの多段JOINが遅い関係データの置き換え先として問われる
  • 読み取りスケールはリードレプリカ+リーダーエンドポイント、変動負荷はServerless

関連サービス・比較

観点NeptuneDynamoDB
データモデルグラフ(ノードと関係)NoSQL(キーバリュー/ドキュメント)
得意な検索つながりをたどる関係探索キーによる高速な取得
クエリ言語Gremlin/openCypher/SPARQL独自API(キー中心)
主な用途レコメンド・不正検知・ナレッジグラフ高スループットなキーバリュー処理

ハンズオン / CLI例

# Neptuneクラスターを作成(ライターとなるDBクラスター)
aws neptune create-db-cluster \
  --db-cluster-identifier app-graph \
  --engine neptune \
  --storage-encrypted

# クラスターにライター用インスタンスを追加
aws neptune create-db-instance \
  --db-instance-identifier app-graph-1 \
  --db-cluster-identifier app-graph \
  --engine neptune \
  --db-instance-class db.r6g.large

# 読み取りスケール用にリードレプリカを追加
aws neptune create-db-instance \
  --db-instance-identifier app-graph-2 \
  --db-cluster-identifier app-graph \
  --engine neptune \
  --db-instance-class db.r6g.large

AWS Service

Amazon Neptuneを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

データベース

比較で見る軸

クラウド: AWS / カテゴリ: データベース / 難易度: intermediate

導入後に効く点

プロパティグラフとRDFの両方に対応し、運用はフルマネージド。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
AWS
カテゴリ
データベース
難易度
intermediate
関連資格
SAA-C03
設計柱
performance

判断チェックリスト

  • 自社の用途が「データベース / performance」に近いか確認する。
  • 強みである「ノードとエッジで関係を表現し、つながりをたどる検索が得意なグラフDB。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

データベースperformanceSAA-C03