Amazon Neptune 基本操作ガイドライン - Amazon Neptune
異なるインスタンスサイズを避ける一括ロードによる再起動は避けてください。述語が多い場合実行時間が長いトランザクションクエリのチューニング負荷分散一時インスタンスを使用するインスタンスのサイズ変更タスク中断エラー

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

Amazon Neptune 基本操作ガイドライン

以下に示しているのは、基本的な運用についてのガイドラインであり、Neptune の使用時にユーザーが従う必要があります。

  • Neptune DB インスタンスを理解して、パフォーマンスおよびユースケースの要件に合わせて適切なサイズを設定できるようにします。「Amazon Neptune DB クラスターとインスタンス」を参照してください。

  • CPU とメモリの使用状況をモニタリングします。これにより、 CPUまたは メモリ容量が大きい DB インスタンスクラスに移行するタイミングを把握し、必要なクエリパフォーマンスを実現できます。使用状況パターンが変化したとき、またはデプロイの容量に近づいたときに通知 CloudWatch するように Amazon を設定できます。これにより、システムのパフォーマンスと可用性を維持するのに役立ちます。詳細については、「インスタンスのモニタリング」と「Neptune のモニタリング」を参照してください。

    Neptune には独自のメモリマネージャーがあるため、使用量が多い場合でも、メモリCPU使用量が比較的少なくなるのは普通です。クエリの実行時に例外が発生する out-of-memoryことは、空きメモリを増やすために必要な最適な指標です。

  • 自動バックアップを有効にして、都合の良いときにバックアップウィンドウを設定します。

  • DB インスタンスのフェイルオーバーをテストすることで、そのプロセスでユースケースにかかる時間を把握します。また、DB インスタンスにアクセスするアプリケーションがフェイルオーバー後に新しい DB インスタンスに自動的に接続できるようにします。

  • VPC ピアリングによるクロスリージョン接続はクエリレスポンスタイムの遅延を引き起こす可能性があるためVPC、可能であれば、クライアントと Neptune クラスターを同じリージョンと で実行します。1 桁のミリ秒のクエリレスポンスの場合、クライアントと Neptune クラスターを同じリージョンと に保持する必要がありますVPC。

  • リードレプリカインスタンスを作成するときは、少なくともプライマリライターインスタンスと同じ大きさにする必要があります。これにより、レプリケーションの遅延がチェックされ、レプリカの再起動が回避されます。「クラスターで異なるインスタンスクラスを避ける」を参照してください。

  • 新しいメジャーエンジンバージョンにアップグレードする前に、必ずそのエンジンでアプリケーションをテストしてください。これを行うには、DB クラスターをクローンしてクローンクラスターで新しいエンジンバージョンを実行し、そのクローンでアプリケーションをテストします。

  • フェイルオーバーを容易にするために、すべてのインスタンスを同じサイズにするのが理想的です。

トピック

クラスターで異なるインスタンスクラスを避ける

DB クラスターに異なるクラスのインスタンスが含まれている場合、時間の経過とともに問題が発生する可能性があります。最も一般的な問題は、レプリケーションのラグが原因で、小さなリーダーインスタンスが再起動を繰り返すサイクルに入る可能性があることです。リーダーノードの DB インスタンスクラスの設定が、ライター DB インスタンスの設定よりも弱い場合、変更のボリュームが大きすぎてリーダーが追いつくことができません。

重要

レプリケーションラグによる再起動が繰り返されないようにするには、すべてのインスタンスが同じインスタンスクラス (サイズ) を持つように DB クラスターを構成します。

Amazon の ClusterReplicaLagメトリクスを使用して、DB クラスターのライターインスタンス (プライマリ) とリーダー間の遅延を確認できます CloudWatch。VolumeWriteIOPs メトリクスでは、レプリケーションラグが発生する可能性のあるクラスター内の書き込みアクティビティのバーストを検出することもできます。

一括ロード中の再起動の繰り返しの回避

一括ロード中のレプリケーション遅延が原因で、リードレプリカが繰り返し再起動されるサイクルが発生した場合、レプリカは DB クラスター内のライターに追いつけない可能性があります。

リーダーをライターよりも大きくするか、一括ロード中にリーダーを一時的に削除し、完了後に再作成してください。

述語の数が多い場合は、OSGPインデックスを有効にします。

データモデルに Distinct 述語が多数含まれていると (たいていは 1000 以上)、パフォーマンスが低下し、運用コストが高くなる可能性があります。

この場合、OSGPインデックス を有効にすることでパフォーマンスを向上させることができます。「OSGP インデックス」を参照してください。

可能な限り、実行時間が長いトランザクションを避ける

実行時間が長いトランザクション (読み取り専用または読み取り/書き込み) は、次の種類の予期しない問題を引き起こす可能性があります。

読み取りインスタンスまたは同時書き込みがあるライターインスタンスで実行時間が長いトランザクションは、異なるバージョンのデータが大量に蓄積される可能性があります。これにより、結果の大部分を除外する読み取りクエリのレイテンシーが高くなる可能性があります。

場合によっては、時間の経過とともに蓄積されたバージョンによって、新しい書き込みがスロットルされることがあります。

