最新記事 builders.flash とは Developer Live Show リソースメンバー登録

Windows ワークロードをクラウドへ移行するためのベストプラクティスをグラレコで解説

2020-08-03

AWS グラレコ解説

Author : 安田茂樹

本記事では、2019 年 9 月 25 日に AWS Public Sector Summit ASEAN - Singapore にて行われたセッションの 1 つである ” Best Practices for Migrating your Microsoft Workloads to AWS (Microsoft ワークロードを AWS へ移行するためのベストプラクティス)” セッションの概要を、グラレコを使って解説します。

※ 本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。awsgeek.com は Amazon Web Services, Inc. プリンシパル・テクニカル・エバンジェリスト、ジェリー・ハーグローブが運営しているサイトです。

前回の記事では、オンプレミスからクラウドへ移行する一般的なステップについて解説しました。今回は、その中から特に、オンプレミスの Microsoft Windows Server / SQL Server を AWS クラウドへ移行する方法を解説します。

オンプレミスの Windows Server / SQL Server をクラウドへ移行するにあたり、AWS クラウドを選ぶメリットは何でしょうか？

主なメリットとしては、次のようなものが挙げられます。

AWS は、2008 年に Microsoft Windows ワークロードのサポートを開始して以来、12 年以上にわたり多数の企業の Windows ワークロードを安定して実行してきた実績があります。
2020 年 7 月現在、AWS は 175 以上のサービスを提供しており、そのうち 90 % はユーザーからのフィードバックをもとに作られたサービスです。
2020 年 7 月現在、AWS のサービスは 24 のリージョン / 77 のアベイラビリティーゾーン (AZ) で提供されており、ユーザーに最も近いリージョンを選択することで、距離に起因する遅延を最小化することができます。
EBS 最適化インスタンスを使用することで、最大 80,000 IOPS (1 秒あたりの読み込み・書き込み可能回数) を実現でき、高いパフォーマンスを達成できます。
AWS は、PCI / ISO / SOC など、90 のセキュリティ標準とコンプライアンス認証をサポートしています。

こうしたメリットにより、Amazon EC2 上で Windows Server を稼働させる法人のお客様の数は年々増え続けており、2015 年以降、5 倍に増加しました。

次に、AWS クラウドのネットワーク構成を見ていきましょう。

AWS クラウドにおける基本的なネットワーク構成要素は、次の図のようになります。

エンタープライズ (法人) の Microsoft ワークロードを AWS クラウドへ移行する場合、これらの基本構成要素に加えて、ユーザー認証やアクセス権限の設定などを行う「Active Directory (以下、AD)」をネットワーク構成に組み込む必要があります。

AWS クラウドで AD を利用するには、

AWS のマネージド型サービスである「AWS Managed Microsoft AD」を利用する
EC2 上にお客様自身で AD 環境を構築する

のどちらかを選択します。

AWS では、お客様の運用管理の労力やヒューマンエラーを軽減するため、マネージド型サービスが利用可能な場合はできるだけマネージド型サービスを利用していただくことを推奨していますが、「AWS Managed Microsoft AD」にはいくつかの制限事項もあるため、制限を回避したり、細かくカスタマイズしたい場合には EC2 上に AD 環境を構築します。

それでは次に、Microsoft ワークロードのうち、リレーショナルデータベース管理システムである Microsoft SQL ServerをAWS へ移行する方法について見ていきましょう。

移行方法としては、

EC2 上に SQL Server を構築する
AWS のマネージド型サービスである「Amazon RDS」を利用する

といった 2 つの方法がありますが、

既存の SQL Server ライセンスを持ち込みたい（BYOL）_(※)
SQL Server の冗長化機能である「Always On 可用性グループ」機能をお客様自身で設定管理したい

場合には、RDS では対応できないため、EC2 上に SQL Server を構築します。その場合、EC2 と EBS 間に独立した帯域を確保し I/O 性能の安定化を図るため、EC2 には「EBS 最適化インスタンス」を選択します。

なお、既存のライセンスを持ち込まず、新規でライセンスを購入する場合は、

EC2 インスタンスを Windows Server ベースの AMI と一緒に購入する
または
Amazon RDS for SQL Server のライセンス込みのインスタンスを購入する

ことで、初期投資無しで、ライセンス料が従量制の利用料金に含まれる形で支払いができます。

また、オンプレミスから AWS クラウドへデータベースをスムースに移行できるよう、AWS では「AWS Database Migration Service」というデータベース移行サービスを提供しています。

