View a markdown version of this page

卓越运营支柱 - AWS 规范性指导
使用 IaC 方法自动部署频繁进行可逆的小规模更改预测故障从所有操作故障中吸取教训使用日志记录功能来监控未经授权或异常的活动

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

卓越运营支柱

Well-Architect AWS ed Framework 的卓越运营支柱侧重于运行和监控系统，以及不断改进流程和程序。其中包括有效地支持开发和运行工作负载的能力，获取对运营的洞察，以及不断改进支持流程和程序以实现业务价值。您可以通过自我修复工作负载降低运营复杂性，这些工作负载无需人工干预即可检测和修复大多数问题。您可以通过遵循本节中描述的最佳实践来努力实现这一目标。当您的工作负载偏离预期行为时 APIs，使用 Amazon Neptune 指标和机制来正确响应。

本次对卓越运营支柱的讨论侧重于以下关键领域：

  • 基础设施即代码（IaC）

  • 变更管理

  • 韧性策略

  • 事件管理

  • 合规性审计报告

  • 日志记录和监控

使用 IaC 方法自动部署

使用 IaC 在 Neptune 上自动部署的最佳实践包括：

  • 尽可能应用基础设施即代码 (IaC) 来部署 Neptune 集群。为了实现一致的环境配置，请使用AWS CloudFormation模板或 HashiCorp Terraform 为集群创建所有必需的资源。AWS Cloud Development Kit (AWS CDK)

  • 尽可能自动执行 Neptune 操作程序，例如调整实例大小、添加或删除只读副本，或者对全局表进行手动失效转移。

  • 将连接字符串存储在客户端外部。使用提取、转换和加载 (ETL) 流程来促进 blue/green 部署策略、灾难恢复 (DR) 以及向新集群的近乎零的停机迁移。连接字符串可以存储在 AWS Secrets Manager、Amazon DynamoDB 或任何可以动态更改它们的位置。

  • 使用标签向 Neptune 资源添加元数据并基于标签跟踪使用情况。有关更多信息，请参阅标记 Amazon Neptune 资源。

频繁进行可逆的小规模更改

以下建议侧重于小的、可逆的更改，以最大限度地降低复杂性并降低工作负载中断的可能性：

  • 将 IaC 模板和脚本存储在源代码控制服务中，例如 GitHub 或 GitLab。

    重要

    不要在源代码管理中存储 AWS 凭据。

  • 要求 IaC 部署才能使用持续集成和持续交付（CI/CD）服务，例如 AWS CodePipeline 或 AWS CodeBuild。这些服务会在包含临时 Neptune 集群的非生产环境中编译、测试和部署代码，然后再影响您的生产 Amazon Neptune 集群。

  • 在将基础设施和应用程序查询部署到生产环境之前，先在较低的环境中对其进行测试。这将最大限度地减少中断的可能性，并有助于确保它们在您的工作负载和扩展下表现良好。

预测故障

自我修复的基础设施通过预测故障并尝试在没有干预的情况下解决任何问题来体现卓越运营。以下建议可以帮助您使用 Neptune 实现该成熟度：

  • 创建使用 Amazon CloudWatch 指标监控数据库实例的 CPU 和内存使用情况并了解使用模式的监控计划。为应用程序日志中的关键指标和 Neptune 客户端响应创建 CloudWatch仪表板和警报。有关 CPU 利用率高或低指标的更多信息，请参阅 Neptune CloudWatch 文档中的使用在 Neptune 中监控数据库实例性能。

    如果您经常在查询中遇到 out-of-memory异常，可以考虑减少查询遍历的节点总数，或者尝试使用该X2系列中的实例，该实例的比例更高 RAM-to-CPU。

  • 设置通知以监控 Neptune 集群的运行状况。例如，BufferCacheHitRatio 应始终处于高位（大于 99.9%），而 MainRequestQueuePendingRequests 应始终保持较低水平（理想情况下为 0，但取决于您的要求和延迟容忍度）。

  • 考虑使用只读副本在 Neptune 内实现高可用性。您应该在与写入器实例不同的可用区中至少有两个只读副本，以确保在失效转移事件期间，实例始终可用于处理读取查询。

  • 根据利用率指标自动扩展只读副本。有关更多信息，请参阅自动扩缩 Amazon Neptune 数据库集群中的副本数量。

  • 测试您的数据库实例的故障转移，以了解对于您的使用案例而言，该过程需要多长时间。

  • 如果您的应用程序需要在完全 AWS 区域 中断后存活下来，请考虑将全局数据库作为灾难恢复计划的一部分。

从所有操作故障中吸取教训

自我修复基础设施是一项长期的工作，当出现罕见问题或响应效果不如预期时，它会不断迭代发展。采取以下实践有助于集中精力实现该目标：

  • 从所有故障中吸取教训，推动改进。

  • 在团队和组织内部分享经验教训。如果组织内有多个团队使用 Neptune，请创建一个公共聊天室或用户群组，以便分享经验和最佳实践。

使用日志记录功能来监控未经授权或异常的活动

要观察异常性能和活动模式，请将日志存储在 Ama CloudWatch zon 日志中。考虑下面的最佳实践：

  • 启用慢速查询日志记录。定期查看日志并诊断某些查询缓慢的原因。使用适用于 Gremlin、SPARQL 或 openCypher 的 Neptune explain 和 profile 端点，来深入了解这些查询缓慢的原因。

  • 启用 Neptune 审核日志，并定期查看日志中是否存在未经授权的访问或异常情况。

  • 如果您使用的是慢查询日志记录或审核日志记录，请启用发布到 CloudWatch 日志。这将帮助您避免实例上的磁盘空间不足。Neptune 实例的日志存储容量有限，超过日志空间时会覆盖较旧的日志文件。 CloudWatch 日志支持长期保留日志。 CloudWatch 日志中增强的监控功能将提高您查询日志和诊断问题的能力。

  • 为了便于使用更好的审计日志分析工具，您可以将 Neptune 数据库集群配置为在 Logs 中将审计日志数据发布到日志组中 CloudWatch 。借助 CloudWatch 日志，您可以对日志数据进行实时分析，用于 CloudWatch 创建警报和查看指标，并使用 CloudWatch 日志将日志记录存储在高度耐用的存储中。有关更多信息，请参阅将 Nep tune 日志发布到 Ama CloudWatch zon 日志。

  • Neptune 支持使用 AWS CloudTrail记录控制面板操作。有关更多信息，请参阅使用记录亚马逊 Neptune API 调用。 AWS CloudTrail