オンプレミス設計とオンクラウド設計の間のトレードオフ

プラトン再発行

フォロワー： 0

テーブルに着いた専門家: 半導体エンジニアリングの専門家が、企業がオンプレミスとクラウドで作業を分割する方法と理由、そして何に注意すべきかについて、CAD インフラストラクチャおよび物理設計フェローの Philip Steinke と話し合いました。 AMD; Mahesh Turaga 氏、クラウド事業開発担当副社長ケイデンス設計システム; Lightmatter のハードウェアエンジニアリング副社長、Richard Ho 氏。 Craig Johnson 氏、クラウドソリューション担当副社長 Siemens Digital Industries Software; そしてロブ・エイトケン氏、フェローシノプシス。以下は、Design Automation Conference の生の聴衆の前で行われた会話の抜粋です。このディスカッションのパート XNUMX は、こちら.

SE: 今日のチップ設計では多くのことが危機に瀕していますが、クラウドリソースで最高の ROI を達成するにはどうすればよいですか?

スタインケ: クラウド対応のためのワークフローを選択するとき、私たちはデータを調べることから始めました。カプセル化できる管理可能なデータセットを持ち、クラウドホストのデータセンターに移動して何らかのコンピューティングを実行し、適切な量の結果が返されるのはどれですか?私たちが注力した分野の 1 つはフロントエンドの検証です。そこで私が好むフローには、ビルドをオンプレミスに保持し、モデル自体をテスト刺激とともにバンドルし、それをクラウドコンピューティング上で実際のシミュレーションアクティビティを実行するために送信することが含まれます。私たちがクラウド対応を行った他のクラスのワークロードは、フルチップ検証ワークロード、静的タイミング、物理検証、電源のためのフルチップサインオフ実行です。主な理由は、配置配線タイプの環境では、毎日の ECO または定期的な ECO が定期的に行われ、変更が加えられます。すでにデータ管理のセットアップがあり、設計のリリースが行われています。そのため、そのリリースメカニズムにフックを組み込むことができ、データセンター内の何らかのローカルリリースボリュームにデータを置くだけでなく、それらのデータを実行するために選択されたクラウドデータセンターにそのデータをプッシュすることができます。仕事。このような大きなワークロードに関する懸念の 1 つは、マージ済みの Oasis をすでに持っている場合、または静的タイミングを実行するデザインの仕様をすべて収集している場合、シフトするデータがかなりの量になることです。一斉に。しかし、ブロックレベルのリリース方法を更新することにより、各ブロックが 1 日を通してリリースされるにつれて、それらが少しずつ浸透していきます。そうすることで、クラウドでホストされているフルチップ分析ジョブをより低い遅延で開始できます。私が見た主な課題は、大きなジョブを実行するのに十分なメモリを備えた優れたクラウド VM にアクセスすることです。これは、チップ設計会社が使用できる十分な RAM を備えたソリューションの提供をクラウドパートナーに求め続けているもう 1 つの分野です。

SE: ワークロードをオンプレミスとクラウドでいつ実行する必要があるかを見極めることについて、どのようなアドバイスができますか?

エイトケン: このパネルの代表者だけに興味深い力関係が見られます。それは、リチャードがそれにアプローチする方法と、フィルがそれにアプローチする方法が異なるためです。ニーズの山と谷を行き来するデザインに非常に焦点を当てています。おそらく AMD では、常に多くの設計が進行しているため、彼らが何をしようとしているのかという点で初期の取り組みが行われていると思われます。すべての設計をクラウド上で行う世界に到達しようとしていて、オンプレミスのデータセンターをまったく持ちたくない場合、どのようなインフラストラクチャが合理的でしょうか?それにアプローチする方法は、すでに所有している大規模なインフラストラクチャのバックアップおよび拡張機能としてクラウドを使用する場合とは異なります。

SE: 実際のところ、どうやって決めるのですか?

