太古の FileMaker システムを延命させる！

 小社では 「売上猫くん 4.0」という自社製パッケージ製品（一部改変）をもう20年程、社内の見積・売上・請求管理システムとして使用しています。　「売上猫くん」は初期には FileMaker 3/4 により開発されたものです。　この太古のシステムは現在、  仮想マシン（Windows Server 2008）上のFileMaker Server 5.5 で公開され、Windows 10 を含む最新のWindows 機上のFileMaker Pro 5.5/6 から毎日アクセスされて使用されています。
　小社同様、FileMaker 5.x/6.0 でシステムを運用している企業・組織は一定数あり、当方の客先にも何社かはそのようなところがあります。
　このような FileMaker のレガシーシステムを運用する場合、まずネックとなるのがハードウェアの老巧化や故障によるリプレイスです。　本稿では「FileMaker レガシーシステムの仮想化による延命方法」を小社の客先である某社を例にご紹介します。

1. 某社の状況

1998年： 某社より生産・購買・販売・在庫管理システムの開発業務を受注。FileMaker 4 により開発を開始。数ヶ月後に首尾よくリリースに漕ぎ着ける。某社本社の Macintosh 上に FileMaker Server 5.5 を配置し、NTTの専用線  Digital Access による WAN を介して複数拠点で運用を開始。

2001年： FileMaker 5.5 へアップグレード。fmj から  fp5 へのファイル構造の変換が伴うアップグレードにも関わらず、難なく終了。 この際、サーバを Windows Server 2000 に変更。

2008年*1： Windows Terminal Service （後のRemote Desktop Service）を導入し、FileMaker Pro 5.5 をインストール。拠点のユーザはこのサーバ上の FileMaker クライアントを実行することにより、アプリの実行速度を改善。この際、FileMaker Serverを運用するサーバ機も Windows Server 2008 に変更（参考記事）。さらに、ネットワークの高速化とコスト低減を目的に Digital Access から インターネットVPN へ変更。　 インターネットVPNへの変更に伴うセキュリティ上のリスクへの備えとして、SonicWALL による IPS 、Gateway Antiviurs 等も併せて導入。

導入以来、数多の仕様変更を繰り返しながら、現在もFileMaker 5.5 の環境で運用中。

*1
2008年当時、小社内で Windows Server 2008 と FileMaker Server 5.5 の組み合わせによる運用実績はあったのですが、このようなレガシーシステムの運用はベンダーによる動作保証の対象外となることを事前に客先に十分説明しなければなりません。　レガシーシステムの延命は客先のリスクに関する理解と許容が重要だと思います。

2. さらなる延命へ

2008年に導入した RDSサーバですが、経年劣化によるリプレイスを検討するように、客先に数年前からお願いしていたところ、先ごろ、ようやくリプレイス案を出すように求められました。　ただ、運用実績のある Windows Server 2008 は既に発売中止になっていました。そこで以下のような図と共に提案書を客先に提出しました。

仮想環境はWindows Server 2012/2016 Standard 付属のHyper-V（ゲストOSが2ライセンス付属）

A案は単純リプレイス型ですが、新サーバを導入し、そこに現行のOS（Windows Server 2008）をインストールし、RDTアカウントやFileMakerが動作する環境を新たに構築し直す、というものです。　問題となるのは、前述のように Windows Server 2008 に公式対応するサーバ機が2017年現在ほとんど存在しないので、それを覚悟の上での実装となります（参考：Microsoft社のサポート期限一覧）。

B案は現行サーバを P2V （Physical to Virutal）し、これを　Hyper-V 2.0 で運用するというものです。これが上手くいくと 旧サーバのハードディスク情報をそのまま仮想マシン化でき、OSやアカウント情報の再構築・再設定が不要になるので、大変便利です。　半面、まったく異なるハードウェア環境へ移動することになるので、各種ドライバでエラーが発生したり、悪くすると初回起動時にブルースクリーンが表示されたりします。　安定運用期に入るまで気をぬけません。

C案は 新規にWindowsサーバを導入、ゲストOS も新たに作成し、その上にRDTアカウント等の再度設定しなおすものです。ゲストOS上での作業はほとんどA案と同様になります。P2Vに比べハードウェアの差異によるエラーやブルースクリーンやらの可能性はほぼなくなりますが、すべて一からの作業となります。

　提案書と概算見積をご提示した後に打ち合わせをしました。結果、サーバ故障時やリプレイス時に仮想マシンであれば迅速に復旧可能であることも勘案し、Windows Server 2016 を使用したB案で進行することになりました。ただ前述のように P2Vが失敗するリスクがあることをご説明し、B案不首尾の場合は、A案、C案、さらには Windows Server 2016 の 2012 へのダウングレード（D案*2） もバックアップとしてご提示しました。

*2
D案の提案理由は  SATO のあるラベルプリンタが Windows Server 2012 へは公式対応している一方、Windows 2016 に非対応であることによります。重要な周辺機器との互換性もレガシーシステムの延命を行うときには“要注意”となります。

3.　テスト環境での実装

新しいサーバ機の納品までしばらく時間があるため、客先の旧サーバを予め P2V してVHD(X)にし、当方の Windows Server 2016 の Hyper-V に入れ、事前にテストを行いました。仮想マシンを起動するとエラーイベントが複数発生していたので、一つ一つ潰していきました。　次に FileMaker Pro 5.5 （以下、FM5.5）を起動してテストを実施。　下図のようにクライアントPCから仮想サーバにRD接続。 FM5.5 を使用し FileMaker Server 5.5 （以下、FMS）上の12万件のデータが入った郵便番号ファイルを開き、ソートを実行・・・　「ん？ 」、なんかかなり遅い感じ。

確認のため、仮想サーバではなく、別の物理マシンのRDS から郵便番号ファイルにアクセス（クライアントPC→物理マシンRDS+FMP→FMS）すると、なんと3倍！速い。　クライアントPC→Win Server 2016 RDS+FMP→FMSで実行してもやはり3倍速い。

　ならば、仮想サーバ上に郵便番号.fp5 を配置して、ネットワークを介さずローカルで実行するとどうか？　一瞬 ＝ 数秒～10秒程度！で終了してしまいます。　ということで、仮想サーバの通信速度（上図の「FMP⇔FMS接続」）に問題があることが判りました。　実はここからがすごく大変で、 「Hyper-V ゲストOS 遅い」や「Hyper-V Guest OS slow」などをキーワードに、数日間、ググって試す、ググって試すを繰り返しました。　ググってまず最初に出てくるのが、NICの仮想マシンキュー（VMQ、Virtual Machine Queue）を オフ にせよ、というもの。これは内外のいろいろなところで書かれており、小社の別のHyper-V環境下のゲストOSでは劇的な効果があったのですが、今回の仮想マシンについては全く効果無しでした。　NICの「IPV4チェックサムオフロード」をオフにしろ、という記事も多く見かけましたがこれもダメ。
NICの設定は、ホスト側からだけではなく、仮想マシンからもいじってみましたがうまくいかず。
万策尽きたか、と思ったところで、突然光明が差しました。　それは、「レガシーネットワークアダプタ」の使用（下図）。

　仮想マシンのネットワークアダプタを作成する際、「ハードウェアの追加」を選択。この時、通常は「ネットワークアダプタ」が推奨されますが、ここで「レガシ ネットワーク アダプター」を図のように選んで“追加”します。　これを行うことにより、

ping -l 60000 hostname

の応答時間も劇的に改善し、12万件の郵便番号ソートも劇的に速くなりました。

　今回のゲストOSは Windows Server 2008 で、このOSは Hyper-V の「統合サービス」に対応しているので、上図では「ネットワーク アダプター」を選択するのがセオリーだと思うのですが、、、
ネットで調べてもレガシはオバーヘッドが多いので、「ネットワークアダプター」を使いなさいという記事しか見当たらりませんでしたが、レガシーのままテストを続行することにしました。

尚、上記の記事に関する後日談はこちらをご覧ください。


（土屋）


追記
「売上猫くん3.0」は1997年に FileMaker Pro 3 により開発されたものですが、 いまだにご愛用頂いているお客様がいらっしゃいます。 ただ、ハードウェアの老巧化の問題があるのでできる限り新バージョンへのアップグレードをお勧めしてます。　それはそれとして、 FileMaker Pro 3/4 のシステムを Windows NT 4.0 の仮想マシンで運用するというのは、実際やったことはありませんが、チャレンジしてみたい気もします。

■ FileMaker 5/6等レガシーシステム関連記事

まだまだいける FileMaker 5.5/6　― レガシーFileMaker の延命 2021 ―(21/07/24投稿)
レガシーFileMaker とOSの互換性、移行時の留意点について

IIS6 + FileMaker Web コンパニオン構成の Web サーバ機で TLS1.2 が動作するようにリバースプロキシを設定する (20/07/06投稿)
TLS1.2 非対応の IIS6 に Web ブラウザアクセス時に警告メッセージが出ないようにする

太古の FileMaker システムを延命させる！ ― 後日談FileMaker（17/09/07投稿）
下記記事のレガシー延命スキームの実施と結果について。

太古の FileMaker システムを延命させる！（17/04/25投稿）
Remote Desktop Server/FileMaker Pro 5.5 搭載の Windows Server 2008 物理マシンを P2Vし、Hyper-Vに移行することにより、レガシーシステムの延命を図る。

FileMaker 5.5/6 をモバイルで使う（16/05/25投稿）
Android/iOS に Remote Desktop Client を載せて、FileMaker Go のようなことをしてみます。

今なお輝くFileMaker 5.5/6（16/05/23投稿）
レガシーFileMaker の意外な利点。

参考リンク：
物理マシンを Hyper-V 仮想マシンに移行する（P2V）
Performance Tuning for Hyper-V Servers
Hyper-V network adapter differences
Windows Server 2012 Hyper-V の SR-IOV 構築手順 (1)

Google サイト（Google Sites）をバックアップする方法

　Google サイトを使っていらっしゃる方は、サイトのバックアップをどうするか悩むところかと思います。

google-sites-liberation で公開されているツールは動かない

 　ツールの最新版は、2011/04/27 で google-sites-liberation-1.0.4.jar  の公開が終わっています。

google-sites-liberation で公開されているツールの一覧

　　しかしながら、google-sites-liberation-1.0.4.jar　を実行すると、以下の認証エラーが出ます。

google-sites-liberation-1.0.4.jar を実行すると表示される認証エラー

GitHub からツールの最新版をダウンロードしてバックアップする

 　google-sites-liberation - issue #107 （ソースは英語）を確認すると、https://github.com/sih4sing5hong5/google-sites-liberation　の方で開発が続行しているので、そちらを確認します。


　操作手順は次のとおりです。

　1. Google Sites Import/Export Tool のセクションからツールをダウンロードします。
　最新バージョンは 1.0.6 です（2017/01/23 現在）。

Google Sites Import/Export Tool のダウンロード

　2. google-sites-liberation-1.0.6-jar-with-dependencies.jar　がダウンロードされますので、ダブルクリックで実行します。
　実行にあたっては事前に Java をインストールしておく必要があります。

 

Google Sites Import/Exportツール

　3. 必要事項を入力してから、“Get a token from browser” をクリックします。
　すると、google がユーザ許可を求めるページが表示されますので、“許可”ボタンをクリックします。
　※事前に Google アカウントにログインしておく必要があります。

google-sites-liberation のアクセスを許可する

　4. トークンが発行されますので、クリップボードにコピーします。

表示されたトークンをクリップボードにコピー

　5. コピーしたトークンをツールに貼りつけてから、“Export from Sites”　をクリックすると、バックアップが始まります。

　※当然のことながら、トークンには有効期限があります。トークンが無効になった場合は、“Get a token from brower”をクリックすることによって、トークンを取得しなおしてください。

　6. Export　Complete が表示されたらバックアップ完了です。

　その他のバックアップツールとして、弊社では WinHTTTrack を使用していますが、このツールの使い方については、また機会をあらためてご紹介したいと思います。

Slim フレームワークの REST(PDO) および RESTfm を使って CRUD のテストをしてみた

　先日の記事『Slim フレームワークの REST による FileMaker データベースへのアクセス』では、REST URI 経由で FileMaker DB アクセス実験を行うために Silm フレームワークを採用しました。
　この記事ではWeb クライアントからの GET 要求を受領してから、 FileMaker データベースに PDO 経由で SELECT クエリを発行してデータを戻すという、Slim REST 側の操作方法を簡単にご紹介しました。

　今回はこの Slim フレームワークの REST 機能のパフォーマンステストに加え、RESTfm でもテストを行ってみました。
　RESTfm は、Goya 社 MIT ライセンスで公開しているオープンソースの PHP コードであり、 FileMaker Server で公開されているデータベースに対する REST API 機能を簡単に実装できます。

　とても便利！と思ったのは、REST に不慣れなプログラマが「 あるテーブルのレコードにアクセスする方法を知りたい」と思ったときに、RESTfm 環境の index.html にアクセスするだけで、その URI を知ることができることです。 
　例えば、「EasyApp15‗p」データベースにログインすれば、任意のレイアウトのそれぞれのレコードへの URI が自動表示され（下図）、商品レイアウト上のレコード ID 10951 へのレコードにアクセスするためのリンクが表示されていることが確認できます。

　また、URL の最後の部分のファイル拡張子は .html ですが、これを .json、.xml、.txt、.fmpxml　などに書き換えるだけで、自動的に変換表示してくれるのもよいですね。これは、PHP でプログラムしたことがある方ならわかりますが、結果セットを簡単に見ることができ、とても楽ちんです。


　さて、本題に戻りますが、今回のパフォーマンス検証では、クライアントの Web ページから GET（取得 READ）、POST（新規作成  CREATE）、PUT（更新 UPDATE）、DELETE（削除） 要求を発行しました。

　比較用として、記事「 FileMaker API別にCRUDのテストをしてみた」で採用した API も一緒にグラフに掲載しておりますので、 併せて参考にしてください。

テスト環境

サーバ： Xeon 2.2GHz(1Core)/4GB RAM（Hyper-V 仮想マシン）
OS/Webサーバ： Windows Server 2012/IIS 8.0
FileMaker Server： Ver 15
使用言語： PHP
使用DB： FMEasy在庫 IWP/WD R1.5 （パイロット版）
使用REST API：
　Slim フレームワーク（PDO を使用）
　RESTfm 4.0.8 (FileMaker API for PHP を使用)
テスト概要：
　Slim フレームワーク REST URI 経由、および RESTfm の URI 経由でCRUD（Create/Read/Update/Delete）を行う簡単な Webアプリを作成・実行。

備考：

1. Slim フレームワークから FileMaker データベースへの接続オブジェクトは PDO(ODBC)です。
2.  RESTfm はその仕様上、内部的には FileMaker API for PHP で FileMaker Server に接続します。

　Slim フレームワークは Composer を使ってインストールします。
　詳しくは以下のリンクをご覧ください。
　https://www.slimframework.com/docs/start/installation.html

　RESTfm の最新版は 4.0.8 です。（2016/12/06 現在）
　以下のリンクよりダウンロードできます。
　https://github.com/GoyaPtyLtd/RESTfm/releases

　各テストはそれぞれ5回実施して開始から終了までの時間をプログラム上で測定。各5回の平均値を基にデータを作成しました。

Slim フレームワークを使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ（FireFox）

RESTfm を使用し、100件のレコードを REST URI 経由で検索・表示した際のブラウザウインドウ（FireFox）

GET メソッドによる Readテスト 1

テスト内容：
　94万レコードを持つテーブルから該当件数が N 件になるようにレコードを検索し、その中から100レコードのみを表示

結果：　XML圧勝！　Slim は遅いね

該当件数がN件になるようにレコードを検索し、その中から100件を表示

No. of found                     recs APIs	0	15000	30000	300000	600000	900000
FM API for PHP	0	0.22	0.34	1.76	3.28	4.74
XML	0	0.19	0.25	1.68	3.26	4.71
PDO	0	0.65	0.72	2.47	4.18	5.91
Slim REST PDO	0	0.46	0.63	3.86	7.3	10.69
RESTfm	0	0.88	0.91	2.32	3.91	5.4

補足：
　対象レコード件数が 1万件前後までは他の API とさほどパフォーマンスの差は感じられませんが、2万件あたりから差は開いていき、3万件を超過すると Slim REST PDO グラフ線（エンジ色）の傾斜は急激にきつくなっています。

　これに対し、RESTfm （黄色のグラフ線）は、該当件数が90万件でも、その中から 100件取り出す程度であれば、PDO よりもパフォーマンスは良いようです。

GET メソッドによる Readテスト 2

テスト内容：
　94万レコードを持つテーブルで 該当件数が3万件になるように検索し、N 件のレコードを表示

結果：　FM API for PHP と XML が有利　Slim と RESTfm はやはり遅い

該当件数が3万件なるように検索し、その中から N件を表示

No of fetched          　　        recs APIs	0	100	500	1000	2500	5000	7500	10000
FM API for PHP	0	0.34	0.81	1.36	4.32	6.99	10.51
XML	0	0.25	0.55	1.09	2.88	6.04	10.58	16.19
PDO	0	0.72	0.74	1.28	3.45	5.18	7.46	10.24
Slim REST PDO	0	0.64	1.6	2.75	6.15	12.32	18.22	23.72
RESTfm	0	0.97	4.31	7.97	19.25

補足

　100 件程度のデータを取り出すなら、やはり FM API for PHP および XML がパフォーマンスに優位性がみられます。
　取得件数が 5000 件を増えると PDO が優位になってきます。

　全体的にみて、Slim も RESTfm も取り出すデータ件数が増えるにしたがい、極端にパフォーマンスが低下しているのがわかります。

　2500件取得時には、Slim（注：Slimは PDO を使用） は PDO（注：Slim不使用の生PDO） の約 1.8倍の応答時間となっており、RESTfm は PDO の約 5.6倍の応答時間となっています。
　1万件取得時には、Slim は PDO の約 2.3倍の応答時間、RESTfm （注：FM API for PHP を使用）にいたっては、5000 件以降はサーバタイムアウト（30秒）が発生し、計測不能となっています。

CREATE テスト

テスト内容：
　94万レコードを持つテーブルに対して 100件のレコードを PHP のループにより作成。その後、作成した100件のレコードを検索して表示。

備考：

1. Slim フレームワークは、内部処理をある程度自由にプログラミングできるため、クライアント側から 100回 POST 要求を発行するパターンと、1 回の POST 要求で Slim フレームワーク側で 100 レコードをループ作成する方法で計測を行いました。
2. RESTfm は、URI のパターンは定型化されていますが、1件レコード作成用の URI と複数のレコード作成を一回のリクエストで実現するバルク処理用の URI が用意されているため、それぞれで計測を行いました。
   
   1件レコード作成用　RESTfm  URI パターン
   /RESTfm/{datagase}/layout/{layout}
   
   バルク作成用　RESTfm 　URI パターン
   /RESTfm/{database}/bulk/{layout}
   
   それぞれ、POST メソッドにて json 形式のデータを送信。

結果：　PDOの圧勝！ただ、バルク処理なら Slim PDO もいい感じ

100レコード連続作成結果

補足

　クライアント側から 1 回リクエストを発行し、REST 側で 100 回レコード作成したほうが、クライアントから 100 回リクエストを発行し、そのたびに 1 回レコードを作るよりパフォーマンスがよくなるのは当然ですけどね…

DELETE テスト

テスト内容：

　94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ削除。PDO および Slim では DELETE table WHERE ～により、100件を一度に抽出して一括削除。

 RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括削除。

備考：

バルク作成用　RESTfm 　URI パターン
/RESTfm/{database}/bulk/{layout}

DELETE メソッドにて json 形式の削除対象データを送信。

結果：　PDO 圧勝だが、Slim も RESTfm もバルク処理ならパフォーマンスはよい

100レコード削除結果

UPDATE テスト

テスト内容：
　94万レコードを持つテーブルを使用。FM API for PHP と XML では100レコードが対象となるように検索を実行。その後に PHP のループによりレコードを1件ずつ更新。　PDO および Slim では　UPDATE table SET ～ WHERE ～により、100件を一度に抽出して一括更新。　更新後、更新対象となったレコード100件を検索して表示。

　RESTfm では、100レコードが対象となるように検索を実行後、バルク処理を使ってレコードを一括更新。

備考：

バルク更新用　RESTfm 　URI パターン
/RESTfm/{database}/bulk/{layout}

注：PUT メソッドにて json 形式の更新データを送信。

結果：　PDO圧勝！Slimも奮闘。ただ、RESTfm は連続更新は苦手みたい

100レコード更新結果

結論：

　Web アクセスをする場合、間に何か挟めば余分なトラフィックが発生しますので、低速になるのはあたりまえです。というわけで、これは納得の結果です。

　すべてが自己完結するような Web アプリケーションを一から組めば、パフォーマンスに優れ、かつかゆいところに手が届くものができるかもしれませんが、それなりのコストと時間がかかってしまうことがネックとなります。

　多少パフォーマンスを犠牲にしてしまうことが許容される業務環境で、Web アプリケーションをなるべく短期間で開発する場合は、Slim のような REST フレームワークや、RESTfm のような既成 REST モジュールを採用することは選択肢としてありでしょう。

　しかしながら、どれを採用するにしても、覚えることが増えることには変わりません。

　Slim フレームワークの場合は、GET/POST/PUT/DELETE などの送信メソッドに対応した便利な機能が多数用意されていますが、それらを組み合わせてそれぞれの要求に応答した処理を行うには、担当プログラマが検討してコーディングする必要があります。
　組み方によっては、効率的にデータベースアクセスができるものが仕上がるという柔軟性はあります。

　RESTfm に関しては、操作用の定型 URI があらかじめ提供されているため、開発者がやりたいことさえ把握していれば、比較的高速に Web アプリケーションを完成させられるでしょう。Slim フレームワークに比べれば、覚えることが少ないのは良いと思います。
　ただし、RESTfm は FileMaker API for PHP を経由しますので、FileMaker API for PHP のパフォーマンスに縛られます。さらに、RESTfm 内部でも処理を行いますので、その分の処理コストが上乗せされます。
　つまり、FileMaker API for PHP が不得手な処理を RESTfm 経由で連続してやらせたりすると、パフォーマンスは極端に低下してしまいます。


　Web プログラミングは、長い目で見れば開発コストよりも運用コストの方がものを言います。特に、多数のクライアントを抱える Web サイトや、短時間に何人ものユーザが集中的にアクセスするようなサイトですと、Web サーバのパフォーマンス問題は避けては通れない話です。

　それぞれの特徴やパフォーマンスをある程度比較検討したうえで、業務要件に適したツール選択を行うのが失敗しない Web 開発につながるでしょう。

参考リンク：
Slim フレームワーク (英語)
Slim フレームワーク ユーザガイド (英語)
RESTfm （Goya 社）(英語)
RESTfm オンラインマニュアル (英語)
RESTfmがオープンソースに (Not only FileMaker)


（亀）