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

# AWS Lambda と Amazon Neptune Gremlinを一緒に使用する際の推奨事項
<a name="lambda-functions-gremlin-recommendations"></a>

ここでは、関数呼び出しごとに 1 つではなく、Lambda 実行コンテキストのライフタイム全体に 1 つの接続とグラフトラバーサルソースを使用することをお勧めします (すべての関数の呼び出しは 1 つのクライアントリクエストのみを処理します)。同時クライアント要求は、別々の実行コンテキストで実行される異なる関数インスタンスによって処理されるため、関数インスタンス内の同時リクエストを処理するために、接続のプールを維持する必要はありません。使用している Gremlin ドライバに接続プールがある場合は、接続を 1 つだけ使用するように構成します。

接続エラーを処理するには、各クエリで再試行ロジックを使用します。実行コンテキストの存続期間中、単一の接続を維持することが目的ですが、予期しないネットワークイベントによってその接続が突然終了する可能性があります。このような接続障害は、使用しているドライバによって異なるエラーとして現れます。Lambda 関数をコーディングして、これらの接続の問題を処理し、必要に応じて再接続を試みる必要があります。

一部の Gremlin ドライバは再接続を自動的に処理します。たとえば、Java ドライバは、クライアントコードの代わりに Neptune への接続を自動的に再確立しようとします。このドライバでは、関数コードを戻してクエリを再試行するだけで済みます。これに対し、JavaScript および Python ドライバは自動再接続ロジックを実装しないため、これらのドライバでは、関数コードがバックオフ後に再接続を試み、接続が再確立された後にのみクエリを再試行する必要があります。

ここでのコード例には、クライアントがそれを処理していると仮定するのではなく、再接続ロジックが含まれています。

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

Lambda 関数がグラフデータを変更する場合は、バックオフと再試行戦略を採用して、次の例外を処理することを検討してください。
+ **`ConcurrentModificationException`** — Neptune トランザクションセマンティクスは、書き込み要求が `ConcurrentModificationException` で失敗することがあるということを意味しています。このような状況では、指数バックオフベースの再試行メカニズムを試してください。
+ ** `ReadOnlyViolationException`** —クラスタートポロジは、計画されたイベントまたは計画外のイベントによっていつでも変更される可能性があるため、書き込み責任がクラスタ内のインスタンスから別のインスタンスに移行することがあります。関数コードが、プライマリ (ライター) インスタンスでなくなったインスタンスに書き込みリクエストを送信しようとすると、リクエストは `ReadOnlyViolationException` で失敗します。この場合、既存の接続を閉じて、クラスターエンドポイントに再接続してから、リクエストを再試行します。

また、バックオフと再試行戦略を使用して書き込みリクエストの問題を処理する場合は、作成リクエストと更新リクエストの冪等クエリを実装することを検討してください (たとえば、次を使用。[fold().coalesce().unfold()](http://kelvinlawrence.net/book/Gremlin-Graph-Guide.html#upsert)。

# 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 関数が含まれています。

# Neptune Gremlin Lambda 関数のコールドスタートを遅らせる可能性がある要因
<a name="lambda-functions-gremlin-cold-start-recommendations"></a>

初めて AWS Lambda 関数が呼び出されることを、コールドスタートと呼びます。コールドスタートのレイテンシーを増加させる要因はいくつかあります。
+ **必ず Lambda 関数に十分なメモリを割り当ててください。**  — コールドスタート中のコンパイルは、Lambda 関数の場合、EC2 よりも大幅に遅くなる可能性があります。関数に割り当てる[メモリに比例して直線的に](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html)AWS Lambda が CPU サイクルを割り当てるからです。1,769 MB では、関数は 1 つのフル vCPU (1 秒あたりのクレジットの 1 vCPU 秒) 相当量を受信します。十分な CPU サイクルを受信するのに十分なメモリを割り当てないことの影響は、Java で記述された大規模な Lambda 関数で特に顕著です。
+ **[IAM データベース認証の有効化](iam-auth-enable.md)によりコールドスタートが遅くなる可能性があることに注意する** – AWS Identity and Access Management (IAM) データベース認証では、特に Lambda 関数で新しい署名キーを生成する必要がある場合に、コールドスタートが遅くなる可能性があります。このレイテンシーはコールドスタートにのみ影響し、後続のリクエストには影響しません。これは、IAM DB 認証が接続認証情報を確立すると、Neptune が定期的にそれらの認証情報がまだ有効であることを検証するだけだからです。