翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 信頼性の柱
AWS Well-Architected フレームワーク[の信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html)には、ワークロードが意図した機能を正しく一貫して実行する能力が含まれます。これには、ライフサイクル全体を通じてワークロードを運用およびテストする機能が含まれます。
信頼性の高いワークロードの実現は、ソフトウェアとインフラストラクチャの両方について事前に設計を決定することから始まります。アーキテクチャの選択は、Well-Architected のすべての柱にわたってワークロードの動作に影響します。信頼性のために、このセクションで説明するように、従う必要がある特定のパターンがあります。
信頼性の柱は、次の主要分野に焦点を当てています。
+ サービスクォータやデプロイパターンなどのワークロードアーキテクチャ
+ 変更管理
+ 障害管理
## Neptune サービスクォータを理解する
AWS アカウントには、 ごとにデフォルトのクォータ (以前は*制限*と呼ばれていました) があります AWS のサービス。特に明記していない限り、クォータはリージョン固有です。一部のクォータの引き上げをリクエストできますが、すべてではありません。
Neptune Analytics のクォータを確認するには、[Service Quotas コンソール](https://console.aws.amazon.com/servicequotas/home)を開きます。ナビゲーションペインで、 を選択し**AWS のサービス**、**Amazon Neptune Analytics** を選択します。グラフとスナップショットの数、グラフの最大プロビジョニングメモリ、API リクエストレートのクォータに注意してください。
最大プロビジョニングメモリがデータセットに十分でない場合は、意図した分析用途に不可欠なノードとエッジタイプを評価します。データのサブセットをロードして、許容されるプロビジョニングされた容量内で分析できるようにします。多くの分析ワークロード、特にグラフアルゴリズムを実行するワークロードでは、完全なトランザクショングラフではなく、プロパティのセットが制限されたトポロジのみが必要です。（トランザクションワークロードと分析ワークロードの違いについては、[「パフォーマンス効率の柱](performance-efficiency-pillar.md)」セクションを参照してください）。
グラフの最大数が意図した用途に十分でない場合：
+ 同様の用途を持つグラフを組み合わせることを検討してください。
+ 一度に実行する必要があるグラフの数を評価します。エフェメラル分析のユースケースがある場合は、不要になったグラフをスナップショットして削除します。これにより、クォータに対するグラフの数が減少します。
+ 異なる でグラフをプロビジョニングすることを検討してください AWS アカウント。
## Neptune のデプロイパターンを理解する
Neptune Analytics グラフをデプロイする場合は、次の決定点を理解します。
+ **シード**: Amazon S3、既存の Neptune データベースクラスター、または既存の Neptune データベーススナップショットのデータを使用して、空のグラフを作成するか、作成時にそのグラフにデータをロードするかを決定します。
推奨事項: ソースが Neptune クラスターまたはスナップショットの場合は、グラフ作成時にデータをロードする必要があります。ソースが Amazon S3 の場合、データをロードする労力が重要で、インフラストラクチャのプロビジョニングアクティビティとして最適である場合は、作成時にデータをロードします。データエンジニアリングまたはアプリケーションアクティビティとしてデータをロードする場合は、空のグラフを作成し、後で Amazon S3 からデータをロードします。
+ **容量**: データサイズと予想されるアプリケーション使用量を考慮して、グラフに必要なプロビジョニングされた容量を見積もります。
推奨事項: 作成時に、グラフサイズを制限する[最大プロビジョニングメモリを指定します](https://docs.aws.amazon.com/neptune-analytics/latest/apiref/API_CreateGraphUsingImportTask.html)。この設定は必須です。必要に応じて、後で容量を変更できます。
+ **可用性と耐障害性**: 可用性にレプリカが必要かどうかを決定します。レプリカは、グラフに障害が発生した場合の復旧のためのウォームスタンバイとして機能します。レプリカを含むグラフは、レプリカを含まないグラフよりも速く回復します。また、グラフが必要な期間、エフェメラル分析専用かどうか、必要な場合はいつ削除されるかも考慮してください。
推奨事項: グラフを作成する前に、グラフを使用できない時間や削除できる時間などの可用性要件を決定します。
+ **ネットワークとセキュリティ**: パブリック接続、プライベート接続、またはその両方が必要かどうか、およびデータを暗号化するかどうかを決定します。
推奨事項**: **グラフを作成する前に、パブリック接続が許可されているかどうか、グラフクライアントアプリケーションがデプロイされる場所など、組織の要件を理解します。
+ **バックアップとリカバリ**: スナップショットを作成するかどうか、作成する場合は、いつ、どの条件でスナップショットを作成するかを決定します。組織にディザスタリカバリ (DR) 要件があるかどうかを検討します。
推奨事項: スナップショットの作成は手動アクティビティです。スナップショットを作成するタイミングを決定し、グラフを作成する前に DR 要件を検討します。
## Neptune クラスターの管理とスケーリング
Neptune Analytics グラフは、単一のメモリ最適化インスタンスで構成されます。インスタンスの容量 (m-NCU) は作成時に設定されます。インスタンスは、[管理アクション](https://docs.aws.amazon.com/neptune-analytics/latest/apiref/API_UpdateGraph.html)を通じてプロビジョニングされた容量を増やすことで垂直方向にスケーリングできます。また、プロビジョニングされた容量を減らすこともできます。レプリカはパッシブフェイルオーバーターゲットであるため、グラフのスケールは増加しません。この点で、グラフレプリカは、アプリケーションからの読み取りオペレーションを処理できる [Neptune クラスター内のアクティブなインスタンスである Neptune データベースリードレプリカ](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-add-replicas.html)とは異なります。
レプリカにはコストがかかります。レプリカの料金はグラフの m-NCU レートです。たとえば、グラフが 128 m-NCU に対してプロビジョニングされ、レプリカが 1 つある場合、コストはレプリカを持たない同等のグラフの 2 倍になります。
分析では、スケールアップの主な理由が 2 つあります。
+ 分析クエリとアルゴリズムにより多くのメモリと CPU を提供するために、個々のクエリは高価であるため、実行するグラフアルゴリズムは本質的に複雑で、入力を考慮するとより多くのリソースを必要とするか、同時リクエストレートが高いです。このようなクエリでout-of-memoryエラーが発生した場合は、スケールアップが妥当な解決策です。
+ 計画よりも大きいグラフサイズをサポートするには。たとえば、現在のプロビジョニングされた容量が 60 GB のソースデータをサポートするために 128 m-NCU で、さらに 40 GB のソースデータが必要な場合は、256 m-NCU への引き上げが必要です。
`NumQueuedRequestsPerSec`、、、、 などの Neptune Analytics `NumOpenCypherRequestsPerSec`の CloudWatch `GraphStorageUsagePercent`メトリクスをモニタリングして`GraphSizeBytes``CPUUtilization`、スケーリングが必要かどうかを判断します。グラフの設定は、コンソール AWS CLI、または SDKs を使用して更新できます。（例とベストプラクティスについては、[「オペレーショナルエクセレンスの柱](operational-excellence-pillar.md)」セクションを参照してください）。
## バックアップとフェイルオーバーイベントを管理する
レプリカを使用して、障害発生時にグラフを使用できるようにします。グラフはログベースの永続性を使用して、 のアベイラビリティーゾーン間で変更をコミットします AWS リージョン。レプリカはウォームスタンバイとして機能し、このデータにアクセスできます。失敗した場合、グラフはレプリカのオペレーションを再開します。アプリケーションは引き続き同じエンドポイントを使用してグラフに接続します。失敗中の処理中のリクエストは、*サービス利用不可*の例外を含むエラーを生成します。アプリケーションコードの[バックオフパターンで再試行](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)してエラーをキャッチし、短い間隔で再試行することを検討してください。フェイルオーバー中に行われた新しいリクエストはキューに入れられ、レイテンシーが長くなる可能性があります。
レプリカが設定されておらず、グラフが失敗した場合、Neptune Analytics は耐久性のあるストレージから復旧しますが、Neptune がリソースを再初期化する必要があるため、復旧に時間がかかります。
グラフのスナップショットを作成します。(Neptune Analytics は自動スナップショットを作成しません）。作成後にグラフが定期的に変更される場合は、スナップショットを頻繁に作成して現在の状態をキャプチャします。以前の時点への復元が必要ない場合は、古いスナップショットを削除します。
スナップショットは、他の アカウントと共有できます AWS リージョン。DR 要件がある場合は、スナップショットから別のリージョンのグラフを復元することが、目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たしているかどうかを検討してください。