「カスタムレンズを使用して、信頼性のあるよく設計されたIDPソリューションを構築する」シリーズの第3部：信頼性

「カスタムレンズを使用して、信頼性の高いIDPソリューションを構築する」シリーズの第3部：信頼性向上

The IDPウェルアーキテクチャカスタムレンズは、AWSを使用してインテリジェントドキュメント処理（IDP）ソリューションを実行するすべてのAWSの顧客を対象とし、AWS上で安全で効率的で信頼性の高いIDPソリューションを構築するためのガイダンスを探している方々向けです。

クラウド上で本番用のソリューションを構築することは、リソース、時間、顧客の期待、ビジネスの成果といった要素の間でトレードオフを行う一連の選択を伴います。 AWSウェルアーキテクチャフレームワークを使用することで、AWS上でワークロードを構築する際に行う決定の利益とリスクを理解することができます。フレームワークを使用することで、クラウド上で信頼性の高い、安全な、効率的な、コスト効果の高い、持続可能なワークロードの設計と運用に関するベストプラクティスを学ぶことができます。

IDPプロジェクトでは通常、光学文字認識（OCR）と自然言語処理（NLP）を組み合わせてドキュメントを読み取り、特定の用語や単語を抽出します。IDPウェルアーキテクチャカスタムレンズは、IDPワークロードの技術的なリスクを評価し特定するためのAWSウェルアーキテクチャのレビューを実行する手順を示しています。それは、フィールドで見られる一般的な課題に対処するためのガイダンスを提供し、ベストプラクティスに基づいてIDPワークロードの設計をサポートします。

この記事では、IDPソリューションの信頼性の柱に焦点を当てています。信頼性の柱と設計原則の紹介から始め、基礎、変更管理、故障管理の3つの焦点領域について詳しく説明します。この記事を読むことで、IDPケーススタディを交えながら、ウェルアーキテクチャフレームワークの信頼性の柱について学ぶことができます。

• カスタムレンズを使用してウェルアーキテクチュアIDPソリューションを構築する – パート2：セキュリティ
• 「Amazon SageMaker JumpStart、Llama 2、およびAmazon OpenSearch Serverless with Vector Engineを使用して、金融サービス向けのコンテキスト重視のチャットボットを構築する」
• 「カスタムレンズを使用して、優れたアーキテクチャのIDPソリューションを構築する – パート1：運用の優秀さ」

設計原則

信頼性の柱は、IDPソリューションが文書処理を正確かつ一貫して行い、定義されたビジネスルールに従って期待通りに機能する能力を意味します。これには、完全なIDPワークフローとそのライフサイクルの運用およびテストの能力が含まれます。

信頼性を向上させるためのいくつかの原則があります。これらをベストプラクティスとして念頭に置いてください：

• 障害から自動的に回復する – IDPワークフローの主要なパフォーマンス指標（KPI）を監視することにより、しきい値が超えた場合に自動化を実行できます。これにより、障害が発生した場合に自動的に通知され、障害を回避または修復するための自動回復プロセスがトリガーされます。 KPIの測定結果に基づいて、障害が発生する前に問題を予測し、是正措置を適用することもできます。
• 回復手順をテストする – IDPワークフローがどのように失敗するかをテストし、回復手順を検証します。自動化を使用して、異なるシナリオをシミュレートしたり、以前の失敗の原因となったシナリオを再現したりします。
• サービスの容量をスケーリングおよび調整する – IDPワークフローの需要と使用状況をモニタリングし、AWSサービスの容量を自動的に調整することで、需要を満たすための最適レベルを維持することができます。 IDPコンポーネントサービス（Amazon TextractやAmazon Comprehendなど）のサービスクォータ、制限、制約を制御し、認識しましょう。
• 変更を自動化する – IDPワークフローインフラストラクチャに変更を適用する際に自動化を使用します。変更を自動化によって管理し、追跡およびレビューすることができます。

焦点領域

信頼性の柱の設計原則とベストプラクティスは、お客様とIDPテクニカルスペシャリストのコミュニティから得られたインサイトに基づいています。これらを設計の決定のガイドラインとサポートとして使用し、IDPソリューションのビジネス要件と整合させます。 IDPウェルアーキテクチャレンズを適用することで、IDPソリューションの設計の弾力性と効率性を検証し、特定のギャップに対応するための推奨事項を提供します。

以下は、クラウド上のIDPソリューションの信頼性に関するベストプラクティスエリアです：

• 基盤 – Amazon TextractやAmazon ComprehendなどのAWS AIサービスは、使用の異なる側面のために一連のソフトリミットとハードリミットを提供します。これらのリミットを確認し、IDPソリューションがソフトリミットに準拠する一方でハードリミットを超えないようにすることが重要です。
• 変更管理 – IDPソリューションをインフラストラクチャのコード（IaC）として扱い、モニタリングと変更管理を自動化できるようにします。インフラストラクチャとAmazon Comprehendカスタムモデルなど、コンポーネント全体でバージョン管理を行い、変更を時系列のリリースに関連付けます。
• 故障管理 – IDPワークフローはイベント駆動型のソリューションであるため、アプリケーションは既知のエラーや未知のエラーに対して強い耐性を持つ必要があります。ウェルアーキテクチャのIDPソリューションは、ログ記録とリトライメカニズムを使用して故障を防止し、発生した場合に耐える能力を持っています。 IDPワークフローアーキテクチャに強靭性を設計し、災害復旧計画を立てることが重要です。

ファンデーション

AWS AIサービスは、Amazon Textract、Amazon Comprehend、およびAmazon Augmented AI（Amazon A2I）を使用して、自動データ抽出と分析などの準備ができたインテリジェンスを提供します。これらのサービスには使用制限（またはクォータ）があります。これにより、オーバープロビジョニングを防ぎ、API操作のリクエスト速度を制限して、サービスを乱用から保護します。

IDPソリューションアーキテクチャを計画および設計する際には、次のベストプラクティスを考慮してください:

• 変更不可能なAmazon TextractおよびAmazon Comprehendのサービスクォータ、制限、制約に注意してください。 – 受け入れ可能なファイル形式、サイズとページ数、言語、ドキュメントの回転、およびイメージのサイズは、変更できないAmazon Textractのハード制限の一部の例です。
  • 受け入れ可能なファイル形式には、JPEG、PNG、PDF、TIFFファイルが含まれます。（PDF内のJPEG 2000エンコードされた画像もサポートされています）。ファイル形式がサポートされていない場合、Amazon Textractを使用する前にドキュメントの前処理が必要です（例えば、Microsoft WordやExcelなど)。この場合、サポートされていないドキュメント形式をPDFまたは画像形式に変換する必要があります。
  • Amazon Comprehendには、ビルトインモデル、カスタムモデル、またはフライホールに対して異なるクォータがあります。Amazon Comprehendのクォータが使用ケースと一致していることを確認してください。
• 必要に応じてAmazon TextractおよびAmazon Comprehendのサービスクォータを調整してください – Amazon Textractサービスクォータ計算機を使用して、使用ケースをカバーするクォータ値を推定することができます。また、自分のソリューションに対してアカウントまたはリージョン間の災害復旧フェイルオーバーを計画している場合は、サービスクォータをアカウントまたはリージョン全体で管理する必要があります。Amazon Textractのクォータを増やすためのリクエストを行う際は、次の推奨事項に従ってください:
  • Amazon Textractサービスクォータ計算機を使用して、最適なクォータ値を推定します。
  • リクエストの変更によってネットワークトラフィックが急増した場合、スループットに影響を与えます。キューイングサーバーレスアーキテクチャや他のメカニズムを使用してトラフィックをなめらかにし、割り当てられた秒間トランザクション（TPS）を最大限に活用します。
  • スロットルされた呼び出しや切断された接続を処理するために、リトライロジックを実装します。
  • スループットを改善するために指数関数的なバックオフとジッターを設定します。

変更管理

IDPワークフローやその環境の変更（需要の急増や破損したドキュメントファイルなど）は、より高い信頼性のあるソリューションを実現するために予測されて対応する必要があります。これらの変更の一部は、前のセクションで説明したファンデーションのベストプラクティスでカバーされていますが、それだけでは変更に対応するのに十分ではありません。以下のベストプラクティスも考慮する必要があります:

