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

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

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 クラスターの耐障害性」を参照してください。

アベイラビリティーゾーンにまたがってリードレプリカを作成すると、それらは Neptune によって、自動的にプロビジョニングおよび維持されます。プライマリ DB インスタンスは複数のアベイラビリティーゾーンにまたがって、リードレプリカに同期してレプリケートされます。これにより、データの冗長性を提供し、I/O のフリーズを防ぎ、システムバックアップの間のレイテンシーの急上昇を最小限に抑えることができます。高可用性を備えた 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 数に等しい数のクエリスレッドがあります。たとえば、2 つの vCPUs がある r4.xlarge では、4 つのクエリスレッドがあるため、4 つの要求を同時に処理できます。たとえば、16 の vCPUs がある 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を待機することでいくらか減少します。

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

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