Amazon Neptune DB クラスターとインスタンス

Amazon Neptune DB クラスタークエリを通じてデータへのアクセスを管理します。クラスターは、次のとおりです。

• 1 つのプライマリ DB インスタンス。。

• 最大 15 のリードレプリカ DB インスタンス。。

クラスターのすべてのインスタンスは同じ基盤となる管理ストレージボリューム共有します。これは、信頼性と高可用性を重視して設計されています。

DB クラスター内の DB インスタンスに接続するには、Neptune エンドポイントを使います。

Neptune DB クラスター内のプライマリ DB インスタンス

プライマリ DB インスタンスは、DB クラスターの基盤となるストレージボリュームへのすべての書き込み操作を調整します。読み取りオペレーションもサポートします。

Neptune DB クラスターには 1 つのプライマリ DB インスタンスしか存在できません。プライマリインスタンスが使用できなくなると、Neptune は、指定可能な優先度を使用して、リードレプリカインスタンスの 1 つに自動的にフェールオーバーします。

Neptune DB クラスター内のリードレプリカ DB インスタンス

DB クラスターのプライマリインスタンスを作成したら、DB クラスターに最大 15 の リードレプリカリードレプリカ レプリカを作成して、読み取り専用クエリをサポートできます。

Neptune リードレプリカ DB インスタンスは、クラスターボリュームでの読み取りオペレーションに特化しているため、読み取りのスケーリングに最適です。すべての書き込みオペレーションはプライマリインスタンスによって管理されます。各リードレプリカ DB インスタンスには、独自のエンドポイントがあります。

クラスターストレージボリュームはクラスター内のすべてのインスタンス間で共有されるため、すべてのリードレプリカインスタンスは、レプリケーションの遅れをほとんど伴わずクエリ結果に対して同じデータを返します。このラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。ただし、書き込みオペレーションの数が非常に多い場合、多少長くなります。

異なるアベイラビリティーゾーンで 1 つ以上のリードレプリカインスタンスを利用可能にすると、リードレプリカがプライマリインスタンスのフェイルオーバーターゲットとして機能するため、可用性が向上します。つまり、プライマリインスタンスが失敗した場合、Neptune はリードレプリカをプライマリインスタンスに昇格します。そうすると、プライマリインスタンスに対して行われた読み取り要求と書き込み要求が失敗して例外が発生すると、短時間の中断が発生し、昇格したインスタンスは再起動されます。

対照的に、DB クラスターにリードレプリカインスタンスが含まれていない場合、プライマリインスタンスが再作成されるまで障害が発生しても、DB クラスターは使用できないままになります。プライマリインスタンスの再作成は、リードレプリカの昇格よりもかなり時間がかかります。

高可用性を確保するために、プライマリインスタンスと同じ DB インスタンスクラスを持ち、プライマリインスタンスとは異なるアベイラビリティーゾーンに配置する 1 つ以上のリードレプリカインスタンスを作成することをお勧めします。Neptune DB クラスターの耐障害性 を参照してください。

コンソールを使用すると、DB クラスターを作成する際にマルチ AZ を指定するだけでマルチ AZ 配置を作成できます。DB クラスターが 1 つのアベイラビリティーゾーンにある場合は、別のアベイラビリティーゾーンに Neptune レプリカを追加して、マルチ AZ の DB クラスターにすることができます。

注記

暗号化されていない Neptune DB クラスターには暗号化されたリードレプリカインスタンスや、暗号化された Neptune DB クラスターの暗号化されていないリードレプリカインスタンスを作成することはできません。

Neptune リードレプリカ DB インスタンスの作成方法の詳細については、コンソールを使用して Neptune リーダーインスタンスを作成するを参照してください。

Neptune DB クラスターでの DB インスタンスのサイジング

CPU とメモリの要件に基づいて、Neptune DB クラスター内のインスタンスのサイズを設定します。インスタンス上の vCPUs の数によって、着信クエリを処理するクエリスレッドの数が決まります。インスタンスのメモリ容量によって、基礎となるストレージボリュームからフェッチされたデータページのコピーを格納するために使用されるバッファキャッシュのサイズが決まります。

各 Neptune DB インスタンスには、そのインスタンスの vCPUs の 2 x 数に等しい数のクエリスレッドがあります。例えば、16 の vCPU がある r5.4xlarge では、32 のクエリスレッドがあるため、32 のクエリを同時に処理できます。

すべてのクエリスレッドが占有されている間に到着する追加のクエリは、サーバーサイドキューに入れられ、クエリスレッドが使用可能になると FIFO 方式で処理されます。このサーバーサイドキューは、約 8000 の保留中の要求を保持できます。一杯になったら、Neptune は追加のリクエストに ThrottlingException で応答します。保留中のリクエストの数は、MainRequestQueuePendingRequests CloudWatch メトリックスを使用するか、Gremlin クエリステータスエンドポイントとパラメータを使用してモニタリングできます。includeWaiting

クライアントの観点から見たクエリの実行時間には、実際にクエリを実行するのに要した時間に加えて、キューに費やされた時間も含まれます。

プライマリ DB インスタンスのすべてのクエリスレッドを使用する持続的な同時書き込みロードは、理想的には 90% 以上の CPU 使用率を示します。これは、サーバー上のすべてのクエリスレッドが有効な作業に積極的に従事していることを示します。ただし、同時書き込み負荷が持続していても、実際の CPU 使用率はやや低くなります。これは通常、クエリスレッドが基になるストレージボリュームへの I/O オペレーションが完了するのを待機中であるためです。Neptune は、3 つのアベイラビリティーゾーンにまたがるデータのコピーを 6 つ作成するクォーラム書き込みを使用します。また、これらの 6 つのストレージノードのうち 4 つの耐久性を考慮するために、書き込みを認識する必要があります。クエリスレッドがストレージボリュームからこのクォーラムを待っている間、スレッドは停止し、CPU 使用率が低下します。

次々に書き込みを実行し、次の書き込みを開始する前に最初の書き込みが完了するのを待っているシリアル書き込みロードがある場合、CPU 使用率が低下すると予想されます。正確な量は、vCPUs とクエリスレッドの数の関数になります (クエリスレッドが多いほど、クエリあたりの全体的な CPU は少なくなります)。I/Oを待機することでいくらか減少します。

DB インスタンスのサイズを決める方法の詳細については、「適切な Neptune DB インスタンスタイプを選択する」を参照してください。これらのファミリーの各インスタンスタイプの料金については、Neptune の料金表ページをご覧ください。

Neptune での DB インスタンスのパフォーマンスのモニタリング

Neptune CloudWatch のメトリックスを使用して DB インスタンスのパフォーマンスをモニタリングし、クライアントが観測したクエリのレイテンシーを追跡できます。Neptune で DB CloudWatch インスタンスのパフォーマンスをモニタリングするために使用する を参照してください。