本サービスでは、

「SQL Server から SQL Server」といった同種のデータベース間の移行
「SQL Server から Amazon Aurora」といった異なるデータベースプラットフォーム間の移行

の両方をサポートしています。本サービスの特徴として、オンプレミスから AWS クラウドへデータベースを移行することはもちろん、AWS クラウドからオンプレミスへデータベースを逆に移行することも可能です。そのため、いざという時にはオンプレミスへデータベースを戻すこともできます。

本サービスは、データベースを 100% 利用可能な状態のまま移行を行える「ライブマイグレーション」に対応しているため、AWS クラウドへの移行を事実上ダウンタイムゼロで行えます。データ移行中にソースデータベースで行われたすべての変更はターゲットに継続的にレプリケート (複製) されるため、ソースとターゲット間で差異が発生することはありません。

オンプレミスから AWS クラウドへのデータ転送は、インターネット経由やプライベート接続の Amazon Direct Connect 経由で行うことも可能ですが、データ量が多い場合、ネットワーク帯域を占有してしまい、転送に多くの日数がかかってしまいます。

その場合は、物理的なストレージデバイスである AWS Snowball (容量 80 TB / 1 台あたり)、Snowball Edge (容量 100 TB / 1 台あたり) あるいは Snowmobile (容量 100 PB / 1 車両あたり) のいずれかを使って、クラウドへデータを移行できます。お客様のオンプレミスサーバーにこれらの物理デバイスを接続した上でデータを取り込み、その後デバイスを AWS のデータセンターへ送り、 AWS クラウドへデータを移行する形になります。

なお、全てのデータはお客様が準備したキーを使って暗号化された上で搬送されるため、機密性は保持されます。

次に、Microsoft ワークロードのうち、Windows アプリケーションの移行方法について見ていきましょう。

Windows アプリケーションの移行は、以下の 3 つの中から、いずれかの方法を選択します。実行が容易なものから順に記します。

リホスト (Rehost) : AWS Server Migration Service (SMS) を使うことで、オンプレミスの仮想マシン (VMware vSphere、Microsoft Hyper-V / SCVMM または Azure 仮想マシン) を Amazon マシンイメージ (AMI) として段階的にレプリケートし、EC2にデプロイします。マルチサーバー移行では、各サーバーを個別に移行するのではなく、アプリケーションスタック全体を移行します。アプリケーション内のすべてのサーバーを AMI としてレプリケートし、適切に起動するように調整した AWS CloudFormation テンプレートを自動生成します。
リプラットフォーム (Replatform) : コンテナを使い、アプリケーションを移行します。具体的には、コマンドラインツールである AWS App2Container を使うことで、ASP.NET Web アプリケーションをコンテナ化し、コンテナイメージをユーザー指定の Amazon ECR リポジトリに登録し、Amazon ECS および Amazon EKS デプロイ用の CloudFormation テンプレートを自動生成します。
リファクタリング (Refactor) : アプリケーションを移行するにあたり、クラウドネイティブな機能を最大限に活用するため、モノリス (単一の巨大なアプリケーション) を複数のマイクロサービス (AWS Lambda など)に分割します。また、コードの修正を伴います（例： AWS Lambda で動かすため、ASP.NET Core アプリケーションとしてコードを書き直す）。 3 つの移行方法の中で最も時間と労力を要します。なお、AWS CloudFormation テンプレートのサーバーレス向け拡張版である AWS SAM (サーバーレスアプリケーションモデル) テンプレートを使うことで、アプリケーションのデプロイを自動化できます。

移行が完了した後の運用管理方法は、大きく分けて以下の 3 つの方法があります。アプリケーションごとに最適な運用管理方法が異なるため、複数の方法を組み合わせる場合もあります。

AWS Managed Services を利用 : 大企業向けの ITIL ベースのIT運用管理サービス。変更管理、パッチ管理、ユーザーのアクセス権限の管理、インシデントの監視、バックアップとリストア、といった自動化された一連の運用管理機能を利用できます。
マネージドサービスプロバイダーを利用 : 100 を超える AWS マネージドサービスプロバイダー (MSP) パートナーがお客様に代わって運用管理を行います。
お客様自身で運用管理 : AWS Service Catalog / AWS Systems Manager / AWS Management and Governance サービス / サードパーティーのツールなどを使い、お客様自身で運用管理します。