re:Invent 2025: AWS File StorageサービスのEFS、FSx最新機能とIntelligent-Tiering
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - What's new with AWS File Storage (STG203)
この動画では、AWSのファイルストレージサービスの最新機能について包括的に解説しています。Christian SmithとAndy Crudgeが、EFS、FSx for Windows File Server、FSx for OpenZFS、FSx for NetApp ONTAP、FSx for Lustreという5つのサービスの特徴と最適なユースケースを説明し、価格パフォーマンス最適化、データ活用、レジリエンス、移行の簡素化という4つの観点から今年の主要なローンチを紹介しています。特に注目すべきは、FSx for LustreへのIntelligent-Tieringストレージクラスの追加、FSxとS3の統合によるアナリティクスサービスとの連携強化、logically air-gapped vaultsへの直接書き込み機能、FlexCacheのライトバックキャッシュ機能などです。機械学習ワークロードにおけるLustreのメタデータIOPS最適化や、Amazon Elastic VMware ServiceでのFSx for ONTAPサポートなど、実践的な改善も多数紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWSファイルストレージの急成長と豊富なポートフォリオ
それでは、皆さん、こんにちは。木曜日へようこそ。本日はご参加いただきありがとうございます。ファイルストレージの新機能についてお話しします。木曜日ですが、今のところ私たちの声はなんとか持ちこたえていますので、もし私たちがステージから素早く退場するのを見かけたら、おそらく飲み物を取りに行って、ここで話を続けられるようにするためだと思ってください。私の名前はChristian Smithです。AWSのワールドワイドストレージスペシャリストチームを率いています。私の名前はAndy Crudgeです。AWSのFSXサービスチームを率いています。
皆さんがご一緒してくださって本当に嬉しいです。今年起こったことについて、リリースしたものや今週発表したものなど、たくさんのことをお話しします。これは少し振り返りの内容であり、そして今年のre:Inventで発表できることを楽しみにしていることを見ていきます。そしてもちろん、ファイルストレージへの投資についてどのように考えているかについての洞察をお伝えします。
それでは、少しの間、なぜファイルストレージなのかについてお話ししましょう。ファイルストレージ全体は、AWS内で最も急速に成長しているストレージサービスであり、それは本当にお客様がAWSに持ち込んでいるユースケースによるものです。私たちはこれらを3つの異なるまとまりで見ています。ビジネスを動かすすべてのアプリケーションというまとまりがあります。それはグループファイル共有かもしれませんし、OracleやSQL Serverデータベースのようなエンタープライズアプリケーションかもしれません。これらをファイルサービス全体でシンプルな方法で実行することには多くの価値があり、そしてもちろん、バックアップとディザスタリカバリの側面全体があります。つまり、AWSでどのようにビジネス継続性を実現するかということです。これらは、AWSに持ち込むリフトアンドシフトアプリケーションである傾向があります。
過去10年から15年の間に、マシン生成データの出現を見てきました。それは、今やミリ秒単位の粒度になっている株式ティックデータから、ゲノミクスデータ、クライオEMデータまで、すべてです。Nvidiaが最近かなりニュースになっていると思いますし、彼らが作っているすべてのチップについての話をすべて見てきたと思います。何だと思いますか?彼らがチップの最終出力に到達するために設計しているそれらのチップの背後には、大量のファイルストレージがあるのです。ですから、私たちはこのすべてのデータの成長を見ており、1つの共通点は、これが多くのコンピュートによってアクセスされる必要がある大量の共有ストレージであるということです。
そしてもちろん、Nvidiaで市場に出てくるこれらすべてのチップとともに、機械学習のようなものがあります。機械学習はもちろん、これらのGPUとCPUに供給し続けるために迅速に処理される必要がある非常に高速で高スループットのデータですが、それだけではありません。それは人々がファイルやフォルダで座って作業することについてでもあります。クオンツアナリティクスのような人々、ゲノミクス研究者のような人々、データサイエンティストであり、彼らがどのようにデータをキュレーションし、さまざまな洞察を導き出すことができる方法でそれを行うかということです。そしてもちろん、ISVアプリケーションです。つまり、アプリケーションの周りにマネージドサービスを作成しているさまざまなベンダー、顧客のニーズに応えるためにファイルベースのデータを使用しているSalesforceのような顧客について考えてください。ですから、私たちはこの途方もない成長を見ており、そしてもちろん、それをサポートするための豊富なポートフォリオを持っています。そしてAndyがそれについてお話しします。
はい、ありがとうございますChristian。そうですね、Christianが言及したように、ファイルストレージを使用するワークロードには本当に幅広い種類があります。このような幅広いスペクトラムのワークロードがあるからこそ、私たちは豊富なファイルストレージサービスのポートフォリオを提供しています。それぞれのサービスは、異なるタイプのワークロードに対応するように構築されており、異なる目的に最適化されています。特定のデプロイメントについてエンドユーザーやアプリケーションオーナーと協力する際、よく見られるのは、これら5つのファイルストレージソリューションのうちの1つが、その特定のアプリケーションに理想的にフィットするということです。しかし、組織レベルで、特に私たちが協力している大規模なエンタープライズ組織と仕事をする際には、非常に興味深いことがあります。これらの組織は実際に、環境内でこれらのファイルソリューションの複数を使用していることが非常に多いのです。繰り返しになりますが、異なるタイプのワークロードに対して異なるファイルソリューションを使っているわけです。しかし、ご存知のように、万能なソリューションというものは本当にありません。それぞれのサービスは、本当に異なるタイプのユースケースに最適化されているのです。それでは、私たちが提供している5つのサービスと、それらが本当に最適化されているユースケースについて、非常に簡単に説明していきます。
FSXファミリーとAmazon EFS：それぞれのサービスが最適化されたユースケース
最初にお話ししたい3つのサービスは、FSXファミリーのサービスです。これらは、FSx for Windows File Server、FSx for OpenZFS、そしてFSx for NetApp ONTAPです。これら3つのサービスについて、私たちが実際に見ているもの、そしてこれらのサービスを立ち上げた理由は、長年にわたって多くのお客様とお話しする中で、大量のエンタープライズファイルデータ、多数のファイルベースのワークロードを持っていて、これらのワークロードに使用している基盤となるストレージが、Windows ServerやZFS、NetApp ONTAPといった人気のあるファイルシステム技術を搭載した、オンプレミスの従来型のNASアプライアンスであるということでした。そして、これら3つのサービスで私たちが本当に目指しているのは、お客様がこれらのファイルベースのデータセットやファイルベースのアプリケーションをAWSに移行できるようにすることを簡単にすることです。
オンプレミスで既にお持ちのNetAppシステムやWindowsシステムと同じように動作する、同等のストレージソリューションを提供することによってです。同じ機能、機能セット、そしてデータ管理に使用するAPIを提供することで、移行プロセスを非常にシンプルにします。これにより、クラウドに移行する際に、データ管理方法を再発明したり、ストレージ管理方法について担当者を再トレーニングしたり、さらにはデータ管理プロセスを変更したりする必要がなくなります。
次にお話ししたいサービスは、Amazon FSx for Lustreです。Lustreに馴染みのない方のために説明しますと、これは世界で最も人気のある高性能ファイルシステムです。スピード、高レベルのスループット、高レベルの集約IOPSに最適化されています。私たちがこのサービスを立ち上げたのは、お客様が高性能なコンピュート集約型、GPU集約型のワークロードをAWSで構築したり、持ち込んで実行したりするのを支援するためです。例えば、ゲノム解析や地震処理のようなワークロードで、本当に大量のデータがあり、それらを非常に高速に処理する必要があるものです。
特にここ数年、FSx for Lustreで私たちが目にしている大きなユースケースは、機械学習ベースのワークロード、機械学習トレーニング、そして機械学習研究です。これについては後ほどもう少し詳しくお話しします。繰り返しになりますが、これらはすべて、高レベルの集約スループットと集約IOPSを必要とするワークロードであり、CPUやGPUがIOを待つのではなく、本当に最大限に活用されるようにするためのものです。
そして最後に、Amazon EFSがあります。これは私たちの完全に弾力性のあるファイルシステムのオファリングです。完全に弾力性のあるストレージと完全に弾力性のあるパフォーマンスを提供します。これは本当にシンプルさのために設計・最適化されており、クラウドネイティブなワークロードや、ECSやEKSのコンテナ化されたワークロード、サーバーレスワークロード、AWS Lambdaで使える超シンプルな共有ストレージソリューションを求めているビルダーの方々のためのものです。EFSはこれらすべての製品と統合されています。繰り返しになりますが、このサービスは私たちのFSxオファリングのような幅広いNASデータ管理機能や、Lustreが持つようなパフォーマンススケーラビリティは提供していませんが、私たちが目にしているこうしたクラウドネイティブタイプのワークロードの多くに対して、シンプルさのために本当に最適化されています。
価格パフォーマンスの最適化：Amazon EFSの大幅な性能向上とアクセスポイントの拡張
それでは、今日ここに来た本題に入りましょう。それは新機能についてお話しすることです。今日はこれから順番に引き継いでいきますので、進めながらこのような形になります。なぜ今日ここにいるのかについてお話ししましょう。今年は一年を通じて多くのリリースがありました。そして私たちはイノベーションのペースを徐々に、あるいは増加させてきました。ファイルポートフォリオを強化するために行っていることの数を増やしてきました。これは私たちがお話しする内容のほんの一部です。これらのいくつかについて振り返りとして、そして今週発表したローンチについてもお話しします。皆さんの中にはすでにご覧になった方もいらっしゃるかもしれません。でも、本当に深く掘り下げて進めていくのが楽しみです。
皆さんのフィードバックとリクエストに基づいて、私たちはお客様の問題を解決したり、新しいことを可能にするものをリリースしています。そして今日のトークの構成として、これを4つの異なるバケットで見ています。1つ目は、価格パフォーマンスをどう最適化するかです。これは、もっと速く、もっと安くという声を聞き続けているからです。TCOの議論があります。ホットデータをホットに保ち、コールドデータを介入なしに最適化する方法についてです。次に、データでもっと多くのことをすることについてお話しします。AWSには豊富なサービスのエコシステムがあります。私たちがやろうとしていることの1つは、データを複数のサービスにコピーすることなく、今データがある場所からそれらのサービスを簡単に利用できるようにすることです。
もちろん、レジリエンスの側面もあります。これは、障害、フォールト、脅威アクターに対してインフラストラクチャをどのように回復力のあるものにするかということです。そして最後に、アプリケーションをAWSに移行しやすくする方法です。それでは最初のものから始めましょう。価格パフォーマンスの最適化についてお話ししましょう。お客様がファイルシステムにより多くのデータを保存し続けており、本当に方法を探しているのを見続けています。私たちがやろうとしていることは、ホットデータが必要なパフォーマンスを持ち、コールドデータがコスト最適化され、それを実現するために何もアクションを取る必要がないようにすることです。
ですから、私たちが持っているものの多くを見ると、常にホット層とコールド層があり、アクセスパターンに基づいてこれら2つの間のやり取りを管理しているので、皆さんはそれについて考える必要がありません。しかし、価格パフォーマンスと、この過去1年間に何が起こったかについてお話ししましょう。Amazon EFS、正確にはElastic File Systemですが、昨年2つの大きな発表がありました。昨年はこれらについて正しい方法でお話ししなかったと思います。ですから、これら2つについてお話ししましょう。1つ目は、読み取りスループットを大幅に増加させ、30ギガビット毎秒から60ギガビット毎秒になりました。また、書き込みスループットも3ギガビット毎秒から5ギガビット毎秒に増加させました。ですから、大量の高IOを行っている場合、大量のストリーミングを行っている場合、ファイルシステムが成長し続けるにつれて、帯域幅を増加させました。
2つ目の機能強化は、IOPSの大幅な向上です。IOPSを10倍に増加させることに成功しました。読み取りスループットは250,000 IOPSから2.5百万IOPSへ、書き込みスループットは30,000 IOPSから50,000 IOPSへと向上しています。この機能をスケールアウトパフォーマンスと呼んでいますが、お話ししていなかったのは、どうやってそこに到達するかということです。はい、これはすべてエラスティックですし、はい、このパフォーマンスを得られますが、CloudWatchダッシュボードを通じて250または30ギガビット毎秒というこれらの制限に達した際、もし私たちからスケールアウトファイルシステムにアップグレードする必要があるとご連絡していない場合は、遠慮なく私たちにご連絡ください。これらのパフォーマンスレベルまでスケールアップすることを確実にするために、私たちは舞台裏でいくつかの作業を行っています。
2つ目にお話ししていなかったことは、クライアントあたりのスループットも最大1.5ギガバイト毎秒まで向上させたということです。そして私たちが目にしているのは、多くのお客様がEFS Utilsパッケージを使用していないということです。そのクライアントあたりのスループットを得たい場合は、必ずシステムにそれをインストールしてください。なぜなら、そのスループットを得るための最適化とチューニングに役立つからです。これらのファイルシステムがどんどん大きくなるにつれて、寄せられるリクエストの1つは、お客様がより少ないファイルシステムを管理したいということです。少なく管理する方が、多く管理するよりも良いのです。そしてお客様が私たちに求めているのは、より大規模なマルチテナントインフラストラクチャを作成したいということです。
今年の2月に、アクセスポイントをリリースし、ファイルシステムあたりのアクセスポイントを1,000から10,000へと10倍に増やしました。これで、アプリケーションがスケールするにつれて、セキュリティとコンプライアンスのためにこれらのファイルシステムをセグメント化できるパフォーマンスとテナンシーの両方を備えていることに自信を持っていただけます。もう1つのローンチ、この1年以内にローンチしたもう1つの機能についてお話ししたいのは、Amazon FSxに追加した新しいIntelligent-Tieringストレージクラスです。
Intelligent-Tieringストレージクラス：FSx for OpenZFSとLustreへの展開
約1年前、実際には昨年のre:Inventで、Intelligent-Tieringの最初のローンチを行い、FSx for OpenZFSサービスにIntelligent-Tieringを追加しました。Intelligent-Tieringとは何かを簡単におさらいすると、これはゼロから構築された新しいストレージクラスです。私たちは実際に一歩下がって、お客様と話し、お客様が私たちに求めてきたこと、そして新しいストレージクラスで見たいと思っていることについて考え抜きました。
まず、Intelligent-Tieringは、以前のFSxストレージクラスとは異なり、完全にエラスティックです。これが意味するのは、ファイルシステムを作成する際に、ストレージのレベルをプロビジョニングする必要さえないということです。保存するデータ量のみに基づいて課金されます。データを追加すると、課金額が増えます。データを削除すると、課金額が減ります。プロビジョニング不要で完全にエラスティックです。
2つ目は、このストレージクラスが本当にコスト最適化されているということです。Christianが先ほど話していたように、これはウォーマーなデータとコールダーなデータの組み合わせのようなもので、Intelligent-Tieringファイルシステム内には実際に3つのストレージティアがあり、データはアクセスパターンに基づいて、つまりデータがどれだけコールドかに基づいて、これらの間で自動的に階層化されます。Intelligent-Tieringの価格は、頻繁アクセスティアで約2.3セントから、アーカイブティアでは0.5セント未満までの範囲となっています。これはS3 Intelligent-Tieringと同じストレージ価格です。S3 ITに馴染みがある方ならご存知かと思いますが、ここでの私たちの目標は、データがホットかコールドかに関わらず、可能な限り最低のTCOを実現できるようにすることです。
最後に、Intelligent-Tieringファイルシステム上でSSDベースのリードキャッシュを提供しています。これはオプションです。ファイルシステムを作成する際、例えばレイテンシーにそれほど敏感ではなく、大きなブロックをストリーミングするだけのファイルがある場合は、キャッシュをプロビジョニングしないことも選択できます。しかし、小さなファイルが多数あるワークロードや、本当にホットなデータの一部がある場合は、SSDリードキャッシュをプロビジョニングして、最もホットなデータに対してサブミリ秒のレイテンシーという超高速なパフォーマンスを得ることができます。
先ほど申し上げたように、私たちは1年前にFSx for OpenZFSサービスでIntelligent-Tieringをローンチしました。それ以来、このローンチに本当に興奮しているお客様と多くの議論を重ねてきました。かなり一貫して聞かれることの1つは、ハイパフォーマンスワークロードを持つお客様も同様に、Intelligent-Tieringで提供している同じシンプルさ、同じ使いやすさ、同じ価格帯を求めているということです。私たちは、オンプレミスで実行してきた従来のHPCワークロードを持つ多くのお客様と話をしました。彼らは主にHDDストレージ上に構築された大規模なファイルシステムを持ち、1セントから2セントの範囲の低価格を必要としており、Intelligent-Tieringで得られる弾力性と俊敏性を本当に望んでいますが、スケールアウト可能な本当にハイパフォーマンスなファイルシステムのパフォーマンスが必要なのです。
私がどこに向かっているか、おそらくお分かりでしょう。今年の5月、数ヶ月前に、私たちはハイパフォーマンスな FSx for Lustreファイルシステムにも、ストレージクラスとしてIntelligent-Tieringを追加しました。これはFSxファミリーでIntelligent-Tieringを提供する2番目のファイルシステムです。
これにより、ハイパフォーマンスワークロードを持つお客様は、Intelligent-Tieringの弾力性、俊敏性、低コストのメリットすべてを、Lustreが提供するハイパフォーマンスとともに得ることができます。これは1セントから2セントの範囲のコストがかかるストレージクラスで、テラバイト毎秒のスループット、数百万IOPSを実現でき、先ほど申し上げたSSDリードキャッシュを使えば、最もホットでアクティブなデータに対してサブミリ秒のレイテンシーを得ることができます。
私たちは、オンプレミスから移行を検討している高性能ワークロードをお持ちの多くのお客様、そして大容量ファイルや大量のデータをストリーミングする機械学習ワークロードをお持ちのお客様とお話ししてきました。このようなケースでは、このストレージクラスはストレージコストの最適化とデータ管理の簡素化に非常に優れています。過去数年間のFSX for Lustreへの投資を振り返ってみますと、これらはすべてお客様からいただいたフィードバックと、お客様が私たちに期待する方向性に基づいたものですが、私たちが継続的に注力してきたのはパフォーマンスのスケーラビリティの向上です。
1年半前には、メタデータIOPSを15倍に向上させるアップデートをリリースしました。これにより、小さなファイルのワークロードに対して、より高いレベルのパフォーマンスまでスケールできるようになりました。そして前回のre:Inventでは、Elastic Fabric AdapterとGPUDirect Storageのサポートを追加しました。これにより、単一のファイルシステムに対するクライアントあたりのスループットを、以前と比べて最大12倍、つまり最大1.2テラビット毎秒のスループットまで引き上げることができるようになりました。
パフォーマンスのスケーラビリティは、今後も私たちが継続的に投資していく領域です。お客様からは、ワークロードの規模とスループットのニーズが増え続けているとお聞きしており、私たちはLustreをさらに高いレベルのパフォーマンスを提供できるよう、投資を続けていきます。ただ、ここで少し時間を取って、FSX for Lustre上でお客様が実行するケースが増えている、非常に興味深いユースケースについてお話ししたいと思います。それは機械学習研究です。
機械学習研究ワークロードへの最適化：FSx for Lustreのメタデータ性能向上とSSDプールの動的スケーリング
今週のMatt Garmanの基調講演をご覧になった方は、実際に現在AWSでFSX for Lustreを使用して機械学習ワークロードを実行しているお客様への言及がいくつかあったことにお気づきかと思います。お客様がこれらのワークロードに対してどのようにストレージソリューションを選択しているか、そして何がお客様をLustreに向かわせているのかを見てみますと、よく見られるパターンの一つは、特に機械学習研究において、お客様がいくつかの要素の組み合わせを求めているということです。
その一つが高スループットです。トレーニングを行う際、GPUインスタンスから大量のデータを読み込む場合、それらのGPUに対してどれだけのスループットを得られるかを最大化することで、実効スループットを最大化し、コストを最適化したいと考えます。同時に、実際に研究を行っている多くの機械学習研究者について、お客様からお聞きしているのは、彼らはデータに対して本当にシンプルで直感的で使いやすいインターフェースを求めているということです。そして、これらの研究者の多くは、ネイティブなファイルシステムでデータを扱うことに慣れています。
私たちがよく目にするお客様の環境設定は、研究者がホストにSSHで接続するというものです。彼らはホームディレクトリを持ち、Pythonスクリプトを持ち、同じファイルシステム上にデータを持っていて、データを処理する新しい方法や、データでトレーニングする新しい方法を試すために常に反復作業を行っています。ですから、この研究のユースケースは、研究者が「よし、今から何かトレーニングしてみよう」と言ったときに必要となる高いパフォーマンスと、データを操作したり色々試したりできる本当に使いやすいインターフェースの、非常に興味深い組み合わせなんです。
簡単な質問ですが、ここにいる方で、Linuxホスト上でLSを実行したことがある方はいらっしゃいますか？ここでもほとんどの方が手を挙げていますね。これは研究者にとって、そして正直なところあらゆるエンドユーザーにとって、ファイルシステムに対して実行する非常にシンプルで、極めて一般的なコマンドです。LSを実行すると、 特に分散ファイルシステムに対して実行する場合、通常見られるのは、ネットワーク接続された分散ファイルシステムに対してLSを実行すると、ローカルストレージに対して実行する場合よりも少し時間がかかることがあるということです。
その理由は、LSの一部として返されるメタデータが大量にあるからです。ファイル名、サイズ、タイムスタンプなどがあり、分散システムでは、内部的に、この情報をすべて収集してユーザーに表示するために、複数のサーバーに接続する必要があります。つまり、ローカルディスクとネットワーク接続ストレージでLSのパフォーマンスを比較すると、特に数百、数千、数万のファイルが入った大きなディレクトリの場合、LSは少し時間がかかる可能性があるということです。
機械学習の研究者と話をして聞いたのは、LSにかかる時間がミリ秒と0.5秒程度の違いというのは大したことではないように思えるかもしれませんが、エンドユーザーとしてファイルシステムと対話している時には、そのミリ秒が実際に重要で、それがストレージの応答性とエンドユーザーの体験の質に本当に影響するということです。そこで、2週間前にローンチした機能強化の一つで、私が本当にお話しできることを楽しみにしているのは、 実際にLustreに変更を加えて、LSが内部でどのように動作するかのIOパターンを最適化したということです。
そうすることで、ディレクトリの内容をリストアップするのにかかる時間を最大5倍短縮することができました。これは、FSx for Lustre上でML研究タイプのワークロードやホームディレクトリタイプのワークロードを実行しているお客様からのフィードバックに基づいて行ったもので、研究者がそれらのデータセットにネイティブファイルシステムを使いたいと思う使いやすさを本当に重視し、それをさらに応答性が高く迅速なものにしています。これは数週間前から、FSx for Lustreの一部として提供している最新のクライアントで利用可能になっています。これは実際にLustreクライアントに加えた変更です。
それでは、TCOに関する最後の機能強化についてお話ししましょう。FSx for NetApp ONTAPをご存知の方なら、基本的に2つの階層があることをご理解いただけると思います。パフォーマンス階層があり、これはプロビジョニングされたSSD階層です。そして、エラスティック階層があり、これは私たちがキャパシティプールと呼んでいるものです。ここでポリシーを設定することで、データが古くなったり、スナップショットのようなものをオフロードしたい場合に、ホット階層からコールド階層へ自動的に移動させることができ、エラスティックな方法で行い、コストを大幅に削減できます。さて、これを実現するために何が起こるかというと、データは常に最初にSSD階層に配置され、その後1日後、30日後、60日後、あるいはお客様のポリシーに応じて、キャパシティプールにオフロードされます。
お客様から聞いているのは、時々、私のデータセットが最初にSSD階層でプロビジョニングしたかったものよりも大きいことがあるということです。これは素晴らしいことで、SSDプールを動的にスケールアップできるからです。逆に、大規模な移行を行っていて、このSSDプールをスケールアップして、できるだけ速くこの移行を吸収したいと考えています。そして、それがキャパシティ階層にドレインされると、そこにあるデータの経過時間やタイプに最適化されます。スケールアップの柔軟性は常にありましたが、今年の8月にリリースしたのは、お客様のアプリケーションに介入することなく、このSSDプールを動的にオンラインで縮小する機能です。これで、SSDプールをスケールアップし、使用し、消費し、何らかのジョブや月末処理を行っている場合はバッチ実行を行い、それが完了してそのデータがキャパシティプールに移動するのを見守りたい場合は、アプリケーションやエンドユーザーに中断を与えることなく、これを再びスケールダウンできます。これは、Gen 2 FSx for ONTAPファイルシステムで今日利用可能な素晴らしい機能であり、ONTAPの用語に精通している方なら、これはアグリゲートを取得して動的に縮小することに相当します。
データでより多くのことを実現：Amazon FSxとS3の統合、そしてAWS Transfer Familyとの連携
それでは、データでより多くのことを行うことについてお話ししましょう。私たちは非常に豊富なサービスのエコシステムを持っています。BedrockやEMRなど、あらゆるものが存在しており、お客様に提供したいのは、ファイルデータを使用してそれを処理できるようにすることです。これは今週の大きな発表でした。それでは、Andyに説明を譲ります。
ありがとう、Christian。先ほど述べたように、私たちが協力している多くのお客様は、歴史的にオンプレミスに置かれてきた既存のエンタープライズファイルデータを持っています。そして、私たちのFSxオファリング、特にWindows File Server、NetApp ONTAP、OpenZFSで見られることの1つは、お客様が同等のストレージソリューションを持つことで、データを再設計することなく、そのデータをクラウドに簡単にリフトアンドシフトして移動できるということです。これは素晴らしいことです。お客様は、マネージドサービスで実行することで得られる管理の容易さ、エラスティックストレージオプションのようなものによるコスト削減、そしてボタンをクリックするだけでスケールアップおよびスケールダウンできる俊敏性のメリットを気に入っていると共有してくれています。
しかし、Christianが先ほど述べたように、AWSを見ると、データでより多くのことを行えるようにする数十ものサービスを提供しています。これらは分析サービス、AIサービス、MLサービスです。例えば、Amazon Athenaを使用すると、データをその場でクエリでき、BedrockとQuickSightを使用すると、データで知識ベースを作成できます。お客様が私たちに伝えているのは、ファイルデータをAWSに持ち込むことで、データの管理をよりシンプルにし、コストを削減するだけでなく、そのデータでより多くのことを行い、持ち込んでいるデータセットに含まれる価値を本当に引き出したいということです。
AWSが提供するクラウドネイティブサービスは数多くありますが、私が挙げたのはその中のいくつかの例に過ぎません。また、クラウドネイティブアプリケーションやサードパーティのISV製品も数多く存在しています。これらのサービスやアプリケーションの大部分は、歴史的にS3に保存されたデータと非常にうまく連携するように書かれてきました。これが、これらのアプリケーションやサービスの多くが動作するネイティブな方法なんです。お客様から非常に一貫したフィードバックをいただいています。お客様はデータでもっと多くのことをしたいと考えています。Amazonが提供する多くのアナリティクスサービスに大変興味を持っており、ファイルとオブジェクトの間でコピーするようなことをせずに、ファイルデータをこれらのサービスで簡単に使えるようにしたいと考えているのです。
そこで今年の初めに、私たちが実際にローンチしたのは、Amazon FSxとAmazon S3の統合でした。これは高レベルで言うと、FSxファイルシステムを使って、そのファイルシステム内のデータをS3サービス経由でアクセスできるようにするもので、まるでデータがS3バケットにあるかのように扱えるようになります。この統合をローンチした理由は、お客様がファイルストレージに保存しているデータを簡単に解放し、そのデータを非常に幅広いサービスやアプリケーションですぐに利用できるようにして、そのデータで本当にクールなクラウドネイティブなことをたくさんできるようにするためです。
今年の6月に、私たちはこれを初めてローンチしました。FSx for OpenZFSサービスにAmazon S3アクセスを追加しました。そして今週のre:Inventでは、FSx for NetApp ONTAPサービスにもS3アクセスを追加しました。では、これがどのように動作するのか、少し内部の仕組みをお見せしましょう。Amazon FSxファイルシステムでは、VPC内にこのファイルシステムを作成できます。標準のNFSまたはSMBクライアントを使用して、コンピュートインスタンスからファイルシステムにアクセスできます。このローンチによってこれらは何も変わりません。引き続き同じように行えます。しかし、そのデータで使いたいと思うかもしれないアナリティクス、AI、MLサービスが数多くあります。
この仕組みは、Amazon S3アクセスポイントと呼ばれる機能と統合しています。非常に高レベルで言うと、お伝えしたい主なことは、すべてのアクセスポイントにはエイリアスが関連付けられているということです。このエイリアスは、あらゆる意味でバケット名と同じです。バケット名やS3 URI、パスを指定するサービスを使用する場合、今できることは、FSxファイルシステムに接続されたS3アクセスポイントを作成し、S3バケットを使用する場所ならどこでも、そのアクセスポイントのエイリアスを使用できるということです。これにより、FSxデータをこれらのサービスに接続できるようになります。データがS3に保存されているかのように扱うだけでいいのです。
この統合の一部として明示的にお伝えしたいのは、データは引き続きFSxファイルシステム上に残るということです。NFSやSMBを通じてそのデータの読み書きを続けることができます。何も変わりません。データはS3との間でコピーされているわけではありません。これが本当に行っているのは、S3 APIアクセスを提供することです。つまり、FSxに保存されているデータにS3 API経由でアクセスできる機能を提供しているのです。
もう一つ申し上げたいのは、多くのお客様がデータセットをFSxに移行しているということです。データを移行し、アプリケーションを移行していますが、この機能により、そのデータをS3ベースのアプリケーションで簡単に使用できるようになります。FSx for NetApp ONTAPでよく見られる非常に興味深いユースケースとして、オンプレミスのワークロードやオンプレミスのアプリケーションを持っているお客様で、それらをクラウドに移行することがまだ意味をなさない段階にある場合、FSx for ONTAPをディザスタリカバリサイトの代替として使用することが一般的です。
お客様からよく聞くのは、プライマリサイトがあって、従来はセカンダリサイトのNetAppシステムにレプリケーションしていたものを、実際にそのセカンダリサイトをFSxファイルシステムに置き換えることができたということです。場合によっては、そのサイトを完全にシャットダウンして、全体的な管理負担を軽減できたケースもあります。今週、この新機能について多くのお客様と具体的にお話しし、どのように使用することを考えているかを議論しましたが、このローンチの本当にクールな側面は、FSxにデータをレプリケーションしている場合、FSxをデータのディザスタリカバリコピーとして使用している場合でも、そのDRコピーでアクセスポイントを使用して、データへの読み取り専用ビューを取得し、それをこれらのサービスの多くに接続できるということです。
つまり、これはオンプレミスに保持しているデータであっても、FSxにデータをレプリケーションし、それをDRコピーとして使用することで、そのセカンダリコピーに対して非常に興味深い分析を行うことができる、本当に面白い方法なのです。先ほど申し上げたように、S3と統合するサービスは数十種類あります。それらすべてを一つ一つ説明するつもりはありません。しかし、お客様との対話で最もよく出てくると思われる例として、一つ取り上げたいのは、データからナレッジベースを作成することです。
ストレージ管理者の方々とお話しすると、よくこう言われます。このオンプレミスのNASに大量のデータがあるのですが、アプリケーションユーザーやエンドユーザーから、自分のデータとチャットするにはどうすればいいか、どのようなデータを持っているかについてより良い洞察を得て、Gen AIを使ってより効果的に質問に答えるのに役立てるにはどうすればいいか、と聞かれます。このローンチによって実際に意味するのは、FSxにデータがある場合、そのための手順は、アクセスポイントを作成し、BedrockコンソールにアクセスしてこのS3 URI、つまりアクセスポイントエイリアスを使用してナレッジベースを作成したいと言い、チャンキング戦略を指定し、埋め込みモデルを指定し、ベクトルデータベースを選択します。これも今週ローンチされたAmazon S3 vectorsを使用できます。それだけです。
データの処理が完了すると、ファイルとオブジェクトの間でデータをコピーする必要なく、すぐに使用できるナレッジベースができあがります。データは、保存しているファイルシステムに置いたまま使い続けることができます。さらに、これはナレッジベースを作成するための非常に低コストな方法です。特にS3 vectorsのようなものを組み合わせると、高スループットのパフォーマンスが必要ない場合もあるかもしれませんが、始めるのに数千ドルではなく数百ドルで済むようになります。
この機能をさらに拡張するために、ファイルシステム上のS3アクセスポイントのパワーについてお話しします。AWS Transfer Familyというサービスがあります。驚くべきことに、30年前に構築されたプロトコルで、決して消えることのないものがたくさんあります。SFTPやFTPSのようなものは、企業同士がやり取りする方法であり、安全で監査可能な方法で行われています。これは市場データかもしれませんし、規制データかもしれませんし、医療データかもしれません。これらのサービスは企業全体に存在し、こうした一般的なタイプのデータについて、企業間で取引を行う主要な方法として今でも使われていることがわかります。
私たちはこのトレンドを見て、AWS Transfer Familyというサービスを作りました。これはマネージドサービスです。AWS Transfer Familyでは、私たちがすべてのセキュリティコンプライアンス、認証を担っています。サーバーを管理する必要もなく、ソフトウェアを管理する必要もなく、サービスの利用者になるだけでよいのです。そして、5年前のローンチ以来、急成長しているサービスです。私たちは常に開発者中心の視点を拡張していますので、イベント駆動型の自動化を作成できます。コードとして実行でき、マルウェア検出のフックも組み込まれているので、入ってくるものをスキャンできます。
これを少し進めると、今日、あるいはこのS3アクセスポイントのローンチ以前は、Transfer Familyの主要なターゲットとして、EFSかS3のどちらかに行くことになっていました。S3アクセスポイントのローンチにより、今ではリーチを拡張し、お客様がさまざまなファイルシステムを使用してこれを実行できるように統合を拡張できるようになりました。ひとつの疑問は、2つあるのに、なぜ3つ目が必要なのか、ということです。実は、お客様が特定のニーズのためにFSxを使用しているからです。ある金融サービス企業のお客様は、市場調査データにFSxを使用しており、サードパーティのデータでそれを強化し、研究者が使用して新しい洞察を導き出せるように、ファイルシステムに直接取り込みたいと考えていました。これにより、そのパラダイムを拡張することが本当に簡単になります。
レジリエンスの強化：多層防御戦略とデータ保護機能の拡充
レジリエンス、非常に重要なトピックです。今日の脅威の状況において、お客様からデータ保護はもはやオプションではなく、本当に不可欠であるとよく聞きます。これは、私たちが話をするお客様にとって重要な焦点領域であり、サービスチームとしての私たちにとっても非常に重要な焦点領域です。お客様が多層防御、深層防御戦略を簡単に実現し、さまざまな脅威から保護できるようにしたいと考えています。今日は、このスペースでデータを保護することをさらに簡単にするために、私たちが行った最近のローンチについてお話ししたいと思います。
その最初のものは、FSx for Windows File Serverファイルシステムに関するものです。わずか2週間前に、File Server Resource Manager、つまりFSRMと呼ばれるWindows Serverの機能のサポートを追加しました。これは、Windows Serverを使用してデータを管理するお客様にとって一般的に使用される機能であり、さまざまなストレージ、データ管理、保護機能を提供します。たとえば、ファイルシステム内のさまざまなフォルダにクォータを設定できます。コンテンツや他のプロパティに基づいて、ファイルシステム内のファイルを分類できます。また、ファイルシステムに書き込めるファイルをスクリーニングすることもできます。
例えば、特定のファイルシステムに.EXEファイルを保存したくないというルールを設定することができます。また、ファイルシステム内にどのような種類のデータがあるかのストレージレポートを生成して、FSx for Windowsに保存しているデータについてより深い洞察を得ることもできます。最後に、FSRMはWindows Serverの機能ではありますが、これをクラウド上のFSx for Windows File Serverに提供するにあたって、できる限りクラウドネイティブにしようと努めてきました。そのために、FSx for Windows File Server上のFSRMをKinesisやCloudWatch logsと実際に統合し、FSRMのログやイベントがこれらのクラウドネイティブアプリケーションで直接生成されるようにしました。
もう一つ、お客様からますます話題に上がっている非常に人気のある機能が、NetApp ONTAPで利用可能なアンチランサムウェア保護、つまりARPです。これは4月にFSx for ONTAPに提供した機能で、この機能をローンチした理由は、ランサムウェア攻撃について考えてみると、残念ながらお客様から発生した事象についてお話を伺うと、攻撃が発生したことに気づいた時にはすでに手遅れだったり、データの一部を取り戻すのが非常に困難だったりすることがあるからです。
そこでARPの目標、ONTAPのこの機能が行うことは、実際に有効化すると、ファイルシステムに加えられている変更を自動的にスキャンし、何か疑わしいことが起きていないかを検出しようとします。そして疑わしいことを検出すると、ファイルシステム上で自動的に対応を行い、自分自身を保護してデータを復元できるまでの時間を短縮します。
例えば、ファイルシステム内に大量の暗号化されたファイルが作成されていることを検出すると、自動的にスナップショットを作成することがあります。これは実際には簡単に削除できないロックされたスナップショットで、データのスナップショットとなり、アラートを生成したり追加の証拠を作成したりするように設定でき、何が起きたかについてより多くの情報を提供します。それに基づいて、何が起きたかを確認することができます。本当の攻撃であれば、そのスナップショットを復元して以前の状態に戻すことができます。しかし繰り返しになりますが、ここでの目標は本当に、システム上で何かが発生してから対応できるまでの時間を短縮し、追加の保護レイヤーを提供して、これらのランサムウェア攻撃の一部に対して本当に役立つようにすることです。
同様の方向性のもう一つの機能がSnapLockです。SnapLockは、数年前にFSx for ONTAPに提供したwrite once, read many、つまりWORM機能です。これは特定のボリュームの内容をロックして、その内容が時間の経過とともに変更されないようにするために実際に使用されます。SnapLockは、金融サービスやヘルスケアなどの規制の厳しい業界のお客様によって一般的に使用されており、また単にデータを保護する追加の方法を探しているお客様にも使用されています。SnapLockは、追加のランサムウェア保護戦略という文脈でよく話題に上がります。
FSx for ONTAPでは、2つの形式のSnapLockを提供しています。コンプライアンスモードは、厳しく規制された業界のお客様に最もよく使用されており、データをロックすると、そのデータ保持期限が切れるまで、本当に変更する方法がありません。そして、エンタープライズモードもあり、これは必要に応じて管理者がデータのロックを解除できる方法があり、これは主に内部ガバナンスの理由のために用意されています。これはFSx for ONTAPで非常によく使われている機能で、ランサムウェア対策のストーリーの一部としてよく使用されています。
今年の初めに、実際にFSx for ONTAPでSnapLockを完全に無料にしました。これはもともとONTAPでライセンス機能だったので、ストレージに対して支払う料金に加えて、この機能を使用する能力のために追加のライセンス料金を支払う必要がありました。そして、お客様と話をしていると、データの追加コピーを持ち、データを保護することは非常に重要であり、お客様が簡単にそれを行えるようにしたいという声をよく聞きました。これらの料金のために、お客様がデータを別のストレージソリューションにコピーして、コンプライアンス要件とTCO要件の両方を満たすために複雑なアーキテクチャを構築しようとすることもありました。そして、FSx for ONTAPでSnapLockの料金を削除することで、お客様ができることは、ファイルシステムにデータを置き、必要なデータをロックし、必要のないデータはロックしないということです。しかし、これを無料にすることで私たちが本当に目指しているのは、不変のデータコピーを持ちたいお客様のためにデータ保護アーキテクチャを簡素化することです。
では、話を変えて、AWS Backupについてお話しします。AWS BackupはAWSのネイティブサービスで、AWS内のすべてのステートフルサービスを保護します。また、EKSを保護する機能もあり、これは先週発表したばかりで、ステートフルコンテナ向けです。1年以上前に Logically Air-gapped Vaultsという機能をリリースしました。そこでのキーワードは「論理的」です。なぜなら、AWSではデータへのネットワークを完全に遮断することはできないからです。しかし、ここでの主な前提は、異なる権限セットとアクセスセットを持つ特別なボールトにデータをバックアップできるようにすることで、データが不変になるということです。そして、それはさまざまな脅威に対して不変です。つまり、rootユーザーでもデータを削除できず、データを復元するには特別な権限が必要で、アカウントが侵害された場合にResource Access Managerを通じて他のアカウントにデータを復元でき、最初に保護しているコアアカウントからデータを分離します。これは、多層防御の会話において人気のある機能で、データ保護のデータバックアップが侵害されることを心配することなく、何かが起こったかどうか、いつ起こったかを確認するために、別の分離されたアカウントで何らかのフォレンジック分析を行う際にそのデータを使用できるようにします。
これにはいくつかの機能強化もあります。GuardDutyとの統合が今週発表されたので、ボールトに入るデータを実際にスキャンできるようになりました。しかし、ここで発表したのは、 logically air-gapped vaultsを使ったTCOの改善です。
以前の主な動作方法は、データをバックアップする際に、まずバックアップのローカルコピーを作成し、次にそのデータのコピーをlogically air-gapped vaultに2番目のコピーとしてレプリケートする必要があり、つまり2つのデータコピーがありました。logically air-gapped vaultsでは、logically air-gapped vaultへの直接書き込みをサポートするようになったので、これらのデータコピーの1つを削除して、logically air-gapped vaultに直接データを書き込むことができます。これは、EFS、S3、およびFSxファイルシステムのすべてで機能しますが、ONTAPを除きます。しかし、ONTAPには、同じような多層防御機能を提供する他の機能の豊富さがすべてあります。
さらに、今年、アクセスポイントの機能強化を発表したのとほぼ同じ時期に、Amazon EFSのクロスアカウントレプリケーションも発表しました。バックアップは一つの方法ですが、例えばボールトにバックアップする場合、そのデータを別のアカウントで再び使用できるようにするには、リストアプロセスを経る必要があります。これは、RTOとRPOが要件を満たす多くのお客様にとっては素晴らしいものです。しかし、一部のお客様は、もっと速くフェイルオーバーする必要がある、災害を宣言した場合に備えて、別のリージョンにほぼスタンバイ状態のコピーを用意しておく必要がある、とおっしゃいます。
お客様からいただいたリクエストの一つは、リージョン間でレプリケーションできることだけではなく、これは1年以上前からサポートしていますが、アカウント間で権限構造を分離する安全な方法でそれを行う必要がある、ということです。つまり、何かが起こって災害を宣言した場合、それは障害やアプリケーションの問題かもしれませんが、アカウントが侵害された可能性もあります。ここで起こっていることが何であれ、セカンダリアカウントのこちら側では誰も同じことができないようにしたいのです。そこで今年の2月に、クロスアカウントレプリケーションを発表しました。これにより、これら2つのアカウント間で権限構造を物理的に分離し、セカンダリ側で異なる種類の権限モデルを確保できます。そして、同じことができます。フェイルオーバー、テスト、そしてデータをプライマリに戻すフェイルバックが可能です。ですので、DRシナリオの計画を行う場合、柔軟に実行できます。
データ移行の簡素化：Amazon Elastic VMware ServiceとFSx for ONTAPの統合
最後に、これが最後のトピックです。あと数分残っています。データ移行の簡素化についてお話しします。オンプレミスのVMware環境をどうするか、それをAWSに移行するにはどうすればいいか、あるいは移行して、その後将来的にモダナイゼーションを行う能力を設定するにはどうすればいいか、といった会話が多く行われていることに気づきました。これらのワークロードを移動する際、数年かかる複雑な取り組みになる可能性があるため、私たちが目指しているのは、できるだけ早くAWSに移行できるようにすることです。
発表を追っていただいた方はご存知かと思いますが、Amazon Elastic VMware Serviceというサービスを発表しました。これは、VMwareからVMwareへの最速のパスです。IPアドレスはそのまま、ネットワークアクセスもそのまま、権限もすべてそのままにできるため、その環境を移行するのが本当に簡単です。VMCのローンチ当時からお客様から聞いていたのは、「でも、オンプレミスで使っているエンタープライズストレージ、NetAppや他のエンタープライズストレージがあって、AWSに移行する際にも同じ機能が欲しい」ということでした。
嬉しいお知らせとして、Amazon Elastic VMware Serviceがローンチされた際、そのリリースと同時にAmazon FSx for ONTAPのサポートを発表しました。つまり、同じ運用モデルを維持しながら、ONTAPのすべてのメリットを得ることができるようになったのです。これには、VMDKを高速かつ瞬時に、できるだけ少ないスペースでクローンできるようにしたい、すべてのVMDKを重複排除して、できるだけ小さいスペースに保存したい、オンプレミスからクラウドにレプリケートしてDRシナリオを開始し、最終的にはVMwareネイティブツールを使用していない場合は移行を切り替えてすべてのVMを反対側で起動する、といったことが含まれます。つまり、VM環境を管理する際のエンタープライズ機能の多くを、シンプルで使いやすい方法で得ることができるのです。
最初から4つの異なるアクセスモードでサポートしています。NFSデータストアを使用されている方は、NFSを使用できます。NFSデータストアとして使用できます。iSCSI経由でブロックストアとして接続することもできますし、VMで直接処理したいデータセットがある場合は、NFSまたはSMB経由でVMに直接接続することもできます。
セットアップして稼働させるのは本当に簡単でシンプルです。これに対するサポートがあり、コンピュート負荷よりもデータ負荷が高いデータやワークロードがある場合に特に役立ちます。ソリューション全体のTCOのバランスを本当にうまく取ることができます。
FlexCacheのライトバックキャッシング：グローバル分散環境での書き込み性能の飛躍的向上
最後になりますが、FlexCacheです。ご存じない方のために説明しますと、FlexCacheは非常に人気のあるNetApp ONTAPの機能で、2つのONTAPシステムがある場合、一方をもう一方のローカルキャッシュとして構成できるというものです。FlexCacheはさまざまな方法で使用されているのをよく目にします。例えば、オンプレミスにオリジンがあり、オンプレミスのデータがある場合、お客様がクラウドにFSxファイルシステムを作成し、それをオンプレミスデータセットのクラウド内キャッシュとして使用しているケースを見かけます。その逆のケースもよく見られます。お客様がデータをFSxに移行し、オンプレミスから低レイテンシーアクセスが必要なユースケースがある場合、オンプレミスのNetAppシステムをそのクラウドデータのキャッシュとして使用します。
最後に、お客様が完全にクラウド内にいる場合、あるいはクラウドとオンプレミスの混在環境にいる場合で、地理的に分散したチームが全員同じデータにアクセスする必要がある、非常に興味深いユースケースを見かけます。米国とAPJ間でレプリケーションを行っているお客様がいて、世界中にチームが分散しており、これらの分散したリモートチームがいる場所にローカルキャッシュを配置することで、全員が同じデータを見ることができ、また場所に関係なくそのデータに対してかなり高速なパフォーマンスを得ることができます。
従来、FlexCacheは、データに対するいわゆるライトアラウンドキャッシュでした。これが意味するのは、データを読み取りに行く際、データがキャッシュにない場合、同期的にオリジンに行き、それをキャッシュに入れてから、クライアントに提供するということです。しかし、書き込みパスでは、同様のことを行います。クライアントがあり、この例では再びクラウド内のFSxファイルシステムとオンプレミスのオリジンについて話していますが、ライトアラウンドキャッシュを使用してデータに書き込みたい場合、実際に内部で起こることは、書き込みがクライアントに確認応答される前に、まずオンプレミスのオリジンに行かなければならないということです。
つまり、読み取り中心のワークロードであれば全く問題ないのですが、実際にデータを書き込もうとするワークロードの場合、オリジンまで戻る必要があるため、特にオリジンとキャッシュが地球上のかなり離れた場所にある場合、レイテンシが高くなる可能性があります。ネットワークの設定によっては、数十ミリ秒から数百ミリ秒になることもあります。 ONTAPがリリースし、今年の初めにFSx for ONTAPに導入した機能が、FlexCache向けのライトバックキャッシュ機能です。
ライトバックキャッシュが可能にすることは、データを読み取る場合、読み取りは全く同じように動作します。キャッシュヒットはキャッシュから提供され、キャッシュミスはオリジンに戻ります。しかし、ライトバックキャッシングでは、この機能を有効にすると、キャッシュにデータを書き込む際、そのキャッシュは実際にデータの整合性を確保するためにオリジンから必要なロックを取得しますが、それらの書き込みを保持し、クライアントがはるかに高速な書き込みパフォーマンスを得られるようにします。キャッシュは、クライアントが行っていることとは非同期に、必要に応じてデータをオリジンにフラッシュバックします。
この機能が可能にすることは、これらのワークロードの一部に対して、はるかに高速な書き込みパフォーマンスを得られるということです。なぜなら、書き込みがオリジンまで戻る必要がなくなるからです。繰り返しになりますが、オリジンはキャッシュから地球の反対側にある可能性があります。その代わりに、書き込みはクライアントからローカルキャッシュに直接行うことができ、場合によっては海を越える必要がありません。先ほど申し上げたように、これは今年の5月にFSx for ONTAPに導入した機能で、特にこのようなグローバル分散ネームスペースタイプのユースケースにおいて、多くのお客様から大きな関心と興奮をいただいています。
世界中にチームがいて、同じコアデータセットへのアクセスが必要だが、全員が低レイテンシでデータにアクセスしたいというケースを非常によく見かけます。これは、そのようなことをはるかに可能にする機能です。なぜなら、これらのローカルキャッシュを持つことで、高速な読み取りパフォーマンスと高速な書き込みパフォーマンスの両方を得ることができるからです。それでは、皆様のお時間をいただき、セッションにご参加いただきありがとうございました。 Christianと私は、後ほど質問がある方のために残りますので、ありがとうございました。それでは失礼します。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion