1．はじめに

2014年9月のIDC調査[1]によると，「2018年のプライベートクラウド市場規模は2013年比3.7倍の1兆6,026億円」と予想されており，さらなる拡大をみせている．こうしたクラウド環境への移行のように，ITシステム基盤を旧環境から新環境に刷新する際には，すでに稼働している業務システムとそのデータの移行を伴う．一方で仮想化技術が発展した今日では，ハードウェアやOS（Operating System）を仮想化することで，ITシステム基盤の更改時に，アプリケーションの移植やデータの変換を必要としない移行が可能となってきている．このようなITシステム基盤の移行におけるデータ移行方法の選択が，企業のビジネス損失を最小化させるための重要な検討事項となる．

こうしたデータ移行方法は，既存で稼働しているITシステム基盤，新規に構築する基盤，そしてそれらの基盤が提供する機能で実現される．その転送方法や移行単位について，お客様業務の停止可能時間など，ビジネスや技術的な要求を十分考慮した上で採用する手段を検討する必要がある．また，決定したデータ移行方法は，移行後の運用でデータコピーやバックアップ方法として利用されることもあり，移行後の運用についての要求も考慮する必要がある．

従来でもデータ移行の重要性[2]からさまざまな取り組みが検討されてきた．例として，Matthes，Schulz，Hallerらは，データ移行のプロセスモデルを整理している[3]．しかしながら，データベースに限定した議論であり,移行方法の選択方法については,リスク軽減の観点でのみ触れるにとどまっている．Morrisはデータ移行戦略の立案方法を整理し，活用方法を述べている[2]．しかしながら，移行方法の選択を含む移行設計については抽象度が高く，実行可能な移行方法を選択するプロセスまでは議論されていない．またLussem，Harrachは，データ移行の検討エリアを整理し，TOGAF^®☆1のADM（Architecture Development Method）を活用したデータ移行プロジェクトの標準的な進め方を整理し，移行方法の選択に必要となる要求について議論した[4]．しかしながら，それぞれの要求を考えたうえで，複数考えられる移行方法から実行方法を選択する具体的な方法には至っていない．以上のように，Morris[2]やLussem，Hurrach[4]の既存の提案では，移行方法の選択を検討する方法については議論されていない．

そこで本稿では，データ移行方法検討の中で，要求から順序だてて具体的に移行方法を選択するためのプロセスを提案し，事例を通して検証した結果を報告する．そのために，まず第2章では，データ移行方法の選択要素，評価方法を定義し，データ移行方法選択プロセスを提案する．次に第3章で，実践した3つの事例を取り上げて，有効性と実行可能性の検証結果を報告する．

2．データ移行方法選択プロセスの提案

2.1　データ移行方法の選択要素の定義

移行方法の決定においては，システムを構成するOSなどのシステムデータや業務データをどのように移行するかを設計する必要がある．その設計要素としては，「データ転送方法」，「データ転送単位」，「データ転送階層」の3つの要素を本稿では定義する．これらの3つの要素は，互いに独立の関係ではなく，1つの要素を選択することによってほかの要素の選択が絞られるという従属の関係にある．それぞれの要素について順に説明する．

要素の1つ目の「データ転送方法」とは，既存環境のデータを異なる拠点に移動させるための方法を意味する．この「データ転送方法」は，災害時の業務継続性の観点と類似する[5]．ただし，移行においては業務停止が必ず発生する点，業務停止の時間に作業失敗時の切り戻しを含める点，さらに物理搬送を最終階層とした点に違いがある．「データ転送方法」は，大分類として新環境と旧環境を同時に稼働させる新旧同時稼働，新旧切り替え，バックアップ・リストア，物理搬送の4分類とした．4分類は，さらに9つの小分類に分割した（表1）．

表1の分類は，Tier9からTier1まで業務停止時間の短さの順番で並べている．ここで，旧環境から新環境へ切り替えるために旧環境を停止した後のデータ転送の前処理に要する時間を$T_p$，データ転送に要する時間を$T_t$，転送後に新環境でサービス提供を開始するための後処理に要する時間を$T_a$とする．新旧の環境切り替えにかかる時間，つまり業務停止時間$T$は(1)式とする．

$T=T_p+Tt+T_a$ 　　　　(1)

なお移行には移行作業当日以外に要する環境の構築等の時間，業務停止を伴わない当日作業の時間は含めない．表1の説明欄に，$T$を見積るための時間$T_p$ ，$T_t$ ，$T_a$の該当する作業や見積要素を記述する．

要素の2つ目の「データ転送単位」は，データのグルーピングの階層を意味する（図1）．この「データ転送単位」を5つに分類した．まず環境全体を1回で移行する環境単位，次に生産管理システムといった業務システム単位である．

さらに，システム単位から詳細にすると，Webサーバといったサーバ単位，サーバが使用するボリューム単位，さらにボリューム内のファイル単位に区分した．

要素の3つ目の「データ転送階層」は，データの移行を実施するシステム階層を意味する．「データ転送階層」は，そのシステムを構成するシステム階層に準じる．たとえば OSを仮想化している環境では，アプリケーション，ミドルウェア，仮想OS，ハイパーバイザ，ストレージといった階層が挙げられる（図2）．たとえば要素2の「データ転送単位」でボリューム単位での移行とした場合でも，仮想マシンで論理ボリュームとして移動するのか，ハイパーバイザで仮想ディスクファイルとして移動するのか，ストレージから論理ディスクとして移動するのか，といったように実装する階層ごとに移行方法が存在する．

2.2　データ移行方法の評価

移行方法は，ステークホルダからのビジネス，技術双方の観点での要求の充足により評価する．要求の例を表2に挙げる．表2ではBusiness Analysis Body Of Knowledge^®(BABOK^®)☆2の要求の分類に対応するITシステム基盤移行における要求例を整理した[6]．ここでのビジネス要求はデータ移行方法を選択するためのビジネスニーズや目標，ステークホルダ要求はビジネス要求を達成するためのステークホルダからの要求，そしてソリューション要求はデータ移行方法が持つべき能力を表す．また移行要求は，データ移行方法を実装するための要求を表す．

2.3　データ移行方法選択プロセスの提案

前節までに整理した移行方法の選択要素と評価の関係を整理する．移行方法を概念モデルとして図3で表現した．移行方法は，3つの選択要素の集約として決定する．選択要素は，互いにいずれかの指定により他の要素の選択肢を制限する関係にある．ただし「データ転送方法」の決定による制限が大きい．それぞれの選択要素は要求事項により決定する．特に移行で重要視する業務停止可能時間やコストといったビジネス要求，ステークホルダ要求を，まず「データ転送方法」選択の要因と考えた．次に主としてソリューション要求が，「データ転送単位」や「データ転送階層」の選択の要因とした．

移行方法の概念モデルは，「データ転送方法」が設計上の重要なポイントとなり，他の要素を制限することを明示している．これらの要素間の関係性から，移行方法を選択するプロセスを図4で表現した．

図4のプロセスでは，まず要求事項の優先順位を明らかにし，「データ転送方法」を絞り込む．このときの「データ転送方法」の絞込みには，業務停止可能時間の要求を用いて，表1の「データ転送方法」からTierの範囲を絞る．次に，絞り込まれたTierを実現する移行方法を構成する具体的な製品と製品機能を整理する．この整理には「データ転送方法」と「データ転送単位」を組み合わせたワークシートを使用すると移行方法案の列挙が容易になる（表3）．次に各Tierの移行方法ごとに，要求に対する評価を整理する．最後に，整理した移行方法の評価から，要求の充足を比較し，移行方法を決定する．

以上のように，具体的に整理された移行方法の選択プロセスを使用することで，系統立てた移行方法の検討を可能とした．たとえば，一般的な仮想化環境は本稿で定義した5種類の「データ転送単位」と5種類の「データ転送階層」に区分でき，「データ転送方法」も9種類すべてが存在し得る．そのため，単純計算で9×5×5=225種類の「データ移行方法」がある．さらに225種類の「データ移行方法」には実装可能な技術・製品が複数存在し，検討すべき「データ移行方法」を実装する組合せは数百となり，すべてを比較・検討することは難しく，選択のミス，あるいは大きな工数をかけてしまうといった可能性がある．提案したデータ移行方法の選択プロセスを使用することで，初期のデータ転送方法の絞込みで最大1/9にまで候補を削減し，その後の「データ転送単位」，「データ転送階層」の検討も，網羅的かつ論理的に検討を進めることを可能とする．具体的なプロセスの進め方とワークシートの使用方法は，次章の実践事例を通して説明する．

　

3．データ移行設計の実践事例

データ移行方法選択プロセスに従ったデータ移行を3件のプロジェクトで実践し，実行可能性と有効性を確認した結果を報告する．また事例を通して，具体的なプロセスの進め方と，使用するワークシートを説明する．

なお事例1，2は表1の大分類における新旧切り替えの事例，事例3はバックアップ・リストアの事例である．また「データ転送階層」として，事例1はストレージ，事例2，3はOSでの移行であった．それぞれの検討で「データ転送方法」のすべてのTier，および「データ転送単位」，「データ転送階層」に対する候補の絞込みを実施した．

3.1　事例1：サービス間でのデータ移行

1つ目の事例は，A社が提供するインフラストラクチャ基盤サービスを，新規に構築した企業内クラウドサービスへ移行するプロジェクトであった．移行先の環境では，異機種複数のストレージ装置を単一ストレージとして利用することができるストレージ仮想化装置を使用しており，移行元の環境にもストレージ仮想化装置が存在した．規模は，バックアップを除くデータ容量が約6TB，事業継続に重要な10システムの移行であった．業務データ部分に対して実施した移行方法の検討を，図4に示したデータ移行方法選択プロセスに従い説明する．

3.1.1　要求事項の優先順位付け

ステークホルダへのヒアリングから，要求事項を識別し，優先順位を評価した（表4）．なおビジネス要求はステークホルダ要求，ソリューション要求，移行要求に展開するが，ここではステークホルダからの主要な要求事項のみを扱う．

3.1.2　データ転送方法の絞込み

要求のなかで最も優先順位の高い業務停止可能時間に基づきTierの範囲を絞り込んだ結果，2日間の業務停止可能時間を満たす「データ転送方法」は，正副切り替えもしくは同時稼働により停止時間をきわめて短くすることが可能なTier9～6であった．

3.1.3　移行方法案の検討

移行方法案の検討では，まず「データ転送単位」について検討した．既存業務への影響度合い，業務停止可能回数から，システム単位の移行とした．システム単位の移行では，システム間連携をどの程度考慮するべきかを検討する必要がある．対象とした環境では，各システムは独立していたため，移行作業が他システムの既存業務へ影響を与える可能性はなかった．ただし，システムは複数台のサーバで構成されており，同一システム内でのサーバ間で，移行時の整合性確保に注意が必要であった．

次に，移行機能を実装する階層の検討を行った．データ移行に要するコストの要求から，移行のための投資が難しく，既存機器の機能を利用する必要があったため，コピー機能を持つソフトウェアやハードウェアの新規導入は不可能であった．このため，既存機器のストレージ仮想化装置もしくはOSの機能を利用することにしたが，Tier9，6に該当する移行方法は存在しないため，これらは除外した．

これらの検討結果で絞り込んだTier8，7に対応する具体的な移行方法案を，表5に列挙した．表5は「データ転送方法」に対して，「データ転送単位」ごとに方法が列挙されている．表5では，ストレージ仮想化装置が提供する非同期遠隔コピー機能は，ボリュームからシステム単位での転送を実現することを示している．

3.1.4　移行方法案の比較と決定

表5に示した各移行方法案について，移行方法案比較シートを用い，3.1.1で整理した要求に基づいて評価を行った（表6）．

列挙した移行方法案においてrsyncとnfsコピーの2つの方法については，データ転送効率が低く，移行作業を2日間に収めることにはリスクがあるため，ビジネス要求において不十分と判断した．一方，ストレージ仮想化装置の非同期遠隔コピー機能を使用する場合，既存機器のSANルータの圧縮機能を用いてデータ転送を行うことが可能であり，1回あたりの作業につき2日間以内の停止時間とすることが可能であり，リスクが低いと判断し，移行方法として採用した．

3.2　事例2：ファイルサーバ統合

2つ目の事例は，複数拠点に点在するファイルサーバ群を，一拠点の企業内クラウドサービスに移行したプロジェクトであった．

移行元環境は全国複数拠点に設置された物理サーバ上の仮想化されていないファイルサーバであった．各ファイルサーバはOS，バックアップソフト，バックアップメディアが統一されておらず，ファイルサーバとしての整理および統合もクラウドサービスへの移行の中で行われる計画となっていた．

移行先のプライベートクラウドは仮想化環境で，ストレージ仮想化装置をデータストアとして使用しており，移行元の環境とは1Gbpsのネットワークで接続されていた．移行元のデータ容量は合計31TB，移行先のサーバは2台の仮想サーバであった．次節より移行方法の検討を順に説明する．

3.2.1　要求事項の優先順位付け

ヒアリング調査を通じて，要求事項の優先順位を評価した（表7）．表7では要求のカテゴリーごとに上から優先順位の高い順に要求を並べている．最も優先順位が高い要求は，データ移行作業所要時間（業務停止可能時間）で，移行時に許容された停止時間はフォールバックを含め土日の2日間であった．また，複数のファイルサーバを整理・統合する観点から，フォルダ単位での移行を可能とする必要があった．

3.2.2　データ転送方法の絞込み

まず，要求の中で最も優先順位の高い，業務停止可能時間に基づきTierの範囲を絞り込んだ．機器搬送およびテープ搬送を伴うTier3～1は，2日間ではサービス停止からバックアップ取得，搬送，リストア，サービス再開までを完了できない拠点が多いため除外した．次に，データ移行に要するコストに基づきTierの範囲を絞り込んだ．移行元環境はバックアップソフトおよびメディアが統一されておらず，レプリケーションの機能もないため， 追加コストが発生するTier5，4は実現不可と判断した．Tier9，8は，移行元・先の機器，およびアプリケーションで相互のレプリケーション機能の対応を持たないため実現不可とした．

3.2.3　移行方法案の検討

絞り込んだ「データ転送方法」のTier7，6に対して移行方法案を，「データ転送単位」について検討した．移行対象はファイルサーバのみであり，システム環境全体の移行は不要であった．そのため「データ転送単位」としては，ファイル，ボリューム，サーバを挙げた．これらの「データ転送単位」に対して，ハイパーバイザやストレージの階層での移行方法はなかったため，仮想OS以上での移行方法案を列挙した（表8）．

3.2.4　移行方法案の比較と決定

表8で列挙した移行方法案に対して要求事項で比較した結果を表9に示す．

Tier7を実現する分散ファイルシステムは，移行元サーバの中にサポートしていないOSバージョンがありバージョンアップを要する点が移行要求を充足しない．物理サーバで稼働しているOSを仮想サーバへ移行する「P2Vツール」は，一度ボリュームイメージ単位でコピーした後，ファイルコピーツールでフォルダの再配置を行う必要があることに対し，「ファイルコピーツール」の場合，最初からフォルダ配置先を変更してコピーができ，ファイルサーバとしての整理および統合ができ，業務停止時間をより短くすることができるため優位と判断した．

結論として，ファイルコピーツールを使用したデータ移行方法を採用した．

3.3　事例3：クラウドサービスへの移行

3つ目の事例は，自組織のサーバをクラウドサービスに移行したプロジェクトであった．

移行元環境は複数システムを構成する約150台のサーバで構成する分散システム環境で，物理サーバ上の仮想化されていないサーバ，および仮想化されているサーバの混在環境であった．移行先は仮想化されたパブリッククラウドサービスであった．移行先，移行元の環境間は運用管理のためのネットワークで接続されていたが，データ移行のためのネットワーク敷設はなかった．次節より，移行方法の検討を順に説明する．

3.3.1　要求事項の優先順位付け

ヒアリング調査を通じて，要求事項の優先順位を評価した（表10）．最も優先順位が高いビジネス要求は，移行時のデータ保護で，ネットワーク接続，およびデータ転送において，通常業務で想定されない接続方式と漏洩リスクのある大容量のデータ転送は許可されなかった．また移行作業にかかる時間にも要求があり，移行時に許容された停止時間はフォールバックを含めて3日間であった．また，サーバ単位での移行が可能であることも要件として挙げられた．

3.3.2　データ転送方法の絞込み

まず，要求の中で最も優先順位の高いデータ保護の必要性の要求に基づきTierの範囲を絞り込んだ．ネットワーク経由での転送が不可であるため，Tier9～4は除外した．次にサーバ単位での移行の要求から，物理搬送を行うTier1は，移行元環境には仮想化されていないサーバも含み，仮想化環境への移行を物理搬送により行うことは不可能なため，対象外と判断した．業務停止可能時間は，物理的な距離からTier3とTier2でも要求を充足した．

3.3.3　移行方法案の検討

絞り込んだ「データ転送方法」のTier3，2に対する移行方法案を，「データ転送単位」について検討した．「データ転送単位」の要求はサーバ単位での移行であったため，それを可能とするサーバ，ボリューム，ファイルでの選択肢を列挙した．「データ転送階層」は物理サーバが含まれた環境であることから，OSでの移行方法案を挙げた（表11）．

3.3.4　移行方法案の比較と決定

表11で列挙した移行方法案に対して要求事項で比較した結果を表12に示す．

Tier3を実現するデータバックアップは，事前に移行先のクラウドサービス上にOSを構築し，移行時にデータリストアを実施する必要があった．そのため，事前作業，およびリストア後のデータの確認が必要となり，移行における作業が煩雑となることから，業務停止時間に対するリスクがあった．一方，Tier2でのシステムバックアップツールでは，事前のOS構築やリストアデータの確認は不要であるが，OS種別ごとに移行手順が異なった．そのため，ステークホルダ要求である「サーバ種別ごとに移行手順を変えない」を満たせなかった．最後にP2Vツールを使用した移行であれば，すべてのOSで同じ移行手順となるため，要求を充足すると判断した．結論として，P2Vツールを使用した物理媒体搬送によるデータ移行方法を採用した．

3.4　事例の考察

ミドルウェアやアプリケーションを問わない環境全体の移行（事例1），ファイルサーバの統合を伴うOS単位のデータ移行（事例2），バックアップ・リストアと物理搬送を伴うクラウドサービスへの移行（事例3）を説明した．事例1ではTier8の非同期遠隔コピー機能を用いたストレージミラーを選択し，業務停止時間が2日間，追加コストを不要とする要求を満たした．環境全体の移行に対して，他候補としたTier7での実装は業務停止時間を充足しないリスクが高かった．事例2ではTier7のファイルコピーツールを使用したソフトウェアミラーを採用した．データ再配置を可能とするこの移行方法が，サーバを統合する目的を満たし，業務停止時間などの要求を満たした．事例3ではTier2のP2V形式データの物理メディア搬送の方法を選択した．データ保護の要求から，事例1，2で選択されたネットワーク経由でのデータ転送は候補とならず，移行作業標準化の要件も満たす移行方法を選択した．なお，各事例は選択した移行方法により成功裏に移行を完了することができた．

各事例では，まず優先順位の高いビジネス要求で「データ転送方法」のTierを大きく絞り込むことができた．事例1では移行作業時間の要求でTier9～6に，事例2では同要求からTier9～4となり，さらにコストの要求から選択可能なTierを絞り込んだ．事例1ではハードウェアの機能からビジネス要件の充足にリスクが低く，既存環境の機能を有効活用できるTier8の移行方法を採用した．事例2ではTier8を実現する機能がなく，データ配置を実施する目的から最適なTier7の移行方法を採用した．Tier8を実現する機能があったとしても，データ配置の事後作業の必要性から優位な移行方法とはならない．事例3ではデータ保護の要求によるネットワークの制約からTier3～1に絞ることができた．このように「データ転送方法」が大きく絞り込まれることにより，それを実現する「データ転送単位」，「データ転送階層」の検討対象も絞り込まれる．さらに移行元，移行先の技術的な制約を受けて候補となる「データ転送単位」，「データ転送階層」は限定される．移行方法の評価で網羅的に要求に対する長所，短所を検討することを容易とした．

4．おわりに

ITシステム基盤を刷新する際のデータ移行方法は，複数の要求事項への考慮が必要である．本稿では，このデータ移行方法を選択するための要素とその関係性を整理し，実施すべきプロセスを提案した．また提案した方法を適用した3件のプロジェクトを報告した．実践したプロジェクトでは，提案したプロセスにより，要求事項からの移行方法の絞込みが可能となり，提案した方法の実行可能性と有効性を検証することができた．事例はストレージ，OS，バックアップツールを用いた移行であったが，提案した方法は移行を実現する階層を問わず活用することができる．今回提案したプロセスにより，確実なデータ移行を実現する設計をより簡易に進められるようになることを期待する．

謝辞　事例プロジェクトをまとめるにあたり多大な協力をいただいた西田景子氏，またプロジェクトを進めるにあたりご協力いただいた関係者の皆様に感謝いたします．