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

# Lambda で Gremlin 読み取りリクエストを使用するための推奨事項
<a name="lambda-functions-gremlin-read-recommendations"></a>

クラスター内に 1 つ以上のリードレプリカがある場合は、これらのレプリカ間で読み取りリクエストのバランスを取ることをお勧めします。1 つのオプションは、[リーダーエンドポイント](feature-overview-endpoints.md)を使うことです。リーダーエンドポイントは、レプリカを追加または削除する、またはレプリカを新しいプライマリインスタンスにするときにクラスタトポロジが変更された場合でも、レプリカ間の接続のバランスをとります。

ただし、リーダーエンドポイントを使用すると、状況によってはクラスタリソースの不均等な使用が発生する可能性があります。リーダーエンドポイントのラウンドロビンルーティングを実行するには、DNS エントリがポイントするホストを変更します。DNS エントリが変更される前にクライアントが多くの接続を開くと、すべての接続要求が単一の Neptune インスタンスに送信されます。これは、Lambda 関数への多数の同時リクエストによって複数の実行コンテキストが作成され、それぞれが独自の接続を持つ高スループットの Lambda シナリオの場合です。これらの接続がすべてほぼ同時に作成されている場合、接続はすべてクラスタ内の同じレプリカを指し、実行コンテキストがリサイクルされるまでそのレプリカを指し続けます。

インスタンス間でリクエストを分散する方法の 1 つは、リーダーエンドポイントではなく、レプリカインスタンスのエンドポイントのリストからランダムに選択されたインスタンスエンドポイントに接続するように Lambda 関数を設定することです。この方法の欠点は、クラスターを監視し、クラスターのメンバーシップが変更されるたびにエンドポイントリストを更新することで、クラスタートポロジの変更を処理する Lambda コードが必要であることです。

クラスター内のインスタンス間で読み取りリクエストのバランスを取る Java Lambda 関数を作成する場合は、クラスタートポロジを認識しており、Neptune クラスター内のインスタンスのセット間で接続とリクエストを公平に分散する Java Gremlin クライアントである、[Amazon Neptune の Gremlin クライアント](https://github.com/aws/neptune-gremlin-client)を使用できます。[このブログ投稿](https://aws.amazon.com/blogs/database/load-balance-graph-queries-using-the-amazon-neptune-gremlin-client/)には、Amazon Neptune 用の Gremlin クライアントを使用するサンプル Java Lambda 関数が含まれています。