ツールを使ったAWSへのサーバー移行の考察

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。

今回はツールを使ったサーバー移行について考えてみます。

企業内の基幹システム、情報システムをクラウドへ移行する方法や手段は どのようなものがあり、自社のシステムには何が最適であるかを判断する助けになれば幸いです。

なお、残念ながら以下には言及しません。 予めご了承ください。

• クラウド移行プロセスの説明
• クラウド移行全体から見た課題や問題点
• 移行ツールのメリデメ表、コスト比較
• 移行ツールの操作手順
• AWS アーキテクチャの設計・設定

おさらい 6つのアプローチ

ご存知の方も多いと思います。 クラウド移行の6つのアプローチをおさらいします。

本エントリは Rehost をメインにしています。

それでは移行ツールを考えていきます。

SMS

まずはサーバー移行から。

AWS Server Migration Service

VMware vSphere または Windows Hyper-V 上の仮想マシンを EC2 へ移行 (レプリケーション) するサービスです。 Connector をオンプレミス環境にデプロイします。 Connector が仮想マシンイメージ (VMware でいうスナップショット) を AWS へ転送し、AMI を作成します。 (Azure 用の Connector もあるようです)

利点

SMS 自体は無料です。 SMS でレプリケーションをすると EBS スナップショットが作成されます。 また、データ転送先に S3 を一時的に使用します。 そのため、EBS スナップショットと S3 の利用料金は別途かかります。

各サーバーの変更 (エージェントインストールなど) は発生しないので 本番稼働中のサーバーに対する影響が少ないのが特徴です。

数時間おきにレプリケーションするようスケジュールを組むと 増分レプリケーションが可能です。

留意点

執筆日時点ではデータ転送経路に DirectConnect を選択することが出来ません。 オンプレミス環境から AWS へはインターネットを経由することになります。

SMS 自体にネットワーク帯域制御機能はございません。 複数台のレプリケーションを計画の場合は、ネットワーク帯域圧迫による 既存システムへの影響を考慮ください。

SMS でレプリケーションした EC2 には 一つの仮想ネットワークインターフェイスが割り当てれます。 オンプレミス環境で複数のネットワークインターフェイスを使用して運用している場合にはご留意ください。 また、仮想ネットワークインターフェイスは DHCP による IP アドレス割当になります。

Linux の場合は SSH、Windows の場合は RDP を有効にしてください。 iptables や Windows Firewall、セキュリティソフトウェアで ブロックされないように設定変更します。 レプリケーション前にオンプレミス環境で設定変更が必要ですので 既存のセキュリティポリシーをよく考慮してご判断ください。

Windows ドメインに参加している場合は、RDP 用のローカルユーザーを追加しておくと安全です。 (よくハマるポイントです)

CloudEndure

2019年6月11日から CloudEndure Migration が無料で利用可能に なりました。

Endure の発音は Google 翻訳 でご確認ください。 カタカナで書くと、「エンドァ」「エンドゥァ」が近いでしょうか・・

オンプレミスの各サーバーにエージェントをインストールします。 エージェントがサーバーのディスク上のデータブロックをレプリケーションします。

AWS にもレプリケーション先の他に CloudEndure サーバーが必要です。

利点

データ転送経路に DirectConnect が使用可能です。 ※エージェントと CloudEndure コンソールとの通信にインターネット接続が必要です。

エージェントが送信に使うネットワーク帯域を制御することが可能です。

サーバー切り替え時間をぎりぎりまで短くしたい場合の選択肢になります。

留意点

全サーバーにエージェントが必要です。 移行対象台数が多いと手間になります。

エージェント型なのでコンピューターリソースを少々消費します。(CPU で見ると数％)

レプリケーション先とは別に CloudEndure サーバーが必要で その分の EC2 費用と管理が発生します。

Linux の場合は SSH、Windows の場合は RDP を有効にしてください。 iptables や Windows Firewall、セキュリティソフトウェアで ブロックされないように設定変更します。 レプリケーション前にオンプレミス環境で設定変更が必要ですので 既存のセキュリティポリシーをよく考慮してご判断ください。

Windows ドメインに参加している場合は、RDP 用のローカルユーザーを追加しておくと安全です。

サーバー移行方式

サーバー移行という観点で SMS と CloudEndure を調べてみました。 これらを使ったサーバー移行はどのように行えばいいでしょうか。 主に二通りの方式が考えれます。

増分移行

SMS や CloudEndure で継続的に増分レプリケーションをしておき 本番移行直前にサービスを停止し静止点を取って 完全な形で同期をとる方式です。

継続的な増分が効率良く行われていれば 最小時間で切り替えを完了できる可能性があります。 ※実際には複数回の移行リハーサルを実施して切り替え時間を計測します。

増分移行は活性状態でのデータレプリケーションですので、 整合性が必要なシステム、DB サーバーなどは移行後の動作にご注意ください。

/var/run/pid ファイルを起動時にチェックしているようなアプリケーションは 移行後に pid ファイルの削除が必要になる可能性があります。 (アプリケーション起動状態でレプリケーションされるため)

さらに注意しなければならないのは オンプレミス環境をそのままクラウドへ移行しなければならないということです。

クラウド上でちょっとした設定変更をしたり AWS ならではの機能、例えば、Systems Manager や CloudWatch 、EC2 Launch をフル活用したい場合は そのための設定作業工数も計画しておく必要があります。 (フェーズ2など)

仮想化基盤を AWS に移しただけでは費用対効果を示しにくくなります。 AWS のマネージドなサービスをフル活用して 運用にかかる手間や工数を削減することが AWS を使う大きな利点だと考えます。 増分移行を行う際には十分な議論をお願いします。

Migration Once DataSynchronize Many

略して MODM。 私が思いついた造語ですので検索しても出てこないと思います。

レプリケーションはあるタイミングで一度切り実施、 その後はアプリケーションに必要なデータのみを差分でコピーしていく方式です。 オンプレミス環境のハードウェアリプレースでよくやる方式ではないでしょうか。

この方式であれば、クラウド移行後に設定変更を行うことが可能ですし、 AWS ならではの機能をフル活用していくことが可能です。

ただ、既存アプリケーションで追加開発を継続中の場合には アプリケーション開発は凍結するか、二重デプロイを行うなどの工夫が必要になります。

データコピーも台数が多くなっていくと、作業費用が発生したり 作業ミスも起きてくるところです。

サーバーを重要度で区分して、重要度が高いサーバー群は MODM で、 それ以外は一旦増分移行を行い次フェーズで ”AWS ならでは機能” を使うように構成していくという ハイブリッドなサーバー移行がベターだと考えます。

DMS

次にデータベース移行を考えていきます。

AWS Database Migration Service

特別なドライバーやソフトウェアを必要することなく オンプレミスのデータベースから AWS 上のデータベースへデータレプリケーションを行います。

同一プラットフォーム同士だけではなく、異なるプラットフォーム (Oracle から PostgeSQL) 間のデータレプリケーションも可能です。

利点

商用 RDBMS のネイティブレプリケーションを使うことなく データレプリケーションが可能です。

RDS へのレプリケーションも可能なので Replatform の実現には必須と言えるサービスです。

一度フルレプリケーションしてしまえば 増分レプリケーションを行えますので切り替え時間を短縮することが可能です。

留意点

DMS からオンプレミスのデータベースへは 強めの権限を持ったユーザーで接続します。 自社のセキュリティポリシーと照らし合わせてご判断ください。

オンプレミスのデータベースで設定変更が必要な場合があります。 例えば、アーカイブログモードを有効にする、復旧モードを Full にするなど。

少なくない制限事項があります。 AWS Database Migration Service とは をよく読んで制限事項を事前にご確認ください。

DMS からオンプレミスのデータベースへ読み込みが発生します。 パフォーマンスの影響は PoC で必ずご確認ください。

DMS 自体にネットワーク帯域制御機能はございません。 ネットワーク帯域圧迫による既存システムへの影響を考慮ください。

ネイティブ機能を使った DB 移行

RDBMS のネイティブは機能を使ってデータ移行します。 DataPump などでエクスポートしたり、ネイティブなレプリケーション機能を使います。

利点

ネイティブな機能なので安全にデータ移行が可能です。 技術者にもオンラインにもナレッジが溜まっているので心理的にも安心出来ます。

留意点

エクスポートの場合はデータ移行に時間がかかります。 エクスポートにかかる時間、データコピーにかかる時間、インポートにかかる時間の それぞれを計測して計画をたてます。

ネイティブなレプリケーションは別途ライセンスが必要になる可能性があります。 レプリケーション系のライセンスをお持ちではない場合には慎重にご検討ください。

VMware Cloud on AWS

説明不要ではないでしょうか。 VMware Cloud on AWS

VMware vSphere ベースのオンプレミス環境を AWS 上のベアメタルへ移行し稼働させるサービスです。 EC2 と同じように S3 や SQS などの AWS サービスが利用可能です。

利点

オンプレミスの VMware 環境を移行することも出来ますし ”拡張” として利用することも可能です。

AWS のセキュアで可用性に優れたインフラストラクチャを利用できる点も利点です。

留意点

効果を出すにはある程度の規模が必要です。

クリーンインストール

おまけ的な要素ですが、クリーンインストールでのサーバー移行も選択肢に入ります。

まっさらな EC2 を起動し、そのうえに必要なアプリケーションやパッケージをインストールします。 一通りのセットアップが完了したらデータ移行を行います。

オンプレミスのハードウェアリプレースなどでよくある方式だと思います。

利点

AWS 提供の AMI を使えば AWS で使用するために最適化された状態で OS がインストールされます。 前述した Systems Manager や EC2 Launch などが該当します。

AWS によって提供されサポートされる Amazon Linux を使用することも容易になります。

クリーンインストールにより、最新の OS、ミドルウェア、アプリケーションを使用可能です。 機能面、セキュリティ面で大きなアドバンテージです。

留意点

手間も時間もかかります。 外部ベンダーに作業依頼する場合は別途費用もかかります。

ソフトウェアライセンス

クラウド移行を行う場合は、各種ライセンス条項をよくご確認ください。

オンプレミスのライセンスがクラウドでそのまま使えるか否かを 販売代理店にご確認ください。 既存の契約に影響がある場合は、関係各所との調整が必要になるかもしれません。

Windows Server、RedHat、SUSE などの商用 OS も要確認です。

移行期間中の二重起動 (同じライセンスがオンプレミスとクラウドで起動する) が許容されているかは難しいところです。 ここも事前にご確認ください。

クラウド上でのライセンスが NG であったり、追加ライセンスが必要になると思わぬ出費が発生します。

何を選んでよいか悩んでいる場合には

まずは SMS、DMS を試してみるのが良いと思います。 影響が少なさそうな開発環境のサーバーを見繕って クラウド移行を試しながら、検証・計測を行っていきます。

アプリケーション機能としての動作検証のほか 運用を見据えて AWS の色々なサービスを組み合わせみると 良い検証が出来ると思います。

クラウド移行で、誰もが幸せになるシステム運用が実現できることを期待しています。

参考

AWS SMS とは Server Migration Service & Application Discovery Service CloudEndure Migration CloudEndure Documentation AWS Database Migration Service とは AWS Database Migration Service

以上、吉井 亮 がお届けしました。