Amazon S3 Access Points で Amazon FSx for NetApp ONTAP 上のデータに AWS サービスからゼロコピーでアクセスする

(この記事は、 Enable zero-copy access to AWS services on Amazon FSx for NetApp ONTAP with Amazon S3 Access Points を翻訳したものです。)

半導体の検証チームは EDA（Electronic Design Automation）ツールを使い、毎晩数千件のシミュレーションジョブを実行しています。大規模な検証環境では 1 晩に 10 万件以上のテスト実行のログが生成されることもあります。1 回のリグレッションテストではシミュレーションログ、コンパイルログ、ジョブスケジューラーのログが出力されます。失敗が数十件に及ぶリグレッションテストでは手作業によるトリアージ（失敗原因の切り分け）に通常 45～60 分を要します。多数の失敗に共通する根本原因の特定には数日を要することもあります。現状ではエンジニアが SSH で接続し、grep でシミュレーション結果を検索して、複数のターミナルでジョブスケジューラーのログと照合しています。独自のスクリプトを開発するチームもありますが、継続的な保守が必要なうえ、ほかのテストスイート（リグレッションテストで実行するテスト群）への展開も困難です。ログファイルは高性能な共有 NFS ストレージにすでに格納されています。課題はこれらのログを、複数のファイルを読み込んで内容を突き合わせられる AI サービスから参照可能にすることです。そのためには取り込み用のパイプラインを構築するか、データを Amazon Simple Storage Service（Amazon S3）にコピーする必要があります。

本記事では既存のワークフローを妨げず、データも移動せずに、EDA の検証ワークフローと AI による分析を連携させるアーキテクチャを紹介します。このアーキテクチャでは Amazon FSx for NetApp ONTAP、Amazon S3 Access Points、Amazon Bedrock AgentCore、Amazon Quick を使用します。

FSx for ONTAP の S3 アクセスポイントを使うと、AWS のサービスから S3 API で検証ログにアクセスできます。データはファイルシステム上に保持されたままです。AgentCore はツールを利用できる AI エージェントをデプロイするマネージドサービスです。Amazon Quick は自然言語による問い合わせやワークフローの自動化を AI で実現する分析サービスです。エンジニアが Amazon Quick で「昨夜の失敗の原因は何か」と質問すると、シミュレーション、コンパイル、ジョブスケジューラー（LSF）の各ログを突き合わせた分析結果が数分以内に返されます。根本原因の分析が迅速になれば、エンジニアは手作業のトリアージに費やしていた時間を削減してバグの修正に注力でき、テープアウトまでの期間も短縮できます。

ソリューションの概要

図 1 にソリューションのアーキテクチャを示します。EDA ツールは NFS 経由で FSx for ONTAP にログデータを書き込みます。ログデータには S3 アクセスポイントを介して S3 API でもアクセスできます。エンジニアがログファイルを参照する経路は 2 つです。要約を素早く得るためのナレッジベースの経路と、複数のファイルを横断して詳しく調査するためのエージェントの経路です。

図 1: EDA ツールは NFS 経由で FSx for ONTAP にログを書き込みます。ログには S3 アクセスポイントを介して S3 API でアクセスできます（ゼロコピー、読み取り専用）。エンジニアはナレッジベースの経路か、エージェントの経路（MCP ゲートウェイ）でログを参照します。

訳注

ナレッジベースの経路（RAG）: ログデータから事前に作成したインデックスを基に回答する経路です。
エージェントの経路: AI エージェントがログファイルを直接読み込み、複数のファイルを横断して調査する経路です。
MCP（Model Context Protocol）: AI エージェントが外部のツールやデータを利用するための標準プロトコルです。

FSx for ONTAP に保存されるログファイル

EDA ツールは計算クラスター上でシミュレーションやコンパイルのジョブを実行します。各ジョブは NFS 経由で FSx for ONTAP のボリュームにログファイルを書き込みます。この既存のワークフローを変更する必要はありません。ログデータは FSx for ONTAP に集約され、ここが正本（Single Source of Truth）となります。ログは共有ストレージ上の /mnt/fsx/logs/ のようなプロジェクトディレクトリ配下に格納されます。

FSx for ONTAP の S3 アクセスポイント

ログを格納したボリュームに S3 アクセスポイントをアタッチすると、S3 API によるアクセスが可能になります。アクセスポイントには読み取り権限のみを持つファイルシステムユーザーを関連付け、アクセスポイント経由の操作を読み取りに限定します。EDA ツールは従来どおり NFS 経由で書き込みを続けます。同時に、AWS のサービスは S3 API 経由でデータを読み込みます。S3 アクセスポイントは AWS CLI の create-and-attach-s3-access-point コマンドで作成します。

ナレッジベースの経路（RAG）

Amazon Quick は自然言語による問い合わせ、ビジュアルダッシュボード、ワークフローの自動化を単一のインターフェイスでエンジニアに提供します。検索拡張生成（RAG: Retrieval Augmented Generation）を用いるこの経路では、Amazon Quick が S3 アクセスポイントからログデータを同期してインデックスを作成し、ナレッジベースに格納します。Quick のチャットエージェントはリクエストのたびにログファイルを読み込むのではなく、作成済みのインデックスから回答します。そのため、「昨夜はいくつのシミュレーションが失敗したか」のように、要約を素早く得たい質問に適しています。

エージェントの経路（MCP ゲートウェイ）

AgentCore は MCP ゲートウェイをホストします。ゲートウェイに登録した AWS Lambda 関数は S3 アクセスポイントを介して FSx for ONTAP のファイルを問い合わせのたびに読み込みます。MCP ゲートウェイはエージェントに次の 3 つのツールを提供します。

List – ディレクトリの一覧を取得する
Read – S3 のファイルを読み込む
Search – S3 のファイルを横断して検索する

シミュレーションログの読み込み時は、Lambda 関数が S3 アクセスポイントに対して GetObject（ファイルの取得）を呼び出します。実行済みのリグレッションテストを一覧で確認する際は、ボリューム上のパスに対して ListObjects（ファイルとディレクトリの一覧の取得）を呼び出します。エージェントは自律的にディレクトリをたどって複数のログを読み込み、詳細なトリアージレポートを生成します。この経路は「AXI タイムアウトによる失敗の根本原因は何か」のように、複数のファイルにまたがる、より詳細な分析が必要な質問に適しています。

仕組み

たとえば、エンジニアが Amazon Quick で「昨夜はいくつのシミュレーションが失敗したか。最も多いエラーは何か」と質問したとします。Amazon Quick はこの質問を AgentCore 上の MCP エージェントに渡します。エージェントはツールを使い、リグレッションテストの結果を格納したディレクトリの一覧を取得します。続いて、終了コードが 0 以外のログファイルを特定し、関連するシミュレーションログと LSF のログを読み込みます。複数のファイルにわたるエラーのパターンを突き合わせ、失敗の種類ごとに件数と影響を受けたモジュールをまとめて返します。エージェントはさらなる質問にも回答できます。この経路では事前に作成したインデックスではなく、問い合わせの時点で S3 アクセスポイントを介して FSx for ONTAP のファイルを読み込みます。そのため、回答には問い合わせ時点のファイルシステム上のデータが反映されます（図 2）。

図 2: トリアージに関する質問例と、AI が生成した回答を表示した Amazon Quick のチャット画面

すべてのコンポーネントはお客様の仮想プライベートクラウド（VPC）内で動作します。S3 アクセスポイントは AWS Identity and Access Management（IAM）のポリシーと、ファイルシステムのアクセス権限の両方を適用します。ログデータを読み取れるのは許可されたサービスに限られます。この構成では、書き込みは NFS 経由に限定されます。

S3 アクセスポイントにより、AWS の分析サービスや AI サービスから S3 API でログデータにアクセスできます。AgentCore と Amazon Quick はこのパターンの実装例の一つです。Amazon Athena、AWS Glue、独自に開発した Lambda 関数などのサービスも、同じアクセスポイントを介して同じデータにアクセスできます。

ダッシュボードとワークフローの自動化

エージェントによるログ分析に用いる S3 アクセスポイントは、ダッシュボードによる可視化とワークフローのスケジュール実行にも利用できます。

リグレッションテストの状況を可視化するダッシュボード

Amazon Quick Sight は S3 アクセスポイントを介して、FSx for ONTAP から構造化された集計データを読み込めます。検証チームのマネージャーは毎朝ブラウザでダッシュボードを開くだけで、スクリプトを実行せずに夜間のリグレッションテストの現状を把握できます。ダッシュボードにはモジュールごとのパス／フェイル率、失敗の種類の内訳、カバレッジのヒートマップ、リソース使用率の推移が表示されます。ファイルシステムに新しいリグレッションテストのデータが追加されると、ダッシュボードは自動的に更新されます。

図 3: モジュールごとのパス／フェイルと失敗の種類の内訳を表示した Amazon Quick Sight のリグレッションテストのダッシュボード

ワークフローのスケジュール実行

Amazon Quick Automate を使うと、毎晩のリグレッションテストの完了後にワークフローをスケジュール実行できます。たとえば、毎日のトリアージを自動化するワークフロー（図 4）では、チームの始業前に失敗の概要をまとめてメールで送信可能です。カバレッジを監視するワークフローでは、モジュールのカバレッジが設定したしきい値を下回った時点でアラートを送信可能です。ライセンスを監視するワークフローでは、繰り返されるチェックアウトの失敗を検知し、インフラチームに通知可能です。

これらのワークフローも S3 アクセスポイントを介して FSx for ONTAP から同じログデータを読み込みます。エンジニアは独自のスクリプトの開発や cron ジョブの保守を行う必要がありません。

図 4: 朝のトリアージレポートを自動生成する Amazon Quick Flows のフロー

検証のトリアージ以外のユースケース

同じアーキテクチャは NFS ストレージにログデータを出力するほかの EDA ワークフローにも適用できます。たとえば、論理合成のタイミングレポートの分析、物理検証（DRC/LVS）の結果、電力解析の出力、設計ドキュメントの生成です。構造化または半構造化されたログを FSx for ONTAP に書き込むワークフローであれば、このパターンを活用できます。

まとめ

EDA の検証チームは毎晩大量のログデータを生成します。このデータは高性能な NFS ストレージに格納されていますが、分析は手作業のままでした。FSx for ONTAP の S3 アクセスポイントを使えば、AI サービスから S3 API で同じデータにアクセスできます。データのコピーや移動は不要です。AgentCore と Amazon Quick を組み合わせると、エンジニアはリグレッションテストについて自然言語で質問できます。回答はシミュレーション、コンパイル、ジョブスケジューラーの各ログを突き合わせて分析したものです。これまで 45～60 分を要していた毎日のトリアージは、数分以内での完了が可能になります。ログデータは FSx for ONTAP に保持したまま、NFS と S3 API の両方から同時にアクセスできます。S3 アクセスポイントは AI サービスが同じデータを活用して有益な知見を得るための、独立した読み取り専用の経路となります。その結果、検証クロージャーの短縮とエンジニアの生産性向上につながります。チームは何時間もかけてバグのトリアージを行うのではなく、バグの修正から 1 日を始められます。

このアーキテクチャを実際に試すには、FSx for ONTAP と S3 アクセスポイントを扱うワークショップについて AWS のアカウントチームにお問い合わせください。このソリューションで使用するサービスの詳細は、次の資料を参照してください。

翻訳はソリューションアーキテクトの酒井賢が担当しました。原文はこちらです。

Amazon Web Services ブログ