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 インスタンスには、そのインスタンスの の 2 倍に等しい数のクエリスレッド vCPUs があります。例えばr5.4xlarge、16 の の場合vCPUs、 には 32 のクエリスレッドがあるため、32 のクエリを同時に処理できます。

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

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

プライマリ 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 インスタンスのパフォーマンスをモニタリングし、クライアントが観察したクエリレイテンシーを追跡できます。「 CloudWatch を使用して Neptune で DB インスタンスのパフォーマンスをモニタリングする」を参照してください。