課題解決 事例紹介

2週間で大量のデータをXML化して新サーバへ移行せよ

業種
利用規模
用途
解決した問題
背景 新システムへの移行にあたり、旧システムのデータを変換して完全に移管する。数が多いのと、ファイルの容量が巨大なことから、手作業では無理と判断。
対応方針 新システム側が、XML形式のデータでI/Fしているため、旧システムデータをXML形式に変換。
その際、例外が生じるので、一度Excelで一覧形式に表示し、必要に応じて手修正した上で、まとめてXML化できるようにした。
想定外 1:1で関連付けられていると思ったデータが、実は1:nだった → 変換ルール変更で一本化し、XMLも一部変更
XMLファイルを含む関連ファイルを1つのZIPファイルにする必要があった → 環境依存でZIP化できない
ZIPの容量が2GBを超えるとZIP化できない → 例外として手運用できるように視覚化 
 ・・・等々
Excelを使ったことによるメリット(事後振り返り) 何段階かの加工を要したが、各段階の結果をファイル/シートで残すようにした(バッチ処理の発想)ことで、想定外が起こる度に発生するリランを最初からやる必要がなく、修正したステップの前段階からの再実行で済んだ。

大量の動画配信サーバを、新システムに移行

需要増大に伴い、配信サーバを強化

お客様(SIer:システム開発会社)のクライアントK社では、かなり前から動画配信サービスを行っていましたが、需要が急拡大してきたことに伴い、サーバの容量不足による配信遅延・画質の低下などにつながっていました。これに伴い、強力なサーバを持つ新しいシステムを構築し、旧サーバ内にあるデータ一式を、新サーバの様式で登録し直す必要が生じました。

お客様側では、ほぼ新システムを完成させ、あとは本番当日までに旧サーバのデータを移行する作業が残っています。

移行対象となるのは、動画ファイルだけでなく、各動画がどのような内容か(概要)、タイトル、制作者、分類(ジャンルなど))を記した情報ファイルも伴います。このうち、情報ファイルは新旧で形式が異なるため、新たにXMLファイルとして生成し直す必要があります。

 

数が多すぎて、XMLファイルの手作成は事実上不可能。

情報ファイルの数は、すでに万のオーダーになっていましたが、翌月までに作業を終える必要があります。作業の膨大さとミスの可能性を考えると、手作業で移行を行うことは現実的ではありません。

加えて、現状の情報ファイルに欠落や矛盾があり、ものによっては手作業で補正する必要がありました。

そこで、一度Excelシート上に内容を視覚化し、エラーチェック機能で欠落を発見し、補正後の内容を基にXML化するツールを作成することになり、当社がこれを引き受けました。実は、ExcelとXMLは、案外相性がよいのです。

 

旧システムの内容が、想定外の事態に

旧システムデータの「こんなはずでは」

さて、いざツールを作って作業を開始すると、想定以上にXML変換されないものが多発しました。その数、実に数千件です。これを手作業で対応していると期日に間に合わず、ツール化した意味が薄れてしまいます。

原因を探ってみると、旧システムのデータが、そもそも当初の仕様通りに入っておらず、元々旧システム側では登録時にエラーチェックを厳密に行っていなかったことが判明しました。

例えば、親ファイル1に対して関連ファイル1個が紐付く(1:1)筈だったのが、蓋を開けてみると1:nだったため、大幅にロジックを変更することになりました。

また、新サーバへのUploadは、一式ZIP化しないと受付けて貰えないことが分かり、急遽ZIP化のロジックを組み込んだものの、今度はお客様のコンピュータ環境が古すぎてZIP化のロジックが動かなかったり、やっとVM環境を使う事で解決したと思ったら、動画ファイルおサイズが大きすぎてZIP化できない(XMLと共に動画ファイルをZIP化する必要があったため)・・・等、これでもかとばかりに、大きな壁が立ちはだかる事態となりました。

・・・Excelツール側の問題ではないとはいえ、この状態を何とかしないと、期限までに移行作業が終えられないことを意味しています。

 

現実的な対応方法

その後検討を続けた結果、当初想定していたルール通りでない場合でも、別のルールに合致すれば一定の変換ができるケースが多いことがわかりました。

早速その措置を行い再実行(ReRUN)したところ、数千件あった未変換データは、一気に数百件にまで減りました。とはいえ、まだまだ数百件、人力で行うにはリスクの高い数値です。

更に検討し、第3のルールを見つけて変換を試みることにしましたが、このルールでも漏れるケースが100件近く残りました。

残りは人が判断せざるを得ないため、こうしたケースについては、見て分かるマークとともに、判断材料を表示させておくと言う方法を採ることにしました。

なお、この間何十回も条件を変えて試しながら検討をしていましたが、基のデータ数が多すぎることもあり、最初から処理するとほぼ半日かかる量でした。このため、段階的に加工ができるようにしておき、ReRUNは必要なステップから行えるようにすることで、再実行時間の短縮に貢献できました。

また、ZIP化については、仮想環境でなら最新OS/Excelを用意できるとのことだったので、(速度は大幅に落ちますが)仮想環境で夜間に処理を行うことで逃げ切りました。

 

期限内に移行させるために、何をすべきか?

データ移行PJ(プロジェクト)の特徴

今回は、期日までにデータを移行することがミッションであり、「何かプログラムファイルを作って納めれば終わり」という性質のものではありません。

特にデータ移行のような場合、今回同様「当初聞いていた話とは異なっていた」というケースはよくあることで、やってみないとわからない以上、やりながら臨機応変の対応が求められます。技術的にも、XML化まではうまくいったものの、急遽求められたZIP化では圧縮後に2GB以内である必要があったなど、思わぬところで仕様上の限界にぶち当たりながらも、運用で逃げる方策を考えるなど、苦労した案件でした。

もともとお客様(SIer)がそのクライアント先から聞いていた事と実態が異なっており、かといって「それでは移行できません」と言うわけにも行かないため、変換できない理由を分析しながら次の手を考え、手作業で補正しても十分な品質が担保できるレベルに落とし込むことができました。

こうした厳密な期限管理が求められるプロジェクトでも、落としどころを探しながら臨機応変な対応を行う事で、(全自動にはならないものの)現実的な着地(期日までに相当の余裕を持って移行完了)に成功しました。