クラウド移行、ミスしない自信がありますか？ よくある間違いとその回避策を事前に知ろう：はじめてのクラウド導入“これ“に注意（2/2 ページ）

[折笠丈侍，ITmedia]

移行計画と許容できるダウンタイム設計でありがちな間違い

　移行シナリオが決まったら、「具体的な移行手順」を決めていく。この際、アプリケーションの種類や移行手順によって「業務に与えるインパクト」が異なる。

　ダウンタイムについては、ネットワークインフラなどの制約から発生する「所要ダウンタイム」と、ビジネス上の制約から発生する「許容ダウンタイム」を考慮する必要がある。移行に当たってはビジネス上の制約の範囲内で計画することが望ましい。

　移行手順のセオリーとしては、「業務への影響度が比較的低い非基幹系のシステム」からPoC（Proof of Concept：概念実証）ベースで小規模に移行を始め、クラウドでの稼働や移行経験を蓄積し、その後に「基幹系などのコア系システム」の移行に着手するのが基本だ。

　しかし、移行に与えられた時間が限られている場合や、最初から基幹系を含めた全面的なクラウド移行に取り組む必要がある場合は、移行実績が豊富なクラウドベンダーに支援を仰ぐのも有効だ。

データ転送が終わらなくて業務が止まる

　パブリッククラウドサービスへ移行する場合、データ移行はオンラインで実行することが基本だ。オンライン移行の手段は「インターネット経由」「インターネットVPN経由」「専用線などの閉域ネットワーク経由」から選ぶことが一般的だ。

図3　オンラインでのデータ移行の概要（出典：ソニービズネットワークス作成）

　ダウンタイムに必要な時間はデータ転送完了までの所要時間が目安になるが、使うネットワークの経路や帯域によって所要時間が変わるため注意が必要だ。

　クローズドな帯域を占有できる専用線サービスや帯域保障契約が付加された閉域接続サービスを利用する場合と、帯域共有型のブロードバンド回線によるインターネット経由やインターネットVPN経由での転送の場合では、遅延やオーバーヘッドの頻度も異なる。

　企業によってはビジネスタイム中のデータ移行に帯域が使えない制約などがあるため、自社の状況を洗い出し、あらかじめサンプルデータで移行テストを行って転送時間を把握しておくことが重要だ。

　また、アプリケーションの整合性をどこまで求めるかによってもダウンタイムの制約は変わる。

　例えば、基幹業務の中心を担う「データベースの移行」は厳密なデータ管理が求められる。移行前後でトランザクションデータにずれが生じないよう、アプリケーション整合性を保った移行が必要だ。この場合は、新規アクセスの受付を停止して静止点を設け、他のデータ更新を防ぎ、その上で深夜や休日のタイミングで一気にテーブルやトランザクションログ、バックアップなどの全てのデータをクラウドへ移行することが望ましい。

　一方、ファイルサーバなどのリアルタイム性やデータの一貫性、完全性を厳しく要求されないアプリケーションは、フォルダや部署単位などで移行ステップを分解し、期間をかけて移行を実施できるだろう。

　転送完了までの所要時間が許容ダウンタイム内に収まらない場合は、移行専用の大容量物理ストレージを使った「オフライン移行オプション」を検討するのも手だ。AWSの場合は、下記のような数十TBの物理ストレージをユーザーに提供しており、それを利用して移行対象データをエクスポートすると、約10営業日前後でAWSにデータをインポートできる。

図4　オフライン移行オプションの概要（出典：ソニービズネットワークス作成）

　リホストのシナリオでは、オンプレミス上の仮想マシンイメージを丸ごとエクスポートし、それをクラウドに設置した仮想マシンイメージに変換して展開するツールや、ブロックレベルあるいはスナップショットベースのレプリケーションツールを使ってマシン全体を移行する方法もよくある。ただしこれらは静止点を設ける必要があり、“作業開始から移行完了までの時間全体”をダウンタイムとして捉える必要がある。

クラウド移行作業の役割分担の選択

　クラウド移行のステップでは、複数のプレイヤーが連携するケースがよくある。プレイヤーはユーザー、アプリケーションベンダー、クラウドベンダーの3者が大半だ。典型的な作業分担のパターンは、ユーザーがセキュリティポリシーや作業用アカウントの権限付与と作成を行って払い出し、アプリケーションベンダーがそのアカウントで移行作業を実施、クラウドベンダーは移行先の仮想マシンやネットワーク環境およびクラウドサービスの操作権限を用意する、といったものだ。

　一方で、クラウドベンダーがアプリケーションの移行までを一括で請け負うケースや、逆にクラウドに詳しいアプリケーションベンダーがクラウド環境の手配や立ち上げを一括で行うケースもある。作業分担や操作権限の準備なども、移行ステップの重要な要素だ。

移行したらアプリが動かないことも？　API連携、IPアドレスなどの注意点

　一般的なクラウドサービスは、さまざまな機能を提供するサービスが個々に独立して稼働しており、クラウドアプリケーションはそれらの機能をネットワークを介してAPIで連携（疎結合アーキテクチャ）する仕組みを利用する。

　つまり、移行前の環境が単一ハードウェア内で複数サービスをモノリシックに密結合させたアーキテクチャの場合は、大きな設計変更が必要になる。また、クラウドサービスのIPアドレスやMACアドレスは、デフォルトでは動的に付与される（具体的には再起動の度に変動する）ので、仮にユーザーが外部公開サーバ用に固定IPアドレスを割り当てたり、一部ソフトウェアのライセンス認証に仮想NICのMACアドレスを固定したりする必要があるケースでは、固定オプションを取得した上で追加の設計が必要となる。

　クラウドでの運用は、サービス側が動的にIPアドレスを割り当て、サービスが持つDNSサーバが名前解決を行うのが基本なので、もし移行前のアプリケーションが特定のIPアドレスを指定した設計になっている場合は考え方が大きく変わる点にも注意が必要だ。

　さらに、オンプレミス環境で利用しているグローバルIPアドレスをクラウド側に持ち込むことや、データセンターとオフィス間の接続でよく行われるプライベートIPアドレス体系の延伸（L2型延伸）も、クラウドサービスでは利用できない（VMware Cloud on AWS など、ベアメタルベースのリソース占有型サービスなどで例外あり）。

忘れがちな”組織面での変化”　クラウド生かすためには協力が大事？

　クラウド移行を計画する上では、システム面の計画だけでなく組織面での調整も欠かせない。特にクラウドの仕様を基にした財務、セキュリティやコンプライアンス部門との事前調整は重要だ。

　またクラウド移行を単なるシステム移行ではなく、クラウドを生かした価値創出につないで成果を出すには、経営層やさまざまな部門の代表者などをメンバーにして構成されるCCoE（Cloud Center of Excellence）と呼ばれるクラウド活用推進組織を社内に立ち上げることもポイントとなる。

　これによりスムーズな移行が期待できるだけでなく、クラウド移行後の組織に合った運用ポリシーを定め、組織的にクラウド活用サイクルを回すことができ、より高い付加価値を得られるだろう。

　次回の第3回では、クラウド移行後の「クラウド設計・構築フェーズ」でのつまずきポイントを紹介する。