目次
| ブログ | 内容 |
|---|---|
| ①概要編 | ダウンタイム最適化手法の仕組み、制約 |
| ②実施編 | ダウンタイム最適化手法の実施手順 |
| ③検証編 | ダウンタイム比較、考察 ※当ブログ |
今回は検証編ということで、ダウンタイム最適化手法と標準方式のコンバージョンのダウンタイム比較とダウンタイム最適化コンバージョンのアップタイム中のデータの挙動、その他考察について記載しています。
検証内容
- 下記３パターンでのコンバージョンを実施し、ダウンタイムを比較
- 標準コンバージョン（以下標準Convと記載）
- Downtime-Optimized DMO（以下DO-DMOと記載）
- Downtime-Optimized conversion（以下DO-Convと記載）
- ダウンタイム最適化手法のコンバージョンのアップタイム中のデータの挙動を確認
検証結果
１．ダウンタイムについての考察
参考までに今回の検証はECC6.0 Ehp6 → S/4HANA2020FPS02のシステムコンバージョンで実施し、ソース環境のデータベースサイズは約1TBのものを使用しています。
以下は３つのコンバージョン手法の実行時間をグラフにしたものでダウンタイムの開始点を合わせた表示としています。
結果、標準Convと比較してDO-DMO、DO-Convはそれぞれダウンタイムが短縮しました。
特にDO-Convでは大きな効果が表れました。「FINデータ変換」のステップがアップタイムに移動しているので、その分が減ることは予測できましたが、DO-DMOと比較してもSUMのダウンタイムが15:27→8:36と約45％短縮されました。FINデータ以外のデータ変換がアップタイム中に行われた効果での短縮と考えられます。
一方でアップタイムはダウンタイムの減少幅と比較して大幅に増えています。アップタイム中のデータ移行処理のパラメータ調整を実施していないことが要因の一つと考えられます。いずれにしてもアップタイムの増加はリスクにつながりますので、アップタイムが増加しないよう調整する必要があります。
※今回はアップタイム中のデータ投入・データ変更はほとんど行っていません。そのためDO-DMO、DO-Convでのダウンタイム中のデルタ処理の時間はほとんど加味されていません。
※検証環境はAWSを利用しています。
※標準Conv、DO-DMOはSQL Server、DO-ConvはDBの制約のためOracleにDB変換して実施しています。
※比較のためチューニング等は基本的に実施していません。SUMのパラメータや並列実行数などの実行パラメータは同一で実施しています。適切なチューニングを実施する事でさらに実行時間の短縮は可能。
２．アップタイム中のデータ追加時の挙動
「初回データ移行」のフェーズが始まった後に会計伝票を登録し、その登録データの挙動を確認しました。ソース環境で会計伝票を登録するとすぐにターゲット環境の伝票件数(BKPF)に反映されました。また、ターゲット環境のUniversal Journal(ACDOCA)にはこの時点では反映されていないことが確認できました。
このことから、アップタイム中のデータ追加では「差分データ移行」は随時行われるが「差分データ変換」は行われていないことがわかります。
また、SUMのユーティリティにあるCRRコントロールセンターで「差分データ移行」の進捗状況を確認することができます。
伝票を登録すると、変更が加えられるテーブルの情報が表示(図の下側)されます。上側に表示されている進捗率が100%→99%と変化し、少し時間が経つと、また100%になるような動きをします。大量のデータが投入されると一時的に進捗率が大幅に低下します。このように随時データが転送されている状況を確認できます。
また、進捗率が75%以上にならないとダウンタイムフェーズへ進めることができません。
本番移行時にはCRRのパフォーマンスや平常時のデータ増加量を考慮して、エンドユーザの追加データ投入の締め切り時間やダウンタイムの開始時間を検討する必要があります。
まとめ
ダウンタイム最適化手法のコンバージョン（DO-DMO、DO-Conv）はダウンタイムの短縮には一定の効果があることがわかりました。特にDO-Convでは大幅に短縮されることが期待できる結果となりました。
標準Conv：約40時間 → DO-DMO：約27時間（約32％減）
標準Conv：約40時間 → DO-Conv：約8時間（約80%減）
一般的にコンバージョンのダウンタイム短縮方法は、「チューニング(システム性能やパラメータなどの調整 )」と「アーカイブ(データ量削減)」が考えられますが、この対応には限界があります。
そういう意味では、今回のダウンタイム最適化手法は、これらの方法とはまた違ったコンセプトのため、組み合わせて使用することが可能であり、ダウンタイム短縮の選択肢を広げるソリューションになりえるものと思います。
一方、実用性を考える上では、アップタイム処理中にアプリ的な制約があること、SI-CHECK対応を事前に本番環境で実施する必要があること、アップタイム中の処理時間やシステム負荷が増えることなどの懸念があることもわかりました。これらの懸念については運用面への影響を正確に把握し、対策をして許容できる範囲に抑えることが必要です。
実際のコンバージョンプロジェクトでは、許容されるダウンタイムや環境情報に応じて各移行方式の適正を検討します。さらに、机上での検証をベースにPoC環境で実際にコンバージョンを実施してダウンタイム短縮効果とリスクや制約を把握した上で、最適な移行方法を選定する事が非常に重要となります。
今回の検証ではダウンタイム最適化手法の費用対効果が感覚的にわかったものとなりました。実用できれば効果は高いが実用するには高めのハードルがいくつかあるといった印象です。
本記事がご参考になれば幸いです。
BeeXでは、ECCからS/4HANAへの移行を検討中のお客様向けのロードマップ作成、アセスメント、PoCなどのSAP S/4HANAコンバージョン関連サービスを実施しています。
BeeX Migration Factoryを利用する事で、お客様データでのPoCにてダウンタイム時間確認もスピーディに対応可能です。
S/4HANAへの移行でお悩みのお客様は是非、お気軽にご相談ください。
この記事をシェアする
