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
関連サービス・比較
| 観点 | Neptune | DynamoDB |
|---|---|---|
| データモデル | グラフ(ノードと関係) | 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。