本番移行は本番システムの停止を伴うことが多く、失敗が許されません。作業遅延や移行データの不備は本番システムでの業務に影響を与えてしまいます。
そこで、移行プログラムや手順書ができたら、本番移行までの期間に何度かリハーサルを行います。移行リハーサルは少なくても2回は実施します。限定的なやり直しも含めると5回、6回と繰り返すこともあります。
本記事では、移行リハーサルを本番に極力近づけ、本番移行を円滑に行うためのコツを紹介します。
移行リハーサル2つの目的
移行リハーサルの目的は以下の2つがあります。
- 時間計測（時間内に移行処理、手順を完了できるか）
- 手順検証（計画・準備した移行手順が実用に耐えるか）
時間計測
目的の1つ目は時間計測です。
本番移行はゴールデンウィークやお盆休みなど通常の土日よりも長い休暇を使って行うことが多いです。業務になるべく影響を与えないよう調整しますので、時間内に移行が完了できないとそのまま稼働開始遅延につながってしまいます。
データ量が多い場合、サーバスペックだけでなくデータパターンによっても移行プログラムの処理速度に影響がありますので、実データ、実際の移行環境に極力近い状態でリハーサルを行うようにします。
手順検証
目的の2つ目は手順検証です。
本番移行は、環境設定からデータ受領、データ確認、投入、結果確認と依存関係があります。関係者も複数部門や会社に及ぶことが多いため、作業だけでなく受け渡しも含めたタイムチャートを作成します。
このタイムチャートの精度を上げるのに重要なのが個々の手順書です。特定の担当者（移行プログラムの作成者）しか実施できない場合、何かトラブルが発生したら全体の進捗がストップしてしまいます。
リハーサルでは、全体の流れに問題がないかを見つつ、実施体制に課題がないかも見極めを行います。
移行リハーサルの計画
上記目的を満たすよう計画を行います。
時間計測
本番移行はシステムの停止時間が決まっているので、全体枠を超えてしまうと多大な影響があります。データ移行の処理自体は減らせないので、個々の処理時間を測定しておき、チューニングや全体バッファの見直し等を検討していく必要があります。
時間内に処理できない場合の対処法としては以下のような方法があります。
- SQLチューニング
- DBチューニング
- インフラ増強
SQLチューニングは開発担当でも実施できますが、本数が多くなると修正と再テストの工数も大きくなります。
DBチューニングはプログラム修正をともなわずパラメータ変更で実施できますが、インフラのサイジング等への考慮が必要です。
インフラ増強は個々のプログラム修正は発生しない一方で、スロットの空きや共用環境のスケジュール調整、追加調達のリードタイムなど違った考慮が必要です。
移行手順の検証
理想としては手順を作成した人と別の人が手順書を見ながら実行し、問題なく実行できるか検証を行います。発生した問題については分析し、移行プログラムや移行手順に反映します。
移行リハーサル結果の記録
データ移行リハーサルでは移行タイムチャートに実績時間を記録し、何か問題があった場合は障害管理表に記録を行います。
これらを元に、次回の移行リハーサルもしくは本番移行に向けて必要なアクションをまとめていきます。
データ移行プログラムや手順書への修正事項や、当日のシフト表など新たに整備が必要なもの、その他、本番までに明確にすべきことの抽出と解決を行います。
追加計画を想定し予備枠を持っておく
リハーサルは当初計画よりも増えることを想定し、予備枠を持っておくことをおすすめします。
プロジェクト終盤の状態は詳細に計画するのは難しいからです。計画した時間内に計画した移行品質を満たせるまで臨機応変にリハーサルを追加することが、本番移行の生命線になります。
本を書きました！（2017/11/18発売）
本記事にあるようなデータ移行の現場に役立つノウハウを実体験に基づいてまとめました。
