re:Invent 2024: サムスン電子DSがAWSで実現した半導体工場設計環境
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Running a complex design environment on AWS (MFG205)
この動画では、Samsung ElectronicsのDS部門が、半導体工場(FAB)の設計・建設プロセスをAWSクラウド上で革新した事例が紹介されています。従来のOn-premiseシステムでのData Siloの問題を解決するため、Amazon DCVやAWS Direct Connectなどを活用した設計プラットフォームを構築し、セキュリティを確保しながら場所を問わない設計環境を実現しました。特に、AutoCADやRevitなどの3D設計ツールをAMIテンプレートとして提供し、Self-serviceポータルを通じて自動プロビジョニングする仕組みや、Web形式でのデータ変換による他システムとの連携など、具体的な実装方法が詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSを活用した設計プラットフォームの概要
おはようございます。AWS Solutions Architectのイ・ウジンです。本日のセッションにご参加いただき、誠にありがとうございます。本日は、Samsung ElectronicsからChanghee ParkさんとYeongyu Hwangさんという特別なスピーカーをお迎えし、AWSで複雑な設計環境を運用してきた彼らの経験をご紹介できることを大変光栄に思います。セッションを始める前に、お二人がIT専門家ではなく、製造や建設のマネージャーやエンジニアであることを強調させていただきたいと思います。彼らがユニークなのは、エンドユーザーの視点から自ら設計プラットフォームを構築し、運用しているという点です。このセッションを通じて、設計作業の効率化をお考えの皆様が直面している課題の解決に向けた示唆が得られることを願っています。
本セッションでは、まず設計プラットフォームとは何かを定義し、AWSで独自のプラットフォームを構築する方法をご紹介します。続いて、Samsung Electronics DS部門による設計プラットフォーム構築の取り組みについてお話しします。Samsungが直面した課題、その解決策、そして達成した成果について詳しく見ていきます。最後に、本セッションで取り上げた重要なポイントをまとめて締めくくりたいと思います。
Industrial Designの課題とAWSによる解決策
それでは、セッションの本題に入りましょう。まず、Industrial Designの定義から始めたいと思います。これは、ユーザーとビジネスにとって最適な設計を生み出すことを目指す、高度に専門化された分野です。小型デバイスや電子部品、自動車から、建物や半導体製造工場のような特殊な施設まで、あらゆるものが含まれます。通常、これらの設計成果物を生み出すプロセスには、論理的なワークフローと複雑なデータ共有が伴います。
設計作業を進めるには、多くのデザイナーが効果的にコラボレーションできる環境が不可欠です。しかし、この環境には生産性、セキュリティ、管理という3つの主要な課題があります。一般的に、生産性を向上させるために、複数のグループや異なる企業間でデータをやり取りしながら設計作業を行います。デザイナーは、普段慣れ親しんでいる環境で作業することを好みます。さらに、作業は単一の拠点だけでなく、様々な場所から行われるのが一般的です。もう一つの大きな懸念は、セキュリティです。設計データには極めて高度なセキュリティ規制が求められます。データの漏洩防止だけでなく、ユーザーアクセスの制御も必要です。このような状況は、複雑なネットワークや大規模なインフラリソースを管理しなければならないIT担当者の作業負荷を大幅に増加させることになります。
分散した場所からユーザーがアクセスする環境でセキュリティを維持するために、集中管理型のスペースを検討することができます。この集中管理型のスペースは、エンドツーエンドの設計フローを通じてデータの一貫性を維持することも可能にします。しかし、リモートアクセス時の遅延など、ユーザー体験のパフォーマンスや、必要な設計ツールの可用性確保といった課題は依然として残ります。集中管理型のスペースに様々な要素を統合することで、先ほど議論した課題に対応する設計プラットフォームを構築したり、必要な機能それぞれをモダナイズしたりすることができます。
この図に示されているように、デザイナーは最上位レイヤーで自身のデバイスからスタートし、プラットフォームを使用するために登録・認証されます。その後、高性能なストリームプロトコルを介してプラットフォームにアクセスし、デバイスを通じて作業を行います。
高性能なストリームプロトコルにより、デザイナーは Virtual Desktop を通じて作業を行い、割り当てられた権限に基づいてデータにアクセスし、設計作業を実施できます。黄色のボックスで強調表示された部分に注目していただきたいのですが、各グループのデザイナーが必要とするツールは異なる場合があります。つまり、管理者は共通の設計ツールを提供しながらも、ユーザーが生産性向上に必要な特定のツールをインストールできる柔軟な Virtual Desktop を提供する必要があります。
大規模なプラットフォームを管理し、各ユーザーの多様な VDI 環境に対応するためには、ユーザーの利便性を向上させる自動化の検討が不可欠です。そこで、管理者がプラットフォームのインフラ全体とユーザーアクセスを効率的に管理できる User Portal と Management Portal を導入しています。 AWS は独自のプラットフォームを構築するための包括的なサービスを提供しています。このセッションでは各サービスの詳細には触れませんが、主要なサービスをいくつかご紹介したいと思います。AWS はネットワークからコラボレーションツールまで、幅広いサービスを提供しています。データを費用対効果の高い方法で保存し、最新の GPU インスタンスで設計作業を加速することができます。
インフラストラクチャに加えて、AWS は VDI とユーザーを管理するための仮想化とオーケストレーションも提供しています。AWS Wickr を使用してプラットフォーム内で安全にコミュニケーションを取ることができます。これらのサービスの多くはマネージドサービスなので、ビジネス要件に応じて簡単かつ迅速にプラットフォームを構築できます。これらの包括的な AWS サービスを活用することで、 生産性を損なうことなく、セキュリティを強化し、大規模インフラストラクチャをサポートするマネージドサービスを活用したプラットフォームを構築することができます。この強力な組み合わせにより、現代の設計フローにおける複雑な要求に対応することが可能になります。
それでは、先ほど説明したさまざまなサービスで構成される設計プラットフォームのハイレベルアーキテクチャを見ていきましょう。このアーキテクチャは4つの主要レイヤーと分離された VPC で構成されています。まず下層から説明していきます。Data VPC があります。このレイヤーは、すべての設計データが費用対効果の高い方法で保存される場所として重要です。Computing VPC と DCV VPC 内でのみ、データへの認可されたアクセスが許可されます。デザイナーはプライベートネットワークを介して VDI に接続でき、VDI への接続時には AWS Directory Service がユーザーを認証し、権限を確認します。
これにより、特定のデータへのアクセスを認可された担当者のみに制限することができます。アーキテクチャの最上層には、チャット、メール、その他のデザインツールなど、外部パートナーソリューションを接続するためのもう一つのゲートウェイがあります。プラットフォーム全体を外部の脅威から保護するため、Firewallなどのセキュリティシステムを配置することができます。この階層型のアプローチにより、アクセシビリティ、機能性、セキュリティのバランスを保つことができます。 デザインプラットフォームを構築する際の最大の課題の一つは、ユーザーエクスペリエンスとパフォーマンスです。
Amazon DCVは、特に高解像度の品質が求められ、マウスの動きやクリックごとの応答時間に敏感な作業において、リモート環境からのデザイン作業を可能にします。Amazonは、デザイナーのこれらの重要なニーズに対応しながら、ログ記録、データ転送の制御、Directory ServiceやSingle Sign-onなどの他のシステムとの統合といった、エンタープライズグレードの導入に必要なセキュリティと様々な機能を提供しています。
ストリーミングのパフォーマンスをお見せするために、簡単なデモンストレーションを用意しました。このデモでは、韓国にある私のラップトップから約9,000キロメートル離れたOregonリージョンで、NVIDIA L4 GPUを搭載したAccelerating Computing Instanceを使用して、RDPとDCVの比較を行います。 画面でご覧いただけるように、いくつかの顕著な違いがあります。 解像度の品質の違いが分かります。さらに重要なのは、RDPプロトコルでのストリーミングにわずかな遅延が見られることです。
ここで明確にしておきたいのは、これはRDPが劣っているプロトコルだということではありません。実際、RDPは多くのシナリオでリモートデスクトップ接続に広く使用されています。このデモの目的は、3Dコンテンツや高解像度のグラフィックスのストリーミングには、Amazon DCVがより適していることを示すことです。最新のDCVをベースとしたこのプラットフォームを通じて、CADなどの3Dアプリケーションを使用したデジタルコンテンツの作成、エンジニアリングシミュレーション、さらには半導体設計まで、幅広いタスクを実行することができます。
Samsung ElectronicsのFAB設計・建設における挑戦
ここからは、デザインプラットフォームの実際の実装例についてご紹介したいと思います。スピーカーの方々を温かくお迎えください。Jimさん、ご紹介ありがとうございます。Samsung ElectronicsがどのようにしてデザインプラットフォームをAWS上に構築したかについて、その道のりをご紹介させていただきます。私は本プロジェクトのマネージャーを務めた Senior EngineerのYeongyu Hwangです。そして、プロジェクトリーダーを務めた同僚のPrincipal EngineerのDr. Changhee Parkも同席しています。Samsungチームには他にもTaekyun Kimをはじめ、本日参加できなかった協力者がいます。彼らは現在のプラットフォームの開発とテストに多大な貢献をしてくれました。
Samsung Electronicsについて簡単にご紹介させていただきます。DS Division（Samsung Semiconductor）は、スマートフォン、家電製品、データセンターサーバーなど、さまざまな電子機器向けの半導体チップを製造するグローバルビジネスユニットです。左側の写真は韓国にあるSamsung Semiconductorの本社キャンパスです。FABと呼ばれるこれらの工場では、SSDやDRAMなどのメモリーチップ、そしてAPやCPUなどの非メモリー製品を製造し、世界中の顧客にサービスを提供しています。 私たちは多くの国々にFABを建設し、1983年以来、半導体産業における主要サプライヤーとしての地位を確立してきました。2024年第1四半期のレポートによると、Samsung Semiconductorは世界の半導体生産の11%を担っています。
FABは、大規模建設プロジェクトの中でも最も複雑なものの一つです。ドバイのBurj Khalifaや、ソウルのDDPのような不規則な形状の建物は、設計・建設が非常に困難なことで知られています。このような建設プロジェクトを完遂できる建築・建設会社は限られています。同様に、FABの設計・建設も非常に複雑です。
多くの課題要因により、 FABの設計・建設は非常に複雑なだけでなく、チップ技術の進歩とともにその規模と性能要件も変化してきました。1983年には2,400ナノメートルの技術でチップが製造されていましたが、2020年までに3ナノメートル技術にまで進化しています。より高度な技術がチップ製造に使用されるようになるにつれて、このプロセスをサポートする建物への要件も厳格化しています。これにより、FAB建設にはより高度な設計手法の使用が必要となっています。
FABの設計・建設は複雑であるだけでなく、高度なセキュリティ環境下でFast-trackスケジュールで実施することで、多くの課題が生まれています。セキュリティの観点では、FABは国家安全保障レベルで運営されています。スケジュールに関しては、一般的なDesign-bid-build方式に従わず、新しいチップ技術が開発されるたびに頻繁な変更が必要となります。
Samsungは従来、設計・建設の管理にOn-premiseのITシステムを使用してきました。しかし、異なるステークホルダー間でData Siloが発生し、建設プロセスにおいて高コストな問題を引き起こすことがありました。この問題を解決するため、Data Lake概念を用いたAWSクラウドテクノロジーによる新しいアプローチが導入されました。これについて、プロジェクトリーダーのChanghee Parkが、AWSクラウドを使用した技術的詳細を説明いたします。
AWSを活用したSamsungの設計プラットフォーム構築の道のり
先ほど申し上げた通り、オンプレミスシステムにはいくつかの制限があり、これらの制限を克服するためにクラウド環境の利用を開始しました。これらの課題を解決するため、私たちのDesign Platformの開発journey についてご説明させていただきます。コンセプトの初期段階では、Design Platformの要件を定義しました。左の図に示すように、まず概念的な要件を定義しました：Data Siloの問題に対処するためのデータ統合、クラウド環境のためのネットワーク信頼性、重要な図面を扱うためのセキュリティ管理、そして場所を問わないプラットフォームへの容易なアクセスです。
これらの要件を実装するため、様々なベンダーテクノロジーの実装方向性について検討・評価を行いました。データ統合については、Autodeskなどのサービスを検討しました。図面用のパブリックSaaSソリューションは利用可能でしたが、私たちは安全なプラットフォームを作りたいと考えました。そこで、Autodeskを選択しつつも、セキュアな環境を使用して独自のソリューションを開発することにしました。ネットワークの信頼性については、3D図面などの大容量データを扱い、高負荷な要求に対応する必要があったため、堅牢なソリューションが必要でした。設計者と建設現場向けにPrivate Network Lineを実装し、VPN技術も併用しました。
セキュリティ管理については、オンプレミスのActive Directoryを統合しました。ユーザー情報は極めて重要で、正確なユーザーの特定、アクセスパターン、プラットフォーム上での活動を把握する必要があるためです。容易なアクセシビリティについては、AWS技術を採用し、Amazon DCVテクノロジーによる自動化された簡単なプロビジョニングを実現しました。
この図は、Design Platformの初期プロトタイプアーキテクチャを示しています。左の図に示すように、ローカル環境ではすべてのPCがデータセンターに配置され、ローカルBIMサーバーに接続され、インターネットから隔離されています。ローカルBIMサーバーでは、図面やデータの利用が制限されていました。これらの制限を解決するため、右の図に示すようなセキュアなクラウドアーキテクチャを設計しました。ローカルクライアントはまずAmazon VDIを使用してグラフィックVDIにアクセスし、これがAmazon FSxサーバーに接続します。これらのFSxサーバーは、パイプラインを通じてAutodeskサーバーと接続され、データは毎日転送されてWeb版に変換され、即時利用が可能になります。この設定により、図面やデータの利用率が向上し、ローカル環境と比較して大幅に改善された環境を実現しています。
POCステージからプラットフォームのアーキテクティングと最適化まで、段階的なプラットフォームのjourneyについて説明させていただきます。POCステージでは、複雑なCADアプリケーションのユーザー体験とパフォーマンスのエミュレーションに焦点を当てました。ワークステーションは非常にリソース集約的であるため、クラウド環境でエミュレートされた体験を作り出すことは大きな課題でした。アーキテクティングとプラットフォームのステージでは、ユーザー体験の高いパフォーマンスを維持しながら、セキュリティ要件を満たしているかを継続的に検証しました。これらの要件を満たすため、プロトタイピングを繰り返し行いました。検証後は、セルフサービスシステムの実装、プロセスの自動化、コスト削減とネットワーク安定性のためのリソース最適化により、運用を最適化しました。
POCの段階では、デザイナーの体験が最も重要でした。当初、デザイナー体験の側面は十分に文書化されていなかったため、マウスの動き、キーボード操作、レスポンス時間、データ転送速度など、さまざまなアプリケーションの操作を慎重に記録しました。これらの記録された体験がVDIのパフォーマンス基準となりました。ローカル環境での基準を確立した後、VDIのパフォーマンスを評価しました。その際の重要な要件は、設計作業のパフォーマンスとレスポンス時間がローカル環境と同等であることでした。さらに、企業のコンプライアンス要件を満たすためのセキュリティ機能も実装しました。アーキテクチャの段階を通じて、コーポレートセキュリティ基準を維持しながら、コンプライアンスと要件を確実に満たす必要がありました。
右側に示すプロトタイピングプラットフォームを見ると、まずVPCとクラウドゾーンを確立することから始めました。右下にグラフィックVDIを設置し、その下部に他のVDIシステムを配置しました。その上にVPCゾーンを設け、Pサーバーやライセンスサーバーなど、VPC管理に必要な管理コンポーネントを配置しました。
その上に、FirewallやSIEMシステムなどの追加のセキュリティレイヤーを実装し、インターネットトラフィックの出入りを制御してプラットフォームを安全にしました。この右側の図は私たちのプラットフォームのプロトタイピングアーキテクチャを表しており、左側はユーザーのアクセス方法を示しています。ユーザーは、AWS Direct ConnectまたはVPNを通じて私たちのプラットフォームに接続できます。プロトタイピングフェーズを完了した後、 要件を満たすパフォーマンスが確認できたため、プラットフォームの最適化を開始しました。
ここに示すように、カスタムポータルを実装し、ユーザーはまず本人確認を行い、設計環境を選択します。情報が正しいことの承認を受けた後、VDIはカスタムポータルを通じて自動的にプロビジョニングされます。カスタムポータルはバックエンドのすべてのデプロイメントツールを管理し、FSxなどのネットワーク設定もバックシステムに組み込まれています。その後、3番に示すように、ユーザーは設計プラットフォームに直接接続でき、すべての手順をセルフサービスで行えます。4番で示すように、リソースとユーザー管理のための管理者ポータルも構築しました。5番については、限られた予算でこのシステムを運用する必要があるため、管理者ポータルにコスト管理機能を実装しました。
このスライドは、設計プラットフォームの最終的なアーキテクチャを示しています。右下にグラフィックVDIがあり、その上に自動化されたVPC、そしてカスタムポータルなどのオンプレミスコンポーネントがあります。最上部のセキュリティレイヤーには、FirewallやSplunkなどのSIEMサーバーが含まれています。インターネットに面していますが、OktaやAutodeskなどの指定されたソリューションに対してのみ、強力な制御によってアクセスが制限されています。これが私たちの最終的なアーキテクチャ設計であり、左側のベンダー（デザイナー、クライアント、建設会社を含む）は、Direct ConnectまたはVPNを使用してクラウドに直接接続できます。この完全なプラットフォームにより、AWSインフラストラクチャ上でのSamsung FAB建設における設計革新とセキュリティの堅牢性の両立を目指して、2024年に私たちのシステムを本格展開しました。 それでは、設計プラットフォームの主要な機能を示す画像をご覧いただきましょう。
左側の図にあるように、これらがDCV Clientの画面です。プラットフォームにアクセスするユーザーはこれを使って情報を入力し、入力が完了すると右側の図のようにプラットフォーム内部を閲覧できるようになります。事前に設定された全ての構成を含むソフトウェアを入手でき、すぐにデザインレビューを開始することができます。ここで最も重要なのは、リモートデザインの概念を採用していることです。先ほど申し上げたように、以前はWorkstationの概念を使用していましたが、このデザインコンセプトは一般的なPCのような限られたリソースのローカルデバイスでも実装でき、このような環境でWorkstationとほぼ同様の体験を得ることができます。
このデザインプラットフォームについて、さらに詳しくご説明いたします。まず、オンプレミスのActive Directoryをプラットフォームに統合しています。ユーザーがSamsung ADに参加すると、そのユーザー情報がクラウドプラットフォームに同期されます。ユーザー情報はSaaSなどのアプリケーション層に提供されます。オンプレミスADとプラットフォームを接続し、同期のための別のIDP Solutionを採用することで、このシステムだけでなくSaaSシステムでも全ての情報を一貫して使用できます。これにより、両システムのユーザープロビジョニングを同期および自動化することができます。ここで右側にお示ししているように、Samsungシステムでプロジェクトにユーザーを追加すると、Autodeskのライセンスもあわせてプロビジョニングされます。
次に、先ほど申し上げたように、グラフィックVDIとSaaSアカウントの自動プロビジョニングが可能になりました。AMIテンプレートイメージごとのグラフィックVDIとは、全てのイメージパッケージがAMIイメージにインストールされ、保存されているということです。これらのAMIイメージは、デモでお見せするSelf-serviceポータルシステムによって提供されます。SaaSアカウントは、OktaなどのIDPベンダーとAutodeskプロバイダー間のユーザー同期を通じて自動的にプロビジョニングされます。
ユーザーがこのポータルにアクセスした時点では、VMは何も持っていません。現時点ではVMは利用できませんが、新しいVDIアプリケーションを申請することができます。ユーザーは情報と理由を記入し、先ほど申し上げたように、右下でVDIテンプレートを選択します。AD情報を把握しているため、選択したVDIイメージが利用可能になっています。選択後、リクエストの承認を申請します。その後、バックエンドでクラウドシステムがツールをプロビジョニングします。承認後、左側の画面がIPアドレスとともに変更され、青いボタンをクリックするとDCV ClientでVDIに接続します。
DCVにアクセスすると、右側に示されているように、AMIイメージを使用しているため、AutoCADやRevitなどの図面作成用の事前パッケージ化されたソフトウェアが全て含まれています。また、SaaSも提供されているため、レビューも開始できます。これがデザインプラットフォームとデモの全体的なコンセプトです。
設計プラットフォームの機能と今後の展望
3番目は新しいコンセプトを紹介します。SaaSソリューションを活用することで、Webベースの図面作成とデータモデリングが可能になります。この設計データをWeb形式に変換するという点で、ローカル環境とは大きく異なります。
このWeb形式にデータをエクスポートすることで、ローカルファイルだけでなく、他の形式でも利用できるようになります。データをデータベースに保存し、CSVファイルとして抽出することも可能です。これにより、工程管理や工事見積もりなどの他のモジュールとデータを連携させることができます。さらに、将来的にはAIモデルがこのデータから学習し、図面を解釈して、自然言語で図面を理解できるChatbotのような革新的なサービスを提供することも可能になります。
設計プラットフォーム全体の管理はAdmin Portalを通じて行います。ご覧の通り、設計プラットフォーム上のユーザー数、VDI数、プロジェクト数などを監視することができます。セキュリティ監視については、SIEM（Security Information Event Management）を適用しています。すべてのユーザー情報はSIEMサーバーで収集・分析されます。不審なアカウント活動が検出された場合は報告され、プラットフォームへのアクセスを制限することができます。
設計プラットフォームにAWSを使用することの利点は3つあります。第一に、グラフィック処理の負荷の高いワークロードへの対応が可能になりました。先ほど述べたように、私たちのワークロードはかなり大きいのですが、G4dnインスタンスとDCVクライアントを使用することで、重いグラフィックワークロードの処理に最適化されています。第二に、APIによるプラットフォームインフラの管理により、きめ細かな制御が可能になり、プラットフォームの完全な自律制御が実現しました。第三に、専用のセキュリティ制御オプションにより、設計図面をクラウドに置いた場合でもコンプライアンスを維持しながら、堅牢なセキュリティを確保できます。
FAB設計プラットフォームの次のフェーズも、引き続きAWS上で開発を進めていきます。G4インスタンスよりも高速なG6インスタンスなど、より新しいインスタンスもあるため、パフォーマンスの最適化を継続していきます。私たちの夢は、ローカル環境よりも高速なプラットフォームを実現することです。また、膨大な量のデータを人間が扱うのは非常に煩雑なため、AIの統合も進めていきます。アルゴリズムを統合することで、データを簡単に解釈し、適切なタイミングで意思決定に必要な情報をステークホルダーに提供できるようになります。最後に、コスト最適化も継続して行います。クラウドプラットフォーム環境は安価ではありませんが、ワークステーションも同様です。将来的には多くのユーザーが私たちのプラットフォームにアクセスして利用できるよう、クラウドのコストを効率化していきたいと考えています。
ご覧いただいたように、これは決して単純なタスクではありませんでした。強固なセキュリティを確保しながら、自動化を適用して高品質なユーザーエクスペリエンスを提供するなど、克服すべき大きな課題がありました。しかし、これらの複雑さにもかかわらず、FAB建設における現行の設計フローを革新するためには、クラウドテクノロジーを活用した設計プラットフォームの構築が不可欠でした。 AWSは、ユーザーとオペレーター双方に向けた幅広いソリューションを提供し、設計プロセスを加速するプラットフォームの構築を支援しています。このセッションが、皆様の課題解決の一助となり、より良い取り組みにつながることを願っています。 ご清聴ありがとうございました。また次回のセッションでお会いできることを楽しみにしております。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion