本記事は、 Timestream for InfluxDB 3 workload analysis and best practices を翻訳したものです。 Amazon Timestream for InfluxDB 3 のデプロイメントにおいて、適切なインスタンスサイズの選択は、時系列インフラストラクチャを設計する上で最も影響の大きい判断の 1 つです。インスタンスが小さすぎるとクエリパフォーマンスの低下や取り込みのボトルネックにつながり、大きすぎると未使用のキャパシティに対して余分なコストを支払うことになります。 本記事では、デプロイメントのサイジングの選び方について解説します。このガイドを参考に、お客様のビジネスユースケースに合った Timestream for InfluxDB 3 の構成を選択してください。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 サイジングのガイダンス パフォーマンス特性の理解 Amazon Timestream for InfluxDB 3 のデプロイメントに適切なインスタンスサイズを選択するには、ワークロードパターンごとのデータベースの挙動を把握することが重要です。 時系列データベースのパフォーマンスは、相互に関連する多くの要因に左右されます。クエリの複雑さはパフォーマンスに大きく影響します。直近のデータに対するシンプルな集計は、数か月分の履歴データにまたがる複雑な分析クエリとはパフォーマンスが異なります。データモデルも大きく影響します。数百万のユニークなタグの組み合わせを持つ高カーディナリティのデータセットは、低カーディナリティのモニタリングデータとは異なるパフォーマンス特性を示します。バッチサイズ、取り込みレート、ラインプロトコルポイントの構造といった書き込みパターンもパフォーマンスに影響します。 同時実行される操作には、固有の考慮事項があります。複数のアプリケーションがデータベースに同時にクエリを実行しながらデータの取り込みも継続している場合、取り込みとクエリ処理の間でリソースのバランスを取る必要があります。クエリの時間範囲も大きな影響を与えます。InfluxDB 3 のキャッシュとインメモリ最適化により直近のデータへのクエリは非常に高速であり、履歴データへのクエリ（Enterprise クラスターの場合）はコンパクター（圧縮を行うコンポーネント）と Parquet ストレージを使用して効率的に取得します。 本記事の目的は、お客様のワークロードに対する正確な予測を提供することではなく、デプロイメントの出発点となる情報を提供することです。 データとクエリに関する考慮事項 クエリと取り込みのパフォーマンスを向上させるには、以下の点を考慮してください。 カーディナリティが低い場合（ユニークなタグの組み合わせが少ない場合）、クエリがフィルタリングする必要のある系列が少なくなるため、パフォーマンスが向上する可能性があります。InfluxDB 3 ではカーディナリティは問題ではなくなりましたが、カーディナリティが際限なく増加してもパフォーマンスに影響がないわけではありません。クエリ操作のメモリ使用量が増え、圧縮パフォーマンスにも影響する可能性があります。 クエリがシンプルな場合（集計ではなく単一フィールドの取得など）、InfluxDB 3 の Last Value Cache の恩恵を受け、大幅に高速なレスポンスタイムが得られます。クエリが生データに対して数時間または数日にわたる集計を行う場合、データサイズの増加に伴いクエリパフォーマンスは低下します。可能な限り処理エンジンを使用して ダウンサンプリング を行い、クエリ結果として表示したい形式に合わせてデータを事前にフォーマットしてください。 書き込みバッチが大きい場合（medium から 4xlarge インスタンスでは 1 バッチあたり 5,000 ポイント、より大きなインスタンスでは 1 バッチあたり 10,000 ポイント以上）、リクエストあたりのオーバーヘッドが減少するため、書き込みスループットが向上します。 クエリが直近のキャッシュウィンドウを超える長い時間範囲や履歴データを対象とする場合、すべてのエディションで利用可能な ダウンサンプリング と、Enterprise エディションで利用できるコンパクター（圧縮を行うコンポーネント）により、良好なパフォーマンスを維持できます。 同時読み取りユーザーが少ない場合、多数の同時操作にリソースが分散されないため、クエリあたりのパフォーマンスが向上します。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。詳細な長期メトリクスについては、CloudWatch が 10 秒ごとに同じ粒度でメトリクスを記録するのに対し、System Metrics Plugin は カスタムスケジュール を設定できるため、CloudWatch よりも適しています。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、 Telegraf を実行する Amazon EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイメントの手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する AWS CDK アプリケーションが含まれています。 サイジングの始め方 最初にデプロイメントを計画する際は、以下のアプローチを推奨します。 ベースライン要件を見積もる : 予想される書き込みレート（1 秒あたりのポイント数）とクエリの同時実行数（同時クエリ数）を計算します。データ量の増加や負荷のスパイクに備え、バッファを持たせてください。 開始するインスタンスサイズを選択する : 理想的な条件でインスタンスサイズを決定するための目安として、以下を参考にしてください。ニーズにおおよそ合致するインスタンスをデプロイし、パフォーマンスに応じて調整します。 書き込み（1 秒あたりの行数） 読み取り（1 秒あたりのクエリ数） インスタンスクラス ~35,000 ~40 db.influx.medium <100,000 ~140 db.influx.large ~120,000 ~290 db.influx.xlarge ~130,000 ~400 db.influx.2xlarge ~140,000 ~425 db.influx.4xlarge <200,000 <430 db.influx.8xlarge ~200,000 <430 db.influx.12xlarge ~210,000 ~430 db.influx.16xlarge ~230,000 ~430 db.influx.24xlarge 直近のデータモニタリング（3〜5 日間）に重点を置いたワークロードの場合は、db.influx.xlarge から始めてください。 書き込みスループットやクエリの同時実行数がより高い要件には、db.influx.2xlarge または db.influx.4xlarge を検討してください。 最大スループットが必要な場合は、db.influx.8xlarge や db.influx.24xlarge で評価してください。 履歴データの保持と分析が必要な場合は、適切なインスタンスサイズで Enterprise エディションを選択してください。 インスタンスサイズとワークロード特性に応じて、デプロイメント用の パラメータグループ を作成し設定します。 本番相当のデータでテストする : 本番環境のカーディナリティと時間範囲に一致するデータセットをロードし、実際のクエリパターンを実行してパフォーマンスを検証します。 モニタリングと調整 : CloudWatch メトリクスと System Metrics Plugin を使用して、CPU、メモリ、クエリレイテンシー、書き込みスループットを監視します。リソース使用率が常に高い場合やパフォーマンスが低下している場合は、スケールアップしてください。 本番レベルで稼働する正常なインスタンスは、CPU とメモリの使用率が平均で 40%〜70% の間であるべきです。 通常 40% を下回っており、ワークロードが安定している場合は、オーバープロビジョニングです。 70% の閾値を超えるスパイクがある場合は、最適化またはスケーリングを検討してください。クエリは書き込みよりも CPU 使用率に大きな影響を与えることに留意してください。 ワークロードの変化に応じて、短時間のダウンタイムを伴いますがインスタンスサイズのスケールアップまたはスケールダウンが可能です。控えめな構成から始め、注意深くモニタリングし、お客様固有のユースケースから得られる実際のパフォーマンスデータに基づいて調整してください。 まとめ Amazon Timestream for InfluxDB 3 のデプロイメントを効果的にサイジングするには、スループット要件、クエリパターン、コストの考慮事項のバランスを取る必要があります。Amazon Timestream for InfluxDB 3 がお客様のビジネスニーズにどのように応えるかを判断する出発点として、本記事を活用してください。ワークロードパターン、クエリの複雑さ、履歴データのニーズを分析することで、要件に合った適切な構成を選択できます。 今すぐ Amazon Timestream for InfluxDB のドキュメント にアクセスし、ビジネスが求めるパワー、柔軟性、スケーラビリティを備えた時系列ワークフローの構築を始めましょう。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。

2026 年 9 月 28 日週、 OpenAI を搭載した Amazon Bedrock マネージドエージェントのパブリックプレビュー を発表しました。これは、AWS ネイティブで AWS リソースと統合されるように設計された OpenAI の Agents API のカスタマイズ版に基づいて構築されています。すでに使用している ID、権限、ガバナンスコントロールを使用して完全に AWS 内で動作する OpenAI モデル用に最適化されたエージェントを構築できるようになりました。 実行環境として、既存の開発マシン、コンテナ、またはコンピューティング環境を使用するセルフホストコンピューティング、または AWS アカウントのマネージドランタイムセッションと設定可能なストレージ用の Amazon Bedrock AgentCore Runtime を選択できます。詳細については、 Amazon Bedrock のドキュメント を参照してください。 さらに、Amazon Bedrock に新しいフロンティアモデルを追加して、モデルの選択肢を広げています。 OpenAI GPT-6.1 Sol : GPT-6 Sol のアップグレード版である GPT-6.1 Sol は、エージェント型コーディング、コンピューター操作、専門業務で非常に高いパフォーマンスを発揮します。OpenAI によると、要求の厳しい評価において、約 5 分の 1 のコストで GPT-6 Astra に迫る性能を発揮し、開発者は高性能なエージェントを大規模に構築、実行する余地をより多く確保できます。詳細については、 GPT-6.1 Sol モデルカード をご覧ください。 OpenAI GPT-6 Astra UltraFast モード : Ultrafast は GPT-6 Astra のプレミアム速度階層で、速度が最も重要なワークロード向けに構築されています。OpenAI によると、Ultrafast は API で最大 6 倍高速な推論を実現し、最大 300 トークン/秒を実現します。Amazon Bedrock 推論エンジンは、本番環境のワークロードに必要なパフォーマンス、セキュリティ、信頼性を提供します。詳細については、 GPT-6 Astra モデルカード をご覧ください。 Anthropic Claude Sonnet 5.5 : Claude Sonnet 5.5 は、より高性能で効率的な Sonnet であり、Sonnet 5 から一段進化しているため、すでに Sonnet を利用して開発しているチームにとって自然なアップグレードとなります。コーディング能力が向上しており、同じセッション内で Claude を使って機能の構築や修正を行ったり、出力を要件と照合して検証したりするなど、より大きなコーディング戦略の一環として、範囲が明確に定義されたタスクを完了するのに適しています。詳細については、 Claude Sonnet 5.5 モデルカード をご覧ください。 SpaceXAI Grok 4.7 : Grok 4.7 は Grok 4.6 をベースに、混在する文書の処理を改善し、計画とエラー回復によってリポジトリ規模のコーディングの信頼性を高め、フォーム入力やポータルナビゲーションを行うブラウザ操作エージェントを強化しています。詳細については、 Grok 4.7 モデルカード をご覧ください。  9 月 28 日週のリリース 私が注目したリリースをいくつかご紹介します。 AWS Well-Architected Agent (preview) : AWS 環境を分析し、アプリケーションのコスト、セキュリティ、パフォーマンス、レジリエンスを改善するための、的確でコンテキストに応じた推奨事項を提供する AI エージェントサービスを利用できます。エージェントはお客様のインフラストラクチャを分析し、お客様固有のビジネス目標を理解し、状況に応じた推奨事項を提示します。 Amazon Aurora PostgreSQL は Apache Iceberg および Parquet データの直接クエリをサポートします : 既存の PostgreSQL アプリケーションとツールを使用して、抽出、変換、ロード (ETL) パイプラインやデータの複製を行うことなく、運用データと、Apache Iceberg および Parquet 形式でデータレイクに保存されているデータをまとめて直接クエリできます。 Amazon S3 Tables は Apache Iceberg V3 のすべてのデータ型をサポートします : Amazon S3 Tables では、Iceberg V3 仕様で定義されている列のデフォルト値に加え、geometry、geography、unknown、nanosecond timestamp の各データ型がサポートされるようになりました。地理空間座標とナノ秒精度のイベント時間を、文字列や整数でエンコードする代わりにネイティブに保存できるようになりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変更された場合、運用への影響を最小限に抑えられるよう、 AWS Product Lifecycle Changes で、利用可能な代替手段に関するガイダンスと移行サポートをお客様に提供します。次のライフサイクル変更は、2026 年 9 月 29 日に更新されました。 メンテナンスフェーズへの移行 (2026 年 10 月 29 日以降、新規のお客様は利用できなくなります): Amazon Chime SDK SIP Media Application Amazon WorkSpaces Secure Browser サンセットフェーズに入るサービス: Amazon Managed Blockchain (2027 年 9 月 29 日サポート終了) Amazon DevOps Guru (2027 年 9 月 30 日サポート終了) AWS Backint Agent for SAP ASE (2027 年 9 月 29 日サポート終了) AWS Infrastructure Composer (スタンドアロンコンソールのサポート終了: 2026 年 12 月 7 日) サポート終了を迎えるサービス (2026 年 9 月 29 日現在): Amazon Mechanical Turk 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 Kiro ワークフローの紹介 : Kiro のワークフローでは、複雑なタスクを最初から最後まで複数のエージェントで実行でき、監督も少なくて済みます。Kiro 自体の開発にもワークフローを使用しており、新しいクラウド設定、クラウドセッション、ワークフローエクスペリエンスの大部分をこれらのワークフローで構築しています。 Strands Decider のご紹介 : Strands Decider は、意思決定モデルまたはシステム 1 モデルと呼ばれる新しいクラスのモデルの 1 つで、今月初めに TypeSafe AI が Jev を発表して以来、大きな注目を集めているタイプのモデルです。Strands Decider 2B は、迅速な実験、ローカル開発、イノベーションに最適化された、小規模なオープンソースの意思決定モデルです。 AWS パートナー向けの新しい FDE パスウェイ : 6 月 30 日、AWS は 10 億ドルの投資に支えられた Forward Deployed Engineering (FDE) 組織を発表し、Partner-Led FDE の取り組みを通じて、この実践的なデリバリーアプローチを AWS パートナーにも拡大しました。現在、AWS パートナーは、本番環境向けのエージェンティック AI の提供に必要な実践的能力を認定する 3 つの新しい Partner FDE パスウェイと認証情報を活用して、その専門性を体系的に構築し、検証できるようになりました。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント ( AWS re:Invent 、 AWS Community Days など) を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 10 月 5 日週のニュースは以上です。10 月 12 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

(この記事は、 AWS 기반 EDA 환경으로 Rebellions의 차세대 AI NPU 개발 가속화하기 を翻訳したものです。) 先端半導体の開発においては数多くの Logic Simulation を繰り返し、DFT（Design for Test）や Physical Design のように高いコンピューティング性能を必要とする EDA（Electronic Design Automation）作業を実行する必要があります。設計規模と検証範囲が大きくなるほど、必要な CPU コアやメモリ、共有ストレージのスループットもあわせて増加します。必要な時点で十分なインフラを確保できなければ、EDA ツールの実行時間やジョブの待ち行列が長くなり、開発スケジュール全体に影響を及ぼす可能性があります。 AI 推論用 NPU を開発する Rebellions は半導体設計プロセスの Design Verification（DV）と Physical Design（PD）業務に AI Transformation（AX）を適用し、エンジニアの生産性を約 3 倍に向上させました。しかし、エンジニアリング業務の生産性が高まった後も相対的に長い EDA ツールの実行時間が全体の開発速度を制約し、新たなボトルネックとして浮き彫りになりました。 Rebellions はこのボトルネックを解消して設計開発全般の生産性をさらに高めるため、実際の NPU 開発ワークロードに基づいて AWS 環境における EDA の性能と拡張性を検証しました。 本記事では AWS ParallelCluster と Amazon FSx を活用した EDA 環境の構成とともに、Logic Simulation、DFT、Physical Design の各ワークロードで確認した性能改善の結果を紹介します。 Rebellions の紹介 Rebellions は AI 推論用の NPU チップからコンパイラを含むソフトウェアまでを自社で開発する、 AI 推論専用のフルスタック・ファブレス・スタートアップです 。大韓民国政府が設立した 国民成長ファンドの第 1 号投資企業 として国家のソブリン AI インフラエコシステムを先導しており、APAC、中東、欧州などのグローバル市場へ事業を拡大しています。 データセンターインフラ向けの第 1 世代 NPU である ATOM の商用化に成功しました。ATOM は大規模なトラフィックが発生する SKT の「エイダット」通話要約サービスなどに採用されています。また、 大韓民国初の NPU-as-a-Service を構築しました。 第 2 世代 NPU である Rebel100 （以下 R100）は最高の performance-per-watt と 韓国初のペタフロップス級の性能 を基盤に、エージェンティック AI の時代に求められる CPU–NPU 統合最適化と、サーバー単位からトークンファクトリー単位まで拡張可能なアーキテクチャを提供します。これにより多様な次世代 AI ワークロードに柔軟に対応できます。2026 年初めに量産に着手し、2026 年下半期から多様な顧客環境へ本格的に適用される予定です。 今後はより多様で複雑化する AI ワークロードに最適化された性能を提供するため、次世代のメモリ中心構造（memory-centric architecture）と HW–SW co-design を中心に、技術および製品アーキテクチャの発展の方向性を継続的に模索していく計画です。 NPU 開発の次のボトルネック、EDA 実行時間 EDA ワークロードは作業によって必要とするリソースの特性が異なります。Logic Simulation は機能や設定、乱数 seed に応じて生成される多数の独立したジョブを限られた時間内に処理しなければなりません。DFT と Physical Design は高い CPU 性能だけでなく、大容量メモリと高速なファイルアクセス性能を必要とします。 こうした作業を固定されたオンプレミスインフラで実行すると、2 つの問題が生じます。まず、プロジェクトのピーク需要を基準に機器を購入すると、平常時にはリソースが余ります。逆に、平均需要に合わせて機器を構成すると、regression や設計マイルストーンのように作業が集中する時期に待ち時間が長くなります。 高性能サーバーを 1 台追加するだけではすべての問題を解決することはできません。Logic Simulation のように独立したジョブが多いワークロードでは並列処理能力が重要であり、Physical Design には高いクロックと十分なメモリを備えたインスタンスが必要です。複数のジョブが共通の設計データやライブラリに同時にアクセスするため、共有ストレージとネットワークの性能もあわせて確保する必要があります。 Rebellions は EDA 作業ごとに適したコンピューティングリソースを選択し、regression や設計マイルストーンのように作業が集中する時点で大規模な実行容量を確保できるかを確認するため、AWS ベースの EDA 環境を検証しました。 図 1. AX と EDA 実行環境の改善による NPU 開発期間の短縮 EDA ワークロードで AWS が提供するメリット オンプレミスの EDA ファームではプロジェクトの開始前にコンピューティングとストレージの需要を予測して機器を購入する必要があります。Rebellions が新規の高性能サーバーを検討した際には、発注後に最低 20 週のリードタイムが必要で、設置と実際の利用開始までを考慮すると 6 か月から 8 か月待たなければなりませんでした。また、EDA の需要は full regression、DFT、Physical Design など特定の時期に集中するため、ピークを基準に機器を購入すると平常時にリソースが余り、平均需要に合わせると重要な時期にジョブの待ち時間が長くなります。 AWS ではプロセッサアーキテクチャや CPU 性能、メモリ、ローカルストレージ、ネットワーク構成がそれぞれ異なる Amazon EC2 インスタンスの中から、EDA 作業に適した構成を選択できます。たとえば r8i は Intel Xeon 6 プロセッサと大容量メモリを必要とする x86 ベースの EDA 作業に活用できます。c8g は AWS Graviton4 プロセッサを搭載した Arm ベースのインスタンスで、使用している EDA ソフトウェアと関連ライブラリが Arm64 をサポートしていれば、よりコスト効率を高める選択肢として検討できます。x8aedz は高いシングルコア性能と大容量メモリ、ローカル NVMe ストレージを必要とする Physical Design や大規模な EDA 作業に適した選択肢です。これらのインスタンスを作業の特性に応じて選択し、必要な時点で拡張することで、サーバーの購入・設置にかかる時間を短縮し、必要なタイミングに合わせて実行環境を構成できます。 図 2. AWS ParallelCluster と Amazon FSx を活用した EDA リファレンスアーキテクチャ AWS ParallelCluster は Slurm ベースの EDA クラスターの構築と管理を簡素化します。ユーザーが従来と同じ方法でジョブを投入すると、待機中のジョブに合わせて Amazon EC2 のコンピューティングノードを作成し、ジョブの完了後に使われなくなったノードを減らします。Logic Simulation、DFT、Physical Design のように要求仕様が異なる作業をそれぞれ別の Slurm キューと EC2 構成に紐づけることもできます。最小コンピューティングノード数を 0 に設定すれば、full regression や設計マイルストーンのときだけ多くのコンピューティングリソースを使用し、平常時はすべてのコンピューティングノードを終了できます。 EDA ツールは多数のソースファイルやライブラリを読み込み、ログ、waveform、中間結果を繰り返し書き込みます。複数のコンピューティングノードが同じデータに同時にアクセスするため、共有ストレージのスループットだけでなくアクセスレイテンシーも重要です。AWS では EDA ワークロードの特性に適した Amazon FSx for OpenZFS と Amazon FSx for NetApp ONTAP という高性能ストレージの選択肢を利用できます。 半導体の設計ファイルは企業の中核的な資産であるため、クラウド環境でも外部への流出を防止できる統制が必要です。EDA 環境をお客様が管理する AWS アカウントと VPC のプライベートサブネットに配置し、データセンターからは AWS Site-to-Site VPN を介してのみアクセスするように構成すれば、設計ファイルとコンピューティング環境をインターネットに公開しません。IAM とセキュリティグループによって許可されたユーザーとシステムのみがアクセスできるように制限し、保存データを暗号化するとともに、AWS CloudTrail でユーザーのアクティビティを監査し、Amazon CloudWatch Logs でシステムとジョブのログをモニタリングできます。これにより、設計ファイルを統制されたネットワークと権限の境界内で管理し、外部流出に対する懸念を軽減できます。 Rebellions が適用した EDA on AWS アーキテクチャ Rebellions は前述した AWS のコンピューティングとストレージの選択肢のうち、AWS ParallelCluster、Amazon EC2 x8aedz および c8g インスタンス、そして Amazon FSx for OpenZFS ストレージを使用して検証環境を構成しました。Rebellions のデータセンターと AWS VPC は AWS Site-to-Site VPN で接続しました。 図 3. Rebellions EDA on AWS 検証アーキテクチャ EDA エンジニアは Site-to-Site VPN を介して AWS ParallelCluster の Slurm スケジューラーにジョブを投入し、データセンターの RTL 設計ファイルを Amazon FSx for OpenZFS にアップロードします。待機中のジョブが発生すると、必要な Amazon EC2 x8aedz コンピューティングノードが作成され、Logic Simulation、DFT、Physical Design のジョブを実行します。ジョブが完了してアイドル状態になると、すべてのコンピューティングノードは終了し、ヘッドノードと Amazon FSx for OpenZFS、EDA ライセンスサーバーは維持されます。コンピューティングノードでは FSx for OpenZFS の高性能ストレージをマウントして EDA ツールや設計データ、作業領域、結果を共有し、クラスターとジョブのログは Amazon CloudWatch Logs で確認できます。 ファイルアクセス性能の比較 EDA 作業はソースコードやライブラリだけでなく、大量のログ、waveform、中間成果物に繰り返しアクセスします。特に多くのジョブが同時に実行される場合、共有ファイルシステムとネットワークのスループットおよびレイテンシーが全体のスループットを制約する可能性があります。 Rebellions は実際の EDA 作業を実行する前に、オンプレミスの NFS と AWS のストレージシステムのファイルアクセス性能を比較しました。 項目 Rebellions オンプレミス NetApp C400A, 40G Ethernet AWS EC2 FSx for OpenZFS, 75G Ethernet 性能改善倍率 シーケンシャル書き込み 108MB/s 855MB/s 約 7.9 倍 シーケンシャル読み込み 67MB/s 1,229MB/s 約 18.3 倍 並列書き込み（4 ストリーム同時） 112MB/s 1,134MB/s 約 10.1 倍 4KB ランダムアクセスのレイテンシー 2.98ms 0.10ms 約 29.8 倍 AWS 環境はシーケンシャル書き込みで約 7.9 倍、シーケンシャル読み込みで約 18.3 倍、4 ストリームの並列書き込みで約 10.1 倍高いスループットを示しました。4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。 こうした差にはストレージ自体の性能だけでなく、ネットワーク帯域幅とリソースの割り当て方式も影響しました。オンプレミス環境では 10Gbps イーサネット 4 回線を複数のコンピューティングサーバーで共有し、個々のサーバーは最大 10Gbps の帯域幅を使用していた一方、AWS 環境では個々の Amazon EC2 インスタンスに最大 75Gbps のネットワーク帯域幅が提供され、7 倍以上の帯域幅を活用できました。また、オンプレミスのストレージは全社で共有するリソースでしたが、Amazon FSx for OpenZFS は今回の EDA ワークロード専用に割り当てられ、他のワークロードの I/O の影響を受けませんでした。 単一の Logic Simulation ジョブで CPU 処理が中心であれば、ストレージのスループットが 10 倍に増えても、アプリケーションの実行時間が同じ比率で短縮されるわけではありません。共有ストレージのメリットは多数のジョブが同時にデータを読み込み、ログや結果を書き込む際により明確に表れます。 Logic Simulation 性能の比較 Logic Simulation は半導体を製造する前に、RTL（Register Transfer Level）で記述した回路が意図したとおりに動作することをソフトウェアで検証する作業です。検証対象の RTL（回路設計）ごとに 1 回あたり数分から数十時間かかるテストを数万件、それぞれ数十回繰り返す必要があります。 今回の比較では EDA ツールとして Synopsys VCS を使用し、Rebellions が保有するオンプレミスサーバー（Intel Xeon Processor ベース）の物理コア数に合わせて、最大 64 個のジョブを同時に実行しました。EC2 では多様な CPU とメモリ構成のインスタンスが提供されているため、ワークロードの特性に合った構成を選択できます。今回の実験では多数の物理コアと高いシングルコア性能に加えて、大容量メモリをあわせ持つ x8aedz コンピューティングノード（AMD EPYC 9R45 ベース）と、コスト効率の高い c8g コンピューティングノード（AWS Graviton4 ベース）の結果を比較しました。 テストした UCIe IP と Network-on-Chip の両ワークロードにおいて、AWS 環境はオンプレミス環境よりも一貫して短い実行時間を示しました。同時ジョブ数が 1 個、16 個、32 個、64 個と増加する間、AWS x8aedz コンピューティングノードでのシミュレーションはオンプレミス比で 2.3 倍から 2.6 倍速く完了し、AWS c8g コンピューティングノードでも約 1.3 倍速く完了しました。 図 4. UCIe IP と Network-on-Chip の Logic Simulation 性能比較 Logic Simulation には Synopsys VCS® のような商用シミュレーターのライセンスが必要なため、コンピューティングリソースとライセンス数量のバランスを取ることが重要です。韓国内外の大企業のように Site Licensing を結んでいる場合は、サーバー（CPU core）の数を多く増やして Simulation スループットを確保するのも一つの方法ですが、限られた数のライセンスを運用するスタートアップには、高いシングルコア性能によって個々のジョブ時間を短縮し、保有するライセンスを効率的に活用するアプローチが必要です。 したがって Logic Simulation 環境ではライセンス数量と作業の特性に合わせてコンピューティングリソースを選択する必要があります。AWS では高いシングルコア性能、多数の CPU コア、大容量メモリ、ローカル NVMe ストレージなど、それぞれ異なる特性を持つ多様な Amazon EC2 インスタンスを選択できます。これにより、個々のシミュレーションの実行速度と大規模並列ジョブのスループットを考慮して適切なコンピューティング構成を使用し、必要な時点でのみ拡張できます。 Design for Test（DFT）設計性能の比較 DFT は製造されたチップの欠陥を検査できるよう、診断回路を設計に挿入するプロセスです。数多くの回路で発生しうる多様な欠陥を短時間で検出しつつ、チップの機能と性能への影響を最小限に抑える必要があるため、高い CPU 負荷とストレージ I/O が発生します。 今回の実験では R100 の Neural Core と Shared Memory を対象として、Synopsys TestMAX を使用しました。ジョブ全体の実行時間を合計すると、オンプレミスでは 11 時間 51 分、AWS x8aedz コンピューティングノードでは 4 時間 41 分かかりました。同一のジョブセットを基準に、AWS 環境が約 2.5 倍速く完了しました。 DFT 対象 作業種別 オンプレミス AWS x8aedz 性能倍率 Neural Core Memory Built-in Self Test 4 時間 44 分 1 時間 54 分 約 2.5 倍 Neural Core Scan Insertion 1 時間 40 分 38 分 約 2.6 倍 Shared Memory Memory Built-in Self Test 2 時間 26 分 1 時間 16 分 約 1.9 倍 Shared Memory Scan Insertion 3 時間 1 分 53 分 約 3.4 倍 Physical Design 性能の比較 Physical Design はコードで記述された半導体の設計図である RTL から、ファウンドリで製造する物理的な回路レイアウトデータである GDSII を作成するプロセスです。論理合成（RTL Synthesis）、Floor Planning と Placement、Clock Tree Synthesis、Routing、Timing および Power Optimization など、非常に複雑な段階で構成されます。 Physical Design は CPU 負荷とメモリ要求量の大きい作業であり、そこで使用される EDA ツールのライセンスは設計インフラの中で最も比重の大きい投資項目です。したがって EDA ツールを効率的に活用して 1 回あたりの実行時間を短縮するためには、高性能 CPU を確保することが非常に重要です。今回の実験においても R100 の Neural Core を対象に Synopsys Fusion Compiler を使用して性能を比較しました。 作業種別 オンプレミス AWS x8aedz 性能倍率 Logic Synthesis 101 時間 54 時間 約 1.9 倍 Clock Tree Synthesis 75 時間 34 時間 約 2.2 倍 Route 90 時間 41 時間 約 2.2 倍 合計 266 時間 129 時間 約 2.1 倍 オンプレミス環境では上表の全作業に 266 時間かかりましたが、AWS 環境では 129 時間で完了しました。約 11 日かかっていた 1 回の実行を約 5.4 日に短縮し、全体の時間を約 2.1 分の 1 に短縮しました。 今回の結果は、高性能 CPU と大容量メモリを備えた AWS のコンピューティング環境の活用により、長時間実行される Physical Design の反復サイクルを短縮し、EDA ツールをより効率的に活用できることを示しています。 検証結果が示すもの 今回のテストでは次の結果を確認しました。 ファイルアクセス性能は項目に応じて 約 7.9 倍から 18.3 倍高いスループット を示し、4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。 Logic Simulation は 1 個から 64 個の同時ジョブの条件で 2.3 倍から 2.6 倍速く 完了しました。AWS Graviton Processor によってコスト効率を高めた c8g インスタンスでは 1.2～1.4 倍速く 完了しました。 DFT 作業は 11 時間 51 分から 4 時間 41 分に短縮され、 約 2.5 倍速く 完了しました。 Physical Design は 266 時間から 129 時間に短縮され、 約 2.1 倍速く 完了しました。 この結果は最新のプロセッサと大容量メモリ、高帯域ネットワーク、独立して割り当てた共有ストレージが組み合わさったテスト環境の効果です。いずれか 1 つのサービスだけで全体の改善を説明することはできません。 より重要な変化は開発需要が発生した時点で多くのコンピューティングリソースを集中的に投入できる点です。Logic Simulation の大量の待ちジョブに対しては複数のコンピューティングノードを同時に拡張し、Physical Design に対しては高いクロックと大容量メモリを備えたインスタンスを割り当てることができます。ジョブの終了後に動的コンピューティングノードを減らすことで、短いピーク需要のために同じ規模のサーバーを常時保有する必要性も低下します。 コストを評価する 3 つの観点 クラウドとオンプレミスのコストは時期や契約、運用方式によって異なるため、単純なサーバー価格だけで比較するのは困難です。ここでは具体的なコストの数値を断定するのではなく、Rebellions が EDA 環境を検討する中で考慮した 3 つの基準を見ていきます。 まず、開発開始の時点に合わせて最上位のサーバーを導入するのは容易ではありません。新規サーバーを選定して発注すると最低 20 週のリードタイムが必要で、配送と設置を経て実際に使用できるようになるまで 6 か月から 8 か月待たなければなりません。開発スケジュールに間に合わせるには、少なくとも 6 か月前に機器を発注しなければならないということです。機器が予定どおり導入されたとしても、開発の開始が 6 か月遅れたらどうなるでしょうか。実際の開発においては、1 世代前のサーバーを使うことになる可能性があります。AWS では開発が始まる時点で利用可能な最新世代の高性能 CPU を選択し、必要な規模のコンピューティングリソースをプロジェクトに合わせて構成できます。 次に、スタートアップがオンプレミスを導入するにあたっては、すべてのワークロードの最大要求量を考慮して CPU 性能、メモリサイズ、ストレージを選定することになるため、個々の EDA ジョブにとっては不要なリソースを使用する非効率が生じます。オンプレミス環境では複数の EDA ワークロードの最大要求仕様を考慮してサーバーを導入しなければならないため、作業によってはリソースが非効率に使われる可能性があります。たとえば、Physical Design 作業には約 400GB～1TB の大容量メモリが必要です。Rebellions が導入したオンプレミスサーバーはすべて 3TB のメモリを搭載しており、開発の前半には Simulation に、後半には Physical Design に活用しています。一方 Simulation ジョブの場合、IP は 2GB～30GB 程度のメモリしか必要としないため、開発の前半ではリソースを非効率に活用していることになります。ストレージのコストも考慮する必要があります。Rebellions が検討した最新型の 500TB 級ストレージは 10 億ウォンから 20 億ウォンの水準でした。ストレージは平均使用量とピーク使用量の差が大きいものの、オンプレミスではピークを基準に高性能・大容量のシステムをあらかじめ構築しておく必要があります。想定したピークの容量や性能を超えると、実行中の EDA ジョブが中断されるという深刻な問題が発生するおそれもあります。一方 AWS ベースのコンピューティングクラスターでは、ストレージへの大規模な初期投資を抑え、実際の使用パターンに合わせて適切な CPU と必要なストレージ容量を構成できます。 最後に EDA ツールの活用度もあわせて評価する必要があります。高性能な EDA ツールを低性能のサーバーで長時間実行すると、ライセンスを十分に活用することは困難です。したがって EDA 環境のコストは、コンピューティングリソースの時間あたり単価だけでなく、高性能なコンピューティング環境で完了したジョブ数や短縮した実行時間、ライセンスの活用効率を基準に評価すべきです。 おわりに – 真の開発の加速 AX によってテスト生成や分析など、エンジニアの業務効率を大きく高めたとしても、EDA ツールの実行時間がボトルネックとして残っていれば、開発期間全体の短縮には限界があります。ソフトウェア開発手法の革新と、それを支えるコンピューティングインフラがともに改善されなければならないのは、このためです。 Rebellions は実際の NPU 開発ワークロードを AWS で検証し、Logic Simulation、DFT、Physical Design の実行時間を短縮し、共有ストレージのファイルアクセス性能を高められることを確認しました。また、最新のクラウドコンピューティングインフラがサーバー調達リードタイムの長さやピーク需要に合わせたストレージへの過剰投資など、オンプレミス環境の限界を補うことのできる現実的な代替手段であることを確認しました。 AWS ベースの EDA 環境の価値は単により高速なサーバーを 1 台使うことにあるのではありません。作業の特性に合ったコンピューティングとストレージを選択し、regression や設計マイルストーンに大規模なリソースを集中的に投入した後、作業が終われば再び縮小できる点にあります。これにより、固定されたインフラ容量が原因で生じるジョブの待ち時間を短縮し、設計の反復結果をより早く得ることができます。 Rebellions は AX によるソフトウェアの革新と AWS の弾力的なコンピューティングインフラが生み出すシナジーを基盤に、次世代 AI NPU の開発をさらに加速し、グローバル市場に競争力のある AI 推論ソリューションを迅速に送り出してまいります。 参考資料 Rebellions Rebellions – R100 AWS ParallelCluster Amazon FSx for OpenZFS Amazon FSx for NetApp ONTAP Amazon EC2 x8aedz Instance Amazon Graviton Processor 著者について パク・サンギュ（박상규） パク・サンギュ氏は Rebellions で Design Verification 分野をリードしており、ATOM MAX、R100、R100s のプロジェクトに参加しました。最近は Rebellions の開発戦略に沿った Agentic Verification Framework をチームメンバーとともに開発しており、この挑戦の一環として AWS の Parallel Computing Service の導入を検討しました。 ジェ・サンウン（제상은） ジェ・サンウン氏は Rebellions で IP/System レベルの検証はもちろん、Architecture evaluation から Silicon Validation まで、多方面にわたってチームに貢献する Multi-role player です。最近は Agentic Verification の基盤となる EDA Orchestration ソリューションである dv-flow を開発し、AWS の Cloud Service をチームの開発業務に適用するための技術評価を主導しました。 ペク・スンミン（백승민） ペク・スンミン氏は Rebellions で Global Strategy および Partnership 業務を担当しています。最近は Next Silicon 戦略とパートナーシップの方向性の策定に参画しており、開発環境の高度化に向けた AWS Cloud および EDA インフラの導入検討と、主要な技術パートナーとの協業に心血を注いでいます。 チェ・チョルウ（최철우） チェ・チョルウ氏は AWS の Senior Frontier AI SA です。主にスタートアップの AI/ML、Physical AI、EDA 分野におけるアーキテクチャ設計と最適化を支援しています。 チョ・ミンス（조민수） チョ・ミンス氏は Amazon Web Services で Frontier AI APJ Sales を担当しており、Physical AI や AI 半導体など高い成長ポテンシャルを持つ AI スタートアップの AWS 導入と Go-to-Market 戦略の実行を支援しています。スタートアップが Zero to One の道のりで直面する技術的・事業的な課題を経営陣の Thinking Partner としてともに考え、実質的な結論を導き出せるよう支援しています。 翻訳はソリューションアーキテクトの酒井 賢が担当しました。原文は こちら です。