咳：データを見てみます。データはどのくらいありますか?どれくらいの量のデータを生成するのでしょうか?そして、何を返す必要がありますか？これを成功させるために重要なのは、クラウドから情報を返したいということです。オンプレミスでは最小限にする必要があるため、表示されるのはレポートと回帰の結果だけです。私たちのビルドは実際には小規模なオンプレミス上にあります。私たちはそれを出荷してシミュレーションを実行し、独自のカバレッジ分析を行います。その後、結果を返送します。結果は非常に小さく、良好です。バックエンドが違います。物理設計の部分では、設計を外部に出荷しますが、データベースは巨大であるため、できるだけ長くクラウド上に残しておく必要があり、実際にはまったく戻したくないのです。その時点で、それはサービスとしてのインフラストラクチャです。従業員にクラウドにログインしてもらい、GDS を取得するまでのすべての物理設計をそこで行うだけです。マシンの内部にあるものです。どのくらいのメモリを搭載できるでしょうか?それがリミッターの一つです。実際、非常に大規模な仮想マシンをクラウドに置くのは非常にコストがかかります。自分で買ったほうが安い場合も多いです。コストについては話していません。クラウドのコストは人々が考えているものではありません。かなり高いですね。オンプレミスよりも頻繁に使用されるため、柔軟性と大容量メモリリソースへのアクセスという利点を得るにはバランスを取る必要があります。そして、その見た目は顧客ごとに非常に個性的になります。

ジョンソン： この質問は、実際にそれを行うことの ROI に関連しています。それは環境のユーザーとして何を達成しようとしているかによって異なりますが、それは課題の一部です。各企業は、自社の戦略に基づいて独自の計算を行って、クラウドで何をしたいのか、そのメリットを享受するためにどれだけ積極的に支出するつもりなのかを把握します。もう 1 つの要素は、測定する収益が所有コストとは異なるということです。当社は ROI の「R」部分よりも総所有コスト分析の方が得意である傾向にあり、スループット時間や市場投入までの時間といった目に見えない要素をより活用する必要があります。

エイトケン: 遅延のような単純なものであっても、ツールの実行中に「マウスを動かした後、しばらくして何かが起こる」という応答時間が発生すると、非常にイライラすることがあります。

ツラガ: 歴史的に、クラウドの ROI を見ると、クラウドを非常に効果的に活用できるツールには 3 つのクラスがあります。 1 つ目は、設計の組織化、設計の反復、検証を伴う回帰です。 2 つ目は、計算負荷の高い長時間実行のシミュレーションがある場合で、さまざまなインスタンスで計算アルゴリズムを活用するために非常にうまく拡張できます。 3 つ目は対話型で、ツールのような遅延が必要であり、コラボレーションの大幅な増加も必要とします。これらは、クラウドから最高の ROI を得るツールの 3 つのカテゴリです。繰り返しになりますが、各顧客の状況に応じて、どのツールをクラウドで開始したいかによって異なります。当社の顧客の中には検証から始めた人もいますが、それは顧客の特定の状況によって異なります。

SE: クラウドユーザーの皆さんは、どのようにしてクラウド利用モデルを決定したのですか?

スタインケ: しばらく行ってきました。私たちはすでにかなり大規模なデータセンターを持っていたので、最初から全力を尽くす必要はありませんでした。私たちは、クラウドが提供するもので自分たちが持っているものを拡張することを検討していました。当社のオンプレミスデータセンターは、膨大な量のコンピューティング能力を提供し続けています。プロジェクトは次々と消えていき、予想外のことが起こります。その柔軟性をさらに強化し、複数のコンピューティングソースを活用できることは、私たちが積極的に利用したいと考えていた利点です。それが私たちがクラウドを目指す動機の大きな部分を占めており、私たちがその道を選んだ理由でもあります。私たちはすでにその先行投資を行っていたので、それを強化して構築することを検討していました。

咳：これには 2 つの観点から答えることができます。 1 つ目の視点は、Lightmatter に入社する前は、Google で TPU とインフラストラクチャチームに所属しており、そこでクラウドも使用していたということです。そこでの答えはLightmatterでの答えとは異なります。自問しなければならない質問の 1 つは、リポジトリ (リポジトリ) をオンプレミスに置くかクラウドに置くかということです。 Google のような企業、そしておそらく AMD では、リポジトリをオンプレミスに置きたいと考えています。彼らはより安心感を感じ、より自分のコントロール下にあると感じます。 Lightmatter のような小規模な会社では、私は必ずしも気にしません。クラウドのセキュリティには満足していたので、クラウド上にリポジトリを持つことができました。そして、その小さな文脈では、クラウドにリポジトリがあるということは、クラウドをほぼ完全なインフラストラクチャとして使用していることを意味します。私のオンプレミスと同じです。それが最初の懸念です。 2 番目の懸念はレガシーです。一部の企業にはレガシーがあり、レガシーからクラウドベースのソリューションに移行しようとする場合、何が得られるのかを本当に理解する必要があり、これがこのパネルの目標を物語っています。私たちは、新しいマシンを使用できるなど、柔軟性の点でどのようなメリットが得られるのかを指摘しようとしています。それが本当に重要なのは、多くの並列実行が行われるワークロードの一部です。実行中の大規模なサーバーとジョブのセットを管理したい場合は、そこにクラウドを使用する必要があります。それをワークロードに活用できます。次に、データフローに戻ります。制約がある場合は、決定を下す必要があります。私たちは物理設計のリポジトリをクラウドに置くことを決定しましたが、他の企業はそうではありませんでした。企業にはもっと多くのものがあることを私は知っています。彼らは多くのストレージを必要とし、それほど多くのマシンを必要としないため、多くの物理設計をまだオンプレミスで行っています。したがって、それぞれのケースを検討し、自分の状況に基づいて決定を下す必要があります。

