Category: Compute

本日のAWS re:Invent 2019にて、AWS Fargate Spotを発表します。Fargate SpotはAWS Fargateの新しい機能です。中断に強いAmazon Elastic Container Service (Amazon ECS)タスクに最適であり、Fargate価格から最大70%割引で提供します。 もしEC2スポットインスタンスを知っていれば、同様のコンセプトで理解できます。Fargate Spotは、AWSクラウドの空きキャパシティを活用してタスクを実行します。Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動することができます。AWSにキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されることになります。Fargate Spot用のキャパシティが使用できなくなると、Fargateは稼働中の通常のタスクを保持しながら、Fargate Spotで稼働するタスクをスケールダウンします。 タスクが中断される可能性があるという特性から、中断が許容できないワークロードをFargate Spotで稼働させるべきではありません。一方で中断耐性のあるワークロードに対しては、コスト最適化に大きく貢献します。 Fargate Spotは特に画像のレンダリング、モンテカルロシミュレーション、ゲノム解析といった並列度の高いワークロードに適しています。また高可用性を求められるウェブサイトやAPIサーバーのように、ECSサービスの一部となるタスクに対してもFargate Spotを適用することができます。 クラスター定義を作成・更新する際、常時稼働させるべき最低限のタスク数を指定し、さらに性能向上を狙いとするタスクをコスト効率の良いFargate Spot上で稼働するように構成することができるようになります。サービス定義のService Auto Scalingを利用することで、Fargate Spot用のキャパシティが使用可能になり次第、リクエストを満たすようにスケジューラーがタスクを起動し、Fargate Spot用のキャパシティが使用できなくなると、前述の通り先に指定した常時稼働タスクを保持しながら、Fargate Spotで稼働するタスクがスケールダウンする、という動作を実現することもできます。 AWS Fargate Spotの開始方法を見ていきましょう。 まずECSマネジメントコンソールより、新規のECSクラスターを作成します。Fargate起動タイプを選択するため、ここでは”Networking only”を選択し、ウィザードを進めます。 クラスターが作成されたらば、”Capacity Providers”タブからキャパシティプロバイダーを追加します。デフォルトではFARGATEとFARGATE_SPOTの2種類のキャパシティプロバイダーが用意されています。 キャパシティプロバイダーとしてFARGATE_SPOTを用いるのに、まずデフォルトのプロバイダーをFARGATE_SPOTに変更します。”Update Cluster”ボタンをクリックし、次の画面で”Add provider”をクリックしてFARGATE_SPOTを追加し、Updateボタンを押します。 続いて、これまでのようにタスクを起動します。事前に設定済みのタスク定義から、10のタスクを指定し、また”VPC and security groups”セクションでVPC関連の必要情報をセットしたのちに”Run Task”をクリックします。 起動された10個のタスクは、通常のFargate環境ではなくFargate Spot環境が選択されています。あるタスクをクリックしてみると、実際にキャパシティプロバイダーとしてFARGATE_SPOTが使用されたことがわかります。 ここまで、Fargate Spotの開始方法を紹介してきました。ぜひお手元でも試してみてください。 数週間前にCompute Savings Plansをリリースしました。FargateはCompute Savings Plansの一部に含まれます。さらにここでFargate Spotが登場したことより、費用の大幅な効率化とともに、様々な種類のアプリケーションへの一層の活用が期待できます。いま、Fargateを使うのにまたとないチャンスが訪れていると言えるでしょう。 […]

昨年のre:Invent 2018では、ArmベースのGravitonプロセッサ搭載の初代EC2インスタンス(A1)を発表しました。以来、コンテナ化されたマイクロサービス、ウェブサーバー、ログ等のデータ処理といったスケールアウト型のワークロードに対して、何千もの顧客がA1インスタンスを活用しています。 ArmアーキテクチャとA1インスタンスは早期の段階から、OSベンダー、ソフトウェアベンダー双方のコミュニティの強い協力を得られています。今やA1インスタンスに対して、Amazon Linux 2, Ubuntu, Red Hat, SUSE, Fedora, Debian, FreeBSDといった複数のLinux/Unixディストリビューションを選択できます。 さらに稼働させるサービスとしてDocker, Amazon ECS,  Amazon Elastic Kubernetes Serviceといったコンテナサービスを選択できますし、他にも多くのシステムエージェントや、AWS Developer ToolsやJenkinsを始めとする様々な開発ツールも動作します。 これまでにA1インスタンスに寄せられたフィードバックは強力かつポジティブなものばかりで、特にCPUインテンシブあるいはメモリインテンシブなワークロードをどんどんArmベースのサーバーで稼働させていきたいという声を受け取っていました。 Graviton2 本日、次世代のARMベースのEC2インスタンスの登場を先行発表します。このインスタンスはAWS Nitro Systemをベースに、新しいGraviton2プロセッサを搭載したものです。このプロセッサは7nm(ナノメートル)製造プロセスによるAWS独自設計によるもので、64ビットARM Neoverseコアをベースとして、浮動小数点演算処理の2倍の性能向上を含め、最大でA1インスタンスの7倍の性能を発揮するものです。また追加のメモリチャネルと1コアあたり倍加したキャッシュにより、メモリアクセス速度は最大で5倍まで向上しました。 これらの改良は、これまでのM5, C5, R5といった第5世代のインスタンスタイプを上回る、極めて大きな性能向上をもたらします。vCPUあたりの性能をM5インスタンスと比較したとき、初期のベンチマーキングでは次のような結果が得られました。 SPECjvm® 2008: +43% (推定) SPEC CPU® 2017 integer: +44% (推定) SPEC CPU 2017 floating point: +24% (推定) NginxでのHTTPSロードバランシング: +24% Memcached: +43% かつレイテンシの短縮 X.264ビデオエンコーディング: +26% Cadence XcelliumによるEDAシミュレーション: […]

社会人になったばかりの頃、開発チーム向けのOSイメージビルドの仕事がアサインされたのを今でも思い出します。時間はかかるし、エラーはよく出るし、再作成とスナップショット再取得をなんども実行する必要がありました。さらに、ご想像のとおり、そのあとには大量の手動テストが控えていたのです。 OSを最新に保つことの重要性は現在も変わりません。場合によっては自動化スクリプトを開発してくれるチームがあるかもしれませんが、いずれにせよVMのスナップショットを手動で取得するという作業は、多くのリソースを消費し、都度エラー対処が要求される、時間のかかる作業であることに変わりはありません。今日ここで、EC2 Image Builderを発表できることを大変うれしく思います。これは、自動化されたビルドパイプラインによる、簡単、かつ高速にセキュアなWindows ServerおよびLinux OSイメージをビルドし保守していくためのツールです。EC2 Image Builderで作成されたイメージは Amazon Elastic Compute Cloud (EC2)で用いることができ、また満たすべき情報セキュリティ基準を遵守できるよう、セキュリティを強化することができます。今後AWSは規制を受ける業界向けに、はじめの一手として使える“Security Technical Implementation Guide (STIG – セキュリティ設定チェックリスト)”に準拠したセキュリティ強化ポリシーを提供していきます。 EC2 Image Builderパイプラインに含めることのできる設定項目は、OSイメージのレシピ、基盤の構成、イメージの配布先、それからテスト構成です。さらに、セキュリティパッチを含むソフトウェアアップデートに応じて、イメージビルドを自動実行する機能も含まれます。パイプラインにより新たなイメージが作成されたタイミングで、各AWSリージョンにイメージを配布する前に検証すべきテストの自動実行を設定することもできます。またEC2 Image BuilderをEC2 VM Import/Export機能と併用することで、オンプレミスに存在するVMDK, VHDX, OVFそれぞれのフォーマットからなるVMイメージと連携することができます。自動テスト機能ではAWS提供のテストとユーザー定義のテストを組み合わせることもできます。 それでは、EC2 Image Builderの開始方法を見ていきましょう。 OSイメージビルドパイプラインの作成 AWSマネジメントコンソールのサービス一覧からEC2 Image Builderを選択し、EC2 Image Builderマネジメントコンソールに進みます。ここで”Create Image Pipeline”ボタンをクリックします。今回はAmazon Linux 2イメージをカスタマイズしてビルドすることにします。はじめの一歩はソースになるOSイメージを選択し、イメージに適用するビルドコンポーネントを指定し、実行するテストを構成するレシピを定義するところからです。 OSソースイメージの選択では、EC2 Image Builderの提供するAWS管理のイメージを選択しました(“Select managed images”).  この手順では他にも、自分で作成したAMIや共有されたAMIを選択することもできます。AMI IDを直接指定することができます。 “Browse images”ボタンを押すとAWS管理のイメージを選択する画面が開きます。イメージを選択するには、OS名のボックス右上のラジオボタンをクリックします。 続いてイメージに適用するビルドコンポーネントを指定します。これはインストールすべき追加ソフトウェアを指定する手順です。ウィザードの”Create build component”をクリックすると、ユーザー定義の新しいビルドコンポーネント作成のためのオプションを指定することができます。新規にビルドコンポーネントを作成するには、ビルドコンポーネントの名前(と説明書き), OS種別、コンポーネント暗号化のためのAWS Key […]

ほぼ10年前、エイプリルフールの日にQuantum Compute Cloudについて書きました。未来が到来し、量子アルゴリズムを作成して実際の量子コンピューターで実行する機会が得られました。本日発表する内容は次のとおりです。 Amazon Braket –科学者、研究者、開発者が1か所で複数の量子ハードウェアプロバイダーのコンピューターで実験を開始できるようにする完全に管理されたサービスです。サービスの名称は、一般に量子力学的な状態を示すために使用されるブラケット表記にインスパイアされました。 AWS量子コンピューティングセンター – カリフォルニア工科大学（Caltech）に隣接する研究センター。世界をリードする量子コンピューティングの研究者とエンジニアを集めて、量子コンピューティングハードウェアとソフトウェアの開発を加速します。 Amazon Quantum Solutions Lab – AWSの顧客をAmazonの量子コンピューティングの専門家と非常に厳選されたコンサルティングパートナーのセットと結びつける新しいプログラムです。 量子コンピューティングとは 通常の（古典的な）コンピューターは、ビットのコレクションを使用して状態を表します。各ビットは明確に0または1であり、nビットがある場合、可能な状態の数は2 ^ nです。1ビットは2つの状態のいずれかになり、2ビットは4つの状態のいずれかになります。1 MiBのメモリを搭載したコンピューターには、CPUレジスタと外部ストレージを除く2つの状態（8 * 1048576）があります。これは大きな数ですが、有限であり、計算できます。 量子コンピューターは量子ビット(qubit)と呼ばれるより洗練されたデータ表現で状態を記述します。各量子ビットは状態1または0に存在できますが、1と0の重ね合わせにも存在できます。つまり、量子ビットは両方の状態を同時に占有します。このような状態は、1組の複素数を含む2次元ベクトルによって指定でき、無限の数の状態になります。各複素数は確率振幅であり、基本的に量子ビットがそれぞれ0または1である確率です。 古典的なコンピューターは、特定の時間にそれらの2 ^ n状態のうちの1つだけになることがありますが、量子コンピューターはそれらすべてを並行して占有できます。 長期間ITに携わっていたなら、ムーアの法則によって、私がこれを書いているように2テラバイトをサムドライブに保存するメモリチップを製造できるようになったことを知っています。これを可能にする物理的および化学的プロセスは驚くべきものであり、研究する価値があります。残念ながら、これらのプロセスは量子ビットを含むデバイスの製造には直接適用されません。私がこれを書いているとき、最大の量子コンピューターには約50量子ビットが含まれています。これらのコンピューターはいくつかの異なる技術で構築されていますが、共通する2つの属性があるようです。それらは希少であり、慎重に制御された物理環境で実行する必要があります。 動作方法 量子コンピューターは、状態ベクトルの振幅を操作することにより動作します。量子コンピューターをプログラムするには、必要な量子ビット数を把握し、それらを量子回路に配線して実行します。回路を構築するとき、正しい答えが最も可能性の高いものであり、残りのすべてが非常にありそうもないようにそれを設定します。古典コンピューターはブール論理を使用しないで使って構築され、OR、およびANDゲートに対し、量子コンピューターは、重ね合わせとの干渉を使用し、使用して構築されている量子論理ゲートを、新しいとエキゾチックな名前（X、Y、Z、CNOT、アダマール、トフォリなど）で構成します。 中期暗号化とデータ保護を検討する際には、これを念頭に置く必要があります。また、ポスト量子暗号について知る必要があります。現在、s2n（TLS / SSLプロトコルの実装）には、すでに量子耐性のある2つの異なるキー交換メカニズムが含まれています。新しい暗号化プロトコルが広く利用可能になり安全に使用できるようになるには約10年かかることを考えると、大規模な量子コンピューターが利用可能になる時期を先取りするのに早すぎるということはありません。 量子コンピューティングは今日主流ではありませんが、その時が来ています。これは、古典的に解決することが困難または不可能な特定の種類の問題を解決できる非常に強力なツールです。40年または50年以内に、量子コンピューターで実行されるサービスを使用して、多くのアプリケーションが部分的に機能するようになると思います。そのため、GPUまたは数学コプロセッサーのように考えるのが最善です。それらは単独では使用されませんが、ハイブリッド古典/量子ソリューションの重要な部分になります。 私たちの目標は、いくつかの適切なユースケースを探しているあなたに、いくつかのテストや実験を行う開始する量子コンピュータについて十分に知っているようにすることです。私たちは、現実にしっかりと根ざした強固な基盤を構築し、あなたと協力して、量子の力を活用した未来に移行したいと考えています。 Amazon Braket この新しいサービスは、量子ビットと量子回路を実際に体験できるように設計されています。シミュレーション環境で回路を構築およびテストしてから、実際の量子コンピューターで実行できます。Amazon Braketは完全に管理されたAWSサービスで、各レベルでセキュリティと暗号化が組み込まれています。 ノートブックスタイルのインターフェースを介してAmazon Braketにアクセスできます。 PythonコードはAmazon Braket SDKを利用します。1行のコードで量子回路を作成できます（これは、私の同僚によると、「量子ビット0と量子ビット1が最大にもつれた (エンタングルした) ベル状態」とのこと）。 bell = Circuit().h(0).cnot(0, 1) そして別のものでそれを実行します： print(device.run(bell, s3_folder).result().measurement_counts()) 古典計算機の力を借りたシミュレーション環境に加えて、Amazon Braketがアクセスを提供するD-Wave、IonQ、およびRigettiの量子コンピュータがあります。これらのデバイスにはいくつかの共通点があります：最先端の技術であり、構築と実行に費用がかかり、通常、電気のない状態に保つ必要がある非常に極端で特殊な環境（過冷却または真空に近い）で動作します。まとめると、ほとんどの組織が量子コンピューターを所有することは決してなく、クラウドベースのオンデマンドモデルの方が適していると考えています。プロダクション規模の量子コンピューターが最初はクラウドのみのテクノロジーである場合もあります。 実際の量子コンピューターは芸術作品であり、いくつかのクールな写真を共有できることを嬉しく思います。D-Wave 2000Qは次のとおりです。 The Rigetti 16Q Aspen-4： そして、IonQリニアイオントラップ： AWS量子コンピューティングセンター […]

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

