re:Invent 2024: AWSストレージによるデータベース性能向上と拡張性
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate database performance and scalability with AWS storage (STG332)
この動画では、AWSでのセルフマネージド型データベースのストレージ選択について詳しく解説しています。Amazon EBSとAmazon FSxファミリー(Windows File Server、OpenZFS、NetApp ONTAP)の特徴や使い分けを説明し、それぞれのスナップショット機能やクローン作成機能、マルチAZ展開による可用性向上などの具体的な活用方法を紹介しています。Adidas社のSAP S/4HANA移行事例では、FSx for ONTAPの採用によりリカバリー時間を59%削減し、S&P Global Market Intelligence社では、FSx for NetApp ONTAPを活用してMicrosoft licensingコストを大幅に削減した実例も共有されています。データベースの要件や既存環境に応じた最適なストレージ選択の判断基準を示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのデータベースストレージ選択肢：自己管理型の利点
みなさん、こんにちは。Amazon Elastic Block Storeを担当するストレージスペシャリストのRyan Sayreです。私は他の分野も幅広く見ていますが、ユーザーとしても、オンプレミスベンダーとしても、ストレージの経験があります。おはようございます。Jim Whiteです。Ryanと同様、私も最初は顧客として、その後EMCやNetAppなどのストレージベンダーで働いた経験があります。AWSには約4年在籍しており、本日お話しするサービスの1つの立ち上げに携わる機会がありました。
今日お話しする文脈は、セルフマネージド型ストレージと、その検討すべき多くの要因についてです。皆さんの組織は驚くべきスピードでデータベースをAWSに移行しています。re:Inventに参加されている皆さんは、クラウドによってコストを削減し、素早くイノベーションを起こし、組織の成功に向けてアプリケーション開発に注力できるという考え方をよく理解されていることと思います。
データベースについて考えるとき、私たちは選択肢の豊富さを重視しています。データベースの自由度という言葉を聞いたことがある方もいらっしゃるでしょう。これは、マネージド型ソリューションでもセルフマネージド型ソリューションでも、異なるサービスを選択できるという考え方です。つまり、AWSが提供する最高のものを選べるということです。私はこのスライドが特に気に入っています。なぜなら、将来的なアプリケーションへの展開の仕組みや可能性を示しており、データベースや分析、あるいはその両方に生成AIのコンポーネントを追加できる可能性を示しているからです。私たちが提供する幅広く深いポートフォリオは、本当に素晴らしいものだと思います。
Amazon EBSの特徴と活用法
セルフマネージド型データベースについては、マネージド型サービスの代わりにこのオプションを選ぶ十分な理由があります。現在、多くの方々がクラウドでセルフマネージドを実践されており、制御の必要性をご理解いただいていると思います。例えば、Amazon RDSで全てが上手く展開されているものの、コンプライアンス要件があったり、RDSでは対応できないストアドプロシージャがあったり、組織特有のデータベースユーザー要件があったりする場合があります。AWSのインフラストラクチャがもたらすこの柔軟性により、セルフマネージド型データベースは非常にうまく機能するのです。
これらは現在、人々が展開しているデータベースの一例です。今日これらのデータベースを見ると、より伝統的な、あるいはエンタープライズスケールアップ型だと考えられます。新しく登場するデータベースを考えると、CockroachDBやATDB、MongoDBなどがあり、これらは時として従来のDBAアーキテクチャの枠を超えていますが、セルフマネージドというテーマは依然として当てはまります。これらを使用する場合、Well-Architectedなコードの優れた実例があり、Amazon EC2やAmazon ECS、Amazon EKSを使用したコンテナ化での展開が可能で、多くの場合、ブロックストレージとファイルストレージにはAmazon EBSとAmazon FSxを使用することになります。
AWSでデータベースをデプロイする際、私たちはよく、データベースが最適に動作するオペレーティングシステムの選択や、特定のプロセッサタイプに関するレガシー要件、あるいは特定のワークフローへの統合について検討します。これらはAWSの自己管理型で構築可能で、既存のアーキテクチャとほぼ同じように実現できます。つまり、AWSが提供する他のメリットを活用し、さらにクラウドアナリティクスやData Lakeへの連携メカニズムを追加する可能性を考慮しながら、リフト＆シフトを行うことができるのです。これは計算処理を移行する上で非常に強力なメカニズムですが、 ストレージコンポーネントの観点からデータベースのパフォーマンスについても考える必要があります。
多くのユーザーは、データベースをブロックストレージのみにデプロイしており、一部のユーザーはブロックストレージとファイルストレージの両方を使用しています。必要に応じて選択し、組み合わせることが可能です。私はAmazon EBS側の人間なのでブロックストレージに多少偏った見方をしていますが、必要に応じてパフォーマンスを調整することができます。RTOやRPOに関する具体的な要件があり、すべてをオンラインに保つ必要がある場合は、それに応じたアーキテクチャを設計する必要があります。
これらの要件に対応し、すべてをオンラインに保つためのアーキテクチャを設計する際は、スナップショット、レプリケーション、アプリケーション管理のレジリエンシーの統合を検討する必要があります。俊敏性に焦点を当てると、クラウドのセキュリティ、クラウドのレジリエンシー、さらにアプリケーションを複数のAvailability Zoneや複数のリージョンに分散させる能力について話すことができます。最終的には、TCOも重要な要素となります。自社のデータベースを熟知し、ビジネスへの影響を深く理解している場合、自己管理を通じた完全なコントロールがTCOを決定付けます。なぜなら、誰よりもデータベースを理解しているからです。
Amazon FSxファミリーの概要と選択基準
ストレージポートフォリオに関して、様々な選択肢があります。 今日は主にブロックストレージとファイルストレージのソリューションについて話をしています。 バックアップやデータウェアハウスコンポーネント、その他のコンポーネント向けに、Amazon S3でオブジェクトアクセスを使用するソリューションもあります。ただし、今回はAWSへの移行が容易なブロックストレージとファイルストレージに焦点を当てます。ファイルストレージの細かな点として、Amazon FSx for NetApp ONTAPもブロックストレージとして使用できます。実際には、今日のスライドで示されているよりも複雑な側面があります。
今日のポイントは、ここに示された4つのサービスについて説明することです。Amazon EBSとFSxファミリーの3つのメンバーについて説明します。Ryanが指摘したように、 FSxファミリーの設計目標の1つは、オンプレミスで広く展開され、採用されている一般的な商用ファイルシステムをAWSに持ち込むことでした。Amazon FSx for NetApp ONTAP、Amazon FSx for Windows File Server、Amazon FSx for OpenZFS、そしてAmazon FSx for Lustreがあります。Lustreは通常データベース用途では使用されないため、今日の議論の対象外となります。私たちはAmazon EBSとこれら3つのFSxサービスに焦点を当てます。これらは、データベース管理者、IT管理者、インフラストラクチャマネージャーがデータベースインフラストラクチャスタックの一部として求める機能と性能を最も適切に提供するからです。
これらのサービスのスーパーパワーについて考えてみましょう。それぞれのサービスは異なる目的のために設計されており、私が「スーパーパワー」と呼ぶような、ほぼ固有の機能や特徴を持っています。スライドの左側にあるAmazon EBSから見ていくと、ブロック接続とブロックエクスペリエンスを提供し、シンプルにデプロイでき、おそらくポートフォリオの中で最高のパフォーマンスを発揮します。スライドを見ていくと、ONTAPとZFSがあり、これらはONTAPやZFSを使用してきたお客様にとってなじみのある豊富な機能と性能を提供します。これを私たちは豊富なデータ管理機能と分類しています。FSxファミリー全体を見ると、お客様がAWSにワークロードを移行する際に、できるだけ新しいことを学ばなくて済むように、使い慣れた環境が重要となります。お客様は、再ツール化、再トレーニング、再学習することなく、オンプレミスと同様のエクスペリエンスを求めています。
FSxファミリーは、デフォルトで高可用性を実現するために、Multi-AZ HAまたはSingle-AZ HAのデプロイメントタイプを提供します。Availability Zone間でビルドすると、後のスライドで説明する追加の組み込み機能が得られます。これらが私たちが考えるべきポイントです：ストレージに必要な機能は何か、オンプレミスやその他のストレージソリューションからの移行の場合、使い慣れた環境は重要か、そしてこれらの機能をどのようにビジネスにマッチさせるかということです。
スナップショットとクローン：FSxの強力な機能
皆さんはAmazon EC2をデプロイしているので、Amazon EBSも使用していることになります。なぜなら、EBSはEC2や他の多くのマネージドサービスの基盤となるストレージだからです。利用可能なボリュームの分類について考えると、プロビジョニングできるボリュームはもっとありますが、これらは私がデータベースアプリケーション向けによく見るメインのボリュームです。帯域幅やIOPSなど、データベースのパフォーマンス要件がわからない場合は、Amazon Linux 2023などをプロビジョニングする際のデフォルトのEBSボリュームタイプである汎用SSDのgp3が本当に適しています。
レイテンシーを重視したデプロイメントを行いたい場合や、アプリケーションに多くのIOPSと帯域幅をプロビジョニングしたい場合は、io2 Block Expressが活躍します。デプロイの理由は様々で、io2 Block Expressの他の利点については別のスライドで説明します。st1について特に言及したいのですが、多くのデータベース操作はバッチ操作であり、また、レイテンシー要件をそれほど気にしないテストや開発環境でも使用されます。本番環境ではなく、クレジットカードでの支払いやライブウェブサイトとのやり取りを必要としない多くの「十分な」タイプのデプロイメントをst1で実行できます。
最後に、sc1については、ログを別のボリュームにダンプしたい場合（アプリケーション所有のものかもしれませんし、サードパーティのユーティリティかもしれませんし、手動で行っているかもしれません）、最も低価格なブロックボリュームとして利用できます。また、時々の使用のためにオンラインで保持しておく必要があるアプリケーションもあるかもしれません。そのデータベースセットを参照する必要があるものの、非常にまれで時間的制約がない場合、sc1が適しています。私はこれが気に入っていて、データベースを使用しているお客様との会話でよくこのような状況を目にします。
詳細に入る前に、耐久性について触れておくのが良いと思います。一般的なボリュームの耐久性は99.8-99.9%程度ですので、数百のボリュームを使用する場合はそれを考慮に入れる必要があります。しかし、重要かつレイテンシーに敏感なワークロードがある場合、そこでio2 Block Expressが活躍します。99.999%の耐久性を提供し、さらにWindowsとLinuxの両方でマルチアタッチが可能です。アプリケーションの要件やフェイルオーバーイベントのために、複数のインスタンスからストレージにアクセスする必要がある場合、io2 Block Expressがまさにぴったりの選択肢となります。
アクティブなワークロードについては、レプリケーションやバックアップにスナップショット管理を使用できます。一定期間内で特定のレベルのスナップショットを保持する必要がある場合や、コンプライアンスまたは運用上の理由でロールバック用のスナップショットが必要な場合、cronタブを作成してバックグラウンドで実行することもできますが、スナップショットの数が増えすぎる可能性があります。私のおすすめは、Amazon Data Lifecycle Managerです。これはスナップショットのオーケストレーションと管理を行うための無料のソリューションです。すでにこれを使用している場合は、Amazon Data Lifecycle Managerにはアプリケーションへのプリフックとポストフックも用意されているので、スナップショットを作成する際にデータベースを休止させて、すべてが適切な状態であることを確認できます。 Amazon Data Lifecycle Managerは複数のリージョンにまたがって管理することができます。
アクティブなデータのユースケースに話を戻しますが、私はElastic Volumesが大好きです。gp2からgp3への移行など、Elastic Volumesを実際に使用したことがある方はどれくらいいらっしゃいますか？これは素晴らしい機能で、Elastic Volumes（EV）について丸一日かけて説明できるくらいです。これにより、あるボリュームタイプから別のタイプへの移行が可能になります。
例えば、季節的なデータセットがある場合を考えてみましょう。今日は12月1日のCyber Mondayですが、このような時期にストレージの需要が急増することがあります。Elastic Volumesを使用すれば、IOPSを大量に消費してテーブルにアクセスする繁忙期には、io2 Block Expressに変更することができます。そして、その繁忙期が過ぎたら、gp3に戻すことができます。あるいは、完全にオフシーズンだけどオンラインで保持しておきたい場合は、st1やsc1に設定することもできます。
これらはすべてオンラインで行えるので、週末を有効活用できます。アプリケーションの実行中にこれらの変更が可能だからです。多くのお客様は、ダウンタイムがあるのではないかと懐疑的ですが、実際にはダウンタイムはありません。だからこそ「週末を取り戻せる」と言えるのです。約束された性能を維持したまま、必要に応じてアップグレードやダウングレードができるからです。Elastic Volumesの変更はボリュームシステムに組み込まれているため、使用料金は発生しません。
Fast Snapshot Restore (FSR) は、スナップショットからの超高速なリハイドレーションのために、ボリュームをホットスタンバイ状態で維持できる仕組みです。一部のユーザーは厳密なRTOのためにFSRを実際に使用し、スタンバイ状態で維持しています。多くのユーザーは、データベースのバージョンアップグレードや、x86からGravitonへの変換など、多くの変更を同時に行う際にFSRを活用しています。もしアップグレードがうまくいかず、ロールバックが必要になった場合、FSRはシンプルでクリーンかつ効率的な復元方法を提供します。Elastic Volumesやボリュームの拡張については延々と話し続けることができますが、非常に興味深いクリエイティブなことができますので、機会があればぜひ確認してみてください。
顧客事例：AdidasとAmdocsのFSx活用
組織ごとに異なるデータベースを、特定のボリュームタイプにマッピングできることは重要です。gp3は誰もが好んで使い続けるサンドイッチのようなものです。なぜなら、とても使い勝手が良いからです。高度なパフォーマンスを必要とする重要なデータベースには、io2 Block Expressが非常に適しています。また、マルチアタッチや99.999%の耐久性といった機能も備えています。バッチログファイルや、それほど高い性能を必要としないオンラインデータベースには、st1やsc1といったHDDボリュームが活用されます。
これは本当に素晴らしいですね。SRDについてご存知の方はいらっしゃいますか？数年前、SRDについての技術講演が行われましたが、これは私たちが開発した新しいプロトコルです。HPCチームからインスピレーションを得て、オンプレミスで期待されるようなサブミリ秒レベルのレイテンシーを実現するため、インフラ全体でマルチパスと帯域幅共有のレベルを構築しました。従来のSANベースのデータベース管理者としてマルチパスを考える場合、それがAmazonの世界でどのように対応するのかを理解することができます。
SRDによって、レイテンシー時間の改善、スループットの向上、一貫性の改善を実現できることは非常に重要です。現在io1をお使いの方は、Elastic Volumesを使用することで、ダウンタイムなしでio1ボリュームをio2に変更し、この恩恵を受けることができます。ユーザーにこの機能を提供できることを非常に嬉しく思っており、io1とio2の間に価格差はありません。実際、高IOPSユーザーの場合、io2に移行することで実質的な割引が受けられるため、移行には複数のメリットがあるかもしれません。ユーザーの皆様にも大変ご好評いただいています。
なぜEBSを選ぶのでしょうか？様々なサービスについて話す際、コンピュート中心の考え方や、異なるストレージアクセスの次元でストレージを展開することを考えているアプリケーション重視のアプローチであれば、EBSは最適です。実際、複数のAvailability Zoneや複数のリージョンにまたがる回復性、レプリケーション、可用性を管理するアプリケーション中心の機能を維持・保持することができます。これは非常に自然に感じられるはずです。データ保護を統合したい場合（これは絶対にお勧めします）、Amazon Data Lifecycle Managerを使用し、プリフックとポストフックを活用してください。
私たちのお客様は、デプロイメントの面で、この機能を最大限に活用されています。オンプレミスからAmazon EBS io2 Block Expressへの移行は非常に自然な流れでした。そして、レジリエンシーと復旧メカニズムを加速することができました。Marqetaの事例では、彼らはMySQLユーザーでしたが、アプリケーション中心のレジリエンシーモデルを活用してマルチリージョン展開を実現しました。明らかにパフォーマンスが向上し、Amazon EBS io2 Block Expressのおかげで、迅速なデプロイメントが可能になりました。
FSxサービスの比較と顧客事例：S&P Global Market IntelligenceとChange Healthcare
それでは、Jimに引き継ぎたいと思います。ありがとう、Ryan。ここからAmazon FSxファミリーのメンバーについて説明していきますが、まずこれらの製品の位置づけと、採用を検討する際の考え方についてお話ししたいと思います。左側のAmazon FSx for Windows File Serverから始めましょう。これはもちろんWindowsインフラストラクチャ上に構築されています。Windows環境をフルスタックで使用しているお客様にとって、これは理にかなった選択です。例えば、Windows Server上でSQL Serverを実行している場合、オンプレミスと同じストレージ環境を維持したい、あるいはWindowsスタックしか使い慣れていないという理由で、Amazon FSx for Windows File Serverが最適なソリューションとなるでしょう。
SQL Serverの様々なバリエーションをAmazon FSx for Windows File Server上にデプロイするお客様も見られます。初めて使用される方にとっても、数回のマウスクリックで簡単にデプロイできます。管理機能の面でもWindowsと同じような使い勝手で、オンプレミスのWindowsと同様の機能をAmazon FSxファミリーでも利用できます。Amazon FSx for OpenZFSに目を向けると、皆さんの中にはZFSについての知識をお持ちの方もいらっしゃるでしょう。ZFSには、スナップショット、クローン、組み込みのレプリケーションなど、豊富な機能セットが備わっています。これらの機能は、多くのデータベース管理者がデータ保護や低TCOでのデータベースコピーの作成を考える際に、非常に重要となります。
Amazon FSx for OpenZFSは、特にOracleデータベースやPostgreSQLデータベースで選ばれる傾向にあります。これはNFS接続を使用します。一方、Amazon FSx for Windows File Serverの場合はSMB接続（昔でいうCIFS）を使用します。Amazon FSx for NetApp ONTAPは、様々な種類のブロックまたはファイル接続を提供します。ファイル側ではSMBとNFSの両方をサポートし、ブロック側ではiSCSIと最近ではNVMe over TCPをサポートしています。データベースにブロック接続が必須だというお客様もいらっしゃいますが、その場合の選択肢はAmazon EBSかAmazon FSx for NetApp ONTAPのいずれかとなります。ファイル接続が可能な場合は、プロトコルによって選択肢が分かれます。SMBの場合はWindowsかONTAP、NFSの場合はOpenZFSかONTAPということになります。
選択肢が多いため、時として混乱を招くことがありますが、それは「どれを選ぶべきか」という疑問につながります。その前に、いくつかの機能について説明させていただきます。これらは選択の際の基本的な要件となります。実は、今日お話しするAmazon FSxファミリーのすべてのサービスで、シングルAZデプロイメントとマルチAZデプロイメントのいずれかを選択できます。どちらの場合も高可用性デプロイメントとなります。左上に示されているように、これらのサービスは2ノードインフラストラクチャ（アクティブノードとスタンバイノード）で構築されており、その間で共有ディスクを使用します。実際にはディスクのコピーが複数あるため、ドライブの障害による問題や停止を心配する必要はありません。アクティブノードに障害が発生した場合、データを失うことなくスタンバイノードにフェイルオーバーします。これは非常に迅速に行われ、アプリケーションやデータベースはほとんど影響を受けません。その間、I/Oが少し一時停止する可能性はありますが、アプリケーションが停止することはありません。
右側に移ると、Multi-AZデプロイメントが示されています。これは、デプロイメントを2つのAvailability Zoneにまたがって展開し、ストレージサービスレベルでの同期レプリケーションを実装したものです。AZ1とAZ2にそれぞれ完全なコピーが配置されています。フェイルオーバーイベントが発生した場合、データベースを実行しているAmazon EC2ホストは、AZ1のアクティブノードを参照しています。そのノードが停止したりアクセス不能になった場合、ホストクラスターレベルでフェイルオーバーが発生し、同期的にミラーリングされた2番目のデータコピーにアクセスするため、データ損失やプロダクションアプリケーションへの影響はありません。
ご想像の通り、これら2つのデプロイメントオプションにはコストの違いがあります。単一のAZと比べて、2つのAvailability Zoneにまたがるデプロイメントの方がコストがかかります。お客様はよく、「この程度の復元力で十分なのか？」「より高い耐久性が必要な状況があり、そのための追加コストを負担すべきか？」といったことを検討されます。また、Region1とRegion2にそれぞれSingle-AZデプロイメントを配置し、より高い復元力を実現するために、データベースレベルやアプリケーションレベルでのレプリケーションを行うお客様もいらっしゃいます。
ここで、これらのストレージサービスの核心部分、つまりインフラストラクチャにおける価値の源泉について詳しく見ていきましょう。まずはスナップショットから始めましょう。スナップショットはストレージ業界において非常に基本的な機能であり、誰もが知っているものです。ストレージサービスによって実装方法は若干異なりますが、Amazon FSx for NetApp ONTAPとAmazon FSx for OpenZFSの場合、基本的にボリュームがあり、そのボリューム内にアクティブデータ用の領域とスナップショットの管理・保存用の領域があります。スナップショット自体は非常に軽量で、それ自体ではまったく容量を占有しません。
1日に複数のスナップショットを取得できます。4時間ごと、1時間ごとにスナップショットを取得するお客様もいれば、15分ごとに取得するお客様もいます。興味深いのは、データベースが稼働しているEC2ホストにインストールされたソフトウェアシムを使用することで、アプリケーションとデータベースの整合性を確保できる点です。例えば、EC2インスタンスまたはインスタンス群で、SQL Server、Oracle、SAP HANAなどのデータベースが稼働している場合、このソフトウェアを使用すると、データベースに一時停止を指示し、スナップショットを取得した後、再開するという一連の処理を数秒で実行できます。
これにより、スナップショットがデータベースと整合性を保っていることが保証され、データベースを復元する際に、スナップショットからの復旧に伴うロールフォワードリカバリが不要になります。単にスナップショットが取得された時点の状態に戻すだけで、数分で完了します。スナップショットの取得は数秒で完了し、スナップショットからのロールバックと復旧も数分で完了する、非常に高速な処理です。ビジネスニーズに応じて、必要な数のリカバリポイントを確保できるというわけです。おそらく最も重要なのは、これらのスナップショットを取得する際、データベースの整合性が保たれるだけでなく、パフォーマンスへの影響がないということです。本番環境のデータベースへの影響を避けたいものですが、実際にそのように動作します。また、FSxの基盤技術を使用して、あるファイルシステムから別のファイルシステムにスナップショットをレプリケートすることができます。つまり、Region1にあるデータベースのスナップショットを、災害復旧の目的でRegion2の別のFSxファイルシステムにレプリケートすることが可能です。
さて、これらのSnapshotを使って非常に興味深いことができます。先ほどご覧いただいたのと同じSnapshotモデルですが、これらのSnapshotを使って「Clone」と呼ばれるものを作成できます。このスライドには、異なる3つの時点で取得された3つのSnapshotが示されています。これらのSnapshotそれぞれからCloneを作成すると、その時点でのデータベースの仮想コピーが3つできることになります。これにより、開発環境やテスト環境の更新をより頻繁に行うことができ、週末に出社してコピー作業を行う必要もなくなります。火曜日の午後2時に簡単にSnapshotを取得し、Cloneを作成して、開発用データベース、テスト用データベース、あるいは明日の研修用データベースを立ち上げることができるのです。
特に興味深いのは、Snapshotは容量を取らないということです。そのSnapshotを元にCloneを作成しても、つまりそのボリュームの仮想的な完全コピーを作成しても、同様に容量を取りません。Clone環境で容量が増えるのは、そのCloneにデータを追加する場合だけです。これは、Cloneが書き込み可能だからです。
例えば、今朝10時にデータベースのSnapshotを取得し、10時30分にそのSnapshotからCloneを作成したとします。このCloneに対して、テーブルの追加や削除など、好きな操作を行うことができます。この時点で、Cloneは本番環境のコピーとは異なる状態になっています。実質的に、独立したデータベースのインスタンスとして扱えるので、Oracleのアップグレードのテストや、テーブルの削除・追加のテスト、さまざまな「what-if」シナリオのテストにCloneを活用できます。テストが終わったら、簡単に破棄することもできます。作成も破棄も非常に簡単なのです。
データベースのコピーをより多く持てたら何ができるか、考えてみてください。どれだけテストの幅が広がるでしょうか？どれだけアジリティが向上するでしょうか？データベースのコピーをより多く作れれば、どれだけ作業のスピードが上がるでしょうか？多くのお客様にとって、Cloneの使用がこれらの課題への答えとなっています。最後に興味深いポイントとして、右端の箇条書きにあるように、Cloneを親から分離（Split）することができます。これらのCloneは、分離するまでは親に紐付いています。分離すると、完全なコピーが作成されます。
Snapshotが取得された時点のアクティブなデータすべてを、例えばClone番号1にコピーします。これを分離して、本番環境や主要な開発環境用のコピーとして昇格させることができます。リージョン間でこれを行うお客様もいます。リージョン1からリージョン2にCloneをレプリケートし、Clone環境を昇格させて、もう一方のリージョンでそのCloneを指すように本番アプリケーションを起動します。これは災害復旧テストを行うための非常に優れた方法で、火曜日の午後2時でも実施できるのです。
別のリージョンでアプリケーションを起動できることを証明するよう依頼され、数時間の時間が与えられた場合、それは非常に簡単に実行できます。FlexCloneを使用して、親ボリュームに接続したままにするか、分割するかを選択できます。そのクローンで表現されているテーブルやログなどを指すデータベースの別インスタンスを起動することができます。Oracleの場合、異なるデータベース名やSIDを使用するなど、事前に準備作業が必要です。両方のデータベースが同時に実行できるようにするための準備が必要ですが、非常にシンプルな方法です。多くのお客様がこの有用な機能を活用しています。実際、この機能はONTAPやZFSのオンプレミス環境で何十年も使用されてきました。
ここで、いくつかのお客様の事例についてお話ししましょう。約18ヶ月前、Adidasが私たちに相談してきました。彼らは複数のデータセンターや場所に分散した多数のERPシステムを抱えていました。これらはすべてオンプレミスでしたが、すべてのインスタンスを1つのセットに統合し、レガシーERPのSAP ECCから最新のS/4HANAにアップグレードしたいと考えていました。
彼らはかなりのリスクを取りました。オンプレミスからクラウドへの移行、基盤となるデータベースの変更、そしてインフラ全体のスタック管理に関するプロセスを完全に変更することを決断したのです。大きな賭けでしたが、結果は非常に良好でした。これは世界最大規模のS/4HANA実装の一つです。すべてAWS上で運用されており、先ほど説明したスナップショットとクローンの機能を理由に、FSx for ONTAPを選択しました。
彼らにはリカバリーと再起動の問題がありました。リカバリーには多くの時間がかかっていましたが、目標はリカバリーだけではありませんでした。データベースをリカバリーすることと再起動することは別の問題です。HANAの場合、インメモリデータベースなので、再起動する前にデータベース全体をメモリにロードする必要があります。彼らはリカバリーと再起動にかかる時間を懸念していました。以前のオンプレミス環境では、ERP全体のリカバリーに最大4時間かかっていましたが、先ほど説明したスナップショットからのリカバリーを使用することで、現在はAWS上で20分以下で完了すると報告しています。
また、開発、テスト、トレーニング、およびアップグレードシナリオ用のサンドボックス環境のために、ONTAPのクローン機能であるFlexClonesを使用してデータベースのコピーを効率的に作成しています。これらすべてをスナップショットとクローンで実現しており、非常に満足しています。ご覧の通り、リカバリー時間は約59%削減されました。
もう1つご紹介したいお客様は、通信業界のAmdocsです。彼らは顧客ごとに複数のデータベースを運用するビジネスを展開しています。大手通信会社やその他の通信企業向けにサービスを提供しているAmdocsは、インフラストラクチャ上で顧客ごとに複数のデータベースを管理しています。AWSの様々なストレージサービスを検討した結果、Amazon FSx for OpenZFSを選択し、NFSを介してOracleデータベースに接続することに全く問題を感じていません。彼らは実際に、スナップショットとクローンを使用して、数百ものスタンバイデータベース、レポート用データベース、テスト・開発用データベースを作成しています。
よく話題に上がるのは、先ほど触れたレジリエンシーだけでなく、パフォーマンスについてです。これらのサービス間のパフォーマンスの比較についてよく質問を受けます。私たちが行ったすべてのテスト、そしてお客様からの報告によると、Amazon FSx for OpenZFSは、本日お話している3つのFSxストレージサービスの中で、データベース環境だけでなく、その他の高性能環境においても、最も低いレイテンシーを実現しています。このように、AmdocsによるOpenZFSの導入は非常に成功を収めています。
まず最も重要なのは、Amazon FSxへの移行方法です。 これは、どのような環境から移行するかによって異なります。例えば、オンプレミスのONTAPやOpenZFSからの移行であれば、両者とも組み込みのレプリケーションエンジンを持っているので、単純にデータをレプリケートすることができます。その他のストレージからの場合、FSxへのデータ移行には様々な方法があります。右側に示されているように、ファイルを移行する場合はAWS DataSyncを使用できます。SMBやNFS経由でデータベースを運用することに問題がなければ、DataSyncを使ってファイルをAからBへコピーすることができます。
Cirus DataやRiverMeadowのような、長年業界で実績のあるISVツールも多数あります。これらはブロックベースの移行に特化しており、オンプレミスのブロックストレージ上のデータベースからAmazon EBSやFSx for ONTAPへの移行を効率的に行うことができます。最後に、今でも一般的な方法として、データベースベースのレプリケーションがあります。これは、両環境にデータベースを構築し、その2つのデータベースインスタンス間でレプリケーションを行ってデータを移行する方法です。
これは何度か言及しましたが、OpenZFSにも当てはまります。 スライドには示されていませんが、ストレージサービスに自身の間でレプリケーションを行う機能が備わっている場合は、それを活用することをお勧めしています。ONTAPの場合、SnapMirrorと呼ばれる機能をサポートしています。 これはNetAppのオンプレミスからFSxへの移行ツールとしてだけでなく、リージョン間やオンプレミスとAWS間のデータ保護ツールとしても機能します。データベースはオンプレミスに置いたまま、クラウドにDRコピーを持ちたいというお客様もいますが、ONTAPからONTAPへの場合、SnapMirrorがその役割を見事に果たします。
最後のカスタマーケースをご紹介します - 実は、この後にもう1件あります。S&P Global Market Intelligenceの事例です。彼らは多数のSQL Serverインスタンスをawsに移行したいと考えていました。具体的には、SQL Server FCIを導入しました。これには2つの理由がありました：Microsoft Enterpriseライセンスに関連する追加コストを削減したかったこと、そしてその結果、かなりの経費削減に成功したことです。また、AWSでのマルチAZストレージ展開も望んでいました。 このスライドをご覧いただくと、これが彼らの実際のインフラ構成です - 同一リージョン内の2つのAZに、クラスター形式でSQL Serverを展開し、両端に1つずつノードを配置しています。FSx for NetApp ONTAPがこれらのAvailability Zoneをまたがって構成されています。
このように、2つのAZ間で同期レプリケーションを行っています。この構成を導入することで、高い回復性を確保できただけでなく、Microsoft licensingのコストが大幅に削減されたため、オンプレミス環境と比べてかなりのコスト削減を実現できたと彼らは評価しています。
これがS&P Global Market Intelligenceの事例です。 数百のデータベースを保有しており、接続方式としてiSCSIを使用しています。 次にChange Healthcareの事例に移りますが、彼らも同様の構成を採用していますが、こちらはFSx for Windows File Serverを使用しています。プロトコルはSMBで、2つのAvailability Zoneにまたがって展開されています。彼らの設計目標も、100個未満のデータベースをAWSに移行することでしたが、要件は全く同じでした。ライセンスコストを削減し、優れたパフォーマンスを確保し、クロスAZ展開による回復性を実現することでした。この事例では、ほぼ100%がWindowsショップだったため、FSx for Windows File Serverが自然な選択肢となりました。
これは少し細かい図ですが、これら3つのFSxサービスを比較することが目的です。これらのストレージサービスに関連する機能と、その機能がもたらすビジネス価値が右側に示されています。いくつか例を挙げてみましょう。データベースの整合性のとれたバックアップの作成について見てみると、FSx for Windowsではネイティブにはできませんが、ZFSとONTAPの場合は、先ほど説明したスナップショットメカニズムを通じて数秒で実行でき、復旧も数分で行えます。ここでのポイントは、要件セット、実現したいこと、オンプレミスや他のクラウドからの移行元の環境を理解し、これら3つのFSxサービスやRyanが説明したAmazon EBSの中から、最も適したものを選択することです。
なぜFSxを選ぶべきなのでしょうか？オンプレミスでONTAPやZFS、Windowsを使用していて、同じような使用感をAWSでも得たいという理由かもしれません。ブロックアクセスやファイルアクセスが必要な場合もあるでしょう - FSxファミリーでは両方、あるいはどちらか一方を選択できます。ストレージの回復性も多くの場合重要です。一般的に、データベース管理者にとってパフォーマンスと回復性は密接に関連しています。そのため、マルチAZ展開が適している場合もあり、FSxでそれを実現できます。そして最後に、これまで説明してきたスナップショット、クローン、レプリケーションといった機能が全て組み込まれています。
AWSストレージ選択のためのアセスメントとre:Inventセッション情報
私がまだ触れていない点で、これらのカスタマーストーリーのいくつかで重要な要素となっているのが、FSxファミリーに備わっているStorage Efficiencyを適用できる機能、つまり圧縮や重複排除です。 実は、先ほどのスライドに戻ると、最後の行がStorage Efficiencyを表しています。これらのサービスには、重複排除や圧縮の様々なバリエーションがあることがわかります。データベースの重複排除では必ずしも大きな効果が得られるわけではありませんが、圧縮に関しては40%、50%、60%といった非常に良好な結果が得られることが多いです。すべてのお客様がこれらの機能をオンにするわけではありませんが - これはトグルスイッチのようなもので、オン・オフを切り替えられます - 全体的なTCOを削減する上で大きな価値を生み出すことができます。
最後に、どこから始めればよいのでしょうか？私からの推奨は、通常、AWSのアカウントチームと協力して何らかのアセスメントを実施することです。非常にフォーマルなものから比較的インフォーマルなものまで - これは本当にお客様とアカウントチームの判断次第です。インフラストラクチャには、必ずしも明白でない事象が発生していることがよくあります。インフラストラクチャのプロバイダーとして、私たちは皆、インフラのあらゆる部分で何が起きているのかを正確に把握しようと努めています。しかし、それは時として困難です。そのため、アセスメントによって、データがどこにあるのか、誰が所有しているのか、環境内の他のデータとどのように関連しているのかなど、完全には把握できていない領域に光を当てることができます。これらのアセスメントは、AWSのリソースまたはリソースのセット、あるいは私たちのConsulting Partnerのいずれかによって実施することができます。基本的には、お客様の状況に応じて、約30日間、場合によってはそれ以上のデータ収集を行います。アセスメントの最後に提供するのは、
私たちの調査結果の包括的な概要です。これらのデータベースや他のワークロードがどのように相互作用しているかを示し、AWSへの移行グループを構築する場合、それらがどのようにグループ化され、相互関係を持つかを説明します。開発環境と本番環境を区別しながら、それぞれのパフォーマンスの比較を提示します。これらのすべての側面は、アセスメントの過程で発見することができます。
このスライドでもう一つ注目していただきたい点があります。少し読みづらいかもしれませんが、今週のプレゼンテーションやセッション全体において、Storageがいかに充実した形で取り上げられているかをお示ししたいと思います。これらはすべてStorage関連のセッションで、データにフォーカスしたものもあります。Storageのトラックをフォローするためにお越しの方々のために、多数のオプションをご用意しています。これらのセッションはすべてカタログに掲載されており、詳細をご確認いただけます。各日にわたって様々なセッションを予定しています。
Ryan、何か付け加えることはありますか？はい、火曜日の真ん中に、私がSTG 345を発表します。これは複数のトピックを組み合わせたユニークなセッションです。Amazon EC2とStore for TDBをご利用の方々向けに、Instance StoreとAmazon EBSの最良の側面を組み合わせたChalk Talkとなっています。自己管理型データベースの最適化を試してみたい方には、非常に良いセッションとなるでしょう。私の話をもう一度聞いていただき、デモンストレーションもご覧いただけます。
これは利用可能なストレージ関連セッションの完全なリストではありません。カタログにはさらに多くのセッションがあり、素晴らしいデモンストレーションも用意されていますので、ぜひ探索してみることをお勧めします。そういうわけで、re:Inventでの素晴らしい時間をお過ごしください。ご質問やご意見、コメントなどがございましたら、お気軽にお声がけください。ゆっくりとお話しさせていただきます。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion