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

Neo4j から Neptune へ移行するときのインフラストラクチャのプロビジョニング

Amazon Neptune クラスターは、ストレージ、書き込み容量、読み取り容量の 3 つの次元でスケーリングできるように構築されています。以下のセクションでは、移行時に考慮すべき具体的なオプションについて説明します。

ストレージのプロビジョニング

Neptune クラスターのストレージは、自動的にプロビジョニングされるため、ユーザー側の管理オーバーヘッドはありません。クラスターのストレージニーズが増えるにつれて、10 GB チャンクで動的にサイズ変更されます。そのため、将来のデータ増加に対応するために、ストレージを見積もってプロビジョニングしたり、過剰にプロビジョニングしたりする必要がありません。

書き込み容量のプロビジョニング

Neptune は 1 つのライターインスタンスを提供しており、Neptune の料金ページに記載されている任意のインスタンスサイズに合わせて垂直方向にスケーリングできます。ライターインスタンスにデータを読み書きする場合、すべてのトランザクションは ACID に準拠し、Neptune でのトランザクション分離レベル で定義されているデータ分離が行われます。

ライターインスタンスに最適なサイズを選択するには、負荷テストを実行して、ワークロードに最適なインスタンスサイズを決定する必要があります。Neptune 内のインスタンスは、DB インスタンスクラスを変更することでいつでもサイズを変更できます。開始時のインスタンスサイズは、クラスターをプロビジョニングするときに最適なインスタンスサイズを見積もる で説明するように、同時実行性と平均クエリレイテンシーに基づいて見積もることができます。

書き込み容量のプロビジョニング

Neptune は、リードレプリカインスタンスをクラスター内で最大 15 個 (または Neptune グローバルデータベースではそれ以上) 追加することで水平方向にスケーリングできるように構築されています。また、Neptune の料金表ページで確認できる任意のインスタンスサイズに合わせて垂直方向にもスケーリングできるように構築されています。すべての Neptune リードレプリカインスタンスは同じ基盤となるストレージボリュームを使用するため、遅延を最小限に抑えてデータを透過的に複製できます。

Neptune クラスター内の読み取りリクエストの水平スケーリングを有効にするだけでなく、リードレプリカはライターインスタンスのフェイルオーバーターゲットとしても機能し、高可用性を実現します。クラスター内のリードレプリカの適切な数と配置を決定する方法については、「Amazon Neptune 基本操作ガイドライン」を参照してください。

接続やワークロードが予測できないアプリケーション向けに、Neptune は、指定した条件に基づいて Neptune レプリカの数を自動的に調整できる自動スケーリング機能もサポートしています。

リードレプリカインスタンスの最適なサイズと数を決定するには、負荷テストを実行して、サポートする必要のある読み取りワークロードの特性を判断する必要があります。Neptune 内のインスタンスは、DB インスタンスクラスを変更することでいつでもサイズを変更できます。開始時のインスタンスサイズは、次のセクションで説明するように、同時実行性と平均クエリレイテンシーに基づいて見積もることができます。

Neptune サーバーレスを使用して、必要に応じてリーダーインスタンスとライターインスタンスを自動的にスケーリングする

予想されるワークロードに必要なコンピューティング容量を見積もることができると便利な場合が多いですが、読み取りと書き込みの容量を自動的にスケールアップまたはスケールダウンするように Neptune サーバーレス機能を設定できます。これにより、ピーク時の要件を満たすと同時に、需要が減少すると自動的にスケールバックできます。

クラスターをプロビジョニングするときに最適なインスタンスサイズを見積もる

最適なインスタンスサイズを見積もるには、ワークロードの実行中の Neptune での平均クエリレイテンシー、および処理中の同時クエリ数を知る必要があります。インスタンスサイズの概算見積もりは、平均クエリレイテンシーに同時実行クエリ数を掛けたものとして計算できます。これにより、ワークロードを処理するのに必要な同時スレッドの平均数がわかります。

Neptune インスタンスの各 vCPU は 2 つの同時クエリスレッドをサポートできるため、スレッドを 2 で割ると、必要な vCPU の数が算出され、Neptune の料金ページの適切なインスタンスサイズと関連付けることができます。例:

Average Query Latency:         30ms (0.03s)
Number of concurrent queries:  1000/second

Number of threads needed:      0.03 x 1000 = 30 threads
Number of vCPUs needed:        30 / 2 = 15 vCPUs

これをインスタンス内のvCPU の数と相関させると、r5.4xlarge がこのワークロードで試すべき推奨インスタンスであるという概算見積もりが得られます。この見積もりは概算であり、インスタンスサイズの選択に関する最初のガイダンスを提供することのみを目的としています。どのようなアプリケーションでも、適切なサイジングを行って、ワークロードに適した適切なインスタンス数とタイプを決定する必要があります。

処理要件だけでなく、メモリ要件も考慮する必要があります。Neptune は、クエリによってアクセスされるデータがメインメモリのバッファプールキャッシュにある場合に最もパフォーマンスが向上します。十分なメモリをプロビジョニングすれば、I/O コストも大幅に削減できます。

Neptune クラスター内のインスタンスのサイズ設定に関するその他の詳細とガイダンスは、「Neptune DB クラスターでの DB インスタンスのサイジング」ページにあります。