re:Invent 2024: Thomson ReutersのSQL Server運用効率化事例 - RDS Customの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Supercharge your SQL Server workloads, featuring Thomson Reuters (XNT203)
この動画では、Thomson ReutersがSQL ServerワークロードをAWSに移行し、運用効率を向上させた事例が紹介されています。SQL Server用のAmazon RDS Customを活用することで、マネージド型データベースの利便性と、オペレーティングシステムへの直接アクセスという両方のメリットを得られた点が説明されています。また、SQL Server Developer Editionの活用やメモリ最適化インスタンスの選択、AWS Storage Gatewayの利用といった具体的な運用効率化のヒントも共有されています。Thomson Reutersは、これらの施策により運用費用を40%削減し、運用効率を5倍に向上させることに成功しました。SQL Serverワークロードの移行手法や高可用性の確保方法など、実践的な知見が豊富に盛り込まれています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSでのSQL Serverワークロード最適化セッション：導入と概要
みなさん、おはようございます。朝8時30分という時間ですが、今日は皆さんを元気にしたいと思います。朝のコーヒーは飲まれましたでしょうか。それでは始めましょう。XN 203「Thomson Reputersが実践するSQL Serverワークロードの性能向上」へようこそ。始める前に、簡単に皆さんのことを知らせていただきたいと思います。SQL Server上でアプリケーションを実行している方は手を挙げてください。わあ、かなりの数ですね。つまり、皆さん適切なセッションに来られたということですね。では、それらをAWS上で実行している方は手を挙げてください。素晴らしい、私たちは顧客を大切にしています。最後の質問が一番重要です。コスト削減に興味がある方は両手を挙げてください。ここで少しストレッチをしましょう。左右に動かして、血行を良くしましょう。さあ、私も元気が出てきました。
私はAWSのSenior Solutions ArchitectのPratip Bagchiです。本日は、Thomson ReputersのDirectorであるNitin Shivani氏と、AWSのTech Leader for Microsoft WorkloadsであるYogi Barot氏にもご参加いただいています。私たち3人で、SQL Serverワークロードを単に実行するだけでなく、運用効率を高めコスト最適化された形で性能を向上させる方法についてお話しさせていただきます。 本日のアジェンダを見ていきましょう。まず、なぜお客様がSQL Serverを実行するクラウドとしてAWSを選択されているのかについてお話しします。次に、AWSへの移行に関する様々な方法についてご紹介します。その後、お客様からよく耳にする移行後の課題について説明します。そして、NitinがThomson Reutersの最も重要なビジネスクリティカルなアプリケーションの一つについて、クラウドジャーニーを共有します。最後に、YogiがAWS上でのSQL Serverワークロードの運用方法についてのヒントとコツをお話しして、セッションを締めくくります。
AWSがSQL Server実行環境として選ばれる理由と移行オプション
それでは、なぜお客様がSQL Serverワークロードを実行するクラウドとしてAWSを選択されているのか見ていきましょう。まず第一に、総保有コスト（TCO）の削減です。コストの話は常に会話の糸口となります。インフラストラクチャとライセンスの両面で大幅なコスト削減を実現できます。AWS上で実行する場合、SQL Serverのライセンスで最大45%、Windows Serverのライセンスで最大77%の削減が可能です。 次に、高いパフォーマンスと信頼性です。AWS上でSQL Serverワークロードを実行することで、計画外のダウンタイムを98%削減できます。同時に、開発者の生産性が26%向上し、デプロイメントは71%速くなります。
柔軟なライセンスオプションもご用意しています。既存の投資を活用するBring Your Own License（BYOL）モデルと、ライセンス管理やコンプライアンス管理から解放されるLicense Includedモデルの2つの選択肢があります。 SQL Serverワークロードの構築と実行のための、シンプルで使いやすい統合された環境を提供しています。AWS Launch Wizard for SQL Serverのような機能では、サイジングオプションや設定オプションを指定し、SQL Serverワークロードをデプロイするための段階的なガイダンスを受けることができます。これは、初めてAWSを使用するDBAや開発者の方々に特に便利な機能です。
私たちは、クラウド上でMicrosoftワークロードを実行する最も豊富な経験を持っています。他のクラウドプロバイダーよりも長い16年以上にわたり、SQL Serverワークロードを実行してきました。数週間前に読んだIDC InfoBriefの記事によると、52%のお客様がSQL Serverワークロードの実行にAWSを選択されているとのことでした。これは、次の6つのクラウドプロバイダーを合わせた数よりも多い数字です。 そして最後に、これは重要なポイントですが、将来のモダナイゼーションへの扉を開きます。AWS上でワークロードの実行を開始すると、目的に応じた様々なデータベースへのモダナイゼーションが可能になり、ライセンス管理やパッチ管理、バックアップの取得、プロビジョニングといった作業から解放され、その時間をデータを活用したイノベーションに投資することができます。
なぜかはお分かりいただけたと思いますので、次は具体的な選択肢について見ていきましょう。セルフマネージドから完全マネージド型のAmazon Relational Database Service（Amazon RDS）まで、様々な選択肢をご用意しています。お客様のクラウドジャーニーがどの段階にあっても、私たちはそこでサポートできる体制を整えています。
一方では、SQL ServerワークロードをAmazon EC2にリフト＆シフトするという選択肢があります。EC2は、SQL Serverワークロードを実行するための実績があり、信頼性が高く、安全なクラウドプラットフォームの一つです。多くのお客様がこの方法を好む理由は、SQL Serverワークロードを移行する最もシンプルで簡単な方法だからです。私のお客様であるThomson Reutersは、データセンターからの移行を決断した際、時間的制約の厳しい重要なプロセスでした。彼らはAmazon EC2インスタンスへの移行を選択しました。主な理由は、可能な限り早くAWSに移行したかったことと、既存のライセンス投資を活用したかったからです。さらに、 開発者やDBAがSQL Serverの環境に完全に精通していたため、選択は明確でした。また、オペレーティングシステムレベルのアクセスも必要としていました。
一方で、多くのお客様はSQL ServerワークロードをAWSのクラウドネイティブな目的別データベースにリファクタリングすることを選択します。正直に申し上げますと、リファクタリングはクラウドの価値を最大限に引き出せますが、時間がかかります。そのため、多くのお客様は SQL Server用のAmazon RDSやSQL Server用のAmazon RDS Customなどのマネージドサービスへのリプラットフォームを選択します。セルフマネージド型からフルマネージド型サービスへの移行により、バックアップの取得、プロビジョニング、パッチ管理などの作業が不要になり、ビジネスにとって最も重要なことに時間を投資できるようになります。
Thomson ReutersのAWS移行事例：課題と解決策
本日はリプラットフォームに焦点を当てますが、まずはお客様がAmazon EC2インスタンスでSQL Serverワークロードの運用を開始した後の本番環境での課題を見てみましょう。お客様から聞く本番環境での課題を、私は大きく4つのカテゴリーに分類することができました。1つ目はコスト管理です。様々なツールや機能を提供していますが、クラウド上でのSQL Serverのコストをコントロールすることは簡単ではありません。ストレージとコンピューティングのペイアズユーゴーモデルに加えて、パフォーマンスを確保するための過剰なプロビジョニングの傾向が、データベースの費用を増加させます。2つ目は、商用データベースプロバイダーの厳しいライセンス条件と、サポート終了の課題への対応です。例えば、Microsoftは今年の夏にSQL Server 2014のサポートを終了すると発表しました。本番環境や非本番環境でSQL Server 2014を使用している場合、このサポート終了の課題に直面していることでしょう。
次はスケーラビリティと運用の回復力です。異なるAvailability Zone間で高可用性を確保し、異なるリージョン間でディザスタリカバリ戦略を設計する必要があります。様々なツールやサービスを提供していますが、お客様に約束したRTOとRPOの要件を確実に満たすために、既存のアプリケーションとこれらを統合する必要があり、それは簡単な作業ではありません。そして最後に重要なのが パッチ管理です。これはIT運用にとって大きな付加価値を生まない作業となります。ほとんどの作業を自動化できますが、自動化後も継続的な監視が必要で、データベースとホスト（この場合はEC2インスタンス）のセキュリティ修正やパフォーマンスパッチが最新の状態に保たれるよう、適切な計画と実行戦略を確保する必要があります。
Thomson ReutersはAWS上でSQL Serverワークロードの運用を開始した直後から、これらすべてのポストプロダクションの課題に直面していました。ここで、最も重要なビジネスアプリケーションの1つを管理されているNitin Shivaniさんをお迎えして、クラウドジャーニーについてお話しいただきたいと思います。Nitin Shivaniさん、よろしくお願いします。ありがとうございます、Pradeep。皆様、おはようございます。素晴らしいですね。フィードバックありがとうございます。会場の皆様にお聞きしたいことがあります。このイベントに初めて参加される方は手を挙げていただけますか？わあ、かなりの人数ですね。実は私も皆様と同じで、今回が初参加なんです。
私にとってLas Vegasも初めてで、素晴らしい朝を迎えることができました。まず、ご来場の皆様、そしてオンラインでご視聴いただいている方々、特にThomson Reutersの同僚の皆様、会場にいらっしゃるThomson Reutersの皆様に感謝申し上げます。
始めに、私と組織についてご紹介させていただきます。私はNitin Shivaniと申します。Product Engineering部門のTechnology Directorを務めており、アーキテクトのグループをリードしています。私の主な担当はAWSへの移行、モダナイゼーション、そしてGenerative AIイニシアチブです。Thomson Reutersでは、複雑なものを明確にし、プロフェッショナルの方々が今日を理解し、明日を切り開くお手伝いをしています。これを実現できているのは、テクノロジーとイノベーション、高度なAI、業界をリードするインサイトなどのおかげです。
ご覧の通り、私たちはデータドリブンな組織としての強いビジョンに導かれています。セキュアでスケーラブルな方法で、より迅速に答えを得ることは私たちにとって極めて重要です。これから、Thomson Reuters内の重要なミッションクリティカルアプリケーションの1つである、ONESOURCE Global Trade Platformについてお話しします。簡単に説明させていただきますと、このプラットフォームは企業の関税負担を最小限に抑え、サプライチェーンポートフォリオを最適化し、さらに国際規制の変更に備えて予測することを支援します。
このプラットフォームは、ご覧のように、Global Classification、Denied Party Screening、Import Export Managementなど、様々な製品を提供しています。では、プラットフォームを数字で見ていきましょう。これは私たちの運用規模を理解していただくために重要です。この堅牢なインフラストラクチャは、現在100台以上のアプリケーションサーバーとデータベースサーバーをサポートしています。プラットフォームには100テラバイトの顧客データが保存されています。これは重要な取引、貿易、コンプライアンスデータです。プラットフォームは1分間に200万件以上のトランザクションを処理しており、これは本質的に、大量のデータが常にリアルタイムで流れていることを意味します。私たちは60分のRTOとRPOをサポートするようにプラットフォームを構築しました。私たちは回復力を持っており、それは必須なのです。
RDS CustomによるSQL Server運用の最適化
この大規模なアーキテクチャについてお話ししましょう。ここでは、バックエンドデータベースアーキテクチャについて、よりシンプルなバージョンをご紹介します。これを1つのクラスターとして考えていただき、Thomson Reutersという組織全体で、このようなクラスターを複数運用しています。私たちは、オンプレミスからAWSへの顧客ワークロードの移行に際して、基本的な再ホスティングというシンプルな戦略を採用しました。オンプレミスの顧客データは、AWS Storage Gatewayを介して安全にバックアップされ、SQL Serverが稼働しているAmazon EC2インスタンスに復元されます。可用性とレジリエンスを確保するため、Availability Zone内での同期レプリケーションと、リージョン間での非同期レプリケーションにサードパーティのソフトウェアソリューションを使用しています。このサードパーティソフトウェアは、クォーラムの維持にAmazon FSX for Windowsを使用しています。また、ネイティブなバックアップ戦略として、顧客の完全バックアップをEBSボリュームに保存し、そこからクロスリージョンレプリケーションされているS3バケットにシフトするプロセスを実行しています。
では、なぜバックエンドデータベースに主な焦点を当てているのかを見ていきましょう。最も重要な点は、デプロイメントとスケールの観点から、100以上のデータベースインスタンスがあり、各インスタンスが50～60の顧客データをホストしているという、その規模の大きさです。
私たちのスケールは非常に大きく、リアルタイムで流れる大量のトランザクションを生成する大規模なユーザーベースを抱えています。安定性の維持は不可欠です。というのも、何か問題が発生すると、顧客とライターの両方のビジネス運営に悪影響を及ぼすからです。インフラストラクチャ全体で複数のインスタンスが稼働しているため、データの整合性と一貫性は常に課題となっていますが、SQL Serverはこの課題解決に大きな力となっています。
パフォーマンスの観点では、データベースの保守と最適化を支援する包括的な監視・管理ツール群を備えています。Thomson Reutersは顧客とそのデータとともに成長を続けており、顧客ニーズに応え、将来に備えるためのスケールとレジリエンスを計画しています。データの機密性を考慮すると、セキュリティは最優先事項です。1分間に200万件のトランザクションを処理する私たちのデータベースインフラストラクチャには、貴重なデータ資産を保護するための複数の堅牢なセキュリティ対策が組み込まれています。RPO要件の遵守は、レジリエンスの観点から絶対に必要不可欠です。
AWSの同僚から非常に重要なことを学びました - すべてのものは常に故障するということです。私たちも様々な課題に直面しました。次の2枚のスライドでは、本番環境前の下位環境での課題と、本番環境での課題について説明します。フェイルオーバーテストを実施している際に最初に遭遇した問題は、データの破損でした。これは使用していたサードパーティのアプリケーションソフトウェアに起因しており、私たちのチームは適切な対応として、ベンダーにサポートを要請しました。しかし、この問題は災害復旧プロセスの整合性に影響を及ぼしていました。
私たちの運用規模を考えると、 SQL Serverのパッチ適用は非常に困難な課題となっています。システムには最新のセキュリティパッチを適用し続ける必要がありますが、この作業には時間がかかります。インスタンス上で複数のデータベースが稼働しており、それぞれのデータベースには独自のパフォーマンス特性と要件があります。これらの課題は本番環境前だけでなく本番環境後にも及び、コストも重要な要因となっています。コストの観点から言えば、先ほど触れたように、データレプリケーション用のサードパーティソリューションを使用しており、これがライセンスコストを押し上げていました。また、ネイティブのバックアップ戦略としてEBS上にバックアップを保存し、その後S3に移動する方式を採用していましたが、これもコストに影響を与えていました。
また、運用の優秀性に関して、本番環境後の課題も抱えていました。Windowsパッチの適用やSQL Serverパッチの適用には、運用に支障をきたさないよう慎重な計画が必要です。さらに、EBSボリュームへのバックアップの保存には時間がかかります。アーキテクチャのちょっとした変更で、これらの課題の多くがどのように解決されたのかをご説明させていただきます。先ほど、サードパーティのソフトウェアを使用してレプリケーションを行い、リージョン間でデータを移動するためのネイティブバックアップ戦略と共に、2つのインスタンスにまたがって顧客データを再ホストしていたとお話ししました。
私たちは以下のように課題を解決しました：再ホストの代わりに、RDS Customを使用してワークロードをリフト＆シフトしました。このアーキテクチャにはコスト面での利点を示す3つの重要なコンポーネントがあります。1つ目は、Availability Zone内のプライマリノードからレプリカへのフェイルオーバー機能です。2つ目は、Availability Zone間でのデータ同期、そして3つ目は、リージョン間でデータを移動するためのクロスリージョンスナップショットコピーです。メリットは明確です：コスト最適化の観点から、データレプリケーション用のサードパーティライセンスソフトウェアが不要になりました。すぐに使えるソリューションが利用可能となり、以前のEBSボリュームを使用したバックアップ・リストア戦略が不要になりました。RDS Customがこの機能をサポートしているため、インスタンスフリートを手動で更新する必要がなくなりました。
RDS Customが提供するこのすぐに使えるソリューションは、もはや私の頭痛の種ではありません。AWSチームが対応してくれます。このメリットの重要な点として強調したいのは、Thomson Reuters内では企業のセキュリティで承認されたGolden Imageがあり、これをRDS Customのプラットフォームに統合できるようになったことです。これは素晴らしい機能です。なぜなら、AMSにカスタム更新が施されており、それをAWSに移行したいと考えていましたが、RDS Customではそれがサポートされているからです。
私たちが期待していた運用の優秀性を実現してくれたAWSのメンバー、PradeepとYogiに感謝したいと思います。それでは、AWSでのSQL Serverワークロードの運用化について、Yogiに説明を譲りたいと思います。ありがとうございました。NitinさんがThomson Reutersのアーキテクチャ、既存のアーキテクチャ、そして皆さんの多くが現在直面しているかもしれない課題について説明してくれてありがとうございます。目標は、AWSでのSQL Serverワークロードを運用化し、いくつかの課題を克服する方法についてお話することです。
AWS上でのSQL Server高可用性とバックアップ戦略
Pradeepが先ほど説明したように、SQL Serverを実行する際には、Lift and Shiftという選択肢があり、ほとんどの顧客がそれを選択しています。Nitinのチームも同様でした。彼らはタイトな期限とライセンス投資の制約の中でデータセンターからの移行を行いました。クラウドが初めてだったため、仮想マシン環境を提供するEC2上での実行を選択しました。アプリケーションの観点からは何も違いを感じることはなく、接続先のエンドポイントが変わるだけなので、非常に簡単です。しかし、2年以上運用してきた顧客の視点から見ると、いくつかの課題に直面し、マネージドサービスへの移行を検討するようになりました。
Amazon RDS for SQL Serverはマネージドサービスであるため、運用上の懸念が少なくなります。パッチ適用、バックアップ、監視、Multi-AZによる高可用性が全て管理されています。同時に、自動スケーリングも利用できます。RDS SQL Serverはこのような素晴らしいメリットを提供しますが、マネージドサービスであるが故に、アプリケーションが制限に直面するケースもあります。例えば、SAアカウントの使用制限があります。通常SQL ServerではいつもSAとしてログインしますが、RDSではそれができません。また、サーバー上に100以上のデータベースがある場合、RDS SQL Serverに移行できません。既存のライセンス投資があってBYOLを行いたい場合も、RDS SQL Serverではできません。さらに、一部のサードパーティアプリケーションがRDS SQL Server上での実行認証を受けていない場合もあります。
このような課題に直面した場合、RDS Custom for SQL Serverという両方の利点を兼ね備えた中間的なソリューションがあります。これは依然としてマネージドサービスなので、バックアップ、パッチ適用、自動監視、Multi-AZによる高可用性は維持されています。同時に、EC2のような体験も得られ、SAアクセスを取得したり、リモートデスクトップのようにRDPで接続してディスク容量を確認したりといった作業も可能です。re:Invent 2021で初めてAmazon RDS Custom for SQL Serverが発表され、以前はRDSに移行できなかった顧客要件に基づいて、RDS Customを使用してマネージドサービスに移行できるようになりました。これは依然としてマネージド体験でありながら、独自のメディアを持ち込む柔軟性を提供します。PradeepはBYOLについて言及しましたが、RDS Customでは、SQL Serverのインストールメディアとライセンスの両方をEC2インスタンスに持ち込むため、BYOMと呼ばれています。オンプレミスでもAWS上でも、独自のActive Directoryを使用でき、DatadogやRed Gate監視ソフトウェア、あるいは会社の要件で必要とされる他のバックアップソフトウェアなどのサードパーティエージェントをインストールすることもできます。これはマネージドサービスであるため、私たちはこれを自動化モードと呼んでいます。
Amazon RDS Customでは、これらの要件に対応できます。顧客が特定の時間枠内で環境をカスタマイズできるようにする必要があります。推奨される方法は、まずスナップショットを取得し、その後自動化を一時停止することです。自動化を一時停止すると、AWSが行う監視がそのインスタンスに対して一時停止され、カスタムドライバーやエージェントのインストール、追加のEBSボリュームの追加、SQLの設定変更などを行った後、自動化を再開できます。自動化の一時停止は最大24時間までで、それ以上は非準拠となるため、このカスタマイズは24時間以内に完了する必要があります。
この制限がありながらも柔軟性を提供することで、目的を達成することができます。きめ細かな制御が必要な場合、例えばRDS CustomにインストールされたSQL Server上でSQL CLRを実行したい場合も可能です。IDP権限、SA権限、きめ細かなアクセス制御が必要な場合も、リソース管理やリソースガバナンスを含めて、全てRDS Custom for SQL Serverでサポートされています。Lift and Shiftのシナリオでは、一部のアプリケーションは多くの変更を必要とせずにそのまま移行できます。RDS SQL Serverでは、マネージドサービスのストアドプロシージャの関係で、特定のコードやバックアップ・リストア手順の修正が必要になる場合がありますが、RDS Customを使用すれば、SQL ServerへのそのままのLift and Shift移行が可能で、移行方法に基づいて最小限のダウンタイムで実現できます。
それでは、このがお客様に適したソリューションかどうかを判断するためのユースケースについて説明しましょう。カスタムドライバーのインストールやXP_cmdshellの使用など、きめ細かな制御が必要な場合や、XP_cmdshellを使用するPowerShellスクリプトがある場合は、RDS Customを使用して継続して実行できます。また、商用既製品（COTS）アプリケーションなど、特定のサードパーティ製パッケージアプリケーションをAWSに移行したい場合もあります。これらのアプリケーションの中には、Microsoft SharePoint、CRM、Microsoft Dynamicsなど、RDS SQL Serverでの実行が認証されていないものもありますが、RDS Customなら実行が可能です。さらに、Always On Availability Groupクラスターを使用して移行を行いたい場合も、RDS Customで同様のオプションを使用して実現できます。
RDS Customの全体的なアーキテクチャと、このアーキテクチャがどのように要件を満たしているかを見ていきましょう。セキュリティは、Thomson Reutersだけでなく、すべてのお客様にとって非常に重要であり、AWSにとっても最優先事項です。RDS Customはお客様のVPC内にデプロイされ、お客様の環境内で実行されるため、追加の分離レイヤーなど、すべてのセキュリティ上の利点を提供します。インスタンスプロファイルとEBSボリュームを持つインスタンス上で実行され、SQL Serverと統合する追加のサービスを備えています。先ほど説明した監視の自動化、一時停止、再開などのカスタマイズをサポートするために、いくつかのエージェントをインストールする必要があります。Amazon CloudWatchでの監視用のCloudWatchエージェント、パッチ適用の自動化とスクリプト実行用のAWS Systems Managerエージェント、そしてこの自動化が破損していないかを確認するための独自のミニエージェントがあります。
サーバーには複数のエージェントがインストールされています。これらのエージェントを停止することはできません。エージェントを停止すると、Amazon RDS Customのサポート対象外となります。これらのアーキテクチャが連携することで、必要な柔軟性と共にシームレスな管理体験を提供します。
次にライセンスについて説明しましょう。PradeepがRDS CustomでのBYOLとBYOMについて言及したことは覚えていると思います。BYOMの仕組みについて説明すると、ライセンスに多額の投資をしている場合を考えてみましょう。SQL Server Standard Editionの2コアライセンス（2vCPU相当）は約7,000ドルです。最低でも4vCPUのライセンスが必要なので、Standard Editionで約15,000ドルになります。Enterprise Editionの場合は、バージョンによって50%から60%以上高くなります。特にThomson Reutersのように数百台のサーバーを持つ場合、SQL StandardとEnterpriseの組み合わせでどれだけのライセンス投資をしているか想像してみてください。私たちは、お客様の既存の投資を無駄にしたくありません。その投資を活用してコストを節約していただきたいと考えています。RDS Customを使用すれば、管理された環境を得ながら、そのライセンスを持ち込むことができます。
コスト削減のための第一のヒントは、非本番環境にDeveloper Editionを使用することです。Developer Editionはコストがゼロ、つまり無料で、Enterprise Editionと同じ機能を備えています。通常、本番環境には開発、QA、ステージングという3つの非本番環境があります。これらの非本番環境はすべて、EC2でもRDS Customでも無料で実行できます。BYOMモデルでは、Developer Editionも無料で持ち込むことができます。アーキテクトと相談して、このDeveloper Editionのメリットを活用してコストを削減することをお勧めします。ライセンスを持っておらず、新しいアプリケーションを構築している場合は、ライセンス込みのインスタンスを使用して、必要に応じて従量課金で利用することができます。
では、EC2上で動作するSQLでBYOMがどのように機能するかについて説明させていただきます。EC2でSQLを実行する場合、メモリ最適化インスタンスであるR5、R6、またはR7を使用します。SQL Serverは一般的にメモリを大量に消費します。データベースのサイズに達するまで、与えられたメモリをすべて使用しようとします。1テラバイトのデータベースがある場合、1テラバイト全体のメモリを使用して、データベース全体をメモリに格納します。SQLはメモリを大量に消費しますが、必要なメモリ量と実際の使用量の適切なバランスを見つける必要があります。ページライフエクスペクタンシーをチェックすることで、ページがメモリにどれだけ長く留まるかを確認し、最適な組み合わせを見つけることができます。
最新のインスタンスであるX2idnをご紹介します。これは1 CPUあたり32GBのメモリを持つインスタンスです。お客様とお話しする際は、必ずこのインスタンスタイプについて言及するようにしています。SQL Serverに関する2つ目のヒントは、メモリ最適化インスタンスを使用することです。ScaleやThomson Reutersグループとの仕事でも、コスト削減のために適切なインスタンスの導入をサポートしました。というのも、SQL ServerはCPUベースで課金されるからです。より多くのCPUを使用し、メモリが少ない場合、ライセンス料が高くなります。BYOMを使用する場合でも、より多くのライセンスが必要です。そのため、2つ目のヒントは、要件に合わせて適切なインスタンスを使用することです。2つのインスタンス、つまりEC2インスタンス上でBYOMを実行し、CEV（Custom Engine Version）を作成します。データベースとAMのバイナリデジタルスナップショットのようなCEVを作成すれば、このCEVを使用してRDS Customを起動できます。
では、高可用性について話しましょう。これは、RDSとRDS Customの機能の中で私が特に情熱を持っている機能の1つです。その理由をお話しさせてください。私は20年以上DBAとして働いており、ちなみにカナダ出身です。
DBAとして働いていた2012年、あるお客様のプロジェクトに携わっていました。メインオフィスはロサンゼルスにあり、バーバンクにもオフィスがあり、トロントに2つのデータセンターがありました。SQL Server Always On可用性グループが導入された際、この2つのデータセンターのSQL Serverレプリカを同期させる必要がありました。セットアップ、監視、管理、レプリカの同期状態の確認は悪夢のような作業でした。約12年前のことで、現在ほどネットワークが安定していなかったため、問題が発生することがよくありました。夜中に呼び出されることもあり、1日の50%をSQL Serverの高可用性管理に費やしていました。
Amazon RDS CustomとRDS SQL Serverを使用すれば、そのような悩みは解消されます。今では、クリック1つで高可用性を実現できます。Always On可用性グループとは異なり、RDS Customではブロックレベルのレプリケーションを実行します。プライマリでの変更はすべて、ブロックレベルでセカンダリにレプリケートされます。Multi-AZセットアップでは同期レプリケーションを使用し、Pratipさんがアーキテクチャで説明したように、DR目的でクロスリージョンスナップショットを作成することもできます。この高可用性機能により、自動フェイルオーバーについて心配する必要がなくなります。
具体的な仕組みを見ていきましょう。 RDS CustomでMulti-AZを選択すると、EBSストレージを持つプライマリDBと、別のEBSストレージを持つセカンダリDBが用意されます。読み取りと書き込みはプライマリに対してのみ行われ、 バックエンドでは、セカンダリEBSボリュームに対してブロックレベルの同期レプリケーションが実行されています。すべてが正常に動作している場合、これが通常の運用状態です。しかし、Nathanが言ったように、障害は常に発生するものであり、それを想定して設計する必要があります。コンピュートレベルまたはストレージレベルで何か問題が発生した場合、 システムはセカンダリEBSボリュームを読み書き可能なボリュームとしてアクティブ化する必要があると判断します。 読み書き可能なボリュームとしてアクティブ化し、SQL Serverデータベースサービスをこのボリュームを指すように変更し、SQL Serverサービスをプライマリとしてアクティブ化し、アプリケーションをそちらにフェイルオーバーするよう転送します。これらすべてが30〜60秒以内に実行され、何の心配もなく高可用性を実現します。
SQL Server移行オプションとThomson Reutersの成果
次に、Nitinが言及した2つ目の課題であるバックアップについて説明しましょう。 バックアップは、マネージドサービスであれ手動サービスであれ、DBAが管理しなければならない最重要タスクです。1つのデータベースを管理する場合は、ネイティブバックアップ、サーバーレベルのバックアップスナップショット、または個別のDBバックアップで対応できます。しかし、Thomson Reutersのような規模を考えてみてください - 数百のデータベース、数百テラバイトのデータを持つ数百のサーバーがあります。以前は、保持期間に基づいて通常7日から30日間、EBSボリュームにバックアップを保存していました。60%の圧縮率であっても、そのような大量のデータを長期間保存することは大きなコストがかかります。 さらに、多数のサーバーに対してAmazon S3へのバックアップ転送を管理する必要があり、これも管理の手間を増やす要因となっていました。
この課題に対処するため、私はAWS Storage Gatewayの使用を提案しました。 AWS Storage Gatewayには複数のコンポーネントがあり、その1つがFile Gatewayと呼ばれるものです。File Gatewayをファイル共有で使用すると、ネットワークドライブとしてマップできるSMB共有のように機能します。これをインスタンスにマップすることで、バックアップをより効率的に管理できるようになります。
このアプローチを使用すると、バックアップDBSを直接SMB共有にバックアップできます。つまり、DBSはAWS Storage Gatewayのファイル共有を使用して直接Amazon S3にバックアップできます。社内のベンチマークによると、このオプションはバックアップに関して最もコスト効率が良く、高パフォーマンスなバックアップと最速のリストア時間を実現します。全体として、バックアップの保存先としてAmazon EBS、Amazon FSx、Amazon FSx for NetApp、Amazon S3、またはAWS Storage Gatewayを選択できます。Storage GatewayはSQL Server 2022以前のバージョンを使用している場合のオプションの1つでした。
SQL Server 2022を使用している場合は、直接Amazon S3にバックアップするという追加オプションがあります。 数週間前にSQL Server 2025のプレビューが発表されました。私自身はまだテストしていませんが、今後数ヶ月以内に試してみる予定です。SQL Server 2022以降を使用している場合、Microsoft SQL Server自体に直接Amazon S3にバックアップを行う機能が追加されました。これは直接S3に保存されるため、バックアップ時間を50%削減できる最もコスト効率の良いオプションとなっています。
それでは、移行オプションについて説明しましょう。 SQL Serverデータベースの移行方法には、バックアップとリストア、AWS Database Migration Service、SQLアプリケーション、Always On可用性グループなど、複数の方法があります。今日は2つのオプションについてのみ説明します。Amazon RDS、Amazon RDS Custom、Amazon EC2へのSQL Server移行についてもっと詳しく知りたい方は、本日午後4時からMGNで開催される私のセッションにご参加ください。そこで移行についてより詳しく学び、アーキテクチャに関する相談もできます。
まず、バックアップとリストアを使用してAmazon RDS Customに移行する方法についてお話しします。 バックアップとリストアが第一のオプションとして挙げられているのは、シンプルで柔軟性が高く、多くのお客様に利用されているからです。DBAの方々にはなじみのある方法で、データベースの整合性を保ちながら、破損などの問題なく安定して動作します。データベースレベルでの完全なバックアップ機能を提供し、フルバックアップ、差分バックアップ、一連のトランザクションログバックアップが可能です。リカバリなしでフルバックアップをリストアし、リカバリなしで差分バックアップをリストアし、トランザクションログと最新のトランザクションログをリカバリ付きで適用することができます。これらのオプションにより、トランザクションログバックアップの頻度に応じて、数分単位での切り替えが可能です。このオプションは、EC2上のSQL Server、Amazon RDS、Amazon RDS Customのいずれでも利用できます。Thomson Reutersも、最初にEC2に移行した際や、その後のAmazon RDS Customへの移行時にこの方法を選択しました。
次に、2番目のオプションを見てみましょう。現在、Always On可用性グループを使用している方はどのくらいいらっしゃいますか？ Always Onのコンセプトをご存知の方なら、クラスターレスまたはWindows フェールオーバークラスターサービスを使用したクラスターで動作することをご存知でしょう。オンプレミスまたはEC2上で2台のEC2インスタンスや2台のサーバーを使用して高可用性を構成している場合、SQL Server分散可用性グループを使用してもう1つのレプリカを追加し、AWSにレプリケーションすることができます。この3番目のレプリカは、オンプレミスとAWS間のネットワークが設定されていれば、オンプレミスのSQL ServerとAmazon RDS Custom間で非同期レプリケーションを使用します。この設定により、アプリケーションを起動し、両方のレプリカが同期されるのを待ち、数日または数ヶ月間実行し続けることができます。切り替えの準備が整ったら、レプリカを簡単に切り替えることができます。このオプションでは、業務を妨げることなく最小限のダウンタイムで迅速な移行が可能です。
まとめに入る前に、ここで私が言及した主要なヒントの1つ目について触れたいと思います。3つの重要なヒントをお話ししました。1つ目はSQL Server Developer Editionの使用、2つ目はメモリ最適化インスタンスの使用、そして3つ目はバックアップにAWS Storage Gatewayを使用することでした。これらの3つのヒントを共有させていただきました。SQL Serverの運用についてさらにヒントが必要な方は、Thomson Reutersの運用効率化ガイダンスに基づく全体的な成果についてPratipにバトンタッチしたいと思います。
ありがとうございます。皆さん、データと数字が大好きですよね？Yogiさん、素晴らしいヒントとコツをありがとうございました。特に、非本番環境の実行に無料で使用できるSQL Server Developer Editionについての言及は素晴らしかったですね。スライドの数字を見ていただければ、この40-45分間お話ししてきたことのすべてが分かります。Thomson Reutersは運用費用全体で40パーセントの削減を達成しました。同時に、運用効率は5倍に向上しました。これは、以前は数週間かかっていたタスクが数日で完了できるようになったということで、効率性が大幅に改善されたことを示しています。
最も重要なのは、両者にとってベストな選択だったということです。開発者はマネージド型データベースの利便性を得られ、一方でデータベース管理者は、アプリケーション管理に不可欠な基盤となるオペレーティングシステムへのアクセスを確保できました。同様の要件をお持ちで、両方のメリットを必要とされる場合は、RDS Customが最適な選択肢となるでしょう。このQRコードをスキャンしていただくと、AWSでデータベースワークロードを実行するための様々なオプションについて、さらに詳しく学んでいただける関連リンクをご用意しています。
本日のセッションにご参加いただき、ありがとうございました。私たちの連絡先を通じて、後ほどオフラインでご連絡いただくことも可能です。私のメールアドレスはYogiBar@amazon.comです。その他のご質問がございましたら、メールでお気軽にお問い合わせください。喜んでサポートさせていただきます。ご参加ありがとうございました。よい一日を、そして素晴らしいre:Inventをお過ごしください。Las Vegasでの滞在もお楽しみください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion