re:Invent 2024: AWSのAmazon EBSで高負荷ワークロードの性能最大化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Maximizing performance for high-intensity workloads using Amazon EBS (STG329)
この動画では、Amazon EBSのパフォーマンスと最適化について詳しく解説しています。特にio2 Block Expressの性能に焦点を当て、256,000 IOPSと4,000MB/秒のスループット、99.999%の耐久性を提供する特徴を説明しています。Epic EHRやSAP HANAなどの実際のユースケースを通じて、高IOPSや高スループットが必要なミッションクリティカルなワークロードでの活用方法を紹介しています。また、CloudWatchメトリクスやNVMe Driverを通じたパフォーマンス監視の新機能、複数ボリュームのストライピングによる性能向上テクニックなど、実践的な運用のポイントも詳しく解説しています。McAfeeの事例では、io2 Block Expressへの移行により30%のパフォーマンス向上や81%のレポート時間短縮を達成した具体的な成果も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EBSの概要と本セッションの目的
みなさん、光が1マイクロ秒でどれくらい進むか知っている方は手を挙げてください。もちろん私には見えませんが、誰かが手を挙げていることを願っています。真空中、つまり実質的に空気中では300メートルまたは981フィートです。光ファイバー内では約30%遅くなり、1マイクロ秒で700フィートつまり230メートルになります。これは物理法則なので、どうしようもなく重要な事実なのです。特に、レイテンシーを他社以上に重視する企業があります。高頻度取引業者が最も良い例です。彼らは証券取引所にできるだけ近い場所にシステムを配置し、取引所は公平性を確保するために、全ての業者が全く同じ長さと距離になるように光ファイバーを配線しているほどです。
彼らは取引所間にマイクロ波中継ネットワークを構築するために何億ドルも投資し、光ファイバーの速度ではなく実際の光速で通信できるように、その30%の速度差を取り戻そうとしています。ロンドンとニューヨークを結ぶために大西洋を横断するポンツーンネットワークを建設している企業もあります。ストレージの分野でも、私たちはレイテンシーを重視しています。Amazon Elastic Block Store（EBS）は大規模な分散システムで、特に私たちのAvailability ZoneやRegionはかなり大きいため、光ファイバーの長さや距離といった要素を考慮する必要があります。今日は、パフォーマンスを最大限に引き出す方法、EBSへの投資を活用する方法、そしてAmazon EBS上で最も高性能で高負荷なワークロードを実行する方法についてお話しします。私はEBSのPrincipal Storage Solutions ArchitectのKirill Davydychevです。私はEBSのSoftware Development ManagerのSunita Singhです。
では、本日のアジェンダについて詳しく見ていきましょう。まずAmazon EBSの概要について説明し、次にio2 Block Expressという特定のボリュームタイプについて詳しく掘り下げます。その後、Epic、SAP HANA、データベースに関する実際の業界事例を紹介し、io2 Block Expressがこれらのユースケースの課題をどのように解決したかを説明します。最後に質疑応答の時間を設けています。
EBSボリュームタイプとio2 Block Expressの特徴
EBSストレージは、ほとんどのワークロードに対して高い耐久性、可用性、そして高性能を提供します。EC2インスタンスにアタッチでき、EC2インスタンスのライフサイクルとは独立して永続化されます。EBSのポートフォリオには、EBSボリューム、Snapshot、そしてデータサービスがあります。Snapshotは、災害復旧やバックアップデータ保護のユースケースのために、ボリュームのポイントインタイムコピーを提供します。データサービスは、Elastic Volumes、Fast Snapshot Restore、Data Lifecycle Managementなど、ボリュームを最適化したり効率化したりするサービスを提供します。ただし、今日は主にEBSボリュームに焦点を当てていきます。EBSボリュームにはSSDベースとHDDベースがあり、SSDの中では次のスライドで詳しく説明するgp3とio2 Block Expressがあります。
EBSは実に様々なワークロードに対応できるよう設計されています。お客様は、ワークロードに適したボリュームタイプを柔軟に選択することができます。EBSでは一方で、データベースのユースケースのような高いIOPSを必要とする高トランザクションワークロードがあり、他方でSAP HANAのような高スループットのユースケースがあります。これらに対応するため、私たちは様々なボリュームタイプを提供しています。迷った場合は、gp3から始めることをお勧めします。gp3は最も人気のある汎用ボリュームで、最も一般的に使用されています。
3,000 IOPSと125メガバイト/秒のスループットという基本的なパフォーマンスを提供します。gp3で始めて、より高いIOPS、スループット、またはストレージ容量が必要になった場合は、Elastic Volumesサービスを使用してボリュームを変更し、これらの値をスケールアップすることが可能です。
さまざまなボリュームタイプのパフォーマンス特性についてより詳しく説明しますと、 gp3はほとんどのワークロードに最適です。io2 Block Expressは、非常に高いIOPSを必要とするミッションクリティカルなワークロード向けに設計されています。io2 Block Expressは256,000 IOPSを提供し、4,000メガバイト/秒のスループットを実現します。また、当社が提供するボリュームタイプの中で最高の99.999%の耐久性を備えており、アプリケーションのダウンタイムを最小限に抑えることができます。io2 Block Expressは、ワークロードに対して一貫してサブミリ秒台のレイテンシーを実現するため、まさにミッションクリティカルなワークロードに適しています。
昨年のre:Inventでの発表を見逃した方のために説明しますと、io2 Block ExpressがすべてのNitroインスタンスをサポートするようになりました。io1とio2を比較すると、io2はio1ボリュームの4倍のスループットと最大IOPSを提供します。100倍の耐久性があり、大量のI/Oを処理する場合は50%安価です。io1を使用している場合、io2 Block Expressにアップグレードしない理由はありません。
Epicの事例：高IOPS要件への対応
ここで、業界の実例をいくつか詳しく見ていきましょう。 需要と企業の合併・買収により、ヘルスケア業界は急速に成長しており、これらのワークロードをクラウドに移行したいと考えています。病院や医師が患者のケアを行う際に医療記録にアクセスできないという状況は、まさにミッションクリティカルです。現在、主要な電子カルテシステムの一つであるEpicは、ほぼすべての導入が自社運用型です。つまり、今後5年から10年分のパフォーマンスを見込んでインフラを事前に準備する必要があり、使用するかどうか分からない設備投資が必要になります。多くのEpicのお客様は、小規模から始めて成長に応じてスケールアップしたいと考えています。Epicのユースケースは非常に特殊で、高いIOPS要件を持つトランザクション処理が必要です。
AWSはio2 Block Expressを使用してEpicに何を提供したのでしょうか？Epicに対してボリュームあたり256,000 IOPSを提供し、さらに複数のボリュームをストライピングすることで420,000 IOPSまで増加させることができました。Epicは1秒あたり7,500万トランザクションを達成し、オンプレミスの運用データベースと比較して35%のスケールアップと2倍のスケールアウトを実現することができました。
先ほど申し上げたように、Epicは高IOPSのユースケースです。Florida州の主要な医療機関であるBaptist Memorial Health Careの事例をご紹介します。彼らは5つの異なる病院のEpicシステムを統合してクラウドに移行し、オンプレミス環境と比較して20%のパフォーマンス向上を実現しました。io2 Block Expressを活用することで、Epicとそのお客様はミッションクリティカルな実装をクラウドへ移行することができました。これは、AWSが医療分野のユースケースにおいてどのように成果をもたらすかを示す良い例です。特筆すべきは、io2 Block Expressがボリュームあたり256K IOPSを提供し、独自の実装とアーキテクチャを通じて、Epicで最大420K IOPSを実現できたことです。
それでは、どのようにして420K IOPSを達成したのか、詳しく見ていきましょう。Epicは医師や看護師が患者ケアを提供するために必要不可欠なアプリケーションです。システムの稼働状態は極めて重要です。私が以前、ある大規模病院システムのストレージアレイをクラッシュさせてしまった際、1000人の医師と看護師がバックアップが復元されるまでの数時間、紙とペンでの作業を余儀なくされました。EpicはInterSystems Cacheという、SQLに似た独自のトランザクショナルデータベース上で動作します。Cacheのブロックサイズは8キロバイトです。Epic自体のワークロードは、主にデータ入力よりも医師による健康記録へのアクセスが中心で、患者名、メモ、チャートなどの小さな8Kトランザクションが多い読み取り主体のワークロードとなっています。
このワークロードは、gp3やio2の標準ブロックサイズが16Kであるため、EBSに完全に適しているわけではありません。EBS上で他のデータベースを低いブロックサイズで実行する場合は、基盤となるストレージがサポートする設定に合わせてデータベースをチューニングすることを検討してください。ST1とSC1は磁気ストレージタイプで、混乱を避けるためにオペレーティングシステムには4Kと表示されますが、実際の内部的なブロックサイズは1メガバイトです。小さなトランザクションでも、裏側では16Kのアクセスが発生し、これはスループットに関する読み取りと書き込みのインフレーションと呼ばれます。8Kで実行している場合でも、インフレーションの影響で、単一のボリュームでio2 Block Expressの8Kでの4ギガバイト/秒を実現できない可能性があります。
Epicには、高いIOPS要件、医師を待たせないための最低限のレイテンシー、そして同時に数千人のユーザーが同じシステムにアクセスする高い同時実行性が求められますが、書き込みは比較的少ないのが特徴です。io2 Block Expressの最大IOPSは256,000で、EC2インスタンスはインスタンスあたり最大400,000 IOPSをサポートしていますが、ボリュームのストライピングや、異なるワークロードを異なるボリュームに配置するなど、複数のボリュームを様々な方法で使用することで、より高いパフォーマンスを実現できます。EBSでのRAIDの使用について質問をよく受けますが、EBSは既に冗長性を備えているため、一般的にRAIDは使用すべきではありません。ただし、RAID 0は例外です。単一のボリュームで提供できる以上のパフォーマンスを実現するために、RAID 0やMD RAID、LVMなどを使用して複数のボリュームを活用することができ、むしろそうすべきです。ただし、インスタンスに複数のボリュームを追加する際は、システムの実効的な耐久性が低下することを覚えておいてください。各ボリュームタイプの耐久性統計は公開されています。
Nボリュームをストライピングする場合、実効的な耐久性は1から年間故障率のN乗を引いた値になります。2つのio2 Block Expressボリュームを使用しても、ほぼ5ナインの耐久性が得られ、これは十分な水準です。ミッションクリティカルなアプリケーションでは、3つ以上のio2 Block Expressボリュームをストライピングすることもできます。ただし、gp3の場合は注意が必要です。インスタンスによっては最大127ボリュームまでサポートしているため、25のボリュームをストライピングして同じ400,000 IOPSを実現することも技術的には可能ですが、1つのボリュームの障害が環境全体をダウンさせる可能性があるため、システムに問題が発生する可能性が高くなります。このようなセットアップを実装する際は、Oracle ASMのようなアプリケーションを使用してレプリケーションを行うか、定期的なスナップショットを取得し、しっかりとしたバックアップとDR戦略を維持するようにしてください。
ボリュームの問題をより簡単に検出できるよう、最近EC2で Attached EBS Status Checkを導入しました。これまでは、ステータスを確認するために個々のEBSボリュームを調べる必要があり、ボリュームに問題がある場合は、どのボリュームが問題を抱えているかを特定するために、インスタンスにアタッチされているすべてのボリュームを検査する必要がありました。現在では、EC2コンソールやEC2 APIを通じてインスタンスに直接問い合わせることで、どのボリュームがIOの一時停止やストールを経験しているかを直接確認できます。また、Auto-Scaling groupsとも統合されており、人手を介さずに回復とインスタンスの置き換えを自動化して信頼性を向上させることができます。
レイテンシーに関して、io2 Block Expressは現在最も低レイテンシーなボリュームです。レイテンシーの具体的な数値は公表していませんが、大きなIOサイズでも一貫してサブミリ秒のパフォーマンスを提供します。実際の数値を得るには独自のベンチマークを実施できますが、ボリュームの配置場所によってリージョン間で変動する可能性があることに注意してください。この例では、スレッドあたり2000 IOPSで0.5ミリ秒のレイテンシーを考えてみましょう。gp3の場合は一桁ミリ秒のレイテンシーなので、スレッドあたり最大1000 IOPSとしましょう。これらの数値は、ミリ秒単位のレイテンシーで1を割ることで得られ、アプリケーションの単一スレッドが処理できるIOPS数を決定します。
では、単一スレッドのアプリケーションでこの程度しかできないのに、256,000 IOPSをどのように実現するのでしょうか？これは特に、トランザクションログへの書き込みを単一スレッドで行うようなデータベースのトランザクション処理において重要です。レイテンシーがボトルネックになることもありますが、ほとんどのアプリケーションは複数のワーカーとプロセスを使用して、個別のノンブロッキングトランザクションを実行できます。MySQLのような場合では、二重書き込みやトランザクションの二重チェックを避けるためにWrite Preventionを使用でき、これによってパフォーマンスが大幅に向上します。io2 Block Expressボリュームを最大限活用するには、マルチスレッドアプリケーションが必要不可欠です。アプリケーションのパフォーマンスをテストする際は、実効キューデプスと実際のキューデプスの両方を確認する必要があります。複数のボリュームを使用する場合、実効キューデプスはボリューム数で分割されるため、目的のパフォーマンスを達成するにはより多くのキューイングが必要になる場合があります。
実効最大IOPSには計算式があります：1をレイテンシーで割り、それにキューデプスを掛けます。アプリケーションのキューデプスが32の場合、io2 Block Expressで64,000以上のIOPSを達成できることになります。もっと可能な場合は、さらに高めることができます。レイテンシーは非常に重要で、多くの人がこの事実を見落としています。
io2 Block ExpressとgP3のテールレイテンシーを比較してみましょう。io2 Block Expressは非常に一貫性があり、極めて安定した低レイテンシーを維持するように設計されています。これにより、より予測可能なパフォーマンスが得られ、単一のパフォーマンスの乱れがアプリケーションに影響を与えることを心配せずに、ボリュームをほぼ限界まで使用できます。一方、gp3では99.9パーセンタイルに近づくにつれて、レイテンシーが上昇します - つまり一貫性が低いのです。そのため、高IOPSと低レイテンシーを必要とするミッションクリティカルなパフォーマンスアプリケーションの場合は、io2での実行を強くお勧めします。このグラフでは明確に示されていませんが、io2 Block Expressボリュームの具体的な数値として、99.9%の時間でサブミリ秒のレイテンシーを提供し、残りの0.1%の時間でも、テールレイテンシーはgp3よりもはるかに優れています。
SAP HANAの事例：高スループット要件への対応
別のユースケースについてお話ししましょう。先ほど、256Kから始まり最大420K IOPSを達成する高IOPS要件のEpicのユースケースを見ました。次のユースケースはSAP HANAについてです。これは高スループットのユースケースです。多くの企業がSAP HANA上でビジネスを運用しているため、HANAはミッションクリティカルです。HANAはインメモリデータベースで、他の多くのインメモリデータベースと同様に、起動時にすべての永続化データをメモリに読み込みます。これは再起動やメンテナンス時に発生し、この間のダウンタイムは企業にとって重要です。これを実現するため、SAPは大きなブロックサイズを使用します。SAP HANAの場合、256Kの大きなブロックサイズを使用する高スループットのユースケースであり、起動時間を最小限に抑えるために非常に高いスループットが必要です。io2 Block Expressは、ミッションクリティカルで高性能が要求されるSAPの導入に推奨されています。
こちらは欧州のNissanからの事例です。Nissanの車は何千もの部品で構成されており、重要な流れ作業の保守・製造ラインで構築され、大規模なデータ分析が必要です。欧州では、データが著しく増加し、このデータを大規模に処理する必要性に直面していました。SAPワークロードをクラウドに移行した際、io2 Block Expressを使用することで63%のパフォーマンス向上を達成しました。さらに、Amazon EBSのスナップショット機能を活用して、データベースリカバリの一貫した所要時間を実現することができました。クラウドへの移行により、新しい取り組みに対する柔軟性も得られ、大規模なテストのためにスケールアップし、テスト完了後にスケールダウンすることが可能になりました。
このSAP HANAのケースは、スループット集中型のユースケースで、Epicのケースとは大きく異なります。
SAP HANAがio2 Block Expressを使用してどのように高スループットを達成したのか、理解していきましょう。データベースのスペクトラムの両極端にある2つの例をご紹介したいと思います。Epicの超小さなブロックサイズと、SAP HANAの超大きなブロックサイズのシーケンシャルワークロードです。ほとんどのデータベースはその中間に位置し、多くは64Kや32Kのブロックサイズを使用しています。MySQL、PostgreSQL、SQL Serverもその範囲にありますが、このアドバイスはすべてのデータベースタイプに当てはまります。
SAP HANAのワークロードは、データをメモリにロードし、すべての処理をメモリ上で行います。起動時には、256Kのブロックサイズで連続的に高速にデータをロードする必要があります。メモリへの高速な読み込みが必要なため、高スループットと低レイテンシーが読み取りに求められます。書き込み時には変更部分のみを書き出しますが、これはランダムな書き込みであり、すでに256Kにコンパクトにまとめられています。並行性は適度です。なぜなら、読み込みが終わってから書き込みを開始し、書き込み時にはほとんど読み込みを行わないためです。EC2インスタンスには12.5ギガバイト/秒の制限があり、io2 Block Expressの最大値は4ギガバイト/秒です。
インスタンスの性能を最大限に引き出すために、io2 Block Expressボリュームのストライピングをお勧めします。3つのボリュームを使用すれば12GB/秒、4つのボリュームで12.5GB/秒を達成できます。また、将来的に16GB/秒や20GB/秒に対応する新しいインスタンスがリリースされる可能性もあります。EBSのネイティブブロックサイズは16キロバイトですが、I/O mergingという機能により、連続した小さなI/Oを最大256キロバイトまで1つのバックエンド操作にマージすることができます。つまり、16キロバイトで連続的に書き込みを行っても、システムがそれを検知して256キロバイトの1回のI/Oとしてカウントされるということです。
これは、最大スループットを達成するために、ボリュームに最大IOPSを割り当てる必要がないことを意味します。io2 Block Expressでは、SAP HANAのようなワークロードの場合、16,000 IOPSのプロビジョニングで4GB/秒のスループットを実現できます。128キロバイトのランダムワークロードの場合でも、io2 Block Expressで32,000 IOPSあれば4GB/秒を達成できます。I/O mergingは読み取りと書き込みで個別に機能しますが、キューごとに1つのワークロードしか処理できないことに注意が必要です。SAP HANAのようなシナリオでは、すでに256キロバイトのI/Oで処理されているため問題ありませんが、小さなブロックサイズのワークロードを結合する場合は、1つの方向に複数のストリームがあると機能しない可能性があることを覚えておいてください。
EBSの新機能とパフォーマンス監視ツール
レイテンシーについて、 EBSボリュームの平均読み取りレイテンシーと書き込みレイテンシーを測定するCloudWatchメトリクスを導入しました。これらは無料利用枠でデフォルトで利用可能で、すべてのボリュームで使用できます。基本的に、1分間隔でレイテンシーを監視し、ボトルネックを特定したり、パフォーマンス調査時にアプリケーションに適したボリュームタイプかどうかを判断したり、問題の根本原因を特定したりするのに役立ちます。
Amazon EBSでは、ボリュームは特定のIOPSとスループットでプロビジョニングされ、それに応じて料金が発生します。例えば、gp3のベースラインは3,000 IOPSです。この制限を超えると、プロビジョニングされたパフォーマンスを超えることができないため、スロットリングが発生します。これに対処するには、より多くのパフォーマンスを割り当てる必要があります。EBSボリュームのレイテンシーメトリクスには、スロットリングに費やされた時間は含まれません。これは、スロットル前のバックエンドレイテンシーを示しているためです。
最近、EBSボリュームのリアルタイムI/Oパフォーマンス統計を再導入しました。これらはNVMe Driverを通じて直接アクセス可能で、ホストレベルのユーティリティを使用してこれらのメトリクスを取得できます。GitHubで提供しているEBS CLI statsというツールがあり、ドキュメントにも記載されています。これらのメトリクスはNVMeドライバーのログページとしても利用可能で、1秒ごとのメトリクスを社内のパフォーマンスログ収集アプリケーションに統合することができます。最終的には、他のベンダーもこれらのメトリクスを自社の監視エージェントに統合することになるでしょう。CloudWatch agentでも利用可能になる予定で、EKSワークロードではすでにPrometheusで利用可能です。
以前は、オペレーティングシステムを使用しない限り、1秒単位の詳細な情報を得ることができませんでした。そして、それもストレージデバイスの視点ではなく、オペレーティングシステムの視点からの情報に限られていました。今回提供するメトリクスでは、IOPSをローリングカウンターとして提供し、実際のリアルタイムIOPSを得るためにサンプルを取得して差分を計算する必要があります。1秒ごとに更新される読み取りと書き込みの合計IOPS、スループット用の読み取りと書き込みの合計バイト数、そして読み取りと書き込みに費やされた合計時間（マイクロ秒単位）を提供します。これは実質的にレイテンシーを表しています。マイクロ秒単位の時間をIOPSで割ることで、ボリュームの存続期間における実効平均レイテンシーを得ることができます。
io2 Block ExpressやgP3ボリュームのレイテンシーの一貫性を検証するために、読み取りと書き込みの両方についてIOレイテンシーヒストグラムを提供しています。この例では、gp3のパフォーマンスを示しており、読み取りIOの大部分が250マイクロ秒から1ミリ秒の間で処理されていることがわかります。書き込みは若干遅くなりますが、ほとんどのIOは4ミリ秒以内に処理されています。外れ値も存在しますが、急速に減少していきます。このヒストグラムを追跡して外れ値を発生時に検出することは特に有用です。このヒストグラムデータを使用してヒートマップを作成することができ、私が先に作らなければ、きっと誰かが自動ヒートマップジェネレーターを提供するでしょう。これは、ボリュームストレージのパフォーマンスの乱れを特定するのに非常に役立ちます。
サポートチームもこれらのメトリクスにアクセスでき、私たちがお客様に提供するのと同じデータに基づいてこのような問題を特定することができます。さらに重要なことは、これが私が最も興奮している点なのですが、ヒストグラムだけでなく、EBSボリュームがパフォーマンス超過状態にあった時間を提供します。これは、割り当てを超過したためにスロットリングされた時間です。IOPSとスループットの両方について、マイクロ秒単位でこれらの時間を提供するので、このユーティリティを使用して、IOPSの制限やスループットの制限に達しているかどうかを簡単に特定できます。不確かな場合は、ボリュームの適切なサイズ設定に役立ちます。
また、EC2レベルのメトリクスも提供します。EC2自体には、それ以上のパフォーマンスを提供できない特定の制限があります。各EC2インスタンスのIASとスループット能力は、私たちのドキュメントに記載されています。このメトリクスは、EC2インスタンスがワークロードに対して適切なサイズになっていないこと、つまりインスタンスが処理できる以上のストレージ負荷をかけていることを示します。最後に、アプリケーションのキューイング動作を確認できるように、ポイントインタイムのキュー長も提供します。
これらの制限に達しているとき、つまりプロビジョニングされたパフォーマンスを超過しているときを特定するために、NVMEドライバーを使用する必要はありません。システムを深くハッキングすることが好きな人には非常に良いツールですが、理想的にはこれらはCloudWatchにあるべきです。生活を簡単にするために、EBSボリュームがオーバードライブされていることを示す2つの新しいCloudWatchメトリクスを導入しました。これらは1分解像度のバイナリメトリクスです。0は正常に動作していることを意味し、このメトリクスが1に変わると、ボリュームがスロットリングされていることを意味します。このメトリクスに対してCloudWatchでアラームを設定でき、しきい値について考える必要はありません。私たちがすでにそのすべてを処理しています。このメトリクスが1の場合、ボリュームの処理能力以上の負荷をかけていることになります。これについて私は非常に興奮しており、お客様がアプリケーションにより多くのリソースが必要かどうかを特定するためにこれを使用することを心待ちにしています。
最後に、ミッションクリティカルなデータベースの一部を io2 Block Express に移行した McAfee の事例をご紹介したいと思います。 これらの4つのパーセンテージは、このセッションで説明してきた io2 Block Express のすべてのメリットを示しています。30%のパフォーマンス向上は、io2 Block Express の高い IOPS、高いスループット、そして低レイテンシーによるものです。20%のクエリ時間短縮もレイテンシーの改善によるものです。レポート時間の短縮は通常スループットに依存しますが、81%という5倍もの削減を実現できました。バックアップは50%速くなりました。これは、バックアップの読み取りが速くなっただけでなく、システム全体でより多くのパフォーマンスが利用可能になり、バックアップワークロードが本番ワークロードと競合しなくなったためです。
では Anita、このセッションの重要なポイントをまとめましょう。ありがとうございます、Carol。まず、最も負荷の高いミッションクリティカルなユースケース向けの io2 Block Express をご紹介しました。多くのワークロードに適している gp3 についても説明しましたが、ミッションクリティカルなワークロードには、必要な最高のパフォーマンスを提供する io2 Block Express が最適です。また、より高い IOPS とスループットを実現するストライピングと論理ボリュームの概念についても説明しました。
Carol は tail latency について説明し、io2 Block Express がワークロードに対して一貫してサブミリ秒のレイテンシーを提供することをグラフで示しました。io2 Block Express では、当社のボリュームの中で最高となる99.999%の耐久性を提供しており、これによりアプリケーションのダウンタイムを低減できます。
高い IOPS 要件を示すさまざまな業界のユースケースについて説明しました。高 IOPS のユースケースとして Epic EHR、高スループットのユースケースとして SAP HANA、そしてデータベースのユースケースについても検討しました。 本日は、Amazon EBS と io2 Block Express について学んでいただくためにお時間を割いていただき、ありがとうございました。
まだご覧になっていない方のために、すべてのセッションの一覧をご紹介します。明日の朝9時30分から MGM Grand でハンズオンワークショップが開催され、これらのトピックの一部を取り上げます。メトリクスの確認、Elastic Volumes、ボリュームのスケール変更、スナップショットを使用した復旧などに興味がある方は、明日 ST031381 というセッションがあります。 ありがとうございました。それでは質疑応答に移りたいと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion