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

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

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

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

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

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

    Neptune には独自のメモリマネージャーがあるため、CPU 使用率が高い場合でもメモリ使用率は比較的低いのが一般的です。クエリ実行時にメモリ不足の例外に遭遇するのは、空きメモリを増やす必要があることを示す最も良い目安です。

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

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

  • 可能であれば、クライアントと Neptune クラスターを同じリージョンと VPC で実行します。VPC ピアリングを使用したクロスリージョン接続では、クエリの応答時間に遅延が生じる可能性があるためです。一桁のミリ秒のクエリ応答の場合、クライアントと Neptune クラスターを同じリージョンと VPC に保持する必要があります。

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

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

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

Amazon Neptune セキュリティベストプラクティス

AWS Identity and Access Management (IAM) アカウントを使用して、Neptune API アクションに対するアクセスを制御します。特に、DB インスタンス、セキュリティグループ、オプショングループ、またはパラメータグループなどの Neptune リソースを作成、変更、削除するアクションが対象になります。DB インスタンスのバックアップや復元などの一般的な管理操作を実行するアクションも対象になります。

  • 可能な限り、永続的な認証情報ではなく一時的な認証情報を使用してください。

  • Amazon Relational Database Service (Amazon RDS) リソースを管理する各ユーザーにそれぞれの IAM アカウントを割り当てます。AWS アカウントのルートユーザーを使用して Neptune リソースを管理しないでください。お客様を含めて全員に IAM ユーザーを作成します。

  • それぞれの職務の実行に最低限必要になる一連のアクセス許可を各ユーザーに付与します。

  • IAM グループを使用して、複数のユーザーのアクセス許可を効果的に管理します。

  • IAM 認証情報のローテーションを定期的に行います。

タグ付けを使用して Neptune リソースへのアクセスを制限する方法については、Amazon Neptune のセキュリティを参照してください。IAM の使用に関する一般的な情報については、AWS Identity and Access ManagementおよびIAM ユーザーガイドIAM ベストプラクティスを参照してください。

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

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

重要

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

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

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

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

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

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

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

その場合は、OSPG インデックスを有効にしてパフォーマンスを改善できます。「OSGP インデックス」を参照してください。

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

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

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

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

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

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

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

Neptune メトリクスを使用するベストプラクティス

リソース不足やその他の一般的なボトルネックによるパフォーマンスの問題を特定するには、Neptune DB クラスターに適用されるメトリクスをモニタリングできます。

パフォーマンスメトリクスを定期的に監視して、さまざまな時間範囲の平均値、最大値、最小値に関するデータを収集します。これは、いつパフォーマンスが低下しているかを特定するうえで有効です。このデータを使用して、特定のメトリクスしきい値に対して Amazon CloudWatch アラームを設定することにより、しきい値に達した場合に警告されるようにすることができます。

新しい DB クラスターをセットアップし、一般的なワークロードで実行するときは、さまざまな間隔 (1 時間、24 時間、1 週間、2 週間など) でのすべてのパフォーマンスメトリクスの平均値、最大値、最小値を収集します。これにより、正常な状態を把握することができます。それにより、オペレーションのピークおよびオフピークの時間帯を比較して、得られた情報から、いつパフォーマンスが標準レベルを下回っているかを特定し、それに応じてアラームを設定できます。

Neptune メトリクスの表示方法の詳細については、Amazon を使用した Neptune のモニタリング CloudWatchを参照してください。

開始時に最も重要なメトリクスは次のとおりです。

  • BufferCacheHitRatio — バッファキャッシュから提供されたリクエストの割合 (パーセント)。キャッシュミスにより、クエリの実行に大きなレイテンシーが追加されます。キャッシュヒット率が 99.9% を下回っており、アプリケーションでレイテンシーが問題になる場合は、より多くのデータをメモリにキャッシュするようにインスタンスタイプをアップグレードすることを検討してください。

  • CPU 使用率 - 使用されているコンピュータの処理能力の割合。クエリパフォーマンスの目標によっては、CPU 使用率に大きな値を設定することをお勧めします。

  • Freeable memory — DB インスタンスで使用可能な RAM の量 (メガバイト単位)。Neptune には独自のメモリマネージャーがあるため、このメトリクスは予想よりも低くなる可能性があります。インスタンスクラスをより多くの RAM を持つクラスにアップグレードすることを検討する必要があるという良い兆候となるのは、クエリが頻繁にメモリ不足の例外をスローする場合です。

[モニタリング] タブのメトリクスの CPU、メモリ、メトリクスの 75% 地点に赤い線でマークされています。インスタンスのメモリ消費が頻繁にこの限界を超える場合は、ワークロードを確認し、クエリのパフォーマンスを向上させるためにインスタンスをアップグレードすることを検討してください。

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

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

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

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

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

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

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

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

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

注記

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

大きいインスタンスサイズを使用してデータをロードするには
  1. 単一の r5.12xlarge インスタンスでクラスターを作成します。このインスタンスはプライマリ DB インスタンスです。

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

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

  3. Bulk Loader コマンドで、“parallelism” : “OVERSUBSCRIBE” を含め、Neptune に利用可能なすべての CPU リソースをロードに使用するように指示します (Neptune ローダーのリクエストパラメータ 参照)。ロードオペレーションは I/O が許す限り高速に進み、通常は CPU リソースの 60 ~ 70% を必要とします。

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

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

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

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

現在のライターインスタンスをリードレプリカインスタンスに意図的にフェイルオーバーするために使用する Neptune 管理 API は、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") を使用している場合、ローダーはすでに正常にロードされたファイルをスキップし、中断が発生したときにまだロードされていなかったファイルのロードを再開します。