翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Windows アプリケーションをコンテナに移行する
概要:
「CNCF Annual Survey 2021
コスト上の利点
次のインフォグラフィックは、AWS Optimization and Licensing Assessment (AWS OLA) の
AWS OLA は、ビジネスが個々の t3.small インスタンスにリフトアンドシフトすることを推奨しました。次のパフォーマンス使用率分析が示すように、企業は、オンプレミスサーバーで 7 つの ASP.NET アプリケーションを実行することで、この削減を実現できます。
さらなる分析により、企業はコンテナでワークロードを実行することでコストをさらに削減できることが明らかになりました。コンテナは、CPU、RAM、ディスク使用量などのシステムリソースに対するオペレーティングシステムのオーバーヘッドを削減します (次のセクションで説明)。このシナリオでは、企業は 7 つのアプリケーションすべてを 1 つの t3.large インスタンスに統合し、さらに 3 GB の RAM の空きを確保しています。コンテナに移行すると、Amazon EC2 の代わりにコンテナを使用することで、コンピューティングおよびストレージ全体で平均 64% のコスト削減を実現できます。
コスト最適化の推奨事項
次のセクションでは、アプリケーションを統合してコンテナを使用することでコストを最適化するための推奨事項を示します。
Amazon EC2 での Windows のフットプリントの削減
Windows コンテナを使用すると、より多くのアプリケーションをより少ない EC2 インスタンスに統合できるため、Amazon EC2 での Windows のフットプリントを削減できます。例えば、ASP.NET アプリケーションが 500 個あるとします。Amazon EC2 で Windows のアプリケーションごとに 1 つのコアを実行している場合、これは 500 個の Windows インスタンス (t3.small) に相当します。Windows コンテナ (t3.large を使用) の使用に 1:7 の比率 (EC2 インスタンスのタイプ/サイズに応じて大幅に増加する可能性あり) を想定した場合、必要な Windows インスタンスは約 71 個のみです。これは、Amazon EC2 での Windows のフットプリントが 85.8% 減少することを意味します。
Windows ライセンスコストの削減
Windows インスタンスをライセンスする場合、そのインスタンスで実行されているコンテナをライセンスする必要はありません。その結果、Windows コンテナを使用して ASP.NET アプリケーションを統合することで、Windows ライセンスコストを大幅に削減できます。
ストレージフットプリントの削減
新しい EC2 インスタンスを起動するたびに、オペレーティングシステムを格納するための新しい Amazon Elastic Block Store (Amazon EBS) ボリュームを作成し、その料金を支払います。これがスケールすると、それに応じてコストもスケールします。コンテナを使用すると、すべてのコンテナが同じ基本オペレーティングシステムを共有するため、ストレージコストを削減できます。さらに、コンテナはレイヤーの概念を使用して、コンテナイメージのイミュータブルな部分を、そのイメージに基づいて実行中のすべてのコンテナに再利用します。前述のシナリオ例では、すべてのコンテナが .NET Framework を実行しているため、すべてが中間およびイミュータブルな ASP.NET フレームワークレイヤーを共有しています。
サポート終了サーバーのコンテナへの移行
Windows Server 2012 および Windows Server 2012 R2 のサポートは、2023 年 10 月 10 日に終了しました。Windows Server 2012 以前のバージョンで実行されているアプリケーションは、新しいオペレーティングシステムで実行するようにコンテナ化することで移行できます。これにより、コンテナが提供するコスト効率、リスクの低減、運用効率、速度、俊敏性を活用しながら、非準拠のオペレーティングシステムでアプリケーションを実行することが回避されます。
このアプローチで考慮すべき注意点は、アプリケーションが、現在使用中のオペレーティングシステムのバージョンに関連する特定の API (COM Interop など) を必要とする場合です。この場合は、アプリケーションを新しい Windows バージョンに移行することをテストする必要があります。Windows コンテナは、ベースコンテナイメージ (Windows Server 2019 など) を、コンテナホストのオペレーティングシステム (Windows Server 2019 など) に合わせます。テストしてコンテナに移行すると、Dockerfile 内のベースイメージを変更し、最新バージョンの Windows を実行している新しいホストのセットにデプロイすることで、将来のオペレーティングシステムのアップグレードが容易になります。
サードパーティー製の管理ツールとライセンスの削除
サーバーフリートを管理するには、パッチ適用と設定管理に複数のサードパーティー製のシステムオペレーションツールを使用する必要があります。これにより、インフラストラクチャ管理が複雑になり、サードパーティーのライセンスコストが発生することがよくあります。でコンテナを使用する場合 AWS、オペレーティングシステム側で何も管理する必要はありません。コンテナランタイムはコンテナを管理します。つまり、基盤となるホストはエフェメラルであり、簡単に置き換えることができます。コンテナホストを直接管理しなくても、コンテナを実行できます。さらに、 などの無料のツールを使用して、ホスト AWS Systems Manager Session Manager に簡単にアクセスし、問題をトラブルシューティングできます。
コントロールと移植性の向上
コンテナを使用すると、EC2 インスタンスよりも CPU や RAM などのサーバーリソースをより細かく制御できます。EC2 インスタンスの場合、インスタンスファミリー、インスタンスタイプ、CPU オプションを選択して CPU と RAM を制御できます。ただし、コンテナでは、ECS タスク定義のコンテナまたは Amazon EKS のポッドに割り当てる CPU または RAM の量を正確に定義できます。実際のところ、Windows コンテナでは、コンテナレベルの CPU とメモリを指定することをお勧めします。このレベルの粒度はコスト上の利点をもたらします。次のサンプルコードについて検討します。
json { "taskDefinitionArn": "arn:aws:ecs:us-east-1:123456789012:task-definition/demo-service:1", "containerDefinitions": [ { "name": "demo-service", "image": "mcr.microsoft.com/dotnet/framework/samples:aspnetapp-windowsservercore-ltsc2019", "cpu": 512, "memory": 512, "links": [], "portMappings": [ { "containerPort": 80, "hostPort": 0, "protocol": "tcp" } ],
イノベーションの加速
コンテナに移行すると、アプリケーションの構築、テスト、デプロイを含む開発ライフサイクルのステージの自動化が容易になります。これらのプロセスを自動化すると、開発チームと運用チームがイノベーションに集中する時間が増えます。
TCO の削減
コンテナに移行すると、ライセンス管理ツールやエンドポイント保護ツールへの依存が減ることがよくあります。コンテナはエフェメラル単位のコンピューティングであるため、パッチ適用、スケーリング、バックアップ、復元などの管理タスクを自動化および簡素化できます。これにより、コンテナベースのワークロードの管理と運用の TCO を削減できます。コンテナは、アプリケーションのインフラストラクチャリソースの使用率を高めることができるように、アプリケーションの配置を最大化できるため、仮想マシンと比較してより効率的です。
スキルギャップの解消
AWS では、コンテナと DevOps テクノロジーに関するカスタマー開発チームのスキルを向上させるためのプログラムとイマージョンデーを提供しています。これには、実践的なコンサルティングと支援が含まれます。
.NET 5+ へのリファクタリングと Linux コンテナの使用
.NET Framework アプリケーションをコンテナに移行することでコストを削減できますが、レガシー .NET アプリケーションを AWSのクラウドネイティブな代替手段にリファクタリングすると、さらにコスト削減を実現できます。
ライセンスコストの削除
Windows 上の .NET Framework から Linux 上の .NET Core にアプリケーションをリファクタリングすると、約 45% のコスト削減につながります。
最新の拡張機能へのアクセス
Windows 上の .NET Framework から Linux 上の .NET Core にアプリケーションをリファクタリングすると、Graviton2 などの最新の拡張機能にアクセスできます。Graviton2 は、同等のインスタンスよりもパフォーマンスに対して 40% 有利な価格を提供します。
セキュリティとパフォーマンスの改善
Windows 上の .NET Framework から Linux 上の .NET Core コンテナにアプリケーションをリファクタリングすると、セキュリティとパフォーマンスが向上します。これは、最新のセキュリティパッチを取得し、コンテナの分離によるメリットを得て、新機能にアクセスできるためです。
IIS の 1 つのインスタンスで多くのアプリケーションを実行する代わりに Windows コンテナを使用する
インターネットインフォメーションサービス (IIS) を使用して 1 つの EC2 Windows インスタンスで複数のアプリケーションを実行する代わりに Windows コンテナを使用することによる次の利点を考慮します。
-
セキュリティ – コンテナは、IIS レベルでの分離では達成されないセキュリティレベルを追加設定なしで提供します。1 つの IIS ウェブサイトまたはアプリケーションが侵害された場合、他のすべてのホストサイトが公開され、脆弱になります。コンテナエスケープはまれであり、ウェブ脆弱性を通じてサーバーを制御するよりも悪用するのが難しい脆弱性です。
-
柔軟性 – コンテナをプロセス分離で実行し、独自のインスタンスを持つ機能により、より詳細なネットワークオプションが可能になります。コンテナは、多くの EC2 インスタンスにわたる複雑な分散方法も提供します。アプリケーションを 1 つの IIS インスタンスに統合しても、これらの利点はありません。
-
管理オーバーヘッド – サーバー名表示 (SNI) は、管理と自動化を必要とするオーバーヘッドを作成します。また、パッチ適用、BSOD のトラブルシューティング (自動スケーリングが有効になっていない場合)、エンドポイントの保護など、一般的なオペレーティングシステム管理オペレーションに取り組む必要があります。セキュリティのベストプラクティス
に従って IIS サイトを設定することは、時間のかかる継続的なアクティビティです。場合によっては、信頼レベル を設定する必要があります。これにより、管理オーバーヘッドも増加します。コンテナは、ステートレスでイミュータブルになるように設計されています。最後に、代わりに Windows コンテナを使用すると、デプロイはより高速で、より安全で、繰り返し可能なものになります。
次の手順
レガシーワークロードを実行するために最新のインフラストラクチャに投資すると、組織に大きなメリットがあります。 AWS コンテナサービスを使用すると、オンプレミスでもクラウドでも、基盤となるインフラストラクチャを簡単に管理できるため、イノベーションとビジネスニーズに集中できます。クラウド内のすべてのコンテナのほぼ 80% が AWS 今日稼働しています。 は、ほぼすべてのユースケースに対して豊富なコンテナサービス AWS を提供します。開始するには、「AWSのコンテナ
その他のリソース
