この記事は『クラウドへワークロードを移行するための手順』という記事のうち、移行に向けた調査フェーズを詳細に説明した記事になります。
全体像が知りたい方は下記をご覧ください。
なぜ移行前の調査が必要なのか
まずは、移行作業に着手する前になぜ調査をすべきなのか、理由を説明します。
技術的な理由
クラウドは万能の技術ではありません。オンプレミスとは違い、絶えず技術は新しくなっていきますので、古いOSやミドルウェアは載せ替えることができません。
具体的にはWindows Server 2008などサポートが切れたOSを新たにクラウド上で構築することはかなりの制約が発生してしまいます。
また、極端に大きなストレージなども、移行不可能でないにせよ手段が限られることがありますので注意が必要です。
こうした、技術的な観点から事前のアセスメントが必要になります。
ビジネス上の理由
ビジネスの状況いかんによっても移行は左右されます。
例えばユーザが絶えず利用するサービスなのでデータ移行や切り替えのタイミングがシビアであるというような場合、メンテナンス等に合わせて作業を進める必要がありますので移行が遅くなりがちです。
特にユーザデータなどを持つDBサーバは切り替えが難しいため、Webサーバなどに比べて後回しにされることがよくあります。
こうしたサーバについては、内外で十分なヒアリングが必要になります。
また、この調査フェーズ自体が、典型的には1~4ヶ月程度の期間を要します。移行しなくても最低限のコストはかかりますので、それも織り込んでおく必要があります。
費用とマンパワーからの理由
移行作業は、調査や実験も含めて一時的にコストが増大しがちです。
このコストとは金銭的なものだけでなく、時間や、新しい技術の習得コストも含んでいます。
予めリスクと必要なリソースを見積もり、スケジュールを立てなければプロジェクト自体が立ち行かないばかりか、他のシステムの運用にも支障をきたすことがあります。
移行前調査のフレームワーク
ここからは、上記の観点をベースに、具体的にアセスメントを進めるための手順について考えていきます。
フレームワークについては、大きくビジネス観点とテクノロジー観点に分けることができます。
ビジネス観点
ビジネス観点でのアセスメント責任者は、主にCEOやCFOです。場合によってはHRの責任者の手も借りる必要があるでしょう。
基本的に判断すべきは下記のような図に表すことができます。


もちろん、これらの試算は後述の技術的な調査後にしか判明しませんし、将来的なリスクを完全に算出できるものではありません。
しかし、こうした数年単位でのロードマップを引くことで、経営的な判断がしやすくなることは事実かと思います。
また、上記の図ではいわゆる基幹システムを想定しコストメリットの点から妥当性を計っていますが、クラウドに習熟することにより、ユーザの目に触れるようなサービス面での開発効率が上がるなどの効果も判断材料に加えるべきです。
テクノロジー観点
次にテクノロジーの観点からの調査事項です。本稿ではこちらの方にやや重きを置いて説明しています。
移行作業
移行作業に伴う技術的な調査は最も時間を使うべきポイントです。事前にリスクを洗い出しておくことで、POCや本番移行作業での手戻りを減らすことができます。
■ワークロードの移行
ワークロードの移行にあたっては、かなり細かくかつ多項目にわたって情報の収集が必要になります。
サーバOSのバージョンや搭載されているソフトウェアはもちろん、停止していい時間やデータ容量によっても移行の優先順位と難易度が変わってくるためです。
本来はIT資産台帳などがあるべきですが、そういった物が無い場合はいい機会ですので調査と整理をおすすめします。
例えば、下の表のような観点で情報を取得すると良いでしょう。
項目 | 内容 |
全体情報 | サーバ名 |
システム名 | |
用途 | |
システム重要度 | |
利用人数 | |
停止して良い時間 | |
提供ベンダ | |
システム情報 | OS種別 |
IPアドレス | |
Database | |
DB以外のミドルウェア | |
アプリケーション/パッケージ | |
開発言語/フレームワーク | |
所轄部署 | |
サーバ情報 | 物理 or 仮想 |
仮想化技術 | |
BIOS | |
CPU | コア数 |
メモリ | メモリ容量 |
ディスクドライブサイズ | 割当量 |
ドライブ数 | |
OSサイズ | |
DBサイズ | 使用量 |
データ転送量 | 送信データ量 (MB/月) |
サーバー用途 | 本番/開発・検証 |
連絡先 | HW/MW購入元 |
ソフトウェア購入元 | |
社内連絡先 |
■データの移行
個人情報や取引情報がビジネス上大きな価値を占める企業では、データの移行にも細心の注意を払う必要があります。
データの容量が小さい場合はオンラインでのデータ転送を選択することができます。例えばAzure Site Recoveryや、AWS Data Syncなどが該当します。
これらのサービスはマイグレーションに向けてチューニングがされており、データの移行の際のセキュリティや効率があらかじめ織り込まれているため、切り替え当日のリスクとダウンタイムを最小化することが可能です。
また、オンプレミスとクラウドを接続し、データ移行する際に、いわゆる専用線サービスを使うこともできます。通信がインターネットを経由しないメリットがありますが、回線の帯域によっては時間がかかってしまうことがあります。
データの容量が数十~数百TBある、または速度的にオンライン移行を選択できない場合、オフラインでのデータ移行をせざるを得ません。
これは文字通り筐体付きのストレージでオンプレミスからデータを抽出し、クラウド上へ吐き出すベンダサービスです。
当然、データの差分等も大きくなりますので当日および事後の移行作業が大きくなります。
ビジネスとコストの要件を適切に見極め、移行サービスを選定する必要があります。
アカウント管理とセキュリティ
一部のセキュリティは移行後に検討することも可能ですが、ミッションクリティカルなシステムではたとえ短期間でもセキュリティリスクを抱えておけませんので、事前の設計が必要です。
また、仮想ネットワークなどの設計は後から変更する負荷が大きいため、これも事前に決めておくべきでしょう。
その他、検討項目は下記のような点になります。
- リソースへのアクセス権限付与と管理
- さらにリスクベース認証
- 組織構造とアカウントの紐付け
- 不正ログイン等の際の検知機能
- 仮想ネットワークの設計
- リソースの冗長化設計
- 通信およびデータ暗号化
- Key Vaultによる鍵管理
- 各レイヤでの攻撃対応
運用
運用に関しては比較的後からでも追加や変更が可能です。
監視のためのツールとしてはCloudWatchなどベンダ純正のツールもありますが、Zabbix、DataDog、Prometheusなどサードパーティツールも充実しています。
また、既にオンプレミスの運用監視基盤(日立のJP-1やNRIのSenjuなど)をお持ちの企業もあるかと思います。
そうした場合は、2つの運用基盤の統合や、インシデント発生時のスキームを予め決めておきましょう。
検討項目は下記のようなものがあります。
- インシデントレベルの設計
- インスタンス死活監視
- インスタンス稼働状況監視
- URL監視
- データベース監視
- 障害対応のスキーム設計
- エスカレーション
- 有事の際の対応
- 請求と支払い

まとめ
この記事では、クラウドへの移行を考える際の、既存IT資産の情報収集と整理について説明しました。
実際のところ、クラウド移行への落とし穴としては、オンプレミスで使っているソフトウェアがクラウドに載らないことや、停止時間、データ移行方法などが頻繁に見られます。
POCで手を動かしながら試すのもありと言えばありですが、躓いたときに個々の調査が発生するため、事前に情報を集めておくのが結局最も効率が良いケースが多々あります。
正確にROIをはかるためにも、事前の情報収集はじっくりと進めたいものです。
今回は以上です。お読みいただきありがとうございました。
コメント