Amazon Web Services ブログ

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

本ブログの位置づけ

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

【移行全体のフェーズと本ブログの位置づけ】

本編に入る前に、AWS の移行における全体像と本ブログの位置づけを記載します。上図は AWS 移行全体のフェーズと、必要なワークストリームをクラウド導入フレームワーク (AWS CAF) の観点で整理した図です。AWS への移行では、まず評価フェーズから始まり、移行に係る総保有コストの分析 や準備状況評価、移行戦略と移行パス (7R) の策定などを実施します。次に計画フェーズでは推進組織を立ちあげ、PoC (Proof of Concept、概念検証) や、移行計画策定を実施します。そして移行フェーズで IT 環境を整備したうえでシステム移行を実行し、運用/最適化フェーズにて運用の自動化などを実施します。本ブログは、移行計画の中でシステムごとの移行方法を確立し、IT 環境を整備する際に参考となる情報として位置づけられます。なお、その他のワークストリームで必要な情報は以下のブログもご参照ください。

AWS へのシステム移行検討のアプローチ

システム移行では、個々のシステムが求められる要件、サービスレベル、リソースの種類を踏まえ、4 つのステップで進めます。 1. 移行パターンを整理し、2. データ転送経路を確保したうえで、3. 利用可能なAWS サービスを選択し、4. 移行と付随する作業を実行します。
従来のオンプレミスにおける移行では、物理的な制約からシステム停止時間が長くなる、人手を介することから人的ミスの混入が避けられないなどの課題がありました。しかしAWS が用意するサービス群を利用することで、効率よくスピーディに移行を実現できます。
一方で、移行時のシステム要件やサービスレベルの整理が不十分なままに移行方法を決めてしまうと、ビジネスに大きな影響を及ぼしたり、多大な工数・コストを費やしたりするリスクもあるため、システムの特性を踏まえて十分な検討を重ねましょう。

1. 移行のパターンの整理

システムの移行方針を考えるうえで、まず移行作業中にシステムが許容できる停止時間を見極めます。停止時間が長いほど、作業時間の確保が可能です。短時間しか停止が許されないシステムであれば、データの整合性を確保するための複雑な考慮が必要となります。これらは既存システムのサービスレベルや非機能要件をインプットに検討します。
また、システムの規模とトラブル時の影響範囲の大きさも考慮が必要です。規模の大きいシステムではトラブル時のリスクを極小化するため、一度に移行するのではなく移行単位の分割が選択肢に入ります。

1-1. 一括移行

一括移行は、既存システム全体を停止しシステムを一度に移行します。通常、規模の小さいシステムの移行で採用されます。システム停止中に移行作業を行うため、一般的に停止時間が長くなります。既存システムにデータが流入しないため、データ静止点が明確で整合性が担保しやすく、移行作業自体の難易度は低くなります。
許容されるシステムの停止時間が短く、すべてのデータを停止時間中に移行できない場合、差分移行を検討します。差分移行は、移行作業を複数のステップに分割し、データのスナップショットをあらかじめ新環境に転送しておきます。移行開始後に既存システムを停止し、転送したスナップショットから最新のデータまでの最終差分のみを停止時間中に新環境に反映します。最終差分を反映する時間だけがシステム停止時間となります。

1-2. 分割移行

大規模なシステムの移行では、システム全体を一度に移行すると停止時間の長期化や、トラブル時にビジネスに与える影響範囲が大きいリスクがあります。そのため、構成する機能ごとに移行する分割移行が選択肢となります。システムの停止時間は、機能のサービスレベルによって異なります。外部顧客に影響する機能はシステム停止時間を短くする必要がある、社内向けの機能は長い停止時間を確保できる、などです。機能ごとの依存関係を考慮して移行するため、移行難易度は高くなります。
分割パターンは様々です。例えばフロントシステム、ミドルシステム、バックエンドシステムと分割して各々を移行する、特定の業務や商品に関連する機能だけを移行し、特殊性の高い業務・商品を後から移行する、などです。

2. データ転送経路の確保

オンプレミスから AWS への移行において、AWS へのデータ転送経路をどのように設定するのかを考えます。データ転送経路は、転送速度、移行着手までのリードタイム、転送するデータ容量、回線・機器コストを考慮して検討します。

2-1. ネットワークによるデータ転送

専用線接続

AWS への専用ネットワーク接続には AWS Direct Connect が利用できます。AWS Direct Connect は専用線で独立した専用のネットワークであり、帯域が保証されているため安定したデータ転送が可能です。ただし、設置のためのリードタイムが長いため、十分な準備期間をとる必要があります。また、回線・機器コストがかかる点に注意が必要です。あらかじめ帯域を確保できているため、移行に要する時間を精緻に見積もる必要がある場合の選択肢となります。AWS Direct Connect デリバリーパートナー経由で払い出すことで、より柔軟で幅広い選択肢を利用できます。

インターネット接続

移行は専用線だけでなく、インターネットを経由して実行することもできます。ただし専用線接続と比べて帯域が確保されておらず、ベストエフォートでの転送となります。AWS VPN を利用することで安全かつ柔軟にデータを転送できます。AWS Direct Connect よりも短期間で設置可能であり、VPN 接続費用も安価です。移行開始までの期間が限られている場合や、設置コストを安価に済ませたい場合の選択肢となります。ただしデータ転送にかかる時間を事前に読み切ることができないため、移行完了までの時間を精緻に見積もりたい場合には向いていません。

2-2. 物理デバイスでのデータ転送

移行完了の目標時間に対して利用できるネットワーク帯域が十分でない場合や不安定な場合、またアーカイブデータの移行には、オフラインデバイスを活用することができます。AWS Snowball Edge や AWS Snowcone は、安全で堅牢なデバイスを提供するサービスです。AWS のコンピューティング機能とストレージ機能を提供し、AWS との間でデータを転送できます。マネジメントコンソールからジョブを作成すると、後日指定した住所に発送されます。移行作業時間には物理デバイスの発送時間や対象環境へのコピーなどの時間を考慮する必要があります。

まとめ

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

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