• Amazon CloudWatchを使用して、Amazon TextractやAmazon ComprehendなどのIDPワークフローコンポーネントを監視します。IDPワークフローからメトリクスを収集し、アラームへの自動応答を自動化し、ワークフローとビジネス目標に必要な通知を送信します。
• IDPワークフローソリューションとすべてのインフラストラクチャの変更をIaC（Infrastructure as Code）を使用して自動化します。例えば、AWS Cloud Development Kit（AWS CDK）やプリビルドされたIDP AWS CDKコンストラクトを使用します。これにより、人為的なエラーの導入がなくなり、本番環境への変更前にテストすることができます。
• Amazon Comprehendカスタムモデルが必要な場合は、フライホールを使用してカスタムモデルの改善プロセスを簡素化できます。フライホールは、新しいカスタムモデルバージョンのトレーニングと評価に関連するタスクをオーケストレートします。
• 必要な場合は、Amazon Textractの事前訓練済みクエリ機能の出力をカスタマイズするために、アダプタをトレーニングして使用します。アダプタを作成する際には、次のベストプラクティスを考慮してください:
  • アダプタトレーニングの前の制限をアダプタクォータと呼びます。これらの制限を考慮し、必要に応じてサービスクォータの増加リクエストを行ってください:
    • アダプタの最大数 – 許可されるアダプタの数（単一のアダプタの下に複数のアダプタバージョンを持つことができます）。
    • 月ごとに作成されるアダプタバージョンの最大数 – AWSアカウントあたりに作成できる正常なアダプタバージョンの数。
    • 進行中のアダプタバージョンの最大数 – アカウントあたりの進行中のアダプタバージョン（アダプタトレーニング）の数。
  • 使用ケースを代表する一連のドキュメントを使用します（最低5つのトレーニングドキュメントと5つのテストドキュメント）。
  • トレーニングに使用するドキュメントはできるだけ多く提供してください（最大2,500ページのトレーニングドキュメントと1,000ページのテストドキュメントまで）。
  • さまざまな回答を使用してクエリを注釈付けします。例えば、クエリの回答が「Yes」または「No」の場合、注釈付けされたサンプルには「Yes」と「No」の両方の出現がある必要があります。
  • 注釈付けスタイルを一貫させ、フィールドにスペースを注釈付けする際にも一貫性を保ちます。
  • トレーニングで使用した正確なクエリを推論に使用してください。
  • アダプタの性能メトリクスをレビューして、目標を達成するためにアダプタをさらに改善する必要があるかどうかを判断します。改善されたバージョンのアダプタを作成する前に、低い精度スコアのドキュメント注釈をレビューするか、新しいドキュメントセットをトレーニング用にアップロードしてください。
  • カスタムアダプタのAutoUpdate機能を使用します。この機能が有効になっている場合、自動的にアダプタが再トレーニングを試みます。

失敗管理

デザインする際に、IDPソリューションの耐久性、発生する既知および未知のエラーの処理方法を考慮することが重要です。IDPソリューションは、IDPワークフローの異なる段階で、エラーのログ記録や失敗した操作の再試行の機能を持つべきです。このセクションでは、失敗を処理するためのIDPワークフローの設計の詳細について説明します。

失敗を管理し耐えるためにIDPワークフローを準備する

「全てのものは何度も失敗する」という言葉は、AWSのCTOであるウェルナー・フォーゲルスの有名な引用です。IDPソリューションも、他のすべてのものと同様に、やがて失敗します。問題は、IDPソリューションが利用者に影響を与えることなく、どのようにして失敗に耐えるかです。IDPアーキテクチャの設計は、発生した障害に対して自動的に対応し、可用性に影響を及ぼさないようにする必要があります。以下のベストプラクティスを考慮してください。

• IDPワークフローの処理に使用するデータストアとして、Amazon Simple Storage Service（Amazon S3）を使用します。Amazon S3は、ミッションクリティカルなデータストレージ向けに設計された非常に信頼性の高いストレージインフラストラクチャを提供します。
• ビジネス要件に基づいて、IDPワークフローのデータをバックアップします。データの損失が発生した場合にデータを回復または再生成する戦略を実装します。この戦略を、ビジネス要件を満たす定義された復旧ポイント目標（RPO）および復旧時間目標（RTO）と合わせて調整します。
• 必要な場合は、AWSアカウントとリージョン間でのIDPソリューションの災害復旧フェイルオーバー戦略を計画し実装します。
• Amazon TextractのOutputConfig機能およびAmazon ComprehendのOutputDataConfig機能を使用して、Amazon TextractまたはAmazon Comprehendの非同期処理の結果を指定されたS3バケットに保存します。これにより、Amazon TextractまたはAmazon Comprehendの呼び出しを繰り返すのではなく、ワークフローをそのポイントから継続することができます。以下のコードは、指定したS3バケットに暗号化推論結果を格納するためのAmazon Textract非同期APIジョブを開始する方法を示しています。詳細については、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ワークフローの段階を分離します。分離パターンは、アーキテクチャコンポーネントの動作を他の依存するコンポーネントから分離し、耐久性と機動性を高めるのに役立ちます。

次に、リトライ呼び出しを制御して制限します。Amazon TextractなどのAWSサービスは、最大許容TPS数を超える場合に失敗する場合があります。これにより、サービスがアプリケーションをスロットルしたり接続を切断したりする可能性があります。

オペレーションを（同期および非同期の両方のオペレーションを）自動的に再試行することでスロットリングと切断された接続を管理します。ただし、一定回数のリトライを指定し、その後のオペレーションが失敗して例外をスローすることも指定する必要があります。短時間に複数回Amazon Textractに呼び出しを行うと、Amazon Textractは呼び出しをスロットリングし、操作応答でProvisionedThroughputExceededExceptionerrorを送信します。

さらに、吞込量を向上させるために、指数バックオフとジッタを再試行に使用します。例えば、Amazon Textractを使用する場合は、Amazon Textractクライアントの作成時に config パラメータを含めてリトライの回数を指定します。リトライ回数としては5回が推奨されています。以下の例のコードでは、config パラメータを使用してアダプティブモードと最大5回のリトライを自動的に実行します:

import boto3from botocore.client import Configdocuments = ['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                }                })        ...

Amazon TextractやAmazon ComprehendなどのAWSサービスへのクライアント呼び出しを再試行するために、AWS SDK for Python (Boto3)などのAWS SDKを利用してください。利用可能な3つのリトライモードがあります:

• レガシーモード – 指数バックオフ（基数2）を含む一定数のエラーや例外の呼び出しをリトライします。
• スタンダードモード – リトライのロジックと動作を他のAWS SDKと統一し、レガシーモードよりもリトライの機能を拡張します。任意のリトライ試行は、最大バックオフ時間が20秒になるように指数バックオフ（基数2）を含みます。
• アダプティブモード – スタンダードモードのすべての機能を含み、各リトライ試行ごとにトークンバケットとレートリミット変数を使用してクライアント側のレート制限を導入します。このモードでは、AWSサービスからの応答のエラーや例外の状態に応じてクライアント側のリトライを柔軟に行うことができます。新しいリトライ試行ごとに、アダプティブモードは応答から提供されるエラーや例外、またはHTTPステータスコードに基づいてレートリミット変数を修正します。そして、これらのレートリミット変数を使用してクライアントの新しい呼び出しレートを計算します。各例外、エラー、またはAWSサービスからの非成功HTTP応答は、成功、トークンバケットの枯渇、または設定された最大試行回数に達するまで、繰り返しリトライが発生するたびにレートリミット変数を更新します。以下は、例外、エラー、または非成功HTTP応答の例です:

# 一時的なエラー/例外RequestTimeoutRequestTimeoutExceptionPriorRequestNotCompleteConnectionErrorHTTPClientError# サービス側のスロットリング/制限のエラーと例外ThrottlingThrottlingExceptionThrottledExceptionRequestThrottledExceptionTooManyRequestsExceptionProvisionedThroughputExceededExceptionTransactionInProgressExceptionRequestLimitExceededBandwidthLimitExceededLimitExceededExceptionRequestThrottledSlowDownEC2ThrottledException# 記述的でない一時的なエラーコードでのリトライ試行。具体的には、これらのHTTPステータスコード: 500, 502, 503, 504.

結論

この記事では、IDPソリューションの信頼性向上のための設計原則、焦点領域、基盤、およびベストプラクティスを共有しました。

IDP Well-Architectedカスタムレンズについて詳しくは、このシリーズの以下の記事をご覧ください。 カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート1: 運用の優れた業績 カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート2: セキュリティ カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート3: 信頼性 カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート4: パフォーマンス効率 カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート5: コスト最適化 カスタムレンズを使用したウェルアーキテクトされたIDPソリューションの構築 – パート6: 持続可能性

AWSは、IDP Well-Architected Lensを進化し続けるツールとしての取り組みを行っています。IDPソリューションと関連するAWSのAIサービスが進化し、新しいAWSサービスが利用可能になると、IDP Lens Well-Architectedも更新されます。

AWS Well-Architectedフレームワークについて詳しく知りたい場合は、AWS Well-Architectedを参照してください。

追加の専門的なガイダンスが必要な場合は、IDP Specialist Solutions Architectを担当するAWSアカウントチームに連絡してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!