ラベル FileMaker Server の投稿を表示しています。 すべての投稿を表示
ラベル FileMaker Server の投稿を表示しています。 すべての投稿を表示

2018-08-31

FileMaker Server の運用をオンプレミス、AWS、FileMaker Cloud で比較してみる

 2017年7 月の FileMaker Cloud リリース以来、FileMaker Server のクラウド環境での運用も増えているようです。これにより企業では FileMaker Server 導入時に、オンプレミス(自社サーバ)、AWS EC2(Amazon社が提供するクラウドサービスで、ユーザは 自身で適切な Windows OS を選択て、FileMaker Server のインストールを行う)、FileMaker Cloud(FileMaker 社が Amazon マーケットプレースで提供する AWS EC2上で稼働する  FileMaker Server プラットフォーム)の 3 つのプラットフォームから選択することになります。

 ユーザはこれら3つのサービスでどれが自社に最適なのか悩むところですが、結論的なことを先に言ってしまうと、システム担当者がいない会社では FileMaker Cloud がお勧めです。FileMaker社が提供するチュートリアルに沿って設定を行えば、通常は数十分で FileMaker Server の準備が完了します。従来からある素の AWS EC2 に比べると、FileMaker Cloud は簡単です。

 オンプレミスかクラウドかはほとんどの場合、企業・組織がもつサーバポリシーによりほぼ自動的に決まってしまうかと思われます。データの秘匿性、セキュリティを重視する会社ではクラウド自身を禁止しているところもありますし、基幹システムはオンプレミスで、その他はクラウドに出すところ、IT部門の人員を削減するためサーバは全てクラウドにするところもあります。逆にサーバの仮想化をすすめ自社のサーバ室ですべてを運用することによりコストダウンを図る会社もあります(当社はこの形態に近いです)。

 本稿では、オンプレミス、AWS EC2、FileMaker Cloud の3つのプラットフォームを機能面と費用面から比較しています。機能については項目別に点数をつけていますが、企業・組織により各項目の重みは大きく異なるので、点数は参考値としてご覧ください。

 なお、3者とも FileMaker Server 17 の年間ライセンスを 25 使用することを前提としています。また、FileMaker Cloud はラインセンスのクラウドへの持ち込み(Bring Your Own License: BYOL)を前提としています。

 始めに機能・運用環境を比較してみます。FileMaker 社の公式ページ FileMaker ServerとFileMaker Cloudの比較 をベースに、さらに検討が必要と思われる項目を追加し、オンプレミス、AWS EC2、FileMaker Cloud 別に点数をつけてみました。

表1. オンプレミス、Amazos Web Service、FileMaker Cloud の機能・運用環境比較
No 比較項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud
(FMC)
説明
1 初期費用(ハード/ソフト) 1 5 5 表2参照
2  運用費用(ハード/ソフト)
4
3
2
表2及び表3参照
3  ハードウェア導入時の手間
2
4
4
OP:ハードウェア/UPS/バックアップ機器等の選定と購入が面倒
AWS:インスタンスタイプの選定のみ。OPに比べ簡単
FMC:インスタンスタイプの選定のみ。OPに比べ簡単
4  OS(選定/インストール/設定)
2
4
5
OP:自社で OS の選定、インストール、各種設定が必要
AWS:OSの選択は必要だが、インストールは不要
FMC: OS 選定もインストールも不要
5  FileMaker Server セットアップ
2
3
5
OP:自社ですべて行うため時間と労力がかかる
AWS:同上
FMC:20分程度(他に比べ簡単)
6  FileMakerライセンスの柔軟性
3
3
2
OP/AWS:自社で FMS ライセンスを用意する必要あり
FMC:AWS MarketPlace から BYOL、またはライセンス込みの FMC オプションを 選択可能。
AWS のユーザ登録とサーバ(EC2)、ストレージ(EBS)の指定が必要。
詳しくはFileMaker Cloud の購入方法を参照。
7  OS・ハードウェアの監視・管理
2
4
5
OP:社内担当者の負担大。
AWS:OS等ソフトウェアは社内担当者が管理、ハードウェアはAmazonにお任せ。
FMC:社内担当者の負担は最小。FMC 側でリアルタイム監視、OS更新通知、ソフトウェアパッチの自動通知
8  バックアップ
5
5
1
OP/AWS:サーバ管理者が計画、設定を行う必要があるが、バックアップスケジュールを自由に設定でき、単独ファイルのバックアップ、フルバックアップ等、柔軟な設計が可能。
FMC:FMC 側で自動メンテナンスを有効にすることによって自動バックアップ可能だが、サーバ環境の AWS スナップショットとなるため、バックアップスケジュールの柔軟性は低い。
FileMaker Cloud のバックアップの操作 を参照。
AWSスナップショットのバックアップはデフォルトで 20分ごとに実行される。一週間で計 504個のバックアップが保持され、古いものから順次自動削除される。よって、一週間より前のバックアップが必要な場合、他のバックアップ方法が必要となる。
バックアップのリストアは EBS ボリュームにスナップショットをアタッチする。ファイル単位の復旧は面倒(関連記事:FileMaker Cloud and Manual Backup Restore(英語))。
9  スケーラビリティ
2
4
4
OP:非仮想化環境の場合、ストレージ/メモリ/コア数の拡張には物理サーバ等のハードの入れ替えが伴うが、仮想マシンであれば拡張は容易で、費用は発生しない。
AWS/FMC:ストレジの拡張、サーバのアップグレードはオンラインで行えるが、拡張すれば運用コストもアップする。
10  最大アクセス数(FM社検証値)
5
5
3
OP/AWS:最大500 同時アクセス
FMC: 最大 100 同時アクセス
11  アップタイム(継続稼働)
3
4
4
OP:会社のポリシーと管理者の力量に依存。
AWS/FMC:99.99% のアップタイム(理論値と思われる)
12  BCP(災害時復旧)
2
4
4
OP:災害被災時は焼失等により復旧不能となる可能性あり。同時被災の可能性が少ない遠隔地ストレージへのバックアップが推奨される。
AWS/FMC:OPに比べ影響を受ける可能性は少ないと思われるが、被災可能性は無いとは言えない。
13  ネットワーク
5
3
3
OP:LAN専用の場合、インターネット環境に影響されない。WANの場合は回線品質に依存する。
AWS/FMC:インターネット接続必須。実行速度はAWSのインスタンスタイプに加え、自社が使用する回線品質にも依存する。OPに比べ、WANの構築は容易。
14  サーバ証明書
3
3
3
OP/AWS:自前の証明書をインストールする必要あり
FMC:Comodoの試用版SSL証明書が付属(90日)
15  サーバ認証
4
4
3
OP/AWS:FileMaker ユーザアカウント認証、Active Directory/Open Directory および OAuth 2.0 アイデンティティプロバイダを使用した外部認証
FMC:FileMaker ユーザアカウント認証、 OAuth 2.0 アイデンティティプロバイダを使用した外部認証
16  サーバサイドスクリプト
5
5
2
OP/AWS:サーバ管理者が計画、スケジュール設定
FMC:スケジュール機能は限定的
17  ESS
5
5
2
OP/AWS:ESS使用可
FMC:ESSアダプタ以外は ESS 使用可
18 ODBC/JDBC
5
5
4
OP/AWS:ドライバのインストールが必要
FMC:ドライバのインストールが必要、専用ドライバの提供あり
19  プラグイン
5
5
3
OP/AWS:使用可能
FMC:一部対応していないものがある可能性あり
20  カスタムWeb with PHPおよびXML
5
5
-
OP/AWS:使用可能
FMC:使用不可
21  FileMaker Data API
3
3
3
OP/AWS:使用可能
FMC:使用不可
注:
本機能は1ライセンスあたり年間24GB のアウトバウンド転送量が付属するが、この転送量を超過するとライセンスを追加購入するが必要ある
土屋企画評価
73
86
67

 次に初期費用をシミュレーションしてみます。下表が、オンプレミス、AWS EC2、FileMaker Cloud 導入時に発生する諸費用となります。

 当然ですが、オンプレミスは自前のサーバが必要となります。サーバが無い、あるいは既存のサーバに空きが無い場合、サーバを購入しなければなりません。

 これに対し、AWS および FileMaker Cloud は、初期費用としてサーバ証明書と FileMaker 年間ライセンス費用のみとなるので、初期費用を抑えることができます

表2. サーバ仕様と初期費用比較
No. オンプレミス
(OP)
AWS EC2
(AWS
FileMaker
Cloud(FMC)
補足
1  サーバ証明書
(COMODO 企業認証タイプ SSL)
¥27,864 ¥27,864 ¥27,864 ・金額は消費税込み。
・FileMaker Cloud はComodo試用版SSL証明書が付属(90日)するが、90日以降の運用を想定して料金に追加
2  FileMaker Server
年間ライセンス費用
¥390,000 ¥390,000 ¥390,000  
3  サーバ配置場所
自社
AWS AWS  
4  リージョン
自社
東京 東京 「東京」のAWS正式呼称:Asia Pacific (Tokyo)。FileMaker Cloud の場合、アジアで選択できるリージョンは、東京とシドニーのみ
5  フルフィルメント・オプション
AIM AIM AIM:Amazon Machine Image (64bit アーキテクチャ)
6
 サーバタイプ
(インスタンス種別)
EC2(t2.large)
EC2(t2.large)
 
7
 HDD/EBS
(追加ストレージ)容量
1000GB
40GB
40GB
FileMaker Cloud は40GBがデフォルトで付属
8
 メモリ
8GB
8GB
8GB
 
9  コア数 2 2 2  
10
 CPU
Intel Xeon
Intel Xeon
Intel Xeon
 
11  クロック
3.3GHz
3.3GHz
3.3GHz
 
12  OS
Win Svr 2016
Win Svr 2016
CentOS Linux
Win Svr 2016:Windows Server 2016
13  サーバハードウェア初期費用
¥300,000
¥0
¥0
OPはUPS、バックアップ機器等のサブシステム費用を含まず
初期費用計 ¥717,864 ¥417,864 ¥417,864  
備考:

年間ライセンスと永続ライセンスはどちらがお得なのか

同一バージョンの FileMaker Server を 3 年以上使する場合、永続ライセンス(買い切り)を購入したほうがコスト安となります。
 とういのは、FileMaker Server を 25ユーザで運用する場合、年間ライセンスは 39万円、これを 3年間使用し続けるとすると年間ライセンスは 117万円となり、この費用は永続ライセンスの金額と同額となるからです。
 よって、3年以上を超えて長く運用すればするほど永続ライセンスがお得です。

 なお、永続ライセンス自体は FileMaker Cloud で使用できない点にご注意ください。
 
 最後に月々の運用コストを比較してみましょう。

表3. 運用コスト月額概算比較
No. セットアップ項目 オンプレミス
(OP)
AWS EC2
(AWS)
FileMaker Cloud(FMC) 補足
1  1日の稼働時間(H)
24
24
24
 
2  消費電力(W)
400
400
400
ラックマウントサーバ Dell R330 相当の消費電力
3
 30日分の消費電力(kW)
288
288
288
400W X 24H X 30日÷1000 として計算
4  電力単価*2
¥17.60
東京電力の料金(夏季)
AWS/FileMaker Cloud は電力請求なし
5  電気代
¥5,068.80
AWS/FileMaker Cloud は電力請求なし
6  AWS の時間単価
$0.13   EC2(t2.large)
7
 FileMaker Cloud の時間単価
$0.117 EC2(t2.large)
8  30日分の料金
$93.60 $84.240 24H × 30日 × 上記時間単価(割引適用無し)
9 9 AWSのストレージ料金(40GB)
$4.80 料金に含む FileMaker Cloud で割り当てられる EBS (40GB)
目安
10  アウトバウンド転送料金 (50GB) ¥0 $6.86 $6.86 保守用のデータ転送として 50GB を想定
11  AWS/FileMaker Cloud 料金合計
$105.26 $91.10  
12  米国ドル為替レート
(2018/08/29 時点)
¥111.15
¥111.15
 
運用費用月額計*1
¥5,069
¥11,700 ¥10,126 *OPは高負荷状態を想定、冷却空調費用含まず


FileMaker Cloud の申し込みの柔軟性について

FileMaker Cloud のライセンスは、 BYOL(既存のライセンスの持ち込み) とマーケットプレース(5/10/25/100ユーザライセンス)での購入に分類できます。
 請求に関しては hourly(時間請求) と annual(年間請求)という分類になります。

 一見、簡単なようにみえますが、以下のようなことを考慮する必要があります。
  1. FileMaker Server の永続ライセンスは使用できない。但し、永続ライセンスを年間ライセンスに変換すれば Cloudでの使用が可能。
    永続ライセンスを年間ライセンスに変換し、FileMaker Cloud に適用するまでの手順が公式動画で紹介されています。
  2. BYOL はリザーブド・インスタンス(インスタンスの年間契約)を選択できないため、hourly (時間請求)の一択になる。
  3. BYOL を使用しない場合、hourly(時間請求)または annual (年間請求)を選択できるが、ユーザ数の区切りが 5ユーザ、10 ユーザ、25 ユーザ、100 ユーザの 4 択になる。同時アクセスユーザ数が 30 など、中途半端になる場合はコスト高になる可能性がある。
  4. annual を選択すると途中解約やダウングレードができない。この件に関するサポートやアップグレードの要望がある場合は要問合せ(英語)
FileMaker Cloud 自身の操作では、 BYOL を AWS のリザーブド・インスタンスに適用できない件は、FileMaker 公式のオンラインコミュニティでも議論されています。
 参考:BYOL to a reserved instance on FileMaker Cloud (英語)

 スレッド内でも言及されていますが、あらかじめ AWS でリザーブド・インスタンスを購入しておいて、後で FileMaker Cloud の BYOL に結びつけるという裏技もあるようです。ただし公式対応ではないため、微妙です。
 参考:Using an AWS Reserved Instance with FileMaker Cloud (英語)

まとめ

すでに社内に仮想環境があるのであれば、仮想マシンを一つ作成するだけで FileMaker Server 環境を構築できますので、FileMaker Cloud の必要性は低いと思います。これはAWS 等のクラウドを運用中の企業でも同様です。

 社内にサーバ技術者がいない、いろいろ考えず手っ取り早く FileMaker を試用したいといった場合には、 FileMaker Cloud が威力を発揮すると思います。ただ、FileMaker AWS への登録、キーペアの作成、FileMaker Cloud 申し込み、FileMaker Cloud へのキーペア紐づけ等の設定は最低限必要になるのでご留意ください。


■ FileMaker Cloud 関連情報(随時更新)
FileMaker Cloud のチュートリアル(18/09/04追記)

FileMaker Cloud スターティングガイド(18/09/04追記)

FileMaker Cloud Support ページ [英語](18/09/03追記)
FileMaker Cloud に関するサポート情報がコンパクトに表形式でまとめられています。



参考リンク:
*本稿執筆にあたり、以下を参考にしています。
FileMaker ServerとFileMaker Cloudの比較 [公式サイト]
FileMaker Cloud 技術仕様 [公式サイト]
ファイルメーカー、「FileMaker Cloud」の日本リリースを発表 [公式サイト]
料金単価表‐電力(従来からの料金プラン) [東京電力]

2017-12-30

Androidを使用した多数移動体位置監視モデル

 前稿前々稿では iBeacon を使用した商品の存否確認に関するモデル(定位置ビーコン監視モデル)について記しました。これらのモデルは iBeacon を使用するため、その電波の到達範囲は0m~100m程度であるため、iBeacon(あるいは iBeacon を取り付けた商品)がその範囲を超えて出ていってしまうと、当然のことながらビーコン監視端末は iBeacon の存在を認識できなくなります。
 今回は前二稿とは趣を変え、モバイル端末を物品に取り付けることによってその位置を適時把握するモデルを考えるとともに、そのモデルに則したプロトタイプを作成・試用してみました。

多数移動体位置監視モデル

 本モデルでは、数十~数百、数千の移動する商品、物品、人などの物体に モバイル端末を取り付け、地図上にその所在地を表示しています。

 下図のように、モバイル端末のインターネット接続にはMVNOが提供する移動体通信網を使用し、端末はGPSにより得られた自身の位置情報をアプリケーションサーバ経由でDBサーバに送ります。DBサーバは送られてきた端末の位置情報を保存します。また、各端末の位置の地図上表示も、PC等のブラウザからアプリケーションサーバを介して行います。

多数移動体位置監視モデルの概要図
図1 ― モデル概要

通信端末について

 当初、上図端末には Raspberry Pi  等のシングルボードコンピュータを使用する予定だったのですが、検討を進めていくうちにコスト増のモデルになり得ることがわかりました。

 具体的には、まず、ラズパイにSIMドングルやGPSモジュール(ドングル)を載せる必要が出てくるわけですが、実用面を考慮するとユーザに容易にシャットダウンしてもらうための電源On/Offスイッチ、電源供給が遮断された場合に備え、UPSも準備する必要があります。

 これらのモノは全て自前で調達して設定しなければならないため、価格、性能評価や設定の労力、携帯性、収納性等がネックとなります。ラズパイは途中まで設定やテストを行ったのですが、結局 Android 端末を使用することにしました。
 Android であれば All-in-One で低価格(¥5千前後~)で入手でき、携帯性・耐衝撃性(移動時にコネクタ/ケーブル類が外れる可能性がほぼ無い)に優れ、電源周りで気を遣うことがなく、安定性・信頼性も実績十分です。
今回のテストに使用した Android フォントタブレット
今回使用したAndroidフォンとタブレット、OUKITEL社(写真左から3/4番目は¥5千/台で購入できた)

移動体通信会社(MVNO)

 本モデルでは多数の Android 端末を使用してインターネット通信を行うため、通信費用はできるだけ抑制したいところです。最近は格安MVNOの登場で、1GB程度のデータ量であれば月額¥500程度で利用できるので、後述のようなシステム仕様であれば1端末月額¥500で運用可能と思われます。
 ただ、今回作成・テストするプロトタイプシステムでは、IoT 通信に特化したデータ通信サービスを展開する SORACOM を試用してみることにしました。
 SORACOM を採用するメリットは主に2つあります。一つは少ないデータ量の通信では費用を低く抑えられること、もう一つは SORACOM API を通じてSIMを制御したり、通信状況を取得することができる点です。SORACOM の実際の使用感については後述します。

システム構成とプロトタイプ開発

 これまでの経緯より、モバイル端末には Android、モバイル通信には SORACOM を使用することに決めました。アプリケーションサーバ(App Server)とデータベースについては、前者を node.js + express.js、後者を FileMaker Server 16 としました。Google Maps API は アプリケーションサーバが Android から取得した位置情報をもとに住所情報を取得する際、またPC/タブレット等でAndroidの位置を Google Map 上に展開する際に使用します(図2参照)。
Android 端末によるデバイス位置管理システムの構成
図2 ― システム機能概要

ハイブリッドアプリとアプリケーションサーバの仕様と処理分担

 Android の GPS から経緯度情報を引き出すには、Android Studio 等でネイティブアプリを作成するか、HTML5/Cordova 等によりハイブリッドアプリを開発することになりますが、今回は iOS 等への対応も視野に入れ、ハイブリッドアプリを採用することにしました(上図の tpcgeo.apk、以下、tpcgeoアプリ)。tpcgeoアプリはアプリケーションサーバに経緯度情報を送信するだけの単純なモノです。Google Maps API を介した住所情報の取得やデータの加工、データベースの更新といった多くの処理は、アプリケーションサーバ上の tpcgeo_server.js と tpcsql.js(前回記事参照) が担います。
 Android 側にあまり仕事をさせないのは、通信量を抑えるというコスト上の理由と、外部で使用するモバイル端末から送信する情報の量は必要最低限にするというセキュリティ上の理由によります。

プロトタイプのテスト

 上記の仕様に従ってそれぞれのアプリケーションを作成し、Android とアプリケーションサーバに必要なアプリケーションやファイルをインストールした状態で、SORACOM SIM(SORACOM Air/Global plan01s)の導入を行いました。図2のように2つのサーバにも必要なシステムをインストールし、テスト開始です。

まず、データベースを起動し、次にアプリケーションサーバで node.js/express.js 上で動作する tpcgeo-servers.js をコマンドプロンプトから起動します。

アプリケーションサーバで tpcgeo-server.js を起動
図3 ― アプリケーションサーバのプロンプトで tpcgeo-server.js を起動

次に、Android 上で tpcgeoアプリ を起動し、位置情報を送信する回数(Requests)と送信間隔(Interval、ミリ秒で指定)を指定します。下図では、10秒間隔で20回、自身の位置情報を送信するように設定されています。“Start”をタップすると、位置情報のアプリケーションサーバへの送信が開始されます。

tpcgeo 実行画面 (Android)
図4 ― Android でハイブリッドアプリ=tpcgeo 実行画面

アプリケーションサーバ上の tpcgeo-server.js が Android から位置情報を受信すると、Google Maps API に位置情報を送り、その戻り値として住所情報を取得します。そして必要なデータ加工を行った後にデータベースへの書き込みを行います。これらの処理が成功すと、tpcgeo-server.js を実行するプロンプト画面には以下のような実行履歴が表示されます。

プロンプト画面に表示される tpcgeo-server.js の実行ログ
図5 ―  tpcgeo-server.js のプロンプト上に表示される実行履歴

 プロンプトに update[OK] が表示されている場合、FileMaker データベースの位置データ(下図のLatitude、Longitude、Altitude等、白地のフィールド)の更新が成功したことを意味します。
Tpc Geo 端末管理画面(FileMaker)
図6 ― 端末の位置情報等を表示する FileMaker アプリ
オレンジの部分は SORACOM API から取得する SIMの状態、課金情報等。 

 各端末の位置は、PC等のブラウザで Google Map 上に表示できます。

各端末の位置が Google Map 上に展開される
図7 Windows Edge で Google Map 上に表示した各端末
データベースから取得した各端末の位置情報に基づき、Google Maps API を介して地図上に端末をマッピング

 赤地のマーカ(端末名)をクリックすると、詳細がポップアップ表示されます。

ピンのクリックによって住所情報をポップアップ表示
端末の所在住所等詳細がポップアップ表示される


SORACOM Global について

 前述のように今回は通信にSORACOM社の提供する SORACOM Air/Global plan01s というサービスを利用しました。本サービスに必要な費用は SIM 1枚当たり、以下のとおりです(2017/12/30現在)。
  • 初期費用(SIM本体含む):US$5
  • 基本料金:US$1.8/30日
  • データ通信料:US$0.2/MB
ご覧のように初期費用が約500円と非常に低いため、本サービスは多くの IoT/M2M システムのテスト環境構築には適していると思われます。
 ただ、今回の Android ベースのプロトタイプ・システムに類似したシステムを“常時”稼働させようとすると、通信量が想像以上に発生し、月額¥500 の MVNO に比べると割高になると考えられます。
 その理由は Android OSとその付属アプリが予期しない多くの通信を行うからです。No root タイプの Firewall を導入して不要な通信を遮断・監視しようとしても、Firewall を回避して発生する通信が発生するため、これがかなりの量に及びます(なお、Android の Firewall については、NetGuard の開発者・M66B さんが BBS 上で参考になるレスを書いています)。
 
 では、常時稼働ではなく、限定的に稼働するようなシステムではどうでしょうか?たとえば、Android 端末が 1カ月の 80%は社内や倉庫内にあり、その間通信を必要としないケース、あるいは特定時間帯、特定期間にのみ通信を必要とするケース。これらのケースであれば、SORACOM のほうが割安となる可能性があります。というのは、SORACOM API を使用することにより、特定の時間、あるいは特定の条件下で SIM のサービスを停止させたり、一定の通信量を超過した場合は管理者にメールや SMS で通知を行うシステムを構築できるからです。


(亀)


IoT/M2M関連リンク

2017-11-14

FMクライアントからサーバ上のODBC/node.js経由でデータベースをCRUDする

 FileMaker(以下、FM)から FileMaker Server (以下、FMS)上のデータベースに接続し、SQLクエリでデータを CRUD する場合に考えられる方法は、通常は以下の2つです。

  1. FM クライアント機に ODBC を入れて、SQL を実行スクリプトステップを使用する
  2. FM クライアント機に ODBC は入れ、ODBCはサーバにのみ入れ、サーバサイドスクリプトで SQL を実行スクリプトステップを使用する

 1. のデメリットは、全てクライアントにODBCを入れる必要があり、保守が面倒なこと、
 2. のデメリットは、サーバサイドスクリプト内はデバッガが使用できず、またクライアントで実行する場合と動作が異なることがあること、です。
また、「\"」のエスケープが面倒で醜いというのは両者に共通した欠点と思います。

 さて、上記の2つの方法のデメリットを回避する方法として、サーバに ODBC/node.js と当方で開発した tpcsql.js を置き、FM クライアントから FMS に対して SQL を発行して CRUD する方法をご紹介します。

 以下で詳述のデータベースサーバ側でクエリ文を待ち受けする Node.js スクリプト tpcsql.js は、以下のページより無償ダウンロードいただけます。

tpcsql.js を使った CRUD テスト方法

以下、環境構築の方法を記します。

注:
  • cURLを使用するため、FileMakerクライアント は Ver.16 以降が必須となります。
  • FMSは Ver16 でのみ検証を行っています。  
  1. FMS 16 の Admin Console で ODBC/JDBC を有効にします。

  2. FM 付属の FileMaker ODBC ドライバを、サーバにインストールします。
    クライアントへのODBCのインストールは不要です。
  3. FMS サーバ環境に Node.js をインストールします。
  4. 上記のサイトより、tpcsql.js をダウンロードし、サーバ 上の任意の場所に配置します。
  5. tpcsql.js に付属の Readme.txt に従って、Node.js 関連パッケージ群をインストールします。
  6. コマンドプロンプト画面から、node tpcsql.js と入力し、Enter キーを押下します。
    以下のようなメッセージが画面に表示されたら、クエリ待ち受け状態となります。

    ここでは、Web サーバのデフォルトポート 80 で待ち受けしますが、すでに他の Web サーバが稼働中の場合は、tpcsql.js に記載されているポート番号を変更(例: 80→8080)し、再起動してください。
  7. 付属のサンプルファイル「TpcQueryTester10.fmp12」 をFMSに配置し、公開します。
    FMクライアントからアクセスできるように、必要に応じて、ファイヤウォールの設定を変更します。
  8. FMクライアントを起動し、上記7で公開したTpcQueryTester10.fmp12 を開きます。
    ログイン情報は tpcsql.js に付属のドキュメントを参照してください。
  9.  [URI]フィールドの hostname の部分を FMS16 のホスト名、または IP アドレスに変更し、“Go”ボタンを押してみてください。

    上記で、[odbcDriver]、[host]、[uid]、[pwd]、[database]フィールドは、FMS16 側から見た場合の設定をあらかじめ入力してありますので、そのまま “Go”で実行できます。
  10. 以下のようにクエリ結果が [result]フィールドに戻ってきたら成功です。
  11.  Data テーブルには 1000 件分のテストデータがあらかじめ登録されています。
    クエリ内容を変更することによって、CRUD 操作をお試しいただけます。
 本稿では データベースは FileMaker Server を使用していますが、MySQL や SQL Server など、ODBC対応であれば他のデータベースでもここに記載した方法は使用できると思います。

tpcsql.jsの他のプラットフォームでの利用

 当初、tpcsql.js は Raspberry Pi 等で iBeaconの情報を収集・加工し、リモートのデータベースをSQLで簡単にCRUDするという M2M な利用を意図して企画したのですが、「FMクライアントから使えたら便利かも?」と思い、公開することにしました。
 もともと、FMのサーバサイドで「SQLを実行」がサポートされているので、「?」な方もいらっしゃるかと思いますが、「役にたったよ」という方が現れたらウレシイです。
 尚、tpcsql.js のラズパイでの利用は、稿を改めてご紹介できればと思います。


(亀澤)

IoT/M2M関連リンク

2017-11-05

iBeacon の適用モデルを考える 3 ― 定位置ビーコン監視モデル(2)

 前稿では、iOS と FileMaker Go を使用して定位置にあるビーコンを監視する方法について記しました。この方法は簡単でとても導入しやすいのですが、ビーコンを監視する端末が多数となる場合、iPad や FileMaker の費用負担がのしかかってきます。また、数十台から百台を超える端末を管理するとしたら、iPad/iPhoneでは大変でしょう。 そこで小社では、FileMaker Go に依存せず、様々なプラットフォームで利用可能なビーコン情報収集サブシステム(以下、TpcBScan.js)を作りました。

多様なデバイスで動作する TpcBScan.js  

TpcBScan.jsは node.js、express.js、nobe.js等の node.jsファミリー群の環境下で稼働する ビーコン情報収集サブシステムで、Windows、Macintosh、iOS、Android、Linux 等をOSとするデバイスで動作します*1。デバイスはBLE対応である必要があり、BLEアダプタ未搭載の場合、BLEアダプタ(ドングル)が必要となります。
 その機能は FileMaker の RangeBeacons関数に準じますが、http リクエストに対して戻り値を返します。 戻り値にはRangeBeacons形式とJSON形式を指定できます。Macintosh/Windows の FileMaker から TpcBScan.js を利用する場合は、「URLから挿入」スクリプトステップを使用します。

*1 Windows (WebDirectを含む)、Maintosh、iPad、Linux (Raspbian) で動作することを確認しています


「FMEasy在庫 IWP/WD R1.5(開発版)」のユーザの皆様には、TpcBScan.js β版 をダウンロード頂けます。詳しくはこちらをご参照ください。(2017/11/8更新)

Raspberry Pi をビーコン監視端末にする

今回、ビーコン監視を行う端末には、安定性、廉価性、保守性に優れるRaspberry Pi(BLE と LANに対応する機種)を使用することにしましたが、BLE/LANであれば Raspberry 以外のデバイスでも構いません。

 システムを構築するにあたっては、各種処理をサーバを中心に行わせる方法と、 端末を中心に実行させる方法の2種類が想定されます。

左がWi-Fi/BLE付の Raspberry Pi Zero W(¥3,000位)、右が Wi-Fi/BLEアダプタを取り付けた Pi Zero(無印)


端末駆動型システム構成

2種類の方法の1つが「端末駆動型」(下図)で、Raspberry端末がビーコン管理に必要な情報(端末が担当するビーコンのUUID/Major/Minorのリストや 、テーブルに保存されている存否情報のリスト=ManagedBeaconsList)をアプリケーションサーバを経由しデータベースサーバから取得します。端末は担当するビーコンが発信する情報(ActiveBeaconsList)を TpcBScan.js を使用して取得します。端末は取得した ManagedBeaconsList と ActiveBeaconsList を比較し、差異があれば アプリケーションサーバに対してデータベース更新等のリクエストを行います。差異が全くない場合は、サーバに更新リクエストは行いません。端末が多くの処理を行うのに対し、アプリケーションサーバの処理はレコードの送信と更新に限られます。 この端末駆動型は端末数やビーコン数が多くサーバ負荷を軽減したい場合に有効なシステム構成と思われます。


図1

サーバ駆動型システム構成

もう一つの方法が下図のサーバ駆動型で、この場合、Rapberry 端末はサーバからのリクエストに応じて自身が担当するビーコンの情報(ActiveBeaconsList)をサーバに返すのみです。一方サーバは、上述の「監視端末駆動型」で端末が担った ActiveBeaconsList 作成処理以外の全てを行うことになります。サーバは各端末に順繰りにリクエストを送り、戻り値を処理していくため、端末が増えると「監視端末駆動型」に比べてサーバの負荷はグッと増えます。この構成は監視端末の数が少なく、サーバが過負荷にならない場合に有効なシステム構成と思われます。
図2

サーバ駆動型を FileMaker Server でやってみる

実は当初、「端末駆動型」システムでも「サーバ駆動型」システムでも、Raspberry(Linux) を使うのであれば、node.js/JavaScript や PHP 等によるWebプログラミングは必須だと思いこんでいたのですが、下図の構成であれば、FileMaker による開発のみで、「サーバ駆動型」を実現できることに気づきました。というのは FileMaker スクリプトには、「URLから挿入」と言うスクリプトステップがあり、このステップは FileMaker Server から実行できるからです。具体的には FileMaker Server から この「URLから挿入」を使用して、各 Raspberry 端末上の node.js に対して、ビーコン情報を返すように http リクエストを送ります。あとは「サーバ駆動型システム構成」で書いたように、FileMaker Server がすべての処理を行います。

図3

 ということで、小社では上図のシステム構成に基づき、多端末対応のFileMaker プロトタイプを作成し、4つの Raspberry と1つのWindows ― 計5台のビーコン監視端末を使用してテストを行いました。本来であれば500台程ビーコンを用意して、各端末に100台ずつビーコンを割り当ててテストしたいところですが、手持ちのビーコンが21台しかないため、各端末が同じ21台のビーコンを監視するように設定しています。

 下図が今回のテストで FileMaker で作成したプロトタイプの画面です。監視端末があるビーコンの情報を受信しない場合は当該ビーコンの[存否]フィールドに「×」が、受信した場合は「OK」が入力されます。


図4 FMPから“Multi-term. TpcBScan”を実行すると、後述のサーバサイドスクリプトが実行される

英語版の動画




 実際にFileMaker からサーバサイドのビーコン監視スクリプトを実行した時の FileMaker Server Console 画面が以下です。通常、[クライアント]にはコンピュータ名が表示されるのですが、サーバサイドスクリプトを実行している場合は、実行されているスクリプト名が表示されるます。 赤枠部がサーバから実行されているスクリプトで、このスクリプト([srv]subTpcB監視~)が5台の端末に対して ActiveBeaconsList (ビーコンから受信した情報)を FileMaker Server に送信するようにリクエストし、それを受信すると ManagedBeaconsList と比較して、必要に応じてデータベースの更新や、メール/SMSの送信等の必要な処理を行います。本「定位置監視ビーコンモデル」は継続してビーコンを監視し続けるモデルですので、赤枠部の各スクリプトは中止命令を受けるまで、常駐して処理を続けます。


図5

 さて、当初の予想ではこのシステム構成は サーバに大きな負荷がかかると思っていたのですが、実際にCPUのパフォーマンス(下図)を見てみると、予想ほどの負荷はかからないようです。
 FileMaker Server 16 は理論上は無制限(検証値的には500)の接続が可能ですので、理論上は無制限のビーコン監視端末を管理できます。

図6

SQL データベースの利用

前項では、FileMaker Server (FMS)は、ビーコン情報を取得し、ビーコンの存否を判断し、データベースを更新するというアプリケーションサーバとデータベースサーバの2つの機能を兼ねています。 一方、図3右下の点線部のように、ODBC対応のデータベースサーバ(以下、SQL DB)を利用する場合は、FMS をアプリケーションサーバとして使用することも可能と思われます。この場合、FMS は SQL DB に対する CRUD を担うことになりますが、CRUD には FileMaker の ESS と サーバサイドからの「SQL を実行」が使えます。以前、 FMS をSQL DB の帳票作成サーバとして使うという記事を書きましたが、FMSをアプリケーションサーバとして使用すると、いろんなことが簡単にできる可能性が広がると思います。


以上


(土屋)



関連リンク