AWSのクラウド環境への移行で必要な考え方、事前準備や移行時の注意点などをお伝えする「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」の連載です。
前回の「計画と実行」では移行に必要な手順でおさえておきたいポイントやTIPSをご紹介しました。今回は「移行本番の切り替え」について移行の本番でのポイントを紹介します。
連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」
【1】事前調査・移行ツール
【2】 計画と実行
▶【3】 移行本番の切り替え
【4】AWSへの移行事例
担当者の連絡体制とフローをきめておく
システム切り替えの当日は、連絡体制の構築が非常に重要です。システム切り替え作業に関わる担当者の連絡先や連絡する手段などを事前にまとめておきましょう。連絡を取りにくい時間帯があるようなら、それも制約として計画に含めておくとより確実です。また、トラブルがない場合にも作業の進捗状況は原則として同報通知を行うのが良いでしょう。特に作業する場所が物理的に離れている場合にあるケースですが、誰がどこまで作業が進めているのかが共有できてないと、後続タスクの作業者の作業進捗に影響が出てくる可能性もあるためです。
AWS移行支援サービスを解説！
このようなお悩みや疑問ありませんか？
・AWSへ移行時のトラブルが不安
・AWSの移行は何から始めるの？
・AWSへ移行したいが、他の業務で手が回らない
移行時体制の構築の作業ステップをまとめる
作業ステップをまとめておきます。ポイントは連絡を取り合うタイミングと判断ポイントを先にきめておくことです。とくに切り戻しの判断タイミングと、基準の設定が重要です。
万が一移行作業に問題が起きたとき、切り戻しの判断が遅れてしまうと、結果的にサービスの停止時間が伸びて業務影響が大きくなってしまうこともあるため、注意が必要です。
作業ステップ例
| 項番 | 作業内容 | 担当 | 想定時間 (単位：分) |
連絡 | 備考 | |
|---|---|---|---|---|---|---|
| 0 | システム連携先への停止通知 | ○○ | – | – | ○○→関係各社 | 事前作業 |
| 1 | システムの閉塞処理 | △△ | 30 | 0:30 | △△→□□ | |
| 2 | コンテンツ同期 | □□ | 60 | 1:30 | ||
| 3 | データベースデータダンプ | □□ | 60 | 2:30 | ||
| 4 | データベースデータ転送 | □□ | 180 | 5:30 | 想定より時間がかかる場合、別途連絡・対応協議 | |
| 5 | データベースデータインポート | □□ | 60 | 6:30 | ||
| 6 | アプリケーション動作確認 | ○○/△△ | 120 | 8:30 | △△→○○ | |
| 7 | 移行判定 | ○○ | 30 | 9:00 | NG時は以降の作業をスキップ、予備日で対応 | |
| 8 | DNS切り替え | □□ | 30 | 9:30 | ||
| 9 | アプリケーション動作正常性確認 | ○○/△△ | 120 | 11:30 | △△→○○ | |
| 10 | 最終判定 | ○○ | 30 | 12:00 | NG時はメンテナンスモードに切り替え、問題解決を図る | |
| 11 | システム連携先への切り替え完了通知 | ○○ | – | – | ○○→関係各社 | |
AWSへの移行作業 直前・直後の3ポイント
AWSへの移行作業の計画を立てる上でのTIPSをいくつか挙げてみます。
イレギュラー判断について
予想される不測の事態をできるだけ事前に洗い出します。イレギュラーな事象が起きた時の対応シナリオを用意しておくことで、切り戻しが必要な場合の判断ポイントの定義がしやすくなるでしょう。また、不測の事態を予想して、シナリオにまで落としておくことが、システム切り替え作業を安心して確実に行うことにもつながります。
連絡体制について
先述しましたが、システム切り替え作業は、移行作業は複数チームで行う場合が少なくありません。円滑な移行作業のためには、連絡体制と定期的な連絡ポイントを適切に設定することが重要です。業務上利用してかまわない場合はSlackやChatworkといったコミュニケーションツールの利用も検討すると良いでしょう。
要員計画について
移行作業は夜間や休日などに行う場合も考えられます。移行完了後、利用者からの問い合わせや、イレギュラーな事象に対する個別対応が発生することも考えられるため、移行作業が完了した後のバックアップ体制も踏まえて要員計画を立てておくとプロジェクト関係者の負荷軽減につながるでしょう。
また、要員の役割はできるだけ分業します。特に作業状況の連絡者と移行作業の作業者は、特定の担当者が同時にこなしていくのは中々難しいため、原則として分けることが望ましいでしょう。
AWSへの移行後のポイント
AWSへの移行作業が完了した後のタスクなどいくつか挙げてみます。
旧環境の廃棄
無事に移行が完了した後に行うタスクとして、忘れがちなのが現環境の契約解除や撤去のタスクです。無駄なコストを発生させないためにも移行計画のタスクとして必ず含めるようにします。
一点注意として、現環境の契約を解除してしまうと、もう元には戻れないため、不測の事態にそなえ、しばらくは新旧のシステムの並行稼動期間を設定するのが良いでしょう。
AWSのクラウド環境の利活用
AWSのクラウド環境への移行が一段落したら、移行した環境をよりクラウドにフィットさせるような改善活動を行いたいところです。ここでは「構成の適正化」「運用性の改善」「管理負荷軽減」の観点から改善ポイントとなる項目を挙げています。
構成の適正化
- シングル構成部分(Single Point Of Failure)を見つけて排除
- インスタンスサイズの適正化
- スケールアウト構成
運用性の改善
- CLIやAPIの活用
- デプロイの見直し
- ログの集約管理
管理負荷軽減
- Amazon EC2の利用を減らす
- サーバレスアーキテクチャの採用
- オペレーションの自動化対応
以上が「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～【3】 移行本番の切り替え」でした。
次回は「AWSへの移行事例」にて移行先のAWSについて詳しく紹介します。
連載「AWSへの移行方法と手順～オンプレからのクラウド移行を成功に導くために～」
【1】事前調査・移行ツール
【2】 計画と実行
▶【3】 移行本番の切り替え
【4】AWSへの移行事例
AWSへ移行を検討・実施される方にオススメ！
これからAWSへ移行を検討・実施される方は必読
・クラウド移行ガイド
・オンプレミスからクラウド移行の成功ポイント
・AWS導入事例集
など、AWS移行に役立つ資料や成功事例をご紹介します。