ツラガ: 私たちの中小企業の顧客のスタートアップの多くは、オンプレミスのリポジトリを望んでいません。彼らは従来のデータセンターの問題を抱えていないため、クラウドを完全に受け入れています。大規模なオンプレミスインフラストラクチャを備えている大企業の一部は、すでにハイブリッドタイプのモデルに移行しています。

SE: クラウドでは、さまざまなベンダーから提供されているほとんど不可解なほどの数のインスタンスタイプがあり、さらにクラウド向けに最適化されていないライセンスコストがある中で、ユーザーはジョブを実行するために適切な種類のインスタンスを選択する方法をどのように改善できるでしょうか?

ジョンソン： これは私たちが取り組もうとしている基本的な事柄の 1 つです。私たちのアイデアは、主に自社のインフラストラクチャを管理し、独自の方法で最適化したいと考えている AMD のような企業向けであり、彼らが私たちに支援を求めているのは、どのタイプのインスタンスとどの量のメモリが最適に機能するかというアプリケーション固有の決定です。そして、場合によってはワークロード自体の構成も異なります。最適なパフォーマンスを得るためにジョブの実行をどのように管理できるでしょうか?私たちはそれをすべてフライトプランと呼ぶものにパッケージ化しようとします。フローのさまざまな部分で利用できるこれらのフライトプランと、ベースラインの提案が用意されています。顧客がそれを使いたいと思ったら、それは素晴らしいことです。彼らがそれを真似してそこから改善したいのであれば、それは私たちにとっても問題ありません。

エイトケン: シノプシスの見解は同じですが、実行している特定の設計にも依存します。一部の設計では、他の設計よりも大きいインスタンスまたはより高いインスタンスが必要になります。そして、特定のワークフローが何であるかに応じて、一部のインスタンスは他のインスタンスより多かれ少なかれ意味をなします。また、かかる費用はライセンス料だけではありません。クラウド内のマシンのコストも同様にトレードオフする必要があります。大きなマシンは高価ですが、より小規模なインスタンスでワークロードを長期間実行し、コンピューティング料金よりも少ないライセンス料金を支払うこともできるかもしれません。

咳：私たちの焦点は、実際の実行がどのようなものであるかという観点からそれを見ることにありました。プレチェックインランですか？事前チェックインでは、低遅延で高速な実行が必要なので、そのために非常に高性能なインスタンスが得られます。それは一夜にしての退行でしょうか？その場合、どれだけ速く終わるかは必ずしも気にしません。一晩で完了する必要があるため、一晩の回帰のために安価なインスタンスの代金を支払うことができることを意味します。私たちはクラウドプロバイダーと協力して、この種のジョブの実行に最適なインスタンスを見つけ出します。次に問題となるのはコストの最適化です。先ほども述べたように、コストはかなり早く増加するため、コストはできるだけ低く抑えたいと考えています。私たちはそれぞれの特定のワークロードを調べて、「そのワークロードに必要なインスタンスタイプは何ですか?」と考えます。同時に、ジョブごとにインスタンスのプールを管理し、そのジョブが実際に開始されたときに適切な速度で実行できるように、そのインスタンスのプールが十分に利用可能であることを確認する必要があるため、難しくなります。時間枠。導入に向けて、これらの質問に対処する必要があります。

ツラガ: 長年にわたり、私たちはいくつかのベストプラクティスを開発してきました。最初に、どのインスタンスタイプを使用するかわからない場合は、コンピューティングとメモリのバランスが取れたもの、または一般的なインスタンスタイプを選択します。ただし、さまざまな種類のワークロードや検証を検討すると、もう少しメモリが必要になります。タイミングに関しても同様です。さらに多くのメモリが必要です。 CFD 解析には GPU が必要になる場合があります。これらは、当社が開発したベストプラクティスの一部であり、お客様と共有しています。