Amazon Web Services ブログ
AWS でのレガシー .NET Framework モノリシック アプリケーションのモダナイゼーションへの道すじ
組織は、顧客のニーズに基づいて最適な技術ソリューションを提供することを目指しています。クラウド導入のどの段階にいようとも、結局多くの企業はモノリシックアプリケーションの管理と構築を行うことになります。これには多くの課題があります。モノリシックアプリケーションの内部構造により、開発者がコードを管理するのが難しくなります。そのため、新たな開発者は習得に時間がかかり、コストも増加します。モノリスでは、複数のチームが1つの大規模なリリースを調整する必要があるため、共同での作業や知識の引継ぎの負担が増えます。ビジネスが成長するにつれて、モノリシックアプリケーションでは、拡大するユーザーからの要求を満たすのに苦労する可能性があります。これらの懸念に対処するには、お客様は、ビジネス上および技術上のニーズを満たすために AWS クラウドでアプリケーションをモダナイズする準備ができているか評価する必要があります。
ここでは、ウェブ層、.NET Framework を使用するアプリケーション層、Microsoft SQL (MSSQL) Server リレーショナルデータベースを使用するデータ層という、モノリシックな 3 層アプリケーション (MVC パターン) をモダナイズするアプローチについて説明します。.NET アプリケーションのモダナイゼーションには、リホスト、リプラットフォーム、リファクタリングという 3 つの主要な方法があります。この意思決定マトリックスに従って、お客様固有の要件に基づいて移行方法を評価および決定することをお勧めします。このブログでは、軽量コンテナとしてパッケージ化され、目的別データベースに支えられた、疎結合なマイクロサービスを設計するためのリプラットフォームとリファクタリング戦略に焦点を当てます。
モダナイゼーション ジャーニー
組織のモダナイゼーションアプローチの成果により、顧客の要求に合わせて最適に拡張できます。モダンなアーキテクチャという目標を達成すると同時に、スケーラビリティ、メンテナンスのしやすさ、迅速なデプロイメントサイクル、コストの最適化に取り組むガイド付きアプローチについて詳しく見ていきましょう。
これには次の 4 つのステップが含まれます。
- モノリスを分割する
- アプリケーションをコンテナ化する
- .NET 6へリファクタリングする
- 目的に合わせた、低コストのデータベースエンジンに移行する
1. モノリスを分割する
アマゾン ウェブ サービス (AWS) クラウドへの移行には多くの利点があります。これらには、市場投入までのスピードとビジネスの俊敏性の向上、新たな収益機会、コスト削減などが含まれます。最大限に活用するには、モノリシックアプリケーションをマイクロサービスにリファクタリングして、組織のアプリケーションを継続的にモダナイズする必要があります。
モノリシックアプリケーションをマイクロサービスに分解するには技術的な課題があり、既存のコードベースとビジネスドメインのコンテキストをしっかりと理解する必要があります。モノリシックアプリケーションを段階的にマイクロサービスやその他の分散設計に変換するには、いくつかのパターンが役立ちます。ただし、コードベースをリファクタリングするプロセスは手動であり、リスクが高く、時間がかかります。
開発者が変換を加速できるように、AWS は AWS Microservice Extractor for .NET を提供しています。これにより、アプリケーションの設計とリファクタリングをより小さなコードプロジェクトに分解できます。AWS Microservice Extractor for .NET によって、当社のパートナーである Kloia がお客様のモダナイゼーションジャーニーを加速し、モノリスを解体するのにどのように役立ったかをご覧ください。
次のモダナイゼーションへの道すじは、アプリケーションをコンテナ化することです。
2. コンテナ化する
なぜコンテナに移行すべきなのでしょうか？ コンテナは、複数の環境でアプリケーションのビルド、テスト、デプロイ、再デプロイを実施するのに役立ちます。具体的には、 Docker Containers はアプリケーションコンポーネントをまとめて、1 つのビルド成果物としてパッケージするための信頼性の高い方法を提供します。モダンなアプリケーションは、依存関係、バイナリ、システムライブラリなど、コード以外にもさまざまな要素で構成されていることが多いため、これは重要です。従来の.NET Framework アプリケーションをコンテナに移行すると、オペレーティングシステムの使用率を最適化し、実行時の一貫性を実現できます。
このプロセスを加速するには、これらのアプリケーションを AWS App2Container (A2C) を使用して Windows コンテナにコンテナ化します。A2C は、.NET および Java アプリケーションをコンテナ化されたアプリケーションにモダナイズするためのコマンドラインツールです。A2C は、仮想マシン、オンプレミス、またはクラウドで実行されているすべてのアプリケーションのインベントリを分析して構築します。コンテナ化するアプリケーションを選択すると、A2C はアプリケーションの成果物と特定された依存関係をコンテナイメージにパッケージ化します。ここでは、A2C を使い始めるためのステップバイステップの記事とセルフペースのワークショップを紹介します。アプリケーションをコンテナ化したら、Amazon EC2 を使用して Windows コンテナで Docker をホストして、自ら管理することができます。Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (Amazon EKS) を使用することもできます。これらは完全に管理されたコンテナオーケストレーションサービスであり、基盤となるインフラストラクチャに煩わされることなく、アプリケーションの構築と管理に集中できます。「Amazon ECS と Amazon EKS の比較:AWS コンテナサービスの理解」 をお読みください。
次のセクションでは、モダナイゼーションのシナリオでコストを最適化する際に重要な 2 つの側面について説明します。
- Windows サーバ上でワークロードを実行する際のライセンスコスト
- SQL サーバーのライセンスコスト
3. .NET 6へリファクタリングする
Windows のライセンスコストに対処するには、.NET Core を採用し、Linux コンテナ用 Dockerfile を使用して Linux 環境に移行することを検討してください。GoDataFeed社をはじめとする多くのお客様は、.NET Framework アプリケーションを最新の.NET 6 に移植して AWS 上で実行することでメリットを得ています。.NET チームは、 .NET 6 を使用してパフォーマンスを大幅に向上させました。これには Linux でのソケットのパフォーマンスが 30 ～ 40% 向上したことも含まれます。ARM64 固有の最適化を.NET ライブラリで行い、お客様が AWS Graviton で実行できるようにしています。
また、 AWS Lambda (.NET 6 ランタイムをサポート) を使用してサーバーレスオプションに切り替えるか、サーバーレスの従量課金制コンピューティングエンジンである Fargate を使用して ECS でコンテナを実行することもできます。AWS Graviton2 プロセッサを搭載した AWS Fargate は、 x86 Intel ベースのインスタンスと比較して、コストを最大 20% 削減し、パフォーマンスを最大 40% 向上させることができます。アプリケーションの基盤となる仮想マシン (VM)、オペレーティングシステム、ストレージ、およびパッチを完全に制御する必要がある場合は、 Amazon EC2 Linux インスタンスで.NET 6 アプリケーションを実行します。これらは最新世代のIntelおよびAMDプロセッサーを搭載しています。
お客様がアプリケーションを.NET 6 に迅速に移植できるように、AWS は Porting Assistant for .NET に.NET 6 のサポートを追加しました。Porting Assistantは、.NET Framework (3.5+) アプリケーションをスキャンしてターゲットとなる.NET Coreまたは.NET 6 の互換性評価を生成する分析ツールです。これにより、必要な作業に基づいて移植するアプリケーションに優先順位を付けることができます。.NET Framework アプリケーションから互換性のない API やパッケージを特定し、既知の代替品を見つけます。このプロセスを説明するデモ動画を参照してください。
4. SQL Server から低コストのデータベースエンジンへの移行する
AWS では、特定のニーズに適した、ユースケース駆動型のスケーラブルな分散型アプリケーションを構築することを推奨しています。データベースの観点から見ると、AWS は多様なデータモデルをサポートするために 15 種類以上の目的別エンジンを提供しています。さらに、マイクロサービスアーキテクチャは疎結合を採用しているため、個々のマイクロサービスはそれぞれ独立して独自のデータストアから情報を保存および取得できます。サービスごとにデータベースパターンをデプロイすることで、アプリケーションやビジネス要件に最適なデータストア (リレーショナルデータベースまたは非リレーショナルデータベース) を選択できます。
このブログでは、SQL Server に代わるリレーショナルデータベースに焦点を当てます。SQL Server のライセンスコストに対処するために、お客様はオープンソースのリレーショナルデータベースエンジンへの移行を検討できます。Amazon Relational Database Service (Amazon RDS) は MySQL、MariaDB、PostgreSQL をサポートしています。移行パスが明確に定義されているPostgreSQLに焦点を当てます。Amazon RDS は 2 種類の Postgres データベースをサポートしています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL 互換エディションです。参考までに、「私にとって Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL のどちらが適していますか？」をご覧ください。
Amazon RDS を採用するかどうかが決まったら、次の質問は「自分にとって適切な移行戦略は何か」です。 次の点を考慮してください。
- スキーマを変換する
- データを移行する
- アプリケーションをリファクタリングする
スキーマの変換
AWS Schema Conversion Tool (SCT) は、既存のデータベースをあるエンジンから別のエンジンに変換するのに役立つ無料のツールです。AWS SCT は、Microsoft SQL Server、Oracle、MySQL など、さまざまなソースデータベースをサポートしています。Amazon Aurora PostgreSQL 互換エディションなどのターゲットデータベースエンジンから選択することも、Amazon S3 を使用してデータレイクをセットアップすることもできます。AWS SCT には、ソースデータベースとターゲットデータベースに直接接続して現在のスキーマオブジェクトを取得するグラフィカルユーザーインターフェイスが用意されています。接続すると、データベース移行評価レポートを生成して、変換作業とアクションアイテムの概要を確認できます。
データ移行
スキーマの移行が完了したら、ソースデータベースからターゲットデータベースにデータを移動できます。アプリケーションの可用性要件に応じて、簡単なジョブを実行して、移行元にある既存データを新しいデータベースにコピーできます。または、既存データをコピーし、新しいデータベースに切り替える準備が整うまで、すべての変更を継続してレプリケーションするツールを使用することもできます。そのようなツールの 1 つが、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他のタイプのデータストアの移行に役立つ AWS Database Migration Service (AWS DMS) です。
AWS DMS では、既存データの移行を実行でき、さらに進行中の変更を複製してソースとターゲットの同期を保つことができます。ソースデータベースとターゲットデータベースが同期したら、データベースをオフラインにして操作をターゲットデータベースに移動できます。プレイブックについては「Microsoft SQL Server To Amazon Aurora with PostgreSQL Compatibility」 をお読みいただくか、このセルフガイドワークショップを利用して SCT と DMS を使用して PostgreSQL 互換データベースに移行してください。
アプリケーションのリファクタリング
データベースエンジンには大小様々な違いがあり、MSSQL Server から PostgreSQL などの新しいデータベースエンジンに移行するには、コードのリファクタリングが必要になります。最初のデータベース移行が完了した後、アプリケーションコードを手動で書き直し、データベースドライバーを切り替え、アプリケーションの動作が変更されていないことを確認するには、多大な労力が必要です。これには、アプリケーションコードに大幅な変更を加えると、エラーが発生するリスクが伴います。
AWS は、アプリケーションを SQL Server から Amazon Aurora PostgreSQL 互換エディションに簡単に移行できるように、Babelfish for Aurora PostgreSQL を構築しました。Babelfish for Aurora PostgreSQL は Amazon Aurora PostgreSQL 互換エディションの新機能です。これにより、Aurora は Microsoft SQL Server 用に作成されたアプリケーションからのコマンドを理解できるようになります。Babelfishを併用することにより、Aurora PostgreSQLは Microsoft SQL Server独自のSQL言語であるT-SQLを解釈できるようになりました。同じ通信プロトコルをサポートしているため、元々SQL Server用に作成されたアプリもAuroraで動作するようになりました。「SQL Server から Babelfishsh for Aurora PostgreSQL に移行する方法」についてお読みください。Babelfish Compass tool を実行して、アプリケーションに現在BabelfishでサポートされていないSQL機能が含まれているかどうかを確認してください。
図 1 は、このブログで説明したモダナイゼーションパスの適用前と適用後のアプリケーションの構成を示しています。アプリケーション層は Amazon ECS Fargate クラスター (または AWS Lambda 関数) で実行されるマイクロサービスで構成され、データ層は Amazon Aurora (PostgreSQL を推奨) で実行されます。
図 1. モダナイズされたマイクロサービスベースのリアーキテクチャ
まとめ
この投稿では、モノリシックな.NET Framework アプリケーションを AWS のモダンなマイクロサービスベースのスタックに移行する方法を示しました。モノリスをマイクロサービスに分割し、アプリケーションをコンテナ化する AWS ツールについて説明しました。また、Linuxベースのシステムに移行し、オープンソースのデータベースエンジンを使用することによるコスト最適化戦略についてもお話ししました。モダナイゼーション戦略について詳しく知りたい場合は、この規範ガイドをお読みください。