サーバ機の老朽化によるマシン本体のリプレースについて考えます。この時、仮想マシンを使用せずに、新サーバ（物理マシン）に
Windows 2000/2003/2008/2012 をインストールし、このOS上で FMS
を運用しようとする場合、物理マシンが各OSをサポートしているか否かはチェックポイントとなります。経験上、メーカーが公式対応していないOSであっても動作する可能性は高いですが、メーカーが公式対応を謳っているマシンであれば、それに越したことはありません。
仮想マシン上で FMSを運用する場合
次に仮想サーバ上での
FMSの運用について考えます。この方法では仮想マシンにWindows
2000/2003/2008/2012 をインストールして、FMS を運用します。
既に仮想環境を構築済みであれば、マシン調達に伴う金銭的コストを負わなくても済むので、担当者の心理的負担は少ないです(経験者談)。逆にFMSだけのために仮想環境を新たに導入するとなると、コスト大の上、担当の心理的負担も大となります（同談）。
注意点が一つあります。当方で遭遇した現象ですが、Dell PowerEdge T105
のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）では、 FMS5.5
が問題なく動作していましたが、PowerEdge R330
のハイパーバイザ上の仮想マシン（Windows Server 2012R2 ）に FMS5.5
を新規インストールした後にFMS の コンソールで「ファイルメーカー
Server」を右クリックして「プロパティ」を選択するとコンソールがクラッシュする、ということがありました。 この時、正常稼働している
PowerEdge T105 上 の仮想ディスク（VHD）を丸ごと PowerEdge R330
にコピーして仮想マシンを再構成したところ、コンソールで「プロパティ」を選択することができました。
このように、一見同じに見えるシステム環境であっれも、FMSで障害が発生することがある、と言う事です。
当社ではFileMakerレガシーの延命を多くうけたまわっており、現在までほぼ成功裡に終わっていますが、リスクがあることをユーザに十分理解頂き、業務を進行することがやはり大切です。
もっとも、最新のテクノロジーでシステムを構築する！、と言っても、既存システムとの互換性、開発失敗リスク、最新テクノロジー故の不安定性・未成熟性といったリスクもあります。また、ベンダーが勝手に契約条件を変更する近年のサブスクリプションというビジネスモデルも大きなリスクです。
5G、AI、機械学習、IoT/M2M、DXを行わない企業に未来はない！などと、漠然としたIT用語や根拠不明の言説が巷に溢れる中、現行仕様で満足している、或いは現行仕様を修正・拡張しながら利用できれば十分というシステムも普通にあるわけで、であればレガシーシステムの延命は十分考慮に値すると思います。
Windows Server の Windows Update
Windows update を行わなければ FileMaker Server 5.5（FMS）
が動作しないということはありませんが、Windows 2008/2012
などの古いOSを運用する際に重要なことなので、本項にて触れておきます。
通常、新たにサーバ機を購入したり、サーバOSをインストールした際は、Windows
update を行い、OS を最新の状態にします。これは以下の理由によります。
-
セキュリティ上の要請
-
運用開始後の Update のリスクを低減する
運用開始後に Windows update
を実施すると、何らかの障害が発生し、運用中のソフトウェアが動作しなくなる可能性があります。できるだけ導入・テストの段階で利用可能な全ての
update を当て、運用後のダウンタイムを減らしましょう。
-
Windows Server
がある程度最新の状態でないと動作しないプログラムがある
ある種のアプリケーションをインストールする際、一定のバージョン以上の
Internet Explorer や .NET Framework
を要求され、インストールを実行できない、ということはままあります。この一定のバージョンに辿り着くまで、何回か
Windows update
を行う必要があることがあります。導入時に最新のUpdateを当てておけば、運用後にこれらの作業を低減することができます。
-
Windows Update 自体が動作しなくなることがある
後述のように Windows Update エージェントが古いと Update
自体ができないことがあります。
Windows update ができない時
FileMaker Server 5.5 と互換性の高い Windows Server 2008/2012
ですが、これらのOS のインストール直後に Windows update を実行すると、
0x80072efe というエラーが発生して、Windows Update
が完了しないことがあります。
このエラーは Windows Update エージェント自体に問題あり、Windows
Update
エージェントのアップデートプログラムを単独でダウンロードし、これを実行することにより解決できます。
※ご利用の Windows Server
のバージョンに適合したものをダウンロード後、インストールしてください。
この他にも、いくつかのアップデートを実行できないこともあります。その場合は
Windows Update
の順番を変えてみたり、個別にアップデートプログラムをダウンロードしたりして対応する必要が出てきます。
以上、運用開始後のダウンタイムを低減するために、導入段階で
Windows Update をできるだけ進め、OSを最新の状態にしておきましょう。
Windows Server のライフサイクル
参考までに、Windows Server
のライフサイクルの表（2021/07/26時点）を挙げておきます。
実行速度とテストについて
物理マシン或いは仮想マシンを問わず、構築した新環境に於ける実行速度が旧環境のそれに比べて明らかに遅い場合、問題となります。 旧環境から新環境への移行業務の早い段階で、必要十分な実行速度が得られているかをユーザに判断してもらうべきです。 業務終了間際に実行速度が遅すぎると判明すると、行った作業が全て無駄になる可能性があります。
当社では実行速度の可否を判断する際、約12万件の郵便番号情報が入った郵便番号.fp5
のファイルをFMSで公開し、FMPからアクセスして住所フィールド（都道府県+市区町村+町域を1つに結合したフィールド）のソートを行います。 この12万レコードのソートが30~40秒程度で終了する、というのを一応の合格基準としています。
注：
これは未ソートの状態で新たににソートした場合の基準です。一旦ソートされた状態で再度ソートすると、ソート時間が30～40％改善するとがあります。このため、ソートテストは常にソートされていない状態で実行してください。
ユーザは実行速度には敏感ですので、旧環境と新環境で郵便番号をソートのデモを行うのも良い考えだと思います。
当方の経験上、コア数やメモリも増やしても、実行速度はほとんど改善されません。ただ、ネットワーク（NIC）の設定を変更することにより、劇的に改善することがあります。これについては、
こちらを参照してください。
レガシーFileMaker の分析
当社では第三者が開発したレガシーFileMakerの保守・開発を引き受けていますが、そのシステムを拝見するとデータベースの正規化が無視されていたり、同種のスクリプトを延々と繰り返していたり（コードの再利用という考えがない）、逆にスクリプトが意味不明に細かく分割されていたり、セキュリティが考慮されていなかったりと、掟破りのシステムを目にすることが少なくありません。
掟破りシステムに障害があると、当社担当が分析・修正するとなるとなります。熟練開発者が書いたスクリプトでも、その開発者の支援無しに第三者がデバッグするのは元々困難な作業です。 これが非熟練者により開発されたものとなると、通常の十倍からそれ以上の工数を要する大変な作業となります。 このような状況では、スクラッチ開発（一から再開発）お勧めしたいのですが、膨れ上がった掟破りシステムをスクラッチ開発するには、多くの時間と費用を要するため、当社担当がデバッグすることになります。
さて、このような悲惨な状況下での頼みの綱がデバッガや分析ツールですが、旧FileMaker にも FileMaker Developer 5.5/6 （以下、Developer）という製品があり、これによりデバッグや分析を行うことができます。
Developerを使うと、下図のようなデータベースデザインレポート（実体は FileMakerのファイル）を作成することができます。 このレポートはシステムの開発量（フィールド、レイアウト、スクリプト等の数）を知るのに有用です。
一方、検索機能が不十分、というか無いに等しいので、保守や障害対応で特定のオブジェクトの検索を行うには、データベースデザインレポートは不適です。
例えば、システムの改変時にフィールドAに対して何らかの変更を加える場合、そのフィールドが影響を及ぼすオブジェクト（他のフィールド、スクリプト、レイアウト、値一覧、リレーション）が無いかをリストアップし、それぞれ検討を行い、悪影響があると判断される場合には対応が必要になります。この時、上記のデータベースデザインレポートには、フィールドAを指定して、関連するオブジェクトを抽出する機能がありません。
この種の検索機能が無いと膨大な作業を人力で行う事になりますが、これは実務上ほぼ不可能となります。このため当社ではオブジェクト検索を行う以下のサブシステムを用意しています。
図の「TPC Database Analyzer」は FileMaker 5.5/6用データベース分析ツールです。［検索条件］に「売上日」と入力して検索を実行すると、[売上日]を含むオブジェクトがすべて検索されます。その検索結果が下図です。
画面左を見るとレコード数が約3万1千ありますが、これがこのシステムを構成するオブジェクトの数です。該当件数が299となっていますが、これが［売上日］が関連するオブジェクトの数です。約3万1千あるオブジェクトから人力で［売上日］を含むオブジェクトをしらみつぶしに調べるのは、実務上ほぼ不可能ですが、299件であれば一つ一つチェックしていければ、時間はかかると思いますが、熟練の開発者であれば必要な修正を加えることが可能です。
このような分析ツールは障害や部分改変を行う際に限らず、新システムのスクラッチ開発時に旧システムを分析する際にも非常に有用なツールとなります。
(本項は21/10/14に加筆)
(NuckyT)
■ FileMaker 5/6等レガシーシステム関連記事
を使って追跡したいビーコンを選択します。上図では、「bcn2-8」 と 「bcn0-5」 の 2種類のビーコンを選択しています。
をクリックします。QuickIPSウインドウの「Webビューア」に指定した2つのビーコンの移動経路と時刻を示す図が表示されます。
