re:Invent 2024: AWSストレージサービスのコスト最適化ベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS storage best practices for cost optimization (STG210)
この動画では、AWSのストレージサービスにおけるコスト最適化のベストプラクティスを詳しく解説しています。Amazon EBS、FSx、EFS、S3という4つの主要なストレージサービスそれぞれについて、最適な使用シーンや具体的なコスト削減手法を紹介しています。例えば、EBSではgp2からgp3への移行で20%のコスト削減が可能なことや、S3ではIntelligent-Tieringの活用により40億ドル以上のコスト削減実績があることなど、具体的な数値とともに説明しています。また、T-MobileやJohnson & Johnsonなどの実際の導入事例も交えながら、ストレージクラスの選択やライフサイクルポリシーの活用など、すぐに実践できる最適化手法を網羅的に解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSストレージのコスト最適化：セッション概要
AWSのストレージにおけるコスト最適化のベストプラクティスについてのセッションへようこそ。私はAWS StorageのProduct Managerを務めるMatt Sidleyです。同じくAWS StorageのProduct ManagerであるArushi Gargと共同で発表させていただきます。本日は、お客様がオンプレミスからクラウドへ移行し、即座にコストメリットを得られる方法についてご説明します。その後、様々なAWSネイティブサービスを活用してさらにコストを削減する方法や、モニタリングや自動化などのツールを使用してストレージコストを削減する方法についてご紹介します。このプレゼンテーションを通じて、ストレージの適切なサイジングや、AWSサービスを使用した継続的な監視と効率化のための実践的な戦略を学んでいただけます。
本日のアジェンダを見ていきましょう。まず、オンプレミスからクラウドへの移行におけるコスト最適化と、そのメリットについてお話しします。次に、ワークロードに適したストレージの選択について説明します。AWSは目的に応じて設計された様々なストレージオプションを提供しています：Amazon S3、EBS、FSx、EFSなどです。これらはそれぞれ特定のユースケースのために設計されています。第三に、ワークロード用のサービスを選択した後、AWSのツールを使用してインフラストラクチャを継続的に測定、監視、改善し、最適なストレージ効率を実現する方法をご紹介します。各サービスに対応するツールの使い方や、これらのネイティブツールを使用してストレージコストを最大80%削減する方法をお伝えします。また、これらのツールを使用してストレージコストをさらに削減した実際のお客様の事例もご紹介します。
オンプレミスからクラウドへの移行：コスト最適化の始まり
まず、オンプレミスのストレージ管理について、そしてそれがしばしば過剰プロビジョニングと非効率性を伴う問題についてお話ししましょう。典型的な例を説明させていただきます。400テラバイトのストレージが必要だとします。しかし、将来の成長に備えて、前もって購入することになります。お客様とお話しする中で、通常は90日分、時には1年分まで先を見越して購入されているケースがあります。問題は、使用されずに待機している状態のストレージ容量に対しても支払いが発生することです。 RAIDの構成やフォーマット、ファイルシステムのセットアップを行うと、実際に購入する必要のある容量は1ペタバイトにまで膨れ上がる可能性があります。
この一般的な問題は、実際の使用量ではなく、予想される需要やフォーマットに基づいてプロビジョニングを行っていることです。AWSストレージでは状況が異なります。使用したストレージ分のみの支払いで済み、インフラストラクチャはデータニーズに応じて弾力的にスケールします。RAIDのオーバーヘッド、フォーマットによる損失、容量計画など、オンプレミスで管理する場合に必要な作業は、すべてAWSストレージが処理します。圧縮や重複排除などのAWSネイティブツールを使用すると、実際のストレージ使用量は予想よりも少なくなる可能性もあります。
ここで一歩下がって考えてみると、オンプレミスからクラウドへワークロードを移行する際のコスト最適化は、単なる移行の問題ではありません。これは実際には継続的なプロセスであり、一つの旅路なのです。最初はリフト＆シフトかもしれませんし、先ほど説明したようにある程度のコスト削減が実現できるかもしれません。しかし、それだけでなく、EC2インスタンスの適切なサイジングや、Amazon S3やEFSなどのマネージドサービスを使用したストレージの最適化を通じて、真のAWS最適化コストを実現することが重要です。これにより、より効率的で需要に応じて弾力的に成長できる、将来を見据えたコスト構造が実現できます。ここには多くのトピックがありますが、本セッションではストレージの最適化に焦点を当てて説明させていただきます。その他のトピックについては、別のセッションで詳しく学んでいただけます。
実例をご紹介しましょう。T-Mobileはオンプレミス環境を使用していましたが、新規プロジェクトによってスケーリングと性能に課題が生じていました。そこで、Amazon EFSというAWSのクラウドネイティブな elastic file serviceに移行することを決定しました。それまでのオンプレミス環境では、プロビジョニングと管理が必要でした。EFSに移行した結果、過剰なプロビジョニングが不要になり、EFSが提供するクラウドネイティブツールを活用できたことで、ストレージコストを最大70%削減することができました。さらに、ハードウェアの計画や導入を考慮する必要がなくなったため、新規プロジェクトの市場投入までの時間を短縮できるという独自のメリットも得られました。
Amazon EBSとFSx：高性能ストレージの最適化戦略
クラウドに移行した後、あるいはどのワークロードにどのサービスが適しているかを選択する際、4つの異なるサービスから選択することができます。これが特定のワークロードに対する最初の判断ポイントとなります。
それではサービスをご紹介しましょう。まず、Amazon EBSは、オンプレミスで実行されているようなSANワークロード向けに設計された高性能ブロックストレージです。SAP HANAやOracleなどのデータベースをサポートしています。次にAmazon FSxは、NASワークロード向けのフルマネージド型ファイルストレージです。NetApp ONTAP、Windowsファイルサーバー、OpenZFS、Lustreなどと同様の機能を提供し、特定のアプリケーションのニーズに対応します。他の環境で実行しているものと同様の機能を提供するため、移行が非常に簡単です。
Amazon EFSは、自動的に拡大・縮小するサーバーレスな伸縮自在のファイルストレージで、ユーザー共有やコンテンツ管理などの共有ファイルアクセスに最適です。そして最後になりますが、Amazon S3は、スケーラビリティと耐久性を重視して設計されたオブジェクトストレージで、アクセス頻度に基づいて自動的にデータを階層化するIntelligent-Tieringなどの機能を備えています。モダンなデータレイク、バックアップ、モバイルアプリケーションなどのユースケースの基盤となっています。これらのサービスはそれぞれ異なるストレージニーズに対応するように設計されているため、ワークロードに適したコスト効率、スケーラビリティ、性能を確保するために、適切なサービスを選択することが重要です。このプレゼンテーションでは、これらのサービスについて詳しく説明し、どのワークロードに適しているかを特定し、さらにそのサービスを使用する際のストレージコストの最適化方法についても説明していきます。
まずはAWSの高性能ブロックストレージであるAmazon EBSから見ていきましょう。 では、なぜEBSを選択するのでしょうか？多くの場合、既存のSANワークロードを持つお客様にとって、EBSは最適な選択肢となります。例えば、典型的なEBSワークロードには、MySQLのような関係データベース、MongoDBのようなNoSQLデータベース、Hadoopのようなビッグデータ分析、あるいはSAP HANAのようなエンタープライズアプリケーションがあります。これらのワークロードをお持ちの場合、EBSは優れた選択肢となります。ボリュームあたり最大256,000 IOPS、インスタンスあたり420,000 IOPSという最高レベルの性能を提供し、EBSは最も性能に敏感なワークロードでも、一貫してサブミリ秒のレイテンシーで処理することができます。
EBSストレージを効果的に管理しコストを最適化するには、適切なボリュームタイプを選択することが重要です。これは実際、EBSをワークロード用に選択した後の2番目の重要な決定となります。EBSは複数のボリュームタイプを提供しています：左側にあるgp2とgp3は、幅広いワークロードに適した汎用ボリュームタイプです。次にio1とio2があり、これらは高IOPSと低レイテンシーを必要とするミッションクリティカルなアプリケーション向けに設計されています。コスト最適化の観点では、st1とsc1がHDDベースのワークロード向けに低価格のオプションを提供しています。ST1はスループット最適化型で、データウェアハウスやログ処理に使用され、sc1はブロック形式で保存する必要があるアクセス頻度の低いワークロードやアーカイブワークロード向けに設計されています。
最も広く使用されているEBSのボリュームタイプであるgp2とgp3に焦点を当て、その違いを見ていきましょう。 gp2ボリュームでは、3,000 IOPSのベースラインパフォーマンスが提供され、必要に応じてより高いパフォーマンスにバーストすることができます。ただし、重要な考慮点として、パフォーマンスがボリュームサイズに紐付けられているため、ボリュームサイズ以上のパフォーマンスが必要な場合、オーバープロビジョニングにつながる可能性があります。一方、gp3ボリュームはこの問題を解決し、パフォーマンスをボリュームサイズから切り離しました。GP3はバーストモードを必要とせず、ボリュームあたり500 IOPSを提供し、高パフォーマンスワークロードに最適です。さらに、gp3はgp2の1GB-月あたり0.10ドルに対して0.08ドルと20%安価です。そのため、まず最初にお勧めすることの1つは、コストを削減し柔軟性を高める明確な方法として、gp2からgp3に移行することです。
Amazon EBSでのもう1つのコスト削減テクニックは、Elastic Volumesの使用です。Elastic Volumesは、運用に影響を与えることなくストレージを適応させることができる柔軟性を提供します。この機能により、必要に応じてボリュームサイズを増減できます。例えば、アプリケーションが突然より多くのストレージを必要とする場合、Elastic Volumesを使用して数分でそのボリュームを拡張できます。IOPSをより多くまたは少なく必要とする場合、パフォーマンス要件に合わせてIOPSを動的に調整でき、未使用の容量に対して過剰な支払いを避けることができます。Elastic Volumesではボリュームタイプの切り替えも可能です。高いパフォーマンスが必要な場合はgp3で開始し、そのデータが冷えたり、アプリケーションのパフォーマンス要件が下がった場合は、sc1などのHDDボリュームタイプに切り替えることができます。Elastic Volumesを使用することで、不必要なストレージコストの主な原因となるオーバープロビジョニングを避け、俊敏性を維持できます。
Devoは、Elastic Volumesの使用とgp2からgp3への移行の両方のテクニックを活用して、コストを削減した素晴らしい例です。まず、gp2からgp3に移行することで、ストレージコストを約20%削減しました。そして、アプリケーションのニーズの変化に応じてElastic Volumesを使用しています。彼らの方法は、SSDバックアップのボリュームタイプであるgp3で開始し、需要の低い期間にはHDDバックアップのsc1ボリュームタイプに切り替えるというものです。これにより大幅なコスト削減を実現し、ボリュームタイプの変更時にもダウンタイムはゼロでした。
EBSスナップショットを活用することでコストを削減することもできます。スナップショットはデータのインクリメンタルな時点コピーであり、ボリュームを簡単にバックアップする方法です。スナップショットには2種類あります。1つ目は標準スナップショットで、これは頻繁なバックアップや災害復旧に最適です。データを非常に素早く保存できるためです。一方、スナップショットアーカイブは、長期保存と低頻度アクセス向けに設計されており、標準スナップショットと比べて75%安価です。データをアーカイブ可能で、24〜72時間の復元時間を許容できる場合、Snapshots Archiveを使用することで、スナップショットのコストを最大75%削減できます。実例として、Johnson & Johnsonは、コンプライアンス上必要だったスナップショットをSnapshots Archiveに移行することで、100万ドル以上のコスト削減を実現しました。
Amazon EBSのコスト最適化に関する3つのベストプラクティスをまとめましょう。まず1つ目は、gp2からgp3への移行です。これは明確な利点があり、ストレージコストを最大20%削減できます。2つ目は、Elastic Volumesを使用してボリュームのサイズ、タイプ、パフォーマンスを変更し、パフォーマンスとストレージサイズを切り離すことです。これにより、必要な分だけを支払うことができます。3つ目は、スナップショットを使用する際、アクセスされなくなったボリュームがある場合は、Snapshots Archiveの使用を検討することです。これらの戦略により、EBSのパフォーマンスを最適化しながらストレージコストを最小限に抑えることができます。
Amazon EFS：サーバーレスで弾力的なファイルストレージの活用
ここで話題を変えて、NASワークロード向けの完全マネージド型ファイルサービスであるAmazon FSxについて説明します。まずAmazon FSxの背景について少しお話ししましょう。世界中の組織が、Network Attached Storage（NAS）上にエクサバイト規模のデータを保存しています。ファイルストレージは数十年の歴史があるため、オンプレミスで成長した成熟したNASファイルシステムソリューションが存在し、組織が長年にわたって導入・管理してきた多くの個別のファイルシステムがあります。組織がアジリティの向上、イノベーションの加速、またはコスト削減のためにオンプレミスからクラウドに移行する際、アプリケーションが依存しているこれらのファイルシステムを移行する方法が必要になります。これこそがAmazon FSxが実現したことであり、何千もの顧客がAWS上で完全マネージド型のNASファイルシステムを利用してクラウドへの移行を実現しています。
Windows環境向けにFSx for Windows File Serverを、NetApp ONTAPファイルシステムに依存する顧客向けにFSx for NetApp ONTAPを、そしてスケールアウトワークロード向けに特に重要なオープンソースファイルシステム向けにFSx for LustreとOpenZFSを構築しました。いずれの場合も、FSxソリューションはオンプレミス環境と同じ機能を持っているため、顧客はワークロードの再設計、ワークフローやプロセスの再構築、アプリケーションの再認証、ユーザーの再トレーニングを必要とせずに、オンプレミスのファイルデータをAWSに移行することができます。
FSxは幅広いコスト最適化機能を提供します。例えば、パフォーマンスを犠牲にすることなくストレージ使用量を削減するデータ圧縮と重複排除機能があります。また、シンプロビジョニングされたボリュームとストレージクォータにより、過剰なプロビジョニングを避けながら効率的にスペースを割り当てることができます。SSDとHDDのオプションを含むストレージタイプの選択肢や、可用性のニーズに応じてSingle-AZまたはMulti-AZ環境にデプロイする機能も備えています。自動データ階層化と動的スケーリングにより、進化するアプリケーションの要件にも対応できます。これらの機能により、既存のファイルシステムのワークロードをFSxに簡単に適応させることができます。
これらのコスト最適化機能を実践的に見ていきましょう。NetApp ONTAPとFSxがどのようにファイルワークロードを実現するのか、詳しく見ていきます。まず、FSx for ONTAPはインテリジェントな双方向データ階層化を提供します。これは、使用パターンに基づいて自動的にデータを階層間で移動することを意味します。アクティブな高性能データ用にサブミリ秒のレイテンシーを実現するSSDストレージがあり、さらにアクセス頻度の低いデータ用に低コストのCapacity Poolストレージがあり、これは自動的に拡大縮小してコストを最適化します。 私たちの調査では、お客様のデータの約20%がSSD階層に必要で、残りの80%はCapacity Poolストレージに置くべきであることがわかっています。
FSx for NetApp ONTAPは双方向の階層化を備えているため、ストレージはすべてSSD階層にあるように感じられますが、コストは大幅に抑えられています。 自動階層化により、アクセス頻度の低いデータをCapacity Poolに置くことで、通常ストレージコストの約3分の2を削減できます。 さらに、ONTAPはデータ圧縮と重複排除をサポートしており、これによりストレージコストをさらに3分の2削減することができます。 そのため、一般的なデータセットでは、SSD価格から実に88%のコスト削減が可能で、ギガバイトあたり月額3セントという低価格で利用できます。この価格で、フル管理型のMulti-AZ対応の機能豊富なファイルストレージが手に入ります。
Arcesiumは、先進的なフィナンシャルテクノロジーおよびプロフェッショナルサービス企業で、オンプレミスでNetApp ONTAPを管理していましたが、FSx for NetApp ONTAPでクラウドにインフラを移行することを決定しました。彼らも同様に、過剰プロビジョニングの課題を抱えており、パフォーマンスの問題も抱えていました。クラウドに移行した結果、ストレージコストが46%削減され、データベース速度が5倍向上し、ストレージのプロビジョニングを管理する必要がなくなったことでリフレッシュコストが80%削減されました。
興味深いことに、FSxファミリーのサービスの中で、多くのお客様がFSx for OpenZFSを選択しています。これは、既にOpenZFSを使用していたデータセットだけでなく、様々なオープンソースや商用のNASファイルシステムに保存されていたデータセットの移行先としても選ばれています。これには複数の理由があります。まず、FSx for OpenZFSは豊富なNAS機能を備えているため、オンプレミスで他のソリューションを使用していたお客様も、通常はオンプレミスでできることすべてをFSx for OpenZFSでクラウド上で実現できます。次に、高性能を目的として設計されており、これは組織がより高速で大規模なアプリケーションを構築する中で、ますます重要になってきています。第三に、OpenZFSはオープンソースであるため、ライセンスコストなしで、フル管理かつサポート付きのサービスのメリットを得ることができます。
これは商用ライセンスのオプションと比較して、30%以上優れた価格性能比を実現します。さらなるコスト削減を支援するため、数日前に発表された新機能についてご紹介できることを嬉しく思います。Amazon FSx for OpenZFSで利用可能になった新しいストレージクラス、FSx Intelligent-Tieringです。この新しいストレージクラスにより、FSx for OpenZFSは、NASの使い慣れた特徴と、完全な弾力性とインテリジェントな階層化を備えた初めてのフルマネージドストレージソリューションとなりました。これは、この後Arushiが詳しく説明するAmazon S3 Intelligent-Tieringストレージクラスをベースにしています。
Amazon S3ストレージを使用することで、ストレージは需要に応じて拡大・縮小する完全な弾力性を持ち、ストレージ容量を管理する必要がなくなり、予測不可能で急激な負荷の変動にも対応できます。データを頻繁アクセス層からアーカイブアクセス層まで、アクセス層間で自動的に移動させることでコストを最適化します。NASデータセットに最適な価格性能を提供するように設計されており、常にSSDストレージを必要としなかった大規模なNASデータセットをクラウドに移行することが可能になりました。
この新しいストレージクラスが、お客様のコスト最適化にどのように役立つのか、ご説明できることを大変楽しみにしています。FSx Intelligent-Tieringの価格設定についてお話ししましょう。Amazon S3 Intelligent-Tieringストレージクラスと同様に、データに対してギガバイト/月単位の料金が発生し、頻繁アクセス層では2.3セント/ギガバイト/月から始まります。その後、データが冷却され、階層が下がるにつれて0.4セント/ギガバイト/月まで下がります。Amazon S3 Intelligent-Tieringストレージクラスと同様に、層間のデータ移動をカバーするモニタリング自動化の料金が発生します。NASとして初めて、読み取りリクエストと書き込みリクエストに対して料金が発生します。これは、以前は特定のIOPS数をプロビジョニングしていたのとは異なり、データにアクセスした時のみ料金が発生するようになりました。
では、FSx Intelligent-Tieringはどのような場合に使用すべきでしょうか？現在、Intelligent-Tieringストレージクラスと、従来のプロビジョニングされたSSDの2つのデプロイメントタイプがあります。FSx Intelligent-Tieringは、ほとんどのワークロードに適した選択肢として考えるべきです。高性能ワークロードであっても、スペースが不足することはなく、ストレージ容量のプロビジョニングを心配する必要もありません。ただし、最低限のレイテンシーが必要な場合や、アクセスパターンがランダムになる可能性のあるワークロードの場合は、プロビジョニングされたSSDストレージクラスの使用を検討すべきです。例えば、EDAやシミュレーションのワークロードで、低レイテンシーと高性能が本当に必要な場合は、SSDが依然として適切な選択肢でしょう。しかし、パフォーマンス重視のワークロードを含むほとんどのワークロードでは、Intelligent-Tieringストレージクラスがデフォルトの選択肢となるべきです。
FSxセッションのまとめとして、ストレージ効率のベストプラクティスについてお話ししましょう。まず、FSxでストレージ効率を最大化するために、データ圧縮や重複排除などのネイティブツールを使用してください。次に、NetApp ONTAPを使用している場合は、データ階層化を使用してください。SSD層とCapacity Pool層の両方を活用することで、データ圧縮と重複排除と組み合わせると最大88%の節約が可能です。最後に、ライセンスコストを支払う必要がないため、NASワークロードで30%優れた価格性能比を実現できるFSx for OpenZFSの使用を検討すべきです。FSx Intelligent-Tieringをデフォルトの選択肢として使用することで、さらなる節約が可能です。
Amazon S3：多様なストレージクラスとIntelligent-Tieringの威力
それでは、EFSとAmazon S3について説明するArushiに引き継ぎたいと思います。Mattありがとうございます、皆さんこんにちは。Mattから、Amazon EBSやAmazon FSxでのコスト最適化の機会についてすでに学んでいただきました。では、Amazon EFSについて詳しく見ていきましょう。Amazon EFS（Elastic File System）は、モダンなアプリケーション開発者向けに設計された、クラウドネイティブで完全な弾力性を持つサーバーレスのファイルストレージサービスです。EFSの主要なユースケースについてお話ししますが、まずはAmazon EFSの主な特徴を理解することが重要です。
EFSの主な特徴について説明させていただきます。ご覧の通り、EFSは設定不要で、高可用性、耐久性、セキュリティが最初から備わっています。EFSの最も重要な特徴の一つは、完全な弾力性を持つことです。事前にストレージをプロビジョニングする必要がなく、データの増減に応じて自動的に拡大・縮小します。EFSはどこからでもアクセス可能で、AWSのコンピュート、サーバー機能、コンテナからアクセスできます。最後に、EFSは従量課金モデルでコスト最適化されており、使用した分だけ支払えば良いようになっています。また、EFSには後ほどご説明するコスト最適化ツールもあります。
EFSの主要なユースケースを考える際、最も重要なアプリケーションの一つは、複数のAmazon EC2コンピュートインスタンス間で共有できる弾力的なファイルシステムをホストすることです。これにより、ファイルやコードの共有が簡単になり、どこからでもアクセスできるため、開発者、エンジニア、研究者の作業が容易になります。また、EFSはコスト最適化されており、アーカイブデータや長期保存に最適化されたストレージクラスを備えているため、データの永続化にも利用できます。さらに、EFSは完全な弾力性を持ち、ストレージのプロビジョニングを自動的に処理するため、ファイルデータの作成、変更、削除を頻繁に行うアプリケーションに最適です。
EFSが提供するストレージクラスについて詳しく見ていきましょう。クラウドストレージを使用する際の重要な決定の一つは、適切なストレージクラスを選択することです。各クラスは特定のワークロードに合わせて設計されており、最適な価格性能を提供します。EFS Standard は、データに頻繁にアクセスするワークロードに使用できます。このストレージクラスは最高のパフォーマンスを提供し、AWSのコンピュート、コンテナ、サービスワークロードとシームレスに統合されます。データへのアクセス頻度が低い場合は、EFS Infrequent Accessストレージクラスを使用できます。最小限のアクセスで長期間保存する必要があるデータには、EFS Archiveストレージクラスが適しています。これはEFSポートフォリオの中で最も低コストなオプションです。
通常、データは最初EFS Standardクラスで頻繁にアクセスされます。例えば、メディア処理アプリケーションでメディアファイルに頻繁にアクセスする場合などです。時間が経過して処理が完了すると、頻繁なアクセスが不要になり、その時点でInfrequent Access、そしてEFS Archiveに移行したいと考えるでしょう。これを手動で行う必要はありません。なぜなら、EFSライフサイクルポリシーというコスト最適化ツールがあるからです。EFSライフサイクルポリシーでは、EFSが自動的にこれらのストレージクラス間でデータを移動します。30日以内にInfrequent Accessに移動し、90日後にはEFS Archiveに移動します。また、データがアクセスされた際に元に戻すライフサイクルポリシーを作成することもでき、データの使用パターンに合ったストレージクラスにのみ料金を支払うことができます。
ストレージクラスの最適化の次に検討できる要素は、スループットモードです。この点についても、EFSは充実した選択肢を用意しています。 一貫して高いスループットが必要なアプリケーションをお使いの場合は、Provisioned Throughputモードの活用をご検討ください。このモードでは、アプリケーションに必要なスループットを事前に決定して設定することができます。
このモードは、最高のパフォーマンスを必要とするデータ集約型アプリケーションに最適です。というのも、このスループットモードは高いスループット対ストレージ比を提供するからです。ただし、スループット要件が不明な場合や、時間とともに変化する場合は、Elastic Throughputモードの活用をお勧めします。実際、これが現在のデフォルトのスループットモードとなっています。
Elastic Throughputモードは、データの増減に応じて自動的にスループットを調整するため、パフォーマンス要件が予測できないワークロードに最適です。 ここで、Johnson & Johnsonの実際の成功事例をご紹介させていただきます。同社は、数百テラバイトのデータを共有・分析できるスケーラブルなソリューションを探していました。科学者たちがゲノミクスや創薬の分析を行えるよう、拡張性の高いストレージソリューションと、高度な計算能力の両方を求めていました。Amazon EFSを活用した結果、より迅速なインサイトの獲得が可能となり、分析時間を37%削減することができました。これだけでも、計算コストの面で大きな成果です。さらに、Amazon EFSのライフサイクル管理ポリシーを使用して、StandardストレージクラスとInfrequent Accessストレージクラス間でデータを移行することで、最大35%のコスト削減を実現しました。これらは非常に印象的な結果です。ファイルデータをお持ちの方は、ぜひこれらのツールをご検討いただければと思います。
では、ここまでに学んだAmazon EFSのベストプラクティスをまとめてみましょう。まず最初のステップは、常にワークロードに適したストレージクラスを選択することです。頻繁にアクセスするデータがある場合は、Standardストレージクラスを活用できますが、頻繁にアクセスしない場合は必ずしもその必要はありません。めったにアクセスしないデータには、より低コストなストレージクラスであるAmazon EFS Archiveの活用をお勧めします。次に、ライフサイクル管理ポリシーを設定しましょう。これにより、Amazon EFSが自動的にストレージクラス間でデータを移動し、ストレージコストの削減を実現します。最後に、最適なスループットモードを選択します。常に最高のパフォーマンスが必要な場合はProvisioned Throughputモードを、ジョブの実行時間中のスループット要件が不明な場合や変動する場合は、Elastic Throughputモードの活用をご検討ください。
これらのベストプラクティスに従うことで、ストレージコストとパフォーマンス要件を適切に調整することができます。では次に、AWSのオブジェクトストレージであるAmazon S3（Amazon Simple Storage Service）についてお話ししましょう。Amazon S3は、データレイクの構築、バックアップやリストア、さらにはジェネレーティブAIアプリケーション用のデータ保存にも活用できます。Amazon EFSと同様に、コスト最適化の第一歩はここでも適切なストレージクラスの選択です。各ストレージクラスは、 特定のワークロードに最適なコストとパフォーマンスを提供できるよう設計されているからです。まずは画面左側に表示されている最初のストレージクラス、S3 Express One Zoneからご説明しましょう。これは昨年リリースした高性能ストレージクラスで、一貫して一桁ミリ秒台のレイテンシーを実現します。他のストレージクラスと比べてデータの保存コストは若干高くなりますが、MLトレーニングジョブやデータ分析ジョブなどの高性能ワークロードを実行する場合、実はこれが最もコストの低いストレージソリューションとなる可能性があります。というのも、このようなワークロードでは、通常お客様は高価なGPインスタンスを使用する傾向にあるため、計算コストの削減が最も重要な要素となるからです。
S3のコスト最適化ツール：ライフサイクルポリシーとStorage Lens
次は、S3 Intelligent-Tieringについて見ていきましょう。S3 Intelligent-Tieringを使用していない場合、先ほどMattがFSxのセクションで説明したように、ストレージコストを削減する最も効果的な方法の1つかもしれません。この点については、後ほど数枚のスライドでも触れる予定です。
まず、S3 Standardについてお話ししたいと思います。これはS3で最も一般的に使用されているストレージクラスの1つです。頻繁にアクセスされるデータがあり、アプリケーションが1桁ミリ秒をわずかに超えるレイテンシーを許容できる場合は、S3 Standardの使用を検討すべきです。これは、データ取り出し料金がなく、最小保持期間もなく、最小課金対象オブジェクトサイズの制限もないためです。
右に進むにつれて、コールドストレージクラスに移行していきます。これは、これらのストレージクラスでのデータ保存コストは低くなりますが、データの取り出しコストは徐々に高くなり、取り出しにかかる時間も長くなることを意味します。ストレージクラスの名前を見ると、Glacierという名前が付いているものは、アーカイブデータ、つまりめったにアクセスされないデータ向けに設計されています。パフォーマンスの面では、S3 Glacier Instant Retrievalストレージクラスは、S3 Standardと同様のミリ秒単位のパフォーマンスを持っていますが、S3 Glacier Flexible RetrievalとS3 Glacier Deep Archiveストレージクラスは非同期ストレージクラスです。つまり、これらからデータを取り出すには2段階のプロセスが必要で、数分から数時間かかります。
適切なストレージクラスを選択するには、いくつかの要因を考慮する必要があります。まず、アクセス頻度です。最も冷たいストレージクラスの低コストと、より高いリクエストおよび取り出し料金のバランスを取るために、アプリケーションがそのストレージクラスからデータにアクセスする頻度を理解することが重要です。次に保持期間です。データが移動または削除される前に、そのストレージクラスにどれくらいの期間留まるかということです。最後に取り出し時間で、アプリケーションがデータにアクセスしようとする際にどれくらい待てるかということです。例えば、S3 Glacier Deep Archiveにオブジェクトを保存するコストは、S3 Glacier Instant Retrievalに保存するよりも75%低くなりますが、S3 Glacier Deep Archiveではデータの取り出しに数分から数時間かかることを覚えておいてください。
これは多くの情報だと思われるかもしれません。アプリケーションのアクセスパターンがわからない場合はどうすればよいのでしょうか？予測不可能、不明、または変化する場合もあるでしょう。実際、ほとんどのワークロードがそのようなシナリオに該当し、そこでS3 Intelligent-Tieringが解決策となります。S3 Intelligent-Tieringは、多くのホットアクセス層とコールドアクセス層を含む様々なアクセス層で構成されており、オブジェクトの最終アクセス日に基づいて、データをホット層からコールド層に自動的に移動します。この移行はオブジェクトレベルで行われ、オブジェクトは頻繁アクセス層から始まり、30日間アクセスがない場合は低頻度アクセス層に移動し、60日後にはアーカイブインスタントアクセス層に移動します。
オプションとして2つの追加階層があり、Intelligent-Tieringがデータをこれらのアクセス階層に移行するまでの待機時間を柔軟に選択できます。パフォーマンスに関しては、最初の3つのアクセス階層はS3 Standardと同様のミリ秒単位のパフォーマンスを提供しますが、アーカイブアクセス階層とディープアーカイブアクセス階層はS3 Glacier Flexible RetrievalとS3 Glacier Deep Archiveと同様のパフォーマンスを提供します。コストに関しては、これらの階層間でデータが移動する際の移行料金はありませんが、Intelligent-Tiering特有の少額のモニタリング料金が発生します。ただし、128キロバイト未満のオブジェクトについては、これらが階層を移動することなく常にFrequent Access階層に留まるため、モニタリング料金は発生しません。
2018年のIntelligent-Tiering開始以来、お客様はS3 Intelligent-Tieringによる自動的なストレージインフラ管理により、40億ドル以上のコスト削減を実現しています。これは非常に心強い結果です。お客様がS3ストレージアーキテクチャを手動で管理する必要がなく、その節約分を事業に還元できているということがわかったからです。既に不明または変動するアクセスパターンについて説明しましたが、もしアクセスパターンが既に把握できている場合はどうでしょうか？その場合は、おそらくストレージクラス間でのデータ移動についてより明示的で適切な選択ができるでしょう。
コスト削減のために、Amazon EFSで説明したものと同様のライフサイクルポリシーというコスト最適化ツールがあります。ライフサイクルポリシーは、Amazon S3がデータグループに適用するルールで、2種類のアクションがあります。1つ目は、データをホットストレージクラスからコールドストレージクラスに移動する移行アクション、もう1つはデータを削除する有効期限アクションです。ライフサイクルポリシーはオブジェクトの経過時間に基づいてトリガーされます。
ライフサイクルポリシーでは移行料金が発生することを覚えておいてください。移行コストは移行先のストレージクラスによって異なり、よりコールドなストレージクラスほど移行料金が高くなります。ここで重要な注意点があります：移行料金はオブジェクトごとに発生し、オブジェクトのサイズには依存しません。プロのヒントとして、ライフサイクルポリシーでデータを移動する場合、データをまとめてより大きなオブジェクトを作成することで、コールドストレージクラスへのデータ移行コストを抑えることができます。ライフサイクルポリシーでは、プレフィックス、オブジェクトタグ、オブジェクトサイズでフィルタリングができます。また、ストレージコストを節約するために、未完了のマルチパートアップロードを削除することもできます。
例を挙げてみましょう。移行料金はオブジェクトのサイズではなくオブジェクト数のみに基づくため、ライフサイクルフィルターを追加して特定のサイズより大きいオブジェクトのみを移行することができます。そうすることで最大の利点を得ることができます。実例を紹介しましょう：Illuminaは、ライフサイエンス研究とゲノミクスにおける画期的な進歩を実現しています。S3 Intelligent-TieringとライフサイクルポリシーをわずかS3か月使用しただけで、ストレージコストを60%削減することができました。
ストレージクラスについて、そしてワークロードのタイプに基づいてどのように選択するかについてお話ししました。しかし、現在行っていることの影響をどのように把握すればよいのでしょうか？そもそも、何か変更が必要だということを今日どうやって知ることができるのでしょうか？見えないものは変えられません。そのため、データから洞察を得る必要があり、ここでAmazon S3 Storage Lensが重要な役割を果たします。S3 Storage Lensは、お客様のS3ストレージの全体像を組織レベルで把握するために、最初に使用することをお勧めしているツールです。コスト最適化の機会を可視化するだけでなく、データ保護、アクセス制御、パフォーマンス最適化の機会も提供します。
S3 Storage Lensは、すべての方に使っていただきたいツールです。その理由をご説明しましょう。まず、データの可視化に使える28個の無料メトリクスが用意されています。低コストのコールドストレージクラスをすでに使用しているかどうかを簡単に確認でき、使用していない場合は使い始めることができます。より詳細な傾向分析のための履歴データなど、より優れた機能を提供する35個の高度なメトリクスにアップグレードすることも可能です。また、Storage Lensでは、さまざまな集計レベルでメトリクスを確認できます。組織レベルから始めて、アカウントレベル、リージョンレベル、さらにはプレフィックスレベルまで掘り下げて、最も効果的な意思決定を行うことができます。
S3 Storage Lensグループを使用すると、メトリクスの集計レベルをカスタマイズできます。例えば、オブジェクトタグ、オブジェクトサイズ、ファイル拡張子、プレフィックスに基づいてカスタマイズできます。ファイル拡張子に基づいてメトリクスをカスタマイズして集計すると、バケット内にどのような種類のデータが存在するかを把握できます。例えば、バケット内に多くのログファイルが存在することが分かった場合、それは重要な洞察となります。数ヶ月後にはログファイルにアクセスしないことが分かっている場合、ライフサイクルポリシーを設定してデータをコールドストレージクラスに移動させることができます。
実際の例をご紹介しましょう。Upstoxはインドの主要なディスカウントブローカーで、1,100万人以上の顧客に投資のためのデジタルプラットフォームを提供しています。UpstoxはS3 Storage Lensの高度なメトリクスを使用してストレージコストを最適化しています。
Upstoxは、S3 Storage Lensの高度なメトリクスを他のAWSサービスと組み合わせて使用し、ストレージコストを削減しました。その結果、年間100万ドル以上のコスト削減を実現しました。主な要因は、アクセス頻度の低いデータを特定し、ライフサイクルポリシーを使用してGlacier Instant Retrievalストレージクラスに移行したことでした。以上でAmazon S3のセクションを終わります。
AWSストレージコスト最適化：ベストプラクティスと今後の学習
これまで説明してきたベストプラクティスをまとめてみましょう。まず、データのアクセス頻度、オブジェクトサイズ、データ保持要件に基づいて、Amazon S3ポートフォリオから適切なストレージクラスを選択します。ワークロードのアクセスパターンが不明な場合は、S3 Intelligent-Tieringを活用することで、ストレージアーキテクチャを自動的に管理し、データをよりコールドなストレージ層に移行することができます。実際、これはほとんどのワークロードに適しており、アクセスパターンが不明な場合の最適な選択肢となります。ワークロードのアクセスパターンを把握している場合は、ライフサイクルポリシーを活用して、データをよりコールドなストレージクラスに移行したり、データを期限切れにしたりすることでコストを削減できます。
最後に、S3 Storage Lensを使用して、バケット、バケットポリシー、アクセスパターン、オブジェクトサイズについてより詳しい可視性を得ることができます。これらはすべて、データに基づいたより良い意思決定を行い、最終的にストレージコストを削減するのに役立ちます。このセッションも終わりに近づいてきましたが、AWSでストレージコストを最適化するための選択肢を絞り込む方法や、今日から使える実践的なヒントを学んでいただけたと思います。このQRコードをスキャンすると、AWSストレージトレーニングを始めることができます。モバイルアプリでアンケートにご記入ください。私たちは皆様からのフィードバックをすべて確認し、今後のセッション改善に活用させていただきます。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion