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

ISVsの運用上のベストプラクティス

このセクションのガイドラインの多くは、すべてのお客様向けのベストプラクティスですが、ISVs には重要性が付加されています。

Neptune クラスターを最新バージョンで更新する

Amazon Neptune リリースノートでは、すべてのバージョンが多数のバグ修正、パフォーマンスの向上、新機能をもたらしていることがわかります。Neptune クラスターをできるだけ最新バージョンに保ちます。

以前に検出されなかったバグがワークロードにあり、クラスターが最新バージョンである場合、Neptune エンジニアはクラスターのプライベートパッチを作成できます (必要に応じて）。パッチは、その修正が一般公開される次のリリースまでブリッジできます。クラスターを最新バージョンに更新するには、Neptune Blue/Green ソリューションを使用します。

データインジェストに削除と置換の代わりに差分を使用する

Neptune にデータを取り込んだり書き込んだりするには、いくつかの手法を使用できます。多くのお客様は、フィードで変更が受信されるたびにグラフを削除して再挿入することで、データの取り込みを簡素化しようとしています。各ノードにlast-modifiedプロパティを追加し、指定した日付以降に変更されていないノードを定期的にスキャンして削除する場合があります。これらの手法はデータ取り込みプロセスを簡素化しますが、Neptune クラスターには長期的なヘルスとスケーラビリティの影響があります。

まず、Neptune は文字列のディクショナリエンコーディングを使用します。ノードとエッジの IDs を明示的に指定しない限り、Neptune は ID の文字列として表される GUID を生成し、その文字列をディクショナリに保存します。オブジェクトを常に削除して追加している場合、自動的に生成された IDs によってディクショナリが肥大化します。

次に、Neptune は最大 1 秒あたり約 120 K オブジェクトを取り込むようにスケールアップします。オブジェクトを継続的に削除して追加する場合、基本的に変更されていないオブジェクトでその帯域幅の多くを消費します。これにより、クラスターでホストできるテナントの数が制限され、クラスター内により大きなライターインスタンスが必要になり、より多くの I/O オペレーションが必要になります。これらの要因はすべてコストを増加させます。

削除および追加メソッドを使用する代わりに、変更内容の真の差分を計算する方法を開発することを強くお勧めします。ただし、一部のデータソースはこれには適していません (たとえば、現在の状態を返す API コールや、変更された内容を正確に追跡しないイベントなど）。raw データソースが変更の特定に適していない場合は、抽出、変換、ロード (ETL) プロセスを使用して差分を計算します。例えば、以前の各データキャプチャのスナップショットを Parquet 形式で維持 AWS Glue し、 を使用してそれらのスナップショットの違いを計算し、その違いのみを Neptune にプッシュできます。

Neptune のコストがテナントとともにどのように進化するかをモデル化する

サイロモデル、プールモデル、ハイブリッドモデルのいずれを使用する場合でも、クラウドコストはテナントのサイズに応じてスケールします。同時接続数が多いテナントでは、同時接続数が少ないテナントよりも大きなインスタンスまたはリードレプリカが必要です。より迅速なデータ取り込みを必要とするテナントにも同じことが当てはまります。

Neptune クラスターコストの 3 つのコンポーネントは、インスタンスサイズ (および数）、データサイズ (GB/月）、I/O オペレーション (100 万あたり) です。これらのコストは一般的にワークロード固有ですが、サイズとデータ量に応じてスケールしますが、 AWS ツールを使用して測定できます。時間の経過とともにサイズがどのように変化するかなど、テナントのサイズの主要な指標に照らしてスケールの経済を追跡し、理解します。I/O 料金の予測不能性がマージンに影響する場合は、より予測可能なコストで Neptune I/O 最適化ストレージを選択することを検討してください。

お客様の需要に合わせてクラスターをスケールする

Neptune インスタンスサイズを適切にサイズ設定するための試行式や true 式はありません。Neptune ドキュメントにはガイダンスが記載されていますが、変数が多すぎて直接マッピングを推奨できません。これらの変数には以下が含まれますが、これらに限定されません。

ワークロードとテナントプロファイルに最適なサイズを決定するためのテストを計画します。一般的に、コスト効率と予測可能性のために、プロビジョニングされたインスタンスを使用することをお勧めします。カスタマーエクスペリエンスの目標がコストよりも最適なスケーリングを優先する場合は、Neptune Serverless インスタンスを使用して、ワークロードの変動に関係なく、より一貫したエクスペリエンスを確保することを検討してください。

テナントの読み取りワークロードのピークとトラフに大きなばらつきがある場合は、Neptune Serverless インスタンスを Neptune 自動スケーリングと組み合わせてください。  通常、新しいリードレプリカが初期化されてからオンラインになるまでに 10～15 分かかります。つまり、自動スケーリングだけではトラフィックの長期的な変化を処理できますが、アクティビティの急激な急増には不十分です。Neptune サーバーレスと Neptune 自動スケーリングを組み合わせることで、インスタンスをスケールアップまたはスケールダウンしたり、リードレプリカの数をスケールインおよびスケールアウトしたりできます。

テナントのワークロードプロファイルまたはサービスレベルアグリーメント (SLAs) が大幅に異なる場合は、カスタムエンドポイントと専用リードレプリカを使用して、そのトラフィックに最適化されたインスタンスにトラフィックを誘導することを検討してください。最適化には、インスタンスの異なるサイズ設定、特定のクエリパターン、バッファキャッシュの事前ウォーミングなどがあります。