翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Neptune ストレージ、信頼性、可用性
Amazon Neptune では、データベースストレージのニーズが増大すると自動的に拡張される分散型および共有ストレージアーキテクチャが使用されます。
Neptune のデータは、NVMe (NVMe) SSD ベースのドライブを使用する単一の仮想ボリュームであるクラスターボリュームに保存されます。クラスターボリュームは、論理ブロックのコレクションで構成されます。これらのセグメントにはそれぞれ 10 ギガバイト (GB) のストレージが割り当てられます。各セグメントのデータは 6 つのコピーにレプリケートされ、その後、DB クラスターが存在する AWS リージョンの 3 つのアベイラビリティーゾーン (AZ) に割り当てられます。
Neptune DB クラスターが作成されると、10 GB の単一のセグメントが割り当てられます。データ量が増加し、現在割り当てられているストレージを超えると、Neptune は新しいセグメントを追加してクラスターボリュームを自動的に拡張します。Neptune クラスターボリュームは、サポートされているすべてのリージョンで、最大 128 テビバイト (TiB) のサイズまで増やすことができます。ただし、中国と GovCloud では 64 TiB に制限されています。ただし、[リリース： 1.0.2.2 (2020-03-09)](engine-releases-1.0.2.2.md) より前のエンジンリリースでは、クラスターボリュームのサイズはすべてのリージョンで 64 TiB に制限されます。
DB クラスターボリュームには、すべてのユーザーデータ、インデックス、およびディクショナリが含まれます ([Neptune のグラフデータモデル](feature-overview-data-model.md) セクション、および内部トランザクションログなどの内部メタデータ。インデックスや内部ログを含め、このグラフデータはすべて、クラスターボリュームの最大サイズを超えることはできません。
## I/O 最適化ストレージオプション
Neptune は、ストレージに対して、次の 2 つの料金モデルを提供しています。
+ **標準ストレージ** — 標準ストレージは、I/O 使用率が低いか中程度のアプリケーション向けの費用対効果の高いデータベースストレージです。
+ **I/O 最適化ストレージ** — I/O 最適化ストレージでは、使用したストレージの分のみ料金が発生します。標準ストレージよりもコストが高く、使用した I/O に対する料金は発生しません。
I/O 最適化ストレージは、コストが予測可能で、I/O レイテンシーが低く、I/O スループットが一貫している、I/O 負荷の高いグラフワークロードのニーズを満たすように設計されています。
詳細については、「[I/O 最適化ストレージ](storage-types.md#provisioned-iops-storage)」を参照してください。
## Neptune ストレージ割り当て
Neptune クラスターボリュームは 128 TiB (または一部のリージョンでは 64 TiB) まで拡大できますが、実際に割り当てられたスペースに対してのみ料金が請求されます。割り当てられる合計容量は、ストレージ*ハイウォーターマーク*によって決まります。これは、クラスタボリュームの存在中の任意の時点でクラスタボリュームに割り当てられる最大量です。
つまり、ユーザーデータがクラスターボリュームから削除された (`g.V().drop()` のようなドロップクエリなど) の場合でも、割り当てられた領域の合計は同じままです。Neptune は、未使用の割り当て領域を自動的に最適化して、将来再利用します。
ユーザーデータに加えて、2 種類のコンテンツでは、ディクショナリデータと内部トランザクションログなどの内部記憶領域が消費されます。ディクショナリデータはグラフデータとともに保存されますが、サポートするグラフデータが削除された場合でも無期限に保持されます。つまり、データが再導入された場合にエントリを再利用できます。内部ログデータは、独自のハイウォーターマークが付いた個別の内部ストレージスペースに格納されます。内部ログの有効期限が切れると、占有したストレージを他のログに再利用できますが、グラフデータには使用できません。ログに割り当てられている内部領域の量は、`VolumeBytesUsed` [CloudWatch メトリクス](cloudwatch.md)によってレポートされる合計領域に含まれます。
割り当てられたストレージを最小限に保ち、スペースを再利用する方法を [ストレージのベストプラクティス](#feature-overview-storage-best-practices) で確認してください。
## Neptune ストレージ請求
ストレージコストは上述の通り、ストレージ*ハイウォーターマーク*に基づいて請求されます。データは 6 つのコピーにレプリケートされますが、課金されるのはデータの 1 つのコピーのみです。
DB クラスターの現在のストレージハイウォーターマークは、`VolumeBytesUsed`CloudWatch メトリクス ([Amazon CloudWatch を使用した Neptune のモニタリング](cloudwatch.md)を参照) を監視して決定できます。
Neptune ストレージコストに影響するその他の要因には、データベースのスナップショットとバックアップが含まれます。バックアップストレージとして別途請求され、Neptune ストレージコストに基づきます ([Neptune バックアップストレージの管理に役立つ CloudWatch メトリクス](backup-restore-overview-metrics.md)参照)。
ただし、[クローン](manage-console-cloning.md)を作成した場合、データベースのうち、クローンは DB クラスター自体が使用しているのと同じクラスターボリュームを指しているため、元のデータに対する追加のストレージ料金は発生しません。クローンへのその後の変更では、[コピーオンライトプロトコル](manage-console-cloning.md#manage-console-cloning-protocol)を使い、その結果、追加のストレージコストが発生します。
Neptune の料金の詳細については、[Amazon Neptune Pricing](https://aws.amazon.com/neptune/pricing) を参照してください。
## Neptune ストレージのベストプラクティス
特定の種類のデータは Neptune の永続ストレージを消費するため、ストレージの大きな急増を回避するには、次のベストプラクティスを使用します。
+ グラフデータモデルを設計するときは、プロパティキーとユーザー向けの一時的な値の使用をできるだけ避けてください。
+ データモデルに変更を加える予定の場合は、[高速リセット API](manage-console-fast-reset.md) を使ってDBクラスターのデータをクリアするまでは、新しいモデルを使用して既存の DB クラスターにデータをロードしないでください。多くの場合、新しいモデルを使用するデータを新しい DB クラスターにロードすることが最善策です。
+ 大量のデータで動作するトランザクションでは、それに応じて大きな内部ログが生成され、内部ログスペースのハイウォーターマークが永続的に増加する可能性があります。たとえば、DB クラスター内のすべてのデータを削除する 1 つのトランザクションでは、大量の内部ストレージを割り当てる必要がある巨大な内部ログを生成し、グラフデータに使用できるスペースを永続的に減らすことができます。
これを回避するには、大きなトランザクションを小さなトランザクションに分割し、関連する内部ログが期限切れになり、後続のログで再利用できるように内部ストレージを解放します。
+ Neptune クラスターボリュームの増加を監視するよう、`VolumeBytesUsed`CloudWatch メトリクスで CloudWatch アラームを設定できます。これは、データがクラスターボリュームの最大サイズに達している場合に特に役立ちます。詳細については、[Using Amazon CloudWatch alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)(Amazon CloudWatch アラームを使用する)を参照してください。
大量の未使用の割り当て済み領域がある場合、DB クラスターが使用するストレージスペースを縮小する唯一の方法は、グラフ内のすべてのデータをエクスポートし、それを新しい DB クラスターに再ロードすることです。DB クラスターからデータをエクスポートする簡単な方法については、[Neptune のデータエクスポートサービスとユーティリティ](machine-learning-data-export.md)を参照してください。また、Neptune にデータをインポートする簡単な方法については、[Neptune のバルクローダー](bulk-load.md)をご覧ください。
**注記**
[スナップショット](backup-restore-restore-snapshot.md)の作成と復元はDB クラスターに割り当てられるストレージの量を減らすことはありません。スナップショットはクラスターの基盤となるストレージの元のイメージを保持するためです。使用されている割り当て済みストレージの量があまり多くない場合、割り当てられたストレージ量を収縮する唯一の方法として、グラフデータをエクスポートし、それを新しい DB クラスターに再ロードできます。
## Neptune のストレージ、信頼性、高可用性。
Amazon Neptune は、信頼性、耐久性、および耐障害性を持つように設計されています。
Neptune データの 6 つのコピーが 3 つのアベイラビリティーゾーン (AZ) にまたがって維持されるため、データのストレージの耐久性が高く、データ損失の可能性が非常に低くなります。データは、DB インスタンスが存在するかどうかにかかわらず、アベイラビリティーゾーン間で自動的にレプリケートされます。レプリケーションの数は、クラスター内の DB インスタンスの数とは関係ありません。
つまり、Neptune はグラフデータの新しいコピーを作成しないため、リードレプリカをすばやく追加できます。代わりに、リードレプリカから、すべてのデータが既に含まれているクラスターボリュームに接続します。同様に、リードレプリカを削除しても、基になるデータは削除されません。
クラスターボリュームとそのデータは、すべての DB インスタンスを削除した後にのみ削除できます。
Neptune はまた、クラスターボリュームを構成するディスクボリュームの障害を自動的に検出します。セグメント内のデータのコピーが破損すると、Neptune はそのセグメントを直ちに修復し、同じセグメント内のデータの他のコピーを使用して、修復されたデータが最新であることを確認します。その結果、Neptune ではデータ損失が回避され、ディスク障害から回復するためのポイントインタイム復元を実行する必要性が低減します。