re:Invent 2024: TessituraのAWSで実現した.NETモノリス最新化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - The art and culture of modernizing a .NET monolith (XNT202)
この動画では、.NETアプリケーションのAWSへの移行と最新化について、Tessitura Networkの事例を中心に解説しています。Tessituraは芸術文化団体向けのソフトウェアを提供する非営利組織で、Dedicated Hostsを使用したRehostから始め、ECSを活用したReplatform、そして.NET FrameworkからモダンなLinuxベースの.NETへのRefactoringまでの過程を詳しく説明しています。Infrastructure as CodeやAWS CDKの活用により54%のコスト削減を実現し、CrowdStrikeインシデントからの26時間での復旧など、具体的な成果も示されています。また、AWS App2ContainerやAWS Microservice Extractor for .NETなど、.NET最新化のための具体的なツールについても紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
re:Inventセッション：.NETモノリスの最新化への道
月曜の早朝のセッションにもかかわらず、多くの方にお集まりいただき、ありがとうございます。皆様がre:Inventの開始にあたって私たちのセッションを選んでくださったことを光栄に思い、とても楽しみにしています。それでは始めましょう。まず手を挙げていただきたいのですが、.NETアプリケーションの開発に何年も、あるいは何十年も携わっている方はどのくらいいらっしゃいますか？タイトルが.NETモノリスの最新化についてですので、当然といえば当然ですね。では、そのまま手を挙げたままか、もう一度手を挙げていただきたいのですが、そういったアプリケーションの中で、扱いづらい巨大なモノリスになってしまったものがある方は？これも、タイトルを見れば予想できる結果ですね。では、現在AWSへの移行を計画中、もしくはすでに進行中の方は手を挙げてください。
これは、この会場にいらっしゃる皆様だけでなく、この会場の外にいる多くのお客様も直面している状況です。では、こうしたアプリケーションをどのように最新化していけばよいのでしょうか？AWSでワークロードを移行し、改善していく中で、どのようにアプリケーションを最新化すればよいのでしょうか？このセッションでは、そういった側面について詳しく見ていきます。Tessitura Networkの最近の最新化事例を通じて説明していきます。彼らは実際にその道を歩み、今日は皆様に貴重な経験を共有してくれます。XFT202へようこそ。私はMicrosoft WorkloadsのAWSスペシャリストソリューションアーキテクトのJagadeesh Chitikesiです。本日は、Tessitura NetworkからChris SzalajとJeff Oliverのお二人をお迎えできることを光栄に思います。
セッションのアジェンダをご紹介します。まず.NETの歴史を簡単に振り返り、その後、.NETアプリケーションをAWSに移行する際におすすめの移行戦略についてお話しします。続いて、ChrisとJeffが、Tessitura Networkのビジネスクリティカルな.NETモノリシックアプリケーションの移行と最新化の journey についてお話しします。最後に私から、AWSが提供する.NET最新化ツールについていくつかご紹介し、時間が許せば最後にQ&Aの時間を設けたいと思います。時間が足りない場合は、セッション後に会場の外でお話しさせていただければと思います。
.NETの歴史と進化：FrameworkからCoreへ
Microsoftは2002年初頭に.NET Frameworkの最初のバージョンをリリースしました。それ以来、アプリケーション開発のニーズの変化に対応する新機能をリリースし、フレームワークは何度もアップデートされてきました。この間、フレームワークのサイズは指数関数的に大きくなりましたが、Windowsのみのシステムであるという点は変わりませんでした。これが変わったのは、Microsoftがよりモジュラーで、オープンソースで、クロスプラットフォームな.NET Coreをリリースしてからです。これはより高性能で軽量、オープンソースであり、さらに重要なことに、Windows、Linux、macOSなどすべてのプラットフォームで動作します。それ以来、.NET Core、あるいは.NET 5以降はMicrosoftが単に.NETと呼ぶようになりましたが、毎年新しいバージョンがリリースされています。
.NET Frameworkの最後のメジャーバージョンは4.8です。現在もサポートは続いていますが、新機能の開発は行われていません。すべてのイノベーションと最新機能の開発は.NETで行われています。皆さんの多くが.NETのバックグラウンドをお持ちなので、なぜ.NETの歴史の講義を受けているのかと思われるかもしれません。これには主に2つの理由があります。1つ目は、この後の話で「モダン.NET」と言う場合、新しいクロスプラットフォームバージョンの.NETを指しているということです。2つ目は、AWSで選択するプラットフォームやサービスが、アプリケーションが.NET Frameworkベースか、モダン.NETベースかによって直接的に変わってくるということです。
.NETの長く豊かな歴史により、私たちのお客様は、従来の.NET Framework、モダンな.NET、そして様々なタイプのアプリケーションを幅広く保有していることがよくあります。AWSでこれらの.NETワークロードを移行し、改善するオプションについて詳しく見ていきましょう。説明を分かりやすくするために、あなたが現在、SQL Server 2014をデータストアとして使用しているASP.NET MVC 4ベースのWebアプリケーションの開発や保守を担当しているとしましょう。このアプリケーションは巨大なモノリスで、まだ動作はしていますが、パフォーマンス、可用性、デプロイ時間の面で問題が出始めています。このアプリケーションをAWSに移行する計画を立てていますが、同時にこのワークロードをクラウドに適したものにモダナイズするオプションについても知りたいと考えています。
では、移行を計画する前に、この状況で最初に取り組むべきことは何でしょうか？まず優先すべきは、ASP.NET MVCフレームワークとSQL Serverの両方をサポートされているバージョンに移行することですよね？両方ともサポートが終了しているからです。 そのため、セキュリティパッチの提供を継続して受けられるよう、.NETとSQLのサポート対象バージョンへの移行を最優先すべきです。
移行の7つのRは、.NETアプリケーションをAWS に移行する際の推奨戦略を説明しています。今回のトークでは、Rehost、Replatform、Refactorの3つに焦点を当てます。 Rehostは、.NETアプリケーションコードを変更せずに、シンプルなリフト＆シフト移行を実行することです。Replatformでは、AWSに移行した際により多くのメリットを得られるよう、アプリケーションのアーキテクチャに小規模な変更を加えることを検討します。Refactoringでは、AWSへの移行時のメリットを最大化するために、アプリケーションのアーキテクチャを根本的に再設計します。より多くのクラウドネイティブな機能を活用することで、スケーラビリティ、レジリエンス、コスト最適化の面でメリットを最大限に引き出します。重要なのは、これらのアプローチの1つだけを選んでそれに固執する必要はないということです。後ほどChrisとJeffから、特定のビジネスニーズを解決するためにハイブリッドアプローチ、つまり複数のアプローチを選択した事例をお聞きいただけます。
AWSにおける.NET移行戦略：Rehost、Replatform、Refactor
Rehostの場合、デプロイに必要なAWSインフラストラクチャを選択します。これには、AWSリージョンとアベイラビリティーゾーンの選択、IAMとSQL Serverを備えたAmazon EC2インスタンスの作成と設定、そしてアプリケーションとデータベースのこれらのインスタンスへの移行が含まれます。考えてみると、このようなシンプルなRehostでも、コスト、セキュリティ、管理の面で大きなメリットが得られます。また、.NETとSQL Serverのワークロード向けにWindowsがサポートされているインスタンスタイプが300種類以上あるため、ワークロードに最適なものを選択する余地が十分にあります。
可用性と耐障害性をさらに向上させるには、デプロイを同じAWSリージョン内の別のアベイラビリティーゾーンに複製し、Auto Scaling groupとElastic Load Balancerを作成するだけです。 SQL Serverについても同様です。ログシッピング、ミラーリング、Always Onなどの SQL Serverネイティブのクラスタリング技術を使用してマルチAZ SQL Serverを作成するだけで、数分で可用性と耐障害性を大幅に向上させることができます。
これらすべてのメリットを、プラットフォームのメンテナンスが一切不要な形で実現する - それこそがAWSのマネージドサービスがご提供できることです。.NET FrameworkアプリケーションをElastic Beanstalkのようなサービスに移行することを想像してみてください。これは、WindowsプラットフォームでのNET Frameworkをサポートする完全マネージド型のサービスで、プロビジョニングとロードバランシングを処理し、組み込みのモニタリング機能も備えています。このように、シンプルなRehostモデルでAWSに移行するだけで、耐障害性、自動スケーリング、コスト効率性を実現でき、プラットフォームのメンテナンスではなく、実際のイノベーションに貴重な時間を費やすことができるようになります。
Replatformのオプションについて見ていきましょう。データベースをAWSの完全マネージド型データベースサービスであるAmazon Relational Database Service（略してRDS）に移行するというオプションがあります。SQL ServerはRDSでサポートされているデータベースエンジンの1つです。RDSに移行することで、自動メンテナンスやバックアップに費やしていた多くの時間を解放することができます。ボタン1つで高可用性を実現でき、プラットフォームはストレージと計算能力のスケーラビリティを提供します。
Windowsに依存する.NET FrameworkアプリケーションをReplatformする、もう1つの一般的な方法は、Windowsコンテナに移行することです。MicrosoftはWindows Server 2016を導入した際に、Dockerと協力してWindowsの開発者向けにコンテナを提供しました。現在、Microsoftは.NET Frameworkアプリケーション向けに複数のベースイメージを提供しており、Server Coreが完全な.NET Frameworkアプリケーションをサポートするベースイメージとして最も人気があります。Nano ServerはサイズがServer Coreと比べて数メガバイト小さい最軽量のイメージですが、現在はモダン.NETのみをサポートしており、.NET Frameworkはサポートしていません。
コンテナ化が完了すれば、.NET Frameworkアプリケーションをホストし、スケールでのコンテナプラットフォームの管理・メンテナンスの手間を省くAWSのマネージドコンテナサービスのいずれかに移行できます。AWSで最も人気のあるマネージドコンテナプラットフォームには、Amazon Elastic Container Service（ECS）やAmazon Elastic Kubernetes Service（EKS）があります。ECSとEKSの両方が、.NET FrameworkアプリケーションをサポートするWindowsノードを持つクラスターをサポートしています。このセッションの後半では、ChrisとJeffから、なぜECSを選択したのか、そしてその選択からどのようなメリットを得たのかについてお話を伺います。
クラスターのノードを構成する自己管理型のAmazon EC2インスタンスを、Windows Fargateで置き換えるオプションもあります。Fargateはタスクを実行するためのサーバーレスな方法で、コンテナベースのアプリケーションに必要な計算能力とメモリを指定するだけで済みます。Fargateでは、現在のところWindowsのサポートはECSに限定されており、EKSではそのサポートは利用できません。
アプリケーションコードにわずかな変更を加えることで、コンテナに移行してAWSでさらなるコスト削減と最適化を実現できました。一貫性と移植性というコンテナがもたらすメリットを活用し始め、AWS Fargateのようなサービスも使い始めています。これでAWSを完全に最適化できたと言えるでしょうか？答えは「いいえ」です。 このビジネス要件に影響を与えていない場合、「いいえ」という答えで満足される方もいるかもしれません。しかし、AWSが提供するすべての機能を真に活用するためには、リファクタリングが不可欠となります。確かに比較的多くの労力が必要になりますが、その結果としてAWS向けに完全にカスタマイズされたアプリケーションを手に入れることができます。
最新の.NETへの移行：メリットと課題
リファクタリングは、Windows専用の.NET Frameworkアプリケーションから、Linuxやその他のプラットフォームで動作する最新の.NETへの移行から始まります。 これにより、最適化のための新たな可能性が数多く開かれることになります。 より安価で高速なLinuxインスタンスで実行できることに加えて、最新の.NETは高性能で効率的な設計を基本としています。またオープンソースであることから、一般的に開発サイクルが速くなります。さらに、コンテナベースのデプロイメントを使用したマイクロサービスやイベントベースのアーキテクチャによるクラウドネイティブな開発にも適しています。Microsoftは.NETに最も多くの時間を投資しており、これが.NETベース開発の未来であると述べています。
アプリケーションの種類によって、 .NET Frameworkベースのアプリケーションから最新の.NETアプリケーションへの移行に必要な労力は異なります。これは、.NET Frameworkベースの一部のアプリケーションタイプには、最新の.NETに直接対応するものがないためです。いくつかのWebアプリケーションタイプについて、その変換がどのようなものになるか見てみましょう。ASP.NET MVCとASP.NET Web APIの場合、 推奨されるアプローチは、MVCとWeb APIに含まれていた以前は別々の機能を統合したASP.NET Core on 最新の.NETに移行することです。
ASP.NET Web Formsの場合、.NETには直接の対応物がありません。推奨される方法は、ASP.NET Core MVCまたはシングルページアプリケーションへの完全なリファクタリングです。ASP.NET Web FormsのMVCとWeb APIに含まれていた個別の機能は、.NETには直接対応するものがありません。CoreWebFormsというオープンソースの取り組みがありますが、現時点ではASP.NET Web Formsと比較してすべての機能をサポートしているわけではありません。
では、最新の.NETへの移行はどのようなメリットをもたらすのでしょうか？ Windowsベースのインスタンスと比較して大幅に安価なLinuxベースのインスタンスでアプリケーションをホストする機会が得られます。また、最新の.NETはARMベースのプロセッサでより高いパフォーマンスを発揮するため、AWS GravitonというAWSのARMベースプロセッサを使用し始める機会も得られます。社内のベンチマークによると、最新のアプリケーションをGravitonプロセッサでホストした場合、x86相当と比較して64%優れた価格性能比を実現し、同時に60%少ないエネルギーで動作することが確認されています。
モダンな.NETを採用することで、AWSのようなプラットフォームの選択肢も広がります。 Fargateを通じてLinuxコンテナの利用が可能になります。 AWS App Runnerは、コードからフルスケールのコンテナデプロイメントへの移行を実現する最も簡単な方法です。統合されたコンテナビルド機能により、コードを受け取り、コンテナをビルドし、アプリケーションを実行するための完全な環境を構築してくれます。AWS Lambdaは最も人気の高いサーバーレスコンピューティングサービスで、AWSの様々なサービスと連携してイベント駆動型アーキテクチャを構築できます。また、Linuxコンテナの使用も可能になり、Windowsコンテナと比べて大幅に軽量なため、コンテナが持つ他のメリットとも相性が良いのです。
モダンな.NETでは、 WindowsタスクをLinuxタスクに置き換え、Gravitonコンピュートの利用を開始できます。また、多くのお客様が採用しているアプローチとして、 マイクロサービスベースのアーキテクチャへの移行があります。これには、独立したスケーリング、障害の分離、デプロイ時間、開発面での数多くのメリットがあります。適切なユースケースであれば、マイクロサービスへの移行に必要な労力は十分に価値があります。
マイクロサービスへの段階的移行：Strangler Figパターン
この移行には主に2つのアプローチがあります。1つ目はBig Bangアプローチで、これはモノリスを一度の大規模な取り組みで完全に変換する方法です。ただし、複雑さに起因するリスクが高いため、通常はお勧めしません。より安全で現実的なアプローチは、段階的に移行を進めていく方法です。これによりリスクを大幅に軽減しながら、段階的な価値を提供できます。このアプローチをStrangler Figパターンと呼んでいます。
Stranglerパターンの実際の動きを見てみましょう。まず、モノリシックなデータベースと通信する.NETモノリスがあります。アプリケーションの前にプロキシまたはロードバランサーを配置し、その後、モノリスの周辺部から小さなマイクロサービスを切り出し、プロキシと新しく作成したサービス、そして残りのモノリス間の通信を確立します。このプロセスを続け、最終的にモノリス全体を新しく作成したマイクロサービスに置き換えていきます。
AWSでの具体的な例を見てみましょう。Elastic Beanstalk上の.NET Frameworkアプリケーションがあり、プロキシを導入し、静的コンテンツをAmazon S3に移行します。その後、新しいマイクロサービスの切り出しを開始し、プラットフォームを選択し、関連するデータをAWSの目的別データベースに移行します。そして、プロキシを使用してルートを調整しながら、最終的にモノリス全体を新しく作成したサービスに置き換えていきます。
この取り組みにおいて、皆様は決して一人ではありません。私たちはチームのスキルアップを支援し、Professional Servicesを通じて実践的なサポートも提供しています。また、Experience-Based Accelerationのようなエンタープライズソリューションで、皆様の取り組みを効果的に推進することができます。このように、複数のオプションをご用意していることがおわかりいただけたと思います。どのオプションを選択するかは、解決しようとしているビジネス課題の性質によって決まります。サポートオプションの概要は以上です。では次に、具体的な実装経験についてお話しいただく次のスピーカーに移りたいと思います。
Tessitura Networkの紹介：芸術文化のためのソフトウェア企業
ありがとうございます、Jagadeeshさん。皆様、こんにちは。私はTessitura Networkのソフトウェアエンジニアリング担当副社長のChris Szalajです。同僚のJeff Oliverと共に、本日は私たちのTessitura Networkソフトウェアにおける.NET現代化とクラウド最適化の取り組みについてお話しできることを嬉しく思います。まず始めに、素晴らしい組織であるTessitura Networkについて少し背景をご説明させていただきます。そして、Jeffと私が今日このステージに立つことになった経緯についてお話しします。
次に、Rehostの取り組みについてお話しします。Jagadeeshが説明したように、いくつかの異なるフェーズがありますが、私たちが選択した3つのフェーズについて、まずRehostから説明していきます。その後、Jeffが続けてReplatformについて、そして現時点での成功の秘訣だと考えていることについてお話しします。私たちの取り組みはまだ完了していません - 計画全体の3分の1程度まで来たところです。今後の展開についてお話しし、素晴らしいデータとケーススタディで締めくくりたいと思います。
まず、Tessituraは1990年代後半にMetropolitan Operaで誕生しました。当時、オペラハウスにはチケット販売システムと寄付者からの献金管理システムが別々に存在していました。顧客の統合的な視点がなく、誰がチケットを購入しながら寄付もしているのか、チケットの購入が寄付につながっているのかなどがわかりませんでした。彼らは理事会に相談し、Metropolitan Operaの理事会は1990年代後半に、カスタムソフトウェアを構築するために500万ドルの投資を承認しました。これは芸術分野に特化して作られ、Tessituraが誕生したのです。
2001年までに、Metropolitan Operaの取り組みに注目し、このソフトウェアの使用に強い関心を示した6つの組織がありました。Metropolitan Operaは、ソフトウェア開発はオペラカンパニーの本来の専門分野ではないと判断し、これを独立した組織として分離することを決定しました。プラットフォームとしてのTessituraは、企業としてのTessituraとなり、Tessitura Networkが誕生しました。Tessituraは、芸術文化の事業の成功のために構築され、専念する初めての非営利ソフトウェア企業であり、芸術文化組織によって運営されています。
現在に目を向けると、私たちのネットワークには803の芸術文化団体が参加しています。活動分野は3つのセクターにまたがっており、まず舞台芸術分野があります - これには劇場、オペラハウス、バレエ団、オーケストラなどの会場や団体が含まれます - そして美術館、さらには動物園や水族館、史跡などのアトラクション施設です。私たちは3大陸10カ国で事業を展開しており、Kansas City Repertory Theaterのような地域の組織から、Metropolitan Opera、Royal Opera House、Sydney Opera House、Carnegie Hall、イギリスのRoyal Collectionなど、世界で最も規模が大きく権威ある芸術団体まで、幅広い組織にサービスを提供しています。
Tessituraのクラウド移行journey：チームカルチャーと戦略
Blackbaud、Ticketmaster、Salesforceなど、私たちの競合他社についてご存知かもしれません。Tessituraの特徴的な点の1つは、メンバー構成にあります。私たちは501(c)(3)の非営利組織で、サービスを提供している芸術団体のリーダーたちで構成される理事会によって運営されています。実際、本日は私たちの組織の1つであるPittsburgh Cultural Trustが聴衆の中におり、CEOのDan Hofferは私たちの理事会のメンバーです。私たちは協同組合で、ユーザーが完全に所有し運営しています。珍しいことに、ユーザーが実際に私たちの上司なのです。
Tessituraでの私の物語は、約9年前に始まりました。企業としての急速な成功により、既存の技術スタックと展開モデルではすぐに対応できなくなっていました。問題が発生してから対処するのではなく、上流で問題を解決し、インフラを本当の意味で近代化することを考える必要がありました。これは著者のDan Heathが著書「Upstream」で「上流思考」と呼んでいるものです。まだ読んでいない方は、素晴らしい本なのでぜひ読んでみてください。Digital Transformationと、Jeffと私が今日お話しする内容は、問題の後始末が上手くなることに焦点を当てるのではなく、上流で問題を解決する方法を考えることの典型的な例です。
そして、Jeffが彼のTessituraでの経験について少しお話しします。皆さん、こんにちは。Jeff Oliverと申します。Tessituraのホスティングサービス担当副社長を務めています。本日は皆様にお時間をいただき、ありがとうございます。私のTessituraでの旅は、2020年12月、約4年前に始まりました。長年の友人であり同僚が、あるコンサルティングプロジェクトから離れる際に、私が興味を持つかもしれないと考えたのです。彼のプロジェクトの説明を聞いた後、私は「John、ちょっと確認させてください。3大陸600社の顧客を抱える従来型のコロケーションVMwareアーキテクチャを、AWSの5つのリージョンに移行するということですか？
ターゲットアーキテクチャは100% Microsoftのワークロードで、Dedicated Hostsで実行され、主にCitrixを通じて提供される。そして、コロケーション費用の1年分を節約するために、10ヶ月以内に移行を完了しなければならない。」と言いました。彼は「そうだけど、どう思う？」と言いました。私は「それはかなりコストがかかりそうですね。経済的な問題が発生する前に、よりクラウドネイティブなアーキテクチャに再設計するのにどのくらいの時間がかかりますか？」と尋ねました。彼は私を見て、「抑制するのに約3年、持続可能にするのにさらに2-3年かかるだろう」と言いました。「興味ある？」そして、私は今ここにいます。4年目になりますが、実際の移行は予定通りに完了し、コスト比率も正しい方向に向かい始めており、それ以来、会社は約45%の成長を維持しています。
プレゼンテーションのタイトルが「.NET Monolithのモダナイゼーションのアートとカルチャー」ということなので、 私たちの.NET Monolithについてお話ししましょう。当初から、私たちのプラットフォームは従来型のクライアントサーバーモデルのアプリケーションでした。 クライアントアプリケーションは、従来の.NET Frameworkを使用したWindowsデスクトップアプリケーションで、PowerBuilderというプラットフォームを使って構築されていました。PowerBuilderをご存知の方は手を挙げていただけますか？おお、皆さん！こんなにいらっしゃるとは思いませんでした。本当に驚きです。
このクライアントアプリケーションは、これまでMicrosoft SQLのシングルテナントデータベースに直接接続する形で運用されてきました。このクライアントアプリケーションは、チケット販売オフィスのスタッフやファンドレイジングの専門家などが実際の業務で使用するものです。 また、独自のWebサイトを構築したくない会員組織向けにE-commerceアプリケーションも提供しています。私たちのAPIを使用して、ホワイトラベルアプリケーションを利用することで、オンラインでのチケット販売やイベント表示、寄付金の収集などが可能です。 これも当初から.NET FrameworkのWeb Formsを使用したアプリケーションで、.NET Framework APIを介してSQLデータベースと通信を行っています。
さらに、データインサイトやダッシュボード用のBusiness Intelligenceアプリケーションも提供しており、これをクライアントアプリケーションに組み込んで、ユーザーがBIレポートを作成できるようにしています。 このアプリケーションには、サードパーティプロバイダーが提供する独自のデータウェアハウスがバックエンドにあり、現在は私たちが自社でホストしています。 そして、これらのコンポーネントはすべて、アプリケーションのメインデータレイヤーとしてMicrosoft SQLデータベースに接続しています。
2016年、私たちのDallasデータセンターでは、このような簡略化されたアーキテクチャを採用していました。コンポーネントはすべて、現在もほとんどがシングルテナントです。各会員はTessituraアプリケーションの独自のデプロイメントを持っていますが、インフラストラクチャは主に共有されています。つまり、複数の会員が1つのインフラストラクチャスタック（データベースホスト、APIホストなど）を共有しているのです。このアーキテクチャには高可用性オプションがなく、会員は本番データベースのインスタンスを1つしか持つことができませんでした。このようなWindowsのクライアントサーバーモデルは、まさにその時代のアーキテクチャでした。2000年代初頭に始めた当時は、これが最先端の堅牢なアーキテクチャでした。20年間、私たちを支え続け、今でも多くの面で役立っています。しかし今日では、より良い方法があります。そのため、私たちはこのモダナイゼーションの旅に出たのです。
変更を最小限に抑え、学習を最大化し、安定性を確保するため、先ほどJagadeeshが説明していたマルチステッププロセスを選択しました。これは、ご覧いただいたStrangler figパターンとほぼ一致するものです。まずRehostから始めて、次にReplatformingとマイクロサービスの構築に進み、最後にRefactoringを行うという流れです。ご覧の通り、プロセスの初期段階で少し順序を変えて、様々な理由でRefactoringを随時実施しました。なぜ私たちがこれまでの過程で特定のタイミングでRefactoringを選択したのか、その理由についてご説明します。
まず、Dallasのデータセンターから Amazon商用クラウドへのRehostingについてお話しします。これは標準的なLift and Shiftの作業でした。オンプレミスのソリューションをクラウドに移行する際、単純にクラウドに配置するだけであれば、アーキテクチャ上の変更はほとんど、あるいはまったく必要ありません。クラウドに最適化するために途中で多くの変更を加えると、タイムラインが大幅に遅れ、クラウド移行後に得られるはずの価値の実現も遅れてしまいます。そのため、私たちは移行時のアーキテクチャの変更を最小限に抑えることにしました。これにより、チームやメンバーに過度な変更を強いることなく、タイムリーかつ手頃なコストで完了することができました。これが可能だったのは、2つの重要な要素があったからです。1つ目は、AmazonのDedicated Hostsというサービスでした。
AWSへの移行：ReホストからReプラットフォームへ
これにより、Windows License Mobilityを活用して、ほぼコストニュートラルな形でクラウドへの移行が可能になりました。当時のMicrosoftのライセンスルールのおかげで、2019年10月1日以前に購入したオンプレミスのWindows Serverライセンスを、AWSのDedicated Hosts環境で使用することができました。
これが2021年のRehosting後のアーキテクチャです。Windows License Mobilityを活用するため、コンピュート処理にはDedicated Hostsを使用しました。Amazon商用クラウドへの移行時にほとんど変更を加えなかったLift and Shiftだったため、アーキテクチャは非常に似通ったものになっています。ただし、Dedicated Hostsには課題もありました。Microsoftのライセンス制限により、2019年10月以降、Dedicated Hosts環境用の新規ライセンスの購入や既存ライセンスのアップグレードができなくなるということです。これは成長にとって良くありません。すでにお話ししたように、私たちは急速な成長期にあったため、これが問題になることは分かっていました。これが、私たちが「Dedicated Hostsのパズル」と呼んでいる課題です。
でも、同情しないでください - 私たちはこれらすべてを承知の上で進めていました。この問題がいずれ発生することを理解していましたし、解決策を見つけなければならないことも分かっていました。その解決策が、今日の議論で取り上げるRefactoringです。商用クラウドが提供するすべてのメリット - スケーラビリティ、最適化されたリソース利用、開発能力の向上など、私たちが知っているような利点を活用し始めるためには、このRefactoringが必要でした。Dedicated Hostsではこれらのメリットを活用することができません。これは単に、タイムリーでコストニュートラルな方法でポイントAからポイントBに移行するためのツールに過ぎませんでした。
その過程で、軽いRefactoringも実施しました。なぜなら、チームが将来Amazon商用クラウドで使用する技術について、事前に学習を始めることが非常に重要だと考えたからです。これには、AWS Elastic Beanstalkの使用、動的デプロイメントコード、Infrastructure as Code、Amazon DynamoDBやドキュメントベースのストレージなどの技術の習得が含まれていました。リスクが低い段階で、チームが安全に学習できる機会を早期に提供することは非常に重要でした。そのおかげで、コスト面での理由からRefactoringが本当に必要になった時点で、チームはすでに使用するツールを理解しており、それらの技術を学ぶために数ヶ月の中断を強いられることなく、問題解決の機会を見出すことができました。
もちろん、失敗なくして学びはありません。私たちが経験した躓きについてお話ししたいと思います。というのも、試行錯誤なくして学びは得られないからです。主に2つの分野で課題がありました：データ管理と、デプロイメントです。先ほど申し上げたように、私たちはMicrosoft SQLを使用している組織なのですが、チームが理解を深めるのに時間を要した分野の1つがAmazon DynamoDBでした。 Microsoft SQLのリレーショナルデータベース環境から、DynamoDBのスキーマレスな扱い方への移行は、長年構造化されたリレーショナルな考え方で仕事をしてきたエンジニアチームにとって、大きな発想の転換が必要でした。チームはプロビジョニングや、データを適切にインデックス化するための構造化の方法について、試行錯誤しながら理解を深めていきました。この実験的な取り組みによって、DynamoDBが提供する価値を活用できるようになり、新しいワークロードでDynamoDBの利用を拡大し続けています。
現在、既存のワークロードをDynamoDBに置き換えているわけではありません。新しいデータストレージのニーズがDynamoDBの特性と合致する場合に、DynamoDBを採用して問題解決を図っています。 また、私たちはAmazonのData Labというプログラムにも参加しました。このプログラムは現在は提供されていませんが、当時はMicrosoft SQLからPostgreSQLなどのオープンソースデータベース技術へのワークロード移行を支援することを目的としていました。私たちの組織では約8ヶ月ごとに、Microsoft SQLを離れてオープンソースデータベースに移行すべきではないか、という議論が持ち上がります。これまで具体的な行動を起こしたことはありませんでしたが、このData Labは私たちにとって良い機会でした。しかし、その週のうちにすぐ、これが想像以上に困難な取り組みになることが分かりました。長年の使用により、私たちはMicrosoft SQL Serverのかなり深い、複雑な機能を使用しており、その結果、提供されている自動化ツールでは迅速な移行を実現することができませんでした。組織によって状況は異なると思いますので、これらのツールが機能しないとは言い切れません。私たちの場合は、Microsoft SQL Serverの使用方法が特殊だったため上手くいきませんでしたが、皆さんの場合はうまく機能するかもしれません。Microsoft SQLからの移行を検討されている方には、これらのツールを試してみることをお勧めします。この警告サインは私たちにとってはうまくいきませんでしたが、将来的に移行を決断する際には、より慎重なアプローチが必要だということを学びました。
後ほどお話しする通り、実は私たちは現在、他の課題を解決するためにMicrosoftテクノロジーへの投資を倍増させています。
私たちにとって2つ目の学びの分野は、Infrastructure as Codeの活用でした。 AWS CloudFormationから始めて、チームはインフラストラクチャをコード化し、デプロイするアプリケーションと共にリポジトリに保存するようになりました。この場合、ストレージにDynamoDBを使用したElastic Beanstalkアプリケーションを使用していました。Auto Scalingを使用する中で、チームは自然な流れでC#を使用したAWS Cloud Development Kit（CDK）へと進化していきました。これは私たちのチームにとって、デプロイメントコードを扱う次のステップとして非常に自然な選択でした。現在、私たちはすべてのインフラストラクチャコードのデプロイメントにCDKを使用しており、長年C#を使用してきたオブジェクト指向の開発者チームにとって、とても相性の良いツールとなっています。
Rehostの後、Replatformingに取り組む時が来ました。ここで、コンテナ化やWindowsからLinuxへの移行について話を進めていきます。Replatformingを支援するため、2つのコンポーネントを従来の.NETから最新の.NETにリファクタリングしました。これにより、Windowsコンテナを中間ステップとして使用することなく、直接Linuxコンテナでの運用に移行することができました。これは私たちにとって良い判断であり、スムーズに進めることができました。ホスティングエンジニアたちは、チーム内にLinuxの経験が少なかったため、直接Linuxに移行することに懸念を示していました。しかし、AWSで利用可能な技術の選択肢のおかげで、Linuxプラットフォームの学習や、Linuxを使用するネットワークコンポーネントの管理に関する複雑さの多くが抽象化されていました。
Lift and Shiftが完了し、次のステップを決める必要がありました。Jeffと私は協力して、Dedicated Hostから脱却し、システムコンポーネントの一部をリファクタリングするためのロードマップを作成しました。最初のステップは、Windowsアプリケーション環境から脱却するため、クライアントアプリケーションをWebインターフェースに移行することです。このWindowsクライアントからWebクライアントへの移行により、現在プラットフォームをホスティングしているユーザーにWindowsクライアントを提供するために使用しているCitrixから脱却することができます。
私たちは創業以来、メンバー組織に対して、プラットフォームを完全に自社でホストする選択肢を提供してきました。2009年には、メンバー向けにホスティングサービスを導入し、私たちがプラットフォームをホストできるようにしました。現在、メンバーの約83%が私たちのホスティングを利用しており、約17%が利用していません。Webベースのクライアントに移行することで、Citrixホストを廃止してコストを削減できます。また、Citrixは私たちのネットワークの中で最も脆弱なコンポーネントの1つであり、多くのサポートチケットの原因となっていますが、これも解消されます。
次に、いくつかのサーバーコンポーネントをコンテナ化し、Windows .NET Frameworkアプリケーションから、最新の.NETを使用したLinuxコンテナへとリファクタリングとリプラットフォーミングを行っています。これにより、Windowsのライセンスコストの課題に対処し、eコマースとAPIアプリケーションをLinuxコンテナに移行します。この移行により、自動スケーリングを通じたコスト削減、オーバープロビジョニングの削減、システム容量とパフォーマンスの向上が実現し、Dedicated Hostのフリートを廃止できます。Amazon Elastic Container Service（ECS）のおかげで、Linuxへの移行は容易になりました。ECSは、コスト、複雑さ、抽象化の面で私たちにとって最適なバランスを提供してくれました。Amazon Elastic Kubernetes Service（EKS）やAWS Fargateも検討しましたが、ECSが私たちのニーズに最適な中間的な選択肢でした。
次に、SQL Server Enterpriseを導入します。これは主に、私たちの目標とする復旧時間を達成するためです。また、すべてのメンバーに対してシングルテナントのデプロイメントを維持しながら、それらをホストするマルチテナントインフラストラクチャを構築できます。これにより、同じSQLホスト上で複数のメンバーデータベースを運用することが可能になります。
最後に、分析アプリケーションをプロバイダーのマネージドサービスクラウドに移行します。このプロジェクトの一環として、ベンダーが提供する独自のデータウェアハウスをAmazon RedshiftとAmazonのData Migration Service（DMS）に置き換えています。初期のテストでは、ベンダーが提供する独自のデータベース技術からDMSとRedshiftに移行することで、パフォーマンスとコストの両面で大きな改善が見込まれています。これらの取り組みはすべて、よりクラウド最適化された状態を実現し、Dedicated Hostsの課題から脱却するためのものです。
Amazon ECSへの移行：コスト削減とパフォーマンス向上の実現
それでは、いくつかのケーススタディについて、Jeffに説明を引き継ぎたいと思います。ありがとう、Chris。ここまでで皆さんもお気づきかと思いますが、私たちのAWSへの移行は、先ほどJagadeeshが説明した3つのRを組み合わせたものでした。まず、最小限の変更でプラットフォームをRehostしました。そして、機会を見てモノリスをいくつかのMicroservicesにRefactorしました。このアプローチにより、初期の成功とAWSツールセットの貴重な経験を得ることができ、これが次のスライドでお話しするプラットフォームの進化を後押ししています。
この journey で最も重要なのは、私たちのチームです。チームカルチャーは重要であり、私たちは3つのコアバリューがクラウドへの移行に大きく貢献したと考えています。これらの価値観は規範的なものではありませんが、皆さんの共感を得られるかもしれません。1つ目はレジリエンスです。チームには変化や混乱に対応できる力が必要です。メンバーの入れ替わり、チームの再編成、優先順位の変更などが起こります。これに対応するため、私たちはクロストレーニングを行い、知識を共有し、オンコール対応を分散させ、ワークライフバランスを推進しています。レジリエントなチームがレジリエントなシステムを作り出すと信じているからです。
Tessituraでは心理的安全性を重視しています。チームメンバーには、ありのままの自分でいられる環境が必要です。私たちは正直さとリスクテイクを必要とし、優秀な人材として採用したメンバーたちの質問、アイデア、懸念に耳を傾ける必要があります。それ以外にどうやって改善できるでしょうか。イノベーションには学習と実験が不可欠です。Tessituraでは、「見て、やって、教える」というアプローチで学習を進めています。チームメンバーは労働時間の最大10%を関連する学習活動に費やすことができます。これにより、3年未満でAWS認定エンジニアの割合を10%未満から60%以上に増やすことができました。私たちは日々のAWS業務でこれらのスキルを活用し、週次セミナーや対面ミーティングでの専用の指導時間を通じて、教え合うことを推奨しています。
これらの価値観を実践に移しています。これらのコアバリューが私たちの変革に貢献した具体的な方法をいくつかご紹介します。まず、リーダーシップレベルでの幅広い理解と、チーム内での深い理解という、T字型のアラインメントを構築します。チームから始めて、戦略的プロジェクトと日常業務への影響を結びつけ、その課題を受け止める余地を与えます。そこから組織全体でアラインメントを構築します。なぜなら、このアラインメントがなければ、これらのプロジェクトを実行することはできないからです。次に、各チームの自律性を高め、チームの結束を強めるために、適切な場所に配置されたエバンジェリストの影響力を過小評価しないでください。内部から指導とサポートができる経験豊富な人材が必要でした。
長年の技術的負債を返済するという観点からの変革には苦労しました。技術的負債は、実際のコストや具体的なリターンをもたらす問題というよりも、ソフトウェアの嫌な部分を指す言葉として武器化されていました。すべての技術的負債を解消することに焦点を当てるのではなく、コスト最適化と運用の卓越性に意味のある影響を与える戦略的投資を行うという視点に変える必要がありました。現状に悪い感情を持つのをやめ、これから向かう先のメリットに焦点を当て始める必要がありました。実際、この投資マインドセットこそが、先ほどChrisが触れた4つの主要なReplatform計画の柱を浮き彫りにしたのです。私たちは一丸となって、プラットフォームの拡張に伴う効率性を向上させるための最適化に焦点を当て、AWSサービス（昨日の請求書によると71のサービス）が私たちの取り組みを支援してくれています。
この最適化は一般的に3つのカテゴリーに分類されます。まず、 CloudFormation、CDK、X-Rayなどのサービスを使用して、管理対象のアセットをコード化することに努めています。 次に、Service Catalog、Image Builder、CodeDeploy、Systems Managerなどのサービスを活用して、クリック操作による作業を自動化により削減しています。 そして最後に、Savings Plans、データエクスポート、Trusted Advisor、QuickSightなどのサービスを活用して、支出を綿密にモニタリングし最適化しています。私たちにとって最適化とは、スタッフの時間の価値を最大化し、メンバーあたりのユニットコストを削減することで、その時間とクラウドのコスト削減分を再投資できるようにすることです。非営利組織として、これが私たちのビジネスとメンバーの持続可能性を実現する方法なのです。
私たちのプラットフォームの一部にライブイベントのチケット販売があります。メンバー組織が「Wicked」や「Hamilton」の全国ツアーのような高需要のチケット発売を行う際には、その需要に応えるために迅速なスケールアップが必要になることがあります。 Dedicated Hostアーキテクチャを採用していたため、複雑なオーケストレーションと計画なしには水平スケーリングができませんでした。共有インフラでトラフィックスパイク時に対応できるよう、より高い容量を持つホストをプロビジョニングしていました。これにより、あるメンバーがチケット発売で不釣り合いな量のリソースを使用し、他のメンバーサイトがリソース不足に陥るという、ノイジーネイバーの問題も発生していました。
さらに、メンバーによって日常的なリソース使用量が異なるため、画一的なソリューションは最適ではありませんでした。 私たちは各メンバーにEコマースプラットフォームの本番環境とテスト環境を提供していますが、プラットフォーム全体で見ると、 これらのテストワークロードの使用率は10%以下で稼働しています。これらの状況を総合すると、Dedicated Hostを使用することで大幅な過剰プロビジョニングが発生していたことがわかります。そこで、私たちはEコマースワークロードの管理にECSを導入し、将来的には他のワークロードにも拡大していく計画です。
この移行を実行するにあたり、私たちだけでは対応できないことを認識していました。チームの能力を補強し、エンジニアのスキルを向上させ、チーム間の協力の仕方を見直すために、パートナーシップを活用する必要がありました。 ほとんどの方がConway's Lawをご存知だと思いますが、簡単に言えば、ソフトウェアの構造はそれを構築したチームの構造を反映するというものです。私たちも例外ではありませんでした。2009年にホスティングサービスを導入して以来、ソフトウェアエンジニアリングチームとホスティングエンジニアリングチームを分けていました。基本的に、ソフトウェアチームがソフトウェアを構築し、ホスティングチームがデプロイメントを管理していたのです。
私たちはそのモデルを超えて成長し、両者を分離することで生じる問題を経験し始めていました。AWSチームから、Experience Based Accelerator（EBA）というプログラムの提案を受けました。EBAプログラムは、プラットフォームコンポーネントの再設計だけでなく、チームの協力方法も進化させたいと考えるチームのために特別に設計されたものです。私たちのプログラムは6週間でした。インフラストラクチャアズコードで再利用可能なコンテナデプロイメントを構築し、Asia Pacificリージョンの単一のメンバーサイトにそのインフラストラクチャを正常にデプロイすることを目指しました。
私たちは、自律的に業務に関する意思決定を行える立場にあるステークホルダーとビルダーによるクロスファンクショナルチームでパイロットを実施したいと考えました。最終的な技術目標には若干届きませんでしたが、チーム内で多くの素晴らしい化学反応が起きるのを目にしました。将来のプログラム全体とその先に向けて活用できるチーム連携のテンプレートとして、知識、効率性、自信、そして信頼を築くことができました。2024年前半には、EBA から得たこれらの教訓を活かし、ソリューションの展開を完了しました。
現在のアーキテクチャは次のようになっています。 図で見ると非常に小さな変更に見えますが、私たちにとって様々な面でメリットがありました。これらの成果について詳しく見ていきましょう。まず、パフォーマンスについて見てみましょう。 初期のテスト結果は複雑で、総リクエスト数とピーク時のリクエスト数はやや低いものの、ほぼ同等でしたが、応答時間は約10%遅くなりました。この予想外の結果を受けて、追加のテストと改善作業を行うことにしました。
Amazon ECSとInfrastructure as Codeのアプローチのおかげで、その作業は比較的迅速かつ容易に実施できました。この作業の後、 両方の面で改善が見られましたが、特に応答時間については、ベースラインと比較して約25%の改善が見られました。
メンバーあたりの1日のコンピューティングコスト を比較すると、Dedicated Hostsを使用した従来のアーキテクチャと比べて、コンテナでは約54%のコスト削減が実現しています。これは月間のAWS支出全体の約4%の削減に相当します。これには、.NET on Linuxへの移行による Microsoft ライセンスコストの削減や、AWS Graviton など、今後予定している他の魅力的な変更による効果は含まれていません。
全体として、Amazon ECSを使用したeコマースワークロードは、Dedicated Hostsでの Windows展開と比較して、 課題に対して次のように対応しています。初期のコンテナ展開では、過剰なプロビジョニングがなくなり、必要に応じてスケールできるようになったため、約54%のコスト削減 を実現しています。Auto Scalingのおかげで、各メンバーのニーズに合わせて自動的にサイズを最適化するソリューションが実現し、 また、各メンバーが独立した展開環境を持つことで、ノイジーネイバーの問題も解消されました。
最後に、この取り組みの影響を実感できる話を共有したいと思います。ご存知の方も多いと思いますが、7月19日の早朝、多くの人が週末の予定を変更することになりました。 CrowdStrikeの話をするのではなく、私たちのチームの話をしたいと思います。これは、今日お話しした多くのメリットと、私たちのメンバーがすでにそれらのメリットを体験している様子を示す素晴らしい事例です。Tessituraでは、プラットフォーム全体で約1,600の影響を受けたインスタンスを修正するため、約12人のエンジニアが作業を行いました。同時に、少人数のエンジニアチームを配置して、最終的に修正を一括で自動化できるようにスクリプトの作成に取り組みました。
US Central Timeの金曜日の夜までに自動化を完了した時点で、本番環境の約30%と非本番環境のすべてが残っていました。自動化を活用することで、2人のエンジニアだけで残りの本番環境とすべてのテスト環境、開発環境の作業を完了し、土曜日の午前3時30分頃（US Central Time）には完全な運用能力を回復することができました。これは、問題が発生してから約24時間後のことでした。エンジニア1人あたりの復旧率が向上しただけでなく、自動化された修正の方が失敗率も大幅に低いことがわかりました。手動プロセスでは、修正を断念してバックアップからの復旧が必要になることが多く、それが復旧作業の時間と複雑さを増す要因となっていました。
Chrisと私が今日お話ししてきた、チーム間のコラボレーション、Infrastructure as Code、クラウドネイティブ技術による自動化といったすべての取り組みがこの事例に集約されており、これらの要素はどれも、このインシデントからの復旧を数日や数週間ではなく26時間で完了できた私たちのチームの能力を支える重要な役割を果たしました。Infrastructure as Codeの実践は、私たちのメンバーに実際のメリットをもたらしています。通常よりもはるかに迅速に完全な運用能力を回復できたことで、世界中のアートや文化団体へのインシデントの影響を大幅に軽減することができました。
Tessituraの今後の展望と.NETモダナイゼーションツールの紹介
これが私たちの現在までの歩みですが、今後の道のりには、今日お話しした3つの移行パターンすべての継続的な進化が含まれています。まず、Rehostingについてはまだ残っている作業があります。Chrisが先ほど触れたように、私たちは100%のメンバーをサポートできるプラットフォームの構築に注力しており、この目標の達成に向けて順調に進んでいます。現在、約83〜85%のメンバーが自社ホスティングではなく私たちのクラウドサービスを選択しています。残りのメンバー環境は非常に大規模で複雑な傾向にあり、特に大規模なチケット販売イベントなどにおけるスケーラビリティと弾力性の必要性が高まっているため、元のアーキテクチャへの移行は現実的ではありません。ここで、AWSパートナーシップの継続的な支援を受けながら、Replatformingの取り組みを続けていくことになります。より持続可能でレジリエントなプラットフォームへと追加のワークロードを再設計することを計画しています。
注力分野には、APIのコンテナ化や、データベースワークロードをRDSやAuroraなどのPostgreSQLに移行することも含まれる可能性があります。これは当面の優先事項ではありませんが、そうすることで、レジリエンス目標を継続的に改善しながら、メンバーあたりのクラウドコストを引き続き削減することを目指しています。
私たちは、Chris が先ほど言及したように、Amazon RedshiftとAWS Database Migration Serviceへの移行を含む、分析プラットフォームの再設計など、いくつかのリファクタリング施策を計画しています。また、他のマイクロサービスの可能性も検討しています。Chrisが私に言ったように、 「計画は現実と衝突すると生き残れない」のですが、アーキテクチャ計画を見て、今日お話しした全ての施策を考慮すると、私たちが目指す状態はこうなります：クラウドジャーニーという終わりのないゲームに向けて、リホスト、リプラットフォーム、そしてリファクタリングを実施していきます。
以上で私の発表を終わり、Jagadeeshにバトンを渡したいと思います。Chris、そしてJeff、素晴らしい取り組みを共有していただき、ありがとうございます。新年に向けたロードマップの実行を、引き続き一緒に進めていけることを楽しみにしています。 ここで.NETアプリケーション向けのモダナイゼーションツールをいくつかご紹介したいと思います。1つ目はApp2Containerです。コンテナをご存じない方のために説明しますと、これはオンプレミスの仮想マシン上でホストされている.NETアプリケーションのリフト＆シフトを支援するコマンドラインツールです。コンテナ化を自動化し、Amazon ECS、Amazon EKS、AWSなどのマネージドコンテナプラットフォームへの移行を可能にします。JavaやNETの複数のバージョンをサポートしているので、コンテナ化の自動化を素早く行いたい場合に非常に便利なツールです。
.NETモダナイゼーションのための2つ目のツールは、AWS Microservice Extractor for .NETです。これは個別にダウンロードしてインストールする必要があるスタンドアロンツールで、.NETモノリスからマイクロサービスベースのアーキテクチャへのマイクロサービス抽出プロセスを簡素化します。コードをスキャンしてコードベースの異なる部分間の静的および実行時の依存関係を分析し、独立したマイクロサービスとして抽出可能なコンポーネントのデフォルトのグループ分けを提案します。
これはコード内の異なるコンポーネント間の関係を視覚化したツールのスクリーンショットです。 AWS Microservice Extractorは、マイクロサービスとして抽出するのに適していると判断したコンポーネントのデフォルトグループ分けを提案するために、バックグラウンドで機械学習モデルを使用しています。開発者は、これらのコンポーネントを必要に応じて微調整し、調整することができます。
これでセッションは終わりですが、皆さんのモダナイゼーションの旅はここから始まります。AWSには.NETのスペシャリストが大勢いますので、アプリケーションについての相談やブレインストーミングが必要な場合は、担当のアカウントチームにご連絡ください。また、モダナイゼーションの取り組みに対応する厳選されたプログラムもご用意しています。こちらも最初のステップとしてアカウントチームにご相談ください。Expoフロアには、Windows、SQL Server、.NETのブースが週を通して開設されています。ぜひお立ち寄りください。
SQL Serverのモダナイゼーションについては触れませんでしたが、これは.NETのワークロードと非常に密接に関連しているものです。そこで、SQL ServerとNETのワークロードをモダナイズする方法について説明したページへのQRコードを表示しておきます。もう一つのQRコードは、AWSにおける.NETに関する全ての情報が掲載されているランディングページへのものです。 本セッションにご参加いただき、誠にありがとうございました。re:Inventの残りの日程も素晴らしいものとなりますように。また皆様とお会いできることを楽しみにしております。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion