AWS へのシステム移行の要点 (後編)

本ブログの位置づけ

AWS Customer Solutions Manager の山崎です。本ブログは現状オンプレミス上での多くの IT 資産が稼働しており、AWS への移行を考えたい、エンタープライズのお客様向けに記載しています。
オンプレミスからAWS への移行は評価、計画、移行、運用/最適化のフェーズに分かれます。本ブログは計画～移行のフェーズにおいて、個々のシステム群の移行をどのような切り口で整理するべきかを前編／後編でまとめています。ここでいう個々のシステム群の移行とは、システムを構成するリソースであるアプリケーションサーバー、データベース、ファイルサーバーの移行を指します。

前編では、AWS へのシステム移行検討のアプローチとして、移行パターンの整理およびデータ転送経路の確保パターンについて整理しました。後編では、リソースごとの移行方法や活用できる AWS サービスについてご紹介していきます。

3. 移行に利用するサービスの識別

移行リソースごとに利用可能なAWS サービスを紹介していきます。リソースの種類や移行方法によって、最適なAWS サービスは変わります。お客様が移行したいリソース、準備状況、獲得したい効果、スケジュール感などを踏まえ、移行方法とあわせて利用するサービスを明確にしましょう。

3-1. アプリケーションサーバー移行

アプリケーションサーバーをどのように移行するのかは、移行パスによって異なります。ここではリホスト、リロケート、リアーキテクチャの3 つのパターンで整理します。

オンプレミスからシステム構成を大きく変更せずにリホスト (リフト＆シフト) する場合は、手動で移行する手段と自動で移行する手段があります。
運用の効率を高めるために OS やミドルウェアの最新化、パッケージ設定の整理やセットアップ・テストの自動化を付随して実施する場合は、手動での移行を考えます。
最新化やセットアップ作業が不要の場合、自動での移行が可能です。自動での移行には AWS Application Migration Service (AWS MGN) を利用します。AWS MGN は、移行元のサーバーにエージェントをインストールすることで、移行先であるAWS に環境をレプリケーションすることができます。ソースサーバーを物理、仮想、またはクラウドのインフラストラクチャから AWS でネイティブに実行するように自動的に変換することにより、AWS への移行を簡素化および迅速化します。

既存オンプレミスの vSphere ワークロードを AWS にリロケートする場合、VMwareCloud on AWS が利用できます。VMware Cloud on AWS により、VMware ベースのデータセンターと AWS 間で相互運用可能なインフラストラクチャとサービスが提供されるため、複雑な環境の管理を避け、関連するリスクを最小限に抑えることができます。

移行と同時にアプリケーションをリアーキテクチャしてモダナイズする場合は、AWS Lambda や AWS Fargate といったサーバーレスプラットフォームが移行先として視野に入ります。この場合、アプリケーション自体をサーバーレスプラットフォームにあわせて変更するため、難易度は最も高くなります。得られる効果として、ビジネスアジリティの向上、運用負荷の削減、コストの最適化などがあります。

3-2. データベース移行

データベースは、一般的に顧客情報や商品情報などのマスタデータ、受注処理や入出金処理などのトランザクションデータを格納するために使用され、システムの基盤となります。

本章ではデータベースの中でも、オンプレミスのシステムで一般的に使われているリレーショナルデータベースについて記載します。
データベース移行には、システムが許容できる停止時間を見極めます。十分な停止時間をとれる場合は、一括移行が可能でなるべくシンプルな移行方式を選択します。ソースデータベースとターゲットが同一エンジンであればダンプツール (Oracle の移行の場合は Oracle Data Pumpなど) 、異なる場合は CSV アンロードを使用します。
許容できる停止時間に余裕がない場合は、差分移行が可能な移行方式を選択します。移行方式には、ソースデータベースとターゲットデータベースが同一エンジンでかつ純正のツールが使える場合はレプリケーション (Oracle の移行の場合は Oracle GoldenGate など)、それ以外の場合は AWS Database Migration Service (AWS DMS) を使用します。差分移行方式では、ダウンタイムを最小限にすることが可能ですが、一括移行方式に比較すると、難易度が高くなるため、事前の調査や検証、リハーサルなどを計画してください。

AWS-18：AWS のサービスを使ったオンプレミスからのデータベース移行

ダンプツールによる移行

データベース移行では、ダンプデータを転送しロードする方法がシンプルで確実です。停止時間を短縮する場合は、一括移行後に差分データを追加ロードすることが基本方針です。ダンプデータをロードする場合、データベースエンジンの純正ツールを使い、オンプレミスから AWS へデータを送りロードをします。移行先には一時的な領域とデータファイルの領域が必要です。

CSVアンロードによる移行

異なるデータベースエンジン間でデータベースを移行する際には、一般的にCSVのアンロードとロードが利用できます。オンプレミスのデータベースでは、SELECT 文などを使用して CSV 形式のファイルを作成し、それを AWS に送り、AWS 側でロードを行います。この移行方法では、ダンプファイルを使用する場合と同様に一時的な領域が必要です。CSV アンロードは、より柔軟な移行方式である一方、データ型 (LOB など) やデータ (制御文字など) によって CSV 化が難しい場合や、ダンプツールと比較して性能が劣る場合もありますので、利用範囲は限定的です。

レプリケーションによる移行

データベースベンダー純正のレプリケーション機能を利用することで、ダンプツールや CSV アンロードによるデータ移行よりもサービス停止時間を短縮できます。利用可能なライセンスやレプリケーション機能のノウハウがある場合には、純正レプリケーション機能 ( Oracleの移行の場合は Oracle GoldenGate や Oracle マテリアライズドビュー ) を検討してください。利用するレプリケーション機能については、各ベンダーのマニュアル等を参照し、事前調査や各種テストを計画してください。

AWS Database Migration Service (AWS DMS) による移行

AWS Database Migration Service (DMS) は、異なるデータベースエンジン間や同じエンジン内でのデータ移行を容易にするサービスです。AWS DMS はデータの抽出、変換、ロードを行い、既存の構成変更を最小限に抑えながらデータベースの移行を可能にします。AWS DMS はすでに存在するテーブルにデータをロードするという動きをするため、あらかじめテーブルやインデックスなどの各種オブジェクトを事前に作成する必要があります。これらの作業は、AWS Schema Conversion Tool (AWS SCT) が利用可能です。AWS DMS を活用することで、短時間で安全かつ柔軟なデータベース移行が実現可能です。ただし AWS DMS は、柔軟な移行方式である一方、ソースデータベースとしての制限とターゲットデータベースとしての制限の双方があるため、プロジェクト初期フェーズでの確認が重要です。また、ソースデータベースのワークロードによっては同期性能が低下する場合やデータが正しく移行されない場合 (例: 文字コード変換による文字化け、制御文字の扱いなど) があるため、PoC (Proof of Concept) や各種テストを計画してください。

3-3. ファイルサーバー移行

ファイルサーバーのデータは、従来の転送プロトコルを使用して Amazon EC2 に転送できます。また、Amazon Simple Storage Service (Amazon S3) やマネージドファイルストレージサービスの移行方法も紹介します。

Amazon S3 へのデータ移行

Amazon S3 へのファイル転送方法について説明します。移行方式はオンラインとオフラインの2 つがあります。オンラインマイグレーションでは、AWS SDK や AWS CLI を使用して Amazon S3 の API を直接利用する方法がシンプルです。また Amazon S3 のPrivateLink や AWS Direct Connect を使用すれば、パブリックネットワークネットワークを経由せずにオンプレミスから Amazon S3にファイルを転送できます。AWS Transfer Family を使用すれば、従来の FTP や SFTP などのプロトコルを使用して、データを Amazon S3 へと転送することができます。これにより、オンプレミスのサーバーのソフトウェア構成を変更せずに AWS 上にデータを送ることができます。オフラインマイグレーションでは AWS Snowball Edge または AWS Snowcone を使用し、大量のファイルを Amazon S3 に転送することも可能です。

マネージドファイルストレージサービスへのデータ移行

オンプレミスの Windows ファイルサーバーや NFS サーバーを AWS へ移行する方法について説明します。移行先としては、Amazon EFS (NFS プロトコル) 、Amazon FSx for OpenZFS (NFS プロトコル)、Amazon FSx for Windows File Server (SMB プロトコル) 、Amazon FSx for NetApp ONTAP (NFS、SMB などのプロトコル) が利用できます。オンラインマイグレーションに利用できるツールとして、AWS DataSync がご利用できます。また、SnapMirror や robocopy などのオンプレミスでも使い慣れたツールもご利用できます。オフラインマイグレーションでは AWS Snowball Edge または AWS Snowcone を使用し、データの一括移行と差分のネットワーク転送を組み合わせます。移行対象データの量やネットワーク状況に応じて適切な方法を選択しましょう。AWS Snowball Edge を利用した場合、大量のデータをオフラインで転送できるメリットがあるものの、メタデータが保持されない可能性があるため、プロジェクト初期フェーズでの確認が重要です。

4. 移行に付随するその他の作業

ここまでは主に、サーバー、データベース、データ (ファイル) に関する移行方法という技術的側面を説明してきました。実際にプロジェクトとしてシステム移行を考慮すると、サーバーやデータを移行する以外にもタスクがあります。これらのタスクは、従来のオンプレミス間でのシステム移行と大きく変わるものではありませんが、AWS を利用することで、各種テストなどの効率化が可能です。

4-1. アプリケーションテスト

サーバーやデータを AWS へ移行した後は、移行したシステムの主要な機能をテストして、正常に動作していることを確認します。ユーザーが期待通りにシステムを利用できるかどうかを確認し、必要な修正や調整を行います。また、移行後のシステムのパフォーマンスをテストして、応答時間や処理能力などが要件を満たしているかどうかを確認します。
AWS であれば、移行したサーバーの Amazon Machine Image (AWS AMI) を取得し、そこからサーバーを複製することで複数の環境を作成し、並列で検証、テストを行うことが可能です。

4-2. システム移行時のサポート体制

システム移行のトラブル発生時のサポート体制や連絡体制の構築も重要です。ユーザ部門、システム部門、関連するシステムの関係部門などトラブルが発生した際の連絡体制を構築してください。AWSでは、本番切り替えなどの重要なイベントを実施する際に、IEM (Infrastruture Event Managerment) という特別なサポートを受けることが可能です。

4-3. 移行後の正常稼働の評価

本番運用を開始した後に、システムが正常に稼働していることの評価を行います。業務アプリケーションのイベントに合わせて、移行直後、週次バッチ後、月次バッチ後などのタイミングで、エラーの発生状況、性能やリソースの使用状況に問題がないかを確認します。
AWSはオンプレミス環境と比較して柔軟性に優れています。仮に、性能やリソース問題で性能チューニングが行われる期間中、一時的にリソースが必要になった場合にも柔軟に追加が可能で、性能チューニング完了後、不要なリソースを削減することも可能です。

5. まとめ

ブログでは、オンプレミスから AWS への移行について、移行パターンの整理における切り口、データ転送経路やシステム移行をサポートする多様な AWS サービスを解説しました。移行パターンの整理や停止時間の考慮など、移行のポイントを押さえて十分な準備を行い、効率的かつスムーズな移行を実現しましょう。

カスタマーソリューションマネージメント統括本部
カスタマーソリューションマネージャー (CSM)　山崎徹、甲斐裕之

参考リンク

Amazon Web Services ブログ