多くの書き込みを伴う実行時間が長い読み取り/書き込みトランザクションは、インスタンスが再起動した場合に問題を引き起こす可能性があります。インスタンスがメンテナンスイベントまたはクラッシュから再起動すると、コミットされていない書き込みはすべてロールバックされます。このような元に戻す操作は通常、バックグラウンドで実行され、インスタンスの復帰をブロックしませんが、ロールバックされる操作と競合する新しい書き込みは失敗します。

たとえば、前回の実行で接続が切断された後に同じクエリが再試行された場合、インスタンスの再起動時に失敗することがあります。

元に戻す操作に必要な時間は、関連する変更のサイズに比例します。

Neptune クエリのチューニングのベストプラクティス

Neptune のパフォーマンスを向上させるには、大量のリソースを消費する使用頻度の最も高いクエリをチューニングして、実行コストを下げることをお勧めします。

Gremlin クエリを調整する方法の詳細については、Gremlin クエリヒント および Gremlin クエリのチューニングを参照してください。SPARQL クエリを調整する方法については、「」を参照してくださいSPARQL クエリヒント。

リードレプリカ全体の負荷分散

リーダーエンドポイントのラウンドロビンルーティングは、DNSエントリがポイントするホストを変更することで機能します。多くの場合、 WebSocket 接続は長期間存続するため、クライアントは新しい接続を作成し、DNSレコードを解決して新しいリードレプリカへの接続を取得する必要があります。

連続するリクエストに対して異なるリードレプリカを取得するには、クライアントが接続するたびにDNSエントリを解決していることを確認します。このためには、接続を終了し、リーダーエンドポイントに再接続する必要があります。

インスタンスエンドポイントに明示的に接続することで、リードレプリカ全体で負荷を分散することもできます。

一時的に大きなインスタンスを使用してロード時間を短縮

大きなインスタンスサイズで、ロードパフォーマンスが向上します。大きなインスタンスタイプを使用していないが、ロード速度を向上させる場合は、大きいインスタンスを使用してロードし、削除することができます。

注記

次の手順は新しいクラスターを対象としています。既存のクラスターがある場合は、新しい大きなインスタンスを追加して、プライマリ DB インスタンスに昇格させることができます。

大きいインスタンスサイズを使用してデータをロードするには

  1. 単一の r5.12xlarge インスタンスでクラスターを作成します。このインスタンスはプライマリ DB インスタンスです。

  2. 同じサイズのリードレプリカを 1 つ以上作成します (r5.12xlarge)。

    リードレプリカは小さいサイズで作成できますが、プライマリインスタンスによる書き込みに追いつくのに十分な大きさでない場合は、頻繁に再起動する必要があります。その結果、ダウンタイムによってパフォーマンスが大幅に低下します。

  3. 一括ローダーコマンドで、 “parallelism” : “OVERSUBSCRIBE”を含めて、ロードに使用できるすべてのCPUリソースを使用するように Neptune に指示します (「」を参照Neptune ローダーのリクエストパラメータ）。その後、ロードオペレーションは I/O が許可する速度で進行します。通常、CPUリソースの 60～70% が必要です。

  4. Neptune ローダーを使用してデータをロードします。ロードジョブはプライマリ DB インスタンスで実行されます。

  5. データのロードが完了したら、追加料金や再起動の問題を繰り返さないように、クラスター内のすべてのインスタンスを同じインスタンスタイプにスケールダウンするようにしてください (異なるインスタンスサイズを避ける参照)。

リードレプリカにフェイルオーバーしてライターインスタンスのサイズを変更する

ライターインスタンスを含む DB クラスター内のインスタンスのサイズを変更する最善の方法は、希望のサイズになるようにリードレプリカインスタンスを作成または変更し、そのリードレプリカに意図的にフェイルオーバーすることです。アプリケーションで見られるダウンタイムは、ライターの IP アドレスを変更するのに必要な時間だけであり、約 3 ～ 5 秒にする必要があります。

現在のライターインスタンスをリードレプリカインスタンスに意図的にフェイルオーバーAPIするために使用する Neptune 管理は ですFailoverDBCluster。Gremlin Java クライアントを使用している場合は、ここに述べるように、フェイルオーバー後に新しいクライアントオブジェクトを作成して、新しい IP アドレスを取得しなければならない場合があります。

以下で説明するように、再起動を繰り返すサイクルを回避するために、すべてのインスタンスを同じサイズに変更してください。

データプリフェッチタスク中断エラー後のアップロードの再試行

バルクローダーを使用してデータを Neptune にロードするときに、LOAD_FAILED ステータスが発生し、詳細情報のリクエストのレスポンスで、次のような PARSING_ERROR および Data prefetch task interrupted メッセージが発生することがあります。

"errorLogs" : [
  {
    "errorCode" : "PARSING_ERROR",
    "errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
    "fileName" : "s3://some-source-bucket/some-source-file",
    "recordNum" : 0
  }
]

このエラーが発生した場合は、バルクアップロードリクエストを再試行します。

このエラーが発生するのは、通常はリクエストやデータが原因で発生しない一時的な中断があった場合であり、一般的にはバルクアップロードリクエストを再実行することで解決できます。

デフォルト設定 ("mode":"AUTO" および "failOnError":"TRUE") を使用している場合、ローダーはすでに正常にロードされたファイルをスキップし、中断が発生したときにまだロードされていなかったファイルのロードを再開します。