re:Invent 2024: Moody'sがWindows AppをAmazon EKSへ移行した事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Go codeless and replatform Windows applications on Amazon EKS (XNT311)
この動画では、LegacyなWindowsアプリケーションをコードを変更することなくAmazon EKSへ移行する方法について解説しています。Moody'sのSenior Director、Head of DevOpsのSreenivas Thirunagaruが、15年以上稼働している4つのフラッグシップアプリケーションを移行した実例を紹介し、45%のコスト削減を実現した具体的な成果を共有しています。また、Windows ContainerをAmazon EKS上で効率的に運用するための技術的なポイントとして、Container Credential Guard（CCG）プラグインの活用やEC2 Image Builderを使用したキャッシング戦略の実装方法、Fast Launchによる起動時間の短縮など、実践的なベストプラクティスが詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Windows アプリケーションのコンテナ化：セッション概要と背景
みなさん、こんにちは。ご参加いただき、ありがとうございます。本日は遅い時間帯ではありますが、このセッションのために少しエネルギーを残しておいていただけたと思います。まず、正しいセッションにお越しいただいているか確認させていただきますが、こちらは「XNT311: Go Codeless and Replatform Windows Applications with Amazon EKS」です。私はAWSのGlobal Financial ServicesのPrincipal Solutions ArchitectのSamuel Baruffiです。そして本日は、Microsoft WorkloadsのSolutions ArchitectであるJarod Oliverと、Moody'sのSenior Director、Head of DevOpsであるSreenivas Thirunagaruをお迎えしています。
本日は、既存のWindowsアプリケーション、特にレガシーなWindowsアプリケーションを、コードを変更することなくコンテナに移行する方法についてご紹介します。その実践的なベストプラクティスをお伝えします。また、Sreenivasから、大手金融機関であるMoody'sがどのようにしてこの移行を進めてきたのか、直面した課題や、その過程で得られた教訓についてお話しいただきます。
始める前に、現在Windowsアプリケーションを運用されている方は手を挙げていただけますでしょうか？かなり多くの方がいらっしゃいますね。まさに適切なセッションにお越しいただいています。では、Windowsアプリケーションを運用されている方の中で、コンテナで運用されている方はどのくらいいらっしゃいますか？予想通り、ごく少数ですね。そして手を挙げていただいた方の中で、Amazon EKSで運用されている方は？誰も...あ、お一人お二人いらっしゃいますね。これからそのやり方とAWSが用意しているベストプラクティスについて学びたい方には、まさに最適なセッションです。
レガシーWindows アプリケーションの課題とAmazon EKSによる解決策
技術的な話に入る前に（これからそうなりますが）、現在の技術状況について少しお話ししたいと思います。金融サービスなどの大規模な組織では、多くのWindowsアプリケーションがレガシー化していることは周知の事実ですが、すべてのWindowsアプリケーションがレガシーというわけではないことを強調しておきたいと思います。この違いは重要です。Jarodが後ほどのプレゼンテーションで触れますが、最先端のゲーミング企業の中には、AWSのコンテナ上で新しいWindowsアプリケーションを開発しているところもあります。
私たちが見てきた傾向として、多くのお客様がレガシーなWindowsアプリケーションを抱えており、様々な課題に直面しています。ここでは、密接に関連する2つのカテゴリーの課題をご紹介します - ビジネス上の課題と技術的な課題です。世界中のすべての企業がイノベーションを進めたいと考える中で、スピーディーなイノベーションへのプレッシャーが高まっています。古い技術を使用していたり、保守が困難なコードベースを持つアプリケーションがある場合、それは技術的な課題だけでなく、ビジネス上の課題にもなります。
.NET Frameworkの古いバージョンや、20-30年前にコーディングされたサードパーティベンダーのアプリケーションを実行している場合、メンテナンスが非常に困難になり、コストが増加していきます。JarodとSreenivasは、Windowsアプリケーションの従来の実行方法について説明します - 仮想マシンやサーバー上にモノリシックなアプリケーションがデプロイされており、それをスケールすることが非常に困難になります。時には、長年にわたって十分な注意を払われてこなかったアプリケーションであっても、スケールする必要性が出てくることがあります。
ビジネス面での最後の課題として、あまり議論されていないことですが、この数年間でGenerative AIのような新しいテクノロジーが台頭してきたため、これらのレガシーアプリケーションを維持できるスキルを持った人材が減少しているということです。そのレガシーアプリケーションでまだ収益を上げているとしても、それをサポートできる人材が十分にいないのです。これらの課題は、技術的な課題とも密接に関連しています。最初の課題として、非常に古いアプリケーションには通常、多くの技術的負債が集中しています。もしかすると、もうコードをサポートするチームがいないかもしれません - 単にアプリケーションとコードベースが動いているだけで、そのアプリケーションがどのように動作しているのか誰も知らないという状況です。
人々は「触れば触るほど悪くなる」という考えを持っていますが、これも課題となり得ます。サードパーティパッケージや.NET Framework、あるいはWindows以外のフレームワークが時代遅れになると、セキュリティの問題が発生します。これらをどのようにアップデートすればよいのでしょうか？これは組織の一部として考慮する必要がある重要な課題です。
私たちはクラウドの時代にいて、仕事に最適なツールを活用したいと考えています。クラウドの主な利点の1つは弾力性です。移行が困難で、仮想マシン上で垂直方向にしかスケールできないアプリケーションがある場合、オンデマンドでスケールすることが課題となります。週の特定の時期にピークがあり、その後スケールダウンしたいアプリケーションの場合、それは非常に困難になります。AWSサービスと統合してデカップリングを始めたいモノリシックなアプリケーションの場合、FunctionsやContainerで実行したい場合も、非常に困難になります。
これらすべてを念頭に置いて、今日お話ししたいのは、EC2や場合によってはオンプレミスで実行されている既存の Windowsアプリケーションをどのようにモダナイズし、クラウドネイティブなContainerに移行できるかということです。タイトルには「Codeless」とありますが、その意味を説明させていただきます。これは、Container上で再プラットフォーム化するためにアプリケーションコードを変更する必要がないという単純な考え方です。運用、セキュリティ、パフォーマンスのベストプラクティスのために必要なことがありますが、それについてはJarodが後ほどAmazon EKS上でどのように実現するかについて詳しく説明します。
Windowsアプリケーションをコンテナ化すると、AWSのオーケストレーター上で実行できるようになります。Moody'sはEKSをメインのオーケストレーションプラットフォームとして選択しているため、今日はAmazon EKSに焦点を当てていきますが、AWS Fargateでも実行可能です。様々な規模のお客様が、すでにオーケストレーションの一元化を採用しているのを目にしています。DevOpsチームやプラットフォームチームがイノベーションに注力している中で、Windowsアプリケーションだけを別の方法で実行したいとは思わないでしょう。WindowsアプリケーションをEKSに、つまりコンテナのオーケストレーションに統合することで、KubernetesのCommon APIを使用して、既存のベストプラクティスやパイプラインを活用して管理できるようになります。
Moody'sにおけるWindows アプリケーションのAmazon EKSへの移行事例
Windowsのモダナイゼーションについて、私たちは3つの異なるステップを確認しています。必ずしもこれらのステップを順番に実行する必要はありませんが、多くのお客様がこのパスを辿っているのを見てきました。最後のServerlessを使用したモダナイゼーションに直接進むこともできますが、一般的に見られるのは、オンプレミスのデータセンターで実行されているWindowsアプリケーションをクラウドに移行したいというケースです。最初に行うのは、RelocateとRehost、いわゆるLift and Shiftと呼ばれる方法です。イメージを作成し、アプリケーションをEC2に配置して移行します。SQL Serverを使用している場合は、EC2上のSQL Serverを使用し、それには手を加えたくないかもしれません。
多くのお客様がすでにこの journey を経験しているか、まもなく経験することになると考えています。私たちが注目したいのはReplatformingです。アプリケーションはあるものの、モダナイゼーションに多くのリソースやエンジニアリング時間を投資したくない場合があります。おそらくLegacyアプリケーションかもしれませんが、Cloud-nativeテクノロジーで実行したいと考えています。Replatformingの考え方は、そのWindowsアプリケーションをコンテナ化することです。その際には、多くのベストプラクティスを念頭に置く必要があります。コンテナ化が完了したら、オーケストレーションプラットフォームを選択できます。Amazon ECS、AWS FargateによるECS、あるいは今日焦点を当てているようにAmazon EKSとWindowsノードで実行することができますが、それで終わりではありません。さらに先に進むお客様も多く見られます。Windowsアプリケーションをすでにコンテナ化していて、そのLegacyアプリケーションを本当にモダナイズしたい場合、AWSは多くのサポートを提供しています。
.NET Frameworkから.NET 8に移行することで、Lambda関数上でも実行できるようになります。完全にEvent-drivenなアプリケーションや、さらにはMicroserviceアプリケーションにすることもモダナイゼーションによって可能になります。これがRefactorとRewriteと呼ばれるものです。Virtual machineからContainerへの移行、これが今回のトークの主な焦点となります。
Amazon EKS on Windowsの利点と実装の詳細
ここからは、Sreenivas Thirunagaruに引き継ぎます。彼はMoody'sで、LegacyなWindowsアプリケーションをコンテナ化してAmazon EKS上でモダナイズした実際の journey についてお話しします。ありがとうございます、Sam。Moody'sのShriです。私はMoody'sのBanking組織のCloud Infrastructureを管理しています。Moody'sには、Moody's AnalyticsとMoody's Ratingsという2つの主要な事業体があります。Moody'sは100年以上にわたってこのビジネスを展開してきました。本日は、Samが言及したように、コードを変更することなく、データセンターからAWS、特にAmazon EKSへアプリケーションを移行した経験を共有させていただきます。
この物語は約5年前に始まりました。私たちはWindows Amazon EKSの最初の導入者として、データセンターからクラウドへとアプリケーションを移行しました。多くの課題と学びの機会がある旅でした。AWSチームと私たちのチームが一緒に学び、間違いなく成功した事例となりました。5年後の今、ほぼすべてのアプリケーションをデータセンターから移行し、Amazon EKSで順調に稼働しています。 これらの多くのアプリケーションの中から、Moody'sで15年以上稼働している4つのフラッグシップアプリケーションを選びました。すべて.NETの世界のもので、クレジットポートフォリオリスク管理ソリューションのRisk Frontier Deal Analyzer、そして同じポートフォリオに属するRiskCalc、CMM、ZMの3つの製品が含まれています。
さらに、これらはすべてWindows .NET 4.8 Frameworkで開発されています。 現在もそのまま動作しており、変更を加えることなくAmazon EKS上で稼働しています。EKS導入以前は、Moody'sのデータセンターでホストされており、通常はアプリケーションサーバーとデータベース、あるいは複数のアプリケーションサーバーと複数のデータベースサーバーで稼働していました。クライアントの要件や作業負荷に応じて、計算サーバーも追加していました。
これらのアプリケーションを振り返ってみると、それぞれのアプリケーションを異なる言語やオペレーティングシステムでリファクタリングまたは書き直すには、500万ドル以上のコストがかかります。このリファクタリング中に既存のアプリケーションをサポートするコストも非常に高額です。同時に、ハードウェアやソフトウェアライセンスの費用も支払わなければならず、これも管理が困難でした。クライアントの要件に基づいて追加の計算エンジンを導入する際には、さらにサーバーや仮想マシンが必要になります。これらのインスタンスは使用されないこともありますが、それでも費用を支払う必要がありました。さらに、新しいアプリケーションをアーキテクチャ設計し、市場に投入するには相当な時間がかかります。これらすべての要因を考慮し、最小限の労力で新しいテクノロジーを使用してこれらのアプリケーションを実行できるソリューションを探すことにしました。そこで見つけたのがAmazon EKSでした。2019年のre:Inventで発表された時、私たちはまさにこれを待っていました。そして2019年に採用し、これらすべてのアプリケーションをAmazon EKSに成功裏に移行しました。
WindowsアプリケーションをEKS上で5年間運用してきた経験から、いくつかの重要なメリットを見出しました。市場投入までのスピードに関して、先ほど述べたモノリシックアプリケーションについて言えば、これらのアプリケーションはすべてデータセンターでインフラストラクチャ・アズ・ア・サービスとしてモノリシックアプリケーションとして稼働していました。新機能をリリースする場合、小さな変更であっても、すべての非本番環境と本番環境を経由する必要があり、それによってダウンタイムが発生し、多大な労力が必要でした。
これらのアプリケーションをすべてコンテナ化した今、軽量なアプリケーションに変更しました。変更を実装して本番環境にプッシュするのが非常に簡単になり、すでにライブで稼働しています。これは間違いなくモダナイゼーションにおける大きな成果です。コンテナ化、EKSプラットフォーム、クラウドスケーリングにより、これらの業界標準のモダンテクノロジーは、リファクタリングの必要なく、今後数年間は確実に生き残ることができるでしょう。
従量課金モデルにより、使用していないリソースに対して支払うことなく、使用した分だけを支払うことができ、必要に応じてリソースを追加する際の制限もありません。運用担当者として特に関心のある運用の容易さについて言えば、データセンターでは数多くの課題がありました。以前は、これら4つのアプリケーションを管理するために、システム管理、ネットワーク、マネジメントの専門知識を持つ少なくとも15人のスタッフが必要でした。しかし現在はクラウド上のEKSを使用し、Farm Shopや様々な自動化ツールを活用しています。これらの自動化により手作業とヒューマンエラーが排除され、わずか3人のスタッフですべてのアプリケーションを効率的に管理できるようになりました。
Windowsインスタンスのパッチ適用については、インスタンスの再構築というアプローチを採用しています。AWSが提供する新しいAmazon Machine Image（AMI）を取得し、必要なツールと設定を追加して独自のGolden AMIを作成します。このGolden AMIを使用してEKSクラスターを再構築し、基本的にすべてを新しいインスタンスにリセットします。このプロセスにより、多くのセキュリティ上の懸念に対処できます。EKSでは、Launch Templateを新しいAMIに変更するだけで、新しいイメージが適用されます。
安定性と信頼性に関しては、AWS上で運用されているため、すべてのインスタンスが地理的に分散された異なるAvailability Zoneに配置されています。AWSはこれらのゾーンをバックアップ電源、冷却、その他の機能で管理しています。これは他のどのデータセンターよりも確実に信頼性が高いと言えます。セキュリティとスケーラビリティについては、Amazon Inspector、Guard Duty、様々な暗号化プロトコルなど、AWSは数多くのセキュリティポリシーを実装しています。例えば、Amazon S3は保存時と転送時の暗号化を提供します。スケーラビリティは、Auto-Scalingツール、Nodeクラスター、必要に応じてスケールできるLoad Balancerを通じて実現されています。シングルサインオンは別の独自機能ですが、すでに多くの他のアプリケーションをAWSで実行していたため、これらのWindowsアプリケーションを既存のシングルサインオンシステムにシームレスに統合することが容易でした。
Farm Shopを使用しているため、本番環境を実行するための本番用ブループリントがあります。別のリージョンにディザスタリカバリを構築する必要があった際は、同じブループリントを適用するだけで、異なるリージョンにWarm Standbyのディザスタリカバリが準備できました。これらはすべて、AWSおよびAmazon EKS on Windowsを利用する主な利点です。
Moody'sの移行成果と課題：コスト削減から運用効率化まで
いくつかの課題についても共有したいと思います。これらの課題は、必ずしもAmazon EKS特有のものではなく、むしろこれらのクラスターにLinuxとWindowsが混在しているために生じています。これはLinuxとWindowsの比較と見ることができます。複雑さの主な要因は、Windowsクラスターとノードのセットアップにあり、設定と管理に追加のステップが必要なため、Linuxと比べてノードの接続がより複雑になる可能性があります。コストの問題はAmazon EKSそのものではなく、Windowsの性質によるものです。Linuxはコストが低く、Windowsはコストが高いため、EKS on Windowsのコストが増加することになります。LinuxとWindowsの機能の同等性に関しては、Linuxの機能は常にWindowsより進んでいます。Windowsクラスターでは一部の機能が欠けている可能性がありますが、それがWindowsの使用を妨げる理由にはならないはずです。
リソースのオーバーヘッドは、やはりWindowsの方が大きいですね。WindowsはCPUやメモリなどのリソースをより多く使用するため、より大きなインスタンスをプロビジョニングする必要があり、そのためLinuxよりもコストが高くなる可能性があります。また、コミュニティやエコシステムは歴史的にLinuxに重点を置いており、機能面でもLinuxに少し遅れを取っているものの、現在急速にキャッチアップしています。EC2インスタンスの起動時間については、通常WindowsインスタンスはLinuxより長くかかり、AMIにDockerイメージを追加するとさらに起動時間が延びてしまいます。これらの課題をどのように克服し、Linuxと同等のクラスター運用を実現できるのか、この後のスライドでJarodが説明してくれます。
これが現在の私たちの環境です。現時点で、400以上のWindowsインスタンスを含む200以上のAmazon EKSクラスターを運用しています。また、25テラバイト以上のAmazon FSx for Windows File Server、1000以上のデータベースを持つAmazon RDS for SQL Serverの多数のインスタンス、そして1000以上のデータベースを持つAmazon ElastiCacheを使用しています。これらのサービスだけでなく、Amazon EKSとシームレスに連携する多くのAWSサービスを活用しています。これこそがAWSにいる利点で、AWSが管理するすべてのサービスを基本的に利用できるのです。
これは私たちのインフラストラクチャの高レベルなアーキテクチャで、どのように運用され、実装され、移行されたかを示しています。多くの要素が含まれているため、かなり簡略化して説明させていただきます。機能面では、これらのアプリケーションは非常にデータ処理が集中的で、バックグラウンドで多くの計算を実行します。計算の完了まで数時間かかることもあります。クライアントがデータをアップロードすると、フロントレイヤーのAPIレイヤーでデータとリクエストを受け取ります。APIレイヤーにあるJob Managerがリクエストを受け取り、データをデータベースに入力し、クライアントがアップロードしたファイルをFSxに保存して、ジョブをスケジュールします。そのジョブはRabbitMQに送られます。
RabbitMQは、ワークロードとデータサイズに基づいてJob Executionレイヤーでジョブをスケジュールします。これらのジョブの処理中、イベントとジョブステータスはEvent Storeに書き込まれます。同じAPIレイヤーにあるJob Monitoring APIが、Event Storeからデータを取得し、進捗状況をクライアントに報告します。
アーキテクチャ的には、これらの縦のラインはそれぞれ異なるサイズのManaged Node Groupとしてのレイヤーを表しています。これらのManaged Node Groupは、Auto Scaler、サイズ、リソース制限などを明示的に定義して管理する必要があります。最近、オープンソースプロジェクトのKarpenterを導入しました。これは近い将来、マネージドサービスになることが期待されています。Karpenterは、Amazon EKSのライフサイクル管理ツールで、スケジュールされていないジョブやリソース制限を確認し、サイズやニーズに基づいてジョブやPodをスケジュールします。
従来のマネージドノードグループに代わり、現在はNode PoolとNode Classという概念が導入されています。Node Classは、VPC内でのプロビジョニング内容、使用するセキュリティグループ、IAMロール、AMIなどを定義するものです。Node Poolでは、m4.xlarge、2xlarge、4xlargeなどのインスタンスサイズを定義し、クラスターの問題を防ぐために1000GBのRAMや1000 CPUといった上限を設定できます。設定後、Karpenterが自動的にノードのスケールアップとスケールダウンを行います。これはAmazon EKSにとって大きな改善であり、不要なリソースをシャットダウンすることでコストを削減できます。
Amazon FSx for Windows File Serverは、以前はAmazon EKSノードにマウントしていましたが、現在はPersistent Volume ClaimのもとでPersistent Volumeとして直接ポッドにマウントしています。ここまでアーキテクチャと機能について説明してきましたが、本題はコードレスマイグレーションについてです。アプリケーションのビルドとデプロイメントに関して、.NET Framework 4.8でビルドされたアーティファクトを、データセンター内の仮想マシンやサーバーに直接デプロイしていました。これを変換する際、コードは一切変更せずに、アーティファクトを取り出してモノリシックなアプリケーションを小さなAPIに分割し、バイナリを分離して異なるDockerイメージにパッケージ化しました。
各Dockerイメージには、ブートストラップPowerShellスクリプトを呼び出すエントリーポイントがあります。このPowerShellスクリプトは、内部で他のスクリプトを呼び出してDockerの実行環境を準備し、すべての変数を環境変数としてロードします。Amazon EKS Config Map、Amazon EKS Secrets、AWS Secrets Managerなど、様々なソースからデータを読み取り、このコンテナ内でトークンやプロパティとして作成された値を置き換え、変数として設定します。
コンテナが起動すると、環境変数からデータを読み取ります。これらのスクリプトは、実行に必要なアプリケーション設定ファイルも準備します。その後、Webサイト、アプリケーションプール、その他必要なものすべてを作成します。これらはブートストラップのプロセスで環境を準備し、コンテナは必要なデータをすべて揃えた状態で起動します。レガシーアプリケーションの場合、証明書はS3に保存され、必要に応じて取得してインストールされます。これらはすべて実行時前に準備されるため、コンテナはインスタンス上で実行するのと同じように通常通り動作します。
これが、新しいアーキテクチャでアプリケーションをパッケージ化してAWSで実行する方法の概要です。成果に関して、コストパフォーマンスの改善は常に重要です。 データセンター環境と比較して、Amazon EKSへの移行により45%のコスト削減を実現しました。Karpenterの採用は確実に大きなコスト最適化をもたらし、現在ではSpotインスタンスも利用できるようになりました。ノードの起動時間は、前述の通り約15分から6分に短縮されました。これは、これらのインスタンスで実行するために必要なイメージをAMI自体に追加することで達成しました。Windowsで有効にしたFast Launch AMI機能により、起動時間はさらに短縮されるはずです。
また、Containerの起動時間も短縮されています。WindowsのContainerはLinuxと比べてかなり大きく、Windows環境でも実行時にダウンロードされるレイヤーが存在します。これらのレイヤーをダウンロードする代わりに、すべてのレイヤーを事前にダウンロードしてイメージを構築しておくことでパフォーマンスを向上させることができます。これらの複雑な課題への対処方法と、より効率的で効果的な実行方法については、次のスライドでJarodが説明します。以上で私の説明は終わりです。ご質問がありましたら、セッション後にお受けいたします。
Windows コンテナ化の技術的詳細：AMIの最適化とキャッシング戦略
ありがとうございます。それでは、Amazon EKS上でWindowsアプリケーションとContainerを実行する利点について見ていきましょう。以前は、アプリケーションとその依存関係が互いに競合しないよう、1つのサーバーに1つのアプリケーションを実行することが一般的で推奨されていました。しかし、Containerは定義上、分離されています。これにより、1台のサーバーで複数のアプリケーションを実行できるようになり、計算能力とストレージの効率性が大幅に向上します。各アプリケーションの実行に完全なオペレーティングシステムが不要なため、同じ数のアプリケーションを実行する場合でもストレージの最適化というメリットが得られます。また、完全なオペレーティングシステムをデプロイする必要がないため、Windowsライセンスの数を削減でき、コスト削減にもつながります。
Windows Serverの各バージョンは、サポート終了とされてアップグレードが必要になるまで、Microsoftから約10年間のサポートを受けられます。しかし、Windowsのバージョン間で変更が生じ、互換性の問題が発生する可能性があるため、アップグレードは必ずしも容易ではありません。アプリケーションとその依存関係（新しいバージョンのWindowsと互換性のない古いものも含まれる可能性があります）をContainer化することで、新しいバージョンのWindows上でアプリケーションを迅速かつ容易にテストできるようになります。テストが早ければ早いほど、高額なサポート終了後の契約を回避できる可能性が高くなります。Containerは新しい技術ではなく、多くのお客様のビジネスで実証済みのソリューションです。社内にすでにある専門知識を活用することで、DevOpsやプラットフォームエンジニアリングへの投資を最大限に活用できます。Sreenivasが示したように、KubernetesはこれらにおいてKey Componentであり、Amazon EKSとWindowsコンテナの活用においてMoody'sの取り組みに大きく貢献しています。
Windows ContainerはNET Frameworkを使用するアプリケーションの実行にのみ使用すべきだという誤解がありますが、Windows互換のフレームワークであれば何でも使用できます。多くの場合、お客様がCommercial Off-The-Shelf（COTS）アプリケーションをWindows Container内で実行しているのを目にします。Samuel Baruffiが先ほど指摘したように、ゲーム関連のお客様がPCプラットフォームやゲームサーバー向けのビルドを実行するためにWindows Containerを使用しているケースもあります。
このセッションのタイトルが示すように、私たちはWindowsアプリケーションのContainer化にCodelessなアプローチを取りたいと考えています。プラットフォームを近代化したいものの、必ずしもアプリケーションのリファクタリングは必要ありません。なぜなら、それには時間とコストがかかるからです。この近代化の取り組みは、Microservicesへの移行やService Meshの使用に関するものではなく、基盤となるプラットフォームを最適化するための戦略です。Windows ContainerはAWS Fargateのようなサービス技術を使用する可能性を広げることで、メンテナンスの負担を軽減します。WindowsとLinuxは異なるユースケースを持ちますが、管理の観点では同等です - どちらもパッチ適用が必要で、メンテナンスが必要で、最終的には各バージョンのオペレーティングシステムがサポート終了を迎え、サポートとセキュリティの理由からアップグレードが必要になります。
Windows ContainerをAmazon EKS上で実行するには、基盤となるホストがWindows Serverを実行している必要があります。 AWSは、これを非常に簡単に実現できるAmazon EKS最適化Windows Server Amazon Machine Image（AMI）を提供しています。 このAMIがどのように機能するか見ていきましょう。Worker NodeとEKSコントロールプレーン間の通信を担うkubeletがあり、クラスター内のトラフィックルーティングのためのネットワークルールを管理するkube-proxyがあります。AWS IAM Authenticator for Kubernetesは、AWS IAMロールを活用することで、Kubernetesアクセス用の別個の認証情報を管理する必要性を解消します。
Container Credential Guard（CCG）プラグインは、これまでAmazon EKS上でWindows Containerを実行したことがない方には馴染みがないかもしれません。このプラグインの役割は、Windowsのドメインレス認証を可能にすることです。つまり、Windowsを動作させるために、クラスター内のWorker NodeをActive Directoryドメインに参加させる必要がないのです。CCGプラグインは、AWS Secrets ManagerやAWS Systems Manager Parameter Storeから認証情報を取得し、Active Directoryに対して呼び出しを行い、Group Managed Service Account（GMSA）アイデンティティを受け取って、それをPodに渡して使用します。 containerdは、EKS最適化AMIに含まれるランタイムで、EKSバージョン1.24から標準のコンテナランタイムとなりました。これはRESTインターフェースを公開しており、ツールがコンテナランタイムと対話できるようになっています。
コンテナランタイムは、ジョブオブジェクトやオブジェクトネームスペースなどのプロセス分離を作成するために、低レベルのカーネルAPIと直接やり取りします。 Linuxではカーネルアクセスが許可されています。これは、最初からそのように設計されたオペレーティングシステムの本来の機能だからです。Microsoftは、コミュニティがLinux用とWindows用の2つの異なるランタイムを作成・維持することはないと認識していました。そこで、Host Compute Service（HCS）レイヤーという追加レイヤーを開発し、C言語で書かれたAPI経由で低レベルのカーネルAPIを公開しました。
コンテナランタイム開発者は、そのC APIと通信するようにランタイムを構築する必要がありますが、正直なところ、それはそれほど簡単ではありません。そこでMicrosoftは、より高レベルな言語からHCSを呼び出すための2つのオプションを提供するラッパーを開発しました。最も一般的に使用されているのはGoで書かれたhcsshimで、C#で書かれた.NET Compute Virtualizationもあります。これらの高レベル言語の方が私たちには理解しやすく、ラッパーがHCSレイヤーのC APIと通信を行います。
HCSレイヤー自体が、先ほど説明した低レベルのWindowsカーネルタスクをすべて処理します。LinuxとWindowsの違いを簡単に説明すると、Linuxではコントロールグループ（cgroups）を使用するのに対し、Windowsではジョブオブジェクトを使用します。Linuxにはネームスペースがあり、Windowsにはオブジェクトネームスペースがあります。HCSレイヤーは、これら2つのコンポーネントを通じてプロセス分離の作成を調整し、その情報をランタイムに返してコンテナを作成できるようにします。
Windowsコンテナは、Linuxコンテナと比べて起動に時間がかかりますが、キャッシング戦略を活用して改善することができます。この画像で見られるように、Windowsコンテナイメージの中間レイヤーのダウンロードと展開には約4分かかります。この問題を解決するには、まず根本的な原因を理解する必要があります。前述の通り、AWSはAmazon EKS最適化Windows Server AMIやECS最適化AMI、そしてAWS Fargate用のAMIを提供しています。これらの最適化されたAMIには、Windows Server CoreとWindows Nano Serverのベースイメージが含まれています。
Windowsコンテナイメージの約40%は、AMIの一部としてすでにホストのディスクに展開されています。Windowsコンテナの最も一般的なユースケースは.NET Frameworkアプリケーションの実行であり、これには.NET Frameworkランタイムのインストールが必要です。コンテナに.NET Frameworkランタイムを組み込む必要があります。アプリがASP.NETに依存している場合は、両方が必要になり、場合によってはアプリケーションレイヤーも必要になります。結果として、Windowsコンテナイメージは4-5ギガバイトのサイズに、さらにアプリケーションが使用する容量が加わります。200メガバイト程度のLinuxコンテナと比較すると、7-8ギガバイト、あるいはそれ以上のサイズになることも珍しくありません。
適切なキャッシング戦略を使用していない場合、ホスト上の最初のWindowsコンテナはすべてのレイヤーをダウンロードする必要があります。その処理で最も時間がかかるのがレイヤーの展開です。Amazon EKSに関しては、containerdがすべてのレイヤーの展開という重要な作業を行う必要があり、これには長時間かかる可能性があります。イメージが大きい場合、Amazon EC2 Image Builderを使用してキャッシング戦略を実装することで、Windowsコンテナの起動時間を短縮できます。EC2 Image BuilderはEKSとECS用のカスタムAMIを構築するパイプラインを作成します。
Microsoftは毎月第2火曜日（Patch Tuesday）に定期的なアップデートと、不定期の重要なアップデートをリリースしており、これらをカスタムAMIに含めることをお勧めします。また、先ほど説明したアプリケーションの実行に必要なレイヤーも含める必要があります。もしアプリケーションがビジネス内でレガシーと見なされ、開発者による更新頻度が低い場合は、起動時間をさらに短縮するためにコンテナイメージに含めることも検討できます。
パイプラインの最後には、先ほど説明した事前キャッシュされたレイヤーがホストディスクに既に用意された、カスタマイズされたEKSまたはECS最適化AMIが完成します。EC2インスタンスの起動時間を改善するためにFast Launchを有効にすることができ、これについては後ほどプレゼンテーションで詳しく説明します。EC2 Image Builderは、新しいインスタンスがプロビジョニングされる際に新しいバージョンのAMIを使用するように、EC2起動テンプレートを更新することができます。そして、お客様は古いAMIを使用しているインスタンス上で実行されているPodのドレイニングを管理し、それらのインスタンスを廃止することができます。
Windows コンテナとEC2インスタンスの起動時間短縮策
このキャッシングの戦略が実際にどのような改善をもたらすのか見てみましょう。これは、Windows コンテナで ASP.NET アプリケーションを実行している例ですが、カスタム AMI は使用していません。スクリーンショットでは、EKS が先ほど見たすべてのレイヤーをディスクにプルして展開するのに7分かかったことが示されています。つまり、ホスト上で最初のコンテナを起動するのにこれだけの時間がかかるということです。2番目のコンテナの起動は、レイヤーがローカルにキャッシュされているため、より速くなります。
Amazon EC2 Image Builder でキャッシング戦略を実装することで得られる速度向上について説明します。この戦略では、アプリケーションの依存関係に必要なレイヤーが既に組み込まれたカスタム AMI を構築します。この例では、コンテナランタイムがそのイメージをプルするのにわずか54秒しかかかりませんでした。レイヤーが既にディスク上に存在していたため、イメージのメタデータを確認してPodを作成・起動するだけで済んだのです。
Windows コンテナやPodの起動時間を短縮する方法を見てきましたが、次はワーカーノード、あるいは Amazon ECS の場合はコンテナインスタンスの起動時間の改善について考えてみましょう。Windows の Sysprep についてご存知の方もいらっしゃるかもしれません。Windows はネットワーク上の各マシンが一意である必要があるように設計されており、これはマシンにセキュリティ識別子（SID）を割り当てることで実現されています。そのマシンを複製して別のマシンにイメージを再展開したい場合は、まず Sysprep を実行してセキュリティ識別子を削除する必要があります。その後、クローンされたイメージで新しい EC2 インスタンスを起動する際には、SID を再度追加するために Sysprep を実行する必要があり、この処理には長時間かかります。
この例では、EC2 ワーカーノードはカスタム AMI で起動されましたが、Fast Launch は使用していません。上部の青いボックスには、午前2時30分42秒に起動した時刻が表示されており、下部の EC2 システムログには、Sysprep プロセスが6分後に完了したことが示されています。つまり、コンテナの起動時間を短縮するためにカスタムの EKS または ECS 最適化 AMI を作成する努力をしたにもかかわらず、ホストの起動に非常に時間がかかっているという状況です。これは問題となる可能性があります。これはEC2インスタンスの起動にかかった時間だけであり、Amazon EKS クラスターへの参加やコンテナイメージのプルと起動にかかる時間はまだ考慮していないことを忘れないでください。
しかし、同じ AMI で Fast Launch を有効にすると（詳細はすぐに説明します）、Sysprep プロセスの完了にわずか1分50秒しかかからなかったことがわかります。この改善の理由は、Fast Launch プロセスが既に Sysprep を実行し、それをスナップショットに保存して、そのスナップショットを使用して Windows EC2 インスタンスを起動したためです。お客様は AWS コンソールまたは AWS CLI を通じて Fast Launch を有効にすることができます。その際、1時間あたりに必要となる Windows EC2 インスタンスの数を考慮する必要があります。バックエンドでは、お客様のアカウントで Amazon EC2 T シリーズインスタンスのセットを起動し、その AMI に対して Sysprep プロセスを実行し、出力を S3 バケットのスナップショットに保存します。その後、新しい Windows EC2 インスタンスを起動するたびに、これらのスナップショットの1つを取得して使用することで、ここで見たように起動時間を大幅に短縮することができます。
ここでお見せしたように、Windows Containerは同等のLinux Containerと比べて起動が遅くなる可能性がありますが、ContainerとホストOSの両方の起動時間を短縮するための効果的な戦略がいくつかあります。本日は他にも100の選択肢がある中で、このセッションにお越しいただき、誠にありがとうございます。このセッションがお役に立てば幸いです。ご質問がございましたら、ぜひお聞かせください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion