ETLはソフトウェアのバージョンアップ、ハードウェアのリソース不足、老朽化等でシステム移行が必要となる。ETLは非常に多くのシステムと接続するためこのシステム移行には労力とリスクを伴う。
特に、ETLが全社的に活用され接続先が多い場合は、問題が起こりやすい。下記はETLサーバーの外部との接続の様子をイメージしたものである。実際はもっと複雑で、30以上の接続タイプ（FTP、JDBC、HTTP等）や1000以上の接続が存在する場合がある。IPアドレスやFWの変更、移行結果の検証方法、失敗時のリカバリ方法、平行稼動の方式等が接続先ごとにことなり複雑化する。このようなケースで新システムに安全に移行する方法を考える。
システム移行方式のパターン
システム移行方式には以下のようなものがある。
- ビッグバン移行（上書き方式）
- ETLソフトウェアの上書きバージョンアップ、仮想化サーバーでOSやハードウェアリソースの上書きバージョンアップ
- ビッグバン移行（新旧切り替え方式）
- 新システムを新規に構築し、移行日に一括で移行する。
- 段階的移行
- サブシステム単位等の特定の単位で段階的に移行する。
- 並行稼働
- しばらくは平行稼動を行い、実行結果の新旧比較から問題ないことを確認後に新旧切り替えを行う。
ETLに適したシステム移行方式
接続先が多いETLの特性からすると”段階的移行”が最も適している。
ビッグバン移行（上書き方式）は最もリスクが高く、移行後にもとに戻すことができない。もし、失敗すると大惨事となる。ビッグバン移行（新旧切り替え方式）は失敗した場合に元に戻せるが、1000ETL処理等が存在し、成功するものと失敗するものが混在する場合は、戻すのが難しい。ターゲットに書き込んでしまった場合はデータも元に戻さなければならない。そもそも、ビッグバン移行は処理数の多いETLサーバーの場合、移行後の検証に時間を要する。検証に1日要して失敗とわかった場合は、リカバリする時間がない。
並行稼働は最も安全だが作業コストが非常に大きい。並行ということは新旧で同じデータを読み込む必要がある。タイミングでデータの内容には相違が発生し、タイミングを合わせる場合は複雑になる。また、ターゲットDBも新旧で同じ構成にしないと新旧比較での検証ができない。ターゲットに対してETL処理以外がデータを変更する場合は、同じ処理を新システムでも実行する必要がある。
ETLのシステム移行のリスク対策
消去法で段階的移行が現実的な移行方式となる。とはいえ、段階的移行も十分、ハイリスク、高難易度である。以下のような工夫によりリスクを低減することができる。
- 移行日に手動で接続先を設定するような仕組みだと人為的なミスでトラブルが発生する。接続先はパラメータファイルで切り換え可能にしておく。
- 移行に失敗した場合は、ターゲットDBのデータがリカバリできる仕組みを容易しておく。もしくは、リカバリが複雑化するようなETL処理を作成しない。例えば、何回実行しても結果は同じになるように処理を設計しておく（ターゲットDBに更新フラグのような項目があるとターゲットDBも修正が必要なりリカバリが複雑化する）
- シンプルにETLアプリの処理を作成し、トラブル発生時に問題の原因が特定し易いようにする。
- 移行と同時にETL処理の改修をしない。ついでに改修を計画するプロジェクトもあるが、ただでさえ、複雑なシステム移行の複雑性がさらに増大してしまう。
- 別システムとの依存関係を作らない。例えば、別システムからETL処理をキックする。別システムのファイルを監視する等。最近、利用が増えているキューイング等で依存関係は削減できる。
このような移行性の高い柔軟なETLシステムを構成するにはグランドデザインのフェーズで適切に標準化を行う必要がある。
まとめると段階的移行＋標準化がポイントである。