re:Invent 2024: Allspringのクラウド移行 - 60ワークロードをAWSへ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Modernizing a spin-off in the cloud: Allspring’s journey with AWS (XNT315)
この動画では、Wells Fargo Asset Managementから分社化したAllspring Global Investmentsが、約60のワークロードをAWSへ移行した事例が紹介されています。Head of Technical Architecture and StrategyのJustin Stokes氏が、データセンターからの脱却を決断した背景や、SQL ServerやOracleなど多数のデータベースを含む移行プロジェクトの進め方について解説しています。また、AWS Senior Solutions ArchitectのVikas Babu Gali氏が、AWS Schema Conversion Toolを使用したデータベースのモダナイゼーション手法をデモを交えて説明しています。Infrastructure as Codeの活用やコスト最適化、マネージドサービスの活用など、クラウドネイティブな環境への移行を成功させるための具体的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSへの移行：Allspringの旅路を探る
XNT 315「Modernizing a spin-off in the Cloud: Allspring's journey with AWS」へようこそ。本日は複数の講演者からお話を伺います。まず、Allspring Global InvestmentsのHead of Technical Architecture and StrategyであるJustin Stokes氏、そしてAWSのSenior Solutions ArchitectでMicrosoft技術、特にSQL Serverを専門とするVikas Babu Gali氏です。
私はThorr Giddingsです。ビンゴカードに「スーパーヒーローの名前を持つ人に会う」というマスがあれば、それは達成です。私はUS Enterprise Applications, Migrations and Modernization Solutions Architect Leaderを務めています。肩書きは長いですが、Microsoftワークロード、SAPワークロード、VMwareワークロード、サーバー、サーバーレス、コンテナなど、そういったものすべてを担当する部門のリーダーです。これらをAWSに移行する際は、喜んでお手伝いさせていただきます。
では、本日のアジェンダについてお話しします。まず、お客様がどのようにAWSに移行するかについてお話しします。続いてJustinが、Allspring Globalの紹介、AWSへの移行を決めた要因、クラウドへの移行の道のり、AWS移行後の経験、そして今後の計画についてお話しします。その後、Vikasがモダナイゼーションについて説明し、AWSのお客様のために特別に開発された技術のデモをご覧いただきます。とても興味深い内容ですので、最後までご覧ください。
クラウド移行の課題と戦略
本セッションは、AllspringのAWSへの移行についての300レベルの講演で、皆様が現在直面している、あるいは過去に経験された課題と似ているかもしれません。おそらく皆様が抱えている課題は「複雑なワークロード群をお客様への影響を最小限に抑えながら、どうやってAWSに移行するか」ということでしょう。様々な依存システムがあり、Active Directoryの移行方法、Windowsファイル共有の戦略、SQL Serverへの対応、そしてコアアプリケーションの扱いについて検討されているのではないでしょうか。本日はこれらすべてについて、そしてJustinからAWSでの成功事例についてお話しいただきます。
この講演をお聞きいただく中で、特に意識していただきたいのは、御社にとって価値を生み出すものは何か、そしてAWSに任せられるものは何かということです。もし御社の価値創造やお客様体験の向上に直接関係のないものであれば、それは差別化につながらない作業として、マネージドサービスに移行することを検討してみてはいかがでしょうか。
まずは「なぜ」から始めましょう - なぜAWSに移行するのでしょうか？何を達成しようとしているのでしょうか？ データセンターからの脱却を目指すお客様もいれば、より機敏でイノベーティブになることを目指すお客様、コスト削減を試みるお客様、より少ないリソースでより多くのことを実現しようとするお客様もいます。ただ、私の経験では大多数の - ちょっと挙手していただけますか - 皆さんは、これらすべてを同時に実現しようとしているのではないでしょうか？そうですね、うなずいている方々がいらっしゃいますね。素晴らしい。
このようなプロジェクトを複雑な変革として捉えることが非常に重要です。結局のところ、これは単なるITプロジェクトではありません。すべてのチームが同時に同じ方向に向かって進む必要があります。そこで自問する必要があります：全員が納得しているでしょうか？ITチームやデベロッパーだけでなく、運用チームは納得していますか？ビジネスのステークホルダーたちは最初から納得しているでしょうか？
AWSへの移行：経験から学ぶ重要ポイント
お客様との成功事例について、少し私の経験をお話ししましょう。これまで何百、おそらく何千ものお客様とお話してきました。特にAWSをしばらく使用されているお客様と話すとき、最初に尋ねることの一つがタイムマシンの質問です。「Thor、タイムマシンの質問って何？」とお思いかもしれません。実はとてもシンプルです：もしAWSの導入journey（道のり）を振り返ることができるとしたら、何を違う方法で行いますか？この質問への回答は、私が最初に尋ね始めたときは意外でした。異なるテクノロジーの実装や特定の障害の回避についての話が出るだろうと思っていたのですが、実際はそうではありませんでした。私が耳にするのは、いくつかの異なるテーマです。一つ目はCloud Operationsに関することです。多くのお客様がオンプレミスのシステムをAWSに持ち込みます - ロギングやパッチ適用システムなどですが - 彼らは早い段階でPatch ManagerやCloudWatch Logsなどを検討しておけばよかったと考えています。なぜなら、AWSで動作させるために時間を費やしたにもかかわらず、最適とは言えないシステムのままだったからです。
Infrastructure as Codeは、もう一つの重要な考慮事項です。多くのお客様は、AWSへの移行だけに焦点を当てていますが、それはゴールではなくスタートラインに過ぎないことに気づいていません。マーケティングチームがアプリケーションの新バージョンを必要とする場合、それを構築するために様々なコンポーネントを分解する必要があります。Infrastructure as Codeを使用すれば、アプリケーションに必要なすべてのリソースと設定要件を構築できるので、数週間だけ別の環境が必要な場合は、それを作成し、終了したらそのスタックを解体して課金を停止できます。
最も頻繁に耳にするフィードバックは、「もっと早くAWSのグループのことを知っていればよかった。もっと早くAWSに相談していればよかった」というものです。私たちはお客様をサポートするためにここにいて、そのためのさまざまな方法を用意しています。私は米国でSolutions Architectグループを率いており、お客様とそのチームがAWSのテクノロジーを深く理解するための様々な方法を提供しています。 最初の一つがWorkshopsです。Workshopsは非常に興味深い取り組みで、トピックを選んで、デモ環境で実際にキーボードに触れながら体験でき、異なるアプローチについてSolutions Architectに質問することができます。
次に紹介するのは、お客様から最も大きな反響をいただいているEBA（Experience-Based Accelerator）です。1週間のSprintを想像してみてください。IT運用チームを含め、本番環境へのデプロイに必要な全員が同じ部屋に集まります。特定の部分を変革するという目標を設定し、1週間で実現します。インタラクティブな取り組みで、途中で問題が発生しても、AWSのエキスパートがその場でサポートしてくれます。 最後はProof of Concept（POC）です。POCでは、アプリケーションにサービスを追加したり、より耐障害性を高めたりすることを検討する際に、Solutions Architectが実現可能性の検証や、Well-Architectedな方向性の見極めをサポートします。私たちは常にお手伝いする準備があります。もしSolutions Architectが見つからない場合は、私に連絡してください。AWSにThorという名前の人はそう多くないですから。
効果的なクラウド移行のアプローチ
多くのお客様で成功を収めている方法論についてご説明します。まず、私が「アクティブ投資システム」と呼んでいるもの、つまり最もよく理解していて日々開発を行っているシステムに焦点を当てます。これらは、他社との差別化要因となるシステムです。システムについて熟知していることは、トラブルシューティングや、問題がAWSの設定によるものなのか、アプリケーションによるものなのかを判断する上で非常に重要です。良いニュースは、これらのアプリケーションを開発したのはお客様とそのチームなので、誰よりも詳しいということです。
AWSへの移行について具体的にお話ししましょう。私は大きく4つのWaveに分けて考えています。 第1のWaveは、コアインフラストラクチャです。最初のワークロードを導入するために必要な基盤システムすべてが含まれます。Active Directory、アカウント戦略、セキュリティ戦略、ログ管理、IAMロールの定義などが含まれます。 第2のWaveは、先ほど説明したアクティブ投資、つまり開発中で誰よりも詳しいシステムです。 第3のWaveは、アクティブメンテナンスシステムです。これらはCOTSアプリケーションやOracleワークロードなど、維持管理は必要だが積極的な開発は行っていないものかもしれません。これらのアプリケーションは動作させる程度の知識はありますが、ソースコードは所有していません。 最後のグループは、その他すべてのアプリケーションで、部門向けアプリケーションや小規模グループのアプリケーションが含まれます。小規模グループのアプリケーションとは、「ああ、またあのアプリケーションか」とか「再起動してみた？」といった反応が返ってくるようなものです。
これらは後のWaveに回すべきです。決して先送りを推奨しているわけではありません。私が言いたいのは、これらのWaveを進めていく中で、AWSについての理解が深まり、設定やトラブルシューティングの能力が向上していくということです。そのため、第4のWaveに到達する頃には、「これはAWSの問題なのか、アプリケーションの問題なのか」と悩む代わりに、システムを機能させることに集中できるようになります。
私は「失敗」という言葉が好きではありません。 少し違う角度から見てみましょう。失敗には大きく2つのタイプがあります。1つ目は従来型の失敗です。 ビジネスに影響を与え、深刻な影響をもたらすもので、夜も眠れなくなるような失敗です。これは避けたい失敗です。 もう1つはタイプ2の失敗で、成功したいのであれば、このタイプの失敗には十分慣れておく必要があります。これは、できるだけ早く前に進む方法を見つけ、何かを試してみて、うまくいかなければリソースを返却し、その日は満足して終えるというものです。プライドや責任追及の問題ではなく、できるだけ早く問題を解決することが重要なのです。
AWSでは、過去5年、10年、あるいは20年にわたって抱えてきた大きな失敗への懸念の多くが、もはや存在しません。長期のソフトウェア契約を結んだりハードウェアを調達したりする必要がないからです。素早く失敗し、リソースを返却して、別のアプローチを試すことができます。私の多くの顧客は、Data Lake、Data Warehouse、あるいはアプリケーションと認証システムの統合を検討する際に、POCを実施します。アイデアから実装までを、何週間や何ヶ月ではなく、数時間や数日で実現できることを知っているのです。23年以上開発者として働いてきた私が本当に素晴らしいと感じるのは、常に本番環境グレードのサービスを使用できることで、ソフトウェアのデモライセンスの期限切れを心配する必要がないことです。
ビジネスグループから「すぐに何かを修正してほしい」と依頼されたことは何度ありますか？週末を返上して家族との時間も犠牲にして作業し、月曜日に出社したら「優先順位が下がったので、テストは数週間後になる」と言われた経験は？AWSの素晴らしい点は、このような迅速なPOCを実施でき、環境が不要になれば停止できることです。Serverlessを使用している場合は、テストが必要な時に自動的にスケールアップ・ダウンします。広範な計画を立てたり、貴重なリソースを無駄にアイドル状態にしたりする必要はありません。
Allspringの事例：AWSへの移行とその成果
では、Justinをステージにお呼びして、彼のAWSでの経験についてお話しいただきます。 Allspringは非常に成熟した資産運用会社です。以前はWells Fargo Asset Managementでしたが、約2年前に分社化してAllspringとなりました。私たちは自分たちを「意図的な投資家」と考えています。目的を持って投資し、先を見通すことを心がけていますが、同時にテクノロジーも活用しています。成熟した資産運用ビジネスに加えて、従業員が20%を所有しており、現在約5,900億ドルの運用資産を有しています。
私たちの旅は 1995年のWells Fargo Asset Managementの設立から始まりました。2021年頃に分社化が始まり、それはテクノロジーの導入を開始するのに絶好のタイミングでした。2021年11月にAllspringとしてリブランドし、その後10月に私が加わってマイグレーションの作業を開始しました。
現在、私たちは非常に成熟した資産運用ビジネスと、スケールのあるテクノロジースタートアップの両方の性質を併せ持っています。これは少し「私は誰？」という状況です。なぜなら、私はAllspringについて話していますが、Allspringこそが本日の主役なのです。 私自身について30秒で自己紹介させていただくと、テクノロジー業界で30年、金融分野で14年以上、そしてAWSで6年の経験があります。これを申し上げるのには理由がありますが、皆さんが思うのとは違う理由です。Thorrや彼の同僚に後で聞いていただければわかりますが、私は彼らに対してあらゆることについて意見を述べます。このプラットフォームを強く信じており、それを推進しています。その結果として、AWSから多くの人材を引き抜いてきました。
私たちは2021年に大きなインフラ関連の決断から始めました。計画フェーズに入った時、事業分割が迫っていることを知っており、データセンターへの投資かクラウドへの移行かという重要な判断を迅速に下す必要がありました。2021年当時の状況を覚えている方なら、ハードウェアの調達が非常に困難な時期だったことをご存知でしょう。そのことが私たちの判断に影響を与えましたが、実際のところ、私たちは確立された資産運用ビジネスを充実させるためにテクノロジーへの投資に本気で取り組んでいました。
約60のワークロードを移行する必要があり、迅速に移行できる環境が必要でした。私たちにとって重要だったのは、ほぼ同等の環境で移行し、既存システムに悪影響を与えないことでした。私たちは多くのSQL、Windows、Active Directory、.NET、そしてOracleデータベースを使用するMicrosoft中心の環境でした。迅速に行動する必要があり、AWSの言葉を借りれば「Scrappy」である必要がありました。インフラ構築と並行して社内の専門知識も構築していたため、できるだけ少ない人数で可能な限り早く実行する必要がありました。 安全かつ効率的に行い、将来を見据えながら、素早く移行する必要がありました。大手資産運用会社として、時は金なりでした。できるだけ早く稼働を開始し、当時アプリケーションが置かれていたデータセンターから脱却することが非常に重要でした。
私たちの出発点を説明させていただくと、大量のデータベースと従来型のデータを抱える、非常にデータ重視の環境でした。多数のアプリケーション、大量のコア、そして大容量のストレージを持つ基幹システムがありました。エンジニアリングリーダーの一人から指摘されたのですが、バケットストレージの500テラバイトを計算に入れていませんでした。私はデータベースとアプリケーションストレージだけを見ていたんです。これらは約60の独自ワークロードに分散され、相互に密接に接続されていました。
私たちは現状を把握しました。大量のデータ、多数のリレーショナルデータベース、そして大規模なストレージ要件がありました。必要だったのは、コンピュートインスタンスをスピンアップし、同等の環境を構築し、既存システムに影響を与えないことでした。それが私たちの大きな焦点でした。いかに素早くこれを実現できるかを考える必要がありました。ご想像の通り、結果として私たちはAWSを大規模に活用することになりました。 正直に言うと、このスライドはデモ資料に入っていたものを使わせていただきました。このスライドが私の心に響いたのは、2021年末というのが、大きな視点で見ればそれほど昔のことではないからです。当時、私たちのAWSの利用額は、まさに始めたばかりの小規模ビジネスと言えるほどわずかでした。その移行から2年も経たないうちに、支出とインスタンス数を見ると約20倍に成長し、今でも成長を続けています。新しいワークロードを構築して、迅速に進め、素早く失敗したいと思うたびに、すぐに実行できることを本当に気に入っています。ほとんど障壁がないんです。
では、なぜAWSを選んだのでしょうか？まず最初に、Mという言葉を使わせていただきます。私たちはマルチクラウドの環境です。必要な各テクノロジーに最適な場所を選ぶという戦略的な決定を下しました。
ここで私の偏見が入ってきました。Amazonは目的に最適なものを選び、最善を尽くすという方向に私を強く導きました。その結果、私たちの本番ワークロードはすべてAWSに置かれることになりました。開発環境、本番環境、UAT環境もそこにあります。他のパートナーの得意分野も活用していますが、安定性、マネージドサービス、機能性という観点では、AWSが私たちにとって大きな助けとなりました。
データベースモダナイゼーションへの挑戦
各サービスの運用性、安定性、成熟度は私たちにとって非常に重要でした。大量のデータと多くのデータベースを移行する必要があり、マネージドサービスが利用可能で、私のニーズすべてに対応できることを確認する必要がありました。AWSはそれらの要件をすべて満たし、最小限の管理で実現させてくれました。最終的に、私は移行に焦点を当て、運用は最小限の人員で行い、それを時間とともに展開していきたいと考えていました。マネージドサービス、Serverless、コンテナ化、そしてデータを配置できるすべてのコアインフラに関するサービスは、私が望むものすべてを提供してくれました。
マルチティアアプリケーションの基本的な図を示します。ここでの過度な複雑さに惑わされないでください。これは、データセンターにある私たちの一般的なアプリケーションが標準的なマルチティアアプリケーションだったことを示すために掲載しました。私たちは「無害化」アプローチで臨みました。データベースとコンピュートを、とにかく移行することが重要でした。AWSの基本的な機能、分散化、Availability Zoneやリージョンの分離などを活用することで、移行時にほとんど変更を加えることなく、信頼性とレジリエンスを向上させることができました。この標準的な基本モデルを採用することで、変更を最小限に抑えながら、より良い結果を得ることができました。
私たちは多くの共有サービスを活用しています。マネージドサービスは私たちにとって大きな要素でした。私のチームはAWS Directory Service、データベース管理、ストレージ管理、エンドユーザーデバイス管理、バックアップなどの標準的なものに関して非常に高い能力を持っています。スキルセットは持っていますが、時間と人員が不足しています。これは重要な区別です。多くの企業がスキルがあるから自分たちでできると判断しますが、私たちは一歩下がって、スキルはあるけれどもやりたくないと考えました。私はDBAたちにクエリの改善、データ移行、ビジネスの機能性を向上させる作業に集中してほしかったのです。
大量のストレージが必要でした。Amazon FSxを広範に使用しています。素晴らしかったです。NetAppのスキルもあり、標準的なSMBやNFSストレージを大量に配置する必要がありました。これはストレージ管理者が不要になることを意味し、大きな成果でした。私たちはこれらのサービスを大いに活用しました。Amazon RDSについても触れなければなりません。私たちは大規模なOracleとMicrosoft SQLの環境を持っていますが、データベース移行やインスタンスレプリケーションの作業から解放され、設定して離れることができ、そこにエネルギーを費やす必要がなくなったことは、ビジネスにとって大きな成果でした。これにより、インフラのサポートではなく、テクノロジーを通じた価値の提供に集中できるようになりました。
私たちは多くのAWSのコアサービスも活用しました。 AWS Systems Managerは私にとって大きな助けとなりました。システムの移行を進める中で、多くのインスタンスの管理について話し合いましたが、中央インフラについてはどうでしょうか？どのように更新し、管理し、ユーザーを扱い、認証を処理するのでしょうか？通常は当たり前のこととして見過ごされがちなこれらの要素について。私たちはこれらを最初に設定する必要がありました。しかも移行中に設定しなければなりませんでした。そこで基本的なサービスを大いに活用しました。AWS Systems Managerで多くのインベントリ管理とアップデートを処理しました。
GuardDutyとAmazon Inspectorを活用することで、スピーディーな展開を維持しながら、安全性とセキュリティを確保することができました。実は少し内緒の話をしますと、現在では AWS以外のクラウドでもWindows更新プログラムの適用にSystems Managerを使用しています。これは想定外の選択でしたが、結果として私たちにとってより堅牢で柔軟、そして普遍的なソリューションとなりました。インスタンス全体で単一のアップデート方式を採用することを決定し、それによって効率が上がり、単一の画面で管理できるようになりました。セキュリティチームとパッチチームは一箇所だけを確認すればよくなり、これが本当に役立ちました。
AWS Schema Conversion Toolを用いたデータベース移行のデモンストレーション
次にコストについてですが、これは私の情熱を注ぐポイントで、後ほど詳しくお話しします。移行を進める際は、初日からコスト管理について考える必要があります。ここで言うコスト管理とは、単に安価なオプションを選ぶということではなく、Amazonが提供する早期のコスト管理のためのプランやプログラムについて考えることです。多くの場合、移行の性質上、これらは後半で話題に上がりがちですが、移行の見通しが立っているなら、早い段階から検討すべきです。
結局のところ、私たちは規模を持ったスタートアップのような存在でした。ビジネスとしては非常に成熟していますが、技術チームの観点では新しい組織でした。私たちにとって、AWSはパラダイムシフトでした。オンプレミスのインフラに慣れた確立された金融機関にとって、クラウドの可用性、パフォーマンス、スケーラビリティの側面は非常に異なります。物事の考え方が全く違うのです。完璧ではありません - 私たちも停止や問題を経験してきました。しかし、よりクラウドネイティブになるにつれて、復旧能力が向上し、より強靭なシステムを構築できるようになってきたことが、私たちの差別化要因となっています。
これは基本的な要件であり、しかも私たちにとって重要なポイントである、ワークロードを最小限の変更で実現できています。他の皆様と同様、私たちも停止を経験し、ミスを犯しますが、これらの基本的な要素に焦点を当てることで、実際のワークロードの変更や最新化に最小限の投資で、より良い結果を得ることができています。これは私たちがAWSについて本当に気に入っている点です - 素早く失敗し、バッファを設け、少しずつ構築することができます。私たちの旅路についてお話ししたいと思います。どのような旅路だったのかを率直にお伝えすることが重要だと考えています。申し訳ありませんが、このスライドは情報が詰まっていて見づらいかもしれません。
上部のバンドが私たちが本当に話している部分です。2022年半ば以前は、私たちはData Centerにいました - すべてのWorkloadがWells FargoのData Centerにありました。それらを移行する計画を立てていました。最初のスコーピング、Workloadの見積もり、そしてパートナー選定やスコープを含むすべての計画を行いました。そして実行に移り、2022年後半に実際の移行を開始しました。私がSequencingを再度ステップとして入れたことにお気づきかと思いますが、これは大規模な移行を行う場合、計画を立て、アプリケーション間の相互接続性を理解し、これらすべてを構築した後で、チームの可用性、チームの準備状況、予期せぬ依存関係によってそのSequencingが変更されることを認識することが重要だからです。柔軟に対応する準備が必要です。2022年から2023年は、私たちにとって柔軟性がすべてでした。
2024年半ばに入ると、コスト比較と統合の観点から最適化に焦点を移し始めました。Wells FargoとWells Fargo Asset Managementの歴史をご存知の方は、時間とともに多くの異なるAsset Management企業を買収して成長してきたことをご存じでしょう。
その結果、私たちには非常に成熟した異なるWorkloadがあり、並行して構築し、相互接続し、これらのことを迅速に行う能力から恩恵を受け始めています。これが2024年の私たちのテーマでした。Modernizationについて考えていますが、それに固執しているわけではありません。これは移行の旅の重要な部分だと思います。Cloud技術とCloud可用性を検討する際に、途中で物事を壊したくはありません。将来待ち受けているこれらの素晴らしいことについて考えることは重要ですが、あまり興奮しすぎないように注意する必要もあります。2025年以降、私たちはModernizationフェーズに入りますが、これは私たちにとって永続的なフェーズとなります。Workloadを見直し、改善し、繰り返していきます。そこには常に機会があるからです。
このアプローチは、パートナー主導で始まりました。 私たちは非常にスリムな状態でスタートし、集中的に支援してくれるパートナーと一緒に始めました。最初は彼らがすべてを行いました。 その後、社内の能力を構築しました。パートナーは私が来る前から、私がチームを構築し始める前からいました。私たちは基礎を固め、自身の体制を構築していきました。社内の能力が備わり始めると、私たちが主導し、パートナーがフォローする形に大きくシフトしました。 準備が整った時点で業務を引き継ぎ、急いで進めることはありませんでした。
そこまで来ると、パートナーの多様化を始めました。 異なる得意分野を持つより多くのパートナーを招き入れ、私たちが成長する間、スケールを支援してもらいました。 現在は継続的な成長モードにあり、これがパートナー多様化の機会なのか、社内能力構築の機会なのか、あるいは能力をブートストラップする状況なのかを、その都度評価しています。移行の最中にチームを構築したため、必要に応じてスキルセットを継続的にリファクタリングすることに非常に慣れています。
パラダイムシフトについてお話ししたいと思います。この特定のケースは、長年データセンターに存在していたワークロードを移行する、とても興味深い事例でした。データセンターでは完全に理にかかなっていたのですが、移行後も同じだと皆が思い込んでいて、同じようにトラブルシューティングできると考えていましたが、実際にはそうではありませんでした。当時、Cloud Engineeringは私のチームの一つで、難しい移行案件を担当していました。私たちの役割は、チームが必要とする時にサポートすることでした。インフラを構築し、彼らが移行を実施し、その後は自走できるようになりました。
分析チームの一つが、ポートフォリオ全体にわたる複雑な数学的計算を行っていました。彼らは早期に移行する必要があったため、最初に移行したワークロードの一つとなりました。本番環境で並行稼働させて結果を検証するのに長い時間が必要だったからです。これらの複雑な計算を実行する中で（私は数学の博士号を持っていないので、正直理解を超えていますが）、彼らは実績のあるオンプレミスのインフラと同じ結果が得られることを確認したかったのですが、実際には異なる結果になっていました。シーケンスが正しいこと、数式が正しいこと、すべてが同じように設定されていることを確認しましたが、奇妙なエラーが発生していました。彼らは、これは計算ソフトウェアを提供しているベンダーの問題だと確信していました。そして、従来のオンプレミスのアプローチで、約6ヶ月かけてそのベンダーとテストを重ね、問題を深く掘り下げようとしました。
期限が迫ってきた時、私たちに支援を求めてきました。この非常に従来型の計算処理主体のワークロードを調査しました。 大規模なインスタンスとSQL Serverの実装が多数ありました。最初は特に目立った問題は見つかりませんでした。まず最初に行ったのは、CloudWatchメトリクスの確認でした。EBSの帯域幅使用量以外には特に目立つものはありませんでした。計算を実行してデータを大量に生成しているので、ドライブに負荷がかかっているのかもしれないと考えました。インスタンスのサイジングを確認したところ、これがチームにとって最初の「なるほど」という瞬間でした。
私たちは、すべてのインスタンスを大きくしてEBSの帯域幅を増やすことを提案しました。チームは私たちが正気を失ったかのように見ましたが、システムの電源を切って入れ直すようなものだと説得しました。この時点で興味深かったのは、彼らが経験していた特定のエラーが予測不可能だったことです。約1週間以内に障害が発生することは分かっていましたが、正確なタイミングは分かりませんでした。私たちは原因を特定できたと思いましたが、それは間違いでした。
この件について、彼らの視点を変えることにしました。 クラウドジャーニーの初期段階のお客様として、彼らにとって理解できないようなことをクラウドで実現することができました。問題を発見し、まずインスタンスサイズを2倍にし、さらにもう一度2倍にしましたが、それでも解決しませんでした。基本的な対応は行いましたが、それらは効果がありませんでした。障害が非常に予測不可能であることが明確になりました。文書化が難しく、いつ発生するかを特定するのも困難でした。数日かかることもありました。これは、彼らが固執していた「一つの変更を加えて結果を待つ」というアプローチでは解決できない問題でした。
そこで私たちは、自分たちのやり方でこれを進めると彼らに伝えました。AWSを使用して、6つの環境を構築し、すべてを複製して、一度にすべてを変更するというアプローチです。彼らはこのコンセプトを最初は理解できませんでしたが、6ヶ月かかっていた問題を私たちがたった2日で特定できたことで理解が深まりました。結果として、特定のCPUタイプでのみ発生する奇妙な浮動小数点計算のエラーだったことが判明しました。彼らは同等の性能を期待して特定のCPUタイプにこだわっていたのです。私たちは一度にすべての可能性を絞り込むことができました。
Infrastructure as CodeやRapid Deploymentについて考えるCloud Nativeの経験が豊富な方々にとって、これは比較的一般的なことでしょう。このようなインフラストラクチャーを展開できることは皆さんご存知だと思います。しかし、そのような考え方に慣れておらず、何ヶ月もの調達プロセスに縛られている従来型のビジネスにとって、これは革新的でした。 私たちは、Network、EBS、CPU、Memory、サイズなどすべての要素を一度にテストすることができ、それは彼らにとって驚くべきことでした。
次にCost Managementについてお話ししたいと思います。特にMigrationの初期段階にある皆さんへの呼びかけですが、AWSチームを頼りにして、積極的に働きかけてください。サイジングを適切に行うのは難しいものです。特にデータセンターから移行する際、Like-for-likeではない場合はなおさらです。オンプレミスでVirtualizationを使用していたり、標準的な調達アイテムとして理解された単一のインフラタイプを使用していた環境から、何百ものInstanceタイプやServiceタイプが存在する世界に移行するのですから。
サイジングは難しく、完璧である必要はありません。これが私たちが伝えようとしたメッセージです。あらゆる作業で大量のデータが生成されているので、サイジングを見直して調整することができます。AWSは試行錯誤を許容してくれますし、コスト最適化を支援する多くのツールを提供しています。 早い段階でCompute Savings Planについて尋ね、常にチームと協力してください。新しいServiceを使用する際や、やり方が分からない場合は、積極的に支援を求めましょう。
私たちは特にCost Management面での自動化に力を入れていました。使用していないInstanceを自動的にシャットダウンしたり、週末に開発環境をオフにしたりするなど、そういった取り組みを重視していました。これらのことを早期に検討することで、後々大きな余裕が生まれます。また、始めるのに早すぎることも遅すぎることもありません。 サイジング、コスト管理、Instanceのオンライン時間などの自動化が適切でない場合は、すぐにでも取り組み始めましょう。いつ導入しても、コスト削減効果が得られます。そして、長期的な経験から言えることですが、追加のテクノロジーへの投資を検討する際に、そのコスト削減効果はますます大きくなっていきます。
今後の計画についてお話ししましょう。 私たちは現在、100%クラウド環境に移行しており、これは私たちにとって重要なマイルストーンです。データセンターからは完全に脱却しましたが、まだ多くの面でデータセンターにいた時のような運用を続けています。
現在、モノリシックなアプリケーションを特定し、循環的なワークロードを解きほぐしていく作業を進めています。古いワークロードを移行された経験がある方なら、私の言っていることがお分かりいただけると思います。私たちは特にサービスの統合に注力しており、データベースは非常に重要な要素です。より拡張性が高く、管理が容易で、よりオープンで、ライセンスコストの少ないデータベースオプションへの移行を目指しています。インフラをできるだけシンプルで効率的なものにし、構成要素を減らし、手作業のプロセスから脱却したいと考えています。どんな小さな改善でも、私たちにとっては大きな成果となります。
それでは、AWSが提供できるツールについて、Vasにバトンタッチしたいと思います。 Justin、素晴らしい取り組みを共有していただき、ありがとうございます。モダナイゼーションとモダンアプリケーションの意味について話す前に、Justinが言及したように、オンプレミス環境からAWSへの移行を無事完了したことをお伝えしたいと思います。移行は言わばゲームの前半戦であり、もう一つの後半戦がモダナイゼーションです。これこそが、これから数ヶ月間のAllspringとAWSの焦点となります。
Microsoftワークロードを専門とするSenior Solutions Architectとして、私はお客様のAWSへの移行とモダナイゼーションをサポートしています。 ここで一歩下がって、モダンアプリケーションとは何かを考えてみましょう。私の考えでは、モダンアプリケーションとはクラウドネイティブなアーキテクチャを使って構築されたものです。AWSに移行したら、マネージドサービスやサーバーレステクノロジー、組み込みのモニタリングなど、AWSサービスを活用する必要があります。Allspringの開発者たちは、すでにLambdaやキューイングサービス、イベント駆動型アーキテクチャなどのサーバーレステクノロジーを活用しています。
最大の課題はモノリシックなアーキテクチャによるデータベースです。データベースのモダナイゼーションを検討する際には、複数の接続されたアプリケーションをどう扱うか、移行に必要な労力、最適なターゲットデータベースプラットフォームの選択などの問題が出てきます。 ここで役立つのがAWS Schema Conversion Toolです。このツールは、データベーススキーマを自動的に変換できるプロジェクトベースのユーザーインターフェースを提供します。Schema Conversion Toolでデータベーススキーマを変換できない場合は、ターゲットプラットフォームへの変換方法についてのガイダンスを提供します。重要なポイントは、Schema Conversion Toolが複数のソースデータベースエンジンをサポートしていることです。Allspringの場合、今日のデモではSQL ServerとOracleに焦点を当て、SQL Serverデータベーススキーマをターゲットデータベースに変換する方法をお見せします。ローカルのSQL Serverを使用する予定です。
AWS SCTによるコード自動変換の実践
SQL Serverに接続していきます。ここで前提として、私のローカルマシンにインストールされているSQL Serverを使用し、同じくローカルマシンにAWS Schema Conversion Toolをインストールする予定です。 AWS Schema Conversion Toolは、デスクトップモードとAWSコンソール上での使用の両方をサポートしています。Schema Conversion Toolをダウンロードする際は、認証情報の入力やログインは不要で、いつでも簡単に使用できるため、データベーススキーマの変換がスムーズに行えます。
ご覧の通り、SQL Serverに接続し、デモ用のデータベースを作成しました。SQL Server Management Studioに接続して、SCT demoというデータベースを作成したところを見ていきましょう。 以前にスポーツの例を使用したことがあるので、スポーツデータを含むテーブルを作成し、10～15個のストアドプロシージャと、いくつかの関数とトリガーも作成しました。Schema Conversion Toolがオープンソースのデータベースエンジンへの移行をどのようにサポートしてくれるか確認していきたいと思います。
先ほど申し上げた通り、Schema Conversion Toolは既にローカルデスクトップにインストール済みです。 ThorとJustinが説明したように、データベース移行はプロジェクトベースのアプローチが必要です。すべてのデータベースを一度に移行することはできないためです。Schema Conversion Toolはプロジェクトベースのユーザーインターフェースを提供しているので、ここで新しいプロジェクトを作成してみましょう。このプロジェクトをSQL Server modernizationと名付けます。 このデータベース移行プロジェクトでは、ご覧の通り5つのステップが含まれています。最初のステップは、ソースデータベースの選択、ソースデータベースへの接続、データベーススキーマの選択、そしてアセスメントレポートの実行です。
ソースエンジンをクリックすると、10～15種類以上の多様なデータベースソースをサポートしていることがわかります。今回のユースケースでは、ここでSQL Serverを選択します。ターゲットエンジンのバージョンについては、ターゲットデータベースがどのようなものになるか、どのデータベースエンジンを使用するかまだ決まっていないため、データベースエンジンの総合的なレポートを確認したいと思います。 2番目のステップは、SQL Serverデータベースへの接続です。SQL Serverの認証情報を入力して接続をテストします。これは単なるSSL警告で、Schema Conversion Toolはソースデータベースへの接続にSSLをサポートしているので、このリスクを受け入れることにします。
ソースのSQL Serverへの接続に成功しました。スキーマの選択は、変換したいデータベースを選ぶだけです。今回の場合はSCT demoなので、他のデータベースのチェックを外してSCT demoだけを選択します。 次のステップでは、アセスメントレポートがどのようなものか確認します。アセスメントレポートの生成にかかる時間は、データベースのサイズとデータベース内のオブジェクトの数によって異なります。 これはデモ用のデータベースなので、数分で完了しました。ここで皆さんにエグゼクティブサマリーに注目していただきたいと思います。
このExecutive Summaryでは、利用可能なターゲットプラットフォームと、各プラットフォームへの移行に必要な労力について、98%や100%といったパーセンテージを示しながら、詳細なレポートを提供しています。各データベースエンジンの詳細なレポートを確認したい場合は、下にスクロールすると、Amazon RDS for MySQLやRDS for PostgreSQLなど、各データベースの詳細なレポートが表示されます。このExecutive Summaryをもう一度見てみると、先ほどの最適なターゲットプラットフォームに関する2つの質問に答えることができます。ご覧の通り、RDS for PostgreSQLとAurora PostgreSQLでは、オブジェクトの98%が自動変換可能か最小限の変更で済み、コードオブジェクトの52%が自動変換可能であることが分かります。
このExecutive Summaryを見ると、先ほどお見せしたアプリケーションにはPostgreSQLが最適な選択肢かもしれないと考えられます。このレポートを保存してチーム内で共有したい場合は、保存オプションが用意されています。チームと共有できるように、すぐにレポートを保存してみましょう。これで、Schema Conversion Toolがターゲットデータベースプラットフォームの決定と、必要な作業量の把握にどのように役立つかが分かりました。最後のステップはターゲットデータベースの選択ですが、この段階までは私たちのターゲットデータベースがどのようなものになるか分からなかったため、現時点ではまだ選択していません。
この会話の始めに、AWS Schema Conversion Tool（AWS SCT）が提供する3つの重要な機能について説明しました。1つ目は、最適なターゲットエンジンの特定と必要な作業量の判断です。使用しないコンポーネントにリソースを費やすべきではありません。2つ目の機能は、AWS SCTによるコードの自動変換についてです。AWS SCTがどのようにコードを自動変換できるか見ていきましょう。
AWS Schema Conversion Toolは仮想ターゲットをサポートしているので、私は仮想ターゲットを使用します。これは、本番環境への移行準備が整うまでリソースをプロビジョニングする必要がないことを意味します。右側でServersセクションを展開すると、すべてのターゲットに「virtual」という接尾辞が付いていることに気付くでしょう。今回のケースでは、データベースをPostgreSQLに移行できることが分かっているので、このProject Wizardを使用してAWS Schema Conversion ToolでデータベーススキーマをPostgreSQLに変換することができます。
これらは同じ接続文字列の設定です。私は再度SQL Serverソースデータベースに接続し、同じSCTデモデータベースを使用します。ご存知の通り、SSLの警告が表示されるので、承認して続行します。これでSQL Server への接続が完了しました。
私はDatabase Administratorとして約6-7年の経験がありますが、本番環境のデータベースに誤って変更を加えてしまい、問題を引き起こす可能性があるという一般的な懸念をよく理解しています。 AWS Schema Conversion Toolは、このような懸念に対応するためにオフラインモードをサポートしています。これにより、誤ってソーステーブルやストアドプロシージャに変更を加えたとしても、実際の本番データベースには影響を与えることがありません。それでは、オフラインモードでのスキーマ変換の方法をご紹介させていただきます。
その前に、まずスキーマをロードしましょう。ご覧の通り、「Loading Schema」というセクションがあります。これによって、データベースのすべてのメタデータやストアドプロシージャなどがロードされます。すぐに確認してみましょう。AWS Schema Conversion Toolで、すべてのテーブルとプロシージャにアクセスできるようになりました。画面上部を見ると、「Disconnect from the server」という緑色のボタンがあります。このボタンをクリックすると、ソースのSQL Serverから切断されます。つまり、ここで行う変更はソースのSQL Serverには影響を与えません。これは非常に便利な機能ですので、このプロジェクトを保存しておきましょう。ソースの本番データベースには影響を与えないので、変更を加えることを心配する必要はありません。
次に、マッピングを作成する必要があります。SQL ServerからPostgreSQLへの変換を行うために、マッピングを作成する次のステップに進みます。「Create Mapping」というセクションがあり、ソースがSQL Server、ターゲットが仮想のAurora PostgreSQLであることが確認できます。変換を実行するには、メインメニューでデータベースを右クリックします。「Create Report」というセクションが表示されますが、すでにレポートを実行済みなので、再度実行する必要はありません。
「Convert Schema」をクリックしてみましょう。先ほど申し上げた通り、変換時間はオブジェクトの数によって異なります。この事例では、ご覧の通り、各ストアドプロシージャを処理しており、数分で完了します。スキーマ変換が完了したので、ストアドプロシージャとテーブルを確認して、PostgreSQL側でどのように表示されているか見てみましょう。ご覧の通り、すべてが移行されています - ソース側にあるのと同じ数のテーブルがターゲット側にも存在し、すべてのストアドプロシージャとトリガーも移行されています。
特定のストアドプロシージャに注目してみましょう。一部のストアドプロシージャには赤い警告マークが付いていますが、警告のないものもあります。例として、Generate_Ticketsストアドプロシージャを確認してみたいと思います。宣言変数セクションの14行目にあるNEWID関数について警告が出ています。SQL Server側ではNEWID関数を使用していますが、この関数はPostgreSQLでは利用できません。なぜ黄色でハイライトされているのか理解するために、もう一度アセスメントを確認してみましょう。先ほど説明した推奨事項を確認するために、アセスメント間を切り替えることができます。アセスメントを見ると、
PostgreSQLの新機能を使用したい場合は、UUID Extensionを使用する必要があることを示しています。Schema Conversion Toolはそのガイダンスを提供し、手順の一部としてそのExtensionを自動的に追加してコードを変更します。PostgreSQLに馴染みがない方にとって、PostgreSQL Extensionは目新しいものかもしれません。ここで小さな詳細に注目していただきたいのですが、456行目と457行目を見ると、SQL Serverでの変数の宣言方法がPostgreSQLとは異なることがわかります。e_idのような変数を宣言する際、PostgreSQL側では構文が異なります。重要なポイントは、Schema Conversion Toolが元のSQL ServerのスキーマをターゲットのPostgreSQLスキーマに自動的に変換してくれるため、あまり手間をかける必要がないということです。AWS SCTが重要な作業を代わりに行ってくれるのです。
AWSのサポート体制と移行・モダナイゼーションの成功への鍵
一部の方にとっては簡単かもしれませんが、複雑に見える場合もあり、私たち全員がサポートを必要としています。ThorとJustinが言及したように、これはプロジェクトではなく旅路であり、この旅路を他の人々と共に歩むのは常に楽しいものです。皆さんの成功を支援できるAWSのチームをいくつかご紹介したいと思います。Account Manager、Technical Account Manager、Solutions Architectを含むAWSアカウントチームは、このMigrationの旅路でお客様を支援することに専念しています。AWSのSpecialistチームには、私のようなSales SpecialistやSpecialist Solutions Architectがおり、特定の分野におけるベストプラクティスをご案内します。AWSには、Migration全体とModernizationの旅路でお客様を支援できる広大なPartner Networkがあります。
もし皆さんの旅路でギャップを埋める必要がある場合は、どうぞAWS Partner Networkにご連絡ください。そして最後になりましたが、AWS Training and Certification - 私の意見では、AWSのサービスやベストプラクティスに慣れ親しみたい場合、Certificationを取得するのが最良の方法です。このセッションから覚えておいていただきたい3つの重要なポイントは、まず第一に、前半をMigrationに、後半をModernizationに充てるなど、成功につながる計画を立てることです。そのような計画があれば、問題を軽減することができます。問題なく成功したMigrationを私は一度も見たことがありません。そのため、事前に計画を立てることで、問題を軽減し、早期に失敗して低コストで失敗することができます。AWSを活用してください - 前払いは不要で、使った分だけお支払いいただく形式です。
仮に直面している問題を克服できない場合でも、AWSが支援させていただくことを忘れないでください。本日は皆様、re:Inventにご参加いただき、お時間を割いていただき、ありがとうございました。セッションのアンケートにご協力いただき、re:Inventの残りをお楽しみください。ご質問がございましたら、私たちは会場の外で待機しており、喜んでお答えさせていただきます。また、re:Invent後にSchema Conversion Toolを試していただきたいと思います - ダウンロードして、SQL ServerやOracleデータベースに接続し、Database Migration Assessment Reportがどのように見えるか確認してください。その情報を私たちと共有していただければ、Modernizationの旅路でお手伝いさせていただきます。重ねて御礼申し上げます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion