re:Invent 2024: AWSのAI/ML向けハイパフォーマンスストレージS3とFSx
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - High-performance storage for AI/ML, analytics, and HPC workloads (STG327)
この動画では、Amazon S3のSenior Software Development ManagerのGeorge LewisとAmazon FSx for LustreのGeneral ManagerのAndrew Crudgeが、AI/ML、Analytics、HPCワークロード向けのハイパフォーマンスストレージについて解説しています。Amazon S3とFSx for Lustreの特徴や使い分け、パフォーマンス最適化の方法を詳しく説明し、特にS3 Express One Zone Directory Bucketの700Gbps以上の帯域幅や、FSx for LustreでのElastic Fabric Adapter（EFA）サポートによる最大1200Gbpsのスループットなど、最新の技術進展にも触れています。また、ShellやLG AI Researchなどの実際の導入事例を交えながら、ファイルベースとオブジェクトベースのストレージソリューションの選択基準や、それらを組み合わせた効果的な活用方法を紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
ハイパフォーマンスストレージの概要と重要性
こんにちは。私はAmazon S3のSenior Software Development Managerを務めるGeorge Lewisです。本日は、Amazon FSx for LustreのGeneral ManagerであるAndrew Crudgeと共に、AI/ML、Analytics、そしてHPCワークロード向けのハイパフォーマンスストレージについてお話しさせていただきます。ファイルベースとオブジェクトベースの両方のハイパフォーマンスストレージについて説明し、それらを比較検討しながら、皆様のワークロードに最適なハイパフォーマンスストレージソリューションの選択をサポートしていきます。
まずは、ハイパフォーマンスワークロードとは何かについてお話ししましょう。大規模なAIモデルのトレーニングや、高頻度取引のアルゴリズムとリスク分析、あるいはリアルタイムのメディアコンテンツ生成など、その本質は、極めて大規模なデータセットへの高速アクセスを必要とするプロセスやアプリケーションです。このアクセスは通常、並列処理が可能で、低レイテンシーであることが求められます。
これらのワークロードは、時間とともに指数関数的に成長する、ますます大規模化するデータセットによって拡大を続けています。この成長を後押ししているのは、より大きなデータセットを処理し、強力な推論を可能にする、特に目的に特化したGPUやAIチップセットなど、最新のコンピューティング技術の進歩です。私たちのアルゴリズムやディープラーニング技術は、ここ数年で大きく進歩し、豊富なデータセットから、これまでは見過ごされていた推論を抽出できるまでになりました。これらのワークロードと大規模データセットの重要なポイントは、標準的なストレージソリューションを限界まで押し上げ、適切なパフォーマンスを提供するために継続的なイノベーションを必要とすることです。
ハイパフォーマンスワークロードにおけるストレージの役割
先ほど申し上げたように、このセッションの焦点は、ファイルソリューションとオブジェクトソリューションに当てられています。ハイパフォーマンスワークロードを見ると、通常、数十、数百、あるいは数千の計算用インスタンスやGPUインスタンスが同時に共通のタスクを実行するようなワークロードです。これらのソリューションでは、通常、ローカルNVMeドライブやEBSボリュームのようなローカルストレージではなく、ネットワーク接続型のファイルストレージやオブジェクトストレージなどの共有ストレージが使用されます。
ハイパフォーマンスワークロードを見ると、ストレージの使用方法にはいくつかの一般的なパターンがあります。まず第一に、これらのワークロードの多くは、保存されたデータの処理に依存しています。分析、要約、あるいはモデル構築の対象となる特定のデータセットから始まります。最初のステップは、そのデータを計算用インスタンスやGPUインスタンスにロードすることです。各インスタンスのローカルストレージにデータをコピーする場合もありますが、最も一般的なのは、ワークロードの実行中に共有ストレージソリューションから直接データをストリーミングする方法です。
私たちが見ている2つ目のユースケースは、Checkpointingです。概して、Checkpointingとは、ワークロードの実行中に定期的に（おそらく数分ごとに）モデルの状態を取得し、そのモデルをストレージに書き込むことを意味します。これが重要な理由は、数百から数千のインスタンスを持つコンピュートクラスターで、そのうちの1つのインスタンスに障害が発生した場合、Checkpointがあれば、故障したインスタンスを新しいものと交換した後に、最後のCheckpointから作業を再開できるからです。Checkpointがない場合、多くの場合、ワークロードを最初からやり直す必要があります。
ご想像の通り、特にノード数の多い大規模なコンピュートクラスターでは、時間とともにCheckpointingの必要性が高まります。これらのCheckpointの書き込み中はアプリケーションが一時停止されることが多いため、Checkpointをできるだけ早く書き込み、素早く読み戻せることが、コンピュートインスタンスの障害後のワークロード再開を迅速に行う上で非常に重要になります。最後に、ほとんどのジョブの終了時には、出力レポートやモデルなどの何らかの結果データセットがストレージに書き込まれます。高性能ワークロードについて、このセッションで特に注目するのは、最初の2つのユースケース、つまりデータのロードとCheckpointingです。これらは、ストレージに対して最も厳しいパフォーマンス要件を持つためです。
Amazon S3の特徴とデータレイクでの活用
パフォーマンスと言えば、なぜストレージのパフォーマンスが重要なのでしょうか？ お客様からよく耳にするのは、AWSでは大規模なコンピュートクラスターを簡単に立ち上げ、他では実現できないような速度でワークロードを実行し、終了後にそれらのリソースの支払いを止められることが素晴らしいという声です。理想的には、クラスターに追加するコンピュートインスタンスが多いほど、 ワークロードの実行が速くなります。理想的な世界では、これはクラスターのサイズにほぼ比例してスケールします。
時々直面する課題は、パフォーマンスに最適化されていない、あるいは特定のワークロードに必要なパフォーマンスを提供できないストレージソリューションを使用しているお客様の場合です。そのようなストレージソリューションがボトルネックとなり、結果としてワークロードのパフォーマンスが一定のレベルを超えてスケールできなくなることがあります。これは、望むような速さで結果を得られないか、CPUやGPUリソースが十分に活用されていないことを意味する可能性があります。GeorgeもPrivateも常にストレージのことを考えているストレージの専門家ですが、実際のところ、これらのワークロードではコンピュートが最も価値のあるリソースです。通常、これらの高性能ワークロードの支出の90〜95%はストレージではなく、コンピュートインスタンス自体にかかっています。
これらのワークロードにおけるストレージの役割を考えると、私たちがストレージ側で本当に最適化しているのは、ストレージが十分に高速で考慮する必要がないようにすること、つまりGPUやCPUが十分にデータを供給され、実際にプロビジョニングしたコンピュートリソースの限界がボトルネックとなるようにすることです。 高性能ワークロード向けのストレージソリューションの選択について、お客様との対話の中で見えてくる重要な考慮事項が3つあり、これらについてはプレゼンテーションの中でさらに詳しく説明していきます。1つ目はプロトコル、つまりデータへのアクセス方法です。私たちが話すお客様の多くは、特定の方法でデータにアクセスするように作られた既存のツール、アプリケーション、環境を持っており、新しいワークロードを構築する際も、同じ方法でデータにアクセスし続けられるようにすることが重要です。
2番目はスループットです。スループットは一般的に、ストレージに対して1秒間に読み書きできるバイト数で測定されます。高性能ワークロードのスケールでは、通常ギガバイトやテラバイト/秒単位になります。これがスループットの1つの単位です。もう1つの一般的な単位は、小さなファイルやオブジェクトを多く扱うワークロードで使用される、1秒あたりのトランザクション数や操作数です。最後の考慮点はレイテンシーで、これはストレージソリューションに対して小さな操作を実行する際のラウンドトリップ時間のことです。Amazon S3の場合、レイテンシーについて語る際は、多くの場合「ファーストバイトレイテンシー」、つまりS3がデータの提供を開始するまでの時間について言及します。
レイテンシーが重要な理由は2つあります。1つ目は、ワークロードの同時実行性に応じてスループットやIOPSに影響を与える可能性があるためです。2つ目は、ストレージソリューションの応答性の指標でもあるためです。私たちがお客様と協力して取り組むワークロードの多くは、大規模なコンピュートクラスターが大量のデータを処理する一方で、そのデータをエンドユーザーや研究者が操作して作業するというコンポーネントを持っています。特にこのような人間が介在するユースケースでは、ストレージの高速性と応答性がエンドユーザーにとって非常に重要になります。
Amazon S3のパフォーマンス最適化戦略
高性能ワークロードの構築や実行を検討しているお客様と協力する際、通常2つのパターンが見られ、このプレゼンテーションではそれぞれについて詳しく見ていきます。1つ目は、主にAmazon S3に大量のデータを保存している既存のお客様です。S3上にData Lakeを持っており、そのデータを活用してより多くの分析を実行し、モデルを構築したいと考えています。ちょっとアンケートを取らせていただきますが、S3ベースのData Lakeを持っていて、そのデータでより多くのことを実現したいと考えている方は手を挙げていただけますか？かなりの割合の方々がいらっしゃいますね。
2つ目のユースケースとしてよく見られるのは、AWS以外、主にオンプレミスで既存のワークロードを実行しているお客様です。そのアプリケーション、ワークロード、そしてそれが依存するデータをクラウドに移行したいと考えています。通常、これらのワークロードはファイルベースで、その理由については後ほど説明します。もう一度アンケートですが、この2番目のシナリオに共感される方は手を挙げていただけますか？およそ20-30%程度の方々ですね。先ほど申し上げたように、これからこれらのパターンそれぞれについて検討し、これまでの経験から得られたアーキテクチャパターンとベストプラクティスを共有していきます。
まずはS3 Data Lakeのお客様から始めましょう。ここからはGeorgeに引き継ぎたいと思います。ありがとう、Andrew。では、Amazon S3について話していきましょう。
まず、なぜAmazon S3を使用するのかというところからお話ししましょう。Amazon S3は18年の歴史を持つ、いわば老舗のサービスです。事実上の標準となっているクラウドオブジェクトストレージソリューションで、ストレージの拡張性は実質無制限です。事前のプロビジョニングや容量管理を必要とせず、ワークロードに応じて動的にスケールし、使用した分だけお支払いいただく仕組みになっています。S3は、11ナインの耐久性と3つのAvailability Zoneにまたがる可用性で知られており、特に重要な、あるいは貴重なデータの保存に適しています。
では、なぜデータレイク用にAmazon S3を選ぶのでしょうか？ここでは特に、図で強調表示している一般用途のバケットについてお話しします。データレイク用のAmazon S3は、アクセスパターンが様々で、ペタバイトからペタバイトへと長期的にデータ量が増加する大規模なデータレークに特に適しています。S3 Standardと、Standard-Infrequent AccessやGlacier Instant Retrievalといったよりコールドなストレージクラスは、ストレージが低温になるにつれてリクエストコストは上がりますが、最も低いストレージコストを実現します。つまり、使用頻度の低い期間がある長期保存データセットが必要な場合、Amazon S3を使用することが最もコスト効率の良いソリューションとなります。多くのお客様は、オブジェクトやデータの使用状況を監視し、コストを最適化するために異なるストレージクラス間で個別に移動させています。さらに、S3 Intelligent-Tieringを使用すれば、S3がアクセスパターンを監視しながら自動的にデータを移動させることができます。
Amazon S3の使用方法と理由について説明しましたので、次はAmazon S3データレークを最大限活用する方法についてお話ししましょう。まず何より重要なのは、ワークロードのパフォーマンス要件、そして利用可能なコンピュートとネットワークリソースから逆算して、ワークロードに必要なスループットを理解することです。Amazon S3の一般用途バケットは、接続ごとに95MBpsを提供し、ワークロードを効果的に並列化して水平方向にスケールすることで、ネットワーク、GPU、またはCPUが飽和するレベルまで、ギガビットやテラビットといった必要な速度を実現できます。
この並列化は、適切に分散されている場合に最も効果を発揮します。ホットスポットが発生すると、より不安定な動作となってしまいます。適切な分散を実現するには、DNS応答ごとに8つの応答を提供し、短いDNSキャッシュTTLを持つMulti-Value Answer DNS技術を使用する必要があります。AWS SDKを使用している場合、これは自動的に設定されます。独自のクライアントを使用している場合は、TTLを5秒以下に設定する必要があります。
S3の一般用途バケットは、プレフィックスごとに、1秒あたり5,500回の読み取りと3,500回の書き込みから始まってスケールします。利用可能なプレフィックスに対するワークロードが増加すると、プレフィックスに必要なTPSやリクエスト容量に応じて自動的にスケールアップします。スケーリング中、お客様はスローダウンメッセージを受け取り、システムがリクエスト容量をスケールする過程で数分かかることがあります。高性能ワークロードの場合、これは望ましくありません。高性能ワークロードには、慎重に検討されたプレフィックス設計をお勧めします。ここで、プレフィックス設計の非常に基本的な例を2つご紹介します。左側には、日付とプラットフォームによる基本的なプレフィックス設計が示されています。
ご覧のように、これは自律走行車向けに設計されており、各プレフィックスは日付と車両番号に基づいています。これらのプレフィックスはそれぞれ、負荷が上がってさらにスケールできるようになるまで、3500と5500で初期化されています。この日付とプラットフォームのプレフィックス設計を見てみると、例えば車両010を追加した場合、車両01と同じプレフィックスを共有してしまうことに気付きます。多くのワークロードでは日付とプラットフォームで簡単に分割できるこの方法でも機能しますが、意図せずにプレフィックスを共有してしまう可能性があります。これを回避するために、画面右側の例をご覧ください。この例では、プレフィックスの先頭にエントロピー（ランダム性）を追加することで、ワークロードが増加しても独立したプレフィックスを持ち、必要なTPSで初期化されることを保証しています。
Data Lakeにおいて、General Purpose Bucketがアクセスパターンが様々なデータや頻度の低いデータに適していることについて多く説明してきました。 しかし、ユースケースが極めて高頻度のアクセスを必要とする場合はどうでしょうか？長期保存のデータではない場合は？短期間のデータに対して集中的にアクセスし、トレーニングやある作業を行った後、チェックポイントを取るか、データをシャッフルしたり、あるいは削除したりする場合はどうでしょうか？このような場合に、S3 Express One Zone Directory Bucketが活躍します。これは最も頻繁にアクセスされるデータのためのものです。 Amazon S3 Express One Zoneは、高い一貫性を持つシングルディジットミリ秒の初回バイトレイテンシーを提供します。価格とパフォーマンスが向上する一方で、リクエストコストを50%削減し、極めて高いTPSの負荷に特化した設計となっています。
Amazon S3 Directory BucketとGeneral Purpose Bucketを比較してみましょう。先ほどプレフィックス設計について詳しく説明しましたが、Amazon S3 Express One Zone Directory Bucketの場合、プレフィックスは存在しません。18年間慣れ親しんできたフラットな設計ではなくなりました。S3 Express One Zoneでバケットを初期化すると、すぐに数十万TPSを利用できます。これは階層的なインデックスによって実現されています。また、Expressの後に「One Zone」と付いているように、 このストレージクラスは単一のAvailability Zoneで提供され、リージョン全体のストレージクラスではありません。これにより、同じVPC内の同じAvailability Zone内で、コンピュートクラスターとストレージを文字通り同じ場所に配置できます。クラウドオブジェクトストレージにおいて、物理的にも論理的にもデータに最も近い接続が可能になります。
最後に、Amazon S3 Express One Zoneでの認証の違いについてお話ししたいと思います。セッションベースの認証モデルを採用しており、5分間有効なトークンを持つセッションを作成します。このトークンは、バケット全体に対する読み取り専用または読み書きアクセス権を提供します。セキュリティモデルを大幅に簡素化し、認証のオーバーヘッドを気にすることなく、コンピュートワークロードを迅速に処理できます。AWS SDKを使用している場合、このセッションの作成と使用は、CRTと同様に完全に自動化されています。
Amazon FSx for Lustreの特徴と活用法
これまで、Amazon S3 General Purpose Bucketの使用方法と、 Amazon S3 Express One Zone Directory Bucketの使用方法について説明してきました。次は、ClickHouseを使用した実際の例でこれらをまとめていきたいと思います。ClickHouseは、リアルタイム分析用に設計されたオープンソースのカラム指向データベース管理システムで、その処理能力の高速性と効率性で知られています。
ClickHouseの内部動作の仕組みについて説明しますと、最初にデータが入ってきて活発に使用される「ホット」な状態では、分析に使用される小さな不変のパートを作成します。データが「コールド」になるにつれて、これらのパートをより大きなパートに結合していきます。ClickHouseはAmazon S3 Express One Zoneを第一階層として使用する2階層システムを実装し、これらのパートが作成され分析が実行される際に活用しました。最も頻繁なデータアクセスは、リクエストコストが最も低いS3 Express One Zone上で実行されました。データが「コールド」になるにつれて、Express One Zone上でマージ操作を実行し、そのデータをGeneral Purpose BucketsとS3 Standardに移行しました。この手法により、クエリのパフォーマンスが283%向上し、総所有コストを65%削減することができました。
ここで、Lift and Shiftのファイルストレージのお客様について説明するため、Andrewに引き継ぎたいと思います。ありがとう、George。Georgeが言及したように、これからLift and Shiftのファイルストレージのお客様と、そこで見られるユースケースパターンについてお話しします。また、Amazon S3のData Lakeをファイルソリューションと組み合わせて使用しているお客様のデザインパターンについてもお話ししますが、まずはLift and Shiftのユースケースから始めましょう。
既存の高性能ワークロードを実行しているお客様と話をすると、これらのワークロードの大半がファイルストレージソリューションを使用して動作しています。これには複数の理由があります。第一に、ファイルシステムはデータにアクセスする馴染みやすい方法です - Linux、Windows、macOSなど、ほとんどのオペレーティングシステムはデータをファイルとフォルダとして表示し、ネットワーク接続型ファイルシステムも全く同じ方法でデータを表示します。第二に、ファイルシステムはPOSIX準拠で、ロックや強力な整合性などの機能をサポートしています。これは、多数のコンピュートインスタンスにまたがるワークロードを実行する際に、結果整合性に頼ることなく、すべてのインスタンスで一貫したポイントインタイムビューを確保する上で非常に重要になります。第三に、ファイルは共有が簡単です - ほとんどのお客様は、各クライアントに存在しファイルシステムにマッピングされる/sharedフォルダを持つコンピュートクラスターを使用しています。第四に、ファイルシステムは高性能です - 数十年にわたって存在し、スループットとレイテンシーを最適化することに焦点を当てた数多くの機能と改善が重ねられてきました。
AWSでは、高性能なファイルベースのワークロードを移行したいと考えているお客様の多くが、主にAmazon FSx for Lustreサービスを選択しています。 Lustreについてはかなり多くの方がご存じだと思います。Lustreは強力なオープンソースのファイルシステムで、スピードに最適化され、高性能で高レベルの集約同時スループットを実現するように設計されています。Amazon FSx for LustreはAmazonが約6年前のre:Invent 2018で発表したサービスです。FSx for Lustreの目標は、お客様が大規模なストレージシステムの管理のエキスパートになる必要なく、Lustreが提供する高性能な機能を利用できるようにすることです。
ストレージソリューションを選択する際にお客様が重視する2つの主要な特性として、スループットとレイテンシーについて説明しました。まず、高性能ワークロードにおいてファイルシステム、特にFSx for Lustreが真価を発揮するレイテンシーについてお話しします。このサービスを構築した際、 AWS上で可能な限り最低のレイテンシーを提供できるように、意図的にこの製品を設計・アーキテクチャ化しました。AWS上で可能な限り最低のレイテンシーを提供するために、いくつかの重要なアプローチを実装しました。
1つ目は、私たちのファイルシステムがSSDストレージ上に構築されているということです。SSDは非常に低いレイテンシーを提供することで知られており、通常数十から数百マイクロ秒の範囲で、驚くほど高速です。 2つ目は、特に難しい設計上の決断でしたが、重要だと考えた点で、クライアントがデータにアクセスするためにファイルシステムをマウントする際のネットワークアーキテクチャに関するものです。私たちは、あるサーバーから別のサーバーへの往復を1回だけにすることを確実にしています。他のストレージソリューションを見てみると、クライアントが1つのサーバーに接続してから別のサーバーにルーティングされたり、クライアントと実際のデータサーバーの間にロードバランサーやプロキシを使用したりするものが多くあります。これらのアーキテクチャパターンには確かに正当な目的がありますが、いずれも追加のレイテンシーが発生します。まるで直行便ではなく経由便を使わなければならないようなものです。私たちは、クライアントがストレージにアクセスする際に、データを含むサーバーまでネットワークホップが1回で済むようにサービスを設計しました。
最後に、Lustre自体には多くのキャッシング機能が組み込まれており、サーバー側とクライアント側の両方で読み取りと書き込みの両方をサポートしています。最近、FSx for Lustreでのキャッシュから処理されるI/Oの割合を分析したところ、大多数がキャッシュから提供されていることがわかりました。これは、これらのキャッシング機能の威力を示しています。簡単に言えば、同じデータを複数回処理するようなワークロードを実行している場合、同じデータの2回目以降の読み取りはキャッシュから提供される可能性が高く、最初の読み取りよりもはるかに高速になるということです。
これがなぜ重要なのかを説明するために、 Audiが編集した自動運転データセットA2D2を例に見てみましょう。このデータセットには、平均約30キロバイトのサイズの数百万枚の画像が含まれています。単一のプロセスを使用してこれらの画像を読み取るのに必要な時間を比較しました。先ほどGeorgeが説明したS3 StandardとS3 Express One Zoneのレイテンシーの違いが、左端のバーの性能差を説明しています。 FSx for Lustreについて私が説明したすべての機能は、レイテンシーをサブミリ秒の範囲まで削減するように最適化されており、これが真ん中のバーと右端のバーの違い、つまり約5倍の改善を生み出しています。並列化のパターンやストレージソリューションに関係なく高性能を達成する方法は様々ありますが、低レイテンシーの主な価値提案は、ストレージシステムのレイテンシーへの対応に費やす時間を減らせることです。
FSx for Lustreのパフォーマンス最適化とEFA機能
私たちは、小規模なランダムな読み取りや書き込みなど、ネットワーク接続ストレージソリューションにとってあまり好ましくないI/Oパターンを持つ多くのお客様と協力しています。大量のデータを読み取る際には最適なI/Oパターンではないかもしれませんが、ストレージシステムが十分に低レイテンシーであれば効果的に機能します。これが、レイテンシーが重要である理由と、私がこれを取り上げたい理由を示しています。 パフォーマンスの2つ目の側面はスループットとIOPSです。そして、 FSx for Lustreを使用する際のスループットとIOPSの最適化について、3つの推奨事項を共有したいと思います。
1つ目の推奨事項は単純明快です。このサービスでは、スループットのレベルをプロビジョニングします。FSx for Lustreでは、ファイルシステムを作成する際に、ストレージ容量とスループットティアの両方を選択します。スループットティアは、ファイルシステムがストレージ1テラバイトあたりサポートできるスループットのレベルを決定します。 FSx for Lustreでは4つの異なるスループットティアを提供しており、低いほうで1テラバイトあたり125メガバイト/秒から、最大で1000メガバイト/秒まで拡張できます。特定のストレージとパフォーマンスのニーズに応じてコストを最適化できるよう、複数のスループットティアを提供しています。最初の推奨事項は、適切なストレージ容量とスループットティアを選択することで、アプリケーションの要件に基づいて十分なスループットをプロビジョニングすることです。
2番目の推奨事項は、今年6月に開始したメタデータIOPSに関する機能についてです。これについては後ほど詳しく説明します。FSx for Lustreには、パフォーマンスに関する2つの重要な要素があります。1つ目はスループットで、これは特定の時点でどれだけのデータの読み書きスループットを実現できるかを決定します。2つ目はメタデータのパフォーマンスで、これはファイルの内容ではなく、ファイル自体に対して実行する操作に関係します。
このメタデータ操作には、ファイルの作成、削除、ディレクトリ内容の一覧表示、権限の取得などが含まれます。Lustreでのほとんどのユースケースや高性能コンピューティングのユースケースでは、特に大きなファイルやオブジェクトを扱う場合、メタデータIOPSよりもスループットの方が重要になります。大多数のユースケースでは、メタデータは実際の制限要因や懸念事項とはならないため、デフォルトではメタデータはプロビジョニングされたストレージ容量にバンドルされています。
しかし、時間の経過とともに、お客様が私たちのストレージ製品を高性能コンピューティングだけでなく、ホームディレクトリやユーザーリサーチワークステーション、つまりよりメタデータパフォーマンスを必要とするインタラクティブなワークロードにも使用したいというニーズが増えてきました。そのため、今年6月に、Amazon FSx for Lustreでメタデータパフォーマンスを最大15倍向上させることができる新機能をリリースしました。 この機能の一環として、お客様がストレージとは独立してメタデータパフォーマンスをプロビジョニングできる機能も提供しました。エンドユーザーのリサーチワークステーションや小規模ファイルタイプのワークロードなど、メタデータを多用するユースケースがある場合、サービスでより高いメタデータパフォーマンスを実現できる機能が利用可能になりました。
今年初めにリリースしたダッシュボードでは、メタデータリソースの使用率をパーセンテージで確認し、必要に応じてメタデータパフォーマンスをスケールアップすることができます。これは主に小規模ファイルやメタデータを多用するユースケースに関係しますが、そうしたワークロードのパフォーマンスを最適化する上で重要なため、ご紹介させていただきました。さて、3番目として、先週リリースしたばかりの新機能についてお話ししたいと思います。この性能に関する推奨事項について、とても興奮してお話しさせていただきたいのですが、それはFSx for Lustreで開始したElastic Fabric Adapter（EFA）のサポートです。
Elastic Fabric Adapter（EFA）は、Amazonが2019年に発表したネットワーキング技術です。簡単に言うと、SRDと呼ばれるカスタムプロトコルをベースに構築されており、従来のTCPネットワーキングと比べて、より高いパフォーマンススケーラビリティと低いレイテンシーを提供するように設計されています。私がAmazonに入社した約9年前は、提供していた最大のEC2インスタンスで約25ギガビット/秒のネットワーク帯域幅でした。数年後には100ギガビット/秒に増加し、昨年にはネットワーク帯域幅が3200ギガビット/秒のP5インスタンスをリリースしました。
これらの数値は時間とともに増加しているだけでなく、お客様がそのレベルのスループットを必要とする状況も増えています。従来のTCPベースのネットワーキングを使用するFSx for Lustreでは、ネットワーキング層自体とTCPネットワーキングがOSカーネルでネットワークトラフィックを処理する必要があるため、パフォーマンスは約100ギガビット/秒で頭打ちになることがわかりました。EFAを使用することで、EC2インスタンスで実行されているオペレーティングシステムのカーネルをバイパスし、Amazonが開発した新しいSRDプロトコルを活用して、さらに高いレベルのパフォーマンススケーラビリティを実現できます。
EFA単体で、1つのクライアントから最大700ギガビット/秒のネットワーク帯域幅を得ることができます。Lustreはスケーリングを前提に設計されているため、数十のクライアントがある場合、ファイルシステム全体で桁違いに高いパフォーマンスを実現できます。EFAとOSバイパス機能により、NVIDIA GPUDirect Storageもサポートするようになりました。この機能により、クライアントのCPUをバイパスして、P5インスタンスで実行されているGPUがクライアントのネットワークカードと直接通信してストレージにアクセスできます。GPUDirect Storageを使用することで、単一のP5インスタンスに対して最大1200ギガビット/秒のスループットを提供できます。これらはすべてクライアントごとの制限であり、複数のクライアントを使用することでこれらの数値の倍数を得ることができます。100ギガビット/秒という大きな数字でも、GPUインスタンスを完全に活用するには不十分かもしれないというお客様の声があり、このようなパフォーマンススケーリング機能をリリースできることを大変嬉しく思っています。
これらのパフォーマンススケーリング機能に加えて、EFAとGDSには2つの注目すべき副次的効果があります。まず、GPUDirect Storageを使用することで、ネットワークI/Oを駆動するためのクライアントのCPU負荷が最大70%削減されます。CPUとOSカーネルをそのデータパスから除外することで、CPUを解放し、クライアントで実行されているリソースを使用してより多くの分析や異なる種類の作業を行うことができます。2つ目は、SRDが低レイテンシーのネットワークパスであるため、シングルストリームのスループットが約20%向上することです。言い換えれば、このSRDプロトコルに切り替えるだけで、シングルストリームのレイテンシーが約20%低下します。先ほど申し上げたように、これは先週リリースしたばかりの新機能で、今週re:Inventでお客様とお話しし、どのように活用しようとしているのかを伺えることを大変楽しみにしています。パフォーマンスに関する推奨事項として、これが3番目となりますが、ハイパフォーマンスワークロードのパフォーマンスをさらに向上させるためのこの強力な機能を有効にすることをお勧めします。
S3とFSx for Lustreの統合ソリューションと事例紹介
ファイルのLift and Shiftのセクションを、Shellの事例で締めくくらせていただきます。数年前、彼らはGPUベースのオンプレミス環境を持っていましたが、オンプレミスのインフラリソースに関してボトルネックに直面していました。オンプレミスでファイルベースの環境を使用していたため、AWSでも同様の環境を望んでいました。余剰キャパシティのためにAWSへのバーストを検討していた彼らは、Amazon FSx for LustreとAmazon EC2を活用し、オンプレミスではできなかったコンピューティングとストレージリソースのスケールアップとスケールダウンを実現することができました。最終的に、この柔軟性とAWSで得られる高性能ストレージにより、クラウドでのGPU使用率を90%から約100%に向上させることができました。10%は大きな数字には見えないかもしれませんが、P5インスタンスを利用したことがある方なら、1パーセントポイントの違いがいかに重要かご理解いただけるでしょう。これこそが、支払っているコンピューティングリソースをフル活用できる高速ストレージを持つことの真価です。
先ほど少し触れたように、Amazon S3データレークのお客様とファイルのLift and Shiftについてお話ししました。お客様からよく耳にするユースケースがもう1つあります。それは、既存のAmazon S3データレークを構築しているものの、時にそのデータにファイルシステムを通じてアクセスしたいというものです。ここから数分、S3データレークにあるデータにファイルアクセスを可能にする機能について、お話しさせていただきたいと思います。
S3データレイクに対してファイルアクセスが必要な理由について疑問に思われるかもしれません。S3はオブジェクトサービスですから。実は、これが重要となる理由が2つあります。1つ目は、ファイルシステム上のデータを前提として作られたファイルベースのツールやアプリケーションを使用している場合です。データがS3データレイク上にある場合、そのデータをファイルシステムのように扱える機能があれば非常に便利です。2つ目は、先ほどファイルソリューションが提供する豊富なパフォーマンス機能について説明しましたが、オブジェクトストレージに対してファイルシステムを配置したり、ファイルアクセスを可能にしたりすることで、S3に直接アクセスする場合と比べて、これらのファイルパフォーマンス特性を活用してワークロードを高速化できることが多いのです。
S3にファイルインターフェースでアクセスする方法として、私たちが開発し、お客様にご利用いただいている2つの主要なソリューションがあります。1つ目は、Mountpoint for Amazon S3というテクノロジーです。Mountpointは、Amazon EC2インスタンス上で動作するFUSEクライアントです。基本的に、EC2インスタンス上にフォルダを公開するファイルシステムマウントを提供します。内部的には、MountpointはアカウントのS3バケットと標準的なS3 API（get、put、list、delete）を使用して通信します。S3へのファイルトランスレーターと考えることができます。2つ目のソリューションは、Amazon FSx for Lustreで、FSxとS3の間にネイティブな統合を提供しています。ファイルシステムを作成する際に、S3バケットとリンクすることを選択すると、S3バケット内のデータをファイルシステム経由でアクセスできるようになります。内部的には、バケット内のすべてのオブジェクトのリストをファイルシステムに取り込みます。ファイルシステムからデータを読み取ろうとすると、バケット内のオブジェクトがファイルシステム上のファイルとして表示されます。バケットにデータを追加すると、自動的にファイルシステムにインポートされ、ファイルシステムにデータを書き込むと、自動的にバケットにエクスポートされます。
S3バケットの前に置かれたファイルシステムキャッシュのようなものだと考えることができます。これら2つのソリューションのうち、Mountpoint for Amazon S3は、ファイル機能は必要だが、ファイルシステムの完全なセマンティクスやパフォーマンスまでは必要としないワークロードに最適なソリューションとなります。
Mountpointの典型的なユースケースは、S3上に大きなオブジェクトがあり、レイテンシーがそれほど重要でなく、主にデータのストリーミングを目的とする場合です。Mountpointはgetをサポートし、S3上のデータへのアクセスに高いパフォーマンスを提供します。S3にはオブジェクトやフォルダの名前変更、データのロックといった概念がないため、これらはファイルシステムが提供するために構築された機能です。より対話的なワークロードや、これらの機能を必要とするワークロードはMountpointには適していない場合があり、そこでAmazon FSx for Lustreが活躍します。
Amazon FSx for Lustreのアーキテクチャでは、コンピュートインスタンスは実際にファイルシステムとインターフェースを取ります。背後にS3バケットがない場合と同じように、完全なセマンティクスとすべての一貫性保証が得られます。ファイルシステム自体には、バケットやファイルシステムに変更を加えた際に、それらが各データソースに正しく調整され、伝播されることを保証する機能があります。大まかに言えば、Mountpointはクライアントとバケットの間にファイルシステムがないためシンプルなソリューションです。一方、FSx for Lustreは、ロック機能、名前変更機能、既存のオブジェクトの変更など、より本格的なファイル機能が必要な場合に、より高品質なソリューションを提供します。
具体例をお見せしましょう。私たちは社内でテストを実施し、パブリックS3データセットとして公開されているKaggleの肝臓データセットを使用して、異なる構成での患者分類の実行時間を計測しました。1つ目の構成では、S3から直接データを読み込み、ローカルストレージにダウンロードしてから、そのローカルストレージに対してトレーニングワークロードを実行しました。2つ目の構成では、S3データの前にFSx for Lustreを配置し、S3バケットからファイルシステムにデータをロードしました。この例では、FSxが提供する低レイテンシーのおかげで、S3から直接ダウンロードする場合と比べて67%高速化を実現しました。先ほど述べたように、Lustreにはキャッシング機能が組み込まれており、他の設定を変更せずに全く同じワークロードを2回目に実行すると、自動キャッシング機能のおかげで1回目と比べて83%高速化されることが確認できました。
Mountpoint for S3のキャッシングについて言えば、同様にデータのパフォーマンスを最適化できるキャッシング機能が組み込まれています。 Mountpointを設定する際、頻繁に読み取られるデータのキャッシュとして、ローカルのNVMeドライブやAmazon EBSボリュームを選択して設定することができます。 この機能がMountpointに組み込まれているため、データへの後続のアクセスは、S3から複数回読み取る場合と比べて最大2.2倍のパフォーマンス向上を実現できます。
先月リリースしたもう1つの機能は、Amazon S3 Express One Zoneを使用したMountpointの共有キャッシュ機能です。これまでしばらくの間提供してきた最初の2つのキャッシングオプションは特定のコンピュートインスタンスにローカルなものでしたが、この新機能では、S3から読み取る対象データを自動的にExpress One Zoneバケットに保存するようにMountpointを設定できます。これにより、コンピュートクラスター内の他のインスタンスが同じデータを読み取る際に、Express One Zoneからデータを提供できるようになり、ローカルストレージベースの既存の2つのキャッシュソリューションとは対照的に、すべてのコンピュートインスタンス間で共有キャッシュを実現できます。
最後に、もう1つの簡単なお客様事例をご紹介します。LG AI Researchの事例です。
彼らは人間の脳を模倣する基盤モデルの作成を目指し、Amazon SageMakerとFSx for Lustreを使用して独自のモデルを構築することを決定しました。この事例は、お客様がそれぞれの長所に基づいて複数のストレージソリューションを使用している点で特に興味深いものです。
ご覧の通り、左側では機械学習のトレーニングデータをS3バケットに保存しています。パフォーマンスの向上とファイルシステムインターフェースを得るために、このバケットにリンクされたLustreファイルシステムを作成し、SageMakerトレーニングインスタンスからこのLustreファイルシステムにアクセスしています。ワークロードが完了すると、モデルのアーティファクトをS3に保存し、その後の推論に使用することができます。このお客様は、トレーニングの入力とモデル出力の長期保存にAmazon S3を使用しながら、FSx for Lustreを活用してトレーニングの実行時間を短縮し、インスタンスから最高のパフォーマンスを引き出しています。
これでプレゼンテーションは終了です。月曜日のセッションの利点の1つは、この週の残りにまだたくさんのセッションが控えているということです。ストレージに関連するトピックや、ストレージのパフォーマンス最適化に焦点を当てたセッションの例をいくつかご紹介したいと思います。これらの多くはChalk Talkと呼ばれる、よりカジュアルな形式のセッションで、エキスパートと直接やり取りしながら、ストレージとコンピューティングのソリューションを適切に組み合わせる方法を学ぶ機会となっています。
ランチ後のセッションにもかかわらず、ご参加いただき、ありがとうございました。まだの方は、アプリで通知が来ているはずですので、アンケートにご協力ください。Georgeとわたしはこのあともここに残って、皆様からのご質問にお答えします。手を挙げていただければ、今すぐ質問にお答えしますし、後ほど廊下でフォローアップのお話をすることもできます。 はい、どうぞ。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion