re:Invent 2024: BonterraのAzureからAWSへの全面移行 - 8ヶ月で実現した戦略と成果
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - From Azure to AWS: One organization’s all-in journey with AWS (XNT316)
この動画では、Bonterra Technologyが、AzureからAWSへのワークロード移行を決断した経緯と実践について紹介しています。18の製品、5つのデータセンター、150のベンダーという大規模な環境を、8-10ヶ月という期間でAWSに移行し、製品によっては50%のコスト削減を実現しました。移行にあたってはリフト＆シフトを避け、Kubernetesクラスターへの移行を目指すなど、戦略的なアプローチを採用。AWS Marketplaceの充実度や、Direct Connectの利用、Migration Acceleration Programの活用など、具体的な判断材料と成果が示されています。また、移行後の文書化により、コンプライアンス監査の期間を3ヶ月から1週間に短縮できたことなど、具体的な改善効果も報告されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSの強みと移行支援の取り組み
このセッションでは、お客様である Bonterra Technology の AWS オールインへの決断について、Azure からのワークロード移行を含めてご紹介します。私は Cameron "Cam" Hales と申します。AWS の Worldwide Specialist Organization のメンバーとして、パブリックセクターのパートナー企業が Microsoft ワークロードを AWS Cloud に移行・モダナイズする支援を行っています。
アジェンダをご覧ください。これは昨年このころに始まった実際のユースケースについてお話しします。まず、Bonterra が AWS との協業を選んだ理由となった重要なポイントについてお話しします。そして、非常に印象的なミッションを持つ Bonterra という企業についてご紹介します。その後、Nik と Sandy から、対象となるフットプリントやアプリケーションの範囲について詳しくお話しいただきます。彼らが「Bakeoff」と呼ぶ比較検討プロセス、つまりワークロードの移行先を決定する際に比較・検討した項目、技術的な評価、そして最終的な意思決定に至った経緯と振り返りについてお話しいただきます。最後に Q&A の時間を設けています。
過去に re:Invent に参加された方は、当時 AWS の CEO だった Andy Jassy（現 Amazon CEO）のスピーチをお聞きになった方もいらっしゃるかもしれません。私たちが社内で話し合いや顧客との会話で頻繁に引用する彼の言葉があります：「経験値には圧縮アルゴリズムが存在しない」。この経験こそが、このクラウド分野で私たちを他のプロバイダーと一線を画すものなのです。
私たちは2006年からクラウドサービスを提供してきました。多くのお客様は私たちを新参者だと思われがちですが、実は私たちが先駆者なのです。この18年間で、200以上のサービスと機能を開発してきました。これらの多くについては、この4日間で詳しく学んでいただけることと思います。
私たちの機能開発とイノベーションの代表例が、Generative AI スタックです。このスタックは、お客様のニーズに応じて柔軟に対応できるよう設計されています。例えば、ビジネスアプリケーション開発、分析、カスタマーエンゲージメントのための Amazon Q ファミリー製品のような AI 強化型アプリケーションを利用したい場合や、Bedrock サービスを通じて事前学習済みモデルを活用したい場合、あるいは革新的なインフラストラクチャを活用して独自のモデルをトレーニングし、イノベーション体験をカスタマイズしたい場合など、様々なニーズに対応できます。
先ほど申し上げたように、私たちはお客様のニーズに寄り添っています。AWSは2008年に初期のマシンインスタンスをローンチし、WindowsとSQL Serverのサービスを提供した最初のプロバイダーでした。16年以上にわたり、MicrosoftのワークロードはAWSにおいて第一級の存在として扱われてきました。AWSでワークロードを運用し、豊富なサービスと機能を活用できるだけでなく、ビジネスにとってより有利だと判断された場合には、それらのアプリケーションやプラットフォームをモダナイズするオプションも提供しています。これにより、AWSクラウドの機能を活用しながら、スケールとイノベーションを実現することができます。
また、私たちの経験は実証済みの移行方法論にも反映されており、NikとSandyが、AWSへの完全移行を決断する際にこのフレームワークがどのように影響したかについてお話しするでしょう。環境を評価するためのツールを用意しており、移行対象となるアプリケーションとインフラストラクチャを完全に把握することができます。何を移行するのかを知る必要があります - Shadow ITは常に頭を悩ませる問題です。評価データを確認する際に「そのシステムが稼働していたとは知らなかった」とか「これがあれと連携していたなんて知らなかった」といった反応が返ってくる顧客との会話に、私は何度も遭遇してきました。これはアプリケーション移行を計画する際のプロセスの一部なのです。実際のリソース使用状況に基づいて、確実に移行を計画できるリソースと方法論を私たちは提供しています。
評価プロセスを通じて収集したデータを活用し、移行計画プロセスにおいて重要な項目がすべて考慮されるようにしています。組織内の技術チームや関係者と時間をかけて協力し、この取り組みの影響を確実に理解してもらいます。ビジネスへの影響を最小限に抑えるよう努めており、何かしらの変更は避けられませんが、チーム、ユーザー、お客様が認識し準備できるようにしています。この認識を持つことが、組織への混乱を最小限に抑える方法の一つなのです。
移行前と移行後のために、移行プロセスの自動化や効率化を支援するツールを用意しており、今週中にそれらについて詳しく学んでいただけます。AWSへの移行が完了しても仕事は終わりではありません。適切なサイズの環境で運用されていることを確認するためのツール、プロセス、リソースも用意しています。クラウドスケールなどの機能や考慮事項が増えるため、レガシー環境が必ずしもAWSでの将来の環境に最適なモデルとは限りません。最高のパフォーマンスとコスト効率で運用できるよう支援しています。
これが私たちのDay Oneの焦点であり、移行したものを文書化することも含まれます。ベースラインと現状を理解する必要があるのには、いくつかの理由があります。第一に、移行を行うチームと、インフラストラクチャの保守・運用を行うチームは必ずしも同じではありません。第二に、私たちはイノベーションと発明の会社なので、そのイノベーション活動が始まるベースラインを理解する必要があります。これらは、クラウド移行とモダナイゼーションの journey においてお客様をサポートする方法のほんの一例であり、彼らの意思決定プロセスにおいて重要な要素となりました。
Bonterraのクラウド移行戦略：AWSを選択した理由
皆様、こんにちは。Bonterraのクラウド最適化担当Senior Vice Presidentを務めておりますNik Kozlovと申します。本日は、SaaS運用担当Senior Vice PresidentのSandy Vannと共に発表させていただきます。 当社について少しご紹介させていただきますと、私たちは様々な規模や形態の製品ポートフォリオを保有しており、それらは異なる場所で運用されています。当社はソーシャルグッド・ソフトウェア企業として2番目の規模を誇り、最も急成長している企業の一つです。
運用の全体像を俯瞰しますと、18の製品を展開し、5つのレンタルデータセンターで運用を行い、150のベンダーと取引があります。これらのサードパーティアプリケーションは、私たちの製品のメンテナンスに不可欠なものです。主要なデータベースタイプは5つありますが、その他にも様々な場所で使用している小規模なデータベースがあります。3つのクラウドで運用を行い、8つの主要プログラミング言語を使用しています。
データセンターのフットプリントを見ると、5つのデータセンターがあり、すでにAWSでかなりの負荷を処理しています。また、Azureも利用しており、以前はHerokuも使用していました。これらの製品全てを維持することの複雑さは、保守チームやソフトウェア開発チームにとってかなり大きな課題となっています。 ここで紹介する製品の一つは、その複雑さを如実に示しています。2023年時点で、3つのクラウド、2つのデータセンターにまたがって運用され、1000コア、1.2テラバイトのRAMを使用していました。決済を扱っているため、すべてが安全である必要があり、様々なネットワーキングとファイアウォールが設置されています。この製品がどのように機能し、すべてのチームがどのようにしてそれを維持できているのかは、とても興味深い事例です。当社のCEOであるScott Brighton氏は、
マルチクラウドは抽象化を生み出すと常々言っていますが、特に私たちのような大規模なフットプリントを持つ環境では、まさにその通りだと実感しています。そこで私たちは、具体的な目標を持ってクラウドプロバイダーへの移行を進めることを決めました。
ビジネスの観点から、私たちはすべてを一つの場所に標準化したいと考えました。複数のデータセンターにまたがる多数の製品を維持することは常に課題であり、高いSLAを維持し続けることは絶え間ない要求となっています。チームメンバーは特定の領域のスペシャリストであり、他の製品への異動には常に長い時間がかかるため、製品間で効果的にチームを活用することができませんでした。私たちの主要な目的の一つはコスト削減でした。データセンター用のハードウェアを購入することで、主にデータセンター自体の費用を支払う固定費の状況が生まれますが、ハードウェアは最終的に故障し、メンテナンスが必要になります。私たちは、エンジニアが単一のインフラストラクチャで作業しやすくし、異なる領域のトレーニングを容易にしながら、全体的なコストを削減したいと考えていました。
技術的な目標に関して、私たちはクラウドサービスを論理的に活用したいと考えていました。つまり、できるだけ多くのサービスを使うという方針ではなく、常にProof of Conceptを繰り返すような状況も避けたかったのです。また、すべての製品を一箇所でモニタリングし、単一のCI/CDを実装することを目指しました。これは、時間とともに複数の製品が当社に加わった結果、様々な種類のCI/CDが存在していたためです。Infrastructure as Codeのアプローチを標準化し、最終的にはKubernetesクラスターへの移行を目指していました。そして、単純なLift and Shiftは絶対に避けたいと考えていました。
ある時点で、私たちは2つの選択肢の間で決断を迫られました。すでにワークロードの一部が稼働しているAzureに移行するか、あるいはAWSに完全に移行するかという選択です。私たちはプロバイダーとの協議を開始し、コスト比較を確実に行いました。また、どちらのプラットフォームに移行するにしても、具体的な移行方法を評価する必要がありました。この2つの選択肢の間で重要な決断を迫られていたのです。
AzureであれAWSであれ、技術要件として、Kubernetesに移行する場合はWorkerノードの細かな制御が必要でした。製品の安全性と分離のために、シングルテナントのコントロールプレーンが必要でした。自動アップグレードは望んでいませんでした。これは、Azure AKSクラスターで自動アップグレードが発生し、ワークロードに悪影響を及ぼした経験があったためです。すべての製品で監視を標準化し、Level 1チームもLevel 3チームも、SLAの改善や障害の迅速な解決に必要な情報を収集できるよう、高度なメトリクスを一箇所で取得したいと考えていました。また、大規模なデータ負荷に対応できる、簡単で信頼性の高いネットワーク設定も必要でした。
技術力を評価したところ、チームの50%がAWSにより精通していることがわかりました。移行前のインフラ分布を分析したところ、すでに45%のインフラがAWS上にあり、これは大きなアドバンテージでした。データベースの分布については、主にオープンソースのデータベースを使用していましたが、Microsoft SQL Enterpriseもかなりの量がありました。オペレーティングシステムの依存関係については、主にLinuxで運用していました。
私たちがAWSを選択した理由は、EKSが私たちのワークロードに十分な分離を提供し、自動アップグレードがないため、インフラを望み通りにコントロールできるからでした。また、私たちのデータセンターの1つがMarkleyで運用されていて、Markleyがすぐに使えるDirect Connectを持っていたのは幸運でした。というのも、データセンター間のVPN接続に加えて、安定したトラフィックの送受信を確保する必要があったからです。
セットアップが容易になり、チームはすでにCloudWatchエージェントで使用しているAWSのメトリクスに精通しているため、必要な数のメトリクスを取り込むことができます。過剰な請求を避けるため、最適化も確実に行いました。ビジネス面では、AWSが非常に魅力的な提案を行い、素晴らしい割引を提示してくれました。ただし、短期間でかなりの規模のインフラをAWSに移行する必要があるという条件付きでした。私たちの移行は、AWSに急かされたからではなく、むしろ私たちが何をすべきかを理解していたからこそ迅速に進められました。戦略的な判断を下せる優れたチームがいたからです。
私は、クラウドへの移行において、単なる経験だけで技術的なProof of Conceptの判断を下すことには常に懐疑的です。そのため、ECSクラスターやその他のインフラではなくKubernetesを選択し、チームの大多数がすでに知っているインフラを採用することを決めました。これにより、新しいクラウドでの製品の立ち上げがスムーズになり、全員にとってより理解しやすくなって、多くのミスを防ぐことができると考えたからです。
AWSからは優れた技術サポートを受けており、データセンターやAzureからの移行時には、AWSのソリューションアーキテクトにいつでも連絡を取ることができました。適切な質問をすれば、彼らは的確な回答を返してくれ、私たちがミスを犯さないよう前に進めてくれました。移行中も昼夜を問わずサポートしてくれ、何も問題が起きないよう見守ってくれました。アメリカ、AWS、パリ、イギリスなど、グローバルなチームの専門家たちが支援してくれました。
ベンダー向けのAWS Marketplaceは素晴らしかったです。私たちには150のベンダーがいて、AzureとAWSを比較検討していました。これだけ多くのベンダーをどうやって管理するか、つまり、多くの見積もりが入ってきて、支払いが発生し、ベンダーやソフトウェアの問題に対応する必要がありました。これらすべてをどのように管理し、サポートするかを考える必要がありました。そこで、私たちのベンダーの大半がAzureよりもAWS Marketplaceにすでに参加していることがわかり、これも大きな決め手となりました。
AWS移行の成果と今後の展望
現在2024年11月、私たちは製品の大部分をAWSに移行することに成功しました。これは8〜10ヶ月の間に、ソフトウェアエンジニア、DevOps運用チームなど、多くのチームの懸命な努力によって実現しました。目指すクラウドへのソフトウェアの移行を完了させるため、全員が完璧に連携して取り組みました。 これは製品の移行方法を示した簡単なアーキテクチャ図ですが、ご覧の通り、一部のサービスがAWSネイティブではありませんが、それで問題ありません。
ご覧の通り、すべてのサービスがAWSネイティブというわけではありませんが、それで問題ありません。同時に、この図に示されている通り、顧客側に依存関係があることも認識しています。Fastlyから移行したかったのですが、300の顧客が持つ300のバニティドメインDNSを変更する必要があり、すべての顧客に連絡しなければならないという単純な理由で実現できませんでした。そこで、Customer Successチームと話し合い、Giving Tuesdayの前日に当たる明日のような重要な時期に、すべてのコミュニケーションが確実に行われるようにしながら、顧客が変更に安心できるようにして、徐々に移行していくことにしました。一晩で実現する必要はないのです。
私たちは80/20ルールを適用し、負荷の80%を一箇所に移行し、20%を維持することにしました。これを文書化し、この作業が確実に継続されるようにすべてのプロセスを整備しています。現在すでにAWSに移行していますが、Direct Connectの接続性など多くの利点を活用しています。AzureやデータセンターからAWSへの移行により、多くの製品で50%のコスト削減を実現しました。リフト＆シフトではないアプローチを採用したことで、より多くの知見を得ることができました。
私たちの製品の中には20年以上の歴史を持つものもあります。そのため、時として文書化されていない、あるいは特定の個人が独占していた知識が失われてしまうことがあります。リフト＆シフトアプローチは常に簡単な選択肢でしたが、それは常に戦術的な決定でした。移行の初期段階で、リフト＆シフトを行うと、CI/CDをどのように再構築するか、製品をどのように維持するかを理解できないことに気付きました。AWSに移行した後でもSLAを維持し、改善できることを確認する必要がありました。
構築した文書化と得られた知見のおかげで、すでにPCIやISOなど、複数のコンプライアンス監査を実施しました。これらは実施した監査のほんの一例ですが、移行後に作成した文書のおかげで、監査人から、監査期間を3ヶ月から1週間に短縮できたと言われました。これは私たちにとって大きな進歩でした。私自身、これらの製品の専門家として数回の監査に関わりましたが、監査人から、移行済みの製品に関しては、すべての製品がこのようであればいいのにと言われました。
先ほど申し上げた通り、AWSはこのプロセス全体を通じて私たちをサポートしてくれました。AWSのチームが私たちの運用方法を理解する必要があったため、正直に言って大変な作業でしたが、彼らは時間を割いてくれ、素晴らしい成果を上げることができました。また、Migration Acceleration Programも活用しました。私はAWSと10年間働いてきましたが、実際にこのプログラムを使用したのは初めてでした。今回使用してみて、6桁から7桁のクレジットを獲得できました。また、ベンダーの50%をMarketplaceに移行したことで、大幅な時間削減を実現しました。現在では、すべてを一箇所で管理できるようになっています。
では、私たちの予測されるフットプリントについてですが、これが第2四半期に実現する姿です。移行が必要な製品はあと1.5個だけとなっています。時間はかかりますが、今年は様々なイベントが重なったため、いくつかの移行を一時的に中断していました。しかし、着実に前進しており、この状態に到達することは確実です。というよりも、すでに大部分の移行は10ヶ月の期間をかけて完了していますので、必ず実現できます。以上で発表を終わらせていただきます。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion