翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Neptune データベースの管理 このセクションでは、 と を使用して Neptune DB クラスターを管理 AWS マネジメントコンソール および維持する方法について説明します AWS CLI。 Neptune は、レプリケーショントポロジに接続されているデータベースサーバーのクラスター上で動作します。そのため、Neptune を管理するには、複数のサーバーへの変更をデプロイし、すべての Neptune レプリカがプライマリサーバーで維持されていることを確認する必要があります。 Neptune では、データの増加に伴い、基本となるストレージを透過的にスケーリングしているため、Neptune の管理に必要なディスクストレージの管理は比較的わずかです。同様に、Neptune では、継続的バックアップが自動的に行われるため、Neptune クラスターでは、バックアップの実行に伴う過度な計画やダウンタイムは必要ありません。 **Topics** + [Neptune ブルー/グリーンソリューションを使用してブルーグリーンアップデートを実行する](neptune-BG-deployments.md) + [Neptune のアクセス許可を持つ IAM ユーザーの作成](manage-console-iam-user.md) + [Amazon Neptune パラメータグループ](parameter-groups.md) + [Amazon Neptune パラメータ](parameters.md) + [を使用した Neptune DB クラスターの起動 AWS マネジメントコンソール](manage-console-launch-console.md) + [Amazon Neptune DB クラスターの停止と開始](manage-console-stop-start.md) + [高速リセット API を使用して Amazon Neptune DB クラスターを空にする](manage-console-fast-reset.md) + [DB クラスターに Neptune リーダーインスタンスを追加する](manage-console-add-replicas.md) + [コンソールを使用して Neptune リーダーインスタンスを作成する](manage-console-create-replica.md) + [コンソールを使用した Neptune DB クラスターの変更](manage-console-modify.md) + [Amazon Neptune でのパフォーマンスとスケーリング](manage-console-performance-scaling.md) + [Amazon Neptune DB クラスター内のレプリカの数の Auto-scaling](manage-console-autoscaling.md) + [Amazon Neptune DB クラスターのメンテナンス](cluster-maintenance.md) + [CloudFormation テンプレートを使用して Neptune DB クラスターのエンジンバージョンを更新する](cfn-engine-update.md) + [Neptune のデータベースのクローン化](manage-console-cloning.md) + [Amazon Neptune インスタンスの管理](manage-console-instances.md) # Neptune ブルー/グリーンソリューションを使用してブルーグリーンアップデートを実行する Amazon Neptune エンジンのアップグレードでは、更新のインストールと検証中はデータベースが使用できないため、アプリケーションのダウンタイムが必要になる場合があります。これは、手動で開始されたか自動で開始されたかに関係なく当てはまります。 Neptune は、 CloudFormation スタックを使用して実行できる Blue/Green デプロイソリューションを提供し、このようなダウンタイムを大幅に短縮します。ブルー本番環境と同期したグリーンステージング環境が構築されます。その後、そのステージング環境を更新して、エンジンのマイナーまたはメジャーバージョンアップグレード、グラフデータモデルの変更、またはオペレーティングシステムの更新を実行し、結果をテストできます。最後に、ダウンタイムをほとんど発生させずに、すぐに本番環境に切り替えることができます。 Neptune ブルー/グリーンソリューションには、次の図に示すように 2 つのフェーズがあります。 ![\[ブルーグリーンデプロイ戦略の大まかなフロー図\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/BG-flow.png) **フェーズ 1 では、本番クラスターと同じグリーン DB クラスターを作成します。** このソリューションでは、一意のブルー/グリーンデプロイ識別子と、本番クラスターと同じクラスタートポロジを使用して DB クラスターを作成します。つまり、DB インスタンスの数とサイズ、パラメータグループ、および設定は、本番 (ブルー) DB クラスターと同じですが、指定したターゲットエンジンバージョンにアップグレードされる点が異なります。ターゲットエンジンのバージョンは、現在の (ブルー) エンジンバージョンよりも高い必要があります。ターゲットのマイナーエンジンバージョンとメジャーエンジンバージョンを指定できます。必要に応じて、ソリューションは指定されたターゲットエンジンバージョンに到達するために必要な中間アップグレードを実行します。この新しいクラスターはグリーンステージング環境になります。 **フェーズ 2 では、継続的なデータ同期を設定します。** グリーン環境が完全に準備されると、ソリューションは Neptune ストリームを使用してソース (ブルー) クラスターとターゲット (グリーン) クラスター間の連続レプリケーションを設定します。これらの間のレプリケーションの差がゼロになると、ステージング環境をテストできる状態になります。その時点で、レプリケーションの遅延がこれ以上発生しないように、ブルークラスターへの書き込みを一時停止する必要があります。 ターゲットエンジンのバージョンには、アプリケーションに影響する新しい機能や依存関係が含まれている可能性があります。[「エンジンリリース」](engine-releases.md)の下にあるターゲットエンジンリリースのページとそれに続くエンジンリリースのページをチェックして、現在のエンジンバージョンから何が変更されたかを確認してください。本番環境に昇格する前に、グリーンクラスターで統合テストを実行するか、アプリケーションを手動で検証するのが最善です。 グリーンクラスターで変更をテストして検証したら、アプリケーションのデータベースエンドポイントをブルークラスターからグリーンクラスターに切り替えるだけです。 スイッチオーバー後、Neptune ブルー/グリーンソリューションは古いブルー本番環境を削除しません。必要に応じて引き続きアクセスして、追加の検証やテストを行うことができます。削除しない限り、そのインスタンスには標準の請求料金が適用されます。Blue/Green ソリューションは、通常の料金で請求されるコストである他の AWS サービスも使用します。使い終わったソリューションを削除する方法の詳細については、[クリーンアップセクション](neptune-BG-cleanup.md)で説明しています。 ## Neptune ブルー/グリーンスタックを実行するための前提条件 Neptune ブルー/グリーンスタックを起動する前に: + 本番 (ブルー) クラスターで [Neptune ストリームを有効に](streams-using.md)します。 + ブルークラスターのすべてのインスタンスが**使用可能**状態になっている必要があります。インスタンスの状態は、[Neptune コンソール](https://console.aws.amazon.com/neptune)で、または [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-instances.html) API を使用して確認することができます。 + また、すべてのインスタンスは [DB クラスターパラメータグループ](parameter-groups.md)と同期している必要があります。 + Neptune ブルー/グリーンソリューションでは、ブルークラスターが配置されている VPC に DynamoDB VPC エンドポイントが必要です。「[Amazon VPC エンドポイントを使用して DynamoDB にアクセスする](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/network-isolation.html#vpc-endpoints-dynamodb)」を参照してください。 + ブルー本番 DB クラスターの書き込みワークロードができるだけ軽くなる時間帯を選んで、ソリューションを実行します。例えば、一括ロードが行われるときや、その他の理由で大量の書き込み操作が行われる可能性があるときには、ソリューションを実行しないでください。 # CloudFormation テンプレートを使用して Neptune ブルー/グリーンソリューションを実行する AWS CloudFormation を使用して Neptune ブルー/グリーンソリューションをデプロイできます。CloudFormation テンプレートは、ブルーソース Neptune データベースと同じ VPC に Amazon EC2 インスタンスを作成し、そこにソリューションをインストールして実行します。「[進行状況のモニタリング](neptune-BG-monitoring.md)」で説明されているように、CloudWatch ログで進行状況をモニタリングできます。 これらのリンクを使用してソリューションテンプレートを確認するか、**起動スタック**ボタンを選択して CloudFormation コンソールで起動できます。 | | | | | --- |--- |--- | | [表示](https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [デザイナーで表示](https://console.aws.amazon.com/cloudformation/designer/home?templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?stackName=NeptuneBG&templateURL=https://aws-neptune-customer-samples-us-east-1.s3.amazonaws.com/neptune-bg/bg.yaml) | コンソールで、ウィンドウの右上にあるドロップダウンからソリューションを実行する AWS リージョンを選択します。 スタックパラメータを次のように設定します。 + **`DeploymentID`** — 各 Neptune ブルー/グリーンデプロイに固有の識別子。 グリーン DB クラスター識別子として、またデプロイ時に作成された新しいリソースに名前を付けるためのプレフィックスとしても使用されます。 + **`NeptuneSourceClusterId`** - アップグレードしようとしているブルー DB クラスターの識別子。 + **`NeptuneTargetClusterVersion:`** — ブルー DB クラスターをアップグレードする [Neptune エンジンのバージョン](engine-releases.md)。 これは、現在のブルー DB クラスターのエンジンバージョンよりも新しいバージョンである必要があります。 + **`DeploymentMode`** — これが新しいデプロイなのか、以前のデプロイを再開しようとしているのかを示します。以前のデプロイと同じ `DeploymentID` を使用している場合は、`DeploymentMode` を `resume` に設定します。 有効な値は `new` (デフォルト) と `resume` です。 + **`GraphQueryType`** — データベースのグラフデータタイプ。 有効な値は `propertygraph` (デフォルト) と `rdf` です。 + **`SubnetId`** — ブルー DB クラスターが配置されているのと同じ VPC のサブネット ID。(「[同じ VPC の Amazon EC2 インスタンスから Neptune DB クラスターに接続する](get-started-connect-ec2-same-vpc.md)」を参照)。 [EC2 Connect](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Connect-using-EC2-Instance-Connect.html) 経由でインスタンスに SSH 接続する場合は、パブリックサブネットの ID を指定します。 + **`InstanceSecurityGroup`** - Amazon EC2 インスタンス用のセキュリティグループ。 セキュリティグループはブルー DB クラスターにアクセスできる必要があり、インスタンスに SSH 接続できる必要があります。「[VPC コンソールを使用してセキュリティグループを作成する](get-started-vpc.md#security-vpc-security-group)」を参照してください。 スタックが完了するまで待ちます。完了するとすぐにソリューションが開始されます。その後、次のセクションで説明するように、CloudWatch ログを使用してデプロイプロセスをモニタリングできます。 # Neptune ブルー/グリーンデプロイの進捗状況の監視 Neptune ブルー/グリーンソリューションの進行状況をモニタリングするには、[CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)にアクセスして、`/aws/neptune/(Neptune Blue/Green deployment ID)` CloudWatch ロググループのログを確認します。CloudWatch ログへのリンクは、ソリューションの CloudFormation スタックの出力にあります。 ![\[ブルー/グリーン CloudFormation スタック出力のスクリーンショット\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/BG-stack-output.png) スタックパラメータとしてパブリックサブネットを指定した場合は、スタックの一部として作成された Amazon EC2 インスタンスに SSH 接続して、`/var/log/cloud-init-output.log` でログを参照することもできます。 ログには、次のスクリーンショットに示すように、Neptune ブルー/グリーンソリューションによって実行されたアクションが表示されます。 ![\[Neptune ブルー/グリーンのログ画面のスクリーンショット\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/BG-log-screenshot.png) ログメッセージには、ブルーおよびグリーンクラスター間の同期ステータスが表示されます。 ![\[Neptune ブルー/グリーンソリューションログメッセージのスクリーンショット\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/BG-log-messages.png) 同期プロセスでは、ブルークラスターの最新のストリーム `eventID` と、Neptune-to-Neptune レプリケーションスタックによって作成された DynamoDB チェックポイントテーブルにあるレプリケーションチェックポイントとの差を計算することにより、レプリケーションラグがチェックされます。これらのメッセージを使用して、現在のレプリケーションの違いを監視できます。 # 本番環境のブルークラスターから更新されたグリーンクラスターへのカットオーバー グリーンクラスターを本番環境に昇格させる前に、ブルークラスターとグリーンクラスターのコミットの差がゼロであることを確認し、ブルークラスターへの書き込みトラフィックをすべて無効にします。データベースエンドポイントをグリーンクラスターに切り替える際にブルークラスターへの書き込みが続行していると、両方のクラスターに部分的なデータを書き込むことによってデータが破損する可能性があります。まだ読み取りトラフィックを無効にする必要はないかもしれません。 ソース (ブルー) クラスターで IAM 認証を有効にしている場合は、アプリケーションで使用している IAM ポリシーをグリーンクラスターを指すように更新してください (このようなポリシーの例については、この「[無制限のアクセスポリシー](iam-data-access-examples.md#iam-auth-data-policy-example-general)」を参照してください)。 書き込みトラフィックを無効にした後、レプリケーションが終了するのを待ってから、グリーンクラスターで (ブルークラスターではなく) 書き込みトラフィックを有効にします。また、読み取りトラフィックをブルークラスターからグリーンクラスターに切り替えます。 # Neptune ブルー/グリーンソリューションが完了した後のクリーンアップ ステージング (グリーン) クラスターを本番環境に昇格させたら、Neptune ブルー/グリーンソリューションによって作成されたリソースをクリーンアップします。 + ソリューションを実行するために作成された Amazon EC2 インスタンスを削除します。 + グリーンクラスターをブルークラスターと同期させた [Neptune ストリームベースのレプリケーション](streams-consumer-setup.md)の CloudFormation テンプレートを削除します。メインのテンプレートは以前に指定したスタック名であり、もう 1 つはデプロイ ID の後に「-replication」が続きます (つまり、`(DeploymentID)-replication`)。 CloudFormation テンプレートを削除しても、クラスター自体は削除されません。グリーンクラスターが期待どおりに動作していることを確認したら、ブルークラスターを手動で削除する前に、オプションでスナップショットを取ることができます。 # Neptune ブルー/グリーンソリューションのベストプラクティス + グリーンクラスターを本番環境に切り替える前に、正常に機能していることを十分に検証する必要があります。データベースのデータと設定の一貫性をチェックしてください。新しいエンジンバージョンによっては、クライアントのアップグレードも必要になる場合があります。アップグレードする前に、エンジンのリリースノートを確認してください。本番環境でブルー/グリーンのアップグレードを開始する前に、開発、テスト、および実稼働前の環境で、これらすべてをテストする価値があります。 + ブルーサーバーからグリーンサーバーへの切り替えは、メンテナンス時間帯に行うのがベストです。 + アップグレードと同期後にすべてが正常に機能していることを確認するには、元のクラスターを一定期間保持してから削除することをお勧めします。予期しない問題が発生したときに役立つことがあります。 + Neptune ブルー/グリーンソリューションを実行するときは、一括読み込みなどの負荷の高い書き込み操作は避けてください。レプリケーションラグが発生し、大幅なダウンタイムが発生する可能性があるためです。ブルークラスターへの書き込みをオフにしてからグリーンクラスターでオンにするまでの時間は、ほんの数分であることが理想的です。 # Neptune ブルー/グリーンソリューションのトラブルシューティング 以下の情報は、既存のクラスターとの競合、Neptune ストリームを有効にする必要性、進行中の一括ロードオペレーション、バージョン互換性要件など、ブルー/グリーンソリューションのデプロイプロセス中に発生する可能性のある問題に焦点を当てています。これらの潜在的な問題に対処することで、Neptune ブルー/グリーンソリューションのデプロイをスムーズかつ正常に行うことができます。 **Neptune ブルー/グリーンソリューションによって発生したエラー** + **`Cluster with id = (blue_green_deployment_id) already exists`** — 識別子 *(blue\$1green\$1deployment\$1id)* が付いた既存のクラスターがあります。 クラスターが前回の Neptune ブルー/グリーンの実行で作成された場合は、新しいデプロイ ID を指定するか、デプロイモードを `resume` に設定します。 + **`Streams should be enabled on the source Cluster for Blue Green Deployment`** — ブルー (ソース) クラスターで [Neptune ストリーム](streams-using-enabling.md)を有効にします。 + **`No Bulkload should be in progress on source cluster: (cluster_id)`** — Neptune ブルー/グリーンソリューションは、進行中の一括ロードを確認すると終了します。 これは、同期プロセスが書き込みに追いつくことができるようにするためです。Neptune ブルー/グリーンソリューションを開始する前に、進行中の一括ロードジョブを回避またはキャンセルしてください。 + **`Blue Green deployment requires instances to be in sync with db cluster parameter group`** — クラスターパラメータグループの変更は、DB クラスター全体で同期されている必要があります。「[Amazon Neptune パラメータグループ](parameter-groups.md)」を参照してください。 + **`Invalid target engine version for Blue Green Deployment`** — ターゲットエンジンバージョンは [Amazon Neptune のエンジンリリース](engine-releases.md) にアクティブとしてリストされている必要があり、ソース (ブルー) クラスターの現在のエンジンリリースよりも新しい必要があります。 # Neptune のアクセス許可を持つ IAM ユーザーの作成 Neptune コンソールにアクセスして Neptune DB クラスターを作成および管理するには、必要なすべてのアクセス許可を持つ IAM ユーザーを作成する必要があります。 最初のステップは、Neptune のサービスリンクロールポリシーを作成することです。 ## Amazon Neptune のサービスリンクロールポリシーを作成する 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。 1. 左側のナビゲーションペインで、**[ポリシー]** を選択します。 1. **[ポリシー]** ページで、**[ポリシーの作成]** を選択します。 1. **[ポリシーの作成]** ページで **[JSON]** タブを選択し、以下のサービスリンクロールポリシーをコピーします。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": "iam:CreateServiceLinkedRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS", "Condition": { "StringLike": { "iam:AWSServiceName":"rds.amazonaws.com" } } } ] } ``` ------ 1. **[次へ: タグ]** を選択し、**[タグの追加]** ページで **[次へ: レビュー]** を選択します。 1. **[ポリシーのレビュー]** ページで、新しいポリシーに「NeptuneServiceLinked」という名前を付けます。 サービスにリンクされたロールの詳細については、「[Amazon Neptune のサービスにリンクされたロールの使用](security-iam-service-linked-roles.md)」を参照してください。 ## 必要なすべてのアクセス許可を持つ新しい IAM ユーザーを作成する 次に、必要なアクセス許可を付与する、作成したサービスリンクロールポリシー (ここでは `NeptuneServiceLinked` という名前) とともに、適切な管理ポリシーがアタッチされた新しい IAM ユーザーを作成します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。 1. 左側のナビゲーションペインで **[ユーザー]** を選択し、**[ユーザー]** ページで **[ユーザーの追加]** を選択します。 1. **ユーザーの追加**ページで、新しい IAM ユーザーの名前を入力し、**アクセスキー - 認証情報タイプのプログラムアクセス**を選択し、**次へ: アクセス許可**を選択します。 AWS 1. **[アクセス許可の設定]** ページの **[ポリシーのフィルタリング]** ボックスに「Neptune」と入力します。次に、表示されるポリシーから以下を選択します。 + **NeptuneFullAccess** + **NeptuneConsoleFullAccess** + **NeptuneServiceLinked** (以前に作成したサービスリンクロールポリシーにその名前を付けたと仮定します)。 1. 次に、**[ポリシーのフィルタリング]** ボックスに「Neptune」の代わりに「VPC」と入力します。リストされたポリシーから **[AmazonVPCFullAccess]** を選択します。 1. **[次へ: タグ]** を選択し、**[タグの追加]** ページで **[次へ: レビュー]** を選択します。 1. **[レビュー]** ページで、以下のすべてのポリシーが新しいユーザーにアタッチされていることを確認します。 + **NeptuneFullAccess** + **NeptuneConsoleFullAccess** + **NeptuneServiceLinked** + **AmazonVPCFullAccess** 次に、**[ユーザーの作成]** を選択します。 1. 最後に、新しいユーザーのアクセスキー ID とシークレットアクセスキーをダウンロードして保存します。 Amazon Simple Storage Service (Amazon S3) など、他のサービスとの相互運用には、さらにアクセス許可と信頼関係を追加する必要があります。 # Amazon Neptune パラメータグループ パラメータグループの[パラメータ](parameters.md)を使用して、Amazon Neptune のデータベース設定を管理します。パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値の*コンテナ*として機能します。 DB クラスターのパラメータグループと、いわゆる DB パラメータグループという、2 つのタイプの DB パラメータグループがあります。 + *DB パラメータグループ*は、インスタンスレベルで適用され、通常 Neptune グラフエンジンに関連付けられています (例: `neptune_query_timeout` パラメータ)。 + *DB クラスターのパラメータグループ*は、クラスター内のすべてのインスタンスに適用され、通常、より広範な設定があります。すべての Neptune クラスターは、DB クラスターパラメータグループに関連付けられます。そのクラスター内の各 DB インスタンスは、DB クラスターのパラメータグループに含まれるエンジン設定値を継承します。 DB クラスターパラメータグループで変更した設定値は、DB パラメータグループのデフォルト値を上書きします。DB パラメータグループ内の対応する値を編集すると、これらの値によって DB クラスターパラメータグループの設定が上書きされます。 カスタム DB パラメータグループを指定せずに DB インスタンスを作成した場合は、デフォルトの DB パラメータグループが使用されます。デフォルトの DB パラメータグループのパラメータ設定を変更することはできません。代わりに、デフォルトのパラメーター設定を変更するには、新しい DB パラメータグループを作成する必要があります。DB エンジンのすべてのパラメータを、作成した DB パラメータグループで変更できるわけではありません。 パラメータグループは、特定の Neptune エンジンバージョンと互換性のあるファミリーで作成されます。新しいメジャーまたはマイナーエンジンバージョンにアップグレードする場合、そのバージョンの対応するパラメータグループファミリーを使用してカスタムパラメータグループを再作成する必要がある場合があります。 パラメータグループファミリーの命名は`neptuneX.Y`パターン に従います。 はエンジンバージョン`X.Y`と一致します。例えば、次のようになります。 + `neptune1` – 1.2.0.0 より前のエンジンバージョンの場合 + `neptune1.2` – エンジンバージョン 1.2.x の場合 + `neptune1.3` – エンジンバージョン 1.3.x の場合 + `neptune1.4` – エンジンバージョン 1.4.x の場合 Neptune クラスターをアップグレードするときは、ターゲットエンジンバージョンの[リリースノート](engine-releases.md)をチェックして、新しいパラメータグループファミリーが必要かどうかを確認します。その場合は、アップグレードする前に新しいファミリー内のすべてのカスタムパラメータグループを再作成する必要があります。 Neptune のパラメータには、静的なものと動的なものがあります。違いは次のとおりです。 **静的パラメータ** + 静的パラメータは、DB インスタンスが再起動された後にのみ有効になるパラメータです。言い換えると、静的パラメータを変更してインスタンスの DB パラメータグループを保存したとき、パラメータの変更を有効にするには、DB インスタンスを手動で再起動する必要があります。現在、Neptune インスタンスレベルのパラメータ (DB クラスターパラメータグループではなく DB パラメータグループ内) はすべて静的です。 + クラスターレベルの静的パラメータを変更して、DB クラスターのパラメータグループを保存したとき、パラメータの変更は、クラスター内のすべての DB インスタンスを手動で再起動した後に有効になります。 **動的パラメータ** + 動的パラメータとは、パラメータグループ内のパラメータが更新されたほぼ直後に有効になるパラメータです。つまり、動的パラメータを更新した後、DB インスタンスを再起動しなくてもパラメータの変更が有効になります。 + 動的クラスターパラメータの変更がすべての DB インスタンスに適用されるまで、多少の遅延が予想されます。 + 更新された動的パラメータ値は、現在実行中のリクエストには適用されず、変更が行われた後に送信されたリクエストにのみ適用されます。 + クラスターレベルの動的パラメータを変更すると、デフォルトでは、パラメータの変更は直ちに DB クラスターに適用され、再起動を必要としません。クラスター内の DB インスタンスが再起動されるまでパラメータの変更を延期するには、 AWS CLI を使用してパラメータ変更`pending-reboot`の `ApplyMethod`を に設定します。 現在、以下の新しいクラスターパラメータを除くすべてのパラメータは静的です。 + `neptune_enable_slow_query_log` (クラスターレベル) + `neptune_slow_query_log_threshold` (クラスターレベル) DB パラメータグループのパラメータを使用する際に、注意する必要がある重要な点を以下に示します。 + DB パラメータグループに不適切な設定のパラメータがあると、パフォーマンスが低下したりシステムが不安定になったり、予期しない悪影響が生じることがあります。データベースパラメータの変更時には常に注意が必要です。DB パラメータグループの変更前にデータをバックアップしてください。テスト DB インスタンスでパラメータグループの設定の変更を試してから、本稼働 DB インスタンスにそれらの変更を適用します。 + DB インスタンスに関連付けられている DB パラメータグループを変更する場合、DB インスタンスで新しい DB パラメータグループを使用する前に、インスタンスを手動で再起動する必要があります。 **注記** [リリース: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md) より前は、DB クラスター内のすべてのリードレプリカインスタンスは、プライマリ (ライター) インスタンスが再起動するたびに自動的に再起動されていました。 [リリース: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md) 以降では、プライマリインスタンスを再起動しても、レプリカインスタンスは再起動しません。つまり、クラスターレベルのパラメータを変更する場合、パラメータの変更を反映するには、各インスタンスを個別に再起動する必要があります。 ## DB クラスターパラメータグループまたは DB パラメータグループの編集 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインの [**Parameter Groups**] (パラメータグループ) を選択します。 1. 編集する DB パラメータグループの [**Name**] (名前) リンクを選択します。 (オプション) [**Create parameter group**] (パラメータグループの作成) を選択して、新しいクラスターのパラメータグループを作成しその新しいグループを作成します。その後、その新しいパラメータグループの [**Name**] (名前) を選択します。 **重要** デフォルトの DB クラスターのパラメータグループしかない場合、このステップは*必須*です。デフォルトの DB クラスターのパラメータグループは変更できないためです。 1. パラメータを検索し、**[名前]** 列の横にある **[値]** フィールドをクリックします。 1. 許可された値を入力し、[値] フィールドの横にあるチェックを選択します。 1. **[Save changes]** (変更の保存) をクリックします。 1. DB クラスターパラメータを変更する場合は、Neptune クラスター内のすべての DB インスタンスを再起動し、DB インスタンスパラメータを変更する場合は 1 つ以上の特定のインスタンスを再起動します。 ## DB パラメータグループまたは DB クラスターパラメータグループの作成 Neptune コンソールを使用して、新しいパラメータグループを簡単に作成できます。 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. 左のナビゲーションペインの [**Parameter Groups**] (パラメータグループ) を選択します。 1. [**Create DB parameter group**] (DB パラメータグループの作成) を選択します。 [**Create DB parameter group**] (DB パラメータグループの作成) ページが表示されます。 1. **パラメータグループファミリー**リストで、ターゲット Neptune エンジンのバージョン (neptune**1.2、neptune1.****3**、**neptune1.4 など**) に一致するファミリーを選択します。 1. **[タイプ]** リストで、**[DB パラメータグループ]** または **[DB クラスターのパラメータグループ]** を選択します。 1. [**グループ名**] ボックスに、新しい DB パラメータグループの名前を入力します。 1. [**説明**] ボックスに、新しい DB パラメータグループの説明を入力します。 1. **[作成]** を選択します。 また、 AWS CLIを使用して、新しいパラメーターグループを作成することもできます。 ``` aws neptune create-db-parameter-group \ --db-parameter-group-name (a name for the new DB parameter group) \ --db-parameter-group-family (the family matching your engine version, such as neptune1.2, neptune1.3, or neptune1.4) \ --description (a description for the new DB parameter group) ``` # Amazon Neptune パラメータ [パラメータグループ](parameter-groups.md)のパラメータを使用して Amazon Neptune のデータベース設定を管理します。Neptune データベースの設定には次のパラメータを利用できます。 **クラスターレベルのパラメータ** + [neptune\$1enable\$1audit\$1log](#parameters-db-cluster-parameters-neptune_enable_audit_log) + [neptune\$1enable\$1slow\$1query\$1log](#parameters-db-cluster-parameters-neptune_enable_slow_query_log) + [neptune\$1slow\$1query\$1log\$1threshold](#parameters-db-cluster-parameters-neptune_slow_query_log_threshold) + [neptune\$1lab\$1mode](#parameters-db-cluster-parameters-neptune_lab_mode) + [neptune\$1query\$1timeout](#parameters-db-cluster-parameters-neptune_query_timeout) + [neptune\$1streams](#parameters-db-cluster-parameters-neptune_streams) + [neptune\$1streams\$1expiry\$1days](#parameters-db-cluster-parameters-neptune_streams_expiry_days) + [neptune\$1lookup\$1cache](#parameters-db-cluster-parameters-neptune_lookup_cache) + [neptune\$1autoscaling\$1config](#parameters-db-cluster-parameters-neptune_autoscaling_config) + [neptune\$1ml\$1iam\$1role](#parameters-db-cluster-parameters-neptune_ml_iam_role) + [neptune\$1ml\$1endpoint](#parameters-db-cluster-parameters-neptune_ml_endpoint) + [neptune\$1enable\$1inline\$1server\$1generated\$1edge\$1id](#parameters-db-cluster-parameters-neptune_inline_edge_id)   **インスタンスレベルのパラメータ** + [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) + [neptune\$1query\$1timeout](#parameters-instance-parameters-neptune_query_timeout) + [neptune\$1result\$1cache](#parameters-db-instance-parameters-neptune_result_cache) + [UndoLogPurgeConfig](#parameters-db-instance-parameters-undo_log_purge_config)   **廃止されたパラメータ** + [neptune\$1enforce\$1ssl](#parameters-db-cluster-parameters-neptune_enforce_ssl) ## `neptune_enable_audit_log` (クラスターレベルパラメータ) このパラメータは、Neptune の監査ログを切り替えます。 指定できる値は `0` (無効) と `1` (有効) です。デフォルト値は `0` です。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 [CLI を使用して Neptune 監査ログを CloudWatch Logs に発行する](cloudwatch-logs.md#cloudwatch-logs-cli) で説明されているように、監査ログを Amazon CloudWatch に公開できます。 ## `neptune_enable_slow_query_log` (クラスターレベルパラメータ) このパラメーターを使用して、Neptune の[スロークエリロギング](slow-query-logs.md)機能を有効または無効にします。 これは動的パラメータです。つまり、値を変更しても DB クラスターを再起動する必要はなく、再起動の原因にもなりません。 許可された値は次のとおりです: + **`info`** — スロークエリロギングを有効にし、パフォーマンスの低下の原因となっている可能性のある特定の属性をログに記録します。 + **`debug`** — スロークエリロギングを有効にし、実行されたクエリで使用可能なすべての属性をログに記録します。 + **`disabled`** — スロークエリロギングを無効にします。 デフォルト値は `disabled` です。 [CLI を使用して Neptune スロークエリログを CloudWatch Logs に発行する](cloudwatch-logs.md#cloudwatch-slow-query-logs-cli) で説明されているように、スロークエリログを Amazon CloudWatch に公開できます。 ## `neptune_slow_query_log_threshold` (クラスターレベルパラメータ) このパラメータは、実行時間のしきい値をミリ秒単位で指定します。この値を過ぎると、クエリはスロークエリとみなされます。[スロークエリロギング](slow-query-logs.md)が有効になっている場合、このしきい値より長く実行されたクエリは、一部の属性とともにログに記録されます。 デフォルト値は 5,000 ミリ秒 (5 秒) です。 これは動的パラメータです。つまり、値を変更しても DB クラスターを再起動する必要はなく、再起動の原因にもなりません。 ## `neptune_lab_mode` (クラスターレベルパラメータ) 設定すると、このパラメータにより Neptune の特定の実験機能が有効になります。現在利用可能な実験機能については、「[Neptune ラボモード](features-lab-mode.md)」を参照してください。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 実験機能を有効または無効にするには、このパラメータに *(機能名)*`=enabled` または *(機能名)*`=disabled` を含めます。次のようにコンマで区切って、複数の機能を有効または無効にすることができます。 *(機能 \$11 名)*`=enabled,`*(機能 \$12 名)*`=enabled` ラボモード機能は、通常、デフォルトで無効化されます。例外は `DFEQueryEngine` 機能で、[Neptune エンジンリリース 1.0.5.0](engine-releases-1.0.5.0.md) からはクエリヒント (`DFEQueryEngine=viaQueryHint`) で使用するためにデフォルトで有効になりました。[Neptune エンジンリリース 1.1.1.0](engine-releases-1.1.1.0.md) 以降、DFE エンジンはラボモードではなくなり、インスタンスの DB パラメータグループの [neptune\$1dfe\$1query\$1engine](#parameters-instance-parameters-neptune_dfe_query_engine) インスタンスパラメータを使用して制御されるようになりました。 ## `neptune_query_timeout` (クラスターレベルパラメータ) グラフクエリの特定のタイムアウト時間をミリ秒単位で指定します。 指定できる値の範囲は `10`～`2,147,483,647` (231 - 1) です。デフォルト値は `120,000` (2 分) です。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 複数のタイムアウト設定 (クラスターレベル、インスタンスレベル、クエリごとの) が設定されている場合、次の表にどのタイムアウト値が優先されるかを示します。 | クラスター PG | インスタンス PG | クエリヒント | 結果 | | --- | --- | --- | --- | | デフォルト | デフォルト | なし | クラスター | | カスタム | デフォルト | なし | クラスター | | カスタム | カスタム | なし | インスタンス | | デフォルト | カスタム | なし | インスタンス | | いずれか | すべて | lowest | クエリ | | デフォルト | カスタム | 最小ではない | インスタンス | | カスタム | デフォルト | 最小ではない | クラスター | | カスタム | カスタム | 最小ではない | インスタンス | **注記** 特にサーバーレスインスタンスでは、クエリのタイムアウト値を高く設定しすぎると、予期しないコストが発生する可能性があります。妥当なタイムアウト設定がないと、クエリは予想よりもはるかに長く実行され続け、予想もしなかったコストが発生する可能性があります。これは、クエリの実行中に大規模で高価なインスタンスタイプにスケールアップする可能性があるサーバーレスインスタンスに特に当てはまります。 ほとんどのクエリに対応し、異常に長い実行でもタイムアウトが発生するだけのクエリタイムアウト値を使用することで、このような予期しない出費を回避できます。 ## `neptune_streams` (クラスターレベルパラメータ) [Neptune Streams](streams.md) を有効または無効にします。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 指定できる値は `0` (無効、デフォルト)、および `1` (有効) です。 ## `neptune_streams_expiry_days` (クラスターレベルパラメータ) サーバーがストリームレコードを削除するまでの日数を指定します。 有効な値は `1`～`90` です。デフォルトは `7` です。 このパラメータは[エンジンバージョン 1.2.0.0](engine-releases-1.2.0.0.md) で導入されました。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 ## `neptune_lookup_cache` (クラスターレベルパラメータ) `R5d` インスタンスで [Neptune lookup cache.](feature-overview-lookup-cache.md) を無効化または最有効化します。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 指定できる値は `1` (有効) と `0` (無効) です。デフォルト値は `0` ですが、DB クラスター内に `R5d` インスタンスが作成される際は常に、`neptune_lookup_cache` パラメータは自動的に `1` に設定され、そのインスタンスにルックアップキャッシュが作成されます。 ## `neptune_autoscaling_config` (クラスターレベルパラメータ) [Neptune auto-scaling](manage-console-autoscaling.md) が作成し管理するリードレプリカインスタンスの構成パラメータを設定します。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 `neptune_autoscaling_config` パラメータの値として設定した JSON 文字列を使用して以下を指定できます。 + 作成するすべての新しいリードレプリカインスタンスに対して Neptune auto-scaling が使用するインスタンスタイプ。 + これらのリードレプリカに割り当てられたメンテナンスウィンドウ。 + すべての新しいリードレプリカに関連付けるタグ。 JSON 文字列には、次のような構造があります。 ``` "{ \"tags\": [ { \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" }, { \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" }, ], \"maintenanceWindow\" : \"wed:12:03-wed:12:33\", \"dbInstanceClass\" : \"db.r5.xlarge\" }" ``` 文字列内の引用符はバックスラッシュ文字 (`\`) を使ってエスケープする必要があります。 `neptune_autoscaling_config` パラメータで指定されていない 3 つの構成設定のいずれかは、DB クラスターのプライマリライターインスタンスの設定からコピーされます。 ## `neptune_ml_iam_role` (クラスターレベルパラメータ) Neptune ML で使用される IAM ロール ARN を指定します。値には、有効な IAM ロール ARN を指定できます。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 機械学習のためにグラフ上でデフォルトの IAM ロール ARN を指定できます。 ## `neptune_ml_endpoint` (クラスターレベルパラメータ) Neptune ML に使用するエンドポイントを指定します。値には任意の有効な [SageMaker AI エンドポイント名](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateEndpoint.html#sagemaker-CreateEndpoint-request-EndpointName)を指定できます。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 機械学習のためにグラフ上でデフォルトの SageMaker AI エンドポイントを指定できます。 ## `neptune_enable_inline_server_generated_edge_id` (クラスターレベルパラメータ) Neptune インラインサーバー生成 Edge ID 機能を有効または無効にします。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 指定できる値は `1` (有効) と `0` (無効) です。デフォルト値は `0` です。 ## `neptune_dfe_query_engine` (インスタンスレベルパラメータ) [Neptune エンジンリリース 1.1.1.0](engine-releases-1.1.1.0.md) 以降、この DB インスタンスパラメータは [DFE クエリエンジン](neptune-dfe-engine.md)の使用方法を制御するために使用されます。許容値は、次のとおりです。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 + **`enabled`** — `useDFE` クエリヒントが存在し、`false` に設定されている場合を除き、可能な限り DFE エンジンを使用するようにします。 + **`viaQueryHint`** (デフォルト) — DFE エンジンは、`true` に設定された `useDFE` クエリヒントを明示的に含むクエリにのみ使用されます。 このパラメータが明示的に設定されていない場合、インスタンスの起動時にデフォルト値の `viaQueryHint` が使用されます。 **注記** すべての openCypher クエリは、このパラメータがどのように設定されているかにかかわらず, DFE エンジンによって実行されます。 リリース 1.1.1.0 より前のリリースでは、これは DB インスタンスパラメータではなくラボモードパラメータでした。 ## `neptune_query_timeout` (インスタンスレベルパラメータ) この DB インスタンスパラメータでは、1 つのインスタンスのグラフクエリのタイムアウト時間をミリ秒単位で指定します。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 指定できる値の範囲は `10`～`2,147,483,647` (231 - 1) です。デフォルト値は `120,000` (2 分) です。 **注記** 特にサーバーレスインスタンスでは、クエリのタイムアウト値を高く設定しすぎると、予期しないコストが発生する可能性があります。妥当なタイムアウト設定がないと、クエリは予想よりもはるかに長く実行され続け、予想もしなかったコストが発生する可能性があります。これは、クエリの実行中に大規模で高価なインスタンスタイプにスケールアップする可能性があるサーバーレスインスタンスに特に当てはまります。 ほとんどのクエリに対応し、異常に長い実行でもタイムアウトが発生するだけのクエリタイムアウト値を使用することで、このような予期しない出費を回避できます。 ## `neptune_result_cache` (インスタンスレベルパラメータ) **`neptune_result_cache`** — この DB インスタンスパラメータは、[クエリ結果の使用](gremlin-results-cache.md) を有効化または無効化します。 このパラメータは静的です。つまり、このパラメータを変更しても、再起動するまでどのインスタンスにも反映されません。 指定できる値は `0` (無効、デフォルト)、および `1` (有効) です。 ## `UndoLogPurgeConfig` (インスタンスレベルパラメータ) **`UndoLogPurgeConfig`** – Neptune で積極的な UndoLog パージを有効または無効にするには、このパラメータを使用します。 使用できる値は、元に戻すログの消去に標準スレッド数を使用する `default` と、元に戻すログのクリーンアップを迅速化するためにスレッド数を増やす `aggressive` です。`agressive` オプションを選択すると、`NumUndoPagesPurged` メトリクスのハガー値が観測されることが予想されます。 ## `neptune_enforce_ssl` (非推奨のクラスターレベルパラメータ) (**廃止**) かつては Neptune への HTTP 接続を許可するリージョンがあり、このパラメータが 1 に設定されている場合、すべての接続に HTTPS を使用するよう強制するために使用されました。ただし、Neptune はすべてのリージョンで HTTPS 接続のみを受け入れるようになったため、このパラメータはもはや関連しません。 # を使用した Neptune DB クラスターの起動 AWS マネジメントコンソール 新しい Neptune DB クラスターを起動する最も簡単な方法は、「」で説明されているように、必要なすべてのリソースを作成する CloudFormation テンプレートを使用することです[Neptune クラスターを作成する](get-started-create-cluster.md)。 必要に応じて、ここで説明するように、Neptune コンソールを使用して新しい DB クラスターを手動で起動することもできます。 **注記** Neptune コンソールにアクセスして Neptune クラスターを作成するには、十分なアクセス許可を持つユーザーが必要です。現在のユーザーにこれらのアクセス許可がない場合は、「[Neptune のアクセス許可を持つ IAM ユーザーの作成](manage-console-iam-user.md)」で説明されているように、必要なアクセス許可を持つ IAM ユーザーを作成できます。 ユーザーが正しいアクセス許可を持っていることを確認した後、または正しいアクセス許可を持つユーザーを作成したら、その IAM ユーザー AWS マネジメントコンソール として にログインし、以下の手順に従って新しい DB クラスターを作成します。 **コンソールを使用して Neptune DB クラスターを起動するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. **[データベース]** の **[クラスター]** ページに移動し、**[データベースの作成]** を選択すると、**[データベースの作成]** ページが開きます。 1. **[設定]** で、新しい DB クラスターの名前を入力するか、そこに表示されているデフォルト名を受け入れます。この名前はインスタンスのエンドポイントアドレスで使用され、次の制約を満たす必要があります。 + 1 ～ 63 文字の英数字またはハイフンを使用する必要があります。 + 1 字目は文字である必要があります。 + ハイフンを、文字列の最後に使用したり、2 つ続けて使用したりすることはできません。 + 特定の AWS リージョンの AWS アカウント内のすべての DB インスタンスで一意である必要があります。 1. **[テンプレート]** で、**[実稼働]** または **[開発とテスト]** のいずれかを選択します。 1. **[DB インスタンスサイズ]** で、インスタンスサイズを選択します。これによって、新しい DB クラスターのプライマリ書き込みインスタンスの処理およびメモリ容量が決まります。 **[実稼働]** テンプレートを選択した場合、一覧に表示されている使用可能なメモリ最適化クラスからしか選択できませんが、**[開発とテスト]** を選択した場合は、より経済的なバースタブルクラスから選択することもできます (バースタブルクラスの説明については [T3 バースト可能インスタンス](manage-console-instances-t3.md) を参照)。 **注記** Neptune は`R4`インスタンスタイプをサポートしなくなりました。 1. **[可用性と耐久性]** で、マルチアベイラビリティーゾーン (マルチ AZ) デプロイを有効にするかどうかを選択できます。実稼働テンプレートでは、デフォルトでマルチ AZ 配置が有効ですが、開発およびテストテンプレートでは有効になっていません。マルチ AZ 配置が有効になっている場合、Neptune は、可用性を高めるために、さまざまなアベイラビリティーゾーン (AZ) に作成したリードレプリカインスタンスを配置します。 1. **[接続]** で、新しい DB クラスターをホストする仮想プライベートクラウド (VPC) を使用可能な選択肢から選択します。Neptune に自動的に VPC を作成させる場合は、ここで **[新しい VPC を作成]** を選択できます。Neptune インスタンスにアクセスするには、この同じ VPC 内に Amazon EC2 インスタンスを作成する必要があります (詳細については、[Amazon VPC による Amazon Neptune データベースの保護](security-vpc.md) を参照)。DB クラスターの作成後は VPC を変更できないことに注意してください。 必要に応じて、**[その他の接続設定]** でクラスターの接続をさらに設定できます。 1. **[サブネットグループ]** で、新しい DB クラスターで使用する Neptune DB サブネットグループを選択できます。VPC にサブネットグループがまだない場合は、Neptune によって DB サブネットグループが作成されます ([Amazon VPC による Amazon Neptune データベースの保護](security-vpc.md) を参照)。 1. **[VPC セキュリティグループ]** で、新しい DB クラスターへのネットワークアクセスを保護する既存の VPC セキュリティグループを 1 つ以上選択するか、Neptune に作成してもらいたい場合は **[新規作成]** を選択して、新しい VPC セキュリティグループの名前を指定します ([VPC コンソールを使用してセキュリティグループを作成する](get-started-vpc.md#security-vpc-security-group) を参照)。 1. **[データベースポート]** で、データベースがアプリケーション接続に使用する TCP/IP ポートを入力します。Neptune は、デフォルトとしてポート番号 `8182` を使用します。 1. Neptune ワークベンチで Jupyter Notebook を Neptune に自動的に作成させる場合は、**[ノートブック設定]** で **[ノートブックの作成]** を選択します ([グラフノートブックでの Amazon Neptune の使用](graph-notebooks.md) および [Neptune ワークベンチを使用して Neptune ノートブックをホストする](graph-notebooks.md#graph-notebooks-workbench) を参照)。次に、新しいノートブックの設定方法を選択できます。 1. **[ノートブックインスタンスタイプ]** で、ノートブックで使用できるインスタンスクラスの中から選択します。 1. **[ノートブック名]** に、ノートブックの名前を入力します。 1. 必要に応じて、**[説明 - オプション]** にノートブックの説明を入力することもできます。 1. **[IAM ロール名]** で、Neptune にノートブック用の IAM ロールを作成させることを選択して、新しいロールの名前を入力するか、使用可能なロールの中から既存の IAM ロールを選択します。 1. 最後に、ノートブックをインターネットに直接接続するか、Amazon SageMaker AI 経由で接続するか、NAT ゲートウェイを備えた VPC 経由で接続するかを選択します。詳細については、「[ノートブックインスタンスを VPC 内のリソースに接続する](https://docs.aws.amazon.com/sagemaker/latest/dg/appendix-notebook-and-internet-access.html)」を参照してください。 1. **[タグ]** で、最大 50 個のタグを新しい DB クラスターに関連付けることができます。 1. **[追加設定]** には、新しい DB クラスターに対して行うことができる設定が他にもあります (多くの場合、スキップしてデフォルト値をそのまま使用できます)。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/manage-console-launch-console.html) 1. **[データベースの作成]** を選択して、新しい Neptune DB クラスターとそのプライマリインスタンスを起動します。 Amazon Neptune コンソールでは、新しい DB クラスターが DB クラスターのリストに表示されます。DB クラスターが作成されて使用できるようになるまで、DB クラスターのステータスは [**作成中**] となります。ステータスが [**使用可能**] に変わったら、DB クラスターのプライマリインスタンスに接続できます。DB インスタンスクラスと割り当てられたストレージによっては、新しいインスタンスを使用できるようになるまで数分かかることがあります。 新しく作成したクラスターを表示するには、Neptune コンソールで **[データベース]** ビューを選択します。 **注記** を使用して DB クラスター内のすべての Neptune DB インスタンスを削除すると AWS マネジメントコンソール、コンソールは自動的に DB クラスター自体を削除します。 AWS CLI または SDK を使用している場合は、最後のインスタンスを削除した後に DB クラスターを手動で削除する必要があります。 **[クラスターエンドポイント]** の値をメモしておきます。この値は、Neptune DB クラスターに接続する際に必要になります。 # Amazon Neptune DB クラスターの停止と開始 Amazon Neptune クラスターの停止と開始は、開発とテスト環境のコスト管理に役立ちます。クラスターを使用するたびに、すべての DB インスタンスを設定および解放するのではなく、クラスターですべての DB インスタンスを一時的に停止することができます。 **Topics** + [Neptune DB クラスターの停止と開始の概要](#manage-console-start-stop-overview) + [Neptune DB クラスターの停止](#manage-console-stopping) + [停止した Neptune DB クラスターの開始](#manage-console-start) ## Neptune DB クラスターの停止と開始の概要 Neptune クラスターが必要ではない期間は、そのクラスターですべてのインスタンスを一度に停止することができます。クラスターを使用する必要がある時はいつでもクラスターを開始できます。開始と停止は、継続的な可用性を必要としない開発、テスト、または類似のアクティビティに使用されるクラスターのセットアップと解放のプロセスを簡素化します。これは、クラスター内のインスタンスの数に関係なく、1 つのアクション AWS マネジメントコンソール で で実行できます。 DB クラスターの停止中は、指定された保持期間内のクラスターストレージ、手動のスナップショット、および自動化されたバックアップストレージに対してのみ課金されます。DB インスタンス時間に対しては請求されません。 Neptune は、7 日後に DB クラスターを自動的に開始するため、必要なメンテナンスの更新が遅れ過ぎてしまうことはありません。 ライトにロードされた Neptune クラスターの料金を最小限に抑えるために、そのリードレプリカのすべてを削除するのはなくクラスターを停止することができます。複数のインスタンスまたは 2 つのインスタンスを持つクラスターの場合、DB インスタンスを頻繁に削除して再作成することは、 AWS CLI または Neptune API を使用してのみ実用的であり、削除を正しい順序で実行することも難しい場合があります。たとえば、フェイルオーバーメカニズムのアクティブ化を避けるためには、プライマリインスタンスを削除する前にすべてのリードレプリカを削除する必要があります。 DB クラスターの実行を維持する必要があるが、容量を減らしたい場合は、開始と停止を使用しないでください。クラスターのコストが高すぎる、または非常にビジー状態でない場合は、1 つ以上の DB インスタンスを削除するか、より小さなインスタンスクラスを使用するように DB インスタンスを変更することはできますが、個別の DB インスタンスを停止することはできません。 ## Neptune DB クラスターの停止 しばらく使用しない場合は、実行中の Neptune DB クラスターを停止し、必要なときに再度開始できます。クラスターの停止中に、指定された保持期間内のクラスターストレージ、手動のスナップショット、および自動化されたバックアップストレージに対しては課金されますが、DB インスタンス時間に対しては課金されません。 停止オペレーションは、すべてのクラスターのリードレプリカインスタンスを停止してから、プライマリインスタンスを停止して、フェイルオーバーメカニズムのアクティブ化を回避します。 ### を使用した DB クラスターの停止 AWS マネジメントコンソール **を使用して Neptune クラスター AWS マネジメントコンソール を停止するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、[**クラスター**] を選択し、クラスターを選択します。このページで停止オペレーションを実行するか、停止する DB クラスターの詳細ページに移動します。 1. [**アクション**] で [**停止**] を選択します。 ### を使用した DB クラスターの停止 AWS CLI を使用して DB インスタンスを停止するには AWS CLI、[stop-db-cluster](api-clusters.md#StopDBCluster) コマンドを呼び出し、 `--db-cluster-identifier`パラメータを使用して停止する DB クラスターを識別します。 **Example** ``` aws neptune stop-db-cluster --db-cluster-identifier mydbcluster ``` ### Neptune 管理 API の使用による DB クラスターの停止 管理 API を使用して DB インスタンスを停止するには、[StopDBCluster](api-clusters.md#StopDBCluster) API を呼び出し、`DBClusterIdentifier` パラメータを使用して、停止する DB クラスターを指定します。 ### DB クラスターが停止している間に発生する処理 + スナップショットからクラスターを復元**できます** (「[DB クラスタースナップショットの復元](backup-restore-restore-snapshot.md)」を参照)。 + DB クラスターまたはその DB インスタンスの設定を変更することは**できません**。 + クラスターに対して DB インスタンスを追加または削除することは**できません**。 + まだ DB インスタンスが関連付けられている場合は、クラスターを削除**できません**。 + 通常、ほとんどの管理アクションを実行するには、停止した DB クラスターを再び開始する必要があります。 + Neptune は、スケジュールされたメンテナンスが再び開始されるとすぐに、クラスターに適用します。7 日後、Neptune は停止したクラスターを自動的に再開始するため、そのメンテナンス状態より過剰に遅れることはありません。 + Neptune は、停止した DB クラスターの自動バックアップを実行しません。これは、クラスターの停止中に基になるデータを変更できないためです。 + Neptune は、DB クラスターの停止中にそのバックアップ保持期間を延長しません。 ## 停止した Neptune DB クラスターの開始 開始できるのは、停止状態の Neptune DB クラスターのみです。クラスターを開始すると、すべての DB インスタンスが再び利用可能になります。クラスターは、エンドポイント、パラメータグループ、および VPC セキュリティグループなどの構成設定を保持します。 ### を使用して停止した DB クラスターを開始する AWS マネジメントコンソール 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、[**クラスター**] を選択し、クラスターを選択します。このページかで開始オペレーションを実行するか、DB クラスターの詳細ページに移動し、そこから開始します。 1. [**アクション**] で [**開始**] を選択します。 ### を使用して停止した DB クラスターを開始する AWS CLI を使用して停止した DB クラスターを開始するには AWS CLI、 `--db-cluster-identifier`パラメータを使用して [start-db-cluster](api-clusters.md#StartDBCluster) コマンドを呼び出し、起動する停止した DB クラスターを指定します。DB クラスターの作成時に選択したクラスター名を指定するか、最後に追加された `-cluster` で、選択した DB インスタンス名を使用します。 **Example** ``` aws neptune start-db-cluster --db-cluster-identifier mydbcluster ``` ### Neptune 管理 API を使用して、停止した DB クラスターを開始する Neptune 管理 API を使用して Neptune DB クラスターを開始するには、`DBCluster` パラメータを使用して [StartDBCluster](api-clusters.md#StartDBCluster) API を呼び出し、開始する DB クラスターを指定します。DB クラスターの作成時に選択したクラスター名を指定するか、最後に追加された `-cluster` で、選択した DB インスタンス名を使用します。 # 高速リセット API を使用して Amazon Neptune DB クラスターを空にする Neptune 高速リセット REST API を使用すると、Neptune グラフをすばやく簡単にリセットし、すべてのデータを削除できます。 これは、[%db\$1reset](#manage-console-fast-reset-db-reset-magic) ラインマジックを使用して、Neptune Notebook 内で行うことができます。 + ほとんどの場合、高速リセット操作は数分以内に完了します。期間は、オペレーションの開始時のクラスターの負荷によって多少異なる場合があります。 + 高速リセット操作では、I/O は追加されません。 + 高速リセット後、ストレージボリュームのサイズは縮小しません。代わりに、新しいデータが挿入されると、ストレージが再利用されます。つまり、高速リセット操作の前後に作成されるスナップショットのボリュームサイズは同じになります。高速リセット操作の前後に作成されたスナップショットを使用して復元されたクラスターのボリュームサイズも同じになります。 + リセットオペレーションの一環として、DB クラスター内のすべてのインスタンスが再起動されます。 **注記** まれな状況では、これらのサーバーの再起動によってクラスターのフェイルオーバーが発生することもあります。 **重要** 高速リセットを使用すると、Neptune DB クラスターと他のサービスの統合が壊れる可能性があります。例: 高速リセットは、データベースからすべてのストリームデータを削除し、ストリームを完全にリセットします。つまり、ストリームコンシューマーは新たな設定をしなければ動作しなくなる可能性があります。 高速リセットは、Neptune ML によって使用されている SageMaker AI リソースに関するすべてのメタデータ (ジョブやエンドポイントを含む) を削除します。これらは SageMaker AI には引き続き存在し、Neptune ML 推論クエリに既存の SageMaker AI エンドポイントを引き続き使用できますが、Neptune ML 管理 API はそれらでは機能しなくなります。 ElasticSearch とのフルテキスト検索統合などの統合も高速リセットによって消去され、再度使用する前に手動で確立する必要があります。 **API を使用して Neptune DB クラスターからすべてのデータを削除するには** 1. まず、データベースのリセットを実行するために使用できるトークンを生成します。この手順は、誰かが誤ってデータベースをリセットするのを防ぐためのものです。 これを行うには、DB クラスターのライターインスタンス上の `/system` エンドポイントに `HTTP POST` リクエストを送信し、`initiateDatabaseReset` アクションを指定します。 JSON コンテンツタイプを使用する `curl` コマンドは次のようになります。 ``` curl -X POST \ -H 'Content-Type: application/json' \ https://your_writer_instance_endpoint:8182/system \ -d '{ "action" : "initiateDatabaseReset" }' ``` または、`x-www-form-urlencoded` コンテンツタイプを使用します。 ``` curl -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ https://your_writer_instance_endpoint:8182/system \ -d 'action=initiateDatabaseReset ' ``` `initiateDatabaseReset` リクエストは JSON レスポンスで次のようにリセットトークンを返します。 ``` { "status" : "200 OK", "payload" : { "token" : "new_token_guid" } } ``` トークンは、発行後 1 時間（60 分）有効です。 リクエストをリーダーインスタンスまたはステータスエンドポイントに送信すると、Neptune は `ReadOnlyViolationException` をスローします。 `initiateDatabaseReset` リクエストを複数送信した場合、実際にリセットを実行する 2 番目のステップでは、生成された最新のトークンのみが有効になります。 サーバーが、`initiateDatabaseReset` リクエストの直後に再起動した場合、生成されたトークンが無効になるため、新しいトークンを取得するには新しいリクエストを送信する必要があります。 1. 次に、`initiateDatabaseReset` から戻ったトークンとともに `performDatabaseReset` リクエストを DB クラスターのライターインスタンス上の `/system` エンドポイントへ送ります。これにより、DB クラスターからすべてのデータが削除されます。 JSON コンテンツタイプを使用する `curl` コマンドは次のようになります。 ``` curl -X POST \ -H 'Content-Type: application/json' \ https://your_writer_instance_endpoint:8182/system \ -d '{ "action" : "performDatabaseReset", "token" : "token_guid" }' ``` または、`x-www-form-urlencoded` コンテンツタイプを使用します。 ``` curl -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ https://your_writer_instance_endpoint:8182/system \ -d 'action=performDatabaseReset&token=token_guid' ``` リクエストは JSON レスポンスを返します。リクエストが受け入れられる場合、応答は次のようになります。 ``` { "status" : "200 OK" } ``` 送信したトークンが発行されたトークンと一致しない場合、応答は次のようになります。 ``` { "code" : "InvalidParameterException", "requestId":"token_guid", "detailedMessage" : "System command parameter 'token' : 'token_guid' does not match database reset token" } ``` リクエストが受け入れられ、リセットが開始されると、サーバーは再起動してデータを削除します。DB クラスターのリセット中は、DB クラスターに他のリクエストを送信することはできません。 ## IAM-Auth での高速リセット API の使用 DB クラスターで Iam-Auth が有効になっている場合は、[awscurl](https://github.com/okigan/awscurl) を使用し、IAM-auth 認証される高速リセットコマンドを送信します。 **awscurl を使用して IAM-auth で高速リセットリクエストを送信する** 1. `AWS_ACCESS_KEY_ID` および `AWS_SECRET_ACCESS_KEY` 環境変数を正しく設定します (一時的な資格情報を使用している場合は `AWS_SECURITY_TOKEN` も設定します）。 1. `initiateDatabaseReset` リクエストは次のようになります。 ``` awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \ -H 'Content-Type: application/json' --region us-west-2 \ -d '{ "action" : "initiateDatabaseReset" }' ``` 1. `performDatabaseReset` リクエストは次のようになります。 ``` awscurl -X POST --service neptune-db "$SYSTEM_ENDPOINT" \ -H 'Content-Type: application/json' --region us-west-2 \ -d '{ "action" : "performDatabaseReset" }' ``` ## Neptune Workbench `%db_reset` ラインマジックを使用して DB クラスターをリセットする Neptune workbench は、Neptune ノートブックで高速なデータベースのリセットを実行できる `%db_reset` ラインマジックに対応しています。 パラメータなしでマジックを呼び出すと、クラスター内のすべてのデータを削除するかどうかを尋ねる画面が表示され、削除後にクラスターデータが利用できなくなることを確認するチェックボックスが表示されます。その時点で、先に進んでデータを削除するか、操作をキャンセルするかを選択できます。 もっと危険な選択肢は、`--yes` または `-y` オプションで `%db_reset` を呼び出すことで、これ以上のプロンプトを表示せずに削除が実行されます。 REST API と同様に、2 つのステップでリセットを実行することもできます。 ``` %db_reset --generate-token ``` レスポンスは次のとおりです。 ``` { "status" : "200 OK", "payload" : { "token" : "new_token_guid" } } ``` 次の操作を実行します。 ``` %db_reset --token new_token_guid ``` レスポンスは次のとおりです。 ``` { "status" : "200 OK" } ``` ## 高速リセット操作の一般的なエラーコード | Neptune エラーコード | HTTP ステータス | メッセージ | 例 | | --- | --- | --- | --- | | `InvalidParameterException` | 400 | システムコマンドパラメータ「*アクション*」にはサポートされていない値「*XXX*」があります | 無効なパラメータ | | `InvalidParameterException` | 400 | 次の値が多すぎます:*アクション* | 複数のアクションを含む高速リセットリクエストが「Content-type:application/x-www-form-urlencoded」のヘッダー付きで送信されました | | `InvalidParameterException` | 400 | フィールド「action」が重複しています | 複数のアクションを含む高速リセットリクエストが「Content-Type: application/json」のヘッダー付きで送信されました | | `MethodNotAllowedException` | 400 | 間違ったルート: /*bad\$1endpoint* | リクエストが間違ったエンドポイントに送信されました | | `MissingParameterException` | 400 | 必須パラメータがありません:[action] | 高速リセットリクエストには、必要な「action」パラメータが含まれていません | | `ReadOnlyViolationException` | 400 | リードレプリカインスタンスでの書き込みは許可されていません | 高速リセットリクエストがリーダーまたはステータスエンドポイントに送信されました | | `AccessDeniedException` | 403 | 認証トークンが見つかりません | IAM-Auth が有効になっている DB エンドポイントに、正しいシグニチャなしで高速リセットリクエストが送信されました | | `ServerShutdownException` | 500 | データベースのリセットが進行中です。クラスターが使用可能になったら、クエリを再試行してください。 | 高速リセットが開始されると、既存および着信する Gremlin/Sparql クエリはエラーとなります。 | # DB クラスターに Neptune リーダーインスタンスを追加する Neptune DB クラスターには、1 つのプライマリ DB インスタンスと最大 15 の Neptune リーダーインスタンスがあります。プライマリ DB インスタンスでは、読み書きオペレーションをサポートしており、クラスターボリュームに対してすべてのデータ変更を実行します。Neptune リーダーインスタンスは、プライマリ DB インスタンスと同じストレージボリュームに接続し、読み取りオペレーションのみサポートします。 リーダーインスタンスを使用して、プライマリ DB インスタンスから読み取りワークロードをオフロードします。 DB クラスターのプライマリインスタンスと Neptune リーダーを複数のアベイラビリティーゾーンに分散して、DB クラスターの可用性を改善することをお勧めします。 [次のセクション](manage-console-create-replica.md)では、DB クラスターにリーダーインスタンスを作成する方法について説明します。 # コンソールを使用して Neptune リーダーインスタンスを作成する Neptune DB DB クラスターのプライマリインスタンスを作成した後、Neptune コンソールを使用して、さらに Neptune リーダーインスタンスを追加できます。 **AWS マネジメントコンソール を使用して Neptune リーダーインスタンスを作成するには** 1. AWS マネジメントコンソールにサインインして Amazon Neptune コンソール ([https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home)) を開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. リーダーインスタンスを作成する DB クラスターを選択します。 1. **[アクション]** を選択し、**[リーダーを追加]** を選択します。 1. **[Create replica DB instance]** (レプリカ DB インスタンスの作成) ページで、Neptune レプリカのオプションを指定します。次の表は、Neptune リードレプリカの設定を示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/manage-console-create-replica.html) 1. Neptune レプリカインスタンスを作成するには、**[Create read replica]** (リードレプリカの作成) を選択します。 DB クラスターから Neptune リーダーインスタンスを削除するには、「[Amazon Neptune の DB インスタンスの削除](manage-console-instances-delete.md)」の説明に従います。 # コンソールを使用した Neptune DB クラスターの変更 を使用して DB インスタンスを変更する場合 AWS マネジメントコンソール、**すぐに適用**を選択して変更をすぐに適用できます。変更の即時適用を選択した場合は、新しい変更と、保留中の変更キューにあるすべての変更が一度に適用されます。 変更の即時適用を選択しない場合、この変更は保留中の変更キューに保存されます。次のメンテナンスウィンドウ実行中に、キューのすべての保留中の変更が適用されます。 **重要** ダウンタイムを必要とする保留中の変更がある場合、変更をすぐに適用するように選択すると、該当する DB インスタンスで予想外のダウンタイムが発生することがあります。DB クラスターの他の DB インスタンスではダウンタイムはありません。 **注記** Neptune で DB クラスターを変更する場合、**[Apply Immediately]** (すぐに適用) 設定による影響を受けるのは、**[DB cluster identifier]**、**[IAM DB authentication]** への変更のみです。その他の変更はすべて、**すぐに適用**設定の値に関係なく、ただちに適用されます。 **コンソールを使用してクラスターを変更するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、[**Clusters (クラスター)**] を選択して、変更する DB クラスターを選択します。 1. [**Actions**]、[**Modify cluster**] の順に選択します。[**DB クラスターの変更**] ページが表示されます。 1. 必要に応じて任意の設定を変更してください。 **注記** コンソールで、インスタンスレベルの変更は、現在の DB インスタンスにのみ適用される場合や、DB クラスター全体に適用される場合があります。インスタンスレベルで DB クラスター全体を変更する設定をコンソールで変更するには、「[DB クラスター内の DB インスタンスの変更](#manage-console-modify-instance)」の手順に従います。 1. すべての変更が正しいことを確認したら、[**Continue**] を選択して概要を確認します。 1. 変更をすぐに適用するには、[**すぐに適用**] を選択します。 1. 確認ページで、変更内容を確認します。正しい場合は、[**クラスターの変更**] を選択して変更を保存します。 変更を編集する場合は [**Back**] を選択し、変更をキャンセルする場合は [**Cancel**] を選択します。 ## DB クラスター内の DB インスタンスの変更 **コンソールを使用して DB クラスター内の DB インスタンスを変更するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで [**Instances**] を選択し、変更する DB インスタンスを選択します。 1. [**Instance actions**] を選択してから、[**Modify**] を選択します。[**Modify DB Instance**] ページが表示されます。 1. 必要に応じて任意の設定を変更してください。 **注記** 一部の設定は DB クラスター全体に適用されるため、クラスターレベルで変更する必要があります。これらの設定を変更するには、「[コンソールを使用した Neptune DB クラスターの変更](#manage-console-modify)」の手順に従います。 では AWS マネジメントコンソール、インスタンスレベルの変更の中には、現在の DB インスタンスにのみ適用されるものもあれば、DB クラスター全体に適用されるものもあります。 1. すべての変更が正しいことを確認したら、[**Continue**] を選択して概要を確認します。 1. 変更をすぐに適用するには、[**すぐに適用**] を選択します。 1. 確認ページで、変更内容を確認します。変更内容が正しい場合は、**[Modify DB Instance]** (DB インスタンスを変更) を選択して変更を保存します。 変更を編集する場合は [**Back**] を選択し、変更をキャンセルする場合は [**Cancel**] を選択します。 # Amazon Neptune でのパフォーマンスとスケーリング Neptune DB クラスターおよびインスタンスは、次の 3 つのレベルでスケーリングされます。 + [ストレージのスケーリング](#manage-console-performance-scaling-storage) + [インスタンススケーリング;](#manage-console-performance-scaling-instances) + [読み取りのスケーリング](#manage-console-performance-scaling-reads) ## Neptune でのストレージのスケーリング Neptune ストレージは、クラスターボリューム内のデータに合わせて自動的にスケーリングします。データが増大するに従って、クラスターボリュームストレージはサポートされている全リージョンで最大 128 TiB まで拡張されます。ただし、中国と GovCloud では 64 TiB に制限されています。 クラスターボリュームのサイズは 1 時間ごとにチェックされ、ストレージコストが決定されます。 Neptune データベースによって消費されるストレージは、毎月 GB 単位で課金され、消費される I/O は 100 万リクエスト単位で課金されています。料金は Neptune データベースで使用したストレージおよび IO の分のみ発生し、事前にプロビジョニングする必要はありません。 料金の情報については、[Neptune の製品ページ](https://aws.amazon.com/neptune/pricing)を参照してください。 ## Neptune でのインスタンススケーリング DB クラスター内の各 DB インスタンスの DB インスタンスクラスを変更することで、必要に応じて Neptune DB クラスターをスケーリングできます。Neptune は、いくつかの最適化された DB インスタンスクラスをサポートしています。 ## Neptune での読み込みのスケーリング Neptune DB クラスターの読み取りのスケーリングは、最大 15 個の Neptune レプリカを DB クラスター内に作成することで実現できます。各 Neptune レプリカは、最小限のレプリカラグでクラスターボリュームから同じデータを返します (多くの場合、このラグは、プライマリインスタンスが更新を書き込んだ後、100 ミリ秒を大幅に下回ります)。読み取りトラフィックが増えたら、追加の Neptune レプリカを作成し、それらに直接接続することで DB クラスターの読み取りワークロードを分散できます。Neptune レプリカの DB インスタンスクラスは、プライマリイスタンスと同じものである必要はありません。 DB クラスターに Neptune レプリカを追加する方法については、[リーダーインスタンスを追加する](manage-console-create-replica.md) を参照してください。 # Amazon Neptune DB クラスター内のレプリカの数の Auto-scaling Neptune 自動スケーリングを使用すると、DB クラスター内の Neptune レプリカの数を自動的に調整して、接続およびワークロードの要件を満たすことができます。自動スケーリングを使用すると、Neptune DB クラスターでワークロードの増加を処理できます。その後、ワークロードが減少すると、自動スケーリングによって不要なレプリカが削除されるため、未使用の容量に対して料金が発生することはありません。 auto-scaling は、すでに 1 つのプライマリライターインスタンスと少なくとも 1 つのリードレプリカインスタンスを持つ Neptune DB クラスターでのみ使用できます ([Amazon Neptune DB クラスターとインスタンス](feature-overview-db-clusters.md) を参照)。また、クラスター内のすべての read-replica インスタンスが使用可能な状態である必要があります。read-replica が使用可能以外の状態にある場合、クラスター内のすべての read-replica が使用可能になるまで、Neptune 自動スケーリングは何もしません。 新しいクラスターを作成する必要がある場合は、[Neptune クラスターを作成する](get-started-create-cluster.md) を参照してください。 AWS CLI を使用して、[スケーリングポリシー](#manage-console-autoscaling-define-policy)を定義して DB クラスターに適用します。AWS CLI を使用して、自動スケーリングポリシーを編集または削除することもできます。ポリシーでは、次の自動スケーリングパラメータを指定します。 + クラスター内に存在するレプリカの最小数と最大数。 + レプリカ追加スケーリングアクティビティ間の `ScaleOutCooldown` 間隔、およびレプリカ削除スケーリングアクティビティ間の `ScaleInCooldown` 間隔。 + CloudWatch メトリクスとスケールアップまたはスケールダウンのメトリクストリガー値。 Neptune 自動スケーリングアクションの頻度は、いくつかの方法で抑えられます。 + 最初に、自動スケーリングでリーダーを追加または削除するには、`CPUUtilization` 高アラームを少なくとも 3 分間超えるか、低アラームを少なくとも 15 分間超える必要があります。 + その最初の追加または削除の後、その後の Neptune 自動スケーリングアクションの頻度は、自動スケーリングポリシーの `ScaleOutCooldown` および `ScaleInCooldown` 設定によって制限されます。 使用している CloudWatch メトリクスがポリシーで指定したしきい値に達し、前回の自動スケーリングアクションから `ScaleOutCooldown` 感覚が経過していて、DB クラスターに設定したレプリカの最大数にまだ達していない場合、Neptune 自動スケーリングは DB クラスターのプライマリインスタンスと同じインスタンスタイプを使用して新しいレプリカを作成します。 同様に、メトリクスが指定した下限しきい値に達し、前回の自動スケーリングアクションから `ScaleInCooldown` 間隔が経過し、DB クラスターに指定した最小レプリカ数を超えるレプリカがある場合、Neptune 自動スケーリングはレプリカの 1 つを削除します。 **注記** Neptune auto-scaling では、自身が作成したレプリカのみ削除されます。既存のレプリカは削除されません。 [neptune\$1autoscaling\$1config](parameters.md#parameters-db-cluster-parameters-neptune_autoscaling_config) DB クラスターパラメータを使用して、Neptune auto-scaling が作成する新しい read-replica のインスタンスタイプ、それらの read-replica のメンテナンスウィンドウ、および各新しい read-replica に関連付けるタグを指定することもできます。これらの構成設定は、`neptune_autoscaling_config` パラメータの JSON 文字列の値として次のように指定します。 ``` "{ \"tags\": [ { \"key\" : \"reader tag-0 key\", \"value\" : \"reader tag-0 value\" }, { \"key\" : \"reader tag-1 key\", \"value\" : \"reader tag-1 value\" }, ], \"maintenanceWindow\" : \"wed:12:03-wed:12:33\", \"dbInstanceClass\" : \"db.r5.xlarge\" }" ``` JSON 文字列内の引用符はすべてバックスラッシュ文字 (`\`) でエスケープする必要があります。文字列内のすべての空白は、通常どおり、任意です。 `neptune_autoscaling_config` パラメータで指定されていない 3 つの構成設定のいずれかは、DB クラスターのプライマリライターインスタンスの設定からコピーされます。 [自動スケーリング](https://docs.aws.amazon.com/autoscaling/plans/userguide/)が新しいリードレプリカインスタンスを追加する際、DB インスタンス ID の接頭句に `autoscaled-reader` (例えば、`autoscaled-reader-7r7t7z3lbd-20210828`) を付けます。また、作成するすべてのリードレプリカに、キー `autoscaled-reader` と `TRUE` の値でタグを追加します。このタグは AWS マネジメントコンソール の DB インスタンスの詳細ページの **[Tags]** (タグ) タブで確認できます。 ``` "key" : "autoscaled-reader", "value" : "TRUE" ``` auto-scaling によって作成されたすべての read-replica インスタンスのプロモーション層は、`15` デフォルトでは優先順位が最も低くなります。つまり、フェイルオーバー時には、手動で作成されたものなど、優先順位の高いレプリカが最初に昇格されます。「[Neptune DB クラスターの耐障害性](backup-restore-overview-fault-tolerance.md)」を参照してください。 Neptune auto-scaling は、定義済みメトリクスとして Neptune [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch メトリクスを使う[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)とともに Application Auto Scaling を使用して実装されています。 ## Neptune サーバーレス DB クラスターでの自動スケーリングの使用 Neptune サーバーレスは、需要がインスタンスの容量を超えたとき、Neptune 自動スケーリングよりもはるかに迅速に対応し、別のインスタンスを追加する代わりにインスタンスをスケールアップします。自動スケーリングが比較的安定したワークロードの増減に対応するように設計されているのに対して、サーバーレスは需要の急激な増加や変動への対応に優れています。 両者の長所を理解すれば、自動スケーリングとサーバーレスを組み合わせて、ワークロードの変化を効率的に処理し、コストを最小限に抑えながら需要を満たす柔軟なインフラストラクチャを構築できます。 自動スケーリングをサーバーレスと効果的に連携させるには、需要の急増や短期的な変化に対応できるように、[サーバーレスクラスターの `maxNCU` 設定を十分に高く設定する](neptune-serverless-capacity-scaling.md#neptune-serverless-capacity-range-max)ことが重要です。そうしないと、一時的な変更によってサーバーレススケーリングがトリガーされず、自動スケーリングによって不要な追加インスタンスが大量に発生する可能性があります。`maxNCU` を十分に高く設定すると、サーバーレススケーリングはそれらの変更をより迅速かつ低コストで処理できます。 ## Amazon Neptune auto-scaling を有効にする方法 自動スケーリングは、AWS CLI を使用する Neptune DB クラスターでのみ有効にできます。AWS マネジメントコンソール を使用して自動スケーリングを有効にすることはできません。 また、自動スケーリングは、次の Amazon リージョンではサポートされていません。 + アフリカ (ケープタウン): `af-south-1` + 中東 (アラブ首長国連邦): `me-central-1` + AWS GovCloud (米国東部): `us-gov-east-1` + AWS GovCloud (米国西部): `us-gov-west-1` Neptune DB クラスターauto-scaling を有効にするには、次の 3 つのステップが必要です。 ### 1. Application Auto Scaling を使用して DB クラスターを登録する Neptune DB クラスターに対して auto-scaling を有効にする最初のステップは、Application Auto Scaling を使用して、クラスターをApplication Auto Scaling に登録することです。このとき、AWS CLI または Application Auto Scaling SDK の 1 つを使用します。クラスターには、すでに 1 つのプライマリインスタンスと少なくとも 1 つの read-replica インスタンスが必要です。 たとえば、クラスタを 1 ～ 8 個の追加レプリカで自動スケーリングするように登録するには、AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを次のようにします。 ``` aws application-autoscaling register-scalable-target \ --service-namespace neptune \ --resource-id cluster:(your DB cluster name) \ --scalable-dimension neptune:cluster:ReadReplicaCount \ --min-capacity 1 \ --max-capacity 8 ``` これは、[https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html](https://docs.aws.amazon.com/ApplicationAutoScaling/latest/APIReference/API_RegisterScalableTarget.html) Application Auto Scaling API オペレーションを使用することと同じです。 AWS CLI `register-scalable-target` コマンドでは、以下のパラメータを使用します。 + ** `service-namespace`** –に設定します。。`neptune` このパラメータは、Application Auto Scaling API にある `ServiceNamespace` パラメータと同じです。 + ** `resource-id`** —これを Neptune DB クラスターのリソース識別子に設定します。リソースタイプは `cluster` で、コロン ('`:`') が、それから DB クラスターの名前が続きます。 このパラメータは、Application Auto Scaling API にある `ResourceID` パラメータと同じです。 + **`scalable-dimension`** — この場合のスケーラブルディメンションは、DB クラスター内のレプリカインスタンスの数であるため、このパラメータを `neptune:cluster:ReadReplicaCount` に設定します。 このパラメータは、Application Auto Scaling API にある `ScalableDimension` パラメータと同じです。 + ** `min-capacity`** –アプリケーションの Auto Scaling で管理するリーダー DB レプリカの最小数。この値は 0 から 15 までの範囲に設定される必要があり、`max-capacity` の Neptune レプリカの最大数として指定された値以下である必要があります。自動スケーリングが機能するには、DB クラスターに少なくとも 1 つのリーダーが必要です。 このパラメータは、Application Auto Scaling API にある `MinCapacity` パラメータと同じです。 + **`max-capacity`** — アプリケーションの自動スケーリングによって管理される既存のインスタンスと新しいインスタンスを含めて、DB クラスター内のリーダー DB レプリカインスタンスの最大数。この値は 0 から 15 までの範囲に設定される必要があり、`min-capacity` の Neptune レプリカの最小数として指定された値以上である必要があります。 `max-capacity` AWS CLI パラメータは、Application Auto Scaling API にある `MaxCapacity` パラメータと同じです。 DB クラスターを登録すると、Application Auto Scaling によって `AWSServiceRoleForApplicationAutoScaling_NeptuneCluster` サービスにリンクされたロールが生成されます。詳細については、*Application Auto Scaling ユーザーガイド*の[Application auto-scaling のサービスにリンクされたロール](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html)を参照してください。 ### 2. DB クラスターで使用するAuto Scaling ポリシーを定義します。 ターゲット追跡スケーリングポリシーは、テキストファイルに保存できる JSON テキストオブジェクトとして定義されます。Neptune の場合、現在、このポリシーは `NeptuneReaderAverageCPUUtilization` という名の定義済みのメトリクスとして Neptune [`CPUUtilization`](cw-metrics.md#cw-metrics-available) CloudWatch メトリクスのみ使用できます。 次に、Neptune のターゲット追跡スケーリング設定ポリシーの例を示します。 ``` { "PredefinedMetricSpecification": { "PredefinedMetricType": "NeptuneReaderAverageCPUUtilization" }, "TargetValue": 60.0, "ScaleOutCooldown" : 600, "ScaleInCooldown" : 600 } ``` ここで **`TargetValue`** 要素には CPU 使用率のパーセンテージが含まれており、これを超えると自動スケーリングが*スケールアウト* (つまりレプリカを追加) し、これより低いと*スケールイン* (つまりレプリカを削除) します。この場合、スケーリングをトリガーする目標パーセンテージは `60.0`% です。 **`ScaleInCooldown`** 要素はスケールインアクティビティが完了してから別のスケールインが開始されるまでの時間 (秒単位) を指定します。デフォルトは 300 秒です。ここで、値 600 は、あるレプリカの削除が完了してから別のレプリカの開始までの間に 10 分以上経過する必要があることを指定します。 **`ScaleOutCooldown`** 要素はスケールアウトアクティビティが完了してから別のスケールアウトが開始されるまでの時間 (秒単位) を指定します。デフォルトは 300 秒です。ここで、値 600 は、あるレプリカの追加が完了してから別のレプリカの開始までの間に 10 分以上経過する必要があることを指定します。 -**`DisableScaleIn`** 要素はブール値であり、存在しており `true` に設定いれば、スケールインを完全に無効にします。つまり、auto-scaling ではレプリカが追加される可能性がありますが、レプリカは削除されません。デフォルトでは、スケールインは有効になっており、`DisableScaleIn` は `false` です。 ### Neptune DB クラスターを アプリケーションの Auto Scaling に登録し、テキストファイルに JSON スケーリングポリシーを定義した後、登録された DB クラスターにスケーリングポリシーを適用します。そのためには、以下のパラメータを指定して AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用します。 ``` aws application-autoscaling put-scaling-policy \ --policy-name (name of the scaling policy) \ --policy-type TargetTrackingScaling \ --resource-id cluster:(name of your Neptune DB cluster) \ --service-namespace neptune \ --scalable-dimension neptune:cluster:ReadReplicaCount \ --target-tracking-scaling-policy-configuration file://(path to the JSON configuration file) ``` auto-scaling ポリシーを適用すると、DB クラスターで auto-scaling が有効になります。 また、AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用して、既存の auto-scaling ポリシーを更新することもできます。 *Application Auto Scaling API リファレンス*の[PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)もご覧ください。 ## Neptune DB クラスターから auto-scaling を削除する Neptune DB クラスターから auto-scaling を削除するには、AWS CLI [削除スケーリングポリシー](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/delete-scaling-policy.html)および[登録解除スケーラブルターゲット](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/deregister-scalable-target.html)コマンドを使用します。 # Amazon Neptune DB クラスターのメンテナンス Neptune は、使用するすべてのリソースに対して、以下のようなメンテナンスを定期的に実施します。 + **必要に応じた基盤となるハードウェアの交換。**これはバックグラウンドで処理され、ユーザーは何もする必要がなく、通常、ユーザーの操作には影響しません。 + **基盤となるオペレーティングシステムの更新。**DB クラスター内のインスタンスのオペレーティングシステムのアップグレードは、パフォーマンスとセキュリティを向上させるために行われるため、通常はできるだけ早く完了する必要があります。通常、アップデートには約 10 分かかります。オペレーティングシステムのアップデートでは、DB インスタンスの DB エンジンのバージョンまたは DB インスタンスクラスは変更されません。 一般的に、最初に DB クラスターのリーダーインスタンスを更新し、次にライターインスタンスを更新するのが最善です。リーダーとライターを同時に更新すると、フェイルオーバーが発生してダウンタイムが生じる可能性があります。DB インスタンスはオペレーティングシステムの更新前に自動的にバックアップされないため、オペレーティングシステムの更新を適用する前に必ず手動でバックアップしてください。 + **Neptune データベースエンジンの更新。**Neptune は、新機能や改善点の導入、バグの修正を目的として、さまざまなエンジンアップデートを定期的にリリースします。 ## エンジンバージョン番号 ### エンジンリリース 1.3.0.0 より前のバージョン番号 2019 年 11 月までは、Neptune がサポートするエンジンバージョンは一度に 1 つのみで、エンジンのバージョン番号はすべて `1.0.1.0.200` という形式でした。ここで `xxx` はパッチ番号を示します。すべての新しいエンジンバージョンは、以前のバージョンへのパッチとしてリリースされました。 2019 年 11 月に、Neptune は複数のバージョンのサポートを開始し、お客様がアップグレードパスをより詳細に制御できるようになりました。これに伴って、エンジンのリリースの番号付けも変更されました。 2019 年 11 月から[エンジンリリース 1.3.0.0](engine-releases-1.3.0.0.md) までのエンジンバージョン番号は 5 つの部分で構成されています。バージョン番号 `1.0.2.0.R2` を例として取り上げます。 + 最初の部分は常に 1 でした。 + 2 番目の部分 (`1.0.2.0.R2` の `0`) は、データベースのメジャーバージョン番号でした。 + 3 番目と 4 番目の部分 (`1.0.2.0.R2` の `2.0`) はどちらもマイナーバージョン番号でした。 + 5 番目の部分 (`1.0.2.0.R2` の `R2`) はパッチ番号でした。 ほとんどのアップデートはパッチアップデートであり、パッチとマイナーバージョンアップデートの区別は必ずしも明確ではありませんでした。 ### エンジンリリース 1.3.0.0 以降のバージョン番号 [エンジンリリース 1.3.0.0](engine-releases-1.3.0.0.md) 以降、Neptune はエンジンアップデートの番号付けと管理の方法を変更しました。 エンジンのバージョン番号は、次の 4 つの部分で構成され、それぞれがリリースのタイプに対応しています。     *製品バージョン***.***メジャーバージョン***.***マイナーバージョン***.***パッチバージョン* 以前はパッチとしてリリースされていた非破壊的変更が、現在はマイナーバージョンとしてリリースされ、[`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) インスタンス設定を使用して管理できるようになりました。 これにより、新しいマイナーバージョンがリリースされるたびに通知を受け取ることができます。そのためには、[`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) イベントにサブスクライブします (「[Neptune イベント通知にサブスクライブする](events-subscribing.md)」を参照してください)。 現在、パッチリリースは緊急のターゲット修正に限定されており、バージョン番号の最後の部分 (`*.*.*.1`、`*.*.*.2` など) を使用して番号が付けられます。 # Amazon Neptune のさまざまなタイプのエンジンリリース エンジンバージョン番号の 4 つの部分に対応するエンジンリリースの 4 つのタイプは次のとおりです。 + **製品バージョン** — 製品の機能やインターフェースに抜本的かつ根本的な変更が加えられた場合にのみ変更されます。現在の Neptune 製品バージョンは 1 です。 + [**メジャーバージョン**](#major-versions) — メジャーバージョンでは重要な新機能や互換性を破る変更が導入されます。通常 2 年以上の有効期間があります。 + [**マイナーバージョン**](#minor-versions) — マイナーバージョンには新機能、改善点、バグ修正が含まれますが、互換性を破るような変更は含まれません。次回のメンテナンスウィンドウ中に自動的に適用するかどうかを選択できます。また、リリースされるたびに通知を受けるように選択することもできます。 + [**パッチバージョン**](#patch-version-updates) — パッチバージョンは、緊急のバグ修正または重大なセキュリティアップデートに対応するためにのみリリースされます。互換性を破る変更が含まれることはめったになく、リリース後の次回のメンテナンスウィンドウ中に自動的に適用されます。 ## Amazon Neptune のメジャーバージョンアップデート メジャーバージョンアップデートでは、通常 1 つ以上の重要な新機能が導入され、多くの場合、互換性を破る変更が含まれます。通常、サポート期間は約 2 年間です。Neptune のメジャーバージョンは、リリース日および推定サポート期間と共に、[エンジンリリース](engine-releases.md)に記載されます。 使用しているメジャーバージョンのサポートが終了するまでは、メジャーバージョンの更新は完全に任意です。新しいメジャーバージョンにアップグレードする場合は、「」の説明に従って、 AWS CLI または Neptune コンソールを使用して、新しいバージョンを自分でインストールする必要があります[メジャーバージョンのアップグレード](engine-updates-manually.md)。 ただし、使用しているメジャーバージョンがサポート終了になると、より新しいメジャーバージョンへのアップグレードが必要であることが通知されます。通知後の猶予期間内にアップグレードしない場合、次回のメンテナンスウィンドウ中に最新のメジャーバージョンへのアップグレードが自動的にスケジュールされます。詳細については「[エンジンバージョンの有効期間](engine-updates-eol-planning.md)」を参照してください。 ## Amazon Neptune のマイナーバージョンアップデート Neptune エンジンのほとんどの更新はマイナーバージョンアップデートです。これらは頻繁に発生し、互換性を破る変更は含まれません。 DB クラスターのライター (プライマリ) インスタンスで [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) フィールドを `true` に設定している場合、マイナーバージョンアップデートは、リリース後の次回のメンテナンスウィンドウ中に DB クラスター内のすべてのインスタンスに自動的に適用されます。 DB クラスターのライターインスタンスで [`AutoMinorVersionUpgrade`](engine-maintenance-management.md#using-amvu) フィールドを `false` に設定している場合は、[明示的にインストール](engine-updates-manually.md)した場合にのみ更新が適用されます。 **注記** マイナーバージョンアップデートは、自己完結型 (同じメジャーバージョンへの以前のマイナーバージョンアップデートには依存しない) および累積的 (以前のマイナーバージョンアップデートで導入されたすべての機能と修正を含む) です。つまり、以前のマイナーバージョンアップデートをインストールしたかどうかに関係なく、どのマイナーバージョンアップデートでもインストールできます。 マイナーバージョンのリリースは、[`RDS-EVENT-0156`](event-lists.md#RDS-EVENT-0156) イベントにサブスクライブすることで簡単に追跡できます (「[Neptune イベント通知にサブスクライブする](events-subscribing.md)」を参照)。これにより、新しいマイナーバージョンがリリースされるたびに通知されます。 また、通知にサブスクライブしているかどうかに関係なく、いつでも[保留中のアップデートを確認](engine-maintenance-management.md#check-pending-updates)できます。 ## Amazon Neptune のパッチバージョンアップデート インスタンスの信頼性に影響するセキュリティ上の問題やその他の重大な不具合が発生した場合、Neptune は必須のパッチをデプロイします。これらは次回のメンテナンスウィンドウ中に DB クラスター内のすべてのインスタンスに適用されます。ユーザーが介入する必要はありません。 パッチリリースは、デプロイしない場合のリスクが、デプロイした場合のリスクやダウンタイムを上回る場合にのみデプロイされます。パッチリリースは頻繁に発生するものではありません (通常数か月に 1 回程度です)。また、メンテナンスウィンドウのごく一部を使用するだけです。 # Amazon Neptune のメジャーエンジンバージョンの有効期間の計画 Neptune のエンジンバージョンは、ほとんどの場合、暦四半期の終わりに有効期限を迎えます。例外が発生するのは、セキュリティや可用性に関する重要な問題が発生した場合のみです。 エンジンバージョンの有効期間が終了すると、Neptune データベースを新しいバージョンにアップグレードする必要があります。 一般的に、Neptune エンジンバージョンは以下のように引き続きご利用いただけます。 + **マイナーエンジンバージョン:** マイナーエンジンバージョンは、リリース後少なくとも 6 か月間はご利用いただけます。 + **メジャーエンジンバージョン:** メジャーエンジンバージョンは、リリース後少なくとも 12 か月間はご利用いただけます。 エンジンバージョンの有効期限の少なくとも 3 か月前に、 AWS はアカウント AWS に関連付けられた E メールアドレスに自動 E メール通知を送信し、同じメッセージを [AWS Health Dashboard](https://docs.aws.amazon.com/health/latest/ug/aws-health-dashboard-status.html) に投稿します。これにより、アップグレードを計画し、準備する時間を確保できます。 エンジンバージョンの有効期間が終了すると、そのバージョンを使用して新しいクラスターやインスタンスを作成できなくなり、オートスケーリングでもそのバージョンを使用してインスタンスを作成できなくなります。 実際に有効期間が終了したエンジンバージョンは、メンテナンス期間中に自動的にアップグレードされます。エンジンバージョンの有効期限の 3 か月前に送信されるメッセージには、自動的にアップグレードされるバージョン、DB クラスターへの影響、推奨アクションなど、この自動更新の内容に関する詳細が記載されています。 **重要** データベースエンジンのバージョンを最新の状態に保つ責任はお客様にあります。 AWS は、セキュリティ、プライバシー、および可用性に関する最新の保護措置の恩恵を受けるために、すべてのお客様にデータベースを最新のエンジンバージョンにアップグレードするよう促します。廃止日を過ぎたサポートされていないエンジンまたはソフトウェア (「レガシーエンジン」) でデータベースを運用すると、セキュリティ、プライバシー、およびダウンタイムイベントを含む運用上のリスクにさらされる可能性が高くなります。 任意のエンジンでのデータベースの運用には、 AWS サービスの使用に適用される契約が適用されます。レガシーエンジンは一般公開されていません。 はレガシーエンジンのサポートを提供し AWS なくなり、 AWS レガシーエンジンがサービス、 AWSその関連会社、または第三者にセキュリティまたは責任のリスク、または損害のリスクをもたらす AWS と判断した場合、いつでもレガシーエンジンへのアクセスまたは使用を制限することができます。レガシーエンジンでコンテンツを引き続き実行すると、コンテンツが利用できなくなったり、破損したり、回復できなくなったりする可能性があります。レガシーエンジンで実行されているデータベースは、サービスレベルアグリーメント (SLA) の例外の対象となります。 レガシーエンジンで実行されているデータベースおよび関連ソフトウェアには、バグ、エラー、欠陥、または有害なコンポーネントが含まれています。それに応じて、契約またはサービス条件にこれと異なる規定があっても、 AWS はレガシーエンジンを「現状のまま」にしています。 # Neptune DB クラスターのエンジン更新の管理 **注記** 更新は、DB クラスター内のすべてのインスタンスに同時に適用されます。更新では、インスタンスでデータベースを再起動する必要があるため、20 ～ 30 秒から数秒のダウンタイムが発生します。その後、DB クラスターの使用を再開できます。インスタンスでは、メンテナンス更新を完了するためにマルチ AZ フェイルオーバーが必要になる場合がまれにあります。 適用に時間がかかるメジャーバージョンアップグレードの場合は、[ブルー/グリーンデプロイ戦略](neptune-BG-deployments.md)を使用してダウンタイムを最小限に抑えることができます。 ## 現在使用しているエンジンバージョンの確認 コマンドを使用して AWS CLI [`get-engine-status`](access-graph-status.md)、DB クラスターが現在使用しているエンジンリリースバージョンを確認できます。 ``` aws neptunedata get-engine-status ``` [JSON 出力](access-graph-status.md#access-graph-status-sample-output)には、次のような `"dbEngineVersion"` フィールドが含まれています。 ``` "dbEngineVersion": "1.3.0.0", ``` ## 保留中および利用可能な更新を確認する DB クラスターの保留中の更新は、Neptune コンソールを使用して確認できます。左側の列で **[データベース]** を選択し、データベースペインで DB クラスターを選択します。保留中の更新は **[メンテナンス]** 列に表示されます。**[アクション]**、**[メンテナンス]** の順に選択すると、次の 3 つの選択肢が表示されます。 + 今すぐアップグレード + 次回のウィンドウでアップグレード + アップグレードを延期 を使用して、次のように保留中のエンジン更新 AWS CLI を一覧表示できます。 ``` aws neptune describe-pending-maintenance-actions \ --resource-identifier (ARN of your DB cluster) --region (your region) \ --engine neptune ``` AWS CLI 次のように、 を使用して利用可能なエンジン更新を一覧表示することもできます。 ``` aws neptune describe-db-engine-versions \ --region (your region) \ --engine neptune ``` 利用可能なエンジンリリースのリストには、バージョン番号が現在のものよりも高く、アップグレードパスが定義されているリリースのみが含まれます。 ## アップグレードの前に必ずテストする 新しいメジャーまたはマイナーバージョンの Neptune エンジンがリリースされたら、アップグレードする前に、まず最初に Neptune アプリケーションをテストしてください。マイナーアップグレードでは、互換性を破る変更がなくても、コードに影響するような新しい機能や動作が導入される場合があります。 まず、現在のバージョンのリリースノートページと対象バージョンのリリースノートページを比較して、クエリ言語のバージョンに変更があるか、その他の重大な変更がないかを確認します。 本番 DB クラスターをアップグレードする前に、新しいバージョンをテストする最善の方法は、[Neptune ブルー/グリーンデプロイソリューション](neptune-BG-deployments.md)を使用することです。これにより、本番 DB クラスターに影響を与えずに、新しいバージョンでアプリケーションやクエリを実行できます。 ## アップグレードの前に必ずスナップショットを手動で作成してください アップグレードの前に必ず DB クラスターの手動スナップショットを作成することを強く推奨します。自動スナップショットを作成しても短期的な保護しか得られませんが、手動スナップショットは明示的に削除するまで使用できます。 場合によっては、Neptune がアップグレードプロセスの一環として手動スナップショットを作成することもありますが、これを頼りにすべきではなく、どのような場合でも独自の手動スナップショットを作成する必要があります。 DB クラスターをアップグレード前の状態に戻す必要がないことが確実な場合は、自分で作成した手動スナップショットと、Neptune が作成した手動スナップショットを明示的に削除できます。Neptune が手動スナップショットを作成する場合、その名前は `preupgrade` で始まり、その後に DB クラスターの名前、ソースエンジンのバージョン、ターゲットエンジンのバージョン、および日付が続きます。 ## Neptune メンテナンスウィンドウ 毎週のメンテナンスウィンドウは 30 分間で、その間に、予定されたエンジンの更新やその他のシステム変更が適用されます。ほとんどのメンテナンスイベントは 30 分のウィンドウ中に完了しますが、大規模なメンテナンスイベントは 30 分以上かかる場合があります。 各 DB クラスターには、毎週 30 分のメンテナンスウィンドウがあります。DB クラスターの作成時に時間を指定しないと、Neptune は、ランダムに曜日を選択し、リージョンによって異なる 8 時間の時間ブロックから 30 分をその曜日内に割り当てます。 例えば、いくつかの AWS リージョンで使用されているメンテナンスウィンドウの 8 時間の時間ブロックは次のとおりです。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/engine-maintenance-management.html) メンテナンスウィンドウにより、保留中の操作がいつ開始されるかが決まり、ほとんどのメンテナンス操作はそのウィンドウ内に完了します。ただし、大規模なメンテナンスタスクはウィンドウの終了時間を超えて続く場合があります。 ### DB クラスターのメンテナンスウィンドウの移動 理想的には、メンテナンスウィンドウは、クラスターの使用率が最も低い時間帯に設定する必要があります。現在のウィンドウが該当しない場合は、次のように、より適切な時間に移動できます。 **DB クラスターのメンテナンスウィンドウを変更するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、**データベース**を選択します。 1. メンテナンスウィンドウを変更する DB クラスターを選択します。 1. **[変更]** を選択します。 1. **[クラスターを変更]** ページの下部にある **[さらに表示]** を選択します。 1. **[優先メンテナンスウィンドウ]** セクションで、希望するメンテナンスウィンドウの曜日、時間、期間を設定します。 1. [**次へ**] を選択します。 確認ページで、変更内容を確認します。 1. 直ちにメンテナンスウィンドウに変更を適用するには、[**すぐに適用**] を選択します。 1. **[送信]** を選択して変更を適用します。 変更を編集する場合は、**[戻る]** を選択します。変更をキャンセルする場合は **[キャンセル]** を選択します。 ## AutoMinorVersionUpgrade を使用してマイナーバージョンの自動更新を制御する **重要** `AutoMinorVersionUpgrade` は、[エンジンリリース 1.3.0.0](engine-releases-1.3.0.0.md) 以降のマイナーバージョンアップグレードにのみ有効です。 DB クラスターのライター (プライマリ) インスタンスで `AutoMinorVersionUpgrade` フィールドを `true` に設定している場合、マイナーバージョンの更新は、リリース後の次回のメンテナンスウィンドウで DB クラスター内のすべてのインスタンスに自動的に適用されます。 DB クラスターのライターインスタンスで `AutoMinorVersionUpgrade` フィールドを `false` に設定している場合は、[明示的にインストール](engine-updates-manually.md#engine-minor-updates-using-console)した場合にのみ更新が適用されます。 **注記** パッチリリース (`*.*.*.1`、`*.*.*.2` など) は、`AutoMinorVersionUpgrade` パラメータの設定に関係なく、常に次回のメンテナンスウィンドウ中に自動的にインストールされます。 AWS マネジメントコンソール 次のように、 `AutoMinorVersionUpgrade`を使用して を設定できます。 **Neptune コンソールを使用して `AutoMinorVersionUpgrade` を設定するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. `AutoMinorVersionUpgrade` を設定する対象の DB クラスターのプライマリ (ライター) インスタンスを選択します。 1. **[変更]** を選択します。 1. **[クラスターを変更]** ページの下部にある **[さらに表示]** を選択します。 1. 展開されたページの下部で、**[マイナーバージョン自動アップグレードをオンにする]** または **[マイナーバージョン自動アップグレードをオフにする]** を選択します。 1. [**次へ**] を選択します。 確認ページで、変更内容を確認します。 1. マイナーバージョン自動アップグレードに変更を適用するには、**[すぐに適用]** を選択します。 1. **[送信]** を選択して変更を適用します。 変更を編集する場合は、**[戻る]** を選択します。変更をキャンセルする場合は **[キャンセル]** を選択します。 を使用して `AutoMinorVersionUpgrade`フィールド AWS CLI を設定することもできます。例えば、`true` に設定するには、次のようなコマンドを使用できます。 ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --auto-minor-version-upgrade \ 4. --apply-immediately ``` 同様に、`false` に設定するには、次のようなコマンドを使用します。 ``` 1. aws neptune modify-db-instance \ 2. --db-instance-identifier (the ID of your cluster's writer instance) \ 3. --no-auto-minor-version-upgrade \ 4. --apply-immediately ``` # Neptune エンジンへの更新の手動インストール ## メジャーバージョンのエンジンアップグレードのインストール メジャーエンジンリリースは常に手動でインストールする必要があります。ダウンタイムを最小限に抑え、テストと検証に十分な時間を確保するために、新しいメジャーバージョンをインストールする最善の方法は、一般的に [Neptune ブルー/グリーンデプロイソリューション](neptune-BG-deployments.md)を使用することです。 場合によっては、DB クラスターを作成した CloudFormation テンプレートを使用してメジャーバージョンアップグレードをインストールすることもできます (「」を参照[CloudFormation テンプレートを使用して Neptune DB クラスターのエンジンバージョンを更新する](cfn-engine-update.md))。 メジャーバージョンアップデートをすぐにインストールする場合は、次のような CLI コマンドを使用できます。 ``` aws neptune modify-db-cluster \ --db-cluster-identifier (identifier for your neptune cluster) \ --engine neptune \ --engine-version (the new engine version) \ --apply-immediately ``` アップグレード先のエンジンのバージョンを必ず指定します。指定しないと、エンジンは最新バージョンではないか、期待するバージョンとは異なるバージョンにアップグレードされる可能性があります。 `--apply-immediately` の代わりに `--no-apply-immediately` と指定することができます。 クラスターでカスタムクラスターパラメータグループを使用している場合は、必ずこのパラメータを使用することを指定します。 ``` --db-cluster-parameter-group-name (name of the custom DB cluster parameter group) ``` 同様に、クラスター内のインスタンスがカスタム DB パラメータグループを使用している場合は、必ずこのパラメータを使用して指定します。 ``` ---db-instance-parameter-group-name (name of the custom instance parameter group) ``` ## を使用したマイナーバージョンエンジンのアップグレードのインストール AWS マネジメントコンソール **Neptune コンソールを使用してマイナーバージョンアップグレードを実行するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、**[データベース]** を選択し、変更する DB クラスターを選択します。 1. **[変更]** を選択します。 1. **[インスタンスの仕様]** で、アップグレード先の新しいバージョンを選択します。 1. [**次へ**] を選択します。 1. 変更をすぐに適用するには、**[すぐに適用]** を選択します。 1. **[送信]** を選択して DB クラスターを更新します。 ## を使用したマイナーバージョンエンジンのアップグレードのインストール AWS CLI 次のようなコマンドを使用すると、次回のメンテナンスウィンドウを待たずにマイナーバージョンアップグレードを実行できます。 ``` aws neptune modify-db-cluster \ --db-cluster-identifier (your-neptune-cluster) \ --engine-version (new-engine-version) \ --apply-immediately ``` を使用して手動でアップグレードする場合は AWS CLI、アップグレードするエンジンバージョンを必ず含めてください。そうしないと、エンジンが最新バージョンまたは期待するバージョンではないバージョンにアップグレードされる可能性があります。 # 1.2.0.0 より前のバージョンからエンジンバージョン 1.2.0.0 以降へのアップグレード [エンジンリリース 1.2.0.0](engine-releases-1.2.0.0.md) では、重要な変更がいくつか導入され、以前のバージョンからのアップグレードが通常よりも複雑になる可能性があります。 + [エンジンリリース 1.2.0.0](engine-releases-1.2.0.0.md) では、カスタムパラメータグループとカスタムクラスターパラメータグループに新しい形式が導入されました。そのため、1.2.0.0 より前のエンジンバージョンからエンジンバージョン 1.2.0.0 以降にアップグレードする場合は、パラメータグループファミリー `neptune1.2` を使用している既存のカスタムパラメータグループとカスタムクラスターパラメータグループをすべて再作成する必要があります。以前のリリースではパラメータグループファミリー `neptune1` が使用されていましたが、それらのパラメータグループはリリース 1.2.0.0 以降では動作しません。詳細については「[Amazon Neptune パラメータグループ](parameter-groups.md)」を参照してください。 + エンジンリリース 1.2.0.0 では、元に戻すログの新しい形式が導入されました。したがって、バージョン 1.2.0.0 より前のバージョンからバージョン 1.2.0.0 以降にアップグレードする場合、[`UndoLogListSize`](cw-metrics.md#cw-metrics-UndoLogListSize)メトリクスは特定のしきい値を下回っている必要があります。そうしないと、パッチはロールバックされて失敗します。しきい値はインスタンスタイプに基づきます。デフォルトの制限は 4xlarge 以上のインスタンスでは 40,000、4xlarge 未満のインスタンスでは 10,000 です。をアップグレードしようとしたときに が制限`UndoLogListSize`を超えると、パッチプロセスはロールバックされ、アップグレードはキャンセルされ、その理由を含むイベントがクラスターイベントページに表示されます。これらの制限は、事前の警告なしに運用上の理由で変更される可能性があります。 パージが行われるクラスターのライターインスタンスをアップグレードすることで、パージの速度を上げることができます。アップグレードを試みる前にこれを行うと、 が該当するしきい値`UndoLogListSize`を下回る可能性があります。ライターのサイズを 24XL インスタンスタイプに増やすと、パージ率が 1 時間あたり 100 万レコードを超えることがあります。 `UndoLogListSize` CloudWatch メトリクスが非常に大きい場合、サポートケースを開くと、必要な制限を下回る追加の戦略を検討するのに役立ちます。 + 最後に、リリース 1.2.0.0 には、IAM 認証で Bolt プロトコルを使用していた以前のコードに影響する重大な変更がありました。リリース 1.2.0.0 以降、Bolt には IAM 署名用のリソースパスが必要です。Java では、リソースパスの設定は以下のようになります: `request.setResourcePath("/openCypher"));`。その他の言語では、`/openCypher` をエンドポイント URI に追加できます。例については、「[Bolt プロトコルの使用](access-graph-opencypher-bolt.md)」を参照してください。 # CloudFormation テンプレートを使用して Neptune DB クラスターのエンジンバージョンを更新する Neptune DB クラスターの作成に使用した Neptune CloudFormation テンプレートを再利用して、エンジンバージョンを更新できます。 Neptune エンジンバージョンのアップグレードは、マイナーとメジャーがあります。 CloudFormation テンプレートを使用すると、多くの場合大幅な変更を含むメジャーバージョンのアップグレードに役立ちます。メジャーバージョンアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があるため、アップグレード時にアプリケーションに変更を加える必要がある場合もあります。必ず、[アップグレードの前にテスト](engine-maintenance-management.md#always-test-before-upgrading)してください。また、アップグレードの前に、DB クラスターの手動スナップショットを常に作成することを強くお勧めします。 メジャーバージョンごとに個別のエンジンアップグレードを行う必要があることに注意してください。メジャーバージョンをスキップして、次のメジャーバージョンに直接アップグレードすることはできません。 2023 年 5 月 17 日より前は、Neptune CloudFormation スタックを使用してエンジンバージョンをアップグレードした場合、現在の DB クラスターの代わりに新しい空の DB クラスターが作成されました。ただし、2023 年 5 月 17 日現在、Neptune CloudFormation スタックは既存のデータを保持するインプレースエンジンアップグレードをサポートするようになりました。 **注記** を使用している場合は AWS Cloud Development Kit (AWS CDK)、使用している AWS CDK バージョンが 2.82.0 以降であることを確認します。2.82.0 より前のバージョンでは、Neptune エンジンの in-place アップグレードはサポートされていません。 メジャーバージョンアップグレードの場合、テンプレートで `DBCluster` に次のプロパティを設定する必要があります。 + `DBClusterParameterGroup` (カスタムまたはデフォルト) + `DBInstanceParameterGroupName` + `EngineVersion` 同様に、DBCluster にアタッチされた DBInstance に対しても以下を設定する必要があります。 + `DBParameterGroup` (カスタム/デフォルト) デフォルトかカスタムかにかかわらず、すべてのパラメータグループがテンプレートで定義されていることを確認してください。 カスタムパラメータグループの場合は、既存のカスタムパラメータグループのファミリーが新しいエンジンバージョンと互換性があることを確認してください。[1.2.0.0](engine-releases-1.2.0.0.md) より前のエンジンバージョンでは、パラメータグループファミリー `neptune1` が使用されていましたが、1.2.0.0 以降のエンジンリリースでは、パラメータグループファミリー `neptune1.2` が必要です。詳細については「[Amazon Neptune パラメータグループ](parameter-groups.md)」を参照してください。 メジャーエンジンバージョンアップグレードの場合、適切なファミリーのパラメータグループを `DBCluster` `DBInstanceParameterGroupName` フィールドで指定します。 デフォルトのパラメータグループは、新しいエンジンバージョンと互換性のあるものにアップグレードする必要があります。 Neptune はエンジンのアップグレード後に DB インスタンスを自動的に再起動することに注意してください。 **Topics** + [例: 1.2.0.1 から 1.2.0.2 へのマイナーエンジンアップグレード](cfn-engine-update-1201-1202.md) + [例: デフォルトのパラメータグループによる 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード](cfn-engine-update-1110-1202-default.md) + [例: カスタムパラメータグループによる 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード](cfn-engine-update-1110-1202-custom.md) + [例: デフォルトパラメータグループとカスタムパラメータグループを組み合わせた 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード](cfn-engine-update-1110-1202-mixed.md) # 例: 1.2.0.1 から 1.2.0.2 へのマイナーエンジンアップグレード アップグレードする DB クラスターと、そのクラスターの作成に使用したテンプレートを選択します。例えば、次のようになります。 ``` Description: Base Template to create Neptune Stack with Engine Version 1.2.0.1 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-cluster-parameter-group-description Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-parameter-group-description Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.1 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` `EngineVersion` プロパティを `1.2.0.1` から `1.2.0.2` に更新します。 ``` Description: Template to upgrade minor engine version to 1.2.0.2 Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-cluster-parameter-group-description Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: test-cfn-neptune-db-parameter-group-description Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` 次に CloudFormation 、 を使用して、改訂されたテンプレートを実行します。 # 例: デフォルトのパラメータグループによる 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード アップグレードする `DBCluster` と、その作成に使用したテンプレートを見つけます。例えば、次のようになります。 ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using default Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + `DBClusterParameterGroup`デフォルトを、新しいエンジンバージョンで使用されているパラメータグループファミリーのものに更新します (こちら`default.neptune1.2`)。 + `DBCluster` にアタッチされた各 `DBInstance` について、デフォルトの `DBParameterGroup` を新しいエンジンバージョンで使用されているファミリーのものに更新します (こちら `default.neptune1.2`)。 + `DBInstanceParameterGroupName` プロパティをそのファミリーのデフォルトパラメータグループに設定します (こちら `default.neptune1.2`)。 + `EngineVersion` プロパティを `1.1.0.0` から `1.2.0.2` に更新します。 テンプレートは次のようになります。 ``` Description: Template to upgrade major engine version to 1.2.0.2 by using upgraded default parameter groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: default.neptune1.2 DBInstanceParameterGroupName: default.neptune1.2 NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: ``` 次に CloudFormation 、 を使用して、改訂されたテンプレートを実行します。 # 例: カスタムパラメータグループによる 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード アップグレードする `DBCluster` と、その作成に使用したテンプレートを見つけます。例えば、次のようになります。 ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Name: engineupgradetestcpg Family: neptune1 Description: 'NeptuneDBClusterParameterGroup with family neptune1' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Name: engineupgradetestpg Family: neptune1 Description: 'NeptuneDBParameterGroup1 with family neptune1' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + カスタム `DBClusterParameterGroup` ファミリーを、新しいエンジンバージョン (ここでは `default.neptune1.2`) で使用されるものに更新します。 + `DBCluster` にアタッチされた各 `DBInstance` について、カスタム `DBParameterGroup` ファミリーを新しいエンジンバージョン (ここでは `default.neptune1.2`) で使用されるものに更新します。 + `DBInstanceParameterGroupName` プロパティをそのファミリーのパラメータグループに設定します (こちら `default.neptune1.2`)。 + `EngineVersion` プロパティを `1.1.0.0` から `1.2.0.2` に更新します。 テンプレートは次のようになります。 ``` Description: Template to upgrade major engine version to 1.2.0.2 by modifying existing custom parameter groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Name: engineupgradetestcpgnew Family: neptune1.2 Description: 'NeptuneDBClusterParameterGroup with family neptune1.2' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Name: engineupgradetestpgnew Family: neptune1.2 Description: 'NeptuneDBParameterGroup1 with family neptune1.2' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DBInstanceParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBClusterParameterGroup NeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` 次に CloudFormation 、 を使用して、改訂されたテンプレートを実行します。 # 例: デフォルトパラメータグループとカスタムパラメータグループを組み合わせた 1.1.1.0 から 1.2.0.2 へのメジャーバージョンアップグレード アップグレードする `DBCluster` と、その作成に使用したテンプレートを見つけます。例えば、次のようになります。 ``` Description: Base Template to create Neptune Stack with Engine Version 1.1.1.0 using custom Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1 Description: 'NeptuneDBClusterParameterGroup with family neptune1' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1 Description: 'NeptuneDBParameterGroup with family neptune1' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.1.1.0 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DependsOn: - NeptuneDBClusterParameterGroup CustomNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup DefaultNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` + カスタムクラスターパラメータグループの場合は、`DBClusterParameterGroup` ファミリーを新しいエンジンバージョンに対応するもの、つまり `neptune1.2` に更新します。 + デフォルトのクラスターパラメータグループの場合、`DBClusterParameterGroup` を新しいエンジンバージョンに対応するもの、つまり `default.neptune1.2` に更新します。 + `DBCluster` にアタッチされる各 `DBInstance` について、デフォルトの `DBParameterGroup` を新しいエンジンバージョンで使用されるファミリーのもの (こちら `default.neptune1.2`) に更新し、カスタムパラメータグループを新しいエンジンバージョンによってサポートされるファミリーを使用するもの (こちら `neptune1.2`) に更新します。 + `DBInstanceParameterGroupName` プロパティを、新しいエンジンバージョンによってサポートされているファミリーのパラメータグループに設定します。 テンプレートは次のようになります。 ``` Description: Template to update Neptune Stack to Engine Version 1.2.0.1 using custom and default Parameter Groups Parameters: DbInstanceType: Description: Neptune DB instance type Type: String Default: db.r5.large Resources: NeptuneDBClusterParameterGroup: Type: 'AWS::Neptune::DBClusterParameterGroup' Properties: Family: neptune1.2 Description: 'NeptuneDBClusterParameterGroup with family neptune1.2' Parameters: neptune_enable_audit_log: 0 NeptuneDBParameterGroup: Type: 'AWS::Neptune::DBParameterGroup' Properties: Family: neptune1.2 Description: 'NeptuneDBParameterGroup1 with family neptune1.2' Parameters: neptune_query_timeout: 20000 NeptuneDBCluster: Type: 'AWS::Neptune::DBCluster' Properties: EngineVersion: 1.2.0.2 DBClusterParameterGroupName: Ref: NeptuneDBClusterParameterGroup DBInstanceParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBClusterParameterGroup CustomNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: Ref: NeptuneDBParameterGroup DependsOn: - NeptuneDBCluster - NeptuneDBParameterGroup DefaultNeptuneDBInstance: Type: 'AWS::Neptune::DBInstance' Properties: DBClusterIdentifier: Ref: NeptuneDBCluster DBInstanceClass: Ref: DbInstanceType DBParameterGroupName: default.neptune1.2 DependsOn: - NeptuneDBCluster Outputs: DBClusterId: Description: Neptune Cluster Identifier Value: Ref: NeptuneDBCluster ``` 次に CloudFormation 、 を使用して、改訂されたテンプレートを実行します。 # Neptune のデータベースのクローン化 DB のクローン作成を使用すると、Amazon Neptune ですべてのデータベースのクローンを迅速かつ高いコスト効率で作成できます。クローンデータベースの初回作成時に必要な追加スペースは最小限です。データベースのクローン作成では、 *コピーオンライトプロトコル*が使用されます。データは、ソースデータベースまたはクローンデータベースのいずれかで、変更時にコピーされます。同じ DB クラスターから複数のクローンを作成できます。また、そのほかのクローンから追加のクローンを作成することもできます。Neptune ストレージのコンテキストにおけるコピーオンライトプロトコルの詳しい動作については、[コピーオンライトプロトコル](#manage-console-cloning-protocol) を参照してください。 DB クローン作成はさまざまなユースケースで使用でき、特に、次のような稼働環境で影響を及ぼさないために役立ちます。 + スキーマの変更やパラメータグループの変更など、変更の影響を試したり評価したりする場合。 + データのエクスポートや分析クエリの実行など、大量のワークロードを扱うオペレーションを実行する場合。 + 開発やテストの目的で試験的な環境で本番稼働用の DB クラスターのコピーを作成する場合 **AWS マネジメントコンソール を使用して DB クラスターのクローンを作成するには** 1. AWS マネジメントコンソールにサインインして Amazon Neptune コンソール ([https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home)) を開きます。 1. ナビゲーションペインで、[**インスタンス**] を選択してください。クローンを作成する DB クラスターのプライマリインスタンスを選択します。 1. [**Instance actions**] を選択してから、[**Create clone**] を選択します。 1. [**Create Clone (クローンの作成)**] ページで、[**DB instance identifier (DB インスタンス識別子)**] としてクローン DB クラスターのプライマリインスタンスの名前を入力します。 希望する場合には、クローン DB クラスターのそのほかの設定を行います。各種の DB クラスターの設定についての詳細は、「[コンソールを使用して起動する](manage-console-launch-console.md)」を参照してください。 1. [**Create Clone**] を選択してクローン DB クラスターを起動します。 **AWS CLI を使用して DB クラスターのクローンを作成するには** + Neptune [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) AWS CLI コマンドを呼び出し、以下の値を指定します。 + `--source-db-cluster-identifier`   –   クローンを作成するソース DB クラスターの名前。 + `--db-cluster-identifier`   –   クローン DB クラスターの名前。 + `--restore-type copy-on-write`   –   `copy-on-write` 値は、クローン DB クラスターを作成する必要があることを示します。 + `--use-latest-restorable-time`   –   これにより、復元可能な最新のバックアップ時間が使用されることが指定されます。 **注記** [restore-db-cluster-to-point-in-time](api-snapshots.md#RestoreDBClusterToPointInTime) AWS CLI コマンドは、その DB クラスターの DB インスタンスではなく、DB クラスターのみをクローン作成します。 次の Linux/UNIX の例では、`source-db-cluster-id` DB クラスターからクローンを作成し、クローンに `db-clone-cluster-id` という名前を付けます。 ``` aws neptune restore-db-cluster-to-point-in-time \ --region us-east-1 \ --source-db-cluster-identifier source-db-cluster-id \ --db-cluster-identifier db-clone-cluster-id \ --restore-type copy-on-write \ --use-latest-restorable-time ``` `\` 行末のエスケープ文字が Windows の `^` と同等のものに置き換えられている場合、同じ例が Windows でも機能します。 ``` aws neptune restore-db-cluster-to-point-in-time ^ --region us-east-1 ^ --source-db-cluster-identifier source-db-cluster-id ^ --db-cluster-identifier db-clone-cluster-id ^ --restore-type copy-on-write ^ --use-latest-restorable-time ``` ## 制限 Neptune での DB クローン作成には以下の制限があります。 + AWS リージョンをまたぐクローンデータベースは作成できません。クローンデータベースはソース データベースと同じリージョンで作成する必要があります。 + クローンされたデータベースは、クローンされたデータベースで使用されている Neptune エンジンバージョンの最新のパッチを常に使用します。これは、ソースデータベースがそのパッチバージョンにアップグレードされていない場合でも当てはまります。ただし、エンジンのバージョン自体は変更されません。 + 現在、他のクローンに基づくクローンを含め、Neptune DB クラスターの 1 つのコピーについて、15 クローンに制限されます。この制限に達したら、データベースを複製するのではなく、データベースのコピーをもう 1 つ作成する必要があります。ただし、新しいコピーから最大で 15 クローンまで作成できます。 + アカウント間での DB クローン作成は現在サポートされていません。 + クローンに異なる virtual private cloud (VPC) を提供できます。ただし、この VPCのサブネットは同じアベイラビリティゾーンにマッピングする必要があります。 ## DB クローン作成のためのコピーオンライトプロトコル 以下の例で、コピーオンライトプロトコルの動作について説明します。 + [クローン作成前の Neptune データベース](#manage-console-cloning-protocol-before) + [クローン作成後の Neptune データベース](#manage-console-cloning-protocol-after) + [ソースデータベースが変更されたとき](#manage-console-cloning-protocol-source-write) + [クローンデータベースが変更されたとき](#manage-console-cloning-protocol-clone-write) ### クローン作成前の Neptune データベース ソースデータベースのデータはページに保存されています。次の図では、ソースデータベースに 4 つのページがあります。 ![\[4 ページで DB クローンを作成する前の Neptune ソースデータベース。\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/neptune-clone-1.png) ### クローン作成後の Neptune データベース 次の図に示すように、DB クローン作成後、ソースデータベースに変更はありません。ソースデータベースとクローンデータベースの両方が同じ 4 つのページを指しています。どのページも物理的にコピーされていないため、追加のストレージは不要です。 ![\[同じページを指す Neptune ソースデータベースとクローンデータベース (DB クローン作成後)。\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/neptune-clone-2.png) ### ソースデータベースが変更されたとき 次の例では、ソースデータベースの `Page 1` のデータに変更があります。元の `Page 1` に書き込む代わりに、追加のストレージを使用して `Page 1'` という新しいページが作成されます。ソースデータベースはこれで新しい `Page 1'`、および `Page 2`、`Page 3` と `Page 4` を指すようになります。クローンデータベースは、これまでと同じく `Page 1` から `Page 4` を指します。 ![\[Neptune ソースデータベースとクローンデータベース (ソースデータベースの変更後)。\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/neptune-clone-3.png) ### クローンデータベースが変更されたとき 次の図では、クローンデータベースにも変更があります。今回の変更は `Page 4` です。元の `Page 4` に書き込む代わりに、追加のストレージを使用して `Page 4'` という新しいページが作成されます。ソースデータベースはこれまで同様、`Page 1'` および `Page 2` から `Page 4` を指しますが、クローンデータベースは `Page 1` から `Page 3` までと `Page 4'` を指すようになります。 ![\[Neptune ソースデータベースとクローンデータベース（クローンデータベースの変更後）。\]](http://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/images/neptune-clone-4.png) 2 番目の例で示すように、DB クローン作成時点では追加のストレージは不要です。ただし、例 3 と例 4 で示すように、ソースデータベースとクローンデータベースで変更があると、変更があったページだけが作成されます。時間が経過してソースデータベースとクローンデータベースの両方で追加の変更があると、その変更をキャプチャして保存するために増分のストレージが必要になります。 ## ソースデータベースの削除 ソースデータベースを削除しても、それに関連付けられているクローンデータベースには影響しません。クローンデータベースは、ソースデータベースが前に所有していたページを指し続けます。 # Amazon Neptune インスタンスの管理 以下のセクションには、インスタンスレベルのオペレーションに関する情報を含みます。 **Topics** + [Neptune T3 バースト可能インスタンスクラス](manage-console-instances-t3.md) + [Neptune DB インスタンスを変更する (その後すぐに適用する)](manage-console-instances-modify.md) + [Neptune DB インスタンスの名前変更](manage-console-instances-rename.md) + [Amazon Neptune における DB インスタンスの再起動](manage-console-instances-reboot.md) + [Amazon Neptune の DB インスタンスを削除する](manage-console-instances-delete.md) # Neptune T3 バースト可能インスタンスクラス `R5` や `R6` などの固定パフォーマンスインスタンスクラスに加えて、Amazon Neptune にはバースト可能パフォーマンス `T3` インスタンスを使用するオプションがあります。グラフアプリケーションを開発しているときは、速度と応答性の高いデータベースが必要ですが、常に使用する必要はありません。Neptune の `db.t3.medium` インスタンスクラスは、まさにそのような状況に適したものであり、最も安価な固定パフォーマンスインスタンスクラスよりも大幅にコストが低くなります。 バースト可能インスタンスは、ワークロードから必要とされるまで CPU パフォーマンスのベースラインレベルで実行され、ワークロードが必要としている間はベースラインをかなり上回ってバーストします。平均 CPU 使用率が 24 時間ベースラインを超えなければ、1 時間あたりの料金でバーストがカバーされます。ほとんどの開発およびテスト状況では、低コストで高いパフォーマンスが実現します。 `T3` インスタンスクラスから始めた場合、本稼働の準備ができたら、AWS マネジメントコンソール、AWS CLI、またはいずれかの AWS SDK を使用して、後で固定パフォーマンスインスタンスクラスに簡単に切り替えることができます。 ## T3 バーストは CPU クレジットによって管理される CPU クレジットは、1 つの仮想 CPU コア (vCPU) の使用率が 1 分間 100% であることを表します。また、1 つの vCPU の使用率が 2 分間 50%、2 つの vCPU の使用率が 2 分間 25% などとも言い換えることができます。 `T3` インスタンスは、アイドル状態のときに CPU クレジットを蓄積し、アクティブなときに消費します。どちらもミリ秒単位で測定されます。`db.t3.medium` インスタンスクラスには 2 つの vCPU があり、それぞれアイドル状態のときに 1 時間あたり 12 CPU クレジットを獲得します。つまり、各 vCPU の使用率が 20% の場合、CPU クレジットバランスがゼロになります。獲得した 12 CPU クレジットは、vCPU の使用率が 20% になると消費されます (60 分の 20% も 12 であるため)。したがって、この 20% の使用率は、CPU クレジット残高がプラスにもマイナスにもならない*ベースライン*使用率です。 アイドル時間 (CPU 使用率が使用可能な合計量の 20% を下回る) が発生すると、CPU クレジットがクレジットバランスバケットに保存されます。 `db.t3.medium` インスタンスクラスの上限は 576 です (24 時間で累積できる CPU クレジットの最大数、つまり 2 x 12 x 24)。この制限を超えると、CPU クレジットはそのまま破棄されます。 CPU クレジットバランスがゼロを下回っても、必要に応じて、ワークロードが必要とする限り CPU 使用率は 100% までバーストできます。インスタンスのバランスが 24 時間継続してマイナスの場合、その期間中 -60 CPU クレジット蓄積されるたびに 0.05 USD の追加料金が発生します。ただし、ほとんどの開発およびテストワークロードでは、バーストは通常、バースト前後のアイドル時間によりカバーされます。 **注記** Neptune の `T3` インスタンスクラスは、Amazon EC2 [unlimited モード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html)と同じように設定されます。 ## AWS マネジメントコンソール を使用した T3 バースト可能インスタンスの作成 AWS マネジメントコンソール では、`db.t3.medium` インスタンスクラスを使用するプライマリ DB クラスターインスタンスまたはリードレプリカインスタンスを作成することも、`db.t3.medium` インスタンスクラスを使用するように既存のインスタンスを変更することもできます。 たとえば、Neptune コンソールで新しい DB クラスタープライマリインスタンスを作成するには、次のようにします。 + **[Create Database]** (データベースの作成) を選択します。 + **DB エンジンバージョン** `1.0.2.2` と同等以降を選びます。 + [**目的**] で、[**開発とテスト**] を選択します。 + [**DB インスタンスクラス**] としてデフォルト値 `db.t3.medium — 2 vCPU, 4 GiB RAM` を受け入れます。 ## AWS CLI を使用した T3 バースト可能インスタンスの作成 AWS CLI を使用して同じ作業を行うこともできます。 ``` aws neptune create-db-cluster \ --db-cluster-identifier (name for a new DB cluster) \ --engine neptune \ --engine-version "1.0.2.2" aws neptune create-db-instance \ --db-cluster-identifier (name of the new DB cluster) \ --db-instance-identifier (name for the primary writer instance in the cluster) \ --engine neptune \ --db-instance-class db.t3.medium ``` # Neptune DB インスタンスを変更する (その後すぐに適用する) Amazon Neptune DB インスタンスへのほとんどの変更は、すぐに適用するか、または次回のメンテナンスの期間まで延期できます。一部の変更 (パラメータグループの変更など) を適用するには、手動による DB インスタンスの再起動が必要になる場合があります。 **重要** 変更を適用するために Neptune が DB インスタンスを再起動する必要がある場合、変更が機能停止につながることがあります。DB インスタンスの設定を変更する前に、データベースとアプリケーションに対する影響を考慮してください。 ## 一般的な設定とダウンタイムに関する意義 次の表には、変更ができる設定、変更が適用される時間、変更により DB インスタンスのダウンタイムが生じるかどうかに関する詳細が含まれます。 **** | DB インスタンス設定 | ダウンタイムに関する注意 | | --- | --- | | **DB インスタンスクラス** | すぐに適用されるか、次のメンテナンスウィンドウ時に適用されるかにかかわらず、この変更時に機能停止が発生します。 | | **DB インスタンス識別子** | すぐに適用されるか、次のメンテナンスウィンドウ時に適用されるかにかかわらず、この変更時に DB インスタンスは再起動され、機能停止が発生します。 | | **サブネットグループ** | すぐに適用されるか、次のメンテナンスウィンドウ時に適用されるかにかかわらず、この変更時に DB インスタンスは再起動され、機能停止が発生します。 | | **セキュリティグループ** | 変更がいつ行われるかを指定しても、変更はできるだけ早く非同期的に適用され、停止は発生しません。 | – | | **認証機関** | デフォルトでは、新しい認証局を割り当てると, DB インスタンスは再起動されます。 | | **Database Port** | 変更は常に即時に行われるため、DB インスタンスが再起動され、機能停止が発生します。 | | **DB パラメータグループ** | この設定を変更しても機能は停止しません。パラメータグループ名自体は即時に変更されますが、フェイルオーバーなしでインスタンスを再起動するまで実際のパラメータの変更は適用されません。この場合、DB インスタンスは自動的には再起動されず、次のメンテナンスウィンドウ時にパラメータの変更は適用されません。ただし、新しく関連付けられた DB パラメータグループの動的パラメータを変更すると、これらの変更は再起動せずに直ちに適用されます。 詳細については、「[Amazon Neptune における DB インスタンスの再起動](manage-console-instances-reboot.md)」を参照してください。 | | **DB クラスターのパラメータグループ** | DB パラメータグループ名は直ちに変更されます。 | | **バックアップの保存期間** | 変更をすぐに実行するように指定した場合、この変更はすぐに実行されます。そうでない場合、設定を 0 以外の値から別の 0 以外の値に変更した場合、変更は可能な限り早く非同期的に適用されます。その他の変更は、次のメンテナンスウィンドウ時に行われます。0 から 0 以外の値、0 以外の値から 0 に変更した場合、機能停止が発生します。 | | **[監査ログ]** | CloudWatch ログを通じて監査ログを使用する場合は、**[監査ログ]** を選択します。監査ログを有効にするには、DB クラスターパラメータグループの `neptune_enable_audit_log` パラメータを `enable` (1) に設定する必要もあります。 | | **マイナーバージョン自動アップグレード** | Neptune DB クラスターに DB エンジンのマイナーバージョンアップグレードがリリースと同時に自動的に適用されるようにする場合は、**[Enable auto minor version upgrade]** (マイナーバージョン自動アップグレードの有効化) を選択します。 *[Auto minor version upgrade]* (自動マイナーバージョンアップグレード) オプションは、Amazon Neptune DB クラスターのマイナーエンジンバージョンに対するアップグレードにのみ適用されます。システム安定性を維持するために適用される定期的なパッチは適用されません。 | # Neptune DB インスタンスの名前変更 AWS マネジメントコンソール を使用して Amazon Neptune DB インスタンスの名前を変更します。DB インスタンスの名前を変更すると、広範囲に影響が及びます。DB インスタンスの名前を変更する前に知っておくべき事柄の一覧を次に示します。 + DB インスタンスの名前を変更すると、DB インスタンスに割り当てた名前が URL に含まれているため、DB インスタンスのエンドポイントが変更されます。必ず古い URL のトラフィックを新しい URL にリダイレクトする必要があります。 + DB インスタンスの名前を変更すると、DB インスタンスで使用されていた古い DNS 名はすぐに削除されますが、数分間キャッシュされたままになる場合があります。名前を変更した DB インスタンスの新しい DNS 名は、約 10 分後に有効になります。名前を変更した DB インスタンスは、新しい名前が有効になるまで使用できません。 + インスタンスの名前を変更する際に、既存の DB インスタンス名を使用することはできません。 + DB インスタンスに関連付けられたすべてのリードレプリカは、名前を変更した後もそのインスタンスに関連付けられたままになります。たとえば、本番データベースを提供する DB インスタンスがあり、そのインスタンスに複数の関連するリードレプリカがあるとします。DB インスタンスの名前を変更して本番環境で DB スナップショットに置き換えた場合、名前を変更した DB インスタンスにはリードレプリカが関連付けられたままになります。 + DB インスタンスの名前に関連付けられたメトリクスとイベントは、DB インスタンス名を再利用する場合も維持されます。例えば、リードレプリカを昇格させ、前のプライマリインスタンスの名前となるように名前を変更した場合、プライマリインスタンスに関連付けられたイベントとメトリクスは、名前が変更されたインスタンスに関連付けられます。 + DB インスタンスのタグは、名前を変更するかどうかにかかわらず DB インスタンスに残ります。 + 名前を変更した DB インスタンスの DB スナップショットは保持されます。 **Neptune コンソールを使用して DB インスタンスの名前を変更するには** 1. AWS マネジメントコンソールにサインインして Amazon Neptune コンソール ([https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home)) を開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. 名前を変更する DB インスタンスの横にあるラジオボタンを選択します。 1. [**Instance actions**] メニューで [**Modify**] を選択します。 1. [**DB instance identifier**] テキストボックスに新しい名前を入力します。[**Apply immediately**] を選択し、次に [**Continue**] を選択します。 1. [**Modify DB instance**] を選択して変更を完了します。 # Amazon Neptune における DB インスタンスの再起動 場合によっては、Amazon Neptune DB インスタンスを変更したり、インスタンスに関連付けられている DB パラメータグループを変更したり、インスタンスによって使用されるパラメータグループの静的データベースパラメータを変更したりすると、その変更を適用するためにインスタンスを再起動する必要があります。 DB インスタンスを再起動すると、データベースエンジンサービスが再起動されます。再起動により、関連付けられている DB パラメータグループに対して保留中になっていた変更も DB インスタンスに適用されます。DB インスタンスを再起動すると、そのインスタンスは一時的に機能停止になります。その間、DB インスタンスのステータスは [*rebooting*] に設定されます。Neptune インスタンスがマルチ AZ 用に構成されている場合、再起動はフェイルオーバーにより実行される可能性があります。再起動が完了すると、Neptune イベントが作成されます。 DB インスタンスがマルチ AZ 配置の場合は、[**Reboot (再起動)**] オプションを選択すると、1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンへのフェイルオーバーを強制的に実行できます。DB インスタンスのフェイルオーバーを強制すると、Neptune は別のアベイラビリティーゾーンでスタンバイレプリカに自動的に切り替わります。次に、DB インスタンスの DNS レコードが更新され、スタンバイ DB インスタンスを指します。その結果、DB インスタンスへの既存の接続のクリーンアップと再確立が必要になります。 [**Reboot with failover**] (フェイルオーバーによる再起動) が便利なのは、テスト用の DB インスタンスで障害をシミュレートするときや、フェイルオーバーの実行後にオペレーションを元のアベイラビリティーゾーンに復元するときです。詳細については、*Amazon RDS ユーザーガイド*の[高可用性 (マルチ AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) を参照してください。DB クラスターを再起動すると、そのスタンバイレプリカにフェイルオーバーします。Neptune レプリカを再起動しても、フェイルオーバーは開始されません。 再起動にかかる時間は、クラッシュ回復プロセスによって異なります。再起動時間を短くするには、再起動プロセス中のデータベースアクティビティをできる限り減らして、未完了のトランザクションのロールバックアクティビティが少なくなるようにすることをお勧めします。 コンソールでは、DB インスタンスが **[Available]** (利用可能) 状態ではない場合、**[Reboot]** (再起動) オプションが無効になる場合があります。その原因としては、進行中のバックアップ、お客様の要求による変更、メンテナンスウィンドウのアクションなどが考えられます。 **注記** [リリース: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md) より前は、DB クラスター内のすべてのリードレプリカインスタンスは、プライマリ (ライター) インスタンスが再起動するたびに自動的に再起動されていました。 [リリース: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md) 以降では、プライマリインスタンスを再起動しても、レプリカは再起動しません。つまり、クラスターパラメータを変更する場合、パラメータの変更を反映するには、各インスタンスを個別に再起動する必要があります (「[パラメータグループ](parameter-groups.md)」を参照)。 **Neptune コンソールを使用して DB インスタンスを再起動するには** 1. AWS マネジメントコンソールにサインインして Amazon Neptune コンソール ([https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home)) を開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. 再起動する DB インスタンスを選択します。 1. [**Instance actions**]、[**Reboot**] の順に選択します。 1. アベイラビリティーゾーン間でフェイルオーバーを強制的に実行するには、**DB インスタンスの再起動**ダイアログボックスから**フェイルオーバーによる再起動**を選択します。 1. [**再起動**] を選択します。逆に、再起動をキャンセルするには、[**Cancel**] (キャンセル) を選択します。 # Amazon Neptune の DB インスタンスを削除する インスタンスが開始していれば、どの状態の Amazon Neptune DB インスタンスでも随時削除できます。 **警告** **ウェブコンソール**を使用してクラスター内の最後の残りのインスタンスを削除すると、基盤となるクラスターストレージボリュームも削除されます。 ## DB インスタンスを削除する前に DB インスタンスの最終スナップショットを作成する DB インスタンスを削除するには、インスタンスの名前と、そのインスタンスの最終 DB スナップショットを作成するかどうかを指定する必要があります。削除する DB インスタンスのステータスが**作成中**の場合、最終 DB スナップショットを作成することはできません。DB インスタンスが**失敗**、**incompatible-restore** (互換性のない復元)、または **incompatible-network** (互換性のないネットワーク) というステータスのエラー状態にある場合は、`SkipFinalSnapshot` パラメータを `true` に設定しているときにのみ、インスタンスを削除できます。 を使用して DB クラスター内のすべての Neptune DB インスタンスを削除すると AWS マネジメントコンソール、DB クラスター全体は自動的に削除されます。 AWS CLI または SDK を使用している場合は、最後のインスタンスを削除した後に DB クラスターを手動で削除する必要があります。 **重要** DB クラスター全体を削除すると、自動バックアップはすべて同時に削除され、復旧できません。つまり、最終的な DB スナップショットを手動で作成しない限り、後で DB インスタンスを最終状態に復元することはできません。インスタンスの手動スナップショットは、クラスターを削除したときに削除されません。 削除する DB インスタンスにリードレプリカがある場合は、そのリードレプリカを昇格させるか、削除する必要があります。 以下の例では、DB インスタンスを削除する際に、最終的な DB スナップショットを作成する場合と作成しない場合の両方を示しています。 ## 最終スナップショットを作成しない DB インスタンスの削除 DB インスタンスを迅速に削除する必要がある場合は、最終 DB スナップショットの作成をスキップできます。DB インスタンスを削除すると、自動バックアップはすべて削除され、復旧できません。手動スナップショットは削除されません。 **Neptune コンソールを使用して最終的な DB スナップショットを作成せずに DB インスタンスを削除するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. **[インスタンス]** リストで、削除する DB インスタンスの横にあるラジオボタンを選択します。 1. **[インスタンスアクション]** を選択し、**[削除]** を選択します。 1. **[Create final snapshot?]** (最終スナップショットを作成しますか) ボックスで [**No**] (いいえ) を選択します。 1. **[削除]** を選択します。 ## 最終スナップショットを作成する DB インスタンスの削除 削除した DB インスタンスを後で復元可能にする必要がある場合、最終 DB スナップショットを作成できます。自動バックアップもすべて削除され、復旧できません。手動スナップショットは削除されません。 **Neptune コンソールを使用して最終的な DB スナップショットを作成せずに DB インスタンスを削除するには** 1. AWS マネジメントコンソールにサインインし、[https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home) で Amazon Neptune コンソールを開きます。 1. ナビゲーションペインで、**[Databases]** (データベース) を選択します。 1. **[インスタンス]** リストで、削除する DB インスタンスの横にあるラジオボタンを選択します。 1. **[インスタンスアクション]** を選択し、**[削除]** を選択します。 1. **[Create final snapshot?]** (最終スナップショットを作成しますか) ボックスで [**Yes**] (はい) を選択します。 1. [**Final snapshot name**] (最終スナップショット名) ボックスに、最終 DB スナップショットの名前を入力します。 1. **[削除]** をクリックします。 [instance-status API](access-graph-status.md) を使用して、インスタンスの状態の確認、インスタンスの種類の特定、現在インストールされているエンジンリリースバージョンの確認、インスタンスに関するその他の情報の取得を行うことができます。