みなさんこんにちは！アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第１回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは？」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは？ このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです（同じビルなので移動が楽！）。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう！   著者について 木村 公哉（Kimura, Koya） 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠（Uehara, Makoto） アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください（なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください）。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール（ブラウザプラグインなど）を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

本記事は AWS のシニアソリューションアーキテクトの Sirirat Kongdeeによる寄稿記事です。 Amazon CloudWatch を利用することで、Amazon Elastic Container Service（Amazon ECS）のリソースを監視することができます。Amazon CloudWatchは、CPU やメモリの割り当てについてや、クラスター、サービスレベルでのリソース使用率のメトリクスを提供するサービスです。以前は、サービスとタスクについてカスタムモニタリングを有効にする必要がありましたが、CloudWatch Container Insightsを使用することで、すべての Amazon ECS リソースの監視、トラブルシューティング、アラームの設定を行うことができるようになりました。これはフルマネージド型のサービスであり、Amazon ECSのメトリクスとログを収集、集約、要約することが可能となります。

 分散型機械学習 (ML) ワークロードの実行に関しては、AWS はマネージドサービスとセルフサービスサービスの両方を提供しています。Amazon SageMaker は、エンジニアリング、データサイエンス、および研究チームが時間を節約し、運用オーバーヘッドを削減できるマネージドサービスです。AWS ParallelCluster は、コンピューティングインフラストラクチャをより直接的に制御したいお客様向けのオープンソースのセルフサービスクラスター管理ツールです。この記事では、AWS で分散 ML を実行する方法について説明します。Amazon SageMaker を使用した分散トレーニングの詳細については、以下の「Horovod を使用した TensorFlow 分散トレーニングの起動」と「マルチリージョンサーバーレス分散トレーニング」の記事を参照してください。 AWS ParallelCluster は、AWS クラウドでのハイパフォーマンスコンピューティング (HPC) クラスターのデプロイと管理に役立つ、AWS がサポートするオープンソースのクラスター管理ツールです。AWS ParallelCluster を使用すると、データサイエンティストと研究者は、必要なコンピューティングリソースと共有ファイルシステムを自動的にセットアップすることで、伸縮自在にスケーリングされた AWS リソースで使い慣れた作業環境を再現できます。Jupyter、Conda、MXNet、PyTorch、TensorFlow などの広くサポートされているデータサイエンスおよび ML ツールにより、低オーバーヘッドのスケーリングによる柔軟でインタラクティブな開発が可能になります。これらの機能により、AWS ParallelCluster 環境は、分散モデルの開発とトレーニングをサポートする ML 研究環境に最適です。 AWS ParallelCluster は、コンピューティングリソースのオンデマンド割り当てを中心に構築されたスケーラブルな研究ワークフローを可能にします。AWS ParallelCluster は、単一のハイパワー GPU 対応ワークステーションで作業し、潜在的に十分に活用するのではなく、GPU 対応コンピューティングワーカーのオンデマンドフリートを管理します。これにより、並列トレーニング実験の簡単なスケールアップと、リソースが不要な場合の自動スケールダウンが可能になり、コストを最小限に抑え、研究者の時間を節約できます。アタッチされた Amazon FSx ファイルシステムは、開発中に従来の高性能 Lustre ファイルシステムを利用しますが、モデルとデータを低コストの Amazon S3 にアーカイブします。 次の図は、AWS ParallelCluster ベースの研究環境を示しています。自動スケーリングされた Amazon […]