信頼性の柱

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

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

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

• サービスクォータとデプロイパターンを含むワークロードアーキテクチャ

• 変更管理

• 障害管理

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

Neptune クラスターボリュームは、クォータが 64 TiB である中国と GovCloud AWS リージョン を除くサポートされているすべての で最大サイズ 128 テビバイト (TiB) まで拡張できます。

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

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

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

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

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

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

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