orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

トラブルになりやすい データ移行という沼を考える

f:id:orangeitems:20210301172032j:plain

 

みずほ銀行が、データ移行という沼にハマってしまったと聞いて。

 

piyolog.hatenadiary.jp

みずほ銀行は障害の発生原因を定期預金取引のデータ移行作業によるものと発表。データ移行作業は障害が発生した28日朝までに行われており、作業中に不具合が発生した。

 

今日の18:00から記者会見を行うそうなので、詳細な報道は今後と思われます。

 

www.nikkei.com

みずほ銀行は1日午後6時から都内で記者会見する。藤原弘治頭取が出席して、2月28日から続くATMの障害について説明する。全国の支店にあるATMは1日午前7時以降にすべて稼働したが、商業施設など支店外にある3カ所のATMは1日午後2時の時点で復旧していない。

 

頭取が夕方会見だなんて、半沢直樹みたいなことになってますね。

 

さて、データ移行って私はインフラエンジニアなのであまり関わることはないですが、開発部門では最も鬼門になる作業です。これは、一般にはあまり知られていないことなので、データ移行はリスクが高いんだと言う認識が一般に広まるといいですね。

なぜデータ移行が怖いかをお話します。

まず、アプリケーションとデータベースの組み合わせについては、リリース前に、架空のデータでまず一度テストされます。架空といっても、本番データさながらにいろんな種類のデータを用意し、そこでアプリケーション側に不具合がないかを確認します。その後、本番データ自体をテスト的に読み込ませ、それでも不具合が無いことを確認します。これらのテストが終わったら一旦はアプリケーションは、本番データを正確に処理することができるとみなします。

さて、ではこのアプリケーションを本番システムとしてリリースします。このとき、以前のテストしたときのタイミングと、リリースのタイミングで本番データの差分が生まれますから、これを本番データに追加し、リリースとなります。

リリースのタイミングで、本番データそのものを、まるごと旧しすてむからコピーする、というやり方もありますが、これだとデータが大量な場合、システムを長時間止めなければいけなくなります。差分コピーしている場面は結構よく見かけました。

さて、ここまで手間をかけて、本番データを移行して本番リリースを行うのですが、ここで怖いのは、最後の「差分データ」の存在です。最後の最後で追加されるデータをテストするタイミングが上記の例では欠落しています。用心深いリリース計画だと、差分に対してのテストをリリース時に行うこともあります。

なお、上記では本番データを旧システムから移す、なんて簡単な表現で済ませていますが、実際データをもらってみると、顧客から事前に聴いていなかったデータが混入していたり、文字コードが違っていたり、ユニーク制約が守られていなかったりと、難易度高めです。きれいな移行元データならいいんですけどね。実際の現場では、例えば、判別できないときに「99999999」なんて数字を入れるようになっていて、二けたの数字しか想定していないのでアプリケーションがエラーになる、なんてことがザラに起こります。その場合、データベースの定義変更をするか、読み込めないデータをはじいて、加工して読み込ませるとか。まあこのデータ移行、すんなり終わるような気がしないのが普通の感覚です。

と、新規アプリケーションリリースの場合ですら気が遠くなるデータ移行。銀行システムのような、動いているアプリケーションに、新しいデータを読み込ませるというのはもっと違うリスクが生じます。既存の処理を行っている中に、これまで実績のない新し移行データを流し込むことで、想定できないことが起こり得るのです。既存のデータと、移行データを足し算して、これらがちゃんとアプリケーションにとって、矛盾の無い状態であるかどうか。これをちゃんと証明した後でないと、正しく動くか証明できないのです。

頭から考えると、既存のアプリケーションのステージング環境で、本番データそのものと移行データを足し合わせたデータセットを、正しく処理できるかテストしなければいけません。でも本番データはやっぱり大きなものだし、移行データの量があまり大したものでなければ、そこまで大掛かりなテストをするか・・、しないという判断もあるでしょう。

・今までちゃんと動いてきた
・移行データは、本番データと比べると、割合としてはとても少ない
・じゃあ、移行データ突っ込んで、移行データの中でエラーが起こったら、そのデータをはじく。

そんなやり方になりそうですが、一番怖いのは、移行データのために、他の本番データが矛盾しちゃうことですね。そうなると、どっちが正しいのかを手動で一件一件チェックしなきゃいけなくなる。

 

ま、そんなことを思いました。特に最近は「データ」が肥大化しつつあります。持ち運びが極めて難しくなりつつある。

簡単にDX、DX言いますが、アプリケーション移行はやっぱりデータ移行が鬼門です。