re:Invent 2024: MindbodyのSQL Server 6万DBのAWS移行事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Mindbody migrated 60,000 SQL Server databases to AWS (XNT317)
この動画では、Mindbodyが60,000のSQL ServerデータベースをAWSに移行した事例が紹介されています。Local Zonesを活用してレイテンシーの課題を解決し、GP2からGP3へのストレージ移行によってコストを年間70万ドル強まで削減した過程が詳しく説明されています。また、High Availabilityの実現のためにSIOSを活用したブロックレベルレプリケーションの導入や、Infrastructure as Codeによる展開など、具体的な技術選定の理由と成果が示されています。最終的にはPostgreSQLへの移行を視野に入れるなど、さらなるモダナイゼーションへの取り組みも進行中であることが語られています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Mindbodyの大規模SQL Server移行プロジェクト：概要
皆様、本日は Mindbody が60,000のSQL Serverデータベースを AWSに移行した事例についてのセッションにご参加いただき、ありがとうございます。私の名前は Reghardt van Rooyen です。Mindbodyのこの移行プロジェクトで Senior Specialist Solution Architectとして携わった者として、本日皆様にお話できることを大変嬉しく、また誇りに思います。まず会場の皆様に伺いたいのですが、現在 AWSで本番用データベースを運用されている方は挙手をお願いできますでしょうか？なるほど、約3分の2の方ですね。では、今後24ヶ月以内にSQL Serverや他のデータベースを AWSに移行することを検討されている方はいらっしゃいますか？素晴らしい、約半数の方ですね。それでは、本日のセッションは皆様にぴったりの内容になるはずです。
Mindbodyの journey（移行の道のり）について、最初から詳しくご説明させていただきます。なぜ AWSを選んだのか、どのようなメリットがあったのか、オンプレミスのSQL Serverアーキテクチャがどのように AWSで変化したのかをご紹介します。また、ビジネス上の意思決定が移行計画にどのような影響を与えたのか、そしてどのようなツールを活用したのかについてもお話しします。移行プロセスの詳細な振り返りもご紹介します。もちろん、途中でさまざまな課題も発生しましたので、そちらもお伝えします。最後に、モダナイゼーションの次のステップと、この過程で得られた教訓についてもお話しさせていただきます。
Mindbodyの紹介とクラウド移行の目的
皆様、こんにちは。AWS Solution Architectの Lior Sadanです。私は AWSのお客様のクラウドワークロードの設計と展開をサポートしており、Mindbodyもその一社です。本日は特別ゲストとして、Mindbodyの Database Administration Managerである Tim Fordをお迎えしています。私は長年データプロフェッショナルとしてのキャリアを積み、コミュニティ活動にも数十年携わってきました。2010年には SQL Cruiseという面白い取り組みを始め、クルーズ船で1週間の研修を行いながら、参加者の皆さんと楽しい時間を過ごしました。
Mindbodyについてご説明させていただきます。Mindbodyは、ヨガスタジオ、フィットネスセンター、スパ、サロン向けのビジネスソリューション、いわば「ビジネスインボックス」のようなサービスです。私たちは業界のリーダーとして、全世界で約240万人のアクティブユーザーを抱えており、ClassPassや Bookerといったブランドでもご存知かもしれません。実は私も皆様のアプリケーションのユーザーで、ジムのクラスを予約して、そのほとんどをキャンセルしています。そのため、高可用性は非常に重要ですね。
では、最初に戻って、なぜクラウドへの移行を決めたのか、その目的についてお話しいただけますか？そうですね、多くの企業と同じように、最初の大きな理由はコスト削減でした。特にデータプラットフォームに関する埋没コストを変換したいと考えていました。60,000のデータベースを運用するためのハードウェアにかかる固定費を、必要に応じて計算能力とコストを調整できる運用モデルに転換したかったのです。SQL Serverデータベースの構築作業は退屈なので、私たちは面白いことがしたかった。Infrastructure as Codeなどのモダンな手法を活用して、反復的な作業から解放されたいと考えていました。
AWSへの移行計画：課題と解決策
また、繰り返し行うタスクであるため、人的要素も確実に関与させたいと考えていました。ビルドに一貫性がないという事態は絶対に避けたかったからです。そのことと、AWSの幅広さと深さを活用する必要があったことが相まって、私たちの旅が始まりました。そうですね、スケーラビリティの話は、これらが始まった時期と関係していますね。2020年2月に外出して社交を楽しんでいた人はここにいますか？そんなことはなかったですよね。私が入社した初日、会議室に呼ばれました。CEOや、それまで一度も会ったことのない人々がいる中で、クラウドに移行することを告げられたのです。
これは素晴らしいことでした。というのも、当時私を会社に誘ってくれていたマネージャーは、オンプレミスの構造に関して対処が必要な興味深い課題について話してくれていたのですが、それらは全て白紙になったのです。18ヶ月後、私たちはAWSと協力し始め、具体的な計画を立て始めました。その一環として、AWSのパートナーネットワークや、クラウドへの移行を迅速に進めるための他のサービスも活用することになりました。
これは大規模なプロジェクトでした。データセンターに大きなフットプリントがある状態で移行しようとする時、どこから始めればいいのでしょうか？データセンターからの移行は、まるでアパートの引っ越しのようなものです。何を持っているのか、何を移動させたいのか、そしてもう喜びを感じられないものは何なのかを知る必要があります。そこで、まず私たちが持っているものと、それをどうするかを検討することから始めました。AWSへの移行理由の中で触れていなかったことの一つは、データセンターからの退去期限が迫っていたということで、これも他の要因に加えてのインセンティブとなりました。
AWSと最初に行ったのは、OLA（Optimization and Licensing Assessment）でした。AWS Cloud Migration Frameworkの一部として、これは3つのステップに分かれています：アセスメントフェーズ、移行フェーズ、そして運用・モダナイズフェーズです。これらの各フェーズを通じて、AWSはMindbodyのような顧客がAWSへ移行するためのさまざまなツールとプログラムを提供しています。OLAはまさにそれで、現在運用しているものを評価し、AWSでの最適な展開と運用方法を決定するためのプログラムです。
OLAは2つの柱で構成されています：適切なサイジングとライセンスの最適化です。適切なサイジングの観点から、現在オンプレミスで運用しているサーバーと実行内容を確認します。多くの顧客は今後3〜5年のニーズを見込んでインフラを購入しますが、AWSではペイアズユーゴーモデルを採用しています。クラウドの柔軟性を活用して、より小規模なインフラで運用し、コストを削減し、必要に応じてインスタンスタイプを増強できます。CPU、メモリ、ネットワークの使用状況を確認し、DBAの場合はディスクのI/Oやスループットも確認します。平均値だけでなく、ピーク値も確認します。これらの分析に基づいて、推奨事項を提示し、サーバーから適切なEC2インスタンスタイプへのマッピングを提案します。
第2のポイントは、Microsoftライセンスの状況を確認することです。AWSでは、SQL ServerとWindowsのライセンスを自分で持ち込むか、ライセンス込みのコストモデルを利用してEC2インスタンスをデプロイし、AWSがお客様に代わってMicrosoftにライセンス料を支払うかを選択できます。Mindbodyのケースでは、Active Software Assuranceによるモビリティ権を持っていたため、BYOLコストモデルを活用することができました。本日ご参加の皆様へのお願いですが、特に移行を検討されている場合は、Account ManagerやTechnical Account Managerに連絡して、OLAの実施についてご相談ください。AWSでは、データに基づく意思決定を重視し、そのデータをお客様に提供しています。
このOLAでは、インフラストラクチャ全体をマッピングした分かりやすいプレゼンテーションとスプレッドシートを提供し、EC2のマッピング提案や、AWSでのSQL Server環境のTCOを算出することができます。これは、コロケーションにあるデータセンターや他のクラウドベンダーからの移行を検討しているお客様向けのサービスです。また、すでにAWSを利用しているお客様も利用できます。多くの場合、お客様は移行時に不安があったり安定化フェーズを経たいという理由で、オーバープロビジョニングすることがあります。その後、安定性に自信が持てるようになってからコスト最適化を行いたいと考えた時に、AWS環境で再度OLAを実行することも可能です。
SQL Serverアーキテクチャの変革とLocal Zonesの活用
では、SQL Serverについて説明しましょう。 オンプレミス環境では、2つの階層に分けて構築していました。1つは6〜7万のデータベースを持つCustomer Subscriber層で、これらはすべてHAなしのWindows 2016 Standard Edition上のスタンドアロンSQL Server 2016でした。これはクラウドへの移行時に改善したい点の1つかもしれません。もう1つはCentral層で、3ノードずつで構成された6つのAvailability Groupを持つ4つのクラスターで構成されていました。
まず最初に、Reghardtが言及したように、6万のデータベースに関連する大きなライセンスコストを削減するため、モダナイゼーションを検討しました。Amazon RDSやAuroraのオプションを検討し、現在もそれらの導入を検討中です。これについては後ほど説明します。また、オンプレミスで抱えていたHA課題を解決し、Central層ではAvailability Groupsの使用を継続したいと考えていました。EC2のサイジングを決める際、SQL Server Standard Editionの制限を考慮し、ワークロードのほとんどがメモリ集約型だったため、SQL Serverで利用可能な128GBのメモリ制限を最大限活用できる4xサイズモデルを採用することにしました。
LAにあるデータセンターからOregonへの移行を検討した際、まずはデータベースを移行することで埋没コストに対処しようと考えました。開発環境のクラスターの一部を構築したパイプラインを使ってOregonリージョンに移行し、テストを開始しました。そこで問題が発見されました - OregonとLAの間の通信が発生するたびに、約20ミリ秒のレイテンシーが発生したのです。アプリケーションがチャッティーだということは分かっていましたが、ここまでとは思っていませんでした。光の速度では十分ではなかったのです。
私たちは行き詰まりました。Big Bang移行を行う計画ではありませんでした - 顧客への影響が甚大になるため、そのような選択肢は考えていませんでした。パンデミックの最中であっても、多くのチェーン店や個人商店のオーナーにとって、私たちが収入源であり生活の糧となっていることを尊重する必要がありました。また、私たちは彼らと顧客をつなぐ重要な役割も担っていたため、サービスの中断を最小限に抑えたかったのです。しかし、Big Bang移行の選択肢が再び浮上してきて深刻な懸念を抱えていた時、AWSがLocal Zonesについて説明してくれました。Local Zonesについて簡単にご説明させていただきます。
会場の皆さんに手を挙げていただきたいのですが、Local Zonesをご存知の方はいらっしゃいますか？ 3分の1か4分の1くらいですね。RegionとAvailability Zoneについては皆さんご存知だと思います。Availability Zoneでは、Region内に3つ以上の異なるデータセンターがあり、通常は冗長性のために3つ以上のAvailability Zoneを持っています。先ほど述べたように、LAから最も近いRegionはOregonにありました。
Local Zonesは都市部に配置されるインフラストラクチャーです。AWSが皆さんの近くでデータセンターを運営し、エッジでコンピューティングを行うようなものだと考えてください。これは、レイテンシーに敏感なワークロードのために使用されます。多くの金融業界やゲーム業界が、まさにこの理由でLocal Zonesを使用しています。つまり、データをユーザーにできるだけ近い場所に配置しようとしているのです。Local Zonesの素晴らしい点は、LAに1つあることで、MindBodyはLAX Local Zoneを利用することができました。
Local Zonesでは、すべてのコアサービスをお客様に提供しています。ネットワーキング、コンピューティング、ストレージなどがあります。Local Zonesについて重要な点は、サービスは利用可能ですが、一部のサービスは親Regionにもアンカリングされているということです。 これがなぜ重要なのか、すぐにご説明します。
テストがいかに簡単だったかについてお話しましょう。Oregonにデプロイしていたものからスナップショットを取得し、LA Local Zoneにリストアしました。VPCの拡張さえ必要ありませんでした。テストを実行したところ、LAの交通事情にもかかわらず、明らかに改善が見られました。これにより、ハイブリッドモデルに戻り、Big Bangアプローチから離れることができました。なぜなら、先ほど申し上げたように、私たちはBig Bangを絶対に行わないと決めていたからです。
ストレージ最適化：課題と解決策
いくつかの課題もありました。Local Zonesで利用可能なサービスには制限があり、それらのサービスの所在地にも制限がありました。例えば、GP3ストレージを活用する予定でしたが、当時Local Zoneではまだ利用できませんでした。サードパーティツールを使用したS3へのバックアップは、データベースがバックアップやアプリケーションの物理的な近くに配置されていないため、より時間がかかるようになりました。クラスターのファイル共有ウィットネスにFSxの利用を検討していましたが、それがOregonに配置されることから、安定した環境を確保する上で、そのレイテンシーが懸念事項となりました。
ストレージの課題について、当初の設計とOLAを実施した際、Oregonをベースにコスト分析を行いました。Oregonへの移行計画ではGP3を使用する予定で、SQL Server用のAmazon EBSに年間100万ドルの予算が設定されていました。これは146の異なるボリュームで、それぞれ2.5テラバイト、SQL Serverのデータとtempdbファイルのために各ボリュームで16,000 IOPSと500メガビット/秒のスループットが必要でした。しかし、Local ZoneではGP3が利用できず、GP2とIO1のみが選択肢でした。GP2では500メガバイト/秒のスループットを処理できないため、IO1に切り替える必要がありました。
IO1で全てを再設計したところ、見積もりは286万ドルとなり、予算を186万ドルオーバーしてしまいました。これは明らかに受け入れられないものでした。この結果を顧客に報告したところ、完全に却下されました。そこで再度検討し直し、既存のGP2をソリューションとして活用することを決めました。
GP2のRAID 0構成を実装しました。これはRAID 5やRAID 10ではなく、可用性や耐障害性を解決するのではなく、パフォーマンスのみを解決するためのものです。RAID 0では、ボリュームを一緒にストライピングするので、両方のボリュームのパフォーマンスを合算できます。2つのボリュームそれぞれで8,000 IOPSと250メガビット/秒のスループットを実現し、それらをストライピングすることで16,000 IOPSと500メガビット/秒を達成しました。
GP2のパフォーマンスには、容量に基づいてパフォーマンスが決まるというトレードオフがあります。容量1ギガバイトあたり3 IOPSが得られます。結果として、必要なストレージパフォーマンスを得るために、容量を大幅にオーバープロビジョニングする必要がありました。これがGP3のメリットの1つです。GP3では容量とパフォーマンスが連動していないため、すべての顧客にGP3への移行を推奨しています。これらすべてを再設計した結果、コストは112万ドルとなり、IO1と比べて174万ドルの削減を実現しましたが、それでも予算をオーバーしていました。
次に、これらのノード上で何が動作しているのか、特にSQLデータファイルやtempDBについて調査を始めました。Local Zonesで利用可能なEC2オプション、特に超高速で低レイテンシーを提供するローカル接続のNVMe SSDを備えたEC2インスタンスを検討しました。最終的に、vCPU1個に対して8GBのメモリ比率を提供するメモリ最適化EC2インスタンスノードであるR5Dノードを選択しました。128GBのRAMを搭載したR5D 4XLインスタンスを採用することにしました。
これらのNVMeドライブを活用して、tempDBデータファイルをそこに配置することにしました。これによって、EBSボリュームの容量とパフォーマンスの両方の要件を削減することができました。その結果、32%の容量削減を実現し、コストを768,000ドルまで下げることができました。しかし、AWSでは常にお客様の声に耳を傾け、お客様に代わってイノベーションを起こすことを大切にしています。そして、まさにそれを実践しました。
Mindbodyと長く協働する中で、2021年4月に彼らに代わってProduct Feature Request（PFR）を提出し、Local ZonesへのGP3のデプロイを要請しました。そして誇らしいことに、2021年7月にはそれがリリースされました。Mindbodyは、その1ヶ月後に移行を完了し、GP2ストレージで本番稼働を開始しました。彼らのプラットフォームアーキテクトの一人がPythonスクリプトを作成し、顧客に影響を与えることなく、すべてのストライプをGP2からGP3に裏側で変換することを可能にしました。
これは、AWS CLIコマンドを使用してインフラストラクチャに対して、オンライン状態でパフォーマンスへの影響を最小限に抑えながら、GP2からGP3に変換できるという素晴らしい事例です。最終的に、GP2からGP3への変換後、年間コストは70万ドル強まで削減されました。これは、私たちが協力し合い、新機能をデプロイした素晴らしい例となりました。
高可用性の実現とOregonリージョンへの移行
Product Feature Requestは、AWSでリリースする製品の原動力となっています。さて、ストレージの話題に関連して、SQL Serverの高可用性を実現したいということでしたが、その点について少しお話しいただけますか？
確かにその通りです。Local Zoneで共有ストレージが利用できない状況で、約10年前にSQL MVPのグループがSIOSという会社に招かれました。当時は自分には関係ないと思っていたので特に気にしていませんでしたが、そのプロダクトのことは覚えていました。SIOSが提供しているのはブロックレベルのレプリケーションです。私たちは、表面的にはAvailability Groupsの構造によく似たプロセスを構成することができました - 各ノードの下に同一のストレージを配置したのです。SIOSの仕組みとしては、プライマリからセカンダリのロックされたドライブへのブロックレベルレプリケーションを行い、SQL ServerのフェイルオーバーやWindowsクラスターのフェイルオーバーとも完璧に連携します。そのおかげで、共有ストレージがなくてもフェイルオーバークラスターのシナリオを実現することができました。
少し話を戻しましょう。FCIの利点の1つは、SQL Server Standard Editionを使用する場合、共有ストレージ層が必要になることです。AWSでは、それはAmazon FSx for Windows File Serverになります。Timが先ほど述べたように、当時これはLAXでは利用できず、Oregonリージョンでのみ利用可能でした。すべての書き込みに対するそのような遅延制約は機能しないと判断しました。また、Amazon FSx for NetApp ONTAPや、最近導入されたIO2 Amazon EBS Multi-Attachも共有ストレージ層として利用可能です。Local ZoneでのニーズにAWSパートナーが対応してくれたというのは素晴らしいですね。私たちはパートナーが大好きです - 彼らは靴下まで提供してくれます。かっこいい靴下ですよ。
計画を立て、多くの問題に直面し、それらを解決しました。では、移行はどのように進めたのでしょうか？ AWSにはクラウドへの移行のための様々なサービスがあります。しかし残念ながら、OSとWindowsのエディションの両方を改善するという意識的な決定をしたため、独自の方法で進めることになりました。結果として、私たちが作成したDB moverツールを使用して、バックグラウンドでデータベースを移行するための独自のソリューションを使用し、そこからAGsを別個に扱うことにしました。
これは膨大なインフラを構築する必要がある - 数百台のサーバーです。かなり早い段階で、私たちが知らなかったけれど必要だと分かった技術についてスキルアップを支援してくれるパートナーと協力しました。多くのTerraformとインフラ構築にPloiというツールを使用し、パートナーと協力してパイプラインを構築しました。正直に言うと、いくつか問題もありました - このツールに慣れ始めて数ヶ月しか経っていなかったので、少し作り込みすぎてしまいました。そのため、デプロイに時間がかかりましたが、それは私たちの責任です。作業自体はスムーズで、最終的にはすべてを展開することができました。私はミシガン出身なので、これを組立ライン方式で見ていました。私がデプロイメントを担当し、他の人がデータベースの移行を担当していました。素晴らしいですね。私の顧客のほとんどがInfrastructure as Codeを使用しているのを見ています。もう誰もUIには触れていません。カットオーバー移行には18ヶ月かかり大変でしたが、最初の問題を乗り越えた後は、すべてがとてもスムーズに進みました。
私たちは顧客のオフタイムにデータベースの移行をスケジュールしていました。サブスクライバー層を北中南アメリカで分割しているので、夜間の時間帯に一つずつゆっくりとデータベースを移行していきました。
アプリケーションの準備を進め、中央データベースと連携するサービスを整えていく中で、1つのAvailability Groupをサポートするすべてのサービスの移行準備が整った時点で、月次メンテナンスウィンドウを活用して移行を実施しました。フロントエンドを停止する必要はありませんでした。既存のメンテナンスウィンドウを利用することで、お客様への影響を最小限に抑えて実施することができました。
ここまでの流れを振り返ってみましょう。COVID期間中に移行を開始し、計画を立て、POCを実施しましたが、レイテンシーが高すぎて上手くいきませんでした。そこでLocal Zonesが救世主となりました。それをテストし、ストレージに関する多くの問題に直面し、それを解決して、そして移行を実施しました。 では、クラウド移行に際して設定した目標に立ち返ってみましょう。高可用性の向上、コスト削減、運用負荷の軽減を目指していましたが、結果はどうだったでしょうか？
私たちにとって大きな課題だった高可用性の問題を解決することができました。1,500のデータベースを抱えるサーバーがダウンした時に高可用性がない状況は想像してみてください。さらに、フェイルオーバークラスターの構築方法について話し合った際に触れたように、コンピューティングのライトサイジングも実現できました。Reghardtと私との創造的な話し合いを通じて、支出の明確な改善も見られました。しかし、私たちの目標を完全に達成するためには、今後さらに別の選択肢を検討する必要があることも分かっていました。
Local Zonesは私たちの目標達成のための通過点に過ぎないことは分かっていました。リージョンへの移行が必要だということは分かっていましたが、正直なところ気が進みませんでした。ある意味、より良い方法を知っていて、私たちの不安を克服する手助けをしてくれたAWSチームに背中を押されたような形でした。移行が完了し、しばらく運用して、プロジェクトの安定化フェーズを経た後、私たちは再度OLAを実施しました。現在のLocal Zonesでの支出額を確認し、Oregonリージョンに移行すれば最適化の余地があると考えました。そしてリージョンへの次の移行を開始するためのビジネスケース作りを支援してくれました。
そして私たちは再び評価フェーズの出発点に戻りました。インベントリ作業は記憶に新しく、すべてのリソースの所在を把握していました。本当に重要だったのは、移行作業のために経営陣からどれだけの時間を与えられるかということでした。前回は18ヶ月かけて実施しましたが、今回は2時間しか与えられませんでした - データベースの切り替え、DNS変更、テストを含めてすべてを2時間で行わなければならず、テストに使えるのはわずか30分でした。つまり、18ヶ月かかった移行を今度は30分で行うということです。私たちに与えられたのは30分だけでした。
それでは詳しく見ていきましょう。先ほど言及したように、Central TierとClient Tierがあります。 この2つに分けて説明していきます。実際のところ、私たちは既存のやり方に縛られていました。移行に際して、ストレージのストライピングの問題を修正することは分かっていました。なぜなら、ストライプボリュームを使用している場合、ストレージの拡張が非常に困難だからです。パフォーマンスのために過剰にプロビジョニングしていたにもかかわらず、現状の構成では新しい論理ボリュームへの拡張が必要になった場合が1、2回ありました。
Always On Availability Groupsについては、同じAvailability Groupを3つのAvailability Zoneに対応する3つのノードでOregonまで拡張することができました。これにより、問題のあったHigh AvailabilityとDisaster Recoveryのセットアップを解消できました。Los AngelesのプライマリノードからOregonの将来のプライマリノードとなるノードへLog Shippingを利用して、OregonにAvailability Group用の追加ノードをプロビジョニングしました。切り替え時には、Log Shippingを停止し、そのインスタンスを起動して、Auto Seedingを活用してHigh Availabilityの状態に戻す計画でした。Availability Groupsは今回も比較的簡単な部分でした。
より密接に結合されているFailover Cluster Instancesについては、様々な選択肢を検討しました。その中で、多くの選択肢を却下しました。一時は、Standard EditionのクラスターすべてをEnterprise Editionに変換して、Enterprise Editionの機能を使ってクラスターを拡張することも検討しました。しかし、これはコストがかかり、Enterprise EditionからStandard Editionへのダウングレードができないため、Oregonで全てを再構築する必要がありました。そのため、この案はすぐに却下されました。
最終的に決定したのは、私たちが「Standard Oprah」と呼んでいた方法です - Standard Editionノードを次々と追加していくというものです。Oregonに新しいクラスターのための完全に複製されたインフラを作成し、SIOSを使用してミラーリングを行いました。Los Angelesのプライマリから、Los Angelesのセカンダリへの同期ジョブを維持しながらミラーリングを行いました。SIOSの仕組み上、セカンダリディスクはロックされているため、プライマリからのみミラーリングジョブを作成できます。クラスターの同期と構築を進める中で、Oregonの両方のノードへのレプリケーションジョブを追加していきました。Los AngelesからOregonへの回線が飽和状態になり、影響が出ました。同期が完了すれば問題ありませんでしたが、100のクラスターが同時にこれを行うことを想像してみてください - かなり大変でした。
クラスターとHigh Availabilityを構築する際に必要なことの1つは、ノードの所有権パーミッションを正しく設定することです。なぜなら最後に
予定より早くカットオーバーが発生してしまったことがありました。移行の1週間前、私が東ワシントン州でキャンピングカーに乗っているときに、携帯電話が狂ったように鳴り始めたのです。調べてみると、ロサンゼルスのLocal Zoneで通信の問題が発生し、いくつかのクラスターが早期に移行を試みていたことがわかりました。可用性の問題が早期に移行してしまい、その間レイテンシーが発生しました。幸い、素早くフェイルバックして、本番に向けた準備態勢に戻ることができました。
さらに遡ると、カットオーバーの約2週間前に同期が完了していました。これは18ヶ月のプロジェクトでしたが、カットオーバーの約3ヶ月前に、会社が移行の2週間前にオフサイトミーティングを行うことを決定しました。2週間前には準備を完了させる必要があり、その際にいくつかの問題に遭遇しました。Technical Account ManagerやSolutions Account Managerからレイテンシーの報告を受け、顧客に影響を与えていると考えたためです。同期ジョブをオフにして処理を減らし、再同期にかかる時間を確認していましたが、実はそれは大手クライアントが自ら実施していた「Hell Week」だったことがわかりました。
その状況から回復し、実際の移行当日は非常にスムーズでした。わずか12分で完了しました。トラフィックを処理していない1つのクラスターで問題が発生しましたが、翌日に自力で解決することができました。それ以外は、すべてが順調に進みました。
プロジェクトの成果と今後の展望
では、当初の目標であるコスト、高可用性、運用効率について振り返ってみましょう。 私の前職は製造原価の見積もり担当で、コストの話になると退屈なDBAや会計士のようになってしまいます。親リージョンへの移行だけで、約13%のコスト削減を実現できました。さらに、6月に実施したため、約8ヶ月でROIを達成できる見込みです。つまり、来年のQ1-Q2には投資回収できる計算です。
3つのAvailability Zoneを活用できるようになったことで、高可用性の課題も解決できました。大きな成果として、バックアップとリカバリーを30%改善できました。ここで強調したいのは、仮想化をどれだけ進めても、すべての問題が解決するわけではないということです。物理的な近接性や迅速なリカバリー能力がなければ、可用性や改善能力が損なわれ、RTOの削減も難しくなります。現在使用しているハードウェアの特性により、トランザクションログのバックアップ頻度を向上させることができ、最終的に目標を達成することができました。
このセッションの直後に会議があるのですが、次に何をするかについては冗談抜きの話です。スライドを読んでいただいて構いませんが、私たちは数ヶ月間これを練習してきましたが、クラウドでよくあることですが、状況は急速に変化し加速してきています。
現在、アプリケーションのモダナイゼーションラボを進めているところですが、それはアプリケーションのモダナイゼーションだけではありません。この後の会議は、データベースに関するもので、SQL ServerからPostgreSQLへの移行が可能かどうかを検討するものです。というのも、ライセンス費用がまだ負担になっているため、可能であればWindowsライセンスとSQL Serverライセンスから脱却したいと考えているからです。これは素晴らしいプログラムであり、私たちはモダナイズしてより迅速なイノベーションを実現しようとしています。
これは本当に素晴らしいストーリーでした。以前、メンターから「同じことを25年間やっているなら、それは1年の経験を持っているだけだ」と言われたことがありますが、今回のプロジェクトは、私たちのチーム全員を予想もしなかった新しい領域へと導いてくれました。これらの学びの中で、私が特に強調したいのは「トレーニング、トレーニング、トレーニング」ということです。私は常に学習、成長、共有の大きな支持者でしたし、今でもその考えは変わりません。このような取り組みに挑戦する場合や参加を検討している場合は、まずAWSのツールやサービスについて、すべての資料を読み、ブログやAWSが提供する他のリソースを理解することから始めてください。
一人では実現できません。私たちには「知らないことが何かも分からない」ことがたくさんありました。AWSの幅広い知識と深い専門性を持つ優れたパートナーを持つことは、私たちにとってかけがえのないものでした。素晴らしいですね。質問の時間が2、3分ほどあるようです。
はい、データベースファイルをリージョンに移行する際、今回の移行では実際に2時間ほどフロントドアをシャットダウンしました。これは、この作業に必要な時間についての交渉と妥協の結果でした。データプラットフォームを移行した後、アプリケーションとインフラストラクチャのチームが各自の作業を行う番となりました。
データセンターに関する大きな課題は、そこから脱却しようとしていたことでした。Direct Connectは導入していたものの、アーキテクチャの特性上、レイテンシーが依然として大きすぎました。ご存知の通り、特定のアプリケーションは非常にチャッティ（通信頻度が高い）です。Mindbodyのアプリケーションで見られたように、1件ずつデータを取得する多数の小さなクエリと、10件や100件のレコードをまとめて取得するバッチ指向のクエリでは大きな違いがあります。多数の小さな呼び出しを行う場合、ページの読み込みやエンドユーザーへのレスポンスまでに、それぞれのトランザクションで発生するレイテンシーが累積的に加算されていきます。20ミリ秒ずつが積み重なっていくわけです。一方、データベースへの呼び出しが1、2回で済む場合は、そのレイテンシーをクエリのタイムアウト時間内に収めることができます。
暗号化に関しては、SQL Serverの暗号化機能を使用して従来通りバックグラウンドで管理されており、バックアップもat-restで暗号化されています。私たちの暗号化スキームはデータの移行に合わせて継承されました。TDE暗号化によってディスク上のデータが暗号化され、さらにTLSを使用して通信経路上のデータも暗号化することができます。
この暗号化機能は引き続き完全に利用可能です。別の話題に移りますが、OLAの実施中に何か予想外の発見はありましたか？アセスメントを行った際に、他のビジネスユニットで予期していなかったSQL Serverのライセンスが見つかったりしましたか？予想通りの結果だったのか、それとも大きな発見があったのでしょうか？
データ側のOLAで予想外のことがあったかという質問ですが、私たちはDBAなので、システムは整然と管理されていました。ただし、月曜日に仕事に戻ることに関して言えば、アプリケーション側でも同じだったかどうかは分かりません。OLAの調査範囲は、必要に応じて広くも狭くもできます。私たちのケースでは、データ層だけに焦点を当てて複数のOLAを実施しました。OLAはアプリケーションスタックまで拡張することもでき、Windowsのライセンスを検討したり、アプリケーションをクロスプラットフォームの.NETに移行してLinux上で実行し、Gravitonで実行することでさらなるコスト削減を達成する方法を検討したりすることができます。
具体的な数字は手元にありませんが、OLAは大きなコスト削減の機会を示しています。私たちの顧客全体で見ると、適切なサイジングで約30%、ライセンスコストの削減機会で約50%の削減が見込めます。最適化によってCPUを削減でき、その結果としてライセンスも少なくて済みます。WindowsもSQL Serverもコアベースのライセンスを使用しているため、適切なサイジングによってコア数を削減することでライセンスコストを節約できます。既存の投資を保護するためのBring Your Own Licenseオプションと、AWS環境向けのライセンス込みのコストモデルの両方を用意しています。
非本番環境のライセンス料金を支払う必要はありません。本番以外のワークロードはSQL Server Developer Editionで実行できます。これは完全に無料で、ライセンスも必要ありません。OLAは、データに基づいた意思決定を行うための優れたツールです。画面上にQRコードが表示されていますが、これは先ほどお話したCloud Adoption Frameworkと、Optimization and Licensing Assessmentに関連するものです。
中央層でio1からio2への移行がまだ完了していないことに気づきました。これも対応が必要ですね。まだgp2を使用している場合はgp3に、io1を使用している場合はio2に移行してください。どちらの移行でもコストを削減でき、より柔軟な運用が可能になります。この変更もダウンタイムなしで実施できます。このように、私たちは常に新しい方法を見つけてコストを削減しています。
そろそろ終わりの時間です。質問については後ほど対応させていただきます。終了後にアンケートにご記入ください。Uberと同じように、私たちも5つ星を目指しています。 本日は貴重なお時間をいただき、ありがとうございました。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion