サーバーの保守期限をきっかけに、AWSへの移行を検討する企業は少なくありません。クラウドには柔軟性という利点がありますが、現在のシステムをそのまま移すだけでは、費用や運用の負担が想定より増えることもあります。
移行を始める前に確認しておきたい項目を整理します。
移行の目的をはっきりさせる
最初に、なぜ移行するのかを明確にします。目的によって、適切な移行方法が変わるためです。
- 保守期限を迎えるサーバーを置き換えたい
- 障害時の復旧を早めたい
- アクセスの増減に対応したい
- 将来の開発を進めやすくしたい
「クラウドにすれば安くなる」と考えていても、構成や利用状況によっては、必ずしも費用が下がるとは限りません。
現在のシステムを把握する
移行対象を正確に把握できていないと、後から想定外の作業が発生します。次の項目を確認します。
| 確認項目 | 内容 |
|---|---|
| サーバーとソフトウェア | OS、ミドルウェア、バージョン、サポート期限 |
| データ | データ量、増加の傾向、バックアップの方法 |
| 連携 | 他システム、社内ネットワーク、外部サービスとの接続 |
| 利用状況 | CPU、メモリ、通信量、利用が集中する時間帯 |
| ライセンス | 商用ソフトをクラウドで利用できる条件 |
| 運用 | 監視、バッチ処理、障害時の連絡体制 |
特に、担当者しか把握していない定期処理や手作業の運用は、見落としやすい項目です。
非機能要件を決める
機能と同じくらい重要なのが、非機能要件です。少なくとも次の点は決めておきます。
- 可用性: どの程度の停止なら許容できるか
- 復旧: どの時点まで、どのくらいの時間で戻す必要があるか
- 性能: 現在と同等で十分か、改善が必要か
- セキュリティ: アクセス権限、暗号化、ログの保管をどうするか
要件を高くするほど、費用は増えやすくなります。業務への影響に合わせて、システムごとに適切な水準を決めましょう。
移行方法を選ぶ
移行方法は、大きく次のように分けて考えられます。
| 方法 | 内容 | 向いている場合 |
|---|---|---|
| そのまま移す | 構成を大きく変えずに移行する | 期限が近い、まず移行を完了したい |
| 一部を置き換える | データベースなどをマネージドサービスへ変更する | 運用の負担を減らしたい |
| 作り直す | クラウドに合わせて設計し直す | 将来の変更が多い、長く使う |
| やめる | 使っていないシステムを廃止する | 利用者が少なく、代替できる |
すべてを一度に変える必要はありません。まず移行を完了し、その後で段階的に改善する進め方もあります。
費用は構築費だけで判断しない
費用を比較するときは、月額の利用料だけでなく、次の項目も含めて考えます。
- 通信料、バックアップ、ログの保管料
- 検証環境の費用
- 監視や運用の作業費
- 移行作業と切り替えのテスト費用
移行後も利用状況を確認し、不要なリソースや過大な構成を見直せるよう、費用の管理方法も決めておきます。
切り替えと切り戻しを計画する
本番の切り替えは、事前のリハーサルが重要です。データ移行にかかる時間を測り、問題が起きたときに元の環境へ戻す判断基準と手順を決めておきます。
移行後の運用も、責任の範囲を整理します。AWSが管理する部分と、利用者が管理する部分は分かれています。OSの更新、権限設定、バックアップなど、自社で対応する項目と担当者を明確にしましょう。
まとめ
AWSへの移行を成功させるには、目的、現状、非機能要件、費用、切り替えの計画を事前に整理することが大切です。移行そのものを目的にせず、業務に合った構成を選びましょう。
