翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Neptune のインスタンスタイプの選択
Amazon Neptune には、さまざまなグラフワークロードに適したさまざまな機能を提供するさまざまなインスタンスサイズとファミリーが用意されています。このセクションでは、ニーズに最適なインスタンスタイプを選択する方法について説明します。
これらのファミリーの各インスタンスタイプの料金については、[Neptune の料金表ページ](https://aws.amazon.com/neptune/pricing/)をご覧ください。
## インスタンスリソース割り当ての概要
Neptune で使用されている各 Amazon EC2 インスタンスタイプとサイズは、定義された量のコンピューティング (vCPU) とシステムメモリを提供します。Neptune のプライマリストレージはクラスター内の DB インスタンスの外部にあり、コンピューティングとストレージの容量を互いに独立してスケーリングできます。
このセクションでは、コンピューティングリソースをスケーリングする方法と、さまざまなインスタンスファミリーのそれぞれの違いに焦点を当てます。
すべてのインスタンスファミリーにおいて、vCPU リソースは vCPU あたり 2 つのクエリ実行スレッドをサポートするように割り当てられます。このサポートはインスタンスサイズによって決まります。特定の Neptune DB インスタンスの適切なサイズを決定する際には、アプリケーションの同時実行可能性とクエリの平均レイテンシーを考慮する必要があります。必要な vCPUs の数は、次のように見積もることができます。レイテンシーはクエリの平均レイテンシー (秒単位) として測定され、同時実行性は 1 秒あたりのクエリの目標数として測定されます。
```
vCPUs = (latency x concurrency) / 2
```
**注記**
DFE クエリエンジンを使用する SPARQL クエリ、openCypher クエリ、および Gremlin 読み取りクエリは、特定の状況下では、クエリ 1 つにつき複数の実行スレッドを使用する場合があります。DB クラスターのサイズを最初に決定するときは、各クエリが実行ごとに 1 つの実行スレッドを消費するという前提から始め、クエリキューへのバックプレッシャーが確認されたらスケールアップします。これは、`/gremlin/status`、`/oc/status`、または `/sparql/status` API を使用して確認することも、`MainRequestsPendingRequestsQueue` CloudWatch メトリクスを使用して確認することもできます。
各インスタンスのシステムメモリは、バッファプールキャッシュとクエリ実行スレッドメモリという 2 つの主要な割り当てに分かれています。
インスタンスで使用可能なメモリの約 3 分の 2 がバッファープールキャッシュに割り当てられます。バッファープールキャッシュは、グラフの最も最近使用されたコンポーネントをキャッシュして、それらのコンポーネントに繰り返しアクセスするクエリのアクセスを高速化するために使用されます。システムメモリの容量が大きいインスタンスは、バッファープールキャッシュも大きく、グラフをより多くローカルに保存できます。ユーザーは、CloudWatch で利用できるバッファーキャッシュのヒットとミスのメトリクスをモニタリングすることで、適切な量のバッファープールキャッシュを調整できます。
一定期間キャッシュヒット率が 99.9% を下回った場合は、インスタンスのサイズを増やしたほうがいいかもしれません。これは、バッファープールの容量が十分ではなく、エンジンが基盤となるストレージボリュームからデータを効率的よりも頻繁に取得しなければならないことを示しています。
システムメモリの残りの 3 分の 1 は、オペレーティングシステム用のメモリと、必要に応じてスレッドが使用できる小さな動的プールを残して、クエリ実行スレッドに均等に分散されます。各スレッドで使用できるメモリは、インスタンスサイズごとにわずかに増加し、`8xl` インスタンスタイプでは、スレッドごとに割り当てられるメモリが最大サイズに達します。
スレッドメモリを追加するタイミングは、`OutOfMemoryException` (OOM) が発生したときです。OOM 例外は、1 つのスレッドに割り当てられた最大メモリを超えるメモリが必要になった場合に発生します (これは、インスタンス全体がメモリ不足になることと同じではありません)。
## `t3` および `t4g` インスタンスタイプ
`t3` および `t4g` ファミリーのインスタンスは、グラフデータベースを使い始めるときだけでなく、初期の開発とテストにも低コストのオプションを提供します。これらのインスタンスは Neptune [無料利用枠オファー](https://aws.amazon.com/neptune/free-trial/)の対象となります。これにより、新規顧客は、スタンドアロン AWS アカウント内で使用されるか、一括請求 (支払いアカウント) を持つ AWS 組織の下にロールアップされる最初の 750 インスタンス時間を無料で Neptune を使用できます。
`t3` および `t4g` インスタンスは中規模構成 (`t3.medium` と `t4g.medium`) でのみ提供されます。
これらは本番環境での使用を目的としていません。
これらのインスタンスはリソースが非常に限られているため、クエリの実行時間やデータベース全体のパフォーマンスのテストにはお勧めできません。クエリのパフォーマンスを評価するには、他のインスタンスファミリーのいずれかにアップグレードしてください。
## `r4` ファミリーのインスタンスタイプ
*非推奨* — `r4` ファミリーは 2018 年に Neptune が発売されたときに提供されていましたが、新しいインスタンスタイプでは価格/パフォーマンスが大幅に向上しています。エンジンバージョン [1.1.0.0](engine-releases-1.1.0.0.md) では、Neptune は `r4` インスタンスタイプをサポートしなくなりました。
## `r5` ファミリーのインスタンスタイプ
`r5` ファミリーには、ほとんどのグラフユースケースに適したメモリ最適化インスタンスタイプが含まれています。`r5` ファミリーには、`r5.large` から `r5.24xlarge` までのインスタンスタイプが含まれます。サイズが大きくなるにつれて、コンピューティングパフォーマンスは直線的にスケーリングします。例えば、`r5.xlarge` (4 つの vCPU と 32 GiB のメモリ) は `r5.large` (2 つの vCPU と 16 GiB のメモリ) の 2 倍の vCPU とメモリを搭載し、`r5.2xlarge` (8 つの vCPU と 64 GiB のメモリ) は、`r5.xlarge` の 2 倍の vCPU とメモリを搭載しています。クエリのパフォーマンスは、`r5.12xlarge` インスタンスタイプまで、コンピューティング容量に直接影響すると期待できます。
`r5` インスタンスファミリーは 2 ソケットの Intel CPU アーキテクチャを採用しています。`r5.12xlarge` 以下のタイプでは、1 つのソケットと、そのシングルソケットプロセッサが所有するシステムメモリを使用します。`r5.16xlarge` および `r5.24xlarge` タイプは、ソケットと使用可能なメモリの両方を使用します。2 ソケットアーキテクチャでは 2 つの物理プロセッサ間にいくらかのメモリ管理オーバーヘッドが必要なため、`r5.12xlarge` から `r5.16xlarge` または `r5.24xlarge` インスタンスタイプへのスケールアップで得られるメリットは、小さいサイズでのスケールアップほど直線的ではありません。
## `r5d` ファミリーのインスタンスタイプ
Neptune には[ルックアップキャッシュ機能](feature-overview-lookup-cache.md)があり、大量のプロパティ値やリテラルを取得して返す必要があるクエリのパフォーマンスを向上させることができます。この機能は主に、多数の属性を返す必要があるクエリを行うお客様が使用します。ルックアップキャッシュは、Neptune のインデックスストレージで属性値を何度も検索するのではなく、これらの属性値をローカルで取得することで、これらのクエリのパフォーマンスを向上させます。
ルックアップキャッシュは、`r5d` インスタンスタイプの NVMe にアタッチされた EBS ボリュームを使用して実装されます。クラスターのパラメータグループを使用して有効化されます。Neptune インデックス化ストレージからデータが取得されると、プロパティ値と RDF リテラルがこの NVMe ボリューム内にキャッシュされます。
ルックアップキャッシュ機能が必要ない場合は、`r5d` のコストが高くなるのを避けるため、`r5d` ではなく標準の `r5` インスタンスタイプを使用してください。
`r5d` ファミリーには、`r5` ファミリーと同じサイズ (`r5d.large` から `r5d.24xlarge` まで) のインスタンスタイプがあります。
## `r6g` ファミリーのインスタンスタイプ
AWS は [Graviton](https://aws.amazon.com/ec2/graviton/) という独自の ARM ベースのプロセッサを開発し、Intel および AMD の同等のプロセッサよりも優れた価格/パフォーマンスを提供します。`r6g` ファミリーは Graviton2 プロセッサーを使用しています。今回のテストでは、Graviton2 プロセッサは OLTP スタイルの (制約のある) グラフクエリのパフォーマンスが 10～20% 向上することを確認しました。ただし、大きな OLAP スタイルのクエリの場合、Graviton2 プロセッサの方がメモリページングのパフォーマンスがわずかに低いため、Intel プロセッサよりもパフォーマンスがわずかに低下する可能性があります。
また、`r6g` ファミリーはシングルソケットアーキテクチャを採用しているため、パフォーマンスは `r6g.large` から `r6g.16xlarge` (ファミリーの最大タイプ) へのコンピューティング容量に比例して増加するという点にも注意してください。
## `r6i` ファミリーのインスタンスタイプ
[Amazon R6i インスタンス](https://aws.amazon.com/ec2/instance-types/r6i/)は、第 3 世代の Intel Xeon スケーラブルプロセッサー (コードネーム Ice Lake) を搭載しており、メモリ集約的なワークロードに最適です。原則として、同等の R5 インスタンスタイプよりもコンピューティングコストパフォーマンスが最大 15% 高く、vCPU あたりのメモリ帯域幅が最大 20% 高くなります。
## `x2g` ファミリーのインスタンスタイプ
グラフのユースケースの中には、インスタンスのバッファープールキャッシュが大きいほどパフォーマンスが向上するものがあります。`x2g` ファミリーは、こうしたユースケースをより良くサポートするために立ち上げられました。`x2g` ファミリーのメモリ対 vCPU 比は、`r5` または `r6g` ファミリーよりも大きくなっています。`x2g` インスタンスは Graviton2 プロセッサも使用し、`r6g` インスタンスタイプと同じパフォーマンス特性の多くを備えているほか、バッファプールキャッシュも大きくなっています。
CPU 使用率が低く、バッファプールのキャッシュミス率が高い `r5` または `r6g` インスタンスタイプを使用している場合は、代わりに `x2g` ファミリーを使用してみてください。そうすれば、CPU 容量を増やさずに、必要な追加メモリを確保できます。
## `x2iezn` ファミリーのインスタンスタイプ
`x2iezn` ファミリーは、高周波パフォーマンスを備えたインテル Xeon スケーラブルプロセッサを搭載したメモリ最適化インスタンスを提供します。これらのインスタンスは、高いmemory-to-vCPU 比 (vCPU あたり 32 GiB) を提供するため、高いシングルスレッドパフォーマンスの恩恵を受けるメモリを大量に消費するグラフワークロードに適しています。
主な機能には、最大 4.5 GHz のオールコアターボ周波数と、2xlarge から 12xlarge までのサイズの可用性が含まれます。
## `x2iedn` ファミリーのインスタンスタイプ
`x2iedn` ファミリーは、ローカル NVMe SSD ストレージを備えたメモリ最適化インスタンスを提供します。これらのインスタンスは、高メモリ容量 (vCPU あたり 32 GiB) と高速のローカルストレージを組み合わせるため、大きなインメモリキャッシュと高性能のローカルディスクキャッシュの両方から恩恵を受けるグラフワークロードに最適です。
第 3 世代 Intel Xeon スケーラブルプロセッサを搭載したこれらのインスタンスは、xlarge から 32xlarge までのサイズで利用でき、メモリとストレージの両方のパフォーマンスを必要とする大規模なグラフデータベースに最適化されています。
## `r8g` ファミリーのインスタンスタイプ
`r8g` ファミリーには、 AWS Graviton4 プロセッサを搭載したメモリ最適化インスタンスタイプが含まれています。これらのインスタンスは、前世代に比べてパフォーマンスが大幅に向上しており、メモリを大量に消費するグラフワークロードに適しています。r8g インスタンスについては、r7g インスタンスと比較して、グラフクエリのパフォーマンスが約 15～20% 向上します。
`r8g` ファミリーはデュアルソケットプラットフォームを使用します。から `r8g.large`までのインスタンスタイプを単一のソケットで`r8g.24xlarge`実行します。つまり、パフォーマンスはその範囲全体のコンピューティング容量に応じて直線的にスケーリングされます。は両方のソケット`r8g.48xlarge`を使用し、 ファミリー内で最大のインスタンスタイプです。他のデュアルソケットファミリーと同様に、 から `r8g.24xlarge`へのスケーリングでは、ソケット間のメモリ管理のオーバーヘッドにより`r8g.48xlarge`、パフォーマンスが向上します。
`r8g` ファミリーの主な機能には次のものがあります。
+ AWS Graviton4 ARM ベースのプロセッサを搭載
+ 前世代と比較して高い vCPU あたりのメモリ帯域幅
+ OLTP スタイル (制約付き) のグラフクエリと OLAP スタイルの分析ワークロードの両方に関する、優れた価格/パフォーマンス比
+ 複雑なグラフトラバーサルに活用できるメモリ管理機能の向上
`r8g` ファミリーは、高いメモリ容量と一貫したパフォーマンスを必要とする本番稼働ワークロードに最適です。これらは、クエリの同時実行要件が高いアプリケーションに特に効果的です。
## `r7g` ファミリーのインスタンスタイプ
`r7g` ファミリーは、以前の AWS Graviton2 ベースのインスタンスよりも優れた価格/パフォーマンスを実現する Graviton3 プロセッサを使用します。 Graviton2-based テストでは、Graviton3 プロセッサについては r6g インスタンスと比較して、OLTP 形式のグラフクエリのパフォーマンスが 25～30% 向上します。
`r6g` ファミリーと同様に、`r7g` はシングルソケットアーキテクチャを採用しているため、パフォーマンスは `r7g.large` から `r7g.16xlarge` (ファミリーの最大タイプ) へのコンピューティング容量の変化に比例してスケールします。
`r7g` ファミリーの主な機能には次のものがあります。
+ AWS Graviton3 ARM ベースのプロセッサを搭載
+ r6g と比較してメモリページングのパフォーマンスが向上し、OLTP ワークロードと OLAP ワークロードの両方にメリットがあります
+ バッファプールキャッシュ効率の向上
+ メモリを大量に消費するオペレーションのレイテンシーを短縮
`r7g` ファミリーは、さまざまなクエリパターンが存在する本番環境に適しており、メモリ帯域幅の向上から恩恵を受けるワークロードに特に効果的です。
## `r7i` ファミリーのインスタンスタイプ
`r7i` ファミリーは第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids というコード) を搭載しており、r6i インスタンスよりも大幅に改善されています。これらのインスタンスは、同等の r6i インスタンスタイプと比較して、vCPU あたりのコンピューティング料金/パフォーマンスが約 15% 向上し、メモリ帯域幅が最大 20% 向上します。
`r7i` インスタンスファミリーは、`r5` ファミリーと同様に 2 ソケットの Intel CPU アーキテクチャを採用しています。`r7i.12xlarge` 以下のタイプでは、1 つのソケットと、そのシングルソケットプロセッサが所有するシステムメモリを使用します。`r7i.16xlarge` および `r7i.24xlarge` タイプは、ソケットと使用可能なメモリの両方を使用します。2 ソケットアーキテクチャでは 2 つの物理プロセッサ間にいくらかのメモリ管理オーバーヘッドが必要なため、`r7i.12xlarge` から `r7i.16xlarge` または `r7i.24xlarge` インスタンスタイプへのスケールアップで得られるメリットは、小さいサイズでのスケールアップほど直線的ではありません。
`r7i` ファミリーの主な機能には次のものがあります。
+ 第 4 世代のインテル Xeon スケーラブルプロセッサを搭載
+ パフォーマンスは最大 r7i.12xlarge のコンピューティングキャパシティに比例してスケール
+ 2 ソケットアーキテクチャの物理プロセッサ間のメモリ管理を強化
+ メモリを大量に消費するグラフオペレーションのパフォーマンスの向上
これらのインスタンスファミリーすべてについて、前述したのと同じ式を使用して、必要な vCPU の数を見積もることができます。
```
vCPUs = (latency x concurrency) / 2
```
ここで、レイテンシーはクエリの平均レイテンシー (秒単位) として測定され、同時実行性は 1 秒あたりのクエリの目標数として測定されます。
## `serverless` インスタンスタイプ
[Neptune サーバーレス](neptune-serverless.md)機能は、ワークロードのリソースニーズに基づいてインスタンスサイズを動的にスケーリングできます。Neptune サーバーレスでは、アプリケーションに必要な vCPU の数を計算する代わりに、DB クラスター内のインスタンスの[コンピューティング容量 (Neptune キャパシティユニットで測定) の上限と下限を設定できます](neptune-serverless-capacity-scaling.md)。使用率が変動するワークロードは、プロビジョニングされたインスタンスではなくサーバーレスを使用することでコストを最適化できます。
プロビジョニングされたインスタンスとサーバーレスインスタンスの両方を同じ DB クラスターにセットアップして、最適なコストパフォーマンスを実現できます。