re:Invent 2024: VeriskのWindows SQLワークロードを5分以内でフェイルオーバー
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Unleashing .NET workloads: From data center to multi-region resilience (XNT314)
この動画では、Veriskという企業がAWS上で実現した、Windows SQL Serverワークロードの5分以内のリージョン間フェイルオーバーについて解説しています。531のワークロードに対してActive-Active/Passive構成を実装し、89のWindowsワークロードで5分以内の自動フェイルオーバーを達成した具体的な取り組みを紹介しています。Windows EC2の起動時間を40分から20-25分に短縮するためのImage BuilderやFast Launchの活用、Warm Poolsによる非本番環境のEC2コスト75%削減の実現など、具体的な改善施策とその成果が示されています。また、.NET CoreへのアップグレードやAWS Application Modernization Labの活用など、Windowsワークロードの最適化に向けた継続的な取り組みについても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Veriskのクラウド移行とマルチリージョン構成への挑戦
昨年、私はMicrosoftとAWSの大手顧客に対して、コスト削減と俊敏性向上のためにオープンソースソリューションへの移行を支援するよう依頼されました。私の任務の一つは、LuisやElliotのような経営陣と面会し、AWSのリーダーシップチームと共に、オープンソースへの移行を説得することでした。私たちはその移行をサポートし、インセンティブを提供し、移行プログラムを作成する予定でした。
連絡を取った際、実は私はLuisと初めて夕食を共にしました。Luisが彼らの取り組みについて説明し始めた時、私は典型的な回答を期待していました。しかしLuisが言ったのは、そういった問題は抱えていないということでした - 彼らはマルチリージョンのMicrosoft workloadを運用しており、5分以内に自動的にフェイルオーバーできるとのことでした。私は彼が技術系のCTOではなく、ビジネス系のCTOに違いないと思いました。そこでさらに詳しく尋ねてみました。PostgreSQLを使用したオープンソースのことを指しているのだろうと考えたのですが、いいえ、彼らはMicrosoft SQL Serverを使用していたのです。最初は、本当にフェイルオーバーができるのか疑問に思い、彼のチームが実際にはできないのに、できると言っているだけなのではないかと考えました。
さらに詳しく調べてみると、彼らは本当にこれを実現していました。しかも一つのワークロードだけでなく、複数のワークロードで実現していたのです。ニューヨークの夏にこれを聞いた時、もし本当にこれができているのなら、彼らはre:Inventで講演しなければならないと確信しました。そういうわけで、今日この二人がステージに立っているのです。このセッションの全体的なテーマは継続的な改善です。私は彼らに、5年前にここにいたと想像して、当時の自分に対して、どんなヒントやコツを知っておきたかったか、どんなことが起こると予め知っておきたかったかを話してもらうようお願いしました。
これは、Luisとの夕食で私が期待していた典型的な状況です。このような構成、つまり2つのAvailability Zoneを使用し、アクティブ-パッシブのSQL Serverがリージョン間でフェイルオーバーできるWindowsワークロードについて話すことを期待していました。通常、顧客はこれを実現したいと言い、別のリージョンで何らかのディザスタリカバリを望みます。彼らは支援を求めますが、ほぼ間違いなく、コストが高すぎる、または実現が難しすぎると言い、価値がないかもしれないと考えます。そして次の危機が発生すると、突然それが価値あるものになるのです。聞き覚えがありませんか？現在、このようなWindowsワークロードを持っている方はいますか？2人が頷いているのが見えますね。
私が聞いたのは、とても印象的なものでした。彼らは複数のリージョンで、5分以内にフェイルオーバーを実現しています。一つのワークロードだけだと思っていましたが、そうではありません - 彼らは23のWindowsワークロードと297のオープンソースワークロードでこれを実現しています。合計531のワークロードに対して、アクティブ-アクティブ、アクティブ-パッシブを実装しています。そのうち89のWindowsワークロードは5分以内の自動フェイルオーバーを実現しています。これは本当に信じられないことです。私たちはいつも誰かがこれを実現できればと夢見ていましたが、彼らがこれを実現し、Luisが「もちろん、それが私たちのやり方です」とさりげなく話すのを聞くと - 彼らは自分たちがどれほど優れているかを理解していないのです。
みなさんはなぜこのセッションを選んだのでしょうか？5分でワークロードを実現する方法に興味があるのかもしれません。今日はそのためのヒントが得られるはずです。彼らはこれを自動的に行っています。あるいは、Windowsのビルド時間で苦労されているかもしれません - 多くの方が40-50分かかるWindowsサーバーのビルドに取り組んでいますが、これは迅速な環境構築を目指す際の大きな課題です。 また、Microsoftワークロードのライセンスコスト削減を求められているかもしれません。これは非常によくある要望です。 そして、私たちがただLinuxを推奨すると思っているでしょう？実はそうではありません。
Luis BarbierはVerisk Analyticsのチーフテクノロジーオフィサー（CTO）で、Elliot MarkowitzはDevOpsのマネージングディレクター、そして私はVeriskのアカウントマネージャーです。以前の役職で彼らと最初に話をした時、私はMicrosoftスペシャリストでした。
Veriskはグローバル保険業界向けの分析データとテクノロジーのパートナーです。 彼らの高度な分析技術と革新的なテクノロジーは、クライアントの業務効率を強化し、引受および保険金請求の成果を改善し、不正を防止するのに役立っています。また、グローバルリスクに関する情報に基づいた意思決定を支援しています。
AWSとの関係について、Veriskは世界でトップ50に入る最大級のWindowsワークロードを持つ企業の一つです。2017年からAWSを利用しており、現在ではワークロードの95%近くがAWS上で稼働しています。彼らはFinOpsと最適化のリーダーであり、これは非常に重要です。多くの企業はAWSに移行してリフト＆シフトを行い、そこで止まってしまいます。しかし彼らは継続的な最適化を行っています。彼らのコア組織はFinOpsと最適化に優れており、常に最適化を追求しています。私たちが新しいアイデアを提案する時、彼らが既に検討していないことは稀です。私は何百もの企業と仕事をしてきましたが、彼らは私が見た中で最高です。AWSへのアプローチのおかげで、彼らは年間5,000万から6,000万ドルを節約しています。
Windows EC2インスタンスの高速化と自動化への取り組み
では、5年で5分を実現した話について、Louis Barbier、お願いします。ありがとう、Chris。あの夕食の時のことを覚えています。私はそれほど大したことではないと言っていましたが、彼は世界に伝えるべきだと主張しました。これから、私たちがどのようにしてそこに到達したのか、どこから始まり、今どこにいるのかについてお話しします。私たちは早い段階でこの journey を信じるようになりました。その理由の一つは、 顧客や経営陣、ビジネスパートナーから、システム障害について批判を受けていたからです。私たちには多くの障害があり、解決に時間がかかっていたため、何かをしなければなりませんでした。
このセッションでよく出てくるテーマですが、新しいサーバーを立ち上げたい時にインフラが間に合わないという問題です。クラウドへの移行を決意する時が来ますが、社内データセンターの会社にとってはそれは簡単なことではありません。2016年、北東部で極寒の寒波が襲来しました。高層ビルの屋上にあるHVACシステムのチラーが凍結してしまったのです。データセンターの温度が上昇し、サーバーを失う前に何とか冷やす必要がありました。残り約2時間という状況で、電話会議の最中に誰かが「窓を壊してデータセンターを冷やそう」と提案したほどでした。
結局、エレベーターシャフトのドアを開けて冷気をデータセンターに導入することにしました。これが最後の引き金となりました。CEOから全社員に至るまで、クラウドへの移行を決断したのです。ここから私たちのクラウドジャーニーが始まりました。DevOpsの流れを受け入れ、Puppet、Ansible、Chefなどを検討しました。2016年末にAWSを選択し、その後はずっと自動化に注力しました。その年の9月に最初のアプリケーションをデプロイしましたが、結局はリフト＆シフトで同じパターンを繰り返しただけでした。1台のサーバーに50個ものアプリケーションが乗っており、WebサイトやAPIが動いていて、1つのアプリケーションが他のアプリケーションに影響を与え、トラブルシューティングの責任のなすり付け合いが起きていました。この状況から脱却したかったので、アプリケーションを適切に分離することに焦点を当てました。私たちの目標は、柔軟性を活用するため、できるだけ早くアプリケーションをAWSに移行することでした。
2018年、パラダイムシフトが起こりました。ここで私たちは「Stack」と呼ぶものの開発を始めました。Stackとは、アプリケーションが独自のLoad Balancer、データストア、そしてスケール可能なEC2インスタンスを持つという考え方です。2017年にデプロイした最初のアプリケーションを含め、すべてのアプリケーションを独自のStackを持つように移行し始めました。
その時点で、もう1つのリージョンが必要だと判断し、Western regionへのアプリケーションのデプロイを開始しました。Western regionには、お金はかかっているものの使用されていないアプリケーション群がありました。問題が発生した際にRoute 53を使用して切り替えることにしました。当初は、反対側のリージョンへの切り替え（私たちは「フリップ」と呼んでいます）を判断するのは人間でした。人間が関与すると、多くの考慮が必要になります。東部で障害が発生した際、西部への切り替えを躊躇することがありましたが、実際に切り替えてみると上手く機能しました。
その後、プロセスの自動化を開始し、New Relicを使用したアラートシステムを導入しました。アラートに基づいて自動的に他のリージョンに切り替わるようにし、意思決定プロセスから人間を除外しました。この時点で、切り替えに要する時間は7〜10分でした。問題解決にかかる時間が短縮されたため、障害は大幅に減少しました。これにより、顧客がリクエストを処理できている間に、私たちは問題の解決に取り組むことができるようになりました。
私たちは順調に進んでおり、さらに多くのアプリケーションをAWSに移行し続けていました。2020年、同僚から、どちらにしてもコストがかかっているのだから、トラフィックを両方に振り分けてはどうかという提案がありました。そこでActive-Active構成を検討し、Route 53のルールセットの活用を開始しました。まず重み付けポリシーレコードを使用し、西部のOregonリージョンに10%、東部のNorth Virginiaリージョンに90%のトラフィックを振り分けることから始め、最終的に50-50の配分まで進めました。各リージョンがトラフィックを処理できることを確認した後、地理的近接性ポリシーを実装しました。これにより、カリフォルニアにいる場合は西部のデータセンターを、ニューヨークにいる場合は東部のデータセンターを利用する仕組みが実現しました。
次のステップは切り替え時間の短縮でした。Route 53のヘルスチェックを活用することで、1分から1分30秒以内での切り替えが可能になりました。アラートが自動的にトリガーされ、それに基づいて切り替えが行われます。現在では、ワークロードの大部分がAWSに移行し、停止時間も継続的に短縮されています。
2024年、Microsoft SQL Serverワークロードの切り替えを導入することを決定しました。私たちはAlways On可用性グループを使用してSQL Serverを運用しているため、DNSを切り替えることで、リージョン間でデータベース操作を効果的に切り替えることができます。
アプリケーションを切り替える際には、データベースもOregonリージョンから実行するように切り替えます。Oregonリージョンがプライマリになり、これをSQL Serverで実装した後、他のデータベースにも展開しました。このプロセスを1分30秒まで短縮することができました。データストアは高可用性を備えており、トラフィックを切り替えることができ、アプリケーションもシームレスに切り替えることができます。
移行やデプロイメントの際に、顧客に影響を与えることなく、この切り替えを頻繁に使用しています。特定のリージョンでテストを行うことができ、これは単に停止を避けるためだけではありません。顧客に影響を与える可能性のある作業が必要な場合は、常にサービスを継続するために切り替えを行います。このグラフは、2016年から2024年までのオンプレミスのコストの推移を示しており、現在ではAWSでのコストはゼロになっています。次の5年間でオンプレミスのワークロードをAWSに移行した際、クラウドでのコストがどの程度を占めているかが分かります。現在では、AWSの総コストの32%を占めています。
この移行により、すでにAWSを利用している企業や、AWSに移行させた企業の買収も可能になりました。ご覧の通り、時間とともにその規模は拡大していきました。また、AWSを活用した新規開発、新規ビジネス、新しいイノベーションも実現できるようになりました。 2017年には、組織全体がAWSへの移行に注力していたため、新規開発はあまり行われませんでした。経営陣が新規施策を制限し、後回しにしたのです。ご覧の通り、2023年には多くの保留案件が一気に実装され、大きな盛り上がりを見せました。そして2024年現在、これらが当社のAWS支出の大半を占めています。全体として、オンプレミスからAWSへの移行は、現在の総コストの32%を占めています。
システム停止に関して、 2020年にダウンタイムの記録を開始して以来、Active-Activeへの切り替えを進めたことで、大幅な改善が見られました。2024年には77%の削減を達成しています。 皆さんもご存知の通り、7月にCrowdStrikeで障害が発生しました。障害の内容を把握した後、私たちは6,200のスタックを一旦停止し、すぐに再起動してお客様へのサービスを再開しました。1時間以内に55%のスタックが復旧し、2時間以内には95%まで回復しました。残りの5%には時間がかかり、そのプロセスの改善に取り組みました。これらのアプリケーションは、まだLift and Shiftの段階で、Active-ActiveまたはActive-Passiveモードへの移行が必要だったため、復旧が難しかったのです。
コスト削減とパフォーマンス向上のためのWarm Pools活用
ここで、私の同僚のElliottに引き継ぎたいと思います。これで終わり、ということですよね？ハッピーエンドで、Veriskは顧客のために素晴らしいことを実現し、Active-Activeを実現し、停止時間も減少した。素晴らしい話です。でも、マルチリージョンになると、アプリケーションのコストが2倍になることに気付くまでは。これが、複数リージョンでアプリケーションを運用する際の最大の不満でしょう。オンプレミスと比べれば節約になるとはいえ、2か所で運用しなければならないのは痛手です。
AWSには、Dynamic ScalingやPredictive Auto Scalingなど、コストを抑えるための機能が多くあります。ただし、これらの機能は、変化する状況や顧客からのリクエストに素早く対応し、急激な負荷の変動に対応できることが前提です。Windowsはそのようなスピードには対応していません。主にWindowsで.NETを使用している私たちは、この制限を身をもって経験しました。Windows EC2をビルドする場合、通常、アプリケーションを完全に構成してトラフィックを受け入れられるようになるまでに約40分かかります。素早いスケーリングが必要な場合、40分待つのは許容できません - サーバーのビルド中に外出して夕食を食べて戻ってこられるようでは長すぎます。そこで、私たちの新しいミッションは、Windows EC2のコストを抑えるか、AWSの機能を活用できるほどWindowsを高速化する方法を見つけることになりました。
最初に試みたのは、正直なところ、より安価なインスタンスタイプを使用するという裏技でした。EC2一台につき一つのアプリケーションを実行していたため、SmallやMediumのような小さなインスタンスは検討しませんでした。代わりに、Spot Instancesに注目しました。 バックアップリージョンには、普段はトラフィックが流れないため、Spot Instancesを配置するというアイデアでした。また、Spotが宣伝通りに安ければ、プライマリリージョンでもOn-DemandとSpot Instancesを組み合わせてコストを削減できると考えました。Spotを使用すれば90%のコスト削減が可能だという話は皆さん聞いたことがあるでしょう。これだけの節約が可能なら、2倍や3倍のSpot Instancesを用意して、1台が失われてもクラスターが動き続ける限り問題ないと考えました。
しかし、このアプローチはうまくいきませんでした。Spot Instanceのコストを考える際には、オペレーティングシステム、リージョン、インスタンスタイプという3つの要因があります。AWSはこれらすべてについて料金と回収率を公開しており、秘密は何もありません。問題は、Windowsの場合、ライセンス料金が最初からかかるため、90%の節約は不可能だということです。さらに、回収の問題も考慮しなければなりませんでした。私たちの環境では、数百から数千のEC2が異なるAuto Scaling Groupで稼働しており、その大半が同じインスタンスタイプを使用していたため、Spot Instanceを失い、「予備容量が不足しているため、リクエストを満たせません」というメッセージを受け取ることがありました。その手間に見合うほどの節約にはならず、実際にはReserved InstancesやSavings Planを使用した方が良い節約効果が得られました。
近道は通用しなかったので、インスタンスの構築を高速化するために本腰を入れて取り組む必要がありました。 EC2 Image Builderを検討しました。これを使用すると、.NET、IIS MVC、サードパーティツール、フレームワークなど、すべてのアプリケーション依存関係をパッケージ化してAMIにインストールできます。これは手動でも可能ですが、自動化を使用して毎月実行できることが利点です。Patch Tuesdayが来てMicrosoftが最新のセキュリティパッチをリリースすると、その上にすべてのソフトウェア要件が適用されます。一部の組織ではアプリケーションを直接AMIにインストールしていますが、私たちの数百から千のアプリケーションでは、それは現実的ではありませんでした。しかし、Image Builderを使用してサードパーティの依存関係をインストールすることで、ビルド時間を40分から30分程度まで短縮することができました。
より速いビルドが実現できたので、インスタンスの起動をさらに高速化できないか検討しました。 Windowsインスタンスの起動を待つのは、遠くのハイウェイを車が走り抜けていくのを見ながら、信号待ちで立ち往生しているような感覚です。インスタンスが起動すれば、アプリケーションが制御を引き継いで最適化できますが、待ち時間が苦痛です。 AWSは比較的最近、1〜2年ほど前にWindows Fast Launchという機能をリリースしました。
この機能は、AMIでFast Launchを有効にするためのチェックボックスにチェックを入れるだけです。実際にはとてもシンプルで、1時間あたりに必要な起動回数を指定するだけです。あまり多くない場合、たとえば5回程度なら、10〜15に設定できます。仕組みとしては、そのAMIのインスタンスを起動し、スナップショットを取得して、インスタンスを終了します。 そして実際にそのAMIのインスタンスが必要になったとき、スナップショットを復元するだけで起動できるため、より高速に実行できます。
考慮すべき要因がいくつかあります。スナップショットのストレージ料金が発生するため、若干のコスト影響があります。私たちの経験では些細で取るに足らない額でしたが、念頭に置いておく必要があります。もう1つの考慮点は、十分な数のスナップショットが利用可能な場合にのみ機能するということです。このAMIに対して1時間あたり5つのスナップショットを設定していて、6つのインスタンスを起動する場合、最初の5つは高速に起動します。6つ目も動作しますが、Fast Launchの恩恵を受けられず、より遅く起動することになります。スナップショットを補充する時間を与える必要があります。
これは大きな助けとなり、Windows Fast LaunchとImage Builderを組み合わせることで、Windows EC2の起動時間を20〜25分程度まで短縮することができました。私たちはこれを素晴らしい成果だと考えていました。Linuxチームには笑われましたが、Windowsで20〜25分というのは実際かなり良い数字です。 そこで、さらなる継続的な改善を進めていきました。サーバーの構築と起動が速くなりましたが、アプリケーションのデプロイについてはどうでしょうか？先ほど触れたように、一部の人々はアプリケーションを直接AMIに組み込んでいます。私たちはOctopus Deployというツールを使用しています。Octopus Deployの仕組みとしては、EC2上でエージェントが動作し、メインのOctopusサーバーに接続して登録を行い、新しいEC2が存在することを通知し、設定に基づいてアプリケーションをEC2にプッシュします。
非本番環境でのWarm Pools実装と成果
私たちは、このプッシュモデルをなくして、プルモデルに変更したらどうだろうかと考えました。 EC2がどこで起動するかわかっているのなら、Octopusにアプリケーションのデプロイをすぐに実行させることはできないだろうか、と。ツールのログから正確なデプロイ時間がわかっていたので、デプロイ自体には時間がかかっていないことは把握していました。EC2が起動したらすぐにアプリケーションをプルするように変更すれば、デプロイが速くなり、アプリケーションをより早く利用可能になるのではないかと考えました。
残念ながら、これはうまくいきませんでした。完全な失敗とは言いたくありません。なぜなら、この仕組みは今でも本番環境で動いているからです。ただ、私たちの目標であった「より速く」という点では効果がありませんでした。実装に深入りする前に、まず計測をすべきだったということを学びました。ただし、これを失敗と呼びたくない理由として、カオスエンジニアリングの観点からバックアップを持つことは常に良いことだからです。今では何か失敗が起きた時のバックアップとして機能していますが、より速く、またはコストを削減するという私たちの最終目標には役立たなかった取り組みでした。
この時点で、私たちはできる限り速くなったと考えていました。 サーバーの構築を速くし、インスタンス起動時にできるだけ少ない作業で済ませ、より速く起動できるようになりました。これ以上何ができるでしょうか？そこで思いついたのが、必要になる前にサーバーを構築しておくというアイデアでした。より早い段階で構築しておいて、必要な時に使えるようにしようと。そこで、特にバックアップリージョンでこれらのサーバーを全て起動するためのスクリプトを作成しました。
ところで、私がDRリージョンではなくバックアップリージョンと呼んでいることにお気づきかもしれません。マルチリージョン構成でアクティブ-アクティブやアクティブ-パッシブを実現する際の最大の障壁は、DRという考え方から抜け出すことです。DRのことは忘れてください。他のリージョンに切り替えることを躊躇する必要はありません。Luisが先ほど言及したように、技術よりも人が問題になることが多いのです。プライマリーリージョンとセカンダリーリージョンとして考えればいいのです。どちらも同じように優れています。そこで私たちは、バックアップリージョンでEC2を構築し、必要になるまで停止しておくことを考えました。
環境全体を処理して、各アプリケーションをサービスとスケーリンググループから切り離すPowerShellスクリプトを作成しました。それが完了したら、サーバーを停止できます。必要な場合は、スクリプトを逆順に実行して元に戻すことができます。これは上手くいったのでしょうか？はい、でも完全ではありません。スクリプトは機能して目的を達成しましたが、過度に複雑でした。多くのステップが必要でした。単純化して説明していますが、特定の順序で実行する必要があります。順序を間違えると、サーバーを失ってしまい、新しいサーバーが構築されてしまいます。これは私たちが目指していたことではありませんでした。私たちは、必要に応じてそのサーバーを起動・停止できるようにしたかったのです。
このやり方は非常にデリケートで、多くのメンテナンスが必要でした。バックアップリージョンでアプリケーションを起動する必要がある場合、どのアプリケーションが必要なのかを正確に把握しなければなりませんでした。そして、私のチームの誰かがスクリプトを実行して起動する必要がありました。メンテナンスが多すぎました。私のチームのメンバー（会場にも何人かいますが）に聞けば、私が怠け者だと言うでしょう。必要以上の労力は使いたくないのです。できるだけAWSにやってもらいたいと考えています。ちなみに、妻も私のことを怠け者だと言うでしょう。
では、これをもっと簡単にするにはどうすればよいのでしょうか？そこで見つけたのがWarm Poolsです。Warm Poolsは、まさに私たちが話していたことを実現してくれます。構築済みで、完全に設定され、準備が整った状態で停止されているEC2のセットを持つことができます。何もする必要がなく、Auto Scalingの際に新しいサーバーやEC2を構築する代わりに、このサーバーを起動するだけです。Hibernateモードを使用すると、完全に停止する必要がないため、さらに早く起動できます。
本番環境とバックアップリージョンに移行する前に、何ができるだろうかと考えました。そこで、非本番環境について検討することにしました。私は非本番環境にお金を使うのが嫌いなんです。本番環境については、お金を稼ぐためにはお金を使う必要があることを、みんな理解していると思います。プライマリの本番環境にはお金をかける必要があります。しかし、非本番環境はつらいですね。特に私たちのような、多くのアプリケーションを持ち、その大半が活発な開発中ではない環境では。これらは長年かけて構築されたもので、時々メンテナンスを行うだけで、活発な作業は行われていません。この非本番リージョンを稼働させておくだけでお金が無駄になっています。
そこで、これらのEC2をすべて停止してはどうかと考えました。すべてをWarm Poolに入れることにしました。そして、Amazon CloudWatchアラームを設定して、Load Balancerへの最初のリクエストで、下層にEC2がない状態でリクエストを受けた場合、503 Service Unavailableを返すようにしました。最初の503エラーがAuto Scaling Groupのスケールアップイベントをトリガーします。すると、Warm Poolからサーバーを取り出して起動します。テストでは、サーバーがオンラインになってトラフィックを受け始めるまでに1〜2分かかりました。実際、CloudWatchが発火するまでの1〜1.5分と同じくらいの時間がかかりました。
CloudWatchは完全なリアルタイムではありませんが、非常に高速で、サーバーもすぐに起動しました。開発者にとって最初のリクエストが失敗する可能性があることを理解するのは、ほんの些細な不便さでした。その後、1時間以内にリクエストがない場合にサーバーを再びオフにする、つまりスケールダウンするというCloudWatchアラームを設定しました。サーバーはWarm Poolに戻り、そこで待機状態になります。これは実は、AWSが1年前に発表した新機能に関連しています。Warm Poolsは長年存在していましたが、EC2をWarm Poolに戻せるようになったのが新しい点です。以前は、EC2をビルドしてWarm Poolに入れ、使用後に終了すると、新しいインスタンスがWarm Poolに入るという仕組みで、これは常に少し面倒でした。このビルド、使用、終了というパイプラインに負荷をかけたくありませんでした。しかし今では、使用後にWarm Poolに戻すことができるようになりました。必要に応じてサーバーをオン・オフするようなものです。
.NET CoreへのアップグレードとServerless化の検討
ここで考慮すべき点がいくつかあります。CICDパイプラインについて - 停止中のサーバーにデプロイするのは少し難しいです。アプリケーションやテストをデプロイする場合は、この点を考慮する必要があります。CICDパイプラインをWarm Poolのセットアップと連携させ、Warm Poolが起動してから処理を継続するようにする必要があります。また、Spot Instancesとは連携しません。先ほど述べたように、私たちは十分な節約効果が得られなかったためSpot Instancesを使用していませんでしたので、これは問題ではありませんでした。ただし、Warm PoolsとSpotは互換性がないことを覚えておいてください。そして、重複するアラームには注意が必要です。私たちは苦い経験をしました - リクエストが1時間なかったためにEC2がシャットダウンしようとしている最中に、新しいリクエストが入ってくることがありました。シャットダウンは3秒では完了せず、1〜3分ほどかかります。そうすると、サーバーがシャットダウン中にスケールアップしようとして、アラームが重複してしまいます。結果として、EC2が終了して新しいインスタンスが作成されることがわかりましたが、これは私たちが望んでいたことではありませんでした。
結果は素晴らしいものでした。非本番環境のEC2コストを75%削減できたことは否定できません。これは、EC2の稼働時間が75%減少したということです。夜間や週末、日中の未使用時にEC2がシャットダウンされていたということです。繰り返しになりますが、これは非本番環境での話です。素晴らしい節約効果でした。そこで、次のステップとして何ができるか、次に何をすべきか考えました。 バックアップリージョンのEC2でこの方法を実践し始めました。バックアップリージョンでは1台のEC2を稼働させ、軽量版や小規模版を実行することがあります。トラフィックが切り替わる際には、すぐにWarm Poolから取り出してスケールアップします。時にはトラフィックが切り替わる前にEC2が起動して実行状態になることもありました。
CI/CDサーバーについては、AtlasとBambooを使用しています。市場には多くのCI/CDツールがあり、エキスポでいくつかを確認することができます。開発者からビルドのキューイング時間に関する苦情を受けることはありません。CI/CDツールのエージェントをより多く構築し、キューの深さに応じてWarm Poolから出し入れするようにしました - リクエストが増えれば追加で取り出し、キューが少なければそれらのEC2をオフにします。
現在では、スパイク的なワークロードに対応するためにWindowsアプリケーションをスケールする機能も備えています。スパイクは本質的に迅速な対応が必要なため、Windowsの起動に時間がかかりすすぎることから、これは以前には考えられなかったことです。しかし、Warm Poolとして準備されたサーバーを1〜2分で起動できれば、WindowsアプリケーションをLinuxやオープンソースアプリケーションのように扱うことができます。今後の検討事項としては、内部アプリケーションや低トラフィックアプリケーションへの適用、夜間や週末の使用量削減などがあります。そして今では、Petsのスケーリングも可能になりました。
その目標は本当に達成されました。Auto Scalingなどのあらゆる機能を活用することで、現在では1〜2分にまで短縮され、とても順調に進んでいます。さらに私たちは、そもそもサーバーを構築する必要がないのではないかと考えました。これを聞くと、多くの人はまずServerlessやLambdaを思い浮かべるでしょう。しかし、その前にContainerについて話す必要があります。
数年前を振り返ると、LuisとVeriskについて話し合っていたことを覚えています。私たちは.NETとJavaの両方を使用する企業で、多様な環境を持っていました。Javaアプリケーションはすでに数年前からEKS上で動作していました。私たちはコンテナ管理ツールとしてEKSを選択していたのです。Luisのオフィスで話し合っていたとき、Windowsワークロードについて「.NET FrameworkアプリケーションをWindowsコンテナに入れたらどうだろう？」という話になりました。当時、Windowsコンテナは徐々に注目を集めていました。アプリケーションを変更することなく、Windowsコンテナに入れてEKS上で実行できると考えました。調査を進めた結果、技術的には可能でしたが、いくつかの懸念がありました。WindowsコンテナはWindows EC2上で実行する必要があり、そのWindows EC2の起動を待たなければならないという問題がありました。さらに、WindowsにはFargateやGravitonで実行できないなどの制限がありました。
re:Inventで、ECSのGravitonについて、そしてGraviton ECSがWindowsをサポートする時期について発表していた方と話をしたことを覚えています。私はEKSとWindowsについて、それが実現するのかどうか尋ねました。その方は少し話題をはぐらかすような感じで、「Windowsの仕組みとFargateの仕組みを知っているなら、期待しない方がいい」というニュアンスの返答をしました。そこで私たちは方針を見直し、Microsoftが.NET Coreへの移行を強く推進していることに着目しました。「アプリケーションを.NET Coreにアップグレードしたらどうだろう？」と考えました。.NET CoreはLinux上で動作するため、可能性は無限大です。Linuxホスト、Linuxコンテナ、EKS、Fargate、Graviton、Spot Instanceなど、何でも使えるようになります。
私たちは比較的新しいアプリケーションの一つを選び、変更が不要な部分から.NET Coreへの移行を開始しました。同時に、私が「試行2a」と呼んでいる、.NETアプリケーションのServerless化とLambdaへの移行も検討しました。ただし、Lambdaは.NETを実行するすべての人にとってベストな選択というわけではありません。Lambdaには適している用途と、そうでない用途があります。残念ながら、私たちはそれを苦い経験から学びました。Lambdaのコストは、リクエスト数、実行時間、必要な計算リソースという3つの要因で決まります。計算リソースをあまり必要としない場合は問題ありません。しかし、普段はトラフィックが少ないものの大量の計算リソースを必要とするLambda関数があり、ある日突然大量のトラフィックが発生した場合、その1日のコストがEC2やEKSで1ヶ月運用するよりも高くなる可能性があります。残念ながら、これは私の実体験です。いくつかのLambda関数で、たった1日の使用で数千ドルものコスト急増が発生し、EKSやEC2で運用していた方が安かったケースがありました。
AWS Lambdaは確かに.NETにとって素晴らしいサービスですが、万能な解決策とは言えません。実際、最近.NET LambdaがLambda SnapStartに対応したというアナウンスがありました。これは.NETをLambdaで実行する際の新たなメリットですが、すべてのユースケースに適しているわけではありません。
AWSによるアプリケーションモダナイゼーション支援と今後の展望
明らかに、私は最も難しい部分である.NET Frameworkから.NET Coreへのアップグレードについて簡単に説明しました。「アプリケーションをアップグレードすれば、Linuxや好きなものでも実行できます」と言うのは簡単ですが、チームにアップグレードを実施してもらうのは困難です。多くの開発者は非常に忙しく、こういったことに時間を割く余裕がありません。一部のチームは成功しましたが、苦労したチームもありました。そこで、ChrisとAWS Application Modernization Lab（AML）について話し合い、彼らが参加してアップグレードの支援や、システムの更新を手伝ってくれることになりました。
Chris、AMLについてもう少し説明していただけますか？はい、ありがとうございます。これは一種の完全な循環ですね。最初、私はLuisと.NET CoreからGoへの移行について、そして私たちがどのように支援できるかについて話し合いました。彼らは素晴らしいことを行っていたので、その時点では「大丈夫です、何をすべきか分かっています」と言っていました。そして今、私たちがどのように支援できるかという話になりました。Application Modernization Labは、特定のワークロードを.NET Coreに移行することを決めた彼らと協力して、コストニュートラルベースでリソースとプロフェッショナルサービスを提供しています。
誰もがこのプログラムの対象となるわけではありませんが、良いニュースは、同様のことを行う多くのプログラムがあるということです。ここでの最大のポイントは、まだAWSのアカウントチームとモダナイゼーションや支援方法について話し合っていない場合は、ぜひその会話を持つべきだということです。アカウントチームがいない、または話をしていない場合でも、おそらくチームは存在するはずなので、見つける必要があります。私がその手助けをすることもできます。Amazon Q Code Transformationなど、.NET Frameworkから.NET Coreへの移行プロセスを自動化するツールもあります。AWS App Container、.NET Refactoring用のツールキット、そしてMicroservice Extractorもあります。
彼らのストーリーで素晴らしいと感じたのは、.NET Coreへの移行だけではないということです。Windowsワークロードを使用し、他のツールを活用してコストを削減することができます。「.NET Coreに移行すれば全て解決する」と言うのは現実的な答えではないことを私たちは知っているので、そこから始めるべきです。SQL ServerからPostgreSQLやAuroraへの移行も同様です。確かに彼らはAuroraワークロードを使用していますが、簡単ではないとわかっていることを「やればいい」と言うには、多くの信頼関係が必要です。質疑応答の時間に入る前に、いくつかの重要なポイントをお伝えします。継続的な改善が秘訣です。言うのは簡単ですが、彼らは常に改善を続け、より良くしようと努力し続けました。彼らが経験したヒントやコツ、そして場合によっては避けるべきことについても学んでいただけたと思います。モダナイゼーションを支援するツールがあることや、モダナイゼーションだけでなく、AWSインフラストラクチャをより効率的に使用することが重要だということを理解していただけたと思います。ありがとうございました。アンケートにご協力いただければ幸いです。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion