翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

コスト最適化の柱

AWS Well-Architected フレームワークのコスト最適化の柱は、不要なコストを回避することに重点を置いています。以下の推奨事項は、コスト最適化の設計原則とアーキテクチャのベストプラクティスを Amazon Neptune に実行するのに役立ちます。

コスト最適化の柱は、次の主要分野に焦点を当てています。

必要な使用状況パターンとサービスの理解

データモデルに識別可能なグラフ構造があり、クエリで関係を調べて複数のホップを通過する必要がある場合、Neptune はワークロードに適しています。グラフデータベースは、次のパターンには適していません。

特定のアクセスパターンに複数の目的別データベースを一緒に使用することで、すべてのニーズに対応できるかどうかを検討してください。例えば、次のようになります。

Neptune とやり取りするサービスや Neptune を補完するサービスに付随する以下のようなコストを把握してください。

コストに注意してリソースを選択する

Neptune の料金は、時間単位のインスタンスコスト (またはサーバーレスに消費される Neptune Compute Units)、データ I/O、ストレージ使用量に基づいています。インスタンスは平均してコスト全体の 85% を占めるため、適切なサイズを選ぶことがコストに大きな影響を与える可能性があります。インスタンスのサイズを適正化する最善の方法は、さまざまなインスタンスでアプリケーションのパフォーマンスをテストし、次の要因を比較することです。

インスタンスコストは、同じインスタンスファミリー内のサイズに応じて直線的にスケーリングされます。db.r6i.2xlarge インスタンスの時間単位のコストは db.r6i.xlarge インスタンスの 2 倍で、リソース割り当ても 2 倍です。db.r6i.24xlarge インスタンスは、db.r6i.xlarge インスタンスの時間単位のコストの 24 倍です。

サポートする必要がある同時クエリの数を見積もります。読み取り専用クエリを処理するために、0～15 個のリードレプリカを持つことができます。要件が時間帯、週、または月によって異なる場合は、複数の小さなインスタンスを使用してスケジュールに基づいてスケーリングできます。インスタンスの各 vCPU には、同時クエリを処理するための 2 つのスレッドが用意されています。それぞれ 4 つの vCPU を持つ 3 つの db.r6i.xlarge リードレプリカは、24 個の同時クエリを処理できます。

そうではなく、トラフィック量が 1 秒あたりのクエリ数 (QPS) で測定される場合は、実験でクエリの平均レイテンシーを決定する必要があります。Neptune クラスターがサポートできる 1 秒あたりのクエリ数は、vCPU × 2 × (1 second/average query latency) に等しくなります。例えば、4 つの vCPU があり、クエリレイテンシーが 100 ミリ秒 (0.1 秒) の場合、QPS = 4 × 2 × (1s/0.1s) = 80 queries per second となります。

プロビジョニングされたインスタンスは、継続的で安定した、予測可能なワークロードに対して、サーバーレスよりも安価です。サーバーレスは、1 日あたり数時間のみ非常に高い使用量を必要とするワークロード (db.r6i.4xlarge など) があり、残りの時間はほとんどトラフィックがない (1 Neptune Compute Unit など) 場合に、コスト最適化の機会が得られます。数時間スケールアップし、その後スケールダウンするサーバーレスインスタンスは、プロビジョニングされた db.r6i.4xlarge インスタンスを終日使用するよりも安価になります。

Neptune 1.4.5.0 以降にアップグレードし、 r8g インスタンスを使用して、 r7gや などの旧世代のインスタンスよりも低コストで読み取りと書き込みのスループットを向上させることを検討してくださいr6g。詳細については、Amazon Neptune v1.4.5 を使用した AWS Graviton4 R8g インスタンスでの書き込みクエリの料金パフォーマンスが 4.7 倍向上する」(AWS ブログ記事) を参照してください。

Neptune クラスターは、デフォルトで標準ストレージで作成されます (コンソールを使用して を作成すると、デフォルトで I/O 最適化ストレージが選択されます）。I/O 最適化ストレージでは、ストレージとインスタンスのコストがわずかに高くなりますが、I/O コストはありません。これにより、予測可能な経常コストが発生しますが、I/O 使用率が一般的に低い場合は、標準ストレージを利用する方がコスト効率が良い可能性があります。最初に大量のデータをロードする場合は、I/O 最適化ストレージを選択し、初期データロードを実行してから、標準ストレージに切り替えることでコストを最適化できます。ストレージタイプは請求モデルにのみ影響し、Neptune DB クラスターまたはインスタンス設定に技術的な違いはありません。ストレージタイプは 30 日に 1 回変更できます。30 日後、詳細な Neptune コストを確認し、Neptune 料金ページを使用して、I/O 最適化ストレージを使用してコストが高くなったかどうかを計算します。そうであれば、引き続き標準ストレージを使用し、そうでない場合は I/O 最適化に切り替えます。

ワークロードに最適な Neptune インスタンス設定を選択する

2025 年 7 月 15 日より AWS アカウント 前に を作成した場合は、Neptune でのエントリレベルの実験に AWS 無料利用枠を使用できます。db.t3.medium および db.t4g.medium インスタンスの無料利用時間である 750 時間で、Neptune を低スケールで十分に理解できます。クラスターは無料トライアル期間終了後も残りますが、それ以降の使用量に対しては課金されます。

db.t3.medium および db.t4g.mediumインスタンスは、openCypher、Graph Explorer、またはさまざまな生成 AI 統合を使用していない低コストの開発環境に適しています。これらのインスタンスの RAM-to-vCPUの比率 (2:1) は、Rファミリーインスタンス (8:1) またはXファミリーインスタンス (16:1) よりも小さくなります。これにより、比率が削減され、openCypher パフォーマンス、GenAI 統合 (LLM にグラフスキーマを通知するため）、Graph Explorer を有効にする DFE エンジン統計が使用できなくなります。パフォーマンスプロファイルは、Tファミリーインスタンスを使用する場合、特に前述のワークロードでは大きく異なる場合があります。これらのインスタンスは、クエリがグラフの大部分をナビゲートOutOfMemoryExceptionsする場合の の発生を増やすこともできます。後者の条件が影響を受ける可能性があるかどうかを判断するには、BufferCacheHitRatio CloudWatch メトリクスを確認します。

本番環境を示唆しない一貫性のない結果が発生する可能性があるため、Tファミリーインスタンスでのパフォーマンステストや負荷テストを行わないことを強くお勧めします。

プロビジョニングされたインスタンスは、ワークロードがかなり安定していて予測可能な場合に、コストとパフォーマンスの最適な組み合わせを提供します。インスタンスサイズは、必要なリクエストの同時実行数とクエリの複雑さに基づいて選択します。同時実行数を増やすには、より多くの vCPU が必要です。クエリの複雑さが高いほど、より多くの RAM が必要になります。前者の影響を判断するには、MainRequestQueuePendingRequests CloudWatch メトリクスを使用します (0 より大きい場合は、同時リクエストの数が処理可能な数よりも多いことを表します)。後者の影響を判断するには、BufferCacheHitRatio CloudWatch メトリクスを使用します。比率が頻繁に 99.9% を下回る場合、評価対象のグラフの作業部分を含むのに十分な RAM がなく、キャッシュスワップの頻度が高くなることを示します。インスタンスの R ファミリーに十分な同時実行性があるものの、十分な RAM がない場合は、インスタンスのXファミリーを試すことを検討してください。

サーバーレスインスタンスの理想的なユースケースについては、Neptune ドキュメントで説明しています。プロビジョニングとサーバーレスのどちらが最適かが不明で、コストが主な懸念事項である場合は、サーバーレスでワークロードをテストして、使用される NCU の数を判断し、プロビジョニング (N hours × hourly provisioned cost) のコストをサーバーレス (sum of NCUs × hourly cost per NCU) と比較します。同等のサイズのプロビジョニングインスタンスがわからない場合、1 NCU は、約 2 GB の RAM および関連する vCPU とネットワークに相当します。プロビジョニングされたインスタンスが r6iファミリーのものである場合、比率は 8 GB の RAM あたり 1 vCPU、または関連するネットワークとともに 4 NCUs。Amazon Neptune 料金計算ツールには、最適なコスト設定を決定するのに役立つ比較も用意されています。

プライマリインスタンスとレプリカインスタンスにサーバーレスを使用する場合、昇格階層 0 と 1 のリードレプリカは、フェイルオーバーイベントが発生した場合に適切にスケーリングされるように、ライターインスタンスに合わせて NCU をスケーリングすることに注意してください。これらのインスタンスの NCU の制限は、ライターまたはリーダーのどちらのインスタンスが最も多くのトラフィックを受信するかに基づいて設定します。

クラスターが 1 日 24 時間、週 7 日必要でない環境では、使用していないときに Neptune インスタンスをオフにし、使用する前に再度起動するスクリプトを記述することを検討してください。必要なメンテナンスアップデートが適用されるように、Neptune インスタンスは 7 日ごとに自動的に再起動されます。インスタンスを長期間オフのままにする場合は、週次スクリプトを使用して再度シャットダウンします。

適切なサイズのデータストレージと転送

より効率的なクエリ (触れる必要のあるグラフ内のノード、エッジ、プロパティが少ないクエリなど) では、必要な I/O 転送が少なくなり、バッファキャッシュが少なくて済むため、より小さなインスタンスを使用できる可能性があります。クエリ言語のプロファイルエンドポイントまたは説明エンドポイントを使用してクエリを最適化し、クエリのパフォーマンスに合わせてグラフモデルを最適化することを検討してください。

Neptune は大きな文字列にディクショナリエンコードを使用し、そのディクショナリは効率ではなくパフォーマンスに最適化されています。プロパティに対して大きな BLOBs、JSON、または頻繁に変更される文字列がある場合は、それらを Neptune の外部の Amazon S3、Amazon DynamoDB、または Amazon DocumentDB に保存し、Neptune ノードには参照のみを保存することを検討してください。

場合によっては、インスタンスサイズを大きくするとコストを下げることができます。BufferCacheHitRatio が低いために I/O コストが非常に高い場合、バッファキャッシュが大きくすると、そのコストが大幅に削減される可能性があります。これは、データがストレージから頻繁にスワップされ、I/O 転送レートが発生する代わりに、すべてのデータがキャッシュに収まるためです。

Neptune はコピーオンライトでクローンを作成します。クローンを作成してグラフを複数のシャードに分割する場合、クローンされたクラスター上の不要なデータを削除しない方が効率的です。これには新しいデータページの作成が含まれ、ストレージコストが増加するためです。クローン作成イベント前から変更されていないデータは、2 つのクラスター間で共有される単独のデータページに存在し、その単独のコピーに対してのみ課金されます。

OSGP インデックスを有効にしたり、R5d インスタンスを使用したりしないでください。ただし、ワークロードに大きな違いが生じることをテストで確認している場合は除きます。どちらもめったに発生しないシナリオ向けに設計されており、メリットがほとんどないにもかかわらずコストが増加する可能性があります。