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

信頼性の柱

信頼性の柱には、ワークロードが意図した機能を正しく一貫して実行する能力が含まれます。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。

信頼性の高いワークロードの実現は、ソフトウェアとインフラストラクチャの両方について事前に設計を決定することから始まります。アーキテクチャの選択は、 AWS Well-Architected のすべての柱にわたってワークロードの動作に影響します。高い信頼性を保つには、特定のパターンに従う必要があります。

信頼性の柱は、次の主要分野に焦点を当てています。

Neptune サービスクォータを理解する

Neptune クラスターボリュームは、クォータが 64 TiB である中国と GovCloud を除くすべてのサポート対象の AWS リージョン で、最大 128 tebibytes (TiB) のサイズまで増やすことができます。

128 TiB のクォータでは、グラフに約 2,000～4,000 億個のオブジェクトを十分に保存することができます。ラベル付きプロパティグラフ (LPG) では、オブジェクトはノード、エッジ、またはノードもしくはエッジ上のプロパティです。Resource Description Framework (RDF) グラフでは、オブジェクトは四角形です。

任意の Neptune サーバーレスクラスターでは、Neptune 容量ユニット (NCU) の最小数と最大数の両方を設定します。各 NCU は、2 ギビバイト (GiB) のメモリと、関連する vCPU およびネットワークで構成されます。最小および最大 NCU 値は、クラスター内のサーバーレスインスタンスに適用されます。設定できる最高の最大 NCU 値は 128.0 NCU であり、最低の最小値は 1.0 NCU です。Amazon CloudWatch メトリクス ServerlessDatabaseCapacity および NCUUtilization を監視し、一般的に実行される範囲をキャプチャしてその範囲内の望ましくない動作やコストを関連付けることで、アプリケーションに最適な NCU 範囲を最適化します。多くのワークロードでは、1.0 NCU の開始点が低すぎるため、非アクティブ状態が続くと動作の信頼性が低下します。ワークロードが十分に速くスケーリングしない場合は、スケーリング中の最初のサージに対して十分な処理を提供するように最小 NCU を増やします。

各 AWS アカウント には、作成できるデータベースリソースの数に対する各リージョンのクォータがあります。これらのリソースには、DB インスタンスと DB クラスターが含まれます。リソースの制限に達すると、リソースを作成するための追加の呼び出しは、例外が発生して失敗します。一部のクォータはソフトクォータで、リクエストにより引き上げることができます。Amazon Neptune と Amazon RDS、Amazon Aurora、Amazon DocumentDB (MongoDB 互換) の間で共有されるクォータのリストと、クォータの引き上げをリクエストするためのリンク (利用可能な場合) については、「Amazon RDS のクォータ」を参照してください。

Neptune デプロイパターンを理解する

Neptune DB クラスターには、1 つのプライマリ DB インスタンスと最大 15 の Neptune レプリカがあります。プライマリ DB インスタンスでは、読み書きオペレーションをサポートしており、クラスターボリュームに対してすべてのデータ変更を実行します。Neptune レプリカは、プライマリ DB インスタンスと同じストレージボリュームに接続し、読み取りオペレーションのみサポートしています。Neptune レプリカは、プライマリ DB インスタンスから読み取りワークロードをオフロードします。

高可用性を実現するには、リードレプリカを使用します。異なるアベイラビリティーゾーンで 1 つ以上のリードレプリカインスタンスを利用可能にすると、リードレプリカがプライマリインスタンスのフェイルオーバーターゲットとして機能するため、可用性が向上します。ライターインスタンスが失敗した場合、Neptune はリードレプリカインスタンスをプライマリインスタンスに昇格します。そうすると、プライマリインスタンスに対して行われた読み取り要求と書き込み要求が失敗して例外が発生すると、短時間の中断 (通常は 30 秒未満) が発生し、昇格したインスタンスは再起動されます。最高の信頼性を得るには、2 つのリードレプリカを別々のアベイラビリティーゾーンに使用することを検討してください。アベイラビリティーゾーン 1 のプライマリインスタンスがオフラインになった場合、アベイラビリティーゾーン 2 のインスタンスはプライマリに昇格されますが、その間はクエリを処理できません。したがって、移行中に読み取りクエリを処理するには、アベイラビリティーゾーン 3 のインスタンスが必要です。

Neptune サーバーレスを使用している場合、すべてのアベイラビリティーゾーンのリーダーインスタンスとライターインスタンスは、データベースの負荷に応じて、互いに独立してスケールアップおよびスケールダウンします。リーダーインスタンスの昇格階層を 0 または 1 に設定すると、ライターインスタンスの容量に合わせてスケールアップまたはスケールダウンできます。これにより、現在のワークロードをいつでも引き継ぐ準備が整います。

アプリケーションにグローバルなフットプリントがある場合、またはマルチリージョンフェイルオーバーが必要な場合は、Neptune グローバルデータベースの使用を検討してください。Amazon Neptune グローバルデータベースは複数のデータベースにまたがり AWS リージョン、低レイテンシーのグローバル読み取りを可能にし、停止が 全体に影響を与えるまれなケースで高速リカバリを提供します AWS リージョン。Neptune グローバルデータベースは、1 つのリージョンにあるプライマリ DB クラスターと、異なるリージョンにある最大 5 つのセカンダリ DB クラスターで構成されます。

Neptune クラスターの管理とスケーリング

Neptune 自動スケーリングを使用すると、DB クラスター内の Neptune レプリカの数を自動的に調整して、CPU 利用率のしきい値に基づいて接続およびワークロードの要件を満たすことができます。自動スケーリングを使用すると、Neptune DB クラスターはワークロードの急激な増加を処理できます。ワークロードが減少すると、自動スケーリングは不要なレプリカを削除し、未使用の容量に対して料金が発生しないようにします。新しいインスタンスの起動には最大 15 分かかる場合があるため、自動スケーリングだけでは需要の急激な変化に対する十分なソリューションにはならないことに注意してください。

自動スケーリングは、既に 1 つのプライマリライターインスタンスと、少なくとも 1 つのリードレプリカインスタンスを持つ Neptune DB クラスターでのみ使用できます (「Amazon Neptune DB Clusters and Instances」を参照)。また、クラスター内のすべての read-replica インスタンスが使用可能な状態である必要があります。リードレプリカが使用可能以外の状態にある場合、クラスター内のすべてのリードレプリカが使用可能になるまで、Neptune 自動スケーリングは何もしません。

需要が急速に変化する場合は、サーバーレスインスタンスの使用を検討してください。サーバーレスインスタンスは短期間で垂直方向にスケールできる一方、自動スケーリングは長期間にわたり水平方向にスケールできます。この設定では、サーバーレスインスタンスが垂直方向にスケールし、自動スケーリングは新しいリードレプリカをインスタンス化して、単一のサーバーレスインスタンスの最大容量を超えるワークロードを処理するため、最適なスケーラビリティを提供します。Amazon Neptune サーバーレスの容量スケーリングの詳細については、「Neptune Serverless DB クラスタの容量スケーリング」を参照してください。

スケーリングのニーズが予測可能なタイミングで変化する場合は、最小インスタンス、最大インスタンス、しきい値に対する変更をスケジュールして、そうした変化するニーズをより適切に処理することができます。必要に応じて、少なくとも 15 分前にスケールアウトイベントをスケジュールして、インスタンスがオンラインになるようにしてください。

パラメータグループのパラメータを使用して、Amazon Neptune のデータベース設定を管理します。パラメータグループは、1 つ以上の DB インスタンスに適用されるエンジン設定値のコンテナとして機能します。パラメータグループのクラスターパラメータを変更するときは、静的パラメータと動的パラメータの違いと、それらを適用する方法とタイミングを理解してください。ステータスエンドポイントを使用して、現在適用されている設定を確認します。

バックアップとフェイルオーバーイベントを管理する

Neptune は、クラスターボリュームを自動的にバックアップし、バックアップ保持期間中、バックアップしたデータを保持します。Neptune のバックアップは連続的かつ増分的であるため、バックアップ保持期間内の任意の時点にすばやく復元できます。DB クラスターを作成または変更するときに、バックアップ保持期間を 1～35 日の間で指定できます。

バックアップ保持期間を超えたバックアップを保持するには、クラスターボリュームの中にデータのスナップショットを作成できます。スナップショットの保存には、Neptune の標準ストレージ料金がかかります。

DB クラスターの Amazon Neptune のスナップショットを作成すると、Neptune はクラスターのストレージボリュームのスナップショットを作成し、個々のインスタンスだけではなく、すべてのデータをバックアップします。新しい DB クラスターは、この DB クラスタースナップショットから復元することで後に作成できます。DB クラスターを復元する場合は、復元の元となる DB クラスタースナップショットの名前を指定し、復元によって作成される新しい DB クラスターの名前を指定します。

フェイルオーバーイベントに対するシステムの応答をテストします。Neptune API を使用してフェイルオーバーイベントを強制します。フェイルオーバーによる再起動が便利なのは、テスト用の DB インスタンスで障害をシミュレートするときや、フェイルオーバーの実行後にオペレーションを元のアベイラビリティーゾーンに復元するときです。詳細については、「マルチ AZ 配置の設定と管理」を参照してください。DB ライタークラスターを再起動すると、そのスタンバイレプリカにフェイルオーバーします。Neptune レプリカを再起動しても、フェイルオーバーは開始されません。

クライアントの信頼性を確保するよう設計します。フェイルオーバーイベント中に動作をテストします。エクスポネンシャルバックオフロジックを使用して、クライアントに再試行ロジックを実装します。このロジックを実装するコード例は、AWS Lambda Amazon Neptune の関数例のドキュメントにあります。

複数のデータベースエンジンに適用される一般的なバックアップ要件のセットがある場合は、AWS Backup の使用を検討してください。