翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Neo4j から Neptune へのアプリケーションの移行
Neo4j から Neptune にデータを移行したら、次のステップはアプリケーション自体を移行することです。データと同様に、アプリケーションを移行する方法は、使用するツール、要件、アーキテクチャの違いなどに基づいて複数あります。このプロセスで通常考慮する必要がある事項を以下に概説します。
## Neo4j から Neptune に移行する際の接続の移行
現在 Bolt ドライバーを使用していない場合、または代替ドライバーを使用したい場合は、返されたデータへのフルアクセスを提供する [HTTPS エンドポイント](access-graph-opencypher-queries.md)に接続できます。
[Bolt プロトコル](access-graph-opencypher-bolt.md)を使用するアプリケーションがある場合は、これらの接続を Neptune に移行し、Neo4j で行ったのと同じドライバーを使用してアプリケーションを接続することができます。Neptune に接続するには、アプリケーションに次の 1 つ以上の変更を加える必要がある場合があります。
+ URL とポートは、クラスターエンドポイントとクラスターポート (デフォルトは 8182) を使用するように更新する必要があります。
+ Neptune では、すべての接続で SSL を使用する必要があるため、接続ごとに暗号化を指定する必要があります。
+ Neptune は [IAM ポリシーとロール](iam-auth.md)の割り当てを通じて認証を管理します。IAM ポリシーとロールによって、アプリケーション内のユーザー管理を非常に柔軟に行うことができるため、クラスターを設定する前に「[IAM の概要](iam-auth.md)」の情報を読んで理解することが重要です。
+ [Neptune での Bolt 接続動作](access-graph-opencypher-bolt.md#access-graph-opencypher-bolt-connections) で説明されているように、Neptune と Neo4j では Bolt 接続の動作がいくつかの点で異なります。
+ 詳細な情報は、「[OpenCypher と Bolt を使用した Neptune のベストプラクティス](best-practices-opencypher.md)」にあります。
Java、Python、.NET、NodeJS などの一般的に使用される言語のコードサンプルと、IAM 認証の使用などの接続シナリオのコードサンプルについては、「[Bolt プロトコルを使用して openCypher クエリを Neptune に作成する](access-graph-opencypher-bolt.md)」を参照してください。
## Neo4j から Neptune に移行する際のクラスターインスタンスへのクエリのルーティング
Neo4j クライアントアプリケーションは[ルーティングドライバー](https://neo4j.com/docs/driver-manual/1.7/client-applications/#routing_drivers_bolt_routing)を使用し、[アクセスモード](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-access-mode)を指定して読み取り/書き込みリクエストを因果クラスター内の適切なサーバーにルーティングします。
クライアントアプリケーションを Neptune に移行するときには、[Neptune エンドポイント](feature-overview-endpoints.md)を使用して、クエリをクラスター内の適切なインスタンスに効率的にルーティングします。
+ Neptune へのすべての接続は、URL で `bolt+routing://` または `neo4j://` ではなく `bolt://` を使用する必要があります。
+ クラスターエンドポイントはクラスターの現在のプライマリインスタンスに接続します。クラスターエンドポイントを使用して、書き込みリクエストをプライマリにルーティングします。
+ リーダーエンドポイントは、クラスター内のリードレプリカインスタンス間で[接続を分散します](best-practices-general-basic.md#best-practices-general-loadbalance)。リードレプリカインスタンスのない単一インスタンスのクラスターを使用している場合、リーダーエンドポイントは書き込み操作をサポートするプライマリインスタンスに接続します。クラスターに 1 つ以上のリードレプリカインスタンスが含まれている場合、リーダーエンドポイントに書き込みリクエストを送信すると、例外が生成されます。
+ クラスター内の各インスタンスは、独自のインスタンスエンドポイントを持つこともできます。クライアントアプリケーションがクラスター内の特定のインスタンスにリクエストを送信する必要がある場合は、インスタンスエンドポイントを使用してください。
詳細については、「[Neptune エンドポイントに関する考慮事項](feature-overview-endpoints.md#feature-overview-endpoint-considerations)」を参照してください。
## Neptune でのデータ整合性
Neo4j 因果クラスターを使用する場合、リードレプリカは最終的にコアサーバーと一致しますが、クライアントアプリケーションは[因果連鎖](https://neo4j.com/docs/driver-manual/1.7/sessions-transactions/#driver-transactions-causal-chaining)を使用することで因果の一貫性を確保できます。因果連鎖では、トランザクション間でブックマークを渡す必要があるため、クライアントアプリケーションはコアサーバーに書き込みを行い、リードレプリカから独自の書き込みを読み取ることができます。
Neptune では、リードレプリカインスタンスは最終的にライターと一致し、レプリカの遅延は通常 100 ミリ秒未満です。ただし、変更が複製されるまでは、既存のエッジと頂点の更新、および新しいエッジと頂点の追加は、レプリカインスタンスでは確認できません。そのため、アプリケーションが Neptune 上で各書き込みを読み取ることで即時整合性を保つ必要がある場合は、書き込み後の読み取り操作にクラスターエンドポイントを使用してください。クラスターエンドポイントを読み取り操作で使用するのは、このときだけです。それ以外の場合は、読み取りにはリーダーエンドポイントを使用してください。
## Neo4j から Neptune へのクエリの移行
Neptune が [openCypher をサポート](https://aws.amazon.com/blogs/database/announcing-the-general-availability-of-opencypher-support-for-amazon-neptune/)しているため、Neo4j からクエリを移行するのに必要な作業量は大幅に減りますが、移行の際にはまだ評価すべき相違点がいくつかあります。
+ [データモデルの最適化](migration-data-migration.md#migration-data-model-optimization) で説明したように、Neptune 用に最適化されたグラフデータモデルを作成するために、データモデルに変更を加える必要がある場合があります。そのためには、クエリとテストを変更する必要があります。
+ Neo4j は、Neptune によって実装された openCypher 仕様には含まれていない, さまざまな Cypher 固有の言語拡張を提供しています。ユースケースと使用する機能によっては、openCypher 言語内、Gremlin 言語の使用、または [Neptune 上の openCypherで実行するように Cypher クエリを書き直す](migration-opencypher-rewrites.md) で説明されているその他のメカニズムによる回避策がある場合があります。
+ 多くの場合、アプリケーションは Bolt ドライバーそのものではなく、他のミドルウェアコンポーネントを使用してデータベースとやり取りします。[Neptune の Neo4j との互換性](migration-compatibility.md) を参照して、使用しているツールやミドルウェアがサポートされているかどうかを確認してください。
+ フェイルオーバーが発生した場合、接続に提供されたクラスターエンドポイントが IP アドレスに解決されたために、Bolt ドライバーは以前のライターまたはリーダーインスタンスに接続し続ける可能性があります。[フェイルオーバー後の新しい接続の作成](best-practices-opencypher.md#best-practices-opencypher-renew-connection) で説明されているように、アプリケーションでの適切なエラー処理によって、これに対処する必要があります。
+ 解決できない競合またはロック待機タイムアウトのためにトランザクションがキャンセルされると、Neptune は `ConcurrentModificationException` で応答します。詳細については、「[エンジンエラーコード](errors-engine-codes.md)」を参照してください。ベストプラクティスとして、クライアントは常にこれらの例外をキャッチして処理する必要があります。
`ConcurrentModificationException` は、複数のスレッドや複数のアプリケーションが同時にシステムに書き込みを行っているときに発生することがあります。[トランザクションの分離レベル](transactions-neptune.md#transactions-neptune-mutation)により、このような競合が避けられない場合があります。
+ Neptune は、同じデータに対する Gremlin クエリと openCypher クエリの両方の実行をサポートしています。つまり、シナリオによっては、より強力なクエリ機能を備えた Gremlin を使用してクエリの機能の一部を実行することを検討する必要があるかもしれません。
[ インフラストラクチャーのプロビジョニングをします。](migration-provisioning-infrastructure.md) で説明したように、インスタンス数、インスタンスサイズ、クラスタートポロジがすべてアプリケーションの特定のワークロードに合わせて最適化されるように、アプリケーションごとに適切なサイジングを行う必要があります。
ここで説明したアプリケーションの移行に関する考慮事項は最も一般的なものですが、すべてを網羅しているわけではありません。アプリケーションはそれぞれ一意であるためです。さらに質問がある場合は、AWS サポートに連絡するか、アカウントチームに連絡してください。
## Neo4j に固有の機能やツールの移行
Neo4j には、アプリケーションが依存する可能性のある機能を備えたさまざまなカスタム機能とアドオンがあります。この機能を移行する必要性を評価する場合、同じ目標を達成するためのより優れたアプローチが AWS 内にあるかどうかを調べると役立つことがよくあります。[Neo4j と Neptune のアーキテクチャの違い](migration-architectural-differences.md)を考慮すると、他の AWS サービスや[統合](integrations.md)を活用する効果的な代替案が見つかることがよくあります。
Neo4j 固有の機能と推奨回避策のリストについては、「[Neptune の Neo4j との互換性](migration-compatibility.md)」を参照してください。