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

成長に備える

プールモデルを正常に使用すると、最終的に単一の Neptune クラスターのサイズが大きくなります。テナントが増加するか、テナントの数が増加し、すべての顧客に必要なデータの取り込み率がクラスターの機能を超えています。これが発生した場合は、顧客を複数のクラスターに分割する必要があります。後で改良を試みるのではなく、この設定を事前に設計してください。初期スケールが 1 つのクラスターのみを使用する場合でも、そのスケールに達したときに将来複数のクラスターにテナントをルーティングする必要があるコンポーネントをモックアップします。

テナントのサイズに基づいてソリューションにより多くのリソースが必要な場合は、その成長に備えてください。1 つのクラスターの複数のお客様が大幅に増加した場合、そのクラスターは要件をサポートしなくなる可能性があります。Amazon Neptune DB クローン作成機能を使用して、テナントを別のクラスターに移動するか、既存のクラスターを 2 つに分割する戦略を設計します。

DB クローンを実装するときにコストを削減できる Neptune Copy-on-Write Protocol に精通してください。取り込みのボトルネックのためにクラスターを分割すると、ポリシーで許可されている限り、クラスターからデータを削除しない方が効率的です。2 つのクラスターは、データページが変更されていない場合はデータページを共有しますが、データページが変更されている場合は共有しません (データページの一部が削除されたため）。

マルチテナンシーシナリオの制限事項

一部の Neptune 機能は、マルチテナンシーシナリオ用に構築されていないことに注意してください。これらのマルチテナンシー戦略はデータベースレベルで強制されないため、テナントにはプールモデル内の Neptune エンドポイントへの直接アクセスを許可しないでください。このドキュメントで説明されている設計を適用する Neptune エンドポイントと顧客の間には、常に何らかのプロキシを保持してください。このようなプロキシの例は次のとおりです。

このガイダンスは、Neptune グラフノートブック、Neptune グラフエクスプローラー、Neptune ストリームなどの機能に直接アクセスできるようにする場合にも適用されます。