IDP Well-Architected Custom Lens（IDP 架构的自定义镜头） 适用于所有使用 AWS 运行智能文档处理（IDP）解决方案的 AWS 客户，并正在寻求有关如何在 AWS 上构建安全、高效和可靠的 IDP 解决方案的指导。
在云中构建可投入生产的解决方案涉及一系列资源、时间、客户期望和业务结果之间的折衷。 AWS 架构遵循指南 帮助您了解在 AWS 上构建工作负载时所做决策的优势和风险。通过使用该架构，您将学习在云中设计和运营可靠、安全、高效、具有成本效益和可持续性的工作负载的操作和架构最佳实践。
IDP 项目通常结合光学字符识别（OCR）和自然语言处理（NLP）来读取和理解文档并提取特定术语或词语。 IDP 架构的自定义镜头概述了执行 AWS 架构审查的步骤，让您评估和识别 IDP 工作负载的技术风险。它提供指南来应对我们在该领域中看到的常见挑战，支持您根据最佳实践构建您的 IDP 工作负载。
本文重点介绍 IDP 解决方案的可靠性支柱。我们将从可靠性支柱和设计原则的介绍开始，然后深入探讨基础、变更管理和故障管理三个重点领域的解决方案设计和实施。通过阅读本文，您将了解 IDP 案例研究中 Well-Architected 架构中的可靠性支柱。
设计原则
可靠性支柱包括 IDP 解决方案在预期期间正确和一致地执行文档处理以及根据定义的业务规则进行处理的能力。这包括操作和测试完整的 IDP 工作流程及其完整的生命周期的能力。
有一些原则可以帮助您提高可靠性。在我们讨论最佳实践时，请牢记这些原则：
- 故障自动恢复 – 通过监视 IDP 工作流程的关键性能指标（KPI），当达到阈值时可以运行自动化。这使您能够自动跟踪并在任何故障发生时收到通知，并触发自动恢复过程以绕过或修复故障。根据 KPI 的测量结果，您还可以预测故障并在发生之前应用补救措施。
- 测试恢复程序 – 测试您的 IDP 工作流程失败情况，并验证恢复程序。使用自动化模拟不同的情景或重新创建导致故障的情景。
- 缩放和调整服务容量 – 监视 IDP 工作流程的需求和使用情况，并自动调整 AWS 服务容量，以维持满足需求的最佳水平，而不过度或欠缺预配。控制并了解您的 IDP 组件服务的服务定额、限制和约束，例如 Amazon Textract 和 Amazon Comprehend。
- 自动化更改 – 在应用更改到您的 IDP 工作流程基础设施时使用自动化。通过自动化管理更改，然后可以进行跟踪和审查。
重点领域
可靠性支柱的设计原则和最佳实践基于我们的客户和 IDP 技术专家社区收集的见解。将它们作为设计决策的指导和支持，并与您的 IDP 解决方案的业务要求相一致。应用 IDP 架构遵循镜头可以帮助您验证 IDP 解决方案设计的弹性和效率，并提供建议以解决可能发现的任何差距。
以下是云中 IDP 解决方案可靠性的最佳实践领域：
- 基础 – AWS AI 服务如 Amazon Textract 和 Amazon Comprehend 为不同使用维度提供一组软性和硬性限制。重要的是要审查这些限制，并确保您的 IDP 解决方案遵守任何软性限制，同时不超过任何硬性限制。
- 变更管理 – 将您的 IDP 解决方案视为基础设施即代码（IaC），使您能够自动化监控和变更管理。在组件（如基础设施和 Amazon Comprehend 自定义模型）之间使用版本控制，并将变更跟踪到某个时间点的发布。
- 故障管理 – 由于 IDP 工作流程是一种事件驱动的解决方案，您的应用程序必须能够处理已知和未知错误。良好架构的 IDP 解决方案通过使用日志记录和重试机制来预防故障并在发生时承受故障。设计弹性到您的 IDP 工作流程架构中并计划灾难恢复非常重要。
基础知识
AWS AI服务提供现成的智能功能，例如使用Amazon Textract、Amazon Comprehend和Amazon Augmented AI（Amazon A2I）进行自动数据提取和分析，用于您的IDP工作流。这些服务设定了服务限制（或配额），以避免过度消耗资源，并限制API操作的请求速率，保护服务免受滥用。
在规划和设计IDP解决方案架构时，请考虑以下最佳实践：
- 了解不可更改的Amazon Textract和Amazon Comprehend服务配额、限制和约束– 接受的文件格式、大小和页数、语言、文档旋转和图像大小是Amazon Textract的一些不可更改的硬限制示例，无法更改。
- 接受的文件格式包括JPEG、PNG、PDF和TIFF文件。（PDF中的JPEG 2000编码图像也受支持）。如果文件格式不受支持（例如Microsoft Word或Excel），使用Amazon Textract之前需要进行文档预处理。在这种情况下，您必须将不受支持的文档格式转换为PDF或图像格式。
- Amazon Comprehend对内置模型、自定义模型和飞轮有不同的配额。确保您的用例与Amazon Comprehend的配额相匹配。
- 调整Amazon Textract和Amazon Comprehend服务的配额以满足需求– Amazon Textract服务配额计算器可以帮助您估计覆盖您用例的配额值。如果您计划在不同账户或区域之间进行灾难恢复故障转移，请管理好您的服务配额。在请求增加Amazon Textract配额时，请确保遵循以下建议：
- 使用Amazon Textract服务配额计算器估计您的最佳配额值。
- 请求更改可能导致网络流量剧增，影响吞吐量。使用队列化无服务器架构或其他机制来平滑流量，并最大限度地利用每秒分配的事务数（TPS）。
- 实施重试逻辑以处理被限制的调用和断开的连接。
- 配置指数回退和抖动以提高吞吐量。
变更管理
必须预见和适应IDP工作流或其环境的变更，例如需求激增或受损的文档文件，以实现更高的解决方案可靠性。这些变更的部分内容在前一节的基础最佳实践中已有涵盖，但仅仅这些还不足以应对变更。还必须考虑以下最佳实践：
- 使用Amazon CloudWatch监控IDP工作流组件，例如Amazon Textract和Amazon Comprehend。从IDP工作流中收集指标，自动响应警报，并按需发送通知给您的工作流和业务目标。
- 使用IaC（基础设施即代码）（例如AWS Cloud Development Kit（AWS CDK）和预构建的IDP AWS CDK构造），通过自动化部署IDP工作流解决方案和所有基础设施更改。这样可以消除引入人为错误的可能性，并使您能够在切换到生产环境之前进行测试。
- 如果您的用例需要使用Amazon Comprehend自定义模型，考虑使用飞轮来简化随时间改进自定义模型的过程。飞轮协调与训练和评估新的自定义模型版本相关的任务。
- 如果您的用例需要，可以通过训练和使用Amazon Textract预训练的查询特性的适配器来自定义输出。创建适配器查询时，请遵循以下最佳实践：
- 适配器配额定义了适配器训练的限制。请考虑这些限制，并在需要时提出服务配额增加请求：
- 最大适配器数量– 允许的适配器数量（一个适配器下可以有多个适配器版本）。
- 每月最多创建的适配器版本数量– 每个AWS账户每月可以创建的成功适配器版本数量。
- 同时进行适配器版本数量上限– 每个账户正在进行的适配器版本数量（适配器训练）。
- 确保使用一组代表您用例的文件进行训练（至少包括五个训练文档和五个测试文档）。
- 尽可能提供更多的训练文档（最多可提供 2,500 页的训练文档和 1,000 页的测试文档）。
- 使用各种答案注释查询。例如，如果对查询的答案是“是”或“否”，则注释样本应包含“是”和“否”的出现。
- 在注释字段时保持注释样式的一致性，并在注释字段中使用空格。
- 在推理中使用与训练时完全相同的查询。
- 在每轮适配器训练之后，查看性能指标以确定是否需要进一步改进适配器以实现目标。在开始新的训练以创建改进版本的适配器之前，上传新的文档集以进行训练或者查看低准确性分数的文档注释。
- 为自定义适配器使用
AutoUpdate功能。如果适配器上启用了AutoUpdate标志，则此功能会尝试自动重新训练。
- 适配器配额定义了适配器训练的限制。请考虑这些限制，并在需要时提出服务配额增加请求：
故障管理
在设计IDP解决方案时，一个重要的考虑因素是其弹性，即如何处理可能发生的已知和未知错误。IDP解决方案应具备记录错误和重试失败操作的能力，在IDP工作流的不同阶段进行。在本节中，我们将讨论如何设计您的IDP工作流以处理故障。
准备您的IDP工作流以管理和经受故障
“一切都会失败，一直都是这样”，这是AWS首席技术官Werner Vogels的一个著名引言。您的IDP解决方案，就像其他一切一样，最终会失败。问题是如何使其在不影响IDP解决方案用户的情况下经受故障。您的IDP架构设计必须在发生故障时意识到，并采取行动以避免对可用性的影响。这必须自动完成，不应对用户产生影响。考虑以下最佳实践：
- 使用Amazon Simple Storage Service (Amazon S3)作为处理IDP工作流文档的可扩展数据存储。Amazon S3提供了一个专为重要和主要数据存储而设计的高度持久的存储基础设施。
- 根据业务需求备份所有IDP工作流数据。实施一种策略，以在数据丢失的情况下恢复或重现数据。将此策略与满足业务需求的定义的恢复点目标（RPO）和恢复时间目标（RTO）保持一致。
- 如果需要，规划和实施跨AWS账户和区域的IDP解决方案的灾难恢复切换策略。
- 使用Amazon Textract的
OutputConfig功能和Amazon Comprehend的OutputDataConfig功能，将来自Amazon Textract或Amazon Comprehend的异步处理结果存储到指定的S3存储桶中。这使得工作流程能够从该点继续进行，而不是重复执行Amazon Textract或Amazon Comprehend调用。以下代码展示了如何启动一个Amazon Textract异步API任务来分析一个文档，并将加密推断输出存储在定义的S3存储桶中。有关更多信息，请参阅Amazon Textract客户端文档。
import boto3client = boto3.client('textract')response = client.start_document_analysis( DocumentLocation={ 'S3Object': { 'Bucket': 'string', 'Name': 'string', 'Version': 'string' } }, FeatureTypes=[ 'TABLES'|'FORMS'|'QUERIES'|'SIGNATURES'|'LAYOUT', ], … OutputConfig={ 'S3Bucket': 'string', 'S3Prefix': 'string' }, KMSKeyId='string' …)设计您的IDP工作流以防止故障
工作负载的可靠性始于前期的设计决策。架构选择将影响您的工作负载行为及其弹性。为了提高您的IDP解决方案的可靠性，请遵循以下最佳实践。
首先，按照IDP工作流设计架构。尽管IDP工作流中的阶段可能因用例和业务需求而有所变化和影响，但数据捕获、文档分类、文本提取、内容丰富、审查与验证以及消费等阶段通常是IDP工作流的一部分。这些明确定义的阶段可以用于分隔功能并在故障发生时隔离它们。
您可以使用Amazon Simple Queue Service (Amazon SQS)来解耦IDP工作流阶段。解耦模式有助于将架构组件的行为与依赖于它的其他组件隔离开来，提高弹性和灵活性。
其次，控制和限制重试调用。如果超过分配的最大TPS数量，AWS服务如Amazon Textract可能会失败，导致服务限流您的应用程序或断开您的连接。
您应该通过自动重试操作（同步和异步操作都包括）来管理限流和断开的连接。但是，您还应指定有限数量的重试次数，超过该次数后，操作将失败并抛出异常。如果您在短时间内对Amazon Textract进行过多的调用，它将限制您的调用并在操作响应中发送一个ProvisionedThroughputExceededExceptionerror。
另外，使用指數退避和抖動技術以改善吞吐量。例如，使用 Amazon Textract 時，在創建 Amazon Textract 客戶端時，通過包含 config 參數來指定重試次數。我們建議設置 5 次重試。在下面的代碼示例中，我們使用 config 參數以自適應模式自動重試操作，最多重試 5 次：
import boto3
from botocore.client import Config
documents = ['doc-img-1.png','doc-img-2.png', 'doc-img-3.png', 'doc-img-4.png', 'doc-img-5.png']
config = Config(
retries = {
'max_attempts': 5,
'mode': 'adaptive'
}
)
client = boto3.client('textract', config=config)
for documentName in documents:
response = client.detect_document_text(
DocumentLocation = {
'S3Object': {
'Bucket': 'string',
'Name': documentName
}
}
)
...
充分利用 AWS SDK，例如 AWS SDK for Python (Boto3)，以協助對 AWS 服務（如 Amazon Textract 和 Amazon Comprehend）的客戶端調用進行重試。有三種可用的重試模式：
- Legacy 模式 – 對一些錯誤和異常進行有限次數的重試，包括指數退避，指數退避因子為 2。
- Standard 模式 – 标准化重試邏輯和行為，與其他 AWS SDK 一致，並擴展復原機制的功能。每次重試均包括指數退避，指數退避因子為 2，最大退避時間為 20 秒。
- Adaptive 模式 – 包含標准模式的所有功能，並引入客戶端端限制通過通過令牌桶和速率限制變量以及每次重試均會更新這些变量，从而使客戶端重試具有適應 AWS 服務響應中的錯誤或異常狀態的靈活性。在每次新重試時，自適應模式根據 AWS 服務響應中呈現的錯誤、異常或 HTTP 狀態碼來修改速率限制變量。每次 AWS 服務返回一個異常、錯誤或非成功的 HTTP 響應時，重試發生，並更新速率限制變量，直到達到成功，令牌桶耗盡，或達到配置的最大重試次數。以下是異常、錯誤或非成功的 HTTP 響應的示例:
# 過渡性錯誤/異常
RequestTimeout
RequestTimeoutException
PriorRequestNotComplete
ConnectionError
HTTPClientError
# 服務端節流/限制錯誤和異常
Throttling
ThrottlingException
ThrottledException
RequestThrottledException
TooManyRequestsException
ProvisionedThroughputExceededException
TransactionInProgressException
RequestLimitExceeded
BandwidthLimitExceeded
LimitExceededException
RequestThrottledSlowDown
EC2ThrottledException
#對於不具有明確描述的過渡性錯誤代碼進行重試。具體來說，這些 HTTP 狀態碼: 500, 502, 503, 504.結論
在本篇文章中，我們分享了可靠性方案的設計原則、重點領域、基礎和最佳實踐。
|
要了解有關 IDP 云原生設計的相關信息，請探索本系列文章中的以下帖子: |
AWS致力于IDP Well-Architected Lens作为一种实用工具。随着IDP解决方案和相关的AWS AI服务的发展以及新的AWS服务的推出，我们将相应地更新IDP Lens Well-Architected。
如果您想了解更多关于AWS Well-Architected Framework的内容，请参阅AWS Well-Architected。
如果您需要额外的专家指导，请联系您的AWS客户团队以联系一个IDP专家解决方案架构师。