

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 可靠性支柱
<a name="reliability-pillar"></a>

W AWS ell-Architected Fr [amework 的可靠性](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html)支柱包括工作负载能够在预期时正确、一致地执行其预期功能。这包括在工作负载的整个生命周期中对其进行操作和测试的能力。

可靠的工作负载始于前期的软件和基础设施设计决策。您的架构选择会影响您在所有 Well-Architected 支柱上的工作负载行为。为了提高可靠性，必须遵循一些特定的模式，如本节所述。

可靠性支柱侧重于以下关键领域：
+ 工作负载架构，包括服务配额和部署模式
+ 变更管理
+ 故障管理

## 了解 Neptune 服务配额
<a name="service-quotas"></a>

您的 AWS 账户对每个配额都有默认配额（以前称为*限制*） AWS 服务。除非另有说明，否则，每个配额是区域特定的。您可以申请提高部分（但不是全部）配额。

要查找 Neptune Analytics 的配额，请打开[服务配额控制台](https://console.aws.amazon.com/servicequotas/home)。在导航窗格中，选择 **AWS 服务**，然后选择**亚马逊 Neptune** Analytics。请注意图表和快照数量的配额、图表的最大预配置内存以及 API 请求速率。

如果最大预配置内存不足以容纳您的数据集，请评估哪些节点和边缘类型对于您的预期分析用途至关重要。加载数据子集，以便在允许的预配置容量内进行分析。许多分析工作负载，尤其是那些运行图形算法的工作负载，只需要具有有限属性的拓扑，而不是完整的交易图。（有关事务性工作负载和分析工作负载之间差异的讨论，请参阅[性能效率支柱](performance-efficiency-pillar.md)部分。）

如果图表的最大数量不足以满足您的预期用途：
+ 考虑组合具有相似用途的图表。
+ 评估在给定时间必须运行多少张图表。如果您有临时分析用例，请在不再需要图表时对其进行快照并删除。这减少了与配额对应的图表数量。
+ 请考虑不同的配置图 AWS 账户。

## 了解 Neptune 部署模式
<a name="deployment-patterns"></a>

计划部署 Neptune Analytics 图表时，请了解以下决策点：
+ **播种**：决定是创建空图，还是在创建时使用来自 Amazon S3、现有 Neptune 数据库集群或现有 Neptune 数据库快照的数据将数据加载到其中。

  建议：如果源是 Neptune 集群或快照，则必须在创建图表时加载其数据。如果源是 Amazon S3，则如果加载数据的工作量很大，并且最好作为基础设施配置活动执行，则在创建时加载数据。如果您更喜欢将数据作为数据工程或应用程序活动加载，请创建一个空图表并稍后从 Amazon S3 加载数据。
+ **容量**：根据数据大小和预期的应用程序使用情况，估计图表所需的预配置容量。

  建议：在创建时，[指定最大预配置内存](https://docs.aws.amazon.com/neptune-analytics/latest/apiref/API_CreateGraphUsingImportTask.html)以限制图形大小。此设置是强制性的。如有必要，您可以稍后更改容量。
+ **可用性和容错能力**：决定是否需要副本才能获得可用性。副本充当热备用副本，以便在图形出现故障时进行恢复。具有副本的图的恢复速度比没有副本的图更快。还要考虑图表需要多长时间，它是否仅用于临时分析，如果是，何时将其删除。

  建议：在创建图表之前，请确定可用性要求，例如图表不可用多长时间以及何时可以将其删除。
+ **网络和安全**：确定您是否需要公共连接、私有连接或两者兼而有之，以及是否要加密数据。

  建议**：**在创建图表之前，请先了解组织要求，例如是否允许公共连接以及图形客户端应用程序将在何处部署。
+ **备份和恢复**：确定是否应创建快照，如果是，则确定何时或在何种条件下创建。考虑您的组织是否有灾难恢复 (DR) 要求。

  建议：创建快照是一项手动活动。在创建图表之前，决定何时创建快照并考虑灾难恢复要求。

## 管理和扩展 Neptune 集群
<a name="clusters"></a>

Neptune Analytics 图表由单个内存优化实例组成。实例的容量 (m-ncU) 是在创建时设置的。通过[管理操作](https://docs.aws.amazon.com/neptune-analytics/latest/apiref/API_UpdateGraph.html)增加预配置容量，可以纵向扩展实例；也可以减少预配置容量。副本是被动的故障转移目标，因此它们不会增加图表的规模。在这方面，图形副本不同于 Nep [tune 数据库只读副本](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-add-replicas.html)，后者是 Neptune 集群中的活动实例，可以处理来自应用程序的读取操作。

副本会产生成本。该副本按图表的 m-ncU 价格定价。例如，如果一个图表预配置了 128 m-nCU 并且具有单个副本，则成本是没有副本的同等图表的两倍。

在分析领域，扩大规模有两个主要原因：
+ 为了为分析查询和算法提供更多的内存和 CPU，由于单个查询的成本很高，因此要运行的图形算法本质上很复杂，并且根据其输入需要更多的资源，或者并发请求速率很高。如果此类查询遇到 out-of-memory错误，则扩大规模是一种合理的补救措施。
+ 支持比计划更大的图表大小。例如，如果当前预配置的容量为 128 M-nCU 以支持 60 GB 的源数据，而您又需要增加 40 GB 的源数据，则有必要将容量增加到 256 M-nCU。

监控 Neptune Analytics 的 CloudWatch 指标，例如`NumQueuedRequestsPerSec``NumOpenCypherRequestsPerSec``GraphStorageUsagePercent`、`GraphSizeBytes`、`CPUUtilization`、和，以确定是否需要扩展。您可以通过控制台、或 AWS CLI，更新图表的配置 SDKs。（有关示例和最佳实践，请参阅[卓越运营支柱](operational-excellence-pillar.md)部分。）

## 管理备份和故障转移事件
<a name="failover"></a>

使用副本来确保图形在出现故障时仍然可用。图表使用基于日志的持久性在中跨可用区提交更改。 AWS 区域副本充当热备用副本，可以访问这些数据。如果出现故障，图表将恢复对副本的操作。应用程序继续使用相同的端点连接到图表。故障期间的动态请求会生成错误，并出现*服务不可用*异常。考虑在应用程序代码中使用[带退避模式的重试](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html)来捕获错误，然后在短暂的间隔后重试。在故障转移期间发出的新请求会被排队，延迟时间可能会更长。

如果未配置任何副本并且图表出现故障，Neptune Analytics 将从持久存储中恢复，但恢复需要更长的时间，因为 Neptune 必须重新初始化资源。

创建图表的快照。（Neptune Analytics 不自动拍摄快照。） 如果图表在创建后定期修改，请经常拍摄快照以捕捉其当前状态。如果不需要恢复到较早的时间点，请删除较早的快照。

您可以与其他账户共享快照，也可以跨账号共享快照 AWS 区域。如果您有灾难恢复要求，请考虑从快照恢复不同区域的图表是否符合您的恢复时间目标 (RTO) 和恢复点目标 (RPO) 要求。