re:Invent 2024: AWSが解説するAmazon EFSの特長と機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Simple Elastic File Systems: A Deep Dive into Amazon EFS (STG344)
この動画では、Amazon Elastic File System (EFS)の主要な特長と機能について詳しく解説しています。EFSは設定不要で高可用性を備え、ペタバイト規模までスケール可能なサーバーレスファイルストレージです。読み取りスループット最大60GB/秒、書き込みスループット最大5GB/秒という高性能な特性に加え、EFS Standard、EFS Infrequent Access、EFS Archiveの3つのストレージクラスを組み合わせることで、最大95%のコスト削減を実現できます。また、AWS IAMやEFS Access Pointsを活用したセキュリティ制御、AWS Backupによる11ナインのデータ耐久性、EFS Replicationによるクロスリージョン/クロスアカウントのデータレプリケーションなど、エンタープライズ向けの充実した機能群を提供しています。QRTやSAPなどの実際の導入事例も紹介され、最後にはライブデモでEFSの実装方法が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EFSの概要と本セッションの目的
皆様、AWSのre:Inventで素晴らしい一週間をお過ごしのことと思います。ラスベガスでは、エキサイティングなイノベーションが次々と生まれています。本日は、Mandalay Bayで1時間のお時間を私たちと共に過ごしていただき、ありがとうございます。他の会場からは少し距離がありますので、皆様のご参加を心より感謝いたします。Amazon Elastic File Systemの詳細についてご紹介する本セッションへようこそ。私はEFSチームのSenior Product ManagerのYuffie Zhangです。本日はAlex Martineauと共にお話しさせていただきます。
本題に入る前に、木曜日の午後1時にもかかわらず、会場が満席になっていますので、皆様にお伺いしたいと思います。これまでに自分でFile Systemをセットアップして管理された経験のある方はいらっしゃいますか？ 何人かの手が挙がりましたね。サーバーやストレージインフラの設定・維持管理の運用負担や、特に成長に合わせてインフラをスケールアップすることの大変さを、よくご理解いただいているのではないでしょうか。次に、EFSを使用したことがある方や、私たちのプロダクトやサービスをご存知の方はいらっしゃいますか？素晴らしいですね。それなら、もう安心です。私たちが目指している「シンプルさ」と「柔軟性」の恩恵を既に受けていただいていることと思います。
本日は、皆様に以下の重要なポイントを持ち帰っていただきたいと思います。まず第一に、EFSは「シンプルで、すぐに使える」クラウドファイルストレージを提供し、ストレージの心配から解放されて、ビジネスの課題解決に専念できるようにします。第二に、EFSは豊富な機能セットを提供し、パフォーマンスの向上、コスト削減、セキュリティの確保を自動的に実現します。そして第三に、最も重要なこととして、最後にライブデモを通じて、これまでお話ししたことを実際にお見せします。
EFSの主要機能と統合性：シンプルさと柔軟性を追求
では、なぜEFSなのか、というところから始めましょう。Amazon Elastic File Systemは、4つの重要な特長を備えたサーバーレスで完全な弾力性を持つファイルストレージです。第一に、複雑な設定なしで、わずか数クリックで高可用性、耐久性、セキュリティを備えたFile Systemを構築できる「設定不要」という特長があります。第二に、「完全な弾力性を持つストレージ」として、アプリケーションを中断することなく、必要に応じてペタバイト規模までスケールできます。この容量をサポートするために、自前で設定しなければならないサーバーの数を想像してみてください。EFSを使えば、ストレージインフラの管理やパフォーマンスのプロビジョニングを気にすることなく、ファイルやデータを共有できます。第三に、「どこからでもアクセス可能」で、あらゆるタイプのAWSコンピュートやオンプレミスリソースと互換性があります。第四に、従量課金制のプライシングモデルを採用し、データアクセスパターンに基づいてコストを自動的に最適化するための機能を備えています。
AWSは、お客様が管理したい範囲に応じて、アプリケーションのモダナイゼーションのためのさまざまなコンピュートサービスを提供しています。Amazon EFSは、AWSのすべてのコンピュートサービスと統合できます。EC2から始めて自分で管理したいすべてのコントロールにアクセスすることも、AWS Lambdaを使って完全にサーバーレスにし、アプリケーションの構築だけに集中してその他すべてをAWSに任せることもできます。これは非常に強力な特長です。なぜなら、チームは自分たちが最も快適に感じる抽象化のレイヤーを選択できるからです。選択に応じて、AWSは必要なツール、サービス、APIを提供し、アプリケーションの構築をサポートします。
EFSは、クライアントの種類を問わず、数万台の同時接続をサポートしています。従来型のEC2サーバーはもちろん、自社管理のクラスターで稼働するコンテナ、Amazon ECS、Amazon EKS、AWS Fargateなどのコンテナサービス、さらにはAWS Lambdaで実行されるサーバーレス関数まで、幅広く対応しています。お客様はEFSを使用して、アプリケーションの状態を管理するための共有永続ストレージとして活用できます。また、AWS SageMakerでの利用も可能で、AWS Direct ConnectやAWS VPNを介してオンプレミス環境からEFSファイルシステムにアクセスすることもできます。
ここで、多くの皆様の関心事であるアプリケーションのモダナイゼーションについてお話ししましょう。お客様は通常、オンプレミスやEC2インスタンスで稼働している既存のアプリケーションを、コンテナ化やサーバーレス化、マイクロサービスベースのアーキテクチャへと移行することで、デプロイメントとオペレーションを簡素化していきます。EFSを活用したクラウドへの移行と成長について、お客様との対話で特に重要な点が2つあります。1つ目は、その始めやすさです。Amazon EFSは完全にサーバーレスで、ファイルストレージのためのインフラや容量を事前にプロビジョニングしたり管理したりする必要がありません。
さらに、お客様が特に注目しているのは、Amazon EFSがクラウド移行の過程でリスクを最小限に抑えられる点です。Amazon EFSへのアプリケーションのリフト＆シフトは、最小限の混乱で実現できます。現在NFSをバックエンドに使用しているアプリケーションをお持ちの場合、 Amazon EFSは、開発者やユーザーが慣れ親しんだものと同じタイプのインターフェースを提供します。
Amazon EFSはAmazon ECSおよびAmazon EKSとネイティブに統合されているため、共有ストレージや永続ストレージを必要とするアプリケーションを簡単にAWSに移行できます。Amazon EFSは、コンテナクラスター内のすべてのノードからファイルへの共有アクセスを提供し、ステートフルコンテナ向けの永続ボリューム、クラッシュ時の迅速なコンテナ復旧、アプリケーションの需要増加に応じた新規コンテナの迅速な起動やセルフサービスプロビジョニングモデルの実現など、 さまざまな機能を可能にします。Amazon EFSを使用することで、お客様はコンテナ間で永続ストレージを共有し、使用量に応じた料金を支払い、AWS IAM認証とアクセスポイントを使用してクラウドネイティブな方法でマルチテナント環境を作成・管理できます。
開発者がコンテナサービスでAmazon EFSをより簡単に使用できるように、EFS Container Storage Interface（CSI）ドライバーもリリースしています。これはGitHubでオープンソースプロジェクトとして公開されています。コンテナが新しいノードに再スケジュールされた場合、CSIドライバーが再起動時にボリュームが利用可能で接続されていることを保証するため、ファイルシステムの手動プロビジョニングが不要になります。これらのコンピューティングサービスに加えて、 Amazon EFSは、アクセス制御のためのAWS IAM、セキュリティのためのAWS KMS、監視のためのAmazon CloudWatchとAWS CloudTrail、より迅速な移行のためのAWS DataSync、追加のデータ保護のためのAWS Backupなど、多くのAWSネイティブサービスと統合されています。また、EFSクライアントの管理を簡素化するために、AWS Systems ManagerとのAmazon EFSの統合も実現しています。
EFSのパフォーマンスとコスト最適化：スループットモードと課金機能
まとめますと、Amazon EFSは、アプリケーションをAWSエコシステムに移行するお客様にとって、ファイルストレージとして自然な選択肢となります。Amazon EFSは直感的に使え、アプリケーションのLift and Shiftとクラウドでの成長を容易にします。次のセクションでは、ストレージのお客様が最も気にかけているパフォーマンスについてお話ししたいと思います。Amazon EFSは3つのスループットモードを提供しています。上のグラフでご覧いただけるように、アプリケーションやワークロードに最適なモードを柔軟に選択することができます。
まず、それぞれのモードについて説明します。1つ目は、ETと呼ばれるElastic throughputです。ETは通常、ほとんどのワークロードに最適なスループットモードで、最高のエクスペリエンスと最高のスループットスケーラビリティを提供します。2つ目は、Provisioned throughputモードで、より高いまたは一貫したスループットを必要とするワークロードに最適です。これにより、一貫性のある予測可能な課金が可能になります。3つ目は、Bursting throughputモードで、基本的なスループット要件を持つワークロードに適しています。Bursting throughputモードは、バーストクレジットの形でファイルシステムのストレージと連動し、ファイルシステムのサイズの増加に応じて自動的にスケールします。現在、多くのワークロードがスパイク的な性質を持つため、Elastic throughputモードがデフォルトかつ推奨されるスループットモードとなっています。
re:Invent 2022で発表した、私が特に興奮しているElastic throughputモードについてもう少し詳しくお話しします。これは、アプリケーションの要件に合わせて自動的にパフォーマンスをスケールするスループットモードです。このグラフのように、平均的には低いスループット要件で、予測不可能なパフォーマンスのピークを経験する可能性のあるスパイキーなワークロードの場合、例えば、Black Fridayのトラフィックを扱うeコマースプラットフォームや、Machine LearningまたはAnalyticsのユースケースをお持ちの場合、Elastic throughputはそのワークロードのために設計されています。マルチテナントファイルシステムとして、Amazon EFSは、プロビジョニングや固定費用なしで、数万台のサーバーのパフォーマンスへのアクセスを提供します。必要に応じてオンデマンドでパフォーマンスをスケールアップすることができます。
必要なときにグループ全体のリソースを活用できるメリットがあります。まとめると、パフォーマンスのニーズがわからない場合や不確かな場合、またはワークロードがスパイク的で予測不可能な性質を持つ場合は、デフォルトのElastic throughputモードから始めることをお勧めします。ワークロードをより良く理解するために、Cloud Metricsを監視して、ワークロードの平均対ピーク比を確認することができます。
アプリケーションが5%以下の平均対ピーク比を示している場合、Elastic throughputモードが適しています。ワークロードのパフォーマンス要件を把握している場合や、アプリケーションが一貫して高いレベルのスループットを必要とする場合（例えば、平均対ピーク比が5%以上の場合）は、Provisioned throughputモードを使用できます。ファイルシステムのストレージ量に応じてスケールするスループットが必要で、短時間だけより高いレベルのスループットにバーストする必要がある場合は、Bursting throughputモードを使用できます。
注意すべき点として、Bursting Throughputモードは上限スループットが低いということがあります。Bursting Throughputモードを使用した後にアプリケーションのパフォーマンスに制約がある場合（例えば、ファイルシステムに許可されたスループットの80%以上を使用している場合や、利用可能なバーストクレジットを使い果たしている場合など）、より高いサービス制限を得るためにProvisioned ThroughputモードまたはElastic Throughputモードへの切り替えを検討する必要があります。
私たちは、Amazon EFSのあらゆるタイプのワークロードに対するパフォーマンス向上に継続的に取り組んでいます。 2024年には、クライアントごとのスループットやIOPSなど、さまざまなパフォーマンス指標において、EFSのパフォーマンススケーラビリティを10倍以上向上させる5つの改善をリリースしました。現在のEFSのパフォーマンスの概要をご紹介します。 読み取りスループットは最大60ギガバイト/秒、書き込みスループットは最大5ギガバイト/秒をサポートしています。クライアントあたりのスループットは1.5ギガバイト/秒、読み取りIOPSは最大250万、書き込みIOPSは50万をサポートしています。これは私たちのチームが過去2年間、懸命に取り組んで実現した素晴らしい改善点であり、とても誇りに思っています。最近EFSをテストされていない方は、ぜひ試してみることをお勧めします。
次に、 EFSの課金機能によって総保有コストを削減する方法についてお話ししたいと思います。EFSには、 EFS Standard、EFS Infrequent Access、EFS Archiveの3つのストレージクラスがあります。EFS Standardは、アクティブで頻繁にアクセスされるデータに対してサブミリ秒のレイテンシーを提供するSSDストレージクラスです。EFS Infrequent AccessとEFS Archiveは、アクセス頻度の低いデータに対してEFS Standardと比較して低コストを実現します。特に、昨年リリースしたEFS Archiveは、年に数回以下しかアクセスされない長期保存用ファイルデータ向けのコスト最適化された新しいストレージクラスです。Infrequent AccessストレージクラスはStandardと比べて95%のコスト削減、ArchiveクラスはInfrequent Accessと比べて50%のコスト削減を実現します。
これら3つのストレージクラスと共に、EFS Intelligent TieringとEFS Lifecycle Managementという2つの機能があり、これらはファイルシステムのアクセスパターンを監視し、3つの異なるストレージクラス間でファイルを自動的に移動します。必要に応じて、3つの階層にまたがるすべてのデータは、アクセスパターンに基づいてアクティブデータと非アクティブデータが自動的にコスト最適化された単一のファイルシステムからアクセスできます。 Amazon EFS Lifecycle Managementについて詳しく見てみましょう。設定後、Lifecycle Managementポリシーに従ってアクセスされていないファイルは、1日、7日、14日から最大90日までの設定可能な期間後に、自動的にEFS StandardからInfrequent Access層またはArchive層に移動されます。データはファイルシステム内に残り、エンドユーザーやアプリケーションからアクセス可能ですが、はるかに安価な価格で保存されます。
EFS Intelligent Tieringは、ファイルデータを適切なストレージクラスに配置することで、アクセスパターンが変化するワークロードに対して自動的なコスト削減を実現します。適切なタイミングで適切なストレージクラスにファイルデータを配置することで、アクセスパターンを最適化できます。数ヶ月間アイドル状態だったデータが突然アクティブになった場合、自動的にStandardクラスに戻され、サブミリ秒のレイテンシーとSSDパフォーマンスStandardクラスが提供できるパフォーマンスの恩恵を受けることができます。例えば、数ヶ月間休止していたデータを使用して大規模な金融バックテストを実行する場合、Intelligent Tieringを使用すると、最初のアクセス後にこのデータはStandardに移行され、再びSSDレイテンシーでアクセスできるようになります。EFS Intelligent Tieringは、手動でデータを移動することなく、適切なタイミングでファイルデータを適切な場所に配置し、適切なパフォーマンスとコストを実現できるように設計されています。
まとめますと、EFSは自動的にコストを最適化できるように設計されています。EFSを使用することで、最低利用料金や手数料がなく使用分のみの支払いで済むため、TCOを大幅に削減できます。また、スループットモードの柔軟性を提供し、コスト当たりのパフォーマンスを最適化しています。さらに、あらゆるAWSコンピューティングモデルと大規模に連携できるように最適化されています。マルチAZアーキテクチャにより、クロスAZ料金を気にすることなく、任意のAZでコンピューティングを実行できます。また、コスト最適化されたストレージクラス、Intelligent Tiering、自動ライフサイクル管理により、ストレージコストを削減できます。独自のファイルシステムストレージインフラを運用する場合と比較したTCO分析を行うと、EFSは自前での運用と比べて90%もコスト効率が良いことがわかります。
EFSのセキュリティと可用性：データ保護とアクセス管理
ストレージにおける重要な側面として、可用性、耐久性、データ保護があります。EFSは高可用性と高耐久性を備えるように設計されており、99.99%のSLAと11ナインのデータ耐久性を提供します。この高い可用性と耐久性を実現するため、すべてのファイルとディレクトリは複数のAvailability Zone（AZ）にわたって冗長的に保存されます。Amazon EFSにデータを書き込む際、3つのAZにわたってデータが永続的に書き込まれるまで、その書き込みは確認されません。また、EFSファイルシステムは1つのAZが完全に失われても、他のAZで同じ品質のサービスを提供し続けることができます。
さらに一歩進んで、AWS Backupを使用してEFSファイルシステムをバックアップすることもできます。これにより、データは3つのAZに保存され、完全に独立したソフトウェアスタックを使用することで、物理インフラとソフトウェア実装の両方で多様性のある追加のデータ保護を実現します。EFSはAWS Backupとネイティブに統合されています。例えば、ユーザーによる誤削除やアプリケーションによる意図しない上書きからファイルシステムのデータを保護したり、EFSコンソールで数回クリックするだけ、あるいは簡単なEFS APIコールでファイルシステムをバックアップしたりすることができます。
また、EFS Replication という新機能により、同一または異なるAWSリージョン間で、ファイルシステムの最新のレプリカを簡単に維持することができます。新規または既存のファイルシステムに、同一のAWSアカウント内または別のAWSアカウントへレプリケーションすることが可能です。レプリケーションは非同期で行われ、数分のRTOとRPOを実現します。2023年には、プライマリファイルシステムとセカンダリファイルシステム間でレプリケーション設定の方向を切り替えることができるレプリケーションフェイルバック機能をリリースしました。EFS Replicationは増分変更のみをコピーすることで2つのファイルシステムを同期状態に保つため、災害復旧のフェイルバック時に全ファイルシステムをコピーする必要はありません。数週間前には、クロスアカウントレプリケーション機能をリリースし、別のAWSアカウントにファイルデータのレプリカを自動的に保持できるようになりました。これらの機能により、リージョンやアカウント間でEFSデータを同期するためのカスタマイズされたアクセスを設定する必要がなくなり、分散環境における回復力と信頼性が向上します。
レプリケーション機能について説明してきましたが、多くの内容を扱ってきましたが、ここで非常に重要なセキュリティについて話しましょう。共有ストレージにアプリケーションがアクセスする際、アイデンティティとプライバシーに関して2つの基本的な目標があります。1つ目は、ストレージが特定のクライアントセットからのみアクセス可能であることです。2つ目は、それらのクライアントが特定のデータにアクセスするための適切な認証情報と権限を持っていることです。
アプリケーションアクセスを管理する際のセキュリティ維持に役立つ2つの機能についてご紹介します。1つ目はEFS Access Pointsで、ファイルシステムとデータへのアプリケーション固有のエントリーポイントを簡単に提供する仕組みです。Access Pointsを使用することで、権限を同期し、そのAccess Pointを使用するすべての着信接続のアイデンティティを強制することで、権限の昇格を防ぐことができます。これは特に、明確なアイデンティティの概念がないServerless関数で非常に有用です。また、EFSとAWS Identity and Access Management (IAM)を組み合わせて使用することをお勧めします。IAMを使用すると、ファイルシステムの使用を管理するポリシーを設定できます。これらを組み合わせることで、どのユーザーがどのAccess Pointをどの権限で使用できるかを制限できます。
セキュリティのベストプラクティスをいくつかご紹介して、私のパートを締めくくりたいと思います。まず、AWS IAMポリシーとEFS Access Pointsを使用して、アプリケーションのファイルシステムへのアクセスを必ず制御してください。次に、VPCセキュリティグループルールを使用して、ファイルシステムへのネットワークアクセスを必ず制御してください。セキュリティグループルールはファイアウォールとして機能し、追加するすべてのルールがトラフィックの流れを定義します。EC2インスタンスとEFSマウントターゲットの両方にセキュリティグループルールを指定できます。最後に、EFSマウントヘルパーを使用して、転送中の暗号化と保管時の暗号化を必ず有効にすることをお勧めします。
次に、Alexに引き継いで、いくつかのユースケースと、これらすべてを簡単に実現できることをライブデモでお見せしたいと思います。 ここからは、EFSの一般的なユースケースについてお話ししましょう。特に、この2年間でお客様から大きな反響をいただいたコスト最適化に焦点を当てていきます。
私たちのお客様は、大規模なグローバルSaaSアプリケーションの運用から、Serverlessアプリケーションの設定ファイルの配布、DevOpsワークフローの実行まで、EFSを幅広く活用しています。EFSに適したワークロードは非常に多岐にわたり、このサービス上で実行される一般的な商用アプリケーションも含まれています。
EFSのコスト最適化されたストレージクラスが、実際のお客様のストレージコストの削減にどのように役立ったかを見てみましょう。最初の例は、イギリスを拠点とする定量的資産運用会社のQRTです。彼らは数百人のクオンツリサーチャーチーム全体で簡単に共有ストレージを提供するためにEFSを使用しています。ミッションクリティカルな研究ワークフローを遅らせることなく、コストを最適化する方法を模索していました。QRTはEFS IAとEFS Archiveへのライフサイクル管理を有効にし、EFSのコストを30%以上削減しました。データの階層化は、アクセス頻度の低い古いデータにのみ影響を与えたため、エンドユーザーへの影響や運用上の変更を必要とせずにこれらのコスト削減を実現できました。QRTは、チェックボックスをクリックしてEFSに作業を任せるだけで、ペタバイト規模のデータを移行することができました。
次に、SAP社の事例をご紹介します。SAPは、顧客に代わって管理しているRISE with SAPというSaaSソリューションの共有ファイルストレージとしてEFSを利用しています。QRT社と同様に、SAPも可用性やパフォーマンスに影響を与えることなくコストを最適化する方法を模索していました。
EFSのコスト最適化機能を活用し、アクセス頻度の低いデータにはEFSのコールドストレージクラスを利用することでコストを削減することができました。複雑なアプリケーションの再設計や、異なるストレージソリューションを組み合わせる必要もなく、2ペタバイト以上のデータをコールドストレージクラスに移行し、ストレージ料金を50%以上削減できたことは、 素晴らしい成果でした。
デモに移る前に、この30分ほどで共有した膨大な情報を振り返っておきたいと思います。これらは、EFSファイルシステムのベストプラクティスと設定です。これから行うデモでも、これらすべてを使用していきます。 このスライド1枚で、ファイルシステムを最適化するための、あるいはファイルシステム設定を始めるにあたっての、私たちのサービスチームからの推奨事項をまとめています。EFS Mount HelperクライアントソフトウェアとAccess Pointsを除いて、これらはすべてコンソールでデフォルトとして提供されています。ファイルシステムを作成すると、90%は完了しており、推奨されるベストプラクティスに到達するために必要なのは、EFS Mount Helperとアーキテクチャに基づいたAccess Pointsの設定という2つのステップだけです。デモに移る前に、より理解しやすく、写真に収めやすい形でこれを1枚のスライドにまとめてお見せしたかったのです。
EFSの実践デモ：ファイルシステムの作成からLambdaとの統合まで
それでは、デモモードに切り替えていきましょう。当初は、デモの動画スニペットをお見せする予定でしたが、木曜日の午後にデモの動画を見せるのはあまり面白くないので、私の個人のラップトップに切り替えてライブで実施することにしました。無謀な判断だと言われましたが、それでもより興味深いものになると思っています。デモの文脈を説明すると、まず下部にいる小さなユーザーから始めます。コンソールに接続してEFSファイルシステムを作成します。これにより、何万台ものサーバーに支えられたEFSクラスター内にデータ構造が作成され、EFSにデータを格納できるようにするためのネットワークルーティング設定が行われます。
次に、EC2インスタンスに移動して、そのファイルシステムにデータの書き込みを開始します。このデモは、お客様がよく使用する分析パターンをシミュレートします。データの発行者が1つまたは少数存在し、EFSに保存されたデータに対して複雑な分析を行う多数のコンシューマーが存在するというパターンです。デモの観点からもEFSの観点からも、ここでお見せするのは、ペタバイト規模のデータを保存し、何千ものインスタンス、Serverless関数、またはコンテナを通じてEFSにアクセスするお客様のケースと全く同じです。もちろん、ここでのコンピュートの処理は些細なものですが、皆様が日々取り組んでいる複雑なビジネスロジックを想像しながら、ご自身のビジネス課題にどのように適用できるか考えていただければと思います。
デモのセットアップに切り替えさせていただきます。 よし、うまくいきました！まず最初に、EFSコンソールに移動してファイルシステムを作成していきます。 ここでCustomizeボタンをクリックすると、先ほどのスライドで説明したすべての設定が事前に構成されているのがご覧いただけます。 ただし、実際にはQuick Createウィザードを使用すれば十分です。ファイルシステムに名前を付けてCreateをクリックするだけです。 すると、EFS側でデータ構造を作成し、AWS EC2ネットワーク上にネットワークルーティングリンクを構築するプロセスが開始されます。これには1分ほどかかります。その間に、先ほど説明した別の項目に触れていきましょう。
並行処理のデモンストレーションの一環としてAWS Lambdaを使用するため、EFS Access Pointが必要になります。 Access Pointを作成し、Lambdaという名前を付けます。このデモの目的では、ユーザーグループ、ルートディレクトリの作成、またはルートディレクトリパスのサブディレクトリ設定を入力する必要はありません。ただし、Access Point自体で実現したい目的に応じて、これらの設定はすべて利用可能です。
ファイルシステムの状態を確認してみましょう。 Networkタブを確認すると、Mount Targetがまだ作成中であることがわかります。問題ありません。ここでAttachボタンをクリックし、 EC2コンソールに移動する前に、ファイルシステムIDとマウントコマンドをコピーしておきます。 簡単に進めるため、Webベースのターミナルを使用して実行中のインスタンスに接続します。これにより、このデモが非常に簡単になります。接続されるまで待ちましょう。
最初に行うのは、 Amazon Linux 2023上にAmazon EFS Utilsをインストールすることです。これはAmazonのパブリックリポジトリでRPMとして提供されています。早速インストールしていきましょう。 このインストールにより、インスタンスで2つの機能が有効になります。1つ目は転送時の暗号化で、NFSクライアントからEFSへのリンクが暗号化されます。2つ目は、クライアントからEFSへのマルチパスを可能にすることで、クライアントあたり1.5ギガバイト/秒のスループット機能が有効になります。ここでインストールしたのは、NFSのconnectよりもEFSのコンテキストでより賢くEFS Mount Targetにマルチ接続する、非常に小さなオープンソースのプロキシです。
EFSコンソールに戻って、Mount Targetがすべて利用可能になっているか確認します。ターミナルに戻り、マウントコマンドを貼り付けて、データを生成します。 このデモでは、EFSマウントポイントに2ギガバイトのゼロデータを追加します。 次に、ファイル読み取りの並行処理を実装する簡単なPythonスクリプトを実行して、この単一のランダムファイルを読み取る能力を最大限に活用します。
EFSが登場する以前のクラウドでは、私たちが数回のコマンドで実現したことは、インスタンスの調達、ネットワークの設定、そして無制限のファイルシステムを構築するためのインフラ整備など、数ヶ月もの作業が必要でした。今では、わずか2、3分で実現できるようになり、ファイルストレージの利用において大幅な時間節約と俊敏性を実現しています。このファイルを複数回読み取り、インスタンスのネットワーク帯域幅の上限である毎秒1.5ギガバイトのスループットにほぼ到達することができました。すべてが正常に動作し、複雑な設定を必要とせずにEFSの最適なパフォーマンスレベルに到達できることを素早く実証できました。
次に、Lambdaコンソールに移動します。シンプルなLambda関数を用意しましたが、そのコードは非常にシンプルです。今回は異なるパス位置からファイルを読み取るだけで、これについては後ほど説明します。
これについては後で説明しますが、皆さんが直面しているビジネス上の課題に合わせて、もっと複雑なことを想像してみてください。ただし、Amazon EFS側の基本的な構成要素はまったく同じです。設定タブに移動し、ファイルシステムの設定パネルまでスクロールして、ファイルシステムとアクセスポイントを追加します。このファイルシステムにLambdaコンテナ内のローカルマウントポイントとして「STG 344」を指定し、保存して、Lambda側の関数を更新します。
次に、便利なCloudShellに移動して、AWS CLIコマンドを実行し、大量のLambdaを起動します。これは、多くのお客様が高度な並行分析ジョブを実行する際に、様々なコンピュートプラットフォームで行っていることとよく似ています。これらのLambdaをすべて実行すると、すべてが同時にEFSファイルシステムから読み取りを行います。毎秒数十ギガバイトという非常に高速なデータ読み取りを行いますが、EFS側で追加の設定や準備は必要ありません。
すべてが正常に動作し、このファイルシステムからのCloudWatchメトリクスが表示され始めています。数分間しかスループットを実行していないため、特に目立った動きはないかもしれませんが、EFSをアプリケーションの基本的な構成要素として素早く使用するために必要なすべての要素が揃っています。非常に優れた、安定したパフォーマンスを素早く簡単に実現できるため、お客様の作業が容易になり、インフラストラクチャの管理に時間を費やすことなく、実際のビジネス課題の解決に専念できます。
ご参加いただき、ありがとうございます。プレゼンテーション後、Yuffieと私は会場に数分間残っておりますので、皆様の具体的なユースケースについてのご質問や、EFSに関するご質問、あるいは単にご挨拶だけでも、お気軽にお声がけください。お会いできることを楽しみにしております。改めまして、にご参加いただき、本サービスについて学んでいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion