Windows アプリケーションをコンテナに移動する - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Windows アプリケーションをコンテナに移動する

概要

CNCF Annual Survey 2021 によると、組織の 96% が、インフラストラクチャをモダナイズするためにコンテナを使用または評価しています。これは、コンテナが組織のリスクを軽減し、運用効率とスピードを向上させ、俊敏性を実現するのに役立つためです。コンテナを使用して、アプリケーションの実行コストを削減することもできます。このセクションでは、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、 など、 AWS コンテナサービス全体でコスト効率の高いコンテナの実行に関する推奨事項を提供しますAWS Fargate

コスト上の利点

次のインフォグラフィックは、AWS 最適化とライセンス評価 (AWS OLA) の推奨事項に基づいて ASP.NET Framework アプリケーションを Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに統合することで、企業が達成できるコスト削減を示しています。次のインフォグラフィックは、アプリケーションを Windows コンテナに移動することで達成できる追加の削減額を示しています。

ASP.NET の統合

AWS OLA は、ビジネスが個々の t3.small インスタンスにリフトアンドシフトすることを推奨しました。以下のパフォーマンス使用率分析が示すように、オンプレミスサーバーで 7 つの ASP.NET アプリケーションを実行することで、企業はこれらの削減を達成できます。

パフォーマンス使用率分析

さらなる分析により、ビジネスはコンテナでワークロードを実行することでコストをさらに削減できることが明らかになりました。コンテナは、CPU、RAM、ディスク使用量などのシステムリソースのオペレーティングシステムのオーバーヘッドを削減します (次のセクションで説明)。このシナリオでは、7 つのアプリケーションすべてを 1 つの t3.large インスタンスに統合し、予備の 3 GB の RAM を保持できます。コンテナに移行すると、Amazon EC2 の代わりにコンテナを使用することで、コンピューティングとストレージ全体で平均 64% のコスト削減を実現できます。

コスト最適化に関する推奨事項

次のセクションでは、アプリケーションを統合してコンテナを使用することでコストを最適化するための推奨事項を示します。

Windows on Amazon EC2 のフットプリントを削減する

Windows コンテナを使用すると、より多くのアプリケーションをより少ない Amazon EC2 インスタンスに統合できるため、Windows on Amazon EC2 のフットプリントを削減できます。たとえば、ASP.NET アプリケーションが 500 個あるとします。Amazon EC2 で Windows のアプリケーションごとに 1 つのコアを実行している場合、これは 500 Windows インスタンス (t3.small) に相当します。Windows コンテナ (t3.large を使用) の使用に 1:7 の比率 (EC2 インスタンスのタイプ/サイズに応じて大幅に増加) を想定した場合、必要な Windows インスタンスは約 71 個のみです。これは、Windows on Amazon EC2 のフットプリントが 85.8% 減少することを意味します。

Windows ライセンスコストの削減

Windows インスタンスをライセンスする場合、そのインスタンスで実行されているコンテナをライセンスする必要はありません。その結果、Windows コンテナを使用して ASP.NET アプリケーションを統合することで、Windows のライセンスコストを大幅に削減できます。

ストレージフットプリントの削減

新しい EC2 インスタンスを起動するたびに、新しい Amazon Elastic Block Store (Amazon EBS) ボリュームを作成して支払い、オペレーティングシステムを格納します。これにより、コストはそれに合わせてスケールされます。コンテナを使用すると、すべてのコンテナが同じ基本オペレーティングシステムを共有するため、ストレージコストを削減できます。さらに、コンテナはレイヤーの概念を使用して、コンテナイメージのイミュータブルな部分を、そのイメージに基づいて実行中のすべてのコンテナに再利用します。前述のシナリオ例では、すべてのコンテナが .NET Framework を実行しているため、すべて中間およびイミュータブルな ASP.NET フレームワークレイヤーを共有しています。

end-of-supportサーバーをコンテナに移行する

Windows Server 2012 および Windows Server 2012 R2 のサポートは、2023 年 10 月 10 日に終了しました。Windows Server 2012 以前のバージョンで実行されているアプリケーションは、新しいオペレーティングシステムで実行するようにコンテナ化することで移行できます。これにより、コンテナが提供するコスト効率、リスクの低減、運用効率、速度、俊敏性を活用しながら、非準拠のオペレーティングシステムでアプリケーションを実行する必要がなくなります。

このアプローチで考慮すべき注意点は、アプリケーションが現在使用中のオペレーティングシステムのバージョンに関連する特定の APIs (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 インスタンスに統合しても、これらの利点はありません。

  • 管理オーバーヘッド – Server Name Indication (SNI) は、管理と自動化を必要とするオーバーヘッドを作成します。また、パッチ適用、BSOD のトラブルシューティング (自動スケーリングがない場合)、エンドポイントの保護など、一般的なオペレーティングシステム管理オペレーションに取り組む必要があります。セキュリティのベストプラクティスに従って IIS サイトを設定することは、時間のかかる継続的なアクティビティです。場合によっては、信頼レベルを設定する必要があります。これにより、管理オーバーヘッドも増加します。コンテナはステートレスでイミュータブルなように設計されています。最終的に、代わりに Windows コンテナを使用すると、デプロイはより高速で、より安全で、繰り返し可能です。

次のステップ

レガシーワークロードを実行するために最新のインフラストラクチャに投資すると、組織に大きなメリットがあります。 AWS コンテナサービスを使用すると、オンプレミスでもクラウドでも基盤となるインフラストラクチャを簡単に管理できるため、イノベーションとビジネスニーズに集中できます。クラウド内のすべてのコンテナのほぼ 80% が AWS 今日稼働しています。 は、ほぼすべてのユースケースに対して豊富なコンテナサービス AWS を提供します。開始するには、「 のコンテナ AWS」を参照してください。

その他のリソース