サーバ管理者によるデータ移行作業は、地味に見えて実は相当な準備と労力を要するものです。今回はITSolutionsのData Migration Toolに関するブログシリーズの第3回、Robin Storyさんの記事を紹介します。

---

FileMaker 17: Data Migration Tool Overview Part Three

Managing a File Migration – Considerations and Best Practices

(元記事はこちら)

Robin Story
2018/5/15

Data Migration Tool (パート1) で説明したように、FileMaker 17で利用できるDMTは自作のスクリプトによるインポートに比べて大きな利点をもたらしますが、それでも完璧ではありません。いくつかの環境では、開発者のニーズによって、スクリプトによるインポートの移行の方がDMTスクリプトよりも優れている場合があります。

移行の目的

利用者が多い大規模で複雑なシステムでは、システムの稼働中に新しい機能やモジュールを追加することができないケースがあります。このような場合、リリース前に必要な変更を実装してテストできるように、開発用コピーを別の環境に置きます。変更を本番環境に反映させるときは、最新のデータを現行の本番システムから取り出して開発システムに投入し、その開発システムを新しい本番システムとします。非常に複雑なシステムの場合、本番システムと開発システムの間に、本環境での動作確認やβテストのための3つ目の環境を準備することもあります。この環境でユーザは本番リリース前に新機能を試したり品質管理のレビューを行うことができます。

データ移行に関する留意点

DMTは、データ・セキュリティ層・値一覧を、データが入っているファイルから未開封のクローンファイルに投入するための、優れた方法です。しかしそれがゆえに、スクリプトによるインポートをやめてDMTに移行する前に、開発環境で何が起こっているのかをよく考慮する必要があります。

留意点1: オブジェクトフィールド

オブジェクトフィールドの外部保存はFileMakerの強力なツールですが、あるファイルから別のファイルにデータを移動するときには厄介なことがあります。DMTは外部保存されたオブジェクトフィールドのデータは移行せず、ソースファイルの既存の外部保存されたファイルをそのまま使用します。外部保存されたオブジェクトフィールドを頻繁に使用している場合、外部保存用のディレクトリをバックアップするなど特別な注意が必要です。特定のファイルキーで暗号化された外部保存を使用したソリューションの問題にぶつかると、細かいところを気にしない管理者によっては作業が煩雑になります。たとえば、新しく移行したファイルで暗号化キーを保持するためには、[サーバへアップロード]機能を使用せずに、サーバ上でファイルを置き換えることが重要です。さらに、オブジェクトフィールドを持つファイルを移行する前に、私は念のため、外部保存されたオブジェクトフィールドを持つテーブルから、主キーとオブジェクトフィールドを合わせてFileMaker形式のファイルにレコードをエクスポートしておくようにしています。万一移行によってオブジェクトフィールドのデータが破損した場合、これが復元のための一手段になります。

留意点2: カスタム値を使用した値一覧

Data Migration Toolを使う場合、クローンファイルの値一覧をソースファイルの値一覧で更新するかどうかを選択することができます。特に、ユーザがカスタム値を使用した値一覧を作成することが許可されていて、開発サイクルが長いファイルでは、これは非常に役に立ちます。しかし逆もまた真の場合もあります。それは開発者がシステムの動作を制御するために値一覧を使用しているようなケースです(たとえば、[オブジェクトへ移動]スクリプトステップをトリガする値一覧、ユーザが自らアカウントを作成できるようにした管理モジュールでアクセス権セットを選択させるための値一覧、など)。これらの値一覧の変更は開発サイクルの一環であり、プログラムの動作に関わる変更がアップグレード時に消えてしまうことは望ましくありません。

特に大規模なシステムでは、両方から値一覧を使用する可能性が高くなります。エンドユーザが管理する値一覧と開発者が管理する値一覧が混在するケースです。このような場合のために値一覧の棚卸をしっかりおこない、データ移行の後で一方のファイルから他方のファイルに必要な値一覧を手動でコピーできるように準備しておくことが重要です。

留意点3: セキュリティ層

前の留意点と同様に、セキュリティ層もすべての移行ツールで重要な検討事項です。DMTは、古いシステムから新しいシステムにアカウントを単純に上書きできるという点で特に優れています。これまでは、比較的長い開発サイクルでは、開発用スナップショットを作成したときから本番リリースまでの間に発生した、新規ユーザ、削除されたユーザ、パスワードの変更について何らか手当をする必要がありました。これを解決するために、次のいずれかを行う必要がありました。

1. ユーザのパスワードを従業員レコードに格納する(これは推奨されません)。

あるいは

2. 開発環境のユーザテーブルをループしてユーザアカウントを削除した後、本番データをインポートして、規定のリセットパスワードと共にユーザデータを再作成する。この方法は各ユーザにパスワードの再設定を強いるため、あまりいい方法だとは言えない。

DMTを使用すると、この不満が解消されます。

留意点4：システムテーブル、開発者用テーブルと、ユーザデータ

比較的規模の小さいシステムでは、通常すべてのテーブルはユーザがデータを入力します。しかし、システムが複雑になり、モジュール応答式の環境、複雑なビジネスルールを制御する値一覧、その他のデータ駆動型プロセスを構築し始めると、多種多様なデータが混在した環境に身を置くことになります。気がつくと、ユーザがデータを入力したテーブルの他に、モジュールや機能を駆動するためのデータを持った多数のバックエンド用テーブルも維持しなくてはいけない状況です。移行プロセスの一環として本番ファイルからデータを引き継ぐことは、開発サイクルの中で新機能を駆動するためにテーブルに追加した必要なレコードを消してしまうことになり、頭の痛い問題となります。値一覧と同様に、常にデータテーブルを見直し、次のことを確認するようにしてください。この組織を動かすためのデータを入力しているのがエンドユーザなのか、あるいは作業環境を駆動するデータを入力しているのが開発者なのか? 前者のデータは、移行時に本番環境から取得することができ、後者はおそらく開発ファイル自体で管理する必要があります。スクリプトによるインポートでは、通常3つのファイルが絡みます。ユーザデータ用の本番スナップショット、開発データを含む開発スナップショット、そしてそれらを選択的に取り込むための新規リリース用の空のクローンファイルです。これにより、開発者は、そのデータの記録システムがユーザ側あるいは開発者側のどちらにあるかをテーブルごとに示すことができます。

留意点5：データマッサージと更新フィールド

最後に、開発システム上に新規機能を作成しているときに、実動システムへのデータの反映が必要な、新規フィールドを作成したり既存のフィールドを修正したりしてしまっていることに気づくことがあるかもしれません。それは例えば、新しいリレーションから値をルックアップする新規フィールドを追加したり、画面部品の動きを制御するフィールドの値が変わって複数箇所に分散したり他の選択肢と統合されたりするようなケースです。その結果、本番ファイルのデータを、移行プロセスの一部として何度も取得する必要が出てきます。

残念ながら、これは通常[再ルックアップ]や[フィールド内容の全置換]の操作が必要であり、更新日時の自動入力フィールドを考慮する必要があることを意味します。既存のフィールドの値を変えないためには、古い本番ファイルの修正タイムスタンプの自動入力をオフにした上で再ルックアップや全置換を実行してから、インポートを行うようにします。しかし、新しいフィールドに値を埋める必要がある場合はあまりいい方策はありません。ともかくインポートを実行し、修正の自動入力フィールドをオフにして、必要なデータマッサージを実行してから、これらのフィールドの設定をオンに戻します。この煩雑な作業を、それでなくても忙しい移行スケジュールに加えて覚えておく必要があります。スクリプト化されたプロセスを使用するメリットの1つは、(移行前に更新日の自動入を無効にしておくと)プロセスの一環としてデータマッサージをスクリプト化して組み込めるため、それを覚えておいて後で実行する必要はありません。

留意点6：破損したデータ

理想的な完璧な世界では、ネットワーク切断、ディスクエラーなど、本番システムでデータが破損するかもしれない有害なイベントは発生しないでしょう。しかし、私たちが住んでいる現実の世界ではそういうわけにはいきません。索引の破損、データの欠損、ハードドライブの劣化は実際に起こりうることで、対処にとても苦労する可能性があります。幸いFileMakerが持っている[修復]機能は、システムを復旧するためのかなり信頼できるツールです。パート1で述べたように、DMTはデータ復旧ツールではありません。そのため、本番ファイルでレコードや索引が破損していることに気づいた場合、移行を実行する前に本番データを修復するステップを組み込んで、できる限りクリーンなバージョンのデータを取得することが重要です。

スクリプトによるインポートの手順に関するその他の考慮事項

• DMTは、移行先のファイルに[次のシリアル値]を自動的に設定します。スクリプトによる移行の場合は、移行されたテーブルのそれぞれで[次のシリアル値を設定]スクリプトステップが必要です。これは、主キーでレコードをソートして最後のレコードに移動し、次のシリアル値をその値+1(またはその他のインクリメントルールに従った値)に設定することを意味します。
• スクリプトによるインポートを実行する場合は、前回の移行以降に追加された新しいテーブルの一覧表を作成し、それらがインポートでちゃんと考慮されていることを確認する必要があります。
• 同様に、データ移行時に[レコードのインポート]スクリプトステップでフィールドのマッチングを常にチェックすることが大事です。通常[照合名順]はかなり安定していますが、念のため以前の移行では新規だったフィールドが現在の移行に対して適切にマップされていることを確認することが大事です。
• ファイルの容量はどのくらいで、移行にどれくらいの時間がかかりますか? 一晩で終えることができますか、それとも週末に実施する必要がありますか? 可能であれば移行先は常にクローンファイルにしてください。これによって可能な限り小さなファイルサイズから始めることができます。大きなファイルに対して[すべてのレコードを削除]ステップを実行すると、移行プロセスが極端に遅くなる可能性があります。

デプロイの一環としてのデータ移行

開発者にとって、データ移行時の最優先事項は、正しいデータを正しい場所から安全に取得することです。しかし、データ移行はエンドユーザにとってもストレスが多いことに留意することが重要です。我々開発者が「移行」と言っているものは、実際にはより大きなデプロイのプロセスの中の一部のみをさしています。デプロイのためのよく計画された戦略では、エンドユーザの潜在的な不安も考慮する必要があります。

開発者の移行計画は、移行当日にやることだけのチェックリスト(サーバーでファイルを閉じる、ファイルをデスクトップに移動する、データ移行を実行する、データをチェックする、ファイルを再度サーバで公開する)のようなものかもしれません。しかし、本来のデプロイ計画は、すべてのユーザが新しいバージョンに対して不安なく準備ができていると思えるものであるべきであり、また関連する多くの部門の人を巻き込み、それぞれの人が移行を問題なく行うために自分が何を遂行すべきかのガイドラインが整理されている必要があります。以下に例を示します。

リリースの1週間前

1週間前に、パワーユーザに対してデプロイが予定されていることを通知します。そこには、新しいバージョンでどのような機能が追加されるかについての簡単な説明が含まれます。

可能であれば、このタイミングでステージング環境を準備して移行スクリプトの予行演習を行い、パワーユーザが本番移行の前に新システムの動作チェックをできるようにするのがいいでしょう。またこの段階で新機能説明会を開き、パワーユーザに新バージョンの詳細に慣れてもらうこともできます。

リリースの2,3日前

この時期までに開発者は、パワーユーザによる最終受入テストの結果として判明した移行プロセスの細かな問題点を特定して対策を行います。大きな問題が発生した場合、全社的なアナウンスを送信せずにリリースを延期することができます。

この機会を利用して、ユーザのトレーニングを行います。これによって、システムの新バージョンを試しに触ってから、本番で実際に使い始めるまでの日数が長くならないようにします。トレーニングで学んだことが比較的新鮮なままであれば、ただでさえストレスの多いプロセスの中での復習の必要性が最小限に抑えられます。組織の規模によっては、すべてのユーザがトレーニングに参加することができない場合がありますが、部門ごとに少なくとも1人が参加するようにして、部門内の他の人への説明役になってもらうことができます。

トレーニングの一環として、「変更点」と題した短くてわかりやすい配布資料を準備します。前に通知した機能追加の簡単な説明を使い、箇条書きで背景のビジネスルールを追加し、実際に操作中やルールの変更点がわからないときに参照できるようにします。

リリースの前夜

リリースの準備中に、すべてのユーザに電子メールを送信し、リリースが予定されてしてデータベースの停止期間があることを伝えます。一般向けには「システム停止中」の画面を表示し、開発者は予期せぬ事態の時にためにシステムに入れるようにしておきます。トレーニング対象者が一部のパワーユーザだけだった場合は、残りのユーザにこの通知の一部として準備した資料を配布します。

リリース

ログイン中のユーザーには、作業内容を失わないようにログアウトするよう警告を出し、十分な時間をとった後サーバ上で本番ファイルを閉じ、スケジュールされたスクリプトがある場合は一時的に無効にします。この時点で本番ファイルを圧縮して、開発者のマシンに転送されるか、その時間を節約するために開発者がサーバ上で移行を実行します。いずれかの方法で、移行が実行されます。移行が完了すると、開発者はファイルを比較してレコード数が正しいことを確認し、サンプリングしたデータを確認した後、事後のデータマッサージ(オブジェクトフィールドの更新、値一覧のメンテナンス、セキュリティ層のクリーンアップなど)を行います。

開発者がリリースが無事に完了したことを確認すると、新しい本番ファイルをサーバ上で再度開きます。開発者はファイルをチェックして、すべてが必要な場所にあることを確認します。リリースがどのように処理されるかに応じて、場合によっては開発者は一部のユーザに「準備OK」の電子メールを送信してシステムが期待どおりに動作していることを確認してもらい、その後すべてのユーザにシステムが再稼働したことを通知します。

リリース後

システムが検査され、すべてのユーザに利用OKの通知を出し、無効化されていたサーバ・スケジュールを再度有効化します。開発者は、何らかの形の課題管理システムを実装して、新しいリリースに関する問題があったときにユーザがフィードバックを整理・調整できるようにします。シンプルなシステムでは、ユーザがバグ修正リクエストを送信して追跡することができます。より複雑なシステムではエンドユーザが送信したバグ修正リクエストを上司が確認し承認することによって、ユーザの操作の問題、リリースと関連しない問題は自部署で処理するよう振り分けます。

リリーススケジュールの調整に役立つデプロイスケジュール表のサンプルを作成しました。たとえば、Amalgamated Widgets Corporation社(AWC)が作業記録システムを5月11日にアップグレードを予定していて、Robinがリリースデベロッパ、Lenがトレーニングとテストを調整するための品質保証(QA)チームのリーダである場合、次のようになります。

開発者は別途移行作業用のチェックリストを使用して、オブジェクトフィールドのデータのバックアップ、更新タイムスタンプの無効化、テーブルレコード数の比較、特定のビューのチェックを行い、データが想定どおりに移動したことを確認します。

デプロイのスケジュールは、システムの規模、組織の複雑さ、変更管理に関するさまざまな標準的な運用手順によって決定されます。

データ移行は簡単な作業ではなく、多くの不満と不安を生む可能性があります。しかし、移行を慎重に計画し、最良のツールを検討することは、そのような不満を解消するために大いに役に立ちます。次回の記事では、Colinがこれまでの説明をまとめ、最終バージョンのData Migration Toolヘルパーファイルを示します。